Home > virtualization, vmware, vsphere > La gestione della memoria in VMware ESX 4.1–parte 2

La gestione della memoria in VMware ESX 4.1–parte 2

Nella prima parte di questa serie di articoli, ho cominciato a descrivere come viene gestita la memoria in VMware ESX 4.1, soffermandomi sui concetti di base.

In questa seconda parte illustrerò le tecniche “classiche” implementate in ESX 4.1 per recuperare memoria dalle vm (memory reclamation), nella terza parte mi soffermerò sulla memory compression presente per la prima volta in ESX4.1.

Le tecniche per il recupero della memoria in ESX4.1

ESX usa, nell’ordine, quattro tecniche per recuperare memoria dalle VM:

  • Transparent page sharing (TPS, condivisione trasparente delle pagine di memoria): recupero della memoria tramite la rimozione delle pagine di memoria ridondanti che hanno contenuto identico;
  • Ballooning: recupero della memoria tramite un aumento indotto artificialmente dell’uso della memoria interno al sistema operativo guest
  • Memory compression (compressione della memoria): recupero della memoria tramite compressione delle pagine che dovrebbero essere swappate;
  • Hypervisor swapping (swap a livello di hypervisor): swap della memoria delle VM fatto direttamente dall’hypervisor.

Perché delle tecniche di recupero della memoria?

Se ripensiamo alla equazione che indica l’uso della memoria dell’host da parte di una VM:

uso dell’host memory <= dimensione della guest physical memory + overhead

se l’hypervisor non potesse recuperare della memoria fisica dell’host (host physical memory) quando una vm la dealloca, dovrebbe riservare abbastanza host physical memory da poter allocare tutta la guest physical memory di tutte le VM (più gli overhead) per impedire che una qualunque VM esaurisca la memoria fisica. Di fatto questo impedirebbe la possibilità di fare overallocazione della memoria.

Il concetto di overallocazione della memoria è semplice: la memoria dell’host è overallocata quando la somma delle guest physical memory delle VM in esecuzione è maggiore della host physical memory.

ESX supporta da sempre l’overallocazione della memoria, questo per via di due importanti benefici che ne derivano:

  • Maggior utilizzo della memoria: grazie all’overallocazione della memoria si ottiene che la memoria dell’host sia utilizzata il più possibile dalla active guest memory. Spesso ci sono VM meno cariche rispetto alle altre, nelle quali la memoria è inutilizzata per lunghi periodi. Grazie all’overallocazione della memoria e alle tecniche di recupero, l’hypervisor può recuperare questa memoria inattiva e darla ad altre VM a cui serve.
  • Maggior fattore di consolidamento: con l’overallocazione della memoria ogni VM ha un uso minore della host memory, rendendo quindi possibile avere più VM sull host mantenendo comunque buone prestazioni.

Per poter però supportare in modo efficiente l’overallocazione della memoria, l’hypervisor deve avere delle tecniche efficienti di recupero della memoria. Passiamole ora in rassegna una ad una.

Transparent page sharing (TPS)

La tecnica del transparent page sharing si basa sulla considerazione che quando ci sono in esecuzione più VM, è probabile che alcune di esse abbiano identiche porzioni di memoria: ad esempio più VM possono avere lo stesso sistema operativo o avere le stesse applicazioni o contenere gli stessi dati utente. Questa considerazione apre l’opportunità di condividere le parti di memoria in comune, sia tra VM che all’interno della stessa VM, recuperando le copie ridondanti e conservando una sola copia condivisa nella host physical memory. Così facendo si riduce il consumo totale della host physical memory da parte delle VM aumentando il livello di overallocazione della memoria.

ESX identifica le pagine di memoria ridondanti in base al loro contenuto: pagine con contenuto identico vengono condivise indipendentemente da come, dove e quando il contenuto è stato generato. Per identificarle, ESX controlla  periodicamente  il contenuto della guest physical memory alla ricerca di possibilità di sharing. Per maggior efficienza, ESX non confronta byte per byte le pagine, ma usa degli hash.

Vediamo l’algoritmo nel dettaglio:

  • basandosi su un una cadenza di scansione, ESX esamina in modo casuale le pagine della guest physical memory;
  • individuata una pagina candidata ad essere condivisa, viene generato un hash basato sul suo contenuto;
  • l’hash viene usato come chiave per cercare una corrispondenza nella tabella globale degli hash (tale tabella contiene l’elenco delle corrispondenze tra hash e pagine fisiche condivise);
  • se l’hash corrisponde a uno degli hash della tabella, viene fatto un confronto completo del contenuto (per evitare false corrispondenze);
  • se anche il confronto completo da’ esito positivo, il mapping tra guest physical e host physical viene modificato, mappando la pagina della guest physical sulla pagina condivisa della host physical e recuperando la pagina, ora ridondante, dalla host memory.

La rimappatura della pagina è completamente invisibile alla VM e inaccessibile al sistema operativo guest.

Nella figura successiva riassumo l’algoritmo:

image

Nel momento in cui avviene una scrittura su una pagina condivisa, viene usata la tecnica del copy-on-write:

  • un tentativo di scrittura su una pagina condivisa genera un page fault minore;
  • il gestore dei page fault dell’hypervisor intercetta il page fault e crea in modo trasparente una nuova copia privata della pagina;
  • l’hypervisor mappa la pagina della guest physical in questione sulla nuova copia privata;
  • la VM può (finalmente) scrivere sulla pagina, che ora diventa una “normale” pagina di memoria in physical guest memory.

Il meccanismo di Transparent Page Sharing avviene in modo trasparente e continuativo anche in situazione di memoria non overallocata.

Un comportamento leggermente differente si ha nel caso il sistema abbia il supporto hardware alla virtualizzazione della memoria (come l’EPT di Intel o l’RVI di AMD): in questo caso ESX abilita automaticamente l’uso di pagine “larghe” (pagine da 2 MB al posto delle pagine normali da 4 KB) in host physical memory come “supporto” per le pagine di memoria di guest physical, questo viene fatto per avere performance migliori. Le pagine “larghe” però non vengono condivise. Nonostante questo ESX genera comunque gli hash per le pagine da 4 KB interne alle pagine da 2MB: ESX, durante l’host swap, non swappa pagine larghe, ma le spezza in pagine normali; l’hash pregenerato di queste pagine viene usato per condividerle prima di swapparle.

Riassumendo: ESX cerca costantemente la possibilità di condividere pagine identiche tra più VM, nel caso ne trovi sostituisce tutte le pagine con una unica, fa puntare tutte a questa e libera la memoria occupata dalle copie; non appena una VM tenta di scrivere su una pagina condivisa, viene creata una copia di questa pagina per la VM in questione.

Ballooning

Il ballooning è una tecnica completamente differente rispetto al transparent page sharing. Tramite il ballooning si rende il sistema operativo guest “consapevole” dello stato di ristrettezze di memoria dell’host: il sistema operativo guest non sa di essere virtualizzato e non e’ a conoscenza dello stato delle altre VM sullo stesso host, quindi non libererebbe memoria quando lo stato complessivo della memoria libera dell’host diventa troppo basso senza un meccanismo come il ballooning.

In ESX, tramite i VMware Tools, viene installato uno pseudo-device driver detto driver di balloon. Questo driver non ha interfacce di comunicazione esterne verso il sistema operativo guest ma comunica con l’hypervisor tramite un canale privato.

Vediamo come funziona il ballooning:

  • il balloon driver contatta a intervalli regolari l’hypervisor per ottenere la dimensione del  balloon;
  • se l’hypervisor ha bisogno di memoria, setta una dimensione per il driver di balloon, facendolo “gonfiare” allocando memoria guest physical all’interno della VM.
  • il driver di balloon alloca la memoria richiesta “bloccandola” (settandola in modo che non venga swappata su disco) tramite i meccanismi del sistema operativo guest;
  • una volta allocata comunica all’hypervisor quali pagine ha allocato cosi’ l’hypervisor possa recuperarle;
  • quando l’hypervisor decide di “sgonfiare” il driver di balloon, settando una dimensione minore, il balloon driver dealloca le pagine che si era riservato.

Tipicamente l’hypervisor gonfia il driver di balloon quando ha problemi di memoria: gonfiando il balloon, una VM consuma meno host physical memory ma piu’ guest physical memory. In pratica l’hypervisor diminuisce la sua pressione di memoria a scapito della pressione di memoria della VM. Il sistema operativo guest, in risposta a questo aumento di richiesta di memoria, attiva i suoi meccanismi e decide come liberare della memoria, eventualmente paginandola su disco.

Il ballooning ha alcuni problemi:

  • necessita l’installazione del balloon driver (contenuto nei VMware Tools, che comunque è buona prassi installare sempre);
  • il sistema operativo guest deve avere abbastanza spazio su disco per il suo swap file;
  • il ballooning può non liberare memoria abbastanza velocemente  da soddisfare le richieste;
  • è possibile che il limite massimo di memoria liberabile dal balloon sia limitato da limiti del sistema operativo guest.

Riassumendo: il ballooning recupera memoria “gonfiando” e “sgonfiando” un “palloncino di memoria” all’interno del sistema operativo guest, così che sia quest’ultimo a dover recuperare la sua memoria. Detto in altro modo: dato che l’hypervisor non può sapere che memoria è in uso o meno da parte della VM, fa si che sia chi ne è a conoscenza (il sistema operativo guest) ad occuparsi di liberarla.

Hypervisor swapping

Quando il ballooning e il transparent page sharing non sono sufficienti a recuperare la memoria, ESX utilizza direttamente lo swap. Alla partenza delle VM, l’hypervisor crea un file di swap per ognuna di esse. In seguito, se necessario, l’hypervisor può swappare la memoria guest physical nel file di swap, recuperando cosi’ della memoria host physical per le altre VM.

Questa tecnica, a differenza del transparent page sharing e del ballooning, è un modo garantito per recuperare memoria in un certo lasso di tempo, ma viene usato come ultima risorsa in quanto le sue performance soffrono di alcune limitazioni:

  • Problemi di selezione della pagine: in alcune situazioni lo swapping può penalizzare pesantemente le prestazione della vm: l’hypervisor non ha conoscenza di quali pagine siano da swappare e quali no (a livello di sistema operativo guest) e può quindi inficiare le politiche di gestione della memoria del sistema operativo guest;
  • Problema di doppia paginazione: è possibile che sia il sistema operativo guest che l’hypervisor siano in scarsità di memoria e quindi è possibile che entrambi swappino delle pagine con i loro rispettivi meccanismi, di fatto creando una situazione in cui una pagina precedentemente swappata dall’hypervisor, venga riportata in memoria  dallo swap dell’hypervisor per essere immediatamente swappata dal sistema operativo guest nel suo file di swap;
  • Alta latenza di swap-in: quando una pagina viene riportata in memoria dallo swap dell’hypervisor, la VM resta bloccata fino al completo caricamento dal disco. Questo introduce latenze, anche di decine di millisecondi, che possono degradare pesantemente le performance della VM.

Per mitigare l’impatto dell’interazione del meccanismo di swapping con i meccanismi di gestione della memoria del sistema operativo guest, ESX sceglie in modo casuale le pagine di memoria guest physical da swappare.

Riassumendo: l’uso dello swap da parte dell’hypervisor è “l’ultima spiaggia” in caso di necessità di recupero di memoria, è il meccanismo che penalizza di più le performance delle VM sia perché’ il disco è più lento della memoria, sia perché può interagire in modo negativo con i meccanismi di gestione della memoria dei sistemi operativi guest delle VM.

 

Con questo concludo la seconda parte di questa miniserie dedicata alle tecniche di gestione  della memoria di ESX 4.1. Nella terza parte illustrerò il nuovo meccanismo di compressione della memoria presente a partire da ESX 4.1

[tweetmeme only_single=”false”]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: