Configuration des ensembles de clusters Microsoft sur Dell PowerEdge (en anglais)

Les jeux de clusters, introduits dans Windows Server 2019 (WS19), améliorent la flexibilité et la résilience du SDDC (Software Defined Data Center). L’ensemble de clusters est une technologie qui permet aux administrateurs de combiner plusieurs clusters Windows 2019 en un seul ensemble de clusters.

Les clusters de basculement existants peuvent accueillir un maximum de 64 nœuds. La technologie Cluster Sets combine plusieurs clusters WS19 dans un seul domaine, chacun de ces clusters prenant en charge jusqu’à 64 nœuds WS19. Par rapport à un cluster de basculement, l’ensemble de clusters offre une résilience supérieure. Par exemple, un cluster de basculement à 4 nœuds peut survivre à une panne de 2 nœuds. Avec le même cluster à 4 nœuds, si nous le divisons en deux clusters à 2 nœuds et que nous formons un ensemble de clusters à partir de celui-ci, il peut survivre à une panne de cluster et à une défaillance de nœud du cluster restant. Ainsi, il peut survivre à 3 défaillances de nœud.

Pour obtenir une vue d’ensemble de la fonctionnalité Cluster-Sets dans Server 2019, reportez-vous aux sections «Introduction aux clusters-sets-in-windows-server-2019» et «Cluster sets». Les jeux de clusters gagnent en flexibilité grâce à l’utilisation d’une technologie sous-jacente appelée serveur de fichiers scale-out d’infrastructure. Cela facilite également la migration intercluster des machines virtuelles au sein de l’ensemble de clusters.

Configuration des exercices pratiques pour le déploiement d’un ensemble de clusters sur PowerEdge

Serveurs utilisés : Deux serveurs PowerEdge R730XD et deux serveurs PowerEdge R740XD

Création du premier cluster à l’aide des deux serveurs R730XD et nommé S2D13G54 (appelé Cluster membre 1).

Création du deuxième cluster à l’aide des deux serveurs R740XD et nommé S2D14G54 (appelé Cluster membre 2).

Création de deux volumes CSV sur chacun des clusters créés ci-dessus.

Création d’une machine virtuelle « vm1 » sur le cluster membre 1 et d’une machine virtuelle « vm2 » sur le cluster membre 2. Ensuite, j’ai combiné ces deux machines virtuelles pour créer un cluster de gestion (nommé mgClus54) pour l’ensemble de clusters. Aucun stockage partagé n’est requis lors de la création du cluster de gestion.

Installation du rôle File-Services sur chacun des nœuds du cluster membre 1, du cluster membre 2 et du cluster de gestion :

Install-WindowsFeature File-Services -IncludeAllSubFeature –IncludeManagementTools –Restart

Création d’un serveur de fichiers SOFS d’infrastructure sur le cluster membre 1, le cluster membre 2 et le cluster de gestion :

Add-ClusterScaleOutFileServerRole : nom <Nom de l’infrastructure SOFS> -Infrastructure

 

Création d’un ensemble de clusters nommé CLUSSET54 :

New-ClusterSet -Name CLUSSET54 -NamespaceRoot <Management Cluster SOFS Name> -CimSession <Session CIM vers cluster de gestion>

 

Ajoutez ensuite la S2D14G54 créée et le cluster S2D13G54 au cluster dans le ClusterSet :

Add-ClusterSetMember -ClusterName S2D14G54 -CimSession <Cim Session to ClusterSet> -InfraSOFSName <Name du SOFS créé sur S2D14G54 cluster>

 

Add-ClusterSetMember -ClusterName S2D13G54 -CimSession <Cim Session to ClusterSet> -InfraSOFSName <Name du SOFS créé sur S2D13G54 cluster>

 

 

 

Ensuite, je déploie deux machines virtuelles V213G et V214G sur les clusters membres 1 et 2, respectivement, et j’enregistre les machines virtuelles sur l’ensemble de clusters :

Get-ClusterSetMember -ClusterName <Nom> du cluster | Register-ClusterSetVM -VMName <VM Name>

 
Pour tester la live migration sur les clusters, j’ai essayé de migrer la machine virtuelle « V213G » vers le cluster membre 2. Avant d’effectuer la migration entre les clusters, nous devons prendre en compte les points suivants :

1. 1. VM settings, Processor Compatibility doit être activé.
   2. Configurer la délégation contrainte Kerberos (KCD) entre toutes les paires de nœuds intercluster
      1. Les conseils de délégation sous contrainte de l’équipe produit Microsoft Hyper-V seront utiles pour la configuration.
      2. Configurez le type d’authentification de migration dynamique des machines virtuelles intercluster vers Kerberos sur chaque nœud de l’ensemble de clusters.

foreach($h in $hosts){Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -computerName $h }

1. 1. 3. Ajoutez le cluster de gestion au groupe d’administrateurs locaux sur chaque nœud de l’ensemble de clusters.

foreach($h in $hosts){ Invoke-Command -ComputerName $h -ScriptBlock {Net localgroup administrators /add <management_cluster_name>$} }

 

Pour effectuer toute activité de maintenance d’un cluster dans l’ensemble de clusters, migrez toutes les machines virtuelles qui font partie du cluster vers d’autres clusters de l’ensemble de clusters, puis supprimez le cluster de l’ensemble de clusters :

 

Remove-ClusterSetMember -ClusterName <ClusterName> -CimSession <Session created for ClusterSet>

 

Après avoir effectué l’activité de maintenance, ajoutez à nouveau le cluster à l’ensemble de clusters.

 

En cas de défaillance inattendue d’un cluster membre, l’ensemble de clusters n’est pas assez intelligent pour gérer le basculement. Seul le déplacement manuel des ressources d’un cluster vers un autre cluster est pris en charge dans Windows Server 2019, même si unbasculement automatique de machine virtuelle continue de fonctionner dans le périmètre d’un cluster à un seul membre.

 

 

 

 

 

 

 

 

 

 

 

Les clusters de basculement existants peuvent accueillir un maximum de 64 nœuds. La technologie Cluster Sets combine plusieurs clusters WS19 dans un seul domaine, chacun de ces clusters prenant en charge jusqu’à 64 nœuds WS19. Par rapport à un cluster de basculement, l’ensemble de clusters offre une résilience supérieure. Par exemple, un cluster de basculement à 4 nœuds peut survivre à une panne de 2 nœuds. Avec le même cluster à 4 nœuds, si nous le divisons en deux clusters à 2 nœuds et que nous formons un ensemble de clusters à partir de celui-ci, il peut survivre à une panne de cluster et à une défaillance de nœud du cluster restant. Ainsi, il peut survivre à 3 défaillances de nœud.

Après avoir effectué l’activité de maintenance, ajoutez à nouveau le cluster à l’ensemble de clusters.

 

En cas de défaillance inattendue d’un cluster membre, l’ensemble de clusters n’est pas assez intelligent pour gérer le basculement. Seul le déplacement manuel des ressources d’un cluster vers un autre cluster est pris en charge dans Windows Server 2019 ; même si le basculement automatique des machines virtuelles continue de fonctionner dans le périmètre d’un cluster à un seul membre.