Alle vet at på UNIX-systemer er et filsystem logisk sett en samling fysiske filsystemer koblet til et enkelt punkt. En av hovedfordelene med en slik organisasjon, etter min mening, er muligheten til å dynamisk endre strukturen til et eksisterende filsystem. Takket være innsatsen til utviklerne har vi i dag muligheten til å koble til et filsystem av nesten hvilken som helst type og på en hvilken som helst praktisk måte. Med "metode" vil jeg først og fremst understreke muligheten til OS-kjernen til å jobbe med filsystemer via nettverkstilkoblinger.

En haug med nettverksprotokoller gi oss muligheten til å jobbe med eksterne filer, enten det er FTP, SMB, Telnet eller SSH. Takket være evnen til kjernen til å til slutt ikke avhenge av typen filsystem som er koblet til, har vi muligheten til å koble til hva som helst og hvordan vi vil bruke mount-programmet.

I dag vil jeg gjerne snakke om NFS - Network File System. Denne teknologien lar deg koble individuelle filsystempunkter på en ekstern datamaskin til filsystemet til den lokale datamaskinen. Selve NFS-protokollen lar deg utføre filoperasjoner ganske raskt, trygt og pålitelig. Hva mer trenger vi? :-)

Hva skal til for at dette skal fungere

For ikke å tulle i lang tid om emnet NFS-versjoner og deres støtte i forskjellige kjerner, vil vi umiddelbart anta at kjerneversjonen din ikke er lavere enn 2.2.18. I den offisielle dokumentasjonen lover utviklerne full støtte for NFS versjon 3-funksjonalitet i denne kjernen og senere versjoner.

Installasjon

For å kjøre NFS-serveren i min Ubuntu 7.10 - Gutsy Gibbon, trengte jeg å installere pakkene nfs-common og nfs-kernel-server. Hvis du bare trenger en NFS-klient, trenger ikke nfs-kernel-server å installeres.

Server Tuning

Etter at alle pakkene har blitt installert, må du sjekke om NFS-demonen kjører:

/etc/init.d/nfs-kernel-server status

Hvis demonen ikke kjører, må du starte den med kommandoen

/etc/init.d/nfs-kernel-server start

Etter at alt har startet, kan du begynne å eksportere filsystemet. Selve prosessen er veldig enkel og tar minimal tid.

Hovedkonfigurasjonsfilen for NFS-serveren ligger i /etc/exports og har følgende format:

Katalogmaskin1(alternativ11,alternativ12) maskin2(alternativ21,alternativ22)

katalog— absolutt bane til FS-serverkatalogen som du må gi tilgang til

maskinX— DNS-navn eller IP-adresse til klientdatamaskinen som tilgang er tillatt fra

alternativXX— FS eksportparametere, de mest brukte av dem:

• ro- filtilgang er skrivebeskyttet
• rw— lese-/skrivetilgang er gitt
• no_root_squash— som standard, hvis du kobler til en NFS-ressurs som root, vil serveren, for sikkerhets skyld, på sin side få tilgang til filer som ingen-bruker. Men hvis du aktiverer dette alternativet, vil filer på serversiden få tilgang som root. Vær forsiktig med dette alternativet.
• no_subtree_check— som standard, hvis du ikke eksporterer hele partisjonen på serveren, men bare en del av filsystemet, vil daemonen sjekke om den forespurte filen er fysisk plassert på samme partisjon eller ikke. Hvis du eksporterer hele partisjonen eller monteringspunktet til det eksporterte filsystemet ikke påvirker filer fra andre fysiske volumer, kan du aktivere dette alternativet. Dette vil gi deg en økning i serverhastighet.
• synkronisere— aktiver dette alternativet hvis det er en mulighet for plutselig tilkoblingstap eller strømbrudd på serveren. Hvis dette alternativet ikke er aktivert, er det en svært høy risiko for tap av data hvis NFS-serveren plutselig stopper.

Så la oss si at vi må gi tilgang til ashep-stasjonære datamaskinen til /var/backups-katalogen til ashep-bærbare datamaskiner. Katalogtilgang er nødvendig for å kopiere sikkerhetskopifiler fra ashep-desktop. Filen min ble slik:

/var/backups ashep-desktop(rw,no_subtree_check,sync)

Etter å ha lagt til linjen i /etc/exports, må du starte NFS-serveren på nytt for at endringene skal tre i kraft.

/etc/init.d/nfs-kernel-server omstart

Det er alt. Du kan begynne å koble til den eksporterte FS på klientdatamaskinen.

Klientoppsett

På klientsiden monteres det eksterne filsystemet på samme måte som alle andre - med mount-kommandoen. Dessuten er det ingen som forbyr deg å bruke /etc/fstab hvis du trenger å koble til FS automatisk når operativsystemet starter. Så, monteringsalternativet vil se slik ut:

Mount -t nfs ashep-laptop:/var/backups/ /mnt/ashep-laptop/backups/

Hvis alt gikk bra og du trenger å koble til den eksterne FS automatisk ved oppstart, legg til linjen i /etc/fstab:

Ashep-laptop:/var/backups /mnt/ashep-laptop/backups nfs auto 0 0

Hva annet

Så vi har en praktisk, liten oversikt over mulighetene til NFS. Dette er selvfølgelig bare en liten del av hva NFS kan gjøre. Dette er nok for bruk hjemme eller på et lite kontor. Hvis dette ikke er nok for deg, anbefaler jeg å lese først

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 av dette manuset det er klart det 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 de ovennevnte pakkene, for riktig drift NFSv2 og v3 krever tilleggspakke portkart(erstattet i nyere distribusjoner med omdøpt til rpcbind). Gjeldende pakke den installeres vanligvis automatisk med NFS som avhengig 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. 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 å skaffe den nødvendige informasjonen, kaller det portoppløsningsrutinen for å få et dynamisk tildelt portnummer for det angitte programmet, versjonen og protokollen.
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 10872 1 udp 10872 0n status 0n 1 udp 10872 0n 2 1 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 2 0 t 3 4 0 0 s 9 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 programregistrering eller få informasjon om egen tjeneste RPC (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årlig 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 for montering eksterne systemer i fil /etc/exports. Denne handlingen kalles eksportkataloghierarki. De viktigste kildene til informasjon om eksporterte kataloger er følgende filer:

• /etc/exports- grunnleggende konfigurasjonsfil, som lagrer konfigurasjonen av eksporterte kataloger. 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 Eksporter 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 (ingen_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.
• synkronisere (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.

Standardalternativene kan variere mellom systemer og kan finnes i /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)- Med alternativet spesifisert 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 mount-kommandoen
• 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 NFS-montering TCP-protokoll eller UDP henholdsvis.
• bg- Hvis du mister tilgangen til serveren, prøv igjen bakgrunn, for ikke å blokkere systemoppstartsprosessen.
• fg- Hvis du mister tilgangen til serveren, prøv igjen i prioritetsmodus. Denne parameteren kan blokkere systemoppstartsprosessen 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 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 tidsavbrudd opp til maksimal verdi 60 sekunder eller til en stor timeout inntreffer. 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-svitsjen 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 delte NFS-katalog offentlig 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!

Nettverksfilsystemer

En av de mest nyttige funksjonene som kan oppnås ved bruk av nettverket er å dele filer gjennom et nettverksfilsystem. Systemet som vanligvis brukes kalles Network File System eller NFS, som er utviklet av Sun Corporation.

Når du arbeider med et nettverksfilsystem, overføres alle operasjoner på filer utført på den lokale datamaskinen via nettverket til ekstern maskin. Når et nettverksfilsystem kjører, mener programmet at alle filene på den eksterne datamaskinen er plassert på datamaskinen der den kjører. Å skille informasjon gjennom et slikt system krever altså ingen endringer i programmet.

Post

E-post er det viktigste kommunikasjonsmiddelet mellom datamaskiner. E-poster lagres i én fil i et spesielt format. Spesielle programmer brukes til å lese og sende brev.

Hver bruker har en egen postkasse, en fil hvor informasjon lagres i et spesielt format der innkommende post lagres. Hvis et brev kommer til datamaskinen, finner postbehandlingsprogrammet postkassefilen til den tilsvarende brukeren og legger det mottatte brevet der. Hvis brukerens postkasse er plassert på en annen datamaskin, blir brevet omdirigert til denne datamaskinen, hvor det deretter behandles.

Postsystemet består av mange forskjellige programmer. Levering av brev til lokale eller eksterne postkasser utføres av ett program (for eksempel sendmail eller smail), mens for vanlig sending eller visning av brev brukes et stort antall forskjellige programmer (for eksempel Pine eller alm). Postboksfiler er vanligvis lagret i /-katalogen.var/spool/mail.

Spørsmål

1. Hva er NOS og hva er formålet?

2. Hvilke nettverksfunksjoner utfører et nettverksoperativsystem?

3. Hvilke deler består NOS-strukturen av?

4. Hva er en omdirigering?

5. Hvordan er nettverksoperativsystemer delt inn etter tilgangsrettigheter til ressurser?

6. Hvordan er nettverksoperativsystemer delt inn etter nettverksskalaen?

7. Hvordan avhenger egenskapene til et nettverksoperativsystem av nettverkets skala?

8. Beskriv NetWare-nettverksoperativsystemet fra Novell.

9. Hvilke elementer utgjør strukturen til NetWare-nettverksoperativsystemet?

10. Beskriv filsystemet til NetWare-nettverksoperativsystemet.

11. Hvilke protokollnivåer støtter NetWare-nettverksoperativsystemet?

12. List opp funksjonene til IPX, SPX-protokollene.

13. Beskriv nettverksoperativsystemet Windows-systemer N.T.

14. List opp oppgavene til nettverksoperativsystemet Windows NT.

15. Hvilke elementer består strukturen til nettverksoperativsystemet Windows NT av?

16. Beskriv filsystemet til Windows NT nettverks-OS.

17. Hvilke sikkerhetsprinsipper brukes i nettverksoperativsystemet Windows NT?

18. List opp funksjonene til nettverksoperativsystemet Windows NT fra synspunktet om implementering av nettverksverktøy.

19. Navngi egenskapene til nettverksoperativsystemet Windows NT.

20. Hva er bruken av Windows NT?

21. Beskriv UNIX-nettverksoperativsystemet.

22. List opp funksjonene til UNIX-nettverksoperativsystemet.

23. Karakteriser filsystemet til UNIX-nettverksoperativsystemet.

24. Hvilke sikkerhetsprinsipper brukes av UNIX?

25. Gi en oversikt over Linux-nettverksoperativsystemet.

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 diskplassen som kreves for å lagre dem.

Denne artikkelen begynner med en kort oversikt over historien til NFS og går deretter videre til å utforske arkitekturen til NFS og hvordan den har utviklet seg. videre utvikling.

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å de nyeste datamiljømodellene 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®-operativsystemet gir en virtuelt filsystemsvitsj (VFS) midler til samtidig å støtte flere filsystemer (for eksempel et filsystem) på en enkelt vert. ISO-systemer 9660 på CD-ROM og ext3fs filsystem på lokal harddisk). 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 presentasjon av data) som sikrer at alle NFS-brukere det samme formatet brukes 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 ulike 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 nettverksstabel gjennom RPC/XDR-laget (for å konvertere datatyper i henhold til serverarkitekturen) og kommer til 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. Det komplette diagrammet for denne prosessen er vist i figur 3. I dette tilfellet er det lokale filsystemet til serveren standard for Linux-fil system, 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 systemfunksjoner Linux), som omdirigeres via 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 det spesifisert fil og katalog 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

Av størst interesse er de to siste versjonene av NFS - 4 og 4.1, på eksemplet som du kan studere mest viktige aspekter utvikling 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 pNFS la til støtte for ulike metoder for 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 dataduplisering svært sannsynlig (flere operativsystemer leser/skriver og hurtigbufrer de samme dataene). 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 ved kopiering av data til 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-plattform® mest brukte SMB, 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 det distribuerte filsystemet Andrew, utviklet ved Carnegie Mellon University og IBM Corporation), GlusterFS (et distribuert filsystem for generell bruk for organisering av skalerbar datalagring) og Luster (en massivt parallelt nettverksfilsystem 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.

NFS-filsystemet (Network File System) ble opprettet av Sun Microsystems. Det er for tiden standard nettverksfilsystem for OS UNIX-familien I tillegg er NFS-klienter og -servere implementert for mange andre operativsystemer. Prinsippene for organisasjonen er nå standardisert av internettsamfunnet; den siste versjonen av NFS v.4 er beskrevet av RFC 300-spesifikasjonen, utgitt i desember 2000.

NFS er et system som støtter en ekstern filtilgangsordning. Brukerens arbeid med eksterne filer etter monteringsoperasjonen blir helt gjennomsiktig - undertreet til filsystemet til NFS-serveren blir et undertre av det lokale filsystemet.

Et av målene til NFS-utviklerne var å støtte heterogene systemer med klienter og servere som kjører forskjellige operativsystemer på forskjellige maskinvareplattformer. Dette målet fremmes av NFS sin implementering av Suns RFC-mekanisme, som støtter XDR-fasiliteter som standard for enhetlig representasjon av eksterne prosedyreargumenter.

For å sikre klientresiliens mot serverfeil, bruker NFS en statsløs tilnærming, det vil si at servere ikke lagrer data om filer som åpnes av klienter når de jobber med filer.

Den grunnleggende ideen med NFS er å la en vilkårlig gruppe brukere dele et felles filsystem. Som oftest tilhører alle brukere det samme lokale nettverket, men ikke nødvendigvis. Du kan også kjøre NFS på et globalt nettverk. Hver NFS-server gjør en eller flere av sine kataloger tilgjengelige for eksterne klienter. Katalogen er erklært fri med alle underkataloger. Listen over kataloger som serveren overfører finnes i filen /etc/exports, slik at disse katalogene automatisk eksporteres umiddelbart når serveren starter opp. Klienter får tilgang til eksporterte kataloger ved å montere dem. Mange Sun-arbeidsstasjoner er diskløse, men selv da kan du montere et eksternt filsystem til rotkatalogen, med hele filsystemet plassert på serveren. Utførelsen av programmer er nesten uavhengig av hvor filen ligger: lokalt eller på ekstern disk. Hvis to eller flere klienter har montert samme katalog samtidig, kan de kommunisere ved å dele en fil.

NFS-filsystemet bruker to protokoller i driften.

Den første NFS-protokollen kontrollerer monteringen. Klienten sender det fullt kvalifiserte katalognavnet til serveren og ber om tillatelse til å montere katalogen et sted i sitt eget katalogtre. I dette tilfellet blir ikke serveren fortalt hvor serverkatalogen skal monteres. Etter å ha mottatt navnet, kontrollerer serveren gyldigheten av denne forespørselen og returnerer til klienten en filbeskrivelse som er det eksterne monteringspunktet. Deskriptoren inkluderer en filsystemtypebeskrivelse, disknummer, inodenummer til katalogen som er det eksterne monteringspunktet og sikkerhetsinformasjon. Fillese- og skriveoperasjoner fra monterte filsystemer bruker filbeskrivelser i stedet for et symbolsk navn.

Montering kan gjøres automatisk ved hjelp av batch-filer ved oppstart. Det er et annet alternativ for automatisk montering: når OS starter til arbeidsstasjon det eksterne filsystemet er ikke montert, men når det først åpnes ekstern fil OS sender forespørsler til hver server og, etter å ha funnet denne filen, monterer katalogen til serveren som den funnet filen er plassert på.

Den andre NFS-protokollen brukes til å få tilgang til eksterne filer og kataloger. Klienter kan sende en forespørsel til serveren om å utføre en handling på en katalog eller lese eller skrive en fil. I tillegg kan de be om filattributter som type, størrelse, opprettelsestid og endringstid. NFS støtter de fleste UNIX-systemanrop, med unntak av åpne og lukke. Unntaket for åpne og lukke er ikke tilfeldig. I stedet for å åpne en ekstern fil, sender klienten serveren en melding som inneholder filnavnet med en forespørsel om å slå det opp og returnere filbeskrivelsen. I motsetning til det åpne anropet, kopierer ikke oppslagskallet noen informasjon til de interne systemtabellene. Leseanropet inneholder et håndtak til filen som skal leses, en offset til allerede lesbar fil og antall byte som skal leses. Fordelen med denne ordningen er at serveren ikke husker noe om åpne filer. På denne måten, hvis serveren svikter og senere gjenopprettes, vil ikke informasjon om åpne filer gå tapt fordi den ikke vedlikeholdes.

Hvis serveren svikter, fortsetter klienten ganske enkelt å sende kommandoer for å lese eller skrive filer til den, men uten å motta et svar og ha brukt tidsavbruddet, gjentar klienten sine forespørsler. Etter omstart mottar serveren den neste gjentatte klientforespørselen og svarer på den. Dermed forårsaker et serverkrasj bare noen avbrudd i klienttjenesten, men nei ytterligere handlinger Klienter er ikke pålagt å gjenopprette tilkoblinger og åpne filer på nytt.

Dessverre gjør NFS det vanskelig å låse filer. På mange operativsystemer kan en fil åpnes og låses slik at andre prosesser ikke får tilgang til den. Når filen lukkes, frigjøres låsen. I statsløse systemer som NFS kan ikke låsen assosieres med å åpne en fil, siden serveren ikke vet hvilken fil som er åpen. Følgelig krever NFS spesielle ekstra låsekontroller.

NFS bruker caching på klientsiden, overfører data til hurtigbufferen blokk for blokk og bruker read-ahead, der lesing av en blokk i cachen på forespørsel fra applikasjonen alltid ledsages av lesing av neste blokk på initiativ av systemet . NFS-bufringsmetoden bevarer ikke UNIX-semantikk for filpartisjonering. I stedet bruker den den mye kritiserte semantikken der endringer i data i en fil bufret av en klient er synlige for en annen klient, avhengig av timing. Når klienten neste gang åpner en fil i hurtigbufferen, sjekker den med serveren når filen sist ble endret. Hvis dette skjer etter at filen har blitt bufret, fjernes filen fra hurtigbufferen og a nytt eksemplar fil. Klienter sprer endringer som er gjort i hurtigbufferen med 30-sekunders intervaller, slik at serveren kan motta oppdateringer med en lang forsinkelse. Som et resultat av mekanismene for å fjerne data fra hurtigbufferen og forplante modifikasjoner, er dataene som mottas av enhver klient ikke alltid de nyeste.

NFS-replikering støttes ikke.

Katalogtjeneste

Formål og prinsipper for organisering

Som en stor organisasjon trenger et stort datanettverk sentralisert lagring av så fullstendig bakgrunnsinformasjon som mulig om seg selv. Løsningen på mange nettverksproblemer er basert på informasjon om nettverksbrukere - deres navn brukes til logisk pålogging, passord, tilgangsrettigheter til nettverksressurser, samt nettverksressurser og komponenter: servere, klientdatamaskiner, rutere, gatewayer, filsystemvolumer , skrivere osv.

Her er eksempler på de viktigste oppgavene som krever en sentralisert database med referanseinformasjon på nettverket:

• En av de mest utførte oppgavene i systemet, basert på referanseinformasjon om brukere, er deres autentisering, på grunnlag av denne autorisert tilgang. Nettverket må på en eller annen måte sentralt lagre brukerkontoer som inneholder brukernavn og passord.
• Tilstedeværelsen av en sentralisert database krever støtte for gjennomsiktig tilgang til mange nettverksressurser. En slik database bør lagre navnene på disse ressursene og tilordne navnene til numeriske identifikatorer (for eksempel IP-adresser), slik at denne ressursen kan bli funnet på nettverket. Åpenhet kan gis ved tilgang til servere, filsystemvolumer, RPC-prosedyregrensesnitt, distribuerte applikasjonsprogramobjekter og mange andre nettverksressurser.
• E-post er et annet populært eksempel på en tjeneste der det ønskes en nettverksomfattende katalogtjeneste som lagrer brukerens e-postnavn.
• I I det siste I nettverk brukes i økende grad styringsverktøy for trafikkkvalitet på tjenesten (QoS), som også krever informasjon om alle brukere og applikasjoner av systemet, deres krav til trafikkkvalitet på tjenesteparametere, samt om alle nettverksenheter, som du kan kontrollere trafikken med (rutere, brytere, gatewayer, etc.).
• Organiseringen av distribuerte applikasjoner kan forenkles betydelig hvis nettverket har en database som lagrer informasjon om eksisterende programvaremoduler-objekter og deres plassering på nettverksservere. En applikasjon som må utføre en standard handling, sender en forespørsel til en slik database og mottar adressen til et programvareobjekt som har evnen til å utføre den nødvendige handlingen.
• Nettverksstyringssystemet må ha en database for lagring av informasjon om nettverkstopologien og egenskapene til alle nettverkselementer som rutere, svitsjer, servere og klientdatamaskiner. Tilgjengelighet fullstendig informasjon om sammensetningen av nettverket og dets forbindelser tillater systemet automatisert kontroll nettverk for å identifisere meldinger om nødhendelser korrekt og finne rotårsaken. Informasjon om eksisterende nettverksutstyr og installert utstyr, organisert av virksomhetens avdelinger programvare nyttig i seg selv, siden det hjelper administratorer med å skape et pålitelig bilde av nettverkets tilstand og utvikle planer for utviklingen.

Slike eksempler kan videreføres, men det er ikke vanskelig å gi et motargument som sår tvil om behovet for å bruke en sentralisert referanseinformasjonsdatabase på nettverket – lenge fungerte nettverk uten en eneste referansedatabase, og mange nettverk fungerer fortsatt uten den. Faktisk er det mange private løsninger som lar deg organisere arbeidet til et nettverk ganske effektivt basert på private referanseinformasjonsdatabaser, som kan representeres av vanlige tekstfiler eller tabeller lagret i applikasjonens kropp. For eksempel bruker UNIX-operativsystemet tradisjonelt en passwd-fil for å lagre data om brukernavn og passord, som dekker brukere av kun én datamaskin. Navn på e-postmottakere kan også lagres i en lokal fil på klientdatamaskinen. Og slike private hjelpesystemer fungerer godt – praksis bekrefter dette.

Denne innvendingen gjelder imidlertid bare for små og mellomstore nettverk, i store nettverk individuelle lokale referansedatabaser mister sin effektivitet. Et godt eksempel som bekrefter uanvendeligheten lokale løsninger for store nettverk, er DNS-navnetjenesten som kjører på Internett. Når størrelsen på Internett overskred en viss grense, ble lagring av informasjon om korrespondansen til navn og IP-adresser til nettverksdatamaskiner i lokale tekstfiler ineffektiv. Det var nødvendig å lage en distribuert database støttet av hierarkisk koblede navneservere, og en sentralisert tjeneste på toppen av denne databasen, for å få symbolske navneløsningsprosedyrer på Internett til å fungere raskt og effektivt.

For et stort nettverk er det også lite effektivt å bruke et stort antall helpdesk snevert formål: en for autentisering, en annen for nettverksadministrasjon, andre for å løse datamaskinnavn osv. Selv om hver av disse tjenestene er godt organisert og kombinerer et sentralisert grensesnitt med en distribuert database, fører et stort antall hjelpetjenester til duplisering av store mengder informasjon og kompliserer nettverksadministrasjon og -administrasjon. For eksempel har Windows NT i det minste fem forskjellige typer referansedatabaser. Hoveddomenekatalogen (NT Domain Directory Service) lagrer informasjon om brukere som kreves når de organiserer deres logiske pålogging til nettverket. Data om de samme brukerne kan finnes i en annen katalog som brukes via epost Microsoft Mail. Tre flere databaser støtter adresseoppløsning: WINS kartlegger Netbios-navn til IP-adresser, DNS (Domain Name Server)-katalog er nyttig når du kobler et NT-nettverk til Internett, og til slutt brukes DHCP-katalogen til å automatisk tildele IP-adresser til datamaskiner på nettverket . Åpenbart kompliserer en slik rekke hjelpetjenester livet til administratoren og fører til flere feil når legitimasjonen til samme bruker må legges inn i flere databaser. Derfor i ny verson I Windows 2000 kan det meste av systemhjelpeinformasjonen lagres av Active Directory, en enkelt sentralisert hjelpetjeneste som bruker en distribuert database og er integrert med DNS-navnetjenesten.

Utviklingen av lagringssystemer for referanseinformasjon resulterte i utseendet til online operativsystemer spesialtjeneste - de såkalte katalogtjenester, også kalt katalogtjenesten (katalog - katalog, katalog). Katalogtjenesten lagrer informasjon om alle brukere og nettverksressurser i form av enhetlige objekter med visse attributter, og lar deg også reflektere relasjonene mellom lagrede objekter, for eksempel brukere som tilhører en bestemt gruppe, brukertilgangsrettigheter til datamaskiner, tilstedeværelsen av flere noder i samme undernett, kommunikasjonskoblinger mellom undernett, produksjonstilknytning av servere osv. Katalogtjenesten lar deg utføre et sett med noen grunnleggende operasjoner på lagrede objekter, som å legge til og slette et objekt, inkludert et objekt i et annet objekt, endre verdiene til et objektattributt, lese attributter og noen andre. Vanligvis bygges ulike spesifikke nettverksapplikasjoner på toppen av en katalogtjeneste, som bruker tjenestens informasjon til å løse spesifikke problemer: nettverksadministrasjon, brukerautentisering, gir tjenestegjennomsiktighet og andre som er oppført ovenfor. En katalogtjeneste er vanligvis bygget på en klient-server-modell: servere lagrer en database med kataloginformasjon som klienter bruker ved å sende passende forespørsler til servere over nettverket. For katalogtjenesteklienten vises den som en sentralisert system Selv om de fleste gode katalogtjenester har en distribuert struktur som involverer et stort antall servere, er denne strukturen transparent for klienter.

En viktig sak er organiseringen av referansedatabasen. En enkelt database som lagrer store mengder referanseinformasjon gir opphav til de samme mange problemer som enhver annen stor database. Å implementere en helpdesk som en lokal database lagret som en enkelt kopi på en av nettverksserverne er ikke egnet for et stort system av flere grunner, først og fremst på grunn av den lave ytelsen og lave påliteligheten til en slik løsning. Ytelsen vil være lav på grunn av at forespørsler til databasen fra alle brukere og applikasjoner på nettverket vil komme til en enkelt server, som store mengder forespørsler vil definitivt slutte å håndtere behandlingen. Det vil si at en slik løsning ikke skalerer godt i forhold til antall brukere som betjenes og delte ressurser. Pålitelighet kan heller ikke være høy i et system med en enkelt kopi av data. I tillegg til å fjerne begrensninger på ytelse og pålitelighet, er det ønskelig at databasestrukturen tillater logisk gruppering av ressurser og brukere etter strukturelle inndelinger av virksomheten og tilordne en administrator til hver slik gruppe.

Problemer med å opprettholde ytelse og pålitelighet når nettverket skaleres opp, løses vanligvis av distribuerte databaser med referanseinformasjon. Deling av data på tvers av flere servere reduserer belastningen på hver server, mens pålitelighet oppnås ved å ha flere replikaer av hver del av databasen. For hver del av databasen kan du tilordne din egen administrator, som kun har tilgangsrettigheter til objekter av sin del av informasjon om hele systemet. For brukeren (og for nettverksapplikasjoner) ser en slik distribuert database ut til å være en enkelt database som gir tilgang til alle nettverksressurser, uavhengig av hvilken arbeidsstasjon forespørselen kom fra.

Det er to populære standarder for katalogtjenester. For det første er dette X.500-standarden, utviklet av ITU-T (på det tidspunktet standarden ble utviklet, ble denne organisasjonen kalt CCITT). Denne standarden definerer funksjonene, organiseringen av helpdesk og protokollen for tilgang til den. X.500-standarden er designet primært for bruk med X.400-posttjenesten, og tillater effektiv lagring av all kataloginformasjon og fungerer som et godt grunnlag for en universell nettverkskatalogtjeneste.

En annen standard er LDAP-standarden (Light-weight Directory Access Protocol) utviklet av internettsamfunnet. Denne standarden definerer en forenklet protokoll for tilgang til katalogtjenester, siden tjenester bygget på X.500-standarden har vist seg å være for tungvint. LDAP har blitt utbredt og har blitt de facto-standarden for klienttilgang til helpdesk-ressurser.

Det finnes også flere praktiske implementeringer av katalogtjenester for nettverksoperativsystemer. Den mest brukte tjenesten er Novells NDS-tjeneste, utviklet i 1993 for nettverksoperativsystemet NetWare 4.0, og i dag også implementert for Windows NT/2000. Active Directory, en katalogtjeneste utviklet av av Microsoft for Windows 2000. Begge disse tjenestene støtter LDAP-tilgangsprotokollen og kan fungere i svært store nettverk på grunn av deres distribuerte natur.

NDS-katalogtjeneste

NDS (NetWare Directory Services) er en global katalogtjeneste som er avhengig av en distribuert, objektorientert database med nettverksressurser. NDS-databasen inneholder informasjon om alle nettverksressurser, inkludert informasjon om brukere, brukergrupper, skrivere, volumer og datamaskiner. NetWare OS (så vel som andre NDS-klienter som kjører på andre plattformer) bruker NDS-informasjon for å gi tilgang til disse ressursene.

NDS-databasen erstattet bindery-katalogen til tidligere versjoner av NetWare. Bindekatalogen er en "flat" eller enkeltlags database designet for å støtte en enkelt server. Den brukte også konseptet "objekt" for en nettverksressurs, men tolkningen av dette begrepet skilte seg fra den generelt aksepterte. Bindeobjekter ble identifisert med enkle numeriske verdier og hadde spesifikke attributter. Imidlertid ble det ikke definert noen eksplisitte objektklasse-arvforhold for disse objektene, så relasjoner mellom bindery-objekter ble satt vilkårlig av administratoren, noe som ofte førte til datakorrupsjon.

NDS-tjenestedatabasen er en flerlagsdatabase som vedlikeholder ressursinformasjon for alle servere på nettverket. For kompatibilitet med tidligere versjoner av NetWare, tilbyr NDS en bindery-databaseemuleringsmekanisme.

NDS er en betydelig forbedring i forhold til tidligere versjoner med:

• fordeling;
• replikerbarhet;
• åpenhet;
• globalitet.

Distribusjon betyr at informasjon ikke lagres på én server, men deles inn i deler som kalles partisjoner. NetWare lagrer disse partisjonene på flere servere på nettverket (Figur 10.8). Denne funksjonen forenkler administrasjon og administrasjon betydelig stort nettverk, siden det ser ut for administratoren som et enkelt system. I tillegg gis raskere tilgang til nettverksressursdatabasen ved å få tilgang til nærmeste server.

Ris. 10.8. NDS-databasepartisjoner

En replika er en kopi av NDS-partisjonsinformasjonen. Du kan opprette et ubegrenset antall replikaer av hver partisjon og lagre dem på forskjellige servere. Hvis en server stopper, kan kopier av denne informasjonen fås fra en annen server. Dette øker systemets motstandskraft siden ingen enkelt server er ansvarlig for all NDS-databaseinformasjonen.

Åpenhet ligger i det faktum at NDS automatisk oppretter forbindelser mellom programvare- og maskinvarekomponenter som gir brukertilgang til nettverksressurser. NDS krever ikke at brukeren kjenner til den fysiske plasseringen av disse ressursene. Ved å spesifisere en nettverksressurs ved navn, vil du ha riktig tilgang til den selv om nettverksadressen eller plasseringen endres.

Den globale karakteren til NDS ligger i det faktum at du etter pålogging får tilgang til ressursene til hele nettverket, og ikke bare én server, slik tilfellet var i tidligere versjoner. Dette oppnås gjennom den globale påloggingsprosedyren. I stedet for å logge på en egen server, logger NDS-brukeren på nettverket, og har da tilgang til nettverksressursene som er autorisert for ham. Informasjonen som gis under innlogging brukes til å identifisere brukeren. Senere, når brukeren prøver å få tilgang til ressurser som servere, volumer eller skrivere, bakgrunnsprosess identifikasjon sjekker om brukeren har rettigheter til en gitt ressurs.