VMware virtual memory: ballooning

Da recenti esperienze lavorative noto che il funzionamento del meccanismo che permette ad una virtual machine di utilizzare o meno la memoria del proprio host non è ben chiaro nemmeno a chi gestisce Virtual Datacenter di una certa dimensione. In ambito virtualizzazione la gestione della memoria è un tema estremamente importante essendo una delle risorse che impattano direttamente le prestazioni dell’ambiente guest.

In questo articolo, il primo di una piccola serie che vorrei proporre, ci concentreremo sul ballooning. Tramite questo sistema gli host ESXi sono titolati a reclamare memoria allocata dalle virtual machine ma non utilizzata al momento. Ciò è possibile grazie ad un apposito pseudo-device driver che serve a “gonfiare un palloncino” di memoria allocata all’interno della virtual machine stessa in modo da liberare una porzione della memoria fisica dell’host facendo crede alla virtual machine di avere questa porzione di RAM in uso.

Lo scopo di questa meccanica è restituire memoria all’host quando questo si trova in carenza di questa risorsa. L’effetto collaterale inevitabile è un potenziale deterioramento delle prestazioni della virtual machine qualora il sistema operativo guest dovesse aver bisogno di ulteriore virtual memory al momento non disponibile. In questo caso il sistema operativo saturerebbe la vRAM restante fino ad arrivare ad utilizzare la propria partizione di swap o il page file con relativo calo delle prestazioni del sistema.

Questo comportamento è tipico delle infrastrutture che, per diverse ragioni, si trovano ad avere una situazione di saturo della memoria RAM a livello host. E’ quindi inevitabile la ricerca di un compromesso che abbia come fine la razionalizzazione della risorsa RAM all’interno di un cluster VMware vSphere.

E’ evidente come il ballooning sia un sistema a tutela dell’infrastruttura più che della virtual machine, in tal senso il cluster vSphere deve essere opportunamente configurato a livello di resource pool e share di risorse tra i pool e le virtual machine stesse.

Ovviamente evitare il ballooning è possibile laddove non lo si desideri affatto (come nei cluster di produzione di cui ho seguito progettazione ed implementazione) al fine avere a disposizione un’infrastruttura che tenda a garantire le risorse alle virtual machine. Senza prendere in esame casi limite di over commitment, si pensi semplicemente al banale caso in cui una virtual machine si trovi improvvisamente a dover sostenere un picco di carico che la porti ad allocare molta vRAM. Se il cluster è molto utilizzato è plausibile un saturo a livello host tale da generare il fenomeno del ballooning, ma se il cluster è configurato in modo da bilanciare il carico tramite DRS tale fenomeno sarà facilmente evitabile ed il livello prestazionale delle virtual machine sarà garantito.

Qualora volessimo accertarci che la nostra virtual machine non sia soggetta a ballooning possiamo eventualmente agire a livello di configurazione della virtual machine stessa tramite la seguente configurazione nel file .vmx (rif. KB 1002586):

sched.mem.maxmemctl = “0″