SISTEME DE GESTIUNE DE FISIERE DISTRIBUITE

Universitatea Politehnica Bucuresti Facultatea de Electronica, Telecomunicatii si Tehnologia Informatiei Disciplina: Sisteme de operare avansate Tema: Sisteme de gestiune de fisiere distribuite Student: Bafane Ionut-Adrian Grupa: Master IISC Bucuresti 2012 CUPRINS: CUPRINS: Capitolul 1: Introducere Capitolul 2: The Network File System (NFS) .4 2.1 Versiunile si ale protocolului NFS 2.1.1 Interactiunea Client-Server 2.1.2 Principiile de export, montare si accesare NFS 2.2 Versiunile si ale protocolului NFS Capitolul 3: The Remote File Sharing Service (RFS) 10 Capitolul 4: The Andrew File System (AFS) 11 Capitolul 5: Server Message Block (SMB) 13 Capitolul 6: The Distributed File System (DFS) 14 6.1 Planificarea unei implementari DFS: .14 Bibliografie 18 18 18 Capitolul 1: Introducere Un sistem de gestiune de fisiere este o metoda de stocare si organizare a fisierelor electronice si a datelor acestora El organizeaza aceste fisiere intr-o baza de date pentru stocare organizare, manipulare, si recuperare de catre sistemul de operare al computerului Sistemele de gestiune de fisiere sunt folosite la dispozitive de stocare de date precum hard-disk-uri sau CD-ROM-uri pentru a putea mentine locatia fizica a fisierelor In plus, ele ar putea oferi acces la datele de pe un server de fisiere, actionand in calitate de clienti unui protocol de retea (ex: NFS , SMB ), sau pot fi virtuale existand numai ca o metoda de acces pentru date virtuale Majoritatea sistemelor de gestiune de fisiere utilizeaza un suport de stocare a datelor ce ofera accesul la o serie de sectoare de marime fizica fixa, in general putere a lui Sistemul de gestiune de fisiere este cel responsabil pentru organizarea acestor sectoare in fisiere si directoare, si de asemenea este cel ce tine in evidenta ce sectoare apartin carui fisier si care dintre ele nu sunt utilizate Majoritatea sistemelor de gestiune de fisiere adreseaza datele in unitati de dimensiuni fixe numite grupuri sau blocuri, care contin un anumit numar de sectoare de disc, de obicei intre si 64 Aceasta este cea mai mica cantitate de spatiu pe disc, ce poate fi alocata unui fisier Sistemele de gestiune de fisiere distribuite sunt construite pe baza unui model client-server Astfel una dintre masinile ce contine sistemul de fisiere, va juca rolul de server, si va oferi astfel acces clientilor printr-un protocol bine definit Spre deosebire de sistemele de fisiere locale, acolo unde spatiul este atasat fizic si accesul este permis doar proceselor locale, sistemele de fişiere distribuite, de retea, permit accesul la fişierele ce se afla pe o altă maşină prin intermediul unui protocol In ultimii 20 de ani au fost dezvoltate mai multe tipuri de sisteme de fisiere distribuite, insa unele dintre acestea nu au avut succesul dorit si au disparut La polul opus, cel mai de succes sistem de gestiune al fisierelor de retea este “The Network File System” (NFS), dezvoltat de Sun Microsystems, acesta fiind folosit de majoritatea sistemelor Unix moderne In timp ce Sun dezvolta NFS-ul, firma AT&T lucra la dezvoltarea unui alt sistem de fisiere distribuite, si anume “Remote File Sharing” (RFS) De asemenea, un alt sistem de fisiere de retea este reprezentat de “The Andrew Filesystem” (AFS), dezvoltat la inceputul anilor 1980, la universitatea “Carnegie Mellon University” (CMU) ca parte a unui proiect sustinut in colaborare intre CMU si IBM denumit “Project Andrew” Acesta a evoluat mai tarziu in “The DCE Distributed File Service” (DFS) Daca sistemele de fisiere de retea mentionate mai sus au fost dezvoltate in special pentru platformele Unix, in continuare va fi introdus sistemul “Server Message Block” (SMB), ce operează la nivelul aplicaţie ỵn stiva de protocoale şi este utilizat în principal pentru a oferi acces la fişiere partajate, imprimante sau la porturi seriale Sistemul SMB este utilizat ỵn special pe sistemele Windows şi mai este cunoscut şi sub denumirea de Microsoft Windows Network Capitolul 2: The Network File System (NFS) NFS a fost proiectat pentru a rezolva o problema obisnuita din cadrul unei retele Unix Tendinta generala cunoscuta este cea a proceselor distribuite si a retelelor clientserver Cu toate acestea, multi utilizatori au, de fapt, masini puternice care comunica cu un server Exista aplicatii de care au nevoie utilizatorii si care sunt localizate in alte locuri decat pe desktop, si de aceea apare necesitatea unei metode de acces a fisierelor la distanta “The Network File System” a fost initial dezvoltat de “Sun Microsystems”, la inceputul anilor 1980, devenind odata cu trecerea timpului un mare succes Scopurile dezvoltarii acestui sistem de gestiune al fisierelor de retea au fost urmatoarele: - Independenta de masina si de sistemul de operare utilizat: scopul a fost acela de a permite functionarea NFS-ului pe sisteme de operare bazate pe Unix si nu numai Protocoalele client-server trebuiau sa fie simple astfel incat sa poata fi implementate pe PC-urile din acea perioada ce rulau in DOS - Disponibilitate in situatia in care serverul este cazut: atunci cand serverul este indisponibil, clientii cu acces la acel server nu trebuie sa faca diferenta intre situatia in care un server a fost cazut si a suferit un restart si situatia in care serverul ofera un timp de raspuns mai indelungat - Accesul transparent la fisiere: pentru indeplinirea acestui scop este necesar faptul ca serverul sa ofere transparenta totala aplicatiilor inregistrate pe client - Performante acceptabile - pentru a putea fi atractiv de utilizat, NFS-ul trebuia sa fie mai rapid decat sistemele deja existente precum rcp Implementarea initiala a sistemului NFS includea versiunile si ale protocolului, atunci cand sistemul a fost introdus pentru prima data publicului in anul 1985 2.1 Versiunile si ale protocolului NFS Arhitectura SunOS pentru sistemele de fisiere a fost reimplementata astfel incat sa fie compatibila cu mai multe tipuri de sisteme de fisiere si de asemenea sa ofere suport pentru sistemul NFS Pentru aceasta s-a utilizat infrastructura “Remote Procedure Call” ce oferea un mecanism sincron de retea prin intermediul caruia un proces putea apela un altul situat pe o alta masina Pentru a realiza comunicarea in cadrul retelei, NFS a utilizat protocolul UDP “(User Datagram Protocol)” Deoarece, in acest caz, codarea mesajelor protocolului si respectiv a raspunsurilor a fost una problematica, s-a recurs la utilizarea “External Data Representation” (XDR) Este util sa prezentam procedura introdusa de sistemul NFS pentru a putea realiza comunicarea in retea Aceasta va fi detaliata in tabelul de mai jos Procedura null este utilizata pentru efectuarea comenzii de ping asupra serverului, in timp ce procedura statfs returneaza informatia ce poate fi afisata atunci cand apelam comanda df Fisierul referit de aceste proceduri poarta numele de “file handle” Aceste reprezinta o structura opaca de date oferita de catre server, ca raspuns al unei cereri de tip look-up Clientul nu trebuie niciodata sa incerce sa interpreteze continutul unui “file handle”, deoarece acest identificator / manipulator de fisier contine campuri ce identifica unic tipul sistemului de fisiere, discul, numarul i-nodului catalogului precum si informatii legate de securitate Serverul NFS nu pastreaza informatie referitoare la cererile anterioare Acest lucru este util, deoarece evita recuperarea complicata in cazul in care serverul a cazut Astfel, daca clientul nu primeste un raspuns de la server intr-o anumita perioada de timp, atunci cererea va fi retransmisa pana cand va reusi Pentru a se putea face distinctia intre fisierele vechi si cele noi, sistemele de fisiere Unix contin un numarator de generatie: “generation count” ce va fi incrementat de fiecare data cand inodul este reutilizat Pentru a putea intelege mai bine vom considera cazul in care atunci cand un fisier este sters de pe server, iar i-nodul sau este reutilizat pentru un alt fisier, atunci identificatorul de fisier returnat nu va mai fi valabil, deoarece se va referi la vechiul fisier 2.1.1 Interactiunea Client-Server Sistemul NFS se bazeaza atat pe “Remote Procedure Call” cat si pe “eXternal Data Representation”, acestea fiind utilizate ca mijloace de comunicare intre client si server RPC este o tehnica puternica pentru construirea aplicatiilor distribuite bazate pe modelul client-server Modelul extinde notiunea de apel local de procedura, diferenta fiind ca procedura apelata nu se afla in acelasi spatiu de adresare cu procedura apelanta Cele doua procese implicate pot sa fie pe acelasi calculator sau pot sa fie pe doua calculatoare in retea RPC foloseste protocolul XDR ( eXternal Data Representation) – RFC 1832- pentru codarea datelor Acest protocol se afla tot la nivelul Prezentare din stiva OSI Astfel, prin intermediul RPC se doreste ca o aplicatie client sa poata apela o functie generata de server, in acelasi mod in care ar putea apela o functie din propriul sau spatiu de adresare Formatul XDR se bazeaza pe faptul ca bytes-ii sunt portabili precum si pe faptul ca codarea bytes-ilor nu se schimba de la o arhitectura la alta Astfel, specificatiile XDR cer ca formatul tipurilor de date sa fie multiplu de bytes In cazul in care tipul de date presupune un format care nu este perfect divizibil cu 4, atunci orice byte neutilizat va fi inlocuit cu Astfel prin intermediul formatului “eXternal Data Representation” este posibil transferul datelor intre diferite tipuri de sisteme Procesul de convertire a formatului local in format XDR este denumit codare, iar procesul invers de convertire din formatul XDR in formatul local este cunoscut sub numele de decodare Formatul XDR este construit ca fiind o librarie software de functii destinate transferului intre diferite sisteme de operare si este de asemenea independent de stratul logic “Transport” din stiva OSI/TCP-IP De asemenea, componentele se reprezintă ỵn ordinea declarării și dupa cum a fost mentionat si mai sus, fiecare are lungime multiplu de Mecanismul RPC poate fi implementat pentru diferite protocoale de transport Astfel, in cazul implementarilor initiale ale NFS-ului, acesta s-a bazat pe protocolul UDP, iar ulterior s-a trecut la implementarea pe protocolul TCP/IP in special pentru a se putea evita pierderea de pachete la trecerea printr-un router In continuare va fi descrisa arhitectura sistemului NFS: Implementarea clientului si a serverului este independenta de protocoalele NFS, marea majoritate a sistemelor Unix folosesc o implementare cu straturi Primul strat este cel al apelurilor de sistem Dupa analizarea apelului si verificarea parametrilor, se invoca al 2-lea strat, si anume stratul sistemului virtual de fisiere denumit si VFS Scopul stratului VFS este acela de a mentine un tablou cu o intrare pentru fiecare fisier deschis, precum tabloul de i-noduri pentru fisierele deschise din Unix Astfel, daca un cazul Unix-ului, un index-node este unic identificat printr-o pereche formata din dispozitiv si nr i-node, in cazul nostru, stratul VFS va avea pentru fiecare fisier deschis o inregistrare numita v-node V-node-urile sunt astfel folosite pentru a se putea determina daca fisierul este unul local, sau se afla la distanta, iar in cazul in care acesta se afla la distanta, atunci va fi pusa la dispozitie informatia necesara pentru a face posibila accesarea fisierului Arhitectura generala NFS in cazul utilizarii sistemului virtual de fisiere va fi ilustrata in figura urmatoare Ne va fi ilustrat plasamentul sistemului NFS, a mecanismului RPC precum si a formatului XDR in cadrul kernel-ului Observam ca, din perspectiva kernel-ului, NFS-ul reprezinta doar un simplu alt tip de sistem de fisiere 2.1.2 Principiile de export, montare si accesare NFS Fiecare server exporta unul din cataloagele sale cu scopul de a putea fi accesate de catre clienti de la distanta In cazul in care un catalog este facut disponibil pentru a putea fi exportat, devin disponibile si restul de subcataloage, fiind practic exportata o structura asemanatoare unui arbore In tabelul prezentat la inceputul lucrarii, nu ne sunt prezentate mijloacele prin care se poate obtine chiar primul identificator de fisiere Acest lucru se poate obtine prin intermediul unui protocol separat numit protocolul de montare Astfel, clientii pot accesa cataloagele exportate de catre server prin intermediul acestui protocol de montare In continuare va fi descris acest mecanism de montare: Un client ii poate trimite unui server o cale si ii poate cere permisiunea serverului de a monta catalogul in ierarhia sa de cataloage Trebuie sa precizam faptul ca serverul nu este deloc interesat de locul unde se va realiza montarea respectiva In continuare, daca se verifica validitatea caii precum si faptul ca a fost exportat initial catalogul, atunci clientul va primi un identificator de fisier, sub numele sau real de “file handle”, care a fost prezentat in subcapitolele anterioare Protocolul de montare initial a fost constituit din urmatoarele proceduri diferite: - MOUNTPROC_NULL => aceasta procedura nu are un rol specific, ea fiind utilizata doar pentru a putea efectua o operatie de ping asupra serverului - MOUNTPROC_MNT => aceasta procedura stabileste o cale trimisa de client serverului, precum si returneaza un identificator de fisiere corespunzator acestei cai - MOUNTPROC_DUMP => aceasta procedura returneaza o lista de clienti precum si fisierele initial exportate de server, ce au fost montate de catre respectivii clienti Acest lucru se poate realiza prin utilizarea functiilor: showmount si dfmounts - MOUNTPROC_UMNT => aceasta procedura este utilizata pentru a informa serverul ca fisierele NFS au fost demontate - MOUNTPROC_UMNTALL => aceasta procedura este trimisa de un client in urma unui restart sau al unui crash - MOUNTPROC_EXPORT => aceasta procedura returneaza lista de sisteme de fisiere exportate Alternativ, o mare parte din sistemele Unix suporta automontarea Acest mecanism permite ca o multime de cataloage de la distanta sa fie asociate cu un catalog local Trebuie precizat faptul ca nici unu catalog nu va fi montat atunci cand clientul porneste Astfel, atunci cand este deschis pentru prima data un fisier de la distanta, sistemul de operare va trimite un mesaj fiecarui server, iar primul server care raspunde va castiga si prin urmare catalogul sau va fi cel montat 2.2 Versiunile si ale protocolului NFS Desi a avut un important succes, versiunea a protocolului NFS nu a fost lipsita de defecte Aceste lipsuri au condus la dezvoltarea versiunii a protocolului NFS In continuare vor fi prezentate principalele defecte ce au condus la necesitatea de progres a protocolului NFS: - Dimensiunea maxima a fisierelor ce puteau fi accesate era una de doar 4GB - Impunerea scrierilor sincronizate pe server a constituit o alta importanta problema Noua versiune imbunatatita a protocolului NFS a reusit sa rezolve si alte probleme aditionale precum: - In timp ce in versiunea a 2-a a protocolului, dimensiunea fisierelor si a cailor de acces era limitata intre intervalul 255 - 1024 caractere, odata cu aparitia versiunii au aparut sirurile de caractere variabile a caror lungime putea fi stabilita in urma acordului intre client si server - In versiunea a 2-a, dimensiunea identificatorului de fisiere era una fixa si anume o structura de date opaca de 32 de bytes Odata cu aparitia versiunii a 3-a, aceasta dimeniune a devenit una variabila, atingand un maxim de 64 de bytes - Odata cu aparitie noii versiuni, a fost eliminata restrictia de a scrie maxim Kb la un apel - Noua versiune a determinat reducerea numarului erorilor ce putea fi returnat de catre server Astfel, toate valorile erorilor au fost iterate si implicit nici o eroare din afara listei nu era permisa - In noua versiune a fost utilizat protocolul TCP/IP in special pentru a se putea evita pierderea de pachete la trecerea printr-un router Protocolul NFS a fost implementat pentru retelele LAN “(Local Area Connection)” si a fost pus in functiune cu mult inaintea dezvoltarii si ascensiunii puternice a “World Wide Web-ului” Astfel odata cu trecerea timpului, necesitatea de a utiliza protocolul NFS in “Wide Area Networks” a crescut foarte puternic, proportional cu necesitatea de a implementa protocolul NFS si pe alte platforme decat Unix Printre principalele imbunatatiri aduse de versiunea a 4-a a NFS-ului se numara: - Internationalizarea: pentru a se putea oferi un suport mai bun, a fost implementata codarea fisierelor si a directoarelor cu UTF-8 - Proceduri compuse: pentru a mari performanta, s-a redus numarul de proceduri individuale, acestea fiind combinate intr-o procedura compusa singulara - Identificatorii volatili de fisire: in noua versiune, identificatorii de fisiere au fost impartiti in categorii: trditionali si volatili, iar in cazul celor din urma, atunci cand serverul determina cu un identificator este invalid, acesta va returna un mesaj de eroare - File Locking: prin implementarea acestei optiuni, se ofera o siguranta mai mare, prin adaugarea unei functii de blocare la nivel de fisier Capitolul 3: The Remote File Sharing Service (RFS) In timp ce Sun dezvolta sistemul de gestiune al fisierelor de retea denumit NFS, firma AT&T era implicata in proiectul dezvoltarii unui alt sistem de gestiune al fisierelor distribuite, care a fost denumit: “The Remote File Sharing Service” Spre deosebire de NFS, in cazul acestui protocol scopul dezvoltarii era unul diferit si anume obtinerea unei semantici complete pentru fisierele Linux Intr-un mod similar celui din cazul sistemului NFS, in cazul sistemului RFS, clientul are posibilitatea de a monta un fisier care a fost exportat de catre server In cazul arhitecturii RFS, un client va putea receptiona detalii referitoare la resursele disponibile de la un “name server” si implicit va putea monta un sistem de fisiere, fara a dispune de cunostinte anterioare despre serverul ce a detinut respectivul sistem de fisiere Sistemul RFS necesita un protocol distinct de serviciu de nume, astfel incat, atunci cand un client efectueaza o cerere ce implica o resursa specifica, “name server-ul” va returna numele serverului pe care a fost localizata acea resursa Si acest sistem de gestiune al fisierelor distribuite va utiliza mecanismul “Remote Procedure Call” (RPC), tehnica prin care se doreste ca o aplicatie client sa poata apela o functie generata de server, in acelasi mod in care ar putea apela o functie din propriul sau spatiu de adresare De asemenea, in cazul RFS, mecanismul RPC va utiliza protocolul XDR pentru codarea datelor, numai in cazurile in care arhitecturile clientului si serverului difera Din perspectiva serverului, scopul acestuia este de a emula mediul clientului si a-i putea oferi acestuia un context familiar Pentru a se putea oferi o semantica Unix completa, incluzand functiile de blocare la nivel de fisier sau accesare, in cazul sistemul RFS serverul, spre deosebire de cel din cazul lui NFS, trebuie sa fie in stare sa pastreze referinte despre fiecare apel deschis efectuat de catre un client, cat si despre securitatea fisierelor si accesarilor de pe server De asemenea, sistemul RFS va mentine o lista a tuturor montarilor efectuate de clienti si astfel in cazul in care un client a devenit indisponibil, serverul va fi nevoit sa elimine toate urmele clientului respectiv Arhitctura sistemului de gestiune RFS va fi ilustrata in figura urmatoare Observam ca, spre deosebire de NFS, arhitectura sistemului RFS necesita un serviciu de transport de incredere, implementat sub forma unui circuit virtual In cazul nostru, acesta este reprezentat de TCP/IP Astfel, un circuit virtual va fi implementat in timpul procesului de montare, si va ramane in existenta, pe toata durata montarii respective Pentru fiecare pereche server-client, circuitul virtual va fi distribuit in cazul in care un client va monta mai mult decat un sistem de fisiere RFS 10 Sistemul RFS suporta de asemenea cache-ul la nivelul clientului RFS implementeaza un cache de tip “write-through” pe fiecare server, ceea ce inseamna ca orice scriere va fi trimisa serverului, chiar la momentul scrierii, iar datelor vor fi stocate in cache pentru accesul ulterior Capitolul 4: The Andrew File System (AFS) Un alt sistem de fisiere de retea este reprezentat de “The Andrew Filesystem” (AFS), dezvoltat la inceputul anilor 1980, la universitatea “Carnegie Mellon University” (CMU) ca parte a unui proiect sustinut in colaborare intre CMU si IBM denumit “Project Andrew” Acesta a evoluat mai tarziu in “The DCE Distributed File Service” (DFS) Unul din scopurile acestui nou sistem de fisiere a fost acela de a oferi un singur spatiu unificat de nume, astfel incat userii sa aiba posibilitatea de a-si accesa fisierele, indiferent de locul in care s-ar afla in retea Pentru cresterea performantei, s-a urmarit de asemenea utilizarea unui caching agresiv la nivelul clientului, precum si permiterea migrarii unui grup de fisiere de la un server la altul fara a suferi pierderi Arhitectura AFS consta intr-un grup de celule ce se afla in / afs Aplicand comanda ls / afs ne va fi afisata lista de celule AFS In acest caz, putem defini o celula ca fiind o colectie de servere care sunt grupate impreuna si administrate ca un intreg Indiferent de cazul in care o celula este locala sau aflata la distanta, toti userii vor vedea exact aceeasi ierarhie a fisierelor, indiferent de locul din care acceseaza sistemul 11 In interiorul unei celule, se afla un numar de servere si clienti Serverele se vor ocupa cu gestiunea unui set de volume ce se afla in “Volume Location Database” Acest VLDB se va afla pe fiecare dintre servere De asemenea volumele pot fi replicate peste un numar diferit de servere sau pot migra pentru a putea fisierele unui user de la o locatie la alta Clientii vor necesita fiecare un local disk propriu, pentru a putea realiza procesul de caching In acest caz, caching-ul va fi controlat de un “local cache manager” In implementarile timpurii, atunci cand un fisier era deschis, acesta era copiat in intregime pe disk-ul clientului Urmatoarele versiuni au definit copierea ca fiind realizata in parti de date de 64 KB Trebuie precizat faptul ca managerul de cache va contine si meta-date, informatii despre fisier, precum si symbolic-link-uri In situatie in care un client preia date de pe un server, acesta va obtine un “callback” Daca in schimb un alt client va modifica datele, serverul are obligatia de a-si informa clientii despre faptul ca cache-ul lor poate fi invalid Daca in schimb, doar un client detine “callback-ul”, atunci acesta poate opera asupra fisierului fara supraveghere din partea serverului pana in momentul in care acesta va trebui sa anunte serverul de efectuarea unui proces precum inchiderea fisierului De asemenea, “callback-ul” primit va deveni invalid daca un alt client va incerca sa modifice fisierul in cauza Pentru a se putea evita situatii de genul celei descrise, clientii ce au primit aceste “callback-uri” vor trimite regulat serverului asa numitele mesaje de proba 12 Capitolul 5: Server Message Block (SMB) In retelistica, SMB-ul cunoscut si sub numele de “Common Internet File System” (CIFS) opereaza la nivelul aplicatie in stiva de protocoale, fiind utilizat in principal pentru a oferi acces la fisierele partajate, la imprimante sau la porturile seriale De asemenea, SMB-ul ofera un mecanism de comunicare autentificata intre procese Spre deosebire de sistemele de gestiune de fisiere distribuite prezentate in aceasta lucrare, sistemul SMB functioneaza de obicei pe Windows, unde mai este cunoscut si sub numele de “Microsoft Windows Network” Acesta utilizeaza protocolul TCP la nivelul transport si comunica prin portul 445 In anul 1996, Microsoft a avut initiativa de a redenumi sistemul SMB in “Common Internet File System (CIFS)” adaugand diferite optiuni, precum suportul pentru symboliclink-uri, pentru hard-link-uri, sau pentru fisiere de dimensiuni mai mari De asemenea se incearca suportul pentru conexiunile directe TCP pe port 445, fara a utiliza insa NETBIOSul ca transport Sistemul SMB functioneaza printr-o arhitectura client/server, unde clientul efectueaza o cerere iar serverul raspunde in consecinta Dezvoltatorii au optimizat sistemul SMB pentru uzul local, insa utilizatorii au determinat sistemul SMB sa acceseze diferitele subretele din Internet Astfel, serverele SMB isi fac propriile sisteme de fisiere precum si alte resurse disponibile clientilor din cadrul retelei Clientii vor dori acces la fisierele distribuite, precum si la printere, si astfel sistemul SMB a devenit unul dintre cele mai cunoscute si mai utilizate sisteme de acest gen Proiectantii de retele au realizat faptul ca latenta are un impact major asupra performantei SMB 1.0 care avea rezultate mai slabe decat FTP Acest lucru se datora faptului ca SMB lucra la nivel de bloc si a fost proiectat de la bun inceput pentru retele LAN de mici dimensiuni Limita blocului de date este de 64 Kb Microsoft a lansat versiunea SMB2 impreuna cu sistemul de operare Vista ỵn 2006 Chiar daca protocolul este proprietar, specificatiile au fost publicate pentru a permite altor sisteme sa poata interopera cu sistemele de operare Windows Prin intermediul acestia au fost aduse anumite imbunatatiri precum: - a fost implementata abilitatea de a adauga mai multe actiuni intr-o singura cerere, reducandu-se astfel numarul de apeluri client-server - a crescut viteza de transfer a fisierelor de dimensiuni mai mari, prin marirea dimensiunii bufferului 13 - spre deosebire de versiunea ce utiliza date pe 16 biti, sistemul SMB versiunea a 2-a utilizeaza date pe 32, 64 si uneori chiar si 128 de biti, fiind eliminata practic limitarea Capitolul 6: The Distributed File System (DFS) Microsoft Windows Server 2003 Release (R2) este primul update realizat pentru Windows Server 2003 La baza acestuia sta DFS-ul (The Distributed File System) al carui scop este acela de a oferi performanta si disponibilitate sporite Spre exemplu, utilizatorii pot intampina probleme in ceea ce priveste localizarea fisierelor distribuite pe servere In plus, administratorii furnizeaza de cele mai multe ori conexiuni cu o latime a benzii de transfer mica, pentru a putea oferi o replicare a fisierelor, precum si o disponibilitate a acestora in retelele de arie larga atunci cand serverele de la sediul central sau de la sucursalele aferente esueaza Pentru a putea rezolva aceste probleme aparute, Windows Server 2003 R2 ne furnizeaza “DFS Namespaces” si “DFS Replication” care impreuna ne ofera acces la fisierle distribuite atunci cand replicarea se face cu o latime a benzii de transfer mica DFS Namespaces: Acest serviciu permite administratorilor sa grupeze folderele partajate, ce sunt localizate pe diferite servere Folderele sunt prezentate ca un arbore virtual denumit spatiu de nume: “name space” pentru ca userii sa nu mai aiba nevoie sa isi aminteasca locatiile fizice ale fisierelor DFS Replication: Acest serviciu este implementat pentru a se adresa retelelor cu o latime de banda mica, utilizand algoritmul de compresie diferential de la distanta RDC Prin utilizarea algoritmului RDC, serviciul “DFS Replication” transfera doar schimbarile petrecute de la momentul ultimului update al fisierelor 6.1 Planificarea unei implementari DFS: 14 Administratorii trebuie sa ia in considerare o multitudine de factori atunci cand pregatesc o implementare DFS Dintre problemele ce se pot ivi amintim implementarea serviciului “Microsoft Active Directory”, disponibilitatea conexiunii intre filiale, disponibilitatea latimii de bandaintre filiale, accesul la fisierele distribuite in medii eterogene de retea, costul procedurilor de back-up precum si tipurile de fisiere existente Consideratii privind serviciul “Microsoft Active Directory”: Anumite functii ale protocolului DFS exista doar in mediul “Active Directory” Astfel spatiile de nume DFS pot fi singulare sau bazate pe un domeniu In continuare se va realiza o mica introducere in mediul “Active Directory”: “Active Directory” este un serviciu director ce poate oferi diverse servicii referitoare la organizarea depozitarii resurselor retelelor Urmatoarele puncte vor ilustra cateva dintre trasaturile serviciului “Active Directory”: - abordare organizata: “Active Directory” instaureaza o anumita ordine in cadrul resurselor unei retele, cum ar fi conturile de utilizatori, conturile de grup, folderele distribuite etc In cadrul lui “Active Directory” utilizatorii pot gasi cu usurinta informatia dorita - privarea utilizatorilor de cunostintele legate de topologia retelei: prin intermediul acestui serviciu, utilizatorii nu trebuie neaparat sa cunoasca anumite detalii precum ce server gazduieste ce resurse si unde este acesta localizat in retea Astfel, “Active Directory” contine puternice instrumente de cautare, astfel incat utilizatorii sa poate efectua cautari complete pentru a putea determina resursele de care au nevoie - reducerea domeniilor NT: un obiectiv important al serviciului “Active Directory” este acela de a face retelele mari mai usor de gestionat si implicit de a reduce numarul domeniilor NT - potential crescut: doua cuvinte cheie ce pot defini “Active Directory” sunt scalabilitatea si extensibilitatea Scalabilitatea inseamna ca serviciul poate creste in functie de cerintele retelei, in timp ce extensibilitatea implica faptul ca serviciul poate fi extins prin intermediul spatiului de nume si a resurselor pe care le contine - standardizarea: serviciul “Active Directory” este construit pe baza protocoalelor de retea utilizate in prezent Astfel “Active Directory este construit pe paza protocolului TCP/IP, si de asemenea este complet integrat cu DNS “Domain Name System” si LDAP “Lightweight Directory Access Protocol” Structura logica “Active Directory” 15 “Active Directory” este construit la nivel de domeniu Spre exemplu domeniile Windows 2000 Active Directory sunt organizate in arbori de domenii ce exista intr-o “padure” “Active Directory” prefera mai putine domenii sau chiar unul singur, cu cateva Organizational Units (OUs) Un “Organizational Unit” este asemanator unui fisier ce contine informatii importante precum utilizatori, computere, imprimante sau chiar si alte “organizational units” Aceste resurse sunt denumite obiecte iar in figura de mai jos va fi ilustrata structura unui asemenea model: Fiecare obiect va contine anumite atribute ce vor fi ilustrate in figura urmatoare Spre exemplu, un cont de utilizator detine atribute precum username, parola, e-mail etc 16 In continuare se va reveni la prezentarea unei implementari DFS: Spatiile de nume DFS singulare pot fi utilizate in cazul in care o organizatie nu utilizeaza serviciul “Active Directory”, sau daca are nevoie sa gazduiasca mai mult de 5000 de foldere in cadrul unui singur spatiu de nume Microsoft recomanda insa utilizarea spatiilor de nume DFS bazate pe domenii pentru a putea fi gazduite 5000 de foldere Serviciul “DFS Replication” trebuie sa fie implementat intr-un mediu “Active Directory” deoarece tehnologia RDC este functionabila doar intr-un domeniu “Active Directory” Consideratii privind disponibilitatea conexiunii intre filiale: Intr-un mediu in care conectivitatea in retea poate sa nu fie disponibila sau sa nu fie sigura, datorita calitatii slabe a provider-ului de internet, DFS permite administratorilor sa configureze mai multe servere de fisiere tinta pentru un spatiu de nume dat In acest caz, disponibilitatea datelor va fi permanenta, si in plus atunci cand principala tinta va reveni in functionare, cererile accesului la date vor fi redirectionate inapoi la primul server DFS Consideratii privind disponibilitatea latimii de banda intre filiale: In multe din cazuri, filialele sunt conectate la serverul principal al companiei utilizand conexiuni VPN (Virtual Private Network) In aceste tipuri de medii, sincronizarea datelor sufera o mica latenta datorita latimii de banda a retelei In Windows Server 2003 R2 algoritmul RDC din cadrul serviciului “DFS Replication” detecteaza modificarile realizate de utilizatori asupra fisierelor replicate si va trimite doar modificarile facute din momentul ultimului update Aceasta modalitate consuma astfel mai putina latime de banda decat in cazul modalitatilor precedente Consideratii privind accesul la fisierele distribuite in medii eterogene de retea Pentru retele ce suporta atat sistemul de operare Windows cat si sistemul de operare Linux, “Windows Server 2003 R2” furnizeaza serviciul “Network File System (NFS)” precum si un serviciu de cartografiere ce permite platformelor non-Windows sa acceseze fisierele distribuite de pe sistemele ce ruleaza pe “Windows Server 2003” Consideratii privind tipurile de fisiere: Windows Server 2003 R2 DFS este implementat sa lucreze doar cu tipuri de fisiere care nu sunt afectate de latenta cauzata de latimea de banda a retelei sau a problemelor de disponibilitate Spre exemplu, fisierele ce necesita sincronizarea datelor in timp real, precum baze de date orientate pe tranzactii nu sunt tocmai indicate pentru o implementare DFS 17 Bibliografie [1] Unix Filesystems - Evolutions, Design, and Implementation - Steve D Pate [2] Linux Bible - Christopher Negus - 2006 Edition [3] http://en.wikipedia.org/wiki/Network_File_System_%28protocol%29 [4] http://en.wikipedia.org/wiki/Andrew_File_System [5] http://en.wikipedia.org/wiki/Server_Message_Block [6] Active Directory Bible - Curt Simmons 18 ... 1980, devenind odata cu trecerea timpului un mare succes Scopurile dezvoltarii acestui sistem de gestiune al fisierelor de retea au fost urmatoarele: - Independenta de masina si de sistemul de operare... (NFS), dezvoltat de Sun Microsystems, acesta fiind folosit de majoritatea sistemelor Unix moderne In timp ce Sun dezvolta NFS-ul, firma AT&T lucra la dezvoltarea unui alt sistem de fisiere distribuite, ... contine sistemul de fisiere, va juca rolul de server, si va oferi astfel acces clientilor printr-un protocol bine definit Spre deosebire de sistemele de fisiere locale, acolo unde spatiul este