Storage Flash 101: come funziona un “disco” flash, considerazioni su XtremIO (it)

Este post también está disponible en Español

In questo post vedremo uno dei temi più interessanti della tecnologia flash; come funziona un “disco” flash.  E ‘ importante conoscere questi aspetti per avere una chiara idea del motivo per cui la tecnologia flash è una tecnologia completamente diversa di quella “tradizionale “,  che chiameremo dischi meccanici o rotazionali , e soprattutto è utile per capire il motivo per cui utilizzare un disco flash in una architettura tradizionale,  cioè  in uno storage che non è stato progettato per utilizzare tecnologia flash,  non è la soluzione migliore .

Cominciamo con il primo punto; come funziona un disco flash.

Possiamo immaginare un disco flash come un insieme di celle dove ci sono righe e colonne, più o meno come un foglio di calcolo Excel.

Storage Flash 101 nand cells
Storage Flash 101 nand cells

In questo schema, ogni cella viene caricata elettronicamente e in base al tipo, SLC ( Single Level Cell ) oppure MLC ( Multi Level Cell) è possibile memorizzare due valori rispettivamente (0,1) per il tipo SLC o 4 valori (0,1 , 2.3 ) per il tipo MLC.

Poiché i valori vengono memorizzati in una struttura simile a un foglio di calcolo, il tipo ad accesso casuale (random) è perfetto per questa tecnologia. È possibile accedere a qualsiasi cella con la stessa latenza.
Ora un punto importante; mentre l’accesso in lettura non è un problema e può sempre essere fatto con la stessa latenza, il processo di scrittura è qualcosa di completamente diverso perché: 1) non è possibile scrivere direttamente in una cella, diciamo piuttosto che non è possibile scrivere dei dati se la cella contiene già un valore e 2) non è possibile scrivere una sola cella alla volta, è necessario scrivere gruppi di celle, di solito 64K o 128K alla volta. Chiameremo a questo gruppo di celle una pagina.

Le difficoltà di sovrascrivere (“overwritting”):  immaginiamo di voler scrivere i dati su una pagina che è vuota, ora non c’è nessun problema,  i dati raggiungeranno il disco flash e sarà possibile scrivere la pagina in una sola operazione.

Immaginiamo invece che non c’è spazio ” adiacente ” per scrivere i dati, in questo caso sarà necessario leggere e spostare altrove i dati esistenti nella pagina che vogliamo sovrascrivere , cancellare i dati della pagina, disporre i dati nella memoria interna dell’array e, infine, scrivere l’intera pagina.

Il grafico seguente mostra come sarebbe questo processo conosciuto come  P/E (Program/Erasure)

Storage Flash 101 garbage collection
Storage Flash 101 garbage collection

Il processo di P/E può essere considerato come parte integrante dell’attività di Garbage Collection (GC), vale a dire, l’attività che tutte le unità flash devono fare per creare spazio prima di poter scrivere. La GC è un aspetto fondamentale della tecnologia flash che influenza direttamente il tempo di risposta (Response Time). Il RT durante la GC normalmente diminuisce perché il sistema deve dedicare risorse per creare spazio.

Essendo la GC un’attività che influisce sul rendimento dell’array , cosa è possibile fare per ridurre questo impatto? Vediamo alcune possibili soluzioni:

GC a livello del sistema operativo dell’array:  Quasi tutti gli array di tipo flash (AFA – All Flash Array) utilizzano in parte questa metodologia. Eseguire la GC a  livello del sistema operativo dell’array ha alcuni svantaggi.  Ad esempio, può accadere che l’array stia lavorando con determinato RT e ad un certo punto inizia l’attvità di GC. Poiché la GC è la priorità numero 1 (altrimenti non sarebbe possibile scrivere nuovi dati e il sistema non potrebbe continuare a lavorare), durante la GC  il RT inevitabilmente diminuisce.

GC a livello dei controller dei dischi flash: in generale i dischi flash possono eseguire una GC più efficace a livello dei controller degli stessi. Nessuno conosce meglio come eseguire la GC su un particolare disco flash che il produttore stesso. Inoltre, l’architettura di molti array di tipo AFA ha solo due controller di front-end con un numero limitato di potenza computazionale che sarebbe meglio non dover dedicare ad eseguire l’impegnativo lavoro di calcolo della GC.

Si consideri, inoltre, che i controllori di front-end devono anche prendersi cura di tutta una serie di funzioni quali copia dei dati, monitoraggio del sistema, ecc. Chiaramente, una tecnica basata sulla gestione della GC a livello dei controller dei dischi è più efficiente. Questo è il metodo utilizzato da XtremIO.

Il punto principale da tenere sempre presente è: tutti di dischi flash sono veloci, quando pensiamo ad uno storage con dischi flash assumiamo che avrà un alto rendimento (performance). Tuttavia, la caratteristica principale di un array di tipo flash non sono le performance, la caratteristica principale, quella che dovremmo considerare di più,  è la capacità dell’array di mantenere un basso e costante tempo di risposta (RT).

Perché un costante e basso RT è così importante? Immaginiamo di sviluppare un progetto (DB, custom application, ecc) in un flash array nuovo (appena comprato), dove c’è abbondanza di spazio a disposizione. Dopo diversi test, si vede che per eseguire un lavoro sono necessarie 3 ore. Diciamo che questo è un valore eccezionale soprattutto paragonato al tempo necessario per eseguire lo stesso lavoro in un array “tradizionale”, con dischi “meccanici”.

Sicuramente vorremmo che il tempo di esecuzione ottenuto quanto abbiamo testato l’applicazione il primo giorno sull’array flash nuovo si mantenga nel tempo, cioè, dopo mesi oppure anni l’applicazione sia performante come il primo giorno. Questo, purtroppo, non accadrà sugli array che gestiscono il processo della GC a livello di controller di front-end. Non appena comincerà il processo di GC il RT diminuirà  significativamente. Il processo di GC non può essere arrestato o posticipato, è la priorità numero 1 per consentire all’array di continuare a funzionare. Questo fenomeno può verificarsi più volte nello stesso giorno e sicuramente inizierà quando le celle flash dell’array saranno tutte scritte.

Si potrebbe pensare che per evitare il processo di GG potrebbe essere sufficiente non riempire completamente l’array, utilizzandolo per esempio al 50% o al 70 % della sua capacità.  In realtà, la tecnologia flash funziona in modo diverso, facendo in modo che “tutte” le celle di “tutti” i dischi vengano scritte nel modo più uniforme possibile. Se il nostro array è di 10TB e creiamo una LUN di 1TB non andremmo a scrivere solo su questo spazio di 1TB ma su tutta la capacità dell’array. Occuperemmo 1TB di dati, ma questi dati verranno distribuiti sui 10TB disponibili. Perché questo è così?

P/E & scritture uniformi: All’inizio di questo post abbiamo detto che non è possibile scrivere un blocco di celle “direttamente” se questo blocco contiene già dei dati, è necessario prima di tutto cancellare i dati presenti prima di poter sovrascriverli. Ci riferiamo a questo processo come cicli di P/E (Program/Erasure).

Secondo la tipologia di disco flash, il numero di cicli di P/E è un valore pre-determinato, di alcune migliaia di volte, 3000 cicli per i dischi flash tipo “consumer” chiamati anche cMLC (Consumer Multi Level Cell), utilizzati da molti vendor,  oppure 30.000 cicli per i dischi di tipo eMLC (Enterprise Multi Level Cell) quelli utilizzato da XtremIO

Ogni applicazione è in grado di fare migliaia di I/O al secondo, e in tal caso, un disco flash avrebbe una durata molto breve se scrivessimo gli stessi dati sulla stessa cella. Per minimizzare questo effetto, i dischi flash utilizzano internamente un sistema di “over-provisioning”, cioè, presentano all’host una capacità logica diversa (inferiore) di quella fisica effettiva.

Questo over-provisioning o livello di virtualizzazione viene utilizzato internamente dai dischi flash per “dirigere”  le scritture, per quanto possibile, sempre su celle diverse su TUTTO l’array utilizzando TUTTI i dischi dell’array indipendentemente se il nostro array è di 10TB e la nostra LUN di 1TB oppure di 10GB.

Numerosi documenti descrivono l’importanza di queste considerazioni. In particolare i seguenti documenti descrivono in dettaglio come eseguire un test di un flash array.

SNIA:

http://www.snia.org/sites/default/files/PeterMurray_SDC2014_Data%20Reduction_Final_rev.pdf

IDC:

http://idcdocserv.com/AFA_Performance_Testing_Framework_IDC_251951

XtremIO mantiene il RT costante nel tempo

In conclusione: Mentre tutti gli array che utilizzano dischi flash possono avere performance ottimali, l’aspetto principale che bisogna prendere in considerazione è quello di un RT basso e costante nel tempo. È il RT il valore fondamentale che ci permette di fare più lavoro in meno tempo e, soprattutto, un RT costante ci permette di pianificare correttamente che le nostre applicazioni saranno veloci oggi e lo saranno nel tempo .