Una panoramica sul mondo della Sicurezza Informatica, del Networking, della Virtualizzazione e non solo. Blog particolarmente indicato per i reparti IT che comunque alterna articoli scritti per specialisti con articoli formulati con linguaggio semplice e comprensibile a tutti.

Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

giovedì 17 settembre 2015

VMWare 6.0 - Il Cluster

Nel precedente articolo abbiamo parlato genericamente del concetto di virtualizzazione. Oggi approfondiremo come le dinamiche cambiano quando gli host sono due o più.


Licenze

Tanto per iniziare, VMWare ha varie licenze e determinate funzionalità sono disponibili solo all'aumentare del livello di licenza acquistato.

In questo breve specchietto è riassunto tutto.


Se vogliamo interattività tra due o più host, allora parliamo in pratica della licenza Essential Plus o successive.


Architetture Hardware e Software

Un cluster minimale VMWare è formato da due host ed uno storage condiviso, ovvero visibile ad entrambi gli host simultaneamente (collegato tipicamente in SAS, FC, iSCSI o NFS, parleremo successivamente delle performance e delle architetture).



Al suo interno deve esserci una macchina virtuale di gestione (dalla versione 4 in poi non è necessario che sia un server fisico dedicato), chiamata VMWare vCenter con interfaccia web vSphere Client a bordo (normalmente è una macchina OpenSUSE customizzata, dedicata e pronta all'uso, scaricabile dal sito vmware).


vMotion e Storage vMotion

Quando parliamo di vMotion, ci riferiamo alla possibilità di spostare una macchina originariamente posizionata su un host fisico, su un altro di destinazione. E' evidente che questa operazione (prima della virtualizzazione assolutamente impensabile) sposta il carico elaborativo da un server fisico ad un altro. Nella fattispecie, viene spostato tutto (ram, cpu, etc..) tranne la parte di storage.

Lo Storage vMotion, invece e come si può facilmente intuire, è la medesima operazione ma che riguarda esclusivamente la parte dischi. Richiede una licenza almeno di tipo enterprise.



A parte l'evidente vantaggio di ridistribuire "a caldo" e senza alcun disservizio il carico di lavoro tra i server fisici, basti pensare ad uno scenario in cui uno dei server accenda il fatidico led ambra di errore hardware. Senza alcun disservizio possiamo spostare tutte le macchine sul server "sano" e spegnere quello guasto effettuando le operazioni manutentive necessarie.



HA (high availability)

Con il termine HA, nella versione 6, si intende la possibilità di automatizzare le operazioni di ripristino delle macchine virtuali il cui host fisico sia venuto a mancare.

Ipotizziamo che entrambi i nostri nodi abbiano 5 VM distinte cadauno, ed uno dei nostri due nodi esploda in mille pezzi in un assordante boato proveniente dal CED. Avendo abilitato la funzione di HA sul Cluster, il sistema riaccenderà le macchine virtuali sul nodo (o sui nodi) superstite.

Per la macchina equivale ad un'interruzione elettrica nell'alimentazione e, nel tempo di un riavvio, la macchina sarà nuovamente operativa.



Fault Tolerance

Se il tempo di un riavvio è comunque troppo per la nostra macchina virtuale, è possibile abilitare il Fault Tolerance. A differenza dell'HA esso duplica la macchina su due nodi mantenendoli costantemente allineati. In caso di fail di un server fisico, il sistema non dovrà riavviare la macchina su un nuovo nodo, ma semplicemente abilitare la parte di network e renderla attiva.


E' bene precisare che, a differenza della modalità HA, questa funzione è estremamente più impegnativa da un punto di vista di risorse. Il traffico di rete elevato (si consiglia di dedicare un'interfaccia vmkernel dedicata a questa funzione) e l'occupazione attiva di risorse su ogni nodo in cui la macchina è duplicata, unitamente ai costi di licenza necessari a sbloccarla, rendono questa funzionalità utilizzabile solo in scenari ove sia realmente necessaria ed indispensabile.



DRS

Il DRS è uno strumento estremamente interessante ma disponibile purtroppo solo con le licenze Enterprise.
Mediante il DRS, infatti, è possibile automatizzare lo spostamento di una macchina virtuale in base a dei criteri.

  • Load Balancing: il sistema può bilanciare il carico dei nodi assegnando a quelli più scarichi delle macchine che, invece, stanno mandando in sofferenza i nodi ove si trovano;
  • Affinità con macchine raggruppate: è possibile stabilire che due o più macchine stiano sempre preferibilmente insieme (ad esempio in caso di alto carico di rete tra le stesse);
  • Affinità con macchine separate: quando due macchine devono preferibilmente stare su nodi separati (ad esempio due controller di dominio è opportuno che non stiano sullo stesso hardware perchè nativamente svolgono funzioni di backup l'una all'altra)




Il DRS ha dei settaggi che lo possono rendere più conservativo o più aggressivo, in base a quanto si voglia far intervenire il bilanciatore di risorse.

Un'altra utile implementazione del sistema DRS riguarda il risparmio energetico. La funzionalità Power Management consente di stabilire degli orari di spegnimento e riaccensione (mediante Wake On Lan) degli host fisici al fine di ridurre i consumi energetici nei grandi CED. 

Immaginiamo di avere 40 nodi vmware e di osservare una riduzione del carico di lavoro dalle 20,00 alle 8,00 del 70%. Mediante il DRS Power Management è possibile, ad esempio ed in questo scenario ipotizzato, istruire il sistema a spegnere gradualmente i server fisici spostando le macchine affinchè rimanga acceso solo il 30% dei nodi. Dalle 7,00 in poi il sistema riaccenderà gradualmente i server (ribilanciando ovviamente anche le macchine virtuali) fin quando non raggiungerà la piena operatività e capacità elaborativa alle 8,00 del mattino.


Il consumo energetico viene, quindi, ridotto drasticamente e le risorse non vengono disperse o sprecate. Ad onor del vero va detto che, per ripagarsi del costo della licenza, è necessario avere davvero molti nodi.





Nel prossimo articolo parleremo di storage, performance e modalità di collegamento, perchè sottodimensionare lo storage di un'infrastruttura virtuale è davvero un attimo ed è un errore particolarmente comune.