Lire en anglais

Partager via


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.

Diagramme montrant l’architecture d’Always On SQL Server pour Azure VMware Solution.

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 correspondantes sont étendus dans 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.

Scénario Temps d’arrêt prévu Notes
Instance autonome SQL Server Bas La migration est effectuée avec VMware vMotion, la base de données est disponible pendant la migration, mais il n’est pas recommandé de commiter les données critiques pendant ce temps.
Groupe de disponibilité SQL Server Always On Bas Le réplica principal sera toujours disponible pendant la migration du premier réplica secondaire et le réplica secondaire deviendra le réplica principal après le basculement initial vers Azure.
Instances de cluster de basculement Always On SQL Server Forte Tous les nœuds du cluster sont arrêtés et migrés à l’aide de VMware HCX Cold Migration. La durée du temps d’arrêt dépend de la taille de la base de données et de la vitesse du réseau privé vers le cloud Azure.

Considérations sur le quorum du cluster de basculement Windows Server

Les groupes de disponibilité Always On Microsoft SQL Server s’appuient sur le cluster de basculement Windows Server, ce qui nécessite un mécanisme de vote de quorum 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 :

  • Témoin de disque
  • 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 de centre de données : gardez le témoin de partage de fichiers localement. 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 de cloud exécuté 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 documentation du clustering de basculement. Pour plus d’informations sur le déploiement du témoin de cloud dans le Stockage Blob Azure, consultez Gérer un quorum de cluster pour un cluster de basculement.

Migrer un groupe de disponibilité Always On 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. Diagramme montrant les propriétés du groupe de disponibilité Always On.
    • Remplacez le Mode de disponibilité par Commit asynchrone uniquement pour le réplica à migrer.
    • 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 réseau locaux ont le segment étendu distant approprié dans Azure.
    • Sélectionnez Valider et vérifiez que toutes les vérifications sont réussies. L’erreur la plus courante est liée à la configuration du stockage. Vérifiez à nouveau qu’aucun contrôleur SCSI virtuel n’a de 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 est indiqué En ligne. Diagramme montrant le Tableau de bord du groupe de disponibilité Always On.

    • L’état Perte de données dans la colonne Préparation du basculement est normal, car le réplica est n’est pas synchronisé avec le 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 Basculement.

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

    Diagramme montrant la sélection du nouveau réplica principal pour Always On.

  9. Connectez-vous au réplica dans l’écran suivant avec vos informations d’identification d’administrateur de base de données. Diagramme montrant la connexion des informations d’identification d’administrateur du nouveau réplica principal.

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

    Diagramme montrant la vérification de l’opération du groupe de disponibilité Always On.

  11. Monitorez la progression du basculement dans l’écran suivant, sélectionnez Fermer une fois l’opération terminée. Diagramme montrant que le cluster Always On SQL Server est terminé.

  12. Actualisez la vue de l’Explorateur d’objets dans SQL Server Management Studio (SSMS), vérifiez que l’instance migrée est maintenant le réplica principal.

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

    Notes

    Migrez un réplica à la fois et vérifiez que tous les changements sont synchronisés dans le réplica après chaque migration. Ne migrez pas tous les réplicas en même temps avec la Migration en bloc HCX.

  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 les réplicas et qu’ils sont tous dans l’état Synchronisé. Diagramme montrant le Tableau de bord du groupe de disponibilité avec le nouveau réplica principal et tous les réplicas secondaires migrés dans l’é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.

      Diagramme montrant la définition d’un paramètre de basculement sur Automatique pour tous les réplicas.

Étapes suivantes