Elementi di base della Flash Virtualization Platform (FVP), parte 2. Uso della propria piattaforma o file system

Uno degli argomenti che ho discusso con Satyam e Murali Vilayannur è stato il file system utilizzato per archiviare i dati su dispositivi flash. I seguenti fatti degni di nota dovrebbero essere tenuti a mente: Satyam ha creato VMFS3, Murali è stato il principale sviluppatore di VMFS5. Da questo punto di vista, l'uso di VMFS sembrerebbe ovvio. Tuttavia, la grande sorpresa per me è stata il fatto che per i dispositivi flash non utilizziamo VMFS, una sorpresa ancora più grande è stata che non usiamo affatto il file system.

Perché non VMFS?
I file system forniscono funzionalità che non sono necessarie e talvolta persino in conflitto con i requisiti della piattaforma che elabora l'I / O attivo su dispositivi flash. Uno dei maggiori problemi con l'utilizzo di un file system simile a VMFS su un dispositivo flash è che è ottimizzato per i sistemi di archiviazione SAN e i loro modelli di gestione dei dati; Satyam ha scritto un articolo su questo per ACM mentre lavora in VMware. Sfortunatamente, questo rende il file system uno strumento inappropriato per le attività FVP.

I file system con indirizzo diretto sovraccaricano i dispositivi flash, riducendone la durata, non elaborano in modo ottimale operazioni di I / O arbitrarie, testano i loro algoritmi di raccolta dei rifiuti (spesso molto fragili) e i loro oggetti (file e directory) sono meno adatti per livello della macchina virtuale e gestione della qualità del servizio, che è estremamente importante per le attività FVP. La prossima sezione descriverà in dettaglio il problema della gestione dei dati sui dispositivi flash, ma per ora una breve conclusione: se il dispositivo flash è costoso per te, non inserire un file system di indirizzamento diretto su di esso.

I file system offrono anche funzionalità che superano di molto le esigenze di FVP. Ad esempio, i blocchi del disco. VMFS ha un gestore di blocco distribuito avanzato che controlla l'accesso ai diversi host ESXi ai dischi. FVP gestisce i dischi locali dell'host e non richiede blocchi su altri host, di conseguenza il gestore dei blocchi distribuiti diventa completamente superfluo. Lo stesso si può dire della compatibilità POSIX e delle transazioni distribuite. E così via

Operazioni flash di basso livello
Ecco un esempio di come la scrittura su dispositivi flash è fondamentalmente diversa dalle registrazioni su hard disk. Flash non può sovrascrivere i dati esistenti. I dati nella memoria flash possono essere scritti solo su una pagina vuota. Una caratteristica della memoria flash è che la registrazione può essere fatta per pagine e la cancellazione può essere fatta solo in blocchi. Cos'è una pagina e cos'è un blocco? Flash archivia i dati nelle celle; le celle sono combinate in pagine (4 KB); le pagine sono raggruppate in blocchi. La maggior parte dei produttori combina 128 pagine in un blocco. Se si desidera cancellare la pagina, è necessario cancellare l'intero blocco. Tutti i dati necessari da altre pagine devono essere salvati altrove. È noto che i dispositivi flash hanno un numero limitato di cicli di scrittura e cancellazione.

Di conseguenza, una scrittura I / O casuale può avere un impatto maggiore di quanto si pensi. Il problema è che la maggior parte dei file system sono stati sviluppati negli anni '80 e '90 e da allora non sono più progrediti. I file system non tengono conto del degrado delle prestazioni che causano ai dispositivi flash utilizzando operazioni di basso livello progettate per i dischi rigidi; La maggior parte dei produttori di dispositivi flash implementa vari meccanismi per tenere conto del degrado progressivo delle prestazioni. Con l'aiuto di diversi schemi, consideriamo questi meccanismi e scopriamo perché la frammentazione ha un tale effetto sui dispositivi flash.

Gestione dell'usura
Nota, per semplicità, ho deciso di mostrare 9 pagine in un blocco invece di 128 pagine per blocco.

Cominciamo con il processo di gestione dell'usura. In questo esempio, l'applicazione ha già creato i dati e li ha registrati nelle pagine A, B e C nel blocco 1 (Passaggio 1). Arrivano nuovi dati (passaggio 2), che viene scritto nelle pagine D, E e F. L'applicazione aggiorna i dati precedenti (CA) e invece di utilizzare le pagine precedenti, il dispositivo flash continua a utilizzare le nuove pagine. Questi nuovi dati sono etichettati A-1, B-1 e C-1. La distribuzione dei record nel modo più uniforme possibile è chiamata "gestione dell'usura". Le vecchie pagine sono ora contrassegnate come scadute.

Garbage collection e voci multiple
In questo esempio, il blocco A è pieno, cosa succede se lo spazio disponibile per la registrazione è esaurito e arrivano nuovi dati?

Flash copia i dati correnti in celle vuote. I dati effettivi nel blocco vengono letti e scritti in un altro blocco. I dati scaduti rimarranno nelle sue pagine e verranno cancellati insieme al resto delle pagine di blocco. Questo processo si chiama "garbage collection".

La garbage collection va bene, ma la voce multipla che si verifica durante il suo funzionamento provoca danni significativi ai dispositivi flash. Per registrare 3 pagine, il dispositivo flash deve leggere 6 pagine e scrivere le 6 pagine in un altro posto prima di poter scrivere nuovi dati. E non dimenticare il ciclo di cancellazione. Supponiamo uno scenario in cui il disco è pieno, dove sposteremo (temporaneamente) i dati prima di registrarne di nuovi? Nel mio diagramma, ho aggiunto il blocco B per questa opzione. Per fare ciò in una situazione reale (quando si utilizza il file system), è necessario allocare lo spazio in eccesso riservato dal controller flash.

Spazio in eccesso
La capacità del flash può essere riservata ai processi gestiti da un controller flash. Questo può essere fatto sia dal produttore del dispositivo flash che dall'utente. Ad esempio, quando si acquista un acceleratore PCIe flash da 160 GB, infatti, si ottiene una scheda da 192 GB. 160 GB sono disponibili per l'utente e 32 GB sono riservati in aggiunta per le operazioni a livello di controller a livello di flash, come la garbage collection, la correzione degli errori e il firmware del controller. Quando si acquista un'unità SSD non industriale, di solito si ottiene un po 'di spazio in eccesso riservato. Quando si formatta questo dispositivo flash in qualsiasi file system, è necessario essere consapevoli di queste funzionalità e, possibilmente, riservare spazio aggiuntivo al di fuori della capacità disponibile. Al momento non ci sono consigli di ridimensionamento standardizzati, quindi devi fare delle scelte in base alla tua esperienza. Nel peggiore dei casi, ti ritroverai con un disco frammentato e l'SSD dovrà trasferire costantemente i dati per scriverne di nuovi. Immagina i bambini che giocano a tag, solo il modello di movimento è un po 'più complicato.

Riconsiderare la gestione dei dati su dispositivi flash
Gli ingegneri PernixData hanno sviluppato un nuovo formato per la gestione dei dati su dispositivi flash per FVP. I dettagli saranno divulgati nei seguenti articoli e ora alcuni punti fondamentali.

Ottimizzato per il flash
Il formato è progettato per archiviare i dati I / O temporanei con il set minimo possibile di metadati e lavorare con un dispositivo flash con le massime prestazioni disponibili. Converte voci casuali in successive, per sfruttare le prestazioni flash più elevate in modalità di scrittura sequenziale. Ciò riduce il numero di sovrascritture di dati ridondanti e di cicli di cancellazione. E l'algoritmo non contiene le limitazioni ereditate dei file system, come blocchi di grandi dimensioni, directory, file, transazioni lunghe, gestori di blocchi, ecc.

Capacità dinamicamente condivisa tra macchine virtuali
grazie profonda integrazione Con VMkernel, FVP può tracciare i blocchi di dati e determinare se la loro macchina virtuale sta leggendo o scrivendo. Tracciando in modo indipendente tali operazioni, la piattaforma può ridimensionare i buffer di lettura e scrittura nello spazio allocato per la macchina virtuale. FVP può memorizzare nella cache o eliminare un set arbitrario di dati della macchina virtuale dalla cache. Al contrario, la politica di evacuazione dei dati sul file system tradizionale per un dispositivo flash sarà non ottimale e comporterà più riscritture, poiché il file system può solo scrivere i dati alla fine del file o eliminare anche i blocchi dalla fine.

Significa anche che non è necessario assegnare una configurazione dello spazio cache statica per ogni macchina virtuale, come sarebbe se si utilizza un file system con indirizzamento diretto. È stata una grande decisione per noi; l'esperienza utente del prodotto dovrebbe essere il più intuitiva possibile.

Cito il nostro product manager Bala: "L'eleganza del prodotto, secondo me, è che svolge compiti basilari, NON richiede azioni nuove o inusuali da parte dell'utente."

In termini di lavoro quotidiano, questo è eccellente: non è necessario pre-ridimensionare la cache per ogni macchina virtuale. Ciò significa che non è necessario conoscere e prevedere il futuro utilizzo del flash: FVP farà tutto per te. La mancanza di un'allocazione effettiva delle risorse significa la mancanza di sottoutilizzazione del flash da parte di macchine virtuali senza carico e la comparsa di cicli di pulizia dei blocchi ridondanti per macchine virtuali attive con dimensioni della cache flash insufficienti. Ciò riduce al minimo il problema delle registrazioni multiple e garantisce le massime prestazioni e affidabilità dei dispositivi flash.

Articolo originale .

Dal 2016 FVP si è ritirato dalla vendita.