CMG Brasil

Pomegranate je nový distribuovaný souborový systém postavený nad distribuovaným tabulkovým úložištěm, který se chová velmi podobně jako systém NoSQL. Je zaměřen na zvýšení výkonu přístupu k drobným objektům za účelem podpory aplikací, jako jsou online fotografické a mikroblogovací služby, které vyžadují vysokou souběžnost, vysokou propustnost a nízkou latenci. Jejich testy zřejmě naznačují, že to funguje:

Prokázali jsme, že souborový systém nad tabulkovým úložištěm funguje dobře pro vysoce souběžný přístup. V našem testovacím clusteru jsme pozorovali lineární nárůst více než 100 000 agregovaných požadavků na čtení a zápis obsloužených za sekundu (RPS).

Není umístěno nad souborovým systémem jako téměř každé jiné úložiště K-V, ale granátové jablko je zapracováno do souborového systému. Myšlenka spočívá v tom, že rozhraní API souborového systému je společné pro všechny platformy, takže by nevyžadovalo samostatné rozhraní API k použití. Každá aplikace by jej mohla používat hned po vybalení z krabice.

Funkce granátového jablka jsou následující:

• Efektivně zpracovává miliardy malých souborů, a to i v jednom adresáři;
• poskytuje samostatnou a škálovatelnou vrstvu mezipaměti, kterou lze snímkovat;
• Vrstva úložiště používá strukturované úložiště protokolů, které pohlcuje zápisy malých souborů, aby se využila šířka pásma disku;
• Vytváří globální jmenný prostor pro malé i velké soubory;
• Sloupcové úložiště pro využití časové a prostorové lokality;
• Distribuovaný rozšiřitelný hash pro indexování metadat;
• Snímkovatelná a rekonfigurovatelná mezipaměť pro zvýšení paralelismu a tolerance vůči selháním;
• Pomegranate by měl být prvním souborovým systémem, který je postaven nad tabulkovým úložištěm, a zkušenosti s budováním by měly být pro komunitu souborových systémů důstojné.

Can Ma, který vede výzkum granátového jablka, byl tak laskav a souhlasil s krátkým rozhovorem.

Můžete prosím uvést přehled architektury a co děláte skvělého a odlišného?

V zásadě neexistuje žádný distribuovaný nebo paralelní souborový systém, který by dokázal efektivně zpracovat miliardy malých souborů. Můžeme však předpokládat, že webové aplikace(jako je e-mail, fotografie a dokonce i video) a bio-počítače(sekvenování genů) potřebují masivní přístupy k malým souborům. Mezitím je rozhraní API souborového systému dostatečně obecné a dobře srozumitelné pro většinu programátorů.

Chceme tedy vytvořit souborový systém, který by spravoval miliardy malých souborů a poskytoval vysokou propustnost souběžných přístupů. Ačkoli je granátové jablko navrženo pro přístupy k malým souborům, nepodporuje ani velké soubory. Je postaven nad jinými distribuovanými souborovými systémy, jako je Lustre, a spravuje pouze jmenný prostor a malé soubory. Chceme prostě stát na „ramenou obrů“. Viz obrázek níže:

Pomegranate má mnoho serverů pro metadata a serverů pro ukládání metadat, které obsluhují požadavky na metadata a požadavky na čtení/zápis malých souborů. MDS jsou pouze vrstvou mezipaměti, která načítá metadata z úložiště a odevzdává snímky paměti do úložiště. Jádrem granátového jablka je distribuovaný systém tabulkového úložiště nazvaný xTable. Podporuje klíčové indexované vícesloupcové vyhledávání. K vyhledávání serveru z klíče používáme distribuovaný rozšiřitelný hash, protože rozšiřitelný hash je adaptabilnější na škálování nahoru a dolů.

V souborových systémech jsou adresářová a inodová tabulka vždy odděleny, aby podporovaly dva různé typy vyhledávání. Vyhledávání podle názvu cesty zpracovává adresářová tabulka, zatímco vyhledávání podle čísla inodu zpracovává inodová tabulka. Je netriviální tyto dva indexy důsledně aktualizovat, zejména v distribuovaném souborovém systému. Použití dvou indexů zároveň zvyšuje latenci vyhledávání, což je pro přístup k malým souborům nepřijatelné. Obvykle existují mezipaměti pro dentry a inode, nicméně tyto mezipaměti nelze snadno rozšiřovat. Při úpravě metadat je nutné aktualizovat více umístění. Pro zachování konzistence je zaveden protokol operací. Zatímco log operací je vždy sériovým bodem pro toky požadavků.

Pomegranate používá adresářovou strukturu podobnou tabulce, která sloučí tabulku adresářů a tabulku inodů. Dva různé typy vyhledávání jsou sjednoceny na vyhledávání podle klíče. Pro souborový systém je klíčem hash hodnota názvu dentry. Konflikty hashů se řeší pomocí globálního jedinečného id pro každý soubor. Pro každou aktualizaci stačí prohledat a aktualizovat jednu tabulku. Abychom eliminovali protokol operací, navrhujeme a podporujeme snímky paměti pro získání konzistentního obrazu. Znečištěné oblasti každého snímku lze bezpečně zapsat do paměti bez ohledu na souběžné úpravy (souběžné aktualizace jsou COWed.)

Je však třeba zvážit některé složité operace souborového systému, jako jsou mkdir, rmdir, hard link a rename. Tyto operace musí aktualizovat alespoň dvě tabulky. Implementujeme spolehlivou vícemístnou aktualizační službu pro šíření delt z jedné tabulky do druhé. Například při mkdir propagujeme delta(„nlink +1“) do nadřazené tabulky.

Existují nějaké jednotlivé body selhání?

V návrhu není žádné SPOF. K obsluze požadavku na metadata používáme cluster MDS. Pokud dojde k havárii jednoho MDS, jsou požadavky přesměrovány na ostatní MDS(používá se konzistentní hash a heartbeats). Metadata a malé soubory jsou replikovány buď do více uzlů. Tato replikace je však spouštěna externími synchronizačními nástroji, které jsou asynchronní vůči zápisům.

Malé soubory byly obvykle smrtí souborových systémů kvůli údržbě adresářové struktury. Jak to obejdete?

Ano, v tradičních souborových systémech je přístup k malým souborům smrtelně pomalý. Tradiční adresářovou tabulku (B+ strom nebo hašovací strom) nahradíme distribuovanou rozšiřitelnou hašovací tabulkou. Název dentry a metadata inodu jsou považovány za sloupce tabulky. Vyhledávání od klientů jsou odesílána (nebo v případě potřeby směrována) do správného MDS. Pro přístup k malému souboru tedy stačí přistoupit k jednomu řádku tabulky, abychom zjistili umístění souboru. Každý malý soubor uchováváme sekvenčně v nativním souborovém systému. Výsledkem je, že jeden vstupně-výstupní přístup může sloužit ke čtení malého souboru.

Jaké posixové apis jsou podporovány? Lze soubory zamykat, mapovat, používat symlinky atd.

V současné době podpora POSIXu postupuje. Podporujeme symlinky, mmap přístup. Zatímco flock podporován není.

Proč dělat souborový systém na úrovni jádra a ne K-V úložiště nad ním?

Naším prvotním cílem je implementovat souborový systém, který bude podporovat více existujících aplikací. Zatímco nyní podporujeme K/V rozhraní nad xTable. Viz obrázek architektury, klient AMC je klient klíč/hodnota pro granátové jablko. Podporujeme jednoduché predikáty na klíči nebo hodnotě, například podporujeme „select * from table where key < 10 and ‚xyz‘ in value“ pro získání k/v párů, které hodnota obsahuje „xyz“ a klíč < 10.

Jak je to ve srovnání s jinými distribuovanými souborovými systémy?

Chceme porovnat výkon malých souborů s jinými souborovými systémy. Zatím jsme jej však netestovali. Uděláme to v příštím měsíci. I když se domníváme, že většina distribuovaných souborových systémů nedokáže efektivně zpracovávat masivní přístupy k malým souborům.

Jsou podporovány indexy a jakýkoli druh dotazů?

Prozatím tyto podpory ještě nebyly řádně zváženy. Příště plánujeme zvážit rozsahové dotazy.

Funguje napříč datovými centry, tj. jak se vypořádává s latencí?

Pomegranate funguje pouze v datovém centru. O podpoře WAN se zatím neuvažuje.

Vypadá to, že kvůli rychlosti používáte architekturu in-memory. Můžete o tom mluvit?

Pro rychlost používáme vyhrazenou vrstvu cache paměti. Řádky tabulky jsou seskupeny jako plátky tabulky. V paměti jsou sl
ice tabulky zaheslovány do lokální rozšiřitelné hashovací tabulky, a to jak kvůli výkonu, tak kvůli spotřebě místa. Jak ukazuje následující obrázek,

Klienti vydávají požadavky pomocí hashování názvu souboru a vyhledávání v bitové mapě. Poté pomocí konzistentního hashovacího kruhu vyhledá server mezipaměti(MDS) nebo server úložiště(MDSL). Každá aktualizace nejprve získá *otevřenou* skupinu transakcí a může se použít pouze na řádek tabulky v paměti. Každá změna skupiny transakcí je atomická. Po dokončení všech čekajících aktualizací lze skupinu transakcí bezpečně odevzdat do úložiště. Tento přístup je podobný jako u systému ZFS společnosti Sun.

Jak je řešena vysoká dostupnost?

Centrální server pro konzistentní správu kruhu hash a koordinátor poruch by měl být replikován algoritmem Paxos. Pro vysokou dostupnost centrální služby plánujeme použít ZooKeeper.
Ostatní komponenty jsou navrženy tak, aby byly odolné vůči poruchám. Havárie MDS a MDSL lze nakonfigurovat jako okamžitě obnovitelné směrováním požadavků na nové servery (výběrem dalšího bodu v konzistentním hash kruhu).

Operativně, jak to funguje? Jak se do systému přidávají uzly?

Přidávání uzlů do vrstvy cache je jednoduché. Centrální server (R2) přidá nový uzel do konzistentního kruhu hash. Všechny servery cache by měly na tuto změnu reagovat a pouze zneplatnit své plátky tabulky cache, pokud je bude nový uzel spravovat. Požadavky od klientů jsou směrovány na nový server a oznámení o změně kruhu CH se klientovi vrátí, aby si z centrálního serveru vytáhl nový kruh.

Jak řešíte velké soubory? Je to vhodné pro streamování videa?

Jak bylo popsáno dříve, velké soubory jsou předávány jiným distribuovaným souborovým systémům. Naše vrstva mezipaměti nebude znečištěna daty streamovaného videa.

Chcete ještě něco dodat?

Další obrázek pro interakci komponent granátového jablka.

.