VMware vCPU optimizing

La virtualizzazione ci porta a considerare la CPU non più come un componente del server ma come uno “pozzo” di cicli macchina da cui le Virtual Machines possono attingere all’occorrenza, rispettando la “coda” e la “priorità” che il sistema impone.

All’interno del Virtual Datacenter parliamo quindi di vCPU, ovvero di entità logiche che rappresentano un certo quantitativo di MHz eguale alla massima frequenza di lavoro della CPU o del CORE fisico del server host. Si ottiene quindi che se il nostro server fisico, su cui abbiamo installato l’hypervisor, è un bi-processo quad-core da 2.6 GHz, si potranno assegnare alle VMs vCPU da 2,6 GHz.

Evidentemente una vCPU non corrisponde alla CPU o CORE fisico del server host, si tratta semplicemente di una certa quantità di risorse computazionali che gli hypervisor mettono a disposizione delle VMs. I processi che girano all’interno dei sistemi operativi guest effettuato delle richieste “di calcolo” alle vCPU che possiamo leggere anche come una formale richiesta al server host di utilizzare un po’ del tempo di elaborazione di uno o più CPU/CORE del sistema fisico. A livello di hypervisor non è quindi necessaria una corrispondenza del tipo “1 vCPU” -> “1 CPU”, anzi avviene l’esatto opposto in quanto più vCPU possono richiedere tempo di elaborazione ad una stessa CPU (o CORE) con l’opportuna gestione da parte dell’intermediario di queste richieste, il software hypervisor.

Grazie a questo meccanismo la virtualizzazione permette di assegnare più vCPU a prescindere dal numero di CPU/CORE fisici che sono installati nel server host. Una sorta di “over booking” (il termine tecnicamente corretto è over entitlement) di tempo computazionale in quanto, teoricamente, ogni vCPU potrebbe chiedere tutto il tempo macchina di una CPU. Naturalmente se questo accadesse e qualora vi fossero vCPU in maggionr numero rispetto alle CPU/CORE, ci troveremmo di fronte ad un bel problema in quanto, a parità di priorità, nessuna guest si troverebbe ad aver a disposizione le risorse che richiede e l’intero sistema di virtualizzazione ci apparirebbe incredibilmente lento ed appesantito.

Come trovare quindi il giusto equilibrio tra consolidamento delle risorse e rispetto delle esigenze di tempo computazionale degli ambienti guest di un Virtual Datacenter?

Non esiste purtroppo una regola unica che sia sempre valida. Gli scenari sono molti e richiedono specifiche analisi per trovare il miglior compromesso. Esistono però delle best practice che ci aiutano a trovare la via giusta. Da tener presenta anche l’importante presenza di specialisti nel campo della virtualizzazione (in italia abbiamo la fortuna di ben otto vExpert compreso il sottoscritto) e di aziende che lavorano molto sulla salute dei Virtual Datacenter (si pensi ai Service Provider che ne fanno largo uso).

Nulla vieta di studiare, capire ed applicare. Il documento messo a disposizione da VMware è senza dubbio illuminante, in questo post vorrei porre l’accento solo su alcuni controversi temi, ovvero su quelle pratiche errate che noto essere tra le più frequenti e, talvolta, molto dannose in quanto si tratta, nei casi migliori, di scelte tecniche atte a migliorare le performance dei propri sistemi ma che portano ad un paradossale peggioramento della situazione (nei casi peggiori si tratta di scelte che sfiorano la stregoneria, in questo caso è sicuramente opportuno consultare chi conosce il tema).

Il primo tema è senza dubbio relativo alla fatidica domanda “quante vCPU assegno ad una nuova VM?”. La risposta, volendo seguire il consiglio di VMware stessa, è semplice e lineare: alla creazione di una nuova VM si assegna il minor numero di vCPU possibile nel rispetto dei requisiti di sistema espressi dai produttori di software. Questo significa che nella stragrande maggioranza dei casi possiamo avviare la nostra VM con 1 vCPU. Ovviamente, laddove le esigenze di carico siano superiori (fatto facilmente verificabile consultando i grafici che riportano l’andamento della vCPU) è opportuno aggiungere le vCPU necessarie alla VM.

Perché è bene assegnare le vCPU secondo reale necessità? Assegnare con troppa generosità vCPU porta uno sgradevole effetto collaterale nei sistemi di virtualizzazione. La concentrazione di vCPU per CPU/CORE aumenta e con essa aumenta il rischio/probabilità che si verifichino delle contese di risorse. Tale situazione risulta inoltre difficile da diagnosticare in quanto le VMs sembrano perdere in prestazioni nonostante non raggiungano praticamente mai il saturo della propria vCPU. Questa catena di aventi spesso confonde il personale tecnico che si trova a cercare di capire come mai le VMs non utilizzano appieno le risorse anche quando sono sotto sforzo, con relativo evidente calo di performance.

In questa casistica è possibile osservare come il Ready Time (il parametro che misura in millisecondi quanto tempo una richiesta alla CPU resta in attesa) tende ad aumentare notevolmente. E’ la prova dell’esistenza di una contesa di risorse a cui il sistema host sta facendo fronte erogando equamente le risorse a chi le richiede. Il fenomeno in questione si presenta con minore incidenza se l’assegnazione delle vCPU avviene secondo un criterio di reale necessità.

Affiancato a questo scenario, dove abbiamo di fatto affrontato uno dei problemi derivanti dall’elevato consolidation ratio, vi è il tema della priorità con cui il sistema host risponde alle richieste della macchina guest. E’ evidente che se tutti hanno pari diritto di richiedere risorse alle CPU si genera un meccanismo tale per cui “tutti resteranno un po’ delusi”. E’ comunque vero che in un Virtual Datacenter esistono VMs meno importanti di altre le cui prestazioni possono essere temporaneamente inficiate per dar modo ad altre VMs, considerate critiche, di attingere alla riserva di risorse nei momenti di elevato carico.

La priorità con cui una VM può chiedere risorse all’ambiente è identificata da una delle proprietà della VM stessa ed ha valenza relativa al resouce pool in cui si trova la VM (si noti che esiste anche un resouce pool “base” chiamato root resouce pool). Ciò significa che ogni VM può contendersi risorse solo con le VMs dello stesso resouce pool o con resouce pool al suo stesso livello. Per dare più priorità ad una VM è necessario aumentarne la quota di “share” all’interno del resouce pool in modo da privilegiarla in caso si verifichi una contesa di risorse. In questo caso il sistema assegnerà le risorse alle VMs mantenendo le proporzioni espresse dai parametri di share delle VMs all’interno del resouce pool.

L’ultimo scenario che affrontiamo in questo post è di più ampia visione. Non guardiamo più alle vCPU in proporzione alle CPU ne ai parametri di share delle VMs, il punto di vista è il Cluster. All’interno di questo macro contenitore di risorse possiamo trovare diverse centinaia di macchine virtuali con workload anche molto differenti. Chi gestisce cluster importanti in termini di dimensioni e con molte VMs difficilmente riesce ad ottenere buoni risultati di omogenea ripartizione del carico senza l’ausilio del Dynamic Resource Scheduler (DRS). Questo arcinoto strumento permette di automatizzare la migration delle VMs tra i nodi del cluster a fronte di una necessità di bilanciamento del carico in termini di CPU e RAM.

DRS di per se lavora già molto bene in quanto, se vengono mantenuti i parametri di default, ogni 300 secondi verifica se il cluster può beneficiare di eventuali spostamenti di VMs. Nel caso chi amministra l’infrastruttura abbia anche contezza dei workload delle VMs o di gruppi di queste è possibile mettere in campo un’altra funzionalità di VMware: le affinity/anti-affinity rules. Queste regole permettono di interferire con le scelte del DRS in relazione alla volontà di mantenere separate o unite delle specifiche VMs a livello di host. Diventa così possibile evitare che due VMs che presentano workload molto simili si trovino su uno stesso host del cluster.

Il tema non si esaurisce certo in queste mille parole, sono comunque abbastanza certo del fatto che questo articolo trova applicazione, almeno in alcune sue parti, in buona parte dei cluster VMware attivi in Italia (per non dire in Europa). Nonostante i concetti siano relativamente semplici – infondo basta studiare – la loro corretta applicazione non è così scontata… quindi in bocca al lupo e nel caso sapete dove trovarmi ;-)