Configurazione dei set di cluster Microsoft per Dell PowerEdge

I set di cluster, introdotti in Windows Server 2019 (WS19), migliorano la flessibilità e la resilienza SDDC (Software-Defined Data Center). Set di cluster è una tecnologia che consente agli amministratori di combinare più cluster Windows 2019 in un unico ombrello di cluster.

I cluster di failover esistenti possono ospitare un massimo di 64 nodi. La tecnologia Cluster Sets combina più cluster WS19 in un unico dominio, con ognuno di questi cluster che supporta fino a 64 nodi WS19. Rispetto a un failover-cluster, il set di cluster offre una maggiore resilienza. Ad esempio, un cluster di failover a 4 nodi può sopravvivere a un errore a 2 nodi. Con lo stesso cluster a 4 nodi se ci dividiamo in due cluster a 2 nodi e formiamo un set di cluster, può sopravvivere a un errore del cluster più un errore del nodo dal cluster rimanente. Quindi, può sopravvivere complessivamente a 3 guasti dei nodi.

Per una panoramica della funzionalità Cluster-Sets in Server 2019, consultare "Introduction-to-cluster-sets-in-windows-server-2019" e "Cluster sets". I set di cluster acquisendo la propria flessibilità grazie all'utilizzo di una tecnologia sottostante denominata Infrastructure Scale-Out File Server; ciò semplifica inoltre la migrazione tra cluster delle VM all'interno del set di cluster.

Lab Setup for Deploying Cluster Set on PowerEdge

Server utilizzati: Due PowerEdge R730XD e due PowerEdge R740XD

Abbiamo creato il primo cluster utilizzando i due R730XD e denominati S2D13G54 (chiamato Member Cluster 1).

Abbiamo creato il secondo cluster utilizzando i due R740XD e denominato S2D14G54 (chiamato Member Cluster 2).

Creazione di due volumi CSV in ciascuno dei cluster creati in precedenza.

È stata creata una VM 'vm1' nel cluster 1 membro e una VM 'vm2' nel cluster membro 2. Quindi, ho combinato queste due VM per creare un cluster di gestione (denominato mgClus54) per il set di cluster. No lo storage condiviso è richiesto durante la creazione del cluster di gestione.

Installato il ruolo File-Services in ciascun nodo nel cluster membro 1, nel cluster membro 2 e nel cluster di gestione:

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

Creazione di un file server SOFS dell'infrastruttura nel cluster 1 membro, nel cluster membro 2 e nel cluster di gestione:

Add-ClusterScaleOutFileServerRole -Name <of the Infrastructure SOFS> -Infrastructure

 

Creazione di un set di cluster denominato CLUSSET54:

New-ClusterSet -Name CLUSSET54 -NamespaceRoot <Management Cluster SOFS Name> -CimSession <CIM session to Management Cluster>

 

Aggiungere quindi il S2D14G54 creato e S2D13G54 Cluster al cluster al ClusterSet:

Add-ClusterSetMember -ClusterName S2D14G54 -CimSession <Cim Session to ClusterSet> -InfraSOFSName <Name of SOFS created on S2D14G54 cluster>

 

Add-ClusterSetMember -ClusterName S2D13G54 -CimSession <Cim Session to ClusterSet> -InfraSOFSName <Name of SOFS created on S2D13G54 cluster>

 

 

 

Quindi , implemento due VM V213G e V214G rispettivamente nel cluster 1 membro e nel cluster membro 2 e registro le VM nel set di cluster:

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

 
Per testare la migrazione in tempo reale tra i cluster, ho tentato di eseguire la migrazione della VM "V213G" al cluster membro 2. Prima di eseguire la migrazione tra i cluster, è necessario considerare i punti seguenti:

1. 1. Impostazioni delle VM. La compatibilità del processore deve essere abilitata.
   2. Configurare la delega vincolata Kerberos (KCD) tra tutte le coppie di nodi tra cluster
      1. Le linee guida per le deleghe limitate fornite dal team di prodotti Microsoft Hyper-V saranno utili per la configurazione.
      2. Configurare il tipo di autenticazione di Live Migration della VM tra cluster su Kerberos su ciascun nodo nel set di cluster.

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

1. 1. 3. Aggiungere il cluster di gestione al gruppo di amministratori locali in ogni nodo nel set di cluster.

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

 

Per eseguire qualsiasi attività di manutenzione di un cluster in Cluster Set, eseguire la migrazione di tutte le VM che fanno parte del cluster ad altri cluster nel set di cluster, quindi rimuovere il cluster dal set di cluster:

 

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

 

Dopo aver eseguito l'attività di manutenzione, aggiungere nuovamente il cluster al set di cluster.

 

In caso di errore imprevisto di un cluster membro, il set di cluster non è sufficientemente intelligente per gestire il failover. In Windows Server 2019 è supportato solo lo spostamento manuale delle risorse da un cluster a un altro; anche se unfailover automatico delle VM continua a funzionare all'interno di un singolo ambito del cluster membro.

 

 

 

 

 

 

 

 

 

 

 

I cluster di failover esistenti possono ospitare un massimo di 64 nodi. La tecnologia Cluster Sets combina più cluster WS19 in un unico dominio, con ognuno di questi cluster che supporta fino a 64 nodi WS19. Rispetto a un failover-cluster, il set di cluster offre una maggiore resilienza. Ad esempio, un cluster di failover a 4 nodi può sopravvivere a un errore a 2 nodi. Con lo stesso cluster a 4 nodi se ci dividiamo in due cluster a 2 nodi e formiamo un set di cluster, può sopravvivere a un errore del cluster più un errore del nodo dal cluster rimanente. Quindi, può sopravvivere complessivamente a 3 guasti dei nodi.

Dopo aver eseguito l'attività di manutenzione, aggiungere nuovamente il cluster al set di cluster.

 

In caso di errore imprevisto di un cluster membro, il set di cluster non è sufficientemente intelligente per gestire il failover. In Windows Server 2019 è supportato solo lo spostamento manuale delle risorse da un cluster a un altro. anche se il failover automatico delle VM continua a funzionare all'interno di un singolo ambito del cluster membro.