CMG Brasil

Pomegranate er et nyt distribueret filsystem, der er bygget over distribueret tabular storage, og som fungerer meget som et NoSQL-system. Det er målrettet mod at øge ydeevnen for adgang til små objekter for at understøtte applikationer som onlinefoto- og mikroblog-tjenester, der kræver høj samtidighed, høj gennemstrømning og lav latenstid. Deres test synes at indikere, at det virker:

Vi har demonstreret, at filsystem over tabular storage klarer sig godt ved højkonkurrent adgang. I vores testklynge observerede vi lineært øgede mere end 100.000 aggregerede læse- og skriveforespørgsler serveret pr. sekund (RPS).

I stedet for at sidde oven på filsystemet som næsten alle andre K-V-lagre er Pomegranate bagt ind i filsystemet. Ideen er, at filsystem-API’et er fælles for alle platforme, så det ville ikke kræve et separat API at bruge. Alle programmer kan bruge det uden videre.

Funktionerne i Pomegranate er:

• Det håndterer milliarder af små filer effektivt, selv i én mappe;
• Det giver separat og skalerbart caching-lag, som kan være snapshot-able;
• Lagringslaget bruger logstruktureret lager til at absorbere små filskrivninger for at udnytte diskbåndbredden;
• Byg et globalt navnerum for både små filer og store filer;
• Kolonneopbevaring for at udnytte tidsmæssig og rumlig lokalitet;
• Distributed extendible hash til indeksering af metadata;
• Snapshot-able and reconfigurable caching to increase parallelism and tolerant failures;
• Pomegranate bør være det første filsystem, der er bygget over tabular storage, og byggeerfaringen bør være værdig for filsystemfællesskabet.

Can Ma, der leder forskningen i Pomegranate, var så venlig at indvillige i et kort interview.

Kan du give et overblik over arkitekturen, og hvad du gør, der er cool og anderledes?

Grundlæggende findes der ikke noget distribueret eller parallelt filsystem, der effektivt kan håndtere milliarder af små filer. Vi kan dog forudse, at webapplikationer(såsom e-mail, foto og endda video) og bio-computere(gensekventering) har brug for massive små filtilgange. I mellemtiden er filsystemets API generelt nok og velforstået for de fleste programmører.

Dermed ønsker vi at opbygge et filsystem, der kan håndtere milliarder af små filer og give høj gennemstrømning af samtidige adgangsadgange. Selv om Pomegranate er designet til adgang til små filer, understøtter det heller ikke store filer. Det er bygget oven på andre distribuerede filsystemer, f.eks. Lustre, og administrerer kun namespace og små filer. Vi ønsker blot at stå på “giganternes skuldre”. Se figuren nedenfor:

Pomegranate har mange metadataservere og metadatalagringsservere til at betjene metadataforespørgsler og læse/skriveforespørgsler om små filer. MDS’erne er blot et caching-lag, som indlæser metadata fra lageret og overfører hukommelsessnapshots til lageret. Kernen i Pomegranate er et distribueret tabularlagringssystem kaldet xTable. Det understøtter nøgleindekserede multi-kolonneopslag. Vi bruger distribueret udvidelig hash til at lokalisere serveren ud fra nøglen, fordi udvidelig hash er mere tilpasningsdygtig til at skalere op og ned.

I filsystemer er mappetabel og inodetabel altid adskilt for at understøtte to forskellige typer opslag. Opslag ved hjælp af et vejnavn håndteres af katalogtabellen, mens opslag ved hjælp af inodetal håndteres af inodetabellen. Det er ikke trivielt at opdatere disse to indekser konsekvent, især ikke i et distribueret filsystem. I mellemtiden har brugen af to indekser øget opslagslatenstiden, hvilket er uacceptabelt ved adgang til små filer. Typisk er der i hukommelsen caches til dentry og inode, men disse caches kan ikke let udvides. Ved ændring af metadata skal der opdateres flere steder. For at bevare konsistensen er der indført en driftslog. Mens operation log altid er et serielt punkt for request flows.

Pomegranate bruger en tabellignende mappestruktur til at sammenlægge mappetabel og inodetabel. To forskellige typer opslag er forenet til opslag efter nøgle. For filsystemet er nøglen hash-værdien af dentry-navnet. Hash-konflikter løses ved hjælp af et globalt unikt id for hver fil. For hver opdatering behøver vi kun at søge og opdatere én tabel. For at eliminere driftsloggen designer og understøtter vi hukommelsessnapshot for at få et konsistent billede. De beskidte regioner i hvert snapshot kan skrives sikkert til lageret uden at tage hensyn til samtidige ændringer (de samtidige opdateringer er COWed.)

Der er dog nogle komplekse filsystemoperationer såsom mkdir, rmdir, hard link og rename, som bør overvejes. Disse operationer skal opdatere mindst to tabeller. Vi implementerer en pålidelig multisite-opdateringstjeneste til at sprede deltaer fra en tabel til en anden. Ved f.eks. mkdir overfører vi delta(“nlink +1”) til den overordnede tabel.

Er der nogen single point of failure?

Der er ingen SPOF i designet. Vi bruger klynge af MDS’er til at betjene metadataforespørgsel. Hvis en MDS går ned, omdirigeres anmodningerne til andre MDS’er (der anvendes konsistent hash og heartbeats). Metadata og små filer replikeres enten til flere knudepunkter eller til flere knudepunkter. Denne replikering udløses imidlertid af eksterne synkroniseringsværktøjer, som er asynkrone i forhold til skrivningerne.

Små filer har normalt været filsystemernes død på grund af vedligeholdelse af mappestrukturen. Hvordan kommer du udenom det?

Ja, det er dødssygt langsomt for adgang til små filer i traditionelle filsystemer. Vi erstatter den traditionelle mappetabel (B+-træ eller hashtræ) med en distribueret udvidelig hashtabel. Dentry-navnet og inode-metadata behandles som kolonner i tabellen. Opslag fra klienter sendes (eller omdirigeres om nødvendigt) til det korrekte MDS. For at få adgang til en lille fil behøver vi således kun at få adgang til én række i tabellen for at finde filens placering. Vi opbevarer hver enkelt lille fil sekventielt i det oprindelige filsystem. Som følge heraf kan én I/O-adgang tjene til at læse en lille fil.

Hvilke posix apis er understøttet? Kan filer låses, mappes, symlinks osv.?

På nuværende tidspunkt er POSIX-understøttelsen under udvikling. Vi understøtter symlinks, mmap-adgang. Mens flock ikke er understøttet.

Hvorfor et filsystem på kerneniveau i stedet for et K-V-lager ovenpå?

Vores oprindelige mål er at implementere et filsystem til at understøtte flere eksisterende applikationer. Selv om vi nu understøtter K/V-interface oven på xTable. Se figuren for arkitekturen, AMC-klienten er nøgle/værdi-klienten for Pomegranate. Vi understøtter simple prædikater på nøgle eller værdi, f.eks. understøtter vi “select * from table where key < 10 and ‘xyz’ in value” for at få de k/v-par, som værdien indeholder “xyz” og key < 10.

Hvordan kan det sammenlignes med andre distribuerede filsystemer?

Vi ønsker at sammenligne den lille filydelse med andre filsystemer. Vi har dog ikke testet det endnu. Vi vil gøre det i løbet af den næste måned. Vi mener dog, at de fleste distribuerede filsystemer ikke kan håndtere massive små filtilgange effektivt.

Er indekser og enhver form for forespørgsler understøttet?

For nu er disse understøttelser ikke blevet overvejet ordentligt endnu. Vi planlægger at overveje range query næste gang.

Funktionerer den på tværs af datacentre, dvs. hvordan håndterer den latency?

Pomegranate fungerer kun i et datacenter. WAN-understøttelse er endnu ikke blevet overvejet.

Det ser ud til, at du bruger en in-memory-arkitektur af hensyn til hastigheden. Kan du fortælle om det?

Vi bruger et dedikeret hukommelsescachelag af hensyn til hastigheden. Tabelrækker er grupperet som tabelskiver. I hukommelsen hashes tabel sl
skiverne i en lokal udvidelig hashtabel både af hensyn til ydeevne og pladsforbrug. Vist af nedenstående figur,

Klienterne udsender forespørgsel ved at hashe filnavnet og slå op i bitmap. Derefter anvendes en konsistent hashring til at lokalisere cache-serveren (MDS) eller lagringsserveren (MDSL). Hver opdatering får først den *åbnede* transaktionsgruppe, og kan kun anvendes på den række af tabellen i hukommelsen. Hver ændring af transaktionsgruppen er atomar. Når alle ventende opdateringer er afsluttet, kan transaktionsgruppen overføres sikkert til lageret. Denne fremgangsmåde svarer til Suns ZFS.

Hvordan håndteres høj tilgængelighed?

Den centrale server til konsistent hashringstyring og fejlkoordinator bør replikeres ved hjælp af Paxos-algoritmen. Vi planlægger at bruge ZooKeeper til den centrale tjeneste med høj tilgængelighed.
Andre komponenter er designet til at være fejltolerante. Nedbrud i MDS og MDSL kan konfigureres til at blive genoprettet øjeblikkeligt ved at videresende anmodninger til nye servere (ved at vælge det næste punkt i den konsistente hashring).

Hvordan fungerer det rent operationelt? Hvordan tilføjes knuder til systemet?

Det er enkelt at tilføje knuder til cachinglaget. Den centrale server (R2) tilføjer den nye node til den konsistente hash-ring. Alle cacheservere bør reagere på denne ændring og blot ugyldiggøre deres cachelagrede tabelskiver, hvis de vil blive forvaltet af den nye knude. Anmodninger fra klienter dirigeres til den nye server, og en CH ring change notification vil piggyback til klienten for at trække den nye ring fra den centrale server.

Hvordan håndterer du store filer? Er det velegnet til streaming af video?

Som beskrevet tidligere videresendes store filer til andre distribuerede filsystemer. Vores caching-lag vil ikke blive forurenet af streaming videodata.

Er der andet, du gerne vil tilføje?

En anden figur for interaktion mellem Pomegranate-komponenter.