• Guide, Sistemi Operativi
• 12 Ottobre 2019

Il Failover Cluster è un gruppo di computer che interagiscono tra di loro per migliorare la disponibilità e la scalabilità dei ruoli cluster. Se in uno o più nodi del cluster si verifica un errore, il servizio verrà garantito dagli altri nodi (processo di failover). I ruoli cluster, inoltre, vengono monitorati in modo proattivo per verificare che funzionino correttamente. Se non funzionano, vengono riavviati o spostati in un altro nodo.

Novità del clustering di failover in Windows Server 2019

• Set di cluster – Consentono di aumentare il numero di server oltre i limiti correnti di un cluster. Questa operazione viene eseguita mediante il raggruppamento di più cluster in un set di cluster. Maggiori papprofondimenti sono disponibili leggendo il mio articolo Introduzione ai Cluster Sets in Windows Server 2019
• Azure-aware cluster – I cluster di failover rileva ora automaticamente quando è in esecuzione nelle macchine virtuali IaaS di Azure e ottimizza la configurazione per garantire il failover proattivo e la registrazione degli eventi di manutenzione pianificata di Azure per ottenere i massimi livelli di disponibilità.
• Migrazione del cluster tra domini (cross-domain)– I cluster di failover si possono ora spostare in modo dinamico da un dominio di Active Directory ad un altro, semplificando il consolidamento dei domini.
• USB witness – È ora possibile usare un semplice dispositivo USB collegato a uno switch di rete come witness nella determinazione del quorum per un cluster.
• Miglioramenti all’infrastruttura di cluster – La cache CSV è ora abilitata per impostazione predefinita per migliorare le prestazioni delle macchine virtuali.
• Cluster Aware Updating supporta Storage Spaces Direct – Cluster Aware Updating (CAU) è ora integrato e compatibile con Storage Spaces Direct e convalida e garantisce il completamento della risincronizzazione dei dati su ciascun nodo. In più controlla gli aggiornamenti solo se necessario e riavvia i nodi in modo intelligente. In questo modo orchestra i riavvii di tutti i server del cluster per la manutenzione pianificata.
• Cluster hardening – Le comunicazioni interne a un cluster tramite Server Message Block (SMB) per Cluster Shared Volumes e Storage Spaces Direct ora sfruttano i certificati per rendere la piattaforma più sicura. In questo modo i cluster di failover possono funzionare senza dipendenze su NTLM e abilitare le baseline di sicurezza.
• Eliminazione dell’autenticazione NTLM – Il cluster di failover non utilizza più l’autenticazione NTLM, ma usa in maniera esclusiva l’autenticazione Kerberos e l’autenticazione basata su certificati. Non sono necessarie modifiche da parte per sfruttare i vantaggi di questo miglioramento della sicurezza.

Schema di funzionamento di un cluster iperconvergente

Per realizzare questa guida ho creato un domain controller (DC1.virtual.lab) e due server che verranno poi utilizzati per creare il cluster iperconvenrgente (HVCONV1-NIC.virtual.lab e HVCONV2-NIC.virtual.lab). Ad ognuno dei due nodi del cluster ho aggiunto anche 4 dischi da 2 TB ciascuno. Tutte le macchine sono state create sul mio portatile con Windows 10, verisone 1903 grazie all’ausilio della Nested Virtualization, una funzionalità disponibile da Windows 10 Anniversary Update e in Windows Server 2016.

Figura 1: Schema del laboratorio per la realizzazione di un cluster Hyper-V iperconvergente a due nodi

Dopo aver creato le due macchine virtuali HVCONV1-NIC e HVCONV2-NIC, ho assegnato loro 4 GB di RAM statica e ho lanciato tramite PowerShell con privilegi elevati i comandi:

 

Controllate la pagina prerequisiti per la Nested Virtualization per avere maggiori informazioni in merito alle configurazioni per la virtualizzazione annidata.

Ho installato Windows Server 2019 all’interno delle macchine HVCONV1-NIC ed HVCONV2-NIC e le ho aggiunte al dominio. Successivamente ho abilitato il ruolo di Hyper-V e la funzionalità di Failover Clustering. È possibile abilitare il ruolo anche utilizzando la nuova funzionalità di PowerShell Direct. Questa funzionalità permette di eseguire delle cmdlet di PowerShell dalla macchina host verso le VM, anche se le VM non hanno una scheda di rete o la scheda di rete è disconnessa. I comandi che ho usato sono:

 

In alternativa potete collegarvi al domain controller ed eseguire il comando PowerShell

 

Figura 2: Installazione del ruolo di Hyper-V e della funzionalità di Failover Cluster sui due nodi Windows Server 2019 tramite PowerShell

Terminata l’installazione della funzionalità, utilizzate la console del Failover Cluster Manager per testare la configurazione dei due nodi e per creare il nuovo cluster. Vi consiglio di verificare i prerequisiti elencati alla pagina Creare un cluster di failover

Lanciate quindi il wizard per la validazione del cluster, in modo tale da essere sicuri che tutti i prerequisiti siano stati rispettati.

Figura 3: Lancio del wizard di validazione del Failover Cluster

Figura 4: Aggiunta dei due nodi da testare

Scegliete nella schermata successiva di effettuare solo i test che volete selezionare e fate clic su Next

Figura 5: Scelta dei test da eseguire

Ricordatevi di selezionare tra i test anche quello relativo a “Storage Spaces Direct“, che non è selezionato di default

Figura 6: Aggiunta del test relativo a Storage Spaces Direct

Figura 7: Validazione del cluster in corso

Figura 8: Wizard di validazione del cluster completato

Per testare il cluster è anche possibile utilizzare il comando PowerShell:

 

Figura 9: Test del cluster utilizzando PowerShell

Creazione del cluster

Procedete quindi alla creazione del cluster utilizzando l’apposito wizard

Figura 10: Wizard di creazione del cluster

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

Figura 12: Conferma delle configurazioni scelte

Figura 13: Creazione del cluster completata

Se avete configurato tutto correttamente potrete accedere alla console del Failover Cluster Manager per verificare la creazione.

Figura 14: Console Failover Cluster Manager

Figura 15: Nodi del cluster

Configurazione del Quorum

Il Quorum riveste un ruolo molto importante nel cluster. Si tratta di un meccanismo che viene utilizzato per assicurarsi che nel caso ci sia un’interruzione delle comunicazioni tra i nodi del cluster oppure uno dei nodi non sia disponibile perché ha subito un guasto, siano sempre disponibili la maggioranza delle risorse del cluster. Il Quorum diventa particolarmente importante nel momento in cui avete un numero pari di nodi. Una cartella condivisa su un nodo che non sia parte del cluster può essere un’ottima soluzione per il nostro scenario di cluster iperconvergente a due nodi e permette di arbitrare le risorse ed evitare la split-brain nel caso uno dei due nodi abbia un malfunzionamento. Io ho scelto di utilizzare una cartella condivisa (servono 5MB di spazio) che si trova sul domain controller, all’interno della quale verrà creato il file witness.log che si occuperà di stabilire chi ha in carico le risorse.

NOTA: il Disk Witness non è supportato con gli Storage Spaces Direct

Il concetto di quorum merita sicuramente un approfondimento e per questo motivo vi rimando alla lettura dell’articolo Configure and manage quorum

Vi ricordo anche che da Windows Server 2016 è disponibile una nuova modalità di quorum: Il Cloud Witness, se il vostro cluster ha accesso ad Internet.

Dalla console Failover Cluster Manager su HVCONV1-NIC è possibile cambiare la modalità di quorum selezionando il nome del cluster e scegliendo More Actions à Configure Cluster Quorum Settings…

Seguite il wizard e scegliete il server e la cartella condivisa da utilizzare. È possibile creare la nuova cartella condivisa direttamente dal wizard.

Figura 16: Modifica della modalità di quorum nel cluster iperconvergente a due nodi

Figura 17: Selezione del quorum witness

Figura 18: Scelta dell’utilizzo di una file share come quorum witness

Figura 19: Creazione e utilizzo di una cartella condivisa per il quorum witness

Figura 20: Conferma delle configurazioni scelte

Figura 21: Verifica della nuova modalità di Witness nel Failover Cluster Manager

Abilitazione della funzionalità di Storage Spaces Direct

Siamo pronti per abilitare la funzionalità di Storage Spaces Direct (S2D). In Hyper-V i dischi collegati alle macchine virtuali riportano come MediaType il valore Unspecified. Storage Spaces Direct utilizza i due valori BusType e MediaType per configurare automaticamente lo storage pool, lo storage tiering e la cache. Durante l’abilitazione degli Storage Spaces Direct potreste avere un errore relativo alla creazione della cache. Nel laboratorio potete ignorarlo.

Prima di abilitare la funzionalità S2D vi invito a dare un’occhiata ai requisiti hardware per gli Storage Spaces Direct visionando la guida Storage Spaces Direct hardware requirements. Tra le configurazioni supportate io ho scelto quella in cui ci sono 4 dischi NVMe per ogni singolo nodo.

Per questo motivo ho aggiunto ad entrambi i nodi HVCONV1-NIC ed HVCONV2-NIC 4 dischi da 2 TB.

Per abilitare Storage Spaces Direct è sufficiente lanciare la cmdlet di PowerShell

 

Figura 22: Abilitazione della funzionalità di Storage Spaces Direct utilizzando PowerShell

Figura 23: Abilitazione della funzionalità di Storage Spaces Direct completata

Se ricevete degli errori visionate il report e individuate qual è la causa. Nel mio caso, come già accennato, poiché i dischi non riportano il MediaType, S2D non è stato in grado di capire se ci fossero dischi da utilizzare per la cache.

Figura 24: Warning nel report di abilitazione della funzionalità di Storage Spaces Direct

Dopo che l’abilitazione della funzionalità di Storage Spaces Direct è completata (potrebbero volerci un paio di minuti) vi accorgerete che nella console del Failover Cluster Manager è disponibile un pool di dischi chiamato Cluster Pool 1 che ha come dimensione esattamente la metà dello spazio dei dischi che avete aggiunto ai due nodi, in quanto è stato arrivato il mirroring tra i dischi

Figura 25: Cluster pool di dischi in mirror

Sempre dalla console noterete che è stato creato un Cluster Virtual Disk (ClusterPerformnaceHistory) della dimensione di 12 GB. Si tratta di una nuova funzionalità inserita in Windows Server 2019 che permette agli amministratori di poter acceder facilmente alle performance di storage, rete, memoria e utilizzo dei processori. Questo tipo di informazioni sono collezionate di default con gli Storage Spaces Direct in Windows Server 2019 e possono essere accedute graficamente tramite Windows Admin Center. Trovate maggiori informazioni nell’articolo Performance history for Storage Spaces Direct

Figura 26: Performance history for Storage Spaces Direct:

È anche possibile utilizzare la PowerShell Get-ClusterPerformanceHistory per ottenere le stesse informazioni in maniera programmatica

Figura 27: Cluster Performance History tramite PowerShell

Lo Storage Pool creato è anche visibile dal Server Manager nel nodo File and Storage Services

Figura 28: Lo Storage Pool creato è anche visibile dal Server Manager

Creazione dei volumi

È possible creare volume in Storage Spaces Direct utilizzando Windows Admin Center, PowerShell oppure la console Failover Cluster Manager. Nell’articolo Creating volumes in Storage Spaces Direct troverete dei video di approfondimento e tutti i consigli per la creazione di diversi tipi di volume.

Utilizzando PowerShell potete semplificare di molto la creazione dei volumi. Con la cmedlet New-Volume potrete creare un disco, partizionarlo e formattarlo, creare il volume associato e aggiungerlo ai Cluster Shared Volumes. Tutto con un unico comando!

Io ho creato due volumi da 500 GB utilizzando le due cmdlet

 

Figura 29: Creazione di due volumi utilizzando PowerShell

Nel caso di 4 o più server è anche possibile definire per la cmdlet New-Volume il parametro ResiliencySettingName, che può avere i valori Mirror oppure Parity

Figura 30: I due nuovi volumi creato sono disponibili nella console del Failover Cluster Manager

Figura 31: I due nuovi volumi creato sono disponibili in Esplora risorse

Creazione di una VM clusterizzata

D’ora in poi tutte le creazioni e le configurazioni delle macchine virtuali dovranno essere effettuate dalla console del Failover Custer Manager e non più dall’Hyper-V Manager. Cliccate sul nodo Roles e col tasto destro fate partire il wizard di creazione di una nuova VM con Virtual MachinesàNew Virtual Machine…

Figura 32: Wizard per la creazione di una nuova VM dalla console del Failover Custer Manager

Scegliete su quale nodo del cluster iperconvergente volete che venga creata la macchina virtuale

Figura 33: Scelta del nodo del cluster iperconvergente su cui sarà creata la macchina virtuale

Figura 34: I file della VM devono essere salvati nel Cluster Shared Volume altrimenti non saranno visibili da tutti i nodi del cliuster

Per effettuare le modifiche alla configurazione della macchina virtuale servitevi sempre della console del Failover Cluster Manager. Dalla stessa console potete avviarla, spegnerla, migrarla su un altro nodo, ecc…

Figura 35: Tutte le operazioni sulla VM devono essere effettuate dalla console del Failover Cluster Manager

Figura 36: Avvio della VM

Scaling-Up

L’aggiunta di dischi, anche chiamata Scaling-up, permette adi aggiungere capacità e può migliorare le performance del cluster. Se avete la poissobilità, potete aggiungere ukteriori dischi ai server senza necessariamente aggiungere un nuovo nodo al cluster. È possibile aggiungere dischi per la cache oppure dischi per la capacità in qualsiasi momento. È però altamente raccomandato di mantenere identiche le configurazioni storage dei server.

Appena aggiungerete i nuovi dischi ai vostri server, questi verranno utilizzati da Storage Spaces Direct nel giro di pochissimo tempo, senza che sia richiesto nessun intervento da parte vostra. I dischi verranno aggiunti allo storage pool e i volumi verranno automaticamente ridistribuiti tra tutti i dischi presenti.

NOTA: è importante che i dischi non contengano dati. Potete formattarli da Disk Managemrnt oppure con la cmdlet di PowerShell Reset-PhysicalDisk

Dalla console del Failover Cluster Manager sarà sufficiente selezionare il Cluster Pool e verificare che siano stati aggiunti i dischi

Figura 37: Dopo l’aggiunta dei dischi il Disk Pool è aumentato automaticamente di capacità. Sono visibili i nuovi dischi fisici aggiunti

È possibile visualizzare le proprietà dei dischi utilizzando PowerShell. Alla pagina https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/Deep-Dive-The-Storage-Pool-in-Storage-Spaces-Direct/ba-p/425959 trovate un ottimo script che vi permette di visualizzare i dischi fisici, determinare il nodo a cui sono collegati, calcolare la dimensione e lo spazio libero in GB e la percentuale di spazio libero disponibile. Potrebbe essere opportuno considerare di aggiungere altro storage quando la percentuale scende sotto il 30%

Figura 38: Script per controllare i dischi fisici collegati allo storage pool e per ogni disco determinare la dimensione, lo spazio libero, il nodo a cui sono collegati e la percentuale di spazio libero disponibile

Storage Spaces Direct ottimizza i dischi automaticamente dopo 15 minuti che sono stati aggiunti al pool. Eventualmente è possibile forzare l’ottimizzazione a mano con la cmdlet Optimize-StoragePool

Figura 39: Ottimizzazione manuale dello Storage Pool

Maggiori informazioni sono disponibili alla pagina Adding servers or drives to Storage Spaces Direct

Estensione del Cluster Shared Volume

L’estensione del Cluster Shared Volume è un processo in più fasi. Dopo aver aggiunto nuovi dischi e aver atteso che il bilanciamento sia stato completato, è necessario estendere il virtual disk che è stato creato nello storage pool. Per farlo è sufficiente utilizzare il comando PowerShell

 

Il passaggio successivo consiste nell’aumentare la dimensione della partizione, sempre con PowerShell

 

Figura 40: Il Vol1 è stato ingrandito

Conclusioni

Creare un cluster Hyper-V con 2 nodi ed utilizzare la nuova funzionalità Storage Spaces Direct ci permette di creare una infrastruttura iperconvergente altamente performante e scalabile, massimizzando l’utilizzo dell’hardware. Semplicemente collegando i due nodi con schede di rete a 10 GBit abbiamo semplificato di molto la creazione del cluster e le configurazioni necessarie per renderlo operativo.

Maggiori approfondimenti sono disponibili al link Storage Spaces Direct overview