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 le serveur vers AWS des groupes de disponibilité distribués
Créée par Praveen Marthala () AWS
Source : SQL serveur sur site | Cible : SQL Serveur activé EC2 | Type R : Rehost |
Environnement : PoC ou pilote | Technologies : bases de données ; migration | Charge de travail : Microsoft |
AWSservices : 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 groupes indépendantsWFSCs. 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 (AmazonEC2) 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 de SQL serveur sur site faisant partie d'un groupe de disponibilité existant vers un SQL serveur avec des groupes de disponibilité configurés sur AmazonEC2. En suivant ce modèle, vous pouvez migrer les bases de données vers le AWS cloud avec un minimum de temps d'arrêt lors du passage au cloud. Les bases de données sont hautement disponibles AWS immédiatement après le passage. Vous pouvez également utiliser ce modèle pour faire passer le système d'exploitation sous-jacent du système d'exploitation AWS local à la même version de SQL Server.
Conditions préalables et limitations
Prérequis
Un AWS compte actif
AWSDirect Connect ou AWS Site-to-Site VPN
La même version du SQL serveur installée sur site et sur les deux nœuds sur AWS
Versions du produit
SQLServer version 2016 et versions ultérieures
SQLServer 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 EC2 sur Amazon on the AWS Cloud
Architecture de migration
Terminologie
WSFC1 — WSFC sur place
WSFC2 — WSFC sur le AWS cloud
AG 1 — Premier groupe de disponibilité, qui est en WSFC 1
AG 2 — Deuxième groupe de disponibilité, qui se trouve dans le groupe WSFC 2
SQLRéplique principale du serveur : nœud dans AG 1 considéré comme le principal global pour toutes les écritures
SQLRedirecteur de serveur — Nœud dans AG 2 qui reçoit les données de manière asynchrone à partir de la SQL réplique principale du serveur
SQLRéplique secondaire du serveur : 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
AWSDirect Connect — AWS Direct Connect relie votre réseau interne à un emplacement 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 AWS services publics, en contournant les fournisseurs de services Internet sur votre chemin réseau.
Amazon EC2 — Amazon Elastic Compute Cloud (AmazonEC2) fournit une capacité de calcul évolutive dans le AWS cloud. 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.
AWS Site-to-SiteVPN— AWS Site-to-Site VPN prend en charge la création d'un réseau privé site-to-site virtuel (VPN). Vous pouvez configurer le VPN pour transmettre le trafic entre les instances sur lesquelles vous lancez 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 de SQL serveurs. Il fournit une interface utilisateur et un groupe d'outils dotés d'éditeurs de script riches qui interagissent avec le SQL serveur.
Épopées
| Tâche | Description | Compétences requises |
|---|---|---|
Créez WSFC unAWS. | Créez WSFC 2 EC2 instances sur Amazon avec deux nœuds pour HA. Vous utiliserez ce cluster de basculement pour créer le deuxième groupe de disponibilité (AG 2) surAWS. | Administrateur système, SysOps administrateur |
Créez le deuxième groupe de disponibilité sur WSFC 2. | En utilisantSSMS, créez AG 2 sur deux nœuds en WSFC 2. Le premier nœud sur WSFC 2 agira en tant que redirecteur. Le deuxième nœud en 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 de la configuration du 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 lance un 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 |
|---|---|---|
DMVsJournaux d'utilisation et de SQL serveur. | Surveillez l'état du flux de données entre deux groupes de disponibilité à l'aide des vues de gestion dynamiques (DMVs) et des journaux SQL du serveur. DMVsqui présentent un intérêt pour le suivi incluent Pour connaître l'état de la synchronisation du redirecteur, surveillez l'état synchronisé dans le journal du SQL serveur sur le 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 le LSNs dans les deux groupes de disponibilité. | Vérifiez les derniers numéros de séquence log (LSNs) dans AG 1 et AG 2. Aucune écriture n'ayant lieu dans le réplica principal d'AG 1, les données sont synchronisées et les derniers groupes LSNs 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 dernières données LSNs 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 URL terminaison 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 de l'AG 2 à l'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 surAWS, 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 en WSFC 1 qui font partie d'AG 1. | Administrateur système, SysOps administrateur |
Ressources connexes
