Nicola Ferrini

Guide, Sistemi Operativi
23 Marzo 2017

Windows Server 2016 Highlights: Hyper-converged Cluster

Tra le novità di Windows Server 2016 spiccano quelle relative all’iperconvergenza dello storage e dell’hypervisor. Per iperconvergenza o per infrastruttura iperconvergente si intende una infrastruttura IT basata su risorse hardware offerte da un unico vendor, che integra calcolo, memorizzazione, virtualizzazione e networking. Tutte le risorse vengono gestite tramite software e l’espansione del sistema è fortemente semplificata.

Avevamo già parlato in un precedente articolo su come implementare Storage Spaces Direct. La nuova funzionalità S2D di Windows Server 2016 permette infatti di creare sistemi di storage ad alta disponibilità utilizzando dischi locali. Se poi sugli stessi nodi fisici utilizzati per creare l’infrastruttura S2D installiamo anche Hyper-V, abbiamo la possibilità di creare un cluster hyper-convergente.

Vi ricordo che Storage Spaces Direct è una funzionalità disponibile solo nella versione Datacenter di Windows Server 2016. Per conoscere le differnze tra le diverse versioni di Windows Server vi rimando alla lettura dell’articolo Windows Server 2016 – Quali sono le differenze tra la Standard Edition e la Datacenter Edition.

Figura 1: Schema di funzionamento di una soluzione Hyper-convergente

In questo articolo vi voglio mostrare queste due funzionalità e realizzare un laboratorio di test per provare la soluzione di Hyper-convergenza offerta da Microsoft. L’obiettivo è quello di creare un cluster formato da SOLO 2 NODI di Hyper-V che usa Storage Spaces Direct.

Figura 2: Schema del laboratorio da realizzare

Nel mio laboratorio, realizzato su un computer con Windows 10 Anniversary Update e con il ruolo Hyper-V installato, ho creato due macchine virtuali, chiamate HV1 ed HV2, all’interno delle quali ho installato Hyper-V. Questo mi permette anche di farvi vedere come funziona la Nested Virtualization, un’altra novità disponibile in Windows 10 Anniversary Update e in Windows Server 2016.

Dopo aver creato le due macchine virtuali HV1 ed HV2 ed aver assegnato loro almeno 4GB di RAM staticamente (controllate i prerequisiti per la Nested Virtualization), ho lanciato (a VM spente) una PowerShell con privilegi elevati e ho abilitato la nested virtualization con i comandi:

#Abilitazione della Nested Virtualization

Set-VMProcessor -VMName HV1 -ExposeVirtualizationExtensions 1

Set-VMProcessor -VMName HV2 -ExposeVirtualizationExtensions 1

Figura 3: Creazione sulla macchina Windows 10 delle due macchine virtuali che faranno da host Hyper-V

Ho installato Windows Server 2016 all’interno di HV1 ed HV2 e ho abilitato il ruolo di Hyper-V. È 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:

#Installazione del ruolo Hyper-V utilizzando PowerShell Direct

$cred = Get-Credential

Invoke-Command -VMName HV1 -Credential $cred -ScriptBlock {Install-WindowsFeature -Name hyper-v -IncludeManagementTools -Restart}

Invoke-Command -VMName HV2 -Credential $cred -ScriptBlock {Install-WindowsFeature -Name hyper-v -IncludeManagementTools -Restart}

Terminata l’installazione del ruolo ho provveduto a creare sullo storage locale dei due nodi Hyper-V due machine virtuali che utilizzerò come Domain controller e che ho chiamato DC1 e DC2. I due domain controller rimarranno ognuno assegnato al proprio nodo Hyper-v e verranno messi in esecuzione automatica, in modo tale che il dominio sia sempre disponibile. Poiché il servizio cluster dipende da Active Directory i due domain controller non verranno “clusterizzati”, ma rimarranno delle semplici macchine virtuali.

Figura 4: Due Domain controller annidati sugli Host virtuali HV1 ed HV2

Per far parlare tra di loro i due domain controller ho provveduto a creare sui due nodi HV1 ed HV2 un virtual switch di tipo External e successivamente ho abilitato sulle schede di rete di HV1 ed HV2 il MAC Address Spoofing dalle proprietà avanzate delle schede, in quanto le due macchine DC1 e DC2 stanno utilizzando la Nested Virtualization e senza abilitazione del MAC Address Spoofing i pacchetti di rete non riuscirebbero a superare i due Virtual Switch.

Figura 5: Abilitazione del MAC Address Spoofing

L’abilitazione del MAC Address Spoofing si può effettuare anche da PowerShell usando il comando:

1 2	#Abilitazione del MAC Address Spoofing Get-VMNetworkAdapter -VMName HV1,HV2 \| Set-VMNetworkAdapter -MacAddressSpoofing On

Dopo aver creato il dominio su DC1 e aver aggiunto DC2 come domain controller aggiuntivo, ho provveduto ad aggiungere al dominio anche i nodi HV1 ed HV2. Ho configurato anche le virtual machine DC1 e DC2 in modo tale che possano partire automaticamente quando parte l’host di virtualizzazione.

Figura 6: Autostart dei due Domanin controller DC1 e DC2

Abilitazione delle funzionalità di Storage Spaces Direct

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

Drive types present	Minimum number required
All NVMe (same model)	4 NVMe
All SSD (same model)	4 SSD
NVMe + SSD	2 NVMe + 4 SSD
NVMe + HDD	2 NVMe + 4 HDD
SSD + HDD	2 SSD + 4 HDD
NVMe + SSD + HDD	2 NVMe + 4 Others

Per questo motivo ho aggiunto ad entrambi i nodi HV1 ed HV2 4 dischi da 512 GB. Per semplicità ho effettuato l’operazione lanciando dalla macchina fisica con Windows 10 eseguendo le seguenti cmdlet:

#Aggiunta dei dischi alla macchina HV1

1..4 | % { New-VHD -Path "C:\LAB\HV1\Virtual Hard Disks\DISCO$_.VHDX" -Dynamic –Size 512GB}

1..4 | % { Add-VMHardDiskDrive -VMName HV1 -ControllerType SCSI -Path "C:\LAB\HV1\Virtual Hard Disks\DISCO$_.VHDX" }

#Aggiunta dei dischi alla macchina HV2

1..4 | % { New-VHD -Path "C:\LAB\HV2\Virtual Hard Disks\DISCO$_.VHDX" -Dynamic –Size 512GB}

1..4 | % { Add-VMHardDiskDrive -VMName HV2 -ControllerType SCSI -Path "C:\LAB\HV2\Virtual Hard Disks\DISCO$_.VHDX" }

Una volta che i dischi sono stati aggiunti sarà possibile utilizzarli per attivare la funzionalità di Storage Spaces Direct. Ho installato su entrambi i nodi HV1 ed HV2 la feature di Failover Clustering e terminata l’operazione di installazione ho aperto un prompt di PowerShell con privilegi elevati su uno dei due nodi ed ho effettuato un test per verificare se fosse possibile configurare il cluster ed utilizzare S2D eseguendo la cmdlet:

1 2	#Test della configurazione dei nodi che formeranno il Cluster Test-Cluster –Node HV1,HV2 –Include "Storage Spaces Direct", Inventory, Network, "System Configuration"

Figura 7: Test della configurazione dei nodi che formeranno il Cluster

Se tutti i test sono andati a buon fine e non avete ricevuto errori potete procedere alla creazione del cluster. Non avendo ricevuto errori ho eseguito su uno dei nodi del cluster HV1 oppure HV2 la seguente cmdlet:

1 2	#Creazione di un nuovo cluster New-Cluster -Name S2DCluster -Node HV1,HV2 –NoStorage –StaticAddress 10.10.10.100

Figura 8: Creazione del Cluster S2DCluster

Al termine della creazione del cluster ho ricevuto un warning. Controllate il contenuto del report creato e verificate che, poiché abbiamo scelto di utilizzare solo 2 nodi e di non aggiungere nessuno storage condiviso al cluster, sarà necessario configurare un witness, come mostrato in figura:

Figura 9: warning presente nel report, riferito al quorum witness

Per questo laboratorio ho preferito usare una novità del cluster di Windows Server 2016: Il Cloud Witness. Aprendo la console Failover Cluster Manager su HV1 sarà infatti possibile cambiare la modalità di quorum selezionando il nome del cluster e scegliendo More Actions à Configure Cluster Quorum Settings…

Figura 10: Modifica della funzionalità di Quorum del Cluster

Ho seguito il wizard di configurazione ed ho inserito il nome dello Storage Account e la Primary Access Key del mio account di archiviazione di Microsoft Azure. Per maggiori informazioni sugli Azure Storage Account potete visitare il link https://docs.microsoft.com/en-us/azure/storage/storage-create-storage-account

Figura 11: configurazione del Cloud Witness

Dopo aver configurato tutto a dovere 🙂 ho ottenuto una situazione come quella mostrata nella figura sotto:

Figura 12: Creazione del Cluster completata

Storage Spaces Direct

Siamo pronti per abilitare la funzionalità di Storage Spaces Direct (S2D). Ho notato che sia in Hyper-V che in Microsoft Azure i dischi collegati alle macchine 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. Infatti lanciando la cmdlet su uno dei nodi del cluster

1 2	#Verifica dei dischi collegati Get-PhysicalDisk \| ? CanPool -EQ 1 \| FT FriendlyName, BusType, MediaType, Size

ottengo il seguente risultato:

Figura 13: verifica dei dischi collegati

Per ovviare a questo problema ho abilitato Storage Spaces Direct lanciando la seguente cmdlet su uno dei nodi del cluster:

1 2	#Abilitazione di Storage Spaces Direct Enable-ClusterS2D -CacheState Disabled -AutoConfig:0 -SkipEligibilityChecks

Rispondete Yes to All al prompt che vi apparirà, come mostrato in figura:

Figura 14: Abilitazione della funzionalità di Storage Spaces Direct

Terminata la configurazione del cluster potreste ricevere un messaggio di avviso, come mostrato in figura:

Figura 15: Abilitazione completata con warning

Se aprite il report potrete verificare che ci sarà soltanto l’avviso relativo ai dischi che non sono stati aggiunti al cluster, in quanto durante la creazione abbiamo specificato il parametro -SkipEligibilityChecks

Figura 16: Warning relativi ai dischi non aggiunti al cluster

Figura 17: Funzionalità S2D abilitata

Dopo aver abilitato la funzionalità di Storage Spaces Direct noterete che nella console del Failover Clustering sono apparsi 2 Enclosures, ognuno dei quali fa riferimento a ogni singolo nodo del cluster:

Figura 18: Enclosure con 1 dischi aggiunti al Cluster S2D

Il passaggio successivo consiste nel creare uno Storage Pool utilizzando i dischi che sono stati aggiunti al cluster attraverso gli Enclosure dei due nodi. Ho creato uno Storage Pool semplicemente eseguendo su uno dei due nodi HV1 oppure HV2 il comando:

1 2	#Creazione dello storage pool New-StoragePool -StorageSubSystemFriendlyName Cluster -FriendlyName S2D -ProvisioningTypeDefault Fixed -PhysicalDisk (Get-PhysicalDisk \| ? CanPool -eq $true)

Nel mio caso ho scelto di creare uno storage pool utilizzando tutti i dischi disponibili: il risultato è mostrato in figura:

Figura 19: Storage Pool creato con tutti i dischi disponibili

Siamo pronti ora per creare un nuovo volume (da 1 TB), formattarlo REFS e trasformarlo in un Cluster Shared Volume. All’interno del volume CSV andremo poi a salvare tutte le macchine virtuali che creeremo in seguito. Per farlo basta eseguire su uno dei nodi del cluster la cmdlet:

1 2	#Creazione del nuovo volume New-Volume -StoragePoolFriendlyName S2D* -FriendlyName VDisk01 -FileSystem CSVFS_REFS -Size 1TB

Il risultato ottenuto è quello mostrato in figura:

Figura 20: Volume da 1TB creato nel Cluster S2D

Se volete potete modificare il percorso predefiniti per il salvataggio delle macchine virtuali, eseguendo su uno dei due host HV1 oppure HV2 la seguente cmdlet:

#Modifica dei percorsi di deafult per il salvataggio delle VM

Set-VMHOST –Computername HV1,HV2 –Virtualharddiskpath 'C:\ClusterStorage\Volume1'

Set-VMHOST –Computername HV1,HV2 -VirtualMachinePath 'C:\ClusterStorage\Volume1'

Test del cluster Hyper-Convergente

Per testare il cluster basta utilizzare la console del Failover Cluster Manager per creare una nuova VM altamente disponibile. Ho lanciato il wizard di configurazione della nuova VM, ho inserito come percorso del salvataggio della VM il CSV creato prima e non ho avuto problemi a terminare le altre configurazioni.

Figura 21: Creazione della VM altamente disponibile

Terminato il wizard di configurazione avrete una VM altamente disponibile, che sarà visualizzata come ruolo del Cluster.

Figura 22: Nuova VM creata all’interno del cluster S2D

Provando a spegnere uno dei due nodi, nel mio caso ho spento il nodo chiamato HV2, il cluster continua a funzionare e la macchina virtuale rimane accesa.

Figura 23: Anche con un nodo spento la macchina continua a funzionare

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.

Per approfondire le configurazioni presentate in questo articolo potete visitare le pagine

Buon lavoro!

Nic