Este post también está disponible en Español
In questo post prenderemo in esame una delle attività che presenta più sfide in un data center: il CDM. Detto in modo molto semplice, per CDM (Copy Data Management) si intende l’insieme di attività che devono essere fatte per creare copie dei dati. Fornire copie dei dati di produzione è importante per molte ragioni: la protezione dei dati, il backup, copie per gli ambienti di test e sviluppo, ecc,
Essere in grado di fornire in modo efficiente copie dei dati in un data center migliora il TCO e la capacità di eseguire più attività.
Siccome XtremIO è completamente diverso da qualsiasi altra tecnologia vista prima, per comprendere meglio i benefici dell’ iCDM è necessario prima “imparare” e “disimparare”.
Imparare e disimparare
Quando consideriamo i meccanismi di copia dei dati che conosciamo facciamo una serie di ipotesi, ma con XtremIO, dobbiamo pensare in modo diverso. Diamo un’occhiata a quello che dovete disimparare e imparare con XtremIO.
Disimparare: Impiegare molto tempo per le operazioni di copia Imparare: Copie istantanee
Disimparare: molto consumo di spazio Imparare: efficienza nell’utilizzo dello spazio
Disimparare: impatti sulle prestazioni Imparare: nessun impatto di performance
Disimparare: limitato numero di copie Imparare: elevato numero di copie
Disimparare: operazioni manuali Imparare: “orchestration”
Disimparare: cloni, snap Imparare: XtremIO Virtual Copies (XVC)
Copie dei dati in un ambiente applicativo
Consideriamo un tipico ambiente applicativo di un cliente per illustrare le sfide che questo presenta. Possiamo immaginare un ambiente come Oracle o SAP, sebbene qualsiasi altro ambiente presenti problemi simili. In un ambiente di database ci sono diverse applicazioni in esecuzione contemporaneamente. Ad esempio, nel caso di SAP, ciascuna di queste applicazioni necessita almeno di un “landscape” di Produzione e di un “landscape” di Progetto, cioè di 2 livelli. Il “landscape” di Produzione è costituito tipicamente da una serie di volumi; uno per lo sviluppo, almeno uno per l’ambiente di test, un altro volume per il controllo della qualità e, naturalmente, il volume di produzione. Quindi abbiamo un certo numero di oggetti nel sistema che sono “trasportati” tra i “landscape” e alla fine diventano produzione. Questo “trasporto” si riferisce a operazioni quali il “refresh” o l’aggiornamento dei volumi ed è qui dove XtremIO offre grandi vantaggi.
I volumi di produzione sono di solito sovradimensionati (overprovisioned) perché nessuno vuole esaurire lo spazio proprio in questo ambiente. Poi ci sono le diverse copie ed è qui soprattutto dove si consuma molto spazio; test1, test2, QA1, Q2, ecc. Il risultato è che, in questo modo, la richiesta di spazio storage è molto alta. Il risultato è che, a fronte di un ambiente di produzione che richiederebbe solo 10TB di spazio reale si finisce con più di 100TB. Qualcosa di molto costoso e inefficiente.
Nelle implementazioni di questo tipo, spesso l’ambiente di sviluppo non è una copia recente, i dati nei landscape sono molte volte obsoleti e ciò significa che è necessario eseguire una serie di “trasporti” verso l’ambiente di QA per verificare di volta in volta la bontà e gli impatti dello sviluppo effettuato prima che i dati possano finire in produzione. Se invece fosse fattibile lavorare nell’ambiente di sviluppo con un copia quanto più recente possibile, si incrementerebbe l’efficienza degli sviluppi riducendo al contempo il numero dei “trasporti”. Pensiamo anche alla complessità dei diversi volumi (copie) che a volte vivono in livelli di storage diversi per attenuare i costi. Con diversi livelli di storage intendo diverse tecnologie disco. È una pratica comune avere l’ambiente di produzione in dischi ad alte prestazioni (FC 15K, RAID-1), mentre gli ambienti di test su dischi di prestazioni inferiori (SAS 10K, RAID-5). A tal fine, spesso anche più di una piattaforma (array) può essere impiegata (anche da più di un fornitore). Gestire la crescita in questo modo è qualcosa veramente molto difficile. Inoltre, si testano le applicazioni su ambienti che non hanno le stesse caratteristiche prestazionali dell’ambiente di produzione con il risultato che non è possibile conoscere come l’applicazione si comporterà una volta in esercizio.
Meccanismi tradizionali di copia di dati
Vediamo brevemente i vari meccanismi di copia di dati finora conosciuti.
Cloni: Niente di nuovo qui. I cloni sono copie fisiche, byte per byte di un volume; si tratta quindi di una “brute force” copy. Sono molti i casi in cui siamo costretti ad usarli. Per esempio quando non è possibile o non si desidera avere impatti di performance sui volumi di produzione. In questi casi è necessario effettuare copie di dati completamente separate dai volumi di produzione. Quali sono gli svantaggi di questa tecnica? Molti: viene utilizzato uno spazio pari al volume da clonare, i cloni hanno bisogno di tempo per essere effettuati, e quindi questo limita la frequenza delle copie e l’agilità di tutto l’ambiente. Siccome fare copie di dati utilizzando questa modalità è molto costoso, spesso per i cloni vengono utilizzati dischi a basso costo (e prestazioni). Sfortunatamente, l’effetto finale è che le prestazioni dell’intero array diminuiscono perché sono necessarie più risorse per eseguire le copie, e non ultimo, non potendo contare su un ambiente veloce su cui eseguire le prove il ciclo di sviluppo è maggiore.
Snaps: Fondamentalmente ci sono due tecniche per gli snap; COW (Copy on First Write) e ROW (Redirect on Write).
COW: In questo tipo di implementazione, la creazione di una snap determina la definizione di un pool addizionale nell’array. Questo pool serve a memorizzare le nuove scritture destinate al volume di produzione. In pratica, ogni volta che una nuova scrittura è rivolta al volume di produzione, accadono due cose, 1- i dati “vecchi” vengono copiati nel pool della snapshot e 2- i nuovi dati vengono copiati nel volume di produzione. Si potrebbe pensare che quando tali operazioni vengono eseguite su dischi flash, grazie alle loro performance, tale attività non rappresenti un problema. In realtà non è così. Questo meccanismo porta ad un sovraccarico del sistema (ogni attività di scrittura implica l’esecuzione di due operazioni di I/O addizionali) che impatta sia il consumo dei dischi flash (diminuendone la durata; c.d. wearing) che le prestazioni dell’intero array (necessità fare di più I/O).
ROW: Il passo successivo nell’evoluzione della tecnologia di snap ha risolto alcuni dei problemi di performance attraverso la gestione dei metadati. In questo tipo di implementazione, quando si esegue una snapshot, i metadati (puntatori) del volume di produzione creano una seconda copia in un’area di memoria diversa nell’array. Lo storage mantiene in questo modo 2 aree di metadati; un’area per volume di produzione e un’area per la snap. Da questo momento in poi, ogni volta che c’è un nuovo dato da scrivere sul volume di produzione, il sistema modifica i metadati in modo che questi “puntino” alla posizione esatta dei dati sui dischi ma senza spostare i blocchi di dati del volume di produzione come accade nel meccanismo di ROW.
Questo tipo di implementazione è efficiente, ma ha ancora qualche problema: spesso, quando i dati vengono cancellati dal volume di produzione (attività che viene fatta eliminando i puntatori) possono rimanere blocchi di dati occupati nei dischi e questo necessita di un lavoro addizionale di “space-reclamation” che non sempre è efficace. Oltre a questo, nel caso di creazione di molti snap oppure snap di snap, l’accesso ai dati originali, la gestione del cambiamento dei metadati in questa struttura complessa e la riconciliazione dei metadati dopo aver cancellato le snaphsot, provocano una diminuzione notevole delle prestazioni.
XtremIO non utilizza nessuna di queste tecniche per eseguire snapshot. XtremIO utilizza un meccanismo diverso e nuovo rispetto a ciò che abbiamo conosciuto finora e per questo motivo verrà utilizzato il termine XVC (XtremIO Virtual Copies) per far riferimento alla modalità di fare snap in XtremIO.
XtremIO XVC: XtremIO utilizza un meccanismo di «contenitori» o aree di memoria e non necessita copiare i dati o i metadati durante la creazione di snapshot. Il risultato è che la creazione di snapshot in XtremIO è un’operazione istantanea.
Diamo un’occhiata al suo funzionamento. Nel disegno seguente possiamo notare i metadati (in-memory metadata) che rappresentano il volume di produzione. Questi metadati “puntano” ai blocchi di dati nei dischi dell’array.
Quando si crea una snap, XtremIO esegue le seguenti azioni: 1-«congela» l’area di metadati che fa riferimento al volume di produzione, 2-crea due nuovi contenitori (aree di memoria) vuoti (Production MD, Snapshot MD) che puntano all’area che prima veniva utilizzata per referenziare il volume di produzione. L’area di metadati del volume di produzione al momento della creazione dello snapshot è ora condivisa (shared) da i due nuovi contenitori appena creati. Uno di questi contenitori sarà d’ora in poi più il contenitore utilizzato per referenziare al volume di produzione, mentre l’altro sarà il contenitore della snapshot.
Se è necessario scrivere nuovi dati sul volume di produzione, questa attività verrà fatta utilizzando il nuovo container di produzione. Se invece è necessario scrivere nuovi dati sul volume di snap, XtremIO lo farà utilizzando il «conteiner» della snap. Logicamente, in entrambi i casi, XtremIO applicherà su ogni nuovo dato che arriva dall’host gli algoritmi di deduplica e compressione prima di scrivere i dati. Il risultato finale è che in molti casi non è necessario scrivere nulla sui dischi flash.
Vantaggi di questa implementazione: l’operazione di creazione di snap in XtremIO è istantanea e senza consumo di spazio disco o copia di metadati. Le snap sono, dal punto di vista delle prestazioni, pari al volume di produzione. Le snap consumano spazio soltanto quando vengono scritti dati nuovi che non possono essere deduplicati. Con la stessa procedura è possibile creare snap di snap senza perdere minimamente le prestazioni e senza copiare i dati e metadati. È possibile cancellare qualsiasi snap in qualsiasi ordine.
Business impacts e vantaggi per le applicazioni
Alla luce di queste informazioni, vediamo di nuovo l’ipotetico ambiente di copia di dati analizzato all’inizio del post appliccando le nuove conoscenze per capire quali vantaggi offre il meccanismo di snap di XtremIO.
Efficienza di spazio:
abbiamo detto che l’ambiente di produzione è di solito sovradimensionato per evitare di esaurire lo spazio. Se consideriamo un volume di produzione di circa 10 TB, per l’effetto di deduplica e compressione nativa di XtremIO, (ipotizziamo conservativamente – e per semplificare l’analisi – 2:1), la produzione occuperà circa 5TB. Come abbiamo visto, possiamo anche dire che le copie consumano in XtremIO 0 (zero) spazio al momento della creazione. Molti degli altri ambienti, test, sviluppo, QA sono copie del volume di produzione. In XtremIO queste copie, oltre a essere create istantaneamente, occuperanno uno spazio minimo. Lo spazio occupato dipenderà dal numero di nuovi dati globalmente non deduplicabili che sarà necessario scrivere nelle copie.
Eccellenti prestazioni per gli snap: tutti gli ambienti (copie) avranno le stesse prestazioni del volume di produzione, permettendoci così di significativamente ridurre i tempi di sviluppo e test. Avere l’ambiente di test con le stesse prestazioni dell’ambiente di produzione, permetterà a chi scrive l’applicazione di conoscere esattamente come questa si comporterà quando sarà in produzione.
Immediato “trasporto” dei dati: il trasporto (passaggio) di dati dagli ambienti di sviluppo a test, da test a QA e da QA a produzione è notevolmente facilitato grazie ad una interessante funzionalità del meccanismo XVC di XtremIO. Questa funzionalità viene chiamata “refresh” e permette, come indica il suo nome, di aggiornare un volume a partire da un altro. Per esempio, immaginate che abbiamo lavorato per un certo tempo sull’ambiente di sviluppo e vogliamo ora spostare o “trasportare” i dati all’ambiente di test. In un sistema tradizionale sarebbe necessario fare un back-up del volume di sviluppo e quindi eseguire un ripristino sul volume di test oppure creare un nuovo volume snap o clone dello sviluppo e montarlo come nuovo volume di test. Quest’ultima attività comporterebbe una nuova mappatura (mapping) del volume al server per vedere questo nuovo volume. XtremIO invece è abbastanza intelligente per memorizzare la mappatura dei dati di un volume, cioè l’iSCSI ID e riutilizzarlo durante la operazione di aggiornamento o “refresh”. In pratica, l’unica cosa da fare è dire che si desidera aggiornare il volume di test con i dati del volume di sviluppo (svil -> test) e XtremIO eseguirà l’operazione immediatamente, senza che sia necessario al server di eseguire un’altra scansione per vedere il volume con i nuovi dati. Basta solo sospendere per un istante (unmount) le operazioni sul volume nel momento in cui si esegue l’aggiornamento (“refresh”). Così, il trasporto tra i vari elementi (volumi) dell’ambiente può ora essere fatto utilizzando questa tecnica in modo estremamente semplice, veloce e soprattutto senza il rischio di errori. Naturalmente l’aggiornamento può essere fatto in qualsiasi direzione, dal volume di produzione a quello di sviluppo, oppure da quello di produzione a quello test e viceversa.
Ora che abbiamo fatto questa introduzione ai vari meccanismi di copia, siamo in grado di capire meglio il concetto di iCDM (gestione integrata copia dati). Possiamo fare un’analogia con la teoria dei quattro elementi fondamentali, elementi che, quando combinati tra loro, creano “qualcosa” di completamente nuovo. Nel nostro caso i 4 elementi sono: XVC, architettura di XtremIO, orchestrazione e API.
Architettura XtremIO di tipo scale-out: XVC sfrutta l’architettura scale-out di XtremIO che consente alle operazioni di copia di essere effettuate in memoria senza impatto sulle prestazioni.
Orchestrazione: Immaginiamo che vogliamo creare copie delle nostre applicazioni che siano coerenti dal punto di vista applicativo (“application consistent”). Ad esempio copie di database (Oracle, SQL Server) che non siano semplici copie (“crash copies”), ma copie dove è possibile ripristinare le transazioni ad un punto desiderato. Questo tipo di copie richiede una precisa interazione tra lo storage e l’applicazione, quello che viene chiamato “riconoscimento delle applicazioni” (application awareness). Nel caso di XtremIO lo storage awareness si ottiene grazie a un software, parte integrante de XtremIO e della strategia di iCDM.
Self-service provisioning: l’ultimo elemento nella strategia di iCDM è il “self-service provisioning”. Grazie alle API di XtremIO è possibile integrare qualsiasi tipo di software di gestione del data center con il processo di iCDM. In altre parole, immaginate di avere delle applicazioni non supportate direttamente da AppSync e volete comunque fare in modo che il meccanismo di copie sia automatico. Nessun problema; grazie alle API di XtremIO e grazie a diversi “plug-in” (Oracle, VMware), è possibile integrare le notre applicazioni in iCDM.
Per riassumere
iCDM è una soluzione unica che combina 4 elementi esclusivi di XtremIO per creare un nuovo paradigma nella gestione delle copie locali che consente di automatizzare, semplificare ed evitare errori nel processo di copia dei dati.
Per ulteriori informazioni:
XtremIO Integrated Copy Data Management (pdf)
XtremIO Integrated Copy Data Management (video)
#IWork4Dell
