La virtualizzazione dei server è uno degli argomenti più caldi di questi anni. Molte aziende stanno già affrontando la loro seconda ondata di virtualizzazione che spesso si traduce in una rivisitazione radicale di quello che è stato fatto negli anni passati per correggere errori e, magari, aggiornare l’infrastruttura con gli ultimi trend tecnologici. L’obiettivo di questa serie di articoli (qui, qui e qui i precedenti) è quello di sottolineare alcuni aspetti di base per chi si avvicina per la prima volta alla virtualizzazione ma anche di ricordare, a chi ha già intrapreso questo percorso, alcuni punti focali per migliorare il più possibile la propria infrastruttura.
Una volta realizzata l’infrastruttura virtuale viene il momento di virtualizzare:
da fisico a virtuale
Il processo per passare da fisico a virtuale non è banale. Certo, esistono casi abbastanza fortunati, soprattutto nelle infrastrutture piccole e/o poco critiche, dove questa attività si può fare con grande tranquillità e magari anche per tentativi successivi ma, nella grande maggioranza dei casi, non ci si possono permettere errori e tempi lunghi di migrazione. L’esperienza e il buon senso insegnano che è bene migrare prima tutte le macchine meno influenti per la produzione (sviluppo e test in primis) per poi passare a quelle di produzione meno critiche e infine a quelle mission critical. L’approccio descritto permette di iniziare con calma e rodare l’infrastruttura: testare gli strumenti di management, impostare le prime schedulazioni (backup, snapshots, ecc.), fare le prime attività di tuning e le opportune verifiche. L’attività di migrazione può durare anche molti mesi e coinvolgere tutta l’azienda (non solo chi fisicamente deve migrare i server ma anche poi chi dovrà fruire dei servizi, chi si occupa della sicurezza, ecc.).
Esistono diversi metodi per migrare da fisico a virtuale, in alcuni casi (sempre più rari) è necessario ricostruire il server da zero, re-installare tutti i software e migrare i dati (un po come si farebbe per una migrazione da fisico a fisico). Lo standard nelle migrazioni fisico-virtuale è comunque quello di utilizzare alcuni tool specifici, speso messi a disposizione dal fornitore dell’hypervisor, che consentono, con pochi click, di clonare il contenuto di un server fisico in un server virtuale in poco tempo e con la ragionevole certezza di fornire lo stesso identico servizio da una macchina virtuale con un disservizio minimo. Ad onor di cronaca posso aggiungere che, alcuni fornitori di soluzioni terze parti, hanno sviluppato nel tempo dei tool molto sofisticati che permettono migrazioni da Fisico a virtuale (ma anche da virtuale a virtuale) su piattaforme differenti, questi tool hanno il grande vanto di poter operare su ambienti multivendor con un unica interfaccia e possono essere una soluzione in ambienti molto complessi.
i rischi della virtualizzzione selvaggia
Dopo i primi passi nel mondo della virtualizzazione capita spesso di assistere ad una “ubriacatura” di tutto l’IT (e parte del management) che può portare a risultati spiacevoli nel medio/lungo periodo. Quello che in gergo viene definito “VM sprawl” è un fenomeno abbastanza diffuso e si può tradurre in una crescita spropositata e scomposta del numero e della qualità delle macchine virtuali all’interno dell’infrastruttura.
Purtroppo, al contrario di quanto succede per le risorse fisiche, tutto quanto riguarda il virtuale si può allocare anche “virtualmente”! Questo significa che se parte un nuovo progetto non dovrò fare una richiesta per nuove risorse (es.: server e storage) che, normalmente, è soggetta ad un lungo processo ma semplicemente le attiverò sulla mi infrastruttura virtuale. Una pratica di questo genere, ne va ad inficiare molte altre di corrette e consolidate e si inizia a sottovalutare il capacity planning e i costi indotti dall’accensione di queste VM (licenze, tempo, management, backup, ecc.). Con l’andare del tempo c’è il rischio concreto di perdere di vista il capitolo TCO dell’infrastruttura e si innesca una rincorsa affannosa a sostenere le richieste di una infrastruttura di cui si è perso il controllo.
Nel tempo, ho vissuto direttamente situazioni del tipo: progetto di virtualizzare 155 server e risultato di oltre 350 VM nel giro di pochi mesi dall’adozione dell’infrastruttura (lamentandosi poi che il tutto non era adeguato alle aspettative!!!): scoperto che virtualizzare era facile i vari manager iniziarono a chiedere VM di dimensioni assurde in termini di CPU, RAM e disco e più di quante realmente necessarie! Certo, questo è un caso limite che poi si risolse cambiando alcuni processi aziendali, ma sono cose che possono succedere.Gli aspetti legati al capacity planning e all’uso delle risorse è decisamente più importante ora di prima e uno strumento di reportistica, spesso integrato con la console di amministrazione, è fondamentale per tener traccia del consumo di risorse e avere modo di reagire prontamente alle richieste dell’azienda.
virtualizzazione e consolidamento
Durante il processo di virtualizzazione non dovrebbe essere mai dimenticato un aspetto altrettanto fondamentale: il consolidamento. La proliferazione di sistemi all’interno del datacenter porta con se dei costi importanti legati al management dei sistemi. Ogni server che viene acceso (sia fisico che virtuale) deve essere gestito, aggiornato, manutenuto, backuppato e così via. Quando è possibile sarebbe sempre buona norma cercare di consolidare più server in uno o pochi (ad es. più server SQL in uno solo). Il consolidamento può permettere di razionalizzare anche gli acquisti di licenze software oltre a consolidare alcuni tipi di workload omogenei, semplificando sensibilmente tutte le attività legate al performance tuning e facilitando il raggiungimento degli standard di servizio prefissati.
Anche per oggi direi che ho scritto a sufficienza, nel prossimo, e ultimo, articolo della serie: capacity planninng e charge back, cloud privato, cloud pubblico
Trackbacks/Pingbacks