Universitatea Alexandru Ioan Cuza Facultatea de …adria/teach/courses/pcd/...•Meta-data:...

2019| Concurrent and Distributed Programming – http://www.info.uaic.ro/~adria

Conf. Dr. Lenuța Alboaie [email protected]

Universitatea “Alexandru Ioan Cuza” Facultatea de Informatică


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


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

• este responsabil pentru organizarea, stocarea, regasirea,

numirea, partajarea si protectia fisierelor

3

File length

Creation timestamp

Read timestamp

Write timestamp

Reference count

…

Owner

File type

Access control list

Managmentul este realizat uzual de sistemul de fisiere


Sisteme de fisiere|Caracteristici • Organizarea

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 sub-ierarhii

4


Sisteme de fisiere|Caracteristici • Organizarea

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


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


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:

• 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

Directory module

File module

Access control module

File access module

Block module

Device module


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


Sisteme de fisiere distribuite|Concepte • Vocabular:

– 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


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


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


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


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


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


Sisteme de fisiere distribuite | Aspecte • Servicii stateful versus stateless

– Stateful

• Serverul tine date despre cererile clientilor

– Mentine informatii privind fisierele deschise de un client, indentificatorul conexiunii, cache-ul serverului

– Memoria trebuie recuperata atunci cand un client inchide sau esueaza

– Stateless

– 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


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

16 [G. Coulouris, et. al, Distributed Systems]



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:

17

Read(FileID,i,n)->Data Citeste o secventa de pana la n itemi, incepand de la itemul i si returneaza in Data

Write(FileID, i, Data) …

Create()->FileId …

Delete(FileID) …

GetAttributes(FileId)->Attr …

SetAttributes(FileId,Attr) …



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


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



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

20

Lookup(Dir,Name)->FileId (throws Not Found)

Localizeaza text name in director si returneaza UFID corespunzator

AddName(Dir, Name, FileId) (throws NameDuplicate)

Daca Name nu este in director, adauga si actualizeaza atributele fisierului

UnName(Dir, Name) (throws NotFound)

…

… ….



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


Sun Network File System

Arhitectura NFS

22 Nota: discutia se va purta avand ca baza implementarea UNIX


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


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


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


Sun Network File System - V3

• Serverul NFS

– RFC 1813

– Interfata oferita cuprinde si caracteristici din cea proiectata in modelul discutat in Slide-urile 15-20

– 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


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


Sun Network File System V3 vs V4

28

[http://www.netapp.com/us/communities/tech-ontap/nfsv4-0408.html]

•NFS version 4.1 (RFC 5661) , 2010


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 printr-un 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



• 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


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



• 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 client-server, si serverul inlatura lock-ul clientului

32


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


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



• 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

[G. Coulouris, et. al, Distributed Systems]


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



• Implementarea de apeluri de sistem in AFS

38 [G. Coulouris, et. al, Distributed Systems]



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


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


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



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


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 [http://www.cs.brown.edu/courses/cs295-11/2006/gfs.pdf ]


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



Arhitectura

45

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

[http://www.cs.brown.edu/courses/cs295-11/2006/gfs.pdf ]



Metode de acces

Citirea

- 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 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


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 [http://www.cs.brown.edu/courses/cs295-11/2006/gfs.pdf ]



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 normal-anormal)

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



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

49

[Zhijin Li, Cloud computing, University of Illinois,

http://www.cs.cornell.edu/courses/cs614/2004sp/papers/gfs.pdf]


• 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.

Experiment- operatii de Read

[Zhijin Li, Cloud computing, University of Illinois]


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



• 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

Experiment – operatii de Append



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 2008

• http://www.youtube.com/watch?v=5Eib_H_zCEY

• http://www.slideshare.net/schubertzhang/distributed-filesystems-review

• http://www.slideshare.net/sriprasanna/distributed-file-systems-1941900

• Andy Wang, Advanced Operating Systems – course

• http://www.scribd.com/doc/46893735/Review-of-Distributed-File-Systems-Concepts-and-Case-Studies

• http://media.netapp.com/documents/tr-3085.pdf

• http://www.ietf.org/rfc/rfc3530.txt

• http://www.ietf.org/rfc/rfc5661.txt

• http://www.cs.berkeley.edu/~brewer/cs262b-2004/Lec-AFS-GFS.pdf

• http://web.cs.wpi.edu/~cs4513/b05/week5-dfs.pdf

• http://www.netapp.com/us/communities/tech-ontap/nfsv4-0408.html

• https://wiki.engr.illinois.edu/display/cs598rco/The+Google+File+System+-+Zhijin+Li

• http://www.cs.brown.edu/courses/cs295-11/2006/gfs.pdf


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 2008

• http://www.cs.berkeley.edu/~brewer/cs262b-2004/Lec-AFS-GFS.pdf

• https://wiki.engr.illinois.edu/display/cs598rco/The+Google+File+System+-+Zhijin+Li

• http://www.cs.brown.edu/courses/cs295-11/2006/gfs.pdf

• http://www.ibm.com/developerworks/web/library/wa-introhdfs/index.html?ca=drs-

• http://hadoop.apache.org/

• Gantz et al., “The Diverse and Exploding Digital Universe,” March 2008 http://www.emc.com/collateral/analyst-reports/diverse-exploding-digital-universe.pdf

• Mahesh Bharath Keerthivasan, Review of Distributed File Systems:Concepts and Case Studies, Dept. of Electrical & Computer Eng., University of Arizona, Tucson

• http://www.intelligententerprise.com/showArticle.jhtml?articleID=207800705, http://mashable.com/2008/10/15/facebook-10-billion-photos/

• http://blog.familytreemagazine.com/insider/Inside+Ancestrycoms+TopSecret+Data+Center.aspx, and http://www.archive.org/about/faqs.php, http://www.interactions.org/cms/?pid=1027032

• Mike Cafarella and Doug Cutting, “Building Nutch: Open Source Search,” ACM Queue, April 2004, http://

queue.acm.org/detail.cfm?id=988408

• Zhang S., “Distributed Filesystems Review”,Online Presentation, http://www.slideshare.net/schubertzhang/distributedfilesystems-review

• “The Hadoop Distributed File System” by Konstantin Shvachko, Hairong Kuang, Sanjay Radia, and Robert Chansler (Proceedings of MSST2010, May 2010, http://storageconference.org/2010/Papers/MSST/Shvachko.pdf).

• http://www.cs.cornell.edu/courses/cs614/2004sp/papers/gfs.pdf


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


Întrebări?

Universitatea “Alexandru Ioan Cuza” Facultatea de Informatică

Universitatea Alexandru Ioan Cuza Facultatea de …adria/teach/courses/pcd/...•Meta-data:...

Documents

Transcript of Universitatea Alexandru Ioan Cuza Facultatea de …adria/teach/courses/pcd/...•Meta-data:...