CMG Brasil

Pomegranate är ett nytt distribuerat filsystem som är byggt på distribuerad tabellerad lagring och som fungerar väldigt mycket som ett NoSQL-system. Det är inriktat på att öka prestandan för åtkomst till små objekt för att stödja tillämpningar som fototjänster och mikrobloggtjänster online, som kräver hög samtidighet, hög genomströmning och låg latenstid. Deras tester verkar tyda på att det fungerar:

Vi har visat att filsystem över tabulära lagringsutrymmen fungerar bra för mycket samtidig åtkomst. I vårt testkluster observerade vi linjärt ökade mer än 100 000 aggregerade läs- och skrivförfrågningar som betjänas per sekund (RPS).

Istället för att sitta ovanpå filsystemet som nästan alla andra K-V-lager är Pomegranate inbakad i filsystemet. Tanken är att filsystemets API är gemensamt för alla plattformar så det skulle inte krävas ett separat API för att använda det. Alla program skulle kunna använda det direkt.

Funktionerna i Pomegranate är:

• Det hanterar miljarder små filer effektivt, även i en katalog;
• Det tillhandahåller ett separat och skalbart cachinglager, som kan vara snapshot-kapabelt;
• Lagringslagret använder loggstrukturerad lagring för att absorbera skrivningar av små filer för att utnyttja bandbredden på disken;
• Bygger upp ett globalt namnområde för både små filer och stora filer;
• Kolumnlagring för att utnyttja tidsmässig och rumslig lokalitet;
• Distributed extendible hash för att indexera metadata;
• Snapshot-kapabla och omkonfigurerbara caching för att öka parallellitet och tolerans mot fel;
• Pomegranate bör vara det första filsystemet som byggs över tabulära lagringsutrymmen, och byggnadserfarenheten bör vara värdig för filsystemsgemenskapen.

Can Ma, som leder forskningen om Pomegranate, var vänlig nog att ställa upp på en kort intervju.

Kan du ge en översikt över arkitekturen och vad du gör som är häftigt och annorlunda?

I grund och botten finns det inget distribuerat eller parallellt filsystem som kan hantera miljarder små filer effektivt. Vi kan dock förutse att webbapplikationer (t.ex. e-post, foton och till och med video) och bioinformatik (gensekvensering) behöver massiva små filåtkomster. Samtidigt är filsystemets API tillräckligt generellt och väl förstått för de flesta programmerare.

Därmed vill vi bygga ett filsystem för att hantera miljarder små filer och ge hög genomströmning av samtidiga åtkomster. Även om Pomegranate är utformat för åtkomst till små filer har det inte heller stöd för stora filer. Det byggs ovanpå andra distribuerade filsystem, t.ex. Lustre, och hanterar endast namnområdet och små filer. Vi vill bara stå på ”jättars axlar”. Se figuren nedan:

Pomegranate har många metadataservrar och metadatalagringsservrar för att betjäna förfrågningar om metadata och förfrågningar om läsning/skrivning av små filer. MDS-servrarna är bara ett cachelager som laddar metadata från lagret och överför minnesbilder till lagret. Kärnan i Pomegranate är ett distribuerat system för lagring av tabeller som kallas xTable. Det stöder nyckelindexerade sökningar i flera kolumner. Vi använder distribuerad extendible hash för att lokalisera servern från nyckeln, eftersom extendible hash är mer anpassningsbar när det gäller att skala upp och ner.

I filsystem är katalogtabellen och inodtabellen alltid separerade för att stödja två olika typer av sökningar. Uppslag efter sökvägsnamn hanteras av katalogtabellen, medan uppslag efter inodnummer hanteras av inodtabellen. Det är inte trivialt att konsekvent uppdatera dessa två index, särskilt i ett distribuerat filsystem. Samtidigt har användningen av två index ökat väntetiden för sökning, vilket är oacceptabelt för åtkomst till små filer. Vanligtvis finns det minnescacher för dentry och inode i minnet, men det är inte lätt att utöka cacherna. Om metadata ändras måste flera platser uppdateras. För att bevara konsistensen införs en loggbok. Operationsloggen är dock alltid en seriepunkt för förfrågningsflöden.

Pomegranate använder en tabellliknande katalogstruktur för att slå samman katalogtabell och inodetabell. Två olika typer av sökningar förenas till sökningar efter nyckel. För filsystem är nyckeln hashvärdet för dentry-namnet. Hashkonflikter löses genom ett globalt unikt id för varje fil. För varje uppdatering behöver vi bara söka och uppdatera en tabell. För att eliminera driftsloggen utformar och stöder vi minnessnapshot för att få en enhetlig bild. De smutsiga regionerna i varje ögonblicksbild kan skrivas till lagret på ett säkert sätt utan hänsyn till samtidiga ändringar (de samtidiga uppdateringarna är COWed).

Det finns dock några komplexa filsystemoperationer som mkdir, rmdir, hard link och rename som bör beaktas. Dessa operationer måste uppdatera minst två tabeller. Vi implementerar en tillförlitlig uppdateringstjänst för flera platser för att sprida deltas från en tabell till en annan. Vid t.ex. mkdir överför vi delta(”nlink +1”) till den överordnade tabellen.

Är det några enskilda felpunkter?

Det finns inga SPOF i konstruktionen. Vi använder kluster av MDS för att betjäna metadataförfrågningar. Om en MDS kraschar omdirigeras förfrågningarna till andra MDS (konsekvent hash och heartbeats används). Metadata och små filer replikeras också till flera noder. Denna replikering utlöses dock av externa synkroniseringsverktyg som är asynkrona med skrivningarna.

Små filer har vanligtvis varit filsystemens död på grund av underhållet av katalogstrukturen. Hur kringgår du detta?

Ja, det är dödligt långsamt för åtkomst till små filer i traditionella filsystem. Vi ersätter den traditionella katalogtabellen (B+-trädet eller hashträdet) med en distribuerad utbyggbar hashtabell. Dentry-namnet och metadata om inoder behandlas som kolumner i tabellen. Sökningar från klienter skickas (eller vid behov dirigeras) till rätt MDS. För att komma åt en liten fil behöver vi alltså bara komma åt en tabellrad för att hitta filens plats. Varje liten fil lagras sekventiellt i det inhemska filsystemet. Som ett resultat av detta kan en I/O-åtkomst tjäna en läsning av en liten fil.

Vilka posix apis stöds? Kan filer låsas, mappas, symlinks osv?

För närvarande går stödet för POSIX framåt. Vi stöder symlänkar och mmap-åtkomst. Medan flock inte stöds.

Varför ett filsystem på kärnnivå i stället för ett K-V-lager ovanpå?

Vårt första mål är att införa ett filsystem för att stödja fler befintliga tillämpningar. Vi stöder dock K/V-gränssnittet ovanpå xTable nu. Se figuren över arkitekturen, AMC-klienten är nyckel/värde-klienten för Pomegranate. Vi stöder enkla predikat på nyckel eller värde, till exempel stöder vi ”select * from table where key < 10 and ’xyz’ in value” för att få fram de k/v-par som värdet innehåller ”xyz” och nyckel < 10.

Hur står det i jämförelse med andra distribuerade filsystem?

Vi vill jämföra prestandan hos den lilla filen med andra filsystem. Vi har dock inte testat det ännu. Vi kommer att göra det under nästa månad. Vi tror dock att de flesta distribuerade filsystem inte kan hantera omfattande åtkomster till små filer på ett effektivt sätt.

Har man stöd för index och någon form av frågor?

För tillfället har dessa stöd inte riktigt övervägts ännu. Vi planerar att överväga range query nästa gång.

Fungerar den över datacenter, dvs. hur hanterar den latenstiden?

Pomegranate fungerar endast i ett datacenter. WAN-stöd har ännu inte beaktats.

Det ser ut som om ni använder en in-memory-arkitektur för att öka hastigheten. Kan du tala om det?

Vi använder ett dedikerat minnescachelager för att öka hastigheten. Tabellrader grupperas som tabellskivor. I minnet hashasas tabellsl
skivorna in i en lokal förlängningsbar hashtabell både för prestanda och för utrymmeskonsumtion. Som framgår av figuren nedan,

Klienterna skickar en förfrågan genom att hasha filnamnet och söka i bitmappen. Därefter används en konsekvent hashring för att lokalisera cache-servern (MDS) eller lagringsservern (MDSL). Varje uppdatering får först den *öppnade* transaktionsgruppen och kan bara tillämpas på raden i minnet. Varje ändring av transaktionsgruppen är atomär. När alla pågående uppdateringar är klara kan transaktionsgruppen överföras till lagringsutrymmet på ett säkert sätt. Detta tillvägagångssätt liknar Suns ZFS.

Hur hanteras hög tillgänglighet?

Den centrala servern för konsekvent hashringhantering och felkoordinator bör replikeras med Paxos-algoritmen. Vi planerar att använda ZooKeeper för den centrala tjänsten med hög tillgänglighet.
Andra komponenter är utformade för att vara feltoleranta. Nedbrytningar av MDS och MDSL kan konfigureras så att de återställs omedelbart genom att förfrågningar dirigeras till nya servrar (genom att välja nästa punkt i den konsekventa hashringen).

Hur fungerar det rent operativt? Hur läggs noder till i systemet?

Det är enkelt att lägga till noder till cachingskiktet. Den centrala servern (R2) lägger till den nya noden i den konsekventa hashringen. Alla cacheservrar bör agera på denna förändring och bara ogiltigförklara sina cachelagda tabellskivor om de kommer att hanteras av den nya noden. Förfrågningar från klienter dirigeras till den nya servern, och ett meddelande om ändring av CH-ringen kommer att piggyback till klienten för att hämta den nya ringen från den centrala servern.

Hur hanterar du stora filer? Är det lämpligt för videoströmning?

Som tidigare beskrivits vidarebefordras stora filer till andra distribuerade filsystem. Vårt cachinglager kommer inte att förorenas av strömmande videodata.

Något annat du vill lägga till?

En annan figur för interaktion mellan Pomegranate-komponenterna.