VMware, i pregi di una struttura virtuale e prima implementazione

Pregi e difetti di una struttura basata sulla piattaforma di virtualizzazione VMware VMware e sempre stata considerata un'azienda leader del mercato per quanto concerne il campo della virtualizzazione. Nonostante gli "attacchi" di piattaforme alternative, sia open source, sia closed, i prodotti VMWare hanno continuato ad eccellere migliorando costantemente. La creazione di una struttura atta a virtualizzare ambienti operativi puo essere un affare cosi semplice da risultare banale con i prodotti di fascia Desktop di VMWare.

Pregi e difetti di una struttura basata sulla piattaforma di virtualizzazione VMware

VMware è sempre stata considerata un’azienda leader del mercato per quanto concerne il campo della virtualizzazione. Nonostante gli “attacchi” di piattaforme alternative, sia open source, sia closed, i prodotti VMWare hanno continuato ad eccellere migliorando costantemente. 

vmware_infrastructure.gif

La creazione di una struttura atta a virtualizzare ambienti operativi può essere un affare così semplice da risultare banale con i prodotti di fascia Desktop di VMWare. Un deploy di virtual machine può diventare un obiettivo più complesso, soprattutto se decidiamo di utilizzare prodotti di fascia server con strutture dedicate anche piuttosto complesse.

A grandi linee, si possono suddividere i prodotti di fascia alta in due:

VMware Virtual Infrastructure e VMware Server.

Le varianti ed i componenti opzionali sono molti, ma la più grande differenza tra i due è il differente target su cui si vanno a posizionare. Mentre Infrastructure è una piattaforma completa per virtualizzare a qualsiasi livello operativo aziendale, la versione Server che è gratuita (ma non open source come si sente spesso erroneamente citare) è atta a deploy più piccoli e prettamente per virtual machine da dedicare ad ambienti di sviluppo e test.

Tale assunto è confermato dal fatto che, genericamente, i “Tools” VMWare esistoo per molte più tipologie di sistemi operativi nella versione Server, mentre, in Virtual Infrastructure, si punta alla maggiore stabilità e i sistemi operativi supportati sono meno.

Fatto questo doveroso preambolo, cercheremo di incentrare il discorso su strutture di livello Enterprise (piuttosto rare in Italia) che sono il miglior ambiente in cui la virtualizzazione VMWare, con Virtual Infrastructure, può dare il meglio di sé (ed anche essere messa maggiormente alla frusta).

Questo articolo è offerto da Noamweb

La Noamweb nasce nel 2001 specializzandosi in soluzioni di hosting, housing e registrazione domini per professionisti del settore, quali programmatori, webmaster, SEO e rivenditori, mettendo a loro disposizione attrezzature di altissima qualità, e offrendo una vasta gamma di servizi studiati appositamente per le loro esigenze.

Quale hardware usare per VMware?

Quale hardware usare per VMware?

Il primo ostacolo importante è la scelta dell’hardware. Nonostante molti credano che sia possibile utilizzare qualsiasi sorta di server basato su architettura x86, le cose sono più complesse. Prima di tutto VMware rilascia una lista dell’hardware certificato da cui è sconsigliato uscire nel modo più assoluto.

Ricordiamo che un problema generalizzato su una struttura che contiene centinaia di server virtuali, può essere davvero un evento difficile da gestire, meglio quindi mantenere un approccio conservativo.

Il discorso è ancora di più difficile discernimento quando entrano in gioco le unità di storage in Fiber Channel per le quali scegliere una scheda non supportata potrebbe compromettere seriamente la stabilità generale della struttura.

Ho escluso volutamente sistemi iScsi dal discorso per vari motivi. Prima di tutto c’è il discorso prestazionale, per cui, tale protocollo è assolutamente inadeguato. So che questa mia affermazione potrebbe risultare impopolare, ma posso garantire di aver visto situazioni in cui il traffico di I/O era ben al di sotto dei limiti teorici di tale tecnologia ed i problemi iniziavano già a diventare insostenibili. Uno storage che basa le sue comunicazioni su Fiber Channel è sicuramente un costo notevolmente maggiore, ma vale ogni singolo centesimo speso in più in un’architettura dove il punto critico sarà sempre la comunicazione con i dischi proprio per la natura stessa dell’ambito di virtualizzazione.

Per quanto riguarda i server che dovranno reggere la struttura, è necessario che questi siano il più omogenei possibile, soprattutto per quanto riguarda marchio e tipologia di processore per ovvi motivi: è fisicamente impossibile migrare un virtual machina da un processore all’altro “a caldo”, mentre è possibile farlo “a freddo” ma con potenziali problemi di kernel al riavvio.

Una tipologia di server che ha preso piede a “fasi alterne” nelle farm dove si fa largo uso di VMWare Vitual Infrastructure sono i “blade” server. Hanno una compattezza invidiabile e permettono la gestione degli switch in fibra come moduli dello chassis facendo risparmiare molto spazio e facilitando la manutenzione tramite un’interfaccia centralizzata di gestione. Purtroppo la contropartita non è trascurabile, infatti il costo è notevolmente più alto a parità di potenza di calcolo rispetto ad una soluzione tradizionale. Problema non secondario è il notevole consumo energetivo in rapporto alle poche unità spese per cui molte farm non riescono ad attrezzare i rack.

Non ultimo, sono necessari speso e volentieri rack cabinet particolarmente adatti ad aspirare velocemente l’aria calda poiché, ovviamente, uno chassis blade sprigiona una quantità di calore notevole.

La preparazione dei dischi per VMware

La preparazione dei dischi per VMware

Una volta scelto l’hardware, inizia il procedimento di suddivisione degli spazi disco.

Un consiglio che posso dare, in questo frangente, è quello di creare un buon numero di LUN di modeste dimensioni sui vostri storage.

Ciò consente migliori prestazioni in generale ed una maggiore manutentibilità.

Una sola LUN di grande dimensione può diventare molto “pesante” da gestire per la struttura in fibra creando problemi di I/O Wait sulle virtual machine ospitate. Attenti a condividere con uno schema preciso le LUN verso gli host fisici poiché non è possibile migrare un disco virtuale da una LUN all’altra senza dover spegnere la VM che la utilizza.

Non secondario è poi il fatto che tali migrazioni necessitano di molto tempo per essere portate a termine e, in casi estremi in cui il traffico è molto alto, possono anche portare ad un fallimento dell’intera procedura. In un solo caso mi è successo che un disco virtuale si corrompesse, eventualità più unica che rara, ma minimizzabile con dischi ben distribuiti all’interno di Lun a loro volta ben distribuite negli Storage.

Ricordo ancora una volta che un’attenta pianificazione è molto importante per essere sempre in grado di upgradare hardware che diventa critico con la crescita dell’infrastruttura di virtualizzazione.

La preparazione dell’ambiente VMware e della parte di rete

La preparazione dell’ambiente VMware e della parte di rete

Terminata questa delicata fase è il momento di installare l’intero software di virtualizzazione per ogni nodo. E’ importante, se avete un grande numero di nodi, prevedere un NFS server per l’installazione, in modo da risparmiare parecchio tempo ed essere pronti in caso di installazione di nuovo hardware o reinstallazione di un nodo per motivi di recupero.

In questa fase dovrete, ovviamente, aver pianificato attentamente gli spazio di rete per assegnare gli IP ai nodi fisici. Altrettanto importante è la creazione dei tag corretti delle VLAN sugli apparati di rete che dovranno poi essere riportati all’interno del gestore delle Virtual Machine per poter far sì che le VM stesse possano raggiungere la rete esterna applicando il dovuto shaping.

Sul fattore shaping è necessario spendere qualche parola in più. E’ possibile, infatti, limitare la banda per ogni VLAN in modo da fornire alla subnet acquistata dal cliente finale il giusto apporto di dati. Questo approccio ha, però, una controindicazione piuttosto importante, ovvero, se delle VM risiedono su nodi fisici differenti, è possibile che venga applicato lo shaping anche tra loro. Di fatto questa è una forte limitazione al concetto di “datacenter virtuale” poiché, grazie al sistema di balancing automatico, è impossibile avere la certezza che due VM risiedano sullo stesso nodo fisico anche se vengono avviate assieme.

Il problema dello shaping è comunque aggirabile ponendo limiti a livello di core router in uscita in modo che soltanto le connessioni in uscita dall’intera infrastruttura abbiano un cap oltre il quale non andare.

Deploy delle macchine virtuali e gestione della ram

Deployment delle macchine virtuali e la gestione delle risorse

Superate le problematiche legate alla rete, arriva il momento di capire come si potrà fare il deploy della macchine virtuali. Prima di tutto è necessario elencare tutte le risorse disponibili a livello di RAM e CPU. Ricordiamoci sempre che, per avere una struttura di High Availability funzionale, possiamo impegnare risorse fintantoché un nodo (il più potente) rimanga completamente libero.

Ovviamente in fase di produzione tutti i nodi avranno un carico che non si avvicina al 100% ma in caso di failure hardware sarà rimasto spazio a sufficienza perché le VM cadute possano essere redistribuite sugli altri nodi in automatico.

Un altro punto estremamente importante è la configurazione della RAM delle Virtual Machine stesse. VMWare permette di settare una percentuale che definisce la quantità di RAM fisica corrispondente alla minima allocabile dalla VM. In situazioni di basso carico, tutta la RAM virtuale corrisponde a banchi di RAM fisica, ma se il carico sale, è possibile che parte della RAM virtualizzata venga messa in swap su disco.

Ovviamente l’utente della VM non nota differenze a livello applicativo, ma è altresì ovvio che le prestazioni possono calare anche drasticamente se la percentuale di “minimo garantito” è molto bassa. Se questa percentuale è settata al 100%, ovviamente avremo garanzia che la RAM in utilizzo sia sempre RAM fisica, ma perderemo l’ottimizzazione VMWare in merito al riutilizzo della RAM stessa, inoltre assottiglieremo il limite oltre il quale HA potrebbe fallire.

E’ altresì vero che, utilizzando appieno la RAM fisica, aumenteremo i costi (non in modo considerevole) ma renderemo anche l’intera struttura più reattiva e sempre con il massimo potenziale per quanto riguarda la VM stesse.

Va considerato, inoltre, che aumentando in modo considerevole la RAM fisica “garantita” lo spazio per eventuali migrazioni di virtual machines su differenti nodi fisici potrebbero fallire. In teoria queto è un caso non possibile poiché VMWare dovrebbe fare check di risorse disponibili prima di iniziare il processo di migrazione, ma ho visto casi in cui, anche se, in teoria, c’era spazio a sufficienza, all’atto del commit della migrazione “live”, si riceveva un “fail”.

Questi episodi si verificavano sempre in concomitanza di nodi che erano quasi al limite in termini di carico e risorse allocate. Probabilmente, questa tipologia di problemi è sempre più rara visto che VMWare aggiorna continuamente i suoi prodotti, ma, se l’obiettivo è la massima stabilità è sempre meglio mantenere un minimo margine di sicurezza.

Nella prossima puntata parleremo degli aspetti più problematici della gestione e della preparazione ed utilizzo del nodo di management, vero punto critico dell’intera infrastruttura.

Questo articolo è offerto da Noamweb

La Noamweb nasce nel 2001 specializzandosi in soluzioni di hosting, housing e registrazione domini per professionisti del settore, quali programmatori, webmaster, SEO e rivenditori, mettendo a loro disposizione attrezzature di altissima qualità, e offrendo una vasta gamma di servizi studiati appositamente per le loro esigenze.