Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Migrer SQL Server vers AWS à l'aide de groupes de disponibilité distribués
Créée par Praveen Marthala (AWS)
Source : SQL Server sur site | Cible : SQL Server sur EC2 | Type R : Rehost |
Environnement : PoC ou pilote | Technologies : bases de données ; migration | Charge de travail : Microsoft |
Services AWS : Amazon EC2 |
Récapitulatif
Les groupes de disponibilité Microsoft SQL Server Always On fournissent une solution de haute disponibilité (HA) et de reprise après sinistre (DR) pour SQL Server. Un groupe de disponibilité se compose d'une réplique principale qui accepte le trafic de lecture/écriture et d'un maximum de huit répliques secondaires qui acceptent le trafic de lecture. Un groupe de disponibilité est configuré sur un cluster Windows Server Failover (WSFC) comportant deux nœuds ou plus.
Les groupes de disponibilité distribués Microsoft SQL Server Always On fournissent une solution pour configurer deux groupes de disponibilité distincts entre deux WFSC indépendants. Les groupes de disponibilité qui font partie du groupe de disponibilité distribué ne doivent pas nécessairement se trouver dans le même centre de données. L'un des groupes de disponibilité peut se trouver sur site, tandis que l'autre groupe de disponibilité peut se trouver sur le cloud Amazon Web Services (AWS) sur des instances Amazon Elastic Compute Cloud (Amazon EC2) d'un domaine différent.
Ce modèle décrit les étapes d'utilisation d'un groupe de disponibilité distribué pour migrer des bases de données SQL Server locales faisant partie d'un groupe de disponibilité existant vers SQL Server avec des groupes de disponibilité configurés sur Amazon EC2. En suivant ce modèle, vous pouvez migrer les bases de données vers le cloud AWS avec un temps d'arrêt minimal lors de la transition. Les bases de données sont hautement disponibles sur AWS immédiatement après le passage. Vous pouvez également utiliser ce modèle pour faire passer le système d'exploitation sous-jacent sur site à AWS tout en conservant la même version de SQL Server.
Conditions préalables et limitations
Prérequis
Un compte AWS actif
AWS Direct Connect ou VPN de site à site AWS
La même version de SQL Server installée sur site et sur les deux nœuds d'AWS
Versions du produit
SQL Server version 2016 et versions ultérieures
SQL Server Enterprise Edition
Architecture
Pile technologique source
Base de données Microsoft SQL Server avec groupes de disponibilité Always On sur site
Pile technologique cible
Base de données Microsoft SQL Server avec groupes de disponibilité Always On sur Amazon EC2 sur le cloud AWS
Architecture de migration
Terminologie
WSFC 1 — WSFC sur site
WSFC 2 — WSFC sur le cloud AWS
AG 1 — Premier groupe de disponibilité, qui se trouve dans WSFC 1
AG 2 — Deuxième groupe de disponibilité, qui se trouve dans WSFC 2
Réplique principale de SQL Server : nœud dans AG 1 considéré comme le principal global pour toutes les écritures
Redirecteur SQL Server : nœud dans AG 2 qui reçoit des données de manière asynchrone à partir de la réplique principale de SQL Server
Réplique secondaire de SQL Server : nœuds d'AG 1 ou AG 2 qui reçoivent des données de manière synchrone en provenance de la réplique principale ou du redirecteur
Outils
AWS Direct Connect — AWS Direct Connect relie votre réseau interne à un site AWS Direct Connect via un câble Ethernet à fibre optique standard. Grâce à cette connexion, vous pouvez créer des interfaces virtuelles directement vers les services AWS publics, en contournant les fournisseurs de services Internet sur votre chemin réseau.
Amazon EC2 — Amazon Elastic Compute Cloud (Amazon EC2) fournit une capacité de calcul évolutive dans le cloud AWS. Vous pouvez utiliser Amazon EC2 pour lancer autant ou aussi peu de serveurs virtuels que vous le souhaitez, et vous pouvez les étendre ou les intégrer.
VPN de site à site AWS : le VPN de site à site AWS prend en charge la création d'un réseau privé virtuel (VPN). site-to-site Vous pouvez configurer le VPN pour transmettre le trafic entre les instances que vous lancez sur AWS et votre propre réseau distant.
Microsoft SQL Server Management Studio
— Microsoft SQL Server Management Studio (SSMS) est un environnement intégré de gestion de l'infrastructure SQL Server. Il fournit une interface utilisateur et un groupe d'outils dotés d'éditeurs de script riches qui interagissent avec SQL Server.
Épopées
| Tâche | Description | Compétences requises |
|---|---|---|
| Créez un WSFC sur AWS. | Créez des instances WSFC 2 sur Amazon EC2 avec deux nœuds pour HA. Vous utiliserez ce cluster de basculement pour créer le deuxième groupe de disponibilité (AG 2) sur AWS. | Administrateur système, SysOps administrateur |
| Créez le deuxième groupe de disponibilité sur WSFC 2. | À l'aide de SSMS, créez AG 2 sur deux nœuds dans WSFC 2. Le premier nœud de WSFC 2 agira en tant que redirecteur. Le deuxième nœud de WSFC 2 servira de réplique secondaire d'AG 2. À ce stade, aucune base de données n'est disponible dans AG 2. Il s'agit du point de départ pour configurer le groupe de disponibilité distribué. | DBA, Développeur |
| Créez des bases de données sans option de restauration sur AG 2. | Sauvegardez les bases de données du groupe de disponibilité sur site (AG 1). Restaurez les bases de données à la fois sur le redirecteur et sur la réplique secondaire d'AG 2 sans option de restauration. Lors de la restauration des bases de données, spécifiez un emplacement avec suffisamment d'espace disque pour les fichiers de données de base de données et les fichiers journaux. À ce stade, les bases de données sont en état de restauration. Ils ne font pas partie de l'AG 2 ou du groupe de disponibilité distribuée, et ils ne se synchronisent pas. | DBA, Développeur |
| Tâche | Description | Compétences requises |
|---|---|---|
| Créez le groupe de disponibilité distribué sur AG 1. | Pour créer le groupe de disponibilité distribué sur AG 1, utilisez l'
| DBA, Développeur |
| Créez le groupe de disponibilité distribuée sur AG 2. | Pour créer le groupe de disponibilité distribué sur AG 2, utilisez-le
Le groupe de disponibilité distribuée est créé entre AG 1 et AG 2. Les bases de données d'AG 2 ne sont pas encore configurées pour participer au flux de données d'AG 1 vers AG 2. | DBA, Développeur |
| Ajoutez des bases de données au redirecteur et à la réplique secondaire sur AG 2. | Ajoutez les bases de données au groupe de disponibilité distribuée en utilisant l' Cela démarre le flux de données asynchrone entre les bases de données sur AG 1 et AG 2. Le primaire global prend des écritures, envoie des données de manière synchrone à la réplique secondaire sur AG 1 et envoie des données de manière asynchrone au redirecteur sur AG 2. Le redirecteur sur AG 2 envoie des données de manière synchrone à la réplique secondaire sur AG 2. | DBA, Développeur |
| Tâche | Description | Compétences requises |
|---|---|---|
| Utilisez les DMV et les journaux SQL Server. | Surveillez l'état du flux de données entre deux groupes de disponibilité à l'aide de vues de gestion dynamiques (DMV) et de journaux SQL Server. Les DMV qui présentent un intérêt pour la surveillance incluent Pour connaître l'état de la synchronisation du redirecteur, surveillez l'état synchronisé dans le journal SQL Server du redirecteur. | DBA, Développeur |
| Tâche | Description | Compétences requises |
|---|---|---|
| Arrêtez tout le trafic vers le réplica principal. | Arrêtez le trafic entrant vers le réplica principal dans AG 1 afin qu'aucune activité d'écriture ne se produise sur les bases de données et que celles-ci soient prêtes pour la migration. | Propriétaire de l'application, développeur |
| Modifiez le mode de disponibilité du groupe de disponibilité distribué sur AG 1. | Sur le réplica principal, définissez le mode de disponibilité du groupe de disponibilité distribué sur synchrone. Une fois que vous avez changé le mode de disponibilité en mode synchrone, les données sont envoyées de manière synchrone depuis la réplique principale dans AG 1 vers le redirecteur dans AG 2. | DBA, Développeur |
| Vérifiez les LSN dans les deux groupes de disponibilité. | Vérifiez les derniers numéros de séquence logarithmique (LSN) dans AG 1 et AG 2. Aucune écriture n'ayant lieu dans la réplique principale d'AG 1, les données sont synchronisées et les derniers LSN des deux groupes de disponibilité doivent correspondre. | DBA, Développeur |
| Mettez AG 1 à jour avec le rôle secondaire. | Lorsque vous mettez à jour AG 1 vers le rôle secondaire, AG 1 perd le rôle de réplique principal et n'accepte pas les écritures, et le flux de données entre deux groupes de disponibilité s'arrête. | DBA, Développeur |
| Tâche | Description | Compétences requises |
|---|---|---|
| Basculez manuellement vers AG 2. | Sur le redirecteur d'AG 2, modifiez le groupe de disponibilité distribuée pour permettre la perte de données. Comme vous avez déjà vérifié et confirmé que les derniers LSN sur AG 1 et AG 2 correspondent, la perte de données n'est pas un problème. Lorsque vous autorisez la perte de données sur le transitaire dans AG 2, les rôles de AG 1 et AG 2 changent :
| DBA, Développeur |
| Modifiez le mode de disponibilité du groupe de disponibilité distribué sur AG 2. | Sur la réplique principale dans AG 2, changez le mode de disponibilité en mode asynchrone. Cela fait passer le mouvement des données d'AG 2 à AG 1, de synchrone à asynchrone. Cette étape est nécessaire pour éviter le temps de latence du réseau entre AG 2 et AG 1, le cas échéant, et n'aura aucun impact sur les performances de la base de données. | DBA, Développeur |
| Commencez à envoyer du trafic vers le nouveau réplica principal. | Mettez à jour la chaîne de connexion pour utiliser le point de terminaison URL de l'écouteur sur AG 2 pour envoyer du trafic aux bases de données. AG 2 accepte désormais les écritures et envoie des données au redirecteur dans AG 1, ainsi que l'envoi de données vers sa propre réplique secondaire dans AG 2. Les données se déplacent de manière asynchrone d'AG 2 à AG 1. | Propriétaire de l'application, développeur |
| Tâche | Description | Compétences requises |
|---|---|---|
| Supprimez le groupe de disponibilité distribuée sur AG 2. | Surveillez la migration pendant la durée prévue. Supprimez ensuite le groupe de disponibilité distribué sur AG 2 pour supprimer la configuration du groupe de disponibilité distribué entre AG 2 et AG 1. Cela supprime la configuration du groupe de disponibilité distribué et le flux de données entre AG 2 et AG 1 s'arrête. À ce stade, AG 2 est hautement disponible sur AWS, avec une réplique principale qui prend des écritures et une réplique secondaire dans le même groupe de disponibilité. | DBA, Développeur |
| Mettez hors service les serveurs locaux. | Mettez hors service les serveurs sur site de WSFC 1 qui font partie d'AG 1. | Administrateur système, SysOps administrateur |
Ressources connexes
