CMG Brasil

A Pomegranate egy újszerű elosztott fájlrendszer, amely elosztott táblázatos tárolórendszerre épül, és nagyon hasonlít egy NoSQL rendszerre. Célja az apró objektumokhoz való hozzáférés teljesítményének növelése az olyan alkalmazások támogatása érdekében, mint az online fotó- és mikroblog-szolgáltatások, amelyek nagy párhuzamosságot, nagy áteresztőképességet és alacsony késleltetést igényelnek. Tesztjeik alapján úgy tűnik, hogy működik:

Mutatjuk, hogy a táblázatos tároló feletti fájlrendszer jól teljesít a nagymértékben egyidejű hozzáférés esetén. A tesztfürtünkben lineárisan megnövekedett, több mint 100 000 összesített, másodpercenként kiszolgált olvasási és írási kérést (RPS) figyeltünk meg.

A Pomegranate ahelyett, hogy a fájlrendszer tetején ülne, mint szinte minden más K-V tároló, a fájlrendszerbe van beépítve. Az ötlet lényege, hogy a fájlrendszer API közös minden platformon, így nem lenne szükség külön API-ra a használatához. Minden alkalmazás használhatná out of the box.

A Pomegranate jellemzői a következők:

• Ez hatékonyan kezeli a több milliárd kis fájlt, akár egy könyvtárban is;
• Ez különálló és skálázható gyorsítótárazási réteget biztosít, amely pillanatfelvétel-képezhető;
• A tárolási réteg naplózott strukturált tárolót használ a kis fájlok írásának elnyelésére, hogy kihasználja a lemez sávszélességét;
• Elkészít egy globális névteret mind a kis fájlok, mind a nagy fájlok számára;
• oszlopos tárolás az időbeli és térbeli lokalitás kihasználására;
• elosztott, bővíthető hash a metaadatok indexelésére;
• Snapshot-olható és újrakonfigurálható gyorsítótár a párhuzamosság és a hibatűrés növelése érdekében;
• A Pomegranate legyen az első olyan fájlrendszer, amely táblázatos tárolásra épül, és az építés tapasztalata méltó legyen a fájlrendszerek közösségéhez.

Can Ma, aki a Pomegranate kutatását vezeti, volt olyan kedves, hogy beleegyezett egy rövid interjúba.

Kérlek, adj egy áttekintést az architektúráról, és arról, hogy mit csinálsz, ami menő és más?

Alapvetően nincs olyan elosztott vagy párhuzamos fájlrendszer, amely hatékonyan tudná kezelni a több milliárd kis fájlt. Előre láthatjuk azonban, hogy a webes alkalmazásoknak (például e-mail, fotó, sőt videó) és a bio-számítástechnikának (génszekvenálás) masszív kis fájlelérésekre van szüksége. Eközben a fájlrendszer API elég általános és jól érthető a legtöbb programozó számára.

Ezért szeretnénk egy olyan fájlrendszert építeni, amely több milliárd kis fájlt képes kezelni, és nagy átviteli teljesítményt biztosít az egyidejű hozzáférésekhez. Bár a Pomegranate-et kis fájlok elérésére tervezték, a nagy fájlokat is támogatja. Más elosztott fájlrendszerekre, például a Lustre-re épül, és csak a névteret és a kis fájlokat kezeli. Mi csak “óriások vállán” akarunk állni. Lásd az alábbi ábrát:

A Pomegranate számos metaadatkiszolgálóval és metaadattároló kiszolgálóval rendelkezik a metaadatkérések és a kis fájlok írási/olvasási kéréseinek kiszolgálására. Az MDS-ek csak egy gyorsítótárazási réteg, amelyek metaadatokat töltenek be a tárolóból, és memóriapillanatképeket rögzítenek a tárolóba. A Pomegranate magja egy elosztott táblázatos tárolórendszer, az xTable. Támogatja a kulcsindexált több oszlopos kereséseket. A kulcsból történő szerverkereséshez elosztott extendible hash-t használunk, mivel a extendible hash jobban alkalmazkodik a felfelé és lefelé történő skálázáshoz.

A fájlrendszerekben a könyvtártábla és az inode tábla mindig elkülönül, hogy két különböző típusú keresést támogasson. Az elérési név szerinti keresést a könyvtártábla, míg az inode szám szerinti keresést az inode tábla kezeli. E két index következetes frissítése nem triviális, különösen egy elosztott fájlrendszerben. Eközben a két index használata megnövelte a keresési késleltetést, ami elfogadhatatlan az apró fájlok eléréséhez. Jellemzően memórián belüli gyorsítótárak vannak a dentry és az inode számára, azonban a gyorsítótárak nem könnyen bővíthetők. A metaadatok módosításához több helyet kell frissíteni. A konzisztencia fenntartása érdekében bevezetésre került a műveleti napló. Míg a műveleti napló mindig egy soros pont a kérések áramlásához.

A Pomegranate egy táblázatszerű könyvtárszerkezetet használ a könyvtártábla és az inode tábla összevonására. A két különböző típusú keresés egyesül a kulcs szerinti keresésre. A fájlrendszer esetében a kulcs a dentry név hash-értéke. A hash-konfliktusokat az egyes fájlok globális egyedi azonosítója oldja fel. Minden egyes frissítéshez csak egy táblázatot kell keresnünk és frissítenünk. A műveleti napló kiküszöbölése érdekében memória pillanatfelvételeket tervezünk és támogatunk, hogy konzisztens képet kapjunk. Az egyes pillanatképek piszkos régióit biztonságosan ki lehet írni a tárolóba az egyidejű módosítások figyelembevétele nélkül.(Az egyidejű frissítések COWed.)

Valamint vannak olyan összetett fájlrendszer műveletek, mint az mkdir, rmdir, hard link és az átnevezés, amelyeket figyelembe kell venni. Ezeknek a műveleteknek legalább két táblát kell frissíteniük. Megbízható multisite frissítési szolgáltatást valósítunk meg a delták egyik táblából a másikba történő átvitelére. Például az mkdir esetén a delta(“nlink +1”) értéket továbbítjuk a szülő táblába.

Léteznek egyetlen hibapontok?

A tervezés során nincs SPOF. MDS-ek fürtjét használjuk a metaadatkérések kiszolgálására. Ha egy MDS összeomlik, a kéréseket átirányítjuk a többi MDS-hez (konzisztens hash és heartbeats használatban). A metaadatokat és a kis fájlokat több csomópontra is replikáljuk. Ezt a replikációt azonban külső szinkronizáló eszközök váltják ki, ami aszinkron az írásokhoz képest.

A kis fájlok általában a fájlrendszerek halálát jelentették a könyvtárszerkezet karbantartása miatt. Hogyan lehet ezt megkerülni?

Igen, a hagyományos fájlrendszerekben halálosan lassú a kis fájlok elérése. A hagyományos könyvtártáblát (B+ fa vagy hash tree) elosztott, bővíthető hash táblára cseréljük. A dentry nevet és az inode metaadatokat a tábla oszlopaként kezeljük. A kliensek keresései a megfelelő MDS-hez kerülnek (vagy szükség esetén átirányításra). Így egy kis fájl eléréséhez csak egy táblázatsorhoz kell hozzáférnünk, hogy megtaláljuk a fájl helyét. Minden kis fájlt szekvenciálisan tárolunk a natív fájlrendszerben. Ennek eredményeképpen egy I/O elérés kiszolgálhat egy kis fájl olvasását.

Milyen posix apik támogatottak? A fájlokat lehet-e zárolni, leképezni, symlinkeket, stb?

A POSIX-támogatás jelenleg folyamatban van. Támogatjuk a symlinkeket, mmap hozzáférést. Míg a flock nem támogatott.

Miért csinálunk kernel szintű fájlrendszert ahelyett, hogy egy K-V tárolót tennénk rá?

A kezdeti célunk egy olyan fájlrendszer megvalósítása, amely több meglévő alkalmazást támogat. Bár most már támogatjuk a K/V interfészt az xTable tetején. Lásd az architektúra ábráját, az AMC kliens a Pomegranate kulcs/érték kliense. Támogatjuk az egyszerű predikátumokat a kulcsra vagy értékre, például támogatjuk a “select * from table where key < 10 and ‘xyz’ in value”, hogy megkapjuk azokat a k/v párokat, amelyek értéke tartalmazza az “xyz”-t és a kulcsot < 10.

Hogyan viszonyul más elosztott fájlrendszerekhez?

A kis fájlok teljesítményét szeretnénk összehasonlítani más fájlrendszerekkel. Azonban még nem teszteltük. A következő hónapban fogjuk megtenni. Bár úgy gondoljuk, hogy a legtöbb elosztott fájlrendszer nem képes hatékonyan kezelni a tömeges kis fájleléréseket.

Támogatottak az indexek és bármilyen lekérdezés?

Egyelőre ezeket a támogatásokat még nem vettük megfelelően figyelembe. Azt tervezzük, hogy legközelebb a tartomány-lekérdezéseket vesszük figyelembe.

Működik az adatközpontok között, azaz hogyan kezeli a késleltetést?

A pomegranate csak egy adatközpontban működik. A WAN-támogatást még nem vették figyelembe.

Úgy tűnik, hogy a sebesség érdekében memórián belüli architektúrát használ. Tudna erről beszélni?

A sebesség érdekében dedikált memória cache réteget használunk. A táblázat sorai táblázatszeletként vannak csoportosítva. A memóriában a táblaszeleteket egy helyi, bővíthető hash-táblába hash-eljük mind a teljesítmény, mind a helyfogyasztás miatt. Az alábbi ábrán látható,

A kliensek a kérést a fájlnév hashelésével és a bittérképben való kereséssel adják ki. Ezután egy konzisztens hash-gyűrű segítségével megkeresi a gyorsítótár-kiszolgálót (MDS) vagy a tárolókiszolgálót (MDSL). Minden frissítés először megkapja a *nyitott* tranzakciós csoportot, és csak a memóriában lévő táblázatsorra alkalmazható. Minden tranzakciócsoport-változás atomikus. Miután az összes függőben lévő frissítés befejeződött, a tranzakciócsoport biztonságosan átvihető a tárolóba. Ez a megközelítés hasonló a Sun ZFS-éhez.

Hogyan kezelik a magas rendelkezésre állást?

Nos, a központi szervert a konzisztens hash-gyűrű kezeléséhez és a hibakoordinátorhoz Paxos algoritmussal kell replikálni. A ZooKeepert tervezzük használni a magas rendelkezésre állású központi szolgáltatáshoz.
A többi komponenst úgy terveztük, hogy hibatűrő legyen. Az MDS és az MDSL összeomlása úgy konfigurálható, hogy a kérések új szerverekre való átirányításával (a konzisztens hash-gyűrű következő pontjának kiválasztásával) azonnal helyreállítható.

Működésileg hogyan működik? Hogyan adnak hozzá csomópontokat a rendszerhez?

A csomópontok hozzáadása a gyorsítótárazási réteghez egyszerű. A központi szerver (R2) hozzáadja az új csomópontot a konzisztens hash-gyűrűhöz. Az összes gyorsítótár-kiszolgálónak reagálnia kell erre a változásra, és csak érvényteleníteniük kell a gyorsítótárazott táblaszeleteket, ha azokat az új csomópont fogja kezelni. Az ügyfelektől érkező kéréseket az új szerverhez irányítjuk, és egy CH gyűrűváltásról szóló értesítés malacperselyben fogja az ügyfelet az új gyűrű kihúzására a központi szerverről.

Hogyan kezeli a nagyméretű fájlokat? Alkalmas-e videó streamingre?

A korábban leírtak szerint a nagyméretű fájlokat más elosztott fájlrendszerekhez továbbítják. A mi gyorsítótárazási rétegünket nem szennyezik a streaming videóadatok.

Mást is szeretne hozzátenni?

Még egy ábra a Pomegranate komponenseinek kölcsönhatásáról.