Virtualizzazione: progettare sempre

Fin dal mio primo progetto di virtualizzazione per un cliente (ma anche prima della virtualizzazione, ad essere onesto), quello che commercialmente è un’offerta di un fornitore, dal punto di vista IT l’ho sempre vista come l’ultimo passo di un progetto.

Quando si deve mettere mano all’infrastruttura IT o se ne deve creare una ex novo è sempre importante partire da un progetto, indipendentemente dal fatto che si stia parlando di un piccolo server per tre utenti o di una multinazionale con sedi sparse in tutto il mondo (alcune delle quali in movimento).

Il progetto nasce da un dialogo (che all’inizio dovrebbe essere sedersi, ascoltare e prendere appunti) con l’utente finale. In questo caso il concetto di “utente” è molto ampio e dipende dal contesto, in quanto si va dall’utilizzatore vero e proprio al suo responsabile, al responsabile di livello superiore… Dipende dal contesto, ovviamente.

Il dialogo serve a capire quali siano i punti dolenti e anche quali siano gli sviluppi futuri, per evitare di acquistare un’infrastruttura che diventa inadatta dopo 6 mesi dal go live perché, ad esempio, viene sostituito il software applicativo su cui gira.

Al dialogo vanno aggiunti i dati tecnici rilevati dal campo, quelli di cui gli utilizzatori ignorano l’esistenza. Esistono tool specifici per analizzare metriche complesse come gli importantissimi (per gli ambienti virtuali) I/O al secondo (IOps), ma molte volte sono sufficienti per partire pochi dati per ogni server che possono essere raccolti in tempi relativamente ridotti:

• RAM attuale e futura;
• spazio disco attuale e futuro (se è disponibile un trend storico di crescita meglio ancora);
• licenza del sistema operativo e del software;
• dipendenze da hardware specifico (se il server è fisico).

Già con questi dati si possono coprire i progetti di ampliamento della maggior parte delle realtà italiane perché le grosse realtà pagano già eserciti di consulenti che fanno questo lavoro e presentano i risultati in gigabyte di file PowerPoint.

Una volta raccolti i dati si imposta un foglio elettronico con l’elenco dei server, la RAM e il disco da assegnare. Usando il tastino Σ si fanno un paio di totali, che indicano le ncessità delle macchine virtuali. La RAM dovrà essere incrementata e arrotondata opportunamente per far posto sia alle richieste dell’hypervisor sia ad eventuali necessità future: almeno un 20% in più del totale, ma è una cifra buttata lì. Discorso analogo vale per il disco, per il quale bisogna tener presente anche il fatto che le snapshot occupano disco e che non è mai bello essere a corto di spazio sul datastore di un ambiente virtualizzato: qui bisogna stare belli larghi.

Il totale dello spazio disco assegnato alle macchine virtuali è il totale massimo teorico di un’istanza di backup, ovvero la dimensione che avrà una copia disaster recovery di tutti i server. Questo è lo zero Kelvin della dimensione dello storage dei backup, in quanto è lo spazio massimo che può occupare una sola copia di tutti i server.

Ma noi non vogliamo avere una sola copia, che viene sovrascritta, vero?

I moderni software di backup dedicati agli ambienti virtuali utilizzano tecniche per ridurre lo spazio occupato dalle copie successive alla prima, come il reverse incremental; esistono anche alcune soluzioni di storage dedicati ai backup che hanno un proprio motore di deduplica interno e presentano a livello applicativo solamente una condivisione SMB, ma sono oggettini il cui costo base è dell’ordine dei 10.000 EUR.

Poi c’è il discorso delle licenze. Microsoft permette di licenziare fino a 4 Windows Server standard per ogni host (macchina fisica) con una licenza Enterprise, oppure infiniti server Windows per macchina fisica con una licenza Datacenter. Ci sono sistemi particolari nel conto delle macchine fisiche, ma questi sono dettagli del licensing di Microsoft che ci porterebbero fuori tema. Ovviamente molti Linux (CentOS, Debian…) non hanno bisogno di licenze.

C’e’ un ultimo scoglio da affrontare nel caso in cui si passi da un ambiente fisico ad uno virtuale: i fornitori del software applicativo. Ci sono molti fornitori del tutto ignoranti (in senso strettamente etimologico, sia chiaro) in materia di virtualizzazione; questi sono i tipici fornitori che, nel caso di un problema al loro software, diranno “è colpa di $piattaforma_di_virtualizzazione” e vi lasceranno in braghe di tela. In questi casi ci sono due opzioni: o si tace il fatto di aver virtualizzato un server (l’ho fatto anche con il tecnico che ha installato il software in sede) oppure si dialoga prima, mettendo bene in chiaro i termini.

Solamente dopo aver raccolto queste informazioni si può procedere ad una prima ipotesi di configurazione:

• quanti host?
• storage condiviso?
• quale licenza del sistema di virtualizzazione?
• quale software di backup e con che politiche?
• sono necessari ampliamenti nel networking?

Ovviamente queste sono macro-aree di esempio al cui interno ci sono altre decine di domande. Parimenti un cambio di configurazione apparentemente minimo potrebbe scatenare un effetto domino sulle licenze o sulle dimensioni degli storage.

Una volta fissate queste informazioni o stabiliti i limiti di oscillazione di alcuni parametri si può procedere alla formulazione di un’offerta commerciale e iniziare la trattativa economica.

Come si può vedere è l’esatto opposto di quello che succedeva anni fa quando il venditore diceva “ho questo modello in promozione, lo vuoi?”