Guest post di Tamir Segal, Senior PM
Le snapshot si basano su una tecnologia che permette la creazione di copie di volumi.
XtremIO ha sviluppato un processo d’integrazione di snapshot che consente di creare copie efficienti in termini di spazio; gestite come volumi standard nel cluster e con le stesse prestazioni e gli stessi data service dei volumi di produzione.
In questo post viene fornita una spiegazione generale dell'implementazione legacy di snapshot e vengono descritte le caratteristiche che contraddistinguono una "snapshot XtremIO".
Alcune informazioni di base
L'implementazione legacy di snapshot si basa su una tecnologia nota come Copy-On-First-Write, secondo cui la creazione di una snapshot determina la definizione di un nuovo storage pool all'interno del sistema.
Ogni scrittura nel volume di produzione comporta un movimento di dati per il pool di snapshot:
- Una nuova scrittura viene ricevuta dal sistema sull'LBA X
- Il sistema legge i dati originali sull'LBA X dal volume di produzione
- Il sistema scrive i dati nel pool di snapshot sull'LBA X
- I dati LBA X sul volume di produzione vengono sovrascritti con quelli nuovi
Ciò significa che ogni attività di scrittura implica l'esecuzione di due ulteriori operazioni I/O.
Si potrebbe pensare che nel caso di supporti con prestazioni elevate, come ad esempio un'unità SSD, questo metodo non causi problemi. Purtroppo non è così.
Tale approccio determina overhead significativi nella gestione dei movimenti di dati, influisce sulla latenza delle operazioni di scrittura e lettura, limita le funzionalità/prestazioni delle snapshot e influisce negativamente sulla resistenza dei supporti SSD.
La fase successiva nell'evoluzione della tecnologia di snapshot ha risolto alcuni problemi di prestazioni attraverso l'implementazione del metodo ROW (Redirect-On-Write), per cui è prevista la gestione dei metadati. Per ogni LBA (o serie di LBA) esiste un sistema basato su puntatore; ogni volta che si effettua una nuova scrittura il sistema scrive i dati una sola volta ed esegue l'aggiornamento dei metadati in modo che puntino alla posizione esatta dei dati.
In alcune implementazioni di ROW i nuovi dati aggiunti al volume di produzione vengono conservati nel pool di snapshot; di conseguenza, in caso di eliminazione di una snapshot, i dati di produzione devono essere riportati nello storage del volume di produzione.
Inoltre, in caso di creazione di più snapshot, l'accesso ai dati originali, il monitoraggio delle modifiche ai metadati nell'intera struttura ad albero di snapshot e la riconciliazione, dopo l'eliminazione delle snapshot, causano un notevole peggioramento delle prestazioni.
Per ottenere una copia dei volumi si utilizzano anche altre tecnologie.
- I cloni forniscono una copia completa dei dati, eseguita in genere a partire da una snapshot statica.
- Gli split mirror vengono impiegati per creare cloni più efficienti da un'origine dinamica.
In passato si tendeva a creare e usare le snapshot per brevi periodi di tempo, generalmente per creare una copia di dati di produzione in tempo reale ai fini di backup. Gli amministratori bloccavano momentaneamente l'applicazione di produzione, eseguivano una snapshot e riprendevano le normali attività. Il risultato era una copia statica dei dati di produzione a cui si accedeva in genere in modalità di sola lettura e di cui si eseguiva il backup su un dispositivo di backup esterno.
I motivi alla base dell'utilizzo delle snapshot per brevi periodi di tempo includono problemi di prestazioni, considerazioni sull'utilizzo della capacità e numero limitato di snapshot supportate.
Successivamente, grazie allo sviluppo delle tecnologie ROW, i tempi di utilizzo delle snapshot vennero estesi, soprattutto in relazione ai processi di test e sviluppo. Tuttavia, il loro impiego rimase limitato, in quanto in alcuni casi le prestazioni risultavano compromesse.
Due le possibili cause:
- l'implementazione Copy-On-Write di snapshot che registravano un notevole peggioramento delle prestazioni per l'ambiente di produzione
- oppure l'implementazione ROW, che aumentava la latenza di lettura come conseguenza della scansione dei dati di metadati collegati nell'array o degli overhead sulle CPU dei controller.
È opportuno sottolineare che il problema delle prestazioni non può essere risolto con un'architettura a doppio controller legacy e, a maggior ragione, con un'architettura active-passive.
Il motivo principale è che nella gestione di ogni volume/snapshot viene attivato un solo controller. Non ci sono margini per la scalabilità e un alto numero di snapshot e volumi di produzione comporta un overhead considerevole sul controller, che influisce poi sulle prestazioni degli snapshot, dei volumi di produzione o di entrambi.
XtremIO, tuttavia, offre un'architettura scale-out avanzata. Gli "Storage Controllers" nel cluster XtremIO vengono costantemente utilizzati per la gestione dei metadati e del flusso di dati (I/O), indipendentemente dal tipo di entità (snapshot o volume di produzione). Ciò implica maggiore potenza della CPU, disponibilità di memoria (un solo controller rispetto a più controller) e distribuzione equa del carico di lavoro su tutte le risorse disponibili.
In cosa differiscono le snapshot XtremIO?
Poiché una snapshot XtremIO è strettamente integrata nell'architettura dell'array XtremIO, trae vantaggio dai metadati in memoria e dai metadati a due fasi.
Usufruisce inoltre di una struttura di dati in grado di supportare la creazione rapida di una snapshot che offra le stesse prestazioni dei volumi di produzione, sia nelle operazioni di lettura che di scrittura e a prescindere dal livello di espansione o profondità della sua struttura ad albero.
XtremIO attua una variazione dell'architettura di snapshot ROW in cui tutti i reindirizzamenti dei blocchi vengono gestiti nella memoria dell'array, che diventa così flessibile, veloce ed efficiente.
Inoltre, qualsiasi scrittura su snapshot o volumi di produzione nel cluster segue lo stesso processo:
- viene contrassegnata tramite fingerprint,
- deduplicata con la deduplica in linea XtremIO
- e scritta nel storage pool globale.
Dall'unione tra l'esclusiva tecnologia di snapshot di XtremIO e una metodologia di gestione delle snapshot semplice e senza problemi, nasce la snapshot XtremIO.
Un altro algoritmo implementato nella tecnologia di snapshot di XtremIO è la funzionalità di ottimizzazione dell'utilizzo della capacità, nota come rimozione delle scritture di shadowing.
Immaginiamo che un utente scriva l'intero spazio degli indirizzi del volume P (step 1) e crei quindi una snapshot su P (step 2). Il volume P e la snapshot non contengono metadati né dispongono di capacità in quanto non è stata ancora eseguita la scrittura di dati nuovi. Supponiamo ora che vengano scritti nuovi dati sull'LBA 4 sia della snapshot sia del volume di produzione (step 3).
I dati e i metadati dell'entità principale nell'LBA 4 non sono più necessari perché vengono nascosti dalle nuove scritture e possono quindi essere liberati dal cluster (step 4). Questo metodo consente di sfruttare al meglio la capacità fisica e di migliorare l'utilizzo complessivo delle risorse del cluster.
Step 1: scrittura dell'intero spazio degli indirizzi del volume P
Step 2: creazione di una snapshot sul volume P
Step 3: sovrascrittura dell'LBA 4 sulla snapshot e sul volume P
Step 4: rimozione delle scritture nascoste, rilascio dei metadati e delle risorse fisiche di LBA 4 dall'entità principale
Che cosa significa tutto questo?
In primo luogo, l'approccio di XtremIO alle snapshot è diverso, in quanto ogni snapshot eseguita nel cluster viene visualizzata come un volume di lettura-scrittura. Pertanto, la sua gestione risulta identica a quella di un qualsiasi volume nel cluster e le operazioni di mapping o eliminazione vengono eseguite allo stesso modo di quelle di un volume di produzione.
In secondo luogo, le snapshot dispongono degli stessi data service dei volumi; in particolare, le funzionalità di deduplica globale in linea e thin provisioning sono costantemente attive.
Infine, le snapshot sono efficienti perché utilizzano la memoria solo per le nuove scritture e lo spazio fisico solo per i dati specifici che non possono essere deduplicati. La creazione di una snapshot è rapida perché non coinvolge metadati né comporta movimenti di dati.
Tutti i controller dello storage e le risorse del cluster vengono impiegati nel flusso di dati, sia per il volume che per le relative snapshot. Tutte le risorse disponibili vengono distribuite sempre equamente, evitando in tal modo la creazione di colli di bottiglia nel cluster.
Inoltre, le snapshot sono rapide ed è possibile ottenere prestazioni prevedibili e uniformi su volumi di produzione o snapshot.
Perché è importante che le snapshot siano gestite come i volumi?
Grazie a questo metodo, le operazioni di creazione e gestione delle snapshot non causano problemi.
Per accedere a una snapshot non è più necessario eseguire un doppio processo di creazione di istanze e clonazione. Non occorre gestire i pool per assicurare lo spazio sufficiente per le snapshot e non è necessario definire i data service sulle snapshot.
Una volta creata, la snapshot viene visualizzata come volume nel cluster e non rimane altro che eseguirne il mapping.
Il gioco è fatto, si ottiene una copia dei dati scrivibile e leggibile, dalle prestazioni elevate e accessibile dal server.
La creazione di una snapshot prevede un semplice processo a tre fasi:
- Fase 1: Selezionare l'entità di origine (volumi, snapshot, set di volumi/snapshot o una cartella), fare clic con il pulsante destro del mouse e selezionare Create Snapshots.
- Fase 2: Assegnare un nome alla snapshot, quindi selezionare la cartella di destinazione.
- Fase 3: Eseguire il mapping della snapshot esattamente come per qualsiasi volume nel sistema
Nota: le snapshot vengono visualizzate come volumi nella stessa schermata dell'interfaccia utente. Differiscono solo per l'icona associata e per il fatto di disporre di un'entità precedente, come illustrato di seguito:
Nessun impatto sulle prestazioni: è davvero possibile?
La risposta è sì.
XtremIO utilizza una struttura di dati collegati nella memoria dell'array per gestire tutti i metadati richiesti per le snapshot. Solo le nuove scritture usano i metadati. I blocchi non scritti non vengono allocati oppure sono utilizzati dalla struttura di dati collegati degli elementi principali.
Ciò significa che non viene eseguita alcuna copia di metadati nel processo di creazione di una snapshot.
Inoltre, il processo di creazione è particolarmente rapido. Per evitare complesse scansioni in memoria dei metadati, l'array gestisce una struttura di dati di tipo bitmap per LBA che semplifica il mapping di collegamento dell'area in cui risiedono i dati nella struttura di dati associata.
Di conseguenza, le operazioni di lettura richiedono lo stesso tempo, indipendentemente dalla struttura gerarchica delle snapshot (estensione o profondità) e registrano le stesse prestazioni di lettura e scrittura del volume di produzione. Per abilitarla non è necessaria alcuna configurazione, ottimizzazione manuale o impostazione particolare.
È quindi possibile creare una snapshot di una snapshot? Come funziona?
Sì, è possibile ottenere una serie infinita di snapshot a cascata con elevati livelli di profondità, ampiezza e altre caratteristiche.
Poiché si possono gestire le snapshot esattamente come se fossero volumi, è possibile crearle da qualsiasi volume o snapshot all'interno del sistema, senza alcuna limitazione.
La snapshot di una snapshot non è che un ulteriore volume a cui è possibile accedere in modalità di lettura/scrittura.
Per eseguire questa operazione, è sufficiente fare clic con il pulsante destro sulla snapshot, selezionare Create Snapshots e assegnare un nome alla snapshot creata.
Quest'ultima verrà visualizzata nella sezione dei volumi del cluster:
È anche possibile visualizzare la snapshot nella vista gerarchica. È sufficiente fare clic con il pulsante destro del mouse su un volume qualsiasi e selezionare Show as Snapshot Hierarchy come illustrato di seguito:
In questo modo si ottiene una vista gerarchica della struttura ad albero della snapshot, come illustrato di seguito:
Non esistono limiti alla topologia di una snapshot, che può presentare un grado di profondità e ampiezza variabile a seconda delle necessità, come illustrato di seguito:
Se un'applicazione viene eseguita su più volumi, è possibile creare una snapshot uniforme in senso trasversale?
L'esecuzione di snapshot uniformi in senso trasversale si può ottenere selezionando un set di volumi da copiare in un'unica operazione oppure eseguendo la snapshot di una cartella o di un'entità in cui è raggruppato un set di volumi.
Il risultato di questa operazione è una snapshot per ciascun volume nel set e ognuna viene visualizzata come volume nel cluster.
Opzione 1: Selezionare un set di entità per la creazione di una snapshot uniforme in senso trasversale:
Opzione 2: Eseguire la snapshot di una cartella
Ovviamente è possibile usare l'interfaccia a riga di comando (CLI) e l'interfaccia REST per la creazione di una snapshot uniforme in senso trasversale.
L'uso di queste due interfacce favorisce l'integrazione con l'applicazione o una metodologia di gestione più sofisticata per le snapshot.
Cosa accade a una snapshot se si elimina il volume di produzione?
È possibile eliminare qualsiasi volume o snapshot all'interno di una gerarchia di snapshot senza limitazioni e senza influire in alcun modo sulle altre snapshot. Ciò vale anche quando si elimina una snapshot nidificata all'interno della gerarchia. Tutte le snapshot che sono state eseguite prima o dopo la creazione della snapshot rimangono nel cluster.
Eliminazione di un volume nidificato nella gerarchia di snapshot:
Inoltre, l'eliminazione di un volume o di una snapshot nidificati non ha ripercussioni sulle prestazioni e non rallenta il cluster (il numero di IOPS o la latenza rimangono invariati).
Quali sono gli use case supportati per le snapshot e gli ambiti di utilizzo migliori?
Le snapshot possono essere usate per svariati use case, tra cui i seguenti:
- Backup: è possibile usare le snapshot per le operazioni di backup su un dispositivo di backup esterno
- Protezione dal danneggiamento logico: si possono creare più snapshot su brevi intervalli di tempo e poi utilizzarle per eseguire il ripristino in caso di danneggiamento logico dei dati
- Test e sviluppo: la creazione di più copie (snapshot) del volume di produzione risulta utile ai fini di test e sviluppo
- Ripartizione del carico di elaborazione (ETL, analisi quasi in tempo reale): la creazione frequente, o a seconda delle necessità, di una copia (snapshot) dei dati di produzione e la possibilità di accedervi per la ripartizione del carico di elaborazione consente alle risorse non di produzione del server di ottenere rapidamente l'accesso alle copie più recenti dei dati di produzione.
Nell'ambito della ripartizione del carico di elaborazione, è possibile trasferire il carico dell'ETL o dei processi analitici da un server di produzione a un altro server.
Dato che le snapshot possono essere create e aggiornate facilmente, è possibile:
- Creare snapshot in tempi relativamente brevi
- Ottenere latenza e IOPS con prestazioni Flash dalle copie dei dati di produzione
Il vantaggio che ne deriva è il consolidamento della produzione con le altre applicazioni business-critical e l'esecuzione di processi ETL o di analisi quasi in tempo reale senza consumo di risorse da parte del server di produzione a prestazioni particolarmente elevate.
XtremIO è la soluzione perfetta per le operazioni di test e sviluppo. Perché?
Il motivo è la combinazione dei fattori seguenti:
- Il risparmio ottenuto dalla deduplica in linea e dal thin provisioning
- L'alto numero di snapshot supportate
- Tutto il supporto illimitato e auspicabile della topologia di snapshot
- La semplicità di aggiornamento delle copie
È possibile creare ed eliminare più copie senza alcuna limitazione. Poiché i dati di sviluppo vengono deduplicati senza problemi, l'utilizzo della capacità fisica è minore.
L'esempio illustrato in precedenza mostra un piano di implementazione di test e sviluppo basato sull'ambiente reale di un cliente. Il supporto di una tale configurazione in un array legacy determina centinaia di terabyte, grossi limiti di prestazioni e tempi di aggiornamento estremamente lunghi.
I costi di un numero elevato di copie su un dispositivo non-XtremIO (come illustrato in precedenza) sono particolarmente elevati.
Una configurazione XtremIO a due X-Brick (basata su X-Brick da 20 TB) è la soluzione ideale per supportare l'impostazione illustrata in precedenza. Questo particolare cliente stava risparmiando centinaia di terabyte in un array high-end al costo di un'implementazione di test e sviluppo.
Il risparmio sui costi relativi all'hardware, oltre al miglioramento del servizio (prestazioni, operatività, gestione e così via) e alla facilità d'uso, rendono il ROI estremamente interessante.
Inoltre, il livello di prestazioni e la semplicità di utilizzo delle snapshot possono generare nuovi stimoli. Un nostro cliente che ha da poco eseguito un'implementazione di test e sviluppo su XtremIO ha ricevuto la seguente osservazione da parte del suo team:
"La nostra soluzione di test e sviluppo è molto più rapida del nostro array di produzione. Sarà necessario trovare una soluzione...". :-)
Qui potrete seguire la XtremIO Snapshot Demo (from Itzik Reich on Vimeo)
by @dtdavide
Nessun commento:
Posta un commento