Ormai praticamente tutta la blogosfera ha fatto post sul VAAI, Io non vi tedierò con una spiegazione in dettaglio di che cosa è il VAAI e perché è cruciale per la Virtualizzazione, vi rimando semplicemente ad alcuni post che ne spiegano in dettaglio l’implementazione attuale:
Il mio focus sarà su come vedo l’evoluzione del VAAI, focalizzandomi sulla sua implementazione lato storage.
Per spiegare il mio punto di vista farò una analogia con una feature che si trova comunemente negli storage array moderni le Point-in-Time Copies.
Le Point-in-time copies (alcune volte chiamate anche Snapshots) sono una feature veramente molto utile, forniscono, per un determinato dataset, un punto nel tempo fermo e consistente su cui si possono effettuare diverse operazioni come backups, duplicazioni di ambienti e tanto altro.
Tradizionalmente le copie PIT venivano realizzate utilizzando una tecnica chiamata Copy-On-Write che è pero’ solamente utilizzabile con un piccolo numero di PIT per ciascuna LUN in quanto le problematiche di performance subentrano immediatamente dopo la prima PIT. Il concetto di PIT è stato introdotto inizialmente da IBM con la sua funzionalità chiamata FlashCopy.
NetApp ha innovato l’approccio alle copie PIT utilizzando una tecnica differente basata sui puntatori, questa tecnica ha quasi completamente eliminato i problemi di performance ed ha permesso l’utilizzo di un numero massivo di snapshot multiple per ciascuna LUN abilitando completamente il potenziale del concetto PIT, questo post spiega come funzionano in dettaglio le snapshot basate su puntatori di Compellent Storage Center, ad ogni modo non è specifico per Compellent, praticamente tutti gli array di nuova generazione (come IBM XIV, NetApp FAS, 3Par InServ, Dell Equallogic, HP Lefthand e molti altri ancora) utilizzano lo stesso approccio.
Quindi abbiamo un bellissimo concetto (copie PIT) ma con molto del loro potenziale ancora bloccato dall’attuale implementazione (Copy-on-Write) e poi abbiamo un innovatore che abilita il pieno potenziale della funzionalità con una implementazione intelligente, e sono praticamente sicuro che il VAAI è ancora nella sua fase “Copy-on-Write” :-).
Come già sapete il VAAI è implementato utilizzando una estensioni del set di comandi SCSI, prendiamo per esempio una delle feature più richieste, la Hardware Offloaded Copy.
L’Hardware Offloaded Copy a mio avviso puo’ essere accelerata di 100000 volte, rendendo i task di clonazione una questione di pochi secondi, ecco come:
Tenete a mente come funziona una snapshot a puntatori e seguitemi nella spiegazione:
Una Virtual Machine da 16GB che risiede su un Datastore da 128GB viene acceduta normalmente da un host ESX.
A questo punto viene fatta dall’host una richiesta di Clone accelerata VAAI, lo storage array, anzichè fare una vera copia blocco-blocco crea semplicemente una “mappa” di puntatori della VM clonata su un’altra porzione del datastore, bloccando il suo spazio ma senza fare una sola vera copia di blocco, questa operazione richiederà lo stesso tempo di una normale snapshot: pochi secondi.
Poi l’host inizia a scrivere sulla nuova VM clonata ed il delta delle differenze vengono immagazzinate nei blocchi bloccati dalla “mappa” precedentemente creata.
Una operazione similare puo’ già essere fatta oggi utilizzando le snapshot, ma diventa immediatamente ingestibile perché ciascun clone deve risiedere sulla sua LUN e Datastore separati, questo approccio invece, puo’ essere applicato “all’interno” del datastore, razionalizzando il deploy. Immagina una infrastruttura VDI basata su questa tecnica di cloning! :-).
Sono sicuro che gli storage vendor cercheranno di integrare ed innovare le loro rispettive implementazione VAAI, spero che questo post vi faccia realizzare quanto potente può essere l’ancora poco maturo approccio VAAI.
Trackbacks/Pingbacks