GFS og dens udvikling

En fascinerende artikel, \ "GFS: Evolution på Fast-Forward \", i den seneste CACM bladet interviews Googler Sean Quinlan og udsætter de problemer, Google har haft med den legendariske Google File System, som virksomheden er vokset.

Nogle af de vigtigste uddrag: Beslutningen om at bygge den oprindelige GFS omkring [a] enkelt mester virkelig hjulpet at få noget ud af døren ... hurtigere .... [Men] problemer begyndt at ske ... går fra et par hundrede terabytes op til petabyte, og så op til tocifrede petabytes ... [Fordi] af mængden af metadata skibsføreren måtte opretholde.

[Også], når du har tusindvis af kunder alle taler med de samme master på samme tid ... den gennemsnitlige kunde ikke er i stand til at kommandere alle, at mange operationer per sekund. Der er applikationer såsom MapReduce, hvor du måske pludselig har en tusind opgaver, der hver ønsker at åbne en række filer. Naturligvis, ville det tage lang tid at håndtere alle disse anmodninger og master vil være under en hel del tvang.

64MB [var] den standard luns størrelse ... Da anvendelsen mix ændret sig over tid, men hvordan skulle vise sig at lade systemet klare effektivt med et stort antal filer [af] langt mindre end 64MB (tænke på Gmail, for eksempel). Problemet var ikke så meget med antallet af filer selv, men snarere med hukommelsen kræver alle disse [small] filer, som stilles på den centraliserede master .... Der er kun et begrænset antal filer, du kan rumme, før føreren løber tør for hukommelse.

Mange gange, det mest naturlige design for nogle ansøgning bare ikke ville passe ind i GFS - selvom ved første øjekast skulle man tro filen tælle ville være helt acceptabel, ville det vise sig at være et problem .... BigTable ... [Er] en mulig afhjælpning ... [Men] jeg vil sige, at de mennesker, der har brugt BigTable udelukkende til at beskæftige sig med fil-count problemet formentlig ikke har været frygtelig lykkelig.

GFS design model fra get-go var alt om at nå gennemløb, ikke om den ventetid, hvor det kan nås .... Generelt en hikke om rækkefølgen af et minut i løbet af en time lang batch job ikke rigtig dukker op. Hvis du arbejder på Gmail, imidlertid, og du forsøger at skrive en mutation, som repræsenterer nogle bruger handling, så sidder fast i et minut, reelt kommer til at rod dig op. Vi havde lignende problemer med vores mester failover. Oprindeligt GFS havde ingen mulighed for automatisk master fiasko. Det var en manuel proces ... Vores første [automatiserede] master-failover gennemførelse, der kræves på rækkefølgen af minutter .... Forsøger at opbygge en interaktiv database på toppen af et filsystem designet fra starten til at støtte mere batch-orienterede aktiviteter har bestemt vist sig at være en smerte punkt.

De grundlæggende forsøger at skjule, at latency, da de kender systemet nedenunder er egentlig ikke så stor. De fyre, der er bygget Gmail gik til en multihomed model, så hvis en instans af din Gmail-konto fik fast, ville du dybest set bare flyttet til et andet datacenter ... Denne evne var nødvendigt ... [Begge] for at sikre tilgængeligheden ... [Og] for at skjule GFS [latenstid] problemer.

Modellen i GFS er, at klienten bare fortsætter med at skubbe skrive indtil det lykkes. Hvis kunden ender ned midt i en operation, er ting tilbage i lidt af en ubestemt tilstand ... RecordAppend giver ikke nogen replay beskyttelse enten. Du kan ende med at få de data, der flere gange i en fil. Der var endda situationer, hvor man kunne få data i en anden rækkefølge ... [Og derefter] opdage poster i forskellige rækkefølger afhængig af hvilken bidder du tilfældigvis være at læse ... På det tidspunkt, må det have virket som en god idé, men set i bakspejlet jeg tror enighed om, at det viste sig at være mere smertefuldt end det var værd. Det bare ikke indfri de forventninger, folk har af et filsystem, så de ender med at få overrasket. Så måtte de finde ud af arbejds-arounds.Interesting at se udsatte vorter af Google File System og Bigtable. Jeg husker, da læser Bigtable papir, der overraskede over, at det var lagdelt oven på GFS. De tidlige beslutninger om at anvende en fil designet system til logs og batchbehandling af træstammer som grundlag for Googles interaktive databaser synes at have forårsaget en masse smerte og løsninger gennem årene.

På et beslægtet emne, et nyligt papir ud af Google, \ "Brug en markedsøkonomi Der Compute ressourcer på tværs af Planet-dækkende klynger \" (PDF), ser på et andet problem Google er der, prioritere alle de MapReduce batch job hos Google og forsøger at maksimere udnyttelsen af deres klynge. Papiret beskriver kun en test af en lovende løsning, bortauktionerer klyngen tid til incent udviklere til at flytte deres arbejdspladser til ikke-myldretiden og uudnyttede beregne ressourcer, men stadig en interessant læse.