Protocolul NFS. Network File System (NFS) - sistem de fișiere de rețea

Când vine vorba de rețele de calculatoare, puteți auzi adesea menționarea NFS. Ce înseamnă acest acronim?

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 în 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 proprietății Sun, a desemnat noua versiune ca v2, astfel încât interoperabilitatea între distribuții să poată fi testată și să se poată face o alternativă.

NFS v2

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

Interfața sistemului de fișiere virtual permite implementarea modulară reflectată într-un protocol simplu. Până în februarie 1986, au fost demonstrate soluții 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 de scriere sincronă. Până în iulie 1992, îmbunătățirile practice au rezolvat multe dintre deficiențele NFS versiunea 2, lăsând în același timp doar suport inadecvat pentru fișiere (dimensiuni și decalaje ale fișierelor pe 64 de biți).

• Suport pentru dimensiuni de fișiere de 64 de biți și decalaje pentru procesarea datelor 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 recuperarea acestora din nou;
• o 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 peste WAN, a început să permită transferul de fișiere de dimensiuni mari pentru vizualizare și scriere. Acest lucru a permis dezvoltatorilor să depășească limita de 8K impusă de User Datagram Protocol (UDP).

Ce este NFS v4?

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

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

Versiunea NFS 4.1 urmărește să ofere suport pentru protocol pentru exploatarea serverelor în cluster, inclusiv capacitatea de a oferi acces scalabil la fișiere simultan 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 adecvate pentru lucrul cu acesta. De exemplu, WebNFS, o extensie pentru versiunile 2 și 3, permite protocolului de acces la sistemul de fișiere în rețea să se integreze mai ușor în browserele web și să permită lucrul prin firewall-uri.

Diverse protocoale terțe au devenit asociate și 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);
• cotă la distanță (RQUOTAD), care permite utilizatorilor NFS să vizualizeze cotele de stocare pe serverele NFS;
• NFS over RDMA - o adaptare a NFS care utilizează accesul direct la memorie la distanță (RDMA) ca mediu de transmisie;
• NFS-Ganesha este un server NFS în spațiul utilizatorului care acceptă CephFS FSAL (Filesystem Abstraction Layer) folosind libcephfs.

Platforme

Sistemul de fișiere în rețea 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 sunt orientate mai ales către „shell-uri” asemănătoare Unix.

În același timp, 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 (client) are nevoie de acces la datele stocate pe altul (server NFS):

• Serverul implementează procese Network File System, pornite implicit ca nfsd, pentru a-și face datele disponibile public pentru clienți. Administratorul serverului determină cum să exporte numele directorului și opțiunile, 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 verificat. Configurația sa de rețea asigură că clienții corespunzători pot negocia cu acesta prin orice sistem firewall.
• Mașina client solicită acces la datele exportate, de obicei prin lansarea comenzii corespunzătoare. Interogează serverul (rpcbind) care utilizează portul NFS și ulterior se conectează la acesta.
• Dacă totul merge bine, utilizatorii de pe computerul client vor putea să vadă și să interacționeze cu sistemele de fișiere instalate pe server în cadrul opțiunilor permise.

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

Dezvoltare până în prezent

Până în secolul 21, protocoalele rivale DFS și AFS nu au obținut niciun succes comercial major asupra sistemului de fișiere de 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 finalizarea vânzărilor AFS și DFS.

La rândul său, în ianuarie 2010, Panasas a introdus NFS v 4.1, o tehnologie care îmbunătățește capacitățile de acces simultan la date. 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 de 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 acestora sub aceeași legătură cu serverul. Cu Network File System v 4.1, unele fișiere pot fi distribuite pe mai multe servere, dar participarea clientului la separarea metadatelor și a datelor este limitată.

În implementarea celui de-al patrulea kit de distribuție al protocolului NFS, serverul este un set de resurse sau componente de server; se presupune că acestea sunt controlate de serverul de metadate.

Clientul contactează în continuare același server MDS pentru a accesa cu crawlere sau a interacționa cu spațiul de nume. Când mută fișiere către și de la server, poate interacționa direct cu setul de date aparținând grupului NFS.

Pentru distribuirea fișierelor într-o rețea locală, se pot distinge următoarele tehnologii (se iau în considerare sistemele bazate pe Linux):

• Network File System (NFS) - un protocol pentru accesul în rețea la sistemele de fișiere;
• Fișierele transferate prin protocolul Shell (FISH) este un protocol de rețea care utilizează sau RSH pentru a transfera fișiere între computere;
• Secure SHell FileSystem (SSHFS) - un client de sistem de fișiere pentru montarea dispozitivelor de disc pe sisteme la distanță, folosit pentru a interacționa cu un sistem la distanță SFTP;
• Samba este un pachet software care vă permite să accesați unități de rețea și imprimante pe diverse sisteme de operare folosind protocolul SMB / CIFS;

Această notă se va concentra asupra NFS.

NFS (sistem de fișiere de rețea) util atunci când trebuie să distribuiți fișiere/directoare tuturor celor din rețea. Accesați transparența folosind NFS Permite clienților să monteze un sistem de fișiere la distanță ca director local, iar sistemele de fișiere pot fi de diferite tipuri. Aceasta înseamnă că orice aplicație client care poate funcționa cu un fișier local poate funcționa la fel de bine cu un fișier conectat de NFS, fără modificări ale programului în sine.

La beneficii NFS pot fi atribuite:

Disponibil acum NFS v4.1, care a introdus o nouă caracteristică pNFS permițându-vă să paralelizați implementarea partajării fișierelor. Există, de asemenea, o extensie pentru NFS 2 și 3 - WebNFS ceea ce facilitează integrarea în browsere web și face posibilă funcționarea printr-un firewall.

Schema de lucru NFS protocol.

Instalarea și configurarea unui server NFS sub Linux

Verificați dacă sistemul acceptă NFS

Cat / proc / sisteme de fișiere | grep nfs

Sub Arch Linux serverul și clientul sunt în același pachet

Yaourt -S nfs-utils

Pentru a instala serverul ( nfs-kernel-server) și client ( nfs-comun) sub Ubuntu pachetele necesare

Sudo apt-get install nfs-kernel-server nfs-common portmap

Mai departe, în nota pentru IP-ul serverului va fi folosit 192.168.1.100 ... Pentru ca serverului să i se atribuie întotdeauna același IP, este necesar să se specifice distribuția unui anumit IP la o anumită adresă MAC în serverul DHCP (cel mai adesea un router). Sau deschideți serverul DNS local. De exemplu sau.

Adresa MAC poate fi găsită folosind ifconfig (câmp eter v Arch Linux).

NFSv4 presupune că există un director rădăcină în care se află deja fișierele de distribuție. De exemplu, / srv / nfs- radacina, / srv / nfs / audio- un director pentru distribuirea muzicii. Dacă nu respectați această nouă directivă în versiune 4 , atunci puteți primi o eroare la conectarea de către client:

Mount.nfs: acces refuzat de server în timpul instalării 192.168.1.100:/home/proft/torrents

Dacă tot doriți să utilizați abordarea fără server fără un director rădăcină pentru NFS, apoi la montare de către client, trebuie să specificați în mod explicit versiunea 3

# pentru comanda mount mount -o "vers = 3" 192.168.1.100:/home/proft/torrents / home / proft / nfs / torrents # pentru fstab 192.168.1.100:/home/proft/torrents / home / proft / nfs / torrents nfs soft, nfsvers = 3 0 0

voi folosi NFSv4 cu directorul rădăcină în / srv / nfs /și montarea subdirectoarelor folosind mount --bind.

Să presupunem că vrem

• distribui un director ~ / torrente Cu rw acces pentru dintre toateîn interiorul rețelei locale;
• distribui un director ~ / fotografii Cu ro acces pentru gazdă cu IP 192.168.1.101 ;

Mai întâi, să creăm directorul rădăcină și cele imbricate necesare.

Sudo mkdir -p / srv / nfs / (torrente, fotografii)

Montați directoarele existente torrente, fotografii v / srv / nfs.

# sudo vim / etc / fstab / home / proft / torrents / srv / nfs / torrents none bind 0 0 / home / proft / photos / srv / nfs / photos none bind 0 0

Hai să edităm / etc / exporturi care descrie toate directoarele partajate

# sudo vim / etc / exports # format fișier: directorul permit-hosts (opțiuni) / srv / nfs / torrents 192.168.1.1/24(rw,async) / srv / nfs / photos 192.168.1.101 (ro, async)

Rețineți că nu există spațiu între gazde permiseși (Opțiuni)... Prezența unui spațiu introduce o interpretare diferită a regulilor.

Optiuni Disponibile:

• ro (rw) - permite accesul numai în citire (citire/scriere);
• subtree_check (no_subtree_check) - în unele cazuri, trebuie să exportați nu întreaga secțiune, ci doar o parte a acesteia. În acest caz, serverul NFS ar trebui să efectueze validare suplimentară a solicitărilor clienților pentru a se asigura că aceștia încearcă să acceseze numai fișierele din subdirectoarele corespunzătoare. Un astfel de control al subarborelui ( verificări subarbore) încetinește ușor interacțiunea cu clienții, dar dacă o renunți, pot apărea probleme cu securitatea sistemului. Puteți elimina controlul unui subarboresc folosind opțiunea no_subtree_check... Opțiune subtree_check activarea unor astfel de controale se presupune implicit. Controlul subarborelui poate fi omis dacă directorul exportat coincide cu partiția discului;
• sync (async) - Indică faptul că serverul ar trebui să răspundă la solicitări numai după ce modificările făcute de acele solicitări sunt scrise pe disc. Opțiune asincron instruiește serverul să nu aștepte ca informațiile să fie scrise pe disc, ceea ce îmbunătățește performanța, dar scade fiabilitatea, deoarece dacă conexiunea este întreruptă sau echipamentul eșuează, este posibilă pierderea datelor;
• noaccess - interzice accesul la directorul specificat. Poate fi util dacă anterior ați dat acces tuturor utilizatorilor rețelei la un anume director, iar acum doriți să restricționați accesul în subdirector doar la unii utilizatori;
• no_root_squash - utilizator implicit rădăcină pe computerul client nu va avea aceleași drepturi la directorul de pe server. Această opțiune elimină această limitare;
• nuhide - NFS nu afișează automat resurse non-locale (de exemplu, montate folosind mount --bind), această opțiune activează afișarea acestor resurse;
• nesigur - utilizați porturi neprivilegiate (> 1024);

Lansarea serverului NFS

# sub archlinux sudo systemctl start rpc-idmapd.service rpc-mountd.service # sub ubuntu sudo /etc/init.d/nfs-kernel-server start

În viitor, la schimbarea fișierului de configurare, este suficient să-l recitiți cu comanda:

Sudo exportfs -rav

Comanda Rpcinfo -p | grep nfs vă permite să verificați dacă serverul a pornit cu succes.

client Linux

Instalare

# pentru archlinux yaourt -S nfs-utils # pentru ubuntu sudo apt-get install portmap nfs-common

Creați directoare pentru montarea resurselor de rețea torrenteși fotografii

Mkdir -p ~ / nfs / (torrente, fotografii)

Pentru montaj manual, executați

Sudo mount -t nfs -o rw, soft 192.168.1.100:/srv/nfs/torrents / home / proft / nfs / torrents sudo mount -t nfs -o rw, soft 192.168.1.100:/srv/nfs/photos / proft / nfs / fotografii

Opțiune moale indică anularea în liniște a încercărilor de a conecta mingea după o anumită perioadă de timp (timpul este stabilit de opțiunea retrans). Mai mult in man nfs.

Această metodă nu este foarte convenabilă, deoarece va trebui să executați aceste comenzi de fiecare dată după repornire. Să facem montarea automată.

Pentru montarea automată, editați fișierul / etc / fstab

# sudo vim / etc / fstab 192.168.1.100:/srv/nfs/torrents / home / proft / net / torrents nfs rw, soft 0 0 192.168.1.100:/srv/nfs/photos / home / proft / net / photos nf ro, soft 0 0

Dar această metodă are și dezavantajele sale, de exemplu, dacă serverul nu este disponibil, atunci încărcarea clientului se poate îngheța din cauza încercărilor de conectare la serverul NFS. Pentru a remedia acest lucru, vedeți mai jos despre AutoFS.

AutoFS - conectarea automată a resurselor de rețea

Este posibil să montați o resursă la distanță folosind AutoFS prima dată când este accesat și demontat automat când nu există activitate.

AutoFS folosește șabloane situate în / etc / autofs... Șablonul principal este numit auto.master, poate indica unul sau mai multe alte șabloane pentru anumite tipuri de media.

Instalare

# pentru archlinux yaourt -S autofs # pentru ubuntu sudo apt-get install autofs

Există mai multe moduri de a specifica modul de montare automată. Eu folosesc asta: in / acasă / profit / nfs este creat automat un director cu numele serverului NFS, în care sunt create automat directoarele disponibile pe server.

# sudo vim /etc/autofs/auto.master / home / proft / nfs /etc/autofs/auto.nfs --timeout = 60

Parametru suplimentar pauză setează numărul de secunde după care dispozitivul va fi demontat. Parametru fantomă indică faptul că resursele configurate vor fi întotdeauna afișate și nu numai atunci când sunt disponibile (această opțiune este activată implicit în AutoFS 5)

Descriem în /etc/autofs/auto.nfs Serverul NFS și directorul rădăcină.

# sudo vim /etc/autofs/auto.nfs nfsserver 192.168.1.100:/srv/nfs

Acum la primul apel / home / proft / nfs / torrents partajarea NFS va fi montată automat.

Să repornim serviciul autofs:

# sub archlinux sudo systemctl restart autofs # sub ubuntu sudo /etc/init.d/autofs restart

De asemenea, puteți specifica timpul de așteptare pentru disponibilitatea resursei NFS. Pentru a face acest lucru, trebuie să modificați valorile MOUNT_WAIT.

# sub archlinux # sudo vim /etc/conf.d/autofs MOUNT_WAIT = 5 # sub ubuntu sudo / etc / default / autofs MOUNT_WAIT = 5

Forțarea utilizării NFS v3

In unele cazuri NFSv4 poate fi lent. Pentru a remedia acest lucru, puteți forța utilizarea celei de-a treia versiuni.

Soluție convenabilă pentru accesarea unui sistem de fișiere distribuit

Sistemul de fișiere este o necesitate. Lucrăm pe computere care oferă acces la imprimante, camere, baze de date, senzori de la distanță, telescoape, compilatoare și telefoane mobile. Aceste dispozitive au puține în comun - în special, multe dintre ele au devenit realitate după ce internetul a devenit omniprezent (de exemplu, camerele electronice și dispozitivele mobile care acționează ca computere mici). Cu toate acestea, toți au nevoie de un sistem de fișiere pentru a stoca și a accesa în siguranță informațiile.

De obicei, nu ne interesează cum datele, aplicațiile care le folosesc și interfețele care ni le prezintă sunt stocate pe computerele în sine. Majoritatea utilizatorilor ar dori să vadă (și în mod justificat) sistemul de fișiere ca pe un perete care îi separă de metalul gol care stochează biți și octeți. Prin urmare, stivele de protocoale care conectează sistemele de fișiere sunt de obicei cutii negre pentru majoritatea utilizatorilor și, într-adevăr, programatori. În cele din urmă, totuși, conectarea în rețea a tuturor acestor dispozitive se rezumă la a permite schimbul de date între sistemele de fișiere.

Sisteme de fișiere de rețea și alte practici sacre

În multe privințe, schimbul de date nu este altceva decât copierea informațiilor pe distanțe lungi. Protocoalele de rețea nu au fost singurele mijloace prin care comunicarea universală a devenit posibilă. La urma urmei, fiecare sistem informatic trebuie să traducă datagramele în ceva pe care sistemul de operare de la celălalt capăt îl poate înțelege. TCP este un protocol de transfer foarte eficient, dar nu este optimizat pentru acces rapid la fișiere sau pentru controlul de la distanță al aplicației software.

Computing distribuit versus rețea

Protocoalele de rețea tradiționale au puțin de oferit pentru organizarea calculelor distribuite între computere și, în plus, între rețele. Doar programatorii nesăbuiți s-ar baza pe protocolul de date și pe cablurile optice pentru calculul paralel. De obicei ne bazăm pe un model secvenţial, în care, odată stabilită o conexiune, protocoalele de nivel de legătură încep să funcţioneze, efectuând o procedură de salut destul de complexă între plăcile de reţea. Calculul paralel și sistemele de fișiere distribuite nu se mai bazează pe IP sau Ethernet. În prezent, pur și simplu le putem ignora când vorbim despre performanță. Problemele de securitate, însă, sunt o chestiune diferită.

O piesă a puzzle-ului este modul în care accesul la fișiere este organizat pe un sistem informatic. Acum, pentru sistemul care accesează fișierele, este indiferent dacă fișierele necesare sunt disponibile pe un singur computer sau sunt localizate dintr-un anumit motiv pe mai multe computere. În prezent, semantica sistemului de fișiere și structurile de date ale sistemului de fișiere sunt două subiecte foarte diferite. Semantica sistemului de fișiere distribuit în stilul Plan 9 sau Andrew File System (AFS) ascunde modul în care fișierele sunt organizate sau modul în care sistemul de fișiere se mapează la hardware și la rețea. NFS nu ascunde neapărat modul în care fișierele și directoarele sunt stocate pe sistemele de fișiere la distanță, dar nici nu dezvăluie stocarea hardware reală a sistemelor de fișiere, directoarelor și fișierelor.

NFS: Rezolvarea problemei UNIX

Accesarea sistemului de fișiere distribuit, totuși, necesită puțin mai mult de câteva comenzi pentru a permite utilizatorilor să monteze un director care se află pe un alt computer din rețea. Sun Microsystems s-a confruntat cu această problemă acum câțiva ani, când a început să distribuie ceva numit Apeluri de procedură de la distanță(RPC) și NFS.

Principala problemă pe care Sun încerca să o rezolve era cum să conecteze mai multe mașini UNIX pentru a crea un singur mediu de lucru distribuit fără a fi nevoie să rescrie semantica sistemului de fișiere UNIX și să adauge prea multe structuri de date specifice sistemelor de fișiere distribuite - integritatea fiecărui sistem avea să fie păstrate.oferind în același timp utilizatorilor posibilitatea de a lucra cu directorul pe alt computer fără a provoca întârzieri sau restricții nedorite în fluxul lor de lucru.

Desigur, NFS face mai mult decât să ofere acces la fișierele text. De asemenea, puteți distribui aplicații „de pornire” prin NFS. Procedurile de securitate sunt folosite pentru a proteja rețeaua de interferența rău intenționată a fișierelor executabile. Dar cum se întâmplă exact asta?

NFS este RPC

NFS este definit în mod tradițional ca o aplicație RPC care necesită TCP pentru serverul NFS și fie TCP, fie alt protocol care nu este copleșitor pentru clientul NFS. Internet Engineering Task Force (IETF) a publicat un Request for Comments (RFC) pentru RPC în RFC 1832. Un alt standard vital pentru funcționarea unei implementări NFS sunt formatele de date utilizate de NFS; a fost publicat în RFC 1831 ca document de reprezentare externă a datelor (XDR).

Alte RFC-uri se ocupă de algoritmii de securitate și de criptare utilizați în schimbul de informații de autentificare în timpul sesiunilor NFS, dar ne vom concentra mai întâi pe mecanismele de bază. Unul dintre protocoalele care ne interesează este Protocolul de montare descrise în Anexa 1 la RFC 1813.

Acest RFC descrie protocoalele care permit funcționarea NFS, dar nu descrie modul în care funcționează NFS timp prezent... Ați învățat deja ceva important, și anume că protocoalele NFS sunt documentate ca standarde IETF. După ce cea mai recentă versiune a NFS a rămas blocată la numărul 3, protocoalele RPC nu au evoluat dincolo de faza de informații RFC și au fost în general percepute ca fiind în sfera de competență a (presupuse) uriașului grup de lucru de inginerie Sun Microsystems și a aromelor proprietare UNIX. Din 1985, Sun a lansat mai multe versiuni de NFS, anticipând cu câțiva ani majoritatea sistemelor de fișiere moderne. Sun Microsystems a transferat controlul NFS către IETF în 1998, iar cea mai mare parte a lucrărilor privind versiunea 4 a NSF (NFSv4) a fost efectuată sub auspiciile IETF.

Adică, atunci când lucrați cu RPC și NFS astăzi, lucrați cu o versiune care reflectă interesele companiilor și grupurilor non-Sun. Cu toate acestea, mulți ingineri Sun rămân profund interesați de dezvoltarea NFS.

NFS versiunea 3

NFS în încarnarea sa ca versiunea 3 (NFSv3) este apatrid (nu cu stare), dar NFSv4 o face. Această expresie fundamentală nu surprinde pe nimeni astăzi, deși lumea TCP / IP pe care este construit NFS este în cea mai mare parte apatridă - un fapt care ajută companiile de analiză a traficului și software de securitate să mă simt destul de bine.

Protocolul NFSv3 a trebuit să se bazeze pe mai multe protocoale suplimentare pentru a monta în mod transparent directoarele pe computere la distanță, astfel încât să nu depindă de mecanismele sistemului de fișiere pe care le foloseau. NFS nu a fost întotdeauna bun la asta. Un bun exemplu este protocolul Mount numit identificatorul inițial al fișierului, în timp ce protocolul Network Lock Manager a blocat fișierul. Ambele operațiuni au necesitat o stare curentă pe care NFSv3 nu a furnizat-o. În consecință, au existat interacțiuni complexe între straturile de protocol care nu au reflectat mecanisme similare de flux de date. În plus, când adăugați faptul că crearea fișierelor și a directoarelor este complet diferită în Microsoft® Windows® decât în ​​UNIX, situația devine și mai complicată.

Protocolul NFSv3 a trebuit să folosească porturi pentru a furniza unele dintre protocoalele sale auxiliare; aceasta oferă o imagine destul de complexă a porturilor, a straturilor de protocol și a problemelor de securitate asociate. Astăzi, acest model de funcționare a fost abandonat, iar toate operațiunile care au efectuat anterior implementări de protocol auxiliar prin porturi individuale sunt controlate de protocolul NFSv4 printr-un port binecunoscut.

NFSv3 era gata și pentru sistemele de fișiere Unicode - un avantaj care a rămas oarecum teoretic până la sfârșitul anilor 1990. Se potrivea bine cu semantica sistemului de fișiere UNIX și a fost motivul creării unor implementări de sisteme de fișiere concurente, cum ar fi AFS și Samba. Nu este surprinzător că suportul Windows a fost slab, dar serverele de fișiere Samba au oferit partajarea fișierelor în sistemele UNIX și Windows.

NFS versiunea 4

Protocolul NFSv4 este, după cum am observat, un protocol cu ​​stare. Câteva schimbări radicale au făcut posibil acest comportament. Am menționat deja că protocoalele de ajutor ar trebui apelate deoarece procesele la nivel de utilizator au fost eliminate. În schimb, toate operațiunile de deschidere a fișierelor și destul de multe apeluri RPC au fost implementate ca operațiuni de sistem de fișiere la nivel de kernel.

Toate versiunile NFS au definit fiecare unitate de lucru în ceea ce privește operațiunile client și server RPC. Fiecare cerere NFSv3 a necesitat un număr destul de semnificativ de apeluri RPC și porturi deschise pentru a returna rezultatul. Versiunea 4 a simplificat acest lucru prin introducerea conceptului de așa-numit compozit(compus) o operație care include un număr mare de operații asupra obiectelor din sistemul de fișiere. Efectul direct, desigur, a fost semnificativ mai puține apeluri RPC și mai puține date de transferat prin rețea, chiar dacă fiecare apel RPC a transportat de fapt mai multe date, făcând mult mai multă muncă. S-a estimat că apelurile RPC în NFSv3 au necesitat de cinci ori mai multe interacțiuni client-server în comparație cu procedurile RPC compuse.

RPC nu mai are de fapt acea importanță și, în esență, include câteva operațiuni care sunt încapsulate în stiva NFSv4. Această modificare a făcut ca stiva de protocoale să fie mult mai puțin dependentă de semantica sistemului de fișiere utilizat. Dar acest lucru nu înseamnă că operațiunile sistemului de fișiere pe alte sisteme de operare au fost ignorate: de exemplu, partajarea resurselor Windows necesită o stare persistentă între apeluri pentru a deschide resursa. Statefulness nu numai că facilitează analiza traficului, dar, atunci când este implementată la nivelul semanticii sistemului de fișiere, face operațiunile sistemului de fișiere mult mai controlabile. Apelurile de resurse deschise cu stat permit clienților să memoreze în cache datele fișierelor și să afirme care altfel ar avea loc pe server. În viața reală (unde clienții Windows sunt omniprezent), a face serverele NFS transparente și unificate cu resursele partajate Windows merită timpul pe care îl petreceți configurând configurația NFS.

Folosind NFS

Instalarea NFS este în general similară cu instalarea Samba. Pe partea de server, definiți sistemele de fișiere sau directoarele de exportat sau partajarea; partea client montează aceste directoare. Când un client la distanță montează un director NFS, directorul este accesibil la fel ca orice alt director din sistemul de fișiere local. Configurarea NFS pe un server este un proces simplu. Cel puțin, trebuie să creați sau să editați fișierul / etc / exports și să porniți demonul NFS. Pentru a configura un serviciu NFS mai sigur, trebuie să editați și fișierele /etc/hosts.allow și /etc/hosts.deny. Clientul NFS necesită doar comanda mount. Pentru mai multe informații și opțiuni, consultați documentația online Linux® (pagina de manual).

Serverul Nfs

Intrările din fișierul / etc / exporturi sunt clare. Pentru a partaja sistemul de fișiere, modificați fișierul / etc / exports și descrieți sistemul de fișiere (cu parametri) în următorul format general:

Parametri comuni

Există mai multe opțiuni generale disponibile pentru a vă personaliza implementarea NFS. Acestea includ:

• sigur: Acest parametru (implicit) folosește un port TCP/IP disponibil mai mic de 1024 pentru conexiunile NFS. Specificarea nesigură dezactivează acest lucru.
• rw: Acest parametru permite clienților NFS acces de citire/scriere. Accesul implicit este doar pentru citire.
• asincron: Această opțiune poate îmbunătăți performanța, dar poate provoca și pierderi de date atunci când serverul NFS este repornit fără a opri mai întâi demonul NFS. Setarea implicită este sincronizarea.
• no_wdelay: Această opțiune dezactivează întârzierea înregistrării. Dacă este setat în modul asincron, NFS ignoră acest parametru.
• nuhide: Dacă montați un director peste altul, vechiul director este de obicei ascuns sau pare gol. Pentru a dezactiva acest comportament, activați parametrul ascundere.
• no_subtree_check: Această opțiune dezactivează monitorizarea subdirectoarelor pentru unele verificări de securitate pe care este posibil să nu doriți să le ignorați. Setarea implicită este de a activa controlul subdirectoarelor.
• no_auth_nlm: Acest parametru, când este setat la insecure_locks, îi spune demonului NFS să nu se autentifice în timpul solicitărilor de blocare. Valoarea implicită este auth_nlm sau secure_locks.
• mp (punct de montare = cale): Declarând explicit acest parametru, NSF solicită ca directorul exportat să fie montat.
• fsid = num: Acest parametru este utilizat în mod obișnuit la configurarea unui sistem de recuperare în caz de dezastru NFS. Dacă doriți să implementați recuperarea în caz de accident pentru NFS, consultați documentația NFS.

Maparea utilizatorului

Prin maparea utilizatorilor NFS, puteți identifica un pseudo-utilizator sau un utilizator real și un grup cu utilizatorul care accesează volumul NFS. Utilizatorul NFS are drepturi de utilizator sau de grup pe care le permite maparea. Utilizarea unui singur utilizator (generic) și a unui grup pentru volume NFS oferă un nivel de protecție și flexibilitate fără efort administrativ semnificativ.

Când utilizați fișiere pe un sistem de fișiere montat pe NFS, accesul utilizatorului este de obicei restrâns. Aceasta înseamnă că utilizatorul accesează fișierele ca un utilizator anonim care are acces numai în citire la acele fișiere. Acest comportament este deosebit de important pentru utilizatorul root. Cu toate acestea, există situații în care doriți ca un utilizator să acceseze fișierele de pe un sistem la distanță ca root sau alt utilizator specific. NFS vă permite să specificați un utilizator (prin numărul de identificare a utilizatorului (UID) și numărul de identificare a grupului (GID)) pentru a accesa fișierele de la distanță și puteți dezactiva comportamentul normal de „suprimare” în mod implicit.

Opțiunile de afișare pentru utilizator includ:

• root_squash: Această opțiune împiedică utilizatorul root să acceseze volumul NFS montat.
• no_root_squash: Acest parametru permite utilizatorului root să acceseze volumul NFS montat.
• all_squash: Această opțiune, utilă pentru volumele NFS cu acces deschis, suprimă toate UID-urile și GID-urile și utilizează numai contul de utilizator anonim. Valoarea implicită este no_all_squash.
• anonuid și anongid: Acești parametri modifică UID-ul și GID-ul utilizatorului anonim în contul specificat.

Lista 1 prezintă exemple de intrări / etc / exporturi.

Listare 1. Exemple de intrări / etc / exporturi

Prima intrare exportă directorul / opt / fișiere pentru toate gazdele din rețeaua 192.168.0. Următoarea intrare exportă / opt / fișiere pentru o singură gazdă: 192.168.0.120. A treia intrare specifică gazda 192.168.0.125 și oferă acces de citire/scriere la fișierele cu drepturi de utilizator cu id de utilizator = 210 și id de grup = 100. Ultima intrare este folosită pentru directorul public și permite accesul numai în citire și numai sub contul de utilizator anonim.

Client NFS

Avertismente

Odată ce utilizați NFS pentru a monta un sistem de fișiere la distanță, acesta va face, de asemenea, parte din orice copie de rezervă a sistemului partajată pe care o efectuați pe computerul client. Acest comportament poate duce la rezultate potențial dăunătoare dacă nu excludeți directoarele montate atunci când faceți backup.

Pentru a utiliza NFS ca client, computerul client trebuie să ruleze rpc.statd și portmap. Puteți rula ps -ef pentru a verifica prezența acestor doi demoni. Dacă funcționează (cum ar trebui), puteți monta directorul exportat de server cu următoarea comandă generală:

În general, trebuie să rulați ca utilizator rădăcină atunci când montați sistemul de fișiere. Pe mașina de la distanță, puteți utiliza următoarea comandă (presupunând că serverul NFS are o adresă IP de 192.168.0.100):

Distribuția sistemului dumneavoastră vă poate solicita să specificați tipul de sistem de fișiere atunci când îl montați. Dacă da, utilizați comanda:

Directorul de la distanță ar trebui să se monteze fără probleme dacă ați configurat corect serverul. Acum rulați comanda cd pentru a trece în directorul / mnt, apoi comanda ls pentru a vizualiza fișierele. Pentru a face această montare permanentă, trebuie să modificați fișierul / etc / fstab și să creați o intrare similară cu următoarea:

Notă: Pentru mai multe informații despre / etc / intrările fstab, consultați ajutorul online fstab.

Critica la adresa NFS

Critica conduce la îmbunătățire

Critica privind securitatea NFS a fost motivul pentru multe dintre îmbunătățirile din NSFv4. Creatorii noii versiuni au luat măsuri reale pentru a întări securitatea interacțiunilor client-server. De fapt, au decis să implementeze un model complet nou al sistemului de protecție.

Pentru a înțelege modelul de securitate, ar trebui să fiți familiarizați cu API-ul. Servicii de securitate generice (GSS-API) versiunea 2, revizuirea 1. GSS-API este complet descris în RFC 2743, care este, din păcate, unul dintre RFC-urile mai dificil de înțeles.

Din experiența noastră cu NFSv4, știm că nu este foarte ușor să faceți sistemul de fișiere din rețea independent de sistemul de operare. Dar este și mai dificil să faci toate zonele sistemului de securitate independente de sistemul de operare și de protocoalele de rețea. Avem nevoie de amândouă, deoarece NFS trebuie să fie capabil să gestioneze un număr destul de mare de operațiuni ale utilizatorului și să facă acest lucru fără a ține cont de specificul comunicării prin protocolul de rețea.

Conexiunile dintre clienții NFS și servere sunt protejate de un așa-numit sistem de securitate (mai degrabă superficial). puternic RPC. NFSv4 folosește standardul ONCRPC (Open Network Computing Remote Procedure Call) așa cum este definit în RFC 1831. Sistemul de securitate a trebuit să fie consolidat, așa că în loc de autentificare simplă (cunoscută ca AUTH_SYS) ca parte obligatorie a protocolului NFSv4, o formă de sistem de securitate bazat pe GSS-API cunoscută ca RPCSEC_GSS... Cele mai importante mecanisme de securitate disponibile în NFSv4 sunt Kerberos versiunea 5 și LIPKEY.

În timp ce Kerberos are limitări atunci când este utilizat pe Internet, LIPKEY are un avantaj frumos - acționând ca un Secure Sockets Layer (SSL), solicită utilizatorilor numele de utilizator și parolele, evitând în același timp dependența TCP de SSL, o dependență pe care NFSv4 nu o face. acțiune. Puteți configura NFS pentru a implementa arome de securitate dacă RPCSEC_GSS nu este necesar. Versiunile anterioare de NFS nu aveau această capacitate și, prin urmare, nu puteau oferi securitate de calitate, integritatea datelor, cerințe de autentificare sau tipuri de criptare.

Protocolul NFSv3 a primit critici semnificative de securitate. Dacă serverele NFSv3 rulau prin TCP, era absolut realist să ruleze rețele NFSv3 pe Internet. Din păcate, au trebuit să fie deschise și mai multe porturi, ceea ce a dus la câteva găuri de securitate bine mediatizate. Făcând portul 2049 obligatoriu pentru NFS, a devenit posibil să se utilizeze NFSv4 cu firewall-uri fără a fi nevoie să acorde prea multă atenție la porturile pe care ascultau alte protocoale, cum ar fi protocolul Mount. Astfel, ștergerea protocolului Mount a avut mai multe efecte pozitive:

• Mecanisme obligatorii de autentificare puternică: NFSv4 a făcut ca mecanismele de autentificare puternice să fie obligatorii. Aromele Kerberos sunt destul de comune. Mecanismul de cheie publică pentru infrastructură inferioară (LIPKEY) trebuie, de asemenea, să fie susținut. NFSv3 nu a suportat niciodată mai mult decât criptarea standard UNIX pentru autentificarea accesului - aceasta a reprezentat o problemă majoră de securitate în rețelele mari.
• Liste obligatorii de control al accesului (ACL) în stil Microsoft Windows NT: Deși NFSv3 a permis criptarea puternică pentru autentificare, nu a folosit scheme de acces ACL în stil Windows NT. ACL-urile în stil POSIX (Portable Operating System Interface) au fost uneori implementate, dar nu au fost niciodată acceptate în general. NFSv4 a făcut ca ACL-urile în stil Windows NT să fie obligatorii.
• Mecanisme și stiluri de autentificare negociate: NFSv4 a oferit capacitatea de a negocia mecanisme și stiluri de autentificare. În NSFv3, era imposibil să faci mai mult decât să definești manual stilul de criptare de utilizat. Administratorul de sistem a trebuit apoi să negocieze protocoale de criptare și securitate.

NFS este încă înaintea concurenței?

NFSv4 înlocuiește NFSv3 pe majoritatea sistemelor UNIX și Linux. Ca sistem de fișiere de rețea, NSFv4 are puțini concurenți. Un concurent viabil ar fi Common Internet File System (CIFS) / Server Message Block (SMB), având în vedere că este prezent în toate variantele de Windows și (în prezent) Linux. AFS nu a avut niciodată prea multă influență comercială; a subliniat elementele sistemelor de fișiere distribuite care facilitează migrarea și replicarea datelor.

Versiunile NFS pregătite pentru Linux au fost lansate după ce nucleul a ajuns la versiunea 2.2, dar una dintre cele mai frecvente eșecuri ale versiunilor de nucleu Linux a fost că Linux a adoptat NFSv3 destul de târziu. De fapt, a trecut mult timp până când Linux a fost pe deplin capabil să suporte NSFv3. Odată cu apariția NSFv4, acest neajuns a fost eliminat rapid și a fost implementat suport complet pentru NSFv4 nu numai pe Solaris, AIX și FreeBSD.

În prezent, NFS este considerată o tehnologie matură, care are un avantaj destul de mare: este sigură și convenabilă - majoritatea utilizatorilor au considerat convenabil să folosească o singură conectare securizată pentru a accesa rețeaua și a-i folosi capacitățile, chiar și atunci când fișierele și aplicațiile sunt localizate pe sisteme diferite. . Deși acest lucru poate părea un dezavantaj în comparație cu sistemele de fișiere distribuite, care ascund structura sistemelor de utilizatori, rețineți că multe aplicații folosesc fișiere care se află pe sisteme de operare diferite și, prin urmare, pe computere diferite. NFS facilitează lucrul cu diferite sisteme de operare fără a fi nevoie să vă faceți prea multe griji cu privire la semantica sistemului de fișiere și la caracteristicile de performanță.

NFS: Un sistem de fișiere de rețea convenabil și pregătit pentru viitor

Sistem de fișiere de rețea Este o abstractizare a rețelei peste un sistem de fișiere obișnuit, permițând unui client la distanță să îl acceseze prin rețea în același mod ca atunci când accesează sistemele de fișiere locale. Deși NFS nu a fost primul sistem de fișiere în rețea, a evoluat pentru a deveni cel mai funcțional și mai solicitat sistem de fișiere în rețea din UNIX® astăzi. NFS permite mai multor utilizatori să partajeze un sistem de fișiere comun și centralizează datele pentru a minimiza cantitatea de spațiu pe disc necesară pentru a le stoca.

Acest articol începe cu o scurtă prezentare a istoriei NFS, apoi trece la explorarea arhitecturii NFS și a modului în care aceasta va evolua.

O scurtă istorie a NFS

Primul sistem de fișiere de rețea a fost numit FAL (File Access Listener) și a fost dezvoltat în 1976 de către DEC (Digital Equipment Corporation). A fost o implementare a protocolului de acces la date (DAP) și a făcut parte din suita de protocoale DECnet. Ca și în cazul TCP/IP, DEC a publicat specificații pentru protocoalele sale de rețea, inclusiv DAP.

NFS a fost primul sistem modern de fișiere de rețea construit pe IP. Prototipul său poate fi considerat un sistem de fișiere experimental dezvoltat de Sun Microsystems la începutul anilor 1980. Având în vedere popularitatea acestei soluții, protocolul NFS a fost introdus ca o specificație RFC și ulterior a evoluat în NFSv2. NFS sa impus rapid ca standard datorită capacității sale de a interopera cu alți clienți și servere.

Standardul a fost actualizat ulterior la versiunea NFSv3 definită în RFC 1813. Această versiune a protocolului a fost mai scalabilă decât versiunile anterioare și a acceptat fișiere mai mari (peste 2 GB), scriere asincronă și TCP ca protocol de transport. NFSv3 stabilește direcția pentru sistemele de fișiere pentru rețelele cu arie largă (WAN). În 2000, ca parte a specificației RFC 3010 (revizuită în versiunea RFC 3530), NFS a fost portat în mediul corporativ. Sun a introdus NFSv4 mai sigur cu suport stateful (versiunile anterioare de NFS nu suportau statefulness, adică erau apatride). În prezent, cea mai recentă versiune a NFS este versiunea 4.1, definită în RFC 5661, în care protocolul prin intermediul extensiei pNFS a fost adăugat suport pentru acces paralel pentru serverele distribuite.

Istoria dezvoltării NFS, inclusiv RFC-uri specifice care descriu versiunile sale, este prezentată în Figura 1.

În mod surprinzător, NFS a fost în dezvoltare de aproape 30 de ani. Este un sistem de fișiere de rețea extrem de stabil și portabil, cu scalabilitate, performanță și calitate remarcabile a serviciilor. Odată cu creșterea vitezei și scăderea latenței schimbului de date în rețea, NFS continuă să fie o modalitate populară de implementare a sistemului de fișiere în rețea. Chiar și cu rețele LAN, virtualizarea încurajează stocarea datelor în rețea pentru a oferi mașinilor virtuale mobilitate suplimentară. NFS acceptă, de asemenea, cele mai recente medii de calcul concepute pentru a optimiza infrastructurile virtuale.

Arhitectura NFS

NFS folosește un model standard de arhitectură client-server (așa cum se arată în Figura 2). Serverul este responsabil pentru implementarea sistemului de fișiere partajat și a stocării la care se conectează clienții. Clientul implementează o interfață cu utilizatorul într-un sistem de fișiere partajat montat în spațiul de fișiere local al clientului.

Figura 2. Implementarea modelului client-server în arhitectura NFS

Pe Linux®, un comutator de sistem de fișiere virtual (VFS) oferă mijloacele de a accepta mai multe sisteme de fișiere pe o singură gazdă (de exemplu, un sistem de fișiere ISO 9660 pe un CD-ROM și un sistem de fișiere ext3fs pe un hard disk local). Comutatorul virtual determină la ce unitate se face cererea și, prin urmare, ce sistem de fișiere ar trebui utilizat pentru a procesa cererea. Prin urmare, NFS are aceeași compatibilitate ca și alte sisteme de fișiere utilizate în Linux. Singura diferență cu NFS este că cererile I/O, în loc să fie procesate local pe gazdă, pot fi direcționate către rețea pentru execuție.

VFS determină că cererea pe care o primește este NFS și o transmite handler-ului NFS din nucleu. Hander-ul NFS procesează cererea I/O și o traduce într-o procedură NFS (OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE etc.). Aceste proceduri, descrise într-o specificație RFC separată, definesc comportamentul protocolului NFS. Procedura necesară este selectată pe baza cererii și executată folosind tehnologia RPC (Remote Procedure Call). După cum sugerează și numele, RPC permite efectuarea apelurilor de procedură între diferite sisteme. Serviciul RPC conectează cererea NFS cu argumentele sale și trimite rezultatul gazdei la distanță corespunzătoare, apoi monitorizează primirea și procesarea răspunsului pentru a-l returna solicitantului.

RPC include, de asemenea, un strat XDR important ( reprezentarea datelor externe- prezentarea independentă a datelor), care asigură că toți utilizatorii NFS folosesc același format pentru aceleași tipuri de date. Atunci când o platformă face o solicitare, tipul de date pe care îl folosește poate fi diferit de tipul de date utilizat pe gazda care procesează cererea. XDR preia munca de conversie a tipului în reprezentare standard (XDR), astfel încât platformele care utilizează arhitecturi diferite să poată interacționa și partaja sisteme de fișiere. XDR definește un format de biți pentru tipuri precum float și ordonarea octeților pentru tipuri precum matricele cu lungime fixă ​​și variabilă. Deși XDR este cunoscut în primul rând pentru utilizarea sa în NFS, această specificație poate fi utilă ori de câte ori trebuie să lucrați în același mediu cu arhitecturi diferite.

După ce XDR convertește datele în reprezentare standard, cererea este trimisă prin rețea folosind un protocol de transport specific. Implementările timpurii ale NFS foloseau UDP, dar astăzi TCP este folosit pentru mai multă robustețe.

Pe partea de server NFS, este utilizat un algoritm similar. Solicitarea urcă în stiva de rețea prin stratul RPC / XDR (pentru a converti tipurile de date conform arhitecturii serverului) și merge la serverul NFS, care este responsabil de procesarea cererii. Acolo, cererea este transmisă demonului NFS pentru a determina sistemul de fișiere țintă căruia îi este adresată și apoi intră din nou în VFS pentru a accesa acest sistem de fișiere pe discul local. O diagramă completă a acestui proces este prezentată în Figura 3. Sistemul de fișiere local al serverului este un sistem de fișiere standard Linux, de exemplu, ext4fs. De fapt, NFS nu este un sistem de fișiere în sensul tradițional al termenului, ci un protocol pentru accesul de la distanță la sistemele de fișiere.

Pentru rețelele cu latență lungă, NFSv4 oferă o procedură compusă specială ( procedeu compus). Această procedură vă permite să includeți mai multe apeluri RPC într-o singură solicitare pentru a minimiza suprasarcina de trimitere a cererilor prin rețea. De asemenea, această procedură implementează mecanismul funcțiilor de apel invers pentru primirea răspunsurilor.

Protocolul NFS

Când un client pornește cu NFS, primul pas este operația de montare, care constă în montarea sistemului de fișiere la distanță în spațiul local al sistemului de fișiere. Acest proces începe cu un apel la procedura de montare (una dintre funcțiile sistemului Linux), care este redirecționată prin VFS către componenta NFS. Apoi, folosind un apel RPC la funcția get_port de pe serverul la distanță, se determină numărul portului care va fi utilizat pentru montare și clientul trimite o cerere de montare prin RPC. Această solicitare de pe partea serverului este gestionată de un demon special rpc.mountd responsabil pentru protocolul de montare ( protocol de montare). Daemonul verifică dacă sistemul de fișiere solicitat de client se află în lista de sisteme disponibile pe serverul dat. Dacă sistemul solicitat există și clientul are acces la el, atunci descriptorul sistemului de fișiere este specificat în răspunsul procedurii de montare RPC. Clientul reține informații despre punctele de montare locale și la distanță și este capabil să facă cereri I/O. Protocolul de montare nu este impecabil din punct de vedere al securității, așa că NFSv4 utilizează în schimb apeluri interne RPC, care pot manipula și punctele de montare.

Pentru a citi un fișier, trebuie mai întâi să îl deschideți. Nu există nicio procedură OPEN în RPC; în schimb, clientul pur și simplu verifică dacă fișierul și directorul specificat există pe sistemul de fișiere montat. Clientul începe prin a face o cerere RPC GETATTR pentru director, care returnează atributele directorului sau un indicator că directorul nu există. În continuare, pentru a verifica existența fișierului, clientul face o cerere RPC LOOKUP. Dacă fișierul există, se face o solicitare RPC GETATTR pentru ca acesta să afle atributele fișierului. Folosind informațiile obținute din apelurile de succes LOOKUP și GETATTR, clientul creează un descriptor de fișier care este prezentat utilizatorului pentru cereri viitoare.

După ce fișierul este identificat pe sistemul de fișiere la distanță, clientul poate emite solicitări RPC READ. Această solicitare constă dintr-un descriptor de fișier, stare, offset și numărul de octeți de citit. Clientul folosește starea ( stat) pentru a determina dacă operația poate fi efectuată în momentul de față, adică. dacă fișierul este blocat. Decalaj ( decalaj) indică de unde să începeți citirea și contorul de octeți ( numara) determină câți octeți de citit. Ca urmare a unui apel RPC READ, serverul nu returnează întotdeauna atât de mulți octeți cât a fost solicitat, dar transmite întotdeauna împreună cu datele returnate câți octeți au fost trimiși către client.

Inovație în NFS

De cel mai mare interes sunt cele mai recente două versiuni de NFS - 4 și 4.1, care pot fi folosite pentru a studia cele mai importante aspecte ale evoluției tehnologiei NFS.

Înainte de apariția NFSv4, pentru realizarea sarcinilor de gestionare a fișierelor, cum ar fi montarea, blocarea etc. existau protocoale suplimentare speciale. În NFSv4, procesul de gestionare a fișierelor a fost simplificat la un singur protocol; în plus, deoarece această versiune UDP nu mai este folosită ca protocol de transport. NFSv4 include suport pentru semantica de acces la fișiere UNIX și Windows®, ceea ce permite NFS să se integreze în mod natural în alte sisteme de operare.

NFSv4.1 a introdus conceptul de NFS paralel(NFS paralel - pNFS). Pentru a oferi mai multă scalabilitate, NFSv4.1 implementează o arhitectură în care datele și metadatele ( marcaj) sunt distribuite pe dispozitive într-un mod similar cu sistemele de fișiere grupate. După cum este ilustrat, pNFS împarte ecosistemul în trei piloni: client, server și stocare. În acest caz, apar două canale: unul pentru transmiterea datelor, iar celălalt pentru transmiterea comenzilor de control. pNFS separă datele de metadatele care le descriu, oferind o arhitectură cu două canale. Când un client dorește să acceseze un fișier, serverul îi trimite metadate de „markup”. Metadatele conțin informații despre locația fișierului pe dispozitivele de stocare. Cu aceste informații, clientul poate accesa stocarea direct, fără a fi nevoit să interacționeze cu serverul, ceea ce îmbunătățește scalabilitatea și performanța. Când clientul termină de lucru la fișier, el confirmă modificările aduse fișierului și „markupul” acestuia. Dacă este necesar, serverul poate solicita metadatele de marcare de la client.

Odată cu introducerea pNFS, au fost adăugate câteva operațiuni noi la protocolul NFS pentru a sprijini acest mecanism. Metoda LayoutGet este folosită pentru a prelua metadatele de pe server, metoda LayoutReturn „eliberează” metadatele „capturate” de client, iar metoda LayoutCommit încarcă „markupul” primit de la client în depozit, astfel încât să fie disponibil pentru alte persoane. utilizatorii. Serverul poate revoca metadatele de la client folosind metoda LayoutRecall. Metadatele „marcate” sunt răspândite pe mai multe dispozitive de stocare pentru a oferi acces simultan și performanță ridicată.

Datele și metadatele sunt stocate în dispozitive de stocare. Clienții pot face solicitări directe I/O pe baza markup-ului rezultat, iar serverul NFSv4.1 stochează și gestionează metadatele. Această funcționalitate în sine nu este nouă, dar suportul pentru diferite metode de accesare a dispozitivelor de stocare a fost adăugat la pNFS. Astăzi pNFS acceptă utilizarea protocoalelor bloc (Fibre Channel), protocoalelor obiect și NFS în sine (nici măcar în formă pNFS).

NFS continuă să evolueze, iar cerințele NFSv4.2 au fost publicate în septembrie 2010. Unele dintre inovații sunt legate de migrarea observată a tehnologiilor de stocare către virtualizare. De exemplu, în mediile virtuale cu un hypervisor, duplicarea datelor este foarte probabilă (mai multe sisteme de operare citesc / scriu și memorează în cache aceleași date). Prin urmare, este de dorit ca sistemul de stocare în ansamblu să înțeleagă unde are loc duplicarea. Această abordare poate ajuta la conservarea spațiului cache al clientului și a capacității generale de stocare. NFSv4.2 sugerează utilizarea unei „hărți de blocuri a blocurilor partajate” pentru a rezolva această problemă. Pe măsură ce sistemele moderne de stocare sunt din ce în ce mai echipate cu propria lor putere de calcul internă, este introdusă copierea pe server pentru a reduce sarcina copierii datelor în rețeaua internă, atunci când aceasta poate fi făcută eficient pe dispozitivul de stocare în sine. Alte inovații includ stocarea în cache a sub-fișierelor pentru flash și recomandări pentru personalizarea I/O la nivelul clientului (de exemplu, folosind mapadvise).

Alternative NFS

Deși NFS este cel mai popular sistem de fișiere de rețea pe UNIX și Linux, există și alte sisteme de fișiere de rețea pe lângă acesta. Platforma Windows® folosește cel mai frecvent SMB, cunoscut și ca CIFS; totuși, Windows acceptă și NFS, la fel ca și Linux acceptă SMB.

Unul dintre cele mai noi sisteme de fișiere distribuite acceptate de Linux, Ceph, este proiectat de la zero pentru a fi un sistem de fișiere compatibil POSIX tolerant la erori. Mai multe informații despre Ceph pot fi găsite în secțiunea.

De menționat, de asemenea, sunt sistemele de fișiere OpenAFS (versiunea Open Source a Andrew Distributed File System dezvoltată la Carnegie Mellon University și IBM), GlusterFS (un sistem de fișiere distribuit de uz general pentru organizarea stocării de date scalabile) și Luster (un fișier masiv paralel în rețea). sistem pentru soluții cluster). Toate aceste sisteme open source pot fi folosite pentru a construi stocare distribuită.

Concluzie

Dezvoltarea sistemului de fișiere NFS continuă. Similar cu Linux, potrivit pentru suportarea soluțiilor bugetare, încorporate și de înaltă performanță, NFS oferă o arhitectură de soluții de stocare scalabile potrivite atât pentru persoane fizice, cât și pentru organizații. Privind calea pe care a parcurs NFS și dezvoltarea sa viitoare, devine clar că acest sistem de fișiere va continua să schimbe modul în care ne gândim la modul în care sunt implementate și utilizate tehnologiile de stocare a fișierelor.

Network File System NFS, sau Network File System, este un protocol popular de sistem de fișiere de rețea care permite utilizatorilor să monteze directoare de rețea la distanță pe mașina lor și să transfere fișiere între servere. Puteți utiliza spațiul pe disc pe o altă mașină pentru fișierele dvs. și puteți lucra cu fișiere aflate pe alte servere. De fapt, aceasta este o alternativă la partajarea Windows pentru Linux, spre deosebire de Samba, este implementată la nivel de kernel și funcționează mai stabil.

Acest articol vă va ghida prin instalarea nfs pe Ubuntu 16.04. Vom parcurge instalarea tuturor componentelor necesare, configurarea unui folder partajat, precum și conectarea folderelor de rețea.

După cum am menționat deja, NFS este un sistem de fișiere de rețea. Pentru a funcționa, aveți nevoie de un server care va găzdui folderul partajat și clienți care pot monta folderul de rețea ca un disc obișnuit în sistem. Spre deosebire de alte protocoale, NFS oferă acces transparent la fișierele de la distanță. Programele vor vedea fișierele ca într-un sistem de fișiere obișnuit și vor lucra cu ele ca și cu fișierele locale, nfs returnează doar partea solicitată a fișierului, în loc de întregul fișier, astfel încât acest sistem de fișiere va funcționa bine pe sisteme cu Internet rapid sau rețea locală .

Instalarea componentelor NFS

Înainte de a putea lucra cu NFS, trebuie să instalăm câteva programe. Pe mașina care va fi server, trebuie să instalați pachetul nfs-kernel-server, care va deschide nfs shares în ubuntu 16.04. Pentru a face acest lucru, rulați:

sudo apt install nfs-kernel-server

Acum să verificăm dacă serverul a fost instalat corect. Serviciul NFS ascultă conexiunile atât pentru TCP, cât și pentru UDP pe portul 2049. Puteți vedea dacă aceste porturi sunt de fapt utilizate cu comanda:

rpcinfo -p | grep nfs

De asemenea, este important să verificați dacă NFS este acceptat la nivel de kernel:

cat / proc / sisteme de fișiere | grep nfs

Vedem ce funcționează, dar dacă nu, trebuie să încărcați manual modulul kernel nfs:

Să adăugăm și nfs la pornire:

sudo systemctl enable nfs

Pe computerul client, trebuie să instalați pachetul nfs-common pentru a putea lucra cu acest sistem de fișiere. Nu trebuie să instalați componentele serverului, doar acest pachet va fi suficient:

sudo apt install nfs-common

Configurarea unui server NFS pe Ubuntu

Putem deschide accesul NFS la orice folder, dar haideți să creăm unul nou în acest scop:

folder_address client (opțiuni)

Adresa folderului este folderul pe care doriți să îl faceți disponibil în rețea. Client - adresa IP sau adresa de rețea din care poate fi accesat acest folder. Dar opțiunile sunt puțin mai complicate. Să luăm în considerare câteva dintre ele:

• rw- permite citirea și scrierea în acest folder
• ro- permite numai citire
• sincronizare- răspunde la următoarele solicitări numai atunci când datele sunt salvate pe disc (implicit)
• asincron- nu blocați conexiunile în timp ce datele sunt scrise pe disc
• sigur- utilizați numai porturi sub 1024 pentru conectare
• nesigur- utilizați orice porturi
• nohide- nu ascundeți subdirectoare când deschideți accesul la mai multe directoare
• rădăcină_dovleac- înlocuiți cererile de la root cu altele anonime
• all_squash- faceți toate cererile anonime
• anonuidși anongid- specifică uid-ul și gid-ul pentru utilizatorul anonim.

De exemplu, pentru folderul nostru, această linie ar putea arăta astfel:

/ var / nfs 127.0.0.1 (rw, sync, no_subtree_check)

Când totul a fost configurat, rămâne să actualizați tabelul de export NFS:

sudo exportfs -a

Gata, deschiderea bilelor nfs în ubuntu 16.04 este completă. Acum să încercăm să configuram clientul și să încercăm să-l montem.

conexiune NFS

Nu ne vom opri asupra acestei probleme în detaliu în articolul de astăzi. Acesta este un subiect destul de amplu care merită un articol separat. Dar voi spune câteva cuvinte.

Pentru a monta un folder de rețea, nu aveți nevoie de niciun client ubuntu nfs, trebuie doar să utilizați comanda mount:

sudo mount 127.0.0.1:/var/nfs/ / mnt /

Acum puteți încerca să creați un fișier în directorul conectat:

Ne vom uita și la sistemele de fișiere montate cu df:

127.0.0.1:/var/nfs 30G 6,7G 22G 24% / mnt

Pentru a dezactiva acest sistem de fișiere, trebuie doar să utilizați umountul standard:

sudo umount / mnt /

concluzii

Acest articol a analizat configurarea nfs ubuntu 16.04, după cum puteți vedea, totul se face foarte simplu și transparent. Conectarea partajărilor NFS se face în câteva clicuri folosind comenzi standard, iar deschiderea partajărilor NFS în ubuntu 16.04 nu este mult mai dificilă decât conectarea. Dacă aveți întrebări, scrieți în comentarii!

Intrări înrudite: