Oggi parleremo di una tecnologia interessante implementata nel sistema di archiviazione Unity/Unity XT, il FAST VP. Se è la prima volta che senti parlare di Unity, puoi consultare le specifiche del sistema tramite il link alla fine dell'articolo. Ho lavorato nel team di progetto di Dell EMC su FAST VP per più di un anno. Oggi voglio approfondire questa tecnologia e rivelare alcuni dettagli sulla sua implementazione. Ovviamente, solo quelli che posso rivelare. Se sei interessato ai temi dell'archiviazione efficace dei dati o se semplicemente non hai ancora compreso a fondo la documentazione, questo articolo sarà sicuramente utile e interessante.
Dico subito cosa non sarà incluso nel materiale. Non ci sarà ricerca sui concorrenti e comparazioni con loro. Inoltre, non intendo parlarvi di tecnologie simili open source, perché un lettore curioso già le conosce. E, naturalmente, non ho intenzione di fare pubblicità.
Storage Tiering. Obiettivi e finalità di FAST VP
FAST VP sta per Fully Automated Storage Tiering per Virtual Pool. Complicato? Niente paura, ora lo spieghiamo. Il tiering è un modo di organizzare l'archiviazione dei dati, che prevede diversi livelli (tiers) in cui i dati vengono memorizzati. Ognuno ha le proprie caratteristiche. Le più importanti sono: prestazioni, capacità e costo di archiviazione per unità di informazione. Naturalmente, c'è una relazione tra di loro.
Una caratteristica importante del tiering è che l'accesso ai dati viene fornito in modo uniforme indipendentemente dal livello di archiviazione in cui si trovano attualmente, e la dimensione del pool è pari alla somma delle dimensioni delle risorse che lo costituiscono. Qui risiedono le differenze rispetto alla cache: la dimensione della cache non si aggiunge al volume complessivo della risorsa (del pool in questo caso), e i dati della cache duplicano un frammento dei dati del supporto principale (o lo faranno se i dati nella cache non sono ancora stati scritti). Inoltre, la distribuzione dei dati tra i livelli è nascosta all'utente. Cioè, non può vedere esattamente quali dati sono posizionati su ciascun livello, anche se può influenzare questo indirettamente, impostando politiche (di cui parleremo più avanti).
Ora diamo un'occhiata alle caratteristiche dell'implementazione dello storage tiering in Unity. In Unity si distinguono 3 livelli, o tier:
- Prestazioni estreme (SSD)
- Prestazioni (HDD SAS 10k/15k RPM)
- Capacità (HDD NL-SAS 7200 RPM)
Sono presentati in ordine decrescente di prestazioni e prezzo. Nel livello di Prestazioni estreme ci sono esclusivamente unità a stato solido (SSD). Negli altri due tier sono incluse unità su disco magnetico, distinte dalla velocità di rotazione e, di conseguenza, dalle prestazioni.
I dispositivi di memoria dello stesso livello e delle stesse dimensioni vengono uniti in un array RAID, formando un gruppo RAID (RAID group, in breve – RG); informazioni sui livelli RAID disponibili e raccomandati possono essere lette nella documentazione ufficiale. Dai gruppi RAID di uno o più livelli si formano pool di archiviazione (Storage pool), da cui viene poi distribuito lo spazio libero. Dallo pool viene quindi allocato spazio per i file system e i LUN.
E perché dovrei usare il Tiering?
In breve e in modo astratto: per ottenere risultati maggiori utilizzando il minimo delle risorse. Se vogliamo essere più specifici, il risultato di solito si riferisce a un insieme di caratteristiche dello storage – velocità e tempo di accesso, costo di archiviazione e altro. Il minimo delle risorse implica la spesa più bassa: denaro, energia e così via. FAST VP implementa precisamente meccanismi di ridistribuzione dei dati attraverso i diversi livelli nello storage Unity/Unity XT. Se mi credete, potete saltare il paragrafo successivo. Per gli altri, racconterò un po' più nel dettaglio.
Una corretta distribuzione dei dati tra i livelli di archiviazione consente di risparmiare sui costi totali dello storage, sacrificando la velocità di accesso a informazioni poco utilizzate, e di migliorare le prestazioni spostando i dati frequentemente usati su supporti più veloci. Qui qualcuno potrebbe obiettare che anche senza il tiering un buon amministratore sa dove collocare i vari dati, quali caratteristiche dello storage sono desiderabili per il suo compito, e così via. Questo è indubbiamente vero, ma la distribuzione ‘manuale’ dei dati ha i suoi svantaggi:
- richiede tempo e attenzione da parte dell'amministratore;
- non sempre riesce a ‘ridisegnare’ le risorse dello storage in base a condizioni mutate;
- Scompare un importante vantaggio: accesso unificato alle risorse su diversi livelli di archiviazione.
Per ridurre le preoccupazioni dei storage admin riguardo alla sicurezza del lavoro, aggiungo che una corretta pianificazione delle risorse è fondamentale anche in questo caso. Ora che le attività di tiering sono state brevemente delineate, vediamo cosa possiamo aspettarci da FAST VP. È ora di tornare alla definizione. Le prime due parole – Fully Automated – indicano che la distribuzione tra i livelli avviene automaticamente. E Virtual Pool è un pool di dati che include risorse da diversi livelli di archiviazione. Ecco come si presenta:
Anticipando, dico che FAST VP sposta i dati solo all'interno di un singolo pool, e non tra più pool.
Le attività affrontate da FAST VP
Iniziamo a parlare in modo astratto. Abbiamo un pool e un meccanismo che può ridistribuire i dati all'interno di questo pool. Tenendo presente che il nostro obiettivo è raggiungere le massime prestazioni, poniamoci la questione: quali modi ci sono per ottenerle? Ce ne possono essere diversi, e qui FAST VP ha molto da offrire all'utente, poiché la tecnologia rappresenta qualcosa di più del semplice tiering di storage. Ecco come FAST VP può aumentare le prestazioni del pool:
- Distribuzione dei dati su diversi tipi di dischi e livelli
- Distribuzione dei dati tra dischi dello stesso tipo
- Distribuzione dei dati durante l'espansione del pool
Prima di esaminare come vengono risolti questi compiti, è necessario conoscere alcuni fatti fondamentali sul funzionamento di FAST VP. FAST VP opera con blocchi di dimensione fissa – 256 megabyte. Questo è il minimo «pezzo» continuo di dati che può essere spostato. Nella documentazione viene definito proprio così: slice. Dal punto di vista di FAST VP, tutti i gruppi RAID sono composti da un insieme di tali «pezzi». Di conseguenza, tutte le statistiche di input/output vengono accumulate per questi blocchi di dati. Perché è stata scelta proprio questa dimensione del blocco e sarà ridotta? Il blocco è abbastanza grande, ma rappresenta un compromesso tra la granularità dei dati (dimensioni del blocco più piccole – distribuzione più precisa) e le risorse computazionali disponibili: con le attuali restrizioni sulla memoria e un gran numero di blocchi, i dati statistici possono occupare troppo spazio, e il numero di calcoli aumenterebbe proporzionalmente.
Come FAST VP distribuisce i dati nel pool. Politiche
Per gestire la distribuzione dei dati nel pool con FAST VP attivato, esistono le seguenti politiche:
- Tier più alto disponibile
- Auto-Tier
- Inizia alto e poi Auto-Tier (predefinito)
- Tier più basso disponibile
Essi influenzano sia il posizionamento iniziale del blocco (i dati vengono registrati per la prima volta) sia la successiva ridistribuzione. Quando i dati sono già posizionati sui dischi, la ridistribuzione sarà avviata secondo un programma o manualmente.
Il Highest Available Tier cerca di posizionare un nuovo blocco al livello più performante. In caso di insufficienza di spazio, passa al livello successivo in termini di prestazioni, ma poi i dati possono essere spostati su un livello più performante (se c'è spazio disponibile o sovrascrivendo altri dati). L'Auto-Tier posiziona nuovi dati a diversi livelli a seconda della dimensione dello spazio disponibile, e vengono ridistribuiti in base alla domanda e allo spazio libero. Start High then Auto-Tier è la politica predefinita e anche raccomandata. All'inizio funziona come Highest Available Tier, mentre successivamente i dati vengono spostati in base alle loro statistiche di utilizzo. La politica Lowest Available Tier mira a posizionare i dati al livello meno performante.
La migrazione dei dati avviene con bassa priorità per non interferire con il lavoro utile del sistema di archiviazione, tuttavia c'è un'impostazione denominata "Data relocation rate" che modifica la priorità. Qui c'è una particolarità: non tutti i blocchi di dati hanno la stessa priorità di redistribuzione. Ad esempio, i blocchi contrassegnati come metadati verranno spostati su un livello più veloce per primi. I metadati sono, per così dire, "dati sui dati", una sorta di informazione aggiuntiva che non è costituita dai dati degli utenti, ma ne descrive le caratteristiche. Ad esempio, informazioni nel file system su quale blocco contiene un file specifico. Quindi, la velocità di accesso ai dati dipende dalla velocità di accesso ai metadati. Considerando che i metadati sono generalmente molto più piccoli, ci si aspetta un guadagno maggiore dal loro spostamento su dischi più performanti.
I criteri che Fast VP utilizza nel lavoro
Il criterio principale per ogni blocco, in termini molto generali, è la caratteristica della "richiesta" dei dati, che dipende dal numero di operazioni di lettura e scrittura del frammento di dati. Questa caratteristica viene chiamata "Temperatura". Ci sono dati richiesti (hot) che sono più "caldi" rispetto a quelli non richiesti. Viene calcolata periodicamente, di default con un intervallo di un'ora.
La funzione di calcolo della temperatura ha le seguenti proprietà:
- In assenza di input/output, i dati nel tempo "si raffreddano".
- Con un carico più o meno costante nel tempo, la temperatura inizialmente aumenta e poi si stabilizza in un certo intervallo.
Successivamente vengono considerate le politiche descritte sopra e lo spazio libero su ogni tier. Per chiarezza, presento un'immagine della documentazione. Qui i blocchi con temperatura alta, media e bassa sono contrassegnati rispettivamente in rosso, giallo e blu.
Ma torniamo ai compiti. Quindi, possiamo procedere all'analisi di ciò che viene fatto per risolvere le attività FAST VP.
A. Distribuzione dei dati su diversi tipi di dischi, livelli
In effetti, questo è l'obiettivo principale di FAST VP. Gli altri, in qualche modo, derivano da esso. A seconda della politica scelta, i dati verranno distribuiti su diversi livelli di archiviazione. Prima di tutto si considera la politica di posizionamento, poi la temperatura dei blocchi e la dimensione/velocità dei gruppi RAID.
Per le politiche Highest/Lowest Available Tier è tutto piuttosto semplice. Per le altre due, la situazione è diversa. I dati vengono distribuiti su diversi livelli tenendo conto della dimensione e delle prestazioni dei gruppi RAID: in modo che il rapporto tra la 'temperatura' totale dei blocchi e la 'massima prestazione teorica' di ciascun gruppo RAID sia all'incirca lo stesso. In questo modo, il carico è distribuito in modo più o meno uniforme. I dati più richiesti vengono spostati su supporti più veloci, quelli raramente utilizzati su supporti più lenti. Idealmente, la distribuzione dovrebbe risultare più o meno così:
B. Distribuzione dei dati tra dischi dello stesso tipo
Ricorda, all'inizio ho scritto che i supporti informatici di uno o più I livelli vengono uniti in un unico pool? Nel caso di un livello singolo, c'è anche lavoro per FAST VP. Per ottimizzare le prestazioni di un livello, è meglio distribuire i dati uniformemente tra i dischi. Questo consentirà (in teoria) di ottenere il massimo numero di IOPS. I dati all'interno di un gruppo RAID possono essere considerati distribuiti uniformemente tra i dischi, mentre tra i gruppi RAID non è sempre così. In caso di squilibrio, FAST VP sposterà i dati tra i gruppi RAID in proporzione al loro volume e alla "prestazione condizionata" (in forma numerica). Per illustrare, mostrerò uno schema di ribilanciamento tra tre gruppi RAID:
Q. Distribuzione dei dati durante l'espansione del pool
Questo compito è un caso particolare del precedente e viene eseguito quando un gruppo RAID viene aggiunto al pool. Affinché il nuovo gruppo RAID non rimanga inattivo, parte dei dati verrà trasferita su di esso, il che comporterà una riorganizzazione del carico su tutti i gruppi RAID.
Allineamento dell'usura SSD
Grazie all'allineamento dell'usura, FAST VP può prolungare la vita degli SSD, anche se questa funzione non è direttamente collegata allo Storage Tiering. Poiché sono già disponibili i dati sulla temperatura e il numero di operazioni di scrittura è considerato, siamo in grado di spostare i blocchi di dati; quindi, sarebbe logico che FAST VP affrontasse anche questo compito.
Nel caso in cui il numero di scritture in un gruppo RAID superi significativamente il numero di scritture in un altro, FAST VP ridistribuirà i dati in base al numero di operazioni di scrittura. Da un lato, questo allevia il carico e preserva le risorse di alcuni dischi; dall'altro, aggiunge 'lavoro' per quelli meno caricati, aumentando le prestazioni complessive.
In questo modo, FAST VP si occupa delle tradizionali mansioni dello Storage Tiering e fa anche un po' di più. Questo permette di memorizzare i dati in modo piuttosto efficiente all'interno della famiglia di storage Unity.
Alcuni consigli
- Non sottovalutate la lettura della documentazione. Ci sono best practices, e funzionano piuttosto bene. Seguendole, di solito non sorgono problemi gravi. Gli altri consigli tendono principalmente a ripetere o ad integrare questi.
- Se hai impostato e attivato FAST VP, è meglio lasciarlo attivo. Lascia che distribuisca i dati nel tempo assegnato, piuttosto che una volta all'anno, influenzando notevolmente le prestazioni di altre attività. In questi casi, la ridistribuzione dei dati potrebbe richiedere molto tempo.
- Fai attenzione alla scelta della finestra di rilocalizzazione. Anche se è ovvio, cerca di scegliere un momento con il minor carico su Unity e assegna un sufficiente intervallo di tempo.
- Pianifica l'espansione del tuo sistema di archiviazione, fallo in tempo. Questa è una raccomandazione generale, importante anche per FAST VP. Se lo spazio libero è molto ridotto, il trasferimento dei dati rallenterà o diventerà impossibile. Soprattutto se hai trascurato il punto 2.
- Espandendo il pool con FAST VP attivo, non è consigliabile partire dai dischi più lenti. Quindi, si dovrebbe o aggiungere subito tutti i gruppi RAID pianificati, oppure iniziare con i dischi più veloci. In questo caso, la ridistribuzione dei dati sui nuovi dischi "veloci" aumenterà la velocità complessiva del pool. Altrimenti, se iniziamo con i dischi "lenti", potremmo trovarci in una situazione poco piacevole. Prima si trasferiranno i dati sui nuovi dischi relativamente lenti e poi, aggiungendo dischi più veloci, ci saranno spostamenti in senso opposto. Ci sono sfumature legate alle diverse politiche FAST VP, ma in generale tale situazione è possibile.
Se stai considerando questo prodotto, puoi provare Unity gratuitamente scaricando Unity VSA virtual appliance.
In conclusione, condivido alcuni link utili:
- Pagina
- – breve descrizione della funzione
- , formato pdf
Conclusione
Vorrei parlare di molte cose, ma capisco che non tutti i dettagli potrebbero interessare il lettore. Ad esempio, si potrebbe approfondire i criteri in base ai quali FAST VP decide di spostare i dati, riguardo ai processi di analisi delle statistiche di input-output. Inoltre, non è affatto stata toccata la questione dell'interazione con , il che meriterebbe un articolo a parte. Si potrebbe anche fantastico sullo sviluppo di questa tecnologia. Spero che non sia stato noioso e di non avervi stancato. A presto!
Fonte: habr.com
