Universitatea Alexandru Ioan Cuza Facultatea de Informatică

Transcription

1 Universitatea Alexandru Ioan Cuza Facultatea de Informatică Conf. Dr. Lenuța Alboaie

2 Cuprins Sisteme de fisiere caracteristici Sisteme de fisiere distribuite Vocabular Cerinte Aspecte Sa schitam un sistem de fisiere distribuite simplificat Studii de caz: Sun Network File System, AFS, GFS, HDFS 2

3 Sisteme de fisiere Caracteristici Sistem de stocare permanenta a datelor De obicei, aflat in partea de sus al nivelelor mediilor de stocare fizica? Baze de date? Divizat in unitati logice numite files Adresabil prin filename ( test1_cloud.txt ) Contin: data si attributes Data accesibila prin operatii de citire/scriere Attributes organizate sub forma unei inregistrari File length Creation timestamp Read timestamp Managmentul este realizat uzual de sistemul de fisiere Write timestamp Reference count este responsabil pentru organizarea, stocarea, regasirea, numirea, partajarea si protectia fisierelor Owner File type Access control list 3

4 Organizarea Sisteme de fisiere Caracteristici High-Level Fisierele sunt organizate in mod ierarhic (e.g. folders Windows, directories Unix)? path relativa absoluta /home/adria/test1_cloud.txt links (symlinks, shortcuts, ) furnizeaza modalitati multiple de acces la fisiere Alte sisteme de fisiere pot fi mounted si vazute ca subierarhii 4

5 Organizarea Sisteme de fisiere Caracteristici Low-Level File data si meta-data sunt stocate separat Meta-data: informatii stocate de sistemul de fisiere (atributele fisierului, directoarele, etc) Descriptorii de fisiere si meta-data sunt stocate in inodes Meta-data pote fi replicata pentru a creste gradul de reliability (incredere) al sistemului Consideratii de proiectare?sistemul de fisiere trebuie sa ofere acces rapid sau de incredere? 5

6 Sisteme de fisiere Caracteristici Furnizeaza o interfata, care elimina grija programatorilor in ceea ce priveste modul de alocare a stocarii Exemplu de operatii principale asupra fisierelor, disponibile aplicatiilor din sistemele UNIX filedes=open(filename, mode) fildes=creat(filename, mode) status=close(fildes) count=read(filedes, buffer, n) count=write(filedes, buffer,n) pos=lseek(filedes, offset, whence) status=unlink(name) status=link(filename1, filename2) status=stat(name, buffer) 6

7 Sisteme de fisiere Caracteristici Exemplu de schema a unei structuri organizate pe module ale unui sistem de fisiere - FS (ne-distribuit) pentru un sistem de operare uzual: Directory module File module Access control module File access module Block module Device module Fiecare nivel depinde de nivelul inferior Implementarea unui sistem distribuit implica aceste componente + componente care se ocupa de comunicarea client-server, sistemul de numire (naming system) si de localizare al fisierelor distribuite 7

8 Sisteme de fisiere distribuite Concepte Un sistem de fisiere distribuit (Distributed File System (DFS)) are ca scop partajarea de informatii (in forma de fisiere) intr-un sistem distribuit Gestioneaza o multime de dispozitive de stocare dispersate Pe ansamblu, stocarea este data de dispozitive diferite aflate la distanta => DFS consta din componente software multiple pe masini diferite, ruland ca un singur sistem 8

9 Vocabular: Sisteme de fisiere distribuite Concepte Resursele pentru o masina sunt local pentru respectiva masina Resursele de pe alta masina sunt remote Service entitate software care ruleaza pe una sau mai multe masini si furnizeaza o functie particulara unor clienti necunoscuti apriori Server serviciu software ruland pe o masina Client proces care invoca un serviciu prin client interface client interface pentru un file service este format din primitive (create, delete, read, write, ) Interfata client a DFS trebuie sa fie transparenta => Clientii trebui sa perceapa DFS in acelasi mod in care percep un FS centralizat; toate problemele care tin de distribuire sunt ascunse la un nivel inferior 9

10 Sisteme de fisiere distribuite Cerinte Transparenta (Transparency) Access transparency Programele client nu sunt constiente de modul de distribuire a fisierelor Programele ce opereaza asupra fisiserlor locale, pot opera fara modificari si asupra resurselor remote Location transparency Fisiere sau grupuri de fisiere pot fi relocalizate fara schimbarea pathname-ului Mobility transparency Nici programele client si nici tabele de administrare in nodurile client nu trebuie modificate daca fisierele au fost mutate Performance transparency Programele client trebuie sa functioneze satisfacator, chiar daca incarcarea serviciului variaza intr-un anumit interval Scaling transparency Serviciul poate fi extins pentru a face fata la un numar mai mare de incarcari si dimensiuni ale retelei 10

11 Sisteme de fisiere distribuite Cerinte Controlul concurentei (Concurrency control) Modificarile asupra unui fisier la un client nu interfereaza cu modificarile realizate de alt client simultan Replicarea (Replication) Se permite copierea fisierului pe masini multiple => scalabilitatea serviciului, cresterea tolerantei la erori, cresterea performantei Nu toate sistemele de fisere suporta replicarea, dar majoritatea suporta caching de fisiere sau portiuni de fisiere Principala problema: consistenta Provocare: consistenta versus disponibilitate versus performanta Consistenta (Consistency) Sistemele de fisiere conventionale ofera modelul one-copy update semantics: continutul fisierului este vazut de toate procesele concurente ca si cum exista un singur fisier. Daca exista replicare (sau caching) exista o intarziere inevitabila in propagarea modificarilor 11

12 Sisteme de fisiere distribuite Cerinte Eterogenitatea hardware si a sistemului de operare => openess Interfata serviciului trebuie sa asigure ca softul client/server poate fi implementat pe sisteme diferite Toleranta la erori (fault tolerance) Sistemul de fisiere trebuie sa functioneze, indiferent de eroarea clientului sau serverului Securitatea (Security) Uzual, sistemele de fisiere furnizeaza un control al accesului bazat pe ACL (Access Control List) In unele DFS este necesara autentificarea cererii clientului Eficienta (Effieciency) Se doreste furnizarea puterii si a unei generalitati, a unui nivel de performanta cel putin egala cu cel al FS conventionale Metrici folosite: timpul de raspuns, throughput, utilizarea sistemului etc. 12

13 Sisteme de fisiere distribuite Aspecte Scheme de nume posibile Fisierele pot fi denumite printr-o combinatie de host si local name Se garanteaza un nume unic, dar nu se asigura transparenta locatiei sau independenta de locatie Acelasi nume merge si local si pentru fisiere remote Directoarele remote sunt mounted in directoare locale Montarea se face explicit, fisierele sunt independente de locatie Sistemul local pare a avea o structura coerenta Ex: Sun NFS O structură globala ce asigura nume unic pentru fiecare fisier DFS este construit in acelasi mod ca un sistem de fisiere local Se asigura independenta de locatie 13

14 Sisteme de fisiere distribuite Aspecte Caching Reduce traficul in retea prin retinerea blocurilor de pe disc recent accesate, a.i. accesul repetat la aceeasi informatie poate fi realizat local Datele pot fi tinute de exemplu in: in memoria locala Se pot folosi statii de lucru fara disk Viteza crescuta sau pe disk-ul local Siguranta crescuta Problema: consistenta cache-ului: pastrarea consistenta a copiilor in raport cu fisierele de pe masinile server 14

15 Sisteme de fisiere distribuite Aspecte Servicii stateful versus stateless Stateful Serverul tine date despre cererile clientilor Stateless Mentine informatii privind fisierele deschise de un client, indentificatorul conexiunii, cache-ul serverului Memoria trebuie recuperata atunci cand un client inchide sau esueaza Fiecare cerere a clientului ofera toate informatiile necesare serverului (e.g. nume fisier, offset, etc).» Serverul poate tine informatii partiale despre client, dar nu este obligatoriu => Performanta: buna pentru stateful nu este nevoie de open/close la fiecare cerere se poate face apel la un read-ahead cache => un server stateful pierde totul atunci cind esueaza => slaba rezistenta la erori -serverul trebuie sa interogheze clientii pentru actualizarea starii -serverul isi goleseste cache-ul => Un server stateless se reincarca fara a se recupera starea anterioara 15

16 Sa schitam un sistem de fisiere distribuit Componente: Flat file service Directory service furnizeaza o interfata cu operatii accesate de catre client, si care permit accesul la fisiere Client module furnizeaza o interfata cu operatii similare ca cele dintr-un FS conventional [G. Coulouris, et. al, Distributed Systems] 16

17 Sa schitam un sistem de fisiere distribuit Flat file service (FFS) Are ca scop implementarea de operatii asupra continutului fisierelor UFID (Unique File IDentifiers) identifica in mod unic fisierele in sistemul distribuit, in toate cererile existente Exemplu de interfata oferita de FFS si folosita prin RPC de clienti: Read(FileID,i,n)->Data Write(FileID, i, Data) Create()->FileId Delete(FileID) GetAttributes(FileId)->Attr SetAttributes(FileId,Attr) Citeste o secventa de pana la n itemi, incepand de la itemul i si returneaza in Data 17

18 Sa schitam un sistem de fisiere distribuit Flat file service (FFS) Observatii: In comparatie de exemplu cu o interfata Unix, nu avem operatii de open(), close() fisierele sunt accesate prin UFID read(), write() includ un parametru care specifica un loc in fisier unde se incepe operatia Pentru a se asigura fault tolerance, interfata FFS ofera: Repetable operations» clientii pot repeta apelul la care nu au primit raspuns Stateless servers» Pot fi restartate dupa esec, fara a fi necesara restaurarea unei stari de catre client sau server 18

19 Sa schitam un sistem de fisiere distribuit Controlul Accesului Daca serverul nu poate retine drepturile de acces (este stateless) => solutii: Verificarea accesului se realizeaza cand numele fisierului este convertit la UFID, rezultatele sunt codificate sub forma de capabilities <resource identifier, operations, authentification code> si care va fi returnat clientului pentru cereri ulterioare Identitatea utilizatorului este trimisa la fiecare cerere, si serverul face verificarea accesului la fiecare operatie Metoda adoptata de NFS, AFS, etc. Obs. In ambele cazuri poate avea loc furtul identitatii, problema care se rezolva cu ajutorul semnaturilor digitale (e.g. Kerberos ofera o schema de autentificare ) 19

20 Sa schitam un sistem de fisiere distribuit Directory Service (DS) Scopul principal: furnizeaza maparea intre text names ale fisierelor si UFID Este client al serviciului FFS Exemplu de interfata oferita de DS Lookup(Dir,Name)->FileId (throws Not Found) AddName(Dir, Name, FileId) (throws NameDuplicate) UnName(Dir, Name) (throws NotFound) Localizeaza text name in director si returneaza UFID corespunzator Daca Name nu este in director, adauga si actualizeaza atributele fisierului. 20

21 Sa schitam un sistem de fisiere distribuit Client module Ruleaza pe fiecare computer client, integrand si extinzand operatiile FFS si DS sub o interfata, disponibila programelor la nivel utilizator Tine informatii despre localizarea in retea a FFS si a proceselor DS Poate juca un rol important in cresterea performantelor, prin implementarea unui mecanism de caching Studii de caz: SNFS, AFS, CODA, Lustre, GFS, GPFS, HDFS, Ceph, KFS, Panasas, PVFS2, RGFS, SMB (CIFS), xfs, WebDAV, 21

22 Sun Network File System Arhitectura NFS Nota: discutia se va purta avand ca baza implementarea UNIX 22

23 Sun Network File System - V3 NFS este atat o implementare cat si o specificatie Protocolul NFS este independent de SO, dar a fost initial dezvoltat pentru retele cu sisteme UNIX Scopul: partajarea de sisteme de fisiere in mod transparent Modelul: client-server (pentru NFS un nod poate juca ambele roluri). Modulul NFS Server se gaseste in kernelul fiecarui computer care joaca rol de server NFS Cereri care referentiaza fisiere aflate intr-un sistem remote sunt trimise de clientul NFS prin apeluri RPC la serverul NFS Comunicare: protocolul NFS este compatibil si cu UDP si cu TCP VFS (Virtual File System) asigura integrarea Acest modul, adaugat kernelului, face distinctia intre identificatorii de fisiere din NFS, identificatorii de fisiere folositi in sistemul local sau in alte sisteme de fisiere asigura transmiterea cererilor la sistemul de fisiere adecvat (sistemul de fisiere local, remote, etc) 23

24 Sun Network File System - V3 Identificatorii de fisiere in NFS poarta numele de file handlers Sunt opaci pentru clienti si contin informatii necesare serverelor Exemplu: in implementarea UNIX a NFS, este format din: filesystem identifier+ i-node number of file +i-node generation number filesystem identifier este numarul unic alocat unui file system i-node generation number este necesar deoarece un i-node este reutilizat dupa stergerea fisierului Mecanism: clientul obtine file handle pentru sistemul remote atunci cind se face montarea File handle sunt trimisi de server clientului in urma operatiilor de lookup, create, mkdir File handle sunt trimisi de la client la server in lista de argumente a tuturor operatiilor de pe server Nivelul VFS, detine: o structura VFS pentru fiecare sistem de fisiere montat Leaga sistemul remote de directorul local unde este montat cate un v-node pentru fiecare fisier deschis V-node contine un indicator: fisier local (=> v-node contine un i-node (in implementarea UNIX) sau fisier remote (=> v-node contine un file handle) 24

25 Sun Network File System - V3 Client-ul NFS Furnizeaza o interfata ce poate fi utilizata de programele conventionale (vezi slide anterior) Este integrat in kernel, si nu furnizat ca o biblioteca ce poate fi incarcata in procesele client Programele utilizator pot accesa fisiere via apeluri de sistem UNIX, fara recompilare Un modul client serveste toate procesele utilizator, manipuland si un cache partajat continand block-uri recent utilizate Acest modul comunica cu VFS Operatii: transfera block-uri de fisiere inspre/dinspre server si face caching la acestea in memoria locala atunci cind este posibil Obs. Se partajeaza acelasi buffer cache folosit de sistemul input-output local 25

26 Sun Network File System - V3 Serverul NFS RFC 1813 Interfata oferita cuprinde si caracteristici din cea proiectata in modelul discutat in Slide-urile Operatiile asupra fisierelor si directoarelor sunt integrate intr-un singur serviciu Creare si insertia de nume de fisiere in directoare este realizata printr-o singura operatie create (ce are ca argumente nume fisier si file handle corespunzator directorului) Alte operatii NFS: create, remove, rename, link, symlink, readlink, mkdir, rmdir, readdir, statfs similare in general cu cele din UNIX Serviciul de mount Ruleaza la nivelul utilizator pe fiecare computer - server NFS Clientii folosesc o versiune modificata a comenzii UNIX mount, pentru montarea sistemului de fisiere remote Mecanism: comanda mount modificata comunica cu serviciul de mount de pe host-ul remote folosind mount protocol; acesta este un protocol RPC, care pe baza caii directorului va returna file handle-ul corespunzator catre clientul NFS si catre nivelul VFS 26

27 Sun Network File System V3 Caching Implementarea NFS prevede mecanism de caching si la nivelul clientului si la nivelul serverului Server NFS Mentinerea in cache-ul serverului a block-urilor citite nu ridica probleme de consistenta Pentru scriere, exista doua operatii: Write through caching: data in operatiile de write primite de la clienti este stocata in cache-ul server-ului si scrisa pe disc inainte de raspunsul trimis clientului => clientul este sigur ca datele sunt stocate persistent Obs. Primirea unui numar mare de operatii write poate duce la bottleneck (gâtuire- blocaj) Data in operatiile de write sunt stocate doar in memoria cache; stocarea persistenta se face doar in urma unei operatii commit Clientul NFS face cache la rezultatele operatiilor read, write, getattr, lookup, readdir pentru reducerea numarului de cereri trimise serverului este responsabil de sondarea serverului pentru actualizarea cache-ului 27

28 Sun Network File System V3 vs V4 NFS version 4.1 (RFC 5661), 2010 [ 28

29 Sun Network File System V4 Versiunea 4 (RFC 3010, RFC 3530) - influente din AFS si CIFS (Common Internet File System) Este un protocol stateful Intr-un mod similar cu versiunile anterioare avem server NFS, care printrun mecanism RPC furnizeaza servicii clientilor NFS Diferente structurale majore: Eliminarea protocoalelor auxiliare In NFS 2 si 3, protocolul Mount e utilizat pentru obtinerea FileHandle, si operatia de file locking e obtinuta cu protocolul Network Lock Manager In NFS 4 - integrarea acestora intr-un singur protocol peste TCP Introducerea procedurilor COMPOUND RPC ce permite clientului gruparea operatiilor asupra fisierului intr-o singura cerere; serverul grupeaza operatiile de raspuns Obs. Evaluarea operatiilor se opreste la prima eroare, deci se recomanda gruparea doar a operatiilor inrudite Introducerea operatiilor stateful open si close In NFS 4,.,.. nu mai au asociata o semantica speciala 29

30 Sun Network File System V4 Protocolul NFS 4 asigura un nivel de securitate ridicat bazat pe arhitectura de autentificare extensibila GSS-API (Generic Security Services - Application Program Interface) NFS 4 definieste un model de control al accesului compatibil cu Windows NT si UNIX NFS 4 suporta replicarea si migrarea Internationalizare: numele fisierelor folosite in operatii sunt stringuri UTF-8 Modelul de sistem de fisiere si partajare Un file system reprezinta implementarea unui spatiu de nume continind fisiere Un file system are asociat un file system identifier fisd 128-biti per server Filehandle identifica in mod unic un fisier pe server In NFS 4 exportul sistemelor de fisiere se face similar ca in versiunile anterioare Pseudo-file systems 30

31 Sun Network File System V4 Caching si delegare Caching pe partea de client Cachingul fisierelor, atributelor, directoarelor seamana cu cel din versiunile anterioare Atributele si directoarele sunt puse in cache pe o durata stabilita de client; la urmatoarea utilizare, dupa trecerea timpului predefinit clientul interogheaza serverul dupa potentiale modificari Pentru fisiere tehnica close-to-open consistency La deschiderea unui fisier, clientul interogheaza serverul pentru a vedea potentiale modificari In functie de raspuns, actualizeaza sau nu cache-ul La inchiderea fisierului, clientul trimite modificarile la server Open delegation In NFS 4, daca un fisier este referentiat de un singur client, responsabilitatea pentru open/close, operatii de locking pot fi lasate (delegates) in seama clientului => eliminarea verificarii periodice a consistentei cache-ului de catre client => reducerea traficului si a latency => eficienta maxima pentru operatii de file locking dese 31

32 Sun Network File System V4 Locking In NFS 2,3 cu NLM (Network Lock Manager) care pornea de la premisa ca transmisia in retea este sigura => probleme in tratarea erorilor => lock-uri orfane pe server In NFS 4 s-a introdus lease per managementul lock-urilor Lease = este o perioada de timp acordata de server clientului, pentru controlul starii unui fisier sau pentru delegare Clientul este responsabil pentru reinoirea perioadei de lease Expirarea lease este considerata esec in comunicarea clientserver, si serverul inlatura lock-ul clientului 32

33 AFS - Andrew File System Pornit de la un proiect de cercetare de la CMU (Carnegie Mellon University) si sustinut de IBM A influentat multe DFS: NFS, Coda, DCE/DFS etc. Scopul initial: suport pentru partajare pe scara larga, prin minimizarea comunicatiei client-server (printr-un mecanism de caching la nivelul clientilor) Caracteristica dominanta => Scalabilitate Caracteristici AFS (mai neobisnuite): Whole-file serving: intregul continut al directoarelor si fisierelor sunt transmise de serverele AFS clientilor (in AFS 3, fisierele sunt transferate in bucati de 64-Kbytes) Whole-file caching: odata ce o copie a fisierului sau a unei bucati a fost transferata, aceasta este stocata in cache pe disk-ul local 33

34 AFS - Andrew File System Aspecte considerate in proiectarea AFS: Fisierele partajate care nu sunt frecvent actualizate (cele continand codul comenzilor UNIX, biblioteci, etc) sau pentru fisiere accesate de un singur utilizator, copiile din cache sunt valide o perioada mai lunga de timp Cache-ul local poate ocupa o parte substantiala din spatiul de pe disk al fiecarei statii Fisierele sunt in general de dimensiuni mici Operatiile de citire sunt mai intalnite decat cele de scriere (in jur de 6 ori) Accesul secvential este obisnuit, cel random este rar; daca un fisier a fost referentiat recent atunci creste probabilitatea de a fi referentiat din nou; Majoritatea fisierelor sunt modificate (write/read/ ) de obicei de un singur utilizator 34

35 AFS - Andrew File System Scenariul general de functionare: La un apel open() pentru un fisier din spatiul de fisiere partajat, care nu este in cache-ul local, este localizat serverul detinator al fisierului si este trimisa o cerere de copiere a acestuia Copia este stocata in sistemul de fisiere local pe computerul clientului, copia este deschisa si descriptorul (de fisier unix) este returnat clientului Operatii (read,write, etc) sunt aplicate copiei locale La apelul close(), daca au fost modificari asupra copiei locale, continutul este trimis la server, care va face update la continut si la timestamp-ul corespunzator.? Cum controleaza AFS situatia in care un apel close sau open al unui client face referire la un fisier partajat?? Cat spatiu este alocat pentru cache?? Cum controleaza AFS consistenta, cand un fisier este actualizat de mai multi clienti? 35

36 AFS - Andrew File System [G. Coulouris, et. al, Distributed Systems] 36

37 AFS - Andrew File System Aspecte arhitecturale Vice este numele software-ului ce ruleaza pe server la nivelul utilizator (functionalitatile flat file service vezi slide 15) Venus este procesul care ruleaza pe computerul client si corespunde modulului client (vezi slide 15) Face mangementul structurii ierarhice de directoare Kernelul fiecarei statii client/server este o versiune modificata de BSD Unix: este proiectat sa intercepteze apeluri de sistem open, close, etc care se refera la fisiere aflate in spatiul de fisiere partajate si transmiterea acestor apeluri la procesul Venus Una din partitiile de fisiere ale disk-ului local de pe o statie de lucru va tine copii ale fisierelor din spatiul partajat; Venus face managementul acestui cache Fiecare fisier/director din spatiul de fisiere partajate are un identificator unic FID (96-bit file identifier); programele client lucreaza cu numele fisierelor, AFS in comunicarea Venus-Vice lucreaza cu FIDs 37

38 AFS - Andrew File System Implementarea de apeluri de sistem in AFS [G. Coulouris, et. al, Distributed Systems] 38

39 AFS - Andrew File System Consistenta cache-ului Callback promise este un token eliberat de Vice, prin care garanteaza ca va notifica pe Venus daca fisierul pe care l-a trimis va fi modificat de alt client Are doua stari: Valid Daca Venus face managementul unui apel open, verifica existenta fisierului in cache; daca token-ul asociat este cancelled, atunci trebuie ceruta o noua copie de la serverul Vice; daca token este valid, atunci se poate utiliza copia locala Cancelled Cand un server actualizeaza un fisier, notifica toate procesele Venus printr-un callback (apel RPC); procesele Venus, seteaza acest token pe cancelled Daca o statie de lucru a fost repornita, Venus incearca sa mentina cat mai multe fisiere in cache, dar nu poate garanta ca tokenurile callback promise sunt corecte => inainte de utilizarea fiecarui fisier din cache, Venus genereaza o cerere de validare continand atributul timestamp de modificare al fisierului; daca timestamp arata ca fisierul este neactualizat, serverul trimite cancelled si tokenul este setat cancelled 39

40 GFS Google File Systems Sistem de fisiere distribuit, scalabil De ce nu un DFS existent? Problemele Google sunt diferite decat cele intalnite in mod normal Stocarea redundanta a unei cantitati imense de date pe computere ieftine si nesigure Incarcare diferita si prioritati de proiectare Sursa de inspiratie? Observatiile Google asupra mediului tehnologic Aplicat unde? Search Engine, Google Video, Gmail, Google Earth, Maps, Google Products, Google News,. => Applicatiile Google sunt proiectate pentru GFS 40

41 GFS Google File Systems Ipoteze in Design Commodity components Hardware la pret scazut (e.g. masini linux) Nodurile pot cadea => dar nu trebuie sa fie afectat intregul sistem Fisiere de dimensiune mare DFS va manipula fisiere mari ( giga- sau penta-bytes) Multe obiecte distribuite in sistemul distribuit High bandwidth Mai importanta decat latenta Patternul de acces in DFS Modificari rare asupra fisierelor deja scrise Majoritatea fisierelor sunt modificate prin appending, si nu prin acces random Doua tipuri de operatii read Citiri consecutive de cantitati mari de date Rareori sunt citiri random File accesibility Acces concurent asigurat clientilor multipli (trebuie sincronizat pentru a mentine consistenta fisierului) 41

42 GFS Google File Systems Operatii suportate in GFS Concurrent appending Masini multiple pot scrie in mod concurent asupra aceluiasi fisier in acelasi timp Interfata GFS Organizarea ierarhica de fisiere Identificarea se face prin pathname Snapshot Permite crearea de copii ale fisierului/directorului =>se permite crearea de checkpoint-uri 42

43 GFS Google File Systems Arhitectura - Un cluster GFS este format din: un singur server Master, servere Chunk (chunkserver) multiple, clienti multipli - Fisierele sunt divizate in chunk-uri de dimensiuni fixate (64 MB) - Fiecare chunk este identificat de un handle unic de 64 biti, asignat de master in momentul crearii - chunkserver stocheaza pe discurile locale aceste chunk-uri ca si fisiere Linux - Reliability: fiecare chunk este replicat pe mai multe chunkserver [ ] 43

44 GFS Google File Systems Arhitectura - Serverul Master - mentine toate metadatele asociate sistemului de fisiere: spatiile de nume, informatii legate de controlul accesului, maparea file-to-chunk, locatia curenta a chunk-urilor. - Controleaza mecanismul de Garbage collection a chunk-urilor orfane, migrarea chunk-urilor intre servere - Comunica periodic cu fiecare chunkserver (mesaje HeartBeat): dand instructiuni si colectind starea acestuia - Obs. Nici la client si nici la chunkservere nu exista mecanism de cache a datelor din fisiere 44

45 Arhitectura GFS Google File Systems [ ] Avantaje: -Nevoia clientilor de a interactiona cu master-ul este redusa, deoarece operatiile de read/write pe acelasi chunk necesita doar o cerere initiala la master pentru aflarea locatiei chunk-ului -Incarcarea in retea este redusa prin mentinerea unei conexiuni TCP persistenta cu chunkserver pentru o perioada mai lunga de timp 45

46 GFS Google File Systems Metode de acces Citirea - Clientul translateaza numele fisierului si offset-ul specificat de aplicatie intr-un chunk index, pe baza dimensiunii fixe a chunkului - Clientul trimite master-ului o cerere continind numele fisierului si chunk index - Masterul raspunde cu un chunk handle si locatiile copiilor; clientul mentine in cache datele avind ca si cheie: nume fisier si chunk index - Clientul trimite cererea (continind chunk handle si pozitia din chunk) la una dintre copii (cea mai aproape) - Urmatoarele operatii de citire a aceluiasi chunk nu mai necesita interactiuni client-master (pana cand informatia din cache expira sau fisierul este redeschis) 46

47 GFS Google File Systems Metode de acces Scrierea Clientul translateaza numele fisierului si offset-ul specificat de aplicatie intr-un chunk index, pe baza dimensiunii fixe a chunk-ului Clientul trimite master-ului o cerere continind numele fisierului si chunk index Masterul raspunde cu un chunk handle si locatiile copiilor; Clientul trimite datele tuturor copiilor; data este stocata in bufferul intern al chunkserver-ului Clientul trimite o cerere de write la primary (una din copiile chunk-ului < chunk leases); se asigneaza un numar la fiecare cerere de scriere primita si realizeaza scrierea datelor pe care le stocheaza in aceasta ordine Primary trimite cereri de write la celelalte copii; acestea vor raspunde dupa ce vor executa operatia, si apoi primary va raspunde clientului [ ] 47

48 GFS Google File Systems Disponibilitatea sistemului - GFS suporta Fast Recovery: master si chunkserver se pot restaura in cateva secunde, indiferent de cum au esuat (nu se face distinctie intre normalanormal) Integritatea datelor - GFS foloseste un mecanism bazat pe sume de control pentru asigurarea datelor scrise/citite - Un checksum de 32 de biti este inclusa in fiecare bloc de 64KB Replicare - GFS implica atat replici chunk cat si replici ale master-ului (shadow master) Consistenta - Sansa ca un client sa citeasca dintr-o replica neactualizata (e.g. datorata caderii chunkserverului si pierderea unor operatii) este mica datorita mecansimului de timeout asociat cache-ului 48

49 GFS Google File Systems Experiment: Micro GFS cluster master 16 chunkservers 16 clients Hardware Dual 1.4GHz PIII CPU 2GB RAM 2 80GB 5400RPM Disk 100M bps Ethernet Switch conectat la o retea 1 Gbps [Zhijin Li, Cloud computing, University of Illinois, 49

50 Experiment- operatii de Read N clienti citesc aleator regiuni de 4MB din fisiere de 320 GB file, de 256 de ori. Rata de citire scade usor, datorita probabilitatii citirii de la acelasi chunkserver. [Zhijin Li, Cloud computing, University of Illinois]

51 Experiment operatii de Write N clienti scriu simultan in N fisiere; fiecare client scrie 1 GB in cate un nou fisier Performante scazute datorita retelei OBS. Scrierea se realizeaza pe 3 chunkservere [Zhijin Li, Cloud computing, University of Illinois]

52 Experiment operatii de Append N clients realizind append unui singur fisier Se incepe la 6.0 MB/s pentru un client si scade pana la 4.8 MB/s pentru 16 clienti [Zhijin Li, Cloud computing, University of Illinois]

53 Bibliografie George Coulouris, Jean Dollimore, Tim Kindberg, Distributed Systems- Concepts and design, Addison Wesley, 2001 Andrew S. Tanenbaum, Maarten van Steen, Distributed Systems, Principles and Paradigms, Second Edition, 2007 Ajay D. Kshemkalyani, Mukesh Singhal, Distributed Computing - Principles, Algorithms, and Systems, Cambridge University Press Andy Wang, Advanced Operating Systems course

54 Bibliografie Tom White, Hadoop-The definitive Guide, Second edition, O Reilly, 2011 Andrew S. Tanenbaum, Maarten van Steen, Distributed Systems, Principles and Paradigms, Second Edition, 2007 Ajay D. Kshemkalyani, Mukesh Singhal, Distributed Computing - Principles, Algorithms, and Systems, Cambridge University Press Gantz et al., The Diverse and Exploding Digital Universe, March Mahesh Bharath Keerthivasan, Review of Distributed File Systems:Concepts and Case Studies, Dept. of Electrical & Computer Eng., University of Arizona, Tucson and Mike Cafarella and Doug Cutting, Building Nutch: Open Source Search, ACM Queue, April 2004, queue.acm.org/detail.cfm?id= Zhang S., Distributed Filesystems Review,Online Presentation, The Hadoop Distributed File System by Konstantin Shvachko, Hairong Kuang, Sanjay Radia, and Robert Chansler (Proceedings of MSST2010, May 2010,

55 Rezumat Sisteme de fisiere caracteristici Sisteme de fisiere distribuite Vocabular Cerinte Aspecte Sa schitam un sistem de fisiere distribuit simplificat Studii de caz: Sun Network File System, AFS, GFS, HDFS 55

56 Universitatea Alexandru Ioan Cuza Facultatea de Informatică Întrebări?