Cluster VMware vs cluster Microsoft

In questo post verranno trattati i vantaggi di implementare un cluster Microsoft e quelli invece di un cluster VMware vSphere. Un cluster Microsoft ha il vantaggio che sono monitorate le applicazioni all’interno del sistema operativo, ad esempio SQL Server: se l’applicazione su uno dei nodi del cluster ha un crash, subentra immediatamente l’istanza sull’altro nodo in modo da garantire continuità di servizio. Nel caso di VMware invece può essere configurato un cluster con la Fault Tolerance (FT), la funzionalità che meglio si avvicina a MSCS. […]

In questo post verranno trattati i vantaggi di implementare un cluster Microsoft e quelli invece di un cluster VMware vSphere.

cluster

Un cluster Microsoft ha il vantaggio che sono monitorate le applicazioni all’interno del sistema operativo, ad esempio SQL Server: se l’applicazione su uno dei nodi del cluster ha un crash, subentra immediatamente l’istanza sull’altro nodo in modo da garantire continuità di servizio. Nel caso di VMware invece può essere configurato un cluster con la Fault Tolerance (FT), la funzionalità che meglio si avvicina a MSCS. Con la FT attiva VMware garantisce la continuità di esecuzione di una VM, ma non delle singole applicazioni all’intero della VM:

  1. se il nodo che ospita la VM ha un malfunzionamento, una VM identica già attiva e avviata entrerà in funzione, garantendo zero disservizio;
  2. se il nodo che ospita la VM funziona correttamente ma ha un crash un’applicazione interna alla VM (un database, un server web, …), la FT non è in grado di effettuare alcun azione e il servizio non verrà più erogato.

Dunque nella scelta tra MSCS e VMware deve essere tenuto in considerazione il livello di protezione garantito, che è maggiore con MSCS ma con lo svantaggio di costi maggiori e di un maggior livello di complessità. Con MSCS infatti devono essere configurati singolarmente i nodi del cluster, così come devono essere configurati disco di quorum e RDM. In VMware invece la configurazione del cluster è molto più semplice ed intuitiva, e viene fatta interamente attraverso vCenter Server, il quale si occuperà sia di monitorare le VM sia di eseguire le azioni opportune in caso di crash. In definitiva, MSCS è da preferire per applicazioni mission-critical, come un database, in cui un disservizio anche minimo può causare notevoli problemi, mentre per altri tipi di servizi, come server DHCP, DNS, o anche server web, un cluster con VMware FT (o eventualmente HA se può essere tollerato un disservizio di alcuni minuti) offre una protezione più che adeguata.

L’alternativa è quella di ricorrere ad un cluster Microsoft direttamente all’interno di un cluster VMware, in modo da unire i benefici della virtualizzazione ad una continuità di servizio 24h/24 per le applicazioni più critiche. Inoltre, si ha un ulteriore vantaggio, che consiste nella possibilità di “spostare” un’applicazione da una VM ad un’altra senza alcun disservizio, ad esempio se si deve effettuare qualche operazione di manutenzione. E’ da notare però che in questo caso sono supportati cluster solo di alcune versioni di Windows. Per maggiori dettagli consultare i collegamenti seguenti:

roghan

VMware HA e nodi isolati

Vedremo in questo post il comportamento di un cluster virtualizzato in cui è stata abilitata la funzionalità HA. Da ricordare che un cluster può essere configurato unicamente tramite un vCenter Server, che resta necessario per il corretto funzionamento di funzionalità quali vMotion e DRS, ma non per l’HA: se il vCenter Server si blocca o ha un guasto, l’HA è comunque garantita per tutti i nodi del cluster. […]

Vedremo in questo post il comportamento di un cluster virtualizzato con VMware in cui è stata abilitata la funzionalità HA. Da ricordare che un cluster può essere configurato unicamente tramite un vCenter Server, che resta necessario per il corretto funzionamento di funzionalità quali vMotion e DRS, ma non per l’HA: se il vCenter Server si blocca o ha un guasto, l’HA è comunque garantita per tutti i nodi del cluster.

ha_p2p
Interrogazione dei nodi in un cluster con HA

L’architettura di funzionamento su cui è basata l’HA è di tipo p2p, ossia ogni nodo effettua a intervalli regolari un ping verso ogni altro nodo del cluster e anche verso il gateway. I ping vengono effettuati dalla scheda di management di un nodo e verso la management di ogni altro nodo (Service Console nel caso di ESX e CLI di management per ESXi). Il funzionamento dell’HA è quindi strettamente legato al networking e alle schede di rete, e qualora la scheda di rete della management di un nodo si guasti il nodo stesso diventa isolato. Studiamo questo caso:

  1. ogni nodo controlla se ogni altro nodo è raggiungibile;
  2. se in un nodo si guasta la scheda di rete di management questo diventa isolato;
  3. di default, un nodo isolato spegne tutte le sua macchine virtuali.

Il comportamento di default potrebbe essere ragionevole nel caso in cui un nodo abbia schede di rete ridondate per la management, ma è in generale altamente consigliato cambiare l’impostazione default. Proviamo a immaginare cosa succederebbe se si guastasse uno switch fisico a cui sono collegati tutti i nodi e pure il gateway? Tutti i nodi risulterebbero isolati, con la conseguenza che ogni nodo spegnerebbe tutte le sue macchine virtuali! E’ una situazione assolutamente da evitare. Pertanto è necessario modificare l’impostazione host isolation response durante la configurazione del cluster, visibile alla schermata seguente:

ha_vcenter
Modificare impostazioni default

Riepilogando, è buona norma modificare il comportamento default di un cluster HA per quanto riguarda l’isolamento del nodo, ed inoltre è buona cosa ridondare la NIC di management.

roghan

E’ migliore ESXi embedded o installabile?

Premettendo che non ci sono differenze funzionali tra le due versioni, vediamo i vantaggi/svantaggi di entrambe:
ESXi embedded:
+ il sistema è già pronto per l’uso e non deve essere installato niente;
+ costi bassi (un flash drive USB costa meno di dischi in RAID);
– no ridondanza, al massimo può essere mantenuta una copia di backup del sistema su un altro drive USB;
– la qualità dei flash drive USB raramente è elevata;
– il sistema operativo risiede interamente su un dispositivo esterno USB (se qualcuno per ignoranza lo rimuove?!). […]

Premettendo che non ci sono differenze funzionali tra le due versioni, vediamo i vantaggi/svantaggi di entrambe:

ESXi embedded:
+  il sistema è già pronto per l’uso e non deve essere installato niente;
+  costi bassi (un flash drive USB costa meno di dischi in RAID);
–  no ridondanza, al massimo può essere mantenuta una copia di backup del sistema su un altro drive USB;
–  la qualità dei flash drive USB raramente è elevata;
–  il sistema operativo risiede interamente su un dispositivo esterno USB (se qualcuno per ignoranza lo rimuove?!).
esxi_embedded
ESXi installabile:
+  flessibilità nell’installazione e possibilità di personalizzazione;
+  alta disponibilità e ridondanza, i dischi su cui viene installato ESXi possono essere messi in RAID;
–  costi elevati.
Le due soluzioni sono invece sullo stesso livello per quanto riguarda le prestazioni così come per il tempo di deploy (ESXi embedded è già pronto all’uso, ma anche ESXi installabile richiede al massimo pochi minuti per essere installato e avviato).Personalmente preferisco la versione installabile :-), ma tuttavia anche la versione embedded funziona egregiamente.

roghan