Migrer un groupe de disponibilité Always-On SQL Server vers Azure VMware Solution

Dans cet article, vous apprenez à migrer un groupe de disponibilité Always On SQL Server vers Azure VMware Solution. Pour VMware HCX, vous pouvez suivre la procédure de migration VMware vMotion.

Microsoft SQL Server (2019 et 2022) a été testé avec Windows Server (2019 et 2022) édition Centre de données avec les machines virtuelles déployées dans l’environnement local. Windows Server et SQL Server sont configurés conformément aux bonnes pratiques et aux recommandations de Microsoft et VMware. L’infrastructure source locale était VMware vSphere 7.0 Update 3 et VMware vSAN s’exécutant sur des serveurs Dell PowerEdge et des appareils Intel Optane P4800X SSD NVMe.

Prérequis

Voici les prérequis de la migration de votre instance SQL Server vers Azure VMware Solution.

• Vérifiez et enregistrez la configuration du stockage et du réseau de chaque nœud du cluster.
• Conservez des sauvegardes de toutes les bases de données SQL Server.
• Sauvegardez la ou les machines virtuelles hébergeant SQL Server.
• Supprimez la machine virtuelle des groupes et règles VMware vSphere Distributed Resource Scheduler (DRS).
• VMware HCX doit être configuré entre votre centre de données local et le cloud privé Azure VMware Solution qui exécute les charges de travail migrées. Pour plus d’informations sur la configuration de HCX, consultez la documentation Azure VMware Solution.
• Vérifiez que tous les segments réseau utilisés par SQL Server et les charges de travail qui l’utilisent sont étendus à votre cloud privé Azure VMware Solution. Pour vérifier cette étape, consultez Configurer l’extension réseau VMware HCX.

La connectivité VMware HCX sur VPN ou ExpressRoute peut être utilisée comme configuration réseau pour la migration.

VMware HCX sur VPN, en raison de sa bande passante limitée, est généralement adapté aux charges de travail pouvant supporter des temps d’arrêt plus longs (comme les environnements hors production).

Pour toutes les instances suivantes, la connectivité ExpressRoute est recommandée pour une migration :

• Environnements de production
• Charges de travail avec de grandes tailles de base de données
• Dans les scénarios où vous devez réduire les temps d’arrêt, nous vous recommandons la connectivité ExpressRoute pour la migration.

D’autres considérations sur les temps d’arrêt sont abordées dans la section suivante.

Considérations sur les temps d’arrêt

Le temps d’arrêt pendant une migration dépend de la taille de la base de données à migrer et de la vitesse de la connexion réseau privée au cloud Azure. Bien que les migrations du groupe de disponibilité SQL Server puissent être exécutées avec un temps d’arrêt minimal de la solution, le mieux est d’effectuer la migration pendant les heures creuses dans une fenêtre de changement préapprouvée.

Le tableau suivant indique le temps d’arrêt estimé pour la migration de chaque topologie SQL Server.

Éléments de quorum de cluster de basculement Windows Server à prendre en compte

Les groupes de disponibilité Always On de Microsoft SQL Server s’appuient sur le cluster de basculement de Windows Server, qui nécessite un mécanisme de quorum par vote pour maintenir la cohérence du cluster.

Un nombre impair d’éléments de vote est nécessaire, ce qui est obtenu par un nombre impair de nœuds dans le cluster ou en utilisant un témoin. Le témoin peut être configuré de trois façons différentes :

• Disque témoin
• Témoin de partage de fichiers
• Témoin de cloud

Si le cluster utilise un témoin de disque, le disque doit être migré avec le reste du stockage partagé du cluster en utilisant la procédure décrite dans ce document.

Si le cluster utilise un témoin de partage de fichiers exécuté localement, le type de témoin de votre cluster migré dépend du scénario Azure VMware Solution et plusieurs options sont proposées.

• Extension du centre de données : conserver le témoin de partage de fichiers dans l’environnement local. Vos charges de travail sont distribuées dans votre centre de données et Azure. Par conséquent, la connectivité entre votre centre de données et Azure doit toujours être disponible. Dans tous les cas, tenez compte des contraintes de bande passante et planifiez en conséquence.
• Sortie de centre de données : dans ce scénario, il y a deux options. Dans les deux options, vous pouvez garder localement le témoin de partage de fichiers pendant la migration au cas où vous deviez effectuer une restauration pendant le processus.
  • Déployez un nouveau témoin de partage de fichiers dans votre cloud privé Azure VMware Solution.
  • Déployez un témoin cloud s’exécutant dans le stockage Blob Azure dans la même région que le cloud privé Azure VMware Solution.
• Reprise d’activité et continuité d’activité : dans un scénario de reprise d’activité, la meilleure option et la plus fiable est de créer un témoin de cloud exécuté dans le Stockage Azure.
• Modernisation des applications : dans ce cas d’usage, la meilleure option est de déployer un témoin de cloud.

Pour plus d’informations sur la configuration et la gestion du quorum, consultez la rubrique Documentation du cluster de basculement. Pour plus d’informations sur le déploiement du témoin cloud dans le stockage Blob Azure, consultez la rubrique Gérer le quorum d’un cluster de basculement.

Migrer un groupe de disponibilité Always On de SQL Server

1. Accédez à votre groupe de disponibilité Always On avec SQL Server Management Studio en utilisant des informations d’identification d’administration.

   • Sélectionnez votre réplica principal et ouvrez Groupe de disponibilitéPropriétés.
   • Remplacez le Mode de disponibilité par Validation asynchrone uniquement pour le réplica qui doit être migré.
   • Remplacez le Mode de basculement par Manuel pour chaque membre du groupe de disponibilité.

2. Accédez au serveur vCenter local et passez à la zone HCX.

3. Sous Services, sélectionnez Migration>Migrer.

   • Sélectionnez une machine virtuelle exécutant le réplica secondaire de la base de données à migrer.
   • Définissez le cluster vSphere dans le cloud privé distant, qui héberge désormais la ou les machines virtuelles SQL Server migrées en tant que Conteneur de calcul.
   • Sélectionnez le magasin de données vSAN comme stockage distant.
   • Sélectionnez un dossier. Ce n’est pas obligatoire, mais nous vous recommandons de séparer les différentes charges de travail dans votre cloud privé Azure VMware Solution.
   • Gardez le Même format que la source.
   • Sélectionnez vMotion comme Profil de migration.
   • Dans Options étendues, sélectionnez Migrer des attributs personnalisés.
   • Vérifiez que les segments de réseau locaux ont le segment étendu distant approprié dans Azure.
   • Sélectionnez Valider et vérifiez que toutes les vérifications sont effectuées avec l’état de réussite. L’erreur la plus courante est liée à la configuration du stockage. Vérifiez qu’aucun contrôleur SCSI virtuel n’a le paramètre de partage physique.
   • Sélectionnez Lancer pour démarrer la migration.

4. Une fois la migration terminée, accédez au réplica migré et vérifiez la connectivité avec le reste des membres du groupe de disponibilité.

5. Dans SQL Server Management Studio, ouvrez le tableau de bord du groupe de disponibilité et vérifiez que le réplica apparaît comme En ligne.

   • L’état Perte de données dans la colonne Préparation du basculement est attendu, car le réplica est désynchronisé par rapport au réplica principal pendant la migration.

6. Modifiez à nouveau Groupe de disponibilitéPropriétés et définissez le Mode de disponibilité sur Validation synchrone.

   • Le réplica secondaire commence à synchroniser tous les changements du réplica principal survenus pendant la migration. Attendez qu’il s’affiche dans l’état Synchronisé.

7. Dans le Tableau de bord du groupe de disponibilité, dans SSMS, sélectionnez Démarrer l’Assistant de basculement.

8. Sélectionnez le réplica migré et sélectionnez Suivant.

   

9. Connectez-vous au réplica dans l’écran suivant avec vos informations d’identification d’administrateur de base de données.

10. Passez en revue les changements et sélectionnez Terminer pour démarrer l’opération de basculement.

    

11. Surveillez la progression du basculement dans l’écran suivant. Sélectionnez Fermer une fois l’opération terminée.

12. Actualisez la vue Explorateur d'objets dans SQL Server Management Studio (SSMS). Vérifiez que l’instance migrée est maintenant la réplique principale.

13. Répétez les étapes 1 à 6 pour le reste des réplicas du groupe de disponibilité.

    Remarque

    Migrez un réplica à la fois et vérifiez que toutes les modifications sont synchronisées avec le réplica après chaque migration. Ne migrez pas toutes les répliques en même temps à l’aide de HCX Bulk Migration.

14. Une fois terminée la migration de tous les réplicas, accédez à votre groupe de disponibilité Always On avec SQL Server Management Studio.

    • Ouvrez le tableau de bord et vérifiez qu’il n’y a aucune perte de données dans l’un des réplicas et que tous sont dans un état synchronisé .

    • Modifiez les Propriétés du groupe de disponibilité et définissez le Mode de basculement sur Automatique dans tous les réplicas.

      

Étapes suivantes

• Activer SQL Azure Hybrid Benefit pour Azure VMware Solution.
• Créer une stratégie de positionnement dans Azure VMware Solution
• Documentation du cluster de basculement de Windows Server
• Documentation Microsoft SQL Server 2019
• Documentation Microsoft SQL Server 2022
• Documentation technique Windows Server
• Planification de déploiements SQL Server à haute disponibilité et d’importance critique avec VMware vSphere
• VMware KB 100 2951 : conseils pour configurer Microsoft SQL Server dans une machine virtuelle
• Microsoft SQL Server 2019 dans VMware vSphere 7.0 Performance Study
• Conception de Microsoft SQL Server sur VMware vSphere – Guide des bonnes pratiques
• Configuration du cluster de basculement Windows Server dans VMware vSphere 7.0