Instalarea și configurarea serverului NFS și a clientului NFS. Testarea modului de instalare NFS

Deci ce urmeaza? Cum să vizionați filme și să ascultați fișierele muzicale care au fost descărcate? Este chiar necesar să le inscripționați pe discuri și astfel să le transferați pe un computer cu GUI? Sau va trebui să le copiez prin SFTP lent? Nu! NFS vine în ajutor! Nu, aceasta nu este o serie de jocuri de curse, ci un sistem de fișiere de rețea.
Network File System (NFS) este un sistem de fișiere de rețea care permite utilizatorilor să acceseze fișiere și directoare situate pe computere la distanță ca și cum acele fișiere și directoare ar fi locale. Principalul avantaj al unui astfel de sistem este că stațiile de lucru individuale pot folosi mai puțin spațiul pe disc, deoarece datele partajate sunt stocate pe o mașină separată și sunt disponibile pentru alte mașini din rețea. NFS este o aplicație client-server. Adică, un client NFS trebuie instalat pe sistemul utilizatorului și pe computerele care le furnizează spatiu pe disc- Server NFS.

Instalare și Configurare NFS-servere (192.168.1.2)

1. Instalați. După ce v-ați conectat prin SSH la computerul server sau pur și simplu în consola acestuia, introduceți:

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

Aceasta va instala serverul NFS, precum și pachetul portmap necesar.

2. Configurați. Pentru a configura lista directoarelor pe care vrem să le deschidem și lista cui vrem să le deschidem, editați fișierul /etc/exports :

Sudo nano /etc/exports /data 192.168.1.1/24(rw,no_root_squash,async)

În exemplul de mai sus, am deschis un director pe server /date și subdirectoarele sale pentru utilizare partajată de către toate computerele cu IP: 192.168.1.1 - 192.168.1.255 cu drepturi de citire și scriere.

Alt exemplu:

/home/serg/ 192.168.1.34(ro,async)

Acest exemplu face posibil directorul principal serg utilizator în modul numai citire pentru un computer cu IP 192.168.1.34. Toate celelalte computere din rețea nu vor avea acces la acest director.

Optiuni Disponibile:

• ro - drepturi de numai citire. Nu trebuie să-l specificați, deoarece este instalat implicit;
• rw - oferă clienților permisiunea de scriere;
• no_root_squash - implicit, utilizatorul root de pe computerul client nu va avea acces la directoarele deschise de pe server. Cu această opțiune eliminăm această limitare. Din motive de siguranță, este mai bine să nu faci asta;
• noaccess - interzice accesul la directorul specificat. Poate fi util dacă ați setat anterior accesul pentru toți utilizatorii rețelei la un anumit director, iar acum doriți să restricționați accesul la subdirector doar la unii utilizatori.

Acum trebuie să reporniți nfs-kernel-server:

Sudo /etc/init.d/nfs-kernel-server restart

Dacă după aceasta doriți să schimbați ceva în fișier /etc/exports , apoi pentru ca modificările să aibă efect, rulați următoarea comandă:

Sudo exportfs -a

Toate. Serverul NFS este instalat și configurat. Puteți trece la clientul NFS.

Instalarea și configurarea clientului NFS

1. Instalare. Efectuăm următoarele în terminalul computerului, care se va conecta:

Sudo apt-get install portmap nfs-common

2. Configurare. Mai întâi, să creăm un director în care va fi montat folderul la distanță:

Cd ~ mkdir date

Puteți monta în două moduri - manual de fiecare dată sau scriind opțiuni de montare într-un fișier /etc/fstab.

Metoda 1: Montare manuală
Creați un fișier text pe desktop sau într-un alt folder:

Nano ~/Desktop/nfs-server-connect

Scriem în el:

#! /bin/bash sudo mount -t nfs -o ro,soft,intr 192.168.1.2:/data ~/data

Să-l facem executabil:

Chmod +x ~/Desktop/nfs-server-connect

Acum, când trebuie să mă conectez la server, rulez acest script în terminal, astfel încât să pot introduce parola pentru sudo.

Metoda 2: Adăugați în /etc/fstab
Deschide /etc/fstab:

Sudo nano /etc/fstab

Și adăugați o linie la sfârșitul fișierului:

192.168.1.2:/data ~/data nfs rw,hard,intr 0 0

Atenţie! În loc de 192.168.1.2:/data, introduceți IP-ul sau numele serverului și calea către directorul partajat. Opțiunile de montare pot fi modificate.

Opțiune greu leagă strict directorul de pe client de server și, dacă serverul se destramă, computerul se poate bloca și el. Opțiune moale, după cum sugerează și numele, nu este atât de categoric.

După salvarea fișierului, puteți monta folderul de la distanță.

Sistemul de fișiere NFS (Network File System) a fost creat de Sun Microsystems. În prezent, este sistemul de fișiere de rețea standard pentru sistemele de operare UNIX, iar clienții și serverele NFS au fost implementate pentru multe alte sisteme de operare. Principiile organizării sale au fost acum standardizate de comunitatea Internet cea mai recentă versiune a NFS v.4 este descrisă de specificația RFC 300, lansată în decembrie 2000.

NFS este un sistem care acceptă o schemă de acces la fișiere de la distanță. Lucrarea utilizatorului cu fișierele de la distanță după operația de montare devine complet transparentă - subarborele sistemului de fișiere al serverului NFS devine un subarboresc al sistemului de fișiere local.

Unul dintre obiectivele dezvoltatorilor NFS a fost să susțină sisteme eterogene cu clienți și servere care rulează sisteme de operare diferite pe platforme hardware diferite. Acest obiectiv este promovat de implementarea de către NFS a mecanismului RFC al Sun, care acceptă în mod implicit facilitățile XDR pentru reprezentarea uniformă a argumentelor procedurii de la distanță.

Pentru a asigura rezistența clientului la defecțiunile serverului, NFS adoptă o abordare fără stat, adică serverele nu stochează date despre fișierele deschise de clienți atunci când lucrează cu fișiere.

Ideea principală a NFS este de a permite unui grup arbitrar de utilizatori să partajeze un sistem de fișiere comun. Cel mai adesea, toți utilizatorii aparțin aceleiași rețele locale, dar nu neapărat. De asemenea, puteți rula NFS într-o rețea globală. Fiecare server NFS pune la dispoziția clienților la distanță unul sau mai multe dintre directoarele sale. Directorul este declarat liber cu toate subdirectoarele sale. Lista directoarelor pe care serverul le transferă este conținută în fișierul /etc/exports, astfel încât aceste directoare să fie exportate automat imediat când serverul pornește. Clienții accesează directoarele exportate prin montarea acestora. Multe stații de lucru Sun sunt fără disc, dar chiar și atunci puteți monta un sistem de fișiere la distanță în directorul rădăcină, cu întregul sistem de fișiere localizat pe server. Execuția programelor este aproape independentă de locul în care se află fișierul: local sau activat disc la distanță. Dacă doi sau mai mulți clienți au montat același director în același timp, aceștia pot comunica prin partajarea unui fișier.

Sistemul de fișiere NFS utilizează două protocoale în funcționarea sa.

Primul protocol NFS controlează montura. Clientul trimite la server Numele complet director și solicită permisiunea de a monta acel director undeva în propriul arbore de directoare. În acest caz, serverului nu i se spune unde va fi montat directorul serverului. După ce a primit numele, serverul verifică validitatea acestei solicitări și returnează clientului un descriptor de fișier care este punctul de montare la distanță. Descriptorul include un descriptor de tip de sistem de fișiere, numărul discului, numărul inodului directorului care este punctul de montare la distanță și informații de securitate. Citirile și scrierile de fișiere din sistemele de fișiere montate folosesc descriptori de fișiere în loc de un nume simbolic.

Montarea se poate face automat folosind fișiere batchîn timpul încărcării. Există o altă opțiune montaj automat: Când sistemul de operare pornește pe o stație de lucru, sistemul de fișiere la distanță nu este montat, dar atunci când un fișier la distanță este deschis pentru prima dată, sistemul de operare trimite cereri către fiecare server și, după detectarea acestui fișier, montează directorul serverului pe care a găsit fișierul este localizat.

Al doilea protocol NFS este folosit pentru a accesa fișiere și directoare de la distanță. Clienții pot trimite o solicitare către server pentru a efectua o acțiune asupra unui director sau pentru a citi sau a scrie un fișier. În plus, pot solicita atribute ale fișierului, cum ar fi tipul, dimensiunea, timpul de creare și timpul de modificare. NFS acceptă majoritatea apelurilor de sistem UNIX, cu excepția deschiderii și închiderii. Excepția deschiderii și închiderii nu este întâmplătoare. În loc să deschidă un fișier la distanță, clientul trimite serverului un mesaj care conține numele fișierului cu o solicitare de a-l căuta și de a returna descriptorul de fișier. Spre deosebire de apelul deschis, apelul de căutare nu copiază nicio informație în interiorul tabelele de sistem. Apelul de citire conține un mâner pentru fișierul de citit, un offset în fișierul care este deja citit și numărul de octeți care trebuie citiți. Avantajul acestei scheme este că serverul nu își amintește nimic despre fișierele deschise. În acest fel, dacă serverul eșuează și este restaurat ulterior, informațiile despre fișierele deschise nu se vor pierde deoarece nu sunt menținute.

Dacă serverul eșuează, clientul pur și simplu continuă să trimită comenzi pentru a-i citi sau scrie fișiere, dar fără a primi un răspuns și după ce a epuizat timpul de expirare, clientul își repetă solicitările. După repornire, serverul primește următoarea cerere repetată a clientului și îi răspunde. Astfel, o prăbușire a serverului cauzează doar o ușoară pauză în serviciul client, dar nu sunt necesare acțiuni suplimentare din partea clienților pentru a restabili conexiunile și a redeschide fișierele.

Din păcate, NFS face dificilă blocarea fișierelor. Pe multe sisteme de operare, un fișier poate fi deschis și blocat, astfel încât alte procese să nu îl poată accesa. Când fișierul este închis, blocarea este eliberată. În sistemele fără stat precum NFS, blocarea nu poate fi asociată cu deschiderea unui fișier, deoarece serverul nu știe ce fișier este deschis. În consecință, NFS necesită comenzi speciale de blocare suplimentare.

NFS folosește memorarea în cache pe partea clientului, transferă date în cache bloc cu bloc și folosește read-ahead, în care citirea unui bloc în cache la cererea aplicației este întotdeauna însoțită de o citire a blocului următor la iniţiativa sistemului. Metoda de stocare în cache NFS nu păstrează semantica UNIX pentru partiționarea fișierelor. În schimb, folosește semantica mult criticată în care modificările datelor dintr-un fișier stocat în cache de un client sunt vizibile pentru un alt client, în funcție de sincronizare. Când clientul deschide un fișier în cache-ul său, verifică cu serverul când fișierul a fost modificat ultima dată. Dacă acest lucru se întâmplă după ce fișierul a fost stocat în cache, fișierul este eliminat din cache și se obține o nouă copie a fișierului de pe server. Clienții propagă modificările făcute în cache la intervale de 30 de secunde, astfel încât serverul poate primi actualizări cu o întârziere mare. Ca urmare a mecanismelor de eliminare a datelor din cache și de propagare a modificărilor, datele primite de orice client nu sunt întotdeauna cele mai recente.

Replicarea NFS nu este acceptată.

Serviciul director

Scopul și principiile de organizare

La fel ca o organizație mare, o rețea de calculatoare mare are nevoie de stocare centralizată a informațiilor de fundal cât mai complete despre ea însăși. Soluția la multe probleme din rețea se bazează pe informații despre utilizatorii rețelei - numele lor utilizate pentru autentificarea logică la sistem, parole, drepturi de acces la resursele de rețea, precum și resurse și componente de rețea: servere, computere client, routere, gateway-uri, volume ale sistemului de fișiere, imprimante etc.

Iată exemple de cele mai importante sarcini care necesită o bază de date centralizată de informații de referință în rețea:

• Una dintre sarcinile efectuate cel mai frecvent în sistem, pe baza informațiilor de referință despre utilizatori, este autentificarea acestora, pe baza căreia apoi este autorizat accesul. Rețeaua trebuie să stocheze cumva central conturile de utilizator care conțin nume de utilizator și parole.
• Prezența unei baze de date centralizate necesită suport pentru accesul transparent la multe resurse de rețea. O astfel de bază de date ar trebui să stocheze numele acestor resurse și să mapeze numele la identificatori numerici (de exemplu, adrese IP), permițând ca această resursă să fie găsită în rețea. Transparența poate fi asigurată atunci când accesați servere, volume de sistem de fișiere, interfețe de procedură RPC, obiecte de program de aplicație distribuite și multe alte resurse de rețea.
• E-mailul este un alt exemplu popular de serviciu pentru care un singur birou de asistență în rețea care stochează informații despre nume poștale utilizatorii.
• Recent, rețelele au început să utilizeze din ce în ce mai mult instrumente de management al calității serviciului de trafic (QoS), care necesită, de asemenea, informații despre toți utilizatorii și aplicațiile sistemului, cerințele acestora pentru calitatea traficului parametrilor serviciului, precum și despre toate dispozitivele de rețea, cu pe care le puteți controla traficul (routere, comutatoare, gateway-uri etc.).
• Organizarea aplicațiilor distribuite poate fi simplificată semnificativ dacă rețeaua are o bază de date care stochează informații despre modulele-obiecte software existente și locația acestora pe serverele de rețea. O aplicație care trebuie să efectueze o acțiune standard face o cerere către o astfel de bază de date și primește adresa unui obiect software care are capacitatea de a efectua acțiunea necesară.
• Sistemul de management al rețelei trebuie să aibă o bază de date pentru stocarea informațiilor despre topologia rețelei și caracteristicile tuturor elementelor rețelei, cum ar fi routere, comutatoare, servere și calculatoare client. Având informații complete despre componența rețelei și conexiunile acesteia, permite sistemului automat de gestionare a rețelei să identifice corect mesajele despre evenimentele de urgență și să găsească cauza principală a acestora. Informații despre activele existente, organizate pe divizii ale întreprinderii echipamente de reteași software-ul instalat este util în sine, deoarece ajută administratorii să creeze o imagine fiabilă a stării rețelei și să dezvolte planuri pentru dezvoltarea acesteia.

Astfel de exemple pot fi continuate, dar nu este greu de dat un contraargument care să pună la îndoială necesitatea utilizării unei baze de date centralizate cu informații de referință în rețea - pentru o lungă perioadă de timp rețelele au funcționat fără o singură bază de date de referință și multe rețele încă funcționează fără aceasta. Într-adevăr, există multe soluții private care vă permit să organizați destul de eficient munca unei rețele bazate pe baze de date private de informații de referință, care pot fi reprezentate prin fișiere text obișnuite sau tabele stocate în corpul aplicației. De exemplu, sistemul de operare UNIX utilizează în mod tradițional un fișier passwd pentru a stoca date despre numele de utilizator și parole, care acoperă utilizatorii unui singur computer. Numele destinatarilor de e-mail pot fi, de asemenea, stocate într-un fișier local de pe computerul client. Și atât de privat sisteme de ajutor Funcționează bine - practica confirmă acest lucru.

Cu toate acestea, această obiecție este valabilă doar pentru rețelele mici și mijlocii, în rețele mari bazele de date de referință locale individuale își pierd eficacitatea. Un exemplu bun, care confirmă inaplicabilitatea soluțiilor locale pentru rețele mari, este serviciul de nume DNS care rulează pe Internet. Odată ce dimensiunea Internetului a depășit o anumită limită, stocarea informațiilor despre corespondența numelor și adreselor IP ale computerelor din rețea în fișierele text locale a devenit ineficientă. A fost necesar să se creeze o bază de date distribuită menținută ierarhic servere legate nume și un serviciu centralizat peste această bază de date, astfel încât procedurile de rezolvare a numelor simbolice pe Internet să înceapă să funcționeze rapid și eficient.

Pentru o rețea mare, este, de asemenea, ineficient să folosiți un număr mare de servicii de ajutor cu scop îngust: unul pentru autentificare, altul pentru gestionarea rețelei, altele pentru rezolvarea numelor de computere etc. Chiar dacă fiecare dintre aceste servicii este bine organizat și combină un interfață centralizată cu o bază de date distribuită, un număr mare de servicii de ajutor duce la duplicarea unor cantități mari de informații și complică administrarea și managementul rețelei. De exemplu, Windows NT are cel puțin cinci tipuri diferite de baze de date de ajutor. Directorul de domeniu principal (NT Domain Directory Service) stochează informații despre utilizatori care sunt necesare atunci când își organizează autentificarea logică la rețea. Datele despre aceiași utilizatori pot fi conținute într-un alt director utilizat prin e-mail Microsoft Mail. Alte trei baze de date acceptă rezoluția adreselor: WINS mapează numele Netbios la adrese IP, directorul DNS (Domain Name Server) este util atunci când conectați o rețea NT la Internet și, în sfârșit, directorul DHCP este folosit pentru a atribui automat adrese IP computerelor din rețea. . Evident, o asemenea varietate de servicii de ajutor complică viața administratorului și duce la erori suplimentare atunci când acreditările aceluiași utilizator trebuie introduse în mai multe baze de date. Prin urmare, în nou versiuni Windows 2000, majoritatea informațiilor de referință de sistem pot fi stocate de Active Directory, un singur serviciu de referință centralizat care utilizează o bază de date distribuită și este integrat cu serviciul de nume DNS.

Dezvoltarea sistemelor de stocare a informațiilor de referință a avut ca rezultat apariția în sistemele de operare în rețea serviciu special- așa-numitul serviciu de directoare ( Servicii de director), numit și serviciu de referință (director - director, director). Serviciul de director stochează informații despre toți utilizatorii și resursele rețelei sub formă de obiecte unificate cu anumite atribute și, de asemenea, vă permite să reflectați relațiile dintre obiectele stocate, cum ar fi utilizatorii aparținând unui anumit grup, drepturile de acces ale utilizatorilor la computere, prezența a mai multor noduri din aceeași subrețea, legături de comunicație între subrețele, afilierea de producție a serverelor etc. Serviciul de directoare vă permite să efectuați un set de operații de bază asupra obiectelor stocate, cum ar fi adăugarea și ștergerea unui obiect, inclusiv a unui obiect în altul obiect, modificarea valorilor unui atribut al unui obiect, citirea atributelor și altele. De obicei, diferite aplicații de rețea specifice sunt construite pe partea de sus a unui serviciu de director, care utilizează informațiile serviciului pentru a rezolva probleme specifice: managementul rețelei, autentificarea utilizatorilor, furnizarea de transparență a serviciului și altele enumerate mai sus. Un serviciu de directoare este de obicei construit pe un model client-server: serverele stochează o bază de date cu informații despre directoare pe care clienții le folosesc trimițând cereri corespunzătoare către servere prin intermediul rețelei. Pentru clientul serviciului de directoare, acesta pare a fi un singur sistem centralizat, deși majoritatea servicii bune directoarele au o structură distribuită, inclusiv un numar mare de servere, dar această structură este transparentă pentru clienți.

O problemă importantă este organizarea bazei de date de referință. O singură bază de date care stochează volume mari de informații de referință dă naștere la aceleași multe probleme ca orice altă bază de date mare. Implementarea unui birou de asistență ca bază de date locală stocată ca o singură copie pe unul dintre serverele de rețea nu este potrivită pentru un sistem mare din mai multe motive, în primul rând din cauza performanței scăzute și a fiabilității scăzute a unei astfel de soluții. Performanța va fi scăzută datorită faptului că solicitările către baza de date de la toți utilizatorii și aplicațiile din rețea vor ajunge pe un singur server, care, cu un număr mare de solicitări, cu siguranță nu le va mai putea procesa. Adică, o astfel de soluție nu se scalează bine în ceea ce privește numărul de utilizatori serviți și resursele partajate. De asemenea, fiabilitatea nu poate fi ridicată într-un sistem cu o singură copie a datelor. Pe lângă eliminarea limitărilor privind performanța și fiabilitatea, este de dorit ca structura bazei de date să permită gruparea logică a resurselor și utilizatorilor pe divizii structurale ale întreprinderii și alocarea unui administrator fiecărui astfel de grup.

Problemele de menținere a performanței și a fiabilității pe măsură ce rețeaua se extinde sunt de obicei rezolvate prin baze de date distribuite cu informații de referință. Partajarea datelor pe mai multe servere reduce sarcina pe fiecare server, în timp ce fiabilitatea este obținută prin existența mai multor replici ale fiecărei părți a bazei de date. Pentru fiecare parte a bazei de date, puteți atribui propriul administrator, care are drepturi de acces doar la obiectele porțiunii sale de informații despre întregul sistem. Pentru utilizator (și pentru aplicațiile de rețea), o astfel de bază de date distribuită pare a fi o bază de date unică care oferă acces la toate resursele rețelei, indiferent de stația de lucru de la care a venit cererea.

Există două standarde populare pentru serviciile de directoare. În primul rând, acesta este standardul X.500, dezvoltat de ITU-T (la momentul în care a fost dezvoltat standardul, această organizație se numea CCITT). Acest standard definește funcțiile, organizarea biroului de asistență și protocolul de accesare a acestuia. Conceput în primul rând pentru a fi utilizat cu serviciul de e-mail X.400, standardul X.500 permite stocarea eficientă a oricărei informații despre director și servește drept bază bună pentru un serviciu universal de director de rețea.

Un alt standard este standardul LDAP (Light-weight Directory Access Protocol) dezvoltat de comunitatea Internet. Acest standard definește un protocol simplificat pentru accesarea serviciilor de directoare, deoarece serviciile construite pe standardul X.500 s-au dovedit a fi prea greoaie. LDAP a devenit larg răspândit și a devenit standardul de facto pentru accesul clienților la resursele biroului de asistență.

Există și câteva implementari practice Servicii de directoare pentru sistemele de operare în rețea. Cel mai utilizat serviciu este serviciul NDS de la Novell, dezvoltat în 1993 pentru sistemul de operare de rețea NetWare 4.0 și implementat astăzi și pentru Windows NT/2000. Serviciul este de mare interes Directoare active Director, dezvoltat de de către Microsoft pentru Windows 2000. Ambele servicii acceptă protocolul de acces LDAP și pot funcționa în rețele foarte mari datorită naturii lor distribuite.

Serviciul Director NDS

NDS (NetWare Directory Services) este un serviciu de director global care se bazează pe o bază de date distribuită, orientată pe obiecte, a resurselor de rețea. Baza de date NDS conține informații despre toate resursele rețelei, inclusiv informații despre utilizatori, grupuri de utilizatori, imprimante, volume și computere. NetWare OS (precum și alți clienți NDS care rulează pe alte platforme) utilizează informații NDS pentru a oferi acces la aceste resurse.

Baza de date NDS a înlocuit directorul de legături al versiunilor anterioare de NetWare. Directorul bindery este o bază de date „plată” sau cu un singur nivel, concepută pentru a suporta un singur server. De asemenea, a folosit conceptul de „obiect” pentru o resursă de rețea, dar interpretarea acestui termen a fost diferită de cea general acceptată. Obiectele de legare erau identificate prin valori numerice simple și aveau atribute specifice. Cu toate acestea, nu au fost definite relații explicite de moștenire a clasei de obiecte pentru aceste obiecte, astfel încât relațiile dintre obiectele de legare au fost stabilite în mod arbitrar de către administrator, ceea ce a dus adesea la coruperea datelor.

Baza de date de servicii NDS este o bază de date cu mai multe niveluri care menține informații despre resurse pentru toate serverele din rețea. Pentru compatibilitate cu versiunile anterioare de NetWare, NDS furnizează un mecanism de emulare a bazei de date de legare.

NDS este o îmbunătățire semnificativă față de versiunile anterioare cu:

• distributie;
• replicabilitate;
• transparenţă;
• globalitatea.

Distribuția înseamnă că informațiile nu sunt stocate pe un singur server, ci sunt împărțite în părți numite partiții. NetWare stochează aceste partiții pe mai multe servere din rețea (Figura 10.8). Această proprietate simplifică foarte mult administrarea și gestionarea unei rețele mari, deoarece apare administratorului ca un singur sistem. În plus, accesul mai rapid la baza de date a resurselor de rețea este asigurat prin accesarea celui mai apropiat server.

Orez. 10.8. Partiții pentru baze de date NDS

O replică este o copie a informațiilor despre partiția NDS. Puteți crea un număr nelimitat de replici ale fiecărei partiții și le puteți stoca pe servere diferite. Dacă un server se oprește, copii ale acestor informații pot fi obținute de la alt server. Acest lucru crește rezistența sistemului, deoarece niciun server nu este responsabil pentru toate informațiile bazei de date NDS.

Transparența constă în faptul că NDS creează automat conexiuni între componentele software și hardware care oferă acces utilizatorului la resursele rețelei. NDS nu solicită utilizatorului să cunoască locația fizică a acestor resurse. Specificând o resursă de rețea după nume, veți avea acces corect la ea chiar dacă adresa de rețea sau locația acesteia se schimbă.

Natura globală a NDS constă în faptul că, după autentificare, aveți acces la resursele întregii rețele, și nu la un singur server, așa cum a fost cazul în versiunile anterioare. Acest lucru se realizează prin procedura de conectare globală. În loc să se conecteze la un server separat, utilizatorul NDS se conectează în rețea și apoi are acces la resursele de rețea care sunt autorizate pentru el. Informațiile furnizate în timpul logării sunt folosite pentru a identifica utilizatorul. Mai târziu, când un utilizator încearcă să acceseze resurse precum servere, volume sau imprimante, un proces de autentificare în fundal verifică dacă utilizatorul are permisiunea de a accesa resursa.

Sistem de fișiere în rețea (NFS)- protocol acces la retea la sistemele de fișiere, vă permite să conectați sisteme de fișiere la distanță.
Dezvoltat inițial de Sun Microsystems în 1984. Baza este Sun RPC: Remote Procedure Call. NFS este independent de tipurile de sistem de fișiere server și client. Există multe implementări ale serverelor și clienților NFS pentru diferite sisteme de operare. Versiunea actuală a NFS v.4 acceptă diverse mijloace de autentificare (în special, Kerberos și LIPKEY folosind protocolul RPCSEC GSS) și liste de control al accesului (atât tipurile POSIX, cât și Windows).
NFS oferă clienților acces transparent la fișierele și sistemul de fișiere al serverului. Spre deosebire de FTP, protocolul NFS accesează doar acele părți ale fișierului care sunt accesate de proces, iar principalul său avantaj este că face acest acces transparent. Datorită acestui lucru, orice aplicație client care poate funcționa cu un fișier local poate funcționa cu același succes cu un fișier NFS, fără a schimba programul în sine.
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.

Versiuni
NFSv1 a fost doar pentru uz internîn scopuri experimentale. Detaliile de implementare sunt definite în RFC 1094.
NFSv2 (RFC 1094, martie 1989) rula inițial în întregime peste UDP.
NFSv3 (RFC 1813, iunie 1995). Descriptorii de fișiere din versiunea 2 sunt o matrice de dimensiune fixă ​​de 32 de octeți. În versiunea 3, este o matrice de dimensiune variabilă cu o dimensiune de până la 64 de octeți. Matrice 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.
Versiunea 2 limitează numărul de octeți pe RPC READ sau WRITE la 8192 de octeți. Această limitare nu se aplică în versiunea 3, 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.
Dimensiunile fișierelor și offset de octeți de pornire pentru CITIȚI proceduriși WRITE a început să folosească adresarea pe 64 de biți în loc de 32 de biți, ceea ce vă permite să lucrați cu fișiere mai mari.
Atributele fișierelor sunt returnate în fiecare apel care poate afecta atributele.
Scrierile (WRITE) pot fi asincrone, în timp ce în versiunea 2 trebuiau să fie sincrone.
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ă informatii statistice informații despre sistemul de fișiere), FSSTAT (returnează informații despre sistemul de fișiere dinamic), PATHCONF (returnează informații despre sistemul de fișiere POSIX.1) și COMMIT (commite scrieri asincrone efectuate anterior pe stocarea persistentă).
La momentul introducerii versiunii 3, dezvoltatorii au început să folosească TCP mai mult ca protocol de transport. Deși unii dezvoltatori au folosit deja TCP pentru NFSv2, Sun Microsystems a adăugat suport TCP în NFS versiunea 3. Acest lucru a făcut ca utilizarea NFS pe Internet să fie mai fezabilă.
NFSv4 (RFC 3010, decembrie 2000, RFC 3530, revizuit în aprilie 2003), influențat de AFS și CIFS, a inclus îmbunătățiri de performanță, securitate ridicată și a devenit un protocol cu ​​drepturi depline. Versiunea 4 a fost prima versiune dezvoltată împreună cu Internet Engineering Task Force (IETF) după ce Sun Microsystems a transferat dezvoltarea protocolului în NFS. NFS v4.1 a fost aprobat de IESG în ianuarie 2010 și a primit numărul RFC 5661. O inovație importantă în versiunea 4.1 este specificarea pNFS - Parallel NFS, un mecanism pentru accesul clientului NFS paralel la datele de pe mai multe servere NFS distribuite. Prezența unui astfel de mecanism în standardul sistemului de fișiere de rețea va ajuta la construirea de sisteme de stocare și informații „în nor” distribuite.

Structura NFS
Structura NFS include trei componente la niveluri diferite:
Stratul de aplicație (NFS însuși) constă din apeluri de procedură la distanță (rpc), care efectuează operațiunile necesare cu fișiere și directoare pe partea serverului.
Funcțiile stratului de prezentare sunt realizate de protocolul XDR (eXternal Data Representation), care este un standard de abstracție a datelor multiplatformă. Protocolul XDR descrie o formă unificată, canonică de reprezentare a datelor, care este independentă de arhitectura sistemului informatic. La transmiterea pachetelor, clientul RPC convertește datele locale în formă canonică, iar serverul efectuează operația inversă.
Serviciul RPC (Remote Procedure Call), care permite clientului să solicite proceduri de la distanță și să le execute pe server, reprezintă funcții la nivel de sesiune. Conectarea resurselor de rețea
Procedura de conectare a unei resurse de rețea folosind NFS se numește „export”. Clientul poate solicita serverului să listeze resursele exportate pe care le reprezintă. Serverul NFS în sine nu difuzează o listă a resurselor sale exportate.
În funcție de opțiunile specificate, resursa exportată poate fi montată (atașată) „numai în citire”, puteți defini o listă de gazde care au voie să se monteze, să specificați utilizarea RPC securizat (secureRPC), etc. Una dintre opțiuni determină modul de montare: „hard” (hard) sau „soft” (moale).
Cu o montură „hard”, clientul va încerca să monteze sistemul de fișiere cu orice preț. Dacă serverul este inactiv, acest lucru va determina înghețarea întregului serviciu NFS: procesele care accesează sistemul de fișiere vor intra într-o stare de așteptare pentru finalizarea cererilor RPC. Din punctul de vedere al proceselor utilizatorului, sistemul de fișiere va arăta ca un disc local foarte lent. Când serverul revine la starea de funcționare, serviciul NFS va continua să funcționeze.
Cu o montare soft, clientul NFS va face mai multe încercări de conectare la server. Dacă serverul nu răspunde, sistemul afișează un mesaj de eroare și nu mai încearcă să monteze. Din punctul de vedere al logicii operațiunilor cu fișierele atunci când serverul eșuează, o montare „soft” emulează o defecțiune locală a discului.
Alegerea modului depinde de situație. Dacă datele de pe client și server trebuie sincronizate în timpul unei eșecuri temporare a serviciului, atunci o montare „hard” este de preferat. Acest mod este, de asemenea, indispensabil în cazurile în care sistemele de fișiere montate conțin programe și fișiere care sunt vitale pentru funcționarea clientului, în special pentru mașinile fără disc. În alte cazuri, mai ales când vine vorba de sisteme de doar citire, modul de montare moale pare mai convenabil.

Partajare într-o rețea mixtă
NFS este ideal pentru rețelele bazate pe UNIX, deoarece vine cu majoritatea versiunilor de sistem de operare. Mai mult, suportul NFS este implementat la nivel Kernel-urile UNIX. Utilizarea NFS pe computerele client Windows creează anumite probleme asociate cu necesitatea instalării unui software client specializat și destul de costisitor. În astfel de rețele, utilizarea instrumentelor de partajare a resurselor bazate pe protocolul SMB/CIFS, în special software-ul Samba, pare mai de preferat.

Standarde
RFC 1094 NFS: Specificația protocolului sistemului de fișiere de rețea] (martie 1989)
Specificația protocolului RFC 1813 NFS versiunea 3] (iunie 1995)
Schema URL RFC 2224 NFS
RFC 2339 Un acord Între Internet Society, IETF și Sun Microsystems, Inc. în materia protocoalelor NFS V.4
RFC 2623 NFS Versiunea 2 și Versiunea 3 Probleme de securitate și utilizarea protocolului NFS a RPCSEC_GSS și Kerberos V5
RFC 2624 NFS Versiunea 4 Considerații de proiectare
Protocolul RFC 3010 NFS versiunea 4
Protocolul RFC 3530 Network File System (NFS) versiunea 4
RFC 5661 Network File System (NFS) Versiunea 4 Protocolul minor Versiunea 1

Surse folosite
1. ru.wikipedia.org
2. ru.science.wikia.com
3. telefon16.ru
4. 4stud.info
5. yandex.ru
6.google.com

utilizatorul poate lucra în momente diferite pe computere diferite. Folosind un server de fișiere, mai multe sarcini sunt rezolvate simultan:

1. backup regulat al tuturor datelor: este nerealist să efectuați această operațiune pentru câteva zeci sau sute de computere, dar este foarte posibil - de la un singur server sau mai multe servere.
2. creșterea fiabilității stocării datelor: este nerezonabil să echipați fiecare computer din rețea cu o matrice RAID, deoarece marea majoritate a fișierelor de pe un computer, cum ar fi pachetele software instalate, sunt mai ușor de reinstalat decât de protejat de eșec; dar ar fi destul de rezonabil să echipați serverul de fișiere cu o matrice RAID hardware sau să o organizați acolo software RAID, cel puțin oglindirea simplă a discului.
3. reducerea costului de stocare a datelor: este costisitor și ineficient să instalați un disc uriaș în fiecare computer în cazul în care aveți nevoie să stocați o mulțime de date, dar este foarte posibil să instalați un subsistem de disc scalabil de capacitate mare pe server.
4. oferind acces la aceleași date de pe orice computer.

Descrierea NFS

Serviciul NFS permite unui server să ofere acces partajat la directoarele specificate pe local Sistemul de fișiere iar clientul să monteze aceste directoare ca și cum ar fi directoarele locale ale clientului.

versiuni NFS

NFS, dezvoltat de Sun Microsystems, a avut atât de mult succes încât implementările sale au fost implementate diferite companii pe aproape toate sistemele de operare. Există câteva implementări fundamental diferite ale NFS. Versiunea NFS 2.0 este destul de comună, deși NFS 3.0 a fost deja introdus în Solaris 2.5. Versiunile ulterioare ale Solaris, inclusiv Solaris 9, au adus completări semnificative la NFS, dar protocolul în sine a rămas compatibil cu implementările NFS 3.0 pe alte sisteme. Începând cu NFS 3.0, transmisia de pachete prin TCP și UDP este acceptată anterior doar UDP.

atenție! Rețeaua ar trebui să utilizeze clienți și servere NFS din aceeași versiune. NFS 2.0 poate fi găsit în sisteme mai vechi, de exemplu, în HP-UX 10.0. Colaborare sisteme care utilizează versiuni diferite de NFS nu este de dorit.

Compatibilitatea NFS și alte servicii de directoare partajate

NFS este similar în sensul și organizarea muncii cu directoare partajate (foldere partajate) V sisteme Windows, dar aceste servicii folosesc protocoale de operare complet diferite și nu sunt compatibile între ele. Cu toate acestea, există mai multe produse software, care instalează suport NFS pe sisteme Windows, deci folosirea NFS într-o rețea cu sisteme de operare diferite nu este o problemă, trebuie doar să vă amintiți să utilizați aceleași versiuni de NFS.

Serviciul NFS presupune un model client-server, cu computerele client și server rulând diferite programe pentru a oferi acces la directoarele partajate de pe server.

Deoarece computerele de la locurile de muncă ale angajaților din Rusia sunt de obicei controlate de sisteme Windows, servere de fișiere Sistemele Windows sunt, de asemenea, adesea folosite. Cu toate acestea, există adesea dorința de a instala UNIX pe un server de fișiere pentru a crește fiabilitatea, a reduce costurile hardware sau pentru a utiliza același server pentru o serie de alte nevoi corporative: ca server web, server de baze de date etc. Pentru a nu instala software suplimentar care să suporte NFS, în acest caz este suficient să instalați pachetul samba pe mașina UNIX. Îi va permite să „pretindă” că este un server Windows, astfel încât toate computerele client să-l percepă ca un server de fișiere obișnuit sau un server de imprimare într-o rețea Windows. Pachetul samba oferă suport pentru protocolul SMB nativ pentru rețelele Windows.

În cazurile în care în rețea operează mai multe computere UNIX și trebuie să acceseze un singur server de fișiere, este logic să folosiți mecanismul NFS (sistem de fișiere de rețea).

NFS nu este foarte rezistent la defecțiunile rețelei, necesită funcționare neîntreruptă a rețelei și necesită o conexiune rapidă între client și server. Utilizarea NFS pentru a monta sisteme de fișiere în afara unei rețele locale, cum ar fi prin Internet, este fezabilă din punct de vedere tehnic, dar nu foarte practică și nesigură.

Terminologie NFS

După configurarea serverului NFS, computerul UNIX va oferi acces utilizatori externi la unele dintre cataloagele sale Sistemul de fișiere. Această furnizare de acces se numește „export”: se spune că sistemul își exportă directoarele. Cât de exact vor fi exportate directoarele este determinat de lista care specifică Administrator de sistem. Pe majoritatea sistemelor UNIX, această listă este conținută în fișierul /etc/exports, dar pe Solaris este într-un fișier diferit - /etc/dfs/dfstab.

NFS funcționează printr-un mecanism de apel de procedură la distanță ( RPC - Remote Procedure Call).

Ce este RPC

Ideologia RPC este foarte simplă și atractivă pentru programator. Cum funcționează de obicei o aplicație de rețea? Urmează un protocol (de exemplu, HTTP): generează un pachet de solicitare, apelează funcția de stabilire a conexiunii la sistem, apoi funcția de trimitere a pachetului, apoi așteaptă un pachet de răspuns și apelează funcția de închidere a conexiunii. Aceasta înseamnă că toate lucrările cu rețeaua sunt responsabilitatea programatorului care scrie aplicația: el trebuie să-și amintească să apeleze funcțiile API-ului de rețea a sistemului și să se gândească la acțiuni în cazul defecțiunilor rețelei.

RPC implică un mod diferit de schimb de date între un client și un server. Din punctul de vedere al unui programator, o aplicație client care rulează folosind RPC apelează o funcție pe server, execută și returnează un rezultat. Redirecționarea unei solicitări de funcție în rețea și returnarea rezultatelor de la server la client este fără probleme pentru aplicație, astfel încât aplicația nu trebuie să-și facă griji cu privire la defecțiunile rețelei sau detaliile implementării protocolului de transport.

Pentru a asigura transparența transferului de date prin rețea, a fost inventată o procedură în doi pași. Pe server, orice aplicație care își oferă serviciul prin RPC trebuie să se înregistreze cu un program numit port mapper. Funcția acestui program este de a stabili o corespondență între numărul procedurii RPC pe care clientul l-a solicitat și numărul portului TCP sau UDP pe care aplicația server ascultă cereri. În general, RPC poate funcționa cu mai mult decât TCP sau UDP. Solaris implementează lucrul bazat pe mecanismul TI (TransportIndependent), așa că în Solaris translatorul de porturi este numit rpcbind, dar nu portmap, ca în Linux sau FreeBSD.

O aplicație care se înregistrează cu un traducător de porturi îi spune numărul programului, numărul versiunii și numerele procedurii care pot fi procesate de program. Aceste proceduri vor fi apelate ulterior de către client după număr. În plus, aplicația raportează numerele de porturi TCP și UDP care vor fi folosite pentru a primi solicitări de efectuare a procedurilor.

Un client care dorește să determine executarea unei proceduri pe un server trimite mai întâi o solicitare traducătorului de porturi de pe server pentru a afla la ce port TCP sau UDP să trimită cererea. Translatorul de porturi pornește la pornirea sistemului și funcționează întotdeauna pe portul standard 111. După ce a primit un răspuns de la acesta, clientul trimite o cerere către portul care corespunde aplicației necesare. De exemplu, serverul NFS rulează pe portul 2049.

Procedura pentru montarea unui director partajat prin NFS

Înainte de a trece la descrierea setărilor pentru serverul și clienții NFS, ar trebui să înțelegeți cum să montați sistemele de fișiere la distanță în principiu.

Clientul NFS trimite o cerere de montare către computerul de la distanță, care o furnizează Sistemul de fișiere(de obicei o parte din el) pentru uz general. În acest caz, ei spun că serverul NFS „exportă” acest sau acel director (adică cu subdirectoare). Solicitare de la un client

Bună ziua, cititori și invitați. A fost o pauză foarte lungă între postări, dar am revenit în acțiune). În articolul de astăzi mă voi uita muncă Protocolul 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ă pe o rețea locală, unde este necesar schimbul 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...) siguranța de prim plan informatiile transmise. Protocolul NFS permite montați sisteme de fișiere la distanță în rețea într-un arbore de directoare local, ca și cum ar fi un sistem de fișiere pe disc montat. Acest lucru permite aplicațiilor locale să lucreze 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 nesfârșite. 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 căutând prezența liniilor corespunzătoare în fișier /proc/sisteme de fișiere:

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

Dacă liniile specificate în fișier /proc/sisteme de fișiere nu apare, atunci trebuie să instalați pachetele descrise mai jos. Acest lucru vă va permite cel mai probabil să instalați module dependente de kernel pentru a suporta sistemele de fișiere necesare. Dacă după instalarea pachetelor, suportul NFS nu este afișat în fișierul specificat, atunci va fi necesar să activați această funcție.

Poveste Sistem de fișiere de rețea

Protocolul NFS dezvoltat de Sun Microsystems și are 4 versiuni în istoria sa. NFSv1 a fost dezvoltat în 1989 și a fost experimental, rulând pe protocolul UDP. Versiunea 1 este descrisă în . NFSv2 a fost lansat în același 1989, descris de același RFC1094 și, de asemenea, bazat pe protocolul UDP, permițând în același timp să nu fie citite mai mult de 2 GB dintr-un fișier. NFSv3 finalizat în 1995 și descris în . Principalele inovații ale celei de-a treia versiuni au fost suportul pentru fișiere mari, suport adăugat pentru protocolul TCP și pachete TCP mari, care au accelerat semnificativ performanța tehnologiei. NFSv4 finalizat în 2000 și descris în RFC 3010, revizuit în 2003 și descris în . A patra versiune a inclus îmbunătățiri de performanță, suport pentru diverse mijloace de autentificare (în special, Kerberos și LIPKEY folosind protocolul RPCSEC GSS) și liste de control al accesului (atât tipurile POSIX, cât și Windows). Versiunea NFS v4.1 a fost aprobat de IESG în 2010 și a primit numărul . O inovație importantă în versiunea 4.1 este specificarea pNFS - Parallel NFS, un mecanism pentru accesul clientului NFS paralel la datele de pe mai multe servere NFS distribuite. Prezența unui astfel de mecanism în standardul sistemului de fișiere de rețea va ajuta la construirea de sisteme de stocare și informații „în nor” distribuite.

Server NFS

Din moment ce avem NFS- Acest reţea sistem de fișiere, atunci este necesar. (Puteți citi și articolul). Următorul este necesar. Pe Debian, acesta este un pachet nfs-kernel-serverȘi nfs-comun, în RedHat acesta este un pachet nfs-utils. Și, de asemenea, trebuie să permiteți demonului să ruleze la nivelurile de execuție ale sistemului de operare necesare (comanda în RedHat - /sbin/chkconfig nfs activat, în Debian - /usr/sbin/update-rc.d nfs-kernel-server implicite).

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

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx 1 root root 20 oct 18 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 root root 27 oct 22 01:23 S16nfs-kernel-server -> kernel-server /nfs-kernel-server

Adică începe primul nfs-comun, apoi serverul în sine 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 web debian ne spune textul acesta: fișiere partajate pentru client și server NFS, acest pachet trebuie instalat pe mașina care va acționa ca client sau server NFS. Pachetul include programe: lockd, statd, showmount, nfsstat, gssd și idmapd. Vizualizarea conținutului scriptului de lansare /etc/init.d/nfs-common puteți urmări următoarea secvență de lucru: scriptul verifică prezența unui fișier binar executabil /sbin/rpc.statd, verifică prezența în fișiere /etc/default/nfs-common, /etc/fstabȘi /etc/exports parametrii care necesită rularea demonilor idmapd Și gssd , pornește demonul /sbin/rpc.statd , apoi înainte de lansare /usr/sbin/rpc.idmapdȘi /usr/sbin/rpc.gssd verifică prezența acestor fișiere binare executabile, apoi pentru demonul /usr/sbin/rpc.idmapd verifică disponibilitatea sunrpc,nfsȘi nfsd, precum și suport pentru sistemul de fișiere rpc_pipefsîn nucleu (adică având-l în fișier /proc/sisteme de fișiere), dacă totul are succes, începe /usr/sbin/rpc.idmapd . În plus, pentru demon /usr/sbin/rpc.gssd verificări modulul nucleului 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), apoi puteți urma următoarea secvență: la pornire, scriptul verifică existența fișierului /etc/exports, Disponibilitate nfsd, disponibilitatea suportului Sistem de fișiere NFSîn (adică în dosar /proc/sisteme de fișiere), dacă totul este la locul lui, atunci demonul începe /usr/sbin/rpc.nfsd , apoi verifică dacă parametrul este specificat NEED_SVCGSD(setat în fișierul de setări server /etc/default/nfs-kernel-server) și, dacă este dat, pornește demonul /usr/sbin/rpc.svcgssd , lansează demonul ultimul /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 demonul rcp.svcgssd. În red hat, daemonul rpc.rquotad și nfslogd încă rulează (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 (a se citi: daemons), situat în directoarele /sbin și /usr/sbin:

În NFSv4, când utilizați Kerberos, sunt porniți daemoni suplimentari:

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

portmap și protocol RPC (Sun RPC)

Pe lângă pachetele de mai sus, pt funcţionare corectă NFSv2 și v3 necesită pachet suplimentar portmap(înlocuit în distribuțiile mai noi cu redenumit în rpcbind). pachetul curent de obicei este instalat automat cu NFS ca dependent și implementează funcționarea serverului RPC, adică este responsabil de alocarea dinamică a porturilor pentru unele servicii înregistrate în serverul 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,versiunea protocolului(tcp sau udp), numere de programȘi versiuni de software. Daemonul portmap este lansat de scriptul /etc/init.d/portmap înainte de a începe serviciile 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, aka, în versiunile noi, rpcbind), iar clienții folosesc apeluri RPC pentru a trimite cereri către portmapper get informatie necesara. Numele ușor de utilizat ale serviciilor de program și numerele lor corespunzătoare sunt definite în fișierul /etc/rpc. Odată ce orice serviciu a trimis cererea corespunzătoare și s-a înregistrat pe serverul RPC în port mapper, serverul RPC atribuie hărțile serviciu TCPși porturile UDP pe care a pornit serviciul și stochează în nucleu informațiile corespunzătoare despre serviciul care rulează (nume), numărul unic al serviciului (în conformitate cu /etc/rpc), despre protocolul și portul pe care rulează serviciul și despre versiunea serviciului și furnizează informațiile specificate clienților la cerere. Convertorul de porturi în sine are un număr de program (100000), numărul de versiune - 2, portul TCP 111 și portul UDP 111. Mai sus, când am specificat compoziția demonilor serverului NFS, am indicat principalele numere de program RPC. Probabil că v-am confundat puțin cu acest paragraf, așa că voi spune o frază de bază 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 RPC cu un anumit număr de program, trebuie să contacteze mai întâi procesul portmap de pe computerul server și să determine 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:

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 portul TCP 111. De asemenea, creează un punct final UDP care așteaptă să ajungă o datagramă UDP pe portul UDP 111.
2. La pornire, programul care rulează prin serverul RPC creează punctul final Punct final TCP și UDP pentru fiecare versiune acceptată a programului. (Un server RPC poate suporta mai multe versiuni. Clientul specifică versiunea necesară la efectuarea apelului RPC.) Fiecărei versiuni a serviciului i se atribuie un număr de port alocat dinamic. Serverul înregistrează fiecare program, versiune, protocol și număr de port făcând apelul RPC corespunzător.
3. Când programul client RPC trebuie să obțină informațiile necesare, apelează rutina de rezoluție de porturi pentru a obține un număr de port alocat dinamic pentru programul, versiunea și protocolul specificat.
4. Ca răspuns la această solicitare, nordul returnează un număr de port.
5. Clientul trimite un mesaj de solicitare RPC la numărul portului obținut la pasul 4. Dacă se folosește UDP, clientul trimite pur și simplu o datagramă UDP care conține mesajul de provocare RPC către numărul portului UDP pe care rulează serviciul solicitat. Ca răspuns, serviciul trimite o datagramă UDP care conține un mesaj de răspuns RPC. Dacă se utilizează TCP, clientul efectuează o deschidere activă a numărului portului TCP al serviciului dorit și apoi trimite un mesaj de apel RPC prin conexiunea stabilită. Serverul răspunde cu un mesaj de răspuns RPC la conexiune.

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

ARCHIV ~ # rpcinfo -p prog vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 59451 status 100024 1 tcp 60872 status 140002 140002 udp 140024 21 3 udp 44310 nlockmgr 100021 4 udp 44310 nlockmgr 100021 1 tcp 44851 nlockmgr 100021 3 tcp 44851 nlockmgr 100021 4 tcp 44851 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 1009 nfs 3 400 200 2000 2000 2000 2000 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100005 1 udp 51306 mountd 100005 1 tcp 41405 mountd 100005 2 udp 51306 mountd 100005 2 tcp 41405 mountd 100005 3 udp 51306 mountd 100005 3 tcp 41405 mountd

După cum puteți vedea, rpcinfo afișează (în coloane de la stânga la dreapta) numărul programului înregistrat, versiunea, protocolul, portul și numele. Folosind rpcinfo puteți elimina înregistrarea programului sau puteți obține informații despre serviciu separat RPC (mai multe opțiuni în man rpcinfo). După cum puteți vedea, demonii portmapper versiunea 2 sunt înregistrate pe udp și porturi tcp, rpc.statd versiunea 1 pe porturile udp și tcp, blocare NFS manager de versiuni 1,3,4, demonul serverului nfs versiunea 2,3,4, precum și versiunile demonului de montare 1,2,3.

Serverul NFS (mai precis, demonul rpc.nfsd) primește cereri de la client sub formă de datagrame UDP pe portul 2049. Deși NFS funcționează cu un rezolutor de porturi, care permite serverului să utilizeze porturi alocate dinamic, portul UDP 2049 este codificat în 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), care este 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 de rețea arbitrare (dacă nu este specificat un port static în setările serviciului).
3. comanda mount de pe computerul client trimite o solicitare către nucleu pentru a monta un director de rețea, indicând tipul de sistem de fișiere, gazdă și directorul propriu-zis pe care nucleul trimite și formează o cerere RPC către procesul portmap de pe serverul NFS pe portul udp; /111 (dacă opțiunea de a lucra prin tcp nu este setată pe client)
4. Nucleul serverului NFS interoghează RPC-ul pentru prezența demonului rpc.mountd și returnează nucleului clientului portul de rețea pe care rulează demonul.
5. mount trimite o cerere RPC către portul pe care rulează rpc.mountd. Serverul NFS poate valida acum un client pe baza adresei IP și a numărului de port pentru a vedea dacă clientul poate monta sistemul de fișiere specificat.
6. Daemonul de montare 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 obținut la pasul 5 cu punctul de montare local de pe gazda clientului. Hranul de fișier este stocat în codul NFS al clientului, iar de acum înainte orice acces de către procesele utilizatorului la fișierele din sistemul de fișiere al serverului va folosi handle-ul de fișier ca punct de plecare.

Comunicare între client și serverul NFS

Un acces tipic la un sistem de fișiere la distanță poate fi descris după cum urmează:

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

1. Clientului (procesului utilizatorului) nu îi pasă dacă accesează un fișier local sau un fișier NFS. Nucleul interacționează cu hardware-ul prin module de kernel sau apeluri de sistem încorporate.
2. Modul kernel kernel/fs/nfs/nfs.ko, care îndeplinește funcțiile unui client 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.
4. Când serverul NFS primește o solicitare de la un client, aceasta este transmisă rutinei locale de acces la fișiere, care oferă acces la disc local pe server.
5. Rezultatul accesului la disc este returnat clientului.

Configurarea unui server NFS

Ajustarea serveruluiîn general constă în specificarea directoarelor locale permise pentru montare sisteme de la distanțăîn dosar /etc/exports. Această acțiune se numește ierarhia directoarelor de export. Principalele surse de informații despre cataloagele exportate sunt următoarele fișiere:

• /etc/exports- fișierul principal 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 demonul rpc.mountd când un client încearcă să monteze o ierarhie (este creată o intrare de montare).
• /var/lib/nfs/etab- o listă de directoare care pot fi montate de către sistemele de la distanță, indicând toți parametrii 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 parametri. Miezul primește aceasta informatie din /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 nici măcar pe http://nfs.sourceforge.net/ este interpretarea neclar.

Configurarea fișierului /etc/exports

În cel mai simplu caz, fișierul /etc/exports este singurul fișier care necesită editare pentru a configura serverul NFS. Acest fișier gestionează următoarele aspecte:

• 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

Fiecare linie a fișierului de export are următorul format:

export_point client1 (opțiuni) [client2(opțiuni) ...]

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 . Opțiuni descrie regulile de montare pt client, precizat mai înainte Opțiuni .

Iată una tipică exemplu de configurare a fișierelor 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, în timp ce fișierele gazdă au acces de citire/scriere, iar gazda 10.0.0.1 și subrețeaua 10.0.230.1/24 au acces numai pentru citire.

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

• Numele nodurilor 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 din domeniul 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)

Opțiuni generale pentru exportul ierarhiilor de directoare

Fișierul de exporturi utilizează următoarele opțiuni generale(opțiunile utilizate implicit în majoritatea sistemelor sunt enumerate mai întâi, cele care nu sunt implicite între paranteze):

• auth_nlm (nu_auth_nlm) sau secure_locks (blocuri_nesigure)- specifică faptul că serverul ar trebui să necesite autentificarea solicitărilor de blocare (folosind protocolul NFS Lock Manager).
• nohide (ascunde)- dacă serverul exportă două ierarhii de directoare, cu una imbricată (montată) în cealaltă. Clientul trebuie să monteze în mod explicit a doua ierarhie (copil), altfel punctul de montare al ierarhiei copil va apărea ca un director gol. Opțiunea nohide are ca rezultat o a doua ierarhie de director fără o montare explicită. ( Notă: Nu am putut face ca această opțiune să funcționeze...)
• ro(rw)- Permite numai cereri de citire (scriere). (În cele din urmă, dacă este posibil să citiți/scrieți sau nu este determinat pe baza drepturilor sistemului de fișiere, iar serverul nu este capabil să distingă o solicitare de citire a unui fișier de o solicitare de executare, deci permite citirea dacă utilizatorul a citit sau executa drepturi.)
• sigur (nesigur)- necesită ca cererile NFS să provină din porturi securizate (< 1024), чтобы программа без drepturi root nu a putut monta ierarhia directoarelor.
• 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ă ce modificările făcute de acele solicitări au fost scrise pe disc. Opțiunea asincronă îi spune serverului să nu aștepte ca informațiile să fie scrise pe disc, ceea ce îmbunătățeș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 mare de comenzi care nu au legătură.

Exportați linkuri simbolice și fișiere de dispozitiv. Când exportați o ierarhie de director care conține legături simbolice, obiectul link trebuie să fie accesibil sistemului client (la distanță), adică una dintre următoarele reguli trebuie să fie adevărată:

Fișierul dispozitivului aparține interfeței. 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.

Opțiuni implicite în sisteme diferite pot varia, pot fi vizualizate în fișierul /var/lib/nfs/etab. După descrierea directorului exportat în /etc/exports și repornirea serverului NFS, toate opțiunile lipsă (a se citi: opțiuni implicite) vor fi reflectate în fișierul /var/lib/nfs/etab.

Opțiuni de afișare (potrivire) ID utilizator

Pentru o mai bună înțelegere a celor de mai jos, vă sfătuiesc să citiți articolul. Fiecare utilizator Linux are propriul său UID și GID principal, care sunt descrise în fișiere /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 conectaț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 în sistem local, ceea ce poate duce la unele probleme:

• este posibil ca un utilizator să nu aibă aceiași identificatori pe ambele sisteme și, prin urmare, poate să poată accesa fișierele altui utilizator.
• deoarece Dacă ID-ul utilizatorului root este întotdeauna 0, atunci acest utilizator este mapat la utilizatorul local în funcție de opțiunile specificate.

Următoarele opțiuni specifică regulile de afișare utilizatori la distanțăîn local:

• root_squash (fără_root_squash)- Cu opțiunea specificată rădăcină_dovleac, solicitările de la utilizatorul root sunt mapate la uid/gid anonim sau la utilizatorul specificat în parametrul anonuid/anongid.
• no_all_squash (tot_squash)- Nu modifică UID/GID-ul utilizatorului care se conectează. Opțiune all_squash setează afișarea TOȚI utilizatorii (nu doar root) ca anonim sau specificat în parametrul anonuid/anongid.
• anonuid= UID Și anongid= GID - Setează în mod explicit UID/GID pentru utilizatorul anonim.
• map_static= /etc/file_maps_users - Specifică un fișier în care puteți seta maparea UID/GID la distanță la UID/GID local.

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 1002 # maparea utilizatorilor cu UID la distanță 0-50 la UID local 1002 gid 0-50 1002 # maparea utilizatorilor cu/interval GID la distanță 0-50 la GID local 1002

Managementul serverului NFS

Serverul NFS este gestionat folosind următoarele utilitare:

• nfsstat
• showmmontare sigură (nesigură).

nfsstat: statistici NFS și RPC

Utilitarul nfsstat vă permite să vizualizați statisticile serverelor RPC și NFS. Opțiunile de comandă pot fi găsite în man nfsstat.

showmount: Afișează informații despre starea NFS

utilitarul showmount interogează demonul rpc.mountd de 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- este afișată o listă a sistemelor de fișiere exportate din punctul de vedere al 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 cataloagele. De exemplu, gazda ARCHIV ne oferă o listă de directoare exportate cu adresele IP ale gazdelor cărora li se permite să monteze directoarele specificate:

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ă demonul NFSd nu rulează pe gazda FILES

exportfs: gestionați directoarele exportate

Această comandă servește directoarele exportate specificate în 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 este executat când demonul nfsd este pornit cu argumentul -r. Utilitarul exportfs în modul kernel 2.6 comunică cu demonul rpc.mountd prin fișiere din directorul /var/lib/nfs/ și nu comunică direct cu nucleul. Fără parametri, afișează o listă a sistemelor de fișiere exportate în prezent.

parametrii exportfs:

• [client:nume-director] - adăugați sau eliminați sistemul de fișiere specificat pentru clientul specificat)
• -v - afișează mai multe informații
• -r - reexportă toate directoarele (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 - opțiuni separate prin virgule (similar cu opțiunile utilizate în /etc/exports; adică puteți modifica opțiunile sistemelor de fișiere deja montate)
• -i - nu utilizați /etc/exports când adăugați, doar opțiunile curente ale liniei de comandă
• -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 (OS client) trebuie să montați-lși primiți de la server indicatorul spre ea. Montare NFS se poate face cu sau folosind unul dintre montatoarele automate care prolifera (amd, autofs, automount, supermount, superpupermount). Procesul de instalare este bine demonstrat în ilustrația de mai sus.

Pe Clienți NFS nu este nevoie să rulați niciun daemon, funcțiile clientului execută un modul kernel kernel/fs/nfs/nfs.ko, care este utilizat la montarea unui sistem de fișiere la distanță. Directoarele exportate de pe server pot fi montate pe client în următoarele moduri:

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

Nu voi lua în considerare a treia metodă cu autofs în acest articol, datorită informațiilor sale voluminoase. Poate că va exista o descriere separată în articolele viitoare.

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

Un exemplu de utilizare a comenzii mount este prezentat în postare. 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 /arhiv-mic pe server Arhiva V punct local montare /archivs/archiv-small cu opțiuni implicite (adică citire și scriere). Cu toate că comanda de montareîn cele mai recente distribuții poate înțelege ce tip de sistem de fișiere este utilizat chiar și fără a specifica tipul, dar totuși indică parametrul -t nfs de dorit. A doua comandă montează directorul exportat /arhivă-mare pe server Arhiva la directorul local /archivs/archiv-big cu opțiune numai pentru citire ( ro). comanda de montare fara parametri, ne arata clar rezultatul montajului. Pe lângă opțiunea de numai citire (ro), este posibil să specificați și altele Opțiuni de bază la montarea NFS:

• nosuid - Această opțiune interzice executarea programelor din directorul montat.
• nodev(fără dispozitiv - nu dispozitiv) - Această opțiune interzice utilizarea caracterelor și blochează fișierele speciale ca dispozitive.
• blocare (nolock)- Permite blocarea NFS (implicit). nolock dezactivează blocarea NFS (nu pornește demonul lockd) și este util atunci când lucrați cu servere mai vechi care nu acceptă blocarea NFS.
• mounthost=nume- Numele gazdei pe care rulează demonul de montare NFS - mountd.
• mountport=n - Portul folosit de demonul mountd.
• port=n- portul folosit pentru conectarea la serverul NFS (implicit este 2049 dacă demonul rpc.nfsd nu este înregistrat pe serverul RPC). Dacă n=0 (implicit), atunci NFS interogează harta port pe server pentru a determina 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, încercați din nou în fundal pentru a nu bloca procesul de pornire a sistemului.
• fg- Dacă pierdeți accesul la server, încercați din nou î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 primul rând pentru depanare.

Opțiuni care afectează memorarea în cache a atributelor pe monturile NFS

Atributele fișierului, stocate în (inoduri), cum ar fi timpul de modificare, dimensiunea, legăturile hard, proprietarul, se schimbă de obicei rar pentru fișierele obișnuite și chiar mai puțin frecvent 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, 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. Cache-ul de atribute este actualizat periodic în conformitate cu parametrii specificați:

• ac (noac) (cache de attribute- cache de atribute) - Permite memorarea în cache de atribute (implicit). Deși opțiunea 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 (directorul cache al atributelor maxim- cache maximă a atributelor pentru un fișier de director) - Numărul maxim de secunde pe care NFS le așteaptă înainte de a actualiza atributele de director (implicit 60 de secunde)
• acdirmin=n (directorul cache al atributului minim- memoria cache minimă a atributelor pentru un fișier de director) - Numărul minim de secunde pe care NFS le așteaptă înainte de a actualiza atributele de director (implicit 30 de secunde)
• acregmax=n (cache de atribute maxim fișier normal- 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 60 sec.)
• acregmin=n (cache de atribute fișier obișnuit minim- cache minimă a atributelor pentru un fișier obișnuit) - Numărul minim de secunde pe care NFS le așteaptă înainte de a actualiza atributele unui fișier obișnuit (implicit 3 secunde)
• actimeo=n (timeout cache-ul atributului- timeout caching atribute) - Înlocuiește valorile pentru toate opțiunile de mai sus. Dacă actimeo nu este specificat, atunci valorile de mai sus preiau valorile implicite.

Opțiuni de tratare a erorilor NFS

Următoarele opțiuni 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) - Încercările de a monta un NFS eșuat în prim-plan/fundal.
• greu moale)- afișează mesajul „serverul nu răspunde” la consolă când este atins timpul de expirare și continuă să încerce montarea. Cu opțiunea oferită moale- în timpul unui timeout, informează programul care a apelat operația despre o eroare I/O. (se recomandă să nu folosiți opțiunea soft)
• nointr (intr) (nicio întrerupere- nu întrerupeți) - Nu permite semnalelor să întrerupă operațiunile cu fișiere într-o ierarhie de directoare montată greu atunci când este atins un timeout mare. intr- permite întreruperea.
• retrans=n (valoarea de retransmisie- valoarea 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ă opțiunea hard/soft.
• reîncercați=n (valoare de reîncercare- 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 (valoarea timeout- valoarea timeout) - Numărul de zecimi de secundă pe care serviciul NFS le așteaptă înainte de a retransmite în cazul RPC sau un timeout mic (implicit 7). Această valoare crește cu fiecare timeout până la maximum 60 de secunde sau până când apare un timeout mare. Când rețea ocupată, 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)

Puteți selecta timpul optim pentru o anumită valoare a pachetului transmis (valori rsiize/wsize) folosind comanda ping:

FIȘIERE ~ # ping -s 32768 arhiv PING arhiv.DOMAIN.local (10.0.0.6) 32768(32796) octeți de date. 32776 octeți din archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0,931 ms 32776 octeți din archiv.domain.local (10.0.0.6): icmp_req=2 ttl=64 time=0,957 ms 32776 bytes din archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03 ms 32776 bytes din archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 time=1.00 ms 32776 bytes din arhiva .domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1.08 ms ^C --- archive.DOMAIN.local statistics ping --- 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 32768 (32Kb), timpul său de călătorie de la client la server și înapoi plutește în jur de 1 milisecundă. Dacă acest timp depășește 200 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. În consecință, este recomandabil să faceți acest test în timpul sarcinii grele ale rețelei.

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 recomandabil să demontați mai întâi toate resursele de pe clienți
• opriți și dezactivați pornirea rpcidmapd dacă nu intenționați să utilizați NFSv4: chkconfig --level 345 rpcidmapd off service rpcidmapd stop
• dacă este necesar, permiteți pornirea serviciilor portmap, nfs și nfslock: chkconfig --levels 345 portmap/rpcbind on chkconfig --levels 345 nfs on chkconfig --levels 345 nfslock on
• 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 lansat rmmod nfs rmmod nfs_acl rmmod lockd
• deschide porturi în
  • 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 a configura rpc.rquota pentru versiuni noi, trebuie să adăugați linia RQUOTAD_PORT=4003 la /etc/sysconfig/nfs
• pentru a configura rpc.rquota este necesar pentru versiunile mai vechi (totuși, 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 la /etc/modprobe[.conf]: opțiuni lockd nlm_udpport=4001 nlm_tcpport=4001
• legați serverul de stare rpc.statd la portul 4000 (pentru sisteme mai vechi, rulați rpc.statd cu comutatorul -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. partajat NFS deschis și inscriptibil, puteți utiliza opțiunea all_squashîn combinație cu opțiuni 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 99 cu gid 99 /fișiere 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 99 cu gid 99 /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 directorul specificat, nobody.nobody trebuie să fie proprietarul directorului partajat:

man mount
omul exportă
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm - Performanță NFS de la IBM.

Salutări, McSim!