XtremIO: Garbage Collection? No, Grazie!

Il minimo da sapere.

Durante il  lancio il 14 novembre, per XtremIO, è stato affermato che non dispone di eventuali processi di Garbage Collection (da qui in avanti detto G.C.) a livello di sistema.   Questo però è stato interpretato  da alcune persone come se XtremIO fosse in qualche modo impermeabile alla necessità di G.C. Ovviamente non è possibile, tutti i dischi flash richiedono la procedura di G.C.  Ciò che conta è dove e come la G.C. è effettuata.  Con XtremIO, dovendo garantire prestazioni sempre coerenti e prevedibili, il processo di G.C.
viene gestito in maniera nuova e unica.

Quindi come mai XtremIO non richiede G.C. a livello di sistema, mantenendo prestazioni costanti e prevedibili?

... prima dobbiamo essere d'accordo sulla definizione di cosa è e cosa fà la G.C. 

Con un disco tradizionale i nuovi dati possono essere scritti proprio sopra quelli esistenti, nel senso che la testina cerca solo la posizione da sovrascrivere e ri-magnetizza con il nuovo contenuto. Con i dischi flash, i dati esistenti devono prima essere cancellati (un'operazione molto lenta) e quindi i nuovi dati possono essere "riprogrammati" in quelle celle. A peggiorare le cose c'è che non si può semplicemente cancellare esattamente ciò che si desidera. Immaginate di avere un "erase block" di 256 KB, per modificare solo 8K dell'intero blocco, si dovranno leggere tutti i 256KB, poi bufferizzarli, poi cancellare o modificare gli 8K, poi i 256KB aggiornati possono essere scritti sulla cella.

Questo viene anche detto "write amplification" (wikipedia > Write_amplification) e poiché i dischi flash hanno comunque un numero finito di cicli di Write , questo non và troppo bene, no?

... e per capire perché, dobbiamo tornare un pò indietro nella storia. 

Nel 2007-2008 fanno la comparsa i primi esemplari di dischi SSD: capacità minuscole, costosi, soggetti ad errori e a tutti i tipi di problemi di prestazioni quando i processi interni di G.C. partivano . Inoltre le performance precipitavano improvvisamente, il tempo di risposta oscillava selvaggiamente, e talvolta l'intero SSD tendeva a bloccarsi per diversi secondi. La Tecnologia nelle controller SSD "in quel tempo" era immatura e si iniziò allora  a pensare di realizzare un sistema "enterprise flash array", cercando schemi e procedure per per impedire loro di fare il proprio G.C. ad ogni costo .
Cosa si pensò? Di far scrivere un disco flash come un tradizionale disco con testina : grandi flussi sequenziali contenuti in un registro dell'array.  Questo metodo è stato utilizzato negli storage per i decenni per evitare che scritture casuali portassero le testine dei dischi a muoversi selvaggiamente.
Metodo che permette di incrementare le prestazioni se il disco è vuoto e lo spazio è facile da trovare. Quando lo spazio contiguo non è sufficiente si inizia a sovrascrivere i dati esistenti, che devono essere prima invalidati e "puliti": questa è la Garbage Collection.
Ed è per questo che molti disk array rallentano sostanzialmente con il riempimento dei dati utilizzati. Se si sceglie un approccio di questo tipo (anche detto "log-structured") per l'array flash, si può efficacemente indirizzare il flusso di dati verso gli SSD, ma alla fine si deve raccogliere un sacco di "garbage"per rendere disponibile spazio libero per le scritture in arrivo.
Molti produttori/fornitori di SSD decisero allora di scrivere algoritmi di G.C. proprietari internamente al disco SSD stesso. Nasce quindi nel 2009 XtremIO, basata in Israele,  con un prodotto di gran lunga superiore agli altri sul mercato: prestazioni costanti, nessuna variazione di latenza e nessun "singulto" nei tempi di risposta.
XtremIO inziò utilizzando SSD con la migliore routine di G.C. interna, e lo fa tutt'ora :-). Non si dovette preoccupare di sviluppare un processo a livello di array, ma si concentro' sulle altre funzionalità rendendo molto più snello, ad esempio,  il metodo di accesso ai dischi stessi e sfruttare veramente la natura ad accesso casuale dei Flash. Spinti dalla convinzione che chi meglio dei produttori di SSD conosce come sono fatti i propri "flash"? (...  il controller all'interno del disco SSD, ecc. ).
XtremIO,  però, esegue decine di migliaia di ore di rigorosi test sugli SSD che utilizza fornendo al cliente un prodotto completo (XtremIO) con prestazioni ed affidabilità certe.

... considerate che:

1. Su un sistema XtremIO sarà possibile facilmente sostituire le unità SSD con quelle di ultima generazione e via via di capacità maggiore da qualsiasi produttore che soddisfa le metriche di affidabilità e prestazioni definite. Non vi è alcun codice piattaforma-dipendente, perché non c'è bisogno di personalizzare la G.C. basata sulla architettura del flash specifico o firmware all'interno di un SSD.  Dovranno essere semplicemente qualificati i migliori SSD del settore, mentre altri produttori di array basati su G.C. a monte, devono adattare le loro routine di G.C. per ogni nuovo SSD che considerano adottare. Quindi, gli altri si concentrano sulla G.C. e attenzione, una volta che hai inserito e basato la tua architettura con G.C. a monte, sarà molto difficile modificarla.
2. Per ogni brick, XtremIO demanda le attività di G.C. a 25 ASICS dei 25 SSD e riserva il 100% delle coputing delle contreller all'I/O degli Hsots. E questo si verifica sia che XtremIO è pieno al 1% o 99%, sia che sia acceso da 5 mesi o da 5 anni. Come è possibile notare nel grafico seguente wIOPS e Latenza sono pressoché lineari a differenza di altri produttori di storage all-flash:

Sotto costante carico di I/O in un tipico data center, altri all-flash-array sostanzialmente degradano in termini di prestazioni.
Come vi sentireste se i vostri server virtuali rallentassero dopo pochi mesi di utilizzo?
O i tempi di risposta delle vostre applicazioni OLTP avessero dei singhiozzi?
IDC ha compilato una serie di raccomandazioni su come testare un all-flash-array in modo che questi effetti siano visibili in anticipo durante la fase di valutazione. (IDC : All - Flash Array Performance Testing Framew ork)

... alla fine 

Altri produttori continuano ad ottimizzare la G.C. a livello di array. Ma per EMC è un problema che ha cessato di esistere proprio come le televisioni CRT (wiki > crt) ; o il telefono rotativo (wikipedia).

Gli SSD moderni sono una tecnologia necessaria, ma non sufficiente a consentire prestazioni costanti e prevedibili. Devi anche avere una architettura a contorno con un modello a metadati (= per consentire la libertà di posizionamento dei dati in qualsiasi spazio libero disponibile nel disco SSD), un giusto modello di protezione dei dati (=ottimizzata per gli aggiornamenti al riempimento dell'array). Solo XtremIO ha queste prerogative.

Diamo quindi il merito a XtremIO per la decisione storica di evitare la G.C. a livello di sistema ed aprire una nuova era di tecnologie flash. Permettendo di innovare in diverse altre aree dell' array, come l'eliminazione "log-structured", lo sviluppo di modelli di metadati superiori, ed evolvendo da decenni di "predominio" del RAID.

Links:

XtremIO Content Addressing
XtremIO Dual-Stage Metadata
XtremIO Data Protection (XDP)
XtremIO In-Memory Metadata

By dtdavide