Implémenter des clusters étendus

Effectué

Traditionnellement, les clusters de basculement fournissaient une protection haute disponibilité contre les défaillances localisées sur un ou plusieurs nœuds de cluster résidant dans le même emplacement physique. Vous pouvez utiliser des clusters étendus lorsqu’il est nécessaire de fournir les fonctionnalités équivalentes dans plusieurs emplacements physiques.

Que sont les clusters étendus ?

Un cluster étendu implémente la haute disponibilité et la récupération d’urgence sur deux emplacements physiques distincts. Les deux emplacements hébergent un système de stockage distinct, avec une réplication synchrone et unidirectionnelle à partir du site principal vers le site secondaire. Si une défaillance affecte la disponibilité du site principal, le cluster transfère automatiquement ses charges de travail vers les nœuds du site survivant pour réduire le temps d’arrêt. Pour les événements de maintenance planifiés sur le site principal, vous pouvez utiliser la migration dynamique Hyper-V pour transférer en toute transparence des charges de travail vers l’autre site, évitant ainsi totalement les temps d’arrêt.

L’utilisation de clusters étendus offre plusieurs avantages par rapport à la maintenance manuelle d’un site de récupération d’urgence :

  • Réplication automatique et basculement automatique des charges de travail en cluster.
  • Réduire les coûts administratifs.
  • Réduire le risque d’erreur humaine, qui est inhérent aux processus manuels.

En revanche, les clusters étendus sont plus complexes à concevoir et à implémenter. Ils nécessitent également un investissement supplémentaire dans l’infrastructure de stockage et de réseau.

Vue d’ensemble du réplica de stockage

Les clusters étendus tirent parti du réplica de stockage, une fonctionnalité de Windows Server qui assure la réplication des volumes entre les serveurs ou les clusters pour la récupération d’urgence. En utilisant le réplica de stockage, les clusters étendus peuvent synchroniser les volumes de stockage attachés aux nœuds de cluster étendus dans deux emplacements distincts.

Le réplica de stockage prend en charge la réplication synchrone et asynchrone :

  • La réplication synchrone réplique les données sur un réseau à faible latence, en quelques millisecondes de temps d’aller-retour, garantissant ainsi l’absence de perte de données au niveau du système de fichiers pendant un basculement.
  • La réplication asynchrone réplique les données sur des distances plus longues qui sont sujettes à des latences plus élevées, mais sans garantie que les deux sites ont des copies identiques des données au moment du basculement.

Important

Les clusters étendus nécessitent une réplication synchrone. L’exigence de réplication synchrone applicable aux clusters étendus impose une limite de 5 ms de latence réseau entre deux groupes de nœuds de cluster dans les sites répliqués. En fonction des caractéristiques de connectivité du réseau physique, cette contrainte se traduit généralement par environ 30-40 kilomètres de distance.

Représentation de l’architecture d’un cluster étendu actif-passif.

Fonctionnalités du réplica de stockage

Les principales fonctionnalités du réplica de stockage sont répertoriées dans le tableau suivant.

Caractéristique Descriptif
Réplication au niveau du bloc Avec la réplication au niveau du bloc, il n’existe aucun risque de verrouillage de fichier.
Simplicité Vous pouvez vous appuyer sur le Windows Admin Center pour vous guider tout au long du processus de création d’un partenariat de réplication entre deux serveurs. Pour déployer un cluster étendu, vous pouvez utiliser un assistant basé sur le Gestionnaire du cluster de basculement.
Utiliser SMB (Server Message Block) 3.0 Le réplica de stockage s’appuie sur SMB 3. x, introduit dans Windows Server 2012 et considérablement amélioré dans les versions ultérieures de Windows Server. Toutes les caractéristiques avancées de SMB, telles que SMB Multichannel et SMB Direct, sont disponibles pour le réplica de stockage.
Security Le réplica de stockage offre un large éventail de mécanismes de sécurité, dont la signature de paquets, le chiffrement de données complet AES-128-GCM, la prise en charge de l’accélération de chiffrement tierce et l’intégrité de pré-authentification pour la prévention des attaques de l’intercepteur. Le réplica de stockage utilise Kerberos AES256 pour toutes les authentifications entre les nœuds.
Contraintes de réseau Dans les cas où il existe plusieurs chemins d’accès réseau entre les volumes répliqués, vous pouvez configurer le trafic du réplica de stockage pour utiliser des cartes réseau désignées. Cela vous permet de réduire l’impact potentiel du trafic de réplication sur les charges de travail de production.
Approvisionnement à la demande Vous avez la possibilité d’implémenter l’allocation dynamique dans les espaces de stockage direct, réduisant ainsi les temps de réplication initiale.

Conditions préalables pour le déploiement de clusters étendus

Les conditions requises pour l’implémentation de clusters étendus sont les suivantes :

  • Les nœuds de cluster doivent être membres de la même forêt AD DS approuvée.

  • Chaque nœud de cluster doit avoir au moins 2 Go de RAM et deux cœurs de processeur par serveur.

  • Chaque nœud de cluster doit exécuter l’édition Windows Server 2025 Datacenter ou Windows Server 2016 Datacenter. Il est possible d’utiliser l’édition Windows Server 2025 Standard, mais cette configuration prend en charge la réplication d’un volume unique pouvant atteindre jusqu’à 2 téraoctets (To) uniquement.

  • Chaque nœud de cluster doit avoir au moins 1 carte Ethernet Gigabit pour la réplication synchrone, bien que l’accès direct à la mémoire à distance (RDMA) soit préférable.

  • Deux ensembles de volumes (un pour les données et l’autre pour les journaux) sur le site principal et le site secondaire, avec les paramètres suivants :

  • Les disques doivent être initialisés en tant que table de partition GUID (GPT), plutôt qu’en tant qu’enregistrement de démarrage principal (MBR).

    • Les volumes doivent être formatés avec ReFS ou NTFS.
    • Les tailles de volume de données et les tailles de secteur doivent correspondre.
    • Les tailles de volume de journaux et les tailles de secteur doivent correspondre.
    • Les volumes de journaux doivent utiliser un stockage plus rapide que les volumes de données.
    • Les volumes de journaux ne doivent pas être utilisés pour d’autres charges de travail.
  • Une connectivité bidirectionnelle via le protocole ICMP (Internet Control Message Protocol), SMB (port 445, plus le port 5445 pour SMB Direct) et Web Services-Management (WS-MAN) (port 5985) entre les deux sites.

  • Réseau entre les serveurs disposant d’une bande passante suffisante pour correspondre aux écritures d’E/S des charges de travail en cluster et latence aller-retour inférieure à 5 ms.

Considérations relatives au déploiement d’un cluster étendu

Les clusters étendus ne sont pas adaptés à chaque charge de travail et chaque scénario. Quand vous concevez une solution de cluster étendu, identifiez clairement les exigences et les attentes de l’organisation. En outre, gardez à l’esprit que les clusters étendus imposent davantage de charge de gestion que les clusters traditionnels dans lesquels tous les nœuds résident dans le même emplacement physique. Vous devez également réfléchir soigneusement au choix optimal du témoin de quorum pour optimiser sa disponibilité en cas de sinistre affectant un site physique entier.

Important

Les applications et les services avec état tels que Microsoft SQL Server, Hyper-V, Microsoft Exchange Server et AD DS doivent utiliser leurs propres mécanismes de résilience natifs plutôt que de s’appuyer sur des clusters étendus pour la haute disponibilité.

Considérations relatives au basculement et à la restauration automatique dans un cluster étendu

Dans le cadre de la planification du déploiement d’un cluster étendu, vous devez définir sa configuration de basculement et de restauration automatique, en tenant compte des points suivants :

  • Dépendances d'infrastructure. Vous devez clairement définir les services critiques, tels que AD DS, DNS et DHCP, qui doivent rester disponibles après un basculement vers le site secondaire.
  • Modèle de quorum. Il est important de choisir le modèle de quorum qui conserve les fonctionnalités du cluster après un basculement.
  • Publication de service et résolution de noms. Si vous avez des services qui sont publiés vers vos utilisateurs internes ou externes, tels que des messages électroniques et des pages Web, sachez que dans certains cas, le basculement vers un autre site nécessite des modifications de nom ou d’adresse IP. Si c’est le cas, vous devez disposer d’une procédure pour modifier les enregistrements DNS dans le DNS interne ou public. Pour réduire les temps d’arrêt, nous vous recommandons de réduire la valeur de durée de vie (TTL) des enregistrements DNS critiques.
  • Connectivité client. En cas de sinistre, un plan de basculement doit prendre en charge la connectivité des applications clientes aux charges de travail en cluster. Cela comprend à la fois les clients internes et externes.
  • La procédure de restauration automatique. Vous devez planifier et implémenter un processus de restauration automatique à effectuer une fois que le site principal est remis en ligne. La restauration automatique est tout aussi importante que le basculement, car si vous l’exécutez de manière incorrecte, vous risquez de perdre des données et d’interrompre le service.

Créer un cluster étendu

Vous pouvez créer un cluster étendu à l’aide de Windows Admin Center, du Gestionnaire du cluster de basculement ou de Windows PowerShell. Windows Admin Center simplifie l’implémentation des clusters étendus en vous guidant à travers le processus d’approvisionnement et en automatisant la plupart des tâches de configuration. Cela inclut la prise en charge des éléments suivants :

  • Clusters hyperconvergents (clustering de basculement, Hyper-V et espaces de stockage direct).
  • Clusters de stockage (clustering de basculement et espaces de stockage direct).

Note

La création d’un cluster étendu à l’aide du Gestionnaire du cluster de basculement ou de Windows PowerShell est plus complexe. Les deux méthodes requièrent l’exécution de chacune des étapes intermédiaires de l’implémentation. Dans les termes les plus simples, cela commence par la création d’un cluster de basculement traditionnel et non étiré constitué de tous les nœuds du site principal et du site secondaire. Après avoir créé le cluster et effectué la validation, dans chaque site, vous créez un ensemble distinct de volumes de stockage. Enfin, vous configurez le réplica de stockage pour répliquer les volumes de stockage entre les deux sites.