vNUMA in vSphere 6.5
La configurazione delle vCPU all’interno delle Virtual Machine, molto spesso è sottovalutata, portando il più delle volte a creare VM che hanno configurazioni sovrastimante e che portano ad avere problemi sulle performance. Con questo articolo ho cercato un po’ di raccogliere un po’ di informazioni che mi hanno aiutato e spero possano aiutare chi vuole capire come funziona l’underlay di virtualizzazione per quanto riguarda la condivisione delle risorse CPU, alcuni esempi di configurazione e l’impatto di queste ultime prima e dopo vSphere 6.5.
NUMA ?
Innanzitutto, NUMA è un acronimo che sta per “Non Uniform Memory Access” .
L’hardware di sistema sottostante ha più di un bus di sistema; un’architettura di memoria condivisa che è possibile trovare nei sistemi SMP di oggi. Ad ogni a ogni CPU fisica viene assegnata la memoria “locale”. L’accesso alla memoria locale offre bassa latenza e prestazioni elevate (larghezza di banda). Se una CPU deve accedere alla memoria di proprietà di un’altra CPU, la latenza aumenta; bassa prestazione (larghezza di banda). Questo tipo di accesso alla memoria è chiamato memoria “remota” ed è una situazione che si desidera evitare.
È possibile avere una configurazione NUMA sbilanciata? Sì e non è raro. Tutto si riduce alla progettazione attenta del server ESXi. Se la tua soluzione richiede sia capacità di memoria che prestazioni di memoria ottimali, il MEMORY RANKING sarà molto importante nella configurazione del tuo server. Una configurazione di nodo NUMA non bilanciata potrebbe essere un sistema con un numero non uniforme di DIMM per canale CPU. Un esempio di configurazione hardware sbilanciata:
supponiamo che io abbia un host ESXi configurato con due socket con 96 GB di memoria (DIMM 8 GB x 12). Il nodo NUMA 0 (zero) ha accesso a otto (8) moduli DIMM da 8 GB (64 GB di memoria), mentre il nodo NUMA 1 avrà accesso ai restanti quattro (4) moduli DIMM da 8 GB (32 GB di memoria), ecco in questo caso ho una configurazione hardware e una accesso alla memoria sbilanciato. Posso anche avere una configurazione “channel” sbilanciata. Fondamentalmente, alla CPU (nodi NUMA) può essere assegnato un numero uguale di DIMM ma i canali per CPU (nodo) non sono bilanciati. Quindi stai molto attento quando progetti i tuoi server ESXi e prendi in considerazione la configurazione di CPU e memoria relativa a quell’hardware!
Quello sopra è solo un esempio, nella stragrande maggioranza dei casi lato hardware la configurazione del server dovrebbe essere il più lineare possibile e quindi dovrei avere la stessa quantità di memoria disponibile per ciascun NUMA Node. L’immagine che trovate qua sotto sono sicuro che vi chiarirà le idee sull’architettura.
vNUMA ?
Quindi cos’è vNUMA? vNUMA è quando la topologia NUMA fisica sottostante (l’host ESXi) diventa visibile ai sistemi operativi guest. Chiaro e semplice. Tuttavia, è necessario soddisfare due condizioni prima che vNUMA venga abilitato su una macchina virtuale:
- La macchina virtuale è configurata con 9 vCPU e oltre
- Il numero delle vCPU supera il numero dei core fisici all’interno del nodo NUMA. L’impostazione avanzata “numa.vcpu.preferHT = True” può svolgere un ruolo fondamentale
KEEP IN MIND:
Avere il CPU e il Memory Hot Plug attivi sulla virtual machine disabilità la possibilità di mostrare la topologia della CPU tramite il vNUMA al sistema operativo Guest
“Hot-Add is not compatible with vNUMA, if hot-add is enabled the virtual NUMA topology is not exposed to the guest OS and this may impact application performance”
Maggiori Informazioni qui
Come funziona in vSphere 6.5?
In vSphere 6.5, cambiare il valore dei cores per socket non influenza la creazione dei vNUMA o la configurazione della topologia del/dei vNUMA. La configurazione virtual socket e cores per socket incide solo sulla presentazione dei virtual processor al sistema operativo, in linea generale viene fatto per motivi di License.
vNUMA determinerà in maniera automatica la corretta vNUMA topology da presentare al sistema operativo guest basato sul sistema hypervisor sottostante ovvero ESXi.
UN ESEMPIO:
supponiamo la creazione di una macchina virtuale a 4-vSocket con 4 cores per socket (ovvero un totale di 16 vCPU), il tutto su un sistema host ESXi dual socket, ciascuno con 16 cores fisici. Prima di vSphere 6.5, vNUMA avrebbe creato 4 nodi vNUMA in base all’impostazione dei core per socket. A partire da vSphere 6.5, il sistema operativo guest vedrà ancora 4 socket e 4 core per socket, ma vNUMA ora creerà solo 1 nodo vNUMA per l’intera macchina virtuale poiché può essere inserito in un singolo nodo NUMA fisico. Questa nuova disconnessione delle impostazioni dei core per socket con vNUMA consente a vSphere di determinare automaticamente la migliore topologia vNUMA in tutte le circostanze. Nel caso in cui si desideri ancora ripristinare il comportamento precedente in vSphere 6.0, utilizzare l’impostazione avanzata
numa.FollowCoresPerSocket = 1
Maggiori Informazioni si posso trovare direttamente sui seguenti articoli:
