Distribuire un insieme di cluster

2025-04-30
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Azure Local 2311.2 and later

Si applica a: Windows Server 2019

Questo articolo fornisce informazioni su come distribuire un set di cluster per i cluster di failover di Windows Server tramite PowerShell. Un set di cluster è un gruppo di più cluster di failover raggruppati tra loro. Usando un set di cluster, è possibile aumentare il numero di nodi del server in un singolo cloud SDDC (Software Defined Data Center) per ordine di grandezza.

I set di cluster sono stati testati e supportati fino a un totale di 64 nodi. Tuttavia, i set di cluster possono essere ridimensionati a limiti molto più grandi e non sono codificati rigidamente per un limite.

Vantaggi

I set di cluster offrono i vantaggi seguenti:

Aumenta significativamente la scalabilità cloud SDDC supportata per l'esecuzione di macchine virtuali a disponibilità elevata combinando più cluster più piccoli in un'unica infrastruttura di grandi dimensioni, mantenendo al tempo stesso il limite di errore software a un singolo cluster. È possibile eseguire facilmente la migrazione delle macchine virtuali nel set di cluster.
Maggiore resilienza. La presenza di quattro cluster a 4 nodi in un set di cluster offre una migliore resilienza rispetto a un singolo cluster a 16 nodi in cui più nodi di calcolo possono scendere e la produzione rimane intatta.
Gestione del ciclo di vita del cluster di failover, incluso l'onboarding e il ritiro dei cluster, senza influire sulla disponibilità delle macchine virtuali tenant.
Flessibilità delle macchine virtuali tra singoli cluster e uno spazio dei nomi di archiviazione unificato.
Modificare facilmente il rapporto tra carico di lavoro di calcolo e archiviazione nell'ambiente iperconvergente.
Trarre vantaggio da fault domains e dai set di disponibilità simili ad Azure nei singoli cluster durante il posizionamento iniziale della VM e la successiva migrazione.
Può essere usato anche se l'hardware di calcolo e archiviazione tra i nodi del cluster non è identico.
Migrazione in tempo reale delle macchine virtuali tra cluster.
Set di disponibilità e domini di guasto simili a quelli di Azure in più cluster.
Spostamento di macchine virtuali di SQL Server tra cluster.

Requisiti e limitazioni

Esistono alcuni requisiti e limitazioni per l'uso dei set di cluster:

Tutti i cluster membri in un set di cluster devono trovarsi nella stessa foresta di Active Directory (AD).
I server membri nel set devono eseguire la stessa versione del sistema operativo. Non è possibile eseguire la migrazione in tempo reale delle macchine virtuali tra sistemi operativi diversi. È possibile avere un set di cluster costituito da uno, ma non da più, delle opzioni seguenti:
- Cluster di failover di Windows Server 2019 e cluster di failover di Windows Server 2019
- Cluster di failover di Windows Server 2019 e Spazi di archiviazione diretta di Windows Server 2019
- Spazi di archiviazione diretta di Windows Server 2019 e Spazi di archiviazione diretta di Windows Server 2019
L'hardware del processore identico è necessario per tutti i server membri per la migrazione in tempo reale tra cluster membri; in caso contrario, è necessario selezionare Compatibilità processore CPU nelle impostazioni delle macchine virtuali.
Le macchine virtuali del set di cluster devono essere migrate manualmente tra cluster. Non possono eseguire automaticamente il failover.
Replica di archiviazione deve essere usata tra cluster membri per realizzare la resilienza dell'archiviazione in caso di errori del cluster. Quando si usa Replica di archiviazione, tenere presente che i percorsi UNC di archiviazione dello spazio dei nomi non cambieranno automaticamente in caso di failover al cluster di destinazione della replica.
"Storage Spaces Direct non funziona tra i cluster membri in un set di cluster." Piuttosto, Spazi di archiviazione diretta si applica a un singolo cluster, ciascuno con il proprio pool di archiviazione.

Architettura

Il diagramma seguente illustra un cluster impostato ad alto livello.

Di seguito è riportato un riepilogo di ognuno degli elementi illustrati:

Gestione dei cluster

Il cluster di gestione ospita il piano di gestione ad alta disponibilità e il File Server di Scalabilità in Riferimento (SOFS) per lo spazio dei nomi del set di cluster. Un cluster di gestione viene disaccoppiato logicamente da singoli cluster membri che eseguono carichi di lavoro di macchine virtuali. In questo modo il piano di gestione del set di cluster è resiliente a qualsiasi errore localizzato a livello di cluster, ad esempio la perdita di potenza di un cluster membro.

Sofs di riferimento dello spazio dei nomi del set di cluster

Uno spazio dei nomi per il cluster set è fornito con un ruolo del server SOFS in esecuzione nel cluster di gestione. È simile a uno spazio dei nomi DFSN (Distributed File System). A differenza di DFSN, tuttavia, i metadati di riferimento dello spazio dei nomi impostati dal cluster vengono popolati automaticamente in tutti i nodi del cluster senza alcun intervento, quindi non vi è quasi alcun sovraccarico delle prestazioni nel percorso di accesso alle risorse di archiviazione. Questo meccanismo di riferimento leggero non partecipa al percorso di I/O.

Ogni condivisione di riferimento SMB (Server Message Block) nel riferimento del namespace SOFS del cluster è di tipo SimpleReferral. Questa segnalazione consente ai client SMB di accedere alla condivisione SMB di destinazione ospitata nel cluster membro SOFS. I riferimenti vengono memorizzati nella cache permanentemente su ciascuno dei nodi client e lo spazio dei nomi del set di cluster aggiorna automaticamente i riferimenti in modo dinamico secondo le necessità. Le informazioni di riferimento vengono memorizzate nella cache permanente in ogni nodo del set di cluster, anche durante i riavvii.

Master del set di cluster

La comunicazione tra cluster membro è associata in modo libero e coordinata dalla risorsa master del set di cluster (CS-Master). Analogamente ad altre risorse del set di cluster, CS-Master è a disponibilità elevata e resiliente agli errori dei singoli cluster membri o agli errori dei nodi del cluster di gestione. Tramite un provider WMI per set di cluster, CS-Master fornisce l'endpoint di gestione per tutte le azioni di gestione dei cluster.

Membro del cluster

Un cluster membro esegue carichi di lavoro di VM e Storage Spaces Direct. Più cluster membri partecipano alla distribuzione di un set di cluster, formando l'infrastruttura cloud SDDC più grande. I cluster membri differiscono dal cluster di gestione in due aspetti chiave: sono coinvolti nei costrutti di dominio degli errori e dei set di disponibilità e sono dimensionati per ospitare carichi di lavoro di macchine virtuali e tecnologie come Storage Spaces Direct. Le macchine virtuali che si spostano tra cluster membri non sono ospitate nel cluster di gestione per questo motivo.

Lavoratore del set di cluster

Il CS-Master interagisce con una risorsa cluster nei cluster membri denominati ruolo di lavoro del set di cluster (CS-Worker). CS-Worker risponde alle richieste da CS-Master, tra cui il posizionamento delle macchine virtuali e l'inventario delle risorse. Esiste un'istanza CS-Worker per ogni cluster membro.

Dominio di errore

Un dominio di errore è un gruppo di hardware e software che potrebbero non riuscire insieme. Anche se è possibile designare uno o più cluster insieme come dominio di errore, ogni nodo può partecipare a un dominio di errore in un set di disponibilità. I limiti del dominio di errore si basano sulla topologia del data center, sull'architettura di rete e su altre considerazioni.

Set di disponibilità

Un set di disponibilità viene usato per configurare la ridondanza desiderata dei carichi di lavoro in cluster tra domini di errore raggruppando e distribuendo i carichi di lavoro. Per un'applicazione a due livelli, è necessario configurare almeno due macchine virtuali in un set di disponibilità per ogni livello, assicurando che quando un dominio di errore in un set di disponibilità si arresta, l'applicazione avrà almeno una macchina virtuale in ogni livello ospitata in un dominio di errore diverso.

Creare un gruppo di cluster

Usare PowerShell nel flusso di lavoro di esempio seguente per creare un set di cluster usando due cluster. Il nome del cluster impostato qui è CSMASTER.

Nome del cluster	Nome SOFS dell'infrastruttura
SET-CLUSTER	SOFS-CLUSTERSET
CLUSTER1	SOFS-CLUSTER1
CLUSTER2	SOFS-CLUSTER2

Usare un computer client di gestione che esegue Windows Server 2022 o Windows Server 2019.
Installare gli strumenti del cluster di failover nel server del cluster di gestione.
Creare due membri del cluster con almeno due Volumi Condivisi del Cluster (CSV) in ciascun cluster.
Creare un cluster di gestione (fisico o guest) che raggruppa i cluster membri. In questo modo si garantisce che il piano di gestione del set di cluster continui a essere disponibile nonostante i possibili errori del cluster membro.
Per creare il set di cluster:
```
New-ClusterSet -Name CSMASTER -NamespaceRoot SOFS-CLUSTERSET -CimSession SET-CLUSTER
```
Annotazioni

Se si usa un indirizzo IP statico, è necessario includere -StaticAddress x.x.x.x nel comando New-ClusterSet .

Per aggiungere membri del cluster al set di cluster:

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

Per enumerare tutti i cluster membri nel set di cluster:
```
Get-ClusterSetMember -CimSession CSMASTER
```
Per enumerare tutti i cluster membri nel set di cluster, inclusi i nodi del cluster di gestione:
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterNode
```
Per elencare tutti i nodi del server da tutti i cluster membri:
```
Get-ClusterSetNode -CimSession CSMASTER
```

Per elencare tutti i gruppi di risorse nel set di cluster:

Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterGroup

Per verificare che il set di cluster contenga una condivisione SMB (ScopeName, che è il nome del file server di infrastruttura) sul SOFS dell'infrastruttura per ogni volume CSV membro del cluster:
```
Get-SmbShare -CimSession CSMASTER
```

Esaminare i file di log di debug del set di cluster, del cluster di gestione e di ciascun membro del cluster:

Get-ClusterSetLog -ClusterSetCimSession CSMASTER -IncludeClusterLog -IncludeManagementClusterLog -DestinationFolderPath <path>

Configurare Kerberos con delega vincolata tra tutti i membri del set di cluster.
Configurare il tipo di autenticazione della migrazione live delle VM tra cluster su Kerberos per ogni nodo del set di cluster.
```
foreach($h in $hosts){ Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -ComputerName $h }
```

Aggiungere il cluster di gestione al gruppo di amministratori locali su ogni nodo nel set di cluster.

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

Creare macchine virtuali del set di cluster

Dopo aver creato il set di cluster, il passaggio successivo consiste nel creare macchine virtuali. È consigliabile eseguire in anticipo i controlli seguenti:

Controllare la memoria disponibile in ogni nodo del server del cluster
Controllare lo spazio su disco disponibile in ogni nodo del server del cluster
Controllare eventuali requisiti di archiviazione delle macchine virtuali specifici in termini di velocità e prestazioni

Il Get-ClusterSetOptimalNodeForVM comando identifica il cluster e il nodo ottimali nel set di cluster e quindi distribuisce la macchina virtuale. Nell'esempio seguente viene creata una nuova macchina virtuale con:

4 GB disponibili
Un processore virtuale
10% CPU minima disponibile

# 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

Al termine, viene visualizzato il nodo del cluster in cui è stata distribuita la macchina virtuale. Per l'esempio precedente, viene visualizzato come segue:

State         : Running
ComputerName  : 1-S2D2

Se la memoria, la capacità della CPU o lo spazio su disco disponibile per aggiungere la macchina virtuale non sono sufficienti, verrà visualizzato l'errore seguente:

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

Dopo aver creato la macchina virtuale, viene visualizzata in Hyper-V manager nel nodo specifico specificato. Per aggiungerla come macchina virtuale del set di cluster e aggiungerla al cluster, usare questo comando:

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

Al termine, l'output è:

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

Se è stato creato un cluster usando macchine virtuali esistenti, è necessario registrare le macchine virtuali con il set di cluster. Per registrare tutte le macchine virtuali contemporaneamente, usare:

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

Aggiungere quindi il percorso della macchina virtuale allo spazio dei nomi del set di cluster.

Si supponga, ad esempio, che un cluster esistente venga aggiunto al set di cluster con macchine virtuali preconfigurato che risiedono nel volume condiviso cluster locale (CSV). Il percorso per VHDX sarà simile a C:\ClusterStorage\Volume1\MYVM\Virtual Hard Disks\MYVM.vhdx1.

È necessaria una migrazione dell'archiviazione, poiché i percorsi CSV sono in base alla progettazione locali a un singolo cluster membro e pertanto non sono accessibili alla macchina virtuale dopo che sono stati migrati in tempo reale tra cluster membri.

In questo esempio, CLUSTER3 viene aggiunto al gruppo di cluster usando Add-ClusterSetMember con il file server per l'espansione orizzontale SOFS-CLUSTER3. Per spostare la configurazione e l'archiviazione della macchina virtuale, il comando è:

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

Al termine, è possibile che venga visualizzato un avviso:

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.

Questo avviso può essere ignorato perché non sono state apportate modifiche fisiche nella configurazione dell'archiviazione dei ruoli della macchina virtuale. La posizione fisica effettiva non cambia; solo i percorsi di configurazione.

Per altre informazioni su Move-VMStorage, vedere Move-VMStorage.

La migrazione in tempo reale di una macchina virtuale all'interno di un set di cluster prevede quanto segue:

Set-VMHost -UseAnyNetworkForMigration $true

Quindi, per spostare una macchina virtuale del set di cluster da CLUSTER1 a NODE2-CL3 in CLUSTER3, ad esempio, il comando sarà:

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

Questo comando non sposta l'archiviazione o i file di configurazione della macchina virtuale e non è necessario perché il percorso della macchina virtuale rimane come \\SOFS-CLUSTER1\VOLUME1. Dopo che una macchina virtuale è stata registrata con il percorso di condivisione file server dell'infrastruttura, le unità e la macchina virtuale non devono trovarsi nello stesso nodo della macchina virtuale.

Creare il file server di scalabilità orizzontale dell'infrastruttura

In un cluster è presente un ruolo del cluster SOFS dell'infrastruttura. Il ruolo SOFS dell'infrastruttura viene creato specificando il -Infrastructure parametro switch al Add-ClusterScaleOutFileServerRole cmdlet. Per esempio:

Add-ClusterScaleoutFileServerRole -Name "my_infra_sofs_name" -Infrastructure

Ogni volume CSV creato attiva automaticamente la creazione di una condivisione SMB con un nome generato automaticamente in base al nome del volume CSV. Non è possibile creare o modificare direttamente le condivisioni SMB con un ruolo SOFS, diversamente dall'uso di operazioni di creazione e modifica del volume CSV.

Nelle configurazioni iperconvergenti, un SOFS dell'Infrastruttura consente a un client SMB (hostHyper-V) di comunicare con la disponibilità continua (CA) al server SMB SOFS dell'infrastruttura. Questa CA di loopback SMB iperconvergente viene realizzata da VM che accedono ai file del disco virtuale (VHDX), in cui l'identità della VM proprietaria viene inoltrata tra il client e il server. Questo inoltro di identità consente l'uso di ACL per i file VHDx esattamente come nelle configurazioni standard del cluster iperconvergente in precedenza.

Dopo aver creato un set di cluster, lo spazio dei nomi del set di cluster si basa su un SOFS dell'infrastruttura in ciascuno dei cluster membri e su un SOFS dell'infrastruttura nel cluster di gestione.

Al momento in cui un cluster membro viene aggiunto a un set di cluster, è possibile specificare il nome di un SOFS dell'infrastruttura su quel cluster se uno esiste già. Se l'Infrastructure SOFS dell'infrastruttura non esiste, viene creato un nuovo ruolo Infrastructure SOFS nel nuovo cluster membro. Se nel cluster membro esiste già un ruolo SOFS dell'infrastruttura, l'operazione Aggiungi lo rinomina in modo implicito con il nome specificato in base alle esigenze. Tutti i server SMB esistenti o i ruoli SOFS non appartenenti all'infrastruttura nei cluster membri non vengono usati dal set di cluster.

Quando viene creato il set di cluster, hai l'opzione di utilizzare un oggetto computer AD esistente come radice dello spazio dei nomi nel cluster di gestione. La creazione del set di cluster crea il ruolo del cluster SOFS dell'infrastruttura nel cluster di gestione o rinomina il ruolo SOFS dell'infrastruttura esistente. Il SOFS dell'infrastruttura nel cluster di gestione viene usato come SOFS di riferimento per lo spazio dei nomi del set di cluster.

Creare domini di errore e set di disponibilità

I domini di errore e i set di disponibilità simili ad Azure possono essere configurati in un set di cluster. Ciò è utile per le migrazioni e i posizionamento iniziali delle macchine virtuali tra cluster.

L'esempio seguente include quattro cluster in un insieme di cluster. All'interno del set viene creato un dominio di errore con due dei cluster e viene creato un secondo dominio di errore con gli altri due cluster. Questi due domini di errore comprendono il set di disponibilità.

Nell'esempio seguente, CLUSTER1 e CLUSTER2 si trovano nel dominio di errore FD1 e CLUSTER3 e CLUSTER4 si trovano nel dominio di errore FD2. Il set di disponibilità è CSMASTER-AS.

Per creare i domini di errore, i comandi sono:

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"

Per assicurarsi che siano stati creati correttamente, Get-ClusterSetFaultDomain può essere eseguito con l'output mostrato per 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

Dopo aver creato i domini di errore, viene creato il set di disponibilità:

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

Per convalidare che sia stato creato, usare:

Get-ClusterSetAvailabilitySet -AvailabilitySetName CSMASTER-AS -CimSession CSMASTER

Quando si creano nuove macchine virtuali, usare il -AvailabilitySet parametro per determinare il nodo ottimale per il posizionamento. Ecco un esempio:

# 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)

Rimuovere un cluster da un set

In alcuni casi è necessario rimuovere un cluster da un set di cluster. Come procedura consigliata, tutte le macchine virtuali del set di cluster devono essere spostate prima dal cluster. Questa operazione può essere eseguita usando i Move-ClusterSetVM comandi e Move-VMStorage .

Se le macchine virtuali non vengono spostate prima dal cluster, tutte le macchine virtuali del set di cluster rimanenti ospitate nel cluster rimosso diventeranno macchine virtuali a disponibilità elevata associate a tale cluster, presupponendo che abbiano accesso alla risorsa di archiviazione. I set di cluster aggiornano automaticamente il loro inventario smettendo di monitorare l'integrità di un cluster che è stato rimosso e le macchine virtuali che girano su di esso, rimuovendo inoltre lo spazio dei nomi e tutti i riferimenti alle condivisioni ospitate nel cluster rimosso.

Ad esempio, il comando per rimuovere il cluster CLUSTER1 da un set di cluster è:

Remove-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER

Backup dello stato del sistema

Il backup dello stato del sistema salverà lo stato e i metadati del cluster. Usando Windows Server Backup, è possibile ripristinare solo il database del cluster di un nodo, se necessario o eseguire un ripristino autorevole per eseguire il rollback dell'intero database del cluster in tutti i nodi. Per i set di cluster, è consigliabile eseguire prima un ripristino autorevole per i cluster membri e quindi per il cluster di gestione. Per ulteriori informazioni sul backup dello stato del sistema, consultare Backup dello stato del sistema e configurazione di base.

Passaggi successivi

Maggiori informazioni su Storage Replica.