Partager via

Migrer une instance de cluster de basculement Always On SQL Server vers Azure VMware Solution

  • Article

Dans cet article, vous allez apprendre à migrer une instance de cluster de basculement SQL Server vers Azure VMware Solution. Actuellement, le service Azure VMware Solution ne prend pas en charge le Linked Mode hybride VMware pour connecter un serveur VMware vCenter local à un autre en cours d’exécution dans Azure VMware Solution. En raison de cette contrainte, ce processus nécessite l’utilisation de VMware HCX pour la migration. Pour plus d’informations sur la configuration de HCX, consultez Installer et activer VMware HCX dans Azure VMware Solution.

VMware HCX ne prend pas en charge la migration de machines virtuelles avec des contrôleurs SCSI en mode de partage physique attaché à une machine virtuelle. Toutefois, vous pouvez passer outre cette limitation en effectuant les étapes indiquées dans cette procédure et en utilisant la migration à froid VMware HCX Cold pour déplacer les différentes machines virtuelles qui composent le cluster.

Le diagramme montre l’architecture du basculement SQL Server pour Azure VMware Solution.

Remarque

Cette procédure nécessite un arrêt complet du cluster. Étant donné que le service SQL Server n’est pas disponible pendant la migration, planifiez en conséquence la période d’arrêt.

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 ont été configurés en suivant les meilleures pratiques et 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

  • Passez en revue et enregistrez la configuration du stockage et du réseau de chaque nœud du cluster.
  • Passez en revue et enregistrez la configuration WSFC.
  • Conservez des sauvegardes de toutes les bases de données SQL Server.
  • Sauvegardez les machines virtuelles du cluster.
  • Supprimez toutes les machines virtuelles des nœuds de cluster des groupes et règles DRS (Distributed Resource Scheduler) dont elles font partie.
  • 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 VMware HCX, consultez la documentation d’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.

Considérations relatives aux 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 vers le cloud Azure. La migration des instances de cluster de basculement SQL Server Always On vers Azure VMware Solution nécessite un temps d’arrêt complet de la base de données et de tous les nœuds de cluster. Toutefois, vous devez planifier l’exécution de la migration pendant les heures creuses avec une fenêtre de modification 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

Le cluster de basculement Windows Server nécessite un mécanisme de quorum pour maintenir le cluster.

Utilisez un nombre impair d’éléments de vote pour obtenir un nombre impair de nœuds dans le cluster ou à l’aide d’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 le témoin de disque, le disque doit être migré avec le stockage partagé du cluster à l’aide du scénario Migration du cluster de basculement.

Si le cluster utilise un témoin de partage de fichiers en cours d’exécution locale, le type de témoin pour votre cluster migré dépend du scénario Azure VMware Solution :

  • Extension de centre de données : gardez le témoin de partage de fichiers au niveau local. Vos charges de travail sont distribuées entre votre centre de données et Azure VMware Solution. Par conséquent, une connectivité entre les deux doit toujours être assurée. 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 cas, vous pouvez garder le témoin de partage de fichiers au niveau local pendant la migration au cas où vous devriez effectuer une restauration.
    • 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.
  • Récupération d'urgence et continuité d’activité : dans un scénario de récupération d'urgence, 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 sur le clustering de basculement. Pour plus d’informations sur le déploiement d’un témoin cloud dans le stockage Blob Azure, consultez la documentation Déployer un témoin cloud pour un cluster de basculement pour des informations détaillées.

Migrer le cluster de basculement

À des fins d’illustration, nous utilisons un cluster à deux nœuds avec Windows Server 2019 Datacenter et SQL Server 2019 Enterprise dans ce document. Windows Server 2022 et SQL Server 2022 sont également pris en charge par cette procédure.

  1. À partir de l’arrêt du client vSphere, le deuxième nœud du cluster.

  2. Accédez au premier nœud du cluster et ouvrez le Gestionnaire de cluster de basculement.

    • Vérifiez que le deuxième nœud est hors connexion et que tous les services et stockage en cluster sont sous le contrôle du premier nœud. Diagramme montrant la vérification du stockage de cluster du Gestionnaire de cluster de basculement Windows Server.

    • Arrêtez le cluster.

      Diagramme montrant un cluster d’arrêt avec gestionnaire du cluster de basculement Windows Server.

    • Vérifiez que tous les services de cluster sont correctement arrêtés sans erreur.

  3. Arrêtez le premier nœud du cluster.

  4. À partir du clientvSphere, modifiez les paramètres du deuxième nœud du cluster.

    • Supprimez tous les disques partagés de la configuration de la machine virtuelle.
    • Vérifiez que la case à cocher Supprimer les fichiers du magasin de données n’est pas cochée, car cela supprime définitivement le disque du magasin de données. Si cela se produit, vous devez récupérer le cluster à partir d’une sauvegarde précédente.
    • Faites passer Partage de bus SCSI de Physique à Aucun dans les contrôleurs SCSI virtuels utilisés pour le stockage partagé. En règle générale, ces contrôleurs sont de type VMware Paravirtual.

  5. Modifiez les paramètres de la première machine virtuelle de nœud. Faites passer Partage de bus SCSI de Physique à Aucun dans les contrôleurs SCSI.

  6. À partir du client vSphere, accédez à la zone de plug-in HCX. Sous Services, sélectionnez Migration>Migrer.

    • Sélectionnez la machine virtuelle du deuxième nœud.
    • Définissez le cluster vSphere dans le cloud privé à distance, qui héberge la ou les machine(s) virtuelle(s) SQL Server migrées, comme le Conteneur de calcul.
    • Sélectionnez le magasin de données vSAN comme stockage distant.
    • Sélectionnez un dossier si vous souhaitez placer les machines virtuelles dans un dossier spécifique. 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.
    • Conservez le même format que la source.
    • Sélectionnez Migration à froid 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 terminées avec l’état de réussite. L’erreur la plus courante est celle liée à la configuration du stockage. Vérifiez à nouveau l’absence de tout contrôleur SCSI présentant un paramètre de partage physique.
    • Sélectionnez Démarrer et la migration démarre.

  7. Répétez le même processus pour le premier nœud.

  8. Accédez au Client vSphere Azure VMware Solution et modifiez les paramètres du premier nœud et revenez au bus SCSI physique partageant le ou les contrôleur(s) SCSI gérant les disques partagés.

  9. Modifiez les paramètres du nœud 2 dans leClient vSphere.

    • Redéfinissez le partage de bus SCSI sur Physique dans le contrôleur SCSI gérant le stockage partagé.
    • Ajoutez les disques partagés de cluster au nœud en tant que stockage supplémentaire. Affectez-les au deuxième contrôleur SCSI.
    • Vérifiez que toutes les configurations de stockage sont identiques à celles enregistrées avant la migration.

  10. Mettez sous tension la machine virtuelle du premier nœud.

  11. Accédez à la machine virtuelle du premier nœud avec la console à distance VMware.

    • Vérifiez la configuration réseau de la machine virtuelle et vérifiez qu’elle peut atteindre les ressources locales et Azure.

    • Ouvrez le Gestionnaire du cluster de basculement et vérifiez les services de cluster.

      Diagramme montrant un résumé du cluster dans le Gestionnaire du cluster de basculement.

  12. Mettez sous tension la machine virtuelle du deuxième nœud.

  13. Accédez à la machine virtuelle du deuxième nœud depuis la console à distance VMware.

    • Vérifiez que Windows Server peut atteindre le stockage.
    • Dans le Gestionnaire du cluster de basculement, vérifiez que le deuxième nœud présente un état En ligne. Le diagramme montre l’état d’un nœud de cluster dans le Gestionnaire du cluster de basculement.

  14. À l’aide de SQL Server Management Studio, connectez-vous au nom du réseau de ressources de cluster SQL Server. Vérifiez que toutes les bases de données sont en ligne et accessibles.

Le diagramme montre une vérification de la connexion de SQL Server Management Studio à la base de données d’instance de cluster migrée.

Vérifiez la connectivité à SQL Server à partir d’autres systèmes et applications de votre infrastructure. Vérifiez que toutes les applications utilisant la ou les base(s) de données peuvent toujours y accéder.

Plus d’informations