NFS filsystem. Hva er NFS? Nettverksfilsystem

NFS: et praktisk og lovende nettverksfilsystem

Nettverksfilsystem er en nettverksabstraksjon på toppen av et vanlig filsystem som lar en ekstern klient få tilgang til den over nettverket på samme måte som ved tilgang til lokale filsystemer. Selv om NFS ikke var det første nettverksfilsystemet, har det utviklet seg til å bli det mest kapable og populære nettverksfilsystemet i UNIX® i dag. NFS lar flere brukere dele et felles filsystem og sentraliserer data for å minimere diskplass nødvendig for deres oppbevaring.

Denne artikkelen begynner med en kort oversikt over historien til NFS og går deretter videre til å utforske arkitekturen til NFS og hvordan den kan utvikle seg i fremtiden.

En kort historie om NFS

Det første nettverksfilsystemet ble kalt FAL (File Access Listener) og ble utviklet i 1976 av DEC (Digital Equipment Corporation). Det var en implementering av DAP-protokollen (Data Access Protocol) og var en del av DECnet-protokollpakken. Som med TCP/IP har DEC publisert spesifikasjoner for sine nettverksprotokoller, inkludert DAP-protokollen.

NFS var det første moderne nettverksfilsystemet bygget på toppen av IP-protokollen. Prototypen kan betraktes som et eksperimentelt filsystem utviklet ved Sun Microsystems på begynnelsen av 80-tallet. Gitt populariteten til denne løsningen, ble NFS-protokollen introdusert som en RFC-spesifikasjon og utviklet seg deretter til NFSv2. NFS etablerte seg raskt som en standard på grunn av sin evne til å interoperere med andre klienter og servere.

Standarden ble deretter oppdatert til NFSv3, definert i RFC 1813. Denne versjonen av protokollen var mer skalerbar enn tidligere versjoner og støttet større filstørrelser (over 2 GB), asynkron skriving og TCP som transportprotokoll. NFSv3 satte retningen for utviklingen av filsystemer for wide area networks (WAN). I 2000 brakte RFC 3010 (revidert som RFC 3530) NFS inn i bedriftsmiljøet. Sun introduserte en sikrere NFSv4 med stateful støtte (tidligere versjoner av NFS støttet ikke stateful storage, dvs. de ble klassifisert som stateless). For øyeblikket er den nyeste versjonen av NFS versjon 4.1, definert i RFC 5661, som legger til protokollen ved å utvide pNFS støtte for parallell tilgang for distribuerte servere er lagt til.

Historien til NFS, inkludert spesifikke RFC-er som beskriver versjonene, er vist i figur 1.

Overraskende nok har NFS vært under utvikling i nesten 30 år. Det er et usedvanlig stabilt og bærbart nettverksfilsystem med enestående skalerbarhet, ytelse og tjenestekvalitet. Ettersom hastigheter øker og ventetiden reduseres når du kommuniserer innenfor et nettverk, fortsetter NFS å være en populær måte å implementere et filsystem i et nettverk. Selv når det gjelder lokale nettverk, oppmuntrer virtualisering til lagring av data på nettverket for å gi ekstra mobilitet til virtuelle maskiner. NFS støtter også nyeste modeller organisasjoner av datamiljøer rettet mot å optimalisere virtuelle infrastrukturer.

NFS arkitektur

NFS bruker en standard klient-server-arkitektonisk modell (som vist i figur 2). Serveren er ansvarlig for å implementere det delte filsystemet og lagringen som klientene kobler seg til. Klienten implementerer et brukergrensesnitt til et delt filsystem montert innenfor klientens lokale filområde.

Figur 2. Implementering av klient-server-modellen i NFS-arkitekturen

I Linux® gir en virtuell filsystemsvitsj (VFS) muligheten til å støtte flere filsystemer (for eksempel et ISO 9660-filsystem på en CD-ROM og et ext3fs-filsystem på en lokal harddisk) samtidig på en enkelt vert . Den virtuelle svitsjen bestemmer hvilken stasjon forespørselen sendes til og derfor hvilket filsystem som skal brukes til å behandle forespørselen. Derfor har NFS samme kompatibilitet som andre filsystemer som brukes i Linux. Den eneste forskjellen med NFS er at i stedet for å bli behandlet lokalt på verten, kan I/O-forespørsler sendes til nettverket for utførelse.

VFS bestemmer at den mottatte forespørselen er NFS og sender den til NFS-behandleren som ligger i kjernen. NFS-behandleren behandler I/O-forespørselen og oversetter den til en NFS-prosedyre (OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE, etc.). Disse prosedyrene, beskrevet i en separat RFC-spesifikasjon, definerer oppførselen til NFS-protokollen. Den nødvendige prosedyren velges avhengig av forespørselen og utføres ved hjelp av RPC-teknologi (remote procedure call). Som navnet antyder, tillater RPC at prosedyrekall utføres mellom forskjellige systemer. RPC-tjenesten kobler sammen en NFS-forespørsel med dens argumenter og sender resultatet til den aktuelle eksterne verten, og overvåker deretter mottaket og behandlingen av svaret for å returnere det til rekvirenten.

RPC inkluderer også et viktig XDR-lag ( ekstern datarepresentasjon- uavhengig datarepresentasjon), som sikrer at alle NFS-brukere bruker samme format for de samme datatypene. Når en plattform sender en forespørsel, kan datatypen den bruker være forskjellig fra datatypen som brukes på verten som behandler forespørselen. XDR-teknologi tar seg av arbeidet med å konvertere typer til en standardrepresentasjon (XDR) slik at plattformer som bruker forskjellige arkitekturer kan fungere sammen og dele filsystemer. XDR definerer bitformatet for typer som float og byte-rekkefølgen for typer som konstant og variabel lengde arrays. Selv om XDR først og fremst er kjent for sin bruk i NFS, kan denne spesifikasjonen være nyttig i alle tilfeller der man må jobbe i samme miljø med ulike arkitekturer.

Etter at XDR har oversatt dataene til en standardrepresentasjon, sendes forespørselen over nettverket ved hjelp av en spesifikk transportprotokoll. Tidlige implementeringer av NFS brukte UDP, men i dag brukes TCP for større pålitelighet.

En lignende algoritme brukes på NFS-serversiden. Forespørselen går opp i nettverksstakken gjennom RPC/XDR-laget (for å konvertere datatyper i henhold til serverarkitekturen) og inn i NFS-serveren, som er ansvarlig for å behandle forespørselen. Der sendes forespørselen til NFS-demonen for å bestemme målfilsystemet som den er adressert til, og går deretter igjen til VFS for å få tilgang til filsystemet på den lokale disken. Et fullstendig diagram over denne prosessen er vist i figur 3. I dette tilfellet er det lokale filsystemet til serveren et standard Linux-filsystem, for eksempel ext4fs. NFS er i hovedsak ikke et filsystem i tradisjonell forstand av begrepet, men en protokoll for ekstern tilgang til filsystemer.

For nettverk med lang ventetid tilbyr NFSv4 en spesiell sammensatt prosedyre ( sammensatt prosedyre). Denne prosedyren lar deg foreta flere RPC-anrop innenfor en enkelt forespørsel for å minimere kostnadene ved å sende forespørsler over nettverket. Denne prosedyren implementerer også en tfor å motta svar.

NFS-protokoll

Når en klient begynner å bruke NFS, er den første handlingen å utføre en monteringsoperasjon, som er å montere det eksterne filsystemet til det lokale filsystemområdet. Denne prosessen begynner med et kall til monteringsprosedyren (en av Linux-systemfunksjonene), som omdirigeres gjennom VFS til NFS-komponenten. Deretter bestemmer et RPC-kall til get_port-funksjonen på den eksterne serveren portnummeret som skal brukes til montering, og klienten sender en monteringsforespørsel via RPC. Denne forespørselen på serversiden behandles av en spesiell daemon rpc.mountd, som er ansvarlig for monteringsprotokollen ( montere protokoll). Daemonen sjekker at filsystemet som klienten ber om er i listen over tilgjengelige systemer på den gitte serveren. Hvis det forespurte systemet eksisterer og klienten har tilgang til det, spesifiserer mount RPC-responsen en filsystembeskrivelse. Klienten beholder informasjon om lokale og eksterne monteringspunkter og er i stand til å gjøre I/O-forespørsler. Monteringsprotokollen er ikke sikker fra et sikkerhetssynspunkt, så NFSv4 bruker interne RPC-anrop i stedet, som også kan administrere monteringspunkter.

For å lese en fil må du først åpne den. Det er ingen OPEN-prosedyre i RPC; i stedet sjekker klienten ganske enkelt at den angitte filen og katalogen finnes på det monterte filsystemet. Klienten begynner med å lage en GETATTR RPC-forespørsel til katalogen, som returnerer katalogens attributter eller en indikator på at katalogen ikke eksisterer. Deretter, for å sjekke om filen er tilstede, sender klienten en LOOKUP RPC-forespørsel. Hvis filen eksisterer, sendes en GETATTR RPC-forespørsel til den for å finne ut filens attributter. Ved å bruke informasjonen hentet fra vellykkede LOOKUP- og GETATTR-anrop, oppretter klienten et filhåndtak som gis til brukeren for fremtidige forespørsler.

Når filen er identifisert på det eksterne filsystemet, kan klienten utstede RPC READ-forespørsler. Denne forespørselen består av en filbeskrivelse, en tilstand, en forskyvning og antall byte som skal leses. Klienten bruker tilstand ( stat) for å avgjøre om operasjonen kan utføres i øyeblikket, dvs. Er filen låst? Offset ( offset) indikerer i hvilken posisjon du skal begynne å lese, og byte-telleren ( telle) bestemmer hvor mange byte som må leses. Som et resultat av et RPC READ-kall returnerer ikke serveren alltid så mange byte som ble forespurt, men sammen med de returnerte dataene rapporterer den alltid hvor mange byte som ble sendt til klienten.

Innovasjon i NFS

De to siste versjonene av NFS er av størst interesse - 4 og 4.1, som eksempler på hvilke du kan studere de viktigste aspektene ved utviklingen av NFS-teknologi.

Før NFSv4 var tilgjengelig for å utføre filbehandlingsoppgaver som montering, låsing osv. det var spesielle tilleggsprotokoller. I NFSv4 ble filbehandlingsprosessen forenklet til en enkelt protokoll; I tillegg, fra og med denne versjonen, brukes ikke lenger UDP som en transportprotokoll. NFSv4 inkluderer støtte for UNIX- og Windows®-filtilgangssemantikk, slik at NFS kan integreres naturlig i andre operativsystemer.

NFSv4.1 introduserte konseptet parallell NFS(parallell NFS - pNFS). For å gi høyere nivåer av skalerbarhet implementerer NFSv4.1 en arkitektur der data og metadata ( merking) distribueres på tvers av enheter på en lignende måte som hvordan det gjøres i klyngede filsystemer. Som vist i , deler pNFS økosystemet inn i tre komponenter: klient, server og lagring. I dette tilfellet vises to kanaler: en for overføring av data, og den andre for overføring av kontrollkommandoer. pNFS skiller data fra metadataene som beskriver dem, og gir en to-kanals arkitektur. Når en klient vil ha tilgang til en fil, sender serveren den metadata med "markup". Metadata inneholder informasjon om plasseringen av filen på lagringsenheter. Når klienten har denne informasjonen, kan den få tilgang til lagringen direkte uten å måtte samhandle med serveren, noe som forbedrer skalerbarheten og ytelsen. Når klienten er ferdig med å jobbe med filen, bekrefter den endringene som er gjort i filen og dens "markup". Om nødvendig kan serveren be om metadata med markering fra klienten.

Med bruken av pNFS ble flere nye operasjoner lagt til NFS-protokollen for å støtte en slik mekanisme. LayoutGet-metoden brukes til å hente metadata fra serveren, LayoutReturn-metoden "frigjør" metadata "fanget" av klienten, og LayoutCommit-metoden laster "layouten" mottatt fra klienten til lagring slik at den er tilgjengelig for andre brukere. Serveren kan hente fram metadata fra klienten ved å bruke LayoutRecall-metoden. «Tagged» metadata distribueres over flere lagringsenheter for å gi parallell tilgang og høy ytelse.

Data og metadata lagres på lagringsenheter. Klienter kan utføre direkte I/O-forespørsler basert på den mottatte markeringen, og NFSv4.1-serveren lagrer og administrerer metadataene. Denne funksjonaliteten i seg selv er ikke ny, men støtte ble lagt til pNFS ulike metoder tilgang til lagringsenheter. I dag støtter pNFS bruk av blokkprotokoller (Fibre Channel), objektprotokoller og selve NFS (ikke engang i pNFS-form).

Utviklingen av NFS fortsetter, og i september 2010 ble krav til NFSv4.2 publisert. Noen av innovasjonene er relatert til den pågående migreringen av datalagringsteknologier mot virtualisering. For eksempel, i virtuelle miljøer med en hypervisor, er det svært sannsynlig at dataduplisering (flere operativsystemer som leser/skriver og bufrer de samme dataene) oppstår. På grunn av dette er det ønskelig for lagringssystemet som helhet å forstå hvor duplisering skjer. Denne tilnærmingen vil bidra til å spare klientbufferplass og total lagringskapasitet. NFSv4.2 foreslår å bruke et "blokkkart over delte blokker" for å løse dette problemet. Ettersom moderne lagringssystemer i økende grad kommer utstyrt med sin egen interne datakraft, introduseres kopiering på serversiden for å redusere belastningen med å kopiere data over et internt nettverk når det kan gjøres effektivt på selve lagringsenheten. Andre innovasjoner inkluderer underfilbufring for flash-minne og anbefalinger for I/O-innstilling på klientsiden (som bruk av mapadvise).

NFS-alternativer

Selv om NFS er det mest populære nettverksfilsystemet i UNIX og Linux, finnes det andre nettverksfilsystemer. På Windows®-plattformen er SMB mest brukt, også kjent som CIFS; Windows OS støtter imidlertid også NFS, så vel som Linux støtter SMB.

Et av de nyeste distribuerte filsystemene som støttes på Linux, Ceph, er designet fra grunnen av for å være et feiltolerant POSIX-kompatibelt filsystem. Mer informasjon om Ceph finner du i seksjonen.

Det er også verdt å nevne filsystemene OpenAFS (Open Source-versjon av Andrew distribuert filsystem, utviklet ved Carnegie Mellon University og IBM Corporation), GlusterFS (distribuert filsystem generelt formål for organisering av skalerbar datalagring) og Luster (et nettverksfilsystem med massiv parallellitet for klyngeløsninger). Alle disse åpen kildekode-systemene kan brukes til å bygge distribuert lagring.

Konklusjon

Utviklingen av NFS-filsystemet fortsetter. I likhet med Linux-operativsystemet, som kan støtte både low-end, innebygde og high-end-løsninger, tilbyr NFS en arkitektur for skalerbare lagringsløsninger som passer for både enkeltpersoner og organisasjoner. Når du ser på reisen NFS allerede har tatt og utsiktene for dens fremtidige utvikling, blir det klart at dette filsystemet vil fortsette å endre måten vi tenker på hvordan fillagringsteknologier implementeres og brukes.

God ettermiddag, lesere og gjester. Det var en veldig lang pause mellom innleggene, men jeg er tilbake i aksjon). I dagens artikkel skal jeg se på NFS-protokolloperasjon, og sette opp NFS-server og NFS-klient på Linux.

Introduksjon til NFS

NFS (Nettverksfilsystem - nettverksfilsystem) etter min mening - perfekt løsning på et lokalt nettverk, hvor det kreves rask (raskere sammenlignet med SAMBA og mindre ressurskrevende sammenlignet med eksterne filsystemer med kryptering - sshfs, SFTP osv...) datautveksling og sikkerheten til den overførte informasjonen ikke er i forkant . NFS-protokoll muliggjør montere eksterne filsystemer over nettverket i et lokalt katalogtre, som om det var et montert diskfilsystem. Dette gjør at lokale applikasjoner kan jobbe med et eksternt filsystem som om de var et lokalt. Men du må være forsiktig (!) med sette opp NFS, fordi med en viss konfigurasjon er det mulig å fryse klientens operativsystem mens du venter på endeløs I/O. NFS-protokoll arbeidsbasert RPC-protokoll, som fortsatt er utenfor min forståelse)) så materialet i artikkelen vil være litt vagt... Før du kan bruke NFS, enten det er en server eller en klient, må du sørge for at kjernen din har støtte for NFS-filen system. Du kan sjekke om kjernen støtter NFS-filsystemet ved å se på tilstedeværelsen av de tilsvarende linjene i filen /proc/filsystemer:

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

Hvis de angitte linjene i filen /proc/filsystemer ikke vises, må du installere pakkene beskrevet nedenfor. Dette vil mest sannsynlig tillate deg å installere avhengige kjernemoduler for å støtte de nødvendige filsystemene. Hvis NFS-støtte ikke vises i den angitte filen etter å ha installert pakkene, må du aktivere denne funksjonen.

Historie Nettverksfilsystem

NFS-protokoll utviklet av Sun Microsystems og har 4 versjoner i sin historie. NFSv1 ble utviklet i 1989 og var eksperimentell og kjørte på UDP-protokollen. Versjon 1 er beskrevet i . NFSv2 ble utgitt i samme 1989, beskrevet av samme RFC1094 og også basert på UDP-protokollen, samtidig som det ikke tillot mer enn 2 GB å bli lest fra en fil. NFSv3 ferdigstilt i 1995 og beskrevet i . De viktigste nyvinningene i den tredje versjonen var filstøtte stor størrelse, støtte for TCP-protokollen og store TCP-pakker ble lagt til, noe som betydelig akselererte ytelsen til teknologien. NFSv4 ferdigstilt i 2000 og beskrevet i RFC 3010, revidert i 2003 og beskrevet i . Den fjerde versjonen inkluderte ytelsesforbedringer, støtte for ulike autentiseringsmetoder (spesielt Kerberos og LIPKEY som bruker RPCSEC GSS-protokollen) og tilgangskontrolllister (både POSIX- og Windows-typer). NFS versjon v4.1 ble godkjent av IESG i 2010 og fikk nummeret . En viktig nyvinning i versjon 4.1 er spesifikasjonen av pNFS - Parallel NFS, en mekanisme for parallell NFS-klienttilgang til data fra flere distribuerte NFS-servere. Tilstedeværelsen av en slik mekanisme i nettverksfilsystemstandarden vil bidra til å bygge distribuerte "sky"-lagrings- og informasjonssystemer.

NFS server

Siden vi har NFS- Dette Nettverk filsystem, da nødvendig. (Du kan også lese artikkelen). Neste er nødvendig. På Debian er dette en pakke nfs-kjerneserver Og nfs-vanlig, i RedHat er dette en pakke nfs-utils. Og også, du må la demonen kjøre på de nødvendige OS-utførelsesnivåene (kommando i RedHat - /sbin/chkconfig nfs på, i Debian - /usr/sbin/update-rc.d nfs-kernel-server standarder).

Installerte pakker i Debian lanseres i følgende rekkefølge:

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx 1 rotrot 20. okt 18 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 rotrot 27. okt 22 01:23 S16nfs-server ->.kerne./it-server. /nfs-kjerneserver

Det vil si at den starter først nfs-vanlig, deretter selve serveren nfs-kjerneserver. I RedHat er situasjonen lik, med det eneste unntaket at det første skriptet kalles nfslock, og serveren kalles enkelt nfs. Om nfs-vanlig Debians nettsted forteller oss dette ordrett: delte filer for NFS-klient og -server, må denne pakken installeres på maskinen som skal fungere som en NFS-klient eller -server. Pakken inkluderer programmer: lockd, statd, showmount, nfsstat, gssd og idmapd. Viser innholdet i lanseringsskriptet /etc/init.d/nfs-common du kan spore følgende arbeidsrekkefølge: skriptet sjekker for tilstedeværelsen av en kjørbar binær fil /sbin/rpc.statd, ser etter tilstedeværelse i filer /etc/default/nfs-common, /etc/fstab Og /etc/exports parametere som krever kjørende demoner idmapd Og gssd , starter demonen /sbin/rpc.statd , deretter før lansering /usr/sbin/rpc.idmapd Og /usr/sbin/rpc.gssd sjekker for tilstedeværelsen av disse kjørbare filene binære filer, videre for daemon /usr/sbin/rpc.idmapd sjekker tilgjengelighet sunrpc,nfs Og nfsd, samt filsystemstøtte rpc_pipefs i kjernen (det vil si å ha den i filen /proc/filsystemer), hvis alt er vellykket, starter det /usr/sbin/rpc.idmapd . I tillegg for demonen /usr/sbin/rpc.gssd sjekker kjernemodul rpcsec_gss_krb5 og starter demonen.

Hvis du ser innholdet NFS server oppstartsskript på Debian ( /etc/init.d/nfs-kernel-server), så kan du følge følgende sekvens: ved oppstart sjekker skriptet eksistensen av filen /etc/exports, Tilgjengelighet nfsd, tilgjengelighet av støtte NFS filsystem i (det vil si i filen /proc/filsystemer), hvis alt er på plass, starter demonen /usr/sbin/rpc.nfsd , sjekker deretter om parameteren er spesifisert NEED_SVCGSD(sett i serverinnstillingsfilen /etc/default/nfs-kernel-server) og, hvis gitt, starter demonen /usr/sbin/rpc.svcgssd , starter demonen sist /usr/sbin/rpc.mountd . Fra dette manuset er det klart at NFS serverdrift består av daemoner rpc.nfsd, rpc.mountd og hvis Kerberos-autentisering brukes, så rcp.svcgssd-demonen. I den røde hatten kjører demonen rpc.rquotad og nfslogd fortsatt (av en eller annen grunn i Debian fant jeg ikke informasjon om denne demonen og årsakene til dens fravær, tilsynelatende ble den slettet...).

Av dette blir det klart at Network File System-serveren består av følgende prosesser (les: daemons), som ligger i katalogene /sbin og /usr/sbin:

I NFSv4, når du bruker Kerberos, startes flere demoner:

• rpc.gssd- NFSv4-demonen tilbyr autentiseringsmetoder via GSS-API (Kerberos-autentisering). Fungerer på klient og server.
• rpc.svcgssd- NFSv4-serverdaemon som gir klientautentisering på serversiden.

portmap og RPC-protokoll (Sun RPC)

I tillegg til pakkene ovenfor, krever NFSv2 og v3 tilleggspakke portkart(erstattet i nyere distribusjoner med omdøpt til rpcbind). Denne pakken installeres vanligvis automatisk med NFS som en avhengig pakke og implementerer driften av RPC-serveren, det vil si at den er ansvarlig for den dynamiske tilordningen av porter for noen tjenester registrert i RPC-serveren. Bokstavelig talt, ifølge dokumentasjonen, er dette en server som konverterer RPC-programnumre (Remote Procedure Call) til TCP/UDP-portnumre. portmap opererer på flere enheter: RPC-anrop eller -forespørsler, TCP/UDP-porter,protokollversjon(tcp eller udp), programnummer Og programvareversjoner. Portmap-daemonen lanseres av /etc/init.d/portmap-skriptet før NFS-tjenester starter.

Kort fortalt er jobben til en RPC-server (Remote Procedure Call) å behandle RPC-anrop (såkalte RPC-prosedyrer) fra lokale og eksterne prosesser. Ved å bruke RPC-anrop registrerer eller fjerner tjenester seg selv til/fra portmapperen (aka portmapper, aka portmap, aka portmapper, aka, i nye versjoner, rpcbind), og klienter bruker RPC-anrop for å sende forespørsler til portmapperen mottar nødvendig informasjon . Brukervennlige navn på programtjenester og deres tilsvarende nummer er definert i filen /etc/rpc. Så snart en tjeneste har sendt den korresponderende forespørselen og registrert seg på RPC-serveren i portmapperen, tilordner RPC-serveren til tjenesten TCP- og UDP-portene som tjenesten startet på og lagrer i kjernen den tilsvarende informasjonen om den kjørende tjenesten (navn), en unik nummertjeneste (i samsvar med /etc/rpc), om protokollen og porten som tjenesten kjører på og om versjonen av tjenesten og gir den spesifiserte informasjonen til klienter på forespørsel. Selve portkonverteren har et programnummer (100000), versjonsnummer - 2, TCP-port 111 og UDP-port 111. Over, når jeg spesifiserte sammensetningen av NFS-serverdemonene, indikerte jeg hoved-RPC-programnumrene. Jeg har sannsynligvis forvirret deg litt med dette avsnittet, så jeg vil si en grunnleggende setning som burde gjøre ting klart: hovedfunksjonen til en portkartlegger er å returnere, på forespørsel fra en klient som har oppgitt et RPC-programnummer ( eller RPC-programnummer) og versjon til ham (klienten) porten som det forespurte programmet kjører på. Følgelig, hvis en klient trenger å få tilgang til RPC med et spesifikt programnummer, må den først kontakte portkartprosessen på servermaskinen og bestemme kommunikasjonsportnummeret med RPC-tjenesten den trenger.

Driften av en RPC-server kan representeres ved følgende trinn:

1. Portomformeren skal starte først, vanligvis når systemet starter opp. Dette oppretter et TCP-endepunkt og åpner TCP-port 111. Det oppretter også et UDP-endepunkt som venter på at et UDP-datagram kommer til UDP-port 111.
2. Ved oppstart oppretter et program som kjører gjennom en RPC-server et TCP-endepunkt og et UDP-endepunkt for hver støttet versjon av programmet. (En RPC-server kan støtte flere versjoner. Klienten spesifiserer den nødvendige versjonen når RPC-anropet foretas.) Et dynamisk tilordnet portnummer tildeles hver versjon av tjenesten. Serveren logger hvert program, versjon, protokoll og portnummer ved å foreta riktig RPC-anrop.
3. Når RPC-klientprogrammet trenger å innhente den nødvendige informasjonen, kaller det portoppløsningsrutinen for å få det dynamisk tilordnede portnummeret for gitt program, versjon og protokoll.
4. Som svar på denne forespørselen returnerer nord et portnummer.
5. Klienten sender en RPC-forespørselsmelding til portnummeret oppnådd i trinn 4. Hvis UDP brukes, sender klienten ganske enkelt et UDP-datagram som inneholder RPC-utfordringsmeldingen til UDP-portnummeret som den forespurte tjenesten kjører på. Som svar sender tjenesten et UDP-datagram som inneholder en RPC-svarmelding. Hvis TCP brukes, åpner klienten aktivt til TCP-portnummeret til ønsket tjeneste og sender deretter en RPC-utfordringsmelding over den etablerte forbindelsen. Serveren svarer med en RPC-svarmelding på tilkoblingen.

For å få informasjon fra RPC-serveren, bruk verktøyet rpcinfo. Når du spesifiserer parametere -p vert programmet viser en liste over alle registrerte RPC-programmer på vertsverten. Uten å spesifisere verten, vil programmet vise tjenester på localhost. Eksempel:

ARCHIV ~ # rpcinfo -p prog-ma vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 59451 status 100024 1 tcp 108002 1 udp 10872 4 status 0n 4 0 021 3 udp 44310 nlockmgr 100021 4 udp 44310 nlockmgr 100021 1 tcp 44851 nlockmgr 100021 3 tcp 44851 nlockmgr 100021 4 tcp 44851 nlockmgr 100003 2 tcp 2049 nfs 100003 2 0 9 0 n 3 4 0 0 049 nfs 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100005 1 udp 51306 montert 100005 1 tcp 41405 montert 100005 2 udp 51306 montert 100005 2 tcp 41405 montert 100005 3 udp 51306 montert 100005 3 tcp 41405 montert

Som du kan se, viser rpcinfo (i kolonner fra venstre mot høyre) det registrerte programnummeret, versjonen, protokollen, porten og navnet. Ved å bruke rpcinfo kan du fjerne et programs registrering eller få informasjon om en spesifikk RPC-tjeneste (flere alternativer i man rpcinfo). Som du kan se, er portmapper-demoner versjon 2 registrert på udp- og tcp-porter, rpc.statd versjon 1 på udp- og tcp-porter, NFS lock manager versjoner 1,3,4, nfs server daemon versjon 2,3,4, også som mount daemon versjoner 1,2,3.

NFS-serveren (mer presist, rpc.nfsd-daemonen) mottar forespørsler fra klienten i form av UDP-datagrammer på port 2049. Selv om NFS arbeider med en port-resolver, som lar serveren bruke dynamisk tilordnede porter, er UDP-port 2049 hardkodet til NFS i de fleste implementeringer.

Network File System Protocol Operation

Montering av fjernkontroll NFS

Prosessen med å montere et eksternt NFS-filsystem kan representeres av følgende diagram:

Beskrivelse av NFS-protokollen ved montering av en ekstern katalog:

1. En RPC-server startes på serveren og klienten (vanligvis ved oppstart), betjent av portmapper-prosessen og registrert på tcp/111- og udp/111-portene.
2. Det lanseres tjenester (rpc.nfsd, rpc.statd, etc.), som er registrert på RPC-serveren og registrert på vilkårlige nettverksporter (hvis en statisk port ikke er spesifisert i tjenesteinnstillingene).
3. monteringskommandoen på klientdatamaskinen sender en monteringsforespørsel til kjernen nettverkskatalog som indikerer type filsystem, vert og selve katalogen, sender og danner kjernen en RPC-forespørsel til portmap-prosessen på NFS-serveren på port udp/111 (hvis muligheten til å jobbe via tcp ikke er satt på klienten)
4. NFS-serverkjernen spør RPC om tilstedeværelsen av rpc.mountd-demonen og returnerer nettverksporten som demonen kjører på til klientkjernen.
5. mount sender en RPC-forespørsel til porten som rpc.mountd kjører på. NFS-serveren kan nå validere en klient basert på IP-adressen og portnummeret for å se om klienten kan montere det angitte filsystemet.
6. Mount-demonen returnerer en beskrivelse av det forespurte filsystemet.
7. Klientens mount-kommando sender mount-systemkallet for å knytte filhåndtaket oppnådd i trinn 5 med det lokale monteringspunktet på klientens vert. Filhåndtaket er lagret i klientens NFS-kode, og fra nå av vil all tilgang fra brukerprosesser til filer på serverens filsystem bruke filhåndtaket som utgangspunkt.

Kommunikasjon mellom klient og NFS-server

En typisk tilgang til et eksternt filsystem kan beskrives som følger:

Beskrivelse av prosessen med å få tilgang til en fil som ligger på en NFS-server:

1. Klienten (brukerprosessen) bryr seg ikke om den har tilgang til en lokal fil eller en NFS-fil. Kjernen samhandler med maskinvare gjennom kjernemoduler eller innebygde systemanrop.
2. Kjernemodul kernel/fs/nfs/nfs.ko, som utfører funksjonene til en NFS-klient, sender RPC-forespørsler til NFS-serveren via TCP/IP-modulen. NFS bruker vanligvis UDP, men nyere implementeringer kan bruke TCP.
3. NFS-serveren mottar forespørsler fra klienten som UDP-datagrammer på port 2049. Selv om NFS kan fungere med en portløser, som lar serveren bruke dynamisk tilordnede porter, er UDP-port 2049 hardkodet til NFS i de fleste implementeringer.
4. Når NFS-serveren mottar en forespørsel fra en klient, sendes den til en lokal filtilgangsrutine, som gir tilgang til den lokale disken på serveren.
5. Resultatet av disktilgangen returneres til klienten.

Sette opp en NFS-server

Server Tuning består generelt av å spesifisere lokale kataloger som er tillatt å monteres av eksterne systemer i en fil /etc/exports. Denne handlingen kalles eksportkataloghierarki. De viktigste kildene til informasjon om eksporterte kataloger er følgende filer:

• /etc/exports- hovedkonfigurasjonsfilen som lagrer konfigurasjonen til de eksporterte katalogene. Brukes når du starter NFS og av exportfs-verktøyet.
• /var/lib/nfs/xtab- inneholder en liste over kataloger montert av eksterne klienter. Brukes av rpc.mountd-daemonen når en klient prøver å montere et hierarki (en mount-oppføring opprettes).
• /var/lib/nfs/etab- en liste over kataloger som kan monteres av eksterne systemer, som indikerer alle parameterne til de eksporterte katalogene.
• /var/lib/nfs/rmtab- en liste over kataloger som for øyeblikket ikke er ueksportert.
• /proc/fs/nfsd- et spesielt filsystem (kjerne 2.6) for å administrere NFS-serveren.
  • eksport- en liste over aktive eksporterte hierarkier og klienter som de ble eksportert til, samt parametere. Kjernen får denne informasjonen fra /var/lib/nfs/xtab.
  • tråder- inneholder antall tråder (kan også endres)
  • ved å bruke filehandle kan du få en peker til en fil
  • og så videre...
• /proc/net/rpc- inneholder "rå" statistikk, som kan fås ved hjelp av nfsstat, samt ulike cacher.
• /var/run/portmap_mapping- informasjon om tjenester registrert i RPC

Merk: Generelt, på Internett er det mange tolkninger og formuleringer av formålet med xtab, etab, rmtab filene, jeg vet ikke hvem jeg skal tro. Selv på http://nfs.sourceforge.net/ er tolkningen Ikke tydelig.

Sette opp filen /etc/exports

I det enkleste tilfellet er filen /etc/exports den eneste filen som krever redigering for å konfigurere NFS-serveren. Denne filen kontrollerer følgende aspekter:

• Hva slags kunder kan få tilgang til filer på serveren
• Hvilke hierarkier? kataloger på serveren kan nås av hver klient
• Hvordan blir tilpassede kundenavn vises til lokale brukernavn

Hver linje i eksportfilen har følgende format:

eksportpunkt klient1 (alternativer) [klient2(alternativer) ...]

Hvor eksportpunkt absolutt bane til det eksporterte kataloghierarkiet, klient1 - n navn på én eller flere klienter eller IP-adresser, atskilt med mellomrom, som har lov til å montere eksportpunkt . Alternativer beskriv monteringsregler for klient, spesifisert før alternativer .

Her er en typisk en eksport filkonfigurasjonseksempel:

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

I dette eksemplet har datamaskinfiler og 10.0.0.1 tilgang til eksportpunktet /archiv1, mens vertsfiler har lese-/skrivetilgang, og vert 10.0.0.1 og subnett 10.0.230.1/24 har skrivebeskyttet tilgang.

Vertsbeskrivelser i /etc/exports er tillatt i følgende format:

• Navnene på individuelle noder beskrives som filer eller files.DOMAIN.local.
• Domenemasken er beskrevet i følgende format: *DOMAIN.local inkluderer alle noder i DOMAIN.local-domenet.
• Subnett er spesifisert som IP-adresse/maskepar. For eksempel: 10.0.0.0/255.255.255.0 inkluderer alle noder hvis adresser begynner med 10.0.0.
• Angi navnet på @myclients-nettverksgruppen som har tilgang til ressursen (når du bruker en NIS-server)

Generelle alternativer for eksport av kataloghierarkier

Eksportfilen bruker følgende generelle alternativer(alternativer som brukes som standard i de fleste systemer er oppført først, ikke-standard i parentes):

• auth_nlm (no_auth_nlm) eller sikre_låser (usikre_låser)- spesifiserer at serveren skal kreve autentisering av låseforespørsler (ved hjelp av NFS Lock Manager-protokollen).
• nohide (skjul)- hvis serveren eksporterer to kataloghierarkier, med den ene nestet (montert) i den andre. Klienten må eksplisitt montere det andre (underordnede) hierarkiet, ellers vil det underordnede hierarkiets monteringspunkt vises som en tom katalog. Nohide-alternativet resulterer i et andre kataloghierarki uten en eksplisitt montering. ( Merk: Jeg kunne ikke få dette alternativet til å fungere...)
• ro(rw)- Tillater kun lese (skrive) forespørsler. (Til syvende og sist, om det er mulig å lese/skrive eller ikke bestemmes basert på filsystemrettigheter, og serveren er ikke i stand til å skille en forespørsel om å lese en fil fra en forespørsel om å utføre, så den tillater lesing hvis brukeren har lest eller utøve rettigheter.)
• sikker (usikker)- krever at NFS-forespørsler kommer fra sikre porter (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (no_subtree_check)- Hvis en underkatalog til filsystemet eksporteres, men ikke hele filsystemet, sjekker serveren om den forespurte filen er i den eksporterte underkatalogen. Deaktivering av verifisering reduserer sikkerheten, men øker dataoverføringshastigheten.
• sync (asynkron)- spesifiserer at serveren skal svare på forespørsler først etter at endringene gjort av disse forespørslene er skrevet til disken. Asynkroniseringsalternativet forteller serveren om ikke å vente på at informasjon skal skrives til disken, noe som forbedrer ytelsen, men reduserer påliteligheten fordi Ved tilkoblingsbrudd eller utstyrssvikt kan informasjon gå tapt.
• wdelay (ingen_wdelay)- instruerer serveren om å utsette utførelse av skriveforespørsler hvis en påfølgende skriveforespørsel venter, skrive data i større blokker. Dette forbedrer ytelsen når du sender store køer med skrivekommandoer. no_wdelay spesifiserer ikke å forsinke utførelsen av en skrivekommando, noe som kan være nyttig hvis serveren mottar et stort antall urelaterte kommandoer.

Eksporter symbolske lenker og enhetsfiler. Når du eksporterer et kataloghierarki som inneholder symbolske lenker, må koblingsobjektet være tilgjengelig for klientsystemet (eksternt), det vil si at én av følgende regler må være sanne:

Enhetsfilen tilhører grensesnittet. Når du eksporterer en enhetsfil, eksporteres dette grensesnittet. Hvis klientsystemet ikke har en enhet av samme type, vil ikke den eksporterte enheten fungere. På klientsystemet, når du monterer NFS-objekter, kan du bruke nodev-alternativet slik at enhetsfiler i de monterte katalogene ikke brukes.

Standardalternativer i ulike systemer kan variere, de kan sees i filen /var/lib/nfs/etab. Etter å ha beskrevet den eksporterte katalogen i /etc/exports og startet NFS-serveren på nytt, vil alle manglende alternativer (les: standardalternativer) reflekteres i /var/lib/nfs/etab-filen.

Alternativer for visning av bruker-ID (samsvarende).

For en bedre forståelse av følgende, vil jeg råde deg til å lese artikkelen. Hver Linux-bruker har sin egen UID og hoved-GID, som er beskrevet i filene /etc/passwd Og /etc/group. NFS-serveren antar at den eksterne vertens operativsystem har autentisert brukerne og tildelt dem riktig UID og GID. Eksport av filer gir brukere av klientsystemet samme tilgang til disse filene som om de var logget direkte på serveren. Følgelig, når en NFS-klient sender en forespørsel til serveren, bruker serveren UID og GID for å identifisere brukeren på det lokale systemet, noe som kan føre til noen problemer:

• en bruker har kanskje ikke samme identifikatorer på begge systemene og kan derfor få tilgang til en annen brukers filer.
• fordi Hvis rotbrukerens ID alltid er 0, blir denne brukeren tilordnet den lokale brukeren avhengig av de angitte alternativene.

Følgende alternativer setter reglene for visning av eksterne brukere i lokale:

• root_squash (ingen_root_squash)- Kl gitt alternativ root_squash, blir forespørsler fra root-brukeren tilordnet den anonyme uid/gid, eller til brukeren spesifisert i anonuid/anongid-parameteren.
• no_all_squash (alle_squash)- Endrer ikke UID/GID til den tilkoblede brukeren. Alternativ all_squash setter visningen av ALLE brukere (ikke bare root) som anonym eller spesifisert i parameteren anonuid/anongid.
• anonuid= UID Og anongid= GID - Angir eksplisitt UID/GID for den anonyme brukeren.
• map_static= /etc/file_maps_users - Spesifiserer en fil der du kan sette tilordning av ekstern UID/GID til lokal UID/GID.

Eksempel på bruk av en brukertilordningsfil:

ARCHIV ~ # cat /etc/file_maps_users # Brukertilordning # ekstern lokal kommentar uid 0-50 1002 # kartlegger brukere med ekstern UID 0-50 til lokal UID 1002 gid 0-50 1002 # kartlegger brukere med/span ekstern GID 0-50 til lokal GID 1002

NFS serveradministrasjon

NFS-serveren administreres ved hjelp av følgende verktøy:

• nfsstat
• showmsecure (usikker) montering

nfsstat: NFS- og RPC-statistikk

nfsstat-verktøyet lar deg se statistikk over RPC- og NFS-servere. Kommandoalternativene finner du i man nfsstat.

showmount: Vis NFS-statusinformasjon

showmount-verktøyet spør rpc.mountd-demonen på den eksterne verten om monterte filsystemer. Som standard returneres en sortert liste over klienter. Nøkler:

• --alle- en liste over klienter og monteringspunkter vises som indikerer hvor klienten monterte katalogen. Denne informasjonen er kanskje ikke pålitelig.
• --kataloger- en liste over monteringspunkter vises
• --eksport- en liste over eksporterte filsystemer vises fra nfsds synspunkt

Når du kjører showmount uten argumenter, vil informasjon om systemene som har tillatelse til å montere bli skrevet ut til konsollen lokale kataloger. For eksempel gir ARCHIV-verten oss en liste over eksporterte kataloger med IP-adressene til verter som har lov til å montere de angitte katalogene:

FILER ~ # showmount --exports archive Eksportliste for arkiv: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

Hvis du spesifiserer vertsnavnet/IP-en i argumentet, vil informasjon om denne verten vises:

ARCHIV ~ # showmount-filer clnt_create: RPC: Program ikke registrert # Denne meldingen forteller oss at NFSd-demonen ikke kjører på FILES-verten

exportfs: administrer eksporterte kataloger

Denne kommandoen betjener de eksporterte katalogene som er spesifisert i filen /etc/exports, ville det være mer nøyaktig å skrive at den ikke tjener, men synkroniserer med filen /var/lib/nfs/xtab og fjerner ikke-eksisterende fra xtab. exportfs kjøres når nfsd-demonen startes med -r-argumentet. Exportfs-verktøyet i 2.6 kjernemodus kommuniserer med rpc.mountd-demonen gjennom filer i /var/lib/nfs/-katalogen og kommuniserer ikke direkte med kjernen. Uten parametere, viser en liste over eksporterte filsystemer.

exportfs parametere:

• [klient:katalognavn] - legg til eller fjern det angitte filsystemet for den angitte klienten)
• -v - vise mer informasjon
• -r - re-eksporter alle kataloger (synkroniser /etc/exports og /var/lib/nfs/xtab)
• -u - fjern fra listen over eksporterte
• -a - legg til eller fjern alle filsystemer
• -o - alternativer atskilt med komma (ligner alternativene som brukes i /etc/exports; det vil si at du kan endre alternativene til allerede monterte filsystemer)
• -i - ikke bruk /etc/exports når du legger til, bare gjeldende kommandolinjealternativer
• -f - tilbakestill listen over eksporterte systemer i kjerne 2.6;

NFS-klient

Før du får tilgang til en fil på et eksternt filsystem, må klienten (klient-OS). monter den og motta fra serveren peker på det. NFS-feste kan gjøres med eller ved hjelp av en av de voksende automatiske montørene (amd, autofs, automount, supermount, superpupermount). Installasjonsprosessen er godt demonstrert i illustrasjonen ovenfor.

På NFS-klienter du trenger ikke å kjøre noen demoner, klientfunksjoner kjører en kjernemodul kernel/fs/nfs/nfs.ko, som brukes når du monterer et eksternt filsystem. Eksporterte kataloger fra serveren kan monteres på klienten på følgende måter:

• manuelt ved å bruke monteringskommandoen
• automatisk ved oppstart, når du monterer filsystemer beskrevet i /etc/fstab
• automatisk ved å bruke autofs-demonen

Jeg vil ikke vurdere den tredje metoden med autofs i denne artikkelen, på grunn av dens omfangsrike informasjon. Kanskje det kommer en egen beskrivelse i fremtidige artikler.

Montering av nettverksfilsystemet med mount-kommandoen

Et eksempel på bruk av mount-kommandoen er presentert i innlegget. Her vil jeg se på et eksempel på mount-kommandoen for å montere et NFS-filsystem:

FILER ~ # mount -t nfs archiv:/archiv-small /archivs/archiv-small FILES ~ # mount -t nfs -o ro archiv:/archiv-big /archivs/archiv-big FILES ~ # mount ..... .. archiv:/archiv-small på /archivs/archiv-small type nfs (rw,addr=10.0.0.6) archiv:/archiv-big på /archivs/archiv-big type nfs (ro,addr=10.0.0.6)

Den første kommandoen monterer den eksporterte katalogen /arkiv-liten på server arkiv til lokalt monteringspunkt /archivs/archiv-small med standardalternativer (dvs. les og skriv). Selv om mount kommando V siste distribusjoner kan forstå hvilken type filsystem som brukes selv uten å spesifisere typen, angi fortsatt parameteren -t nfsønskelig. Den andre kommandoen monterer den eksporterte katalogen /arkiv-stor på server arkiv til lokal katalog /archivs/archiv-big med skrivebeskyttet alternativ ( ro). mount kommando uten parametere viser den oss tydelig monteringsresultatet. I tillegg til skrivebeskyttet alternativ (ro), er det mulig å spesifisere andre Grunnleggende alternativer ved montering av NFS:

• nosuid- Dette alternativet forbyr kjøring av programmer fra den monterte katalogen.
• nodev(ingen enhet - ikke en enhet) - Dette alternativet forbyr bruk av tegn og blokkerer spesielle filer som enheter.
• lås (nolock)- Tillater NFS-låsing (standard). nolock deaktiverer NFS-låsing (starter ikke lockd-demonen) og er nyttig når du arbeider med eldre servere som ikke støtter NFS-låsing.
• mounthost=navn- Navnet på verten som NFS mount daemon kjører på - mountd.
• mountport=n - Port brukt av mountd-demonen.
• port=n- port som brukes til å koble til NFS-serveren (standard er 2049 hvis rpc.nfsd-demonen ikke er registrert på RPC-serveren). Hvis n=0 (standard), spør NFS portkartet på serveren for å bestemme porten.
• rsize=n(les blokkstørrelse - lese blokkstørrelse) - Antall byte lest om gangen fra NFS-serveren. Standard - 4096.
• wsize=n(skriveblokkstørrelse - skriveblokkstørrelse) - Antall byte skrevet om gangen til NFS-serveren. Standard - 4096.
• tcp eller utp- For å montere NFS, bruk henholdsvis TCP- eller UDP-protokollen.
• bg- Hvis du mister tilgangen til serveren, prøv igjen i bakgrunnen for ikke å blokkere systemoppstartsprosessen.
• fg- Hvis du mister tilgangen til serveren, prøv igjen i prioritetsmodus. Dette alternativet kan blokkere systemets oppstartsprosess ved å gjenta monteringsforsøk. Av denne grunn brukes fg-parameteren primært for feilsøking.

Alternativer som påvirker attributtbufring på NFS-monteringer

Filattributter, lagret i (inoder), som endringstid, størrelse, harde lenker, eier, endres vanligvis sjelden for vanlige filer og enda sjeldnere for kataloger. Mange programmer, som ls, får tilgang til filer skrivebeskyttet og endrer ikke filattributter eller innhold, men kaster bort systemressurser på dyre nettverksoperasjoner. For å unngå å sløse med ressurser, kan du cache disse attributtene. Kjernen bruker endringstiden til en fil for å bestemme om hurtigbufferen er utdatert ved å sammenligne endringstiden i hurtigbufferen og endringstiden til selve filen. Attributtbufferen oppdateres med jevne mellomrom i samsvar med de angitte parameterne:

• ac (noac) (attributtbuffer- attributt caching) - Tillater attributt caching (standard). Selv om noac-alternativet bremser serveren, unngår det at attributter er forfalt når flere klienter aktivt skriver informasjon til et felles hierarki.
• acdirmax=n (attributt cache katalogfil maksimum- maksimal attributtbufring for en katalogfil) - Maksimalt antall sekunder som NFS venter før oppdatering av katalogattributter (standard 60 sek.)
• acdirmin=n (attributt cache katalogfil minimum- Minimum attributtbufring for en katalogfil) - Minimum antall sekunder som NFS venter før oppdatering av katalogattributter (standard 30 sek.)
• acregmax=n (attributt cache vanlig fil maksimum- attributt caching maksimum for en vanlig fil) - Maksimalt antall sekunder som NFS venter før oppdatering av attributtene til en vanlig fil (standard 60 sek.)
• acregmin=n (attributt cache vanlig fil minimum- minimum attributtbufring for en vanlig fil) - Minimum antall sekunder som NFS venter før oppdatering av attributtene til en vanlig fil (standard 3 sekunder)
• acttimeo=n (tidsavbrudd for attributtbuffer- attributt caching timeout) - Erstatter verdiene for alle alternativene ovenfor. Hvis acttimeo ikke er spesifisert, overtar verdiene ovenfor standardverdiene.

NFS-feilhåndteringsalternativer

Følgende alternativer kontrollerer hva NFS gjør når det ikke er noe svar fra serveren eller når det oppstår I/O-feil:

• fg(bg) (forgrunnen- forgrunnen, bakgrunn- bakgrunn) - Forsøk på å montere en mislykket NFS i forgrunnen/bakgrunnen.
• hard myk)- viser meldingen "serveren svarer ikke" til konsollen når tidsavbruddet er nådd og fortsetter å forsøke å montere. Med opsjon gitt myk- under en timeout, informerer programmet som kalte operasjonen om en I/O-feil. (det anbefales å ikke bruke det myke alternativet)
• nointr (intr) (ingen avbrudd- ikke avbryt) - Tillater ikke signaler å avbryte filoperasjoner i et hardt montert kataloghierarki når et stort tidsavbrudd er nådd. intr- muliggjør avbrudd.
• retrans=n (gjenoverføringsverdi- retransmission verdi) - Etter n små timeouts genererer NFS en stor timeout (standard 3). Et stort tidsavbrudd stopper operasjoner eller skriver ut en "server svarer ikke"-melding til konsollen, avhengig av om det harde/myke alternativet er spesifisert.
• prøv på nytt=n (prøv igjen verdi- Prøv på nytt verdi) - Antall minutter NFS-tjenesten vil gjenta monteringsoperasjoner før de gir opp (standard 10000).
• timeo=n (tidsavbruddsverdi- timeout-verdi) - Antallet tideler av et sekund NFS-tjenesten venter før den sender på nytt i tilfelle RPC eller en liten timeout (standard 7). Denne verdien øker med hver timeout opptil maksimalt 60 sekunder eller til en stor timeout oppstår. Hvis nettverket er opptatt, serveren er treg, eller forespørselen går gjennom flere rutere eller gatewayer, kan en økning av denne verdien forbedre ytelsen.

Automatisk NFS-montering ved oppstart (beskrivelse av filsystemer i /etc/fstab)

Du kan velge den optimale timeo for en spesifikk verdi av den overførte pakken (rsize/wsize-verdier) ved å bruke ping-kommandoen:

FILER ~ # ping -s 32768 archiv PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) byte med data. 32776 byte fra archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0,931 ms 32776 byte fra archiv.domain.local (10.0.0.6): icmp_req=2 ttl=927 ms .357 ms . fra archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 tid=1,03 ms 32776 byte fra archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 tid=1,00 ms 32 .domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1,08 ms ^C --- archive.DOMAIN.local ping-statistikk --- 5 pakker overført, 5 mottatt, 0 % pakketap, tid 4006ms rtt min/avg/max/mdev = 0,931/1,002/1,083/0,061 ms

Som du kan se, når du sender en pakke med størrelse 32768 (32Kb), flyter reisetiden fra klienten til serveren og tilbake rundt 1 millisekund. Hvis denne tiden overskrider 200 ms, bør du tenke på å øke timeo-verdien slik at den overskrider bytteverdien med tre til fire ganger. Følgelig er det tilrådelig å gjøre denne testen under stor nettverksbelastning.

Starter NFS og setter opp brannmur

Notatet ble kopiert fra bloggen http://bog.pp.ru/work/NFS.html, som tusen takk for!!!

Kjør NFS-server, mount, block, quota og status med "riktige" porter (for brannmur)

• Det er tilrådelig å først avmontere alle ressurser på klienter
• stopp og deaktiver rpcidmapd fra å starte hvis du ikke planlegger å bruke NFSv4: chkconfig --nivå 345 rpcidmapd off service rpcidmapd stop
• om nødvendig, la portmap-, nfs- og nfslock-tjenestene starte: chkconfig --levels 345 portmap/rpcbind på chkconfig --levels 345 nfs på chkconfig --levels 345 nfslock på
• om nødvendig, stopp nfslock- og nfs-tjenestene, start portmap/rpcbind, last ut modulene tjenesten nfslock stop service nfs stop service portmap start # service rpcbind start umount /proc/fs/nfsd service rpcidmapd stop rmmod nfsd service autofs stop # somewhere later it må startes rmmod nfs rmmod nfs_acl rmmod lockd
• åpne porter i
  • for RPC: UDP/111, TCP/111
  • for NFS: UDP/2049, TCP/2049
  • for rpc.statd: UDP/4000, TCP/4000
  • for låst: UDP/4001, TCP/4001
  • for montert: UDP/4002, TCP/4002
  • for rpc.rquota: UDP/4003, TCP/4003
• for rpc.nfsd-serveren, legg til linjen RPCNFSDARGS="--port 2049" til /etc/sysconfig/nfs
• for monteringsserveren, legg til linjen MOUNTD_PORT=4002 til /etc/sysconfig/nfs
• for å konfigurere rpc.rquota for nye versjoner, må du legge til linjen RQUOTAD_PORT=4003 til /etc/sysconfig/nfs
• for å konfigurere rpc.rquota er det nødvendig for eldre versjoner (du må imidlertid ha kvotepakken 3.08 eller nyere) legg til /etc/services rquotad 4003/tcp rquotad 4003/udp
• vil sjekke tilstrekkeligheten til /etc/exports
• kjør tjenestene rpc.nfsd, mountd og rpc.rquota (rpcsvcgssd og rpc.idmapd lanseres samtidig, hvis du husker å slette dem) service nfsd start eller i nye versjoner service nfs start
• for blokkeringsserveren for nye systemer, legg til linjene LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001 til /etc/sysconfig/nfs
• for låseserveren for eldre systemer, legg til direkte i /etc/modprobe[.conf]: options lockd nlm_udpport=4001 nlm_tcpport=4001
• bind rpc.statd-statusserveren til port 4000 (for eldre systemer, kjør rpc.statd med -p 4000-nøkkelen i /etc/init.d/nfslock) STATD_PORT=4000
• start lockd- og rpc-tjenestene.statd-tjenesten nfslock start
• sørg for at alle porter er bundet normalt ved å bruke "lsof -i -n -P" og "netstat -a -n" (noen av portene brukes av kjernemoduler som lsof ikke ser)
• hvis serveren før "gjenoppbyggingen" ble brukt av klienter og de ikke kunne demonteres, må du starte de automatiske monteringstjenestene på klientene på nytt (am-utils, autofs)

Eksempel på NFS-server og klientkonfigurasjon

Serverkonfigurasjon

Hvis du vil gjøre din NFS delte katalog åpen og skrivbar, kan du bruke alternativet all_squash i kombinasjon med alternativer anonuid Og anongid. For å angi tillatelser for brukeren "ingen" i gruppen "ingen", kan du for eksempel gjøre følgende:

ARCHIV ~ # cat /etc/exports # Lese- og skrivetilgang for klient på 192.168.0.100, med rw-tilgang for bruker 99 med gid 99 /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99) # Lese- og skrivetilgang for klient på 192.168.0.100, med rw-tilgang for bruker 99 med gid 99 /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

Dette betyr også at hvis du vil tillate tilgang til den angitte katalogen, må nobody.nobody være eieren av den delte katalogen:

mann mount
mann eksporterer
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm - NFS-ytelse fra IBM.

Med vennlig hilsen, McSim!

Network File Server (NFS)-protokollen er en åpen standard for å gi ekstern brukertilgang til filsystemer. De sentraliserte filsystemene som er bygget på den, gjør daglige oppgaver som sikkerhetskopiering eller virusskanning enklere, og konsoliderte diskpartisjoner er enklere å vedlikeholde enn mange mindre, distribuerte.

I tillegg til å tilby sentralisert lagring, har NFS vist seg å være svært nyttig for andre applikasjoner, inkludert diskløse og tynne klienter, nettverksklynger og mellomvaresamarbeid.

En bedre forståelse av både selve protokollen og detaljene i implementeringen vil gjøre det lettere å takle praktiske problemer. Denne artikkelen er dedikert til NFS og består av to logiske deler: Først beskriver den selve protokollen og målene som er satt under utviklingen, og deretter implementeringen av NFS i Solaris og UNIX.

HVOR DET HELE BEGYNTE...

NFS-protokollen ble utviklet av Sun Microsystems og dukket opp på Internett i 1989 som RFC 1094 under følgende tittel: Network File System Protocol Specification (NFS). Det er interessant å merke seg at Novells strategi på den tiden var rettet mot ytterligere forbedring filtjenester. Inntil nylig, før åpen kildekode-bevegelsen tok av, var Sun motvillige til å dele hemmelighetene til nettverksløsningene sine, men allerede da forsto selskapet viktigheten av interoperabilitet med andre systemer.

RFC 1094 inneholdt to originale spesifikasjoner. På tidspunktet for publiseringen var Sun allerede i ferd med å utvikle den neste, tredje versjonen av spesifikasjonen, som er angitt i RFC 1813 "NFS Version 3 Protocol Specification". Versjon 4 av denne protokollen er definert i RFC 3010, NFS versjon 4-protokoll.

NFS er mye brukt på alle typer UNIX-verter, inkludert Microsoft-nettverk og Novell, samt i IBM-løsninger som AS400 og OS/390. Selv om det er ukjent utenfor nettverksriket, er NFS kanskje det mest utbredte plattformuavhengige nettverksfilsystemet.

UNIX VAR GENESIS

Selv om NFS er et plattformuavhengig system, er dets stamfar UNIX. Med andre ord, arkitekturens hierarkiske arkitektur og filtilgangsmetoder, inkludert filsystemstruktur, måter å identifisere brukere og grupper på, og filhåndteringsteknikker, er alle veldig like UNIX-filsystemet. For eksempel er NFS-filsystemet, som er strukturelt identisk med UNIX-filsystemet, montert direkte på det. Når du arbeider med NFS på andre operativsystemer, er brukeridentifikasjonsparametere og filtilgangsrettigheter underlagt kartlegging.

NFS

NFS-systemet er beregnet for bruk i klient-server-arkitektur. Klienten får tilgang til filsystemet eksportert av NFS-serveren gjennom et monteringspunkt på klienten. Denne tilgangen er vanligvis gjennomsiktig for klientapplikasjonen.

I motsetning til mange klient-serversystemer, bruker NFS Remote Procedure Calls (RPC) for å utveksle informasjon. Vanligvis etablerer en klient en forbindelse til en tidligere kjent port og sender deretter, i samsvar med protokollen, en forespørsel om å utføre en spesifikk handling. I tilfelle av eksterne prosedyrekall, oppretter klienten et prosedyrekall og sender det deretter til serveren for utførelse. En detaljert beskrivelse av NFS vil bli presentert nedenfor.

Som et eksempel, anta at en klient har montert usr2-katalogen på det lokale rotfilsystemet:

/root/usr2/ -> fjernkontroll:/root/usr/

Hvis en klientapplikasjon trenger ressurser fra denne katalogen, sender den ganske enkelt en forespørsel operativsystem til den og til filnavnet, og den gir tilgang gjennom NFS-klienten. Tenk for eksempel enkel kommando UNIX-cd, som "vet ingenting" om nettverksprotokoller. Team

Cd /root/usr2/

vil plassere arbeidskatalogen på et eksternt filsystem, "uten engang å innse" (brukeren har heller ikke behov for dette) at filsystemet er eksternt.

Etter å ha mottatt forespørselen, vil NFS-serveren sjekke om brukeren har rett til å utføre den forespurte handlingen, og hvis svaret er positivt, vil den utføre den.

La oss bli bedre kjent

Fra klientens synspunkt består prosessen med lokal montering av et eksternt filsystem ved hjelp av NFS av flere trinn. Som nevnt vil NFS-klienten utstede et eksternt prosedyrekall for å kjøre på serveren. Merk at i UNIX er klienten et enkelt program (monteringskommandoen), mens serveren faktisk er implementert som flere programmer med følgende minimumssett: en portmapper-tjeneste, en mount-demon og en NFS-server. .

Klientmonteringskommandoen kommuniserer først med serverens portoversettelsestjeneste, som lytter etter forespørsler på port 111. De fleste implementeringer av klientmonteringskommandoen støtter flere versjoner av NFS, noe som øker sannsynligheten for å finne en felles protokollversjon for klienten og serveren. Søket utføres med den høyeste versjonen, så når en vanlig er funnet, blir den automatisk den nyeste versjonen som støttes av klienten og serveren.

(Materialet som presenteres er fokusert på den tredje versjonen av NFS, siden den er den mest utbredte for øyeblikket. Den fjerde versjonen støttes ennå ikke av de fleste implementeringer.)

Serverens portoversettelsestjeneste svarer på forespørsler basert på den støttede protokollen og porten som mount-daemonen kjører på. Monteringsklientprogrammet etablerer først en tilkobling til servermonteringsdemonen og utsteder deretter monteringskommandoen til den via RPC. Hvis denne prosedyren er fullført, da klientapplikasjon kobler til NFS-serveren (port 2049) og får tilgang til det eksterne filsystemet ved å bruke en av de 20 eksterne prosedyrene som er definert i RFC 1813 og oppført i tabell 1.

Betydningen av de fleste kommandoer er intuitiv og forårsaker ingen problemer for systemadministratorer. Følgende liste, hentet ved hjelp av tcdump, illustrerer lesekommandoen generert av UNIX cat-kommandoen for å lese en fil med navnet test-fil:

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32.0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32.0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.3412h lookup 3h 2 4307 (DF) 10:30: 16.012729 eth0 192.168.1.254.3476097947: svar ok 128 oppslag fh 32.0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 lest fh 32.0/ 224307 4096 bytes @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 lest fh 32.0/ 224307 4096 bytes @ 0 10:30:16.013650 eth0 192.168.1.9283 lest: 0 DF 1.928131. 30:16.013650 eth0 192.168.1.254.3492875163 : svar ok 108 lest (DF)

NFS har tradisjonelt blitt implementert over UDP. Noen versjoner av NFS støtter imidlertid TCP (TCP-støtte er definert i protokollspesifikasjonen). Den største fordelen med TCP er en mer effektiv overføringsmekanisme i upålitelige nettverk. (Med UDP, hvis det oppstår en feil, sendes hele RPC-meldingen, bestående av flere UDP-pakker, på nytt. Med TCP sendes bare det ødelagte fragmentet på nytt.)

NFS TILGANG

NFS-implementeringer støtter vanligvis fire måter å gi tilgangsrettigheter på: gjennom bruker-/filattributter, på delt ressursnivå, på masternodenivå og som en kombinasjon av andre tilgangsmetoder.

Den første metoden er basert på UNIXs innebygde system med filtillatelser for en individuell bruker eller gruppe. For å forenkle vedlikeholdet bør bruker- og gruppeidentifikasjon være konsistent på tvers av alle NFS-klienter og -servere. Sikkerhet må vurderes nøye: NFS kan utilsiktet gi tilgang til filer som ikke var tiltenkt da de ble opprettet.

Tilgang på delt nivå lar deg begrense rettighetene til kun å tillate visse handlinger, uavhengig av fileierskap eller UNIX-privilegier. For eksempel kan arbeid med NFS-filsystemet begrenses til skrivebeskyttet. De fleste NFS-implementeringer lar deg begrense tilgangen på delt ressursnivå ytterligere til spesifikke brukere og/eller grupper. For eksempel har Human Resources-gruppen lov til å se informasjon og ingenting mer.

Master node nivå tilgang lar deg montere et filsystem kun på spesifikke noder, noe som generelt er en god idé siden filsystemer enkelt kan opprettes på alle NFS-aktiverte noder.

Kombinert tilgang kombinerer ganske enkelt de ovennevnte typene (for eksempel tilgang på delt nivå med tilgang gitt til en spesifikk bruker) eller lar brukere få tilgang til NFS kun fra en spesifikk node.

NFS I PINGVIN-STILEN

Linux-relatert materiale er basert på Red Hat 6.2 med kjerneversjon 2.4.9, som leveres med nfs-utils versjon 0.1.6. Det er også nyere versjoner: i skrivende stund denne artikkelen, mest Siste oppdatering nfs-utils pakkenummer var 0.3.1. Den kan lastes ned fra: .

nfs-utils-pakken inneholder følgende kjørbare filer: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount og statd.

Dessverre er NFS-støtte noen ganger en kilde til forvirring for Linux-administratorer fordi tilgjengeligheten til en bestemt funksjon er direkte avhengig av versjonsnumrene til både kjernen og nfs-utils-pakken. Heldigvis er ting bedre på dette området, med de nyeste distribusjonene inkludert de nyeste versjonene av begge. For tidligere utgivelser gir Seksjon 2.4 av NFS-HOWTO en komplett liste over systemfunksjonalitet tilgjengelig for hver kjerne- og nfs-utils-pakkekombinasjon. Utviklerne opprettholder bakoverkompatibilitet av pakken med tidligere versjoner, og legger stor vekt på å sikre sikkerhet og eliminere programvarefeil.

NFS-støtte bør startes under kjernekompilering. Om nødvendig bør muligheten til å jobbe med NFS versjon 3 legges til kjernen.

For distribusjoner som støtter linuxconf er det enkelt å konfigurere NFS-tjenester for både klienter og servere. Den raske måten å installere NFS ved hjelp av linuxconf gir imidlertid ikke informasjon om hvilke filer som ble opprettet eller redigert, noe som er svært viktig for administratoren å vite situasjonen i tilfelle systemfeil. NFS-arkitekturen på Linux er løst koblet til BSD-versjonen, så de nødvendige støttefilene og programmene er enkle å finne for administratorer som kjører BSD, Sun OS 2.5 eller tidligere versjoner av NFS.

/etc/exports-filen, som i tidligere versjoner av BSD, definerer filsystemene som NFS-klienter har tilgang til. I tillegg inneholder den en rekke tilleggsfunksjoner knyttet til administrasjons- og sikkerhetsproblemer, og gir administratoren et middel for finjustering. Dette tekstfil, bestående av oppføringer, tomme linjer eller kommenterte linjer (kommentarer begynner med et #-symbol).

La oss si at vi ønsker å gi klienter skrivebeskyttet tilgang til /home-katalogen på Lefty-noden. Dette vil tilsvare følgende oppføring i /etc/exports:

/hjem (ro)

Her må vi fortelle systemet hvilke kataloger vi skal gjøre tilgjengelige ved å bruke rpc.mountd mount daemon:

# exportfs -r exportfs: Det er ikke noe vertsnavn spesifisert i /home (ro), skriv inn *(ro) for å unngå advarselen #

Når kommandoen eksportfs kjøres, avgir kommandoen en advarsel om at /etc/exports ikke begrenser tilgangen til en bestemt node, og oppretter en tilsvarende oppføring i /var/lib/nfs/etab fra /etc/exports som forteller hvilke ressurser som kan vises med cat :

# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid= -2,anongid=-2)

Andre alternativer oppført i etab inkluderer standardverdiene som brukes av NFS. Detaljene vil bli beskrevet nedenfor. For å gi tilgang til /home-katalogen, må du starte de aktuelle NFS-tjenestene:

# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

Når som helst etter å ha startet mount daemon (rpc.mountd), sjekk separate filer tilgjengelig for utdata, kan du se innholdet i /proc/fs/nfs/exports-filen:

# cat /proc/fs/nfs/exports # Versjon 1.0 # Path Client(Flags) # IPs /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

Det samme kan sees ved å bruke showmount-kommandoen med parameteren -e:

# showmount -e Eksporter liste for lefty: /home (alle) #

For å hoppe litt frem, kan showmount-kommandoen også brukes til å bestemme alle monterte filsystemer, eller med andre ord for å finne ut hvilke noder som er NFS-klienter for systemet som kjører showmount-kommandoen. Kommandoen showmount -a vil vise alle klientmonteringspunkter:

# showmount -a Alle monteringspunkter på venstre: 192.168.1.252:/home #

Som nevnt ovenfor støtter de fleste NFS-implementeringer ulike versjoner av denne protokollen. Linux-implementeringen lar deg begrense listen over NFS-versjoner som kan startes ved å spesifisere -N-bryteren for mount daemon. For eksempel, for å kjøre NFS versjon 3, og bare versjon 3, skriv inn følgende kommando:

# rpc.mountd -N 1 -N 2

Hyppige brukere kan finne det upraktisk at Linuxs NFS-demon (rpc.nfsd) venter på versjon 1 og versjon 2-pakker, selv om dette har den ønskede effekten av ikke å støtte den tilsvarende protokollen. La oss håpe at utviklerne av fremtidige versjoner vil gjøre de nødvendige korreksjonene og vil være i stand til å oppnå større konsistens mellom komponentene i pakken i forhold til forskjellige versjoner av protokollen.

"SVØM MED PINGVINER"

Tilgang til Lefty konfigurert ovenfor, et Linux-basert NFS eksporterbart filsystem, avhenger av klientoperativsystemet. Installasjonsstilen for de fleste operativsystemer i UNIX-familien faller sammen med stilen til begge kildesystemer Sun OS og BSD, eller nyere Solaris. Fordi denne artikkelen er viet til begge systemene, Linux og Solaris, la oss se på Solaris 2.6-klientkonfigurasjonen fra synspunktet om å etablere en forbindelse med Linux-versjonen av NFS, som vi beskrev ovenfor.

Takket være funksjoner som er arvet fra Solaris 2.6, kan den enkelt konfigureres til å fungere som en NFS-klient. Dette krever bare én kommando:

# mount -F nfs 192.168.1.254:/home /tmp/tmp2

Forutsatt at den forrige monteringskommandoen var vellykket, vil monteringskommandoen uten parametere sende ut følgende:

# mount / on /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home read/ write/remote on Man 3. september 23:19:25 2001

La oss analysere tcpdump-utgangen mottatt på Lefty-noden etter at brukeren utstedte ls /tmp/tmp2-kommandoen på Sunny-noden:

# tcpdump vert lefty og host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Ukjent/1 (DF) 06:07:43.490678 lefty.mcwrite.n.nfs >. 2191983953: svar ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.n.DF00s: 13201s: 13200 7 :43.491463 venstre. mcwrite.n.nfs > sunny.2191983954: svar ok 120 tilgang c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus .9fh 07 by 800 00 000000 (DF) 06 :07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: svar ok 1000 readdirplus (DF)

Vi ser at noden Sunny ber om et filhåndtak (fh) for ls, som noden Lefty svarer med OK og returnerer katalogstrukturen. Sunny sjekker deretter tillatelsen til å få tilgang til innholdet i katalogen (132 tilgang fh) og mottar et tillatelsessvar fra Lefty. Sunny-noden leser deretter hele innholdet i katalogen ved hjelp av readdirplus-rutinen. Fjernprosedyreanrop er beskrevet i RFC 1813 og er oppført i begynnelsen av denne artikkelen.

Selv om kommandosekvensen for tilgang til eksterne filsystemer er veldig enkel, kan en rekke omstendigheter føre til at systemet ikke blir riktig montert. Før du monterer en katalog, må monteringspunktet allerede eksistere, ellers må det opprettes ved å bruke mkdir-kommandoen. Vanligvis er den eneste årsaken til feil på klientsiden mangelen på en lokal monteringskatalog. De fleste problemer knyttet til NFS skyldes uoverensstemmelse mellom klient og server eller feil serverkonfigurasjon.

Den enkleste måten å feilsøke problemer på en server på er fra noden serveren kjører på. Men når noen andre administrerer serveren for deg, er dette ikke alltid mulig. En rask måte å sikre at de riktige servertjenestene er riktig konfigurert er å bruke rpcinfo-kommandoen med -p-alternativet. Fra Solaris Sunny-verten kan du bestemme hvilke RPC-prosesser som er registrert på Linux-verten:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 090t status 100024 090t 4 udp 5 d /100005 3 tcp 1024 montert 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Merk at versjonsinformasjon også er gitt her, noe som er ganske nyttig når systemet krever støtte for ulike NFS-protokoller. Hvis en tjeneste ikke kjører på serveren, må denne situasjonen rettes opp. Hvis monteringen mislykkes, vil følgende rpcinfo -p-kommando hjelpe deg med å finne ut at mountd-tjenesten på serveren ikke kjører:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

Kommandoen rpcinfo er veldig nyttig for å finne ut om en bestemt ekstern prosess er aktiv. Parameteren -p er den viktigste av bryterne. For å se alle funksjonene til rpcinfo, se man-siden.

Et annet nyttig verktøy er nfsstat-kommandoen. Med dens hjelp kan du finne ut om klienter faktisk får tilgang til det eksporterte filsystemet, og også vise statistisk informasjon i samsvar med protokollversjonen.

Til slutt, et annet ganske nyttig verktøy for å bestemme årsakene til systemfeil er tcpdump:

# tcpdump vert lefty og host sunny -s512 tcpdump: lytter på eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF) :8196. lefty.mcwrite.n.nfs > sunny.2191984020: svar ok 116 lookup FEIL: Ingen slik fil eller katalog (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.28 getattr: (fh18 getattr: DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: svar ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 0000001000 (DF) 0000001000 (DF) 0000001000 (DF) 0000001000 (DF) 0000001000 (DF) 0016.205:259:259:2819:2819:289:2519 .mcwrite.n.nfs : 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: svar ok 116 lookup FEIL: Ingen slik fil eller katalog (DF) 06:29: 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create fh Ukjent/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.402191 rep. Tillatelse nektet (DF)

Listen ovenfor, produsert ved å utføre berøringstest.c-setningen, viser følgende handlingssekvens: først prøver berøringskommandoen å få tilgang til en fil som heter test.c, så ser den etter en katalog med samme navn, og etter mislykkede forsøk den prøver å lage en fil test.c , som heller ikke fører til suksess.

Hvis filsystemet er montert, er de vanligste feilene knyttet til vanlige UNIX-tillatelser. Ved å bruke en uid eller NIS+ på Sun unngår du å angi tillatelser globalt på alle filsystemer. Noen administratorer praktiserer «åpne» kataloger, der lesetilgang gis til «hele verden». Dette bør imidlertid unngås av sikkerhetsmessige årsaker. Bortsett fra sikkerhetshensyn, er denne tilnærmingen fortsatt en dårlig praksis, siden brukere sjelden oppretter data med den hensikt å gjøre dem lesbare for alle.

Tilgang for en privilegert bruker (root) til monterte NFS-filsystemer behandles annerledes. For å unngå å gi en privilegert bruker ubegrenset tilgang, blir forespørsler fra den privilegerte brukeren behandlet som om de kom fra brukeren ingen. Denne kraftige mekanismen begrenser privilegert brukertilgang til globalt lesbare og skrivbare filer.

NFS SERVER SOLARIS VERSJON

Å konfigurere Solaris til å fungere som en NFS-server er like enkelt som det er med Linux. Kommandoene og filplasseringene er imidlertid litt forskjellige. På Støvelhempe Solaris, når kjørenivå 3 er nådd, startes NFS-tjenester automatisk og alle filsystemer eksporteres. For å starte disse prosessene manuelt, skriv inn kommandoen:

#/usr/lib/nfs/mountd

For å starte mount daemon og NFS-serveren, skriv inn:

#/usr/lib/nfs/nfsd

Fra og med versjon 2.6 bruker ikke Solaris lenger en eksportfil for å spesifisere hvilke filsystemer som skal eksporteres. Filene eksporteres nå ved hjelp av share-kommandoen. La oss si at vi vil tillate eksterne verter å montere /export/home. For å gjøre dette, skriv inn følgende kommando:

Del -F nfs /export/home

Sikkerhetstiltak

SIKKERHET I LINUX

Noen Linux-baserte NFS-systemtjenester har en ekstra tilgangsbegrensningsmekanisme gjennom kontrolllister eller tabeller. På det interne nivået er denne mekanismen implementert ved å bruke tcp_wrapper-biblioteket, som bruker to filer for å generere tilgangskontrolllister: /etc/hosts.allow og /etc/hosts/deny. En uttømmende oversikt over reglene for arbeid med tcp_wrapper ligger utenfor denne artikkelens omfang, men det grunnleggende prinsippet er som følger: sammenligningen gjøres først med etc/hosts.allow, og deretter med /etc/hosts. benekte. Hvis regelen ikke blir funnet, vises ikke den forespurte systemtjenesten. For å komme rundt dette siste kravet og gi et veldig høyt sikkerhetsnivå, kan du legge til følgende oppføring på slutten av /etc/hosts.deny:

ALLE: Alle

Etter dette kan du bruke /etc/hosts.allow for å sette en eller annen driftsmodus. For eksempel filen /etc/hosts. tillat, som jeg brukte da jeg skrev denne artikkelen, inneholdt følgende linjer:

Lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:1912.168.5 stat.29.192.168.5 168.1.0/255.255.255.0

I dette tilfellet er det tillatt bestemt type tilgang til noder før tilgang på applikasjonsnivå gis. På Linux kontrolleres tilgang på applikasjonsnivå av filen /etc/exports. Den består av oppføringer i følgende format:

Eksporter katalog (mellomrom) vert|nettverk (alternativer)

En "eksportkatalog" er en katalog som nfsd-demonen har lov til å behandle forespørsler om. Et "node|nettverk" er noden eller nettverket som har tilgang til det eksporterte filsystemet, og "alternativene" definerer begrensningene som nfsd-demonen pålegger bruken av denne delte ressursen - skrivebeskyttet tilgang eller bruker-ID-tilordning. .

Følgende eksempel gir hele mcwrite.net-domenet skrivebeskyttet tilgang til /home/mcwrite.net:

/home/mcwrite.net *.mcwrite.net(ro)

Flere eksempler finner du på man-siden for eksport.

NFS SIKKERHET I SOLARIS

I Solaris er muligheten til å gi tilgang til NFS lik Linux, men i dette tilfellet settes begrensninger ved hjelp av visse parametere i share-kommandoen med -o-bryteren. Følgende eksempel viser hvordan du aktiverer skrivebeskyttet montering av /export/mcwrite.net på en hvilken som helst vert i mcwrite.net-domenet:

#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net

Man-siden for share_nfs detaljer som gir tilgang ved hjelp av kontrolllister på Solaris.

Internett-ressurser

NFS og RPC er ikke uten hull. Generelt sett bør ikke NFS brukes når du surfer på Internett. Du kan ikke stikke hull i brannmurer for å tillate noen form for tilgang via NFS. Det er viktig å følge nøye med på eventuelle nye RPC- og NFS-oppdateringer, og mange kilder til sikkerhetsinformasjon kan hjelpe. De to mest populære kildene er Bugtraq og CERT:

Den første kan sees regelmessig på jakt etter nødvendig informasjon eller ved å abonnere på periodiske nyhetsbrev. Den andre gir kanskje ikke like rask informasjon sammenlignet med andre, men i et ganske fullstendig volum og uten skyggen av sensasjonalitet som er karakteristisk for enkelte nettsteder dedikert til informasjonssikkerhet.

Kapittel 29 NFS: Nettverksfilsystem

Introduksjon

I dette kapittelet skal vi se på Network File System (NFS), et populært program som gir klientapplikasjoner gjennomsiktig tilgang til filer. Hjørnesteinen i NFS er Sun RPC: Remote Procedure Call, som vi først skal dekke.

Klientprogrammet krever ikke spesialverktøy for å dra nytte av NFS. Kjernen oppdager at filen er på en NFS-server og genererer automatisk RPC-anrop, for å få tilgang til filen.

Vi skal ikke se nærmere på hvordan filtilgang er implementert, men skal se på hvordan Internett-protokoller brukes, spesielt UDP.

Sun Remote Procedure Call

I de fleste tilfeller løses problemer med nettverksprogrammering ved å skrive applikasjonsprogrammer som kaller opp funksjoner levert av systemet for å utføre spesifikke nettverksoperasjoner. For eksempel utfører en funksjon en aktiv TCP-åpning, en annen en passiv TCP-åpning, en tredje sender data over en TCP-forbindelse, en fjerde setter spesifikke protokollalternativer (aktiverer TCP-timeren "stay alive"), og så videre. I avsnittet Application Programming Interfaces i kapittel 1 nevnte vi at det er to populære sett med n(applikasjonsprogrammeringsgrensesnitt, APIer): sockets og TLI. API-en som brukes av klienten og API-en som brukes av serveren kan variere, og det samme kan operativsystemene som klienten og serveren kjører. Det er kommunikasjons- og applikasjonsprotokollene som bestemmer om en bestemt klient kan kommunisere med serveren. En Unix-klient skrevet i C med sockets som programmeringsgrensesnitt og TCP som kommunikasjonsprotokoll kan kommunisere med en stormaskinserver skrevet i COBOL ved å bruke forskjellige APIer og TCP hvis begge vertene er koblet til nettverket og begge har en TCP-implementering. /IP.

Vanligvis sender klienten kommandoer til serveren, og serveren sender svar til klienten. Alle applikasjonene vi har vurdert - Ping, Traceroute, rutingdemoner, DNS-klienter og servere, TFTP, BOOTP, SNMP, Telnet, FTP, SMTP - er alle bygget på denne måten.

RPC, ekstern prosedyrekall, implementerer en annen tilnærming til nettverksprogrammering. Klientprogrammet kaller ganske enkelt funksjoner i serverprogrammet. Så dette bestemmes fra programmererens synspunkt, men i virkeligheten finner følgende handlingssekvens sted.

1. Når en klient kaller en ekstern prosedyre, kalles en funksjon på den lokale verten som genereres av RPC-pakken. Denne funksjonen kalles klientstubb. klientstubb pakker prosedyreargumenter inn i nettverksmelding og sender en melding til serveren.
2. serverstubben på serververten mottar nettverksmeldingen. Argumentene hentes fra nettverksmeldingen og et kall blir gjort til serverprosedyren skrevet av applikasjonsprogrammereren.
3. Serverfunksjonen returnerer kontrollen til serverstubben, som igjen tar de mottatte verdiene, pakker dem inn i en nettverksmelding og sender meldingen tilbake til klientstubben.
4. klientstubb returnerer verdier fra en nettverksmelding til klientapplikasjonen.

Nettverksprogrammering ved hjelp av stubber og bibliotek-RPC-rutiner bruker APIer (sockets eller TLI), men brukerapplikasjoner (klientprogrammet og serverprosedyrene kalt av klienten) får aldri tilgang til APIen. Klientapplikasjonen trenger bare å kalle serverprosedyren, mens alle implementeringsdetaljer skjules av RPC-pakken, klientstubben og serverstubben.

RPC-pakker har følgende fordeler.

• Programmering blir enklere fordi du ikke trenger å løse (og hvis du gjør det, er det veldig lite). Applikasjonsprogrammerere skriver ganske enkelt klientprogrammet og serverprosedyrene som klienten kaller.
• Hvis en upålitelig protokoll som UDP brukes, håndteres alle detaljene, nemlig tidsavbrudd og reoverføringer, av RPC-pakken. Dette forenkler igjen brukerapplikasjonen.
• RPC-biblioteket håndterer nødvendig konvertering av argumenter og returverdier. For eksempel, hvis argumentene består av heltall og flyttall, vil RPC-pakken håndtere eventuelle forskjeller mellom representasjonen av heltall og flytende tall på klienten og serveren. Dette forenkler implementeringen av klienter og servere for å operere i heterogene miljøer.

RPC-programmering er dekket i detalj i kapittel 18. De to mest populære RPC-pakkene er Sun RPC og RPC-pakken i Open Software Foundations (OSF) Distributed Computing Environment (DCE) Vi skal se på hvordan prosedyren kalles, hvordan returmeldingen ser ut og hvordan dette forholder seg til Sun RPC-pakken, siden det er denne pakken som brukes i nettverksfilsystemet Sun RPC versjon 2 er beskrevet i RFC 1057 [Sun Microsystems 1988a].

Det finnes to typer Sun RPC. En versjon er bygget ved hjelp av sockets API og fungerer med TCP og UDP. Den andre kalles TI-RPC (transportuavhengig), bygget ved hjelp av TLI API og fungerer med alle transportlag levert av kjernen. Fra vårt synspunkt er det ingen forskjell mellom dem, siden vi i dette kapittelet kun tar for oss TCP og UDP.

Figur 29.1 viser formatet til en RPC-prosedyrekallmelding ved bruk av UDP.

Figur 29.1 RPC-prosedyreanropsmeldinger i UDP-datagramformat.

Standard IP- og UDP-hoder er vist tidligere (Figur 3.1 og Figur 11.2). Alt som følger UDP-headeren bestemmes av RPC-pakken.

Transaksjonsidentifikatoren (XID - transaksjons-ID) settes av klienten og returneres av serveren. Når klienten mottar et svar, sammenligner den XID-en returnert av serveren med XID-en til forespørselen som ble sendt. Hvis de ikke stemmer overens, forkaster klienten meldingen og venter på at den neste kommer. Hver gang klienten utsteder en ny RPC, endrer den XID. Imidlertid, hvis klienten sender RPC-en på nytt (hvis ingen respons ble mottatt), endres ikke XID.

Anropsvariabelen er 0 for et anrop og 1 for et svar. Gjeldende versjon RPC-versjon er 2. De neste tre variablene, programnummer, versjonsnummer og prosedyrenummer, identifiserer den spesifikke prosedyren som skal kalles på serveren.

Legitimasjon identifiserer klienten. I noen eksempler er dette feltet tomt, mens du i andre kan se brukerens digitale identifikator og gruppeidentifikatoren han tilhører. Serveren kan se på legitimasjonen og bestemme om forespørselen skal behandles eller ikke. Verifier brukes for Secure RPC, som bruker DES-kryptering. Selv om autoritets- og valideringsfeltene er felt med variabel lengde, sendes lengden deres som en del av feltet.

Neste er prosedyreparametrene. Formatet deres avhenger av hvordan applikasjonen definerer fjernprosedyren. Hvordan vet mottakeren (serverstubben) størrelsen på parameterne? Siden UDP brukes, kan størrelsen på parameterne beregnes som størrelsen på UDP-datagrammet minus lengden på alle feltene opp til avkrysningsfeltet. Når TCP brukes i stedet for UDP, er det ikke noe konsept for en fast lengde, siden TCP er en strøm av byte uten postskilletegn. I et slikt tilfelle vises et 4-byte lengdefelt mellom TCP-overskriften og XID-en, hvorfra mottakeren lærer lengden på RPC-anropet i byte. Dette gjør at RPC-anropsmeldingen kan sendes over flere TCP-segmenter om nødvendig. (DNS bruker en lignende teknikk; øvelse 4 i kapittel 14.)

Figur 29.2 viser RPC-svarformatet. Den sendes fra serverstubben til klientstubben når den eksterne prosedyren avsluttes.

Figur 29.2 RPC-prosedyre svarmeldingsformat som et UDP-datagram.

Anrops XID kopieres ganske enkelt inn i svar XID. Svarfeltet inneholder 1, dette feltet skiller mellom en utfordring og en respons. Statusfeltet inneholder en nullverdi hvis anropsmeldingen er akseptert. (Meldingen kan bli forkastet hvis RPC-versjonsnummeret ikke er 2 eller hvis serveren ikke kan autentisere klienten.) Verifikatorfeltet brukes i tilfelle sikker RPC for å indikere serveren.

Godta statusfeltet inneholder en nullverdi hvis alt er i orden. En verdi som ikke er null kan for eksempel indikere et feil versjonsnummer eller et feil prosedyrenummer. Hvis TCP brukes i stedet for UDP, vil, som med RPC-utfordringsmeldingen, et 4-byte lengdefelt sendes mellom TCP-hodet og XID.

XDR: Ekstern datarepresentasjon

External Data Representation (XDR) er en standard som brukes til å kode verdier i RPC-anrop og svarmeldinger - RPC-headerfelt (XID, programnummer, mottaksstatus, etc.), prosedyreparametere og prosedyreresultater. En standard måte å kode data på lar en klient kalle en prosedyre på et system med en annen arkitektur. XDR er definert i RFC 1014 [Sun Microsystems 1987].

XDR definerer et visst antall datatyper og den nøyaktige måten de bæres i en RPC-melding (bitrekkefølge, byte-rekkefølge, og så videre). Avsenderen må konstruere RPC-meldingen i XDR-format, deretter konverterer mottakeren XDR-formatet til den opprinnelige representasjonen. (I formatet som er akseptert for systemet hans.) Vi ser for eksempel i figur 29.1 og 29.2 at alle heltallsverdiene vi viste (XID, anrop, programnummer og så videre) er 4-byte heltall . Faktisk opptar alle heltall i XDR 4 byte. XDR støtter andre datatyper, inkludert usignert heltall, boolsk, flytende komma, arrayer med fast lengde, arrayer med variabel lengde og strukturer.

Havneoverholdelse

RPC-serverprogrammer som inneholder eksterne prosedyrer bruker dynamisk tilordnede porter i stedet for forhåndskjente porter. Dette krever en form for "logging" for å alltid vite hvilken dynamisk tilordnet port som brukes av hvilket RPC-program. I Sun RPC kalles denne loggeren en portmapper. (En portmapper er en server som konverterer RPC-programnumre til DARPA-protokollportnumre. Denne serveren må kjøre for å kunne foreta et RPC-anrop.)

Begrepet "port" i navnet kommer fra TCP- og UDP-portnumrene, egenskapene til Internett-protokollfamilien. Siden TI-RPC kjører over alle transportlag, ikke bare TCP og UDP, har navneportkartleggingen på systemer som bruker TI-RPC (for eksempel SVR4 og Solaris 2.2) blitt konvertert til rpcbind. Vi vil imidlertid fortsette å bruke den mer kjente portkartleggeren.

Faktisk må portresolveren selv ha en kjent port: UDP-port 111 og TCP-port 111. Port-resolveren er bare et RPC-serverprogram. Den har et programnummer (100000), versjonsnummer (2), TCP-port 111 og UDP-port 111. Servere registrerer hverandre med portløseren ved hjelp av RPC-anrop, og klienter ber om portløseren ved hjelp av RPC-anrop. Portløseren har fire serverprosedyrer:

1. PMAPPROC_SET. Ringt opp av RPC-serveren ved oppstart for å registrere programnummer, versjonsnummer og protokoll med port-resolveren.
2. PMAPPROC_UNSET. Kalt opp av serveren for å fjerne en tidligere registrert transformasjon.
3. PMAPPROC_GETPORT. Ringes opp av RPC-klienten ved oppstart for å få portnummeret for gitt programnummer, versjonsnummer og protokoll.
4. PMAPPROC_DUMP. Returnerer alle elementer (programnummer, versjonsnummer, protokoll og portnummer) til port-resolver-databasen.

Når RPC-serverprogrammet starter og senere når det kalles opp av RPC-klientprogrammet, skjer følgende trinn.

1. Portomformeren skal starte først, vanligvis når systemet starter opp. Dette oppretter et TCP-endepunkt og åpner passivt TCP-port 111. Det oppretter også et UDP-endepunkt som venter på at et UDP-datagram kommer til UDP-port 111.
2. Når RPC-serverprogrammet starter, oppretter det et TCP-endepunkt og et UDP-endepunkt for hver støttet versjon av programmet. (Et RPC-program kan støtte flere versjoner. Klienten spesifiserer den nødvendige versjonen når serverprosedyren kalles.) Et dynamisk tilordnet portnummer tildeles hvert endepunkt. (Det spiller ingen rolle om TCP- og UDP-portnumrene er like eller forskjellige.) Serveren registrerer hvert program, versjon, protokoll og portnummer ved å foreta et eksternt anrop til PMAPPROC_SET-portløsningsprosedyren.
3. Når RPC-klientprogrammet starter, kaller det portløserprosedyren PMAPPROC_GETPORT for å få det dynamisk tilordnede portnummeret for det angitte programmet, versjonen og protokollen.
4. Klienten sender en RPC-utfordringsmelding til portnummeret hentet i trinn 3. Hvis UDP brukes, sender klienten ganske enkelt et UDP-datagram som inneholder RPC-utfordringsmeldingen (Figur 29.1) til serverens UDP-portnummer. Som svar sender serveren et UDP-datagram som inneholder en RPC-svarmelding (Figur 29.2). Hvis TCP brukes, gjør klienten en aktiv åpning til serverens TCP-portnummer og sender deretter en RPC-utfordringsmelding over tilkoblingen. Serveren svarer med en RPC-svarmelding på tilkoblingen.

Programmet rpcinfo(8) skriver ut alle gjeldende portkartleggingsinnstillinger. (Det er her portmapper-rutinen PMAPPROC_DUMP kalles.) Den typiske utgangen er vist nedenfor:

Sol% /usr/etc/rpcinfo -p
program vers proto port
100005 1 tcp 702 mountd NFS mount daemon
100005 1 utp 699 montert
100005 2 tcp 702 montert
100005 2 utp 699 montert

100003 2 udp 2049 nfs NFS selv

100021 1 tcp 709 nlockmgr NFS lock manager
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

Vi ser at noen programmer støtter flere versjoner, og hver kombinasjon av programnummer, versjonsnummer og protokoll har sitt eget portnummeroppsett, servert av en portløser.

Begge versjonene av monteringsdemonen kan nås via samme TCP-portnummer (702) og samme UDP-portnummer (699), men hver versjon av blokkeringsbehandlingen har sitt eget portnummer.

NFS-protokoll

NFS gir klienter transparent tilgang til serverens filer og filsystem. Dette er forskjellig fra FTP (kapittel 27), som gir filoverføring. Ved hjelp av FTP utføres en fullstendig filkopiering. NFS får bare tilgang til de delene av en fil som en prosess har tilgang til, og hovedfordelen med NFS er at den gjør denne tilgangen transparent. Dette betyr at enhver klientapplikasjon som kan jobbe med en lokal fil like gjerne kan jobbe med en NFS-fil, uten noen modifikasjoner på selve programmet.

NFS er en klient-server-applikasjon bygget ved hjelp av Sun RPC. NFS-klienter får tilgang til filer på en NFS-server ved å sende RPC-forespørsler til serveren. Dette kan implementeres ved bruk av vanlige brukerprosesser - nemlig NFS-klienten kan være en brukerprosess som foretar spesifikke RPC-kall til serveren, som også kan være en brukerprosess. Imidlertid implementeres NFS vanligvis annerledes av to grunner. Først må tilgang til NFS-filer være transparent for klienten. Derfor utføres NFS-klientoppkall av klientoperativsystemet på vegne av klientens brukerprosess. For det andre er NFS-servere implementert i operativsystemet for å forbedre servereffektiviteten. Hvis NFS-serveren var en brukerprosess, ville hver klientforespørsel og serversvar (inkludert data som skal leses eller skrives) måtte gå gjennom en separator mellom kjernen og brukerprosessen, noe som vanligvis er ganske dyrt.

I denne delen skal vi se på versjon 2 av NFS som dokumentert i RFC 1094 [Sun Microsystems 1988b]. Den beste beskrivelsen av Sun RPC, XDR og NFS er gitt i [X/Open 1991]. Detaljer om bruk og administrering av NFS er gitt i [Stern 1991]. NFS-protokollens versjon 3-spesifikasjoner ble implementert i 1993, som vi vil diskutere i en del av dette kapittelet.

Figur 29.3 viser typiske NFS-klient- og NFS-serverinnstillinger. I denne figuren må du ta hensyn til følgende.

1. Klienten bryr seg ikke om den får tilgang til en lokal fil eller en NFS-fil. Kjernen oppdager dette når filen er åpen. Etter at filen er åpnet, sender kjernen all tilgang til lokale filer til boksen merket "lokal filtilgang", og alle lenker til NFS-filer sendes til "NFS-klient"-boksen.
2. NFS-klienten sender RPC-forespørsler til NFS-serveren via TCP/IP-modulen. NFS bruker vanligvis UDP, men nyere implementeringer kan bruke TCP.
3. NFS-serveren mottar forespørsler fra klienten som UDP-datagrammer på port 2049. Selv om NFS kan fungere med en portløser, som lar serveren bruke dynamisk tilordnede porter, er UDP-port 2049 hardkodet til NFS i de fleste implementeringer.

Figur 29.3 Typiske NFS-klient- og NFS-serverinnstillinger.

Når NFS-serveren mottar en forespørsel fra en klient, sendes den til en lokal filtilgangsrutine, som gir tilgang til den lokale disken på serveren.

Serveren kan ta tid å behandle klientforespørsler. Til og med tilgang til det lokale filsystemet kan ta litt tid. I løpet av denne tiden ønsker ikke serveren å blokkere forespørsler fra andre klienter som også må betjenes. For å takle denne situasjonen, startes de fleste NFS-servere flere ganger, noe som betyr at det er flere NFS-servere i kjernen. Spesifikke løsningsmetoder avhenger av operativsystemet. De fleste Unix-kjerner "lever" ikke flere NFS-servere, men starter i stedet flere brukerprosesser (vanligvis kalt nfsd) som foretar et enkelt systemkall og forblir inne i kjernen som en kjerneprosess.

På samme måte tar en NFS-klient tid å behandle en forespørsel fra en brukerprosess på klientverten. RPC-en utstedes til serververten, hvoretter et svar forventes. For å sikre at brukerprosesser på klientverten kan dra nytte av NFS når som helst, er det flere NFS-klienter som kjører inne i klientkjernen. Den spesifikke implementeringen avhenger også av operativsystemet. Unix-systemer bruker vanligvis en teknikk som minner om en NFS-server: en brukerprosess kalt en biod foretar et enkelt systemkall og forblir inne i kjernen som en kjerneprosess.

De fleste Unix-verter kan fungere som en NFS-klient og en NFS-server, eller begge deler samtidig. De fleste PC (MS-DOS)-implementeringer har bare NFS-klientimplementeringer. De fleste IBM stormaskiner gir bare NFS-serverfunksjonalitet.

NFS er faktisk mer enn bare NFS-protokollen. Figur 29.4 viser de ulike RPC-programmene som brukes med NFS.

applikasjon	Programnummer	Versjonsnummer	Antall prosedyrer
portomformer
NFS
montere programmet
blokkeringsansvarlig
statusmonitor

Figur 29.4 Ulike RPC-programmer brukt i NFS.

Versjonene vi har vist i denne figuren som enheter finnes på systemer som SunOS 4.1.3. Nye implementeringer gir nyere versjoner av noen programmer. Solaris 2.2, for eksempel, støtter også versjon 3 og 4 av port-resolveren og versjon 2 av mount-demonen. SVR4 støtter også versjon 3 av portomformeren.

Mount-daemonen påkalles på klientens NFS-vert før klienten får tilgang til serverens filsystem. Vi beskriver denne prosessen nedenfor.

Blokkeringsbehandlingen og statusovervåkeren lar klienten blokkere noen filer som er plassert på NFS-serveren. Disse to programmene er uavhengige av NFS-protokollen fordi blokkering krever klientautentisering til både klientverten og serveren, og NFS i seg selv er "nøytral". (Vi skal snakke om NFS likegyldighet mer detaljert nedenfor.) Kapittel 9, 10 og 11 [X/Open 1991] dokumenterer prosedyrene som brukes av låseansvarlig og statusovervåker for låsing i NFS.

Filbeskrivelser

En av grunnprinsippene i NFS er implementert av filbeskrivelser. For å få tilgang til en fil eller katalog på objektserveren brukes opaque. Begrepet ugjennomsiktig betyr at serveren lager et filhåndtak, sender det tilbake til klienten, som klienten deretter bruker når han får tilgang til filen. Klienten ser aldri på innholdet i filbeskrivelsen - innholdet er kun av interesse for serveren.

NFS-klienten mottar et filhåndtak hver gang den åpner en fil som faktisk ligger på NFS-serveren. Når en NFS-klient leser eller skriver til denne filen (på vegne av en brukerprosess), sendes et håndtak til filen tilbake til serveren. Dette indikerer at filen har blitt åpnet.

Vanligvis fungerer ikke brukerprosessen med filbeskrivelser. Filbeskrivelser utveksles mellom NFS-klienten og NFS-serveren. I versjon 2 av NFS er filbeskrivelsen 32 byte, og i versjon 3 har den vokst til 64 byte.

Unix-servere lagrer vanligvis følgende informasjon i filbeskrivelsen: filsystemidentifikator (hoved- og mindre filsystemenhetsnumre), inodenummer (i-node) (et unikt nummer i filsystemet), inodegenerasjonsnummer (et tall som endres hver gang inoden gjenbrukes for en annen fil).

Monteringsprotokoll

Klienten bruker NFS-monteringsprotokollen for å montere serverens filsystem før den får tilgang til NFS-filer. Dette skjer vanligvis når klienten laster. Som et resultat mottar klienten et filhåndtak til serverens filsystem.

Figur 29.5 beskriver handlingssekvensen til en Unix-klient når du utfører mount(8)-kommandoen.

Figur 29.5 Monteringsprotokoll brukt av Unix-monteringskommandoen.

I dette tilfellet utføres følgende trinn.

1. Når serveren starter, starter portomformeren på den.
2. Etter portløseren starter mount daemon (mountd) på serveren. Den oppretter et TCP-endepunkt og et UDP-endepunkt, og tildeler hvert et dynamisk tildelt portnummer. Den registrerer deretter disse tallene med portkartleggeren.
3. Klienten utfører mount-kommandoen, som sender et RPC-kall til serverens portløser for å få et portnummer fra mount-daemonen på serveren. Både TCP og UDP kan brukes for kommunikasjon mellom klienten og portløseren, men UDP brukes vanligvis.
4. Port-resolveren rapporterer portnummeret.
5. Monteringskommandoen sender et RPC-kall til monteringsdemonen for å montere serverens filsystem. Igjen, enten TCP eller UDP kan brukes, men UDP brukes vanligvis. Serveren kan nå validere en klient basert på IP-adressen og portnummeret for å se om klienten kan montere det angitte filsystemet.
6. Mount-demonen svarer med et filhåndtak til det angitte filsystemet.
7. Klientens mount-kommando sender mount-systemkallet for å knytte filhåndtaket oppnådd i trinn 5 med det lokale monteringspunktet på klientens vert. Filhåndtaket er lagret i klientens NFS-kode, og fra nå av vil all tilgang fra brukerprosesser til filer på serverens filsystem bruke filhåndtaket som utgangspunkt.

Denne implementeringen overlater hele monteringsprosessen, bortsett fra monteringssystemkallet på klienten, til brukerprosesser i stedet for kjernen. De tre programmene vi viste - mount-kommandoen, portløseren og mount-demonen - er brukerprosesser.

I dette eksemplet, på vertssolen (NFS-klient), ble kommandoen utført

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

Denne kommandoen monterer /usr-katalogen på bsdi-verten (NFS-serveren) som det lokale filsystemet /nfs/bsdi/usr. Figur 29.6 viser resultatet.

Figur 29.6 Montering av bsdi:/usr-katalogen som /nfs/bsdi/usr på vertssolen.

Etter det, når du får tilgang til filen /nfs/bsdi/usr/rstevens/hello.c på sun-klienten, får du tilgang til filen /usr/rstevens/hello.c på bsdi-serveren.

NFS prosedyrer

NFS-serveren har 15 prosedyrer, som vi nå skal beskrive. (Tallene som brukes i denne beskrivelsen er ikke de samme som NFS-prosedyrenumre, ettersom vi har gruppert dem etter funksjonalitet.) Selv om NFS ble designet for å fungere på tvers av operativsystemer, ikke bare Unix-systemer, er noen av prosedyrene basert spesifikt på Unix-funksjonalitet. , som på sin side kanskje ikke støttes av andre operativsystemer (for eksempel harde lenker, symbolske lenker, gruppebruk, rettigheter for utførelsestilgang og så videre). Kapittel 4 inneholder mer informasjon om egenskapene til filsystemer, noen av dem bruker NFS.

1. GETATTR. Returnerer filattributter: filtype ( vanlig fil, katalog osv.), tilgangsrettigheter, filstørrelse, fileier, siste tilgangstid og så videre.
2. SETATTR. Angir filattributter. Bare et spesifikt sett med attributter kan angis: tilgangsrettigheter, eier, gruppeeierskap, størrelse, siste tilgangstid og siste endringstid.
3. STATFS. Returnerer statusen til filsystemet: mengde ledig plass, optimal størrelse for overføring og så videre. Brukes for eksempel av Unix df-kommandoen.
4. SE OPP. "Evaluerer" filen. Denne prosedyren kalles opp av klienten hver gang en brukerprosess åpner en fil som ligger på NFS-serveren. Et filhåndtak returneres sammen med filens attributter.
5. LESE. Leser fra en fil. Klienten spesifiserer et filhåndtak, en startbyteforskyvning og det maksimale antallet byte som skal leses (opptil 8192).
6. SKRIVE. Skriver til en fil. Klienten spesifiserer filhåndtaket, startforskyvningen i byte, antall byte som skal skrives og dataene som skal skrives.

   Forpliktet til NFS poster var synkrone (med forventning). Serveren kan ikke svare OK før dataene er skrevet (og all annen filinformasjon som må oppdateres) til disken.

7. SKAPE. Oppretter en fil.
8. FJERNE. Sletter en fil.
9. GJENNOMFØR. Gi nytt navn til filen.
10. LINK. Lager en hard lenke til filen. En hard link er et Unix-konsept som spesifiserer at en gitt fil på disk kan ha et hvilket som helst antall inngangspunkter (navn, også kalt harde lenker) som peker til den filen.
11. SYMLINK. Oppretter en symbolsk lenke til en fil. En symbolsk lenke er en fil som inneholder navnet på en annen fil. De fleste operasjoner som utføres på en symbolsk lenke (for eksempel åpning) utføres faktisk på filen som den symbolske lenken peker til.
12. LESLINK. Lesing av en symbolkobling returnerer navnet på filen som symbolkoblingen peker på.
13. MKDIR. Oppretter en katalog.
14. RMDIR. Sletter en katalog.
15. READDIR. Leser katalogen. Brukes for eksempel av Unix ls-kommandoen.

Faktisk begynner prosedyrenavnene som vises med NFSPROC_-prefikset, som vi har utelatt.

UDP eller TCP?

NFS ble opprinnelig skrevet for å bruke UDP, og alle leverandører tilbyr denne muligheten. Nyere implementeringer støtter imidlertid også TCP. TCP-støtte brukes til å jobbe i globale nettverk som blir raskere og raskere. Derfor er bruken av NFS ikke lenger begrenset til lokale nettverk.

Grensene mellom lokale og globale nettverk visker ut, og alt dette skjer veldig raskt. Returtidene varierer over et meget bredt område og overløp forekommer oftere og oftere. Disse egenskapene til globale nettverk fører til at de i økende grad bruker algoritmene som vi vurderte for TCP – langsom start og unngåelse av overbelastning. Siden UDP ikke gir noe som ligner på disse algoritmene, må de eller lignende bygges inn i NFS-klienten og serveren, ellers må TCP brukes.

NFS over TCP

Berkeley Net/2 NFS-implementeringen støtter både UDP og TCP. [Macklem 1991] beskriver denne implementeringen. La oss se på hvordan bruk av NFS er forskjellig når du kjører over TCP.

1. Når serveren starter, starter den NFS-serveren, som aktivt åpner på TCP-port 2049, og venter på at en tilkoblingsforespørsel kommer fra klienten. Dette gjøres vanligvis i tillegg til vanlig NFS UDP, som lytter etter innkommende datagrammer på UDP-port 2049.
2. Når en klient monterer en servers filsystem ved hjelp av TCP, gjør den en aktiv åpning på TCP-port 2049 på serveren. Dette etablerer en TCP-forbindelse mellom klienten og serveren for dette filsystemet. Hvis den samme klienten monterer et annet filsystem på samme server, opprettes en annen TCP-tilkobling.
3. Både klienten og serveren satte TCP "stay alive"-alternativet i endene av tilkoblingen (kapittel 23). Dette lar deg bestemme øyeblikket for feil eller omstart av en eller annen utvekslingsdeltaker.
4. Alle applikasjoner på klienten som bruker serverens filsystem deler den samme TCP-tilkoblingen til det filsystemet. For eksempel, hvis det var i figur 29.6, ville det være en annen katalog på bsdi, kalt smith, under /usr-katalogen, tilganger til filer i /nfs/bsdi/usr/rstevens og /nfs/bsdi/usr/smith ville dele det samme samme TCP-tilkoblingen.
5. Hvis klienten fastslår at serveren har krasjet eller startet på nytt (etter å ha mottatt en TCP "tilkobling tidsavbrutt" eller "tilkobling lukket av vert"-feil), prøver den å koble til serveren på nytt. Klienten utfører en annen aktiv åpning for å reetablere TCP-forbindelsen for dette filsystemet. Enhver forespørsel fra en klient som ble tidsavbrutt på en tidligere tilkobling, utstedes på nytt på en ny tilkobling.
6. Hvis en klient feiler, gjør det også applikasjonene som kjørte før feilen. Når klienten starter på nytt, kan den remontere serverens filsystem ved hjelp av TCP, ved å bruke en annen TCP-tilkobling til serveren. Den forrige forbindelsen mellom klienten og serveren for dette filsystemet er i en halvåpen tilstand (serveren tror den fortsatt er åpen), men siden serveren har satt alternativet "stay alive" vil denne halvåpne forbindelsen være lukket når TCP-serveren sender neste probe." stay alive."

Over tid planlegger andre leverandører å støtte NFS over TCP.

NFS eksempler

La oss bruke tcpdump for å se hvilke NFS-rutiner som påkalles av klienten for vanlige filoperasjoner. Når tcpdump bestemmer at et UDP-datagram inneholder et RPC-anrop (anrop er 0 i figur 29.1) med målport 2049, dekoder det datagrammet som en NFS-forespørsel. Tilsvarende, hvis et UDP-datagram inneholder et RPC-svar (svaret er 1 i figur 29.2) med en kildeport på 2049, dekoder det datagrammet som et NFS-svar.

Enkelt eksempel: lese en fil

I det første eksemplet vil vi kopiere en fil som ligger på NFS-serveren til terminalen ved å bruke cat(1)-kommandoen:

Sol% cat /nfs/bsdi/usr/rstevens/hello.c kopiere en fil til terminalen
hoved()
{
printf("hei, verden\n");
}

/nfs/bsdi/usr-filsystemet på host sun (NFS-klient) er faktisk /usr-filsystemet på vert bsdi (NFS-server), som vist i figur 29.6. Solkjernen oppdager dette når cat åpner en fil og bruker NFS for å få tilgang til filen. Figur 29.7 viser utdata fra tcpdump-kommandoen.

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

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

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

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

9 0,027621 (0,0052) sun.7aaa > bsdi.nfs: 116 lest 1024 byte @ 0
10 0,032170 (0,0045) bsdi.nfs > sun.7aaa: svar ok 140

Figur 29.7 NFS-operasjon ved lesing av en fil.

tcpdump-kommandoen dekoder NFS-forespørselen eller -svaret, og den skriver også ut XID-feltet for klienten i stedet for portnummeret. XID-feltet på linje 1 og 2 er 0x7aa6.

Filnavnet /nfs/bsdi/usr/rstevens/hello.c behandles av den åpne funksjonen i klientkjernen ett navneelement om gangen. Når den åpne funksjonen når /nfs/bsdi/usr, bestemmer den at dette er et NFS-filsystemmonteringspunkt.

På linje 1 kaller klienten GETATTR for å få attributtene til serverkatalogen som klienten monterte (/usr). Denne RPC-forespørselen inneholder 104 byte med data, i tillegg til IP- og UDP-hodene. Svaret på linje 2 returnerer OK og inneholder 96 byte med data, i tillegg til IP- og UDP-hodene. Vi kan se i denne figuren at minimum NFS-melding inneholder omtrent 100 byte med data.

På linje 3 kaller klienten LOOKUP på filen rstevens og mottar et OK-svar på linje 4. LOOKUP spesifiserer navnet på filen rstevens og et håndtak til filen som ble lagret av kjernen da det eksterne filsystemet ble montert. Svaret inneholder et nytt filhåndtak som brukes i neste trinn.

På linje 5 SLÅTER klienten opp filen hello.c ved å bruke filhåndtaket fra linje 4. Den mottar et annet filhåndtak på linje 6. Dette nye filhåndtaket er nøyaktig det klienten bruker på linje 7 og 9 for å få tilgang til filen / nfs /bsdi/usr/rstevens/hello.c. Vi ser at klienten utfører et OPPSLAG på hver navnekomponent i banen til filen som åpnes.

På linje 7 utfører klienten GETATTR igjen, etterfulgt av READ på linje 9. Klienten ber om 1024 byte som starter ved offset 0, men mottar mindre enn 1024 byte med data. (Etter å ha trukket fra størrelsene på RPC-feltene og andre verdier som returneres av READ-prosedyren, returneres 38 byte med data på linje 10. Dette er nøyaktig størrelsen på hello.c-filen.)

I dette eksemplet vet ikke brukerprosessen noe om disse NFS-forespørslene og -svarene, som utføres av kjernen. Applikasjonen kaller bare opp kjernefunksjonen, som fører til at 3 forespørsler og 3 svar utveksles (linje 1-6), og kaller deretter opp kjernelesefunksjonen, som kaller 2 forespørsler og 2 svar (linje 7-10). For klientapplikasjonen er filen som ligger på NFS-serveren gjennomsiktig.

Enkelt eksempel: lage en katalog

Som et annet eksempel, la oss endre arbeidskatalogen til en katalog som ligger på NFS-serveren, og deretter opprette en ny katalog:

Sol% cd /nfs/bsdi/usr/rstevens endre arbeidskatalogen
sol% mkdir Mail opprette en katalog

Figur 29.8 viser utdata fra tcpdump-kommandoen.

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

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

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

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

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

Figur 29.8 NFS-operasjon når du endrer katalog (cd) til NFS-katalog og deretter oppretter katalog (mkdir).

Ved endring av katalog ringer klienten GETATTR to ganger (linje 1-4). Når vi oppretter en ny katalog, ringer klienten GETATTR (linje 5 og 6), deretter LOOKUP (linje 7 og 8 for å sjekke at katalogen ikke eksisterer), deretter MKDIR for å opprette katalogen (linje 9 og 10). OK-svaret på linje 8 betyr ikke at katalogen eksisterer. Det betyr ganske enkelt at prosedyren ga en viss verdi. tcpdump tolker ikke verdien som returneres av NFS-prosedyrer. Kommandoen skriver ganske enkelt ut OK og antall byte med data i svaret.

Likegyldighet

En av egenskapene til NFS (NFS-kritikere kaller det en vorte, ikke en funksjon) er at NFS-serveren er likegyldig. Serveren bryr seg ikke om hvilke klienter som får tilgang til hvilke filer. Legg merke til at listen over NFS-prosedyrer vist tidligere ikke inkluderer en åpen eller lukket prosedyre. OPPSLAG-prosedyren ligner på en åpen, men serveren vet aldri om klienten har fått tilgang til filen etter at OPPSLAGET er gjort.

Grunnen til denne "bryr seg ikke" er å gjøre det lettere å gjenopprette fra en serverfeil etter at den krasjer og starter på nytt.

Eksempel: serverfeil

I det følgende eksempelet leser vi en fil fra en NFS-server når serveren krasjer og starter på nytt. Dette vil vise hvordan serverens "likegyldighet" lar klienten "ikke vite" at serveren har feilet. Hele tiden serveren krasjer og starter på nytt, er klienten uvitende om problemet, og klientapplikasjonen fungerer som før.

På sun-klienten kjørte vi cat med en veldig stor fil som argument (/usr/share/lib/termcap på svr4 NFS-serveren), koblet fra Ethernet-kabelen midt i overføringen, slo av og startet serveren på nytt, og koblet deretter til kabelen igjen . Klienten er konfigurert til å lese 1024 byte per NFS-lesing. Figur 29.9 viser utdataene til tcpdump.

Linje 1-10 tilsvarer at klienten åpner filen. Denne operasjonen ligner den som er vist i figur 29.7. På linje 11 ser vi den første lesingen (READ) fra filen med 1024 byte med data; svaret kom tilbake på linje 12. Dette fortsetter til linje 129 (leser 1024 byte med READ og svarer deretter OK).

På linje 130 og 131 ser vi to forespørsler som går ut og sendes inn på nytt i linje 132 og 133. Første spørsmål: vi ser to leseforespørsler, den ene starter ved offset 65536 og den andre starter ved offset 73728, hvorfor? Klientkjernen bestemte at klientapplikasjonen leste sekvensielt og forsøkte å skaffe datablokker på forhånd. (De fleste Unix-kjerner gjør dette på forhånd.) Klientkjernen kjører også flere NFS-blokk input/output (I/O) daemoner (biod-prosesser) som forsøker å generere flere RPC-forespørsler på vegne av klienten. En demon leser 8192 byte, starter på 65536 (i 1024-byte kjeder), og de andre leser fremover 8192 byte, starter på 73728.

Klientoverføringer vises på linjene 130-168. På linje 169 ser vi at serveren har restartet og sendt en ARP-forespørsel før den svarer på klientens NFS-forespørsel på linje 168. Svaret til linje 168 sendes på linje 171. Klientens READ-forespørsel fortsetter.

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

3 0,009041 (0,0014) sun.7adf > svr4.nfs: 116 oppslag "del"
4 0,017237 (0,0082) svr4.nfs > sun.7adf: svar ok 128

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

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

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

11 0,050984 (0,0052) sun.7ae3 > svr4.nfs: 116 lest 1024 byte @ 0
12 0,084995 (0,0340) svr4.nfs > sun.7ae3: svar ok 1124

Lesning

128 3.430313 (0.0013) sun.7b22 > svr4.nfs: 116 lest 1024 byte @ 64512
129 3.441828 (0.0115) svr4.nfs > sun.7b22: svar ok 1124

130 4.125031 (0.6832) søn.7b23 >
131 4,868593 (0,7436) søn.7b24 >

132 4.993021 (0.1244) sun.7b23 > svr4.nfs: 116 lest 1024 byte @ 65536
133 5.732217 (0.7392) sun.7b24 > svr4.nfs: 116 lest 1024 byte @ 73728

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

136 10.211964 (2.7399) søn.7b23 >
137 10,951960 (0,7400) søn.7b24 >

138 17.171767 (6.2198) sun.7b23 > svr4.nfs: 116 lest 1024 byte @ 65536
139 17,911762 (0,7400) sun.7b24 > svr4.nfs: 116 lest 1024 byte @ 73728

140 31.092136 (13.1804) sun.7b23 > svr4.nfs: 116 lest 1024 byte @ 65536
141 31.831432 (0.7393) sun.7b24 > svr4.nfs: 116 lest 1024 byte @ 73728

142 51.090854 (19.2594) sun.7b23 > svr4.nfs: 116 lest 1024 byte @ 65536
143 51.830939 (0.7401) sun.7b24 > svr4.nfs: 116 lest 1024 byte @ 73728

144 71.090305 (19.2594) sun.7b23 > svr4.nfs: 116 lest 1024 byte @ 65536
145 71.830155 (0.7398) sun.7b24 > svr4.nfs: 116 lest 1024 byte @ 73728

Gjensendinger

167 291.824285 (0.7400) sun.7b24 > svr4.nfs: 116 lest 1024 byte @ 73728
168 311.083676 (19.2594) sun.7b23 > svr4.nfs: 116 lest 1024 byte @ 65536

Server startet på nytt

169 311.149476 (0.0658) arp hvem-har sol tell svr4
170 311.150004 (0.0005) arp-svar sun is-at 8:0:20:3:f6:42

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

172 311.156671 (0.0018) sun.7b25 > svr4.nfs: 116 lest 1024 byte @ 66560
173 311.168926 (0.0123) svr4.nfs > sun.7b25: svar ok 1124
lesning

Figur 29.9 Klient leser en fil når NFS-serveren krasjer og starter på nytt.

Klientapplikasjonen vil aldri vite at serveren krasjet og startet på nytt, bortsett fra at det var en 5-minutters pause mellom linje 129 og 171, så serverkrasj er gjennomsiktig for klienten.

For å estimere lengden på tidsavbrudd for reoverføring i dette eksemplet, se for deg at det er to klientdemoner, hver med sine egne tidsavbrudd. Intervallene for den første demonen (leses fra offset 65536) er omtrent som følger (avrundet til to desimaler): 0,68; 0,87; 1,74; 3,48; 6,96; 13,92; 20,0; 20,0; 20.0 og så videre. Intervallene for den andre daemonen (leses fra offset 73728) er nøyaktig de samme. Dette betyr at disse NFS-klientene bruker tidsavbrudd som er multipler på 0,875 sekunder, med en øvre grense på 20 sekunder. Etter hver timeout dobles retransmisjonsintervallet: 0,875; 1,75; 3,5; 7,0 og 14,0.

Hvor lang tid vil det ta før klienten foretar reoverføringer? Oppdragsgiver har to alternativer som kan påvirke dette. For det første, hvis serverens filsystem er hardt montert, vil klienten sende på nytt for alltid, men hvis serverens filsystem er mykmontert, vil klienten slutte å prøve etter et fast antall reoverføringer. I tilfelle av en hard montering, har klienten muligheten til å la brukeren avbryte mislykkede reoverføringer eller ikke avbryte. Hvis, ved montering av serverens filsystem, klientens vert indikerer at den kan avbrytes, og hvis vi ikke ønsker å vente 5 minutter på at serveren skal starte på nytt etter å ha krasjet, kan vi angi et avbruddssymbol for å avslutte klientapplikasjonen.

Flere identiske prosedyrer

RPC-prosedyrer kan utføres av serveren flere ganger, men returnerer fortsatt det samme resultatet. For eksempel leseprosedyren for NFS. Som vi så i figur 29.9, sender klienten ganske enkelt READ-anropet på nytt så lenge den mottar et svar. I vårt eksempel var årsaken til retransmisjonen at serveren var nede. Hvis serveren ikke har sviktet og meldinger som inneholder RPC-svar har gått tapt (siden UDP er en upålitelig protokoll), sender klienten ganske enkelt på nytt og serveren gjør den samme READ igjen. Den samme delen av den samme filen leses på nytt og sendes til klienten.

Dette fungerer fordi hver READ-leseforespørsel inneholder en startforskyvning. Hvis NFS-prosedyren ba serveren om å lese de neste N byte av filen, ville den ikke fungere. Hvis serveren ikke var likegyldig (dette er det motsatte av likegyldig) og svaret gikk tapt og klienten ga READ på nytt for de neste N bytene, ville resultatet bli annerledes. Dette er grunnen til at NFS READ- og WRITE-prosedyrene har en startforskyvning. Det er klienten som opprettholder tilstanden (gjeldende offset for hver fil), ikke serveren.

Dessverre kan ikke alle filsystemoperasjoner utføres flere ganger. Tenk deg for eksempel følgende trinn: NFS-klienten sender en FJERN-forespørsel om å fjerne en fil; NFS-serveren sletter filen og svarer OK; serverrespons tapt; NFS-klienten timeout og sender forespørselen på nytt; NFS-serveren finner ikke filen og returnerer en feil. Klientapplikasjonen mottar en feil som sier at filen ikke eksisterer. Denne feilen returneres til klientapplikasjonen, og denne feilen inneholder feil informasjon - filen fantes ikke og ble slettet.

Nedenfor er en liste over NFS-prosedyrer som kan utføres flere ganger: GETATTR, STATFS, LOOKUP, READ, WRITE, READLINK og READDIR. Prosedyrer som ikke kan utføres flere ganger: CREATE, REMOVE, RENAME, LINK, SYMLINK, MKDIR og RMDIR. SETATTR utføres vanligvis flere ganger, med mindre den ble brukt til å avkorte en fil.

Fordi foreldreløse svar alltid vil oppstå ved bruk av UDP, må NFS-servere ha en måte å håndtere operasjoner som ikke kan utføres flere ganger. De fleste servere har en nylig svarbuffer der de lagrer de sist mottatte svarene for slike operasjoner. Hver gang serveren mottar en forespørsel, ser den først gjennom cachen sin, og hvis et samsvar blir funnet, returnerer den forrige responsen i stedet for å kalle NFS-prosedyren igjen. [Juszczak 1989] beskriver detaljene til disse cache-typene.

Denne tilnærmingen til serverprosedyrer gjelder for alle UDP-baserte applikasjoner, ikke bare NFS. DNS, for eksempel, gir en tjeneste som kan brukes flere ganger uten smerte. DNS-server kan lage en parserforespørsel et hvilket som helst antall ganger, noe som ikke vil føre til negative resultater (kanskje, bortsett fra at nettverksressurser vil være okkupert).

NFS versjon 3

I løpet av 1994 ble spesifikasjoner for versjon 3 av NFS-protokollen utgitt [Sun Microsystems 1993]. Implementeringer forventes å bli tilgjengelige i løpet av 1994.

Her er en rask oversikt over hovedforskjellene mellom versjon 2 og 3. Vi kaller dem V2 og V3.

1. Filbeskrivelser i V2 er en matrise med fast størrelse på 32 byte. I V3 er det en matrise med variabel størrelse med en størrelse på opptil 64 byte. En matrise med variabel lengde i XDR er definert av en 4-byte teller etterfulgt av reelle byte. Dette reduserer størrelsen på filbeskrivelsen i implementeringer som Unix, hvor det bare kreves omtrent 12 byte, men lar ikke-Unix-implementeringer utveksle tilleggsinformasjon.
2. V2 begrenser antall byte per READ eller WRITE RPC prosedyre til 8192 byte. Denne begrensningen gjelder ikke i V3, som igjen betyr at ved bruk av UDP vil grensen kun være størrelsen på IP-datagrammet (65535 bytes). Dette gjør at store pakker kan brukes til lesing og skriving på raske nettverk.
3. Filstørrelser og startbyte-forskyvninger for READ- og WRITE-prosedyrer er utvidet fra 32 til 64 biter, slik at større filstørrelser kan håndteres.
4. Filattributter returneres i hvert kall som kan påvirke attributtene. Dette reduserer antallet GETATTR-anrop som kreves av klienten.
5. Writes (WRITEs) kan være asynkrone, mens de i V2 skulle være synkrone. Dette kan forbedre ytelsen til WRITE-prosedyren.
6. Én prosedyre ble fjernet (STATFS) og sju ble lagt til: ACCESS (sjekk filtillatelser), MKNOD (lag en spesiell Unix-fil), READDIRPLUS (returnerer navn på filer i en katalog sammen med deres attributter), FSINFO (returnerer statistisk informasjon om filsystemet ), FSSTAT (returnerer dynamisk filsysteminformasjon), PATHCONF (returnerer POSIX.1-filinformasjon) og COMMIT (forplikter tidligere utførte asynkrone skrivinger til vedvarende lagring).

Korte konklusjoner

RPC er en måte å bygge en klient-server-applikasjon på på en slik måte at klienten ganske enkelt kaller prosedyrer på serveren. Alle nettverksdetaljer er skjult i klient- og serverstubber, som genereres for applikasjoner av RPC-pakken og i RPC-biblioteksrutiner. Vi viste formatet til RPC-anrop og svarmeldinger og nevnte at XDR brukes til å kode verdier, slik at RPC-klienter og -servere kan kjøre på forskjellige maskinarkitekturer.

En av de mest brukte RPC-applikasjonene er Sun NFS, en heterogen filtilgangsprotokoll som er mye brukt på verter av praktisk talt alle størrelser. Vi så på NFS og hvordan den bruker UDP eller TCP. NFS versjon 2-protokollen definerer 15 prosedyrer.

Klienttilgang til en NFS-server begynner med en monteringsprotokoll, hvoretter et filhåndtak returneres til klienten. Klienten kan da få tilgang til filer på serverens filsystem ved å bruke dette filhåndtaket. Filnavn slås opp på serveren ett navneelement om gangen, og returnerer et nytt filhåndtak for hvert element. Det endelige resultatet er et håndtak til filen som ble åpnet, og som brukes til sekvensiell lesing og skriving.

NFS prøver å gjøre alle sine prosedyrer uavhengige av antall henrettelser, slik at klienten ganske enkelt kan sende ut forespørselen på nytt hvis svaret går tapt. Vi har sett eksempler på dette hvor en klient leste en fil mens serveren krasjet og startet på nytt.

Øvelser

I figur 29.7 så vi at tcpdump tolker pakker som NFS-forespørsler og svar, og skriver ut XID. Kan tcpdump gjøre dette for RPC-forespørsler eller svar?

Hvorfor tror du RPC-serverprogrammet på Unix-systemer bruker dynamisk tilordnede porter i stedet for forhåndskjente?

RPC-klienten kalte to serverprosedyrer. Den første prosedyren tok 5 sekunder å fullføre, og den andre - 1 sekund. Klienten har en timeout på 4 sekunder. Tegn et tidsdiagram over hva som utveksles mellom klient og server. (Se for deg at det ikke ble brukt tid på å sende en melding fra klient til server og omvendt.)

I eksemplet i figur 29.9, hva ville skje hvis NFS-serverens Ethernet-kort ble fjernet mens NFS-serveren var slått av?

Når serveren startet på nytt i figur 29.9, behandlet den forespørselen med start ved offset 65536 (linje 168 og 171), og behandlet deretter neste forespørsel fra offset 66560 (linje 172 og 173). Hva skjer med spørringen som starter ved offset 73728 (linje 167)?

Da vi beskrev prosedyrer uavhengig av antall NFS-kjøringer, viste vi et eksempel på en FJERN-respons som gikk tapt i nettverket. Hva skjer i dette tilfellet hvis TCP brukes i stedet for UDP?

Hvis NFS-serveren bruker en dynamisk tilordnet port i stedet for port 2049, hva skjer med NFS-klienten når serveren krasjer og starter på nytt?

Det er veldig, veldig få reserverte portnumre (kapittel 1, avsnitt "Portnumre"), med maksimalt 1023 per vert. Hvis en NFS-server krever at klientene har reserverte porter (som de vanligvis gjør), og en NFS-klient som bruker TCP monterer N filsystemer på N forskjellige servere, må klienten ha forskjellige reserverte portnumre for hver tilkobling?

Network File System (NFS) er en fildelingsløsning for organisasjoner som har blandede Windows- og Unix/Linux-maskinmiljøer. NFS-filsystemet lar deg åpne generell tilgang til filer mellom spesifiserte forskjellige plattformer mens operativsystemet kjører Windows Server 2012: NFS Services i Windows Server 2012 inkluderer følgende funksjoner og forbedringer.

1. Active Directory-søk. Du har muligheten til å bruke Windows Active Directory for å få tilgang til filer. Identity Management for Unix-skjemautvidelsen for Active Directory inneholder Unix-brukeridentifikator (UID) og gruppeidentifikator (GID)-felt. Dette gjør at Server for NFS og Client for NFS kan se Windows-brukerkontotilordninger på Unix direkte fra Active Directory Domain Services. Identity Management for Unix gjør det enklere å administrere tilordningen av Windows-brukerkontoer på Unix til Active Directory Domain Services.

2. Forbedret serverytelse. Tjenester for NFS inkluderer en filfilterdriver som reduserer den totale ventetiden betydelig ved tilgang til filer på serveren.

3. Støtte for spesielle Unix-enheter. Tjenester for NFS støtter spesielle Unix-enheter (mknod).

4. Utvidet Unix-støtte. Tjenester for NFS støtter følgende versjoner av Unix: Sun Microsystems Solaris versjon 9, Red Hat Linux versjon 9, IBM AIX versjon 5L 5.2 og Hewlett Packard HP-UX versjon 11i, samt mange moderne Linux-distribusjoner.

Et av de vanligste scenariene som skaper behov for NFS involverer å eksponere et Unix-basert enterprise resource planning (ERP) system for Windows-brukere. Mens de er i ERP-systemet, kan brukere lage rapporter og/eller eksportere økonomiske data til Microsoft Excel for videre analyse. NFS-filsystemet gjør det mulig å få tilgang til disse filene mens de fortsatt er i Windows-miljøet, noe som reduserer behovet for spesialiserte tekniske ferdigheter og tiden brukt på å eksportere filer ved hjelp av et Unix-skript og deretter importere dem til et spesifikt Windows-program.

Det kan også være en situasjon der du har et Unix-system som brukes til å lagre filer på et slags Storage Area Network (SAN). Å kjøre NFS-tjenester på en Windows Server 2012-maskin lar brukere i en organisasjon få tilgang til filer som er lagret der uten overhead av skripting på Unix-siden.

Før du installerer NFS Services, må du fjerne alle tidligere installerte NFS-komponenter, for eksempel NFS-komponenter som ble inkludert i Services for Unix.

NFS Services-komponenter

Følgende to NFS-tjenestekomponenter er tilgjengelige.

1. Server for NFS(Server for NFS). Vanligvis kan en Unix-basert datamaskin ikke få tilgang til filer som ligger på en Windows-basert datamaskin. En datamaskin som kjører Windows Server 2012 R2 og Server for NFS kan imidlertid fungere som en filserver for Windows- og Unix-datamaskiner.

2. Klient for NFS(Klient for NFS). Vanligvis kan ikke en Windows-basert datamaskin få tilgang til filer som ligger på en Unix-basert datamaskin. En datamaskin som kjører Windows Server 2012 R2 og Client for NFS-funksjonen kan imidlertid få tilgang til filer som er lagret på en Unix-basert NFS-server.

Installere server for NFS ved hjelp av PowerShell

La oss se hvordan du bruker PowerShell til å installere NFS-rollen på en server og opprette en NFS-filressurs.

1. Åpne et Windows PowerShell-vindu via oppgavelinjen som en administratorkonto.

2. Skriv inn følgende kommandoer for å installere NFS-rollen på serveren:

PS C:\> Import-Module ServerManager PS C:\> Add-WindowsFeature FS-NFS-Services PS C:\> Import-Module NFS

3. Skriv inn kommandoen nedenfor for å opprette en ny NFS-fildeling:

PS C:\> New-NfsShare -Navn "Test" -Path "C:\Shares\Test"

4. For å se alle de nye NFS-spesifikke PowerShell-cmdletene som er tilgjengelige i Windows Server 2012 R2, kjør følgende kommando:

PS C:\>Get-Command -Module NFS

5. Høyreklikk på mappen C:\Shares\Test, velg "egenskaper", og gå deretter til fanen NFS-deling. Klikk på Administrer NFS-deling-knappen, i dialogboksen som vises, kan du administrere mappetilgangstillatelser, tillate anonym tilgang og konfigurere filkodingsinnstillinger. Du kan dele en mappe over NFS ved å bruke dialogboksen NFS Advanced Sharing uten å bruke PowerShell.

Sette standard oppløsninger

Nå må vi åpne noen brannmurporter for at NFS skal fungere. Portene som kreves for at NFS-tjenester skal fungere ordentlig, er presentert i tabellen nedenfor.