Peatükk 29 NFS: võrgufailisüsteem

Sissejuhatus

Selles peatükis vaatleme võrgu failisüsteemi ( NFS - võrgufail System), populaarne rakendus, mis pakub kliendirakendusi läbipaistev juurdepääs failidele. NFS-i nurgakivi on Sun RPC: Remote Procedure Call, mida me kõigepealt kirjeldame.

Klientprogramm ei vaja NFS-i kasutamiseks spetsiaalseid tööriistu. Kernel tuvastab, et fail on NFS-serveris ja genereerib failile juurdepääsuks automaatselt RPC-kutse.

Me ei hakka üksikasjalikult kirjeldama, kuidas failidele juurdepääsu rakendatakse, vaid kuidas see kasutab Interneti-protokolle, eriti UDP-d.

Suni kaugprotseduuri kutsumine

Enamasti lahendatakse võrgu programmeerimise probleemid, kirjutades rakendusprogramme, mis kutsuvad välja süsteemi pakutavad funktsioonid konkreetsete võrgutoimingute tegemiseks. Näiteks üks funktsioon teostab aktiivse TCP-avamise, teine ​​passiivse TCP-avamise, kolmas saadab andmeid TCP-ühenduse kaudu, neljas määrab konkreetsed protokollivalikud (võimaldab TCP-i elusoleku taimerit) jne. Peatüki 1 jaotises "Rakenduste programmeerimisliidesed" mainisime, et võrguprogrammeerimiseks on kaks populaarset funktsioonikomplekti (rakenduse programmeerimisliides, API), pistikupesad ja TLI. Kliendi kasutatav API ja serveri kasutatav API võivad olla erinevad, samuti kliendis ja serveris töötavad operatsioonisüsteemid. Side- ja rakendusprotokollid määravad kindlaks, kas konkreetne klient saab serveriga suhelda. Unixi klient, mis on kirjutatud C-s, kasutades programmeerimisliidese pesasid ja TCP-d sideprotokollina, saab suhelda COBOL-is kirjutatud suurarvuti serveriga, kasutades teisi API-sid ja TCP-d, kui mõlemad hostid on võrku ühendatud ja mõlemal on TCP-rakendus /ip.

Tavaliselt saadab klient käsud serverile ja server saadab kliendile vastused. Kõik rakendused, mida oleme vaadanud – Ping, Traceroute, marsruutimise deemonid, DNS-i kliendid ja serverid, TFTP, BOOTP, SNMP, Telnet, FTP, SMTP – on kõik sel viisil üles ehitatud.

RPC, Remote Procedure Call, läheneb võrgu programmeerimisele erinevalt. Klientprogramm lihtsalt kutsub serveriprogrammi funktsioone. Nii otsustatakse programmeerija seisukohalt, kuid tegelikkuses toimub järgmine toimingute jada.

1. Kui klient kutsub kaugprotseduuri, kutsutakse kohalikus hostis välja funktsioon, mille loob RPC-pakett. Seda funktsiooni nimetatakse kliendi stub. Klient pakib protseduuri argumendid võrgusõnumisse ja saadab sõnumi serverisse.
2. serveri stub serveri hostis võtab võrgusõnumi vastu. Argumendid ekstraheeritakse võrgusõnumist ja kutsutakse välja rakenduse programmeerija kirjutatud serveriprotseduur.
3. Serveri funktsioon naaseb serveri haldamine stub, mis omakorda võtab vastuvõetud väärtused, pakib need võrgusõnumisse ja saadab sõnumi tagasi kliendi tünnile.
4. kliendi stub tagastab väärtused võrgusõnumist kliendirakendusele.

Võrguprogrammeerimine, kasutades tüve ja RPC teegi rutiine, kasutab API-sid (pistikupesasid või TLI-sid), kuid kasutajarakendused (kliendi poolt kutsutud kliendiprogrammid ja serveriprotseduurid) ei pääse API-le kunagi juurde. Piisab, kui klientrakendus kutsub serveriprotseduuri, samal ajal kui kõik juurutamise üksikasjad on peidetud RPC-paketi, kliendi stub ja serveri stub poolt.

RPC-pakettidel on järgmised eelised.

• Programmeerimine muutub lihtsamaks, sest te ei pea lahendama võrguprogrammeerimise probleeme (ja kui lahendate, siis väga vähe). Rakenduse programmeerijad kirjutavad lihtsalt kliendiprogrammi ja serveriprotseduurid, mida klient kutsub.
• Kui kasutatakse ebausaldusväärset protokolli (nt UDP), käsitleb kõiki üksikasju, nagu ajalõpud ja kordusedastused, RPC-pakett. See omakorda lihtsustab kasutajarakendust.
• RPC teek tegeleb vajaliku argumendi ja tagastusväärtuse teisendamisega. Näiteks kui argumendid koosnevad täisarvudest ja ujukitest, käsitleb RPC pakett kõiki erinevusi täisarvude ja ujukite esituse vahel kliendis ja serveris. See lihtsustab klientide ja serverite rakendamist heterogeensetes keskkondades töötamiseks.

RPC programmeerimist käsitletakse üksikasjalikult 18. peatükis. Kaks kõige populaarsemat RPC-paketti on Sun RPC ja Open Software Foundationi (OSF) hajutatud arvutikeskkonna (DCE) RPC-pakett. Vaatame, kuidas tehakse protseduurikutse, kuidas tagastatud sõnum välja näeb ja kuidas seda võrrelda Sun RPC pakett, kuna seda paketti kasutab võrgu failisüsteem. Sun RPC versiooni 2 kirjeldatakse dokumendis RFC 1057 [Sun Microsystems 1988a].

Sun RPC-sid on kahte tüüpi. Üks versioon on ehitatud socket API abil ning töötab TCP ja UDP-ga. Teist nimetatakse TI-RPC-ks (transpordist sõltumatuks), mis on loodud TLI API abil ja töötab mis tahes kerneli pakutava transpordikihiga. Meie seisukohast pole neil vahet, kuna selles peatükis käsitleme ainult TCP-d ja UDP-d.

Joonis 29.1 näitab RPC protseduuri kõne sõnumi vormingut UDP abil.

Joonis 29.1 RPC protseduuride kõne sõnumid UDP datagrammi vormingus.

Standardsed IP ja UDP päised on näidatud varem (joonis 3.1 ja joonis 11.2). Kõik pärast UDP-päist määrab RPC-pakett.

Tehingu ID ( XID - tehingu ID) määrab klient ja tagastab server. Kui klient saab vastuse, võrdleb ta serveri tagastatud XID-d saadetud päringu XID-ga. Kui need ei ühti, loobub klient sõnumist ja ootab järgmise saabumist. Iga kord, kui klient väljastab uue RPC, muudab ta XID-d. Kui aga klient saadab RPC uuesti (kui vastust ei saadud), siis XID ei muutu.

Kõne muutuja on 0 kõne ja 1 vastuse jaoks. Praegune RPC versioon on 2. Järgmised kolm muutujat, programmi number, versiooni number ja protseduuri number, määravad kindlaks konkreetse protseduuri, mida serveris välja kutsuda.

Mandaadid tuvastavad kliendi. Mõnes näites jäetakse see väli tühjaks, teistes aga näete kasutaja numbrilist ID-d ja selle grupi ID-d, kuhu ta kuulub. Server saab õigusi uurida ja otsustada, kas taotlust töödelda või mitte. Verifitseerimist (tõendajat) kasutatakse turvalise RPC (Secure RPC) jaoks, mis kasutab DES-krüptimist. Kuigi autoriseerimis- ja valideerimisväljad on muutuva pikkusega väljad, edastatakse nende pikkus välja osana.

Järgnevad protseduuri parameetrid. Nende vorming sõltub sellest, kuidas rakendus kaugprotseduuri määratleb. Kuidas vastuvõtja (serveri tünn) parameetrite suurust teab? Kuna kasutatakse UDP-d, saab parameetrite suuruse arvutada UDP datagrammi suurusest, millest on lahutatud kõigi väljade pikkus kuni valideerimisväljani. Kui UDP asemel kasutatakse TCP-d, pole fikseeritud pikkuse kontseptsiooni, kuna TCP on baitide voog ilma kirje eraldajateta. Sellisel juhul ilmub TCP päise ja XID vahele 4-baidine väli, millest vastuvõtja saab teada RPC-kõne pikkuse baitides. See võimaldab vajadusel saata RPC väljakutse sõnumit mitmes TCP segmendid. (DNS kasutab sarnast tehnikat; 14. peatüki harjutus 4.)

Joonis 29.2 näitab RPC vastuse vormingut. Kui kaugprotseduur on oma töö lõpetanud, saadetakse see serveri tünnist kliendi tünnile.

Joonis 29.2 RPC protseduuri vastuse sõnumi vorming UDP datagrammina.

Kõne XID kopeeritakse lihtsalt vastuse XID-sse. Vastuse väli sisaldab 1 ja see väli eristab väljakutset ja vastust. Olekuväli sisaldab väärtust null, kui kõneteade on vastu võetud. (Kui RPC versiooninumber ei ole 2 või kui server ei saa klienti autentida, võidakse sõnumist loobuda.) Turvalise RPC puhul kasutatakse kontrollija välja serveri määramiseks.

Nõusoleku oleku väli seatakse nullile, kui kõik on korras. Nullist erinev väärtus võib viidata näiteks valele versiooninumbrile või valele protseduurinumbrile. Kui UDP asemel kasutatakse TCP-d, siis nagu RPC väljakutseteate puhul, saadetakse TCP päise ja XID vahele 4-baidine väli.

XDR: väline andmete esitus

External Data Representation (XDR) on standard, mida kasutatakse väärtuste kodeerimiseks RPC kõne- ja vastusesõnumites - RPC päiseväljad (XID, programmi number, vastuvõtuolek jne), protseduuri parameetrid ja protseduuri tulemused. Standardne andmete kodeerimise viis võimaldab kliendil kutsuda protseduure erineva arhitektuuriga süsteemis. XDR on määratletud standardis RFC 1014 [Sun Microsystems 1987].

XDR määratleb teatud arvu andmetüüpe ja täpne viis kuidas need RPC-sõnumis edastatakse (bitijärjestus, baitide järjekord jne). Saatja peab koostama RPC-sõnumi XDR-vormingus, seejärel teisendab vastuvõtja XDR-vormingu selle algsesse esitusviisi. (Tema süsteemi jaoks aktsepteeritud vormingus.) Näiteks joonistel 29.1 ja 29.2 näeme, et kõik meie näidatud täisarvud (XID, kõne, programmi number jne) on 4-baidised täisarvud. Tõepoolest, kõik XDR-i täisarvud võtavad 4 baiti. XDR toetab muid andmetüüpe, sealhulgas märgita täisarve, tõeväärtusi, ujukomanumbreid, fikseeritud pikkusega massiive, muutuva pikkusega massiive ja struktuure.

Sadama kaardistamine

Kaugprotseduure sisaldavad RPC-serveriprogrammid kasutavad dünaamiliselt määratud porte, mitte eelnevalt teadaolevaid porte. See nõuab teatud vormis "registreerimist", et olla alati teadlik sellest, millist dünaamiliselt määratud porti antud RPC-programm kasutab. Sun RPC-s nimetatakse seda registripidajat pordi kaardistajaks. (Porti kaardistaja on server, mis teisendab RPC programmide numbrid DARPA protokolli pordinumbriteks. RPC-kõne tegemiseks peab see server töötama.)

Nimes sisalduv termin "port" pärineb TCP- ja UDP-pordi numbritest, mis on Interneti-protokolli perekonna tunnused. Kuna TI-RPC töötab mis tahes transpordikihi peal, mitte ainult TCP ja UDP peal, on TI-RPC-d kasutavate süsteemide (näiteks SVR4 ja Solaris 2.2) nimede pordi kaardistaja teisendatud rpcbindiks. Küll aga jätkame tuttavama sadamakaardistaja kasutamist.

Tegelikult peab pordilahendajal endal olema eelnevalt teadaolev port: UDP port 111 ja TCP port 111. Portresolver on lihtsalt RPC-serveri programm. Sellel on programminumber (100000), versiooninumber (2), TCP-port 111 ja UDP-port 111. Serverid registreerivad üksteist pordilahendajaga RPC-kõnede abil ja kliendid küsivad pordilahendit RPC-kõnede abil. Pordilahendaja pakub nelja serveriprotseduuri:

1. PMAPPROC_SET. RPC-server helistab käivitamisel, et registreerida programmi number, versiooninumber ja protokoll pordilahendiga.
2. PMAPPROC_UNSET. Server helistas varem registreeritud teisenduse eemaldamiseks.
3. PMAPPROC_GETPORT. RPC klient helistas käivitamisel, et saada antud programminumbri, versiooninumbri ja protokolli pordi number.
4. PMAPPROC_DUMP. Tagastab kõik üksused (programmi number, versiooni number, protokoll ja pordi number) pordi lahendaja andmebaasi.

RPC-serveriprogrammi käivitumisel ja hiljem, kui RPC-klientprogramm seda kutsub, toimuvad järgmised toimingud.

1. Pordilahendaja peaks kõigepealt käivituma, tavaliselt siis, kui süsteem käivitub. See loob TCP-lõpp-punkti ja avab passiivselt TCP-pordi 111. See loob ka UDP-lõpp-punkti, mis ootab UDP-datagrammi saabumist UDP-porti 111.
2. Kui RPC-serveri programm käivitub, loob see iga toetatud programmi versiooni jaoks TCP-lõpp-punkti ja UDP-lõpp-punkti. (RPC programm võib toetada mitut versiooni. Klient määrab vajaliku versiooni serveriprotseduuri kutsudes.) Igale lõpp-punktile määratakse dünaamiliselt määratud pordinumber. (Pole vahet, kas TCP- ja UDP-pordi numbrid on samad või erinevad.) Server registreerib iga programmi, versiooni, protokolli ja pordi numbri, tehes kaugportide lahendamise protseduuri kutse PMAPPROC_SET.
3. Kui RPC-klientprogramm käivitub, kutsub see välja pordilahendaja protseduuri PMAPPROC_GETPORT, et saada antud programmile, versioonile ja protokollile dünaamiliselt määratud pordinumber.
4. Klient saadab sammus 3 saadud pordinumbrile RPC väljakutseteate. Kui kasutatakse UDP-d, saadab klient lihtsalt RPC väljakutseteadet sisaldava UDP-andmegrammi (Joonis 29.1) serveri UDP-pordi numbrile. Vastuseks saadab server UDP-datagrammi, mis sisaldab RPC vastuseteadet (joonis 29.2). Kui kasutatakse TCP-d, avab klient serveri TCP-pordi numbrile aktiivse avamise ja saadab seejärel ühenduse kaudu RPC väljakutseteate. Server vastab ühenduse kaudu RPC vastusesõnumiga.

Programm rpcinfo(8) prindib kõik praegused pordilahendaja sätted. (Siin kutsutakse välja pordilahendaja protseduur PMAPPROC_DUMP.) Järgmine on tüüpiline väljund:

Päike % /usr/etc/rpcinfo -p
programm versus proto port
100005 1 tcp 702 mountd NFS mount deemon
100005 1 udp 699 mountd
100005 2 tcp 702 mountd
100005 2 udp 699 mountd

100003 2 udp 2049 nfs NFS ise

100021 1 tcp 709 nlockmgr NFS-lukuhaldur
100021 1 udp 1036 nlockmgr
100021 2 tcp 721 nlockmgr
100021 2 udp 1039 nlockmgr
100021 3 tcp 713 nlockmgr
100021 3 udp 1037 nlockmgr

Näeme, et mõned programmid toetavad mitut versiooni ning igal programminumbri, versiooninumbri ja protokolli kombinatsioonil on oma pordinumbri vastendus, mida haldab pordilahendaja.

Ühendusdeemoni mõlemale versioonile pääseb juurde sama TCP-pordi numbri (702) ja sama UDP-pordi numbri (699) kaudu, kuid igal blokeerimishalduri versioonil on oma pordinumber.

NFS-protokoll

NFS pakub klientidele läbipaistvat juurdepääsu failidele ja serveri failisüsteemile. See erineb FTP-st (peatükk 27), mis pakub failiedastust. FTP abil tehakse faili täielik koopia. NFS pääseb juurde ainult nendele failiosadele, millele protsess juurde pääseb, ja NFS-i peamine eelis on see, et see muudab juurdepääsu läbipaistvaks. See tähendab, et iga kliendirakendus, mis suudab töötada kohaliku failiga, võib sama hästi töötada ka NFS-failiga, ilma programmis endas muudatusi tegemata.

NFS on Sun RPC abil loodud klient-serveri rakendus. NFS-kliendid pääsevad juurde NFS-serveris olevatele failidele, saates serverisse RPC-päringuid. Seda saab realiseerida tavaliste kasutajaprotsesside abil – nimelt võib NFS-klient olla kasutajaprotsess, mis teeb serverile spetsiifilisi RPC-kõnesid, mis võib olla ka kasutajaprotsess. Kuid NFS-i rakendatakse tavaliselt erinevalt kahel põhjusel. Esiteks peab juurdepääs NFS-failidele olema kliendi jaoks läbipaistev. Seetõttu teeb NFS-kliendikõned kliendi operatsioonisüsteem kliendi kasutajaprotsessi nimel. Teiseks on NFS-serverid juurutatud operatsioonisüsteemi sees, et parandada serveri tõhusust. Kui NFS-server oleks kasutajaprotsess, peaks iga kliendi päring ja serveri vastus (sealhulgas loetavad või kirjutatavad andmed) läbima kerneli ja kasutajaprotsessi vahelise eraldaja, mis on üldiselt üsna kulukas.

Selles jaotises vaatleme NFS-i versiooni 2, nagu on dokumenteeritud dokumendis RFC 1094 [Sun Microsystems 1988b]. parim kirjeldus Sun RPC, XDR ja NFS on esitatud dokumendis [X/Open 1991]. Üksikasjad NFS-i kasutamise ja manustamise kohta on toodud [Stern 1991]. NFS-protokolli 3. versiooni spetsifikatsioonid rakendati 1993. aastal, mida käsitleme selle peatüki ühes osas.

Joonis 29.3 näitab tüüpilisi NFS-kliendi ja NFS-serveri sätteid. Sellel joonisel peate pöörama tähelepanu järgmisele.

1. Klienti ei huvita, kas ta pääseb juurde kohalikule failile või NFS-failile. Kernel tuvastab selle faili avamisel. Kui fail on avatud, edastab kernel kõik juurdepääsud kohalikele failidele kasti "kohalik juurdepääs failidele" ja kõik viited NFS-failidele edastatakse kasti "NFS-klient".
2. NFS-klient saadab RPC-päringuid NFS-serverisse TCP/IP-mooduli kaudu. NFS kasutab tavaliselt UDP-d, kuid uuemad rakendused võivad kasutada TCP-d.
3. NFS-server võtab kliendilt päringuid vastu UDP-datagrammide kujul pordis 2049. Kuigi NFS võib töötada pordilahendajaga, mis võimaldab serveril kasutada dünaamiliselt määratud porte, on UDP-port 2049 enamikus rakendustes NFS-iga ühendatud.

Joonis 29.3 Tüüpilised NFS-kliendi ja NFS-serveri sätted.

Kui NFS-server saab kliendilt päringu, edastatakse see kohalikule failijuurdepääsurutiinile, mis tagab juurdepääsu serveri kohalikule kettale.

Serveril võib kliendi päringute töötlemine aega võtta. Isegi kohalikule failisüsteemile juurdepääs võib võtta veidi aega. Selle aja jooksul ei taha server blokeerida teiste klientide päringuid, mida tuleb samuti teenindada. Selle olukorra lahendamiseks käivitatakse enamik NFS-servereid mitu korda, mis tähendab, et kernelis on mitu NFS-serverit. Spetsiifilised meetodid lahendused sõltuvad operatsioonisüsteemist. Enamik Unixi kernelisüsteeme ei "ela" mitut NFS-serverit, vaid käitavad mitut kasutajaprotsessi (tavaliselt nimetatakse seda nfsd-ks), mis käivitavad ühe süsteemikutse ja jäävad kerneli protsessina tuuma sisse.

Sarnaselt kulub NFS-kliendil kliendi hostis oleva kasutajaprotsessi päringu töötlemiseks aega. RPC väljastatakse serveri hostile, mille järel oodatakse vastust. Selleks, et kliendihosti kasutajaprotsessid saaksid igal ajal NFS-i kasutada, töötab kliendi tuumas mitu NFS-klienti. Konkreetne teostus sõltub ka operatsioonisüsteemist. Unixi süsteem kasutab tavaliselt NFS-serveriga sarnast tehnikat: kasutajaprotsess nimega biod teeb ühe süsteemikutse ja jääb kerneli protsessina tuuma sisse.

Enamik Unixi hoste saab toimida nii NFS-kliendi kui ka NFS-serverina või mõlemana. Enamikul arvutirakendustel (MS-DOS) on ainult NFS-i kliendirakendused. Enamik IBMi suurarvuteid pakuvad ainult NFS-serveri funktsioone.

NFS on tõesti enamat kui lihtsalt NFS-protokoll. Joonis 29.4 näitab erinevaid RPC-programme, mida kasutatakse koos NFS-iga.

Rakendus	Programmi number	Versiooni number	Protseduuride arv
pordi muundur
NFS
mount programm
blokeerimishaldur
oleku monitor

Joonis 29.4 Erinevad NFS-is kasutatavad RPC-programmid.

Sellel joonisel ühikutena näidatud versioonid on leitud sellistes süsteemides nagu SunOS 4.1.3. Uuemad rakendused pakuvad mõne programmi uuemaid versioone. Näiteks Solaris 2.2 toetab ka pordilahendaja versioone 3 ja 4 ning mount deemoni versiooni 2. SVR4 toetab ka pordimuunduri versiooni 3.

Ühendusdeemon käivitatakse kliendi NFS-hostis enne, kui klient pääseb juurde serveri failisüsteemile. Kirjeldame seda protsessi allpool.

Lukustushaldur ja olekumonitor võimaldavad kliendil lukustada mõned NFS-serveris olevad failid. Need kaks programmi on NFS-protokollist sõltumatud, kuna blokeerimine nõuab kliendi autentimist nii kliendi hostis kui ka serveris ning NFS ise on "ükskõikne". (NFS-i ükskõiksusest räägime lähemalt allpool.) [X/Open 1991] peatükkides 9, 10 ja 11 on dokumenteeritud protseduurid, mida lukuhaldur ja olekumonitor kasutavad NFS-i lukustamiseks.

Failide kirjeldused

Üks NFS-i põhialuseid on rakendatud failideskriptorite abil. Läbipaistmatut kasutatakse objektiserveris olevale failile või kataloogile viitamiseks. Mõiste läbipaistmatu tähendab, et server loob failideskriptori, edastab selle kliendile tagasi, mida klient seejärel failile juurde pääsedes kasutab. Klient ei vaata kunagi failideskriptori sisu – selle sisu pakub huvi ainult serverile.

NFS-klient saab failikäepideme iga kord, kui ta avab tegelikult NFS-serveris oleva faili. Kui NFS-klient loeb või kirjutab seda faili (kasutajaprotsessi nimel), edastatakse failideskriptor serverile tagasi. See näitab, et failile on juurdepääs.

Tavaliselt ei tegele kasutajaprotsess failideskriptoritega. Failideskriptoreid vahetavad NFS-klient ja NFS-server. NFS-i versioonis 2 on faili deskriptor 32 baiti ja versioonis 3 on see kasvanud 64 baiti.

Unixi serverid salvestavad failideskriptoris tavaliselt järgmise teabe: failisüsteemi identifikaator (peamise ja väiksema failisüsteemi seadmete numbrid), inoodi number (i-node) (failisüsteemis kordumatu number), inode genereerimise number (number, mis muutub iga kord, kui inode kasutatakse teise faili jaoks).

Mount Protokoll

Klient kasutab NFS-ühenduse protokolli, et ühendada enne NFS-failidele juurdepääsu serveri failisüsteemi. Tavaliselt juhtub see siis, kui klient käivitub. Selle tulemusena saab klient serveri failisüsteemi failideskriptori.

Joonis 29.5 kirjeldab Unixi kliendijada käsu mount(8) täitmisel.

Joonis 29.5 Ühendusprotokoll, mida kasutab Unixi mount käsk.

Seda tehes tehakse järgmised sammud.

1. Kui server käivitub, käivitub sellel pordimuundur.
2. Pärast pordi lahendajat käivitub serveris mount deemon (mountd). See loob TCP ja UDP lõpp-punkti ning määrab mõlemale dünaamiliselt määratud pordinumbri. Seejärel registreerib see need numbrid pordi lahendajaga.
3. Klient täidab mount-käsu, mis väljastab RPC-kutse serveri pordilahendajale, et saada serveri mount-deemonilt pordi number. Kliendi ja pordilahendaja vaheliseks suhtluseks saab kasutada nii TCP-d kui ka UDP-d, kuid tavaliselt kasutatakse UDP-d.
4. Pordimuundur teatab pordi numbri.
5. mount käsk väljastab serveri failisüsteemi ühendamiseks RPC-kutse mount-deemonile. Jällegi saab kasutada nii TCP-d kui ka UDP-d, kuid tavaliselt kasutatakse UDP-d. Nüüd saab server klienti kinnitada selle IP-aadressi ja pordi numbri alusel, et näha, kas klient saab määratud failisüsteemi ühendada.
6. Ühendusdeemon vastab määratud failisüsteemi failideskriptoriga.
7. Kliendi mount käsk väljastab mount süsteemikutse, et seostada toimingus 5 saadud failideskriptor kliendi hosti kohaliku ühenduspunktiga. Faili deskriptor salvestatakse kliendi NFS-koodi ja sellest ajast alates kasutavad kõik serveri failisüsteemi failidele juurdepääsu töötlevad kasutajad lähtepunktina failideskriptorit.

Selline teostus annab kogu paigaldusprotsessi, välja arvatud kliendi ühendamise süsteemikutse, pigem kasutajaprotsessidele kui kernelile. Kolm programmi, mida oleme näidanud – mount käsk, pordi lahendaja ja mount deemon – on kasutaja protsessid.

Selles näites käivitati käsk host sunil (NFS-klient).

päike # mount -t nfs bsdi:/usr /nfs/bsdi/usr

See käsk ühendab /usr kataloogi bsdi hostis (NFS-serveris) kohaliku failisüsteemina /nfs/bsdi/usr. Joonis 29.6 näitab tulemust.

Joonis 29.6 Kataloogi bsdi:/usr paigaldamine kui /nfs/bsdi/usr hostile sunnile.

Seejärel pääseb sunkliendis failile /nfs/bsdi/usr/rstevens/hello.c juurde pääsedes bsdi serveris failile /usr/rstevens/hello.c.

NFS protseduurid

NFS-server pakub 15 protseduuri, mida me nüüd kirjeldame. (Kirjelduses kasutatud numbrid ei ühti NFS-i protseduuride numbritega, kuna oleme need funktsioonide järgi rühmitanud.) Kuigi NFS töötati välja operatsioonisüsteemides, mitte ainult Unixi süsteemides, põhinevad mõned rutiinid konkreetselt Unixi käitumisel, mida omakorda ei pruugi toetada teised operatsioonisüsteemid (nt kõvalingid, sümboolsed lingid, ühiskasutus, täitmisload jne). Peatükk 4 sisaldab rohkem teavet failisüsteemide omaduste kohta, millest mõnda kasutab NFS.

1. GETATTR. Tagastab faili atribuudid: faili tüüp (tavaline fail, kataloog jne), õigused, faili suurus, faili omanik, viimane juurdepääsuaeg ja nii edasi.
2. SETATTR. Määrab faili atribuudid. Määrata saab ainult teatud atribuutide komplekti: load, omanik, grupi omand, suurus, viimane juurdepääsuaeg ja viimane muutmise aeg.
3. STATFS. Tagastab failisüsteemi oleku: suurus vaba ruum, edastamiseks optimaalne suurus ja nii edasi. Kasutab näiteks Unixi df käsk.
4. VAATA ÜLES. "Hindab" faili. Klient kutsub seda protseduuri välja iga kord, kui kasutajaprotsess avab faili, mis asub NFS-serveris. Tagatakse faili deskriptor koos faili atribuutidega.
5. LOE. Loeb failist. Klient määrab faili deskriptori, algusnihke baitides ja maksimaalse lugemise baitide arvu (kuni 8192).
6. KIRJUTA. Kirjutab faili. Klient määrab faili deskriptori, algbaitide nihke, kirjutatavate baitide arvu ja kirjutatavad andmed.

   NFS-i kirjutamine peab olema sünkroonne (ootel). Server ei saa vastata nupuga OK enne, kui andmed (ja muu värskendamist vajava faili kohta käiv teave) on edukalt kettale kirjutatud.

7. LOO. Loob faili.
8. EEMALDA. Kustutab faili.
9. ÜMBER NIMETAMINE. Nimetab faili ümber.
10. LINK. Loob failile kõva lingi. Kõva link on Unixi kontseptsioon, mis määrab, et konkreetsel kettal oleval failil võib olla suvaline arv sisestuspunkte (nimesid, mida nimetatakse ka kõvadeks linkideks), mis sellele failile osutavad.
11. SYMLINK. Loob failile sümboolse lingi. Sümboolne link on fail, mis sisaldab teise faili nime. Enamik sümboolse lingiga tehtavaid toiminguid (nt avamine) tehakse tegelikult failiga, millele sümboolne link viitab.
12. LOE LINK. Sümboolse lingi lugemine tagastab faili nime, millele sümboolne link viitab.
13. MKDIR. Loob kataloogi.
14. RMDIR. Kustutab kataloogi.
15. READDIR. Loeb kataloogi. Kasutab näiteks Unix ls käsk.

Tegelikult algavad loetletud protseduuride nimed prefiksiga NFSPROC_, mille oleme välja jätnud.

UDP või TCP?

NFS oli algselt kirjutatud UDP-i kasutamiseks ja kõik müüjad pakuvad seda võimalust. Kuid uuemad juurutused toetavad ka TCP-d. TCP-tuge kasutatakse töötamiseks laivõrkudes, mis muutuvad kiiremaks. Seetõttu ei piirdu NFS-i kasutamine enam ainult kohtvõrkudega.

Piirid kohalike ja globaalsete võrkude vahel hägustuvad ja see kõik toimub väga kiiresti. Tagastusajad varieeruvad väga laias vahemikus ning ületäitumist esineb üha sagedamini. Need laivõrkude omadused toovad kaasa asjaolu, et nad kasutavad üha enam TCP jaoks mõeldud algoritme - aeglane käivitamine ja ülevoolu vältimine. Kuna UDP ei paku nendele algoritmidele midagi sarnast, tuleb need või sarnased NFS-kliendisse ja serverisse sisse ehitada, vastasel juhul tuleb kasutada TCP-d.

NFS üle TCP

Berkeley Net/2 NFS-i juurutus toetab nii UDP-d kui ka TCP-d. [Macklem 1991] kirjeldab seda teostust. Vaatame, kuidas NFS-i kasutamine TCP-ga töötamisel erineb.

1. Kui server käivitub, käivitab see NFS-serveri, mis avab aktiivse TCP-pordi 2049, oodates kliendilt ühenduse taotlust. Tavaliselt tehakse seda lisaks tavalisele NFS UDP-le, mis kuulab sissetulevaid datagramme UDP-pordis 2049.
2. Kui klient ühendab serveri failisüsteemi TCP-ga, avab see serveris TCP-pordi 2049 aktiivse avamise. See loob selle failisüsteemi jaoks TCP-ühenduse kliendi ja serveri vahel. Kui sama klient ühendab samasse serverisse teise failisüsteemi, luuakse teine ​​TCP-ühendus.
3. Nii klient kui ka server määravad oma ühenduse otstele TCP "jääb elus" (peatükk 23). See võimaldab teil määrata ühe või teise vahetuse osaleja rikke või taaskäivitamise hetke.
4. Kõik kliendi rakendused, mis kasutavad serveri failisüsteemi, jagavad selle failisüsteemi jaoks sama TCP-ühendust. Näiteks kui see oleks joonisel 29.6, kui bsdi-s oleks /usr kataloogi all teine ​​kataloog nimega smith, jagaksid juurdepääsud kataloogides /nfs/bsdi/usr/rstevens ja /nfs/bsdi/usr/smith sama TCP ühendus.
5. Kui klient tuvastab, et server on kokku jooksnud või taaskäivitatud (pärast TCP-tõrketeate "ühendus aegus" või "ühenduse katkestas host" saamist), proovib ta serveriga uuesti ühendust luua. Klient teeb selle failisüsteemi jaoks TCP-ühenduse taastamiseks uue aktiivse avamise. Kõik kliendi päringud, mille eelmine ühendus aegus, esitatakse uuesti uuel ühendusel.
6. Kui klient jookseb kokku, jooksevad kokku ka rakendused, mis töötasid enne krahhi. Kui klient taaskäivitub, ühendab see tõenäoliselt uuesti serveri failisüsteemi, kasutades TCP-d, kasutades serveriga teistsugust TCP-ühendust. Selle failisüsteemi eelmine ühendus kliendi ja serveri vahel on pooleldi avatud olekus (server arvab, et see on endiselt avatud), kuid kuna server on määranud valiku "jää elus", siis see pooleldi avatud ühendus suletakse, kui TCP-server saadab järgmise sondi "jää ellu".

Aja jooksul plaanivad teised müüjad hakata NFS-i TCP kaudu toetama.

NFS-i näited

Kasutame tcpdump, et näha, milliseid NFS-rutiine klient kasutab tavalistes failitoimingutes. Kui tcpdump teeb kindlaks, et UDP-andmegramm sisaldab sihtpordiga 2049 RPC-kutset (kõne on 0 joonisel 29.1), dekodeerib see datagrammi NFS-päringuna. Samamoodi, kui UDP-andmegramm sisaldab RPC-vastust (vastus on 1 joonisel 29.2) lähtepordiga 2049, dekodeerib see datagrammi NFS-vastuseks.

Lihtne näide: faili lugemine

Esimeses näites kopeerime NFS-serveris asuva faili cat(1) käsu abil terminali:

Päike % cat /nfs/bsdi/usr/rstevens/hello.c kopeeri fail terminali
peamine ()
{
printf("tere, maailm\n");
}

Failisüsteem /nfs/bsdi/usr hostis sun (NFS-klient) on tegelikult /usr hosti bsdi-s (NFS-serveris), nagu on näidatud joonisel 29.6. Sun kernel tuvastab selle, kui cat avab faili ja kasutab failile juurdepääsuks NFS-i. Joonis 29.7 näitab käsu tcpdump väljundit.

1 0.0 sun.7aa6 > bsdi.nfs: 104 getattr
2 0,003587 (0,0036) bsdi.nfs > sun.7aa6: vastake ok 96

3 0,005390 (0,0018) sun.7aa7 > bsdi.nfs: 116 otsing "rstevens"
4 0,009570 (0,0042) bsdi.nfs > sun.7aa7: vastake ok 128

5 0,011413 (0,0018) sun.7aa8 > bsdi.nfs: 116 otsing "hello.c"
6 0,015512 (0,0041) bsdi.nfs > sun.7aa8: vastake ok 128

7 0,018843 (0,0033) sun.7aa9 > bsdi.nfs: 104 getattr
8 0,022377 (0,0035) bsdi.nfs > sun.7aa9: vastake ok 96

9 0,027621 (0,0052) sun.7aaa > bsdi.nfs: 116 loe 1024 baiti @ 0
10 0,032170 (0,0045) bsdi.nfs > sun.7aaa: vastake ok 140

Joonis 29.7 NFS-i käitumine faili lugemisel.

Käsk tcpdump dekodeerib NFS-i päringu või vastuse ja prindib pordi numbri asemel kliendi XID-välja. XID väli ridadel 1 ja 2 on 0x7aa6.

Failinime /nfs/bsdi/usr/rstevens/hello.c töötleb kliendituuma avatud funktsioon üks nimeelement korraga. Kui avatud funktsioon jõuab /nfs/bsdi/usr-ni, teeb see kindlaks, et tegemist on NFS-i ühenduspunktiga.

1. real kutsub klient välja protseduuri GETATTR, et hankida kliendi ühendatud serverikataloogi atribuudid (/usr). See RPC-päring sisaldab lisaks IP- ja UDP-päistele 104 baiti andmeid. Vastus real 2 tagastab OK ja sisaldab lisaks IP- ja UDP-päistele 96 baiti andmeid. Sellel joonisel näeme, et minimaalne NFS-sõnum sisaldab ligikaudu 100 baiti andmeid.

Real 3 kutsub klient välja LOOKUP protseduuri failis rstevens ja saab real 4 vastuse OK. LOOKUP määrab rstevensi faili nime ja faili deskriptori, mille kernel kaugfailisüsteemi ühendamisel salvestas. Vastus sisaldab uut failikirjeldust, mida kasutatakse järgmises etapis.

Real 5 otsib klient LOOKUP c hello.c, kasutades real 4 failideskriptorit. Ta saab real 6 teise failideskriptori. See uus failideskriptor on täpselt see, mida klient kasutab ridadel 7 ja 9 failile /nfs / viitamiseks. bsdi/usr/rstevens/hello.c. Näeme, et klient otsib avatava faili tee iga nimekomponendi LOOKUP.

Real 7 käivitab klient uuesti GETATTR-i, millele järgneb 9. real READ. Klient taotleb 1024 baiti, alustades nihkest 0, kuid saab vähem kui 1024 baiti andmeid. (Pärast RPC väljade suuruste ja muude READ-protseduuriga tagastatud väärtuste lahutamist tagastatakse real 10 38 baiti andmeid. See on täpselt faili hello.c suurus.)

Selles näites ei tea kasutajaprotsess nendest kerneli tehtud NFS-i päringutest ja vastustest. Rakendus kutsub lihtsalt kerneli avatud funktsiooni, mis põhjustab 3 päringu ja 3 vastuse vahetuse (read 1–6) ning seejärel kerneli lugemisfunktsiooni, mis põhjustab 2 päringut ja 2 vastust (read 7–10). Kliendirakenduse puhul on NFS-serveris asuv fail läbipaistev.

Lihtne näide: kataloogi loomine

Teise näitena muudame töökataloogi NFS-serveri kataloogiks ja loome seejärel uue kataloogi:

Päike % cd /nfs/bsdi/usr/rstevens muuta töökataloogi
päike % mkdir mail luua kataloog

Joonis 29.8 näitab käsu tcpdump väljundit.

1 0.0 sun.7ad2 > bsdi.nfs: 104 getattr
2 0,004912 (0,0049) bsdi.nfs > sun.7ad2: vastake ok 96

3 0,007266 (0,0024) sun.7ad3 > bsdi.nfs: 104 getattr
4 0,010846 (0,0036) bsdi.nfs > sun.7ad3: vastake ok 96

5 35,769875 (35,7590) sun.7ad4 > bsdi.nfs: 104 getattr
6 35.773432 (0.0036) bsdi.nfs > sun.7ad4: vastake ok 96

7 35.775236 (0.0018) sun.7ad5 > bsdi.nfs: 112 otsing "Mail"
8 35.780914 (0.0057) bsdi.nfs > sun.7ad5: vastake ok 28

9 35,782339 (0,0014) sun.7ad6 > bsdi.nfs: 144 mkdir "Mail"
10 35,992354 (0,2100) bsdi.nfs > sun.7ad6: vastake ok 128

Joonis 29.8 NFS-i käitumine kataloogi (cd) muutmisel NFS-kataloogiks ja seejärel kataloogi (mkdir) loomisel.

Kataloogi muutmisel kutsub klient GETATTR protseduuri kaks korda (read 1-4). Kui loome uue kataloogi, helistab klient GETATTR (read 5 ja 6), seejärel LOOKUP (read 7 ja 8, et kontrollida, et kataloogi pole), seejärel MKDIR, et luua kataloog (read 9 ja 10). OK vastus real 8 ei tähenda, et kataloog on olemas. See tähendab lihtsalt, et protseduur andis mingi väärtuse. tcpdump ei tõlgenda NFS-protseduuride tagastatud väärtust. Käsk lihtsalt prindib vastuses OK ja andmete baitide arvu.

ükskõiksus

Üks NFS-i omadusi (NFS-i kriitikud nimetavad seda tüükaks, mitte omaduseks) on see, et NFS-server on ükskõikne. Serveril pole vahet, millised kliendid millistele failidele juurde pääsevad. Pange tähele, et varem näidatud NFS-protseduuride loendis ei ole avatud ega sulgemise protseduuri. LOOKUP-protseduur sarnaneb avamisega, kuid server ei tea kunagi, kas klient on pärast LOOKUP-i tegemist failile juurde pääsenud.

Selle "ükskõikse käitumise" põhjuseks on serveri krahhist taastumise hõlbustamine pärast selle kokkujooksmist ja taaskäivitamist.

Näide: serveri krahh

Järgmises näites loeme faili NFS-serverist, kui server läheb alla ja taaskäivitub. See näitab, kuidas serveri "ükskõiksus" võimaldab kliendil "ei tea", et server on maas. Kogu aja jooksul, mil server jookseb kokku ja taaskäivitub, ei ole klient probleemist teadlik ja kliendirakendus töötab samamoodi nagu varem.

Sun-kliendis käivitasime cat väga suure faili argumendina (/usr/share/lib/termcap svr4 NFS-serveris), ühendasime transpordi ajal Etherneti kaabli lahti, sulgesime ja taaskäivitasime serveri ning ühendasime seejärel uuesti kaabel. Klient oli konfigureeritud lugema 1024 baiti NFS-i lugemise kohta. Joonis 29.9 näitab tcpdump väljundit.

Read 1-10 vastavad faili avavale kliendile. See toiming sarnaneb joonisel 29.7 kujutatule. Real 11 näeme esimest lugemist (READ) 1024 baidise andmefaili failist; vastus tagastati real 12. See jätkub kuni reani 129 (lugemine READ 1024 baiti ja seejärel OK vastus).

Ridadel 130 ja 131 näeme kahte päringut, mis aeguvad ja mis saadetakse uuesti ridadele 132 ja 133. Esimene küsimus: näeme kahte lugemistaotlust, millest üks algab nihkest 65536 ja teine ​​algab nihkest 73728, miks? Kliendituum on kindlaks teinud, et klientrakendus teostab järjestikust lugemist ja on püüdnud eelnevalt hankida andmeplokke. (Enamik Unixi kerneleid teeb seda ettelugemiseks.) Kliendituum on käivitanud ka mitu NFS-i ploki I/O-deemonit (biod-protsesse), mis üritavad genereerida kliendi nimel mitut RPC-päringut. Üks deemon loeb 8192 baiti alates 65536-st (1024-baidistes ahelates), teised aga edasi 8192 baiti alates 73728-st.

Kliendi kordusedastused kuvatakse ridadel 130–168. Real 169 näeme, et server taaskäivitas ja saatis ARP-päringu enne kliendi NFS-i päringule vastamist realt 168. Vastus reale 168 saadetakse reale 171. Kliendi READ-päringud jätkuvad.

1 0.0 sun.7ade > svr4.nfs: 104 getattr
2 0,007653 (0,0077) svr4.nfs > sun.7ade: vastake ok 96

3 0,009041 (0,0014) sun.7adf > svr4.nfs: 116 otsingu "jagamine"
4 0,017237 (0,0082) svr4.nfs > sun.7adf: vastake ok 128

5 0,018518 (0,0013) sun.7ae0 > svr4.nfs: 112 otsing "lib"
6 0,026802 (0,0083) svr4.nfs > sun.7ae0: vastake ok 128

7 0,028096 (0,0013) sun.7ae1 > svr4.nfs: 116 otsing "termcap"
8 0,036434 (0,0083) svr4.nfs > sun.7ae1: vastake ok 128

9 0,038060 (0,0016) sun.7ae2 > svr4.nfs: 104 getattr
10 0,045821 (0,0078) svr4.nfs > sun.7ae2: vastake ok 96

11 0,050984 (0,0052) sun.7ae3 > svr4.nfs: 116 lugemine 1024 baiti @ 0
12 0,084995 (0,0340) svr4.nfs > sun.7ae3: vastake ok 1124

Lugemine

128 3,430313 (0,0013) sun.7b22 > svr4.nfs: 116 lugemine 1024 baiti @ 64512
129 3,441828 (0,0115) svr4.nfs > sun.7b22: vastake ok 1124

130 4,125031 (0,6832) p.7b23 >
131 4,868593 (0,7436) p.7b24 >

132 4,993021 (0,1244) sun.7b23 > svr4.nfs: 116 lugemine 1024 baiti @ 65536
133 5,732217 (0,7392) sun.7b24 > svr4.nfs: 116 lugemine 1024 baiti @ 73728

134 6,732084 (0,9999) sun.7b23 > svr4.nfs: 116 lugemine 1024 baiti @ 65536
135 7,472098 (0,7400) sun.7b24 > svr4.nfs: 116 lugemine 1024 baiti @ 73728

136 10,211964 (2,7399) p.7b23 >
137 10,951960 (0,7400) p.7b24 >

138 17,171767 (6,2198) sun.7b23 > svr4.nfs: 116 lugemine 1024 baiti @ 65536
139 17,911762 (0,7400) sun.7b24 > svr4.nfs: 116 lugemine 1024 baiti @ 73728

140 31.092136 (13.1804) sun.7b23 > svr4.nfs: 116 loe 1024 baiti @ 65536
141 31,831432 (0,7393) sun.7b24 > svr4.nfs: 116 lugemine 1024 baiti @ 73728

142 51,090854 (19,2594) sun.7b23 > svr4.nfs: 116 lugemine 1024 baiti @ 65536
143 51,830939 (0,7401) sun.7b24 > svr4.nfs: 116 lugemine 1024 baiti @ 73728

144 71,090305 (19,2594) sun.7b23 > svr4.nfs: 116 lugemine 1024 baiti @ 65536
145 71,830155 (0,7398) sun.7b24 > svr4.nfs: 116 lugemine 1024 baiti @ 73728

Kordusülekanded

167 291,824285 (0,7400) sun.7b24 > svr4.nfs: 116 lugemine 1024 baiti @ 73728
168 311.083676 (19.2594) sun.7b23 > svr4.nfs: 116 loe 1024 baiti @ 65536

Server taaskäivitatud

169 311,149476 (0,0658) arp, kellel on päike, ütle svr4
170 311.150004 (0.0005) arp reply sun is-at 8:0:20:3:f6:42

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

172 311,156671 (0,0018) sun.7b25 > svr4.nfs: 116 lugemine 1024 baiti @ 66560
173 311.168926 (0,0123) svr4.nfs > sun.7b25: vastake ok 1124
lugemist

Joonis 29.9 Kliendi faili lugemine, kui NFS-server katkes ja taaskäivitus.

Kliendirakendus ei saa kunagi teada, et server jooksis kokku ja taaskäivitus, välja arvatud see, et ridade 129 ja 171 vahel oli 5-minutiline paus, nii et serveri krahh on kliendi jaoks läbipaistev.

Selles näites kordusedastuse ajalõppude kestuse hindamiseks kujutage ette, et on kaks kliendideemonit, millest igaühel on oma ajalõpud. Esimese deemoni intervallid (lugemine nihkega 65536) on ligikaudu järgmised (ümardatud kahe kümnendkohani): 0,68; 0,87; 1,74; 3,48; 6,96; 13,92; 20,0; 20,0; 20.0 ja nii edasi. Teise deemoni intervallid (lugemine nihkega 73728) on täpselt samad. See tähendab, et need NFS-i kliendid kasutavad aegumistähtajaid, mis on 0,875 sekundi kordsed ja mille ülempiir on 20 sekundit. Iga ajalõpu järel kordusedastuse intervall kahekordistub: 0,875; 1,75; 3,5; 7.0 ja 14.0.

Kui kaua klient uuesti edastab? Kliendil on kaks võimalust, mis võivad seda mõjutada. Esiteks, kui serveri failisüsteem on kõvasti ühendatud, saadab klient uuesti igavesti, kuid kui serveri failisüsteem on pehmelt ühendatud, lõpetab klient proovimise pärast fikseeritud arvu kordusedastusi. Samuti on kliendil kõvaühenduse korral võimalus lubada kasutajal katkestada ebaõnnestunud kordusedastused või mitte katkestada. Kui serveri failisüsteemi paigaldamisel annab kliendi host märku, et katkestada on lubatud, ja kui me ei taha oodata 5 minutit, kuni server pärast krahhi taaskäivitub, saame kliendi töö lõpetamiseks sisestada katkestusmärgi. rakendus.

Mitu sama protseduuri

Server saab RPC-protseduure mitu korda käivitada ja need annavad siiski sama tulemuse. Näiteks NFS-i lugemisprotseduur. Nagu nägime joonisel 29.9, saadab klient lihtsalt READ-kõne uuesti välja seni, kuni saab vastuse. Meie näites oli kordusedastuse põhjuseks see, et server läks alla. Kui server ei jooksnud kokku ja RPC vastuseid sisaldavad sõnumid läksid kaotsi (kuna UDP on ebausaldusväärne protokoll), saadab klient lihtsalt uuesti ja server teeb sama READ uuesti. Sama faili sama osa loetakse uuesti ja saadetakse kliendile.

See toimib, kuna iga READ taotlus sisaldab algusnihet. Kui NFS-rutiin oleks palunud serveril lugeda faili järgmised N baiti, poleks see toiminud. Kui server poleks ükskõikne (see on ükskõiksuse pööre) ja vastus kaob ja klient väljastab järgmise N baidi jaoks uuesti READi, oleks tulemus erinev. Seetõttu on protseduuridel NFS READ ja WRITE algusnihe. Olekut säilitab klient (iga faili praegune nihe), mitte server.

Kahjuks ei saa kõiki failisüsteemi toiminguid teha mitu korda. Kujutage ette näiteks järgmisi samme: NFS-klient väljastab faili kustutamise taotluse REMOVE; NFS-server kustutab faili ja vastab OK; serveri vastus kadunud; NFS-i klient aegub ja saadab päringu uuesti; NFS-server ei leia faili ja tagastab veateate; Kliendirakendus saab veateate, mis teatab, et faili pole olemas. See tõrge tagastatakse kliendirakendusele ja see viga on vale – faili ei eksisteerinud ja see kustutati.

Järgnev on loend NFS-protseduuridest, mida saab mitu korda käivitada: GETATTR, STATFS, LOOKUP, READ, WRITE, READLINK ja READDIR. Protseduurid, mida ei saa mitu korda käivitada: CREATE, REMOVE, REMOVE, LINK, SYMLINK, MKDIR ja RMDIR. SETATTR käivitatakse tavaliselt mitu korda, välja arvatud juhul, kui seda kasutatakse faili kärpimiseks.

Kuna UDP kasutamisel võivad vastused alati kaduma minna, peab NFS-serveritel olema võimalus käsitleda toiminguid, mida ei saa mitu korda teha. Enamikul serveritel on hiljutine vastuste vahemälu, kuhu nad salvestavad selliste toimingute jaoks viimati saadud vastused. Iga kord, kui server saab päringu, vaatab ta esmalt läbi oma vahemälu ja kui leitakse vaste, tagastab NFS-protseduuri uuesti kutsumise asemel eelmise vastuse. [Juszczak 1989] kirjeldab nende vahemälutüüpide üksikasju.

Selline lähenemine serveriprotseduuridele kehtib kõigi UDP-põhiste rakenduste, mitte ainult NFS-i puhul. Näiteks DNS pakub teenust, mida saab mitu korda valutult kasutada. DNS-server võib lahendajalt päringuid teha mis tahes arv kordi, mis ei too kaasa negatiivseid tulemusi (võib-olla, välja arvatud võrguressursid hõivatud).

NFS versioon 3

1994. aastal anti välja spetsifikatsioonid NFS-protokolli 3. versiooni jaoks [Sun Microsystems 1993]. Eeldatakse, et teostused muutuvad kättesaadavaks 1994. aasta jooksul.

Siin on kokkuvõte peamistest erinevustest versioonide 2 ja 3 vahel. Viitame neile kui V2 ja V3.

1. V2 failideskriptorid on massiiv fikseeritud suurus- 32 baiti. V3-s on see muutuva suurusega massiiv, mille suurus on kuni 64 baiti. Muutuva pikkusega massiiv XDR-is on määratletud 4 baitide arvuga, millele järgneb reaalbait. See vähendab failideskriptori suurust sellistes rakendustes nagu Unix, kus on vaja ainult umbes 12 baiti, kuid võimaldab mitte-Unix-rakendustel vahetada lisateavet.
2. V2 piirab baitide arvu READ või WRITE RPC protseduuri kohta 8192 baidini. See piirang V3-s ei kehti, mis omakorda tähendab, et UDP-d kasutades on piirang ainult datagrammi IP-suurus (65535 baiti). See võimaldab kiiretes võrkudes kasutada suuri lugemis- ja kirjutamispakette.
3. READ ja WRITE protseduuride failisuurusi ja algusbaitide nihkeid on suurendatud 32 bitilt 64 bitile, mis võimaldab töötada suuremate failidega.
4. Faili atribuudid tagastatakse igas kõnes, mis võib atribuute mõjutada. See vähendab kliendi nõutavate GETATTR-kõnede arvu.
5. Kirjutamine (WRITE) võib olla asünkroonne, samas kui V2-s pidid need olema sünkroonsed. See võib parandada WRITE-protseduuri jõudlust.
6. Üks protseduur on eemaldatud (STATFS) ja seitse on lisatud: ACCESS (failiõiguste kontrollimine), MKNOD (spetsiaalse Unixi faili loomine), READDIRPLUS (kataloogis olevate failinimede tagastamine koos nende atribuutidega), FSINFO (statistilise teabe tagastamine failisüsteem ), FSSTAT (tagastab dünaamilise failisüsteemi teabe), PATHCONF (tagastab POSIX.1 failiteabe) ja COMMIT (seostab varem tehtud asünkroonsed kirjutused püsivale salvestusruumile).

Lühikesed järeldused

RPC on viis klient-serveri rakenduse loomiseks nii, et klient lihtsalt kutsub serveris olevaid protseduure. Kõik võrgu üksikasjad on peidetud kliendi ja serveri tünnidesse, mis on loodud rakenduste jaoks RPC-paketi poolt ja RPC teegi rutiinides. Näitasime RPC väljakutse- ja vastusesõnumite vormingut ning mainisime, et väärtuste kodeerimiseks kasutatakse XDR-i, mis võimaldab RPC klientidel ja serveritel töötada erineva arhitektuuriga masinates.

Üks enimkasutatavaid RPC rakendusi on Sun NFS, heterogeenne failidele juurdepääsu protokoll, mida kasutatakse laialdaselt peaaegu igas suuruses hostides. Vaatasime NFS-i ja seda, kuidas see UDP-d või TCP-d kasutab. NFS-i versiooni 2 protokollis (NFS-i versioon 2) on määratletud 15 protseduuri.

Kliendi juurdepääs NFS-serverile algab ühendamisprotokolliga, mille järel tagastatakse kliendile failikirjeldus. Seejärel pääseb klient selle failikäepideme abil juurde serveri failisüsteemis olevatele failidele. Failinimesid otsitakse serverist üks nimeelement korraga, iga elemendi jaoks tagastatakse uus failideskriptor. Lõpptulemus on faili käepide, millele juurde pääses ja mida kasutatakse järgnevaks lugemiseks ja kirjutamiseks.

NFS püüab muuta kõik oma protseduurid täitmiste arvust sõltumatuks, et klient saaks vastuse kaotsimineku korral päringu lihtsalt uuesti esitada. Oleme näinud selle näiteid juhul, kui klient luges faili samal ajal, kui server lagunes ja taaskäivitus.

Harjutused

Joonisel 29.7 nägime, et tcpdump tõlgendab pakette NFS-i päringute ja vastustena ning prindib seda tehes XID. Kas tcpdump saab seda teha kõigi RPC päringute või vastuste puhul?

Miks teie arvates kasutab RPC serveriprogramm Unixi süsteemides pigem dünaamiliselt määratud porte kui teadaolevaid?

RPC klient kutsus välja kaks serveriprotseduuri. Esimene protseduur võttis aega 5 sekundit ja teine ​​1 sekund. Kliendil on aeg 4 sekundit. Joonistage ajutine lisamise skeem mida klient ja server vahetavad. (Kujutage ette, et sõnumi edastamine kliendilt serverisse ja vastupidi ei võta aega.)

Mis juhtub joonise 29.9 näites, kui NFS-serveri töötamise ajal eemaldati selle Etherneti plaat?

Kui server taaskäivitus joonisel 29.9, töötles see päringu alates nihkest 65536 (read 168 ja 171) ning seejärel töötles järgmist päringut alates nihkest 66560 (read 172 ja 173). Mis juhtub päringuga, mis algab nihkega 73728 (rida 167)?

Kui kirjeldasime NFS-i täitmisest sõltumatuid protseduure, näitasime näidet REMOVE vastusest, mis läks võrku kaduma. Mis juhtub sel juhul, kui UDP asemel kasutatakse TCP-d?

Kui NFS-server kasutab pordi 2049 asemel dünaamiliselt määratud porti, siis mis juhtub NFS-kliendiga, kui server jookseb kokku ja taaskäivitub?

Reserveeritud pordinumbreid on väga-väga vähe (peatükk 1, jaotis Pordinumbrid), maksimaalselt 1023 hosti kohta. Kui NFS-server nõuab oma klientidel reserveeritud porte (mida ta tavaliselt teeb) ja TCP-d kasutav NFS-klient ühendab N failisüsteemi N erinevas serveris, siis kas kliendil peavad iga ühenduse jaoks olema erinevad reserveeritud pordinumbrid?

Sel hetkel peaks teie võrguga olema töötav TCP/IP-ühendus. Peaksite saama pingida teisi võrgus olevaid arvuteid ja kui olete lüüsi õigesti konfigureerinud, peaksite saama ka Internetis olevaid arvuteid pingida. Nagu teate, on arvuti võrguga ühendamise peamine eesmärk teabele juurdepääsu saamine. Kuigi mõned inimesed võivad lihtsalt arvuti võrku ühendada, soovivad enamik inimesi faile ja printereid jagada ning neile juurde pääseda. Nad sooviksid pääseda juurde Internetis olevatele dokumentidele või mängida võrgumänge. Installides oma uude Slackware süsteemi TCP/IP toe ja vajaliku tarkvara, saate selle kõik; kuid installides ainult TCP/IP toe, on funktsionaalsus väga piiratud. Anda ja saada üldine juurdepääs failidele, peame need FTP või SCP abil edasi-tagasi edastama. Meie uues Slackware arvutis ei saa me failipuud sirvida ikoonide " võrku" või "Terve võrk" Windowsi arvutitest. Soovime püsivalt juurde pääseda teiste Unixi masinate failidele.

Ideaalis tahaksime kasutada võrgu failisüsteem, mis võimaldab meil läbipaistvat juurdepääsu arvutites olevatele failidele. Programmid, mida me kasutame arvutitesse salvestatud teabega töötamiseks, ei pea tegelikult isegi teadma, millises arvutis see on salvestatud. soovitud faili. Nad peavad teadma ainult faili olemasolu ja selle hankimise viisi. Ülejäänu on juba operatsioonisüsteemi ülesanne, mis tagab juurdepääsu sellele failile olemasolevate kohalike ja võrgufailisüsteemide abil. Kaks kõige sagedamini kasutatavat võrgufailisüsteemi on SMB (rakendatud Samba kaudu) ja NFS.

5.6.1. SMB/Samba/CIFS

SMB (serveri sõnumite blokeerimine) serveri sõnumid) on vanema NetBIOS-i protokolli järeltulija, mille IBM töötas algselt välja nende LAN Manageri toote jaoks. Microsoft on omakorda alati olnud huvitatud NetBIOSist ja selle järglastest (NetBEUI, SMB ja CIFS). Samba projekt sai alguse 1991. aastal, kui see pandi pakkuma sidet IBM PC ja Unixi serveri vahel. Failide ja printimisteenuste jagamine SMB võrgu kaudu on tänapäeval valikmeetod praktiliselt kogu tsiviliseeritud maailma jaoks, kuna seda toetab ka Windows.

Samba konfiguratsioonifail /etc/samba/smb.conf on üks kõige paremini dokumenteeritud konfiguratsioonifaile, mida võite leida. Jagamisseadetega on juba valmis näited, et saaksite neid vastavalt oma vajadustele üle vaadata ja muuta. Kui vajate veelgi suuremat kontrolli, on smb.conf käsiraamatu leht teie teenistuses. Kuna Sambal on sellised hea dokumentatsioon, me ei kirjuta seda siia ümber. Käime aga peamistest punktidest kiirelt üle.

smb.conf on jagatud mitmeks osaks: üks jaotis aktsia kohta pluss üks globaalne jaotis kõikjal kasutatavate parameetrite määramiseks. Mõned parameetrid kehtivad ainult globaalses jaotises ja mõned ainult väljaspool seda. Pidage meeles, et globaalse jaotise saab tühistada mis tahes muu jaotisega. Lisateabe saamiseks vaadake juhendi lehekülgi.

Tõenäoliselt soovite muuta faili smb.conf, et see kajastaks teie seadeid. kohalik võrk. Soovitame teil muuta järgmisi üksusi:

See on teie Slackware arvuti kirjeldus, mis kuvatakse kaustas Network Neighborhood (või kogu võrk).

Peaaegu kindlasti soovite oma Slackware süsteemis kasutada kasutaja turvataset.

Kui parooli krüptimine pole lubatud, ei saa te Sambat kasutada NT4.0, Win2k, WinXP ja Win2003 süsteemidega. Windowsi operatsioonisüsteemide varasemad versioonid ei vajanud jagatud ressurssidele juurdepääsu võimaldamiseks krüptimist.

SMB on autentitud protokoll, st. saate selle teenuse kasutamiseks anda kasutajanime ja parooli. Me ütleme samba serverile, et kasutajanimed ja paroolid on õiged, kasutades käsku smbpasswd. smbpasswd võimaldab jagatud võtmeid lisada kui tavakasutajatele ja kasutajamasinad (SMB nõuab arvutite NETBIOS-nimede lisamist kasutajamasinatena, piirates sellega, millistest arvutitest saab autentida).

Oluline on märkida, et see kasutajanimi või masina nimi peab failis /etc/passwd juba olemas olema. Seda saate saavutada käsuga adduser. Pange tähele, et kui kasutate arvuti nime lisamiseks käsku adduser, peate sellele lisama dollarimärgi ("$"). Siiski see Mitte tuleb teha smbpasswd-ga töötamisel. Utiliit smbpasswd lisab dollarimärgi ise. Selle reegli rikkumine adduseriga põhjustab sambasse hostinime lisamisel tõrke.

#adduser masin$

5.6.2. Võrgu failisüsteem (NFS)

NFS-i (Network File System) kirjutas algselt Sun Solarise jaoks, nende Unixi süsteemi juurutamiseks. Ja kuigi seda on palju lihtsam seadistada ja konfigureerida kui SMB-d, on NFS palju vähem turvaline. pealik nõrk koht turvalisus on kasutaja- ja rühmaidentifikaatorite asendamise lihtsus ühes masinas teise masina identifikaatoritega. NFS-protokoll ei rakenda autentimist. On väidetud, et NFS-protokolli tulevased versioonid parandavad turvalisust, kuid selle kirjutamise ajal pole seda veel tehtud.

NFS-i konfigureeritakse faili /etc/exports kaudu. Kui laadite redaktorisse standardse /etc/exports faili, näete tühja faili, mille ülaosas on kaherealine kommentaar. Peame iga eksporditava kataloogi jaoks ekspordifaili lisama rea, mis loetleb kliendi tööjaamad, millel on sellele kataloogile juurdepääs. Näiteks kui tahame eksportida Bari tööjaama kataloogi /home/foo, peaksime faili /etc/exports lisama järgmise rea:

Nagu näete, on mitu erinevat võimalust, kuid enamik neist peaks sellest näitest selgeks saama.

NFS eeldab, et võrgu ühest masinast antud kasutajal on sama identiteet kõigis teistes masinates. Kui NFS-klient proovib lugeda või kirjutada NFS-serverisse, edastatakse UID lugemis-/kirjutuspäringu osana. Eeldatakse, et see UID on sama, kui päring oleks tehtud kohalikust masinast. Nagu näete, kui keegi saab kaugmasina ressurssidele juurdepääsul antud UID-d meelevaldselt määrata, võib halbu asju juhtuda ja juhtub. Võimalus seda osaliselt vältida on ühendada kõik kataloogid valikuga root_squash. See vastendab iga kasutaja UID-d, kes deklareerib end teise UID-ga, takistades seega juurjuurdepääsu eksporditud kataloogi failidele ja kataloogidele. Tundub, et root_squash on turvakaalutlustel vaikimisi lubatud, kuid autorid soovitavad selle siiski oma /etc/exports failis selgesõnaliselt määrata.

Samuti saate eksportida serveri kataloogi otse käsurealt, kasutades käsku exportfs, nagu allpool näidatud:

# exportfs -o rw,no_root_squash Bar:/home/foo

See käsk ekspordib /home/foo kataloogi "Bar" arvuti jaoks ja annab sellele lugemis-/kirjutamisõiguse. Lisaks ei ole NFS-serveris suvand root_squash lubatud, mis tähendab, et igal kasutajal Baril UID-ga "0" (root's UID) on serveris samad õigused kui administraatoril. Süntaks tundub üsna kummaline (tavaliselt siis, kui määrake kataloog kujul arvuti:/kataloog/fail, viitate antud arvuti kataloogis olevale failile).

Ekspordifaili kohta lisateabe saamiseks vaadake käsiraamatu lehte.

Head aega, lugejad ja külalised. Postituste vahel oli väga pikk paus, kuid olen tagasi lahingus). Tänases artiklis ma vaatan NFS-protokolli toimimine, ja NFS-serveri ja NFS-kliendi seadistamine Linuxis.

Sissejuhatus NFS-i

NFS (Võrgu failisüsteem - võrgu failisüsteem) minu arvates - ideaalne lahendus kohtvõrgus, kus kiire (SAMBA-ga võrreldes kiirem ja krüpteeritud kaugfailisüsteemidega - sshfs, SFTP jne ... vähem ressursimahukas) andmevahetus on vajalik ja ei ole esirinnas ohutus edastatud teave. NFS-protokoll lubab ühendage kaugfailisüsteemid üle võrgu kohalikku kataloogipuusse, nagu oleks see ühendatud ketta failisüsteem. Seega saavad kohalikud rakendused töötada kaugfailisüsteemiga nagu kohalikuga. Kuid peate olema ettevaatlik (!). NFS-i seadistamine, sest teatud konfiguratsiooniga saab kliendi operatsioonisüsteemi lõputut I/O-d ootama riputada. NFS-protokoll töö põhjal RPC protokoll, millest ma veel aru ei pea)), nii et artikli materjal jääb veidi ebamääraseks... Enne NFS-i kasutamist, olgu selleks server või klient, peate veenduma, et teie kernel toetab NFS-faili süsteem. Saate kontrollida, kas kernel toetab NFS-failisüsteemi, otsides failist vastavaid ridu /proc/failisüsteemid:

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

Kui failis määratud read /proc/failisüsteemid ei kuvata, siis peate installima allpool kirjeldatud paketid. See installib tõenäoliselt sõltuvad kerneli moodulid soovitud failisüsteemide toetamiseks. Kui pärast pakettide installimist NFS-i tuge ei kuvata määratud fail, siis on see vajalik selle funktsiooni kaasamisega.

Lugu Võrgu failisüsteem

NFS-protokoll on välja töötanud Sun Microsystems ja sellel on ajaloos 4 versiooni. NFSv1 töötati välja 1989. aastal ja oli eksperimentaalne, töötas UDP-protokolli kallal. Versiooni 1 on kirjeldatud . NFSv2 ilmus samal 1989. aastal, mida kirjeldas sama RFC1094 ja mis põhines ka UDP-protokollil, võimaldades samas failist lugeda mitte rohkem kui 2 GB. NFSv3 viimistletud 1995. aastal ja kirjeldatud aastal. Kolmanda versiooni peamised uuendused olid suurte failide tugi, lisatud tugi TCP-protokollile ja suurtele TCP-pakettidele, mis kiirendasid oluliselt tehnoloogia jõudlust. NFSv4 viimistletud 2000. aastal ja kirjeldatud standardis RFC 3010, muudetud 2003. aastal ja kirjeldatud aastal. Neljas versioon sisaldas jõudluse täiustusi, erinevate autentimistööriistade (eelkõige Kerberos ja LIPKEY, mis kasutavad RPCSEC GSS-protokolli) ja juurdepääsu kontrolli loendeid (nii POSIX-i kui ka Windowsi tüübid). NFS-i versioon v4.1 IESG kiitis selle heaks 2010. aastal ja sai . Oluline uuendus versioonis 4.1 on spetsifikatsioon pNFS – Parallel NFS, mehhanism NFS-kliendi paralleeljuurdepääsuks mitme hajutatud NFS-serveri andmetele. Sellise mehhanismi olemasolu võrgu failisüsteemi standardis aitab luua hajutatud "pilve" ("pilve") salvestus- ja infosüsteeme.

NFS-server

Kuna meil on NFS- See võrku failisüsteemi, vajate . (Saate lugeda ka artiklit). Järgmine on vajalik. Debianis on see pakett nfs-kernel-server Ja nfs-common, RedHatis on see pakett nfs-utils. Ja lisaks on vaja lubada deemoni käivitamine OS-i nõutavatel käitamistasemetel (RedHati käsk on /sbin/chkconfig nfs sees, Debianis - /usr/sbin/update-rc.d nfs-kernel-server vaikesätted).

Debiani installitud pakette käivitatakse järgmises järjekorras:

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

See tähendab, esimene jooks nfs-common, siis server ise nfs-kernel-server. RedHati puhul on olukord sarnane, ainsa erandiga, et kutsutakse välja esimene skript nfslock, ja serverit kutsutakse lihtsalt nfs. Pro nfs-common Debiani sait ütleb meile sõna otseses mõttes järgmist: jagatud failid NFS-kliendi ja -serveri jaoks peab see pakett olema installitud masinasse, mis toimib NFS-kliendi või -serverina. Pakett sisaldab programme: lockd, statd, showmount, nfsstat, gssd ja idmapd. Käivitusskripti sisu vaatamisega /etc/init.d/nfs-common saab jälgida järgmine jada töö: skript kontrollib käivitatava binaarfaili olemasolu /sbin/rpc.statd, kontrollib olemasolu failides /etc/default/nfs-common, /etc/fstab Ja /etc/exports valikud, mis nõuavad deemonite käivitamist idmapd Ja gssd , käivitab deemoni /sbin/rpc.statd , siis enne käivitamist /usr/sbin/rpc.idmapd Ja /usr/sbin/rpc.gssd kontrollib nende käivitatavate failide olemasolu binaarfailid, siis jaoks deemon /usr/sbin/rpc.idmapd kontrollib saadavust sunrpc, nfs Ja nfsd, samuti failisüsteemi tugi rpc_pipefs kernelis (st selle olemasolu failis /proc/failisüsteemid), kui kõik õnnestub, käivitub see /usr/sbin/rpc.idmapd . Lisaks deemonile /usr/sbin/rpc.gssd kontrollid rpcsec_gss_krb5 kerneli moodul ja käivitab deemoni.

Kui vaatate sisu NFS-serveri käivitusskript Debianis ( /etc/init.d/nfs-kernel-server), siis saab jälgida järgmist jada: käivitamisel kontrollib skript faili olemasolu /etc/exports, Saadavus nfsd, toe kättesaadavus NFS-failisüsteem sisse (st failis /proc/failisüsteemid), kui kõik on paigas, siis deemon käivitub /usr/sbin/rpc.nfsd , seejärel kontrollib, kas parameeter on seatud NEED_SVCGSSD(seatud serveri seadete failis /etc/default/nfs-kernel-server) ja kui see on antud, käivitab deemoni /usr/sbin/rpc.svcgssd , viimane deemoni käivitamiseks /usr/sbin/rpc.mountd . See skript näitab seda NFS-serveri töö koosneb deemonid rpc.nfsd, rpc.mountd ja kui kasutatakse Kerberose autentimist, siis deemon rcp.svcgssd. Rpc.rquotad ja nfslogd deemonid töötavad endiselt punase mütsiga (millegipärast ei leidnud ma Debianist teavet selle deemoni ja selle puudumise põhjuste kohta, ilmselt eemaldatud ...).

Sellest selgub, et Võrgu failisüsteemi server koosneb järgmistest protsessidest (loe - deemonid) asub kataloogides /sbin ja /usr/sbin:

NFSv4-s käivitatakse Kerberose kasutamisel täiendavalt deemonid:

• rpc.gssd- NFSv4 deemon pakub autentimismeetodeid GSS-API (Kerberose autentimine) kaudu. Töötab kliendis ja serveris.
• rpc.svcgssd- NFSv4 serverideemon, mis pakub serveripoolset kliendi autentimist.

pordikaart ja RPC-protokoll (Päikese RPC)

Lisaks ülaltoodud pakettidele, jaoks õige toimimine NFSv2 ja v3 nõuavad lisapaketti pordikaart(uuemates distributsioonides asendatakse nimega ümbernimetatud rpcbind). Praegune pakett installitakse tavaliselt automaatselt sõltuva NFS-iga ja rakendab RPC-serveri tööd, st vastutab mõne RPC-serveris registreeritud teenuse dünaamilise pordi määramise eest. Sõna otseses mõttes on dokumentatsiooni kohaselt tegemist serveriga, mis teisendab RPC (Remote Procedure Call) programminumbrid TCP / UDP pordinumbriteks. portmap töötab mitme üksuse peal: RPC kõned või päringud, TCP/UDP pordid,protokolli versioon(tcp või udp), programmi numbrid Ja tarkvara versioonid. Portmap deemoni käivitab /etc/init.d/portmap skript enne NFS-teenuste käivitamist.

Lühidalt öeldes on RPC (Remote Procedure Call) serveri ülesanne töödelda kohalikest ja kaugprotsessidest pärinevaid RPC-kõnesid (nn RPC-protseduure). RPC-kõnesid kasutades registreerivad teenused või kustutavad end pordi kaardistajasse (aka portmapper, aka portmap, aka portmapper, aka, uutes versioonides rpcbind) ning RPC-kõnesid kasutavad kliendid saavad vajaliku teabe otse päringud portmapperile. Kasutajasõbralikud programmiteenuste nimed ja nende vastavad numbrid on määratletud failis /etc/rpc. Niipea kui mõni teenus on saatnud vastava päringu ja registreerinud end pordi kaardistaja RPC-serveris, määrab RPC-server TCP- ja UDP-teenusele pordid, millest teenus käivitus, ning salvestab kernelisse vastava teabe töötava teenuse kohta. (nime kohta), kordumatu numbriteenus (vastavalt failile /etc/rpc), protokoll ja port, millel teenus töötab, ja teenuse versioon ning esitab klientidele nõudmisel täpsustatud teabe. Portresolveril endal on programmi number (100000), versiooni number 2, TCP port 111 ja UDP port 111. Eespool NFS-i serveri deemonite koostise täpsustamisel märkisin ära peamised RPC programmide numbrid. Tõenäoliselt ajasin teid selle lõiguga veidi segadusse, seega ütlen põhifraasi, mis peaks selgitama: pordi kaardistaja põhifunktsioon on tagastada talle (kliendile) port, millel soovitud programm töötab. Seega, kui kliendil on vaja RPC-ga ühendust võtta konkreetse programminumbriga, peab ta esmalt võtma ühendust serverimasina pordikaardi protsessiga ja määrama pordi numbri, et suhelda vajaliku RPC-teenusega.

RPC-serveri tööd saab kujutada järgmiste sammudega:

1. Pordilahendaja peaks kõigepealt käivituma, tavaliselt siis, kui süsteem käivitub. See loob TCP-lõpp-punkti ja avab TCP-pordi 111. See loob ka UDP-lõpp-punkti, mis ootab UDP-datagrammi saabumist UDP-porti 111.
2. Käivitamisel loob RPC-serveri kaudu töötav programm iga toetatud programmi versiooni jaoks TCP-lõpp-punkti ja UDP-lõpp-punkti. (RPC-server võib toetada mitut versiooni. Klient määrab vajaliku versiooni RPC-kõne tegemisel.) Teenuse igale versioonile määratakse dünaamiliselt määratud pordinumber. Server registreerib iga programmi, versiooni, protokolli ja pordi numbri, tehes vastava RPC-kõne.
3. Kui RPC-klientprogramm peab hankima vajalikku teavet, käivitab see pordilahendaja protseduuri, et saada antud programmile, versioonile ja protokollile dünaamiliselt määratud pordinumber.
4. Vastuseks sellele päringule tagastab server pordi numbri.
5. Klient saadab sammus 4 saadud pordinumbrile RPC Request sõnumi. Kui kasutatakse UDP-d, saadab klient lihtsalt RPC Call sõnumit sisaldava UDP datagrammi UDP pordinumbrile, millel taotletud teenus töötab. Vastuseks saadab teenus UDP-datagrammi, mis sisaldab RPC-vastussõnumit. Kui kasutatakse TCP-d, avab klient aktiivselt soovitud teenuse TCP-pordi numbri ja saadab seejärel loodud ühenduse kaudu RPC väljakutseteate. Server vastab ühenduse kaudu RPC vastusesõnumiga.

RPC-serverist teabe hankimiseks kasutage utiliiti rpcinfo. Parameetrite määramisel -p peremees programm loetleb kõik hostis registreeritud RPC-programmid. Ilma hosti määramata kuvab programm teenuseid localhostis. Näide:

Archiv ~ # rpcinfo -p прог -ма верс перотlot порт 100000 2 TCP 111 PortMapper 100000 2 UDP 111 PORTMAPPER 100024 1 UDP 59451 staatus 100024 1000241011 4411 4410 100024131313. 44851 nlockmgr 100021 3 TCP 44851 Nlockmgr 100021 4 TCP 44851 NLOCKMGR 100003 2 TCP 2049 NFS 100003 3 TCP 2049 NFS 100003 4 TCP 2043 1 UDP 2033 333 333 333 333 335 335 4 41405 mountd 100005 2 udp 51306 mountd 100005 2 tcp 41405 mountd 100005 3 udp 51306 mountd 100005 3 tcp 41405 mountd

Nagu näete, kuvab rpcinfo (veerudes vasakult paremale) registreeritud programmi numbri, versiooni, protokolli, pordi ja nime. Rpcinfo abil saate eemaldada programmi registreerimise või hankida teavet konkreetse RPC teenuse kohta (rohkem valikuid on man rpcinfos). Nagu näete, portmapperi deemonite versioon 2 udp ja tcp portidel, rpc.statd versioon 1 deemonid udp ja tcp portidel, NFS-i lukuhalduri versioonid 1,3,4, nfs-serveri deemoni versioon 2,3,4, samuti mount deemon on registreeritud versioonid 1,2,3.

NFS-server (täpsemalt rpc.nfsd deemon) võtab kliendilt päringuid vastu UDP-datagrammide kujul pordis 2049. Kuigi NFS töötab pordi lahendajaga, mis võimaldab serveril kasutada dünaamiliselt määratud porte, on UDP port 2049 juhtmega ühendatud NFS-iga enamikus rakendustes.

Võrgu failisüsteemi protokolli kasutamine

NFS-i kaugkinnitus

Kaug-NFS-failisüsteemi paigaldamise protsessi saab kujutada järgmiselt:

NFS-protokolli kirjeldus kaugkataloogi paigaldamisel:

1. RPC-server käivitatakse serveris ja kliendis (tavaliselt alglaadimisel), mida haldab portmapper protsess ja registreeritakse tcp/111 ja udp/111 portides.
2. Käivitatakse teenused (rpc.nfsd, rpc.statd jne), mis registreerivad end RPC-serveris ja registreerivad end suvalistes võrguportides (kui teenuse seadetes pole staatilist porti määratud).
3. klientarvuti mount käsk saadab kernelile võrgukataloogi ühendamise taotluse, mis näitab failisüsteemi tüüpi, hosti ja kataloogi ennast, kernel saadab RPC päringu udp/111 NFS-serveris olevale portmap protsessile. port (kui tcp-ga töötamise võimalus pole kliendil määratud)
4. NFS-serveri tuum küsib RPC-lt deemoni rpc.mountd olemasolu ja tagastab kliendituumale võrgupordi, millel deemon töötab.
5. mount saadab RPC päringu porti, kus rpc.mountd töötab. NFS-server saab nüüd klienti kinnitada selle IP-aadressi ja pordi numbri alusel, et näha, kas klient saab määratud failisüsteemi ühendada.
6. Ühendusdeemon tagastab soovitud failisüsteemi kirjelduse.
7. Kliendi mount käsk väljastab mount süsteemikutse, et seostada toimingus 5 saadud failideskriptor kliendi hosti kohaliku ühenduspunktiga. Faili deskriptor salvestatakse kliendi NFS-koodi ja sellest ajast alates kasutavad kõik serveri failisüsteemi failidele juurdepääsu töötlevad kasutajad lähtepunktina failideskriptorit.

Side kliendi ja NFS-serveri vahel

Tüüpilist juurdepääsu kaugfailisüsteemile saab kirjeldada järgmiselt.

NFS-serveris asuvale failile juurdepääsu protsessi kirjeldus:

1. Klient (kasutajaprotsess) ei hooli sellest, kas ta pääseb juurde kohalikule failile või NFS-failile. Kernel tegeleb riistvaraga suhtlemisega kerneli moodulite või sisseehitatud süsteemikutsete kaudu.
2. kerneli moodul kernel/fs/nfs/nfs.ko, mis toimib NFS-kliendina, saadab RPC-päringuid NFS-serverisse TCP/IP-mooduli kaudu. NFS kasutab tavaliselt UDP-d, kuid uuemad rakendused võivad kasutada TCP-d.
3. NFS-server võtab kliendilt päringuid vastu UDP-datagrammide kujul pordis 2049. Kuigi NFS võib töötada pordilahendajaga, mis võimaldab serveril kasutada dünaamiliselt määratud porte, on UDP-port 2049 enamikus rakendustes NFS-iga ühendatud.
4. Kui NFS-server saab kliendilt päringu, edastatakse see kohalikule failijuurdepääsurutiinile, mis tagab juurdepääsu serveri kohalikule kettale.
5. Kettale juurdepääsu tulemus tagastatakse kliendile.

NFS-serveri seadistamine

Serveri häälestamineüldiselt on määrata kohalikud kataloogid, mida kaugsüsteemidel on lubatud failis ühendada /etc/exports. Seda toimingut nimetatakse kataloogi hierarhia eksport. Peamised teabeallikad eksporditud kataloogide kohta on järgmised failid:

• /etc/exports- peamine konfiguratsioonifail, mis salvestab eksporditud kataloogide konfiguratsiooni. Kasutatakse NFS-i käivitamisel ja utiliidi exportfs kasutamisel.
• /var/lib/nfs/xtab- sisaldab kaugklientide paigaldatud kataloogide loendit. Kasutab deemon rpc.mountd, kui klient üritab hierarhiat ühendada (loodi ühendamise kirje).
• /var/lib/nfs/etab- kaugsüsteemidega ühendatavate kataloogide loend, mis näitab eksporditud kataloogide kõiki parameetreid.
• /var/lib/nfs/rmtab- nimekiri kataloogidest, mida praegu ei ekspordita.
• /proc/fs/nfsd- spetsiaalne failisüsteem (kernel 2.6) NFS-serveri haldamiseks.
  • eksporti- aktiivsete eksporditud hierarhiate ja klientide loend, kellele need eksporditi, samuti parameetrid. Kernel võtab vastu see informatsioon failist /var/lib/nfs/xtab.
  • niidid- sisaldab lõimede arvu (saab ka muuta)
  • failikäepideme abil saate failile viida
  • ja jne...
• /proc/net/rpc- sisaldab "toores" (toores) statistikat, mida saab hankida nfsstat'i abil, samuti erinevaid vahemälu.
• /var/run/portmap_mapping- teave RPC-s registreeritud teenuste kohta

Märge: Üldiselt on Internetis palju tõlgendusi ja sõnastusi xtab, etab, rmtab failide eesmärgi kohta, ma ei tea, keda uskuda Isegi http://nfs.sourceforge.net/ tõlgendus pole üheselt mõistetav .

Faili /etc/exports seadistamine

Lihtsamal juhul on /etc/exports ainus fail, mida tuleb NFS-serveri seadistamiseks redigeerida. See fail juhib järgmisi aspekte.

• Millised kliendid pääseb juurde serveris olevatele failidele
• Millised hierarhiad? serveri kataloogidele pääseb juurde iga klient
• Kuidas kohandatud klientide nimed toimivad kuvatakse kohalikele kasutajanimedele

Ekspordifaili igal real on järgmine vorming:

exportpoint klient1(valikud) [klient2(valikud) ...]

Kus ekspordi_punkt absoluutne tee eksporditud kataloogi hierarhia, klient1 - n ühe või mitme kliendi või IP-aadressi nimi, mis on eraldatud tühikutega ja mida on lubatud ühendada ekspordi_punkt . Valikud kirjeldage paigaldamise reegleid klient enne valikuid .

Siin on tüüpiline ekspordifaili konfiguratsiooni näide:

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

Selles näites on arvutifailidel ja 10.0.0.1-l juurdepääs /archiv1 ekspordipunktile, samal ajal kui failide hostil on lugemis-/kirjutamisvõimalus ning hosti 10.0.0.1 ja alamvõrk 10.0.230.1/24 on kirjutuskaitstud.

Hostikirjeldused failis /etc/exports on lubatud järgmises vormingus:

• Üksikute sõlmede nimesid kirjeldatakse failidena või failidena.DOMAIN.local.
• Domeeni maski kirjeldus on tehtud järgmises vormingus: *DOMAIN.local hõlmab kõiki domeeni DOMAIN.local sõlmi.
• Alamvõrgud on määratud IP-aadressi/maski paaridena. Näiteks: 10.0.0.0/255.255.255.0 hõlmab kõiki hoste, mille aadressid algavad numbriga 10.0.0.
• Ressursile juurdepääsu omava võrgurühma nime @myclients määramine (NIS-serveri kasutamisel)

Kataloogihierarhiate üldised ekspordivalikud

Ekspordifail kasutab järgmist üldised valikud (Esiteks on näidatud enamikus süsteemides vaikimisi kasutatavad valikud, mittevaikeväärtused sulgudes):

• auth_nlm (no_auth_nlm) või turvalised_lukud (ebaturvalised_lukud)- määrab, et server peaks nõudma lukustustaotluste autentimist (kasutades NFS Lock Manageri protokolli).
• peita (peida)- kui server ekspordib kaks kataloogihierarhiat, millest üks on pesastatud (ühendatud) teise sisse. Klient peab selgesõnaliselt ühendama teise (alam)hierarhia, vastasel juhul kuvatakse alamhierarhia ühenduspunkt tühja kataloogina. Suvand nohide annab tulemuseks teise kataloogihierarhia ilma selgesõnalise ühendamiseta. ( Märge: Ma ei saanud seda võimalust tööle panna...
• ro(rw)- Lubab ainult lugeda (kirjutada) taotlusi. (Lõppkokkuvõttes määratakse failisüsteemi õiguste põhjal, kas lugemine/kirjutamine on võimalik või mitte .)
• turvaline (ebaturvaline)- nõuab, et NFS-i päringud tuleksid turvalistest portidest (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• alampuu_kontroll (no_subtree_check)- Kui eksporditakse failisüsteemi alamkataloog, kuid mitte kogu failisüsteem, kontrollib server, kas taotletud fail on eksporditud alamkataloogis. Kinnitamise keelamine vähendab turvalisust, kuid suurendab andmeedastuskiirust.
• sünkroonimine (asünkroonimine) Määrab, et server peaks päringutele vastama alles pärast seda, kui nende päringutega tehtud muudatused on kettale kirjutatud. Asünkroonimisvalik käsib serveril mitte oodata teabe kettale kirjutamist, mis parandab jõudlust, kuid vähendab töökindlust. Ühenduse katkemisel või seadme rikke korral on võimalik teabe kadu.
• wdelay (no_wdelay)- annab serverile korralduse viivitada kirjutamistaotluste täitmist, kui järgmine kirjutamistaotlus on ootel, kirjutades andmed suuremate plokkidena. See parandab jõudlust suurte kirjutamiskäskude järjekordade saatmisel. no_wdelay määrab kirjutuskäsu täitmist mitte edasi lükkama, mis võib olla kasulik, kui server saab suure hulga käske, mis ei ole omavahel seotud.

Ekspordi sümboolsed lingid ja seadme failid. Sümboolseid linke sisaldavate kataloogide hierarhia eksportimisel peab lingiobjekt olema kliendi (kaug)süsteemile kättesaadav, st üks järgmistest reeglitest peab olema tõene:

Seadme fail viitab liidesele. Seadme faili eksportimisel eksporditakse see liides. Kui klientsüsteemis pole sama tüüpi seadet, siis eksporditud seade ei tööta. Kliendisüsteemis saab NFS-objektide paigaldamisel kasutada suvandit nodev, et ühendatud kataloogides olevaid seadmefaile ei kasutata.

Vaikevalikud sisse erinevad süsteemid võivad erineda, leiate need failist /var/lib/nfs/etab. Pärast eksporditud kataloogi kirjeldamist failis /etc/exports ja NFS-serveri taaskäivitamist kajastuvad kõik puuduvad suvandid (loe: vaikesuvandid) failis /var/lib/nfs/etab.

Kasutaja ID-de kuvamisvalikud

Järgneva paremaks mõistmiseks soovitan teil artiklit lugeda. Igal Linuxi kasutajal on oma UID ja peamine GID, mida kirjeldatakse failides /etc/passwd Ja /etc/group. NFS-server usub, et kaughosti operatsioonisüsteem on kasutajad autentinud ja määranud neile õige UID ja GID. Failide eksportimine annab kliendisüsteemi kasutajatele nendele failidele sama juurdepääsu, nagu nad logiksid otse serverisse sisse. Seega, kui NFS-klient saadab serverile päringu, kasutab server kohalikus süsteemis kasutaja tuvastamiseks UID-d ja GID-d, mis võib põhjustada mõningaid probleeme:

• kasutajal ei pruugi mõlemas süsteemis olla sama identiteet ja seega võib tal olla juurdepääs teise kasutaja failidele.
• sest Kuna juurkasutaja ID on alati 0, seostatakse see kasutaja sõltuvalt määratud suvanditest kohaliku kasutajaga.

Järgmised valikud määravad reeglid kaugkasutajate kuvamiseks kohalikes kasutajates:

• root_squash (no_root_squash)- Valikukomplektiga root_squash, vastendatakse juurkasutaja päringud anonüümsesse uid/gid või parameetris anonuid/anongid määratud kasutajaga.
• no_all_squash (all_squash)- Ei muuda ühendava kasutaja UID/GID-d. Võimalus kõik_squash määrab KÕIK kasutajad (mitte ainult root) kuvamiseks anonüümsetena või anonüümsena või anonüümsena/anongidi parameetris määratud.
• anonuid= UID Ja anongid= GID - Määrab anonüümse kasutaja UID/GID selgesõnaliselt.
• map_static= /etc/file_maps_users - Määrab faili, mida saab kasutada kaug-UID/GID-de vastendamiseks kohalikele UID-dele/GID-dele.

Näide kasutaja vastendusfaili kasutamisest:

ARCHIV ~ # kass /etc/file_maps_users # Mapping users # remote local comment uid 0-50 1002 # kaug-UID-ga 0-50 kasutajate vastendamine kohalikule UID-le 1002 gid 0-50 1002 # kasutajate vastendamine kaug-GID-ga 0-50 kohalikule GID 1002-le

NFS-i serverihaldus

NFS-serverit hallatakse järgmiste utiliitide abil:

• nfsstat
• näitab turvalist (ebaturvalist) hulka

nfsstat: NFS- ja RPC-statistika

Utiliit nfsstat võimaldab teil vaadata RPC- ja NFS-serverite statistikat. Käsuvalikud leiate failist man nfsstat.

showmount: kuvab NFS-i olekuteavet

showmount utiliit küsib ühendatud failisüsteemide jaoks kaughosti deemonit rpc.mountd. Vaikimisi tagastatakse klientide sorteeritud loend. Klahvid:

• --kõik- antakse klientide ja ühenduspunktide loend, mis näitab, kuhu klient kataloogi ühendas. See teave ei pruugi olla usaldusväärne.
• --kataloogid- kinnituspunktide loend
• -- eksport- on antud eksporditud failisüsteemide loend nfsd seisukohast

Showmounti käivitamisel argumentideta prinditakse konsooli teave süsteemide kohta, millel on lubatud ühendada kohalik kataloogid. Näiteks pakub host ARCHIV meile nimekirja eksporditud kataloogidest koos nende hostide IP-aadressidega, millel on lubatud määratud kataloogid ühendada:

FAILID ~ # showmount -- ekspordib arhiivi Ekspordi loend arhiivi jaoks: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

Kui määrate argumendis hostinime / IP, kuvatakse teave selle hosti kohta:

ARCHIV ~ # showmount failid clnt_create: RPC: Programm pole registreeritud # antud sõnumütleb meile, et NFSd deemon ei tööta hostis FILES

exportfs: eksporditud kataloogide haldamine

See käsk teenindab failis määratud eksporditud katalooge /etc/exports, oleks täpsem kirjutada ei teeninda, vaid sünkroonib failiga /var/lib/nfs/xtab ja eemaldab xtabist olematud. exportfs käivitatakse, kui nfsd deemon käivitatakse argumendiga -r. Kerneli režiimis 2.6 olev utiliit exportfs suhtleb deemoniga rpc.mountd kataloogis /var/lib/nfs/ olevate failide kaudu ja ei räägi otse kerneliga. Ilma parameetriteta tagastab praegu eksporditud failisüsteemide loendi.

exportfsi valikud:

• [klient:katalooginimi] – lisage või eemaldage määratud kliendi jaoks määratud failisüsteem)
• -v - kuvab rohkem teavet
• -r - kõigi kataloogide uuesti eksportimine (sünkrooni /etc/exports ja /var/lib/nfs/xtab)
• -u - eemaldage ekspordiloendist
• -a - kõigi failisüsteemide lisamine või eemaldamine
• -o - komadega eraldatud võtmed (sarnaselt failis /etc/exports kasutatavatele võtmetele; seega saate muuta juba ühendatud failisüsteemide valikuid)
• -i - ärge kasutage lisamisel /etc/exports, vaid ainult praeguse käsurea suvandid
• -f - lähtestatakse 2.6 tuumas eksporditud süsteemide loend;

NFS klient

Enne kaugfailisüsteemis olevale failile juurde pääsemist peab klient (kliendi OS) seda tegema paigalda see ja saada serverist osuti sellele. NFS-kinnitus saab teha ühe viljaka automaatse monteerijaga (amd, autofs, automount, supermount, superpupermount) või selle abil. Paigaldusprotsess on hästi näidatud ülaltoodud joonisel.

Peal NFS-i kliendidühtegi deemonit pole vaja käivitada, kliendi funktsioonid käivitab kerneli mooduli kernel/fs/nfs/nfs.ko, mida kasutatakse kaugfailisüsteemi paigaldamisel. Serverist eksporditud katalooge saab kliendile paigaldada järgmistel viisidel:

• käsitsi, kasutades käsku mount
• automaatselt alglaadimisel, kui ühendate failisüsteeme, mida on kirjeldatud failis /etc/fstab
• automaatselt autofsi deemoniga

Ma ei käsitle selles artiklis kolmandat autofs-meetodit selle mahuka teabe tõttu. Võib-olla on järgmistes artiklites eraldi kirjeldus.

Võrgufailide süsteemi ühendamine käsuga mount

Näide käsu mount kasutamisest on toodud postituses. Siin vaatan näidet NFS-failisüsteemi paigaldamise käsust mount:

FAILID ~ # mount -t nfs arhiiv:/archiv-small /archivs/archiv-small FILES ~ # mount -t nfs -o ro arhiiv:/archiv-big /archivs/archiv-big FILES ~ # mount ..... .. arhiiv:/archiv-small /archivs/archiv-small type nfs (rw,addr=10.0.0.6) arhiiv:/archiv-big /archivs/archiv-big tüüpi nfs (ro,addr=10.0.0.6)

Esimene käsk ühendab eksporditud kataloogi /arhiiv-väike serveris arhiiv kohalikku kinnituspunkti /archivs/archiv-small vaikevalikutega (st lugemine ja kirjutamine). Kuigi mount käsk viimastes distributsioonides saab aru, mis tüüpi failisüsteemi kasutatakse ka ilma tüüpi määramata, määrake ikkagi parameeter -tnfs soovitav. Teine käsk ühendab eksporditud kataloogi /arhiiv-suur serveris arhiiv kohalikku kataloogi /archivs/archiv-big kirjutuskaitstud valikuga ( ro). mount käsk ilma parameetriteta kuvab selgelt kinnituse tulemuse. Lisaks kirjutuskaitstud valikule (ro) on võimalik määrata ka muud põhilised NFS-i paigaldusvalikud:

• nosuid - See valik keelab programmide täitmise ühendatud kataloogist.
• nodev(seade puudub) – see suvand keelab tähemärgid ja blokeerib erifailid seadmetena.
• lukk (lukuta)- Lubab NFS-lukustuse (vaikimisi). nolock keelab NFS-i lukustamise (ei käivita lukustatud deemonit) ja on kasulik vanemate serveritega, mis NFS-i lukustamist ei toeta.
• mounthost=nimi- NFS-i ühendamise deemonit käivitava hosti nimi on mountd.
• mountport=n - Port, mida mountd deemon kasutab.
• port = n- NFS-serveriga ühenduse loomiseks kasutatav port (vaikimisi on 2049, kui rpc.nfsd deemon pole RPC-serveris registreeritud). Kui n = 0 (vaikeseade), saadab NFS serveri pordi kaardile päringu pordi määramiseks.
• suurus=n(lugemisploki suurus – lugemisploki suurus) – NFS-serverist korraga loetud baitide arv. Vaikimisi on 4096.
• wsize=n(kirjutusploki suurus – kirjutusploki suurus) – NFS-serverisse korraga kirjutatud baitide arv. Vaikimisi on 4096.
• tcp või udp- NFS-i ühendamiseks kasutage vastavalt TCP-d või UDP-d.
• bg- Kui kaotate juurdepääsu serverile, proovige taustal uuesti, et mitte blokeerida süsteemi alglaadimisprotsessi.
• fg- Kui kaotate juurdepääsu serverile, proovige prioriteetrežiimis uuesti. See suvand võib blokeerida süsteemi alglaadimisprotsessi, proovides uuesti ühendada. Sel põhjusel kasutatakse suvandit fg peamiselt silumiseks.

Suvandid, mis mõjutavad atribuutide vahemällu salvestamist NFS-ühendustel

Faili atribuudid, mis on salvestatud (inoodidesse), nagu muutmise aeg, suurus, kõvad lingid, omanik, muutuvad tavaliste failide puhul tavaliselt harva ja kataloogide puhul veelgi harvemini. Paljud programmid, näiteks ls, pääsevad juurde kirjutuskaitstud failidele ega muuda faili atribuute ega sisu, vaid raiskavad süsteemiressursse kallitele võrgutoimingutele. Ressursside raiskamise vältimiseks saate seda teha vahemälu andmete atribuudid. Kernel kasutab faili muutmisaega, et teha kindlaks, kas vahemälu on aegunud, võrreldes vahemälus oleva muutmisaega ja faili enda muutmisaega. Atribuudi vahemälu värskendatakse perioodiliselt vastavalt määratud parameetritele:

• ac (noac) (atribuudi vahemälu- atribuudi vahemällu salvestamine) - atribuudi vahemälu lubamine (vaikimisi). Kuigi suvand noac aeglustab serveri tööd, väldib see atribuutide vananemist, kui mitu klienti kirjutavad aktiivselt teavet ühisesse hierarhiasse.
• acdirmax=n (atribuudi vahemälu kataloogifaili maksimum- kataloogifaili atribuudi vahemällu salvestamise maksimum) - Maksimaalne sekundite arv, mille NFS ootab enne kataloogiatribuutide värskendamist (vaikimisi 60 sek.)
• acdirmin=n (atribuudi vahemälu kataloogifaili miinimum- minimaalne atribuutide vahemällu salvestamine kataloogifaili jaoks) - minimaalne sekundite arv, mis NFS ootab enne kataloogiatribuutide värskendamist (vaikimisi 30 sekundit)
• accregmax=n (atribuudi vahemälu tavafaili maksimum- atribuutide vahemällu salvestamine tavalise faili puhul) - Maksimaalne sekundite arv, mille NFS ootab enne tavalise faili atribuutide värskendamist (vaikimisi 60 sekundit)
• aregmin=n (atribuudi vahemälu tavalise faili miinimum- tavafaili minimaalne atribuutide vahemällu salvestamine) - minimaalne arv sekundeid, mida NFS ootab enne tavalise faili atribuutide värskendamist (vaikimisi 3 sekundit)
• actimeo=n (atribuudi vahemälu ajalõpp- atribuudi vahemällu salvestamise ajalõpp) - alistab kõigi ülaltoodud valikute väärtused. Kui actimeo pole määratud, on ülaltoodud väärtused vaikeväärtused.

NFS-i veakäsitluse valikud

Järgmised suvandid määravad, mida NFS teeb, kui serverilt ei tule vastust või ilmnevad sisend-/väljundtõrked.

• fg (bg) (esiplaanil- esiplaan, taustal- taust) – katse ühendada ebaõnnestunud NFS esiplaanile/taustale.
• kõva pehme)- prindib ajalõpu saabudes konsooli teate "server ei reageeri" ja jätkab ühendamiskatseid. Antud valikuga pehme- on timeout teavitab toimingu kutsunud programmi I/O veast. (pehmet varianti ei soovitata kasutada)
• nointr(intr) (ei katkestata- ära katkesta) - ei luba signaalidel katkestada failitoimingud kõvasti ühendatud kataloogihierarhias, kui on saavutatud suur ajalõpp. intr- lubage katkestus.
• retrans=n (taasedastuse väärtus- kordusedastuse väärtus) - Pärast n väikest ajalõpu genereerib NFS suure ajalõpu (vaikimisi 3). Suur ajalõpp lõpetab toimingud või prindib konsoolile teate "server ei reageeri", olenevalt määratud kõva/pehme suvandist.
• proovi uuesti=n (proovi väärtust uuesti- uuesti proovimise väärtus) - NFS-i uuesti proovimise minutite arv enne loobumist (vaikimisi 10000).
• timeo=n (ajalõpu väärtus- ajalõpu väärtus) – sekundikümnendiku arv, mille NFS-teenus ootab enne uuesti saatmist RPC või väikese ajalõpu korral (vaikimisi 7). Seda väärtust suurendatakse iga ajalõpu korral kuni maksimaalse väärtuseni 60 sekundit või kuni suure ajalõpuni. Kui võrk on hõivatud, server on aeglane või päring läbib mitut ruuterit või lüüsi, võib selle väärtuse suurendamine jõudlust parandada.

Automaatne NFS-i ühendamine alglaadimisel (failisüsteemide kirjeldus failis /etc/fstab)

Saate valida edastatava paketi konkreetse väärtuse jaoks optimaalse aja (rsize / wsize väärtused), kasutades ping-käsku:

FAILID ~ # ping -s 32768 arhiiv PING arhiiv.DOMAIN.local (10.0.0.6) 32768(32796) baiti andmeid. 32776 baiti domeenist archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0.931 ms alates archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03main 6tes .277 ms .local (10.0.0.6): icmp_req=5 ttl=64 aeg=1,08 ms ^C --- arhiiv.DOMAIN.kohalik ping-statistika --- 5 paketti edastatud, 5 vastu võetud, paketikadu 0%, aeg 4006 ms rtt min/ avg/max/mdev = 0,931/1,002/1,083/0,061 ms

Nagu näete, hõljub 32768 (32Kb) suuruse paketi saatmisel selle reisiaeg kliendilt serverisse ja tagasi umbes 1 millisekund. Kui see aeg läheb skaalalt 200 ms võrra maha, siis peaksite mõtlema timeo väärtuse suurendamisele, et see ületaks vahetusväärtust kolm kuni neli korda. Seetõttu on soovitatav seda testi teha suure võrgukoormuse ajal.

NFS-i käivitamine ja tulemüüri konfigureerimine

Märkus on kopeeritud blogist http://bog.pp.ru/work/NFS.html, mille eest suur tänu talle!!!

Käivitage NFS-server, ühendage, lukustage, kvoot ja olek "õigete" portidega (tulemüüri jaoks)

• Soovitav on kõik klientide ressursid eelnevalt lahti ühendada
• peatada ja keelata rpcidmapd käivitumine, kui NFSv4 pole planeeritud: chkconfig -- tase 345 rpcidmapd teenuse väljas rpcidmapd stop
• vajadusel luba portmap, nfs ja nfslock teenuste käivitamine: chkconfig --levels 345 portmap/rpcbind chkconfigis --levels 345 nfs chkconfigis --levels 345 nfslock sees
• vajadusel peatage nfslock ja nfs teenused, käivitage portmap/rpcbind, laadige moodulid maha service nfslock stop service nfs stop service portmap start # service rpcbind start umount /proc/fs/nfsd service rpcidmapd stop rmmod nfsd service autofs stop # kusagil hiljem peate käivitama see rmmod nfs rmmod nfs_acl rmmod lukus
• avage pordid sisse
  • RPC jaoks: UDP/111, TCP/111
  • NFS-i jaoks: UDP/2049, TCP/2049
  • rpc.statd jaoks: UDP/4000, TCP/4000
  • lukustatud jaoks: UDP/4001, TCP/4001
  • monteeritud jaoks: UDP/4002, TCP/4002
  • rpc.rquota jaoks: UDP/4003, TCP/4003
• rpc.nfsd serveri jaoks lisage rida RPCNFSDARGS="--port 2049" kausta /etc/sysconfig/nfs
• mount serveri jaoks lisage MOUNTD_PORT=4002 rida /etc/sysconfig/nfs
• et konfigureerida rpc.rquota uute versioonide jaoks, peate faili /etc/sysconfig/nfs lisama rea ​​RQUOTAD_PORT=4003
• vanemate versioonide jaoks vajaliku rpc.rquota seadistamiseks (samas peab teil olema pakett quota 3.08 või uuem) lisage faili /etc/services rquotad 4003/tcp rquotad 4003/udp
• kontrollige /etc/exports kehtivust
• käivitage teenused rpc.nfsd, mountd ja rpc.rquota (samal ajal käivituvad rpcsvcgssd ja rpc.idmapd, kui mäletate neid kustutada) service nfsd start või uuemates versioonides service nfs start
• uute süsteemide lukuserveri jaoks lisage read LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001 faili /etc/sysconfig/nfs
• vanemate süsteemide lukuserveri jaoks lisage otse faili /etc/modprobe[.conf]: options lockd nlm_udpport=4001 nlm_tcpport=4001
• seo olekuserver rpc.statd pordiga 4000 (vanemate süsteemide jaoks käivitage rpc.statd koos -p 4000 failis /etc/init.d/nfslock) STATD_PORT=4000
• start lockd ja rpc services.statd service nfslock start
• veenduge, et kõik pordid on õigesti seotud "lsof -i -n -P" ja "netstat -a -n" (mõnda porti kasutavad kerneli moodulid, mida lsof ei näe)
• kui enne "ümberehitamist" kasutasid kliendid serverit ja neid ei saanud lahti ühendada, peate teenused klientidel taaskäivitama automaatne kinnitus(am-utils, autofs)

NFS-serveri ja kliendi konfiguratsiooni näide

Serveri konfiguratsioon

Kui soovite muuta oma NFS-partitsioonidega kataloogi avatuks ja kirjutatavaks, võite kasutada seda valikut kõik_squash kombinatsioonis valikutega anonüümne Ja anonüümne. Näiteks kasutajale "nobody" õiguste määramiseks grupis "nobody" saate teha järgmist.

ARCHIV ~ # cat /etc/exports # Lugemis-/kirjutusjuurdepääs kliendile aadressil 192.168.0.100, rw-juurdepääs kasutajale 99 koos gid 99 /failid 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=9) # Kliendi lugemis- ja kirjutamisõigus aadressil 192.168.0.100, rw-juurdepääsuga kasutajale 99 gid 99 /failid 192.168.0.100 (rw,sync,all_squash,anonuid=99,anongid=99))

See tähendab ka seda, et kui soovite lubada juurdepääsu määratud kataloogile, peab nobody.nobody olema jagatud kataloogi omanik:

mehe mägi
mees ekspordib
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm – NFS-i jõudlus IBMilt.

Lugupidamisega Mc.Sim!

NFS-failisüsteemi (Network File System) lõi Sun Microsystems. Praegu on see UNIX-i operatsioonisüsteemide standardne võrgufailisüsteem ning NFS-kliendid ja -serverid on rakendatud paljude teiste operatsioonisüsteemide jaoks. Selle organisatsiooni põhimõtted on tänapäeval standarditud Interneti-kogukonna poolt, Uusim versioon NFS v.4 on kirjeldatud 2000. aasta detsembris välja antud ZOY RFC spetsifikatsioonis.

NFS on süsteem, mis toetab failidele kaugjuurdepääsu skeemi. Kasutaja töö kaugfailidega pärast ühendamise operatsiooni muutub täiesti läbipaistvaks – NFS-serveri failisüsteemi alampuu muutub kohaliku failisüsteemi alampuuks.

Üks NFS-i disainieesmärke oli toetada heterogeenseid süsteeme klientide ja serveritega, mis töötavad erinevatel riistvaraplatvormidel erinevaid operatsioonisüsteeme. Selle eesmärgi saavutamist hõlbustab Sun RFC mehhanismil põhineva NFS-i rakendamine, mis vaikimisi toetab XDR-i vahendeid kaugprotseduuri argumentide ühtseks esitamiseks.

Kliendi vastupanuvõime tagamiseks serveritõrgete suhtes kasutab NFS olekuta lähenemisviisi, st failidega töötamisel ei salvesta serverid andmeid klientide avatud failide kohta.

NFS-i põhiidee on võimaldada suvalisel kasutajarühmal ühist failisüsteemi jagada. Enamasti kuuluvad kõik kasutajad samasse kohalikku võrku, kuid mitte tingimata. Saate käivitada NFS-i ülemaailmne võrk. Iga NFS-server teeb kaugklientidele juurdepääsuks ühe või mitu oma kataloogi. Kataloog kuulutatakse juurdepääsetavaks koos kõigi selle alamkataloogidega. Kataloogide loend, mida server läbib, sisaldub failis /etc/exports, nii et need kataloogid eksporditakse automaatselt kohe pärast serveri käivitumist. Kliendid pääsevad eksporditud kataloogidele juurde paigaldamise teel. Paljud Suni tööjaamad on kettata, kuid isegi siis saate juurkataloogi ühendada kaugfailisüsteemi, kus kogu failisüsteem asub serveris. Programmide täitmine on peaaegu sõltumatu sellest, kas fail asub kohapeal või kaugdraivis. Kui kaks või enam klienti on korraga ühendanud sama kataloogi, saavad nad suhelda faili poolitades.

NFS-failisüsteem kasutab oma töös kahte protokolli.

Esimene NFS-protokoll juhib kinnitusi. Klient saadab serverile kataloogi täisnime ja küsib luba kataloogi kuhugi oma kataloogipuusse monteerimiseks. Sel juhul server ei määra, kuhu serveri kataloog ühendatakse. Pärast nime saamist kontrollib server selle päringu õiguspärasust ja tagastab kliendile kaugühenduspunktiks oleva faili käepideme. Deskriptor sisaldab failisüsteemi tüübi deskriptorit, ketta numbrit, kaugühenduspunktiks oleva kataloogi inode numbrit ja turbeteavet. Ühendatud failisüsteemidest failide lugemisel ja kirjutamisel kasutatakse sümboolse nime asemel failideskriptoreid.

Paigaldamist saab teha automaatselt kasutades partiifailid laadimise ajal. Automaatseks ühendamiseks on veel üks võimalus: kui OS käivitub tööjaamas, siis kaugfailisüsteemi ei ühendata, kuid kaugfaili esmakordsel avamisel saadab OS päringud igale serverile ja pärast selle faili leidmist ühendab kataloogi. serverist, kus leitud fail asub.

Teist NFS-protokolli kasutatakse kaugfailidele ja kataloogidele juurdepääsuks. Kliendid saavad saata serverile taotluse kataloogiga mõne toimingu tegemiseks või faili lugemiseks või kirjutamiseks. Lisaks saavad nad taotleda faili atribuute, nagu tüüp, suurus, loomise ja muutmise aeg. NFS-i toetab enamik süsteemikõned UNIX, välja arvatud avamine ja sulgemine. Avamise ja sulgemise erand ei ole juhuslik. Kaugfaili avamise asemel saadab klient serverile sõnumi, mis sisaldab failinime, paludes sellel see üles otsida (otsing) ja tagastada faili deskriptor. Erinevalt avatud kõnest ei kopeeri otsingukõne mingit teavet sisemistesse süsteemitabelitesse. Lugemiskutse sisaldab loetava faili deskriptorit, nihet sisse loetav fail ja loetavate baitide arv. Selle skeemi eeliseks on see, et server ei mäleta avatud failidest midagi. Nii ei lähe avatud faili teave kaotsi, kui server jookseb kokku ja seejärel taastatakse, kuna seda ei toetata.

Kui server ebaõnnestub, jätkab klient lihtsalt failide lugemise või kirjutamise käskude saatmist, kuid pärast vastust saamata ja ajalõpu ammendumist kordab klient oma päringuid. Pärast taaskäivitamist saab server kliendilt uue korduva päringu ja vastab sellele. Seega põhjustab serveri krahh klienditeeninduses vaid väikese pausi, kuid ühenduste taastamiseks ja failide taasavamiseks pole klientidelt vaja täiendavaid toiminguid teha.

Kahjuks muudab NFS failide lukustamise keeruliseks. Paljudes operatsioonisüsteemides saab faili avada ja lukustada, nii et teised protsessid ei pääse sellele juurde. Kui fail suletakse, lukk vabastatakse. Olekuta süsteemides, nagu NFS, ei saa lukku seostada avatava failiga, kuna server ei tea, milline fail on avatud. Seetõttu vajab NFS spetsiaalseid täiendavaid lukustusnuppe.

NFS kasutab kliendipoolset vahemällu, edastab andmed vahemällu plokkide kaupa ja kasutab eellaadimist, mille puhul ploki vahemällu lugemisele rakenduse nõudmisel järgneb alati järgmise ploki lugemine süsteem. NFS-i vahemällu salvestamise meetod ei säilita failijagamiseks UNIX-i semantikat. Selle asemel kasutab see palju kritiseeritud semantikat, mille kohaselt on kliendi vahemällu salvestatud failis tehtud andmete muudatused teisele kliendile nähtavad, olenevalt ajastusest. Järgmine kord, kui ta vahemälus faili avab, kontrollib klient serverist, millal faili viimati muudeti. Kui see juhtub pärast faili vahemällu salvestamist, eemaldatakse fail vahemälust ja server võtab selle vastu uus koopia faili. Kliendid levitavad vahemällu salvestatud muudatusi 30-sekundiliste intervallidega, nii et server saab värskendusi vastu võtta pika viivitusega. Vahemälu kustutamise ja muutmise levimismehhanismide tulemusena ei ole ühegi kliendi saadud andmed alati kõige värskemad.

NFS-i replikatsiooni ei toetata.

Kataloogiteenus

Organisatsiooni eesmärk ja põhimõtted

Nagu suur organisatsioon, suur arvutivõrk vajab tsentraliseeritud salvestamist enda kohta võimalikult täielikku viiteteavet. Paljude võrguprobleemide lahendamine põhineb teabel võrgukasutajate kohta - nende loogiliseks sisselogimiseks kasutatavad nimed, paroolid, juurdepääsuõigused võrguressurssidele, aga ka võrguressursside ja komponentide kohta: serverid, klientarvutid, ruuterid, lüüsid, fail süsteemimahud, printerid jne.

Siin on näited kõige olulisematest ülesannetest, mis nõuavad võrgus viiteteabe tsentraliseeritud andmebaasi:

• Üks sagedamini teostatavaid ülesandeid süsteemis, mis põhineb kasutajate viiteinfol, on nende autentimine, mille alusel teostatakse seejärel juurdepääsu autoriseerimine. Võrk peab kuidagi tsentraalselt talletama nimesid ja paroole sisaldavaid kasutajakontosid.
• Mõne tsentraliseeritud andmebaasi olemasolu eeldab läbipaistva juurdepääsu toetamist paljudele võrguressurssidele. Selline andmebaas peaks salvestama nende ressursside nimed ja kaardistama nimed numbriliste identifikaatoritega (näiteks IP-aadressidega), mis võimaldavad seda ressurssi võrgust leida. Läbipaistvust saab tagada juurdepääsul serveritele, failisüsteemi köidetele, RPC protseduuride liidestele, hajutatud rakendusprogrammi objektidele ja paljudele muudele võrguressurssidele.
• E-post on veel üks populaarne näide teenusest, mille jaoks on üks võrk kasutajatugi A, mis salvestab kasutaja e-posti nimeandmed.
• Viimasel ajal on võrkudes üha enam kasutatud teenusekvaliteedi (QoS) haldustööriistu, mis nõuavad teavet ka kõigi süsteemi kasutajate ja rakenduste kohta, nende nõuete kohta teenuse parameetrite liikluskvaliteedile, aga ka kõigi võrguseadmete kohta, millega koos. saate hallata liiklust (ruuterid, lülitid, lüüsid jne).
• Hajutatud rakenduste organiseerimist saab oluliselt lihtsustada, kui võrgus on andmebaas, mis salvestab infot saadaolevate tarkvaramoodulite-objektide ja nende asukoha kohta võrguserverites. Rakendus, mis peab sooritama mõnd standardtoimingut, esitab sellisele andmebaasile päringu ja võtab vastu programmiobjekti aadressi, millel on võime teha vajalikku toimingut.
• Võrguhaldussüsteemil peab olema baas teabe salvestamiseks võrgu topoloogia ja kõigi võrguelementide (nt ruuterid, kommutaatorid, serverid ja klientarvutid) omaduste kohta. Täieliku teabe olemasolu võrgu koostise ja selle ühenduste kohta võimaldab automatiseeritud võrguhaldussüsteemil õigesti tuvastada hädaolukorra sõnumeid ja leida nende algpõhjus. Korraldatud äriüksuse teabe olemasoleva kohta võrguseadmed ja installitud tarkvara on iseenesest kasulik, kuna see aitab administraatoritel saada tõest ülevaadet võrgu olekust ja töötada välja selle arendamise plaane.

Selliseid näiteid võib jätkata, kuid pole raske esitada vastuargumenti, mis seab kahtluse alla vajaduse kasutada võrgus viiteteabe tsentraliseeritud andmebaasi - pikka aega võrgud töötasid ilma ühe võrdlusbaasita ja paljud võrgud töötavad siiani ilma selleta. Tõepoolest on palju privaatseid lahendusi, mis võimaldavad tõhusalt korraldada võrgu tööd privaatsete viiteinfobaaside alusel, mida saab kujutada tavaliste tekstifailide või rakenduse kehasse salvestatud tabelitega. Näiteks UNIX kasutab tavapäraselt kasutajanimede ja paroolide salvestamiseks faili passwd, mis hõlmab ainult ühe arvuti kasutajaid. Meili saajate nimesid saab salvestada ka klientarvuti kohalikku faili. Ja sellised privaatsed viitesüsteemid töötavad hästi – praktika kinnitab seda.

See vastuväide kehtib aga ainult väikese ja keskmise suurusega võrkude puhul, suurtes võrkudes kaotavad üksikud kohalikud võrdlusandmebaasid oma tõhususe. Hea näide kohalike lahenduste mittekasutatavusest suurvõrkude puhul on Internetis töötav DNS-nimeteenus. Niipea, kui Interneti suurus ületas teatud piiri, muutus võrguarvutite nimede ja IP-aadresside vastavuse kohta teabe salvestamine kohalikesse tekstifailidesse ebaefektiivseks. Interneti-sümbolite lahendamise protseduuride kiireks ja tõhusaks toimimiseks oli vaja luua hajutatud andmebaas, mida toetavad hierarhiliselt seotud nimeserverid ja sellele andmebaasile tsentraliseeritud teenus.

Suure võrgu puhul on ebaefektiivne kasutada ka suurt hulka kitsa eesmärgiga kataloogiteenuseid: üht autentimiseks, teist võrguhalduseks, kolmandat arvutinimede lahendamiseks jne. Isegi kui kõik need teenused on hästi organiseeritud ja kombineeritud tsentraliseeritud liides hajutatud baasandmetega, suur number kasutajatugi toob kaasa suurte teabemahtude dubleerimise ning muudab võrgu haldamise ja haldamise keerulisemaks. Näiteks Windows NT-l on vähemalt viis erinevat tüüpi viiteandmebaasid. Domeeni põhikataloog (NT Domain Directory Service) salvestab kasutajate kohta teavet, mis on vajalik nende loogilise võrku sisselogimise korraldamisel. Samade kasutajate andmed võivad sisalduda ka teises kasutatavas kataloogis meili Microsoft Mail. Veel kolm andmebaasi toetavad aadresside eraldusvõimet: WINS vastendab Netbiose nimed IP-aadressidega, DNS-otsing (domeeninimeserver) on kasulik NT-võrgu ühendamisel Internetti ja lõpuks kasutatakse DHCP-otsingut IP-aadresside automaatseks määramiseks arvutitele. võrk. Ilmselgelt muudab selline abiteenuste mitmekesisus administraatori elu keeruliseks ja toob kaasa täiendavaid vigu, kui sama kasutaja mandaadid tuleb sisestada mitmesse andmebaasi. Seetõttu uues Windowsi versioonid 2000 enamuse süsteemi viiteinfost saab teenus salvestada Active Directory- ühtne tsentraliseeritud viiteteenus, mis kasutab hajutatud andmebaasi ja on integreeritud DNS-i nimeteenusega.

Viiteteabe salvestussüsteemide väljatöötamise tulemuseks oli eriteenuse - nn kataloogiteenuse (Directory Services), mida nimetatakse ka viiteteenuseks (kataloog - kataloog, kataloog) - tekkimine võrgu operatsioonisüsteemides. Kataloogiteenus salvestab teavet kõigi kasutajate ja võrguressursside kohta teatud atribuutidega ühtsete objektide kujul ning võimaldab teil kajastada ka salvestatud objektide vahelisi seoseid, näiteks kasutaja seotust teatud grupp, kasutajate juurdepääsuõigused arvutitele, mitme sõlme kaasamine samasse alamvõrku, alamvõrkudevahelised sidelingid, serverite tootmisseos jne. Kataloogiteenus võimaldab salvestatud objektidel sooritada mõningaid põhitoiminguid, näiteks lisada ja objekti kustutamine, sealhulgas objekti teises objektis, objekti atribuudi väärtuste muutmine, atribuutide lugemine ja mõned muud. Tavaliselt on kataloogiteenuse peale ehitatud erinevad spetsiifilised võrgurakendused, mis kasutavad teenuseteavet konkreetsete probleemide lahendamiseks: võrguhaldus, kasutaja autentimine, teenuse läbipaistvus ja muud ülaltoodud. Kataloogiteenus on tavaliselt üles ehitatud klient-server mudeli alusel: serverid salvestavad viiteteabe andmebaasi, mida kliendid kasutavad, edastades võrgu kaudu serveritele vastavaid päringuid. Kataloogiteenuse kliendi jaoks näib see olevat ühtne tsentraliseeritud süsteem, kuigi enamikul headel kataloogiteenustel on hajutatud struktuur, mis hõlmab palju servereid, kuid see struktuur on klientide jaoks läbipaistev.

oluline küsimus on viiteandmebaasi korraldus. Üks andmebaas, mis salvestab suurel hulgal viiteteavet, tekitab samasuguseid probleeme nagu iga teinegi suur alus andmeid. Help Desk juurutamine as kohalik baasühes võrguserveris ühe koopiana salvestatud andmed ei sobi suurde süsteemi mitmel põhjusel ning eelkõige sellise lahenduse vähese jõudluse ja vähese töökindluse tõttu. Jõudlus on madal, kuna kõigi võrgu kasutajate ja rakenduste päringud andmebaasi suunatakse ühte serverisse, mis suurel hulgal päringuid ei käsitleta kindlasti enam. See tähendab, et selline lahendus ei mastaap hästi teenindatavate kasutajate arvu ja jagatud ressursside osas. Samuti ei saa usaldusväärsus olla kõrge süsteemis, kus on üks andmete koopia. Lisaks jõudluse ja töökindluse piirangute eemaldamisele on soovitav, et andmebaasi struktuur võimaldaks ressursside ja kasutajate loogilist rühmitamist ettevõtte struktuuriüksuste kaupa ning igale sellisele rühmale administraatori määramist.

Jõudluse ja töökindluse säilitamisega seotud väljakutsed võrgu laienemisel lahendatakse tavaliselt hajutatud viiteandmebaaside abil. Andmete jagamine mitme serveri vahel vähendab iga serveri koormust, tagades samal ajal usaldusväärsuse, kuna andmebaasi igast osast on mitu koopiat. Andmebaasi iga osa jaoks saate määrata oma administraatori, kellel on juurdepääsuõigused ainult tema kogu süsteemi teabe osa objektidele. Kasutaja (ja võrgurakenduste) jaoks esindab sellist hajutatud andmebaasi ühtne andmebaas, mis tagab juurdepääsu kõigile võrguressurssidele, olenemata sellest, millisest tööjaamast päring pärineb.

Kataloogiteenuste jaoks on kaks populaarset standardit. Esiteks on see ITU-T poolt välja töötatud X.500 standard (standardi väljatöötamise ajal kandis see organisatsioon nime CCITT). See standard määratleb kasutajatoe funktsioonid, ülesehituse ja sellele juurdepääsu protokolli. Peamiselt X.400 meiliteenusega kasutamiseks mõeldud X.500 standard võimaldab tõhusalt salvestada mis tahes viiteteavet ja on heaks aluseks universaalsele võrgukataloogiteenusele.

Teine standard on LDAP (Light-weight Directory Juurdepääsuprotokoll), mille on välja töötanud Interneti-kogukond. See standard määratleb kataloogiteenusele juurdepääsu lihtsustatud protokolli, kuna X.500 standardile üles ehitatud teenused osutusid liiga tülikaks. LDAP-protokoll on muutunud laialt levinud ja sellest on saanud de facto standard klienditoe ressurssidele juurdepääsu võimaldava protokollina.

Võrgu operatsioonisüsteemide kataloogiteenustel on ka mitmeid praktilisi rakendusi. Novelli NDS-teenus, mis töötati välja 1993. aastal võrguoperatsioonisüsteemi NetWare 4.0 jaoks ja mis on nüüdseks rakendatud ka Windows NT/2000 jaoks, on saanud suurima leviku. Suurt huvi pakub Microsofti poolt Windows 2000 jaoks välja töötatud Active Directory kataloogiteenus. Mõlemad teenused toetavad LDAP-pääsuprotokolli ja võivad oma levitamise tõttu töötada väga suurtes võrkudes.

NDS kataloogiteenus

NDS (NetWare Directory Services) on globaalne kataloogiteenus, mis põhineb võrguressursside hajutatud objektorienteeritud andmebaasil. NDS-andmebaas sisaldab teavet kõigi võrguressursside kohta, sealhulgas teavet kasutajate, kasutajarühmade, printerite, köidete ja arvutite kohta. NetWare OS (nagu ka teised teistel platvormidel töötavad NDS-kliendid) kasutab nendele ressurssidele juurdepääsu võimaldamiseks NDS-i teavet.

NDS-i andmebaas asendas NetWare'i eelmiste versioonide sidekataloogi. Sidekataloog on "tasane" või ühetasandiline andmebaas, mis on loodud ühe serveri toetamiseks. Samuti kasutati võrguressursi kohta mõistet "objekt", kuid selle mõiste tõlgendus erines üldtunnustatud tõlgendusest. Sideobjektid tuvastati lihtsate arvväärtuste järgi ja neil olid teatud atribuudid. Kuid nende objektide jaoks ei määratletud selgesõnalisi objektiklasside pärimissuhteid, mistõttu administraator määras sideobjektide vahelise seose meelevaldselt, mis sageli põhjustas andmete terviklikkuse rikkumisi.

NDS-teenuste andmebaas on mitmetasandiline andmebaas, mis säilitab teavet kõigi võrgus olevate serverite ressursside kohta. Ühilduvuse tagamiseks NetWare'i eelmiste versioonidega pakub NDS sidebaasi jäljendamise mehhanismi.

NDS on eelmiste versioonidega võrreldes märkimisväärne edasiminek:

• levitamine;
• replikatsioon;
• läbipaistvus;
• globaalsus.

Levitamine seisneb selles, et teavet ei salvestata ühte serverisse, vaid see on jagatud osadeks, mida nimetatakse partitsioonideks. NetWare salvestab need partitsioonid mitmesse võrgu serverisse (joonis 10.8). See funktsioon lihtsustab oluliselt suure võrgu haldamist ja haldamist, kuna see tundub administraatorile ühtse süsteemina. Lisaks annab see rohkem kiire juurdepääs võrguressursside andmebaasi, võttes ühendust lähima serveriga.

Riis. 10.8. NDS-i andmebaasi partitsioonid

Replica on NDS-i partitsiooni teabe koopia. Igast partitsioonist saate luua piiramatu arvu koopiaid ja salvestada need erinevatesse serveritesse. Kui üks server peatub, saab selle teabe koopiaid hankida teisest serverist. See suurendab süsteemi vastupidavust, kuna ükski server ei vastuta kogu NDS-i andmebaasi teabe eest.

Läbipaistvus seisneb selles, et NDS loob automaatselt lingid tarkvara- ja riistvarakomponentide vahel, mis tagavad kasutajale juurdepääsu võrguressurssidele. NDS ei nõua, et kasutaja teaks nende ressursside füüsilist asukohta. Kui määrate võrguressursi nime järgi, saate sellele õige juurdepääsu isegi siis, kui selle võrguaadress või asukoht muutub.

NDS-i globaalne olemus seisneb selles, et pärast sisselogimist pääsete ligi kogu võrgu ressurssidele, mitte ainult ühele serverile, nagu oli varasemates versioonides. See saavutatakse globaalse sisselogimisprotseduuri kaudu. Eraldi serverisse sisselogimise asemel logib NDS-i kasutaja võrku sisse ja pääseb seejärel ligi neile lubatud võrguressurssidele. Sisselogimisel antud teavet kasutatakse kasutaja tuvastamiseks. Hiljem, kui kasutaja proovib pääseda juurde ressurssidele, nagu serverid, köited või printerid, kontrollib tausta autentimisprotsess, et näha, kas kasutajal on ressursi õigused.

Network File System (NFS) on failijagamislahendus organisatsioonidele, kus on segatud Windowsi ja Unixi/Linuxi masinakeskkond. NFS-failisüsteem võimaldab töötamise ajal faile jagada määratud erinevate platvormide vahel operatsioonisüsteem Windows Server 2012 NFS Windows Server 2012 sisaldab järgmisi funktsioone ja täiustusi.

1. Otsige Active Directoryst. Teil on võimalus failidele juurdepääsuks kasutada Windows Active Directory't. Active Directory skeemi laiendus Unixi identiteedihaldus sisaldab Unixi kasutajaidentifikaatori (UID) ja rühma identifikaatori (GID) välju. See võimaldab serveril NFS-ile ja kliendile NFS-i teenustele vaadata Windowsi kasutajakontode vastendusi Unixis otse teenustest. Aktiivne domeen Kataloog (Active Directory domeeniteenused). Unixi identiteedihaldus võimaldab hõlpsalt hallata Windowsi vastendamist Unixi kasutajakontodega Active Directory domeeniteenustes.

2. Parem serveri jõudlus. Teenused NFS-ile sisaldavad failifiltri draiverit, mis vähendab märkimisväärselt üldist failijuurdepääsu latentsust serveris.

3. Spetsiaalsete Unixi seadmete tugi. NFS-i teenused toetavad spetsiaalseid Unixi seadmeid (mknod).

4. Laiendatud Unixi tugi. Services for NFS toetab järgmisi Unixi versioone: Sun Microsystems Solarise versioonid 9, Red Hat Linuxi versioon 9, IBM AIX versioon 5L 5.2 ja Hewlett Packardi HP-UX versioon 11i, samuti paljud kaasaegsed Linuxi distributsioonid.

Üks levinumaid stsenaariume, mis tekitab vajaduse NFS-i kasutamiseks, hõlmab juurdepääsu avamist kasutajatele Windowsi keskkond Unixil põhinevale ettevõtte ressursside planeerimise (ERP) süsteemile. ERP-süsteemis olles saavad kasutajad luua aruandeid ja/või eksportida finantsandmeid Microsoft Excel edasiseks analüüsiks. NFS-failisüsteem võimaldab neile failidele juurde pääseda veel Windowsi keskkonnas, vähendades vajadust spetsiaalsete tehniliste oskuste järele ja vähendades aega, mis kulub failide eksportimiseks Unixi skripti abil ja seejärel nende importimiseks. konkreetne rakendus Windows.

Teil võib tekkida ka olukord, kus teil on Unixi süsteem, mida kasutatakse failide salvestamiseks mõnes salvestuspiirkonna võrgus ( hoiuala Võrk – SAN). NFS-i käitamine Windows Server 2012 masinas võimaldab organisatsiooni kasutajatel pääseda juurde seal salvestatud failidele ilma Unixi poolel skriptimiseta.

Enne NFS-i installimist peate eemaldama kõik varem installitud NFS-i komponendid, näiteks NFS-i komponendid, mis olid kaasas teenusega Services for Unix.

NFS-i teenuse komponendid

Saadaval on kaks järgmist NFS-teenuste komponenti.

1. Server NFS-i jaoks(NFS-i server). Üldiselt ei pääse Unixi-põhine arvuti Windowsi-põhises arvutis asuvatele failidele juurde. Arvuti, milles töötab Windows Server 2012 R2 ja Server for NFS, võib aga toimida Windowsi ja Unixi arvutite failiserverina.

2. NFS-i klient(NFS-i klient). Tavaliselt ei pääse Windowsi põhinev arvuti Unixi-põhises arvutis olevatele failidele juurde. Kuid Windows Server 2012 R2 ja NFS-i klienti kasutav arvuti pääseb juurde failidele, mis on salvestatud Unixi-põhisesse NFS-serverisse.

NFS-i serveri installimine PowerShelli abil

Vaatame, kuidas kasutada PowerShelli NFS-i rolli installimiseks serverisse ja NFS-faili ühiskasutusse loomiseks.

1. Avage tegumiribal administraatorikontona Windows PowerShelli aken.

2. NFS-i rolli installimiseks serverisse sisestage järgmised käsud:

PS C:\> Impordi mooduli serverihaldur PS C:\> Lisa - Windowsi funktsioon FS-NFS - teenused PS C:\> Impordi moodul NFS

3. Uue ühiskasutuse loomiseks sisestage allolev käsk failiressurss NFS:

PS C:\> Uus-NfsShare -Nimi "Test" - Tee "C:\Shares\Test"

4. Kõigi Windows Server 2012 R2-s saadaolevate uute NFS-iga seotud PowerShelli cmdlet-käskude vaatamiseks käivitage järgmine käsk:

PS C:\> Get-Command - moodul NFS

5. Paremklõpsake kaustal C:\Shares\Test, valige "properties", seejärel klõpsake vahekaarti NFS Sharing. Klõpsake nuppu Halda NFS-i ühiskasutust. Ilmuvas dialoogiboksis saate hallata kaustale juurdepääsu õigusi, lubada anonüümset juurdepääsu ja konfigureerida failide kodeerimise sätteid. Saate jagada kausta NFS-i kaudu, kasutades dialoogi NFS-i täiustatud ühiskasutus, ilma PowerShelli kasutamata.

Standardõiguste määramine

NFS-i toimimiseks peame nüüd avama mõned tulemüüri pordid. NFS-teenuste normaalseks toimimiseks vajalikud pordid on toodud allolevas tabelis.