Migration de clusters de basculement Windows

Un cluster de basculement Microsoft est un groupe de serveurs dont le stockage est principalement partagé entre eux. Vous pouvez utiliser des clusters de basculement pour améliorer la haute disponibilité de vos applications et services. Vous pouvez également migrer vos clusters de basculement vers le Cloud AWS pour bénéficier de sa fiabilité, de ses performances et d’un coût total de possession réduit.

Les clusters de basculement Windows fonctionnent différemment dans le cloud et dans les environnements sur site. Il est important de noter que seuls les clusters à sous-réseaux multiples peuvent être déployés dans le cloud. Contrairement aux environnements sur site, l’adresse IP d’un cluster de basculement Windows est attribuée à un adaptateur réseau élastique (ENA) plutôt qu’au niveau du système d’exploitation. Dans un environnement sur site, le système d’exploitation gère l’attribution des adresses IP, mais un fournisseur de cloud (AWS) gère l’attribution des adresses IP dans le cloud. Le clustering de basculement étant une fonctionnalité au niveau du système d’exploitation, il ne peut pas prendre le contrôle du basculement IP. Par conséquent, la même adresse IP ne peut pas basculer entre les nœuds. Pour contourner ce problème, vous pouvez utiliser des clusters à sous-réseaux multiples dans lesquels les clusters basculent vers une adresse IP secondaire. L’adresse IP secondaire est attribuée à l’ENA dans un autre sous-réseau et peut être mise en ligne. Pour de plus amples informations, veuillez consulter Failover Clustering Networking Basics and Fundamentals dans la documentation Microsoft.

Un processus de migration d’un cluster de basculement Windows vers AWS peut s’avérer complexe, mais une planification et une implémentation minutieuses permettent d’y parvenir en perturbant le moins possible vos opérations métier. Par exemple, chaque application est configurée différemment sur un cluster de basculement. Il est donc impératif de comprendre ses besoins, puis de déterminer au préalable comment ils peuvent être satisfaits dans le cloud. Le processus englobe les étapes suivantes :

• S’assurer que tous les nœuds du cluster exécutent la même version de Windows et toutes les mises à jour nécessaires

• Configuration du quorum de cluster

• Veiller à ce que l’intégralité des applications et des données soit sauvegardée et puisse être restaurée pendant la migration

Évaluation

La phase d’évaluation est une étape essentielle du processus de migration d’un cluster de basculement vers AWS. Au cours de cette phase, vous collectez des informations sur votre environnement actuel, déterminez la faisabilité de la migration vers AWS et identifiez les défis ou les risques potentiels. Nous vous recommandons de procéder comme suit lors de la phase d’évaluation :

• Évaluer l’état de préparation de vos applications : déterminez si vos applications peuvent être migrées vers AWS sans modification ou si elles doivent être mises à jour ou réécrites pour tirer parti des services natifs cloud.

• Évaluer vos exigences en matière de réseau et de sécurité : déterminez vos exigences en matière de réseau et de sécurité, y compris la configuration des pare-feux, des équilibreurs de charge et des VPN.

• Évaluer vos besoins en matière de migration de données : déterminez comment vos données sont migrées vers AWS, notamment leur taille et leur emplacement, le temps nécessaire à la migration et les éventuels coûts de transfert de données. Dans un environnement sur site, vous utilisez peut-être diverses technologies de stockage telles que JBOD, NAS et SAN. Chacune d’elles peut présenter des données à votre application par le biais de différentes méthodes d’accès, telles que les partages SAN Fiber Channel, iSCSI, SAS ou SMB/NFS.

• Identifier les risques et les défis potentiels : identifiez tous les risques ou défis potentiels susceptibles d’avoir un impact sur le processus de migration, tels que les temps d’arrêt, les problèmes de compatibilité ou les pertes de données.

• Estimation des coûts : estimez le coût de la migration vers AWS, y compris le coût des instances EC2, du stockage, du transfert de données et de tout autre service AWS requis.

• Création d’un plan de migration : sur la base des informations recueillies au cours de la phase d’évaluation, créez un plan de migration détaillé qui inclut les délais, les ressources requises et les étapes de la migration vers AWS.

Évaluation de votre environnement actuel

Évaluez votre environnement actuel, y compris les configurations matérielles et logicielles, afin de déterminer ce qui doit être migré vers AWS. Identifiez les dépendances entre les applications, les serveurs et les bases de données.

Détermination de votre stratégie de migration

Examinez les options qui s'offrent à vous pour migrer vers AWS, notamment une lift-and-shift approche ou une refonte de l'architecture de votre environnement afin de tirer parti des services cloud natifs.

• Migration classique de clusters de basculement : si vous configurez un cluster en partant de rien dans le cloud, vous pouvez suivre les étapes décrites dans Didacticiel : Configurer un cluster HPC Windows sur Amazon EC2 du Guide de l’utilisateur Amazon EC2 pour les instances Windows, tout en ignorant les étapes propres au HPC. Vous pouvez également créer un cluster de groupes de disponibilité SQL Server Always On sans passer par les étapes propres à SQL. Le stockage partagé est l’un des principaux facteurs à prendre en compte lors d’une migration de clusters de basculement. Amazon EBS multi-attach ne prend pas en charge la réservation persistante SCSI-3, mais Amazon FSx for Windows File Server et FSx for NetApp ONTAP fonctionnent tous deux bien en tant qu'options de stockage partagé. L’un des cas d’utilisation les plus courants est l’utilisation d’une instance de cluster de basculement Always On pour un cluster SQL Server avec Amazon FSx for Windows File Server. Pour de plus amples informations, veuillez consulter le billet Simplify your Microsoft SQL Server high availability deployments using Amazon FSx for Windows File Server sur le blog AWS Storage. L’étape suivante consiste à transférer les nœuds vers le cloud. Cela peut se faire en utilisant Application Migration Service. Pour plus d'informations, consultez le billet Migration de vos clusters Microsoft Windows vers AWS à l'aide de la CloudEndure migration sur le blog AWS Storage. Vous pouvez ensuite configurer un rôle en cluster pour votre application afin de garantir une haute disponibilité.

• Migration pratiquement sans interruption de service à l’aide d’un cluster étendu : un cluster étendu peut être une solution idéale si vous avez une application stratégique à migrer vers le cloud et que vous ne pouvez pas vous permettre une interruption de service. Avec un cluster étendu Microsoft, le site A et le site B doivent communiquer entre eux sur un réseau, mais ils peuvent disposer de leur propre espace de stockage partagé individuel. Vous pouvez l’utiliser à votre avantage dans un scénario de migration. Par exemple, votre source (qu’elle soit sur site ou dans le cloud d’un autre fournisseur) peut être le site A, qui dispose d’une connectivité réseau avec un Amazon VPC sur lequel vous déployez le site B. Une fois le site B opérationnel, vous pouvez passer au site B. Le mécanisme de réplication des données est essentiel dans cette approche, car votre technologie de stockage source peut avoir des facteurs limitatifs quant à la méthode de réplication qui pourrait fonctionner.

• Migration d'un cluster de basculement déployé sur VMware sur site vers VMware dans le cloud sur AWS — VMware Cloud on AWS prend en charge de manière native la réservation persistante SCSI-3. Cela permet d'héberger un cluster de basculement sur un disque de machine virtuelle (VMDK) sur VMware Cloud on AWS. Pour de plus amples informations, veuillez consulter Migrating SQL Server FCI cluster with shared disks to VMware Cloud on AWS dans la documentation VMware.

  Notice (Avis)

  Depuis le 30 avril 2024, VMware Cloud on n' AWS est plus revendu AWS ni par ses partenaires de distribution. Le service continuera d'être disponible via Broadcom. Nous vous encourageons à contacter votre AWS représentant pour plus de détails.

• Migration d'un FCI SQL Server à l'aide de volumes Amazon EBS Multi-Attach — Vous pouvez utiliser les réservations Amazon EBS Multi-Attach et NVMe pour créer des instances de cluster de basculement (FCI) SQL Server avec des io2 volumes Amazon EBS comme stockage partagé sur des clusters de basculement Windows Server. Ces volumes ne peuvent être attachés qu'à des instances situées dans la même zone de disponibilité. Le déploiement de clusters de basculement Windows Server à l'aide de io2 volumes Amazon EBS nécessite les derniers pilotes Windows qui traduisent les commandes de réservation SCSI en commandes de réservation NVMe. Pour plus d'informations sur la migration de vos FCI SQL Server sur site vers AWS dans une seule zone de disponibilité en utilisant cette approche, consultez le billet de blog AWS How to deploy a SQL Server failover cluster with Amazon EBS Multi-Attach on Windows Server.

La phase d’évaluation est essentielle pour garantir le succès de la migration de votre cluster de basculement vers AWS. Si vous prenez le temps de recueillir des informations et d’identifier les défis potentiels, vous pouvez élaborer un plan de migration complet qui minimise les interruptions de service, réduit les risques et garantit une transition fluide vers AWS.

Mobilisation

Lors de la migration d’un cluster de basculement vers AWS, la phase de mobilisation consiste à préparer le cluster pour la migration vers AWS et à le tester pour garantir son bon fonctionnement. La phase de mobilisation comprend les étapes suivantes :

1. Préparation de l’environnement cible : au cours de cette étape, vous créez les ressources AWS nécessaires pour héberger le cluster de basculement. Cela implique la configuration d’un Amazon VPC, de sous-réseaux, de groupes de sécurité et d’autres ressources nécessaires.

2. Préparation de l’environnement source : au cours de cette étape, vous préparez le cluster de basculement existant pour la migration. Cela peut impliquer de modifier la configuration du réseau, de configurer la réplication ou d’installer les logiciels nécessaires.

3. Validation du cluster : une fois les environnements source et cible préparés, vous pouvez effectuer un test de validation pour vous assurer que le cluster fonctionne correctement. Cela implique d’exécuter une série de tests pour s’assurer que le cluster peut basculer avec succès vers l’environnement cible.

4. Création d’un lien de réplication : après le test de validation, vous pouvez créer un lien de réplication entre les environnements source et cible. Cela garantit que toutes les modifications apportées à l’environnement source sont répliquées dans l’environnement cible.

5. Surveillance de la réplication : une fois le lien de réplication établi, surveillez le processus de réplication pour vous assurer que toutes les modifications sont correctement répliquées.

6. Basculement du cluster : après avoir vérifié que la réplication fonctionne correctement, effectuez le basculement final vers l’environnement cible. Cela implique d’arrêter les services de cluster sur l’environnement source et de les démarrer sur l’environnement cible.

7. Test du basculement : une fois le basculement terminé, effectuez un test pour vous assurer que les applications et les services exécutés sur le cluster fonctionnent correctement dans le nouvel environnement.

Migrer

La migration d’un cluster de basculement Microsoft peut être un processus complexe qui nécessite une planification et une mise en œuvre minutieuses pour garantir un résultat satisfaisant. Il est essentiel d’évaluer minutieusement l’environnement existant, d’identifier les problèmes potentiels et d’élaborer un plan de migration complet comprenant des tests et une validation avant d’apporter des modifications à l’environnement de production. Pendant la phase de migration, il est important de suivre le processus de près et de corriger rapidement tout problème ou comportement inattendu. La communication et la collaboration entre toutes les parties prenantes, y compris les équipes informatiques, les utilisateurs professionnels et les fournisseurs, sont essentielles au bon déroulement du processus de migration.

En outre, il est important de prendre en compte l’impact de la migration sur les applications ou services tiers exécutés sur le cluster de basculement. Identifiez toutes les dépendances et testez soigneusement ces applications pour vous assurer qu’elles continuent de fonctionner comme prévu après la migration. Un autre aspect clé de la phase de migration consiste à établir un plan de restauration en cas de problème ou d’échec imprévu pendant le processus de migration. Ce plan inclut idéalement une procédure pour annuler la migration et restaurer l’environnement d’origine, tout en minimisant tout impact sur l’environnement de production.

Enfin, une fois que la migration est terminée et que le cluster de basculement s’exécute correctement dans le nouvel environnement, il est important de procéder à une validation et à des tests post-migration pour confirmer que tout fonctionne comme prévu. Il s’agit notamment de contrôler les performances, de valider les capacités de basculement et de s’assurer que toutes les applications et tous les services fonctionnent correctement.