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.

mercoledì 16 settembre 2015

VMWare 6.0 - Panoramica sulla virtualizzazione

Con questo articolo inizia la "saga di vmware", ovvero una serie di articoli ad approfondimento progressivo con l'obiettivo di esplorare la virtualizzazione mediante VMWare 6.

I primi articoli saranno molto elementari, quindi mi scuso fin d'ora se gli argomenti trattati potranno risultare banali e consiglio di saltare questa parte a chi ha dimestichezza con l'argomento. Man mano che ci addentreremo, parleremo di Cluster Balancing, di DRS con gestione intelligente del consumo energetico (spegnimento notturno ed automatizzato di host), di HA e di storage performance (iSCSI, SAS, FC, NFS, etc.), nonchè di sistemi di backup e di gestione centralizzata mediante i tool a disposizione del la piattaforma vSphere. 


Iniziamo dal principio: cosa si intende per virtualizzazione?


Partiamo dall'inizio. In passato l'assioma Server Fisico <---> Sistema Operativo era indissolubilmente univoco. Ad ogni macchina fisica corrispondeva un sistema operativo. I più virtuosi amavano differenziare i ruoli, ma questo comportava la proliferazione di tanti (spesso piccoli e poco affidabili) server fisici nel proprio CED.


In questo scenario sono evidenti alcuni limiti:
  • Le risorse sono spesso sprecate, normalmente le macchine rimangono "a riposo" per la maggior parte del tempo
  • Il consumo energetico è significativo
  • Gli spazi nei CED iniziano a diventare un problema
  • La manutenzione di tanti piccoli server è molto problematica (ricambi, garanzie, architetture ridondate, etc)
  • I backup sono spesso di difficile gestione in architetture frammentate

Da qualche anno vmware (seguito a ruota da altri attori) ha rivoluzionato il mondo dell'hardware rendendo possibile quello che in passato era considerato solo un miraggio (o si faceva con artifizi davvero orrendi), ovvero astrarre (virtualizzare) la parte fisica del server e renderla disponibile a più macchine virtuali (sistemi operativi). Così facendo, le risorse di un server fisico (host) vanno in un contenitore che le metterà a disposizione (frazionandole) di tutte le macchine virtuali. Lo strato che astrae l'hardware (ovvero l'hypervisor), nel nostro caso si chiama ESXi.



Facciamo l'esempio della RAM: sul mio server fisico ho 64Gb, potrò disporre quindi di allocarne 4 per la macchina Windows che fa da Controller di Dominio, 8 per quella che fa da FileServer ed altri 4 per il WebServer. Così anche per la porzione disco, per i core del processore (che in questo caso vengono condivisi tra le macchine portando il concetto di "frazionamento" verso quello di "priorità" di accesso alla risorsa) e così via.



In buona sostanza, le risorse hardware possono essere suddivise ed allocate alle singole macchine in maniera granulare, ed un singolo server fisico sarà in grado di far girare N sistemi operativi differenti, detti anche Macchine Virtuali.


All'interno del software di controllo, chiamato anche vSphere Client (per il singolo server), sarà possibile comandare le singole macchine, vederne l'output video (come se ci fosse un monitor collegato) e assegnare loro le periferiche usb connesse al sistema fisico.



I vantaggi sono palesi, basti pensare alla possibilità di assegnare più RAM ad un sistema operativo con un solo click.



Intendiamoci, sto banalizzando, lo scopo di questo articolo è introdurre il neofita a concetti nuovi. La semplificazione è dovuta.


A questo punto, ho acquistato un singolo server particolarmente robusto da un punto di vista di performance e ridondanza (dimensionato opportunamente ed in grado quindi di reggere il precedente carico di tutte le macchine), ed ho consolidato il mio CED virtualizzando (o ricreando ex novo) le macchine che originariamente erano fisiche in "contenitori virtuali" in esecuzione sul mio nuovo hardware. La virtualizzazione può avvenire mediante il tool apposito chiamato VMWare vCenter Converter Standalone.



Nel prossimo articolo parleremo di Cluster e di cosa è possibile fare quando gli host sono due o più, introducendoci al rivoluzionario mondo del vMotion: ovvero la possibilità di spostare "a caldo" le macchine da un server fisico ad un altro, senza creare alcun disservizio.