vSphere education - Quali sono gli svantaggi della configurazione di VM con * troppa * RAM?

La gestione della memoria di VMware sembra essere un atto di bilanciamento complicato. Con RAM cluster, pool di risorse, tecniche di gestione di VMware (TPS, ballooning, scambio di host), utilizzo della RAM in-guest, swap, prenotazioni, condivisioni e limiti, ci sono molte variabili.

Sono in una situazione in cui i clienti utilizzano risorse cluster vSphere dedicate. Tuttavia, stanno configurando le macchine virtuali come se fossero su hardware fisico. A sua volta, ciò significa che una build VM standard può avere 4 vCPU e 16 GB o più di RAM. Vengo dalla scuola di avvio di piccole dimensioni (1 vCPU, RAM minima), controllo dell'utilizzo nel mondo reale e adattamento, se necessario. Sfortunatamente, molti requisiti del fornitore e persone che non hanno familiarità con la virtualizzazione richiedono più risorse del necessario ... Sono interessato a quantificare l'impatto di questa decisione.

Alcuni esempi da un cluster "problematico".

Riepilogo pool di risorse: sembra quasi 4: 1 sovraccarico. Nota l'elevata quantità di RAM con palloncini.

Allocazione delle risorse - La colonna Allocazione caso peggiore mostra che queste macchine virtuali avrebbero accesso a meno del 50% della RAM configurata in condizioni vincolate.

Il grafico di utilizzo della memoria in tempo reale della VM principale nell'elenco sopra. 4 vCPU e 64 GB di RAM allocati. Ha una media di utilizzo inferiore a 9 GB.

Riepilogo della stessa macchina virtuale

• Quali sono gli svantaggi del sovraccarico e della configurazione eccessiva delle risorse (in particolare RAM) negli ambienti vSphere?

• Supponendo che le VM possano funzionare con meno RAM, è corretto affermare che esiste un sovraccarico per la configurazione di macchine virtuali con più RAM di quanto effettivamente necessario?

• Qual è il contro-argomento a: "se una VM ha allocato 16 GB di RAM, ma utilizza solo 4 GB, qual è il problema ?? "? Ad esempio, i clienti devono essere informati che le macchine virtuali non sono le stesse dell'hardware fisico?

• Quali metriche specifiche devono essere utilizzate per misurare l'utilizzo della RAM. Tieni traccia dei picchi di "Attivo" rispetto al tempo? Stai guardando "Consumato"?

Aggiornamento: ho usato vCenter Operations Manager per creare un profilo di questo ambiente e ottenere alcuni dettagli sulle statistiche del cluster sopra elencate. Mentre le cose sono decisamente sovraccaricate, le VM sono in realtà così sovraconfigurate con RAM non necessaria che il footprint di memoria reale (minuscolo) non mostra alcuna contesa di memoria a livello di cluster / host ...

La mia cosa da asporto è che le macchine virtuali dovrebbero avere le dimensioni giuste con un po 'di buffer per la memorizzazione nella cache a livello di sistema operativo. Commettere per ignoranza o "requisiti" del fornitore porta alla situazione qui presentata. Il ballooning della memoria sembra essere negativo in ogni caso, poiché ha un impatto sulle prestazioni, quindi il dimensionamento corretto può aiutare a prevenire questo.

Aggiornamento 2: alcune di queste macchine virtuali iniziano a bloccarsi con:

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 

VMware lo descrive come un sintomo di un sovraccarico eccessivo di memoria . Quindi suppongo che risponda alla domanda.

Rapporto "Macchine virtuali di grandi dimensioni" di vCops ...

Grafico "Rifiuti rigenerabili" di vCops ...

La gestione della memoria di vSphere è abbastanza decente, sebbene i termini usati spesso causino molta confusione.

In generale, il sovraccarico della memoria dovrebbe essere evitato in quanto crea esattamente questo tipo di problema. Tuttavia, ci sono momenti in cui non può essere evitato, quindi gli avvertiti sono anticipati!

Quali sono gli svantaggi del sovraccarico e della configurazione eccessiva delle risorse (in particolare RAM) negli ambienti vSphere?

Il principale svantaggio delle risorse eccessivamente impegnative è che, in caso di controversie, i padroni di casa sarebbero costretti a passare in rassegna, scambiare o pianificare / de-duplicare in modo intelligente dietro le quinte per fornire a ogni VM la RAM di cui ha bisogno.

Per il ballooning, vSphere gonfia un "balloon" di RAM all'interno di una VM scelta, quindi fornisce tale RAM in balloon al guest che ne ha bisogno. Questo non è davvero "negativo" - le VM si stanno rubando reciprocamente la RAM, quindi non c'è scambio di dischi in corso - ma potrebbe portare a avvisi errati e metriche distorte se si basano sull'analisi dell'utilizzo della RAM della VM, poiché la RAM ha vinto essere contrassegnato come "mongolfiera", solo che è "in uso" dal sistema operativo.

L'altra funzione che vSphere può utilizzare è Transparent Page Sharing (TPS), che è essenzialmente la deduplicazione della RAM. vSphere eseguirà periodicamente la scansione di tutta la RAM allocata, alla ricerca di pagine duplicate. Una volta trovato, verrà duplicato e liberato le pagine duplicate.

Dai un'occhiata al white paper sulla gestione della memoria di vSphere (PDF) - in particolare "Reclamation della memoria in ESXi" (pagina 8) - se hai bisogno di una spiegazione più approfondita.

Supponendo che le macchine virtuali possano funzionare con meno RAM, è corretto affermare che esiste un sovraccarico per la configurazione di macchine virtuali con più RAM del necessario?

Non c'è sovraccarico visibile: puoi allocare 100 GB di RAM su un host con 16 GB (tuttavia, ciò non significa che dovresti , per i motivi sopra).

La memoria totale utilizzata da tutte le macchine virtuali è la curva "Attiva" mostrata nei grafici. Naturalmente, non dovresti mai fare affidamento solo su quella cifra quando calcoli quanto vorresti sovraccaricare, ma se hai metriche storiche come hai, puoi analizzarle e elaborarle in base all'utilizzo effettivo.

La differenza tra RAM "attiva" e "consumata" è discussa in questo thread della community VMWare .

Qual è il contro-argomento a: "se una VM ha allocato 16 GB di RAM, ma utilizza solo 4 GB, qual è il problema ??" ? Ad esempio, i clienti devono essere istruiti?

La risposta breve a questa domanda è sì : i clienti devono sempre essere istruiti sulle migliori pratiche, indipendentemente dagli strumenti a loro disposizione.

I clienti dovrebbero essere istruiti a dimensionare le loro macchine virtuali in base a ciò che usano , piuttosto che a ciò che desiderano . Molte volte, le persone specificheranno in modo eccessivo le loro macchine virtuali solo perché potrebbero aver bisogno di 16 GB di RAM, anche se storicamente si perdono in 2 GB giorno dopo giorno. Come amministratore di vSphere, hai le conoscenze, le metriche e il potere per sfidarli e chiedere loro se hanno effettivamente bisogno della RAM che hanno allocato.

Detto questo, se si combina la gestione della memoria di vSphere con limiti di overcommit attentamente controllati, raramente si dovrebbe avere un problema in pratica, la probabilità di rimanere senza RAM per un lungo periodo di tempo è relativamente remota.

Inoltre, vMotion automatizzato (chiamato Distributed Resource Scheduling di VMware) è essenzialmente un bilanciamento del carico per le VM - se una singola VM sta diventando un porco di risorse, DRS dovrebbe migrare le VM in giro per sfruttare al meglio le risorse del cluster.

Quale metrica specifica deve essere utilizzata per misurare l'utilizzo della RAM. Tieni traccia dei picchi di "Attivo" rispetto al tempo?

Principalmente trattato in precedenza - la tua preoccupazione principale dovrebbe essere l'utilizzo della RAM "Attiva", sebbene tu debba definire attentamente le soglie di sovraccarico in modo che se raggiungi un certo rapporto ( questo è un esempio decente , sebbene possa essere leggermente obsoleto). In genere, rimarrei sicuramente entro il 120% della RAM totale del cluster, ma spetta a te decidere con quale rapporto ti senti a tuo agio.

Alcuni buoni articoli / discussioni sull'over-commit della memoria:

• Overcommit di memoria in produzione? SÌ SÌ SÌ
• vSphere - Memoria in eccesso?
• Overcommit della memoria in vSphere

Oltre all'ottima risposta di Craig Watson, vorrei aggiungere quanto segue:

Il sovraccarico della memoria in VMware non è qualcosa che dovresti fare di proposito. In genere mostra che tu o il tuo cliente state sottoscrivendo l'hardware in eccesso.

Se la scelta eccessiva è l'unica scelta, allora consiglio vivamente di applicare le regole di priorità. Se qualcuno è disposto a fornire una VM non critica da 16 GB di vRam quando ha bisogno solo di 4 GB, almeno metti quella VM in un pool di risorse basso o assegnagli una priorità bassa. In realtà non si desidera scambiare un database di produzione critico dall'hypervisor. Non solo le prestazioni diminuiranno, ma consumeranno anche le code I / O rispetto al tuo archivio back-end.

Se stai eseguendo uno storage incredibilmente veloce (FusionIO, Violin, SSD locale ecc.), Lo scambio potrebbe non essere un grosso problema, ma con l'archiviazione SAN tradizionale alla fine influenzerai ogni singola VM e host connesso allo stesso array / controller.