Cerca nel blog

martedì 13 settembre 2011

Evoluzione di Storage vMotion


Storage vMotion è una funzionalità che permette lo spostamento a caldo del disco tra datastore senza causare downtime alle VM. Questa operazione avviene a “all’interno” di ESX/ESXi oppure “all’interno” dello storage array per quei prodotti che supportano l’accelerazione HW portata dalle VAAI. Questo articolo parla dell’evoluzione del prodotto, nel corso delle release di ESX/ESXi.
La prima versione di questo software è stata introdotta con la migrazione da ESX 3.x a ESX 3.0.1. L’aggiornamento comportava anche il passaggio dalla VMFS-2 alla VMFS-3 quindi, per evitare il downtime delle VM, è stata progettata questa funzione che ai tempi non veniva chiamata Storage vMotion. Nonostante questo specifico utilizzo, appariva già evidente quali altre strade questa feature avrebbe potuto prendere ed in effetti nel corso delle edizioni Storage vMotion si è evoluto molto significativamente.
Con ESX 3.5, Storage vMotion si basava sul meccanismo delle snapshot. Dopo il lancio del comando (al tempo via CLI oppure con plug-in di terze parti) veniva creata una snapshot sui dischi sorgenti della VM in modo tale che tutte le nuove scritture fossero dirottate sulla snapshot (dischi delta). In questa condizione il disco di base poteva essere spostato verso il datastore di destinazione. Al termine della migrazione i cambiamenti, catturati nei file delta delle snapshot, venivano committati sul VMDK nel nuovo datastore. Questo meccanismo risultava poco efficiente per le VM con uso intensivo dello storage, che faceva incrementare la crescita dei file delta e di conseguenza il tempo della commit, con il risultato che Storage vMotion poteva consumare una quantità considerevole di tempo.
Per queste ragioni Storage vMotion, nella versione ESX 3.5, veniva considerato uno strumento per le operazioni di straordinaria amministrazione come la sostituzione di una SAN o la riconfigurazione di un volume.
Con vSphere 4.x, grazie alle vStorage API, è stata introdotta una nuova  funzionalità chiamata Changed Block Tracking (CBT). CBT, tra le altre, incrementa le prestazioni di Storage vMotion in quanto elimina l’uso delle snapshot; di fatto con vSphere 4.x lo spostamento di VM con snapshot non era più supportato. Lanciato il comando i dischi della VM vengono copiati nel datastore di destinazione (opzionalmente è possibile smembrare le VM su datastore diversi); lo scopo di CBT è di tener traccia dei blocchi modificati dopo la prima copia. A questo punto inizia una copia, di uno o più passi, per applicare i blocchi modificati sul disco alla destinazione; durante il ciclo quando il numero del blocchi modificati è sufficientemente piccolo viene eseguita l’operazione di “Fast Suspend/Resume” che permette di trasferire l’esecuzione della VM sul datastore di destinazione. Anche in questo caso VM con I/O particolarmente intensivi potevano causare molti cicli di copia, risultando in un lungo tempo di esecuzione portando, in alcuni casi, al fallimento dell’operazione.
Con vSphere 4.x Storage vMotion estende il suo utilizzo in altri ambiti prima preclusi su ESX 3.5 quale la redistribuzione manuale delle VM su più datastore per equilibrare i carichi di lavoro.
In vSphere 5.0 lo spostamento con Storage vMotion avviene con una “copia in un singolo passaggio” grazie all’uso di Mirror Driver, un meccanismo che, dopo la prima copia, permette di sincronizzare tutti i cambiamenti avvenuti sul disco di destinazione. Non sono più quindi necessarie le copie ricorsive riducendo notevolmente i tempi dello spostamento. Storage vMotion in vSphere 5 reintroduce il supporto per lo spostamento di VM con snapshot e di VM linked clones.
vSphere5 apre nuove scenari per l’utilizzo di Storage vMotion come le tecniche per il bilanciamento automatico delle VM in base all’uso e/o al carico di lavoro; questa funzionalità si chiama Storage DRS.
Per maggiori informazioni consultare l’articolo: “vSphere 5.0 Storage Features Part 2 - Storage vMotion

Nessun commento: