CMG Brasil

Pomegranate is een nieuw gedistribueerd bestandssysteem dat is gebouwd op gedistribueerde tabelopslag en dat erg veel lijkt op een NoSQL-systeem. Het is gericht op het verbeteren van de prestaties van de toegang tot kleine objecten ter ondersteuning van toepassingen zoals online foto- en microblogdiensten, die een hoge concurrency, hoge doorvoer en lage latency vereisen. Hun tests lijken erop te wijzen dat het werkt:

We hebben aangetoond dat bestandssystemen over tabelvormige opslag goed presteren voor zeer gelijktijdige toegang. In ons testcluster hebben we een lineaire toename van meer dan 100.000 geaggregeerde lees- en schrijfverzoeken per seconde (RPS) waargenomen.

In plaats van boven op het bestandssysteem te zitten, zoals bijna elke andere K-V-opslag, is Pomegranate ingebouwd in het bestandssysteem. Het idee is dat de API van het bestandssysteem gemeenschappelijk is voor elk platform, zodat er geen aparte API nodig is om het te gebruiken. Elke applicatie kan het gebruiken.

De kenmerken van Pomegranate zijn:

• Het gaat efficiënt om met miljarden kleine bestanden, zelfs in één directory;
• Het biedt een aparte en schaalbare caching laag, die snapshot-able kan zijn;
• De opslag laag maakt gebruik van log gestructureerde opslag om kleine file writes te absorberen om de disk bandbreedte te benutten;
• Bouw een globale namespace voor zowel kleine bestanden als grote bestanden;
• Columnar opslag om temporele en ruimtelijke lokaliteit te benutten;
• Distributed uitbreidbare hash om metadata te indexeren;
• Snapshot-able en herconfigureerbare caching om parallellisme te vergroten en storingen te tolereren;
• Pomegranate zou het eerste bestandssysteem moeten zijn dat over tabulaire opslag is gebouwd, en de bouwervaring zou de bestandssysteem gemeenschap waardig moeten zijn.

Can Ma, die het onderzoek naar Pomegranate leidt, was zo vriendelijk om in te stemmen met een kort interview.

Kunt u alstublieft een overzicht geven van de architectuur en wat u doet dat cool en anders is?

Basaal gezien is er geen gedistribueerd of parallel bestandssysteem dat efficiënt kan omgaan met miljarden kleine bestanden. We kunnen echter verwachten dat webtoepassingen (zoals e-mail, foto’s en zelfs video), en bio-computing (gensequencing) massale toegang tot kleine bestanden nodig hebben. Ondertussen is de API van het bestandssysteem algemeen genoeg en goed begrepen door de meeste programmeurs.

Dus, we willen een bestandssysteem bouwen dat miljarden kleine bestanden kan beheren, en een hoge doorvoer van gelijktijdige toegang biedt. Hoewel Pomegranate is ontworpen voor toegang tot kleine bestanden, ondersteunt het ook grote bestanden. Het is gebouwd bovenop andere gedistribueerde bestandssystemen, zoals Lustre, en beheert alleen de namespace en kleine bestanden. We willen gewoon op “de schouders van reuzen” staan. Zie de figuur hieronder:

Pomegranate heeft veel Metadata Servers en Metadata Storage Servers om metadata-verzoeken en lees/schrijf-verzoeken van kleine bestanden te bedienen. De MDS’en zijn slechts een cachinglaag, die metadata uit de opslag laden en geheugenmomentopnamen naar de opslag vastleggen. De kern van Pomegranate is een gedistribueerd opslagsysteem voor tabellen, xTable genaamd. Het ondersteunt sleutel geïndexeerde multi-kolom opzoekingen. We gebruiken gedistribueerde uitbreidbare hash om de server te lokaliseren vanuit de sleutel, omdat uitbreidbare hash meer adaptief is om op en neer te schalen.

In bestandssystemen zijn de directorytabel en de inode-tabel altijd gescheiden om twee verschillende soorten lookups te ondersteunen. Opzoekingen op padnaam worden afgehandeld door de directorytabel, terwijl opzoekingen op inode nummer worden afgehandeld door de inode tabel. Het is niet eenvoudig om deze twee indexen consistent bij te werken, vooral in een gedistribueerd bestandssysteem. Ondertussen heeft het gebruik van twee indexen de lookup latency verhoogd, wat onacceptabel is voor het benaderen van kleine bestanden. Normaal gesproken zijn er in het geheugen caches voor dentry en inode, maar deze caches kunnen niet gemakkelijk worden uitgebreid. Het wijzigen van metadata moet meerdere locaties updaten. Om consistentie te behouden, wordt operation log geïntroduceerd. Terwijl, operation log altijd een serieel punt is voor request flows.

Pomegranate gebruikt een tabel-achtige directory structuur om de directory tabel en de inode tabel samen te voegen. Twee verschillende types van lookup zijn verenigd tot lookups per sleutel. Voor het bestandssysteem is de sleutel de hash waarde van de dentry naam. Hash conflicten worden opgelost door een globaal uniek id voor elk bestand. Voor elke update, hoeven we alleen maar één tabel te doorzoeken en bij te werken. Om de operations log te elimineren, ontwerpen en ondersteunen we geheugen snapshot om een consistent beeld te krijgen. De vuile gebieden van elke momentopname kunnen veilig naar de opslag worden geschreven zonder rekening te houden met gelijktijdige wijzigingen. (De gelijktijdige updates zijn COWed.)

Echter, er zijn een aantal complexe bestandssysteem operaties zoals mkdir, rmdir, hard link, en hernoemen die moeten worden overwogen. Deze operaties moeten ten minste twee tabellen bijwerken. We implementeren een betrouwbare multisite update service om delta’s van de ene tabel naar de andere te propageren. Bijvoorbeeld, op mkdir, propageren we de delta(“nlink +1”) naar de bovenliggende tabel.

Zijn er single points of failure?

Er is geen SPOF in het ontwerp. Wij gebruiken cluster van MDSs om metadataverzoeken te dienen. Als een MDS crasht, worden de verzoeken omgeleid naar andere MDS’en (consistente hash en heartbeats worden gebruikt). Metadata en kleine bestanden worden ook gerepliceerd naar meerdere nodes. Echter, deze replicatie wordt getriggerd door externe sync tools die asynchroon zijn met de writes.

Kleine bestanden zijn meestal de dood van bestandssystemen vanwege het onderhoud van de directory structuur. Hoe omzeil je dat?

Ja, het is dodelijk traag voor toegang tot kleine bestanden in traditionele bestandssystemen. We vervangen de traditionele directory tabel (B+ boom of hash boom) door een gedistribueerde uitbreidbare hash tabel. De dentry naam en inode metadata worden behandeld als kolommen van de tabel. Lookups van clients worden verzonden (of gerouteerd indien nodig) naar de juiste MDS. Dus, om een klein bestand te benaderen, hoeven we slechts één tabelrij te benaderen om de bestandslocatie te vinden. We houden elk klein bestand sequentieel opgeslagen in het native bestandssysteem. Het resultaat is dat één I/O toegang kan dienen om een klein bestand te lezen.

Welke posix apis worden ondersteund? Kunnen bestanden worden gelocked, gemapped, symlinks, etc?

Op dit moment is de POSIX ondersteuning in volle gang. We ondersteunen wel symlinks, mmap toegang. Terwijl, flock niet wordt ondersteund.

Waarom een bestandssysteem op kernel-niveau in plaats van een K-V opslag bovenop?

Onze eerste doelstelling is om een bestandssysteem te implementeren om meer bestaande applicaties te ondersteunen. We ondersteunen nu wel een K/V interface bovenop xTable. Zie de figuur van de architectuur, de AMC client is de sleutel/waarde client voor Pomegranate. We ondersteunen eenvoudige predicaten op sleutel of waarde, bijvoorbeeld “select * from table where key < 10 and ‘xyz’ in value” om de k/v paren te krijgen die waarde “xyz” bevat en key < 10.

Hoe verhoudt het zich tot andere gedistribueerde bestandssystemen?

We willen de prestaties van kleine bestanden vergelijken met andere bestandssystemen. We hebben het echter nog niet getest. Dat zullen we in de komende maand doen. Hoewel we denken dat de meeste gedistribueerde bestandssystemen niet efficiënt kunnen omgaan met massale toegang tot kleine bestanden.

Worden indexen en andere soorten queries ondersteund?

Voorlopig is deze ondersteuning nog niet goed overwogen.

Werkt het over datacenters heen, dat wil zeggen, hoe gaat het om met latency?

Pomegranate werkt alleen in een datacenter. WAN-ondersteuning is nog niet overwogen.

Het lijkt erop dat u een in-memory architectuur gebruikt voor snelheid. Kunt u daar iets over zeggen?

We gebruiken een speciale geheugen cache laag voor snelheid. Tabel rijen zijn gegroepeerd als tabel slices. In het geheugen worden de tabel slices gehasht in een lokale uitbreidbare hashtabel voor zowel prestatie als ruimtegebruik. De onderstaande afbeelding laat zien dat

Clienten doen een aanvraag door de bestandsnaam te hashen en op te zoeken in de bitmap. Vervolgens wordt een consistente hash-ring gebruikt om de cache-server (MDS) of opslagserver (MDSL) te lokaliseren. Elke update krijgt eerst de *geopende* transactie groep, en kan alleen van toepassing op de in het geheugen tabel rij. Elke transactiegroep wijziging is atomair. Nadat alle hangende updates zijn voltooid, kan de transactiegroep veilig worden gecommit naar de opslag. Deze aanpak is vergelijkbaar met Sun’s ZFS.

Hoe wordt hoge beschikbaarheid behandeld?

Wel, de centrale server voor consistent hash ring management en falen coördinator zou moeten worden gerepliceerd door Paxos algoritme. We zijn van plan om ZooKeeper te gebruiken voor een hoog beschikbare centrale service.
Andere componenten zijn ontworpen om fouttolerant te zijn. Crashes van MDS en MDSL kunnen worden geconfigureerd als onmiddellijk hersteld door verzoeken te routeren naar nieuwe servers (door het volgende punt in consistente hash ring te selecteren).

Operationeel, hoe werkt het? Hoe worden nodes aan het systeem toegevoegd?

Het toevoegen van nodes aan de caching laag is eenvoudig. De centrale server (R2) voegt de nieuwe node toe aan de consistente hashring. Alle cache servers moeten op deze verandering reageren en alleen hun cache tabel slices ongeldig maken als ze door de nieuwe node beheerd zullen worden. Verzoeken van clients worden gerouteerd naar de nieuwe server, en een CH ring change notification zal piggyback naar client om de nieuwe ring te trekken van de centrale server.

Hoe ga je om met grote bestanden? Is het geschikt voor streaming video?

Zoals eerder beschreven, worden grote bestanden doorgegeven aan andere gedistribueerde bestandssystemen. Onze cachinglaag zal niet vervuild worden door de streaming videogegevens.

Is er nog iets dat u zou willen toevoegen?

Een ander figuur voor de interactie van de Pomegranate-componenten.