Déployer un ensemble de clusters

2025-05-05
S’applique à: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Azure Local 2311.2 and later

S’applique à : Windows Server 2019

Cet article explique comment déployer un jeu de clusters pour des clusters de basculement Windows Server en utilisant PowerShell. Un jeu de clusters est un groupe de plusieurs clusters de basculement qui sont regroupés ensemble. À l’aide d’un ensemble de clusters, vous pouvez augmenter le nombre de nœuds serveur dans un cloud SDDC (Software Defined Data Center) unique par ordre de grandeur.

Les jeux de clusters ont été testés et pris en charge jusqu’à 64 nœuds de cluster totaux. Cependant, les jeux de clusters peuvent être mis à l’échelle avec des limites plus grandes qui ne font pas l’objet d’un codage en dur.

Avantages

Les ensembles de clusters offrent les avantages suivants :

Augmente considérablement l'échelle du cloud SDDC prise en charge pour l'exécution de machines virtuelles hautement disponibles, en combinant plusieurs petits clusters en une unique grande structure, tout en maintenant la limite d'erreur logicielle à un seul cluster. Vous pouvez facilement migrer des machines virtuelles sur l’ensemble de clusters.
Résilience accrue. La présence de quatre clusters à 4 nœuds dans un ensemble de clusters vous offre une meilleure résilience qu’un seul cluster à 16 nœuds dans lequel plusieurs nœuds de calcul peuvent descendre en panne et la production reste intacte.
Gestion du cycle de vie du cluster de basculement, y compris l’intégration et la mise hors service des clusters, sans impact sur la disponibilité des machines virtuelles du locataire.
Flexibilité des machines virtuelles entre les clusters individuels et présentation d’un espace de noms de stockage unifié.
Modifiez facilement le ratio de charge de travail de calcul à stockage dans votre environnement hyperconvergé.
Bénéficiez des domaines d’erreur et des groupes de disponibilité de type Azure à travers différents clusters, tant lors du placement initial des machines virtuelles que lors de leur migration ultérieure.
Peut utiliser même si le matériel de calcul et de stockage entre les nœuds de cluster n’est pas identique.
Migration dynamique de machines virtuelles entre clusters.
Groupes à haute disponibilité et domaines d’erreur de type Azure sur plusieurs clusters.
Déplacement de machines virtuelles SQL Server entre des clusters.

Conditions requises et limitations :

Il existe quelques exigences et limitations pour l’utilisation des ensembles de clusters :

Tous les clusters membres d’un ensemble de clusters doivent se trouver dans la même forêt Active Directory (AD).
Les serveurs membres du jeu doivent exécuter la même version du système d’exploitation. Les machines virtuelles ne peuvent pas être migrées en direct entre différents systèmes d’exploitation. Vous pouvez avoir un ensemble de clusters qui se compose de n’importe lequel, mais pas de multiples, des options suivantes :
- Cluster de basculement Windows Server 2019 et Cluster de basculement Windows Server 2019
- Cluster de basculement Windows Server 2019 et espaces de stockage direct Windows Server 2019
- Espaces de stockage direct Windows Server 2019 et Espaces de stockage direct Windows Server 2019
Le matériel processeur identique est nécessaire pour que tous les serveurs membres pour la migration dynamique entre les clusters membres se produisent ; sinon, vous devez sélectionner Compatibilité du processeur dans les paramètres des machines virtuelles.
Les machines virtuelles du jeu de clusters doivent être migrées manuellement en direct sur les clusters ; elles ne peuvent pas basculer automatiquement.
La réplication de stockage doit être utilisée entre les clusters membre pour assurer la résilience du stockage en cas de défaillances de cluster. Quand vous utilisez Réplica de stockage, gardez à l’esprit que les chemins d’accès UNC du stockage de l’espace de noms ne changent pas automatiquement lors du basculement de Réplica de stockage vers le cluster cible du réplica.
Les espaces de stockage direct ne fonctionnent pas entre les clusters membres d’un ensemble de clusters. Au lieu de cela, les espaces de stockage direct s’appliquent à un seul cluster, chaque cluster ayant son propre pool de stockage.

Architecture

Le diagramme suivant illustre un ensemble de clusters à un niveau élevé :

Voici un résumé de chacun des éléments affichés :

Cluster de gestion

Le cluster de gestion héberge le plan de gestion hautement disponible et le Serveur de fichiers avec montée en puissance parallèle (SOFS) de référence de l’espace de noms pour le jeu de clusters. Un cluster de gestion est dissocié logiquement des clusters membres individuels qui exécutent des charges de travail de machine virtuelle. Cela rend le plan de gestion de l’ensemble de clusters résilient aux défaillances localisées au niveau du cluster, telles que la perte de puissance d’un cluster membre.

Référence d’espace de noms du jeu de clusters SOFS

Un espace de noms pour l’ensemble de clusters est fourni avec un rôle serveur SOFS s’exécutant sur le cluster de gestion. C'est similaire à un espace de noms de système de fichiers distribué (DFSN). Contrairement à DFSN toutefois, les métadonnées de référence de l’espace de noms de l’ensemble de clusters sont renseignées automatiquement sur tous les nœuds de cluster sans intervention. Il n’y a donc presque aucune surcharge de performances dans le chemin d’accès au stockage. Ce mécanisme de référence léger ne fait pas partie du chemin d’accès entrée/sortie.

Chaque partage de référence SMB (Server Message Block) sur la référence SOFS de l’espace de noms du jeu de clusters est de type SimpleReferral. Ce renvoi permet aux clients SMB d’accéder au partage SMB ciblé hébergé sur le cluster membre SOFS. Les références sont mises en cache perpétuellement sur chacun des nœuds clients et l’espace de noms du groupe de clusters met à jour dynamiquement les références en fonction des besoins. Les informations de référence sont mises en cache de manière permanente dans chaque nœud d'ensemble de clusters, même pendant les redémarrages.

Jeu de clusters maître

La communication entre les clusters membres est faiblement couplée et coordonnée par la ressource master (CS-Master) du groupe de clusters. Comme les autres ressources de jeux de clusters, CS-Master est hautement disponible et résilient face aux défaillances des clusters membres individuelles ou aux défaillances des nœuds de clusters de gestion. Par le biais d’un fournisseur WMI de jeu de clusters, CS-Master fournit le point de terminaison de gestion pour toutes les actions de gestion des jeux de clusters.

Groupe de membres

Un cluster membre exécute des charges de travail de machine virtuelle et d’espaces de stockage direct. Plusieurs clusters membres participent à un déploiement d’ensemble de clusters, formant l’infrastructure cloud SDDC plus grande. Les clusters membres diffèrent du cluster de gestion en deux aspects clés : les clusters membres participent à des constructions de domaine d’erreur et de groupe à haute disponibilité, et les clusters membres sont dimensionnés pour héberger des charges de travail de machine virtuelle et d’espaces de stockage direct. Les machines virtuelles qui se déplacent entre les clusters membres ne sont pas hébergées sur le cluster de gestion pour cette raison.

Worker du jeu de clusters

Le jeu de clusters maître interagit avec une ressource de cluster sur les clusters membres appelée Worker de jeu de clusters (CS-Worker). CS-Worker répond aux demandes du CS-Master, y compris le placement des machines virtuelles et l’inventaire des ressources. Il existe une instance CS-Worker par cluster membre.

Domaine d'erreur

Un domaine d’erreur est un groupe de matériel et de logiciels qui peuvent échouer ensemble. Bien que vous puissiez désigner un ou plusieurs clusters ensemble comme domaine d’erreur, chaque nœud peut participer à un domaine d’erreur dans un groupe à haute disponibilité. Les limites de domaine d’erreur sont basées sur la topologie du centre de données, l’architecture réseau et d’autres considérations.

Ensemble de disponibilité

Un groupe à haute disponibilité est utilisé pour configurer la redondance souhaitée des charges de travail en cluster entre les domaines d’erreur en regroupant et en déployant des charges de travail. Pour une application à deux niveaux, vous devez configurer au moins deux machines virtuelles dans un groupe à haute disponibilité pour chaque niveau, ce qui garantit que lorsqu’un domaine d’erreur dans un groupe à haute disponibilité tombe en panne, votre application aura au moins une machine virtuelle de chaque niveau hébergée sur un domaine d’erreur différent.

Créer un ensemble de clusters

Utilisez PowerShell dans l’exemple de flux de travail suivant pour créer un ensemble de clusters à l’aide de deux clusters. Le nom du cluster défini ici est CSMASTER.

Nom du cluster	Nom SOFS de l’infrastructure
SET-CLUSTER	SOFS-CLUSTERSET
CLUSTER1	SOFS-CLUSTER1
CLUSTER2	SOFS-CLUSTER2

Utilisez un ordinateur client de gestion exécutant Windows Server 2022 ou Windows Server 2019.
Installez les outils de cluster de basculement sur le serveur de cluster d’administration.
Créez deux membres de cluster et avec au moins deux volumes partagés de cluster (CSV) dans chaque cluster.
Créez un cluster de gestion (physique ou invité) qui chevauche les clusters membres. Cela garantit que le plan de gestion de l’ensemble de clusters continue d’être disponible malgré les défaillances possibles du cluster membre.
Pour créer l’ensemble de clusters :
```
New-ClusterSet -Name CSMASTER -NamespaceRoot SOFS-CLUSTERSET -CimSession SET-CLUSTER
```
Remarque

Si vous utilisez une adresse IP statique, vous devez inclure -StaticAddress x.x.x sur la commande New-ClusterSet .

Pour ajouter des membres de cluster à l’ensemble de clusters :

Add-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER1
Add-ClusterSetMember -ClusterName CLUSTER2 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER2

Pour énumérer tous les clusters membres dans l’ensemble de clusters :
```
Get-ClusterSetMember -CimSession CSMASTER
```
Pour énumérer tous les clusters membres dans l’ensemble de clusters, y compris les nœuds du cluster de gestion :
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterNode
```
Pour répertorier tous les nœuds serveur de tous les clusters membres :
```
Get-ClusterSetNode -CimSession CSMASTER
```
Pour répertorier tous les groupes de ressources dans l’ensemble de clusters :
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterGroup
```
Pour vérifier que l’ensemble de clusters contient un partage SMB (ScopeName étant le nom du serveur de fichiers d’infrastructure) sur l’infrastructure SOFS pour chaque volume CSV membre du cluster :
```
Get-SmbShare -CimSession CSMASTER
```
Passez en revue les fichiers journaux du jeu de clusters pour le jeu de clusters, le cluster de gestion et chaque membre du cluster :
```
Get-ClusterSetLog -ClusterSetCimSession CSMASTER -IncludeClusterLog -IncludeManagementClusterLog -DestinationFolderPath <path>
```
Configurez Kerberos avec une délégation contrainte entre tous les membres du jeu de clusters.
Configurez le type d’authentification de migration dynamique de machine virtuelle entre clusters sur Kerberos sur chaque nœud du groupe de clusters :
```
foreach($h in $hosts){ Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -ComputerName $h }
```
Ajoutez le cluster de gestion au groupe administrateurs local sur chaque nœud de serveur membre du cluster dans l’ensemble de clusters :
```
foreach($h in $hosts){ Invoke-Command -ComputerName $h -ScriptBlock {Net localgroup administrators /add <management_cluster_name>$} }
```

Créer des machines virtuelles du groupe de clusters

Après avoir créé le jeu de clusters, l’étape suivante consiste à créer des machines virtuelles. Vous devez effectuer les vérifications suivantes au préalable :

Vérifier la mémoire disponible sur chaque nœud de serveur de cluster
Vérifier l’espace disque disponible sur chaque nœud de serveur de cluster
Vérifier les exigences de stockage de machines virtuelles spécifiques en termes de vitesse et de performances

La Get-ClusterSetOptimalNodeForVM commande identifie le cluster et le nœud optimaux dans l’ensemble de clusters, puis déploie la machine virtuelle sur celle-ci. Dans l’exemple suivant, une nouvelle machine virtuelle est créée avec :

4 Go disponibles
Un processeur virtuel
10 % du processeur minimum disponible

# Identify the optimal node to create a new virtual machine
$memoryinMB=4096
$vpcount = 1
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

# Deploy the virtual machine on the optimal node
Invoke-Command -ComputerName $targetnode.name -scriptblock { param([String]$storagepath); New-VM CSVM1 -MemoryStartupBytes 3072MB -path $storagepath -NewVHDPath CSVM.vhdx -NewVHDSizeBytes 4194304 } -ArgumentList @("\\SOFS-CLUSTER1\VOLUME1") -Credential $cred | Out-Null

Start-VM CSVM1 -ComputerName $targetnode.name | Out-Null
Get-VM CSVM1 -ComputerName $targetnode.name | fl State, ComputerName

Une fois terminé, vous indiquez le nœud de cluster sur lequel la machine virtuelle a été déployée. Pour l’exemple ci-dessus, il s’affiche comme suit :

State         : Running
ComputerName  : 1-S2D2

S’il n’y a pas suffisamment de mémoire, de capacité processeur ou d’espace disque disponible pour ajouter la machine virtuelle, vous recevez l’erreur suivante :

Get-ClusterSetOptimalNodeForVM : A cluster node isn't available for this operation.

Une fois la machine virtuelle créée, elle s’affiche dans Hyper-V manager sur le nœud spécifique spécifié. Pour l’ajouter en tant que machine virtuelle de jeu de clusters et l’ajouter au cluster, utilisez cette commande :

Register-ClusterSetVM -CimSession CSMASTER -MemberName $targetnode.Member -VMName CSVM1

Quand c’est terminé, la sortie est :

Id  VMName  State  MemberName  PSComputerName
--  ------  -----  ----------  --------------
 1  CSVM1     On   CLUSTER1    CSMASTER

Si vous avez créé un cluster à l’aide de machines virtuelles existantes, les machines virtuelles doivent être inscrites auprès de l’ensemble de clusters. Pour inscrire toutes les machines virtuelles à la fois, utilisez :

Get-ClusterSetMember -Name CLUSTER3 -CimSession CSMASTER | Register-ClusterSetVM -RegisterAll -CimSession CSMASTER

Ensuite, ajoutez le chemin d’accès de la machine virtuelle à l’espace de noms de l’ensemble de clusters.

Par exemple, supposons qu’un cluster existant soit ajouté à l’ensemble de clusters avec des machines virtuelles préconfigurées qui résident sur le volume partagé de cluster local (CSV). Le chemin d’accès du VHDX serait similaire à C:\ClusterStorage\Volume1\MYVM\Virtual Hard Disks\MYVM.vhdx1.

Une migration de stockage est nécessaire, car les chemins CSV sont créés localement sur un cluster membre unique et ne sont donc pas accessibles à la machine virtuelle une fois qu’elles sont migrées en direct sur des clusters membres.

Dans cet exemple, CLUSTER3 est ajouté au jeu de clusters en utilisant Add-ClusterSetMember avec le serveur de fichiers avec montée en puissance parallèle SOFS-CLUSTER3. Pour déplacer la configuration et le stockage de la machine virtuelle, la commande est la suivante :

Move-VMStorage -DestinationStoragePath \\SOFS-CLUSTER3\Volume1 -Name MyVM

Une fois terminé, vous pouvez recevoir un avertissement :

WARNING: There were issues updating the virtual machine configuration that may prevent the virtual machine from running. For more information view the report file below.
WARNING: Report file location: C:\Windows\Cluster\Reports\Update-ClusterVirtualMachineConfiguration '' on date at time.htm.

Cet avertissement peut être ignoré, car aucune modification physique n’a été apportée à la configuration de stockage des rôles de machine virtuelle. L’emplacement physique réel ne change pas ; seuls les chemins de configuration le font.

Pour plus d’informations sur Move-VMStorage, consultez Move-VMStorage.

La migration dynamique d’une machine virtuelle au sein d’un groupe de clusters implique les éléments suivants :

Set-VMHost -UseAnyNetworkForMigration $true

Ensuite, pour déplacer une machine virtuelle de groupe de clusters de CLUSTER1 vers NODE2-CL3 sur CLUSTER3 par exemple, la commande serait :

Move-ClusterSetVM -CimSession CSMASTER -VMName CSVM1 -Node NODE2-CL3

Cette commande ne déplace pas les fichiers de stockage ou de configuration de la machine virtuelle et n’est pas nécessaire, car le chemin d’accès à la machine virtuelle reste comme \\SOFS-CLUSTER1\VOLUME1. Une fois qu'une machine virtuelle a été enregistrée pour utiliser le chemin de partage du serveur de fichiers de l'infrastructure, les lecteurs de disque et la machine virtuelle n'ont pas besoin d'être sur le même nœud.

Créer le serveur de fichiers avec montée en puissance parallèle de l’infrastructure

Il existe un rôle de cluster SOFS d’infrastructure sur un cluster. Le rôle SOFS d’infrastructure est créé en spécifiant le paramètre de commutateur -Infrastructure pour la cmdlet Add-ClusterScaleOutFileServerRole. Par exemple:

Add-ClusterScaleoutFileServerRole -Name "my_infra_sofs_name" -Infrastructure

Chaque volume CSV créé déclenche automatiquement la création d’un partage SMB avec un nom généré automatiquement en fonction du nom du volume CSV. Vous ne pouvez pas créer ou modifier directement des partages SMB sous un rôle SOFS, autre que l’utilisation des opérations de création et de modification du volume CSV.

Dans les configurations hyperconvergées, une Infrastructure SOFS permet à un client SMB (hôteHyper-V) de communiquer avec le serveur SMB SOFS d’infrastructure en assurant une disponibilité continue (CA). Cette autorité de certification hyperconvergée pour le bouclage SMB est réalisée par des machines virtuelles qui accèdent aux fichiers de leur disque virtuel (VHDX) où l’identité de la machine virtuelle propriétaire est transférée entre le client et le serveur. Ce transfert d’identité permet d’utiliser des listes de contrôle d’accès pour les fichiers VHDx comme dans les configurations de cluster hyperconvergées standard comme précédemment.

Une fois qu’un ensemble de clusters est créé, l’espace de noms du groupe de clusters s’appuie sur une instance SOFS d’infrastructure sur chacun des clusters membres, ainsi qu’une instance SOFS d’infrastructure dans le cluster de gestion.

Au moment où un cluster membre est ajouté à un ensemble de clusters, vous pouvez spécifier le nom d’un SOFS d’infrastructure sur ce cluster s’il en existe déjà un. Si le SOFS d’infrastructure n’existe pas, un nouveau rôle SOFS d’infrastructure est créé sur le nouveau cluster membre. Si un rôle SOFS d’infrastructure existe déjà sur le cluster membre, l’opération Add le renomme implicitement en nom spécifié si nécessaire. Les serveurs SMB existants ou les rôles SOFS non d’infrastructure sur les clusters membres ne sont pas utilisés par l’ensemble de clusters.

Quand le jeu de clusters est créé, vous avez la possibilité d’utiliser un objet ordinateur AD existant comme racine d’espace de noms sur le cluster de gestion. La création d’un ensemble de clusters crée le rôle de cluster SOFS d’infrastructure sur le cluster de gestion ou reconfigure le rôle SOFS d’infrastructure existant. Le SOFS d’infrastructure sur le cluster de gestion est utilisé comme SOFS de référence d’espace de noms du jeu de clusters.

Créer des domaines de panne et des ensembles de disponibilité

Les domaines d’erreur et les groupes à haute disponibilité de type Azure peuvent être configurés dans un ensemble de clusters. Cela est bénéfique pour les placements et migrations de machines virtuelles initiales entre les clusters.

L’exemple ci-dessous comporte quatre clusters dans un ensemble de clusters. Dans l’ensemble, un domaine d’erreur est créé avec deux des clusters et un deuxième domaine d’erreur est créé avec les deux autres clusters. Ces deux domaines de panne forment l'ensemble de disponibilité.

Dans l’exemple ci-dessous, CLUSTER1 et CLUSTER2 se trouvent dans le domaine d’erreur FD1 et CLUSTER3 et CLUSTER4 se trouvent dans le domaine d’erreur FD2. Le groupe à haute disponibilité est CSMASTER-AS.

Pour créer les domaines d’erreur, les commandes sont les suivantes :

New-ClusterSetFaultDomain -Name FD1 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER1,CLUSTER2 -Description "First fault domain"

New-ClusterSetFaultDomain -Name FD2 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER3,CLUSTER4 -Description "Second fault domain"

Pour vous assurer qu'elles ont été créées avec succès, vous pouvez exécuter Get-ClusterSetFaultDomain pour afficher sa sortie pour FD1 :

PS C:\> Get-ClusterSetFaultDomain -CimSession CSMASTER -FdName FD1 | fl *

PSShowComputerName    : True
FaultDomainType       : Logical
ClusterName           : {CLUSTER1, CLUSTER2}
Description           : First fault domain
FDName                : FD1
Id                    : 1
PSComputerName        : CSMASTER

Maintenant que les domaines de défaillance ont été créés, l'ensemble de disponibilité est créé :

New-ClusterSetAvailabilitySet -Name CSMASTER-AS -FdType Logical -CimSession CSMASTER -ParticipantName FD1,FD2

Pour valider qu’elle a été créée, utilisez :

Get-ClusterSetAvailabilitySet -AvailabilitySetName CSMASTER-AS -CimSession CSMASTER

Lors de la création de machines virtuelles, utilisez le -AvailabilitySet paramètre pour déterminer le nœud optimal pour le placement. Voici un exemple :

# Identify the optimal node to create a new VM
$memoryinMB=4096
$vpcount = 1
$av = Get-ClusterSetAvailabilitySet -Name CSMASTER-AS -CimSession CSMASTER
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10 -AvailabilitySet $av
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

Retirer un cluster d’un ensemble

Il existe des moments où un cluster doit être supprimé d’un ensemble de clusters. En guise de meilleure pratique, toutes les machines virtuelles de l’ensemble de clusters doivent être déplacées au préalable vers l’extérieur du cluster. Cette opération peut être effectuée à l’aide des commandes Move-ClusterSetVM et Move-VMStorage.

Si les machines virtuelles ne sont pas déplacées du cluster en premier, toutes les machines virtuelles restantes hébergées sur le cluster en cours de suppression deviennent des machines virtuelles hautement disponibles liées à ce cluster, en supposant qu’elles ont accès à leur stockage. Les ensembles de clusters mettent également à jour automatiquement leur inventaire en ne suivant plus l’intégrité d’un cluster supprimé et les machines virtuelles en cours d’exécution, et en supprimant l’espace de noms et toutes les références aux partages hébergés sur le cluster supprimé.

Par exemple, la commande permettant de supprimer le cluster CLUSTER1 d’un ensemble de clusters est la suivante :

Remove-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER

Sauvegarde de l’état du système

La sauvegarde de l’état du système sauvegarde l’état et les métadonnées du cluster. À l’aide de la sauvegarde Windows Server, vous pouvez restaurer uniquement la base de données de cluster d’un nœud si nécessaire ou effectuer une restauration faisant autorité pour restaurer l’intégralité de la base de données de cluster sur tous les nœuds. Pour les ensembles de clusters, nous vous recommandons d’effectuer d’abord une restauration faisant autorité pour les clusters membres, puis pour le cluster de gestion. Pour plus d’informations sur la sauvegarde de l’état du système, consultez Sauvegarder l’état du système et matériel nu.

Étapes suivantes

En savoir plus sur le Réplicat de stockage.