La tecnologia va avanti alla velocità della luce e non sempre riusciamo a starle dietro specie se non riusciamo a comprendere appieno i reali vantaggi che può portare. È quindi importante conoscere bene i nuovi prodotti e le loro funzionalità così da poter sfruttare o meno i possibili benefici, o perlomeno per sapere che quella strada non fa per noi.
In ambito informatico, quando esce una nuova tecnologia o un nuovo software sento spesso domande del tipo: è il caso di cambiare? Quali sono i vantaggi che ho se faccio l’upgrade? E l’hardware vecchio, lo butto via? Microsoft come risposta a questo tipo di domande, già in Windows Server 2012 e maggiormente in 2012R2, è riuscita a portare funzionalità che fino ad ora erano pensati per realtà molto grandi alla portata di tutti. Si pensi alle tantissime novità, presenti negl’ultimi Sistemi Operativi Server, in ambito storage, virtualizzazione e networking.
In questo articolo vedremo cosa ci serve per costruire un cluster sfruttando principalmente gli strumenti nativi di Windows Server 2012R2 e Hyper-V, come mettere in alta disponibilità le macchine virtuali e i reali benefici di questa tecnologia.
Definizione di Failover Cluster
Cerchiamo intanto di definire cosa è un Failover Cluster. Un Failover Cluster è un gruppo di computer indipendenti che lavorano insieme per aumentare la disponibilità e la scalabilità di applicazioni e servizi in cluster (da ora chiamati ruoli cluster). I server in cluster (denominati nodi) sono connessi tra di loro mediante cavi fisici e dal software, come mostra la figura 1.
Figura 1 – Cluster Schema
Se uno o più dei nodi del cluster non funzionano gli altri nodi cominciano a erogare il servizio, un processo noto proprio con il nome di failover. Inoltre, i ruoli del cluster sono continuamente e costantemente monitorati per verificare che funzionino correttamente e per qualsiasi motivo non dovessero funzionare, vengono riavviati o spostati in un altro nodo.
Ci sono una serie di innegabili vantaggi a chi decide di implementare un failover cluster, primo tra tutti è l’elevata disponibilità e business continuity per applicazioni business critical, quali Microsoft SQL Server, Microsoft Exchange e macchine virtuali in esecuzione su Hyper-V.
Con Windows Server 2012 R2, Microsoft supporta di failover cluster fino a 64 nodi fisici, ed una scalabilità fino a 8.000 macchine virtuali in esecuzione contemporaneamente. È importante notare, però, che Hyper-V in Windows Server 2012 R2 supporta 1.024 macchine virtuali per host, quindi non è necessario la serie completa di 64 nodi per raggiungere gli 8.000 VM per cluster. È possibile gestire il failover cluster utilizzando lo snap-in Failover Cluster Manager o le cmdlet clustering di failover di Windows PowerShell. In Windows Server 2012 R2, grazie al cruscotto della nuova Dashboard Cluster avanzata, è possibile visualizzare rapidamente lo stato di salute di tutti i failover cluster gestiti, con un’icona che indica se il cluster è in esecuzione, il numero di ruoli cluster, lo stato del nodo, e lo stato dell’eventi delle ultime 24 ore.
Per chi utilizza SAN come soluzione di storage condiviso, si consiglia di presentare una LUN della SAN, per ogni nodo del cluster, e abilitare tali LUN come Cluster Shared Volumes.
Cluster Shared Volumes
Abbiamo parlato di cluster shared volumes, cerchiamo di capire un po’ meglio di cosa si tratta. Il Cluster Shared Volumes (CSV) in un Failover cluster di Windows Server 2012 R2 consente a più nodi del cluster di avere simultaneamente accesso in lettura e scrittura sulla stessa LUN (disco), che viene presentata come un volume NTFS. Con il CSV, i ruoli cluster possono eseguire il failover rapidamente da un nodo a un altro nodo senza richiedere un cambio di proprietà, o lo smontaggio e rimontaggio di un volume.
Le applicazioni CSV includono:
- Cluster di virtual hard disk (VHD) per clusterizzare le macchine virtuali in Hyper-V
- Scale-out file share per archiviare i dati delle applicazioni con il ruolo di Scale-Out File Server.
Funzionamento di un Cluster
Ma come funziona un Failover Clustering? Dal punto di vista della virtualizzazione, il Failover Clustering fornisce ad una VM un elevata disponibilità.
Supponiamo di avere un host fisico in failure, le macchine virtuali in esecuzione su tale host sarebbero ovviamente anche ferme. A seconda della situazione questo blocco repentino e violento della VM rischierebbe di avrebbe tempi molto alti di fermo. Tuttavia, se tale nodo fisico fa parte di un cluster, i nodi rimanenti del cluster sarebbero in grado di sopperire al nodo in failure e coordinare rapidamente la riaccensione della VM, su altri nodi disponibili nel cluster; questo in maniera totalmente automatica e senza intervento del personale IT. Questo assicura che i carichi di lavoro in esecuzione su un cluster, abbiano un più alto livello di disponibilità di quelli in esecuzione su server fisici in standalone.
In Windows Server 2008 R2 e versioni precedenti, era necessario che le macchine virtuali in esecuzione su un cluster dovevano essere collocate su di uno storage condiviso, ovvero una SAN, iSCSI o FC. In Windows Server 2012 e, successivamente, di Windows Server 2012 R2, un Failover Cluster supporta l’immissione delle macchine virtuali in una shar condivisa, accessibile utilizzando il protocollo SMB 3.0, e quindi attraverso la rete. Questo fornisce agli amministratori maggiore flessibilità quando si effettua un nuovo deploy di un’infrastruttura.
Cluster Quorum e Dynamic Quorum
Non si può parlare di cluster senza parlare del quorum. Il quorum, figura 2, per un cluster è determinato dal numero complessivo dei membri attivi che costituiscono il cluster e che permettono al quel cluster di avviarsi correttamente o di continuare l’esecuzione. Come regola generale, quando si configura un quorum, gli elementi di voto nel cluster dovrebbe essere un numero dispari. Tradizionalmente, ogni nodo del cluster dispone di un voto, pertanto, se il cluster contiene un numero di nodi pari, è necessario configurare un testimone (Witness) che può essere, ad esempio, lo storage.
Figura 2 – Quorum Schema
In questo modo il cluster sarà così in grado di sostenere il crash di uno o più nodi consentendo di continuare a erogare il servizio anche se la metà dei nodi del cluster vanno contemporaneamente in down o vengano scollegati. Per aumentare l’elevata disponibilità del cluster, e i ruoli che sono ospitati su quel cluster, è importante impostare la configurazione quorum del cluster in modo appropriato. La configurazione quorum cluster ha un effetto diretto sulla disponibilità elevata del cluster, in quanto aiuta a garantire che il failover cluster possa avviarsi correttamente o continuare a funzionare nel caso ci fossero dei problemi o interruzioni, pianificata o no, da parte di qualche nodo.
Tenere presente che la funzione completa di un cluster oltre che dal quorum dipende dai seguenti fattori:
- La connettività di rete tra i nodi del cluster
- La capacità di ogni nodo per ospitare i ruoli cluster che vengono immessi sul nodo
- Le impostazioni di priorità che sono configurate per i ruoli cluster
Ad esempio, un cluster che ha cinque nodi può continuare ad avere il quorum anche dopo che due nodi sono andati in failure. Tuttavia, ogni nodo rimanente dovrebbe essere in grado di sostenere i ruoli cluster per continuare a erogare il servizio ai client.
Quorum Gestione Dinamica
Già in Windows Server 2012, come opzione di configurazione quorum avanzata, era possibile scegliere di attivare una gestione dinamica quorum del cluster. Quando questa opzione è attivata, il cluster gestisce dinamicamente l’assegnazione voto di nodi, in base allo stato di ciascun nodo. I voti vengono automaticamente rimossi dai nodi che lasciano il cluster attivo, e il voto viene assegnato automaticamente quando un nodo si ricollega al cluster. Per impostazione predefinita, la gestione quorum dinamica è abilitata.
Nota: Con la gestione dinamica quorum, il cluster quorum di maggioranza è determinata dalla serie di nodi che sono membri attivi del gruppo in qualsiasi momento. Questa è una distinzione importante dal quorum del cluster in Windows Server 2008 R2, in cui era fissato come «quorum di maggioranza», in base alla configurazione iniziale del cluster.
Dynamic Witness
In Windows Server 2012 R2, se il cluster è configurato per utilizzare quorum dinamica (impostazione predefinita), il voto testimone è anche regolato dinamicamente in base al numero di nodi di voto dei membri del cluster corrente. Se ci sono un numero dispari di voti, il testimone quorum non dispone di un voto. Se c’è un numero pari di voti, il testimone quorum ha un voto.
Cluster Active Directory Indipendente
Un’altra importante novità in Windows Server 2012 R2, è la possibilità di distribuire un failover cluster senza avere dipendenze di servizi di dominio Active Directory (AD DS) per i nomi di rete. Questo è indicato come un cluster Active Directory-indipendente. Quando si distribuisce un cluster utilizzando questo metodo, il nome della rete di cluster e nomi di rete per tutti i ruoli cluster sono registrati nel Domain Name System (DNS).
Nota: i nodi del cluster devono ancora essere uniti a un dominio Active Directory
Con questo metodo di distribuzione, è possibile creare un Failover cluster senza le autorizzazioni precedentemente necessarie per creare oggetti computer in Active Directory o la necessità di richiedere che un amministratore di Active Directory debba pre-inserire gli oggetti computer in Active Directory. Ad esempio, è possibile evitare l’eventuale problema in cui un amministratore di Active Directory elimina accidentalmente l’oggetto computer cluster, che incide la disponibilità dei carichi di lavoro del cluster.
L’opzione per creare un cluster Active Directory di default non era disponibile in Windows Server 2012. In Windows Server 2012, è possibile distribuire solo un Failover cluster in cui i nomi di rete per il cluster sono sia DNS e Active Directory. In Windows Server 2012 e Windows Server 2012 R2 i cluster hanno anche la capacità di “partire” senza dipendenze AD DS, il che si traduce in una maggiore flessibilità per i data center con i controller di dominio virtualizzati in esecuzione sul cluster.
VM Drain
In Windows Server 2012, se si arresta un nodo di cluster senza prima migrare le risorse dal nodo, le macchine virtuali vengono messi in uno stato salvato, e poi spostati in altri nodi e riprese. Ciò significa che ci sarà ovviamente una interruzione alla disponibilità delle macchine virtuali. Se ci vuole troppo tempo per salvare lo stato delle macchine virtuali, possono essere spenti, e poi riavviati su un altro nodo. In Windows Server 2012 R2 tuttavia, il cluster migra automaticamente in tempo reale tutte le macchine virtuali in esecuzione prima dello spegnimento.
Questa modifica prevede un meccanismo di sicurezza per contribuire a garantire che un arresto del server (o qualsiasi azione che chiude il Servizio cluster) non causa i tempi di inattività non pianificati per l’esecuzione di macchine virtuali. Questo aumenta la disponibilità delle applicazioni che vengono eseguite all’interno del sistema operativo guest.
Rilevamento Salute VM Network
In Windows Server 2012, se c’era una disconnessione dalla rete a livello di macchina virtuale, la macchina virtuale continua l’esecuzione su quel computer anche se la VM non è disponibile agli utenti. In Windows Server 2012 R2, vi è ora un’opzione di controllo abilitabile sulla VM. Se capita una disconnessione dalla rete della VM quest’ultima verrà migrata. Questa impostazione è disponibile nelle funzioni avanzate della scheda di rete. Per impostazione predefinita, l’impostazione è attivata.
Deploy di un Cluster
Vediamo adesso quali sono i principali step per costruire un cluster. Beh, in primo luogo, è necessario un qualche tipo, storage condiviso.
Nelle versioni precedenti di Hyper-V, l’unico modo per costruire un cluster di failover, è quello di utilizzare storage condiviso, Fibre Channel o iSCSI. In Windows Server 2012, si ha anche la possibilità di utilizzare condivisioni di file SMB come storage centralizzato per Hyper-V cluster, fornendo un basso costo, soluzione semplificata per la costruzione di un cluster Hyper-V.
Una volta che abbiamo il nostro storage condiviso, abbiamo bisogno di trasformare alcuni host Hyper-V, in nodi del cluster. Per trasformare un normale host Hyper-V in un nodo di cluster, è necessario prima attivare la funzionalità cluster di failover, che viene attivato tramite Server Manager.
Networking
Una volta attivata la funzionalità cluster di failover, abbiamo bisogno di configurare la nostra rete tra gli host e, facoltativamente, se si utilizza iSCSI o di archiviazione SMB, le nostre reti di storage. Ci sono un paio di considerazioni importanti quando si parla di networking.
Quello che è importante è che abbiamo bisogno di reti isolate. Quali sono i diversi tipi di reti?
- Host Management: Usata per gestire l’host Hyper-V attraverso RDP, Hyper-V Manager, Virtual Machine Manager etc.
- VM Access: È la NIC dedicata sui nodi per la rete delle VM
- Live Migration: Network dedicate al traffic della live migration
- Cluster Shared Volumes: Rete usata dal Cluster per comunicare la salute del cluster stesso. Inoltre, è anche utilizzata da Cluster Shared Volumes per inviare dati tra l’owner e il non-owner dei nodi. Se l’accesso allo storage è interrotto, questa rete è usata per accedere al CSV per backup o fare Mantenance
- Storage (Optional): Rete usata per la comunicazione tra l’host e lo storage iSCSI o SMB
Deploy con Virtual Machine Manager – VMM
Con System Center Virtual Machine Manager è possibile gestire tutte le funzionalità di Clustering che abbiamo visto precedentemente, e che permettono all’amministratore IT di costruire e configurare il cluster direttamente dall’interfaccia di gestione di base. Il primo punto fondamentale da sapere, quando si costruisce un cluster, è che i nodi si desidera aggiungere, devono essere già gestiti da VMM. Una volta aggiunti, saranno disponibili per la selezione come un nodo del cluster.
Dopo aver selezionato i nodi, sarete anche in grado di scegliere se si desidera eseguire la convalida, per garantire che si sta costruendo un’infrastruttura resiliente e, soprattutto, che il tutto sia supportato. Una volta selezionati i nodi, è possibile configurare il sistema di storage. VMM presenterà archiviazione remota che è stata presentata a tale nodo, come fosse quello presentato da un iSCSI SAN. È possibile scegliere di formattare, assegnare nomi, e anche convertire in formato CSV, il tutto con la procedura guidata.
Con VMM si potranno creare anche le reti. Questo ci aiuta a semplificare la creazione di cluster e la standardizzazione di tutti i nodi all’interno del cluster.
Failover Priority, Affinity and Anti-Affinity
Parliamo ora di alcune nuove funzionalità molto interessanti: Failover Priority, Affinity and Anti-Affinity:
Priority
La Priority in Windows Server 2012, e successivamente, Windows Server 2012 R2, fornisce una nuova funzionalità che permette all’amministratore di definire l’ordine di avvio delle macchine virtuali in esecuzione su quel cluster, in modo che in caso di guasto, alcune VM avranno la priorità rispetto ad altre, a seconda delle impostazioni scelte. Questa funzionalità consente agli amministratori di garantire che quando le risorse sono limitate sul failover, la VM più importante inizierà prima di ottenere le risorse di cui hanno bisogno, prima di avviare altre, meno importanti VM.
Affinity (and Anti-Affinity)
Gli amministratori possono ora configurare macchine virtuali partner affinché in caso di failover, queste vengano migrate simultaneamente. Ad esempio, gli amministratori possono configurare la macchina virtuale di SharePoint e la macchina virtuale SQL Server come partner per gestirne sempre il failover insieme allo stesso nodo. Gli amministratori possono anche specificare che due macchine virtuali non possono coesistere sullo stesso nodo in uno scenario di failover.
VM Monitoring
È ora possibile monitorare non solo la salute dell’host Hyper-V ma anche delle VM presenti in un cluster, inoltre posso decidere di intraprendere delle azioni specifiche al susseguirsi di eventi, figura 4. Ad esempio posso far riavviare una macchina Virtuale quando per tre volte si è fermato un determinato servizio.
Figura 3 – VM Monitoring
Quando il servizio cluster determina che una macchina virtuale è in uno stato “critico, cioè un’applicazione o un servizio all’interno della macchina virtuale è in uno stato malsano, richiede le seguenti azioni di recupero:
- Event ID 1250 is logged on the host – this could be monitored by a centralized monitoring solution such as System Center Operations Manager
- The virtual machine status in Failover cluster Manager will indicate that the virtual machine is in an “Application Critical” state”
Gestire i Carichi di Lavoro
Come gestiamo, invece, i cambi di carichi dinamici di lavoro. Come tutti sappiamo, il workload cambia a seconda di molti fattori (ora del giorno / mese, la domanda, stagionalità, ecc) ed è necessario regolare i carichi di lavoro in modo efficace, se non si vuole stare lì a guardare tutto il tempo. Con System Center è facilissimo, infatti VMM si accorge quando i carichi di lavoro su un particolare hypervisor passano una determinata soglia e regola automaticamente la distribuzione delle VM.
Con ottimizzazione dinamica, VMM esamina una serie di parametri; CPU, memoria, disco e rete IO IO e quando l’utilizzo delle risorse va al di sopra della soglia di ottimizzazione, VMM orchestra migrazioni live delle macchine virtuali, e bilanciando di conseguenza l’utilizzo delle risorse. Ottimizzazione dinamica può essere utilizzato non solo con Hyper-V, ma in sostituzione di DRS in un ambiente VMware, e anche come un valore aggiunto in un ambiente XenServer, contribuendo a mantenere ciascun ambiente operativo efficiente e utilizzare le risorse in modo ottimizzato.Con la Dynamic Optimization abilitata, l’amministratore IT ha anche la possibilità di attivare, su un programma, Potere di ottimizzazione, che, come mostra il diagramma, quando l’utilizzo delle risorse dei padroni di casa scende sotto la soglia di ottimizzazione, VMM si sposterà le macchine virtuali su un numero inferiore padroni di casa , liberando gli host che possono poi essere spento. I padroni di casa dovrebbero essere gestiti tramite il BMC, in modo che VMM può orchestrare il loro risveglio al momento sia un utilizzo di risorse maggiore, o in un momento pianificato when Power Optimization non dovrebbe più essere in funzione.
Patching
Per quanto riguarda il patching VMM 2012 R2 può essere integrato con un Windows Server Update Services (WSUS) 3.0 Server SP2 e andrà ad orchestrare la gestione del patching sui nodi del cluster, figura 4. Farà inoltre la migrazione di VM in altri host del cluster per aggiornare il nodo e ripeterà il processo sull’host successivo fino a quando l’intero cluster è up-to-date.
Figura 4 – Patching con VMM
Comparazione con VMWare
La figura 5 mostra come sia Hyper-V e vSphere Enterprise Plus offrono elevati livelli di disponibilità e resilienza in the box, ma la scalabilità di un cluster Hyper-V offre è superiore a vSphere, con il supporto di solo la metà del numero di nodi, e VM per cluster.
Figura 5 – Comparazione Hypervisor
Inoltre l’Hypervisor vSphere, la versione gratuita, non ha alcuna capacità di clustering – i clienti devono acquistare un vSphere Enterprise per ottenere questa funzionalità, a differenza di Hyper-V Server, che, è un prodotto totalmente gratuito.
Guest Clustering
Con Hyper-V in Windows Server 2012, Microsoft fornisce il supporto completo per la clusterizzzione delle macchine virtuali, a livello di sistema operativo guest. Un esempio potrebbe essere una configurazione cluster SQL Always On. In questo esempio, figura 5, abbiamo un cluster formato da 3 nodi fisici, e sopra, abbiamo 2 VM Guest in Cluster, entrambi hanno accesso diretto ad una qualche forma di storage condiviso.
Questa configurazione cluster di VM Guest, come detto in precedenza, è pienamente supportata da Microsoft, e in aggiunta, può essere combinato con caratteristiche come Live Migration, e Dynamic Memory. Il vantaggio di un cluster di VM, è il secondo livello di resilienza.In una situazione in cui un nodo fisico va in failure, e le VM su di esso sono anche andate giù, il cluster Hyper-V fisico assicura che le VM si riavviino rapidamente su un nodo diverso e la resilienza a livello di applicazione assicura che l’applicazione o il carico di lavoro rimanga attiva.
In Windows Server 2012 R2, è ora possibile condividere un file nel formato di file VHDX tra più macchine virtuali: è possibile utilizzare questi file per la memorizzazione condivisa per un failover cluster della macchina virtuale. Il bello è che quando si configura una macchina virtuale per utilizzare un file VHDX condiviso, non è necessario apportare modifiche di configurazione di archiviazione quali zoning e LUN masking.
Utilizzo di un disco rigido virtuale condiviso è l’ideale per le seguenti situazioni:
- File di database di SQL Server
- Servizi di file server in esecuzione all’interno di una macchina virtuale
- I file di database che risiedono su dischi condivisi
Un Failover Cluster Guest di Hyper-V, che utilizza un disco rigido virtuale condiviso, ha due modelli di distribuzione preferite. Il disco rigido virtuale condiviso per il Failover Cluster ospite può essere distribuito su:
- Cluster Shared Volumes (CSVs) on block storage (including Clustered Storage Spaces)
- Scale-Out File Server with SMB 3.0 on file-based storage