CMG Brasil

Pomegranate on uudenlainen hajautettu tiedostojärjestelmä, joka on rakennettu hajautetun taulukkomuistitallennuksen päälle ja joka käyttäytyy pitkälti kuin NoSQL-järjestelmä. Se on suunnattu lisäämään pienten objektien käytön suorituskykyä, jotta voidaan tukea sovelluksia, kuten verkkokuvapalveluja ja mikroblogipalveluja, jotka vaativat suurta samanaikaisuutta, suurta läpimenoa ja pientä latenssia. Heidän testinsä näyttävät osoittavan, että se toimii:

Me olemme osoittaneet, että tiedostojärjestelmä yli taulukkomuotoisen tallennuksen toimii hyvin erittäin samanaikaisessa käytössä. Testiklusterissamme havaitsimme lineaarisesti kasvaneen yli 100 000 yhteenlasketun luku- ja kirjoituspyynnön palvelemisen sekunnissa (RPS).

Sen sijaan, että Pomegranate istuisi tiedostojärjestelmän päällä, kuten lähes kaikki muut K-V-varastot, se on sisäänrakennettu tiedostojärjestelmään. Ajatuksena on, että tiedostojärjestelmän API on yhteinen kaikille alustoille, joten sen käyttäminen ei vaatisi erillistä API:ta. Jokainen sovellus voisi käyttää sitä valmiiksi.

Pomegranaten ominaisuuksia ovat:

• Se käsittelee tehokkaasti miljardeja pieniä tiedostoja, jopa yhdessä hakemistossa;
• Se tarjoaa erillisen ja skaalautuvan välimuistikerroksen, joka voi olla tilannekuvakelpoinen;
• Tallennuskerros käyttää lokien strukturoitua varastoa pienten tiedostojen kirjoitusten vaimentamiseen, jotta levyn kaistanleveys saadaan hyödynnettyä;
• Rakennetaan globaalia nimitilaa sekä pienille tiedostoille että suurille tiedostoille;
• Sarakkeellinen tallennus ajallisen ja alueellisen paikallisuuden hyödyntämiseksi;
• Hajautettu laajennettavissa oleva hash metatietojen indeksoimiseksi;
• Snapshot-kelpoinen ja uudelleenkonfiguroitavissa oleva välimuistitallennus rinnakkaisuuden lisäämiseksi ja vikasietoiseksi vikojen sietämiseksi;
• Pomegranaten pitäisi olla ensimmäinen tiedostojärjestelmä, joka rakennetaan taulukkomuotoisen tallennusmuistion varaan, ja rakennuskokemuksen pitäisi olla tiedostojärjestelmäyhteisön kannalta arvokas.

Can Ma, joka johtaa Pomegranaten tutkimusta, oli niin ystävällinen, että suostui lyhyeen haastatteluun.

Voisitko antaa yleiskatsauksen arkkitehtuurista ja siitä, mitä siistiä ja erilaista teette?

Periaatteessa ei ole mitään hajautettua tai rinnakkaista tiedostojärjestelmää, joka pystyisi käsittelemään tehokkaasti miljardeja pieniä tiedostoja. Voimme kuitenkin ennakoida, että web-sovellukset (kuten sähköposti, valokuvat ja jopa videot) ja biotietokoneet (geenisekvensointi) tarvitsevat massiivisia pieniä tiedostoja. Samaan aikaan tiedostojärjestelmän sovellusliittymä on riittävän yleinen ja ymmärrettävä useimmille ohjelmoijille.

Haluamme siis rakentaa tiedostojärjestelmän, joka pystyy hallitsemaan miljardeja pieniä tiedostoja ja tarjoamaan suuren läpimenotehon samanaikaisille tiedostokäynneille. Vaikka Pomegranate on suunniteltu pienten tiedostojen käyttöä varten, se tukee myös suuria tiedostoja. Se on rakennettu muiden hajautettujen tiedostojärjestelmien, kuten Lustren, päälle, ja se hallitsee vain nimiavaruutta ja pieniä tiedostoja. Haluamme vain seistä ”jättiläisten harteilla”. Katso alla olevaa kuvaa:

Pomegranatessa on monia metatietopalvelimia ja metatietojen tallennuspalvelimia, jotka palvelevat metatietopyyntöjä ja pienten tiedostojen luku- ja kirjoituspyyntöjä. MDS-palvelimet ovat vain välimuistikerros, joka lataa metatietoa tallennustilasta ja sitouttaa muistin tilannekuvat tallennustilaan. Pomegranaten ydin on hajautettu taulukkomuotoinen tallennusjärjestelmä nimeltä xTable. Se tukee avainindeksoituja monisarakkeisia hakuja. Käytämme hajautettua laajennettavaa hashia palvelimen paikantamiseen avaimesta, koska laajennettava hash on mukautuvampi skaalautumaan ylös- ja alaspäin.

Tiedostojärjestelmissä hakemistotaulukko ja inode-taulukko erotetaan aina toisistaan, jotta ne tukevat kahta erityyppistä hakua. Polunimen perusteella tapahtuva haku hoidetaan hakemistotaulussa, kun taas inode-numeron perusteella tapahtuva haku hoidetaan inode-taulussa. Näiden kahden indeksin johdonmukainen päivittäminen ei ole yksinkertaista, varsinkaan hajautetussa tiedostojärjestelmässä. Samalla kahden indeksin käyttö on lisännyt hakujen viiveaikaa, jota ei voida hyväksyä, kun käytetään pieniä tiedostoja. Tyypillisesti dentrylle ja inodelle on muistissa välimuistit, mutta välimuisteja ei voi helposti laajentaa. Metatietojen muuttaminen edellyttää useiden paikkojen päivittämistä. Yhdenmukaisuuden säilyttämiseksi otetaan käyttöön toimintoloki. Operaatioiden loki on kuitenkin aina pyyntövirtojen sarjapiste.

Pomegranate käyttää taulukkomaista hakemistorakennetta hakemistotaulukon ja inode-taulukon yhdistämiseksi. Kaksi erilaista hakutyyppiä on yhdistetty avaimen mukaan tapahtuviin hakuihin. Tiedostojärjestelmän osalta avain on hammastunnuksen nimen hash-arvo. Ristiriidat ratkaistaan kunkin tiedoston globaalilla yksilöllisellä tunnuksella. Jokaista päivitystä varten on etsittävä ja päivitettävä vain yksi taulukko. Toimintalokin eliminoimiseksi suunnittelemme ja tuemme muistin tilannekuvaa yhtenäisen kuvan saamiseksi. Kunkin tilannekuvan likaiset alueet voidaan kirjoittaa tallennustilaan turvallisesti ottamatta huomioon samanaikaisia muutoksia.(Samanaikaiset päivitykset ovat COWed.)

On kuitenkin olemassa joitakin monimutkaisia tiedostojärjestelmäoperaatioita, kuten mkdir, rmdir, hard link ja rename, jotka on otettava huomioon. Näiden operaatioiden on päivitettävä vähintään kaksi taulua. Toteutamme luotettavan multisite-päivityspalvelun, joka levittää deltat yhdestä taulusta toiseen. Esimerkiksi mkdir-tapahtumassa siirretään delta(”nlink +1”) emotaulukkoon.

Onko olemassa yksittäisiä vikapisteitä?

Suunnittelussa ei ole SPOF:ia. Käytämme MDS-klusteria palvelemaan metatietopyyntöjä. Jos yksi MDS kaatuu, pyynnöt ohjataan muille MDS:ille (käytetään johdonmukaista hashia ja heartbeatia). Metatiedot ja pienet tiedostot kopioidaan useisiin solmuihin. Tämä replikointi käynnistetään kuitenkin ulkoisilla synkronointityökaluilla, jotka ovat asynkronisia kirjoituksiin nähden.

Pienet tiedostot ovat yleensä olleet tiedostojärjestelmien kuolema hakemistorakenteen ylläpidon vuoksi. Miten sen voi kiertää?

Jep, pienten tiedostojen käyttö on tappavan hidasta perinteisissä tiedostojärjestelmissä. Korvaamme perinteisen hakemistotaulun (B+-puu tai hash-puu) hajautetulla laajennettavalla hash-taululla. Hammasluettelon nimi ja inode-metatiedot käsitellään taulun sarakkeina. Asiakkaiden hakuja lähetetään (tai ohjataan tarvittaessa) oikeaan MDS-tietokantaan. Näin ollen pientä tiedostoa hakiessa tarvitaan vain yksi taulukon rivi tiedoston sijainnin löytämiseksi. Jokainen pieni tiedosto tallennetaan peräkkäin natiiviin tiedostojärjestelmään. Tämän seurauksena yksi I/O-käynti voi palvella pientiedoston lukemista.

Mitä posix-apujärjestelmiä tuetaan? Voiko tiedostoja lukita, kartoittaa, käyttää symlinkkejä jne?

Tällä hetkellä POSIX-tuki etenee. Tuemme symlinkkejä, mmap-käyttöä. Flockia ei kuitenkaan tueta.

Miksi tehdä ydintason tiedostojärjestelmä eikä K-V-varastoa päälle?

Alustavana tavoitteenamme on toteuttaa tiedostojärjestelmä, joka tukee useampia nykyisiä sovelluksia. Vaikka tuemme K/V-rajapintaa xTable-taulukon päällä nyt. Katso kuva arkkitehtuurista, AMC-asiakas on Pomegranaten avain/arvo-asiakas. Tuemme yksinkertaisia predikaatteja avaimelle tai arvolle, esimerkiksi tuemme ”select * from table where key < 10 and ’xyz’ in value” saadaksemme k/v-parit, joiden arvo sisältää ”xyz” ja avain < 10.

Miten se vertautuu muihin hajautettuihin tiedostojärjestelmiin?

Haluamme verrata pienten tiedostojen suorituskykyä muihin tiedostojärjestelmiin. Emme ole kuitenkaan vielä testanneet sitä. Teemme sen ensi kuussa. Uskomme kuitenkin, että useimmat hajautetut tiedostojärjestelmät eivät pysty käsittelemään massiivisia pienten tiedostojen käyttökertoja tehokkaasti.

Tuetaanko indeksejä ja kaikenlaisia kyselyjä?

Toistaiseksi näitä tukia ei ole vielä harkittu kunnolla. Seuraavaksi aiomme harkita range-kyselyjä.

Toimii se yli datakeskusten, eli miten se käsittelee latenssia?

Pomegranate toimii vain datakeskuksessa. WAN-tukea ei ole vielä huomioitu.

Näyttää siltä, että käytät nopeuden vuoksi in-memory-arkkitehtuuria. Voitteko kertoa siitä?

Käytämme dedikoitua muistin välimuistikerrosta nopeuden vuoksi. Taulukon rivit ryhmitellään taulukkoviipaleiksi. Muistissa taulukon viipaleita
hashataan paikalliseen laajennettavaan hash-tauluun sekä suorituskyvyn että tilankulutuksen vuoksi. Alla olevasta kuvasta käy ilmi,

Asiakkaat esittävät pyynnön hashilla tiedostonimen ja etsivät sen bittikartasta. Sitten käytetään johdonmukaista hash-rengasta välimuistipalvelimen (MDS) tai tallennuspalvelimen (MDSL) paikantamiseen. Jokainen päivitys saa ensin *avattua* tapahtumaryhmän, ja sitä voidaan soveltaa vain muistissa olevaan taulukkoriviin. Jokainen transaktioryhmän muutos on atominen. Kun kaikki vireillä olevat päivitykset on saatu valmiiksi, transaktioryhmä voidaan siirtää turvallisesti muistiin. Tämä lähestymistapa on samanlainen kuin Sunin ZFS.

Miten korkea käytettävyys hoidetaan?

Keskuspalvelin johdonmukaista hash-renkaan hallintaa ja vikakoordinaattoria varten tulisi replikoida Paxos-algoritmilla. Aiomme käyttää ZooKeeperiä korkean saatavuuden keskuspalveluun.
Muut komponentit on suunniteltu vikasietoisiksi. MDS:n ja MDSL:n kaatumiset voidaan konfiguroida niin, että niistä voidaan toipua välittömästi reitittämällä pyynnöt uusille palvelimille (valitsemalla seuraava piste johdonmukaisessa hash-renkaassa).

Käytännöllisesti katsoen, miten se toimii? Miten solmuja lisätään järjestelmään?

Solmujen lisääminen välimuistikerrokseen on yksinkertaista. Keskuspalvelin (R2) lisää uuden solmun johdonmukaiseen hash-renkaaseen. Kaikkien välimuistipalvelimien pitäisi toimia tämän muutoksen mukaan ja vain mitätöidä välimuistiin tallennetut taulukkosiivunsa, jos ne ovat uuden solmun hallinnassa. Asiakkaiden pyynnöt ohjataan uudelle palvelimelle, ja CH-rengasmuutosilmoitus piggybackaa asiakkaan vetämään uuden renkaan keskuspalvelimelta.

Miten käsittelet suuria tiedostoja? Soveltuuko se videon suoratoistoon?

Kuten aiemmin kuvattiin, suuret tiedostot välitetään muille hajautetuille tiedostojärjestelmille. Suoratoistovideodata ei saastuta välimuistikerrostamme.

Mitä muuta haluaisit lisätä?

Toinen luku Pomegranate-komponenttien vuorovaikutuksesta.