Googles filsystem - Google File System

Googles filsystem
Operativsystem Linux-kjernen
Type Distribuert filsystem
Tillatelse Proprietær

Google File System ( GFS eller GoogleFS , ikke å forveksle med GFS Linux-filsystemet) er et proprietært distribuert filsystem utviklet av Google for å gi effektiv, pålitelig tilgang til data ved hjelp av store klynger av råvare . Den siste versjonen av Google File System med kodenavnet Colossus ble utgitt i 2010.

Design

Image
Google File System er designet for interaksjon mellom system og system, og ikke for interaksjon mellom bruker og system. Chunk-serverne replikerer dataene automatisk.

GFS er forbedret for Googles kjerne behov for datalagring og bruk (primært søkemotoren ), som kan generere enorme mengder data som må beholdes; Google File System vokste ut av en tidligere Google-innsats, "BigFiles", utviklet av Larry Page og Sergey Brin i Googles tidlige dager, mens den fremdeles befant seg i Stanford . Filer er delt inn i biter av fast størrelse på 64 megabyte , som ligner på klynger eller sektorer i vanlige filsystemer, som bare ekstremt sjelden blir overskrevet eller krympet; filer blir vanligvis lagt til eller lest. Den er også designet og optimalisert for å kjøre på Googles databehandlingsklynger, tette noder som består av billige "handelsvare" -maskiner, noe som betyr at det må tas forholdsregler mot den høye sviktfrekvensen til individuelle noder og det påfølgende datatapet. Andre designbeslutninger velger høy datagjennomstrømning , selv når det koster ventetid .

En GFS-klynge består av flere noder. Disse nodene er delt inn i to typer: en master node og flere Chunkservers . Hver fil er delt inn i biter av fast størrelse. Chunkservers lagrer disse bitene. Hver del blir tildelt en globalt unik 64-biters etikett av masternoden på tidspunktet for opprettelsen, og logiske kartlegginger av filer til komponentbiter opprettholdes. Hver del replikeres flere ganger i hele nettverket. Som standard replikeres den tre ganger, men dette kan konfigureres. Filer som er i høy etterspørsel kan ha en høyere replikasjonsfaktor, mens filer som applikasjonsklienten bruker strenge lagringsoptimaliseringer for, kan replikeres mindre enn tre ganger - for å takle raske retningslinjer for rengjøring av søppel.

Master-serveren lagrer vanligvis ikke de faktiske bitene, men heller alle metadataene som er knyttet til bitene, for eksempel tabellene som kartlegger 64-biters etiketter til klumpsteder og filene de utgjør (kartlegging fra filer til klumper), plasseringene av kopiene av biter, hvilke prosesser som leses eller skrives til en bestemt del, eller tar et "øyeblikksbilde" av biter i henhold til å replikere det (vanligvis på initiativ av Masterserveren, når antallet på grunn av nodefeil av kopier av en del har falt under angitt nummer). Alle disse metadataene holdes oppdatert ved at masterserveren regelmessig mottar oppdateringer fra hver klumpserver ("Heart-beat meldinger").

Tillatelser for modifikasjoner håndteres av et system med tidsbegrensede, utløpende "leieavtaler", der masterserveren gir tillatelse til en prosess i en begrenset periode der ingen annen prosess vil bli gitt tillatelse fra masterserveren til å endre klumpen. . Den modifiserende chunkserveren, som alltid er den primære chunkholderen, forplanter deretter endringene til chunkserverne med sikkerhetskopiene. Endringene lagres ikke før alle klosservere erkjenner, og dermed garanterer fullføringen og atomiciteten til operasjonen.

Programmer får tilgang til biter ved først å spørre Master-serveren for plassering av de ønskede biter; hvis biter ikke blir operert (dvs. ingen utestående leiekontrakter eksisterer), svarer mesteren med stedene, og programmet kontakter og mottar deretter dataene fra bitereserveren direkte (ligner på Kazaa og dets supernoder ).

I motsetning til de fleste andre filsystemer er GFS ikke implementert i kjernen til et operativsystem , men blir i stedet gitt som et brukerområde- bibliotek.

Grensesnitt

Google File System har ikke et POSIX- grensesnitt. Filer er organisert hierarkisk i kataloger og identifisert av stienavn. Filoperasjonene som å opprette, slette, åpne, lukke, lese, skrive støttes. Den støtter Record Append som gjør at flere klienter kan legge til data i den samme filen samtidig, og atomisitet er garantert.

Opptreden

Ved å bestemme ut fra benchmarking-resultater, når det brukes med relativt lite antall servere (15), oppnår filsystemet leserytelse som er sammenlignbar med en enkelt disk (80–100 MB / s), men har redusert skriveytelse (30 MB / s) ), og er relativt treg (5 MB / s) i å legge data til eksisterende filer. Forfatterne presenterer ingen resultater på tilfeldig søketid. Siden masternoden ikke er direkte involvert i datalesing (dataene overføres fra klumpserveren direkte til leseklienten), øker lesehastigheten betydelig med antall kortservere, og oppnår 583 MB / s for 342 noder. Aggregering av flere servere tillater også stor kapasitet, mens det reduseres noe ved å lagre data på tre uavhengige steder (for å gi redundans).

Se også

Referanser

Bibliografi

Eksterne linker

  • "GFS: Evolution on Fast-forward", Kø , ACM .
  • "Google File System Eval, Part I", Storage mojo .