Realizzare un cloud privato nella propria infrastruttura informatica è un passo strategico importante per un’azienda, perché con esso i servizi IT possono guadagnare in flessibilità e scalabilità, senza per questo minare la capacità del CIO di mantenere un totale controllo sulla propria schiera di server enterprise. Tuttavia, prima di cedere a facili entusiasmi e partire subito con l’implementazione della nuvola privata (salvo poi accorgersi in un secondo tempo, con grande frustrazione, della presenza, ad esempio, di colli di bottiglia di varia natura che rallentano le prestazioni e l’efficienza dell’infrastruttura) è bene fare un passo indietro, e analizzare con metodo e precisione le caratteristiche tecniche di ogni singolo server del parco macchine hardware; sono infatti queste macchine fisiche che nel data center avranno il compito di sostenere tutto il carico di lavoro e lo sforzo computazionale, derivanti dal funzionamento dell’infrastruttura virtuale.
Verificare le funzionalità e la dotazione hardware
I server devono possedere funzionalità e caratteristiche hardware in grado di supportare la virtualizzazione e tutto lo stack software necessario per installare il cloud privato. In particolare, occorre verificare il supporto che ciascun server è in grado di fornire, a livello di processore, memoria, risorse di rete e di storage, senza dimenticare le caratteristiche di resilienza, che tornano utili nei casi di malfuzionamento dell’infrastruttura, e consentono di ripristinare una situazione di normalità.
Partiamo dal processore. Prima di installare gli hypervisor e poi il software per il cloud privato, è necessario verificare la presenza (e, in caso positivo, abilitarle) delle estensioni di virtualizzazione x86 del processore, che tipicamente sono la Intel Virtualization Technology (Intel VT), per le architetture Intel, e AMD Virtualization (AMD-V), per quelle AMD. Queste estensioni aiutano in sostanza a eliminare o attenuare i cali di prestazioni sul server host derivanti dal funzionamento della virtualizzazione e delle VM, ossia le macchine virtuali.
Estensioni e funzionalità: quando e cosa abilitare
Altre estensioni del processore utili da abilitare, direttamente attraverso il BIOs o l’interfaccia UEFi (unified extensible firmware interface) del server, sono quelle Intel eXecute Disable (XD) e AMD No eXecute (NX), che consentono di prevenire attacchi informatici di ‘buffer overflow’ e l’esecuzione di altri exploit software malevoli.
Per ogni server, è importante considerare anche quanti core ha il processore, e quanti thread è in grado di gestire. Infatti, ci sono ad esempio hypervisor, come VMware vSphere ESXi 6.0, che richiedono un server host con almeno due core di processore: tuttavia, questo è solo un requisito di sistema minimo, e va tenuto presente che più core ha il processore, più sarà possibile estendere il numero di macchine virtuali e workload che ciascun server è in grado di amministrare.
Un ulteriore aspetto cruciale, da non trascurare, è legato alla disponibilità sul server della tecnologia UEFi, che rappresenta una sorta di firmware più evoluto rispetto al classico BIOs, e fornisce funzionalità aggiuntive di avvio (boot da hard disk, dischi ottici, unità USB). Tuttavia, con questo firmware gli hypervisor possono accusare limitazioni. Sempre prendendo ad esempio ESXi 6.0, le limitazioni legate al boot da rete richiedono l’uso del tradizionale BIOs, perché UEFi non è supportato. Quindi, se si passa dal BIOs a UEFi dopo aver installato l’hypervisor, tale cambiamento può generare problemi di avvio in fase di boot del sistema.
Memoria centrale, un parametro chiave
La dotazione di memoria principale del server, o RAM, è un altro parametro chiave da valutare, in quanto ogni macchina virtuale o container esistente ‘gira’ in una parte dello spazio di memoria fisica della macchina. Di conseguenza, più capacità di memoria è disponibile, più questa giocherà un ruolo positivo nella virtualizzazione del server e nell’implementazione del cloud privato. Per hypervisor come ESXi si raccomanda un sistema con almeno 8 GB, necessari per ospitare l’hypervisor e conservare comunque la capacità sufficiente a far funzionare almeno qualche macchina virtuale in ambienti di produzione. Gli stack software di private cloud come OpenStack richiedono anche meno risorse, raccomandando solo 2 GB per la piattaforma, più altra memoria, in funzione delle macchine virtuali che si decide di creare. Va comunque considerato che i moderni server oggi disponibili sul mercato partono già ben dotati, con capacità di memoria che possono di gran lunga superare quelle citate. Quindi, il vero punto è comprendere quante macchine virtuali o container si intende far funzionare sul server in questione, e quanta memoria si vorrà dedicare a ogni istanza: ma questa è un’esigenza che dipende strettamente dalla singola organizzazione.
Attenzione alla memoria di massa
Anche per quanto riguarda la capacità di storage, occorre prestare innanzitutto attenzione ai requisiti dei software di virtualizzazione. Hypervisor come ESXi richiedono 10 GB di storage, per la creazione del dispositivo di boot, che genera il volume VMFs (virtual machine file system), e la partizione di scratch sul dispositivo di avvio. Piattaforme di servizi private cloud come OpenStack, invece, raccomandano almeno 50 GB di spazio disco. In ogni caso, però, anche qui, il calcolo della capacità realmente necessaria dipende dal numero di macchine virtuali e dalla quantità di storage che si desidera allocare per ciascuna. È chiaro che un ambiente IT che utilizza poche macchine virtuali con immagini disco di dimensione fissa può richiedere meno capacità di un’infrastruttura in cui sono dispiegate molte macchine virtuali, ciascuna con un’immagine disco con differenti requisiti di storage. Tuttavia, come regola, 1 TB di storage si ritiene una capacità adeguata per un tipico server virtualizzato.
Quale supporto di rete e resilienza
Più si procede con la virtualizzazione, e più aumentano i workload sui server fisici, più aumenta anche l’utilizzo della rete, e ciò può creare colli di bottiglia e cali nella banda disponibile, che finiscono per compromettere le prestazioni e la stabilità degli altri workload. Cosa, questa, che può diventare particolarmente fastidiosa durante le operazioni ad elevato consumo di banda, come i backup delle macchine virtuali, specie quando sono diverse le VM che cercano di compiere in maniera simultanea tali operazioni. Anche le scelte sull’architettura di rete diventano quindi critiche quando si deve realizzare un cloud privato: un hypervisor come ESXi tipicamente richiede almeno una porta Gigabit Ethernet (GbE). Sebbene una porta più veloce, come quella 10 GbE, possa essere in grado attenuare i colli di bottiglia della banda, è spesso preferibile implementare due o più porte GbE, perché disporre di molteplici porte fisiche può fornire diversi importanti benefici. Ad esempio, diventa possibile combinare più porte GbE per aggregare la banda e ottenere un canale di comunicazione a più elevata capacità. Senza contare i vantaggi di resilienza, perché, in caso di malfunzionamento su una porta, il traffico può essere rediretto sull’altra.
Poter contare su server a prova di avarie
Proprio la resilienza è un altro fattore chiave da considerare, perché, più VM coesistono sullo stesso server fisico, maggiori sono i danni che si possono produrre in caso di avaria del server. Nel progetto di virtualizzazione e implementazione del private cloud è dunque essenziale integrare nel server hardware caratteristiche di resilienza in grado di mettere al riparo l’infrastruttura, preservandola dagli effetti negativi di un malfunzionamento. Gli accorgimenti dovrebbero prevedere l’inclusione nel server di alimentatori ridondati, oltre che l’integrazione di sistemi intelligenti ‘firmware-based’ di auto-diagnostica, che in caso di guasto possano aiutare i tecnici a individuare e isolare le avarie. Altro accorgimento è quello di abilitare nel server i meccanismi di resilienza della memoria, come la funzionalità ECC (error correcting code), che proteggono la stessa da errori nei dati, in fase di lettura, scrittura e trasferimento delle informazioni.
