CMG Brasil

Pomegranate este un nou sistem de fișiere distribuit construit pe un sistem de stocare tabulară distribuită care se comportă foarte asemănător cu un sistem NoSQL. Este destinat creșterii performanțelor de accesare a obiectelor minuscule pentru a sprijini aplicații precum serviciile de fotografii online și micro-bloguri, care necesită o concurență ridicată, un debit ridicat și o latență redusă. Testele lor par să indice că funcționează:

Am demonstrat că sistemul de fișiere peste stocarea tabulară se comportă bine pentru accesul foarte concurent. În clusterul nostru de testare, am observat o creștere liniară de peste 100.000 de cereri agregate de citire și scriere servite pe secundă (RPS).

În loc să stea deasupra sistemului de fișiere, ca aproape toate celelalte magazine K-V, Pomegranate este integrat în sistemul de fișiere. Ideea este că API-ul sistemului de fișiere este comun pentru fiecare platformă, astfel încât nu ar necesita o API separată pentru a fi utilizată. Fiecare aplicație ar putea să o folosească din start.

Caracteristicile lui Pomegranate sunt:

• Gestionează eficient miliarde de fișiere mici, chiar și într-un singur director;
• Furnizează un strat de cache separat și scalabil, care poate fi instantaneu;
• Stratul de stocare utilizează stocarea structurată în jurnal pentru a absorbi scrierile de fișiere mici pentru a utiliza lățimea de bandă a discului;
• Construiește un spațiu de nume global atât pentru fișierele mici, cât și pentru cele mari;
• Stocare în coloane pentru a exploata localitatea temporală și spațială;
• Hash extensibil distribuit pentru a indexa metadatele;
• Caching reconfigurabil și cu posibilitatea de a face instantanee pentru a crește paralelismul și a tolera eșecurile;
• Pomegranate ar trebui să fie primul sistem de fișiere care este construit pe stocare tabulară, iar experiența de construcție ar trebui să fie demnă pentru comunitatea sistemelor de fișiere.

Can Ma, care conduce cercetările privind Pomegranate, a fost destul de amabil să accepte un scurt interviu.

Puteți, vă rog, să faceți o prezentare generală a arhitecturii și a ceea ce faceți care este interesant și diferit?

În principiu, nu există un sistem de fișiere distribuit sau paralel care să poată gestiona eficient miliarde de fișiere mici. Cu toate acestea, putem prevedea că aplicațiile web (cum ar fi e-mail, fotografii și chiar video) și bioinformatica (secvențierea genelor) au nevoie de accesări masive de fișiere mici. Între timp, API-ul sistemului de fișiere este suficient de general și bine înțeles de majoritatea programatorilor.

Prin urmare, dorim să construim un sistem de fișiere care să gestioneze miliarde de fișiere mici și să ofere un debit ridicat de accesări simultane. Deși Pomegranate este proiectat pentru accesări de fișiere mici, acesta suportă și fișiere mari. Acesta este construit pe baza altor sisteme de fișiere distribuite, cum ar fi Lustre, și gestionează doar spațiul de nume și fișierele mici. Vrem doar să ne ridicăm pe „umerii uriașilor”. A se vedea figura de mai jos:

Pomegranate are multe servere de metadate și servere de stocare a metadatelor pentru a servi cererile de metadate și cererile de citire/scriere a fișierelor mici. MDS-urile sunt doar un strat de caching, care încarcă metadatele din stocare și angajează instantanee de memorie în stocare. Nucleul Pomegranate este un sistem distribuit de stocare tabulară numit xTable. Acesta suportă căutări pe mai multe coloane indexate cu chei. Noi folosim hash extensibil distribuit pentru a localiza serverul din cheie, deoarece hash extensibil este mai adaptabil la mărirea și micșorarea dimensiunii.

În sistemele de fișiere, tabelul de directoare și tabelul de inode sunt întotdeauna separate pentru a suporta două tipuri diferite de căutări. Căutările prin nume de drum sunt gestionate de tabelul de directoare, în timp ce căutările prin numărul de inode sunt gestionate de tabelul de inode. Nu este ușor de actualizat în mod constant acești doi indici, în special într-un sistem de fișiere distribuit. Între timp, utilizarea a doi indici a crescut latența căutării, ceea ce este inacceptabil pentru accesarea fișierelor mici. În mod obișnuit, există cache-uri în memorie pentru dentry și inode, însă cache-urile nu se pot extinde cu ușurință. Modificarea metadatelor trebuie să actualizeze mai multe locații. Pentru a păstra coerența, se introduce jurnalul de operațiuni. În același timp, jurnalul de operații este întotdeauna un punct serial pentru fluxurile de cereri.

Pomegranate utilizează o structură de directoare de tip tabel pentru a îmbina tabela de directoare și tabela de noduri. Două tipuri diferite de căutări sunt unificate în căutări prin cheie. Pentru sistemul de fișiere, cheia este valoarea hash a numelui dentar. Conflictele de hash sunt rezolvate prin intermediul unui id unic global pentru fiecare fișier. Pentru fiecare actualizare, trebuie doar să căutăm și să actualizăm un singur tabel. Pentru a elimina jurnalul de operațiuni, proiectăm și susținem instantanee de memorie pentru a obține o imagine coerentă. Regiunile murdare din fiecare instantaneu pot fi scrise în siguranță în memorie fără a lua în considerare modificările simultane (actualizările simultane sunt COWed.)

Cu toate acestea, există unele operații complexe ale sistemului de fișiere, cum ar fi mkdir, rmdir, hard link și redenumire, care trebuie luate în considerare. Aceste operații trebuie să actualizeze cel puțin două tabele. Implementăm un serviciu de actualizare multisite fiabil pentru a propaga delta de la un tabel la altul. De exemplu, la mkdir, propagăm delta(„nlink +1”) în tabelul părinte.

Există puncte unice de eșec?

Nu există niciun SPOF în proiectare. Utilizăm un cluster de MDS-uri pentru a servi cererea de metadate. Dacă un MDS se prăbușește, cererile sunt redirecționate către alte MDS-uri (se utilizează hash consistent și heartbeats). Metadatele și fișierele mici sunt replicate fie în mai multe noduri. Cu toate acestea, această replicare este declanșată de instrumente de sincronizare externe care sunt asincrone cu scrierile.

Filetele mici au fost, de obicei, moartea sistemelor de fișiere din cauza menținerii structurii directoarelor. Cum ocoliți această problemă?

Da, este mortal de lent pentru accesul la fișiere mici în sistemele de fișiere tradiționale. Înlocuim tabelul de directoare tradițional (arborele B+ sau arborele hash) cu un tabel hash extensibil distribuit. Numele dentarului și metadatele inodului sunt tratate ca și coloane ale tabelului. Căutările de la clienți sunt trimise (sau direcționate, dacă este necesar) către MDS corect. Astfel, pentru a accesa un fișier mic, trebuie doar să accesăm un singur rând din tabel pentru a găsi locația fișierului. Fiecare fișier mic este stocat secvențial în sistemul de fișiere nativ. Ca urmare, un singur acces I/O poate servi la citirea unui fișier mic.

Ce apisuri posix sunt suportate? Fișierele pot fi blocate, mapate, cu legături simbolice, etc?

În prezent, suportul POSIX este în progres. Suportăm symlink-uri, acces mmap. În timp ce, flock nu este suportat.

De ce să facem un sistem de fișiere la nivel de kernel, mai degrabă decât o memorie K-V deasupra?

Obiectivul nostru inițial este de a implementa un sistem de fișiere pentru a susține mai multe aplicații existente. Deși, în prezent, susținem interfața K/V deasupra xTable. A se vedea figura de arhitectură, clientul AMC este clientul cheie/valoare pentru Pomegranate. Acceptăm predicte simple asupra cheii sau valorii, de exemplu, acceptăm „select * from table where key < 10 and ‘xyz’ in value” pentru a obține perechile k/v care conțin „xyz” și cheia < 10.

Cum se compară cu alte sisteme de fișiere distribuite?

Vrem să comparăm performanța fișierelor mici cu alte sisteme de fișiere. Cu toate acestea, nu am testat-o încă. O vom face în luna următoare. Deși, credem că majoritatea sistemelor de fișiere distribuite nu pot gestiona eficient accesările masive de fișiere mici.

Sunt acceptate indexurile și orice fel de interogări?

Pentru moment, aceste suporturi nu au fost încă luate în considerare în mod corespunzător. Plănuim să luăm în considerare interogările de tip range query în continuare.

Funcționează între centrele de date, adică, cum se ocupă de latență?

Pomegranate funcționează doar într-un centru de date. Suportul WAN nu a fost luat în considerare încă.

Se pare că folosiți o arhitectură în memorie pentru viteză. Puteți vorbi despre asta?

Utilizăm un strat dedicat de memorie cache pentru viteză. Rândurile de tabel sunt grupate ca felii de tabel. În memorie, sl
cile de tabel sunt hașurate într-un tabel hash local extensibil, atât pentru performanță, cât și pentru consumul de spațiu. Așa cum se arată în figura de mai jos,

Clienții emit cererea prin hasharea numelui de fișier și căutarea în bitmap. Apoi, folosind un inel hash consistent pentru a localiza serverul de cache (MDS) sau serverul de stocare (MDSL). Fiecare actualizare primește mai întâi grupul de tranzacții *deschis* și se poate aplica doar la rândul din tabelul din memorie. Fiecare modificare a grupului de tranzacții este atomică. După ce toate actualizările în așteptare sunt terminate, grupul de tranzacție poate fi trimis în siguranță la stocare. Această abordare este similară cu ZFS de la Sun.

Cum se gestionează disponibilitatea ridicată?

Ei bine, serverul central pentru gestionarea coerentă a inelului hash și coordonatorul de eșecuri ar trebui să fie replicat prin algoritmul Paxos. Intenționăm să folosim ZooKeeper pentru serviciul central cu disponibilitate ridicată.
Alte componente sunt proiectate pentru a fi tolerante la erori. Prăbușirile MDS și MDSL pot fi configurate ca fiind recuperate imediat prin rutarea cererilor către noi servere (prin selectarea următorului punct din inelul hash consistent).

Operațional, cum funcționează? Cum se adaugă noduri în sistem?

Aducerea nodurilor în stratul de cache este simplă. Serverul central (R2) adaugă noul nod la inelul hash consistent. Toate serverele de cache ar trebui să acționeze în funcție de această modificare și doar să-și invalideze feliile de tabel cache dacă acestea vor fi gestionate de noul nod. Solicitările de la clienți sunt direcționate către noul server, iar o notificare de schimbare a inelului CH se va suprapune clientului pentru a extrage noul inel de la serverul central.

Cum gestionați fișierele mari? Este potrivit pentru streaming video?

După cum am descris mai devreme, fișierele mari sunt retransmise către alte sisteme de fișiere distribuite. Stratul nostru de cache nu va fi poluat de datele de streaming video.

Am mai dori să adăugați ceva?

O altă figură pentru interacțiunea componentelor Pomegranate.