CMG Brasil

Pomegranate è un nuovo file system distribuito costruito su storage tabellare distribuito che si comporta in modo molto simile a un sistema NoSQL. È mirato ad aumentare le prestazioni dell’accesso a piccoli oggetti al fine di supportare applicazioni come foto online e servizi di micro-blog, che richiedono alta concorrenza, alto throughput e bassa latenza. I loro test sembrano indicare che funziona:

Abbiamo dimostrato che il file system sullo storage tabellare funziona bene per un accesso altamente concorrente. Nel nostro cluster di test, abbiamo osservato un aumento lineare di oltre 100.000 richieste aggregate di lettura e scrittura servite al secondo (RPS).

Piuttosto che stare in cima al file system come quasi ogni altro negozio K-V, Pomegranate è cotto nel file system. L’idea è che l’API del file system sia comune ad ogni piattaforma, quindi non richiederebbe un’API separata da usare. Ogni applicazione potrebbe usarlo fuori dalla scatola.

Le caratteristiche di Pomegranate sono:

• Gestisce miliardi di piccoli file in modo efficiente, anche in una sola directory;
• Fornisce uno strato di caching separato e scalabile, che può essere snapshot-able;
• Lo strato di archiviazione utilizza log structured store per assorbire le scritture di piccoli file per utilizzare la larghezza di banda del disco;
• Costruisce uno spazio dei nomi globale sia per i file piccoli che per quelli grandi;
• Columnar storage per sfruttare la localizzazione temporale e spaziale;
• Distribuito hash estensibile per indicizzare i metadati;
• Caching riconfigurabile e capace di fare snapshot per aumentare il parallelismo e tollerare i fallimenti;
• Pomegranate dovrebbe essere il primo file system costruito su storage tabulare, e l’esperienza di costruzione dovrebbe essere degna per la comunità dei file system.

Can Ma, che guida la ricerca su Pomegranate, è stato così gentile da acconsentire a una breve intervista.

Puoi dare una panoramica dell’architettura e cosa state facendo di bello e di diverso?

Fondamentalmente, non esiste un file system distribuito o parallelo che possa gestire miliardi di piccoli file in modo efficiente. Tuttavia, possiamo prevedere che le applicazioni web (come e-mail, foto e anche video) e il bio-computing (sequenziamento dei geni) hanno bisogno di accessi massicci a piccoli file. Nel frattempo, l’API del file system è abbastanza generale e ben compresa dalla maggior parte dei programmatori.

Quindi, vogliamo costruire un file system per gestire miliardi di piccoli file, e fornire un alto throughput di accessi simultanei. Anche se Pomegranate è progettato per gli accessi a piccoli file, supporta anche file di grandi dimensioni. È costruito sopra altri file system distribuiti, come Lustre, e gestisce solo lo spazio dei nomi e i piccoli file. Vogliamo solo stare sulle “spalle dei giganti”. Vedi la figura qui sotto:

Pomegranate ha molti Metadata Server e Metadata Storage Server per servire le richieste di metadati e di lettura/scrittura di piccoli file. Gli MDS sono solo uno strato di caching, che caricano i metadati dallo storage e commettono snapshot di memoria allo storage. Il nucleo di Pomegranate è un sistema di archiviazione tabellare distribuito chiamato xTable. Supporta lookup multi-colonna indicizzati con chiavi. Usiamo l’hash distribuito estendibile per localizzare il server dalla chiave, perché l’hash estendibile è più adattivo per scalare su e giù.

Nei file system, la tabella delle directory e la tabella degli inode sono sempre separate per supportare due diversi tipi di ricerca. Le ricerche per nome di percorso sono gestite dalla tabella delle directory, mentre le ricerche per numero di inode sono gestite dalla tabella degli inode. Non è banale aggiornare costantemente questi due indici, specialmente in un file system distribuito. Nel frattempo, l’uso di due indici ha aumentato la latenza di ricerca, che è inaccettabile per l’accesso a file piccoli. Tipicamente, ci sono cache in memoria per dentry e inode, tuttavia, le cache non possono essere facilmente estese. La modifica dei metadati deve aggiornare più posizioni. Per mantenere la coerenza, viene introdotto il registro delle operazioni. Mentre, il registro delle operazioni è sempre un punto seriale per i flussi di richiesta.

Pomegranate usa una struttura di directory simile a una tabella per unire la tabella delle directory e la tabella degli inode. Due diversi tipi di ricerca sono unificati alla ricerca per chiave. Per il file system, la chiave è il valore hash del nome della cartella. I conflitti di hash sono risolti da un id unico globale per ogni file. Per ogni aggiornamento, abbiamo solo bisogno di cercare e aggiornare una tabella. Per eliminare il registro delle operazioni, progettiamo e supportiamo snapshot di memoria per ottenere un’immagine coerente. Le regioni sporche di ogni snapshot possono essere scritte nella memoria in modo sicuro senza considerare le modifiche concorrenti (gli aggiornamenti concorrenti sono COWed.)

Tuttavia, ci sono alcune complesse operazioni di file system come mkdir, rmdir, hard link e rename che dovrebbero essere considerate. Queste operazioni devono aggiornare almeno due tabelle. Implementiamo un affidabile servizio di aggiornamento multisito per propagare i delta da una tabella all’altra. Per esempio, su mkdir, propaghiamo il delta(“nlink +1”) alla tabella madre.

Ci sono singoli punti di fallimento?

Non ci sono SPOF nel progetto. Usiamo un cluster di MDS per servire le richieste di metadati. Se un MDS va in crash, le richieste vengono reindirizzate ad altri MDS (vengono usati hash coerenti e heartbeat). Anche i metadati e i piccoli file sono replicati su più nodi. Tuttavia, questa replica è attivata da strumenti di sincronizzazione esterni che sono asincroni alle scritture.

I piccoli file sono stati di solito la morte dei filesystem a causa della manutenzione della struttura delle directory. Come lo aggirate?

Sì, è mortalmente lento l’accesso ai piccoli file nei file system tradizionali. Sostituiamo la tabella di directory tradizionale (albero B+ o albero hash) con una tabella hash distribuita estendibile. Il nome della cartella e i metadati dell’inode sono trattati come colonne della tabella. Le ricerche dai client sono inviate (o instradate, se necessario) all’MDS corretto. Così, per accedere a un piccolo file, abbiamo solo bisogno di accedere a una riga della tabella per trovare la posizione del file. Manteniamo ogni piccolo file memorizzato in modo sequenziale nel file system nativo. Di conseguenza, un accesso I/O può servire a leggere un piccolo file.

Quali apici posix sono supportati? I file possono essere bloccati, mappati, link simbolici, ecc?

Al momento, il supporto POSIX sta progredendo. Supportiamo i collegamenti simbolici, l’accesso mmap. Mentre, flock non è supportato.

Perché fare un file system a livello di kernel piuttosto che uno store K/V sopra?

Il nostro obiettivo iniziale è di implementare un file system per supportare più applicazioni esistenti. Mentre ora supportiamo l’interfaccia K/V sopra xTable. Vedi la figura dell’architettura, il client AMC è il client chiave/valore per Pomegranate. Supportiamo semplici predicati su chiave o valore, per esempio supportiamo “select * from table where key < 10 and ‘xyz’ in value” per ottenere le coppie k/v che il valore contiene “xyz” e la chiave < 10.

Come si confronta con altri filesystem distribuiti?

Vogliamo confrontare le prestazioni del file piccolo con altri filesystem. Tuttavia, non lo abbiamo ancora testato. Lo faremo nel prossimo mese. Anche se crediamo che la maggior parte dei file system distribuiti non possano gestire accessi massicci a file di piccole dimensioni in modo efficiente.

Sono supportati gli indici e qualsiasi tipo di query?

Per ora, questi supporti non sono ancora stati adeguatamente considerati. Abbiamo in programma di prendere in considerazione le prossime query di intervallo.

Funziona attraverso i datacenter, cioè, come affronta la latenza?

Pomegranate funziona solo in un datacenter. Il supporto WAN non è stato ancora considerato.

Sembra che usiate un’architettura in-memory per la velocità. Puoi parlarne?

Utilizziamo uno strato di memoria cache dedicato per la velocità. Le righe della tabella sono raggruppate come fette di tabella. In memoria, le sl
cifre della tabella sono inserite in una tabella hash locale estendibile sia per le prestazioni che per il consumo di spazio. Mostrato dalla figura seguente,

I clienti emettono la richiesta con l’hash del nome del file e la ricerca nella bitmap. Poi, usando un anello di hash coerente per localizzare il server di cache (MDS) o il server di archiviazione (MDSL). Ogni aggiornamento ottiene in primo luogo il gruppo di transazioni *aperto* e può essere applicato solo alla riga della tabella in memoria. Ogni cambio di gruppo di transazione è atomico. Dopo che tutti gli aggiornamenti in sospeso sono finiti, il gruppo di transazioni può essere commesso allo storage in modo sicuro. Questo approccio è simile a ZFS di Sun.

Come viene gestita l’alta disponibilità?

Bene, il server centrale per la gestione coerente dell’hash ring e il coordinatore dei guasti dovrebbe essere replicato dall’algoritmo Paxos. Abbiamo intenzione di usare ZooKeeper per il servizio centrale ad alta disponibilità.
Altri componenti sono progettati per essere tolleranti ai guasti. I crash di MDS e MDSL possono essere configurati come recuperati immediatamente instradando le richieste a nuovi server (selezionando il punto successivo in un anello hash coerente).

Operativamente, come funziona? Come vengono aggiunti i nodi nel sistema?

L’aggiunta di nodi al livello di caching è semplice. Il server centrale (R2) aggiunge il nuovo nodo all’anello di hash coerente. Tutti i server di cache dovrebbero agire su questo cambiamento e semplicemente invalidare le loro fette di tabella in cache se saranno gestite dal nuovo nodo. Le richieste dei client sono indirizzate al nuovo server, e una notifica di cambiamento dell’anello CH farà da piggyback al client per estrarre il nuovo anello dal server centrale.

Come gestisce i file di grandi dimensioni? È adatto per lo streaming video?

Come descritto in precedenza, i file di grandi dimensioni vengono trasmessi ad altri file system distribuiti. Il nostro strato di caching non sarà inquinato dai dati video in streaming.

Nient’altro che vorresti aggiungere?

Un’altra figura di interazione dei componenti di Pomegranate.