1.4 Sistem de fișiere din rețea

Sistemul de fișiere CIFS domină piața sistemelor de fișiere de rețea pentru platforma Windows. Pe platforma UNIX, principalul este Network File System (NFS). În plus, NFS este considerat a fi primul sistem de fișiere adoptat pe scară largă, datând de la mijlocul anilor 1980. Cu toate acestea, în ciuda unor funcționalități comune între CIFS și NFS (sisteme de fișiere de rețea care permit clienților să acceseze resursele serverului), aceste sisteme au caracteristici arhitecturale complet diferite. Odată cu lansarea NFS versiunea 4, unele diferențe au fost revizuite.
Protocolul CIFS stochează date de serviciu specifice fiecărui client. Înainte de versiunea 3, sistemul de fișiere NFS nu păstra statutul de client, care sa schimbat în versiunea 4.
Clientul NFS nu „negociază” cu serverul NFS pentru a stabili o sesiune. Se iau măsuri de securitate pentru întreaga sesiune sau fiecare comunicare între client și server. Ultima opțiune este prohibitiv de costisitoare de implementat, așa că NFS lasă responsabilitatea de securitate în seama clientului. Serverul „presupune” că ID-urile utilizatorului de pe sistemele client și server sunt aceleași (și clientul a verificat identitatea utilizatorului înainte de a-i permite acestuia să se înregistreze sub ID-ul specificat). În plus, NFS oferă un anumit nivel de securitate prin controlul listei de sisteme de fișiere pe care un client le poate monta. De fiecare dată când un client CIFS deschide un fișier, primește un handle de fișier (adică date de serviciu pe care serverul trebuie să le stocheze) și îl folosește pentru a efectua operațiuni de citire sau scriere la nivelul clientului, serverul NFS interogează serverul, care returnează fișierul. mâner. Acest descriptor de fișier este procesat de clienții care acceptă standardele NFS 3 și NFS 2. Clientul memorează în cache descriptorul de fișier rezultat și se așteaptă ca descriptorul să indice întotdeauna același fișier.
Pentru cei familiarizați cu UNIX, un descriptor de fișier constă de obicei dintr-un număr de inoduri, un număr de generare de inoduri și ID-ul fișierului care este asociat cu partiția de disc. Este suficient să spunem că inodul este o structură de date extrem de importantă folosită în sistemele de fișiere UNIX. Sunt stocate suficiente informații pentru a elimina mânerele stocate în cache de clienți dacă fișierul corespunzător pentru mâner s-a schimbat și mânerul trebuie să indice un fișier diferit. De exemplu, dacă un fișier este șters și un fișier cu același nume este copiat în locul său, contorul de generare a inodului va fi modificat și descriptorul fișierului stocat în cache de client va fi invalid. Sistemul de fișiere NFS 4 are diferențe în implementare.
Unii clienți NFS realizează memorarea în cache pe partea client prin stocarea datelor pe discuri, ceea ce este similar cu memorarea în cache CIFS. De asemenea, unii clienți NFS modifică valoarea timeout-urilor în funcție de timpul de răspuns al serverului. Cu cât serverul răspunde mai lent, cu atât valoarea timeout este mai mare și invers.
Sistemul de fișiere NFS a fost conceput pentru a fi independent de transport și a folosit inițial protocolul de transport UDP. Pot fi utilizate diferite tipuri de NFS Protocolul TCPși alte protocoale.

1.4.1 Sistemul de fișiere de rețea versiunea 3

Sistemul de fișiere NFS 3 îmbunătățește performanța, în special pentru fișierele mari, permițând clientului și serverului să selecteze dinamic cantitatea maximă de date care este transferată într-un singur element de pachet logic atunci când scrie sau citește. În sistemul de fișiere NFS 2, dimensiunea pachetului a fost limitată la 8 KB. Cu alte cuvinte, clientul ar putea trimite maximum 8 KB într-o cerere de scriere, iar serverul ar putea trimite maximum 8 KB într-un răspuns la cerere de citire. În plus, NFS 3 a redefinit decalajele fișierelor și dimensiunile datelor. Acestea sunt acum valori de 64 de biți, în loc de 32 de biți în NFS 2.
Mai jos sunt câteva dintre caracteristicile NFS 3.
■ Descriptorii de fișiere în NFS 3 au dimensiuni variabile; dimensiunea lor maximă este de 64 de biți.
■ Sistemul de fișiere NFS 3 permite clienților și serverelor să aleagă dimensiune maximă nume de fișiere și directoare.
■ NFS 3 defineşte o listă de erori pe care serverul le poate returna clienţilor. Serverul trebuie să returneze una dintre erorile specificate sau să nu returneze nicio eroare.
■ În NFS 3, serverului i se permite să memoreze în cache datele pe care clientul le-a trimis cu o solicitare de scriere. Serverul poate stoca datele în cache și poate trimite un răspuns la cerere către client înainte ca datele să fie scrise pe disc. A fost adăugată și o comandă COMMIT, care permite clientului să se asigure că toate datele trimise au fost scrise pe disc. Acest lucru face posibilă atingerea unui echilibru între îmbunătățirea performanței și menținerea integrității datelor.
■ NFS 3 reduce numărul de operaţii de cerere/răspuns între client şi server. Pentru a face acest lucru, datele despre atributul fișierului sunt trimise împreună cu solicitarea inițială. În NFS 2, clientului i s-a cerut să obțină nume de fișiere și un descriptor pentru fiecare fișier, abia apoi au fost transmise atributele fișierului.

1.4.2 Sistemul de fișiere de rețea versiunea 4

NFS 4 a revizuit complet principiile fundamentale și a implementat multe caracteristici specifice CIFS, ceea ce i-a supărat foarte mult pe unii apologeți NFS. Dacă te uiți la istoria sistemelor de fișiere din rețea, poți vedea că NFS a devenit larg răspândit. Sistemul de fișiere SMB a fost conceput având în vedere punctele forte și punctele slabe ale NFS, iar acum, cel puțin în rândul clienților, CIFS/SMB devine din ce în ce mai comun, iar NFS evoluează pentru a profita de punctele forte și slabe ale CIFS/SMB. Următoarele evidențiază funcțiile care au fost adăugate la NFS 4 pentru a îmbunătăți performanța, securitatea și interoperabilitatea cu CIFS.
■ NFS 4 a introdus cererea COMPOUND, care vă permite să împachetați cereri multiple într-o singură cerere și răspunsuri multiple într-un singur răspuns. Această inovație este concepută pentru a îmbunătăți performanța prin reducerea încărcării rețelei și reducerea latenței pe măsură ce cererile și răspunsurile circulă în rețea. Dacă aceasta sună oarecum ca caracteristica CIFS AndX SMB (vezi Secțiunea 3.3.5.1), atunci s-ar putea să nu fie o simplă coincidență.
■ Sistemul de fișiere de rețea versiunea 4 împrumută unele caracteristici de la WebNFS de la Sun. În special, NFS 4 acceptă unele protocoale secundare în specificația de bază, făcând NFS mai potrivit pentru utilizarea cu firewall-uri. NFS 3 și versiunile anterioare au folosit un protocol special pentru a monta o partajare de server în arborele sistemului de fișiere local. Deoarece serviciul de protocol de montare nu avea alocat un port TCP sau UDP, clientul a trimis mai întâi o solicitare către demonul portmapper, care furnizează numărul portului pe care serviciul de montare ascultă cereri. Astfel, pe lângă NFS, la proces au luat parte și protocoalele de montare și mapare a porturilor. Mai mult, deoarece serviciul de montare ar putea folosi un port arbitrar, configurarea firewall-ului a devenit foarte dificilă. În NFS 4, protocoalele de montare și mapare porturi au fost eliminate. În plus, blocarea a fost inclusă în specificația de bază a protocolului NFS, iar protocolul NLM (Network Lock Manager), care a fost folosit în versiunile anterioare ale NFS, a fost permanent depreciat.
■ Sistemul de fișiere NFS 4 necesită utilizarea unui protocol de transport care oferă capacitatea de a detecta congestionarea rețelei. Aceasta înseamnă că clienții și serverele NFS se vor muta treptat la TCP în loc de UDP, care este folosit în mod obișnuit cu NFS 3.
■ NFS 2 și NFS 3 au permis utilizarea setului de caractere din S.U.A. ASCII sau ISO Latin 1. Acest lucru a cauzat probleme atunci când un client care folosea un set de caractere a creat un fișier și acel fișier a fost accesat de un client folosind un set de caractere diferit. NFS 4 folosește setul de caractere UTF-8, care acceptă compresia compactă a caracterelor pe 16 și 32 de biți pentru transmisia prin rețea. În plus, setul de caractere UTF-8 conține suficiente informații pentru a evita problemele la crearea unui fișier folosind un set de caractere și accesarea unui fișier folosind un alt set de caractere.
■ Sistemul de fișiere NFS 4 necesită clientului să gestioneze descriptorii de fișiere separat. În NFS 3, clientul putea stoca în cache mânerul ca obiect, în timp ce serverul se asigura că mânerul indică întotdeauna un fișier. NFS 4 definește două tipuri de descriptori de fișiere. Unul se numește descriptori de fișiere persistente și are capabilitățile de descriptori de fișiere din NFS 3. Al doilea, descriptori de fișiere temporare, presupune că descriptorul expiră după o anumită perioadă de timp sau eveniment. Aceasta este o caracteristică pentru serverele ale căror sisteme de fișiere (cum ar fi NTFS) nu pot oferi o mapare coerentă între fișierele afișate și handle.
■ NFS 4 adaugă suport pentru operațiuni OPEN și CLOSE, a căror semantică permite interacțiunea cu clienții CIFS. Comanda OPEN creează date de stare pe server.
■ Suportul de solicitare OPEN al NFS 4 permite unui client să emită o cerere de deschidere a fișierului care este structurată în mod similar cu cererile de deschidere a aplicației Windows. De asemenea, este acceptată alegerea de a partaja fișierul cu alți clienți sau de acces exclusiv la fișier.

1.4.2.1 Securitate NFS 4

Sistemul de fișiere NFS 4 vă permite să îmbunătățiți securitatea datelor stocate. În special, NFS 4 a adăugat suport Mai mult atributele fișierului. Unul dintre aceste atribute este o listă de control al accesului (ACL) în stil Windows NT. Acest lucru permite o interoperabilitate îmbunătățită între sistemele de fișiere și o structură de securitate mai puternică.
În timp ce în NFS 2 și NFS 3 utilizarea caracteristicilor de securitate a fost doar recomandată, în NFS 4 a devenit obligatorie. Sistemul de fișiere NFS 4 necesită implementarea unui mecanism de securitate folosind interfața RPCSEC_GSS (Generic Security Services) în general și protocoalele Kerberos 5/LIPKEY în special. Rețineți că RPCSEC_GSS acționează pur și simplu ca un API și un mecanism de transport pentru etichetele și datele legate de securitate. Sistemul de fișiere NFS 4 permite mai multe scheme de autentificare și securitate și posibilitatea de a alege schema potrivită pentru clienți și servere.
Să acordăm puțină atenție studierii tehnologiei LIPKEY, care utilizează o combinație de criptare simetrică și asimetrică. Clientul criptează datele utilizatorului și parola folosind o cheie de 128 de biți generată aleatoriu. Criptarea se realizează folosind un algoritm simetric, adică. trebuie folosită aceeași cheie pentru decriptare. Deoarece serverul are nevoie de această cheie pentru a decripta mesajele, o cheie generată aleatoriu trebuie trimisă către server. Clientul criptează cheia (care este generată aleatoriu) folosind cheia publică a serverului. Serverul decriptează datele cu cheia sa privată, extrage cheia simetrică și decriptează datele utilizatorului și parola.
Clienții pot autentifica serverele folosind un certificat de server, iar serviciile de autoritate de certificare sunt utilizate pentru a verifica certificatul. Una dintre metodele populare de hacking este interceptarea pachetelor de date „extraterestre” și apoi trimiterea lor după o anumită perioadă de timp. Când utilizați Kerberos, sistemul de fișiere NFS adaugă un marcaj temporal fiecărui pachet. Serverul înregistrează marcajele de timp primite recent și le compară cu marcajele de timp ale noilor pachete RPC. Dacă marcajele de timp ale pachetelor sunt mai vechi decât cele primite anterior de server, serverul ignoră pachetele primite

1.5 Probleme de acces la utilizarea mai multor protocoale

Mai multe companii au început să ofere sisteme care acceptă simultan CIFS, NFS și alți clienți de sistem de fișiere de rețea. Furnizorii au depus multă muncă încercând să depășească provocările tehnice care apar din cauza clienților care pot utiliza diferite sisteme de operare și sisteme de fișiere. Vă rugăm să rețineți că problemele nu apar cu datele în sine, ci cu metadatele fișierelor. Un simplu test pentru astfel de probleme ar fi copierea unui fișier de pe server pe client și înapoi pe server (sau invers). Odată ce fișierul este plasat în resursa inițială, metadatele ar trebui să conțină valorile de bază, adică Permisiunile pentru fișiere și marcajele de timp nu ar trebui să se schimbe. Dacă acest lucru nu este adevărat, atunci problema a fost detectată.
Următoarele sunt exemple ale unor posibile probleme tehnice.
■ Sistemele de operare diferite folosesc metode diferite pentru a urmări permisiunile de acces ale utilizatorilor și grupurilor.
■ Diferite sisteme de operare și sisteme de fișiere au o semantică diferită pentru deschiderea și blocarea fișierelor.
■ Convențiile de denumire a fișierelor sunt gestionate în moduri diferite. Diferite sisteme de fișiere au reprezentări diferite ale dimensiunii maxime a unui nume de fișier, valoarea majusculă a unui nume de fișier și setul de caractere permis în nume.
■ Datele și structura lor diferă în diferite sisteme de fișiere; de exemplu, unele sisteme de fișiere urmăresc două marcaje temporale, în timp ce altele urmăresc trei marcaje temporale (ora la care fișierul a fost accesat ultima dată, fișierul a fost modificat ultima dată și fișierul a fost creat). Chiar dacă ambele sisteme de fișiere urmăresc două marcaje temporale, unitățile de măsură pot diferi. Un alt exemplu sunt unitățile de măsurare a offset-urilor în fișiere. Unele sisteme de fișiere acceptă decalaje de 32 de biți, iar unele acceptă decalaje de 16 sau 64 de biți.
■ Probleme cu adresarea lacăturilor afișate. Serverul CIFS impune blocarea: dacă un client a blocat o regiune a unui fișier, atunci orice operație de scriere în acea regiune a fișierului de către un alt client va avea ca rezultat o eroare. Cu toate acestea, blocarea forțată nu este acceptată de serverele NFS. Prin urmare, trebuie să alegeți dacă blocarea va fi aplicată, ceea ce va duce la trimiterea unui mesaj de eroare către clientul NFS.

AGENTIA FEDERALA DE TRANSPORT AERIAN

INSTITUȚIE DE ÎNVĂȚĂMÂNT FEDERALĂ DE STAT

ÎNVĂŢĂMÂNT PROFESIONAL SUPERIOR

„STATUL MOSCOVA

UNIVERSITATE TEHNICA

AVIATIE CIVILA"

____________________________________________________________________________________________________________________

Departamentul Calculatoare, Complexe, Sisteme și Rețele

SISTEME DE OPERARE ÎN REȚEA.

SISTEME DE FIȘIERE DE REȚEA

SI SERVICIUL DIRECTORUL

Aprobat editorial

Consiliul editorial al MSTU GA

Moscova - 2010

BBK 32.973.202-018.2ya73-1+32.973.26-018.2ya73-1

Publicat prin hotărâre a consiliului editorial și editorial

Universitatea Tehnică de Stat de Aviație Civilă din Moscova

Recensori: Ph.D. fizica si matematica Științe, conferențiar ;

Ch48 Sisteme de operare în rețea. Sisteme de fișiere de rețea și servicii de directoare: un tutorial. - M.: MSTU GA, 2010. –68 p. 10 ill., lit.: 4 nume.

Acest manual este publicat în conformitate cu programul de lucru al disciplinei academice „Sisteme de operare în rețea” conform Curriculum-ului de specialitate 230101 pentru studenții din anul IV cu normă întreagă.

Revizuit și aprobat la ședințele departamentului din 11.05.10 și ale consiliului metodologic din 14.05.10.

-038 BBK 32.973.202-018.2ya73-1+32.973.26-018.2ya73-1

Ts33(03)-10 Sf. teme. plan 2010

CERKASOVA Natalia Ivanovna

SISTEME DE OPERARE ÎN REȚEA.

SISTEME DE FIȘIERE DE REȚEA ȘI SERVICII DE DIRECTOR

Tutorial

Editor

Semnat pentru publicare la 11 octombrie 2010.

Imprimare offset Format 60x84/16 4.0 ed. academic. l.

3,95 convențional cuptor l. Comanda nr. 000 / Tiraj 100 exemplare.

Universitatea Tehnică de Stat de Aviație Civilă din Moscova

125993 Moscova, Bulevardul Kronstadtsky, 20

Departamentul de redactare și editare

125493 Moscova, st. Pulkovskaia, 6a

© Statul Moscova

Universitatea Tehnică din GA, 2010

Secțiunea 1. Compoziția sistemelor de operare în rețea

1.1. Sistem de operare de rețea. Definiție, proprietăți de bază

Rețeaua poate fi orice, dintr-un set simplu de computere (două computer conectat există deja o rețea) la internetul global, care utilizează multe mijloace diferite de comunicare, inclusiv tehnologiile cu microunde și satelit.

O rețea constă din calculatoare, echipamente de comunicații (de exemplu, cabluri de cupru sau fibră optică) și alte dispozitive, cum ar fi diferite tipuri de hub-uri și routere (care vă permit să gestionați traficul de rețea), adaptoare (care sunt folosite pentru a conecta un computer la o rețea), formând o structură de rețea. Tehnologiile de transmitere a informațiilor sunt, de asemenea, foarte diverse.

Sunt considerate două tipuri de rețele: LAN (Local area network) - o rețea locală, un set de computere și dispozitive unite într-o singură clădire și WAN (Wide area network) - o rețea globală care combină mai multe rețele locale separate geografic care sunt conectate prin diferite WAN - tehnologii.

Scopul unei rețele depinde de nevoile unei persoane sau ale unei organizații, dar, în general, pot fi enumerate următoarele posibilități de utilizare a rețelelor:

1) partajarea fișierelor. Rețeaua vă permite să utilizați fișiere de date atât stocate pe computerul unui anumit utilizator, cât și fișiere găzduite pe un server de fișiere specializat;

2) partajarea hardware-ului;

3) partajarea software-ului;

4) schimbul de informații între utilizatori;

5) jocuri de rețea.

Rețeaua reprezintă nu numai resurse locale pentru utilizare, dar însăși existența rețelei înseamnă că aceasta poate fi combinată cu alte rețele.

Sistemele de operare pentru rețele sunt în multe privințe similare cu sistemul de operare al unui computer independent. Cu toate acestea, dacă acesta din urmă prezintă utilizatorului o anumită mașină de calcul virtuală, atunci sistemul de operare al rețelei, în timp ce îi prezintă utilizatorului un anumit sistem de calcul virtual, cu care este mult mai ușor de lucrat decât cu echipamente de rețea reală, nu ascunde complet sistemul distribuit. natura prototipului său real. Putem spune că sistemul de operare al rețelei oferă utilizatorului o rețea virtuală. În mod ideal, un sistem de operare de rețea ar trebui să prezinte utilizatorului resursele de rețea ca resurse dintr-o singură mașină virtuală centralizată. Asemenea sisteme de operare se numesc sistemul de operare distribuit sau sistemul de operare cu adevărat distribuit.

Sistemele de operare distribuite, prin distribuirea dinamică și automată a lucrărilor pe diferite mașini de sistem pentru procesare, fac ca un set de mașini conectate în rețea să funcționeze ca un uniprocesor virtual. Un sistem de operare distribuit funcționează ca un singur sistem de operare într-un sistem de calcul.

Sistemele de operare de rețea moderne nu sunt cu adevărat distribuite, adică gradul de autonomie al fiecărui computer din rețea care rulează un sistem de operare de rețea este semnificativ mai mare în comparație cu computerele care rulează un sistem de operare distribuit.

Termenul de sistem de operare de rețea este folosit în două sensuri: în primul rând, ca totalitatea sistemului de operare al tuturor computerelor din rețea și, în al doilea rând, ca sistemul de operare al unui computer individual capabil să lucreze în rețea. Din punct de vedere funcțional, sistemul de operare al rețelei poate fi împărțit în următoarele componente:

1) instrumente locale de gestionare a resurselor, adică toate funcțiile sistemului de operare ale unui computer autonom;

2) partea de server a sistemului de operare este un mijloc de furnizare de resurse și servicii locale pentru uz public;

3) parte client a sistemului de operare – mijloace de acces la resurse și servicii de la distanță;

4) vehicule OS, care împreună cu sistemul de comunicare asigură transferul de mesaje între calculatoarele din rețea.

Combinația de părți server și client ale sistemului de operare care oferă acces la o anumită resursă prin intermediul rețelei se numește serviciu de rețea. Un serviciu de rețea oferă unui utilizator de rețea un set de servicii numit serviciu de rețea. Fiecare serviciu este asociat cu un anumit tip de resursă de rețea și/sau cu metode specifice de accesare a acestor resurse.

Serviciile de rețea sunt sisteme client-server, adică conțin o parte client și o parte server. Cu toate acestea, un serviciu de rețea poate fi reprezentat în sistemul de operare fie de ambele părți, fie de doar una dintre ele.

Trebuie remarcat faptul că, atunci când un serviciu de rețea oferă un anumit serviciu, sunt folosite nu numai resursele serverului, ci și ale clientului. Diferența fundamentală dintre un client și un server este că clientul este întotdeauna inițiatorul activității unui serviciu de rețea, iar serverul este întotdeauna într-un mod pasiv de așteptare a cererilor.

Deși un tip de server poate fi proiectat pentru a gestiona diferite tipuri de clienți, clientul și serverul trebuie să accepte un protocol de comunicare standard comun.

Profunzimea implementării serviciilor de rețea în sistemul de operare determină mai multe abordări pentru construirea sistemelor de operare de rețea:

1) serviciile de rețea sunt combinate sub forma unui anumit set - un shell;

2) serviciile de rețea sunt furnizate și fabricate ca un produs separat;

3) serviciile de rețea sunt implementate în sistemul de operare.

Diferitele scopuri urmărite la crearea diferitelor rețele necesită existența unor tipuri diferite de rețele. Rețeaua Peer-to-Peer este o modalitate simplă de conectare calculatoare personaleîn cazurile în care este necesară partajarea fișierelor și a altor resurse. Într-o rețea peer-to-peer, nu există un server și toate computerele funcționează ca peer. O rețea peer-to-peer este adesea numită grup de lucru, deoarece acest termen este asociat cu colaborarea peer-to-peer fără control centralizat.

Un nod de rețea este un computer care conectează două rețele folosind aceleași protocoale. Nodul oferă doar comunicarea între două programe compatibile pe două astfel de rețele. Nodurile folosesc în esență informațiile de adresă conținute în pachetele transmise. Nodurile sunt dispozitive de nivel de rețea.

Să luăm în considerare software-ul unor astfel de rețele. În rețelele peer-to-peer, toate computerele au instalat un sistem de operare care oferă posibilități egale tuturor computerelor din rețea. Evident, astfel de sisteme de operare peer-to-peer trebuie să includă atât componente de serviciu de rețea de server, cât și de client.

Odată cu egalitatea potențială a tuturor computerelor dintr-o rețea peer-to-peer, apare adesea eterogenitatea funcțională. Este posibil să existe utilizatori în rețea care nu își împărtășesc resursele.

În acest caz, capacitățile de server ale sistemului lor de operare nu sunt activate, iar computerele acționează ca clienți „puri”. Este posibilă și situația inversă, când unele computere îndeplinesc doar funcții pentru a deservi cererile clienților, adică devin servere „pure”. Cu toate acestea, inițial în rețelele peer-to-peer, specializarea OS nu depinde de rolul computerului.

DOS nu a acceptat rețele peer-to-peer, așa că partajarea fișierelor sau imprimantelor necesita produse software suplimentare, adică funcțiile de rețea au fost implementate de shell-uri de rețea care rulează pe sistemul de operare. Pentru a susține grupurile de lucru, au fost utilizate produse software precum Artisoft LANtastic, Novell NetWare Lite, Personal NetWare și Windows for Workgroup 3.11. Toate versiunile ulterioare de Windows acceptă grupuri de lucru.

Distribuțiile Linux acceptă și crearea de grupuri de lucru de pe computere care rulează Windows sau Linux folosind Samba.

Deși principalele avantaje ale rețelelor peer-to-peer includ, în primul rând, ușurința instalării, există o serie de alte avantaje:

1) de obicei, tot software-ul necesar este deja inclus în sistemul de operare;

2) nu este necesar administrarea sistemului, iar utilizatorii individuali pot gestiona singuri resursele;

3) nodurile de rețea nu depind de server, prin urmare, pot funcționa chiar și atunci când alte noduri nu sunt disponibile.

Cu toate acestea, într-o astfel de rețea, numărul de computere este strict definit - nu mai mult de zece. Distribuirea resurselor într-o rețea cu un număr mare de noduri va face dificilă accesarea fișierelor, fiecare dintre acestea putând fi protejat propria ta parolă. În plus, protecția centralizată este imposibilă aici, singura protecție posibilă este protecția la nivel de resurse. În general, există o creștere a încărcăturii pe computere din cauza partajării resurselor.

Rețelele cu un server (sau servere) dedicate (rețele bazate pe server) pot fi foarte mari și oferă utilizatorilor o gamă mai largă de resurse în comparație cu rețelele peer-to-peer. Acest lucru se datorează, în primul rând, faptului că o astfel de rețea are diverse servere specializate.

În plus, aceste rețele permit gestionarea centralizată a resurselor și adăugarea de noi computere, utilizatori și resurse în rețea. Astfel de rețele sunt scalabile, adică se pot extinde cu ușurință.

Singura cerință pentru o astfel de rețea este prezența unui computer care rulează sistemul de operare în rețea, un astfel de computer se numește server.

La fel ca o rețea peer-to-peer, rețelele de servere dedicate au avantajele și dezavantajele lor. În primul rând, să enumerăm avantajele:

1) pentru a avea acces la resursele rețelei, utilizatorul introduce un singur nume de înregistrare și o parolă;

2) securitatea rețelei și resursele rețelei sunt gestionate central;

3) locația centralizată vă permite să faceți copii de siguranță ale directoarelor și fișierelor;

4) serverele specializate oferă acces rapid la resurse;

5) astfel de rețele pot fi extinse.

Acum să remarcăm o serie de dezavantaje:

1) este necesară configurarea și gestionarea resurselor din rețea, adică este necesar un administrator de sistem;

2) dacă serverul principal eșuează, accesul la resursele rețelei este întrerupt;

3) din punct de vedere economic, rețelele cu server dedicat sunt benefice doar pentru companii destul de mari.

Astfel, în funcție de modul în care funcțiile sunt distribuite între computerele din rețea, acestea pot acționa în trei roluri diferite:

1) un computer cu rol de server de rețea dedicat, adică deservește doar cereri de la alte calculatoare;

2) un computer care face o cerere către resursele unei alte mașini este un nod client;

3) un computer care combină funcțiile unui client și ale unui server este un nod peer-to-peer.

Prin urmare, se pot defini diferite scheme de proiectare a rețelei ca:

1) rețea peer-to-peer – o rețea bazată pe noduri peer-to-peer;

2) rețea cu un server dedicat – o rețea bazată pe clienți și servere.

Cu toate acestea, o rețea poate include toate tipurile de noduri - o rețea hibridă, care este uneori denumită rețea de server dedicat.

Sistemele de operare client din rețelele cu un server dedicat sunt de obicei eliberate de funcțiile serverului, ceea ce simplifică foarte mult organizarea acestora. Dezvoltatorii unor astfel de sisteme de operare se concentrează pe interfața cu utilizatorulși părțile client ale serviciilor de rețea. În același timp, serverele folosesc versiuni speciale ale sistemelor de operare de rețea care sunt optimizate pentru a funcționa ca server și sunt numite sisteme de operare pentru server.

Specializarea unui sistem de operare pentru a acționa ca server este o modalitate naturală de a îmbunătăți eficiența operațiunilor serverului, deoarece intensitatea solicitărilor de resurse partajate poate fi foarte mare și serverul trebuie să facă față acesteia fără întârzieri mari. Cu cât sistemul de operare îndeplinește mai puține funcții, cu atât pot fi implementate mai eficient.

Pentru a optimiza performanța serviciilor, dezvoltatorii NetWare au exclus complet multe elemente ale sistemului de operare universal din sistem, lăsând exclusiv elemente de rețea. Cu toate acestea, multe companii care dezvoltă sisteme de operare în rețea produc două versiuni de sisteme de operare bazate pe același cod de bază, dar cu un set diferit de servicii și utilități - sisteme de operare server și client.

Diverse servicii de rețea pot fi găzduite pe mai multe servere specializate, iar serverul central nu numai că permite utilizatorului să intre în rețea, ci determină și la ce resurse va avea acces utilizatorul.

Să ne uităm la principalele servere specializate.

Serverele de fișiere sunt folosite pentru a stoca fișierele necesare utilizatorilor rețelei. Serverele de imprimare sunt folosite pentru a gestiona o imprimantă de rețea, în esență un canal de control pentru comunicarea cu imprimanta.

Un server de comunicații folosește un software special care permite utilizatorilor să comunice online. Susține servicii E-mailși teleconferințe. Serverul de aplicații găzduiește diverse aplicații, iar serverul vă permite să creați un site web, deși puteți folosi serviciile unui furnizor pentru a găzdui site-ul.

Unele tipuri de servere sunt folosite nu pentru a obține acces la resurse, ci pentru a îmbunătăți calitatea și eficiența rețelei. De exemplu, server DNS (Serviciul de nume de domeniu) - serviciul de nume de domeniu rezolvă numele prietenoase în adrese corespunzătoare.

Acum să ne uităm la interacțiunea dintre client și sistemul de operare server mai detaliat. Când un computer accesează un fișier de pe o unitate locală sau o imprimantă conectată direct, solicitarea este trimisă procesorului computerului. Procesorul execută cererea și toate operațiunile sunt efectuate local. Când accesați partajări pe un server de fișiere sau imprimați pe o imprimantă de la distanță, software-ul client de rețea va efectua o operație specială care face ca computerul să considere partajările de rețea ca fiind locale.

Acest proces este realizat de componenta client software, care se numește redirector (REDIRECTOR). Interceptează orice solicitări făcute pe computer și, în funcție de tipul cererii, o transmite unui server de rețea pentru procesare sau stabilește că cererea va fi executată local.

1.2. Suport pentru rețele bazate pe OSWindows2000. NiveluriOSIși componentele rețelei OSWindows2000. ReţeaAPI

Să ne uităm la mecanismele de construire a unui sistem de operare în rețea folosind Windows 2000 ca exemplu.

Referinţă modelOSI (Modelul de referință OSI)

Pentru a ajuta furnizorii să standardizeze și să integreze software-ul de rețea, în 1974, Organizația Internațională pentru Standardizare (ISO) a definit un model de software pentru trimiterea de mesaje între computere. Rezultatul a fost modelul de referință OSI (Open Systems Interconnection). Modelul definește șapte niveluri de software (Fig. 1).

DIV_ADBLOCK314">

Liniile punctate din figură arată protocoalele utilizate pentru a transmite cererea către mașina de la distanță. Fiecare strat de rețea crede că comunică cu un strat echivalent pe o altă mașină care utilizează același protocol. Setul de protocoale care trec cereri peste nivelurile de rețea se numește stivă de protocoale.

Reţea ComponenteWindows 2000 (componente de rețea)

În fig. 2 prezentate schema generala protocoale de rețea Windows 2000, corespondența lor cu straturile modelului de referință și protocoalele utilizate de diferitele straturi. După cum puteți vedea, nu există o corespondență exactă între nivelurile modelului și componentele rețelei. Unele componente se întind pe mai multe niveluri. Mai jos este o listă și o scurtă descriere:

1) API-urile de rețea asigură interacțiunea independentă de protocol a aplicațiilor prin rețea. API-urile de rețea sunt implementate fie în modul kernel și modul utilizator, fie numai în modul utilizator. Unele API-uri de rețea înglobează alte API-uri și implementează un model de programare specific sau oferă servicii suplimentare. (Termenul API de rețea se referă la orice interfețe de programare expuse de software-ul de rețea);

2) Clienți TDI (Transport Driver Interface). Drivere de dispozitiv în modul kernel, care implementează de obicei porțiunea API-ului de rețea care rulează în modul kernel. Clienții TDI sunt denumiți astfel deoarece pachetele de solicitare I/O (IRP) pe care le trimit driverelor de protocol Windows 2000 sunt formatate folosind standardul de interfață a driverului de transport (documentat în DDK). Acest standard definește o interfață de programare comună pentru driverele de dispozitiv în modul kernel;

3) Transporturi TDI. Sunt drivere de protocol în modul kernel și sunt adesea numite transporturi (Network Driver Interface Specification), drivere de protocol NDIS sau drivere de protocol. Acceptă IRP-uri de la clienții TDI și procesează cererile transmise de acele IRP-uri. Procesarea cererilor poate necesita comunicarea prin rețea cu alte computere egale, caz în care transportul TDI adaugă antete specifice protocolului (TCP, UDP, IPX) la datele IRP și comunică cu driverele adaptoarelor prin funcții NDIS (de asemenea, documentate în DDK) . În general, transporturile TDI conectează aplicațiile printr-o rețea prin efectuarea de operațiuni precum segmentarea mesajelor, recuperarea mesajelor, comandarea, confirmarea și retransmiterea;

4) Biblioteca NDIS (Ndis.sys). Încapsulează funcționalitatea driverelor de adaptoare, ascunzând de acestea specificul mediului Windows 2000 care rulează în modul kernel. Biblioteca NDIS exportă funcții pentru transporturi TDI, precum și funcții de suport pentru driverele adaptoarelor;

5) miniport – drivere NDIS. Drivere pentru modul Kernel, responsabile cu organizarea interfețelor între transporturile TDI și adaptoarele de rețea specifice. Driverele de miniport NDIS sunt scrise pentru a fi incluse în biblioteca Windows 2000 NDIS. Această încapsulare oferă compatibilitate multiplatformă cu versiunile pentru consumatori de Windows. Driverele de miniport NDIS nu se ocupă de proces IRP; și înregistrați o interfață la tabelul de apeluri al bibliotecii NDIS, care conține pointeri către funcții corespunzătoare funcțiilor exportate de biblioteca NDIS pentru transporturi TDI. Driverele de miniport NDIS interacționează cu adaptoarele de rețea folosind funcții de bibliotecă NDIS care apelează funcțiile corespunzătoare (HAL).

Notă: Managerul I/O definește modelul pentru livrarea cererilor I/O către driverele de dispozitiv. Majoritatea cererilor I/O sunt reprezentate de pachete de solicitare I/O (IRP) trimise de la o componentă a subsistemului I/O la alta. Un IRP este o structură de date care conține informații care descriu complet o solicitare I/O.

De fapt, cele patru straturi inferioare de rețea sunt adesea denumite în mod colectiv transport, iar componentele situate în primele trei straturi sunt adesea denumite utilizatori de transport.

DIV_ADBLOCK317">

Protocolul SMB este un protocol de nivel de aplicație care include un strat de rețea și un strat de prezentare.

IMM-urile implementează:

1) stabilirea unei sesiuni;

2) serviciul de fișiere;

3) serviciu de imprimare;

4) serviciu de mesaje.

CIFS este un standard Microsoft deschis (documentat în Platform SDK) care permite altor platforme să interopereze cu serverul de fișiere Windows 2000 și clientul de fișiere Windows 2000. De exemplu, Samba permite sistemelor UNIX să acționeze ca un server de fișiere pentru un client Windows 2000 și aplicațiilor UNIX să acceseze fișierele stocate pe sisteme care rulează sisteme Windows 2000. Alte platforme care acceptă CIFS includ DEC VMS și Apple Macintosh.

Partajarea fișierelor în Windows 2000 se bazează pe un redirector (redirector FSD pe scurt) care rulează pe computerul client și comunică cu redirectorul FSD al serverului. FSD interceptează cererile de I/O ale fișierelor Win32 direcționate către fișierele aflate pe server și transmite mesaje CIFS sistemului de fișiere al serverului. Serverul primește mesaje CIFS și le convertește înapoi în solicitări I/O, pe care le emite FSD-urilor locale, cum ar fi NTFS.

Deoarece sunt integrate cu subsistemul de intrare/ieșire Windows 2000 (sistem I/O), FSD-urile de redirector și server au mai multe avantaje față de implementările alternative ale serverului de fișiere:

1) pot interacționa direct cu transporturile TDI și FSD-urile locale;

2) se integrează perfect cu managerul de cache, care permite ca datele de pe serverul de fișiere să fie stocate în cache pe sistemele client.

Aplicațiile pot folosi funcții standard de I/O pentru fișiere Win32, cum ar fi CreateFile, ReadFile și WriteFile pentru a accesa fișierele de la distanță.

În Windows 2000, serverul de redirecționare FSD utilizează convențiile standard de denumire a resurselor de rețea utilizate de toate serverele de fișiere și de programele client în modul kernel. Dacă o conexiune la o resursă de rețea se realizează prin literă de unitate, numele fișierelor de rețea sunt, de asemenea, indicate ca fiind locale. Cu toate acestea, redirector acceptă și nume UNC

Atât serverul FSD, cât și redirectorul au servicii Win32, Server și Workstation, care rulează în procesul de management de control al serviciului (SCM) și furnizează șoferilor interfețe de control administrativ.

Notă:

Puteți implementa o aplicație server într-un mod simplu program executabil, dar puteți folosi un tip special - serviciu (serviciu). Un serviciu este o aplicație care conține infrastructură suplimentară care permite SCM să gestioneze aceste aplicații. Toate aplicații server, furnizat împreună cu sistemul, rulează ca servicii.

Interfață pentru șofer de transport (TDI)

Arhitectură de rețea deschisă Instrumente Windows NT permite stațiilor sale de lucru (și serverelor) să funcționeze pe rețele eterogene nu numai oferind capacitatea de a încărca și descărca în mod dinamic instrumente de rețea, ci și prin trecerea directă de la instrumente de rețea bazate pe software concepute pentru a interacționa cu un tip de rețea la instrumente software pentru alt tip de rețea în timpul funcționării sistemului. Windows NT acceptă comutarea software-ului la trei niveluri:

1) la nivel de redirector - fiecare redirector este proiectat pentru propriul protocol (SMP, NCP, NFS, VINES);

2) la nivelul driverelor de protocol de transport, oferind o interfață TDI standard pentru aceștia și pentru redirectori;

3) la nivelul driverului adaptorului de rețea - cu o interfață standard NDIS 3.0.

Pentru a accesa alte tipuri de rețele în Windows NT, pe lângă cea încorporată, pot fi încărcate redirectoare suplimentare. Componentele speciale Windows NT decid ce redirector ar trebui apelat pentru a deservi o solicitare de I/O la distanță. În ultimele decenii, s-au răspândit diverse protocoale de transmitere a informațiilor prin rețea. Și, deși Windows NT nu acceptă toate aceste protocoale, cel puțin vă permite să activați suportul pentru ele.

Odată ce o solicitare de rețea ajunge la redirector, aceasta trebuie redirecționată către rețea. Într-un sistem tradițional, fiecare redirector este strâns cuplat la un protocol de transport specific. Windows NT este însărcinat cu conectarea flexibilă a unuia sau altuia protocol de transport, în funcție de tipul de transport utilizat în altă rețea. Pentru a face acest lucru, în toate redirectoarele, nivelul inferior trebuie scris în conformitate cu anumite acorduri, care determină un singur interfata software, numit interfață pentru șofer de transport(TDI).

TDI permite redirectorilor să rămână independenți de transport. Astfel, o versiune a redirectorului poate folosi orice mecanism de transport. TDI oferă un set de funcții pe care redirectorii le pot folosi pentru a transmite orice tip de date folosind stratul de transport. TDI acceptă atât comunicații orientate spre conexiune ( conexiuni virtuale), și comunicații fără conexiune (comunicații cu datagramă). Deși LAN Manager utilizează comunicații orientate spre conexiune, Novell IPX este un exemplu de rețea care utilizează comunicații fără conexiune. Microsoft furnizează în mod nativ transporturile - NetBEUI (NetBIOS Extended User Interface), TCP/IP, IPX/SPX, DECnet și AppleTalk.

Pe baza celor de mai sus, prezentăm următoarele concluzii.

ȘI interfață pentru șofer de transport(TDI) este o interfață comună care permite componentelor precum redirectorul și serverul să comunice cu diferite transporturi de rețea, adică să rămână independente de transport. Rețineți că (TDI) nu este un driver, ci un standard pentru transmiterea mesajelor între straturile unei arhitecturi de rețea. Microsoft a definit standardul TDI astfel încât driverele de protocol de rețea nu trebuie să utilizeze interfețe separate pentru fiecare protocol de transport de care au nevoie.

După cum sa spus deja, Interfață pentru șofer de transport(TDI) reprezintă în esență regulile pentru formarea cererilor de rețea în IRP-uri, precum și alocarea adreselor de rețea și a conexiunilor de comunicație. Protocoalele de transport care sunt conforme cu acest standard exportă interfața TDI către clienții lor, care includ drivere API de rețea și redirector. Protocolul de transport implementat ca driver de dispozitiv se numește transporturi TDI și, deoarece sunt drivere, ele convertesc cererile primite de la clienți în IRP-uri. Interfață pentru șofer de transport(Funcțiile de suport pentru formulare TDI din biblioteca \winnt\system32\drivers\tdi.sys.

BibliotecăNDIS (Ndis. sys)

Să introducem și conceptul de strat limită. O graniță este o interfață unificată între straturile funcționale într-un model de arhitectură de rețea. Crearea granițelor ca partiții între straturile de rețea facilitează dezvoltarea de drivere și servicii de rețea pentru terți într-un mediu de sistem deschis.

Adaptoarele de rețea vin cu drivere de rețea, care în trecut erau adesea concepute pentru a comunica cu un anumit tip de protocol de transport. Deoarece Windows NT vă permite să încărcați drivere pentru diferite protocoale de transport, producătorii de adaptoare de rețea care utilizează această abordare au trebuit să scrie versiuni diferite ale aceluiași driver pentru a comunica cu diferite protocoale de nivel de transport.

Pentru a ajuta producătorii să evite acest lucru, Windows NT oferă o interfață și un mediu software numit „ specificația interfeței driverului de rețea" (NDIS), care protejează driverele de rețea de detaliile diferitelor protocoale de transport. Stratul superior al driverului adaptorului de rețea trebuie scris conform recomandărilor NDIS. În acest caz, utilizatorul poate lucra cu o rețea TCP/IP și un Rețeaua NetBEUI (sau DECnet, NetWare, VINES etc.) folosind un adaptor de rețea și un driver de rețea. Mediul NDIS a fost utilizat în. rețele LAN Manager, dar a fost actualizat pentru Windows NT.

Prin limita sa inferioară, un driver de adaptor de rețea comunică de obicei direct cu adaptorul sau adaptoarele pe care le deservește. Driverul adaptorului de rețea implementat pentru mediul NDIS nu controlează direct adaptorul, dar utilizează funcțiile furnizate de NDIS pentru a face acest lucru (de exemplu, pentru a declanșa I/O sau pentru a gestiona întreruperi). Astfel, mediul NDIS formează un fel de shell care face destul de ușor transferul driverelor adaptoarelor de rețea de la un sistem de operare la altul. NDIS permite driverelor de rețea să nu aibă cunoștințe încorporate despre procesorul sau sistemul de operare pe care rulează.

Securitatea rețelei și structura domeniului

Securitatea rețelei înseamnă protejarea tuturor componentelor hardware, a software-ului și a datelor stocate împotriva distrugerii, furtului și utilizării neautorizate. Plan de sprijin bine gândit și bine construit Securitatea calculatorului, care asigură o monitorizare bună, facilitează controlul utilizării computerelor din rețea, elimină practic distrugerea accidentală sau coruperea datelor și face imposibilă sau extrem de dificilă utilizarea neautorizată a resurselor.

Microsoft a inclus cerințe de securitate ca parte a specificației inițiale pentru dezvoltarea Windows NT. Problemele de securitate în Windows NT sunt de o importanță capitală. Modelul de securitate include componente pentru a controla accesul la obiecte (cum ar fi fișiere și imprimante partajate). Aceste componente definesc cine poate accesa ce obiecte, ce acțiune poate fi efectuată asupra obiectului (de exemplu, scrierea într-un fișier etc.) și ce evenimente sunt auditabile.

Securitatea rețelei Windows NT include relații de încredere între domenii, ceea ce face ca acest sistem de operare să fie cel mai bine protejat.

Arhitectura modelului de securitate

În fig. 3 prezintă componentele modelului securitate Windows NT, care includ:

1) Procesele de conectare, care primesc cereri de conectare de la utilizatori. Acestea includ conectarea interactivă, care se face folosind caseta de dialog inițială de conectare și procesele de conectare la distanță, care oferă utilizatorilor de la distanță acces la procesele serverului Windows NT;

2) serviciul local de securitate (Local Security Authority, LSA), care asigură că utilizatorul are dreptul de acces la sistem. Această componentă este centrul subsistemului de securitate Windows NT. Acesta generează jetoane de acces, gestionează politica de securitate locală și oferă autentificare interactivă a utilizatorilor. În plus, LSA controlează politica de audit și înregistrează înregistrările de audit generate de monitorul de securitate;

3) Security Account Manager (SAM), care menține o bază de date de conturi de utilizator, cunoscută și ca bază de date director. Această bază de date conține informații pentru toate conturile de utilizator și de grup. SAM oferă serviciul de verificare a utilizatorilor care este utilizat de LSA;

4) Security Reference Monitor, care verifică dacă utilizatorul are permisiunea de a accesa obiectul și dreptul la operațiunea pe care încearcă să o efectueze. Această componentă impune verificări ale nivelului de acces și aplică politica de audit definită de LSA. Acesta oferă un serviciu în modul kernel și în modul utilizator care verifică dacă toți utilizatorii și procesele care încearcă să acceseze un obiect au nivelul necesar de acces. Dacă este necesar, această componentă generează și intrări în fișierul de audit.

În mod colectiv, toate aceste componente sunt cunoscute și ca subsistemul de securitate. Acest subsistem, numit subsistem integral, nu este un subsistem de mediu deoarece se întinde pe întregul sistem de operare Windows NT.

Cand vine vorba de retele de calculatoare, puteți auzi adesea menționat NFS. Ce înseamnă această abreviere?

Este un protocol de sistem de fișiere distribuit dezvoltat inițial de Sun Microsystems în 1984, care permite unui utilizator de pe un computer client să acceseze fișiere printr-o rețea, similar cu accesarea stocării locale. NFS, ca multe alte protocoale, se bazează pe sistemul Open Network Computing Remote Procedure Call (ONC RPC).

Cu alte cuvinte, ce este NFS? Este un standard deschis, definit de Request for Comments (RFC), care permite oricui să implementeze protocolul.

Versiuni și variante

Inventatorul a folosit doar prima versiune pentru propriile sale scopuri experimentale. Când echipa de dezvoltare a adăugat modificări semnificative la NFS original și l-a lansat în afara autorului lui Sun, au desemnat noua versiune ca v2, astfel încât să poată testa interoperabilitatea între distribuții și să creeze o soluție alternativă.

NFS v2

Versiunea 2 a funcționat inițial numai pe protocolul User Datagram Protocol (UDP). Dezvoltatorii săi au dorit să păstreze partea de server fără blocare implementată în afara protocolului principal.

Interfața sistemului de fișiere virtual permite o implementare modulară reflectată într-un protocol simplu. Până în februarie 1986, soluțiile au fost demonstrate pentru sisteme de operare precum System V versiunea 2, DOS și VAX/VMS folosind Eunice. NFS v2 a permis doar citirea primilor 2 GB dintr-un fișier din cauza limitărilor de 32 de biți.

NFS v3

Prima propunere de dezvoltare a NFS versiunea 3 la Sun Microsystems a fost anunțată la scurt timp după lansarea celei de-a doua distribuții. Motivația principală a fost încercarea de a atenua problema performanței înregistrării sincrone. Până în iulie 1992, îmbunătățirile practice au rezolvat multe dintre deficiențele NFS versiunea 2, lăsând doar suport insuficient pentru fișiere (dimensiuni de fișiere pe 64 de biți și decalaje ale fișierelor).

• suport pentru dimensiuni de fișiere de 64 de biți și decalaje pentru a gestiona date mai mari de 2 gigaocteți (GB);
• suport pentru înregistrarea asincronă pe server pentru a îmbunătăți performanța;
• atribute de fișiere suplimentare în multe răspunsuri pentru a evita să fie nevoie să le preluăm din nou;
• Operațiune READDIRPLUS pentru a obține date și atribute împreună cu numele fișierelor la scanarea unui director;
• multe alte îmbunătățiri.

În timpul introducerii versiunii 3, suportul pentru TCP ca protocol de nivel de transport a început să crească. Utilizarea TCP ca mijloc de transfer de date, efectuată folosind NFS pe un WAN, a început să permită transferul de fișiere de dimensiuni mari pentru vizualizare și scriere. Datorită acestui fapt, dezvoltatorii au reușit să depășească limitele de 8 KB impuse de User Datagram Protocol (UDP).

Ce este NFS v4?

Versiunea 4, influențată de Endres File System (AFS) și Server Message Block (SMB, numită și CIFS), include îmbunătățiri ale performanței, oferă o securitate mai bună și introduce un protocol de conformitate.

Versiunea 4 a fost prima distribuție dezvoltată de Internet Engineering Task Force (IETF) după ce Sun Microsystems a externalizat dezvoltarea protocoalelor.

Versiunea NFS 4.1 urmărește să ofere suport pentru protocol pentru valorificarea implementărilor de servere în cluster, inclusiv capacitatea de a oferi acces paralel scalabil la fișierele distribuite pe mai multe servere (extensia pNFS).

Cel mai nou protocol de sistem de fișiere, NFS 4.2 (RFC 7862), a fost lansat oficial în noiembrie 2016.

Alte extensii

Odată cu dezvoltarea standardului, au apărut instrumente corespunzătoare pentru lucrul cu acesta. Astfel, WebNFS, o extensie pentru versiunile 2 și 3, permite protocolul acces la retea Sistemele de fișiere sunt mai ușor de integrat în browserele web și permit lucrul prin firewall-uri.

Diverse protocoale terțe au devenit, de asemenea, asociate cu NFS. Cele mai cunoscute dintre ele sunt:

• Network Lock Manager (NLM) cu suport pentru protocolul de octeți (adaugat pentru a suporta API-ul de blocare a fișierelor UNIX System V);
• Remote Quota (RQUOTAD), care permite utilizatorilor NFS să vadă cotele de stocare pe serverele NFS;
• NFS over RDMA este o adaptare a NFS care utilizează accesul direct la memorie la distanță (RDMA) ca mediu de transmisie;
• NFS-Ganesha este un server NFS care rulează în spațiul utilizatorului și acceptă CephFS FSAL (File System Abstraction Layer) folosind libcephfs.

Platforme

Network File System este adesea folosit cu sisteme de operare Unix (cum ar fi Solaris, AIX, HP-UX), MacOS Apple și sisteme de operare asemănătoare Unix (cum ar fi Linux și FreeBSD).

Este disponibil și pentru platforme precum Acorn RISC OS, OpenVMS, MS-DOS, Microsoft Windows, Novell NetWare și IBM AS/400.

Protocoalele alternative de acces la fișiere de la distanță includ Server Message Block (SMB, numit și CIFS), Apple Transfer Protocol (AFP), NetWare Core Protocol (NCP) și OS/400 Server File System (QFileSvr.400).

Acest lucru se datorează cerințelor NFS, care vizează mai ales „shell-uri” asemănătoare Unix.

Cu toate acestea, protocoalele SMB și NetWare (NCP) sunt utilizate mai des decât NFS pe sistemele care rulează Microsoft Windows. AFP este cel mai frecvent pe platformele Apple Macintosh, iar QFileSvr.400 este cel mai frecvent pe OS/400.

Implementare tipică

Presupunând un scenariu tipic în stil Unix în care un computer (clientul) are nevoie de acces la datele stocate pe altul (serverul NFS):

• Serverul implementează procese Network File System, care rulează implicit ca nfsd, pentru a-și face datele disponibile public pentru clienți. Administratorul serverului determină cum să exporte numele directorului și setările, utilizând de obicei fișierul de configurare /etc/exports și comanda exportfs.
• Administrarea securității serverului asigură că acesta poate recunoaște și aproba un client autentificat. Configurația sa de rețea asigură că clienții eligibili pot negocia cu acesta prin orice sistem firewall.
• Mașina client solicită acces la datele exportate, de obicei prin lansarea unei comenzi. Interogează serverul (rpcbind) care utilizează portul NFS și ulterior se conectează la acesta.
• Dacă totul se întâmplă fără erori, utilizatorii de pe computerul client vor putea să vadă și să interacționeze cu sistemele de fișiere instalate pe server în limitele parametrilor permisi.

De asemenea, trebuie remarcat faptul că automatizarea procesului Network File System poate avea loc - poate folosind etc/fstab și/sau alte instrumente similare.

Dezvoltare până în prezent

Până în secolul 21, protocoalele concurente DFS și AFS nu au obținut niciun succes comercial major în comparație cu sistemul de fișiere în rețea. IBM, care a achiziționat anterior toate drepturile comerciale asupra tehnologiilor de mai sus, a donat majoritatea codului sursă AFS comunității de software liber în 2000. Proiectul Open AFS există și astăzi. La începutul anului 2005, IBM a anunțat încheierea vânzărilor AFS și DFS.

La rândul său, în ianuarie 2010, Panasas a propus NFS v 4.1 bazat pe tehnologie care îmbunătățește capabilitățile de acces la date paralele. Protocolul Network File System v 4.1 definește o metodă pentru separarea metadatelor sistemului de fișiere de locația anumitor fișiere. Deci, depășește simpla separare nume/date.

Ce este NFS al acestei versiuni în practică? Caracteristica de mai sus o deosebește de protocolul tradițional, care conține numele fișierelor și datele lor sub o singură conexiune la server. Cu Network File System v 4.1, unele fișiere pot fi partajate pe servere cu mai multe noduri, dar implicarea clientului în partajarea metadatelor și a datelor este limitată.

La implementarea celei de-a patra distribuții a protocolului, serverul NFS este un set de resurse sau componente de server; se presupune că acestea sunt controlate de serverul de metadate.

Clientul încă contactează un singur server de metadate pentru a traversa sau a interacționa cu spațiul de nume. Pe măsură ce mută fișierele către și de la server, poate interacționa direct cu un set de date deținut de un grup NFS.

Capitolul 29 NFS: Sistemul de fișiere în rețea

Introducere

În acest capitol, ne vom uita la Network File System (NFS), o aplicație populară care oferă aplicațiilor client acces transparent la fișiere. Piatra de temelie a NFS este Sun RPC: Remote Procedure Call, pe care o vom trata mai întâi.

Programul client nu necesită instrumente speciale pentru a profita de NFS. Nucleul detectează că fișierul se află pe un server NFS și generează automat un apel RPC pentru a accesa fișierul.

Nu ne vom uita în detaliu la modul în care este implementat accesul la fișiere, ci vom analiza modul în care sunt utilizate protocoalele de Internet, în special UDP.

Sun Remote Procedure Call

În cele mai multe cazuri, problemele de programare a rețelei sunt rezolvate prin scrierea unor programe de aplicație care apelează funcții furnizate de sistem pentru a efectua operațiuni specifice de rețea. De exemplu, o funcție realizează o deschidere TCP activă, alta deschidere TCP pasivă, o a treia trimite date printr-o conexiune TCP, a patra setează opțiuni specifice de protocol (activează cronometrul TCP „stay alive”) și așa mai departe. În secțiunea Interfețe de programare a aplicațiilor din capitolul 1, am menționat că există două seturi populare de funcții pentru programare în rețea(interfață de programare a aplicațiilor, API), acestea sunt socket-uri și TLI. API-ul utilizat de client și API-ul utilizat de server pot diferi, la fel ca și sistemele de operare pe care le rulează clientul și serverul. Protocoalele de comunicare și de aplicație determină dacă un anumit client poate comunica cu serverul. Un client Unix scris în C folosind socket-uri ca interfață de programare și TCP ca protocol de comunicare poate comunica cu un server mainframe scris în COBOL folosind diferite API și TCP dacă ambele gazde sunt conectate la rețea și ambele au o implementare TCP.

De obicei, clientul trimite comenzi către server, iar serverul trimite răspunsuri către client. Toate aplicațiile pe care le-am analizat - Ping, Traceroute, demoni de rutare, clienți și servere DNS, TFTP, BOOTP, SNMP, Telnet, FTP, SMTP - sunt toate construite astfel.

RPC, apel de procedură la distanță, implementează o abordare diferită a programării rețelei. Programul client apelează pur și simplu funcții în programul server. Deci acest lucru este decis din punctul de vedere al programatorului, dar în realitate are loc următoarea secvență de acțiuni.

1. Când un client apelează o procedură la distanță, este apelată o funcție de pe gazda locală care este generată de pachetul RPC. Această funcție se numește client stub. client stub împachetează argumentele procedurii într-un mesaj de rețea și trimite mesajul către server.
2. server stub de pe serverul gazdă primește mesajul de rețea. Argumentele sunt preluate din mesajul de rețea și se efectuează un apel către procedura de server scrisă de programatorul aplicației.
3. Funcția de server returnează controlul stub-ului de server, care la rândul său preia valorile primite, le împachetează într-un mesaj de rețea și trimite mesajul înapoi către stub-ul clientului.
4. client stub returnează valori dintr-un mesaj de rețea către aplicația client.

Programarea în rețea care utilizează rutinele RPC de bibliotecă și stub utilizează API-uri (socket-uri sau TLI), dar aplicațiile utilizator (programul client și procedurile server numite de client) nu accesează niciodată API-ul. Aplicația client trebuie doar să apeleze procedura serverului, în timp ce toate detaliile de implementare sunt ascunse de pachetul RPC, client stub și server stub.

Pachetele RPC au următoarele avantaje.

• Programarea devine mai ușoară pentru că nu trebuie să rezolvi problemele de programare în rețea (și dacă o faci, este foarte puțin). Programatorii de aplicații scriu pur și simplu programul client și procedurile de server pe care clientul le apelează.
• Dacă se folosește un protocol nesigur precum UDP, toate detaliile, și anume timeout-uri și retransmisii, sunt gestionate de pachetul RPC. Acest lucru, la rândul său, simplifică aplicația utilizatorului.
• Biblioteca RPC se ocupă de conversia necesară a argumentelor și a valorilor returnate. De exemplu, dacă argumentele constau din numere întregi și numere în virgulă mobilă, pachetul RPC va gestiona orice diferență între reprezentarea numerelor întregi și a numerelor în virgulă mobilă pe client și pe server. Acest lucru simplifică implementarea clienților și serverelor pentru a opera în medii eterogene.

Programarea RPC este tratată în detaliu în Capitolul 18. Cele mai populare două pachete RPC sunt Sun RPC și pachetul RPC din DCE (Distributed Computing Environment) al Open Software Foundation (OSF). la pachetul Sun RPC, deoarece acest pachet este utilizat în Sun RPC Versiunea 2, care este descris în RFC 1057 [Sun Microsystems 1988a].

Există două tipuri de Sun RPC. O versiune este construită folosind API-ul sockets și funcționează cu TCP și UDP. Celălalt se numește TI-RPC (independent de transport), construit folosind API-ul TLI și funcționează cu orice nivel de transport furnizat de kernel. Din punctul nostru de vedere, nu există nicio diferență între ele, deoarece în acest capitol luăm în considerare doar TCP și UDP.

Figura 29.1 prezintă formatul mesajului de apel de procedură RPC, cu folosind UDP.

Figura 29.1 Mesaje de apel de procedură RPC în format de datagramă UDP.

Antetele standard IP și UDP sunt prezentate mai devreme (Figura 3.1 și Figura 11.2). Tot ceea ce urmează antetul UDP este determinat de pachetul RPC.

Identificatorul tranzacției (XID - ID tranzacție) este setat de client și returnat de server. Când clientul primește un răspuns, compară XID-ul returnat de server cu XID-ul cererii trimise. Dacă nu se potrivesc, clientul renunță la mesaj și așteaptă să sosească următorul. De fiecare dată când clientul emite un nou RPC, acesta schimbă XID-ul. Cu toate acestea, dacă clientul retransmite RPC (dacă nu a fost primit niciun răspuns), XID-ul nu se modifică.

Variabila de apel este 0 pentru un apel și 1 pentru un răspuns. Versiune curentă Versiunea RPC este 2. Următoarele trei variabile, numărul programului, numărul versiunii și numărul procedurii, identifică procedura specifică care trebuie apelată pe server.

Acreditările identifică clientul. În unele exemple acest câmp este lăsat necompletat, în timp ce în altele puteți vedea identificatorul digital al utilizatorului și identificatorul de grup din care face parte. Serverul poate analiza acreditările și poate decide dacă procesează cererea sau nu. Verifier este utilizat pentru Secure RPC, care utilizează criptarea DES. Chiar dacă câmpurile de autorizare și validare sunt câmpuri de lungime variabilă, lungimea lor este trecută ca parte a câmpului.

Urmează parametrii procedurii. Formatul lor depinde de modul în care aplicația definește procedura de la distanță. Cum știe receptorul (server stub) dimensiunea parametrilor? Deoarece este utilizat UDP, dimensiunea parametrilor poate fi calculată ca dimensiunea datagramei UDP minus lungimea tuturor câmpurilor până la câmpul de verificare. Când se folosește TCP în loc de UDP, nu există conceptul de lungime fixă, deoarece TCP este un flux de octeți fără delimitatori de înregistrare. Într-un astfel de caz, între antetul TCP și XID apare un câmp de lungime de 4 octeți, de la care receptorul învață lungimea apelului RPC în octeți. Acest lucru permite ca mesajul de apel RPC să fie trimis pe mai multe segmente TCP, dacă este necesar. (DNS folosește o tehnică similară; Exercițiul 4 din capitolul 14.)

Figura 29.2 prezintă formatul de răspuns RPC. Este trimis de la stub-ul serverului către stub-ul client atunci când procedura de la distanță iese.

Figura 29.2 Formatul mesajului de răspuns al procedurii RPC ca datagramă UDP.

Apelul XID este pur și simplu copiat în răspunsul XID. Câmpul de răspuns conține 1, acest câmp distinge între o provocare și un răspuns. Câmpul de stare conține o valoare nulă dacă mesajul de apel a fost acceptat. (Mesajul poate fi eliminat dacă numărul versiunii RPC nu este 2 sau dacă serverul nu poate autentifica clientul.) Câmpul de verificare este utilizat în cazul RPC securizat pentru a indica serverul.

Câmpul de stare de acceptare conține o valoare zero dacă totul este bine. O valoare diferită de zero ar putea indica, de exemplu, un număr de versiune incorect sau un număr de procedură incorect. Dacă se folosește TCP în loc de UDP, atunci, ca și în cazul mesajului de provocare RPC, este trimis un câmp de lungime de 4 octeți între antetul TCP și XID.

XDR: Reprezentare externă a datelor

Reprezentarea datelor externe (XDR) este un standard utilizat pentru codificarea valorilor în mesajele de apel și răspuns RPC - câmpurile antet RPC (XID, numărul programului, starea primirii etc.), parametrii procedurii și rezultatele procedurii. Un mod standard de codificare a datelor permite unui client să apeleze o procedură pe un sistem cu o arhitectură diferită. XDR este definit în RFC 1014 [Sun Microsystems 1987].

XDR definește un anumit număr de tipuri de date și modul exact în care acestea sunt transportate într-un mesaj RPC (ordinea biților, ordinea octeților și așa mai departe). Expeditorul trebuie să construiască mesajul RPC în format XDR, apoi destinatarul convertește formatul XDR în reprezentarea originală. (În formatul care este acceptat pentru sistemul său.) Vedem, de exemplu, în figurile 29.1 și 29.2, că toate valorile întregi pe care le-am arătat (XID, apel, număr de program și așa mai departe) sunt numere întregi de 4 octeți . Într-adevăr, toate numerele întregi din XDR ocupă 4 octeți. XDR acceptă alte tipuri de date, inclusiv numere întregi fără semn, boolean, virgulă mobilă, matrice cu lungime fixă, matrice cu lungime variabilă și structuri.

Conformitatea porturilor

Programele server RPC care conțin proceduri de la distanță folosesc porturi alocate dinamic mai degrabă decât porturi precunoscute. Acest lucru necesită o anumită formă de „înregistrare” pentru a ști întotdeauna care port alocat dinamic este utilizat de către ce program RPC. În Sun RPC, acest logger este numit port mapper. (Un port mapper este un server care convertește numerele de program RPC în numere de port de protocol DARPA. Acest server trebuie să ruleze pentru a efectua un apel RPC.)

Termenul „port” din nume provine de la numerele de port TCP și UDP, caracteristici ale familiei de protocoale Internet. Deoarece TI-RPC rulează peste orice nivel de transport, nu doar TCP și UDP, mapperul de nume de port pe sistemele care utilizează TI-RPC (SVR4 și Solaris 2.2, de exemplu) a fost convertit în rpcbind. Cu toate acestea, vom continua să folosim mapatorul de porturi mai familiar.

De fapt, rezolutorul de porturi însuși trebuie să aibă un port cunoscut: portul UDP 111 și portul TCP 111. Rezolvatorul de porturi este doar un program server RPC. Are un număr de program (100000), un număr de versiune (2), portul TCP 111 și portul UDP 111. Serverele se înregistrează reciproc cu rezolutorul de porturi folosind apeluri RPC, iar clienții solicită rezolutorul de porturi folosind apeluri RPC. Soluția de porturi oferă patru proceduri de server:

1. PMAPPROC_SET. Apelat de serverul RPC la pornire pentru a înregistra numărul programului, numărul versiunii și protocolul cu soluția de porturi.
2. PMAPPROC_UNSET. Apelat de server pentru a elimina o transformare înregistrată anterior.
3. PMAPPROC_GETPORT. Apelat de clientul RPC la pornire pentru a obține numărul de port pentru numărul de program, numărul de versiune și protocolul dat.
4. PMAPPROC_DUMP. Returnează toate elementele (numărul programului, numărul versiunii, protocolul și numărul portului) în baza de date de rezoluție de porturi.

Când pornește programul server RPC și mai târziu când este apelat de programul client RPC, au loc următorii pași.

1. Convertorul de porturi ar trebui să pornească mai întâi, de obicei când sistemul pornește. Aceasta creează un punct final TCP și deschide pasiv portul TCP 111. De asemenea, creează un punct final UDP care așteaptă să ajungă o datagramă UDP pe portul UDP 111.
2. Când pornește programul server RPC, acesta creează un punct final TCP și un punct final UDP pentru fiecare versiune acceptată a programului. (Un program RPC poate suporta mai multe versiuni. Clientul specifică versiunea necesară atunci când apelează procedura serverului.) Fiecărui punct final i se atribuie un număr de port alocat dinamic. (Nu are nicio diferență dacă numerele de porturi TCP și UDP sunt aceleași sau diferite.) Serverul înregistrează fiecare program, versiune, protocol și număr de port efectuând un apel de la distanță la procedura de rezolvare a portului PMAPPROC_SET.
3. Când programul client RPC pornește, apelează procedura de rezoluție de porturi PMAPPROC_GETPORT pentru a obține numărul de port alocat dinamic pentru programul, versiunea și protocolul specificat.
4. Clientul trimite un mesaj de provocare RPC la numărul portului obținut la pasul 3. Dacă se folosește UDP, clientul trimite pur și simplu o datagramă UDP care conține mesajul de provocare RPC (Figura 29.1) către numărul portului UDP al serverului. Ca răspuns, serverul trimite o datagramă UDP care conține un mesaj de răspuns RPC (Figura 29.2). Dacă se folosește TCP, clientul face o deschidere activă a numărului de port TCP al serverului și apoi trimite un mesaj de provocare RPC prin conexiune. Serverul răspunde cu un mesaj de răspuns RPC la conexiune.

Programul rpcinfo(8) imprimă toate setările curente ale cartografierii portului. (Aici este apelată rutina de cartografiere de porturi PMAPPROC_DUMP.) Ieșirea tipică este prezentată mai jos:

Soare% /usr/etc/rpcinfo -p
program vers proto port
100005 1 tcp 702 mountd demon de montare NFS
100005 1 udp 699 mountd
100005 2 tcp 702 montat
100005 2 udp 699 mountd

100003 2 udp 2049 nfs NFS propriu-zis

100021 1 tcp 709 nlockmgr Manager de blocare NFS
100021 1 udp 1036 nlockmgr
100021 2 tcp 721 nlockmgr
100021 2 udp 1039 nlockmgr
100021 3 tcp 713 nlockmgr
100021 3 udp 1037 nlockmgr

Vedem că unele programe acceptă mai multe versiuni și fiecare combinație de număr de program, număr de versiune și protocol are propriul aspect al numărului de port, deservit de un rezolutor de porturi.

Ambele versiuni ale demonului de montare pot fi accesate prin același număr de port TCP (702) și același număr de port UDP (699), totuși fiecare versiune a managerului de blocare are propriul număr de port.

Protocolul NFS

NFS oferă clienților acces transparent la fișierele și sistemul de fișiere al serverului. Acesta este diferit de FTP (Capitolul 27), care oferă transfer de fișiere. Folosind FTP, se realizează o copie completă a fișierului. NFS accesează doar acele părți ale fișierului pe care le-a accesat un proces, iar principalul avantaj al NFS este că face acest acces transparent. Aceasta înseamnă că orice aplicație client care poate funcționa cu un fișier local poate funcționa la fel de ușor și cu un fișier NFS, fără nicio modificare a programului în sine.

NFS este o aplicație client-server construită folosind Sun RPC. Clienții NFS accesează fișierele de pe un server NFS trimițând cereri RPC către server. Acest lucru poate fi implementat folosind procese normale ale utilizatorului - și anume, clientul NFS poate fi un proces utilizator care face apeluri RPC specifice către server, care poate fi și un proces utilizator. Cu toate acestea, NFS este de obicei implementat diferit din două motive. În primul rând, accesul la fișierele NFS trebuie să fie transparent pentru client. Prin urmare, apelurile clientului NFS sunt efectuate de sistemul de operare client în numele procesului utilizator al clientului. În al doilea rând, serverele NFS sunt implementate în sistemul de operare pentru a îmbunătăți eficiența serverului. Dacă serverul NFS ar fi un proces utilizator, fiecare cerere client și răspuns de server (inclusiv datele de citit sau scris) ar trebui să treacă printr-un separator între kernel și procesul utilizator, care este în general destul de costisitor.

În această secțiune, ne vom uita la versiunea 2 a NFS așa cum este documentată în RFC 1094 [Sun Microsystems 1988b]. Cea mai bună descriere a Sun RPC, XDR și NFS este dată în [X/Open 1991]. Detalii despre utilizarea și administrarea NFS sunt date în [Stern 1991]. Specificațiile protocolului NFS versiunea 3 au fost implementate în 1993, despre care vom discuta într-o secțiune a acestui capitol.

Figura 29.3 prezintă setările tipice pentru client NFS și server NFS. În această figură, trebuie să acordați atenție la următoarele.

1. Clientului nu îi pasă dacă accesează un fișier local sau un fișier NFS. Nucleul detectează acest lucru atunci când fișierul este deschis. După deschiderea fișierului, nucleul trece tot accesul la fișierele locale în caseta etichetată „acces fișier local”, iar toate linkurile către fișierele NFS sunt transmise casetei „client NFS”.
2. Clientul NFS trimite cereri RPC către serverul NFS prin modulul TCP/IP. NFS utilizează de obicei UDP, însă implementările mai noi pot folosi TCP.
3. Serverul NFS primește cereri de la client ca datagrame UDP pe portul 2049. Deși NFS poate funcționa cu un rezolutor de porturi, care permite serverului să utilizeze porturi alocate dinamic, portul UDP 2049 este codificat în NFS în majoritatea implementărilor.

Figura 29.3 Setări tipice pentru client NFS și server NFS.

Când serverul NFS primește o solicitare de la un client, aceasta este trecută la o rutină locală de acces la fișiere, care oferă acces la discul local de pe server.

Serverul poate dura timp pentru a procesa cererile clientului. Chiar și accesarea sistemului de fișiere local poate dura ceva timp. În acest timp, serverul nu dorește să blocheze solicitările de la alți clienți care trebuie de asemenea să fie serviți. Pentru a face față acestei situații, majoritatea serverelor NFS sunt pornite de mai multe ori, ceea ce înseamnă că există mai multe servere NFS în nucleu. Metodele specifice de soluție depind de sistemul de operare. Majoritatea nucleelor ​​Unix nu „trăiesc” mai multe servere NFS, ci în schimb pornesc mai multe procese utilizator (numite de obicei nfsd) care fac un singur apel de sistem și rămân în interiorul nucleului ca proces de nucleu.

De asemenea, un client NFS are nevoie de timp pentru a procesa o solicitare de la un proces utilizator de pe gazda client. RPC-ul este emis gazdei serverului, după care se așteaptă un răspuns. Pentru a vă asigura că procesele utilizatorului de pe gazda clientului pot profita de NFS în orice moment, există mai mulți clienți NFS care rulează în interiorul nucleului clientului. Implementarea specifică depinde și de sistemul de operare. Sistemele Unix folosesc de obicei o tehnică care amintește de un server NFS: un proces utilizator numit biod efectuează un singur apel de sistem și rămâne în interiorul nucleului ca proces de nucleu.

Majoritatea gazdelor Unix pot funcționa ca client NFS și server NFS, sau ambele în același timp. Majoritatea implementărilor pentru PC (MS-DOS) au doar implementări client NFS. Majoritatea mainframe-urilor IBM oferă doar funcționalitate server NFS.

NFS este de fapt mai mult decât doar protocolul NFS. Figura 29.4 prezintă diferitele programe RPC care sunt utilizate cu NFS.

Aplicație	Numărul programului	Versiunea numarul	Numărul de proceduri
convertor de porturi
NFS
program de montare
manager de blocare
monitor de stare

Figura 29.4 Diverse programe RPC utilizate în NFS.

Versiunile pe care le-am arătat în această figură ca unități se găsesc pe sisteme precum SunOS 4.1.3. Noile implementări oferă versiuni mai noi ale unor programe. Solaris 2.2, de exemplu, acceptă și versiunile 3 și 4 ale rezolutorului de porturi și versiunea 2 a demonului de montare. SVR4 acceptă și versiunea 3 a convertorului de porturi.

Daemonul de montare este invocat pe gazda NFS a clientului înainte ca clientul să poată accesa sistemul de fișiere al serverului. Descriem acest proces mai jos.

Managerul de blocare și monitorul de stare permit clientului să blocheze unele fișiere care se află pe serverul NFS. Aceste două programe sunt independente de protocolul NFS, deoarece blocarea necesită autentificarea clientului atât pentru gazda client, cât și pentru server, iar NFS în sine este „neutru”. (Vom vorbi despre indiferența NFS mai detaliat mai jos.) Capitolele 9, 10 și 11 [X/Open 1991] documentează procedurile care sunt utilizate de managerul de blocare și de monitorul de stare pentru blocarea în NFS.

Descriptori de fișiere

Unul dintre elementele fundamentale ale NFS este implementat de descriptori de fișiere. Pentru a accesa un fișier sau un director de pe serverul de obiecte, se folosește opac. Termenul opac înseamnă că serverul creează un handle de fișier, îl transmite înapoi clientului, pe care clientul îl folosește apoi atunci când accesează fișierul. Clientul nu se uită niciodată la conținutul descriptorului de fișier - conținutul acestuia este de interes doar pentru server.

Clientul NFS primește un handle de fișier de fiecare dată când deschide un fișier care se află de fapt pe serverul NFS. Când un client NFS citește sau scrie în acest fișier (în numele unui proces utilizator), un handle al fișierului este transmis înapoi serverului. Aceasta indică faptul că fișierul a fost accesat.

De obicei, procesul utilizatorului nu funcționează cu descriptori de fișiere. Descriptorii de fișiere sunt schimbați între clientul NFS și serverul NFS. În versiunea 2 a NFS, descriptorul fișierului este de 32 de octeți, iar în versiunea 3 a crescut la 64 de octeți.

Serverele Unix stochează în mod obișnuit următoarele informații în descriptorul de fișiere: identificatorul sistemului de fișiere (numerele dispozitivelor majore și minore ale sistemului de fișiere), numărul inodului (i-node) (un număr unic în sistemul de fișiere), numărul generației inodului (un număr care se modifică de fiecare dată când inodul este reutilizat pentru un alt fișier).

Protocol de montaj

Clientul folosește protocolul de montare NFS pentru a monta sistemul de fișiere al serverului înainte de a accesa fișierele NFS. Acest lucru se întâmplă de obicei când clientul se încarcă. Ca rezultat, clientul primește un handle de fișier către sistemul de fișiere al serverului.

Figura 29.5 descrie secvența de acțiuni ale unui client Unix la executarea comenzii mount(8).

Figura 29.5 Protocolul de montare utilizat Comanda Unix montură.

În acest caz, se efectuează următorii pași.

1. Când serverul pornește, convertorul de porturi pornește pe el.
2. După soluția de porturi, demonul de montare (mountd) începe pe server. Acesta creează un punct final TCP și un punct final UDP și atribuie fiecăruia un număr de port alocat dinamic. Apoi înregistrează aceste numere cu mapatorul de porturi.
3. Clientul execută comanda mount, care emite un apel RPC către solutorul de porturi al serverului pentru a obține un număr de port de la demonul mount de pe server. Atât TCP, cât și UDP pot fi utilizate pentru comunicarea între client și rezolutorul de porturi, dar UDP este de obicei utilizat.
4. Resolutorul portului raportează numărul portului.
5. Comanda mount lansează un apel RPC către demonul mount pentru a monta sistemul de fișiere al serverului. Din nou, poate fi folosit fie TCP, fie UDP, totuși UDP este utilizat de obicei. Serverul poate valida acum un client pe baza adresei sale IP și a numărului de port pentru a vedea dacă clientul poate monta sistemul de fișiere specificat.
6. Daemonul de montare răspunde cu un handle de fișier la sistemul de fișiere specificat.
7. Comanda de montare client lansează apelul sistem de montare pentru a asocia mânerul de fișier obținut la pasul 5 cu punctul de montare local de pe gazda client. Hranul de fișier este stocat în codul clientului NFS și, de acum înainte, orice acces de către procesele utilizatorului la fișierele din sistemul de fișiere al serverului va folosi mânerul de fișier ca punct de plecare.

Această implementare lasă întregul proces de montare, cu excepția apelului de sistem de montare pe client, mai degrabă proceselor utilizatorului decât nucleului. Cele trei programe pe care le-am arătat - comanda mount, rezolutorul de porturi și demonul mount - sunt procese utilizator.

În acest exemplu, pe soarele gazdă (client NFS), comanda a fost executată

soare # mount -t nfs bsdi:/usr /nfs/bsdi/usr

Această comandă montează directorul /usr pe gazda bsdi (server NFS) ca sistem de fișiere local /nfs/bsdi/usr. Figura 29.6 arată rezultatul.

Figura 29.6 Montarea directorului bsdi:/usr ca /nfs/bsdi/usr pe soarele gazdă.

După aceea, la accesarea fișierului /nfs/bsdi/usr/rstevens/hello.c pe clientul sun, este accesat fișierul /usr/rstevens/hello.c de pe serverul bsdi.

Proceduri NFS

Serverul NFS oferă 15 proceduri, pe care le vom descrie acum. (Numerele utilizate în această descriere nu sunt aceleași cu numerele procedurii NFS, deoarece le-am grupat în funcție de funcționalitate.) Deși NFS a fost proiectat să funcționeze peste sisteme de operare, nu doar sisteme Unix, unele dintre proceduri se bazează în mod special pe funcționarea Unix , care, la rândul său, poate să nu fie acceptat de alte sisteme de operare (de exemplu, legături rigide, legături simbolice, utilizare în grup, drepturi de acces la execuție și așa mai departe). Capitolul 4 conține mai multe informații despre caracteristicile sistemelor de fișiere, dintre care unele le utilizează NFS.

1. GETATTR. Returnează atributele fișierului: tipul fișierului (fișier obișnuit, director etc.), drepturi de acces, dimensiunea fișierului, proprietarul fișierului, ora ultimului acces și așa mai departe.
2. SETATTR. Setează atributele fișierului. Numai un anumit set de atribute poate fi setat: drepturi de acces, proprietar, proprietate a grupului, dimensiune, ora ultimului acces și ora ultimei modificări.
3. STATFS. Returnează starea sistemului de fișiere: cantitatea de spațiu liber, dimensiunea optimă pentru transfer și așa mai departe. Folosit, de exemplu, de comanda Unix df.
4. PRIVEŞTE ÎN SUS. „Evaluează” fișierul. Această procedură este apelată de client de fiecare dată când un proces utilizator deschide un fișier care se află pe serverul NFS. Este returnat un handle de fișier, împreună cu atributele fișierului.
5. CITIT. Citește dintr-un fișier. Clientul specifică un mâner de fișier, un decalaj de octeți de pornire și numărul maxim de octeți de citit (până la 8192).
6. SCRIE. Scrie într-un fișier. Clientul specifică mânerul fișierului, offset-ul de pornire în octeți, numărul de octeți de scris și datele de scris.

   Este necesar ca scrierile NFS să fie sincrone (cu o așteptare). Serverul nu poate răspunde OK până când datele au fost scrise cu succes (și orice alte informații despre fișier care trebuie actualizate) pe disc.

7. CREA. Creează un fișier.
8. ELIMINA. Șterge un fișier.
9. RENUMIRE. Redenumește fișierul.
10. LEGĂTURĂ. Face un link greu la fișier. Un hard link este un concept Unix care definește fisier specific pe disc poate avea orice număr de puncte de intrare (nume, numite și linkuri hard) care indică acest fișier.
11. SYMLINK. Creează o legătură simbolică către un fișier. O legătură simbolică este un fișier care conține numele altui fișier. Majoritatea operațiunilor care sunt efectuate pe o legătură simbolică (de exemplu, deschiderea) sunt de fapt efectuate pe fișierul către care indică legătura simbolică.
12. READLINK. Citirea unui link simbolic returnează numele fișierului indicat de linkul simbolic.
13. MKDIR. Creează un director.
14. RMDIR. Șterge un director.
15. READDIR. Citește directorul. Folosit, de exemplu, de comanda Unix ls.

De fapt, numele procedurilor afișate încep cu prefixul NFSPROC_, pe care l-am omis.

UDP sau TCP?

NFS a fost scris inițial pentru a utiliza UDP și toți furnizorii oferă această capacitate. Cu toate acestea, implementările mai noi acceptă și TCP. Suportul TCP este folosit pentru a opera prin rețele globale, care devin din ce în ce mai rapide. Prin urmare, utilizarea NFS nu se mai limitează la rețelele locale.

Granițele dintre rețelele locale și globale se estompează și toate acestea se întâmplă foarte repede. Timpii de întoarcere variază într-o gamă foarte largă și depășirea are loc din ce în ce mai frecvent. Aceste caracteristici ale rețelelor globale duc la faptul că folosesc din ce în ce mai mult algoritmii pe care i-am considerat pentru TCP - slow start and congestion avoidance. Deoarece UDP nu oferă nimic similar cu acești algoritmi, aceștia sau alții similari trebuie să fie încorporați în clientul și serverul NFS, altfel trebuie utilizat TCP.

NFS peste TCP

Implementarea Berkeley Net/2 NFS acceptă atât UDP, cât și TCP. [Macklem 1991] descrie această implementare. Să ne uităm la modul în care utilizarea NFS diferă atunci când rulează peste TCP.

1. Când serverul pornește, pornește serverul NFS, care se deschide activ pe portul TCP 2049, așteptând să sosească o solicitare de conectare de la client. Acest lucru se face de obicei în plus față de NFS UDP obișnuit, care ascultă datagramele primite pe portul UDP 2049.
2. Când un client montează sistemul de fișiere al unui server utilizând TCP, efectuează o deschidere activă pe portul TCP 2049 de pe server. Aceasta stabilește o conexiune TCP între client și server pentru acest sistem de fișiere. Dacă același client montează un alt sistem de fișiere pe același server, se creează o altă conexiune TCP.
3. Atât clientul, cât și serverul setează opțiunea TCP „stay alive” la capetele conexiunii (Capitolul 23). Acest lucru vă permite să determinați momentul eșecului sau repornirii unuia sau altuia participant la schimb.
4. Toate aplicațiile de pe client care utilizează sistemul de fișiere al serverului partajează aceeași conexiune TCP la acel sistem de fișiere. De exemplu, dacă ar exista în Figura 29.6, ar exista un alt director pe bsdi, numit smith, sub directorul /usr, apeluri la fișierele din /nfs/bsdi/usr/rstevens și /nfs/bsdi/usr/smith ar partaja același lucru, aceeași conexiune TCP.
5. Dacă clientul stabilește că serverul s-a prăbușit sau a repornit (după ce a primit o eroare TCP „conexiune expirată” sau „conexiune închisă de gazdă”), încearcă să se reconnecteze la server. Clientul efectuează o altă deschidere activă pentru a restabili conexiunea TCP pentru acest sistem de fișiere. Orice solicitare de la un client care a expirat la o conexiune anterioară este reemisă la o nouă conexiune.
6. Dacă un client eșuează, la fel și aplicațiile care rulau înainte de eșec. Când clientul repornește, acesta poate remonta sistemul de fișiere al serverului folosind TCP, folosind o conexiune TCP diferită la server. Conexiunea anterioară dintre client și server pentru acest sistem de fișiere este într-o stare pe jumătate deschisă (serverul crede că este încă deschisă), totuși, deoarece serverul a setat opțiunea „stay alive”, această conexiune pe jumătate deschisă va fi închis când serverul TCP trimite următoarea sondă." rămâne în viață."

De-a lungul timpului, alți furnizori plănuiesc să accepte NFS prin TCP.

Exemple NFS

Să folosim tcpdump pentru a vedea care rutine NFS sunt invocate de client pentru operațiuni normale cu fișiere. Când tcpdump determină că o datagramă UDP conține un apel RPC (apelul este 0 în Figura 29.1) cu portul de destinație 2049, decodifică datagrama ca o cerere NFS. În mod similar, dacă o datagramă UDP conține un răspuns RPC (răspunsul este 1 în Figura 29.2) cu un port sursă de 2049, aceasta decodifică datagrama ca răspuns NFS.

Exemplu simplu: citirea unui fișier

În primul exemplu, vom copia un fișier aflat pe serverul NFS pe terminal folosind comanda cat(1):

Soare% cat /nfs/bsdi/usr/rstevens/hello.c copierea unui fișier pe terminal
principal()
{
printf("bună, lume\n");
}

Sistemul de fișiere /nfs/bsdi/usr de pe gazda sun (client NFS) este de fapt sistemul de fișiere /usr de pe gazda bsdi (server NFS), așa cum se arată în Figura 29.6. Sunkernel-ul detectează acest lucru atunci când cat deschide un fișier și folosește NFS pentru a accesa fișierul. Figura 29.7 arată rezultatul comenzii tcpdump.

1 0.0 sun.7aa6 > bsdi.nfs: 104 getattr
2 0.003587 (0.0036) bsdi.nfs > sun.7aa6: răspuns ok 96

3 0,005390 (0,0018) sun.7aa7 > bsdi.nfs: 116 căutare „rstevens”
4 0.009570 (0.0042) bsdi.nfs > sun.7aa7: răspuns ok 128

5 0,011413 (0,0018) sun.7aa8 > bsdi.nfs: 116 căutare „hello.c”
6 0.015512 (0.0041) bsdi.nfs > sun.7aa8: răspuns ok 128

7 0.018843 (0.0033) sun.7aa9 > bsdi.nfs: 104 getattr
8 0.022377 (0.0035) bsdi.nfs > sun.7aa9: răspuns ok 96

9 0.027621 (0.0052) sun.7aaa > bsdi.nfs: 116 citiți 1024 octeți @ 0
10 0.032170 (0.0045) bsdi.nfs > sun.7aaa: raspunde ok 140

Figura 29.7 Operarea NFS la citirea unui fișier.

Comanda tcpdump decodifică cererea sau răspunsul NFS și, de asemenea, tipărește câmpul XID pentru client în loc de numărul portului. Câmpul XID din rândurile 1 și 2 este 0x7aa6.

Numele de fișier /nfs/bsdi/usr/rstevens/hello.c este procesat de funcția de deschidere din nucleul clientului, câte un element de nume. Când funcția deschisă ajunge la /nfs/bsdi/usr, determină că acesta este un punct de montare a sistemului de fișiere NFS.

Pe linia 1, clientul apelează GETATTR pentru a obține atributele directorului serverului pe care clientul l-a montat (/usr). Această solicitare RPC conține 104 octeți de date, în plus față de anteturile IP și UDP. Răspunsul de pe linia 2 returnează OK și conține 96 de octeți de date, în plus față de anteturile IP și UDP. Putem vedea în această figură că mesajul NFS minim conține aproximativ 100 de octeți de date.

Pe linia 3, clientul apelează LOOKUP pe fișierul rstevens și primește un răspuns OK pe linia 4. LOOKUP specifică numele fișierului rstevens și un handle pentru fișierul care a fost stocat de kernel când a fost montat sistemul de fișiere la distanță. Răspunsul conține un nou handle de fișier care este utilizat în pasul următor.

Pe linia 5, clientul caută fișierul hello.c folosind mânerul de fișier de la linia 4. Primește un mâner de fișier diferit pe linia 6. Acest nou mâner de fișier este exact ceea ce clientul folosește pe liniile 7 și 9 pentru a accesa fișierul / nfs /bsdi/usr/rstevens/hello.c. Vedem că clientul efectuează o CĂUTARE pe fiecare componentă de nume din calea către fișierul deschis.

Pe linia 7, clientul execută din nou GETATTR, urmat de READ pe linia 9. Clientul solicită 1024 de octeți începând cu offset-ul 0, dar primește mai puțin de 1024 de octeți de date. (După scăderea dimensiunilor câmpurilor RPC și a altor valori returnate de procedura READ, 38 de octeți de date sunt returnați pe linia 10. Aceasta este exact dimensiunea fișierului hello.c.)

În acest exemplu, procesul utilizatorului nu știe nimic despre aceste solicitări și răspunsuri NFS, care sunt efectuate de nucleu. Aplicația apelează doar funcția de bază deschisă, care face ca 3 cereri și 3 răspunsuri să fie schimbate (liniile 1-6), apoi apelează funcția de citire de bază, care apelează 2 cereri și 2 răspunsuri (liniile 7-10). Pentru aplicația client, fișierul aflat pe serverul NFS este transparent.

Exemplu simplu: crearea unui director

Ca un alt exemplu, să schimbăm directorul de lucru într-un director care se află pe serverul NFS și apoi să creăm un nou director:

Soare% cd /nfs/bsdi/usr/rstevens schimba directorul de lucru
soare% mkdir Mail creați un director

Figura 29.8 arată rezultatul comenzii tcpdump.

1 0.0 sun.7ad2 > bsdi.nfs: 104 getattr
2 0.004912 (0.0049) bsdi.nfs > sun.7ad2: răspuns ok 96

3 0.007266 (0.0024) sun.7ad3 > bsdi.nfs: 104 getattr
4 0.010846 (0.0036) bsdi.nfs > sun.7ad3: răspuns ok 96

5 35.769875 (35.7590) sun.7ad4 > bsdi.nfs: 104 getattr
6 35.773432 (0.0036) bsdi.nfs > sun.7ad4: raspunde ok 96

7 35.775236 (0.0018) sun.7ad5 > bsdi.nfs: 112 căutare „Mail”
8 35.780914 (0.0057) bsdi.nfs > sun.7ad5: raspunde ok 28

9 35.782339 (0.0014) sun.7ad6 > bsdi.nfs: 144 mkdir „Mail”
10 35.992354 (0.2100) bsdi.nfs > sun.7ad6: raspunde ok 128

Figura 29.8 Operarea NFS la schimbarea directorului (cd) în directorul NFS și apoi la crearea directorului (mkdir).

La schimbarea directorului, clientul apelează GETATTR de două ori (liniile 1-4). Când creăm un nou director, clientul apelează GETATTR (liniile 5 și 6), apoi LOOKUP (liniile 7 și 8 pentru a verifica dacă directorul nu există), apoi MKDIR pentru a crea directorul (liniile 9 și 10). Răspunsul OK de pe linia 8 nu înseamnă că directorul există. Înseamnă pur și simplu că procedura a returnat o anumită valoare. tcpdump nu interpretează valoarea returnată de procedurile NFS. Comanda imprimă pur și simplu OK și numărul de octeți de date din răspuns.

Indiferenţă

Una dintre caracteristicile NFS (criticii NFS o numesc un neg, nu o caracteristică) este că serverul NFS este indiferent. Serverului nu îi pasă ce clienți accesează ce fișiere. Observați că lista procedurilor NFS prezentată mai devreme nu include o procedură de deschidere sau de închidere. Procedura LOOKUP este similară cu cea deschisă, dar serverul nu știe niciodată dacă clientul a accesat fișierul după ce a fost efectuată CĂUTAREA.

Motivul acestui „comportament nu-mi pasă” este acela de a facilita recuperarea după o defecțiune a serverului după ce acesta se blochează și repornește.

Exemplu: eroare de server

În exemplul următor, citim un fișier de pe un server NFS atunci când serverul se blochează și repornește. Aceasta va arăta cum „indiferența” serverului îi permite clientului „să nu știe” că serverul a eșuat. În tot timpul când serverul se blochează și repornește, clientul nu este conștient de problemă, iar aplicația client funcționează la fel ca înainte.

Pe clientul Sun, am rulat cat cu un fișier foarte mare ca argument (/usr/share/lib/termcap pe serverul svr4 NFS), am deconectat cablul Ethernet la mijlocul transferului, am oprit și repornit serverul, apoi am reconectat cablul . Clientul a fost configurat să citească 1024 de octeți per citire NFS. Figura 29.9 arată rezultatul tcpdump.

Rândurile 1-10 corespund cu clientul care deschide fișierul. Această operație este similară cu cea prezentată în Figura 29.7. Pe linia 11 vedem prima citire (READ) din fișierul de 1024 de octeți de date; răspunsul a revenit pe linia 12. Acest lucru continuă până la linia 129 (citește READ la 1024 de octeți și apoi răspunde OK).

În rândurile 130 și 131 vedem două cereri care expiră și sunt retrimise în rândurile 132 și 133. Prima întrebare: vedem două solicitări de citire, una începe cu offset 65536 și cealaltă începe cu offset 73728, de ce? Nucleul client a determinat că aplicația client citea secvenţial și a încercat să obţină blocuri de date în avans. (Majoritatea nucleelor ​​Unix fac această citire înainte.) Nucleul client rulează, de asemenea, mai multe daemoni de intrare/ieșire (I/O) bloc NFS (procese biod) care încearcă să genereze mai multe cereri RPC în numele clientului. Un demon citește 8192 de octeți, începând de la 65536 (în lanțuri de 1024 de octeți), iar ceilalți citesc înainte 8192 de octeți, începând de la 73728.

Retransmisiunile clientului apar pe liniile 130-168. Pe linia 169 vedem că serverul a repornit și a trimis o cerere ARP înainte de a răspunde la cererea NFS a clientului pe linia 168. Răspunsul la linia 168 este trimis pe linia 171. Solicitările READ ale clientului continuă.

1 0.0 sun.7ade > svr4.nfs: 104 getattr
2 0.007653 (0.0077) svr4.nfs > sun.7ade: răspuns ok 96

3 0,009041 (0,0014) sun.7adf > svr4.nfs: 116 căutare „share”
4 0.017237 (0.0082) svr4.nfs > sun.7adf: răspuns ok 128

5 0,018518 (0,0013) sun.7ae0 > svr4.nfs: 112 căutare „lib”
6 0.026802 (0.0083) svr4.nfs > sun.7ae0: răspuns ok 128

7 0,028096 (0,0013) sun.7ae1 > svr4.nfs: 116 căutare „termcap”
8 0.036434 (0.0083) svr4.nfs > sun.7ae1: răspuns ok 128

9 0.038060 (0.0016) sun.7ae2 > svr4.nfs: 104 getattr
10 0.045821 (0.0078) svr4.nfs > sun.7ae2: răspuns ok 96

11 0,050984 (0,0052) sun.7ae3 > svr4.nfs: 116 citire 1024 octeți @ 0
12 0.084995 (0.0340) svr4.nfs > sun.7ae3: raspunde ok 1124

Citind

128 3.430313 (0.0013) sun.7b22 > svr4.nfs: 116 citire 1024 octeți @ 64512
129 3.441828 (0.0115) svr4.nfs > sun.7b22: raspunde ok 1124

130 4.125031 (0.6832) soare.7b23 >
131 4.868593 (0.7436) soare.7b24 >

132 4.993021 (0.1244) sun.7b23 > svr4.nfs: 116 citiți 1024 octeți @ 65536
133 5.732217 (0.7392) sun.7b24 > svr4.nfs: 116 citire 1024 octeți @ 73728

134 6.732084 (0.9999) sun.7b23 > svr4.nfs: 116 citiți 1024 octeți @ 65536
135 7.472098 (0.7400) sun.7b24 > svr4.nfs: 116 citire 1024 octeți @ 73728

136 10.211964 (2.7399) soare.7b23 >
137 10.951960 (0.7400) soare.7b24 >

138 17.171767 (6.2198) sun.7b23 > svr4.nfs: 116 citire 1024 octeți @ 65536
139 17.911762 (0.7400) sun.7b24 > svr4.nfs: 116 citiți 1024 octeți @ 73728

140 31.092136 (13.1804) sun.7b23 > svr4.nfs: 116 citire 1024 octeți @ 65536
141 31.831432 (0.7393) sun.7b24 > svr4.nfs: 116 citiți 1024 octeți @ 73728

142 51.090854 (19.2594) sun.7b23 > svr4.nfs: 116 citire 1024 octeți @ 65536
143 51.830939 (0.7401) sun.7b24 > svr4.nfs: 116 citiți 1024 octeți @ 73728

144 71.090305 (19.2594) sun.7b23 > svr4.nfs: 116 citire 1024 octeți @ 65536
145 71.830155 (0.7398) sun.7b24 > svr4.nfs: 116 citiți 1024 octeți @ 73728

Retransmisii

167 291.824285 (0.7400) sun.7b24 > svr4.nfs: 116 citiți 1024 octeți @ 73728
168 311.083676 (19.2594) sun.7b23 > svr4.nfs: 116 citire 1024 octeți @ 65536

Serverul a fost repornit

169 311.149476 (0.0658) arp cine-are soare spune svr4
170 311.150004 (0.0005) arp răspuns soarele este la 8:0:20:3:f6:42

171 311.154852 (0.0048) svr4.nfs > sun.7b23: raspunde ok 1124

172 311.156671 (0.0018) sun.7b25 > svr4.nfs: 116 citire 1024 octeți @ 66560
173 311.168926 (0.0123) svr4.nfs > sun.7b25: raspunde ok 1124
citind

Figura 29.9 Clientul citește un fișier atunci când serverul NFS se blochează și repornește.

Aplicația client nu va ști niciodată că serverul s-a prăbușit și a repornit, cu excepția faptului că a existat o pauză de 5 minute între liniile 129 și 171, astfel încât blocarea serverului este transparentă pentru client.

Pentru a estima durata timpului de retransmisie din acest exemplu, imaginați-vă că există doi daemoni client, fiecare cu propriile timeout-uri. Intervalele pentru primul demon (citirea de la offset 65536) sunt aproximativ după cum urmează (rotunjit la două zecimale): 0,68; 0,87; 1,74; 3,48; 6,96; 13,92; 20,0; 20,0; 20.0 și așa mai departe. Intervalele pentru cel de-al doilea demon (citirea de la offset 73728) sunt exact aceleași. Aceasta înseamnă că acești clienți NFS folosesc timeout-uri care sunt multipli de 0,875 secunde, cu o limită superioară de 20 de secunde. După fiecare timeout, intervalul de retransmisie se dublează: 0,875; 1,75; 3,5; 7.0 și 14.0.

Cât timp va dura clientului să facă retransmisii? Clientul are două opțiuni care pot afecta acest lucru. În primul rând, dacă sistemul de fișiere al serverului este montat greu, clientul va retransmite pentru totdeauna, dar dacă sistemul de fișiere al serverului este montat soft, clientul nu va mai încerca după un număr fix de retransmisii. De asemenea, în cazul unui hard mount, clientul are opțiunea de a permite utilizatorului să anuleze retransmisiile eșuate sau să nu anuleze. Dacă, la montarea sistemului de fișiere al serverului, gazda clientului indică faptul că acesta poate fi întrerupt și dacă nu dorim să așteptăm 5 minute ca serverul să se repornească după crash, putem introduce un simbol de întrerupere pentru a termina aplicația client.

Mai multe proceduri identice

Procedurile RPC pot fi executate de server de mai multe ori, dar totuși returnează același rezultat. De exemplu, procedura de citire NFS. După cum am văzut în Figura 29.9, clientul pur și simplu reemite apelul READ atâta timp cât primește un răspuns. În exemplul nostru motivul retransmisie a fost că serverul nu era. Dacă serverul nu a eșuat și mesajele care conțin răspunsuri RPC s-au pierdut (deoarece UDP este un protocol nesigur), clientul pur și simplu retransmite și serverul face din nou același READ. Aceeași parte a aceluiași fișier este citită din nou și trimisă clientului.

Acest lucru funcționează deoarece fiecare solicitare de citire READ conține un offset de pornire. Dacă procedura NFS ar cere serverului să citească următorii N octeți ai fișierului, nu ar funcționa. Dacă serverul nu ar fi indiferent (acesta este opusul indiferentului) și răspunsul a fost pierdut și clientul a reemis READ pentru următorii N octeți, rezultatul ar fi diferit. Acesta este motivul pentru care procedurile NFS READ și WRITE au un offset de pornire. Clientul este cel care menține starea (offset-ul curent pentru fiecare fișier), nu serverul.

Din păcate, nu toate operațiunile sistemului de fișiere pot fi efectuate de mai multe ori. De exemplu, imaginați-vă următorii pași: clientul NFS emite o solicitare REMOVE pentru a elimina un fișier; Serverul NFS șterge fișierul și răspunde OK; răspunsul serverului a fost pierdut; Clientul NFS expiră și retransmite cererea; Serverul NFS nu poate găsi fișierul și returnează o eroare; Aplicația client primește o eroare care declară că fișierul nu există. Această eroare este returnată aplicației client, iar această eroare conține informații incorecte - fișierul nu a existat și a fost șters.

Mai jos este o listă de proceduri NFS care pot fi executate de mai multe ori: GETATTR, STATFS, LOOKUP, READ, WRITE, READLINK și READDIR. Proceduri care nu pot fi executate de mai multe ori: CREATE, REMOVE, RENAME, LINK, SYMLINK, MKDIR și RMDIR. SETATTR este de obicei executat de mai multe ori, cu excepția cazului în care a fost folosit pentru a trunchia un fișier.

Deoarece răspunsurile orfane sunt întotdeauna probabil să apară atunci când se utilizează UDP, serverele NFS trebuie să aibă o modalitate de a gestiona operațiuni care nu pot fi efectuate de mai multe ori. Majoritatea serverelor au un cache de răspuns recent în care stochează ultimele răspunsuri primite pentru astfel de operațiuni. De fiecare dată când serverul primește o solicitare, se uită mai întâi prin cache-ul său și, dacă se găsește o potrivire, returnează răspunsul anterior, în loc să apeleze din nou procedura NFS. [Juszczak 1989] descrie detaliile acestor tipuri de cache.

Această abordare a procedurilor serverului se aplică tuturor aplicațiilor bazate pe UDP, nu doar NFS. DNS, de exemplu, oferă un serviciu care poate fi folosit de mai multe ori fără durere. Serverul DNS poate interoga analizatorul de orice număr de ori, ceea ce nu va duce la rezultate negative (poate, cu excepția faptului că resursele de rețea vor fi ocupate).

NFS versiunea 3

În 1994, au fost lansate specificațiile pentru versiunea 3 a protocolului NFS [Sun Microsystems 1993]. Se preconizează că implementările vor deveni disponibile în cursul anului 1994.

Iată o scurtă prezentare a principalelor diferențe dintre versiunile 2 și 3. Le vom numi V2 și V3.

1. Descriptorii de fișiere din V2 sunt o matrice de dimensiune fixă ​​de 32 de octeți. În V3 este o matrice de dimensiune variabilă cu o dimensiune de până la 64 de octeți. O matrice cu lungime variabilă în XDR este definită de un numărător de 4 octeți urmat de octeți reali. Acest lucru reduce dimensiunea descriptorului de fișier în implementări precum Unix, unde sunt necesari doar aproximativ 12 octeți, dar permite implementărilor non-Unix să facă schimb de informații suplimentare.
2. V2 limitează numărul de octeți per procedură RPC READ sau WRITE la 8192 de octeți. Această limitare nu se aplică în V3, ceea ce înseamnă, la rândul său, că folosind UDP limita va fi doar dimensiunea datagramei IP (65535 octeți). Acest lucru permite utilizarea pachetelor mari pentru citirea și scrierea în rețele rapide.
3. Dimensiunile fișierelor și decalajele de octeți de pornire pentru procedurile de CITIERE și SCRIERE au fost extinse de la 32 la 64 de biți, permițând gestionarea dimensiunilor mai mari ale fișierelor.
4. Atributele fișierului sunt returnate în fiecare apel care poate afecta atributele. Acest lucru reduce numărul de apeluri GETATTR solicitate de client.
5. Scrierile (WRITE) pot fi asincrone, în timp ce în V2 trebuiau să fie sincrone. Acest lucru poate îmbunătăți performanța procedurii WRITE.
6. A fost eliminată o procedură (STATFS) și au fost adăugate șapte: ACCESS (verificați permisiunile fișierelor), MKNOD (creați un fișier special Unix), READDIRPLUS (returnează numele fișierelor dintr-un director împreună cu atributele acestora), FSINFO (returnează informații statistice despre sistemul de fișiere), FSSTAT (returnează informații despre sistemul de fișiere dinamic), PATHCONF (returnează informații despre fișierul POSIX.1) și COMMIT (commite scrieri asincrone făcute anterior pe stocarea persistentă).

Concluzii scurte

RPC este o modalitate de a construi o aplicație client-server în așa fel încât clientul să apeleze pur și simplu proceduri de pe server. Toate detaliile rețelei sunt ascunse în stub-urile client și server, care sunt generate pentru aplicații de pachetul RPC și în rutinele bibliotecii RPC. Am arătat formatul mesajelor de apel și răspuns RPC și am menționat că XDR este folosit pentru a codifica valori, permițând clienților și serverelor RPC să ruleze pe diferite arhitecturi de mașini.

Una dintre cele mai utilizate aplicații RPC este Sun NFS, un protocol eterogen de acces la fișiere care este utilizat pe scară largă pe gazde de aproape toate dimensiunile. Ne-am uitat la NFS și cum folosește UDP sau TCP. Protocolul NFS Versiunea 2 definește 15 proceduri.

Accesul clientului la un server NFS începe cu un protocol de montare, după care un handle de fișier este returnat clientului. Clientul poate accesa apoi fișierele de pe sistemul de fișiere al serverului folosind acest handle de fișier. Numele fișierelor sunt căutate pe server câte un element de nume, returnând un nou handle de fișier pentru fiecare element. Rezultatul final este un handle pentru fișierul care a fost accesat și care este folosit pentru citiri și scrieri secvențiale.

NFS încearcă să facă toate procedurile sale independente de numărul de execuții, astfel încât clientul să poată pur și simplu reemite cererea dacă răspunsul este pierdut. Am văzut exemple în acest sens în care un client citea un fișier în timp ce serverul s-a prăbușit și a repornit.

Exerciții

În Figura 29.7, am văzut că tcpdump interpretează pachetele ca cereri și răspunsuri NFS și tipărește XID-ul. Poate tcpdump să facă acest lucru pentru orice cereri sau răspunsuri RPC?

De ce crezi că programul server RPC de pe sistemele Unix utilizează mai degrabă porturi alocate dinamic decât cele precunoscute?

Clientul RPC a apelat două proceduri de server. Prima procedură a durat 5 secunde, iar a doua - 1 secundă. Clientul are un timeout de 4 secunde. Desenați o diagramă de timp a ceea ce este schimbat între client și server. (Imaginați-vă că nu a fost timp petrecut pentru a transmite un mesaj de la client la server și invers.)

În exemplul din Figura 29.9, ce s-ar întâmpla dacă placa Ethernet a serverului NFS ar fi îndepărtată în timp ce serverul NFS a fost oprit?

Când serverul a repornit în Figura 29.9, a procesat cererea începând cu offset-ul 65536 (liniile 168 și 171), apoi a procesat următoarea cerere începând cu offset-ul 66560 (liniile 172 și 173). Ce se întâmplă cu interogarea care începe cu offset 73728 (linia 167)?

Când am descris proceduri independente de numărul de execuții NFS, am arătat un exemplu de răspuns REMOVE care a fost pierdut în rețea. Ce se întâmplă în acest caz dacă se folosește TCP în loc de UDP?

Dacă serverul NFS utilizează un port alocat dinamic în loc de portul 2049, ce se întâmplă cu clientul NFS atunci când serverul se blochează și repornește?

Există foarte, foarte puține numere de porturi rezervate (Capitolul 1, secțiunea „Numere de port”), cu maximum 1023 per gazdă. Dacă un server NFS solicită clienților săi porturi rezervate (ceea ce fac de obicei), iar un client NFS care utilizează TCP montează N sisteme de fișiere pe N servere diferite, este necesar ca clientul să aibă numere de porturi rezervate diferite pentru fiecare conexiune?

#image.jpg Distracție plăcută, cititori și oaspeți ai blogului meu. A fost o pauză foarte lungă între postări, dar am revenit în acțiune). În articolul de astăzi mă voi uita Operarea protocolului NFS, și configurarea serverului NFS și a clientului NFS pe Linux.

Introducere în NFS

NFS (Sistem de fișiere de rețea- sistem de fișiere de rețea) după părerea mea - o soluție ideală într-o rețea locală unde aveți nevoie de un schimb de date rapid (mai rapid în comparație cu SAMBA și mai puțin consumator de resurse în comparație cu sistemele de fișiere la distanță cu criptare - sshfs, SFTP etc...) și Securitatea informațiilor transmise nu este o prioritate maximă. Protocolul NFS vă permite să montați sisteme de fișiere la distanță într-o rețea într-un arbore de directoare local, ca și cum ar fi un sistem de fișiere pe disc montat.

Astfel, aplicațiile locale pot funcționa cu un sistem de fișiere la distanță ca și cum ar fi unul local. Dar trebuie să fii atent (!) cu configurarea NFS, deoarece cu o anumită configurație este posibil să înghețe sistemul de operare al clientului în așteptarea unei I/O fără sfârșit.

Protocolul NFS bazat pe muncă Protocolul RPC, care este încă dincolo de înțelegerea mea)) așa că materialul din articol va fi puțin vag... Înainte de a putea folosi NFS, fie că este un server sau un client, trebuie să vă asigurați că nucleul dumneavoastră are suport pentru fișierul NFS sistem. Puteți verifica dacă nucleul acceptă sistemul de fișiere NFS vizualizând prezența linii corespunzătoareîn fișierul /proc/filesystems:

ARCHIV ~ # grep nfs /proc/filesystems nodev nfs nodev nfs4 nodev nfsd

Dacă liniile indicate nu sunt în fișierul /proc/filesystems, atunci trebuie să instalați pachetele descrise mai jos. Acest lucru vă va permite probabil să instalați module dependente de kernel pentru a suporta sistemele de fișiere adecvate.

Dacă, după instalarea pachetelor, suportul NFS nu este afișat în fișierul desemnat, atunci va trebui să recompilați nucleul pentru a activa această funcție.

Poveste Sistem de fișiere de rețea

Protocolul NFS dezvoltat de Sun Microsystems și are patru versiuni în istoria sa. NFSv1 a fost dezvoltat în 1989 și a fost experimental, rulând pe protocolul UDP. Versiunea Unu este descrisă în RFC 1094.

NFSv2 a fost lansat în același an 1989, a fost descris de același RFC1094 și a fost, de asemenea, bazat pe protocolul UDP, permițând în același timp citirea a cel puțin 2 GB dintr-un fișier. NFSv3 a fost finalizat în 1995 și este descris în RFC 1813.

Principalele inovații ale celei de-a treia versiuni au fost suportul pentru fișiere marime mare, a fost adăugat suport pentru protocolul TCP și pachete TCP mai mari, ceea ce a accelerat semnificativ performanța tehnologiei. NFSv4 a fost finalizat în 2000 și descris în RFC 3010, revizuit în 2003 și descris în RFC 3530.

A patra versiune a inclus îmbunătățiri de performanță, suport pentru diverse mijloace de autentificare (în special, Kerberos și LIPKEY cu introducerea protocolului RPCSEC GSS) și liste de control al accesului (atât tipurile POSIX, cât și Windows). NFS v4.1 a fost aprobat de IESG în 2010 și a primit RFC 5661.

Inovația fundamentală a versiunii 4.1 este specificarea pNFS - Parallel NFS, un mecanism de acces paralel al unui client NFS la datele de pe mai multe servere NFS distribuite. Prezența unui astfel de mecanism într-un sistem de fișiere de rețea eșantion va ajuta la construirea de sisteme de stocare și informații distribuite în „cloud”.

Server NFS

Din moment ce avem NFS- Acest reţea sistem de fișiere, trebuie să configurați netîn Linux. (Puteți citi și articolul conceptele principale ale rețelelor). Apoi, trebuie să instalați pachetul corespunzător. Pe Debian, acesta este pachetul nfs-kernel-server și nfs-common, pe RedHat acesta este pachetul nfs-utils.

De asemenea, trebuie să permiteți demonului să ruleze la niveluri de execuție adecvate (comandă în RedHat - /sbin/chkconfig nfs on, în Debian - /usr/sbin/update-rc.d nfs-kernel-server defaults).

Pachetele instalate în Debian sunt lansate în următoarea ordine:

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx O rădăcină 20 oct Eighteen 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx O rădăcină 20 șapte Oct 20 două 01:23 S16nfs -> kernel.-/rwxrwx .d/nfs-kernel-server

Cu alte cuvinte, începe primul nfs-comun, mai târziu serverul însuși nfs-kernel-server.

În RedHat situația este similară, cu singura excepție că se apelează primul script nfslock, iar serverul este numit simplu nfs. Despre nfs-comun Site-ul debian ne spune literalmente următoarele: fișiere partajate pentru clientul și serverul NFS, acest pachet trebuie instalat pe mașina care va funcționa ca client sau server NFS.

Pachetul include programe: lockd, statd, showmount, nfsstat, gssd și idmapd. Prin vizualizarea conținutului scriptului de pornire /etc/init.d/nfs-common, puteți urmări următoarea secvență de lucru: scriptul verifică prezența fișierului binar executabil /sbin/rpc.statd, verifică prezența în fișierele /etc/default/nfs-common, /etc/fstab și /etc/exports care necesită rularea demonilor idmapdȘi gssd, pornește demonul /sbin/rpc.statd, apoi înainte de a porni /usr/sbin/rpc.idmapd și /usr/sbin/rpc.gssd verifică prezența acestor fișiere binare executabile, apoi demonul /usr/sbin/rpc.idmapd verifică prezența modulelor kernelului sunrpc, nfs și nfsd, precum și suport pentru sistemul de fișiere rpc_pipefs din kernel (cu alte cuvinte, prezența acestuia în fișierul /proc/filesystems), dacă totul este cu succes, se lansează /usr/sbin/rpc.idmapd. În plus, pentru demon /usr/sbin/rpc.gssd verifică modulul kernel rpcsec_gss_krb5 și pornește demonul.

Dacă vizualizați conținutul Scriptul de pornire a serverului NFS pe Debian (/etc/init.d/nfs-kernel-server), atunci puteți urma următoarea secvență: la pornire, scriptul verifică existența fișierului /etc/exports, prezența modulului kernel nfsd, prezența suportului pentru sistemul de fișiere NFS în nucleul Linux (alte cuvinte în fișierul /proc/filesystems), dacă totul este la locul său, atunci demonul începe /usr/sbin/rpc.nfsd, apoi verifică dacă parametrul NEED_SVCGSSD este setat (setat în fișierul de opțiuni de server /etc/default/nfs-kernel-server) și, dacă este setat, pornește demonul /usr/sbin/rpc.svcgssd, ultimul care a lansat demonul /usr/sbin/rpc.mountd. Din acest scenariu este clar că Operarea serverului NFS constă în demonii rpc.nfsd, rpc.mountd și dacă se folosește autentificarea Kerberos, atunci demon rcp.svcgssd. Demonul rpc.rquotad și nfslogd încă rulează în red hat (Din anumite motive în Debian nu am găsit informații despre acest demon și motivele absenței sale, se pare că a fost șters...).

De aici devine clar că Serverul Network File System este format din următoarele procese (citește - demoni), situat în directoarele /sbin și /usr/sbin:

• rpc.statd- Monitorizare imposibilă a stării rețelei (aka Network Status Monitor, alias NSM). Vă permite să anulați corect blocarea după o blocare/repornire. Pentru a notifica încălcări, utilizați programul /usr/sbin/sm-notify. Statd imp funcționează atât pe servere, cât și pe clienți. Anterior, acest server era necesar pentru ca rpc.lockd să funcționeze, dar acum nucleul este responsabil pentru blocare (notă: dacă nu mă înșel #image.jpg). (Programul RPC 100 mii 20 unu și 100 mii 20 patru - în versiuni noi)
• rpc.lockd- Lockd lock imp (cunoscut și ca manager de blocare NFS (NLM)) gestionează cererile de blocare a fișierelor. Impul de blocare funcționează atât pe servere, cât și pe clienți. Clienții solicită blocarea fișierelor, iar serverele o permit. (învechit și nefolosit ca demon în distribuțiile noi. Funcțiile sale în distribuțiile moderne (cu un nucleu mai vechi de 2.2.18) sunt realizate de nucleu, mai precis de modulul de kernel (lockd).) (programul RPC 100024)
• rpc.nfsd- Demonul principal al serverului NFS este nfsd (în versiunile noi se numește uneori nfsd4). Acest imp servește cererile de la clienții NFS. Parametrul RPCNFSDCOUNT din fișierul /etc/default/nfs-kernel-server de pe Debian și NFSDCOUNT din fișierul /etc/sysconfig/nfs de pe RedHat determină numărul de demoni de rulat (prestabilit este 8 (programul RPC 100003).
• rpc.mountd- Fără montarea NFS, mountd gestionează cererile clientului de a monta directoare. Mountd imp rulează pe servere NFS. (programul RPC 100005)
• rpc.idmapd- Idmapd pentru NFSv4 de pe server convertește uid/gid-ul local al utilizatorilor în formatul nume@domeniu, iar serviciul de pe client convertește numele de utilizator/grup de tipul nume@domeniu în identificatori locali de utilizator și grup (conform configurației fișier /etc/idmapd.conf, mai multe detalii în man idmapd.conf):.
• În plus, versiunile mai vechi de NFS foloseau imps: nfslogd- NFS log imp înregistrează activitatea pentru sistemele de fișiere exportate, funcționează pe servere NFS și rquotad- serverul de cote la distanță oferă informații despre cotele de utilizatori în sistemele de fișiere la distanță, poate funcționa atât pe servere, cât și pe clienți (programul RPC 100011).

În NFSv4, atunci când utilizați Kerberos, demonii sunt lansați suplimentar:

• rpc.gssd- Bes NFSv4 oferă metode de autentificare prin GSS-API (autentificare Kerberos). Funcționează pe client și server.
• rpc.svcgssd- Imp server NFSv4, care oferă autentificare client pe partea de server.

portmap și protocol RPC (Sun RPC)

Pe lângă pachetele indicate mai sus, NFSv2 și v3 necesită un pachet suplimentar pentru funcționarea corectă portmap(înlocuit în distribuțiile mai noi cu redenumit în rpcbind). Acest pachet este de obicei instalat automat cu NFS ca pachet dependent și implementează funcționarea serverului RPC, cu alte cuvinte, este responsabil de alocarea dinamică a porturilor pentru unele servicii înregistrate în server RPC.

Literal, conform documentației, acesta este un server care convertește numerele de program RPC (Remote Procedure Call) în numere de porturi TCP/UDP. portmap operează pe mai multe entități: apeluri sau solicitări RPC, porturi TCP/UDP, versiune de protocol (tcp sau udp), numere de program și versiuni de program. Demonul portmap este lansat de scriptul /etc/init.d/portmap înainte de începerea serviciilor NFS.

Pe scurt, sarcina unui server RPC (Remote Procedure Call) este de a procesa apeluri RPC (așa-numitele proceduri RPC) din procesele locale și de la distanță.

Folosind apeluri RPC, serviciile se înregistrează sau se elimină către/de la un port mapper (aka port mapper, aka portmap, aka portmapper, alias, în versiunile noi, rpcbind), iar clienții folosesc apelurile RPC pentru a trimite cereri către portmapper pentru a primi informații relevante. Numele ușor de utilizat ale serviciilor de program și numerele lor corespunzătoare sunt definite în fișierul /etc/rpc.

Deoarece orice serviciu a trimis cererea corespunzătoare și s-a înregistrat pe serverul RPC în mapatorul de porturi, serverul RPC atribuie, mapează serviciului porturile TCP și UDP pe care a pornit serviciul și stochează în nucleu informațiile corespunzătoare despre serviciul care rulează. (nume), un număr unic de serviciu (în conformitate cu /etc/rpc), despre protocolul și portul pe care rulează serviciul și despre versiunea serviciului și furnizează informațiile indicate clienților la cerere. Convertorul de porturi în sine are un număr de program (100000), un număr de versiune 2, portul TCP 100 unsprezece și portul UDP 111.

Mai sus, când am indicat componența demonilor serverului NFS, am indicat numerele principale ale programului RPC. Probabil că v-am confundat puțin cu acest paragraf, așa că voi spune principala frază care ar trebui să clarifice lucrurile: principala funcție a port mapper este de a reveni, la cererea clientului care a furnizat numărul programului RPC (sau Numărul programului RPC) și versiunea lui (client) a portului pe care rulează programul solicitat. În consecință, dacă un client trebuie să acceseze un RPC cu un anumit număr de program, trebuie să contacteze mai întâi procesul portmap de pe computerul server și să găsească numărul portului de comunicație cu serviciul RPC de care are nevoie.

Funcționarea unui server RPC poate fi reprezentată prin următorii pași:

Pentru a obține informații de la serverul RPC, utilizați utilitarul rpcinfo. Când specificați trăsătura gazdă -p, programul afișează o listă cu toate programele RPC înregistrate gazdă gazdă. Fără a specifica gazda, programul va afișa serviciile pe localhost. Exemplu:

ARCHIV ~ # rpcinfo -p prog-ma vers proto port 100 mii Două tcp 100 unsprezece portmapper 100 mii Două udp 100 unsprezece portmapper 100 mii 20 patru Unu udp 50 nouă mii patru sute 50 o stare 100 mii 20 patru mii o sută ecp șase 70 doi statut 100 mii 20 unu Unu udp 40 patru mii trei sute 10 nlockmgr 100 mii 20 unu Trei udp 40 patru mii trei sute 10 nlockmgr 100 mii 20 unu Patru udp 40 patru mii trei sute 10 nlockmgr 100 mii 204 unu tcp 204 mie opt sute 50 unu nlockmgr 100 mii 20 unu Trei tcp 40 patru mii opt sute 50 unu nlockmgr 100 mii 20 unu Patru tcp 40 patru mii opt sute 50 unu nlockmgr 100 mii trei Două tcp Două mii 40 nouă mii trei tcp 100 mii 40 nouă nfs 100 mii trei Patru tcp Două mii 40 nouă nfs 100 mii trei Două udp Două mii 40 nouă nfs 100 mii trei Trei udp Două mii 40 nouă nfs 100 mii trei Patru udp Două mii 40 nouă nfs 100 mii 50 unu udp o mie trei sute 6 mountd 100 mii 5 Un tcp 40 o mie patru sute 5 mountd 100 mii 5 Două udp 50 o mie trei sute 6 mountd 100 mii 5 Două tcp 40 o mie patru sute 5 mountd 100 mii 5 Trei udp 50 o mie trei sute 6 mountd 100 mii 5 Trei tcp 40 o mie patru sute 5 mound

După cum puteți vedea, rpcinfo indică (în coloane de la stânga la dreapta) numărul programului înregistrat, versiunea, protocolul, portul și numele.

Folosind rpcinfo puteți elimina înregistrarea unui program sau puteți obține informații despre un anumit serviciu RPC (mai multe opțiuni în man rpcinfo). După cum puteți vedea, portmapper versiunea doi demoni sunt înregistrate pe udp și porturi tcp, rpc.statd versiunea One pe porturile udp și tcp, blocare NFS manager de versiuni 1,3,4, versiunile de server non-nfs 2,3,4, precum și versiunile fără montaj 1,2,3.

Serverul NFS (mai precis, rpc.nfsd) primește cereri de la client sub formă de datagrame UDP pe portul 2049. În ciuda faptului că NFS funcționează cu un rezolutor de porturi, care permite serverului să utilizeze porturi alocate dinamic, portul UDP Două mii 40 nouă sunt strict atribuite NFS în majoritatea implementărilor.

Operarea protocolului sistemului de fișiere în rețea

Montarea NFS la distanță

Procesul de montare a unui sistem de fișiere NFS la distanță poate fi reprezentat prin următoarea diagramă:

Descrierea protocolului NFS la montarea unui director la distanță:

1. Un server RPC este lansat pe server și client (de obicei la pornire), deservit de procesul portmapper și înregistrat pe portul tcp/111 și udp/111.
2. Sunt lansate servicii (rpc.nfsd, rpc.statd etc.), care sunt înregistrate pe serverul RPC și înregistrate pe porturi ale rețelei (dacă nu este specificat un port static în setările serviciului).
3. comanda mount de pe computerul clientului trimite nucleului o cerere de montare a unui director de rețea indicând tipul de sistem de fișiere, gazdă și practic directorul, nucleul trimite și generează o cerere RPC către procesul portmap de pe serverul NFS de pe portul udp/ 111 (dacă funcția să funcționeze prin tcp nu este setată pe client)
4. Nucleul serverului NFS interoghează RPC-ul pentru prezența imp rpc.mountd și returnează nucleului clientului portul de rețea pe care rulează imp.
5. mount trimite o cerere RPC către portul pe care rulează rpc.mountd. Pe acest moment Serverul NFS poate valida un client pe baza adresei IP și a numărului de port pentru a vedea dacă clientul poate monta sistemul de fișiere desemnat.
6. Mountless returnează o descriere a sistemului de fișiere solicitat.
7. Comanda de montare a clientului emite apelul de sistem de montare pentru a asocia mânerul de fișier găsit la pasul 5 cu punctul de montare local de pe gazda clientului. Hranul de fișier este stocat în codul clientului NFS și, de acum înainte, orice acces de către procesele utilizatorului la fișierele din sistemul de fișiere al serverului va folosi mânerul de fișier ca punct de plecare.

Schimb de date între client și serverul NFS

Accesul obișnuit la un sistem de fișiere la distanță poate fi descris prin următoarea schemă:

Descrierea procesului de accesare a unui fișier aflat pe un server NFS:

Configurarea unui server NFS

Ajustarea serveruluiîn general constă în specificarea directoarelor locale care pot fi montate de sistemele de la distanță în fișierul /etc/exports. Această acțiune se numește ierarhia directoarelor de export. Principalele surse de informații despre directoarele exportate sunt următoarele fișiere:

• /etc/exports- de bază Fișier de configurare, care stochează configurația directoarelor exportate. Folosit la pornirea NFS și de utilitarul exportfs.
• /var/lib/nfs/xtab- conține o listă de directoare montate de clienți la distanță. Folosit de rpc.mountd imp atunci când un client încearcă să monteze o ierarhie (este creată o înregistrare de montare).
• /var/lib/nfs/etab- o listă de directoare care pot fi montate de către sistemele de la distanță, indicând toate caracteristicile directoarelor exportate.
• /var/lib/nfs/rmtab- o listă de directoare care nu sunt în prezent neexportate.
• /proc/fs/nfsd- un sistem de fișiere special (kernel 2.6) pentru gestionarea serverului NFS.
• exporturi- o listă de ierarhii active exportate și clienți către care au fost exportați, precum și proprietăți. Nucleul primește aceste informații de la /var/lib/nfs/xtab.
• fire- conține numărul de fire (de asemenea, poate fi schimbat)
• folosind filehandle puteți obține un pointer către un fișier
• si etc...
• /proc/net/rpc- conține statistici „brute”, care pot fi obținute folosind nfsstat, precum și diverse cache-uri.
• /var/run/portmap_mapping- informatii despre serviciile inregistrate in RPC

Notă:În general, pe Internet există o mulțime de interpretări și formulări ale scopului fișierelor xtab, etab, rmtab, nu știu pe cine să cred #image.jpg Nici pe http://nfs.sourceforge.net/ interpretarea nu este clara.

Configurarea fișierului /etc/exports

În cazul normal, fișierul /etc/exports este singurul fișier care necesită editare pentru funcția serverului NFS. Acest fișier controlează următoarele proprietăți:

• Ce fel de clienți poate accesa fișierele de pe server
• Care ierarhii? directoarele de pe server pot fi accesate de fiecare client
• Cum vor fi numele personalizate de clienți fi afisat la nume de utilizator locale

Nu contează ce linie a fișierului de export are următorul format:

export_point client1(funcții) [client2(funcții) ...]

Unde punct_export calea absolută a ierarhiei directoarelor exportate, client1 - n numele unuia sau mai multor clienți sau adrese IP, separate prin spații, cărora li se permite montarea punct_export. Funcții schițați regulile de montare pentru client indicate înainte de opțiuni.

Iată una obișnuită exemplu de configurare a fișierului de export:

ARCHIV ~ # cat /etc/exports /archiv1 files(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)

În acest exemplu, fișierele computerelor și 10.0.0.1 au acces la punctul de export /archiv1, cu acces de citire/scriere la gazda fișierelor și acces numai pentru citire pentru gazda 10.0.0.1 și subrețeaua 10.0.230.1/24.

Descrierile gazdelor din /etc/exports sunt permise în următorul format:

• Numele de noduri individuale sunt descrise ca fișiere sau fișiere.DOMAIN.local.
• Descrierea măștii domeniului se face în următorul format: *DOMAIN.local include toate nodurile domeniului DOMAIN.local.
• Subrețelele sunt specificate ca perechi adresă IP/mască. De exemplu: 10.0.0.0/255.255.255.0 include toate nodurile ale căror adrese încep cu 10.0.0.
• Specificarea numelui grupului de rețea @myclients care are acces la resursă (când se utilizează un server NIS)

Funcții generale pentru exportul ierarhiilor de directoare

Următoarele funcții comune sunt utilizate în fișierul de export:(în primul rând, funcțiile utilizate implicit în majoritatea sistemelor sunt indicate, între paranteze - non-implicit):

• auth_nlm (nu_auth_nlm) sau secure_locks (blocuri_nesigure)- specifică că serverul ar trebui să caute autentificarea cererilor de blocare (folosind protocolul NFS Lock Manager).
• nohide (ascunde)- dacă serverul exportă două ierarhii de directoare, în timp ce una este imbricată (montată) în cealaltă. Clientul trebuie, desigur, să monteze a doua ierarhie (copil), altfel punctul de montare al ierarhiei copil va arăta ca un director gol. Funcția nohide are ca rezultat o a doua ierarhie a directorului fără nicio montare trivială. (notă: I această opțiune nu am reusit sa-l fac sa functioneze...)
• ro(rw)- Permite numai cereri de citire (scriere). (În cele din urmă, dacă poate fi citit/scris sau nu este determinat pe baza drepturilor sistemului de fișiere, cu toate acestea, serverul nu este capabil să distingă o solicitare de citire a unui fișier de o solicitare de executare, deci permite citirea dacă utilizatorul are drepturi de citire sau executare.)
• sigur (nesigur)- solicită ca cererile NFS să provină din porturi securizate (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (fără_subtree_check)- Dacă este exportat un subdirector al sistemului de fișiere, dar nu întregul sistem de fișiere, serverul verifică dacă fișierul solicitat se află în subdirectorul exportat. Dezactivarea verificării reduce securitatea, dar crește viteza de transfer al datelor.
• sincronizare (async)- specifică că serverul ar trebui să răspundă la solicitări numai după scrierea pe disc a configurațiilor efectuate de acele solicitări. Funcția asincronă îi spune serverului să nu aștepte ca informațiile să fie scrise pe disc, ceea ce crește performanța, dar reduce fiabilitatea, deoarece În cazul unei întreruperi a conexiunii sau a unei defecțiuni a echipamentului, informațiile se pot pierde.
• wdelay (fără_wdelay)- instruiește serverul să întârzie executarea cererilor de scriere dacă o cerere de scriere ulterioară este în așteptare, scriind datele în blocuri mai mari. Acest lucru îmbunătățește performanța la trimiterea unor cozi mari de comenzi de scriere. no_wdelay specifică să nu întârzie execuția unei comenzi de scriere, ceea ce poate fi util dacă serverul primește un număr nelimitat de comenzi fără legătură.

Exportați linkuri simbolice și fișiere de dispozitiv. La exportul unei ierarhii de directoare care conține legături simbolice, obiectul link trebuie să fie accesibil sistemului client (la distanță), cu alte cuvinte, una dintre următoarele reguli trebuie să fie adevărată:

• obiectul link trebuie să existe pe sistemul de fișiere client
• trebuie să exportați și să montați obiectul de referință

Fișierul dispozitivului se referă la interfață Kernel-urile Linux. Când exportați un fișier de dispozitiv, această interfață este exportată. Dacă sistemul client nu are un dispozitiv de același tip, dispozitivul exportat nu va funcționa.

Pe sistemul client, atunci când montați obiecte NFS, puteți utiliza opțiunea nodev, astfel încât fișierele dispozitivului din directoarele montate să nu fie utilizate.

Funcțiile implicite pot varia între sisteme și pot fi găsite în /var/lib/nfs/etab. După descrierea directorului exportat în /etc/exports și repornirea serverului NFS, toate funcțiile lipsă (a se citi: funcții implicite) vor fi reflectate în fișierul /var/lib/nfs/etab.

Funcții pentru afișarea (potrivirii) ID-urilor de utilizator

Pentru o mai bună înțelegere a următoarelor, vă sfătuiesc să citiți articolul Gestionarea utilizatorilor Linux. Fiecare utilizator Linux are propriul său UID și GID principal, care sunt descrise în fișierele /etc/passwd și /etc/group.

Serverul NFS presupune că sistemul de operare al gazdei la distanță a autentificat utilizatorii și le-a atribuit UID-ul și GID-ul corect. Exportarea fișierelor oferă utilizatorilor sistemului client același acces la acele fișiere ca și cum ar fi fost logați direct pe server. În consecință, atunci când un client NFS trimite o cerere către server, serverul folosește UID și GID pentru a identifica utilizatorul pe sistemul local, ceea ce poate duce la unele probleme:

Următoarele funcții stabilesc regulile pentru afișarea utilizatorilor de la distanță în cei locali:

Un exemplu de utilizare a unui fișier de mapare utilizator:

ARCHIV ~ # cat /etc/file_maps_users # Maparea utilizatorului # uid comentariu local la distanță 0-50 O mie doi # utilizatori de mapare cu UID la distanță 0-50 la UID local O mie doi gid 0-50 O mie doi # utilizatori de mapare cu /span GID de la distanță 0-50 la GID local 1002

Managementul serverului NFS

Serverul NFS este gestionat folosind următoarele utilitare:

• nfsstat
• showmmontare sigură (nesigură).
• exportfs

nfsstat: statistici NFS și RPC

Utilitarul nfsstat vă permite să vizualizați statisticile serverelor RPC și NFS. Funcțiile comenzii pot fi găsite în man nfsstat.

showmount: afișați informații despre starea NFS

utilitarul showmount interogează rpc.mountd pe gazda la distanță despre sistemele de fișiere montate. În mod implicit, este returnată o listă sortată de clienți. Chei:

• --toate- este afișată o listă de clienți și puncte de montare indicând locul unde clientul a montat directorul. Este posibil ca aceste informații să nu fie de încredere.
• --directoare- este afișată o listă de puncte de montare
• --exporturi- o listă a sistemelor de fișiere exportate este dată pe baza credințelor nfsd

Când rulați showmount fără argumente, informațiile despre sistemele cărora li se permite montarea vor fi tipărite pe consolă local colecții. De exemplu, gazda ARCHIV ne oferă o listă de directoare exportate cu adrese IP ale gazdelor cărora li se permite să monteze colecțiile desemnate:

FIȘIERE ~ # showmount --exports archive Exportați lista pentru arhivă: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

Dacă specificați numele de gazdă/IP în argument, vor fi afișate informații despre această gazdă:

ARCHIV ~ # showmount files clnt_create: RPC: Programul nu este înregistrat # acest mesaj ne spune că NFSd nu rulează pe gazda FILES

exportfs: gestionați directoarele exportate

Această comandă servește colecții exportate, date din fișier /etc/exports, ar fi mai corect să scrieți că nu servește, ci se sincronizează cu fișierul /var/lib/nfs/xtabși le elimină pe cele inexistente din xtab. exportfs se face atunci când rulează demonul nfsd cu argumentul -r. Utilitarul exportfs în modul kernel 2.6 vorbește cu rpc.mountd imp prin fișierele din directorul /var/lib/nfs/ și nu vorbește direct cu nucleul. Fără trăsături, afișează o listă a sistemelor de fișiere exportate în prezent.

proprietățile exportfs:

• [client:nume-director] - adăugați sau eliminați sistemul de fișiere desemnat pentru clientul desemnat)
• -v - afișează mai multe informații
• -r - reexportă toate colecțiile (sincronizează /etc/exports și /var/lib/nfs/xtab)
• -u - elimina din lista de exportate
• -a - adăugați sau eliminați toate sistemele de fișiere
• -o - funcții separate prin virgule (similar cu opțiunile utilizate în /etc/exports; adică puteți schimba funcțiile sistemelor de fișiere deja montate)
• -i - nu utilizați /etc/exports când adăugați, doar proprietățile liniei de comandă curente
• -f - resetează lista sistemelor exportate în kernel 2.6;

Client NFS

Înainte de a accesa un fișier pe un sistem de fișiere la distanță, clientul trebuie să montați-lși primiți de la server indicatorul spre ea. Montare NFS se poate face folosind comenzi de montare sau folosind unul dintre dispozitivele de montare automate care prolifera (amd, autofs, automount, supermount, superpupermount). Procesul de instalare este perfect demonstrat în ilustrația de mai sus.

Pe Clienți NFS nu este nevoie să eliberezi vreun demoni, funcțiile clientului realizează un modul kernel kernel/fs/nfs/nfs.ko, care este folosit la montarea unui sistem de fișiere la distanță. Colecțiile exportate de pe server pot fi instalate pe client în următoarele moduri:

• manual folosind comanda mount
• automat la pornire, la montarea sistemelor de fișiere prezentate în /etc/fstab
• folosind automat demonul autofs

Nu voi lua în considerare a 3-a metodă cu autofs în acest articol, din cauza cantității mari de informații. Poate că va fi o descriere separată în articolele următoare.

Montarea sistemului de fișiere de rețea cu comanda mount

Un exemplu de utilizare a comenzii mount este prezentat în comenzile post Block Device Control. Aici mă voi uita la un exemplu de comandă mount pentru montarea unui sistem de fișiere NFS:

FIȘIERE ~ # mount -t nfs arhiv:/archiv-small /archivs/archiv-small FIȘIERE ~ # mount -t nfs -o ro arhiv:/archiv-big /archivs/archiv-big FIȘIERE ~ # mount ..... .. arhiv:/archiv-small pe /archivs/archiv-small tip nfs (rw,addr=10.0.0.6) arhiv:/archiv-big pe /archivs/archiv-big tip nfs (ro,addr=10.0.0.6)

Prima comandă montează directorul exportat /archiv-small pe serverul de arhivare la punctul de montare local /archivs/archiv-small cu opțiuni implicite (cu alte cuvinte, citire-scriere).

Cu toate că comanda de montareîn cele mai recente distribuții se poate gândi la ce tip de sistem de fișiere este folosit chiar și fără a specifica tipul, dar totuși specifică parametrul -t nfs este mai bun. A doua comandă montează directorul exportat /archiv-big pe serverul de arhive în directorul local /archivs/archiv-big cu opțiunea de numai citire (ro). comanda de montare fără caracteristici ne arată clar rezultatul montării. Pe lângă funcția de numai citire (ro), pot fi specificate și altele funcțiile principale la montarea NFS:

• nosuid- Această funcție interzice execuția programelor setuid din directorul montat.
• nodev(fără dispozitiv - nu dispozitiv) - Această funcție interzice utilizarea caracterelor și blochează fișierele speciale ca dispozitive.
• blocare (nolock)- Permite blocarea NFS (implicit). nolock dezactivează blocarea NFS (nu rulează lockd) și este convenabil atunci când lucrați cu servere mai vechi care nu acceptă blocarea NFS.
• mounthost=nume- Numele gazdei pe care rulează NFS mountless - mountd.
• mountport=n - Portul folosit de mountd imp.
• port=n- portul folosit pentru conectarea la serverul NFS (implicit este 2049 dacă rpc.nfsd nu este înregistrat pe serverul RPC). Dacă n=0 (implicit), atunci NFS trimite o solicitare către portmap de pe server pentru a găsi portul.
• dimensiunea=n(citiți dimensiunea blocului - citiți dimensiunea blocului) - Numărul de octeți citiți la un moment dat de pe serverul NFS. Standard - 4096.
• wsize=n(write block size - write block size) - Numărul de octeți scriiți simultan pe serverul NFS. Standard - 4096.
• tcp sau udp- Pentru a monta NFS, utilizați protocolul TCP sau, respectiv, UDP.
• bg- Dacă pierdeți accesul la server, repetați testele în fundal pentru a nu întrerupe procesul de pornire a sistemului.
• fg- Dacă pierdeți accesul la server, repetați testele în modul prioritar. Această opțiune poate bloca procesul de pornire a sistemului prin repetarea încercărilor de montare. Din acest motiv, parametrul fg este folosit în principal pentru depanare.

Funcții care afectează memorarea în cache a atributelor pe monturile NFS

Atributele fișierului, stocat în inod ( inoduri), cum ar fi timpul de modificare, dimensiunea, link-uri dure, proprietar, sunt de obicei modificate ocazional pentru fișierele obișnuite și chiar mai rar pentru directoare. Multe programe, cum ar fi ls, accesează fișierele doar în citire și nu modifică atributele sau conținutul fișierelor, ci risipesc resursele sistemului cu operațiuni costisitoare de rețea.

Pentru a evita irosirea resurselor inutile, poți stocați în cache aceste atribute. Nucleul folosește timpul de modificare a unui fișier pentru a determina dacă memoria cache este învechită, comparând timpul de modificare din cache și timpul de modificare a fișierului însuși. Memoria cache a atributelor este actualizată periodic în conformitate cu acești parametri:

• ac (noac)(attribute cache - attribute cache) - Permite memorarea în cache a atributelor (în mod implicit). Deși noac încetinește serverul, evită învechirea atributelor atunci când mai mulți clienți scriu în mod activ informații într-o ierarhie comună.
• acdirmax=n(maximum fișierul directorului cache al atributelor - stocarea în cache maximă a atributelor pentru un fișier director) - Numărul maxim de secunde pe care NFS le așteaptă înainte de a actualiza atributele directorului (implicit Șaizeci de secunde)
• acdirmin=n(minimum fișierul directorului cache al atributelor - cache minim al atributelor pentru un fișier director) - Un număr mic de secunde pe care NFS le așteaptă înainte de a actualiza atributele directorului (implicit 30 sec.)
• acregmax=n(maximum pentru fișierul obișnuit în cache de atribute - stocarea în cache maximă a atributelor pentru un fișier obișnuit) - Numărul maxim de secunde pe care NFS le așteaptă înainte de a actualiza atributele unui fișier obișnuit (implicit: șaizeci de secunde)
• acregmin=n(minimum al fișierului obișnuit din memoria cache a atributelor - cache minim al atributelor pentru un fișier obișnuit) - Un număr mic de secunde pe care NFS le așteaptă înainte de a actualiza atributele unui fișier obișnuit (implicit Trei secunde)
• actimeo=n(atribut cache timeout - atribut cache timeout) - Înlocuiește valorile pentru toate opțiunile de mai sus. Dacă actimeo nu este specificat, atunci valorile de mai sus preiau valorile implicite.

Funcții de tratare a erorilor NFS

Următoarele funcții controlează ce face NFS atunci când nu există niciun răspuns de la server sau când apar erori I/O:

• fg(bg)(prim-plan - prim-plan, fundal - fundal) - Creați probe de montare NFS nereușite în prim-plan/fond.
• greu moale)- afișează mesajul „serverul nu răspunde” la consolă când este atins timeout-ul și continuă montarea testelor. Cu această funcție moale- în timpul unui timeout, raportează o eroare I/O programului care a apelat operația. (se recomandă să nu folosiți opțiunea soft)
• nointr (intr)(fără întrerupere) - Nu permite semnalelor să întrerupă operațiunile de fișiere într-o ierarhie de directoare montată greu atunci când este atins un timeout mare. intr- permite întreruperea.
• retrans=n(valoare de retransmisie) - După n timeout-uri mici, NFS generează un timeout mare (implicit 3). Un timeout mare oprește operațiunile sau tipărește un mesaj „serverul nu răspunde” pe consolă, în funcție de dacă este specificată funcția hard/soft.
• reîncercați=n(valoare de reîncercare) - Numărul de minute în care serviciul NFS va repeta operațiunile de montare înainte de a renunța (implicit 10000).
• timeo=n(valoare timeout - valoare timeout) - Numărul de 10 de secundă de așteptat serviciu NFSînainte de retransmitere în caz de RPC sau timeout mic (implicit 7). Această valoare crește cu fiecare timeout până la o valoare mai mare de 60 de secunde sau până când apare un timeout mare. În cazul unei rețele ocupate, a unui server lent sau când cererea trece prin mai multe routere sau gateway-uri, creșterea acestei valori poate îmbunătăți performanța.

Montare automată NFS la pornire (descrierea sistemelor de fișiere în /etc/fstab)

Am atins descrierea fișierului /etc/fstab în articolul corespunzător. În exemplul curent voi analiza câteva exemple de montare a fișierelor sisteme NFS cu o descriere a opțiunilor:

FIȘIERE ~ # cat /etc/fstab | grep nfs arhiv:/archiv-small /archivs/archiv-small nfs rw,timeo=4,rsize=16384,wsize=16384 Null Null nfs-server:/archiv-big /archivs/archiv-big nfs rw,timeo=50 ,hard,fg Zero 0

Primul exemplu montează sistemul de fișiere /archiv-small de la gazda arhiv la punctul de montare /archivs/archiv-small, tipul sistemului de fișiere este specificat ca nfs (trebuie specificat întotdeauna pentru acest tip), sistemul de fișiere este montat cu opțiunea de citire-scriere (rw).

Gazda arhivei este conectată printr-un canal local rapid, astfel încât pentru a crește performanța, parametrul timeo a fost redus, iar valorile rsiize și wsize au fost semnificativ crescute. Câmpurile pentru programele dump și fsck sunt setate la zero, astfel încât aceste programe să nu utilizeze un sistem de fișiere montat pe NFS.

Al doilea exemplu montează sistemul de fișiere /archiv-big de la gazda serverului nfs. Deoarece Suntem conectați la gazda serverului nfs printr-o conexiune lentă, parametrul timeo este crescut la 5 secunde (50 10 de secundă), iar parametrul hard este, de asemenea, setat greu, astfel încât NFS să continue să remonteze sistemul de fișiere după o perioadă lungă de timp. timeout, parametrul fg este de asemenea setat, astfel încât atunci când sistemul pornește și gazda nfs-server nu este disponibilă, acesta să nu se înghețe.

Înainte de a salva configurațiile în /etc/fstab, asigurați-vă că încercați să montați manual și asigurați-vă că totul funcționează!!!

Performanță NFS îmbunătățită

Performanța NFS poate fi afectată de mai multe lucruri, mai ales atunci când rulează pe conexiuni lente. Când lucrați cu conexiuni lente și puternic încărcate, este mai bine să utilizați parametrul hard, astfel încât intervalele de timp să nu facă ca programele să nu mai funcționeze. Dar trebuie să luați în considerare faptul că, dacă montați sistemul de fișiere prin NFS cu parametrul hard prin fstab și gazda la distanță nu este accesibilă, atunci când porniți sistem va avea loc congelare.

De asemenea, una dintre cele mai ușoare modalități de a crește performanța NFS este creșterea numărului de octeți transferați la un moment dat. Dimensiunea de patru mii nouăzeci și șase de octeți este foarte mică pentru conexiunile rapide moderne, creșterea acestei valori la Opt mii 100 nouăzeci și doi sau mai mult este posibilă experimental găsi cea mai bună viteză.

De asemenea, nu trebuie pierdut din vedere funcții de timeout. NFS așteaptă un răspuns la transferul de date în perioada de timp specificată în funcția timeo dacă nu se primește un răspuns în acest timp, atunci se efectuează un transfer repetat;

Dar în conexiunile ocupate și lente, acest timp poate fi mai mic decât timpul de răspuns al serverului și capacitatea canalului de comunicație, ceea ce duce la retransmisii inutile care încetinesc activitatea În mod implicit, timeo este de 0,7 secunde (700 de milisecunde). după niciun răspuns timp de șapte sute de ms, serverul va retransmite și va dubla timpul de așteptare la 1,4 secunde, creșterea timpului va continua la o valoare mai mare de șaizeci de secunde. În continuare, în funcție de parametrul hard/soft, va avea loc o anumită acțiune (vezi mai sus).

Puteți selecta cel mai bun timp pentru o anumită valoare a pachetului transmis (valori rsiize/wsize) folosind comanda ping:

FIȘIERE ~ # ping -s 30 două mii șapte sute șaizeci și opt arhiv PING arhiv.DOMAIN.local (10.0.0.6) 32768(32796) octeți de date. 30 două mii șapte sute 70 6 octeți din archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0,931 ms 30 două mii șapte sute 70 6 octeți din archiv.domain.local (10.0.0.6): icmp_req= 2 ttl=64 time=0,958 ms 30 două mii șapte sute 70 6 octeți din archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1,03 ms 30 două mii șapte sute 70 6 octeți din arhivă .domain.local (10.0.0.6): icmp_req=4 ttl=64 time=1,00 ms 30 două mii șapte sute 70 6 octeți din archiv.domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1,08 ms ^C --- statistici ping arhiv.DOMAIN.local --- 5 pachete transmise, 5 primite, 0% pierdere de pachete, timp 4006ms rtt min/avg/max/mdev = 0.931/1.002/1.083/0.061 ms

După cum puteți vedea, atunci când trimiteți un pachet de dimensiunea 30 două mii șapte sute șaizeci și opt (32Kb), timpul său de călătorie de la client la server și înapoi plutește în jur de O milisecundă. Dacă acest timp depășește două sute de ms, atunci ar trebui să vă gândiți la creșterea valorii timeo, astfel încât să depășească valoarea de schimb de trei până la patru ori. Prin urmare, este mai bine să faceți acest test în timpul incarcatura grea retelelor

Lansarea NFS și configurarea paravanului de protecție

Nota a fost copiata de pe blogul http://bog.pp.ru/work/NFS.html, pentru care multumesc mult!!!

Rulați serverul NFS, montați, blocați, cota și starea cu porturi „corecte” (pentru firewall)

• este mai bine să demontați mai întâi toate resursele de pe clienți
• opriți și dezactivați pornirea rpcidmapd dacă nu este planificat NFSv4: chkconfig --level Trei sute 40 5 rpcidmapd off service rpcidmapd stop
• dacă este necesar, permiteți pornirea serviciilor portmap, nfs și nfslock: chkconfig --levels Trei sute 40 5 portmap/rpcbind pe chkconfig --levels Trei sute 40 5 nfs pe chkconfig --levels Trei sute 40 5 nfslock activat
• dacă este necesar, opriți serviciile nfslock și nfs, porniți portmap/rpcbind, descărcați modulele service nfslock stop service nfs stop service portmap start # service rpcbind start umount /proc/fs/nfsd service rpcidmapd stop rmmod nfsd service autofs stop # undeva mai târziu trebuie rulat rmmod nfs rmmod nfs_acl rmmod lockd
• deschide porturi în iptables
  • pentru RPC: UDP/111, TCP/111
  • pentru NFS: UDP/2049, TCP/2049
  • pentru rpc.statd: UDP/4000, TCP/4000
  • pentru blocare: UDP/4001, TCP/4001
  • pentru mountd: UDP/4002, TCP/4002
  • pentru rpc.rquota: UDP/4003, TCP/4003
• pentru serverul rpc.nfsd, adăugați linia RPCNFSDARGS="--port 2049" la /etc/sysconfig/nfs
• pentru serverul de montare, adăugați linia MOUNTD_PORT=4002 la /etc/sysconfig/nfs
• pentru funcția rpc.rquota pentru versiuni noi, trebuie să adăugați linia RQUOTAD_PORT=4003 la /etc/sysconfig/nfs
• pentru funcția rpc.rquota este necesar pentru versiunile mai vechi (la urma urmei, trebuie să aveți pachetul de cotă 3.08 sau mai nou) adăugați la /etc/services rquotad 4003/tcp rquotad 4003/udp
• va verifica caracterul adecvat al /etc/exports
• rulați serviciile rpc.nfsd, mountd și rpc.rquota (rpcsvcgssd și rpc.idmapd sunt lansate în același timp, dacă vă amintiți să le ștergeți) service nfsd start sau în versiuni noi service nfs start
• pentru serverul de blocare pentru sisteme noi, adăugați liniile LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001 la /etc/sysconfig/nfs
• pentru serverul de blocare pentru sisteme mai vechi, adăugați direct în /etc/modprobe[.conf]: opțiuni lockd nlm_udpport=4001 nlm_tcpport=4001
• legați serverul de stare rpc.statd la portul Patru Mii (pentru sisteme mai vechi, rulați rpc.statd cu cheia -p 4000 în /etc/init.d/nfslock) STATD_PORT=4000
• porniți serviciile lockd și rpc.statd service nfslock start
• asigurați-vă că toate porturile sunt legate în mod normal folosind „lsof -i -n -P” și „netstat -a -n” (unele dintre porturi sunt folosite de modulele kernel pe care lsof nu le vede)
• dacă înainte de „reconstruire” serverul a fost folosit de clienți și nu au putut fi demontați, atunci va trebui să reporniți serviciile de montare automată pe clienți (am-utils, autofs)

Exemplu de configurare pentru server și client NFS

Configurare server

Dacă doriți să faceți directorul dvs. partiționat NFS public și inscriptibil, puteți utiliza opțiunea all_squash în combinație cu opțiunile anonuid și anongid. De exemplu, pentru a seta permisiuni pentru utilizatorul „nimeni” din grupul „nimeni”, puteți face următoarele:

ARCHIV ~ # cat /etc/exports # Acces de citire și scriere pentru client pe 192.168.0.100, cu acces rw pentru utilizatorul Ninety-nine cu gid Ninety-nine /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid = 99)) # Acces de citire și scriere pentru client pe 192.168.0.100, cu acces rw pentru utilizatorul Nouăzeci și nouă cu gid Nouăzeci și nouă /fișiere 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

Aceasta înseamnă, de asemenea, că, dacă doriți să permiteți accesul la un director desemnat, nobody.nobody trebuie să fie proprietarul directorului partajat:

# chown -R nimeni.nimeni /fișiere

Configurare client

Pe client, trebuie să montați directorul la distanță într-un mod convenabil, de exemplu cu comanda mount:

FIȘIERE ~ # mount -t nfs archive:/files /archivs/files

rezumat

Puff... Articolul s-a terminat. Momentan am studiat ce este sistemul de fișiere de rețeași cum să-l mănânc, în următorul articol voi încerca să fac un HOWTO cu autentificare Kerberos. Sper că materialul a fost inteligibil și necesar.

Mă bucur să văd completările și comentariile tale!

NFS HOWTO, nfs.sourceforge, man nfs? man mount, omul exportă

RFC O mie nouăzeci și patru - NFSv1, v2
RFC O mie opt sute treisprezece - NFSv3
RFC Trei mii 500 30 - NFSv4
RFC 5 mii 600 șaizeci și unu - NFSv4.1
NFS HOWTO
nfs.sourceforge.net
man mount
omul exportă