Instalimi dhe konfigurimi i serverit NFS dhe klientit NFS. Testimi i sjelljes së instalimit të NFS

Ja, çfarë është më pas? Si mund të shikoj filma dhe të dëgjoj skedarë muzikorë të shkarkuar? A keni vërtet nevojë t'i digjni ato në disqe dhe t'i transferoni në këtë mënyrë në një kompjuter me një GUI? Apo do t'ju duhet t'i kopjoni ato në SFTP të ngadaltë? Jo! NFS vjen në shpëtim! Jo, kjo nuk është një seri lojërash garash, por një sistem skedari rrjeti.
Sistemi i skedarëve të rrjetit (NFS) është një sistem skedari rrjeti që lejon përdoruesit të aksesojnë skedarët dhe drejtoritë e vendosura në kompjuterë të largët sikur skedarët dhe drejtoritë të ishin lokale. Avantazhi kryesor i një sistemi të tillë është se stacionet e punës individuale mund të përdorin më pak hapësirën e tyre të diskut, pasi të dhënat e përbashkëta ruhen në një makinë të veçantë dhe janë të disponueshme për makinat e tjera në rrjet. NFS është një aplikacion klient-server. Kjo do të thotë, një klient NFS duhet të instalohet në sistemin e përdoruesit dhe një server NFS në kompjuterët që ofrojnë hapësirën e tyre në disk.

Instalimi dhe konfigurimi i një serveri NFS (192.168.1.2)

1. Instaloni. Pasi të jeni lidhur nëpërmjet SSH me kompjuterin nga serveri, ose thjesht në tastierën e tij, shkruani:

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

Kjo do të instalojë serverin NFS si dhe paketën e kërkuar të portmap-it.

2. Konfigurimi. Për të konfiguruar listën e drejtorive që duam të hapim dhe listën të cilëve duam t'i hapim ato, modifikoni skedarin / etj / eksportet :

Sudo nano / etj / eksporton / të dhëna 192.168.1.1/24 (rw,no_root_squash,async)

Në shembullin e mësipërm, ne hapëm drejtorinë në server / të dhëna dhe nëndrejtoritë e tij për përdorim të përbashkët nga të gjithë kompjuterët me IP: 192.168.1.1 - 192.168.1.255 me të drejta leximi dhe shkrimi.

Një shembull tjetër:

/ shtëpi / serg / 192.168.1.34 (ro, asinkron)

Ky shembull e bën direktorinë kryesore të serg të përdoruesit të disponueshëm në modalitetin vetëm për lexim për kompjuterin me IP 192.168.1.34. Të gjithë kompjuterët e tjerë në rrjet nuk do të kenë akses në këtë direktori.

Opsionet e disponueshme:

• ro - leje vetëm për lexim. Ju nuk keni nevojë ta specifikoni atë, pasi është instaluar si parazgjedhje;
• rw - u jep klientëve akses për shkrim;
• no_root_squash - si parazgjedhje, përdoruesi rrënjë në makinën e klientit nuk do të ketë akses në drejtoritë e hapura në server. Me këtë opsion, ne e heqim këtë kufizim. Për arsye sigurie, është mirë të mos e bëni këtë;
• noaccess - mohon hyrjen në drejtorinë e specifikuar. Mund të jetë e dobishme nëse keni vendosur më parë aksesin për të gjithë përdoruesit e rrjetit në një drejtori të caktuar dhe tani dëshironi të kufizoni aksesin në nëndrejtori vetëm për disa përdorues.

Tani duhet të rinisni serverin nfs-kernel:

Rinisja e Sudo /etc/init.d/nfs-kernel-server

Nëse pas kësaj dëshironi të ndryshoni diçka në skedar / etj / eksportet , atëherë në mënyrë që ndryshimet të hyjnë në fuqi, thjesht ekzekutoni komandën e mëposhtme:

Sudo eksportfs -a

Gjithçka. Serveri NFS është instaluar dhe konfiguruar. Mund të shkoni te klienti NFS.

Instalimi dhe konfigurimi i klientit NFS

1. Instalimi. Ne kryejmë sa më poshtë në terminalin e kompjuterit që do të lidhet:

Sudo apt-get install portmap nfs-common

2. Vendosja. Së pari, le të krijojmë një direktori ku do të montohet dosja në distancë:

Cd ~ mkdir të dhëna

Mund të montoni në dy mënyra - çdo herë me dorë ose duke shkruar opsionet e montimit në një skedar / etj / fstab.

Metoda 1. Montimi me dorë
Krijoni një skedar teksti në desktop ose në ndonjë dosje tjetër:

Nano ~ / desktop \ desktop / nfs-server-connect

Ne i shkruajmë asaj:

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

Ne e bëjmë atë të ekzekutueshme:

Chmod + x ~ / desktop \ desktop / nfs-server-connect

Tani kur më duhet të lidhem me serverin, e ekzekutoj këtë skript në terminal në mënyrë që të mund të fus fjalëkalimin për sudo.

Metoda 2. Shtimi në / etc / fstab
Hapni / etc / fstab:

Sudo nano / etj / fstab

Dhe shtoni një rresht në fund të skedarit:

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

Kujdes! Zëvendësoni 192.168.1.2:/data me IP-në ose emrin e serverit dhe shtegun për në drejtorinë e përbashkët. Opsionet e montimit mund të ndryshohen.

Opsioni vështirë lidh në mënyrë të ngurtë drejtorinë e klientit me serverin dhe nëse serveri bie, kompjuteri juaj gjithashtu mund të ngrijë. Opsioni i butë, siç nënkupton edhe emri i tij, nuk është aq kategorik.

Pas ruajtjes së skedarit, mund të montoni dosjen në distancë.

Sistemi i skedarëve NFS (Network File System) u krijua nga Sun Microsystems. Aktualisht është sistemi standard i skedarëve të rrjetit për sistemet operative të bazuara në UNIX, dhe klientët dhe serverët NFS janë implementuar për shumë sisteme të tjera operative. Parimet e organizimit të tij janë aktualisht të standardizuara nga komuniteti i Internetit, versioni më i fundit i NFS v.4 përshkruhet nga specifikimi RFC ZOJ, i lëshuar në dhjetor 2000.

NFS është një sistem që mbështet një skemë të aksesit të skedarëve në distancë. Puna e përdoruesit me skedarët në distancë pas funksionimit të montimit bëhet plotësisht transparent - nënpema e sistemit të skedarëve të serverit NFS bëhet një nënpemë e sistemit lokal të skedarëve.

Një nga qëllimet e zhvilluesve të NFS ishte të mbështeste sisteme heterogjene me klientë dhe serverë që drejtonin sisteme të ndryshme operative në platforma të ndryshme harduerike. Ky synim ndihmohet nga zbatimi i NFS i bazuar në RFC nga Sun, i cili mbështet strukturën e paracaktuar XDR për përfaqësimin e unifikuar të argumenteve të procedurës në distancë.

Për të siguruar qëndrueshmërinë e klientit ndaj dështimeve të serverit, NFS ka adoptuar një qasje pa shtetësi, domethënë, kur punoni me skedarë, serverët nuk ruajnë të dhëna për skedarët e hapur nga klientët.

Ideja bazë pas NFS është të lejojë një grup arbitrar përdoruesish të ndajnë një sistem skedarësh të përbashkët. Më shpesh, të gjithë përdoruesit i përkasin të njëjtit rrjet lokal, por jo domosdoshmërisht. Ju gjithashtu mund të ekzekutoni NFS në WAN. Çdo server NFS ofron një ose më shumë nga drejtoritë e tij për akses në distancë të klientit. Drejtoria deklarohet e aksesueshme me të gjitha nëndrejtoritë e saj. Lista e drejtorive të kaluara nga serveri gjendet në skedarin / etc / exports, kështu që këto direktori eksportohen automatikisht sapo serveri të niset. Klientët aksesojnë drejtoritë e eksportuara duke u montuar. Shumë stacione pune Sun janë pa disk, por edhe atëherë është e mundur të montoni një sistem skedarësh në distancë në direktorinë rrënjësore me të gjithë sistemin e skedarëve në server. Ekzekutimi i programeve është pothuajse i pavarur nga vendi ku ndodhet skedari: në nivel lokal ose në një disk të largët. Nëse dy ose më shumë klientë kanë montuar të njëjtën drejtori në të njëjtën kohë, atëherë ata mund të komunikojnë duke ndarë skedarin.

Sistemi i skedarëve NFS përdor dy protokolle në punën e tij.

Protokolli i parë NFS kontrollon montimet. Klienti i dërgon serverit emrin e drejtorisë plotësisht të kualifikuar dhe kërkon leje për ta montuar atë direktori diku në pemën e tij të direktoriumit. Në këtë rast, serveri nuk tregohet se ku do të montohet direktoria e serverit. Pas marrjes së emrit, serveri vërteton kërkesën dhe i kthen klientit një përshkrues skedari që është pika e montimit në distancë. Përshkruesi përfshin një përshkrues të llojit të sistemit të skedarëve, numrin e diskut, numrin inode të drejtorisë që është pika e montimit në distancë dhe informacionin e sigurisë. Leximi dhe shkrimi i skedarëve nga sistemet e skedarëve të montuar përdorin përshkrues skedarësh në vend të një emri simbolik.

Montimi mund të bëhet automatikisht duke përdorur skedarët e grupit në nisje. Ekziston një mundësi tjetër për montimin automatik: kur OS niset në një stacion pune, sistemi i skedarëve në distancë nuk është i montuar, por kur skedari në distancë hapet për herë të parë, OS dërgon kërkesa te secili server dhe, pasi zbulon këtë skedar, monton direktoriumin e serverit në të cilin ndodhet skedari i gjetur.

Protokolli i dytë NFS përdoret për të hyrë në skedarët dhe drejtoritë në distancë. Klientët mund t'i dërgojnë një kërkesë serverit për të kryer disa veprime në drejtori ose për të lexuar ose shkruar një skedar. Përveç kësaj, ata mund të kërkojnë për atribute të skedarëve si lloji, madhësia, koha e krijimit dhe modifikimit. NFS mbështetet nga shumica e thirrjeve të sistemit UNIX, me përjashtim të hapjes dhe mbylljes. Përjashtimet e hapura dhe të mbylljes nuk janë të rastësishme. Në vend të hapjes së një skedari në distancë, klienti dërgon një mesazh në server që përmban emrin e skedarit, duke kërkuar një kërkim dhe duke kthyer një përshkrues skedari. Ndryshe nga thirrja e hapur, thirrja e kërkimit nuk kopjon asnjë informacion në tabelat e brendshme të sistemit. Thirrja e leximit përmban përshkruesin e skedarit për t'u lexuar, zhvendosjen në skedarin që lexohet dhe numrin e bajteve për t'u lexuar. Avantazhi i kësaj skeme është se serveri nuk mban mend asgjë në lidhje me skedarët e hapur. Në këtë mënyrë, nëse serveri prishet dhe më pas rikthehet, informacioni për skedarët e hapur nuk do të humbasë, sepse nuk mbështetet.

Nëse serveri dështon, klienti thjesht vazhdon të dërgojë komanda për të lexuar ose shkruar në skedarë, por pa marrë përgjigje dhe pa mbaruar afatin, klienti përsërit kërkesat e tij. Pas rindezjes, serveri merr një kërkesë tjetër të përsëritur nga klienti dhe i përgjigjet asaj. Kështu, një ndërprerje e serverit shkakton vetëm një pauzë në shërbimin e klientit, por nuk kërkohen veprime shtesë nga klientët për të rivendosur lidhjet dhe për të rihapur skedarët.

Fatkeqësisht, NFS e bën të vështirë bllokimin e skedarëve. Në shumë sisteme operative, një skedar mund të hapet dhe kyçet në mënyrë që proceset e tjera të mos mund t'i qasen. Kur skedari mbyllet, bllokimi lirohet. Në sistemet pa shtetësi si NFS, bllokimi nuk mund të lidhet me hapjen e një skedari, pasi serveri nuk e di se cili skedar është i hapur. Rrjedhimisht, NFS kërkon kontrolle të veçanta shtesë të kyçjes.

NFS përdor cache-in nga ana e klientit, të dhënat transferohen në bllokun e memories së memories në bllok dhe përdoret leximi përpara, në të cilin leximi i një blloku në cache sipas kërkesës nga aplikacioni pasohet gjithmonë nga leximi i bllokut tjetër me iniciativën e sistemi. Metoda e memorizimit NFS nuk ruan semantikën UNIX për ndarjen e skedarëve. Në vend të kësaj, përdoret semantika e kritikuar në mënyrë kritike, në të cilën ndryshimet në të dhënat në një skedar të ruajtur nga një klient janë të dukshme për një klient tjetër, në varësi të kohës. Në hapjen tjetër të një skedari në cache-in e tij, klienti kontrollon me serverin se kur skedari është modifikuar për herë të fundit. Nëse kjo ndodh pasi skedari është vendosur në cache, skedari hiqet nga cache dhe një kopje e re e skedarit merret nga serveri. Klientët shpërndajnë modifikimet e bëra në cache çdo 30 sekonda, në mënyrë që serveri të marrë përditësime me një vonesë të gjatë. Si rezultat i mekanizmave për pastrimin e të dhënave nga cache dhe shpërndarjen e modifikimeve, të dhënat e marra nga çdo klient nuk janë gjithmonë më të fundit.

Replikimi NFS nuk mbështetet.

Shërbimi i drejtorisë

Qëllimi dhe parimet e organizimit

Ashtu si një organizatë e madhe, një rrjet i madh kompjuterik duhet të ruajë në mënyrë qendrore sa më shumë informacion referimi për veten e tij. Zgjidhja e shumë problemeve në rrjet mbështetet në informacionin rreth përdoruesve të rrjetit - emrat e tyre të përdorur për hyrjen logjike, fjalëkalimet, të drejtat e aksesit në burimet e rrjetit, si dhe burimet dhe komponentët e rrjetit: serverët, kompjuterët e klientit, ruterat, portat, vëllimet e skedarëve. sisteme, printera, etj.

Këtu janë shembuj të detyrave më të rëndësishme që kërkojnë një bazë të dhënash të centralizuar të informacionit të referencës në rrjet:

• Një nga detyrat e kryera më shpesh në sistem, bazuar në informacionin referues për përdoruesit, është vërtetimi i tyre, në bazë të të cilit më pas kryhet autorizimi i aksesit. Rrjeti duhet disi të ruajë në mënyrë qendrore llogaritë e përdoruesve që përmbajnë emra dhe fjalëkalime.
• Pasja e një lloji të bazës së të dhënave të centralizuar kërkon mbështetjen e transparencës së aksesit në shumë burime të rrjetit. Një bazë e tillë e të dhënave duhet të ruajë emrat e këtyre burimeve dhe hartimin e emrave me identifikues numerikë (për shembull, adresat IP), duke ju lejuar të gjeni këtë burim në rrjet. Transparenca mund të sigurohet për aksesimin e serverëve, vëllimeve të sistemit të skedarëve, ndërfaqeve të procedurës RPC, objekteve të programit të aplikacionit të shpërndarë dhe shumë burimeve të tjera të rrjetit.
• Email-i është një shembull tjetër popullor i një shërbimi që dëshiron një tavolinë ndihmëse të bazuar në ueb që ruan të dhënat e emrit të postës së përdoruesit.
• Kohët e fundit, rrjetet kanë filluar gjithnjë e më shumë të përdorin mjetet e menaxhimit të cilësisë së shërbimit të trafikut (QoS), të cilat kërkojnë gjithashtu informacion për të gjithë përdoruesit dhe aplikacionet e sistemit, kërkesat e tyre për cilësinë e trafikut të parametrave të shërbimit, si dhe për të gjitha pajisjet e rrjetit me të cilat mund të të përdoret për të menaxhuar trafikun (ruterat, çelësat, portat, etj.).
• Organizimi i aplikacioneve të shpërndara mund të thjeshtohet ndjeshëm nëse rrjeti ka një bazë të dhënash që ruan informacione për modulet-objektet e disponueshme të programit dhe vendndodhjen e tyre në serverët e rrjetit. Një aplikacion që duhet të kryejë disa veprime standarde bën një kërkesë në një bazë të dhënash të tillë dhe merr adresën e një objekti programi që mund të kryejë veprimin e kërkuar.
• Sistemi i menaxhimit të rrjetit duhet të ketë një bazë për ruajtjen e informacionit në lidhje me topologjinë e rrjetit dhe karakteristikat e të gjithë elementëve të rrjetit si ruterat, ndërprerësit, serverët dhe kompjuterët e klientit. Pasja e informacionit të plotë për përbërjen e rrjetit dhe lidhjet e tij i lejon sistemit të automatizuar të menaxhimit të rrjetit të identifikojë saktë mesazhet në lidhje me ngjarjet e emergjencës dhe të gjejë shkakun e tyre rrënjësor. I organizuar sipas njësisë së biznesit, informacioni në lidhje me harduerin dhe softuerin e instaluar të rrjetit është i dobishëm në vetvete, pasi ndihmon administratorët të kenë një pamje solide të shëndetit të rrjetit dhe të planifikojnë zhvillimin e tij.

Shembuj të tillë mund të vazhdohen, por nuk është e vështirë të citosh një kundërargument që hedh dyshime mbi nevojën për të përdorur një bazë të dhënash të centralizuar të informacionit të referencës në rrjet - për një kohë të gjatë rrjetet funksionuan pa një bazë të dhënash të vetme referencë, dhe shumë rrjete ende punoni pa të. Në të vërtetë, ka shumë zgjidhje private që bëjnë të mundur organizimin efektiv të funksionimit të një rrjeti bazuar në bazat e të dhënave të referencës private, të cilat mund të përfaqësohen nga skedarë teksti të zakonshëm ose tabela të ruajtura në trupin e aplikacionit. Për shembull, UNIX përdor tradicionalisht një skedar passwd për të ruajtur emrat e përdoruesve dhe fjalëkalimet, i cili mbulon vetëm përdoruesit në një kompjuter. Ju gjithashtu mund të ruani emrat e marrësve të e-mail në një skedar lokal në kompjuterin e klientit. Dhe sisteme të tilla të ndihmës private funksionojnë mirë - praktika e konfirmon këtë.

Megjithatë, ky kundërshtim është i vlefshëm vetëm për rrjetet e vogla dhe të mesme; në rrjetet e mëdha, bazat e të dhënave lokale referente individuale humbasin efektivitetin e tyre. DNS në internet është një shembull i mirë që dëshmon se nuk është i zbatueshëm për zgjidhjet e brendshme për rrjete të mëdha. Pasi madhësia e internetit tejkaloi një kufi të caktuar, u bë e paefektshme ruajtja e informacionit në lidhje me korrespondencën e emrave dhe adresave IP të kompjuterëve në rrjet në skedarët e tekstit lokal. Ishte e nevojshme të krijohej një bazë të dhënash e shpërndarë e mbështetur nga serverë emrash të lidhur në mënyrë hierarkike dhe një shërbim i centralizuar në krye të asaj baze të dhënash në mënyrë që zgjidhja simbolike e emrave në internet të funksiononte shpejt dhe me efikasitet.

Për një rrjet të madh, është gjithashtu i paefektshëm përdorimi i një numri të madh shërbimesh ndihmëse për qëllime të ngushta: një për vërtetim, një tjetër për menaxhimin e rrjetit, e treta për zgjidhjen e emrave të kompjuterëve, etj. Edhe nëse secili prej këtyre shërbimeve është i organizuar mirë dhe kombinon një ndërfaqe e centralizuar me një bazë të dhënash të shpërndarë, një numër i madh shërbimesh ndihmëse çon në dyfishim të sasive të mëdha të informacionit dhe ndërlikon administrimin dhe menaxhimin e rrjetit. Për shembull, Windows NT ka të paktën pesë lloje të ndryshme të bazave të të dhënave të referencës. Drejtoria kryesore e domenit (Shërbimi i Drejtorisë së Domainit NT) ruan informacione rreth përdoruesve, të cilat kërkohet kur organizojnë hyrjen e tyre logjike në rrjet. Të dhënat për të njëjtët përdorues mund të përmbahen në një drejtori tjetër të përdorur nga posta elektronike e Microsoft Mail. Tre baza të tjera të të dhënave mbështesin zgjidhjen e adresave: WINS harton emrat e Netbios në adresat IP, direktoria DNS (Serveri i emrave të domenit) është i dobishëm kur lidhni një rrjet NT me internetin dhe së fundi, Drejtoria DHCP përdoret për të caktuar automatikisht adresat IP në kompjuterët në rrjet. ... Natyrisht, një shumëllojshmëri e tillë e shërbimeve të ndihmës e ndërlikon jetën e administratorit dhe çon në gabime shtesë kur kredencialet e të njëjtit përdorues duhet të futen në baza të të dhënave të shumta. Prandaj, në versionin e ri të Windows 2000, shumica e informacionit të ndihmës në lidhje me sistemin mund të ruhet nga Active Directory, një shërbim i vetëm, i centralizuar ndihmës që përdor një bazë të dhënash të shpërndarë dhe është i integruar me DNS.

Rezultati i zhvillimit të sistemeve të ruajtjes së informacionit të referencës ishte shfaqja në sistemet operative të rrjetit të një shërbimi të veçantë - të ashtuquajturat Shërbimet e Direktorisë, të quajtur edhe shërbim referimi (disaksion). Shërbimi i drejtorisë ruan informacione për të gjithë përdoruesit dhe burimet e rrjetit në formën e objekteve të unifikuara me atribute të caktuara, dhe gjithashtu ju lejon të pasqyroni marrëdhëniet midis objekteve të ruajtura, të tilla si përkatësia e përdoruesve në një grup të caktuar, të drejtat e aksesit të përdoruesit në kompjuter, futja e disa nyjeve në një nënrrjet, lidhjet e komunikimit ndërmjet nënrrjeteve, prodhimi i serverit, etj. Shërbimi i drejtorisë ju lejon të kryeni disa operacione bazë në objektet e ruajtura, të tilla si shtimi dhe heqja e një objekti, përfshirë një objekt në një objekt tjetër, ndryshimi i vlerave të një atributi objekti, atribute leximi dhe disa të tjera. Në mënyrë tipike, aplikacione të ndryshme specifike të rrjetit ndërtohen në krye të shërbimit të drejtorisë, të cilat përdorin informacionin e shërbimit për detyra specifike: menaxhimin e rrjetit, vërtetimin e përdoruesit, transparencën e shërbimit dhe të tjera të listuara më sipër. Një shërbim drejtorie zakonisht ndërtohet në një model klient-server: serverët ruajnë një bazë të dhënash të informacionit referencë që klientët përdorin duke dërguar kërkesa te serverët përmes rrjetit. Për një klient shërbimi direktoriumi, duket se është një sistem i vetëm i centralizuar, megjithëse shumica e shërbimeve të mira të drejtorive kanë një strukturë të shpërndarë që përfshin një numër të madh serverësh, kjo strukturë është transparente për klientët.

Një çështje e rëndësishme është organizimi i bazës së të dhënave të referencës. Një bazë e vetme e të dhënave që ruan një vëllim të madh informacioni referencë krijon të njëjtat probleme si çdo bazë tjetër e madhe e të dhënave. Zbatimi i Help Desk si një bazë të dhënash lokale e ruajtur si një kopje e vetme në një nga serverët e rrjetit nuk është i përshtatshëm për një sistem të madh për disa arsye, kryesisht për shkak të performancës së ulët dhe besueshmërisë së ulët të një zgjidhjeje të tillë. Performanca do të jetë e ulët për faktin se kërkesat për bazën e të dhënave nga të gjithë përdoruesit dhe aplikacionet në rrjet do të shkojnë në një server të vetëm, i cili, me një numër të madh kërkesash, me siguri do të pushojë së përballuari me përpunimin e tyre. Kjo do të thotë, një zgjidhje e tillë nuk përshkallëzohet mirë për sa i përket numrit të përdoruesve të shërbyer dhe burimeve të përbashkëta. Besueshmëria gjithashtu nuk mund të jetë e lartë në një sistem me një kopje të vetme të të dhënave. Përveç heqjes së kufizimeve në performancën dhe besueshmërinë, është e dëshirueshme që struktura e bazës së të dhënave të lejojë grupimin logjik të burimeve dhe përdoruesve sipas ndarjeve strukturore të ndërmarrjes dhe të caktojë një administrator për secilin grup të tillë.

Sfidat e ruajtjes së performancës dhe besueshmërisë ndërsa rrjeti rritet zakonisht adresohen përmes bazave të të dhënave të shpërndara të referencës. Ndarja e të dhënave nëpër serverë të shumtë redukton ngarkesën në secilin server, duke ruajtur besueshmërinë duke pasur kopje të shumta të secilës pjesë të bazës së të dhënave. Për secilën pjesë të bazës së të dhënave, mund të caktoni administratorin e vet, i cili ka të drejta aksesi vetëm në objektet e pjesës së tij të informacionit për të gjithë sistemin. Për përdoruesin (dhe për aplikacionet e rrjetit), një bazë të dhënash e tillë e shpërndarë duket të jetë një bazë e vetme e të dhënave që ofron akses në të gjitha burimet e rrjetit, pavarësisht se nga cili stacion pune erdhi kërkesa.

Ekzistojnë dy standarde të njohura për shërbimet e drejtorive. Së pari, është standardi X.500 i zhvilluar nga ITU-T (në kohën e zhvillimit të standardit, kjo organizatë quhej CCITT). Ky standard përcakton funksionet, organizimin e tavolinës së ndihmës dhe protokollin e aksesit në të. I projektuar kryesisht për përdorim me shërbimin postar X.400, standardi X.500 ju lejon të organizoni me efikasitet ruajtjen e çdo informacioni referencë dhe shërben si një bazë e mirë për një shërbim universal të drejtorive në rrjet.

Një standard tjetër është standardi i Protokollit të Qasjes në Drejtorinë e Lehtë (LDAP) i zhvilluar nga komuniteti i Internetit. Ky standard përcakton një protokoll të thjeshtuar të aksesit të shërbimit të direktoriumit, sepse shërbimet e ndërtuara në standardin X.500 kanë rezultuar të jenë shumë të rënda. LDAP është bërë i përhapur dhe është bërë standardi de fakto si një protokoll aksesi i klientit për burimet e tavolinës së ndihmës.

Ekzistojnë gjithashtu disa zbatime praktike të shërbimeve të drejtorive për sistemet operative të rrjetit. Më i përhapuri është shërbimi Novell NDS, i zhvilluar në vitin 1993 për sistemin operativ të rrjetit NetWare 4.0, ndërsa sot zbatohet edhe për Windows NT / 2000. Me interes të madh ka Active Directory i Microsoft për Windows 2000. Të dyja këto shërbime mbështesin protokollin e aksesit LDAP dhe mund të funksionojnë në rrjete shumë të mëdha për shkak të shpërndarjes së tyre.

Shërbimi i drejtorisë NDS

NetWare Directory Services (NDS) është një shërbim referimi global i bazuar në një bazë të dhënash të orientuar drejt objekteve të burimeve të rrjetit. Baza e të dhënave NDS përmban informacione për të gjitha burimet e rrjetit, duke përfshirë informacionin për përdoruesit, grupet e përdoruesve, printerët, vëllimet dhe kompjuterët. NetWare OS (dhe klientët e tjerë NDS që funksionojnë në platforma të tjera) përdor informacionin NDS për të siguruar akses në këto burime.

NDS zëvendësoi direktorinë bindery të versioneve të mëparshme të NetWare. Direktoria bindery është një bazë të dhënash "e sheshtë" ose me një nivel, e krijuar për të mbështetur një server të vetëm. Ai përdori gjithashtu konceptin e "objektit" për një burim rrjeti, por interpretimi i këtij termi ndryshonte nga ai i pranuar përgjithësisht. Objektet lidhëse u identifikuan me vlera të thjeshta numerike dhe kishin atribute specifike. Megjithatë, për këto objekte, nuk kishte një marrëdhënie të qartë trashëgimie për klasat e objekteve, kështu që marrëdhënia midis objekteve lidhëse u vendos në mënyrë arbitrare nga administratori, gjë që shpesh çonte në shkelje të integritetit të të dhënave.

Baza e të dhënave NDS është një bazë të dhënash me nivele që ruan informacionin e burimeve për të gjithë serverët në një rrjet. Për pajtueshmërinë e prapambetur me NetWare, NDS ofron një mekanizëm emulimi bindery.

NDS është një përmirësim i rëndësishëm krahasuar me versionet e mëparshme duke:

• shpërndarja;
• replikueshmëria;
• transparencë;
• globaliteti.

Shpërndarja do të thotë që informacioni nuk ruhet në një server të vetëm, por ndahet në pjesë të quajtura ndarje. NetWare i ruan këto ndarje në shumë serverë në rrjet (Figura 10.8). Kjo veçori thjeshton shumë administrimin dhe menaxhimin e një rrjeti të madh, pasi administratori i duket si një sistem i vetëm. Gjithashtu siguron akses më të shpejtë në bazën e të dhënave të burimeve të rrjetit duke hyrë në serverin më të afërt.

Oriz. 10.8. Ndarjet e bazës së të dhënave NDS

Një kopje është një kopje e informacionit të ndarjes NDS. Ju mund të krijoni një numër të pakufizuar kopjesh të secilës ndarje dhe t'i ruani ato në serverë të ndryshëm. Nëse një server ndalon, atëherë kopjet e këtij informacioni mund të merren nga një server tjetër. Kjo rrit elasticitetin e sistemit sepse asnjë server nuk është përgjegjës për të gjithë informacionin në bazën e të dhënave NDS.

Transparenca është se NDS krijon automatikisht lidhje midis komponentëve të softuerit dhe harduerit që i ofrojnë përdoruesit akses në burimet e rrjetit. NDS nuk kërkon që përdoruesi të dijë vendndodhjen fizike të këtyre burimeve. Duke specifikuar një burim rrjeti me emër, do të keni akses të saktë në të edhe nëse adresa e rrjetit ose vendndodhja e tij ndryshon.

Natyra globale e NDS është se pasi të identifikoheni, ju fitoni akses në burimet në të gjithë rrjetin, jo vetëm në një server, siç ishte rasti në versionet e mëparshme. Kjo realizohet përmes procedurës globale të hyrjes. Në vend që të kyçet në një server të veçantë, përdoruesi i NDS hyn në rrjet dhe më pas fiton akses në burimet e rrjetit që i lejohen. Informacioni i dhënë gjatë hyrjes logjike përdoret për të identifikuar përdoruesin. Më vonë, kur një përdorues përpiqet të përdorë burime të tilla si serverët, vëllimet ose printerët, procesi i vërtetimit të sfondit kontrollon për të parë nëse përdoruesi ka të drejta për burimin.

Sistemi i skedarëve të rrjetit (NFS)- Protokolli i hyrjes në rrjet në sistemet e skedarëve, ju lejon të lidhni sistemet e skedarëve në distancë.
I zhvilluar fillimisht nga Sun Microsystems në 1984, ai bazohet në Sun RPC: Remote Procedure Call. NFS është i pavarur nga llojet e skedarëve të serverit dhe klientit. Ka shumë implementime të serverëve dhe klientëve NFS për sisteme të ndryshme operative. Aktualisht, përdoret NFS v.4, i cili mbështet mjete të ndryshme vërtetimi (në veçanti, Kerberos dhe LIPKEY duke përdorur protokollin RPCSEC GSS) dhe listat e kontrollit të aksesit (si tipet POSIX ashtu edhe Windows).
NFS u siguron klientëve qasje transparente në skedarët dhe sistemin e skedarëve të serverit. Ndryshe nga FTP, NFS akseson vetëm pjesët e skedarit në të cilat procesi ka aksesuar dhe përparësia e tij kryesore është se e bën këtë akses transparent. Falë kësaj, çdo aplikacion klienti që mund të funksionojë me një skedar lokal mund të funksionojë po aq mirë me një skedar NFS, pa ndryshuar vetë programin.
Klientët NFS aksesojnë skedarët në serverin NFS duke dërguar kërkesa RPC në server. Kjo mund të zbatohet duke përdorur procese normale të përdoruesit - domethënë, klienti NFS mund të jetë një proces përdoruesi që bën thirrje specifike RPC në server, i cili gjithashtu mund të jetë një proces përdoruesi.

versionet
NFSv1 ishte për përdorim të brendshëm vetëm për qëllime eksperimentale. Detajet e zbatimit përcaktohen në RFC 1094.
NFSv2 (RFC 1094, Mars 1989) fillimisht u ekzekutua tërësisht mbi UDP.
NFSv3 (RFC 1813, qershor 1995). Përshkruesit e skedarëve në versionin 2 janë një grup me madhësi fikse prej 32 bajt. Në versionin 3, është një grup me madhësi të ndryshueshme deri në 64 bajt. Një grup me gjatësi të ndryshueshme në XDR përcaktohet nga një numërues 4 bajt i ndjekur nga bajtë realë. Kjo zvogëlon madhësinë e përshkruesit të skedarit në implementime të tilla si UNIX, të cilat kërkojnë vetëm rreth 12 bajt, por lejon që zbatimet jo-Unix të shkëmbejnë informacion shtesë.
Versioni 2 kufizon numrin e bajteve për READ ose WRITE RPC në 8192 byte. Ky kufizim nuk zbatohet në versionin 3, që, nga ana tjetër, do të thotë se duke përdorur UDP, kufizimi do të jetë vetëm në madhësinë e datagramit IP (65535 bajt). Kjo lejon që paketat e mëdha të përdoren gjatë leximit dhe shkrimit në rrjete të shpejta.
Madhësitë e skedarëve dhe kompensimi fillestar i bajtit për procedurat READ dhe WRITE filluan të përdorin adresimin 64-bit në vend të 32-bit, gjë që lejon punën me skedarë më të mëdhenj.
Atributet e skedarit kthehen në çdo thirrje që mund të ndikojë në atributet.
Shkrimet (WRITE) mund të jenë asinkrone ndërsa në versionin 2 supozohej të ishin sinkron.
Një procedurë u hoq (STATFS) dhe shtatë u shtuan: ACCESS (kontrollimi i lejeve të skedarit), MKNOD (krijimi i një skedari të veçantë Unix), READDIRPLUS (ktheu emrat e skedarëve në një direktori së bashku me atributet e tyre), FSINFO (kthehet informacion statistikor rreth sistemi i skedarëve ), FSSTAT (kthimi i informacionit dinamik të sistemit të skedarëve), PATHCONF (kthehet informacioni i skedarit POSIX.1) dhe COMMIT (transferon shkrimet asinkrone të bëra më parë në ruajtje të vazhdueshme).
Në kohën e prezantimit të versionit 3, zhvilluesit filluan të përdorin TCP më shumë si një protokoll transporti. Edhe pse disa zhvillues kanë përdorur tashmë TCP për NFSv2, Sun Microsystems shtoi mbështetjen TCP në versionin 3 të NFS. Kjo e bëri përdorimin e NFS përmes internetit më të realizueshëm.
NFSv4 (RFC 3010, dhjetor 2000, RFC 3530, rishikuar prill 2003), i ndikuar nga AFS dhe CIFS, inkorporoi përmirësime të performancës, siguri të lartë dhe u shfaq si një protokoll i plotë. Versioni 4 ishte versioni i parë i zhvilluar në lidhje me Task Forcën e Inxhinierisë së Internetit (IETF) pasi Sun Microsystems kaloi zhvillimin e protokolleve NFS. NFS v4.1 u miratua nga IESG në janar 2010 dhe mori RFC 5661. Një risi e rëndësishme në versionin 4.1 është specifikimi pNFS - Parallel NFS, një mekanizëm për aksesin paralel të klientit NFS në të dhëna nga serverë të shumtë të shpërndarë NFS. Prania e një mekanizmi të tillë në standardin e sistemit të skedarëve të rrjetit do të ndihmojë në ndërtimin e ruajtjes së shpërndarë "cloud" dhe sistemeve të informacionit.

Struktura NFS
Struktura NFS ka tre komponentë në nivele të ndryshme:
Shtresa e aplikacionit (vetë NFS) është thirrjet e procedurës në distancë (rpc) që kryejnë operacionet e nevojshme në skedarët dhe drejtoritë në anën e serverit.
Funksionet e shtresës së prezantimit kryhen nga protokolli XDR (EXternal Data Representation), i cili është një standard i abstraksionit të të dhënave ndër-platformë. Protokolli XDR përshkruan një formë të unifikuar, kanonike, të paraqitjes së të dhënave që nuk varet nga arkitektura e sistemit kompjuterik. Kur transmeton paketa, klienti RPC i konverton të dhënat lokale në formë kanonike dhe serveri bën të kundërtën.
Shërbimi i thirrjes së procedurës në distancë (RPC), i cili i mundëson një klienti të kërkojë procedura në distancë dhe t'i ekzekutojë ato në server, është një funksion në nivel sesioni. Lidhja e burimeve të rrjetit
Procedura për lidhjen e një burimi rrjeti duke përdorur NFS quhet "eksportim". Klienti mund t'i kërkojë serverit një listë të burimeve të eksportuara që ai përfaqëson. Vetë serveri NFS nuk transmeton një listë të burimeve të tij të eksportuara.
Në varësi të opsioneve të specifikuara, burimi i eksportuar mund të montohet (i bashkangjitur) "vetëm për lexim", ju mund të përcaktoni një listë të hosteve që lejohen të montohen, të specifikoni përdorimin e RPC të sigurt (secureRPC), etj. Një nga opsionet përcakton metodën e montimit: "e vështirë" (e fortë) ose "e butë" (e butë).
Me një montim "të vështirë", klienti do të përpiqet të montojë sistemin e skedarëve me çdo kusht. Nëse serveri nuk funksionon, kjo do të çojë në faktin se i gjithë shërbimi NFS duket se ngrin: proceset që hyjnë në sistemin e skedarëve do të kalojnë në një gjendje pritjeje për përfundimin e kërkesave RPC. Nga pikëpamja e proceseve të përdoruesit, sistemi i skedarëve do të shfaqet si një disk lokal shumë i ngadaltë. Kur serveri të kthehet në linjë, shërbimi NFS do të vazhdojë të funksionojë.
Në një montim të butë, klienti NFS do të bëjë disa përpjekje për t'u lidhur me serverin. Nëse serveri nuk përgjigjet, sistemi lëshon një mesazh gabimi dhe ndalon përpjekjet për t'u montuar. Nga pikëpamja e logjikës së operacioneve të skedarëve, kur një server dështon, një montim i butë emulon një dështim të një disku lokal.
Zgjedhja e mënyrës varet nga situata. Nëse të dhënat në klient dhe server duhet të sinkronizohen në rast të një ndërprerjeje të përkohshme të shërbimit, atëherë preferohet një montim "i vështirë". Kjo mënyrë është gjithashtu e pazëvendësueshme në rastet kur sistemet e skedarëve të montuar përmbajnë programe dhe skedarë që janë jetik për funksionimin e klientit, veçanërisht për makinat pa disk. Në raste të tjera, veçanërisht kur bëhet fjalë për sisteme vetëm për lexim, modaliteti i montimit të butë është më i përshtatshëm.

Ndarja e rrjetit të përzier
NFS është ideale për rrjetet e bazuara në UNIX pasi dërgohet me shumicën e versioneve të sistemit operativ. Për më tepër, mbështetja NFS zbatohet në nivelin e kernelit UNIX. Përdorimi i NFS në kompjuterët e klientëve Windows krijon probleme të caktuara që lidhen me nevojën për të instaluar softuer të specializuar dhe mjaft të shtrenjtë të klientit. Në rrjete të tilla, përdorimi i mjeteve të shkëmbimit të bazuara në SMB / CIFS, në veçanti softueri Samba, duket se është i preferueshëm.

Standardet
RFC 1094 NFS: Specifikimi i protokollit të sistemit të skedarëve të rrjetit] (Mars 1989)
Specifikimi i Protokollit RFC 1813 NFS Version 3] (qershor 1995)
Skema e URL-ve RFC 2224 NFS
RFC 2339 Një marrëveshje ndërmjet Shoqërisë së Internetit, IETF dhe Sun Microsystems, Inc. në çështjen e NFS V.4 Protokollet
RFC 2623 NFS Versioni 2 dhe Versioni 3 Çështjet e sigurisë dhe përdorimi i RPCSEC_GSS dhe Kerberos V5 nga Protokolli NFS
RFC 2624 NFS Version 4 Konsideratat e dizajnit
Protokolli RFC 3010 NFS versioni 4
RFC 3530 Network File System (NFS) versioni 4 Protokolli
Sistemi i skedarëve të rrjetit RFC 5661 (NFS) Versioni 4 Protokolli i vogël Versioni 1

Burimet e përdorura
1.ru.wikipedia.org
2.ru.science.wikia.com
3. phone16.ru
4.4stud.info
5.yandex.ru
6.gogle.com

përdoruesi mund të punojë në kohë të ndryshme në kompjuterë të ndryshëm. Duke përdorur një server skedari, disa detyra zgjidhen menjëherë:

1. kopje rezervë e rregullt e të gjitha të dhënave: është joreale të kryhet ky operacion për disa dhjetëra ose qindra kompjuterë, por është mjaft e mundur - nga një server i vetëm ose disa serverë.
2. rritja e besueshmërisë së ruajtjes së të dhënave: është e paarsyeshme të pajisësh çdo kompjuter në rrjet me një grup RAID, sepse shumica dërrmuese e skedarëve në një kompjuter, siç janë paketat e softuerit të instaluar, janë më të lehta për t'u riinstaluar sesa për t'i mbrojtur nga dështimi; por do të ishte mjaft e arsyeshme pajisja e serverit të skedarëve me një grup RAID hardware ose organizimi i një grupi RAID softueri atje, të paktën pasqyrimi i thjeshtë i diskut.
3. Kostot e reduktuara të ruajtjes: Është e shtrenjtë dhe joefikase të instaloni një disk të madh në çdo kompjuter në rast se keni nevojë të ruani shumë të dhëna, por është mjaft e mundur të instaloni një nënsistem të madh disku të shkallëzuar në server.
4. duke siguruar akses në të njëjtat të dhëna nga çdo kompjuter.

Përshkrimi i NFS

Shërbimi NFS lejon një server të sigurojë akses të përbashkët në drejtoritë e specifikuara në lokalin e tij sistemi i skedarëve dhe klienti duhet t'i montojë këto direktori ashtu sikur të ishin drejtoritë lokale të klientit.

Versionet e NFS

NFS, i zhvilluar nga Sun Microsystems, ka qenë aq i suksesshëm saqë zbatimet janë zbatuar nga kompani të ndryshme në pothuajse të gjitha sistemet operative. Ekzistojnë disa zbatime thelbësisht të ndryshme NFS. NFS 2.0 është mjaft i zakonshëm, megjithëse NFS 3.0 u prezantua në Solaris 2.5. Publikimet e mëvonshme të Solaris, duke përfshirë Solaris 9, bënë përmirësime të rëndësishme në NFS, por vetë protokolli mbeti i pajtueshëm me implementimet e NFS 3.0 në sisteme të tjera. Duke filluar me NFS 3.0, transmetimi i paketave TCP dhe UDP mbështetet, më parë mbështetej vetëm UDP.

bej kujdes! Përdorni të njëjtin version të klientëve dhe serverëve NFS në rrjet. NFS 2.0 mund të gjendet në sistemet më të vjetra si HP-UX 10.0. Bashkëpunimi ndërmjet sistemeve që përdorin versione të ndryshme të NFS nuk është i dëshirueshëm.

Përputhshmëria e NFS dhe shërbimeve të tjera të drejtorisë së përbashkët

NFS është i ngjashëm në kuptimin dhe organizimin e punës me drejtoritë e përbashkëta(dosje të përbashkëta) në sistemet Windows, por këto shërbime përdorin protokolle krejtësisht të ndryshme operative dhe nuk janë të pajtueshme me njëra-tjetrën. Megjithatë, ka disa produkte softuerësh që instalojnë mbështetje NFS në sistemet Windows, kështu që përdorimi i NFS në një rrjet me sisteme të ndryshme operative nuk është problem, thjesht mos harroni të përdorni të njëjtin version të NFS.

NFS është një model klient-server, ku programe të ndryshme ekzekutohen në kompjuterët e klientit dhe serverit për të siguruar akses në drejtoritë e përbashkëta në server.

Meqenëse kompjuterët në vendet e punës të punonjësve në Rusi zakonisht kontrollohen nga sistemet Windows, sistemet Windows shpesh përdoren gjithashtu si serverë skedarësh. Sidoqoftë, shpesh ekziston dëshira për të instaluar UNIX në një server skedari për të përmirësuar besueshmërinë, për të zvogëluar kostot e harduerit ose për të përdorur të njëjtin server për një sërë nevojash të tjera të korporatës: si një server në internet, server të bazës së të dhënave, etj. Për të mos instaluar softuer shtesë për mbështetje NFS, në këtë rast mjafton të instaloni paketën samba në një makinë UNIX. Kjo do t'i lejojë asaj të "pretendohet" se është një server Windows në mënyrë që të gjithë kompjuterët e klientëve ta perceptojnë atë si serverin më të zakonshëm të skedarëve ose serverin e printimit në një rrjet Windows. Paketa samba ofron mbështetje për protokollin SMB të Windows-it.

Në rastet kur disa kompjuterë UNIX punojnë në rrjet dhe ata duhet të hyjnë në të njëjtin server skedar, ka kuptim të përdoret mekanizmi NFS (sistemit të skedarëve të rrjetit).

NFS nuk është shumë elastik ndaj ndërprerjeve të rrjetit, kërkon funksionim të pandërprerë dhe supozon lidhje të shpejta midis klientit dhe serverit. Përdorimi i NFS për montimin e sistemeve të skedarëve jashtë rrjetit lokal, për shembull, përmes Internetit, është teknikisht i realizueshëm, por jo shumë racional dhe i pasigurt.

Terminologjia NFS

Pas konfigurimit të serverit NFS, kompjuteri UNIX do t'u sigurojë përdoruesve të jashtëm akses në disa nga drejtoritë e tij. sistemi i skedarëve... Kjo dispozitë aksesi quhet "eksportim": sistemi thuhet se eksporton katalogët e tij. Se si saktësisht eksportohen drejtoritë përcaktohet nga një listë e vendosur nga administratori i sistemit. Në shumicën e sistemeve UNIX, kjo listë është në skedarin / etc / exports, por në Solaris është në një skedar tjetër, / etc / dfs / dfstab.

NFS funksionon përmes mekanizmit të thirrjes së procedurës në distancë ( RPC - Thirrje me procedurë në distancë).

Çfarë është RPC

Ideologjia RPC është shumë e thjeshtë dhe tërheqëse për programuesin. Si funksionon zakonisht një aplikacion rrjeti? Ai ndjek një protokoll të caktuar (për shembull, HTTP): gjeneron një paketë me një kërkesë, thërret funksionin e sistemit të vendosjes së një lidhjeje, më pas funksionin e dërgimit të paketës, më pas pret një paketë përgjigjeje dhe thërret funksionin për të mbyllur lidhje. Kjo do të thotë që e gjithë puna me rrjetin është shqetësimi i programuesit që shkruan aplikacionin: ai duhet të kujtojë thirrjen e funksioneve të rrjetit API të sistemit, të mendojë se çfarë të bëjë në rast të dështimeve të rrjetit.

RPC supozon një mënyrë të ndryshme të shkëmbimit të të dhënave midis një klienti dhe një serveri. Nga këndvështrimi i një programuesi, një aplikacion klienti RPC thërret një funksion në server, ai ekzekuton dhe kthen rezultatin. Përcjellja e një kërkese për të ekzekutuar një funksion përmes rrjetit dhe kthimi i rezultateve nga serveri te klienti është i padukshëm për aplikacionin, kështu që ky i fundit nuk duhet të shqetësohet për dështimet e rrjetit ose detajet e zbatimit të protokollit të transportit.

Për të siguruar transparencën e transferimit të të dhënave përmes rrjetit, është krijuar një procedurë me dy hapa. Në server, çdo aplikacion që ofron shërbimin e tij nëpërmjet RPC duhet të regjistrohet vetë me një program të quajtur "port mapper". Funksioni i këtij programi është të krijojë një korrespondencë midis numrit të procedurës RPC që klienti ka kërkuar dhe numrit të portit TCP ose UDP në të cilin aplikacioni i serverit pret kërkesat. Në përgjithësi, RPC mund të punojë me më shumë sesa thjesht TCP ose UDP. Solaris zbaton punën në bazë të mekanizmit TI (TransportIndependent), kështu që në Solaris përkthyesi i portit quhet rpcbind, por jo portmap si Linux ose FreeBSD.

Një aplikacion që regjistrohet me një përkthyes porti i tregon atij numrin e programit, numrin e versionit dhe numrat e procedurës që mund të përpunohen nga programi. Këto procedura më pas do të thirren nga klienti me numër. Përveç kësaj, aplikacioni raporton numrat e portave TCP dhe UDP që do të përdoren për të marrë kërkesa për të ekzekutuar procedurat.

Një klient që dëshiron të thirrë ekzekutimin e një procedure në server së pari i dërgon një kërkesë përkthyesit të portit në server për të gjetur se në cilin port TCP ose UDP të dërgojë kërkesën. Përkthyesi i portit fillon në fillimin e sistemit dhe funksionon gjithmonë në portën standarde 111. Pasi të ketë marrë një përgjigje prej tij, klienti dërgon një kërkesë në portin që korrespondon me aplikacionin e kërkuar. Për shembull, një server NFS po funksionon në portin 2049.

Si të montoni një drejtori të përbashkët përmes NFS

Para se të kalojmë në përshkrimin e cilësimeve për serverin NFS dhe klientët, është e nevojshme të kuptojmë se si montohen në parim sistemet e skedarëve në distancë.

Klienti NFS dërgon një kërkesë montimi në kompjuterin në distancë, i cili e siguron atë sistemi i skedarëve(zakonisht një pjesë e tij) për përdorim të përgjithshëm. Thuhet se serveri NFS "eksporton" këtë apo atë drejtori (që do të thotë - me nëndrejtori). Kërkesa e klientit

Kohë e mirë, lexues dhe të ftuar. Kishte një pushim shumë të gjatë midis postimeve, por unë jam kthyer në betejë). Në artikullin e sotëm do të shqyrtoj Operacioni i protokollit NFS, si dhe konfigurimi i një serveri NFS dhe klienti NFS në Linux.

Një hyrje në NFS

NFS (Sistemi i skedarëve të rrjetit - sistemi i skedarëve të rrjetit) për mendimin tim - një zgjidhje ideale në një rrjet lokal, ku është i nevojshëm shkëmbimi i të dhënave i shpejtë (më i shpejtë se SAMBA dhe me më pak burime në krahasim me sistemet e skedarëve në distancë me enkriptim - sshfs, SFTP, etj ...) dhe nuk është në siguria e parë e informacionit të transmetuar. Protokolli NFS lejon montoni sistemet e skedarëve në distancë përmes një rrjeti në një pemë të drejtorive lokale sikur të ishte një sistem skedari i montuar në disk. Kështu, aplikacionet lokale mund të punojnë me sistemin e skedarëve në distancë si me atë lokal. Por ju duhet të jeni të kujdesshëm (!) Me konfigurimi i NFS, sepse me një konfigurim të caktuar është e mundur të pezullohet sistemi operativ i klientit, duke pritur për I/O pafundësi. Protokolli NFS bazuar në punë Protokolli RPC, i cili ende nuk është në kuptimin tim)) kështu që materiali në artikull do të jetë pak i paqartë ... Përpara se të përdorni NFS, qoftë server apo klient, duhet të siguroheni që kerneli juaj të ketë mbështetje për sistemin e skedarëve NFS. Ju mund të kontrolloni nëse kerneli mbështet sistemin e skedarëve NFS duke kërkuar praninë e linjave përkatëse në skedar / proc / sistemet e skedarëve:

ARCHIV ~ # grep nfs / proc / file systems nodev nfs nodev nfs4 nodev nfsd

Nëse linjat e specifikuara në skedar / proc / sistemet e skedarëve dështon, atëherë duhet të instaloni paketat e përshkruara më poshtë. Kjo ka shumë të ngjarë të instalojë module të varur kernel për të mbështetur sistemet e skedarëve të dëshiruar. Nëse, pas instalimit të paketave, mbështetja NFS nuk shfaqet në skedarin e specifikuar, atëherë do të jetë e nevojshme me këtë funksion të aktivizuar.

Histori Sistemi i skedarëve të rrjetit

Protokolli NFS zhvilluar nga Sun Microsystems dhe ka 4 versione në historinë e saj. NFSv1 u zhvillua në 1989 dhe ishte eksperimental, duke funksionuar në protokollin UDP. Versioni 1 përshkruhet në. NFSv2 u lëshua në të njëjtin 1989, u përshkrua nga i njëjti RFC1094 dhe bazohej gjithashtu në protokollin UDP, duke ju lejuar të lexoni jo më shumë se 2 GB nga një skedar. NFSv3 rishikuar në 1995 dhe përshkruar në. Risitë kryesore të versionit të tretë ishin mbështetja për skedarë të mëdhenj, mbështetje shtesë për protokollin TCP dhe paketa të mëdha TCP, të cilat përshpejtuan ndjeshëm funksionimin e teknologjisë. NFSv4 finalizuar në 2000 dhe përshkruar në RFC 3010, rishikuar në 2003 dhe përshkruar në. Versioni i katërt përfshinte përmirësime të performancës, mbështetje për mjete të ndryshme vërtetimi (në veçanti, Kerberos dhe LIPKEY duke përdorur protokollin RPCSEC GSS) dhe listat e kontrollit të aksesit (si tipet POSIX ashtu edhe Windows). NFS v4.1 u miratua nga IESG në vitin 2010 dhe mori numrin. Një risi e rëndësishme e versionit 4.1 është specifikimi pNFS - Parallel NFS, një mekanizëm për aksesin paralel të një klienti NFS në të dhënat e shumë serverëve NFS të shpërndarë. Prania e një mekanizmi të tillë në standardin e sistemit të skedarëve të rrjetit do të ndihmojë në ndërtimin e ruajtjes së shpërndarë "cloud" dhe sistemeve të informacionit.

Serveri NFS

Meqenëse kemi NFS- atë rrjeti sistemi i skedarëve është i nevojshëm. (Mund ta lexoni edhe artikullin). Më tej është e nevojshme. Në Debian, kjo është paketa nfs-kernel-server dhe nfs-i përbashkët, në RedHat kjo është paketa nfs-utils... Dhe gjithashtu, është e nevojshme të aktivizoni nisjen e demonit në nivelet e kërkuara të funksionimit të OS (komandimi në RedHat është / sbin / chkconfig nfs aktivizuar, në Debian - /usr/sbin/update-rc.d parazgjedhjet e nfs-kernel-server).

Paketat e instaluara në Debian ekzekutohen në rendin e mëposhtëm:

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

Kjo është, ajo fillon së pari nfs-i përbashkët pastaj vetë serveri nfs-kernel-server... Në RedHat, situata është e ngjashme, me përjashtimin e vetëm që quhet skripti i parë nfslock dhe serveri thjesht thirret nfs... Rreth nfs-i përbashkët faqja e debian fjalë për fjalë na thotë sa vijon: skedarë të zakonshëm për klientin dhe serverin NFS, kjo paketë duhet të instalohet në një makinë që do të veprojë si klient ose server NFS. Paketa përfshin programet: lockd, statd, showmount, nfsstat, gssd dhe idmapd... Duke parë përmbajtjen e skriptit të fillimit /etc/init.d/nfs-common mund të gjurmoni sekuencën e mëposhtme të punës: skripti kontrollon praninë e një skedari binar të ekzekutueshëm /sbin/rpc.statd, kontrollon praninë në skedarë / etc / default / nfs-common, / etj / fstab dhe / etj / eksportet parametrat që kërkojnë demonët fillestarë idmapd dhe gssd , fillon demon /sbin/rpc.statd , pastaj para fillimit /usr/sbin/rpc.idmapd dhe /usr/sbin/rpc.gssd kontrollon praninë e këtyre binarëve të ekzekutueshëm, pastaj për daemon /usr/sbin/rpc.idmapd kontrollet për sunrpc, nfs dhe nfsd, si dhe mbështetje për sistemin e skedarëve rpc_pipefs në kernel (d.m.th., prania e tij në skedar / proc / sistemet e skedarëve), nëse gjithçka është e suksesshme, atëherë ajo funksionon /usr/sbin/rpc.idmapd ... Për më tepër, për demonin /usr/sbin/rpc.gssd çeqe moduli i kernelit rpcsec_gss_krb5 dhe fillon demonin.

Nëse shikoni përmbajtjen Skripti i nisjes së serverit NFS në Debian ( /etc/init.d/nfs-kernel-server), atëherë mund të ndiqni sekuencën e mëposhtme: në fillim, skripti kontrollon ekzistencën e skedarit / etj / eksportet, Disponueshmëria nfsd, disponueshmëria e mbështetjes Sistemi i skedarëve NFS në (domethënë në dosje / proc / sistemet e skedarëve), nëse gjithçka është në vend, atëherë daemon fillon /usr/sbin/rpc.nfsd , më pas kontrollon nëse parametri është vendosur NEED_SVCGSSD(vendosur në skedarin e cilësimeve të serverit / etc / default / nfs-kernel-server) dhe, nëse jepet, fillon demonin /usr/sbin/rpc.svcgssd , i fundit që nisi demonin /usr/sbin/rpc.mountd ... Nga ky skenar mund ta shihni këtë Operacioni i serverit NFS përbëhet nga daemons rpc.nfsd, rpc.mountd dhe nëse përdoret vërtetimi Kerberos, atëherë daemon rcp.svcgssd. Daemon rpc.rquotad dhe nfslogd ende funksionojnë në kapelën e kuqe (Për disa arsye, nuk gjeta informacion në lidhje me këtë demon në Debian dhe arsyet e mungesës së tij, me sa duket të fshira ...).

Nga kjo bëhet e qartë se serveri i sistemit të skedarëve të rrjetit përbëhet nga proceset e mëposhtme (lexo - demonët) të vendosura në drejtoritë / sbin dhe / usr / sbin:

Në NFSv4, kur përdorni Kerberos, demonët fillojnë gjithashtu:

• rpc.gssd- Daemon NFSv4 ofron metoda të vërtetimit përmes GSS-API (Kerberos Authentication). Punon në klient dhe server.
• rpc.svcgssd- Daemon i serverit NFSv4 që siguron vërtetimin e klientit nga ana e serverit.

portmap dhe protokolli RPC (Sun RPC)

Përveç paketave të mësipërme, kërkohet një paketë shtesë që NFSv2 dhe v3 të funksionojnë siç duhet portmap(në shpërndarjet më të reja, zëvendësuar me riemërtuar në rpcbind). Kjo paketë zakonisht instalohet automatikisht me NFS si një vartës dhe zbaton funksionimin e serverit RPC, domethënë është përgjegjës për caktimin dinamik të porteve për disa shërbime të regjistruara në serverin RPC. Fjalë për fjalë, sipas dokumentacionit, ky është një server që konverton numrat e programit të thirrjes së procedurës në distancë (RPC) në numrat e portit TCP / UDP. portmap operon në disa entitete: Thirrjet ose kërkesat e RPC, Portet TCP / UDP,versioni i protokollit(tcp ose udp), numrat e programit dhe versionet e softuerit. Daemon portmap niset nga skripti /etc/init.d/portmap përpara se të nisë shërbimet NFS.

Shkurtimisht, puna e një serveri RPC (Thirrje me procedurë në distancë) është të përpunojë thirrjet RPC (të njohura si procedurat RPC) nga proceset lokale dhe të largëta. Duke përdorur thirrjet RPC, shërbimet regjistrohen ose largohen në / nga hartuesi i portit (aka portmapper, aka portmap, aka portmapper, aka rpcbind, në versionet më të reja) dhe klientët që përdorin thirrjet RPC që drejtojnë kërkesat te hartuesi i portit marrin informacionin që u nevojitet. Emrat e shërbimeve të programeve miqësore për përdoruesit dhe numrat e tyre përkatës përcaktohen në / etc / rpc. Sapo një shërbim ka dërguar një kërkesë përkatëse dhe është regjistruar me serverin RPC në hartuesin e porteve, serveri RPC i cakton portet TCP dhe UDP shërbimit në të cilin filloi shërbimi dhe ruan në kernel informacionin përkatës në lidhje me shërbimi i ekzekutimit (emri), një shërbim me numër unik (në përputhje me / etc / rpc), në lidhje me protokollin dhe portin në të cilin po funksionon shërbimi dhe në lidhje me versionin e shërbimit, dhe ofron informacionin e specifikuar për klientët sipas kërkesës. Vetë konverteri i portit ka një numër programi (100000), numrin e versionit - 2, portin TCP 111 dhe portin UDP 111. Më lart, kur specifikoja përbërjen e demonëve të serverit NFS, tregova numrat kryesorë të programit RPC. Ndoshta ju ngatërrova pak me këtë paragraf, kështu që do të them frazën kryesore, e cila duhet të sqarojë: funksioni kryesor i hartuesit të portit është t'i kthejë atij (klientit) portin në të cilin po ekzekutohet programi i kërkuar. Prandaj, nëse një klient duhet të hyjë në RPC me një numër të caktuar programi, ai fillimisht duhet të kontaktojë procesin e portmap-it në makinën e serverit dhe të përcaktojë numrin e portit për të komunikuar me shërbimin RPC që i nevojitet.

Funksionimi i një serveri RPC mund të përfaqësohet nga hapat e mëposhtëm:

1. Konvertuesi i portit duhet të niset së pari, zakonisht në nisjen e sistemit. Kjo krijon një pikë fundore TCP dhe hap portin TCP 111. Krijon gjithashtu një pikë fundore UDP që pret që një datagram UDP të arrijë në portën UDP 111.
2. Në nisje, një program që kalon përmes një serveri RPC krijon një pikë fundore TCP dhe një pikë fundore UDP për çdo version të mbështetur të programit. (Një server RPC mund të mbështesë disa versione. Klienti specifikon versionin e kërkuar kur kryen një telefonatë RPC.) Një numër porti i caktuar në mënyrë dinamike i caktohet çdo versioni të shërbimit. Serveri regjistron çdo program, version, protokoll dhe numër porti duke bërë thirrjen e duhur RPC.
3. Kur programi i klientit RPC ka nevojë për informacionin që i nevojitet, ai thërret një rutinë të hartës së portit për të marrë një numër porti të caktuar në mënyrë dinamike për një program, version dhe protokoll të caktuar.
4. Në përgjigje të kësaj kërkese, veriu kthen numrin e portit.
5. Klienti dërgon një mesazh kërkese RPC në numrin e portit të marrë në hapin 4. Nëse përdoret UDP, klienti thjesht dërgon një datagram UDP që përmban mesazhin e thirrjes RPC tek numri i portit UDP në të cilin po ekzekutohet shërbimi i kërkuar. Si përgjigje, shërbimi dërgon një datagram UDP që përmban një mesazh përgjigjeje RPC. Nëse TCP është në përdorim, klienti bën një hapje aktive në numrin e portit TCP të shërbimit të kërkuar dhe më pas dërgon një mesazh thirrjeje RPC mbi lidhjen e krijuar. Serveri përgjigjet me një mesazh përgjigjeje RPC mbi lidhjen.

Për të marrë informacion nga serveri RPC, përdorni programin rpcinfo... Gjatë përcaktimit të parametrave -p host programi liston të gjitha programet RPC të regjistruara në host. Pa specifikuar hostin, programi do të shfaqë shërbimet në localhost. Shembull:

Archiv ~ # rpcinfo -p prog-ma port version proto 100000 2 tcp 111 portmapper 100000 2 UDP 111 portmapper 100024 1 UDP 59.451 Statusi 100024 1 tcp 60.872 Statusi 100021 1 UDP 44310 nlockmgr 100021 3 UDP 44310 nlockmgr 100021 4 UDP 44310 nlock 44851 nlockmgr 100021 3 tcp 44851 nlockmgr 100021 4 tcp 44851 nlockmgr 100.003 2 tcp 2049 nfs 100003 3 TCP 2049 nfs 100.003 4 tcp 2049 nfs 100003 2 UDP 2049 NFS 100003 3 UDP 2049 NFS 100003 4 ud5 TCP 2049 NFS 1000030 1 mali 41.405 mountd 100005 2 PZHU 51306 montuar 100005 2 tcp 41405 montuar 100005 3 udp 51306 montuar 100005 3 tcp 41405 montuar

Siç mund ta shihni, rpcinfo shfaq (në kolonat nga e majta në të djathtë) numrin e programit të regjistruar, versionin, protokollin, portin dhe emrin. Ju mund të përdorni rpcinfo për të hequr regjistrimin e një programi ose për të marrë informacion në lidhje me një shërbim individual RPC (shih man rpcinfo për më shumë opsione). Siç mund ta shihni, demonët e versionit 2 të portmapper janë regjistruar në portat udp dhe tcp, versioni rpc.statd 1 në portet udp dhe tcp, versionet e menaxherit të kyçjes NFS 1,3,4, serveri nfs daemon 2,3,4, si dhe Mount Daemon versionet 1,2,3.

Serveri NFS (më saktë, daemon rpc.nfsd) merr kërkesa nga klienti në formën e të dhënave UDP në portin 2049. Edhe pse NFS punon me një hartues porti, i cili i lejon serverit të përdor portet e caktuara në mënyrë dinamike, porta UDP 2049 është i koduar në NFS në shumicën e implementimeve ...

Operacioni i protokollit të sistemit të skedarëve të rrjetit

Montoni NFS në distancë

Procesi i montimit të një sistemi skedarësh të largët NFS mund të përfaqësohet nga diagrami i mëposhtëm:

Përshkrimi i protokollit NFS kur montoni një drejtori të largët:

1. Një server RPC niset në server dhe klient (zakonisht në boot), shërbehet nga procesi portmapper dhe regjistrohet në portat tcp / 111 dhe udp / 111.
2. Fillojnë shërbimet (rpc.nfsd, rpc.statd, etj.), të cilat regjistrohen në serverin RPC dhe regjistrohen në portet arbitrare të rrjetit (përveç nëse një port statik specifikohet në cilësimet e shërbimit).
3. komanda mount në kompjuterin e klientit i dërgon një kërkesë kernelit për të montuar një direktori rrjeti me një tregues të llojit të sistemit të skedarëve, hostit dhe vetë direktorisë, kerneli dërgon një kërkesë RPC në procesin portmap në serverin NFS në udp / Porta 111 (nëse klienti nuk ka mundësi të punojë përmes tcp)
4. Kerneli i serverit NFS anketon RPC-në për praninë e demonit rpc.mountd dhe kthen portin e rrjetit në të cilin demon po ekzekutohet te kerneli i klientit.
5. mount dërgon një kërkesë RPC në portin në të cilin po ekzekutohet rpc.mountd. Tani serveri NFS mund të vërtetojë klientin bazuar në adresën e tij IP dhe numrin e portit për të parë nëse klienti mund të montojë sistemin e skedarëve të specifikuar.
6. Mount daemon kthen një përshkrim të sistemit të skedarëve të kërkuar.
7. Komanda e montimit të klientit lëshon thirrjen e sistemit të montimit për të lidhur përshkruesin e skedarit të marrë në hapin 5 me pikën lokale të montimit në hostin e klientit. Përshkruesi i skedarit ruhet në kodin e klientit NFS dhe nga kjo pikë e tutje, çdo akses nga proceset e përdoruesit në skedarët në sistemin e skedarëve të serverit do të përdorë përshkruesin e skedarit si pikënisje.

Komunikimi midis klientit dhe serverit NFS

Qasja tipike në një sistem skedari në distancë mund të përshkruhet si më poshtë:

Përshkrimi i procesit të hyrjes në një skedar të vendosur në serverin NFS:

1. Klientit (procesi i përdoruesit) nuk i intereson nëse ka akses në një skedar lokal ose një skedar NFS. Kerneli merret me ndërveprimin me harduerin përmes moduleve të kernelit ose thirrjeve të integruara të sistemit.
2. Moduli i kernelit kernel / fs / nfs / nfs.ko, i cili vepron si një klient NFS dhe dërgon kërkesa RPC në serverin NFS përmes modulit TCP / IP. NFS zakonisht përdor UDP, megjithatë implementimet më të reja mund të përdorin TCP.
3. Serveri NFS merr kërkesa nga klienti si datagrame UDP në portën 2049. Megjithëse NFS mund të punojë me një hartues portash, i cili i lejon serverit të përdorë porte të caktuara në mënyrë dinamike, porta UDP 2049 është e koduar në NFS në shumicën e implementimeve.
4. Kur serveri NFS merr një kërkesë nga një klient, ajo i kalohet rutinës lokale të aksesit të skedarit, e cila siguron akses në diskun lokal në server.
5. Rezultati i aksesit të diskut i kthehet klientit.

Vendosja e një serveri NFS

Akordimi i serverit përgjithësisht konsiston në specifikimin e drejtorive lokale që lejohen të montohen nga sistemet në distancë në një skedar / etj / eksportet... Ky veprim quhet hierarkia e drejtorisë së eksportit... Burimet kryesore të informacionit rreth drejtorive të eksportuara janë skedarët e mëposhtëm:

• / etj / eksportet- skedari kryesor i konfigurimit që ruan konfigurimin e drejtorive të eksportuara. Përdoret kur nisni NFS dhe programin e eksportit.
• / var / lib / nfs / xtab- përmban një listë të drejtorive të montuara nga klientët në distancë. Përdoret nga daemon rpc.mountd kur një klient përpiqet të montojë një hierarki (krijohet një rekord montimi).
• / var / lib / nfs / etab- një listë drejtorish që mund të montohen nga sistemet në distancë, duke treguar të gjithë parametrat e drejtorive të eksportuara.
• / var / lib / nfs / rmtab- një listë të drejtorive që nuk eksportohen për momentin.
• / proc / fs / nfsd- një sistem skedari të veçantë (kerneli 2.6) për menaxhimin e serverit NFS.
  • eksportet- një listë të hierarkive aktive të eksportuara dhe klientëve tek të cilët janë eksportuar, si dhe parametra. Kerneli e merr këtë informacion nga / var / lib / nfs / xtab.
  • fijet- përmban numrin e fijeve (mund të ndryshohet gjithashtu)
  • duke përdorur filehandle mund të merrni një tregues skedari
  • dhe etj...
• / proc / neto / rpc- përmban statistika të papërpunuara që mund të merren duke përdorur nfsstat, si dhe cache të ndryshme.
• / var / run / portmap_mapping- informacione për shërbimet e regjistruara në RPC

Shënim: ne pergjithesi ne internet ka shume interpretime dhe formulime te qellimit te skedareve xtab, etab, rmtab, nuk di kujt t'i besoj.Edhe ne http://nfs.sourceforge.net/, interpretimi nuk është e paqartë.

Konfigurimi i skedarit / etc / exports

Në rastin më të thjeshtë, skedari / etc / exports është i vetmi skedar që ka nevojë për redaktim për të konfiguruar serverin NFS. Ky skedar kontrollon aspektet e mëposhtme:

• Çfarë klientësh mund të hyjë në skedarë në server
• Cilat hierarki drejtoritë në server mund të aksesohen nga çdo klient
• Si do të jenë emrat e klientëve me porosi të shfaqet te emrat e përdoruesve lokalë

Çdo rresht në skedarin e eksporteve ka formatin e mëposhtëm:

export_point klient1 (opsione) [klient2 (opsione) ...]

ku eksport_pika rruga absolute e hierarkisë së direktorisë së eksportuar, klient1 - n emri i një ose më shumë klientëve ose adresave IP, të ndara me hapësira, që lejohen të montohen eksport_pika . Opsione përshkruani rregullat e montimit për klient specifikuar më parë opsione .

Këtu është një tipike shembull eksporton konfigurimin e skedarit:

ARCHIV ~ # cat / etj / eksporton / skedarë arkiv1 (rw, sinkronizo) 10.0.0.1 (ro, sinkronizim) 10.0.230.1/24 (ro, sinkronizoj)

Në këtë shembull, skedarët e kompjuterëve dhe 10.0.0.1 lejohen qasja në pikën e eksportit / arkiv1, ndërsa skedarët pritës lexohen/shkruhen, dhe për hostin 10.0.0.1 dhe nënrrjetin 10.0.230.1/24, aksesi vetëm për lexim.

Përshkrimet e hostit në / etj / eksportet lejohen në formatin e mëposhtëm:

• Emrat e nyjeve individuale përshkruhen si skedarë ose skedarë.DOMAIN.local.
• Maskat e domenit përshkruhen në formatin e mëposhtëm: * DOMAIN.local përfshin të gjitha nyjet në domenin DOMAIN.local.
• Nënrrjetet përcaktohen si çifte adresash IP/maske. Për shembull: 10.0.0.0/255.255.255.0 përfshin të gjitha nyjet, adresat e të cilave fillojnë me 10.0.0.
• Vendosja e emrit të grupit të rrjetit @myclients që ka akses në burim (kur përdorni një server NIS)

Opsionet e përgjithshme të eksportit për hierarkitë e drejtorive

Skedari i eksporteve përdor opsionet e përgjithshme të mëposhtme(opsionet e përdorura si parazgjedhje në shumicën e sistemeve tregohen së pari, në kllapa - jo si parazgjedhje):

• auth_nlm (jo_auth_nlm) ose sigurt_kyçet (kyçet_të pasigurta)- specifikon që serveri duhet të kërkojë vërtetimin e kërkesave të kyçjes (duke përdorur protokollin NFS Lock Manager).
• nohide (fsheh)- nëse serveri eksporton dy hierarki direktorie, me njërën të vendosur (të montuar) në tjetrën. Klienti duhet të montojë qartë hierarkinë e dytë (fëmijë), përndryshe pika e montimit të hierarkisë së fëmijës do të shfaqet si një drejtori bosh. Opsioni nohide rezulton në një hierarki të drejtorisë së dytë pa një montim të qartë. ( shënim: Nuk mund ta gjeja këtë opsion për të punuar ...)
• ro (rw)- Lejon vetëm kërkesat për lexim (shkrim). (Përfundimisht, nëse është e mundur të lexohet/shkruash apo jo, përcaktohet në bazë të lejeve të sistemit të skedarëve, ndërsa serveri nuk është në gjendje të dallojë një kërkesë për leximin e skedarit nga një kërkesë ekzekutimi, kështu që lejon leximin nëse përdoruesi ka leje leximi ose ekzekutimi .)
• i sigurt (i pasigurt)- kërkon që kërkesat NFS të vijnë nga porte të sigurta (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• nënpemë_kontrolli (jo_nëntree_kontroll)- Nëse një nëndrejtori e sistemit të skedarëve eksportohet, por jo i gjithë sistemi i skedarëve, serveri kontrollon nëse skedari i kërkuar është në nëndrejtorinë e eksportuar. Çaktivizimi i verifikimit ul sigurinë, por rrit shpejtësinë e transferimit të të dhënave.
• sinkronizoj (asinkronizoj)- tregon se serveri duhet t'u përgjigjet kërkesave vetëm pasi ndryshimet e bëra nga ato kërkesa të shkruhen në disk. Opsioni async i thotë serverit të mos presë që informacioni të shkruhet në disk, gjë që përmirëson performancën, por ul besueshmërinë, sepse humbja e informacionit është e mundur në rast të shkëputjes së lidhjes ose dështimit të pajisjes.
• wdelay (no_wdelay)- I thotë serverit të vonojë ekzekutimin e kërkesave për shkrim nëse një kërkesë e mëvonshme për shkrim është në pritje, duke shkruar të dhëna në blloqe më të mëdha. Kjo përmirëson performancën kur dërgoni radhë të mëdha shkrimi. no_wdelay tregon që të mos shtyhet ekzekutimi i komandës për shkrim, gjë që mund të jetë e dobishme nëse serveri merr një numër të madh komandash që nuk kanë lidhje me njëra-tjetrën.

Eksportimi i lidhjeve simbolike dhe skedarëve të pajisjes. Kur eksportoni një hierarki drejtorish që përmbajnë lidhje simbolike, objekti i lidhjes duhet të jetë i aksesueshëm për sistemin e klientit (në distancë), domethënë, duhet të përmbushet një nga rregullat e mëposhtme:

Skedari i pajisjes i referohet ndërfaqes. Kur eksportoni një skedar pajisjeje, kjo ndërfaqe eksportohet. Nëse sistemi i klientit nuk ka një pajisje të të njëjtit lloj, atëherë pajisja e eksportuar nuk do të funksionojë. Në sistemin e klientit, kur montoni objekte NFS, mund të përdorni opsionin nodev në mënyrë që skedarët e pajisjes në drejtoritë e montuara të mos përdoren.

Opsionet e paracaktuara mund të ndryshojnë nga sistemi në sistem, ato mund të shihen në skedarin / var / lib / nfs / etab. Pas përshkrimit të drejtorisë së eksportuar në / etc / exports dhe rinisjes së serverit NFS, të gjitha opsionet që mungojnë (lexo: opsionet e paracaktuara) do të pasqyrohen në skedarin / var / lib / nfs / etab.

Opsionet e shfaqjes (përputhjes) të ID-së së përdoruesit

Për të kuptuar më mirë sa vijon, do t'ju këshilloja të lexoni artikullin. Çdo përdorues Linux ka UID-in e vet dhe GID-në kryesore, të cilat përshkruhen në skedarë / etc / passwd dhe / etj / grup... Serveri NFS supozon se sistemi operativ i hostit në distancë ka vërtetuar përdoruesit dhe u ka caktuar atyre UID-të dhe GID-të e sakta. Eksportimi i skedarëve u jep përdoruesve në sistemin e klientit të njëjtën qasje në këta skedarë sikur të ishin duke u identifikuar direkt në server. Prandaj, kur një klient NFS dërgon një kërkesë në një server, serveri përdor UID dhe GID për të identifikuar përdoruesin në sistemin lokal, gjë që mund të çojë në disa probleme:

• përdoruesi mund të mos ketë të njëjtët identifikues në të dy sistemet dhe, në përputhje me rrethanat, mund të hyjë në skedarët e një përdoruesi tjetër.
• që nga viti Nëse përdoruesi rrënjë ka një identifikues gjithmonë 0, atëherë ky përdorues është i lidhur me një përdorues lokal në varësi të opsioneve të specifikuara.

Opsionet e mëposhtme përcaktojnë rregullat për hartimin e përdoruesve të largët me ata lokalë:

• rrënjë_kungull (jo_rrënjë_kungull)- Me opsionin e dhënë rrënjë_kungull, kërkesat nga përdoruesi rrënjë vendosen në uid / gid anonim, ose te përdoruesi i specifikuar në parametrin anonuid / anongid.
• jo_all_kungull (të gjitha_kunguj)- Nuk ndryshon UID / GID të përdoruesit që lidh. Opsioni all_kungull vendos që të gjithë përdoruesit (jo vetëm root) të shfaqen si anonimë ose të specifikuar në parametrin anonuid / anongid.
• anonuid = UID dhe anongid = GID - Vendos në mënyrë të qartë UID / GID për përdoruesin anonim.
• harta_statike = / etc / file_maps_users - Përcakton një skedar në të cilin mund të vendosni hartëzimin e UID / GID të largët - UID / GID lokal.

Një shembull i përdorimit të një skedari të hartës së përdoruesit:

ARCHIV ~ # cat / etc / file_maps_users # Përdoruesit e hartës # uid komenti lokal në distancë 0-50 1002 # hartimi i përdoruesve në UID në distancë 0-50 në UID lokal 1002 gid 0-50 1002 # hartimi i përdoruesve në / shtrihet GID në distancë 0-50 k GID lokal 1002

Menaxhimi i serverit NFS

Serveri NFS menaxhohet duke përdorur shërbimet e mëposhtme:

• nfsstat
• showmsecure (i pasigurt) unazë

nfsstat: Statistikat e NFS dhe RPC

Shërbimi nfsstat ju lejon të shikoni statistikat e serverëve RPC dhe NFS. Opsionet e komandës mund të shihen në man nfsstat.

showmount: shfaq informacionin e statusit NFS

Shërbimi Showmount pyet daemonin rpc.mountd në hostin në distancë për sistemet e skedarëve të montuar. Si parazgjedhje, kthehet një listë e renditur e klientëve. Çelësat:

• -- të gjitha- shfaqet një listë e klientëve dhe pikave të montimit, duke treguar se ku e ka montuar klienti direktorinë. Ky informacion mund të mos jetë i besueshëm.
• -- drejtoritë- jepet një listë e pikave të montimit
• --eksportet- jep një listë të sistemeve të skedarëve të eksportuar nga pikëpamja e nfsd

Nëse ekzekutoni showmount pa argumente, tastiera do të shfaqë informacione rreth sistemeve që lejohen të montohen lokal drejtorive. Për shembull, hosti ARCHIV na ofron një listë të drejtorive të eksportuara me adresat IP të hosteve që lejohen të montojnë drejtoritë e specifikuara:

FILES ~ # showmount --exports archiv Eksporto listën për arkivin: / archiv-big 10.0.0.2 / archiv-small 10.0.0.2

Nëse specifikoni emrin e hostit / IP në argument, informacioni për këtë host do të shfaqet:

ARCHIV ~ # skedarë showmount clnt_create: RPC: Programi nuk është regjistruar # ky mesazh na tregon se daemon NFSd nuk po funksionon në hostin FILES

exportfs: menaxhoni drejtoritë e eksportuara

Kjo komandë u shërben drejtorive të eksportuara të specifikuara në skedar / etj / eksportet, do të jetë më e saktë të shkruani nuk shërben, por sinkronizohet me skedarin / var / lib / nfs / xtab dhe heq ato që nuk ekzistojnë nga xtab. exportfs ekzekutohet kur daemon nfsd niset me argumentin -r. Programi exportfs në modalitetin e kernelit 2.6 komunikon me daemonin rpc.mountd përmes skedarëve në drejtorinë / var / lib / nfs / dhe nuk komunikon drejtpërdrejt me kernelin. Pa parametra, liston sistemet e skedarëve të eksportuar aktualisht.

Opsionet e eksportit:

• [klienti: emri i drejtorisë] - shtoni ose hiqni sistemin e skedarëve të specifikuar për klientin e specifikuar)
• -v - shfaq më shumë informacion
• -r - rieksporto të gjitha drejtoritë (sinkronizimi / etj / eksportet dhe / var / lib / nfs / xtab)
• -u - hiqni nga lista e të eksportuarve
• -a - shtoni ose hiqni të gjitha sistemet e skedarëve
• -o - opsione të ndara me presje (të ngjashme me opsionet e përdorura në / etc / eksporte; kështu që mund të ndryshoni opsionet për sistemet e skedarëve të montuar tashmë)
• -i - mos përdorni / etc / eksportoni kur shtoni, vetëm parametrat e linjës aktuale të komandës
• -f - rivendos listën e sistemeve të eksportuara në kernel 2.6;

Klient NFS

Përpara se të aksesoni një skedar në sistemin e skedarëve në distancë, klienti (OS klienti) duhet montoni atë dhe merrni nga serveri tregues për të. Montimi i NFS mund të bëhet me ose me ndihmën e një prej montuesve automatikë pjellorë (amd, autofs, automount, supermount, superpupermount). Procesi i montimit tregohet mirë në ilustrimin e mësipërm.

Në Klientët NFS asnjë demon nuk duhet të fillojë, funksionet e klientit ekzekuton modulin e kernelit kernel / fs / nfs / nfs.ko i cili përdoret gjatë montimit të një sistemi skedarësh në distancë. Drejtoritë e eksportuara nga serveri mund të montohen në klient në mënyrat e mëposhtme:

• manualisht duke përdorur komandën mount
• automatikisht në nisje, kur montoni sistemet e skedarëve të përshkruar në / etc / fstab
• automatikisht duke përdorur demonin autofs

Unë nuk do ta konsideroj metodën e tretë me autofs në këtë artikull, për shkak të informacionit të saj voluminoz. Ndoshta në artikujt vijues do të ketë një përshkrim të veçantë.

Montoni sistemin e skedarëve të rrjetit me komandën mount

Një shembull i përdorimit të komandës mount është paraqitur në postim. Këtu është një shembull i një komande montimi për të montuar një sistem skedari NFS:

FILES ~ # mount -t nfs archiv: / archiv-small / archivs / archiv-small FILES ~ # mount -t nfs -o ro archiv: / archiv-big / archivs / arkiv-big FILES ~ # montoj ..... ... .

Komanda e parë monton direktorinë e eksportuar / arkiv-i vogël në server arkivi në pikën lokale të montimit / arkiva / arkiv-small me opsionet e paracaktuara (d.m.th. lexoni dhe shkruani). edhe pse komandën e montimit në shpërndarjet e fundit, ai di të kuptojë se çfarë lloj sistemi skedari përdoret pa specifikuar llojin, megjithatë specifikoni parametrin -t nfs e dëshirueshme. Komanda e dytë monton direktorinë e eksportuar / arkiv-i madh në server arkivi në drejtorinë lokale / arkiva / arkiv-i madh me opsion vetëm për lexim ( ro). Komanda e montimit pa parametra, ai na tregon qartë rezultatin e montimit. Përveç opsionit vetëm për lexim (ro), është e mundur të specifikoni të tjera opsionet bazë kur montoni NFS:

• nosuid- Ky opsion ndalon ekzekutimin e programeve nga direktoria e montuar.
• nodev(pa pajisje - jo pajisje) - Ky opsion ndalon përdorimin e karaktereve dhe bllokon skedarët e veçantë si pajisje.
• bllokoj (nolock)- Lejon mbylljen e NFS (parazgjedhja). nolock çaktivizon kyçjen NFS (nuk e nis demonin e kyçur) dhe është i dobishëm për serverët e vjetër që nuk mbështesin kyçjen NFS.
• mounthost = emër- Emri i hostit në të cilin po funksionon demoni i montimit NFS - montuar.
• montport = n - Porti i përdorur nga demon i montuar.
• port = n- porta e përdorur për t'u lidhur me serverin NFS (si parazgjedhje 2049 nëse daemon rpc.nfsd nuk është i regjistruar në serverin RPC). Nëse n = 0 (parazgjedhja), atëherë NFS do të kërkojë hartën e portit në server për të përcaktuar portin.
• rsize = n(madhësia e bllokut të leximit) - Numri i bajteve të lexuara në të njëjtën kohë nga serveri NFS. Standard - 4096.
• wsize = n(madhësia e bllokut të shkruar) - Numri i bajteve të shkruara në të njëjtën kohë në serverin NFS. Standard - 4096.
• tcp ose udp- Për të montuar NFS, përdorni përkatësisht protokollin TCP ose UDP.
• bg- Nëse humbni aksesin në server, provoni përsëri në sfond në mënyrë që të mos bllokoni procesin e nisjes së sistemit.
• fg- Nëse humbni aksesin në server, provoni sërish në modalitetin prioritar. Ky opsion mund të bllokojë procesin e nisjes duke përsëritur përpjekjet e montimit. Për këtë arsye, parametri fg përdoret kryesisht për qëllime korrigjimi.

Opsionet që ndikojnë në ruajtjen e atributeve kur montohet NFS

Atributet e skedarit të ruajtura në (inoda), të tilla si koha e modifikimit, madhësia, lidhjet e forta, pronari, zakonisht ndryshojnë rrallë për skedarët e rregullt dhe aq më rrallë për drejtoritë. Shumë programe, të tilla si ls, aksesojnë skedarët vetëm për lexim dhe nuk ndryshojnë atributet ose përmbajtjen e skedarëve, por harxhojnë burimet e sistemit në operacione të shtrenjta të rrjetit. Për të shmangur humbjen e panevojshme të burimeve, mundeni atributet e dhëna cache... Kerneli përdor kohën e modifikimit të një skedari për të përcaktuar nëse cache është e vjetëruar duke krahasuar kohën e modifikimit në cache me kohën e modifikimit të vetë skedarit. Cache e atributeve azhurnohet periodikisht sipas parametrave të specifikuar:

• ac (noac) (atrebute cache- caching atributi) - Aktivizon ruajtjen e atributeve (parazgjedhur). Megjithëse opsioni noac ngadalëson serverin, ai shmang skadimin e atributeve kur shumë klientë po shkruajnë në mënyrë aktive informacion në hierarkinë e përbashkët.
• acdirmax = n (atributet maksimale të skedarit të dosjes së cache-it- maksimumi i memorizimit të atributeve për një skedar drejtorie) - Numri maksimal i sekondave që pret NFS përpara se të përditësojë atributet e drejtorisë (parazgjedhja 60 sekonda)
• acdirmin = n (Minimumi i atributeve të skedarit të drejtorisë së cache-it- ruajtja në memorie e atributeve të paktën për një skedar drejtorie) - Numri minimal i sekondave që pret NFS përpara se të përditësojë atributet e drejtorisë (si parazgjedhje 30 sekonda)
• acregmax = n (maksimumi i atributit të skedarit të rregullt të cache-it- maksimumi i ruajtjes së atributeve për një skedar të rregullt) - Numri maksimal i sekondave që pret NFS përpara se të përditësojë atributet e një skedari të rregullt (parazgjedhja 60 sek.)
• acregmin = n (Minimumi i atributeve të skedarit të rregullt të cache-it- memoria e atributeve të paktën për një skedar të rregullt) - Numri minimal i sekondave që pret NFS përpara se të përditësojë atributet e një skedari të rregullt (3 sekonda si parazgjedhje)
• aktimeo = n (atribut cache timeout- Atributi i caching timeout) - Anulon vlerat për të gjitha opsionet e mësipërme. Nëse actimeo nuk është specifikuar, atëherë vlerat e mësipërme vendosen në vlerat e tyre të paracaktuara.

Opsionet e trajtimit të gabimeve NFS

Opsionet e mëposhtme kontrollojnë se si sillet NFS kur nuk ka përgjigje nga serveri ose kur ndodhin gabime I/O:

• fg (bg) (plan të parë- plani i parë, sfond- sfond) - Provoni të montoni një NFS të dështuar në plan të parë / sfond.
• fortë butë)- shfaq mesazhin "serveri nuk përgjigjet" në tastierë kur të arrihet skadimi dhe vazhdon përpjekjet e montimit. Me opsionin e dhënë i butë- nëse ndodh skadimi, informon programin që thirri operacionin për një gabim I/O. (opsioni i butë këshillohet të mos përdoret)
• nointr (intr) (asnjë ndërprerje- mos ndërprisni) - Parandalon sinjalet nga ndërprerja e operacioneve të skedarëve në hierarkinë e direktoriumit të montuar në mënyrë të vështirë kur arrihet një kohë e gjatë. intr- mundëson ndërprerjen.
• retrans = n (vlera e ritransmetimit- vlera e ritransmetimit) - Pas n ndërprerjesh të vogla kohore, NFS gjeneron një afat kohor të madh (3 sipas parazgjedhjes). Një kohë e gjatë ndalon operacionet ose shfaq një mesazh "serveri nuk përgjigjet" në tastierë, në varësi të opsionit të vështirë / të butë të specifikuar.
• riprovoj = n (riprovoni vlerën- vlera e riprovës) - Numri i minutave që shërbimi NFS riprovon operacionet e montimit përpara se të heqë dorë (10,000 sipas parazgjedhjes).
• timeo = n (vlera e afatit- vlera e skadimit) - Numri i të dhjetave të sekondës që pret shërbimi NFS përpara ritransmetimit në rast të RPC ose afatit të ulët (parazgjedhja 7). Kjo vlerë rritet me çdo ndërprerje, deri në një maksimum prej 60 sekondash, ose derisa të ndodhë një kohë e gjatë. Në një rrjet të zënë, në një server të ngadaltë ose kur një kërkesë po kalon nëpër rutera ose porta të shumta, rritja e kësaj vlere mund të përmirësojë performancën.

Montimi automatik i NFS në nisje (përshkrimi i sistemeve të skedarëve në / etc / fstab)

Për të gjetur kohën optimale për një vlerë specifike të paketës së transmetuar (vlerat rsize / wsize), përdorni komandën ping:

FILES ~ # ping -s 32768 arkiv PING archiv.DOMAIN.local (10.0.0.6) 32768 (32796) bajt të dhënash. 32776 byte nga archiv.domain.local (10.0.0.6): icmp_req = 1 ttl = 64 kohë = 0.931 ms 32776 bajte nga archiv.domain.local (10.0.0.6): icmp_req = 2 ttl kohë 7 = 06. nga archiv.domain.local (10.0.0.6): icmp_req = 3 ttl = 64 kohë = 1.03 ms 32776 bajt nga archiv.domain.local (10.0.0.6): icmp_req = 4 ttl = 64 kohë = 1,07 ms 32776 byte .domain.local (10.0.0.6): icmp_req = 5 ttl = 64 kohë = 1,08 ms ^ C --- archiv.DOMAIN.local statistika ping --- 5 paketa të transmetuara, 5 të marra, 0% humbje pakete, koha 4006ms rtt min / mesatar / max / mdev = 0,931 / 1,002 / 1,083 / 0,061 ms

Siç mund ta shihni, kur dërgoni një paketë me madhësi 32768 (32 Kb), koha e saj e udhëtimit nga klienti në server dhe mbrapa lundron në rajonin prej 1 milisekonda. Nëse kjo kohë shkon jashtë shkallës në 200 ms, atëherë duhet të mendoni për të rritur vlerën e timeo në mënyrë që të tejkalojë vlerën e shkëmbimit me tre deri në katër herë. Prandaj, këshillohet ta bëni këtë test gjatë një ngarkese të fortë të rrjetit.

Nisja e NFS dhe konfigurimi i murit të zjarrit

Shënimi është kopjuar nga blogu http://bog.pp.ru/work/NFS.html, për të cilin shumë faleminderit !!!

Nis serverin NFS, montimin, kyçjen, kuotën dhe statusin me portat "korrekte" (për murin e zjarrit)

• këshillohet që fillimisht të çmontoni të gjitha burimet tek klientët
• ndalo dhe mos lejo që rpcidmapd të fillojë nëse nuk po planifikon të përdorësh NFSv4: chkconfig --niveli 345 rpcidmapd jashtë shërbimit rpcidmapd ndalo
• nëse është e nevojshme, aktivizoni fillimin e shërbimeve portmap, nfs dhe nfslock: chkconfig --nivelet 345 portmap / rpcbind në chkconfig --nivelet 345 nfs në chkconfig --nivelet 345 nfslock në
• nëse është e nevojshme, ndaloni shërbimet nfslock dhe nfs, nisni portmap / rpcbind, shkarkoni modulin shërbimin nfslock ndaloni shërbimin nfs ndaloni shërbimin portmap start # shërbimi rpcbind start umount / proc / fs / nfsd shërbimi rpcidmapd ndaloni shërbimin rmmod nfsd autofs më vonë duhet të ndalet # diku ekzekutoni rmmod nfs rmmod nfs_acl rmmod i kyçur
• portet e hapura në
  • për RPC: UDP / 111, TCP / 111
  • për NFS: UDP / 2049, TCP / 2049
  • për rpc.statd: UDP / 4000, TCP / 4000
  • për kyçje: UDP / 4001, TCP / 4001
  • për montim: UDP / 4002, TCP / 4002
  • për rpc.rquota: UDP / 4003, TCP / 4003
• për serverin rpc.nfsd shtoni linjën RPCNFSDARGS = "- port 2049" në / etc / sysconfig / nfs
• për serverin e montimit shtoni linjën MOUNTD_PORT = 4002 në / etc / sysconfig / nfs
• për të konfiguruar rpc.rquota për versione të reja, shtoni rreshtin RQUOTAD_PORT = 4003 në / etc / sysconfig / nfs
• për të konfiguruar rpc.rquota është e nevojshme për versionet më të vjetra (megjithatë, duhet të keni kuotën 3.08 ose paketën më të re) shtoni rquotad 4003 / tcp rquotad 4003 / udp në / etj / shërbime
• do të kontrollojë përshtatshmërinë e / etj / eksporteve
• nisni shërbimet rpc.nfsd, mountd dhe rpc.rquota (në të njëjtën kohë nisin rpcsvcgssd dhe rpc.idmapd, nëse nuk keni harruar t'i hiqni) shërbimi nfsd start ose në versionet e reja shërbimi nfs start
• për serverin e kyçjes për sistemet e reja shtoni linjat LOCKD_TCPPORT = 4001 LOCKD_UDPPORT = 4001 në / etc / sysconfig / nfs
• për një server kyç për sistemet e vjetra shto direkt në /etc/modprobe [.conf]: opsionet e kyçura nlm_udpport = 4001 nlm_tcpport = 4001
• lidhni serverin e statusit rpc.statd me portin 4000 (për sistemet e vjetra, ekzekutoni rpc.statd me çelësin -p 4000 në /etc/init.d/nfslock) STATD_PORT = 4000
• nisni shërbimet e kyçura dhe shërbimi rpc.statd filloni nfslock
• sigurohuni që të gjitha portet të jenë të lidhura siç duhet me "lsof -i -n -P" dhe "netstat -a -n" (disa nga portet përdoren nga modulet e kernelit që lsof nuk i sheh)
• nëse para "rindërtimit" serveri përdorej nga klientët dhe ata nuk mund të çmontoheshin, atëherë do të duhet të rinisni shërbimet e montimit automatik në klientët (am-utils, autofs)

Shembull i konfigurimit të serverit dhe klientit NFS

Konfigurimi i serverit

Nëse dëshironi ta bëni direktoriumin tuaj të ndarë NFS të hapur dhe të shkruajtshëm, mund të përdorni opsionin all_kungull në kombinim me opsionet anonuid dhe anongid... Për shembull, për të vendosur të drejtat për përdoruesin "askush" në grupin "askush", mund të bëni sa më poshtë:

ARCHIV ~ # cat / etj / eksporton # Qasje leximi / shkrimi për klientin në 192.168.0.100, me akses rw për përdoruesin 99 me gid 99 / skedarët 192.168.0.100 (rw, sync, all_squash, anonuid = 99, anongid = 9)) # Qasje për lexim / shkrim për klientin në 192.168.0.100, me akses rw për përdoruesin 99 me gid 99 / skedarë 192.168.0.100 (rw, sinkronizo, all_squash, anonuid = 99, anongid = 99))

Kjo do të thotë gjithashtu se nëse doni të lejoni aksesin në drejtorinë e specifikuar, nobody.nobody duhet të jetë pronar i drejtorisë së ndarë:

mali njeri
eksportet e njeriut
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm - Performanca NFS nga IBM.

Të fala, Mc.Sim!