• Guide, Sistemi Operativi
• 11 Gennaio 2025

In Windows Server 2016 è stata introdotta la possibilità di creare cluster usando dei nodi in workgroup, permettendo quindi di non dover utilizzare un dominio ed implementare dei domain controller. Ne avevo già parlato nell’articolo Implementare Workgroup Cluster e Multi-Domain Cluster in Windows Server 2016 – ICT Power

Tuttavia, la migrazione live (live migration) per i cluster Workgroup non era supportata fino ad oggi, con l’introduzione della funzionalità in Windows Server 2025. Ora, grazie a questa novità, è possibile sfruttare la flessibilità della migrazione live insieme all’alta disponibilità tipica dei cluster Workgroup, consentendo una gestione ancora più efficiente e resiliente delle risorse nei contesti aziendali.

Per implementare un workgroup cluster è necessario però che vengano rispettati determinati prerequisiti:

• Creare un account utente con lo stesso nome e la stessa password su tutti i nodi
• Aggiungere l’account creato al gruppo Administrators locale
• Se non si utilizza l’account predefinito Administrator è necessario creare la chiave di registro LocalAccountTokenFilterPolicy in HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System e metterla con valore 1
• È necessario creare il Cluster Network Name (chiamato anche Administrative Access Point) di tipo DNS
• Ogni nodo deve avere un suffisso DNS
• Il Witness consigliato è un Cloud Witness oppure un Disk Witness. Non è supportato l’utilizzo del File Share Witness.

Creazione del cluster

In questo articolo creeremo un workgroup cluster a due nodi (chiamati SRV2025-NODO1 e SRV2025-NODO2) utilizzando Windows Server 2025. Dopo aver preparato i nodi del cluster ed aver installato il sistema operativo ho provveduto a configurare il suffisso DNS su entrambi i nodi, come mostrato in figura:

Figura 1: Aggiunta del suffisso DNS al primo nodo del cluster

Figura 2: Aggiunta del suffisso DNS al secondo nodo del cluster

Procedete quindi al riavvio di entrambi i nodi.

Figura 3: Riavvio dei nodi dopo aver aggiunto il suffisso DNS

Dopo aver riavviato entrambi i nodi, ho provveduto a modificare il file HOSTS sulle macchine in modo tale che potessero risolvere i nomi dei nodi e il nome del cluster (che ho deciso di chiamare CLUSTER). Questa operazione è necessaria solo se non volete configurare un DNS. Nel caso abbiate un DNS in rete potete popolare la zona scelta (il suffisso DNS) per il vostro cluster (nel mio caso demo.lab).

Figura 4: Modifica del file HOSTS per la risoluzione del nomi

Figura 5: Utilizzo di un server DNS per la risoluzione dei nomi (nel caso sia disponibile)

Per creare e configurare un cluster Workgroup che supporti la live migration, vengono utilizzati account locali con lo stesso nome utente e la stessa password su ogni nodo. Il cluster utilizza certificati Public Key User-to-User (PKU2U) auto-firmati per l’autenticazione, consentendo la migrazione di una macchina virtuale da un nodo host a un altro. In pratica, il certificato permette a un nodo di verificare l’identità dell’altro nodo senza la necessità di un controller di dominio o di un server Kerberos.

Gli account locali su ogni nodo sono l’unico metodo di autenticazione valido per i cluster Workgroup e permettono la migrazione live tra il server di origine e quello di destinazione. Questo approccio è cruciale per garantire che le operazioni di migrazione vengano eseguite correttamente e in sicurezza.

Ho provveduto quindi a creare su entrambi i nodi l’account di servizio ClusterSVC, ho impostato la stessa password e l’ho aggiunto al gruppo Administrators locale, come mostrato in figura:

Figura 6: Creazione di un account locale con privilegi amministrativi su tutti i nodi del workgroup cluster

L’account è necessario affinché i nodi utilizzino l’autenticazione NTLM. Poiché non sto usando l’account Administrator è necessario inserire sui nodi la chiave di registro indicata nei prerequisiti. In maniera rapida ho eseguito sui due nodi, da un prompt PowerShell con privilegi elevati, il comando:

Figura 7: Inserimento della chiave di registro necessaria all’utilizzo degli account creati su tuttii nodi del cluster

Ogni nodo del cluster deve essere aggiunto a Windows Remote Management (WinRM) come host attendibile. A tale scopo, modificate il TrustedHosts file aggiungendo una voce per ogni server che si connetterà al computer locale. Questo processo implica la modifica del file TrustedHosts aggiungendo una entry per ogni server che si connetterà alla macchina locale.

Esistono molti modi per aggiungere host attendibili, tra cui nome host, nome di dominio o indirizzo IP. Il comando di PowerShell seguente consente a ogni nome host specificato di accedere al computer locale:

Completare questo processo in ogni nodo del server.

Figura 8: Ogni nodo del cluster deve essere aggiunto a Gestione remota Windows (WinRM) come host attendibile

Installazione del ruolo Hyper-V e della funzionalità di Failover Cluster

Provvedete ad installare il ruolo di Hyper-V e la funzionalità di Failover Cluster su tutti i nodi che parteciperanno al workgroup cluster. Questa operazione può essere fatta da interfaccia grafica utilizzando il Server Manager oppure con il comando PowerShell:

Figura 9: Installazione del ruolo Hyper-V e della funzionalità di Failover Cluster tramite PowerShell

Figura 10: Installazione del ruolo Hyper-V e riavvio dei nodi Windows Server 2025

Creazione del cluster

Terminata l’installazione lanciate la console del Failover Cluster Manager e lanciate il wizard per la creazione del Cluster. Ho aggiunto i due nodi e ho cliccato su Next, come mostrato in figura:

Figura 11: Wizard per la creazione del Failover Cluster

Eseguite i test di validazione del cluster tramite il Failover Cluster Manager per accertarvi che ogni nodo sia configurato correttamente e che siano soddisfatti i requisiti di compatibilità per la migrazione live. Questo test verifica che i nodi, la rete, lo storage e altri componenti necessari siano configurati correttamente per il funzionamento del cluster.

Figura 12: Scelta del test di validazione del cluster

Figura 13: Conferma del test di validazione del cluster

La validazione dei nodi del cluster si può fare anche tramite il comando PowerShell:

Figura 14: Esecuzione dei test di validazione dei nodi del cluster in corso

Al termine dei test aprite il report HTML generato e verificate la presenza di eventuali avvisi o errori. Come si può notare dalla figura sotto, riceverete un warning che vi avvisa di problemi di configurazione di Active Directory, proprio perché i nodi sono in workgroup.

Figura 15: Warning relativo alla non appartenenza dei nodi del cluster al dominio

Figura 16: Warning relativo alla non appartenenza dei nodi del cluster al dominio

Terminate tutte le verifiche, potete procedere con la creazione del cluster.

Figura 17: Creazione del cluster utilizzando i nodi verificati

Figura 18: Wizard per la creazione del cluster

Nella schermata successiva del wizard ho indicato il nome del cluster (basta solo il nome NETBIOS, senza suffisso DNS) e l’indirizzo IP scelto, come mostrato in figura:

Figura 19: Scelta del nome del cluster e dell’indirizzo IP

Terminata la verifica che non ci sia un server con lo stesso nome NETBOIS e non ci siano indirizzi IP duplicati nella stessa rete, appare la schermata riepilogativa mostrata in figura, che indica che il cluster utilizzerà per la registrazione solo il DNS:

Figura 20: Schermata di riepilogo del wizard di creazione del cluster

Figura 21: Creazione del cluster completata

L’operazione di creazione del cluster può essere effettuata anche tramite PowerShell utilizzando il comando:

Figura 22: Cluster creato con successo

Figura 23:Nodi del cluster

Come si può vedere dalla figura sotto, su tutti i nodi del cluster troverete installato lo stesso certificato con lo stesso seriale e lo stesso thumbprint.

I certificati PKU2U auto-firmati (Public Key User-to-User) consentono ai nodi di un cluster Workgroup di autenticarsi reciprocamente durante le operazioni come la migrazione live delle macchine virtuali. L’uso di certificati auto-firmati semplifica la configurazione di un cluster Workgroup, poiché non è necessario gestire una CA (Certificate Authority) esterna o utilizzare un dominio Active Directory per l’autenticazione.

Questi certificati sono una soluzione di autenticazione sicura tra i nodi di un cluster che non richiede infrastrutture esterne complesse e sono utilizzati per garantire che le operazioni di migrazione live e altre operazioni siano eseguite in modo sicuro tra i nodi del cluster.

Figura 24: Certificato PKU2U auto-firmato (Public Key User-to-User)

Cos’è il ruolo “User Manager Group” in Failover Cluster Manager?

In un cluster di failover Windows Server, il ruolo User Manager Group è un servizio che fa parte del sistema di gestione e sicurezza del cluster. In pratica, si occupa della gestione dell’accesso e dei permessi per gli utenti e i gruppi che interagiscono con il cluster. Il nome potrebbe sembrare indicare un gruppo di utenti, ma in realtà si tratta di un componente che gestisce le autorizzazioni degli utenti rispetto alle operazioni del cluster.

Questo servizio è associato alla gestione dell’autenticazione e dei permessi di accesso per le risorse del cluster e consente di assicurarsi che solo gli utenti o i gruppi autorizzati possano eseguire determinati compiti, come l’amministrazione del cluster, la gestione delle macchine virtuali, la migrazione live, e altre operazioni critiche.

Funzione del servizio User Manager Group

• Gestione degli accessi: Il servizio si occupa di autenticare e gestire chi può accedere alle funzionalità di amministrazione del cluster. Garantisce che solo gli utenti autorizzati possano eseguire operazioni su macchine virtuali, risorse di storage, e configurazioni del cluster.
• Controllo dei permessi: Gestisce i permessi di accesso a livello di servizio, assicurando che gli utenti o i gruppi che interagiscono con il cluster abbiano i privilegi appropriati. In altre parole, funge da “guardiano” che controlla chi ha il permesso di eseguire determinati task amministrativi.
• Sicurezza: Il servizio contribuisce a mantenere la sicurezza del cluster, assicurando che solo i membri di gruppi autorizzati possano modificare la configurazione del cluster o eseguire azioni come la migrazione live o il failover delle macchine virtuali.

Figura 25: Ruolo “User Manager Group” in Failover Cluster Manager

Al Failover Cluster ho aggiunto un disco condiviso attraverso un’infrastruttura iSCSI. iSCSI è una tecnologia di rete che consente di connettere i dispositivi di archiviazione remoti (come un array di dischi) ai server attraverso una rete IP, simile a un protocollo di rete per la gestione dei dispositivi di archiviazione a livello di blocco. Una volta che questo disco è stato integrato nel cluster, è stato convertito in un Cluster Shared Volume (CSV). Un CSV è un tipo di volume che permette a tutti i nodi (server) del failover cluster di accedere contemporaneamente alla stessa unità di archiviazione, migliorando la disponibilità e la gestione delle risorse.

Questo Cluster Shared Volume ospiterà successivamente le macchine virtuali (VM).

Per maggiori dettagli vi invito a consultare la pagina Use Cluster Shared Volumes in a failover cluster | Microsoft Learn

Figura 26: Cluster Storage Volume aggiunto al Cluster

Creazione di una nuova macchina virtuale in alta disponibilità

Dopo aver creato il cluster potete creare le macchine virtuali che saranno altamente disponibili. Per farlo basta lanciare dal Failover Cluster Manager il menu Roles > Virtual Machines… > New Virtual Machine e seguire il wizard di creazione della nuova VM, come mostrato nelle figure sotto:

Figura 27: Creazione di una nuova VM altamente disponibile

Figura 28: Scelta del nodo su cui deve essere inizialmente creata la VM

Figura 29: Wizard di creazione della nuova VM

Il cluster deve avere una delle seguenti tecnologie di storage configurate e disponibili per tutti i nodi del cluster:

• Storage Spaces Direct (S2D). Se si sta creando un cluster con Storage Spaces Direct, consultare la sezione Storage Spaces Direct hardware requirements | Microsoft Learn.
• SAN attached storage.
• NAS con SMB 3.0 o versione successiva.

Per altre informazioni sui requisiti di storage del clustering di failover consultate la pagina Failover clustering hardware requirements and storage options | Microsoft Learn.

Io ho deciso di mettere i file di configurazione e i dischi della nuova macchina virtuale nel Cluster Shared Volume che ho aggiunto prima.

Figura 30: Configurazione della nuova VM

Figura 31: Schermata finale del wizard di creazione della nuova VM

Figura 32: Nuova VM altamente disponibile creata con successo

La nuova macchina virtuale è stata creata con successo ed è associata al nodo scelto in fase di creazione. Non ci resta che accenderla .

Figura 33: Nuova VM associata al nodo SRV2025-NODO2

Figura 34: Nuova VM in esecuzione sul nodo SRV2025-NODO2 ed in fase di installazione

Live migration della VM nell’Hyper-V workgroup cluster

La migrazione live di una macchina virtuale (VM) in un cluster Hyper-V Workgroup è un processo che consente di spostare una macchina virtuale da un nodo a un altro senza interruzioni nel servizio. Grazie alle impostazioni che abbiamo implementato e alla novità introdotta in Windows Server 2025, il sistema eseguirà la migrazione senza interruzione del servizio, spostando lo stato della VM e le risorse da un nodo all’altro.

L’operazione viene fatta cliccando col tasto destro sulla VM e scegliendo Move > Live Migration > Best Possible Node oppure Select node…

L’opzione Best Possible Node è quella più automatica e “intelligente”. Quando selezionate questa opzione, Hyper-V prende autonomamente la decisione su quale nodo del cluster sia il più adatto per eseguire la migrazione della macchina virtuale in base a diversi fattori. Questi fattori includono:

• Capacità di risorse disponibili (CPU, memoria, ecc.)
• Utilizzo delle risorse su ciascun nodo
• Affinità della rete (se ci sono problemi di rete che potrebbero influire sulla migrazione)
• Utilizzo dello storage condiviso e accessibilità

Hyper-V valuta automaticamente la situazione e seleziona il nodo più adatto per la migrazione, cercando di ottimizzare l’allocazione delle risorse per garantire che la macchina virtuale venga spostata nel nodo con le migliori condizioni operative.

L’opzione Select Node… vi consente di scegliere manualmente il nodo di destinazione su cui desiderate migrare la macchina virtuale. Quando selezionate questa opzione, vi viene mostrata una lista di tutti i nodi disponibili nel cluster e potete scegliere esplicitamente su quale nodo eseguire la migrazione. Vi offre un controllo totale sul processo di migrazione, poiché potete selezionare il nodo che preferite, basandovi su esigenze specifiche come la posizione geografica, la disponibilità delle risorse, la distribuzione del carico di lavoro o altre considerazioni particolari.

Figura 35: Live migration della VM nell’Hyper-V workgroup cluster

Figura 36: Live migration della VM nell’Hyper-V workgroup cluster

Figura 37: Live migration della VM nell’Hyper-V workgroup cluster eseguita con successo

Configurazione del Quorum

La configurazione del quorum in un cluster Workgroup è un aspetto fondamentale per garantire la disponibilità e la consistenza del cluster. Il quorum è il meccanismo che consente di determinare se il cluster è operativo e in grado di continuare a funzionare in modo corretto, soprattutto in caso di guasti di nodi o di comunicazioni tra i nodi.

Nel caso di un cluster Workgroup, che non è integrato in Active Directory, la configurazione del quorum deve essere gestita in modo diverso rispetto ai cluster che fanno parte di un dominio. Le modalità di quorum supportate sono:

1. Node Majority
   

In questa modalità, ogni nodo del cluster ha un “voto” e il cluster richiede che più della metà dei nodi siano attivi e in grado di comunicare per rimanere operativo.

• Funzionamento: Ogni nodo ha un voto. Se il numero di nodi attivi (e quindi di voti) è maggiore della metà, il cluster può continuare a funzionare.
• Pro: Semplice da configurare e funziona bene per cluster con un numero dispari di nodi.
• Contro: Se più della metà dei nodi fallisce o non può comunicare, il cluster non sarà in grado di operare. Meno resiliente in caso di guasti di rete o nodi che non sono più raggiungibili.

1. Cloud Witness
   

Il Cloud Witness sfrutta Microsoft Azure come testimone remoto che fornisce un “voto” aggiuntivo per determinare il quorum. È particolarmente utile per i cluster Workgroup, dove non è disponibile un dominio Active Directory.

• Funzionamento: Il Cloud Witness si basa su un account di archiviazione in Azure. Se il cluster non può raggiungere la maggioranza dei nodi, il Cloud Witness fornisce un “voto” remoto per determinare se il cluster può continuare a funzionare.
• Pro: Alta disponibilità e resilienza grazie all’infrastruttura di Azure, indipendente da Active Directory e da risorse fisiche locali.
• Contro: Necessita di una connessione a Internet stabile e di un account di archiviazione Azure. Se Azure è irraggiungibile, il cluster potrebbe non essere in grado di raggiungere il quorum.

1. Disk Majority
   

La modalità Disk Majority è una modalità di quorum in cui viene utilizzato un disco condiviso (testimone di quorum) per determinare se il cluster può continuare a funzionare. Questo disco funge da “testimone”, e in caso di guasto di uno o più nodi, il cluster verifica la disponibilità del disco per decidere se continuare a operare.

• Funzionamento: In questa modalità, oltre ai nodi, un disco di quorum condiviso viene utilizzato come terzo “voto”. Il disco di quorum è accessibile da tutti i nodi del cluster e fornisce un voto supplementare. Se il disco non è accessibile (ad esempio, in caso di guasto del disco o del nodo che lo ospita), il cluster non raggiungerà il quorum e si interromperà.
• Pro: Non dipende da servizi esterni come Internet o Azure, il che può risultare vantaggioso in ambienti che preferiscono mantenere tutto localmente.
• Contro: Richiede un’infrastruttura di archiviazione condivisa, il che può comportare costi e complessità nella configurazione. Inoltre, la disponibilità del disco di quorum è cruciale: se il disco non è raggiungibile, il cluster non potrà continuare a funzionare.

Ogni modalità ha i suoi vantaggi e svantaggi e la scelta dipenderà dalle esigenze specifiche del vostro ambiente e dalla configurazione delle risorse disponibili.

Conclusioni

In questa guida, abbiamo esplorato come configurare e gestire un Hyper-V Workgroup Cluster, concentrandoci in particolare sulla migrazione live delle macchine virtuali tra i nodi del cluster. Sebbene un cluster Workgroup non sia integrato con Active Directory, possiamo comunque ottenere un’infrastruttura altamente disponibile e resiliente con una configurazione appropriata.

La migrazione live delle macchine virtuali rappresenta un aspetto chiave nella gestione di un cluster Hyper-V. Abilitando la migrazione live, è possibile spostare le macchine virtuali tra i nodi senza interruzioni, garantendo continuità operativa anche in caso di manutenzione o guasti parziali.

Nel complesso, un Hyper-V Workgroup Cluster può essere una scelta efficace per ambienti che non vogliono o non possono usare un dominio Active Directory. Con una configurazione accurata, è possibile ottenere alta disponibilità, migrazione live delle macchine virtuali e una gestione del quorum che garantisca l’affidabilità e la continuità operativa. È fondamentale, però, prestare attenzione alla configurazione di rete, alla gestione delle risorse condivise e all’autenticazione tra i nodi, per mantenere l’ambiente stabile e sicuro.