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 dell SDDC (Software Defined Data Center). Cluster Set è una tecnologia che consente agli amministratori di combinare più cluster Windows 2019 in un unico 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, ognuno dei quali supporta fino a 64 nodi WS19. Rispetto a un cluster di failover, il set di cluster offre una maggiore resilienza. Ad esempio, un cluster di failover a 4 nodi può sopravvivere a un guasto di 2 nodi. Con lo stesso cluster a 4 nodi, se ci dividiamo in due cluster a 2 nodi e formiamo un cluster composto da esso, questo può sopravvivere a un guasto del cluster più un guasto del nodo dal cluster rimanente. Quindi, può sopravvivere complessivamente a 3 guasti del nodo.

Per una panoramica della funzionalità Cluster-Sets in Server 2019, vedere "Introduction-to-cluster-sets-in-windows-server-2019" e "Clustersets". I set di cluster acquisiscono flessibilità mediante l'utilizzo di una tecnologia sottostante denominata Infrastructure Scale-Out File Server; ciò facilita anche la migrazione tra cluster delle macchine virtuali all'interno del set di cluster.

Configurazione del laboratorio per il deployment del set di cluster su PowerEdge

Server utilizzati: Due PowerEdge R730XD e due PowerEdge R740XD

Il primo cluster è stato creato utilizzando i due R730XD e denominato S2D13G54 (denominato Member Cluster 1).

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

Sono stati creati due volumi CSV su ciascuno dei cluster creati sopra.

Creazione di una VM 'vm1' nel cluster membro 1 e di una VM 'vm2' nel cluster membro 2. Quindi, ho combinato queste due macchine virtuali per creare un cluster di gestione (denominato mgClus54) per il set di cluster. Durantela creazione del cluster di gestione non è richiesto storage condiviso.

Installato il ruolo File-Services in ciascuno dei nodi del cluster membro 1, del cluster membro 2 e del cluster di gestione:

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

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

Add-ClusterScaleOutFileServerRole -Name <Nome dell'infrastruttura SOFS> -Infrastructure

 

È stato creato un set di cluster denominato CLUSSET54:

New-ClusterSet -Name CLUSSET54 -NamespaceRoot <Management Cluster SOFS Name> -CimSession <Dalla sessione CIM al cluster> di gestione

 

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

Add-ClusterSetMember -ClusterName S2D14G54 -CimSession <Cim Session Session to ClusterSet> -InfraSOFSName <Nome del SOFS creato nel cluster S2D14G54>

 

Add-ClusterSetMember -ClusterName S2D13G54 -CimSession <Cim Session Session to ClusterSet> -InfraSOFSName <Nome del SOFS creato nel cluster S2D13G54>

 

 

 

Quindi, implemento due macchine virtuali V213G e V214G rispettivamente sul cluster membro 1 e sul cluster membro 2 e registro le macchine virtuali sul set di cluster:

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

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

1. 1. È necessario abilitare VM settings, Processor Compatibility.
   2. Configurazione della delega vincolata Kerberos (KCD) tra tutte le coppie di nodi tra cluster
      1. Le indicazioni per la delega vincolata del team del prodotto Microsoft Hyper-V saranno utili per la configurazione.
      2. Configurare il tipo di autenticazione per la migrazione in tempo reale della macchina virtuale tra cluster su Kerberos su ciascun nodo del set di cluster.

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

1. 1. 3. Aggiungere il cluster di gestione al gruppo amministratori locali su ogni nodo del 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 nel set di cluster, eseguire la migrazione di tutte le VM che fanno parte del cluster ad altri cluster del set di cluster, quindi rimuovere il cluster dal set di cluster:

 

Remove-ClusterSetMember -ClusterName <ClusterName> -CimSession <Sessione creata per ClusterSet>

 

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

 

In caso di guasto 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 nell'ambito di un cluster a membro singolo.

 

 

 

 

 

 

 

 

 

 

 

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

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

 

In caso di guasto 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 nell'ambito di un singolo cluster membro.