1.4 Netværksfilsystem

CIFS-filsystemet dominerer markedet netværksfiler systemer til Windows platforme. På UNIX-platformen er den vigtigste netværksfilsystemet (Netværk Filsystem- NFS). Derudover anses NFS for at være det første bredt anvendte filsystem, der dateres tilbage til midten af ​​1980'erne. Dog trods nogle generelle funktionalitet CIFS og NFS (netværksfilsystemer, der giver klienter adgang til serverressourcer), disse systemer har helt andre arkitektoniske funktioner. Med udgivelsen af ​​NFS version 4 er nogle forskelle blevet revideret.
CIFS-protokollen gemmer servicedata, der er specifikke for hver klient. Før version 3 beholdt NFS-filsystemet ikke klientstatus, hvilket ændrede sig i version 4.
NFS-klienten "forhandler" ikke med NFS-serveren for at etablere en session. Der tages sikkerhedsforanstaltninger for hele sessionen eller hver kommunikation mellem klienten og serveren. Sidstnævnte mulighed er uoverkommeligt dyr at implementere, så NFS overlader sikkerhedsansvaret til klienten. Serveren "antager", at bruger-id'erne på klient- og serversystemerne er de samme (og klienten har verificeret brugerens identitet, før han tillader ham at registrere sig under specificeret identifikator). Derudover giver NFS et vist niveau af sikkerhed ved at kontrollere listen over filsystemer, som en klient kan montere. Hver gang en CIFS-klient åbner en fil, modtager et filhåndtag (det vil sige servicedata, som serveren skal gemme) og bruger det til at udføre læse- eller skriveoperationer på klientsiden, forespørger NFS-serveren serveren, som returnerer filen håndtere. Denne filbeskrivelse behandles af klienter, der understøtter standarderne NFS 3 og NFS 2. Klienten cacher den resulterende filbeskrivelse og forventer, at deskriptoren altid peger på den samme fil.
For dem, der er bekendt med UNIX, består en filbeskrivelse typisk af et inodenummer, en inodegenereringstælling og det fil-id, der er knyttet til diskpartitionen. Det er tilstrækkeligt at sige, at inoden er en ekstremt vigtig datastruktur, der bruges i UNIX-filsystemer. Der gemmes tilstrækkelig information til at fjerne håndtag, der er cachelagret af klienter, hvis den tilsvarende fil for håndtaget er ændret, og håndtaget skal pege på en anden fil. For eksempel, hvis en fil slettes, og en fil med samme navn kopieres i stedet for, vil inodegenereringstælleren blive ændret, og filbeskrivelsen, som er cachelagret af klienten, vil være ugyldig. NFS 4-filsystemet har forskelle i implementering.
Nogle NFS-klienter udfører cachelagring på klientsiden ved at gemme data på diske, hvilket svarer til CIFS-cachelagring. Nogle NFS-klienter ændrer også værdien af ​​timeouts afhængigt af serverens responstid. Jo langsommere serveren reagerer, jo større timeoutværdi og omvendt.
NFS-filsystemet blev designet til at være transportuafhængigt og brugte oprindeligt UDP-transportprotokollen. Forskellige typer NFS kan bruge TCP og andre protokoller.

1.4.1 Netværksfilsystem version 3

NFS 3-filsystemet forbedrer ydeevnen, især for store filer, ved at tillade klienten og serveren dynamisk at vælge den maksimale mængde data, der overføres i ét logisk pakkeelement, når de skriver eller læser. I NFS 2-filsystemet var pakkestørrelsen begrænset til 8 KB. Med andre ord kunne klienten maksimalt sende 8 KB i en skriveanmodning, og serveren kunne maksimalt sende 8 KB i et læseanmodningssvar. Derudover har NFS 3 omdefineret filforskydninger og datastørrelser. Disse er nu 64-bit værdier i stedet for 32-bit i NFS 2.
Nedenfor er nogle af funktionerne i NFS 3.
■ Filbeskrivelser i NFS 3 er variabel størrelse; deres maksimale størrelse er 64 bit.
■ NFS 3-filsystemet giver klienter og servere mulighed for at vælge den maksimale størrelse for fil- og mappenavne.
■ NFS 3 definerer en liste over fejl, som serveren kan returnere til klienter. Serveren skal returnere en af ​​de angivne fejl eller slet ingen fejl.
■ I NFS 3 har serveren lov til at cache data, som klienten sendte med en skriveanmodning. Serveren kan cache data og sende et svar på anmodningen til klienten, før dataene skrives til disken. Der er også tilføjet en COMMIT-kommando, som giver klienten mulighed for at sikre, at alle indsendte data er blevet skrevet til disken. Dette gør det muligt at finde en balance mellem at forbedre ydeevnen og bevare dataintegriteten.
■ NFS 3 reducerer antallet af anmodnings-/svarhandlinger mellem klient og server. For at gøre dette sendes filattributdata sammen med den første anmodning. I NFS 2 skulle klienten indhente filnavne og en deskriptor for hver fil, først derefter blev filattributterne overført.

1.4.2 Netværksfilsystem version 4

NFS 4 gennemgik de grundlæggende principper fuldstændigt og implementerede mange CIFS-specifikke funktioner, hvilket i høj grad forstyrrede nogle NFS-apologeter. Hvis du ser på historien om netværksfilsystemer, kan du se, at NFS er blevet udbredt. SMB-filsystemet blev designet under hensyntagen til styrkerne og svaghederne ved NFS og nu ifølge i det mindste blandt klienter er CIFS/SMB mere almindelige, og NFS er under udvikling, idet der tages højde for alle ulemper og fordele ved CIFS/SMB. Det følgende fremhæver funktioner, der blev føjet til NFS 4 for at forbedre ydeevne, sikkerhed og interoperabilitet med CIFS.
■ NFS 4 introducerede COMPOUND-anmodningen, som giver dig mulighed for at pakke flere anmodninger i en enkelt anmodning og flere svar i et enkelt svar. Denne innovation er designet til at forbedre ydeevnen ved at reducere netværksbelastningen og reducere latens, når anmodninger og svar rejser på tværs af netværket. Hvis dette lyder lidt som CIFS AndX SMB-funktionen (se afsnit 3.3.5.1), så er det måske ikke en simpel tilfældighed.
■ Network File System version 4 låner nogle funktioner fra Suns WebNFS. Især NFS 4 understøtter nogle sekundære protokoller i basisspecifikationen, hvilket gør NFS mere velegnet til brug med firewalls. I NFS 3 og nyere tidligere versioner en speciel protokol blev brugt til at montere serverdelingen i det lokale filsystemtræ. Fordi mount-protokoltjenesten ikke havde en TCP- eller UDP-port tildelt, sendte klienten først en anmodning til portmapper-dæmonen, som angiver det portnummer, som mount-tjenesten lytter efter anmodninger på. Ud over NFS deltog således monterings- og portkortlægningsprotokoller i processen. Desuden, da mount-tjenesten kunne bruge en vilkårlig port, blev det meget vanskeligt at konfigurere firewallen. I NFS 4 blev mount- og portmapping-protokollerne fjernet. Derudover var låsning inkluderet i basis NFS-protokolspecifikationen, og NLM-protokollen (Network Lock Manager), som blev brugt i tidligere versioner af NFS, er blevet permanent forældet.
■ NFS 4-filsystemet kræver brug af en transportprotokol, der giver mulighed for at registrere netværksoverbelastning. Det betyder, at NFS-klienter og -servere gradvist vil flytte til TCP i stedet for UDP, som almindeligvis bruges med NFS 3.
■ NFS 2 og NFS 3 tillod brugen af ​​det amerikanske tegnsæt. ASCII eller ISO Latin 1. Dette forårsagede problemer, da en klient, der brugte et tegnsæt, oprettede en fil, og denne fil blev tilgået af en klient, der brugte et andet tegnsæt. NFS 4 bruger UTF-8-tegnsættet, som understøtter kompakt komprimering af 16- og 32-bit tegn til transmission over netværket. Derudover indeholder UTF-8-tegnsættet nok information til at undgå problemer, når du opretter en fil med et tegnsæt og får adgang til en fil med et andet tegnsæt.
■ NFS 4-filsystemet kræver, at klienten håndterer filbeskrivelser separat. I NFS 3 kunne klienten cache håndtaget som et objekt, mens serveren sikrede, at håndtaget altid pegede på en fil. NFS 4 definerer to typer filbeskrivelser. Den ene kaldes persistente fildeskriptorer og har evnerne til filbeskrivelser fra NFS 3. Den anden, midlertidige fildeskriptorer, antager, at deskriptoren udløber efter et bestemt tidsrum eller begivenhed. Dette er en funktion til servere, hvis filsystemer (såsom NTFS) ikke kan levere en ensartet kortlægning mellem viste filer og håndtag.
■ NFS 4 tilføjer understøttelse af OPEN- og CLOSE-operationer, hvis semantik tillader interaktion med CIFS-klienter. OPEN-kommandoen opretter tilstandsdata på serveren.
■ NFS 4's OPEN-anmodningsunderstøttelse giver en klient mulighed for at udstede en filåbningsanmodning, der er struktureret på samme måde som Windows-applikationsåbningsanmodninger. Udvælgelse er også understøttet deling fil med andre klienter eller eksklusiv adgang til filen.

1.4.2.1 NFS 4-sikkerhed

NFS 4-filsystemet giver dig mulighed for at forbedre sikkerheden for lagrede data. Især tilføjer NFS 4 understøttelse af flere filattributter. En af disse attributter er en Windows NT-stiladgangskontrolliste (ACL). Dette giver mulighed for forbedret interoperabilitet mellem filsystemer og en stærkere sikkerhedsstruktur.
Mens brugen af ​​sikkerhedsfunktioner i NFS 2 og NFS 3 kun blev anbefalet, er det i NFS 4 blevet obligatorisk. NFS 4-filsystemet kræver implementering af en sikkerhedsmekanisme, der bruger RPCSEC_GSS (Generic Security Services)-grænsefladen generelt og Kerberos 5/LIPKEY-protokollerne i særdeleshed. Bemærk, at RPCSEC_GSS simpelthen fungerer som en API og transportmekanisme for sikkerhedsrelaterede etiketter og data. NFS 4-filsystemet giver mulighed for flere godkendelses- og sikkerhedsskemaer og muligheden for at vælge det passende skema til klienter og servere.
Lad os være lidt opmærksomme på at studere LIPKEY-teknologien, som bruger en kombination af symmetrisk og asymmetrisk kryptering. Klienten krypterer brugerdata og adgangskode ved hjælp af en tilfældigt genereret 128-bit nøgle. Kryptering udføres ved hjælp af en symmetrisk algoritme, dvs. den samme nøgle skal bruges til dekryptering. Da serveren har brug for denne nøgle til at dekryptere meddelelser, skal en tilfældigt genereret nøgle sendes til serveren. Klienten krypterer nøglen (som er tilfældigt genereret) med offentlig nøgle server. Serveren dekrypterer dataene med sine privat nøgle, udtrækker den symmetriske nøgle og dekrypterer brugerdata og adgangskode.
Klienter kan godkende servere ved hjælp af et servercertifikat, og certifikatmyndighedstjenester bruges til at verificere certifikatet. En af de populære hackingmetoder er at opsnappe "fremmede" datapakker og derefter sende dem efter en vis periode. Når du bruger Kerberos, tilføjer NFS-filsystemet et tidsstempel til hver pakke. Serverregistreringerne modtog for nylig tidsstempler og sammenligner dem med tidsstemplerne for nye RPC-pakker. Hvis pakkernes tidsstempler er ældre end dem, der tidligere er modtaget af serveren, ignorerer serveren de modtagne pakker

1.5 Adgangsproblemer ved brug af flere protokoller

Flere virksomheder er begyndt at tilbyde systemer, der samtidig understøtter CIFS, NFS og andre netværksfilsystemklienter. Leverandører har gjort en masse arbejde for at overvinde de tekniske udfordringer, der opstår fra kunder, der potentielt bruger forskellige operativsystemer og filsystemer. Bemærk venligst, at problemerne ikke opstår med selve dataene, men med filernes metadata. En simpel test for sådanne problemer ville være at kopiere en fil fra serveren til klienten og tilbage til serveren (eller omvendt). Når filen er placeret i den indledende ressource, skal metadataene indeholde basisværdierne, dvs. Filtilladelser og tidsstempler bør ikke ændres. Hvis dette ikke er sandt, er problemet blevet opdaget.
Følgende er eksempler på nogle mulige tekniske problemer.
■ Forskellige operativsystemer bruger forskellige metoder til at spore bruger- og gruppeadgangstilladelser.
■ Forskellige operativsystemer og filsystemer har forskellig semantik til åbning og låsning af filer.
■ Filnavnekonventioner håndteres på forskellige måder. Forskellige filsystemer har forskellige repræsentationer af den maksimale størrelse af et filnavn, et filnavns store og små bogstaver og det tilladte tegnsæt i navne.
■ Data og deres struktur er forskellige i forskellige filsystemer; for eksempel sporer nogle filsystemer to tidsstempler, mens andre sporer tre tidsstempler (det tidspunkt, hvor filen sidst blev tilgået, filen blev sidst ændret, og filen blev oprettet). Selvom begge filsystemer sporer to tidsstempler, kan måleenhederne variere. Et andet eksempel er enheder til måling af forskydninger i filer. Nogle filsystemer understøtter 32-bit offsets, og nogle understøtter 16- eller 64-bit offsets.
■ Problemer med adressering af viste låse. CIFS-serveren gennemtvinger låsning: Hvis en klient har låst et område af en fil, vil enhver skriveoperation til den filregion af en anden klient resultere i en fejl. Tvungen låsning understøttes dog ikke af NFS-servere. Derfor skal du vælge, om låsen skal håndhæves, hvilket vil resultere i, at der sendes en fejlmeddelelse til NFS-klienten.

FEDERAL LUFTTRANSPORTAGENTUR

FORBUNDSSTATS UDDANNELSESINSTITUTION

HØJERE PROFESSIONEL UDDANNELSE

"MOSKVA STAT

TEKNISK UNIVERSITET

CIVIL LUFTFART"

____________________________________________________________________________________________________________________

Institut for computere, komplekser, systemer og netværk

NETVÆRKSoperativsystemer.

NETVÆRKSFILSYSTEMER

OG VEJLEDNINGSSERVICE

Redaktionelt godkendt

Publishing Council of MSTU GA

Moskva - 2010

BBK 32.973.202-018.2ya73-1+32.973.26-018.2ya73-1

Udgivet efter beslutning af redaktions- og forlagsrådet

Moscow State Technical University of Civil Aviation

Anmeldere: Ph.D. fysik og matematik Videnskaber, lektor ;

Ch48 netværksoperativsystemer. Netværksfilsystemer og bibliotekstjenester: En selvstudie. - M.: MSTU GA, 2010. –68 s. 10 ill., lit.: 4 navn.

Denne lærebog er udgivet i overensstemmelse med arbejdsprogrammet for den akademiske disciplin "Netværksoperativsystemer" i henhold til Curriculum for speciale 230101 for fjerdeårs fuldtidsstuderende.

Gennemgået og godkendt på møder i afdelingen den 05/11/10 og metoderådet den 14/05/10.

-038 BBK 32.973.202-018.2ya73-1+32.973.26-018.2ya73-1

Ts33(03)-10 St. temaer. 2010 plan

CHERKASOVA Natalya Ivanovna

NETVÆRKSoperativsystemer.

NETVÆRKSFILSYSTEMER OG katalogtjenester

Tutorial

Redaktør

Underskrevet til offentliggørelse den 11. oktober 2010.

Offsettryk Format 60x84/16 4.0 akademisk udg. l.

3,95 konventionel ovn l. Best. nr. 000 / Oplag 100 eksemplarer.

Moscow State Technical University of Civil Aviation

125993 Moskva, Kronstadtsky Boulevard, 20

Redaktion og forlagsafdeling

125493 Moskva, st. Pulkovskaya, 6a

© Moskva-staten

Technical University of GA, 2010

Afsnit 1. Sammensætning af netværksoperativsystemer

1.1. Netværks OS. Definition, grundlæggende egenskaber

Netværket kan være alt fra et simpelt sæt computere (to tilsluttet computer allerede har et netværk) til globalt Internet netværk, ved hjælp af en bred vifte af kommunikationsmedier, herunder mikrobølge- og satellitteknologier.

Et netværk består af computere, kommunikationsmedier (f.eks. kobber eller fiberoptiske kabler) og andre enheder såsom hubs forskellige typer og routere (som giver dig mulighed for at administrere netværkstrafik), adaptere (bruges til at forbinde en computer til et netværk), der danner en netværksstruktur. Teknologier til transmission af information er også meget forskellige.

Der tages hensyn til to typer netværk: LAN ( Lokalområde netværk) - et lokalt netværk, et sæt computere og enheder samlet i en bygning og WAN (Wide Area Network) - et globalt netværk, der kombinerer flere geografisk adskilte lokale netværk, som er forbundet via forskellige WAN-teknologier.

Formålet med et netværk afhænger af en persons eller en organisations behov, men generelt kan følgende muligheder for at bruge netværk opstilles:

1) fildeling. Netværket giver dig mulighed for at bruge datafiler både gemt på en specifik brugers computer og filer hostet på en specialiseret filserver;

2) deling af hardware;

3) deling af software;

4) udveksling af information mellem brugere;

5) netværksspil.

Netværket stiller ikke kun lokale ressourcer til rådighed, men selve netværkets eksistens betyder, at det kan kombineres med andre netværk.

Operativsystemer til netværk ligner på mange måder operativsystemet på en selvstændig computer. Men hvis sidstnævnte præsenterer brugeren for en bestemt virtuel computer, så præsenterer netværksoperativsystemet brugeren for et bestemt virtuelt computersystem, som er meget lettere at arbejde med end med et rigtigt. netværksudstyr, skjuler ikke fuldstændigt den distribuerede natur af sin virkelige prototype. Vi kan sige, at netværks-OS giver brugeren virtuelt netværk. Ideelt set bør et netværks-OS præsentere netværksressourcer for brugeren som ressourcer fra en enkelt centraliseret virtuel maskine. Sådanne operativsystemer kaldes distribueret OS eller virkelig distribueret OS.

Distribuerede operativsystemer, ved dynamisk og automatisk at distribuere arbejde på tværs af forskellige systemmaskiner til behandling, får et sæt netværksmaskiner til at fungere som en virtuel uniprocessor. Et distribueret OS fungerer som et enkelt operativsystem på tværs af et computersystem.

Moderne netværks-OS'er er ikke rigtigt distribuerede, det vil sige, at graden af ​​autonomi for hver computer på netværket, der kører et netværks-OS, er betydeligt højere sammenlignet med computere, der kører et distribueret OS.

Udtrykket netværks-OS bruges i to betydninger: for det første som helheden af ​​operativsystemet for alle computere på netværket, og for det andet som operativsystemet på en individuel computer, der er i stand til at arbejde på netværket. Funktionelt kan netværkets OS opdeles i følgende komponenter:

1) lokale ressourcestyringsværktøjer, det vil sige alle funktioner i operativsystemet på en autonom computer;

2) serverdelen af ​​operativsystemet er et middel til at levere lokale ressourcer og tjenester til offentlig brug;

3) klientdel af operativsystemet - midler til adgang til eksterne ressourcer og tjenester;

4) køretøjer OS, som sammen med kommunikationssystemet sikrer overførsel af beskeder mellem computere på netværket.

Kombinationen af ​​server- og klientdele af operativsystemet, der giver adgang til en specifik ressource via netværket, kaldes en netværkstjeneste. En netværkstjeneste giver en netværksbruger et bestemt sæt tjenester, der kaldes netværkstjeneste. Hver tjeneste er knyttet til en bestemt type netværksressource og/eller på bestemte måder adgang til disse ressourcer.

Netværkstjenester er klient-server-systemer, det vil sige, at de indeholder en klient og en serverdel. En netværkstjeneste kan dog repræsenteres i OS af enten begge dele eller kun én af dem.

Det skal bemærkes, at når en netværkstjeneste leverer en bestemt tjeneste, bruges ressourcerne på ikke kun serveren, men også klienten. Den grundlæggende forskel mellem en klient og en server er, at klienten altid er initiativtager til arbejdet i en netværkstjeneste, og serveren er altid i en passiv tilstand af at vente på anmodninger.

Selvom én type server kan designes til at håndtere forskellige typer klienter, skal klienten og serveren understøtte en fælles standardkommunikationsprotokol.

Dybden af ​​implementering af netværkstjenester i operativsystemet bestemmer flere tilgange til at bygge netværks-OS'er:

1) netværkstjenester kombineres i form af et bestemt sæt - en skal;

2) netværkstjenester leveres og fremstilles som et separat produkt;

3) netværkstjenester er implementeret i OS.

Forskellige mål forfulgt under oprettelsen forskellige netværk, foreslår tilstedeværelsen af ​​forskellige typer netværk. Peer-to-Peer-netværk er en enkel måde at oprette forbindelse på personlige computere i tilfælde, hvor det er nødvendigt at dele filer og andre ressourcer. I et peer-to-peer-netværk er der ingen server, og alle computere fungerer som peers. Et peer-to-peer-netværk kaldes ofte arbejdsgruppe(Arbejdsgruppe), da dette udtryk er forbundet med peer-to-peer-samarbejde uden centraliseret kontrol.

En netværksknude er en computer, der forbinder to netværk ved hjælp af de samme protokoller. Noden giver kun kommunikation mellem to kompatible programmer på to sådanne netværk. Noder bruger i det væsentlige adresseinformationen indeholdt i de transmitterede pakker. Noder er netværkslagsenheder.

Lad os overveje softwaren til sådanne netværk. I peer-to-peer-netværk er der installeret et OS på alle computere, som giver potentielt lige muligheder for alle computere på netværket. Det er klart, at sådanne peer-to-peer OS'er skal omfatte både server- og klientnetværksservicekomponenter.

Med den potentielle lighed for alle computere i et peer-to-peer-netværk opstår der ofte funktionel heterogenitet. Der kan være brugere på netværket, som ikke deler deres ressourcer.

I dette tilfælde er serverfunktionerne i deres OS ikke aktiveret, og computerne fungerer som "rene" klienter. Den modsatte situation er også mulig, når nogle computere kun udfører funktioner for at servicere klientanmodninger, det vil sige, at de bliver "rene" servere. Men i første omgang i peer-to-peer-netværk afhænger OS-specialisering ikke af computerens rolle.

DOS understøttede ikke peer-to-peer-netværk, så deling af filer eller printere krævede yderligere softwareprodukter, dvs. netværksfunktioner blev implementeret af netværksskaller, der kørte oven på operativsystemet. For at understøtte arbejdsgrupper, softwareprodukter såsom Artisoft LANtastic, Novell NetWare Lite, Personal NetWare og Windows til Arbejdsgruppe 3.11. Alle efterfølgende versioner af Windows understøtter arbejdsgrupper.

Linux-distributioner understøtter også oprettelsen af ​​arbejdsgrupper fra computere, der kører Windows eller Linux ved hjælp af Samba.

Selvom de vigtigste fordele ved peer-to-peer-netværk først og fremmest inkluderer nem installation, er der en række andre fordele:

1) normalt er al den nødvendige software allerede inkluderet i OS;

2) systemadministration er ikke påkrævet, og individuelle brugere kan selv administrere ressourcer;

3) netværksknuder er ikke afhængige af serveren, derfor kan de fungere, selv når andre noder er utilgængelige.

Men i et sådant netværk er antallet af computere strengt defineret - ikke mere end ti. Fordeling af ressourcer på tværs af et netværk med et stort antal noder vil gøre det vanskeligt at få adgang til filer, som hver især kunne være beskyttet din egen adgangskode. Derudover er centraliseret beskyttelse umulig her; den eneste mulige beskyttelse er beskyttelse på ressourceniveau. Generelt er der en stigning i belastningen på computere på grund af ressourcedeling.

Netværk med en dedikeret server (eller servere) (serverbaserede netværk) kan være meget store og give brugerne mere bredt udvalg ressourcer sammenlignet med peer-to-peer netværk. Dette skyldes først og fremmest, at et sådant netværk har forskellige specialiserede servere.

Derudover tillader disse netværk centraliseret ressourcestyring og tilføjelse af nye computere, brugere og ressourcer til netværket. Sådanne netværk er skalerbare, det vil sige, at de nemt kan udvides.

Det eneste krav til et sådant netværk er tilstedeværelsen af ​​en computer, der kører netværksoperativsystemet, sådan en computer kaldes en server.

Ligesom et peer-to-peer-netværk har dedikerede servernetværk deres fordele og ulemper. Først og fremmest, lad os liste fordelene:

1) for at få adgang til netværksressourcer indtaster brugeren kun ét registreringsnavn og adgangskode;

2) netværkssikkerhed og netværksressourcer administreres centralt;

3) centraliseret placering giver dig mulighed for at udføre backup mapper og filer;

4) specialiserede servere giver hurtig adgang til ressourcer;

5) sådanne netværk kan udvides.

Lad os nu bemærke en række ulemper:

1) det er nødvendigt at konfigurere og administrere ressourcer på netværket, det vil sige, at der kræves en systemadministrator;

2) hvis hovedserveren fejler, afsluttes adgangen til netværksressourcer;

3) økonomisk er netværk med en dedikeret server kun gavnlige for ret store virksomheder.

Alt efter hvordan funktioner fordeles mellem computere på netværket, kan de således fungere i tre forskellige roller:

1) en computer i rollen som en dedikeret netværksserver, dvs. kun betjener anmodninger fra andre computere;

2) en computer, der sender en anmodning til ressourcerne på en anden maskine, er en klientknude;

3) en computer, der kombinerer funktionerne af en klient og en server, er en peer-to-peer node.

Derfor kan man definere forskellige netværksdesignskemaer som:

1) peer-to-peer netværk – et netværk baseret på peer-to-peer noder;

2) netværk med en dedikeret server – et netværk baseret på klienter og servere.

Et netværk kan dog omfatte alle typer noder – et hybridnetværk, som nogle gange omtales som et dedikeret servernetværk.

Klientoperativsystemer i netværk med en dedikeret server er normalt frigjort for serverfunktioner, hvilket i høj grad forenkler deres organisation. Udviklere af sådanne operativsystemer fokuserer på brugergrænseflade og klientdele af netværkstjenester. Samtidig bruger servere specielle versioner af netværksoperativsystemer, der er optimeret til at fungere som server og kaldes serveroperativsystemer.

OS specialisering til at fungere som en server er på en naturlig mådeøge effektiviteten af ​​serverdrift, da intensiteten af ​​anmodninger til delte ressourcer kan være meget stor, og serveren skal klare det uden lange forsinkelser. Jo færre funktioner operativsystemet udfører, jo mere effektivt kan de implementeres.

For at optimere ydeevnen af ​​tjenester udelukkede NetWare-udviklere fuldstændigt mange elementer af det universelle OS fra systemet og efterlod udelukkende netværkselementer. Imidlertid producerer mange virksomheder, der udvikler netværksoperativsystemer, to versioner af operativsystemer baseret på den samme basiskode, men med et andet sæt tjenester og hjælpeprogrammer - server- og klientoperativsystemer.

Forskellige netværkstjenester kan hostes på flere specialiserede servere, og den centrale server tillader ikke kun brugeren at komme ind på netværket, men bestemmer også hvilke ressourcer brugeren får adgang til.

Lad os se på de vigtigste specialiserede servere.

Filservere bruges til at gemme filer, der er nødvendige for netværksbrugere. Printservere bruges til at administrere netværksprinter, i det væsentlige er dette en kontrolkanal for kommunikation med printeren.

En kommunikationsserver bruger speciel software, der giver brugerne mulighed for at kommunikere online. Det understøtter e-mail- og telekonferencetjenester. Applikationsserveren er vært for forskellige applikationer, og serveren giver dig mulighed for at oprette et websted, selvom du kan bruge tjenester fra en udbyder til at hoste webstedet.

Nogle typer servere bruges ikke til at få adgang til ressourcer, men for at forbedre kvaliteten og effektiviteten af ​​netværket. For eksempel DNS-server (Domain Name Service) - domænenavnstjenesten opløser venlige navne til tilsvarende adresser.

Lad os nu se på interaktionen mellem klienten og serverens OS mere detaljeret. Når en computer får adgang til en fil på et lokalt drev eller en direkte tilsluttet printer, sendes anmodningen til computerens processor. Processoren udfører anmodningen, og alle operationer udføres lokalt. Når du får adgang til delinger på en filserver eller udskriver til en fjernprinter, udfører netværksklientsoftwaren en speciel handling, der får computeren til at betragte netværksdelingerne som lokale.

Denne proces udføres af en komponent af klientsoftwaren kaldet en redirector (REDIRECTOR). Den opsnapper alle anmodninger på computeren og, afhængigt af typen af ​​anmodning, sender den til en netværksserver til behandling eller bestemmer, at anmodningen vil blive udført lokalt.

1.2. Understøttelse af OS-baserede netværkWindows2000. NiveauerOSIog OS netværkskomponenterWindows2000. NetværkAPI

Lad os se på mekanismerne til at bygge et netværksoperativsystem ved hjælp af Windows 2000 som eksempel.

Reference modelOSI (OSI-referencemodellen)

For at hjælpe leverandører med at standardisere og integrere netværkssoftware, definerede International Organization for Standardization (ISO) i 1974 software model videresendelse af beskeder mellem computere. Resultatet var referencemodellen Open Systems Interconnection (OSI). Modellen definerer syv niveauer af software (fig. 1).

DIV_ADBLOCK314">

De stiplede linjer i figuren viser de protokoller, der bruges til at sende anmodningen til den eksterne maskine. Hvert netværkslag mener, at det kommunikerer med et tilsvarende lag på en anden maskine, der bruger den samme protokol. Sættet af protokoller, der sender anmodninger på tværs af netværkslag, kaldes en protokolstak.

Netværk KomponenterWindows 2000 (netværkskomponenter)

I fig. 2 præsenteret almindelig ordning netværksprotokoller Windows 2000, deres korrespondance til niveauer referencemodel, samt de anvendte protokoller forskellige niveauer. Som du kan se, er der ingen nøjagtig overensstemmelse mellem modelniveauerne og netværkskomponenterne. Nogle komponenter spænder over flere niveauer. Følgende er en liste og en kort beskrivelse:

1) Netværks-API'er giver protokol-uafhængig interaktion af applikationer over netværket. Netværks-API'er implementeres enten i kernetilstand og brugertilstand eller kun i brugertilstand. Nogle netværks-API'er ombryder andre API'er og implementerer en specifik programmeringsmodel eller leverer yderligere tjenester. (Begrebet netværks-API refererer til alle programmeringsgrænseflader, der eksponeres af netværkssoftware);

2) TDI (Transport Driver Interface) klienter. Kernel-mode enhedsdrivere, der typisk implementerer den del af netværks-API'en, der kører i kernetilstand. TDI-klienter hedder sådan, fordi I/O-anmodningspakkerne (IRP'er), de sender til Windows 2000-protokoldrivere, er formateret ved hjælp af Transport Driver Interface-standarden (dokumenteret i DDK). Denne standard definerer en fælles programmeringsgrænseflade for enhedsdrivere i kernetilstand;

3) TDI transporter. De er kernetilstandsprotokoldrivere og kaldes ofte transporter (Network Driver Interface Specification), NDIS-protokoldrivere eller protokoldrivere. De accepterer IRP'er fra TDI-kunder og behandler anmodninger indsendt af disse IRP'er. Behandling af anmodninger kan kræve kommunikation på tværs af netværket med andre peer-computere, i hvilket tilfælde TDI-transporten tilføjer protokolspecifikke headere (TCP, UDP, IPX) til IRP-dataene og kommunikerer med adapterdrivere gennem NDIS-funktioner (også dokumenteret i DDK) . Generelt transporterer TDI forbindelsesapplikationer på tværs af et netværk ved at udføre operationer såsom meddelelsessegmentering, meddelelsesgendannelse, bestilling, bekræftelse og retransmission;

4) NDIS-bibliotek (Ndis.sys). Indkapsler funktionalitet til adapterdrivere og skjuler detaljer for dem Windows miljø 2000 kører i kernetilstand. NDIS-biblioteket eksporterer funktioner til TDI-transporter, såvel som støttefunktioner til adapterdrivere;

5) miniport – NDIS-drivere. Kernel mode drivere, ansvarlige for at organisere grænseflader mellem TDI transporter og specifikke netværksadaptere. NDIS miniport-drivere er skrevet til at blive pakket ind i Windows 2000 NDIS-biblioteket. Denne indkapsling giver kompatibilitet på tværs af platforme med forbrugerversioner af Windows. NDIS miniport-drivere håndterer ikke proces IRP; og registrer en grænseflade til NDIS-biblioteksopkaldstabellen, som indeholder pointere til funktioner, der svarer til de funktioner, der eksporteres af NDIS-biblioteket til TDI-transporter. NDIS miniport-drivere interagerer med netværksadaptere ved hjælp af NDIS-biblioteksfunktioner, der kalder de tilsvarende (HAL) funktioner.

Bemærk: I/O-manageren definerer modellen for levering af I/O-anmodninger til enhedsdrivere. De fleste I/O-anmodninger er repræsenteret af I/O-anmodningspakker (IRP'er), der sendes fra en I/O-delsystemkomponent til en anden. En IRP er en datastruktur, der indeholder information, der fuldstændigt beskriver en I/O-anmodning.

Faktisk omtales de nederste fire netværkslag ofte som transport, og komponenterne placeret i de øverste tre lag omtales ofte som transportbrugere.

DIV_ADBLOCK317">

SMB-protokollen er en applikationslagsprotokol, der inkluderer et netværkslag og et præsentationslag.

SMB implementerer:

1) etablering af en session;

2) filservice;

3) trykkeritjeneste;

4) beskedtjeneste.

CIFS er en åben Microsoft-standard (dokumenteret i Platform SDK), der tillader andre platforme at interoperere med Windows 2000 filserver og Windows 2000 fil klient. For eksempel tillader Samba UNIX-systemer at fungere som en filserver for en Windows 2000-klient og UNIX-applikationer til at få adgang til filer, der er gemt på systemer, der kører Windows 2000-systemer. Andre platforme, der understøtter CIFS, omfatter DEC VMS og Apple Macintosh.

Fildeling i Windows 2000 er afhængig af en omdirigering (forkortet omdirigering FSD), som kører på klientmaskine og interagerer med serverens FSD-omdirigering. FSD opsnapper Win32-fil I/O-anmodninger rettet til filer placeret på serveren og sender CIFS-meddelelser til serverens filsystem. Serveren modtager CIFS-meddelelser og konverterer dem tilbage til I/O-anmodninger, som den udsteder til lokale FSD'er såsom NTFS.

Fordi de er integreret med Windows 2000 input/output-undersystemet (I/O-system), har redirector- og server-FSD'er adskillige fordele i forhold til alternative filserverimplementeringer:

1) de kan interagere direkte med TDI-transporter og lokale FSD'er;

2) de integreres problemfrit med cache-manageren, som gør det muligt at cache data fra filserveren på klientsystemer.

Programmer kan bruge standard Win32 fil I/O-funktioner såsom CreateFile, ReadFile og WriteFile til at få adgang til fjernfiler.

I Windows 2000 bruger omdirigeringsserveren FSD standardnavnekonventionerne for netværksressourcer, der bruges af alle filservere og klientprogrammer i kernetilstand. Hvis der oprettes forbindelse til en netværksressource med drevbogstav, er navnene på netværksfiler også angivet som lokale. Redirector understøtter dog også UNC-navne

Både server-FSD og omdirigering har Win32-tjenester, server og arbejdsstation, der kører i SCM-processen (Service Control Manager) og leverer administrative kontrolgrænseflader til drivere.

Bemærk:

Du kan implementere en serverapplikation som et simpelt eksekverbart program, men du kan bruge en speciel type - en tjeneste. En tjeneste er en applikation, der indeholder yderligere infrastruktur, der gør det muligt for SCM at administrere disse applikationer. Alle serverapplikationer, der leveres med systemet, kører som tjenester.

Transport Driver Interface (TDI)

Den åbne arkitektur i Windows NT-netværk gør det muligt for dets arbejdsstationer (og servere) at fungere på heterogene netværk, ikke kun ved at give mulighed for dynamisk at indlæse og aflæse netværksværktøjer, men også ved direkte at skifte fra softwarebaserede netværksværktøjer, der er designet til at interagere med én type netværk til software-baserede. betyder for andre typer netværk under systemdrift. Windows NT understøtter softwareskift på tre niveauer:

1) på redirector-niveau - hver redirector er designet til sin egen protokol (SMP, NCP, NFS, VINES);

2) på niveauet for transportprotokoldrivere, der giver en standard TDI-grænseflade til dem og for omdirigerere;

3) på førerniveau netværksadaptere- med en standard NDIS 3.0 interface.

For at få adgang til andre typer netværk i Windows NT, udover det indbyggede, kan der indlæses yderligere omdirigerere. Specielle Windows NT-komponenter bestemmer, hvilken redirector der skal kaldes til at betjene en ekstern I/O-anmodning. I løbet af de sidste årtier er forskellige protokoller til transmission af information over netværket blevet udbredt. Selvom Windows NT ikke understøtter alle disse protokoller, giver det dig i det mindste mulighed for at aktivere understøttelse af dem.

Når en netværksanmodning når omdirigeren, skal den videresendes til netværket. I et traditionelt system er hver redirector tæt koblet til en specifik transportprotokol. Windows NT har til opgave at udføre fleksibel tilslutning af en eller anden transportprotokol, afhængig af hvilken type transport der bruges i et andet netværk. For at gøre dette skal bundniveauet i alle omdirigerere skrives i overensstemmelse med visse aftaler, som bestemmer en enkelt software interface, hedder transport driver interface(TDI).

TDI gør det muligt for omdirigerere at forblive transportuafhængige. En version af omdirigeringen kan således bruge enhver transportmekanisme. TDI giver et sæt funktioner, som omdirigerere kan bruge til at videresende enhver type data ved hjælp af transportlaget. TDI understøtter både forbindelsesorienteret kommunikation (virtuel kommunikation) og forbindelsesløs kommunikation (datagramkommunikation). Selvom LAN Manager bruger forbindelsesorienteret kommunikation, er Novell IPX et eksempel på et netværk, der bruger forbindelsesfri kommunikation. Microsoft leverer indbygget transporterne - NetBEUI (NetBIOS Extended User Interface), TCP/IP, IPX/SPX, DECnet og AppleTalk.

På baggrund af ovenstående præsenterer vi følgende konklusioner.

OG transport driver interface(TDI) er en fælles grænseflade, der gør det muligt for komponenter som redirectoren og serveren at kommunikere med forskellige netværkstransporter, dvs. forblive transportuafhængige. Noter det (TDI) er ikke en driver, men en standard for at sende beskeder mellem lag netværksarkitektur. Microsoft definerede TDI-standarden, så netværksprotokoldrivere ikke skal bruge separate grænseflader for hver transportprotokol, de har brug for.

Som allerede nævnt, Transport Driver Interface(TDI) repræsenterer i det væsentlige reglerne for dannelse af netværksanmodninger i IRP'en samt tildeling netværksadresser og kommunikationsforbindelser. Transportprotokoller, der mødes denne standard, eksportere TDI-grænsefladen til deres klienter, som inkluderer netværks-API-drivere og en omdirigering. Transportprotokollen implementeret som en enhedsdriver kaldes TDI-transporter, og da de er drivere, konverterer de anmodninger modtaget fra klienter til IRP'er. Transport Driver Interface(TDI-formularstøttefunktioner fra biblioteket \winnt\system32\drivers\tdi.sys.

BibliotekNDIS (Ndis. sys)

Lad os også introducere begrebet et grænselag. En grænse er en samlet grænseflade mellem funktionelle lag i en netværksarkitekturmodel. At skabe grænser som partitioner mellem netværkslag gør det lettere for tredjeparter at udvikle netværksdrivere og tjenester i et åbent systemmiljø.

Netværksadaptere kommer med netværksdrivere, som tidligere ofte var designet til at kommunikere med en bestemt type transportprotokol. Da Windows NT giver dig mulighed for at indlæse drivere til forskellige transportprotokoller, var netværksadapterproducenter, der brugte denne tilgang, nødt til at skrive forskellige versioner af den samme driver for at kommunikere med forskellige transportlagsprotokoller.

For at hjælpe producenter med at undgå dette, tilbyder Windows NT en grænseflade og et softwaremiljø kaldet " netværksdrivergrænsefladespecifikation" (NDIS), som beskytter netværksdrivere fra detaljer om forskellige transportprotokoller. De fleste højeste niveau Netværksadapterdriveren skal skrives i overensstemmelse med NDIS anbefalinger. I dette tilfælde kan brugeren arbejde med et TCP/IP-netværk og et NetBEUI-netværk (eller DECnet, NetWare, VINES osv.) ved hjælp af en netværksadapter og en netværksdriver. NDIS-miljøet blev brugt i LAN Manager-netværk, men er blevet opdateret til Windows NT.

Gennem sin nedre grænse kommunikerer en netværksadapterdriver typisk direkte med den eller de adaptere, den servicerer. Netværksadapterdriveren implementeret til NDIS-miljøet styrer ikke direkte adapteren, men bruger funktioner leveret af NDIS til at gøre det (f.eks. til at udløse I/O eller håndtere afbrydelser). NDIS-miljøet danner således en slags skal, der gør det ret nemt at overføre netværksadapterdrivere fra et OS til et andet. NDIS tillader netværksdrivere ikke indeholder indbygget viden om den processor eller det operativsystem, det kører på.

Netværkssikkerhed og domænestruktur

Netværkssikkerhed betyder beskyttelse af alle hardwarekomponenter, software og lagrede data mod ødelæggelse, tyveri og uautoriseret brug. Gennemtænkt og dygtigt opbygget støtteplan computersikkerhed, at sørge for god overvågning, gør det nemmere at kontrollere brugen af ​​netværkscomputere, eliminerer praktisk talt utilsigtet ødelæggelse eller beskadigelse af data og gør det umuligt eller ekstremt vanskeligt uautoriseret brug ressourcer.

Microsoft inkluderede sikkerhedskrav som en del af den indledende specifikation for Windows udvikling N.T. Sikkerhedsproblemer i Windows NT er af afgørende betydning. Sikkerhedsmodellen inkluderer komponenter til at kontrollere adgangen til objekter (såsom filer og delte printere). Disse komponenter definerer, hvem der kan få adgang til hvilke objekter, hvilken handling der kan udføres på objektet (f.eks. skrivning til en fil osv.), og hvilke hændelser der kan kontrolleres.

Sikkerhed Windows netværk NT inkluderer også tillidsforhold mellem domæner, hvilket gør dette operativsystem til det bedst beskyttede.

Sikkerhedsmodelarkitektur

I fig. Figur 3 viser komponenterne i Windows NT-sikkerhedsmodellen, som omfatter:

1) Logon-processer, som modtager login-anmodninger fra brugere. Disse inkluderer interaktivt login, som udføres ved hjælp af den indledende login-dialog, og fjerntliggende processer logins, som giver fjernbrugere adgang til Windows NT-serverprocesser;

2) lokal sikkerhedstjeneste (Local Security Authority, LSA), som sikrer, at brugeren har ret til at få adgang til systemet. Denne komponent er centrum for Windows NT-sikkerhedsundersystemet. Det genererer adgangstokens, administrerer lokalpolitik sikkerhed og giver interaktiv brugergodkendelse. Derudover kontrollerer LSA revisionspolitikken og logger revisionsposter genereret af sikkerhedsmonitoren;

3) Security Account Manager (SAM), som vedligeholder en brugerkontodatabase, også kendt som en mappedatabase. Denne database indeholder oplysninger for alle bruger- og gruppekonti. SAM leverer brugerverifikationstjenesten, der bruges af LSA;

4) Security Reference Monitor, som kontrollerer, om brugeren har adgangstilladelse til objektet og retten til den handling, han forsøger at udføre. Denne komponent håndhæver kontrol af adgangsniveauer og håndhæver revisionspolitikken defineret af LSA. Det giver en kernetilstand og en brugertilstandstjeneste, der kontrollerer, at alle brugere og processer, der forsøger at få adgang til et objekt, har det nødvendige adgangsniveau. Om nødvendigt genererer denne komponent også poster i revisionsfilen.

Samlet er alle disse komponenter også kendt som sikkerhedsundersystemet. Dette undersystem, kaldet det integrerede undersystem, er ikke et miljøundersystem, fordi det spænder over hele Windows NT-operativsystemet.

Netværkstjenester

Foredrag 10

Sættet af server- og klientdele af operativsystemet, der giver adgang til en bestemt type computerressource via et netværk, kaldes netværkstjeneste. Klientdelen laver netværksanmodninger til serverdelen af ​​en anden computer. Serverdelen opfylder anmodninger til lokale serverressourcer. Klientdelen er aktiv, serverdelen er passiv.

I netværkskommunikation spiller netværksadgang til filsystemet en væsentlig rolle. I dette tilfælde dannes klient- og serverdelene sammen med netværksfilsystemet filtjeneste

En nøglekomponent i et distribueret OS er netværksfilsystemet. Et netværksfilsystem understøttes af en eller flere computere, der gemmer filer (filservere)

Klient computere vedhæfter eller monterer disse filsystemer til deres lokale filsystemer

Filtjeneste omfatter serverprogrammer og klientprogrammer, der interagerer over netværket ved hjælp af en protokol.

Filtjenester inkluderer selve filtjenesten (filoperationer) og bibliotekstjenesten (katalogstyring)

Netværksfiltjenestemodellen inkluderer følgende elementer:

Lokalt filsystem (FAT, NTFS)

Lokalt filsystemgrænseflade (systemopkald)

Netværksfilsystemserver

Netværksfilsystemklient ( Windows Stifinder, UNIX-skal osv.)

Netværksfilsystemgrænseflade (gentager lokale filsystemkald)

Network File System Client-Server Protocol (SMB-Server Message Block til Windows, NFS (Network File System) og FTP (File Transfer Protocol) til UNIX)

Netværksfilsystemgrænseflade

Der er flere typer grænseflader, som er kendetegnet ved:

Filstruktur. De fleste netværksfilsystemer understøtter flade filer

Filændringsmuligheder. De fleste netværksfilsystemer har mulighed for at ændre en fil. Nogle distribuerede filsystemer forbyder ændringsoperationer. Kun oprette og læse er muligt. For sådanne filer er det lettere at organisere caching og replikering.

Filadskillelse semantik:

Semantik UNIX (centraliseret). Hvis en læsning følger flere skrivninger, læses den seneste opdatering. Dette princip er også muligt i et distribueret filsystem, forudsat at der er én filserver, og der ikke er nogen filcache på klienten.

Session semantik.Ændringer begynder, efter at filen er åbnet, og fuldføres, når filen er lukket. Med andre ord, for andre processer er ændringer kun synlige, efter at filen er lukket. I I dette tilfælde Der er et problem med at dele en fil. Semantik af uforanderlige filer. Filen kan kun oprettes og læses. Du kan også genskabe filen under et andet navn. Derfor kan filen ikke ændres, men kan erstattes med en ny fil. Der er intet delingsproblem.

Transaktionsmekanisme. Dette er en måde at arbejde med delte filer på ved hjælp af en transaktionsmekanisme (udelelige operationer)

Adgangskontrol. For eksempel er der for Windows NT/2000 to mekanismer: på biblioteksniveau (for FAT) og på filniveau (NTFS)

Adgangsenhed. Fuld fil upload/download model (FTP). Den anden model er brugen af ​​filoperationer.

Alle ved, at på UNIX-systemer er et filsystem logisk set en samling af fysiske filsystemer, der er forbundet til et enkelt punkt. En af de vigtigste fordele ved en sådan organisation er efter min mening evnen til dynamisk at ændre strukturen af ​​et eksisterende filsystem. Også takket være udviklernes indsats har vi i dag mulighed for at forbinde FS af næsten enhver type og enhver på en bekvem måde. Ved "metode" vil jeg først og fremmest understrege OS-kernens evne til at arbejde med filsystemer via netværksforbindelser.

Mange netværksprotokoller giver os mulighed for at arbejde med fjernfiler, det være sig FTP, SMB, Telnet eller SSH. Takket være kernens evne til i sidste ende ikke at afhænge af typen af ​​filsystem, der er tilsluttet, har vi mulighed for at forbinde hvad som helst, og hvordan vi vil bruge mount-programmet.

I dag vil jeg gerne tale om NFS - Network File System. Denne teknologi giver dig mulighed for at forbinde individuelle FS-punkter til fjerncomputer til filsystemet på den lokale computer. Selve NFS-protokollen giver dig mulighed for at udføre filoperationer ret hurtigt, sikkert og pålideligt. Hvad har vi ellers brug for? :-)

Hvad skal der til for at dette kan virke

For ikke at tude i lang tid om emnet NFS-versioner og deres understøttelse i forskellige kerner, vil vi straks antage, at din kerneversion ikke er lavere end 2.2.18. I den officielle dokumentation lover udviklerne fuld understøttelse af NFS version 3-funktionalitet i denne kerne og senere versioner.

Installation

For at køre NFS-serveren i min Ubuntu 7.10 - Gutsy Gibbon, var jeg nødt til at installere nfs-common og nfs-kernel-server-pakkerne. Hvis du kun har brug for en NFS-klient, skal nfs-kernel-server ikke installeres.

Server Tuning

Efter at alle pakker er blevet installeret, skal du kontrollere, om NFS-dæmonen kører:

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

Hvis dæmonen ikke kører, skal du starte den med kommandoen

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

Når alt er startet med succes, kan du begynde at eksportere filsystemet. Selve processen er meget enkel og tager minimal tid.

NFS-serverens hovedkonfigurationsfil er placeret i /etc/exports og har følgende format:

Katalogmaskine1(option11,option12) maskine2(option21,option22)

vejviser— absolut sti til FS-serverbiblioteket, som du skal give adgang til

maskineX— DNS-navn eller IP-adresse på den klientcomputer, hvorfra adgang er tilladt

optionXX— FS eksportparametre, de mest almindeligt anvendte af dem:

• ro- filadgang er skrivebeskyttet
• rw— læse/skriveadgang er givet
• no_root_squash— som standard, hvis du opretter forbindelse til en NFS-ressource som root, vil serveren for sikkerhedens skyld på sin side få adgang til filer som ingen-brugeren. Men hvis du aktiverer denne mulighed, vil filer på serversiden blive tilgået som root. Vær forsigtig med denne mulighed.
• no_subtree_check— som standard, hvis du ikke eksporterer hele partitionen på serveren, men kun en del af filsystemet, vil dæmonen kontrollere, om den anmodede fil fysisk er placeret på den samme partition eller ej. Hvis du eksporterer hele partitionen eller monteringspunktet for det eksporterede filsystem ikke påvirker filer fra andre fysiske volumener, så kan du aktivere denne mulighed. Dette vil give dig en stigning i serverhastigheden.
• synkronisere— aktiver denne mulighed, hvis der er mulighed for et pludseligt forbindelsestab eller serverstrømafbrydelse. Hvis denne mulighed ikke er aktiveret, er der en meget høj risiko for datatab, hvis NFS-serveren pludselig stopper.

Så lad os sige, at vi skal give adgang til ashep-desktop-computeren til mappen /var/backups på ashep-laptop-computeren. Directory-adgang er påkrævet for at kopiere backup-filer fra ashep-desktop. Min fil blev sådan her:

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

Efter at have tilføjet linjen til /etc/exports, skal du genstarte NFS-serveren for at ændringerne træder i kraft.

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

Det er alt. Du kan begynde at forbinde den eksporterede FS på klientcomputeren.

Klient opsætning

På klientsiden Fjernfilsystemet monteres på samme måde som alle andre - med mount kommandoen. Desuden er der ingen, der forbyder dig at bruge /etc/fstab, hvis du skal forbinde FS automatisk, når OS starter. Så monteringsmuligheden vil se sådan ud:

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

Hvis alt gik godt, og du skal oprette forbindelse til den eksterne FS automatisk ved opstart, skal du blot tilføje linjen til /etc/fstab:

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

Hvad ellers

Så vi har et praktisk, lillebitte overblik over mulighederne i NFS. Dette er selvfølgelig kun en lille del af, hvad NFS kan. Dette er nok til brug derhjemme eller inde lille kontor. Hvis dette ikke er nok for dig, anbefaler jeg at læse først

Konstantin Pyanzin

Hovedtræk ved NFS-filsystemet på UNIX-platformen.

Lykke er, når vores ønsker falder sammen med andre menneskers evner.

"Vremechko"

Netværksfilsystemer har spillet, spiller og vil fortsat spille en vigtig rolle i informationsinfrastrukturen. På trods af applikationsservernes voksende popularitet forbliver filtjenesten et universelt middel til at organisere kollektiv adgang til information. Desuden fungerer mange applikationsservere også som filservere.

I øjeblikket operationsstue UNIX system oplever noget af en renæssance, og det skylder meget af denne stigning i interesse til det frit tilgængelige Linux-operativsystem. Samtidig bruges forskellige versioner af Windows på stationære computere, primært Windows 9x og Windows NT/2000, selvom frit distribuerede varianter af UNIX efterhånden får statsborgerskab her.

For mange organisationer er hosting af en netværksfiltjeneste på UNIX-computere en meget attraktiv løsning, forudsat at tjenesten har tilstrækkelig ydeevne og pålidelighed. I betragtning af de mange forskelle i UNIX- og Windows-filsystemer, primært i filnavneskemaer, adgangsrettigheder, låsning og systemkald ved adgang til filer, er det af særlig vigtighed at sikre adgangsgennemsigtighed i det heterogene UNIX/Windows-miljø. Derudover installeres UNIX-filservere ofte som en tilføjelse til eksisterende Windows NT- og NetWare-servere.

Til UNIX-operativsystemet er der implementeringer af alle mere eller mindre populære netværksfilsystemer, inklusive dem, der bruges i Microsoft (SMB), NetWare (NCP), Macintosh (AFP) netværk. Selvfølgelig har UNIX-netværk deres egne protokoller, især NFS og DFS. Husk, at enhver UNIX-server samtidigt kan levere NFS- og SMB-tjenester (såvel som NCP og AFP) og dermed give yderligere fleksibilitet, når der oprettes en netværksinfrastruktur.

På trods af mangfoldigheden af ​​UNIX-netværksfilsystemer er de ubestridte ledere NFS (Network File System, bogstavelig oversættelse - netværksfilsystem) og SMB (Service Message Block). Denne artikel vil diskutere mulighederne i NFS. Samtidig planlægger vi i et af de kommende udgaver at overveje karakteristikaene for SMB på UNIX-platformen og først og fremmest Samba-produktet, som har vist sig godt i UNIX/Windows-netværk.

NFS VERSIONER

Den første implementering af NFS-netværksfilsystemet blev udviklet af Sun Microsystems tilbage i 1985. Siden da er NFS blevet udbredt i UNIX-verdenen, med installationer på titusinder. Ud over UNIX har NFS-systemet som serverplatform fundet anvendelse i VMS-, MVS- og endda Windows-operativsystemerne.

NFS er det oprindelige filsystem for UNIX og følger logikken i UNIX-filoperationer som ingen anden. Dette gælder filnavneområde og tilladelser. Desuden er NFS-understøttelse indbygget i kernen af ​​alle populære versioner af UNIX-lignende operativsystemer.

I øjeblikket er NFS repræsenteret af den anden og tredje version (den første version af NFS er aldrig dukket op på markedet). På trods af en række begrænsninger er NFS v2 meget populær; det er en del af det frit distribuerede UNIX (især Linux), såvel som noget kommercielt UNIX.

Den tredje version af NFS blev udviklet i midten af ​​90'erne af fælles indsats fra Sun, IBM, Digital og andre virksomheder for at forbedre ydeevnen, sikkerheden og lette administrationen af ​​netværksfilsystemet. NFS v3 er bagudkompatibel med den tidligere NFS-specifikation, hvilket betyder, at en NFS v3-server ikke kun kan betjene NFS v3-klienter, men også NFS v2-klienter.

På trods af sin ret lange tilstedeværelse på markedet er NFS v3 stadig ringere end NFS v2 med hensyn til antallet af installationer. Ud fra disse overvejelser vil vi først fokusere på hovedkarakteristikaene ved NFS v2, og derefter stifte bekendtskab med innovationerne i den tredje version af NFS.

Husk, at specifikke implementeringer af den samme version af NFS kan afvige en smule fra hinanden. Forskellene vedrører primært sammensætningen af ​​dæmoner, deres navne, placering og titel konfigurationsfiler NFS. Derudover afhænger NFS-implementeringer af egenskaberne og funktionerne i selve UNIX. For eksempel understøtter NFS v2 ACL'er, men kun på varianter af UNIX, der har en sådan understøttelse indbygget i kernen. Derfor vil vi, når vi beskriver NFS, overveje det mest generelle tilfælde.

NFS V2 PROTOKOLLER

Figur 1 viser NFS v2-netværksmodellen i henhold til OSI-referencemodellen. I modsætning til de fleste TCP/IP-netværkstjenester bruger NFS eksplicit præsentations- og sessionsprotokoller. NFS arbejder baseret på konceptet med fjernprocedurekald (RPC). Ifølge dette koncept, når man tilgår fjernressource(for eksempel til en fil), udfører et program på den lokale computer et normalt systemkald (lad os sige et opkald til filåbningsfunktionen), men faktisk udføres proceduren eksternt - på ressourceserveren. I dette tilfælde er brugerprocessen ikke i stand til at bestemme, om opkaldet foretages lokalt eller eksternt. Efter at have fastslået, at processen tilgår en ressource på en fjerncomputer, der fungerer som en server, pakker kernen eller en speciel dæmon i systemet procedurens argumenter sammen med dens identifikator i en netværkspakke, åbner en kommunikationssession med serveren og sender denne pakke til den. Serveren pakker den modtagne pakke ud, bestemmer den anmodede procedure og argumenter og udfører derefter proceduren. Derefter sender serveren procedurereturkoden til klienten, som sender den videre til brugerprocessen. Således overholder RPC fuldt ud sessionslaget i OSI-modellen.

Et retfærdigt spørgsmål opstår: hvorfor har NFS-netværksmodellen brug for en særlig protokol på præsentationsniveau? Pointen er, at Sun klogt stolede på brugen af ​​NFS i heterogene netværk, hvor computere har forskellige systemarkitekturer, herunder forskellig byte-rækkefølge i et maskinord, forskellige flydende komma-repræsentationer, inkompatible strukturjusteringsgrænser osv. Fordi Siden RPC-protokollen involverer afsendelse procedureargumenter, dvs. strukturerede data, er tilstedeværelsen af ​​en protokol på præsentationsniveau et presserende behov i et heterogent miljø. Dette er den eksterne datarepræsentationsprotokol (eXternal Data Representation, XDR). Den beskriver den såkaldte kanoniske form for datarepræsentation, som ikke afhænger af processorens systemarkitektur. Når der sendes RPC-pakker, oversætter klienten lokale data til kanonisk form, og serveren udfører den modsatte handling. Det skal man huske på kanonisk form XDR svarer til den anvendte datarepræsentation for SPARC- og Motorola-processorfamilien. På servere, der implementerer en lignende form for datapræsentation, giver dette mulighed for at opnå en vis (dog højst sandsynligt mikroskopisk) ydeevnefordel i forhold til konkurrenter i tilfælde af intensiv adgang til filserveren.

I NFS v2 blev UDP valgt som transportprotokol. Udviklerne forklarer dette med, at RPC-sessionen varer en kort periode. Derudover er hver RPC-pakke selvstændig, det vil sige, at hver pakke bærer fuldstændig information om, hvad der skal udføres på serveren, eller om resultaterne af proceduren. RPC-tjenester er typisk forbindelsesløse, hvilket betyder, at serveren ikke gemmer information om, hvilke klientanmodninger der tidligere er blevet behandlet, såsom hvor i en fil klienten sidst læste data. For et netværksfilsystem er dette en klar fordel med hensyn til pålidelighed, da klienten kan fortsætte filoperationer umiddelbart efter, at serveren er genstartet. Men denne ordning er fyldt med problemer, når du skriver og låser filer, og for at komme uden om dem, blev NFS-udviklere tvunget til at bruge forskellige løsninger (brug af UDP giver anledning til et andet sæt specifikke problemer, men vi vil komme ind på dem senere).

En vigtig forskel mellem RPC-tjenesterne inkluderet i NFS og andre netværksservertjenester er, at de ikke bruger inetd superdæmonen. Almindelige netværkstjenester, såsom telnet eller rlogin, lanceres normalt ikke som dæmoner ved systemstart, selvom dette ikke er forbudt. Oftest bruger de den såkaldte superdæmon inetd, som "lytter" på softwareporte TCP protokoller og UDP. Tjenester er specificeret i superdaemonens konfigurationsfil (normalt /etc/inetd.conf). Når en anmodning modtages på en softwareport fra en klient, starter inetd den tilsvarende proces som en underordnet proces. netværkstjeneste(for eksempel in.rlogind), som behandler anmodningen.

RPC-tjenester bruger ikke inetd-superdæmonen, fordi, som nævnt, en RPC-session kun varer i meget kort tid, faktisk kun i varigheden af ​​en enkelt anmodning. Det vil sige, at for hver anmodning ville inetd være tvunget til at starte en ny underordnet proces af RPC-tjenesten, hvilket er meget dyrt for UNIX. Af lignende årsager kan en RPC-proces ikke skabe nye processer og kan ikke betjene flere anmodninger parallelt. Derfor, for at forbedre ydeevnen, køres RPC-tjenester som flere dæmonforekomster, der kører samtidigt. Imidlertid er antallet af forekomster af en bestemt dæmon ikke direkte relateret til antallet af klienter. Selv en dæmon kan betjene mange klienter, men ad gangen er den i stand til at behandle en enkelt anmodning, resten vil blive placeret i en kø.

En anden vigtig forskel mellem RPC-tjenester og almindelige netværkstjenester er, at de ikke bruger foruddefinerede UDP-softwareporte. I stedet anvendes et såkaldt port mapping-system. For at understøtte det, initialiseres en speciel portmap-dæmon, når systemet starter. Som en del af portoversættelsessystemet er hver RPC-tjeneste tildelt et programnummer, versionsnummer, procedurenummer og protokol (UDP eller TCP). Programnummeret identificerer entydigt en specifik RPC-tjeneste. Forholdet mellem RPC-tjenestenavne og programnumre kan spores baseret på indholdet af filen /etc/rpc. Hvert RPC-program understøtter mange procedurer, som er identificeret ved deres procedurenumre. Procedurenumrene kan findes i de tilsvarende header-filer: for NFS-tjenesten er de for eksempel angivet i filen /usr/include/nfs/nfs.h.

Især NFS-tjenesten har programnummer 100003 og inkluderer procedurer som "åben fil", "læs blok", "opret fil" osv. Når man kalder fjernprocedurer, sendes serviceprogramnummeret sammen med procedureargumenterne i RPC-pakke, procedurenummer og versionsnummer. Versionsnummeret bruges til at identificere tjenestens muligheder. Faktum er, at udviklere konstant forbedrer NFS-tjenesten, og hver ny version er fuldstændig bagudkompatibel med tidligere.

Funktionsprincippet for portmap-oversætteren er ret simpelt. Når en RPC-tjeneste initialiseres (især på det tidspunkt, hvor OS starter), registreres den ved hjælp af portmap-dæmonen. Når den startes på en server, leder RPC-tjenesten efter en ledig softwareport, reserverer den til sig selv og rapporterer portnummeret til portmap-dæmonen. For at kunne kommunikere med serveren skal RPC-klienten først kontakte serverens portmap og spørge, hvilken softwareport der er optaget af en bestemt RPC-tjeneste på serveren. Først derefter kan kunden kontakte tjenesten direkte. I nogle tilfælde kommunikerer klienten indirekte med den ønskede tjeneste, det vil sige, at den først kontakter portmap-dæmonen, som anmoder om RPC-tjenesten på vegne af klienten. I modsætning til RPC-tjenester er portmap-portoversætteren altid bundet til en foruddefineret port 111, således at klienten kommunikerer med portmap på standardmåden.

SAMMENSÆTNING AF NFS V2

Generelt inkluderer NFS-serveren ud over portmap dæmonerne rpc.mountd, nfsd, rpc.lockd, rpc.statd. En NFS-klientmaskine, der kører på en UNIX-platform, skal have biod (valgfrit), rpc.lockd og rpc.statd-dæmonerne kørende.

Som tidligere nævnt understøtter UNIX NFS på kerneniveau, så ikke alle dæmoner er nødvendige, men de kan forbedre ydeevnen af ​​filoperationer væsentligt og tillade filskrivelåsning.

rpc.mountd-dæmonen håndterer klientanmodninger om at montere filsystemer. Mount-tjenesten er implementeret som en separat dæmon, da monteringsprotokollen ikke er en del af NFS. Dette skyldes, at monteringsoperationen er tæt knyttet til filnavnesyntaks, og filnavngivningsprincipper er forskellige mellem UNIX og f.eks. VMS.

nfsd-dæmonen accepterer og servicerer NFS RPC-anmodninger. For at forbedre ydeevnen køres der typisk flere forekomster af nfsd på serveren.

rpc.lockd-dæmonen, der kører på både klienten og serveren, er designet til at låse filer, mens rpc.statd-dæmonen (kører også på serveren og klienten) fører statistik over låse i tilfælde af, at de automatisk skal gendannes, hvis NFS-tjenesten går ned.

Biod-dæmonen, der kører på klienten, er i stand til at læse-forud og lazy-write-operationer, hvilket i høj grad forbedrer ydeevnen. Tilstedeværelsen af ​​biod er dog ikke påkrævet for at klienten kan arbejde. For yderligere at forbedre ydeevnen kan flere biod-dæmoner indlæses på klientmaskinen.

En anden dæmon, der kører på serveren, er ansvarlig for godkendelses- og udskrivningstjenester for DOS/Windows-klienter; på nogle systemer hedder den pcnfsd, på andre in.pcnfsd.

Derudover inkluderer NFS-pakken forskellige systemværktøjer og diagnostiske programmer (showmount, rpcinfo, exportfs, nfsstat).

EKSPORTREGLER

De filsystemer og mapper, som klienter kan fjernmontere på NFS-serveren, skal udtrykkeligt angives. Denne procedure kaldes "eksport" af ressourcer i NFS. Samtidig udsender en NFS-server, i modsætning til f.eks. en SMB-server, ikke en liste over sine eksporterede ressourcer. Klienten kan dog anmode om en sådan liste fra serveren. På serversiden er rpc.mountd-dæmonen ansvarlig for at servicere mount-anmodninger.

Eksport af NFS-filressourcer følger fire grundlæggende regler.

1. Filsystemet kan eksporteres enten som en helhed eller i dele, såsom mapper og filer. Det skal huskes, at den største eksporterede enhed er filsystemet. Hvis et bestemt filsystem (/usr/bin) er monteret på serveren i hierarkiet under et andet filsystem (/usr), vil eksport af /usr-systemet ikke påvirke /usr/bin-systemet.
2. Kun lokale filressourcer kan eksporteres, med andre ord, hvis en andens filsystem er monteret på serveren, det vil sige placeret på en anden server, så kan det ikke re-eksporteres.
3. Du kan ikke eksportere undermapper til et allerede eksporteret filsystem, medmindre de er separate filsystemer.
4. Du kan ikke eksportere de overordnede mapper til en mappe, der allerede er blevet eksporteret, medmindre den overordnede mappe er et uafhængigt filsystem.

Enhver overtrædelse af disse regler vil resultere i en fejl i NFS-driften.

Tabellen over eksporterede ressourcer er placeret i filen /etc/exports. Syntaksen for denne fil er desværre UNIX-specifik, så vi bruger Solaris som eksempel. Filen /etc/exports består af tekstlinjer i formatet:

-,...

Nogle af de mest populære muligheder er angivet i tabel 1. Faktisk beskriver mulighederne de adgangsrettigheder, som klienter har til de eksporterede ressourcer. Det er vigtigt at huske, at de tilladelser, der er angivet under eksport, på ingen måde tilsidesætter de tilladelser, der gælder direkte for filsystemet. For eksempel, hvis filsystemet eksporteres skrivbart, og en bestemt fil har en skrivebeskyttet attribut, så vil det ikke være muligt at ændre det. Ved eksport fungerer adgangsrettigheder således som et ekstra filter. Ydermere, hvis f.eks. et filsystem eksporteres med muligheden ro (skrivebeskyttet), så har klienten ret til at montere det med muligheden rw (læse/skrive), men forsøg på at skrive vil resultere i en fejlmeddelelse.

Adgangsindstillingen giver dig mulighed for at angive værter med ret til at montere en ressource. Derfor har ingen anden vært, bortset fra dem, der er nævnt i den, evnen til at montere og derfor udføre operationer på ressourcen.

Listen over værter, der kan skrive information, er angivet ved hjælp af rw-indstillingen. Hvis indstillingen rw ikke angiver en liste over værter, har enhver vært ret til at skrive.

Rodindstillingen giver dig mulighed for at angive værter, hvor lokale root-superbrugere får serverrodrettigheder til den eksporterede ressource. Ellers, selvom værten tildeles rw-rettigheder, svarer root-brugeren på den til user nobody (uid=-2), dvs. en bruger med minimale adgangsrettigheder. Ovenstående gælder specifikt for adgangsrettigheder til en fjernressource og påvirker ikke adgangsrettigheder til lokale klientressourcer.

De anonyme og sikre muligheder vil blive diskuteret, når NFS-godkendelsesskemaet beskrives.

INSTALLATIONSREGLER

Hvis de eksporterede ressourcer for serveren kan fungere som et filsystem eller en separat mappe, så ligner de for klienten altid filsystemer. Da NFS-understøttelse er indbygget i UNIX-kernen, udføres monteringen af ​​NFS-filsystemer standard værktøj mount (en separat dæmon til montering af NFS er ikke påkrævet), skal du kun angive, at det monterede filsystem er NFS. En anden måde at montere er at bruge filen /etc/fstab (/etc/filesystems på nogle versioner af UNIX). I dette tilfælde er eksterne NFS-systemer (såvel som lokale) monteret ved OS-startstadiet. Monteringspunkter kan være hvilke som helst, også som en del af andre NFS-filsystemer, dvs. NFS-systemer kan "spændes" oven på hinanden.

Grundlæggende NFS-monteringsmuligheder er angivet i tabel 2.

Bg-indstillingen giver dig mulighed for at montere i baggrunden, i hvilket tilfælde du kan køre andre mount-kommandoer.

Parret af hårde/bløde muligheder virker meget interessante. Med en "hård" montering vil klienten forsøge at montere filsystemet for enhver pris. Hvis serveren er nede, vil dette få hele NFS-tjenesten til at fryse: processer, der får adgang til filsystemet, vil gå i en tilstand, hvor de venter på, at RPC-anmodninger er fuldført. Fra brugerprocessernes synspunkt vil filsystemet se ud som en meget langsom lokal disk. Når serveren vender tilbage til arbejdsvilkår NFS-tjenesten vil fortsætte med at fungere, som om intet var hændt. Brug af intr-indstillingen giver dig mulighed for at afbryde den hårde monteringsproces ved hjælp af INTERRUPT-systemsignalet.

Under en blød montering vil NFS-klienten gøre flere forsøg på at oprette forbindelse til serveren, som specificeret af retans- og timeo-indstillingerne (nogle systemer understøtter også en speciel genforsøgsmulighed). Hvis serveren ikke reagerer, viser systemet en fejlmeddelelse og stopper forsøget på at montere. Ud fra et synspunkt om logikken i filoperationer, når serveren fejler, emulerer et "blødt" mount en lokal diskfejl. Hvis muligheden for gentransmission (genforsøg) ikke er angivet, er antallet af genforsøg begrænset til standardværdien for det givne UNIX-system. Retrans- og timeo-indstillingerne gælder ikke kun for mounts, men også for alle RPC-operationer, der udføres på NFS-filsystemet. Det vil sige, at hvis klienten udfører en skriveoperation, og der på dette tidspunkt er en fejl på netværket eller på serveren, vil klienten forsøge at gentage anmodninger.

Spørgsmålet om hvilken tilstand, "blød" eller "hård", der er bedre, kan ikke besvares entydigt. Hvis dataene på serveren skal være konsistente, når den midlertidigt fejler, er en "hård" montering at foretrække. Denne tilstand er også uundværlig i tilfælde, hvor de monterede filsystemer indeholder programmer og filer, der er afgørende for klientens drift, især for diskløse maskiner. I andre tilfælde, især når det kommer til skrivebeskyttede systemer, ser blød monteringstilstand ud til at være at foretrække.

AUTENTIFIKATION OG SIKKERHED

Som nævnt er hver RPC-pakke selvstændig. Desuden giver NFS generelt ikke statefulness, dvs. det holder ikke styr på, hvilke anmodninger klienter tidligere har lavet, og det sporer ikke klientens ydeevne. I systemer, der bruger fjernprocedurekald, viser sikkerhedsproblemet sig derfor at være yderst relevant.

I NFS udføres godkendelse udelukkende på tidspunktet for montering af filsystemet og kun baseret på domænenavnet (eller IP-adressen) på klientmaskinen. Det vil sige, at hvis en NFS-klient (her mener vi en computer, ikke en computerbruger) kontakter serveren med en monteringsanmodning, bestemmer serveren adgangsrettigheder ved hjælp af /etc/exports-tabellen, og klienten identificeres med navnet (IP) adresse) på computeren. Hvis klienten får lov til at udføre visse operationer på den eksporterede ressource, får den at vide et bestemt "magisk tal" (magisk cookie). Klienten skal derefter inkludere dette nummer i hver RPC-anmodning for at bevise sine legitimationsoplysninger.

Dette er faktisk hele det simple sæt af klientgodkendelsesværktøjer; brugere er ikke godkendt på nogen måde. Hver RPC-anmodning indeholder dog uid'et for den bruger, der startede anmodningen, og en liste over gruppe-id'er, gid, som brugeren tilhører. Men disse identifikatorer bruges ikke til godkendelse, men til at bestemme en specifik brugers adgangsrettigheder til filer og mapper.

Bemærk venligst, at uid og gid bestemmes på klientsiden, ikke serversiden. Derfor står administratorer over for problemet med at koordinere indholdet af /etc/passwd (og /etc/group) mellem klienter og NFS-servere, så brugeren Vasya på serveren ikke tildeles brugeren Petyas rettigheder. For store netværk giver dette alvorlige vanskeligheder. For at sikre ensartethed af brugerdatabasen, såvel som systemfiler såsom /etc/hosts, /etc/rpc, /etc/services, /etc/protocols, /etc/aliases osv., kan du bruge netværksinformationstjenesten System, NIS), udviklet af Sun tilbage i 1985 og inkluderet i de fleste versioner af UNIX (dens mere avancerede version NIS+ er ikke meget brugt). NIS er en informationstjeneste, der løst minder om Windows NT-katalogtjenesten, som giver dig mulighed for centralt at gemme og behandle systemfiler. I øvrigt er NIS bygget på samme princip som NFS, især bruger den RPC- og XDR-protokollerne.

En anden vigtig egenskab ved NFS er, at hver RPC-anmodning indeholder en liste over brugerens gid-grupper. For at begrænse størrelsen af ​​RFC-pakken begrænser de fleste NFS-implementeringer antallet af grupper til 8 eller 16 grupper. Hvis en bruger er medlem af flere grupper, kan dette føre til fejl ved bestemmelse af tilladelser på serveren. Dette problem er meget relevant for virksomhedsfilservere. En radikal løsning er at bruge ACL'er, men det er desværre ikke alle UNIX-varianter, der understøtter dem.

Godkendelsessystemet, der er vedtaget af NFS, er meget dårligt og giver ikke pålidelig beskyttelse. Enhver, der har beskæftiget sig med NFS, ved, hvor nemt det er at omgå dets sikkerhed. For at gøre dette er det ikke engang nødvendigt at bruge metoder til at forfalske IP-adresser (IP-spoofing) eller navne (DNS-spoofing). En angriber skal blot opsnappe det "magiske nummer", og i fremtiden kan han udføre handlinger på vegne af klienten. Derudover ændres det "magiske nummer" ikke før næste server genstart.

På adskillige internetservere kan du finde andre, herunder meget eksotiske, metoder til at hacke NFS. Antallet af opdagede "huller" er i tusindvis. Derfor anbefales NFS v.2 kun at blive brugt inden for sikre netværk.

Baseret på disse overvejelser udviklede Sun SecureRPC-protokollen ved hjælp af både asymmetriske og symmetriske krypteringsnøgler. Hvori kryptografiske metoder bruges til at godkende ikke kun værter, men også brugere. Selve dataene er dog ikke krypteret. På grund af eksportrestriktioner fra den amerikanske regering er det desværre ikke alle UNIX'er, der leveres med SecureRPC-support. Derfor vil vi ikke dvæle ved denne protokols muligheder. Men hvis din version af UNIX understøtter SecureRPC, så vil Hal Steins bog "Managing NFS and NIS" udgivet af O'Reilly & Associates give uvurderlig hjælp til at sætte den op.

Et andet problem er med NFS-klienter på MS-DOS og Windows 3.x/9x platforme. Disse systemer er enkeltbruger, og det er ikke muligt at identificere brugeren ved hjælp af normale NFS-værktøjer. Med det formål at identificere DOS/Windows-brugere, startes pcnfsd-dæmonen på serveren. Når du tilslutter (monterer) NFS-diske på klientmaskinen, beder den om brugernavn og adgangskode, som ikke kun tillader identifikation, men også godkendelse af brugere.

Selvom Windows NT er et flerbrugeroperativsystem, er dets brugerdatabase og brugeridentifikationsskema inkompatible med UNIX. Derfor er NFS-klientwebsteder baseret på Windows NT også tvunget til at bruge pcnfsd's muligheder.

Ud over brugergodkendelse tillader pcnfs udskrivning på UNIX fra DOS/Windows-klientwebsteder. Sandt nok inkluderede Windows NT oprindeligt programmet LPR.EXE, som også tillader udskrivning på UNIX-servere.

For at få adgang til filtjenesten og NFS-tjenesten på DOS/Windows-maskiner skal du installere speciel klientsoftware, og priserne for disse produkter er ret høje.

Lad os dog vende tilbage til NFS-fileksportindstillingerne (se tabel 1). Anon-indstillingen definerer brugeridentifikations-uid i det tilfælde, hvor DOS/Windows-brugeren ikke kunne godkende sig selv (indstille en forkert adgangskode), eller når brugeren af ​​værten, der var tilsluttet via SecureRPC, mislykkedes med godkendelse. Som standard har anon uid=-2.

Den sikre indstilling bruges, når SecureRPC-protokollen bruges.

ARKITEKTONISKE FUNKTIONER AF NFS V2

NFS-filsystemer skal overholde to betingelser (i øvrigt gælder de samme krav ikke kun for NFS, men også for andre netværksfilsystemer).

1. Fra en klients synspunkt brugerprogrammer NFS-filsystemet er placeret som på en lokal disk. Programmer har ingen mulighed for at skelne NFS-filer fra almindelige filer.
2. NFS-klienten er ikke i stand til at bestemme, hvilken platform der bruges som server. Dette kunne være UNIX, MVS eller endda Windows NT. Forskelle i serverarkitektur påvirker kun specifikke operationer, ikke NFS-funktioner. Til klient filstruktur NFS ligner det lokale system.

Det første niveau af gennemsigtighed opnås gennem UNIX's brug af Virtual File System (VFS). VFS er ansvarlig for at interagere ikke kun med NFS, men også med lokale systemer som UFS, ext2, VxFS osv.

Det andet niveau af gennemsigtighed leveres gennem brugen af ​​såkaldte virtuelle noder (vnodes), hvis struktur kan korreleres med inoder i UNIX-filsystemer.

Operationer på NFS-filsystemer er VFS-operationer, mens interaktioner med separate filer og mapper bestemmes af vnode-operationer. RPC-protokollen fra NFS v2 beskriver 16 procedurer forbundet med operationer, ikke kun på filer og mapper, men også på deres attributter. Det er vigtigt at forstå, at RPC-kald og vnode-grænsefladen er forskellige begreber. vnode-grænseflader definerer OS-tjenester til adgang til filsystemer, uanset om de er lokale eller eksterne. RPC fra NFS er en specifik implementering af en af ​​vnode-grænsefladerne.

Læse-/skriveoperationer cachelagres på klientsiden, dvs. klienten cacher indholdet af filer og mapper. Typisk er NFS-cachebufferens størrelse 8 KB. Hvis biod-dæmoner kører på klienten, er læsning færdig forud, og skrivning udføres i doven tilstand. For eksempel, hvis en brugerproces skriver information, akkumuleres dataene i en cachebuffer, før de videresendes, normalt i en enkelt RPC-pakke. Når en skriveoperation udføres, returnerer kernen straks kontrol til processen, og RPC-anmoverføres til biod. Hvis biod-dæmonerne ikke kører, og kernen ikke understøtter multi-threaded RPC-behandling, så skal kernen håndtere videresendelsen af ​​RPC-pakker i single-threaded mode, og brugerprocessen går ind i en tilstand, hvor den venter på, at videresendelsen er fuldført . Men i dette tilfælde bruges NFS-cachen stadig.

Ud over indholdet af NFS-filer og mapper, cachelagres fil- og biblioteksattributter på klientsiden, og attributcachen opdateres med jævne mellemrum (normalt med få sekunders mellemrum). Dette skyldes det faktum, at værdien af ​​attributterne kan bruges til at bedømme tilstanden af ​​en fil eller et bibliotek. Lad os forklare denne tilgang med et eksempel. Når en bruger læser en fil, placeres indholdet af filen i NFS-cachen, men filens attributter (oprettelse/opdateringstid, størrelse osv.) placeres også i attributcachen. Hvis en anden klient på dette tidspunkt skriver til den samme fil, kan dette føre til mismatch af indholdet i forskellige klienters cache. Men da den første klients attributcache opdateres med få sekunders mellemrum, er den i stand til at fastslå, at attributterne er ændret (i dette tilfælde tidspunktet, hvor filen blev opdateret), så klienten skal udføre en opdateringshandling på filens indholdscache (denne handling udføres automatisk).

For at betjene klientanmodninger skal nfsd-dæmoner køre på serveren. I dette tilfælde cacherer dæmonerne information, når de læser fra serverdiske. Alle dæmoner tjener den samme kø af klientanmodninger, hvilket giver mulighed for optimal brug af processorressourcer.

Desværre at bestemme optimal mængde biod og nfsd dæmoner er meget vanskelige. På den ene side, jo større antallet af kørende dæmoner, jo større er antallet af anmodninger, der kan behandles samtidigt; på den anden side kan en forøgelse af antallet af dæmoner påvirke systemets ydeevne negativt på grund af øget processkifteoverhead. Finjustering af NFS er en meget kedelig procedure og kræver, at der ikke kun tages højde for antallet af klienter og brugerprocesser, men også karakteristika som skifttid mellem proceskontekster (dvs. processorarkitekturfunktioner), RAM-størrelse, systembelastning osv. er bedre at bestemme sådanne indstillinger eksperimentelt, selv om standardindstillingerne i de fleste tilfælde vil gøre det (normalt lanceres 8 nfsd-dæmoner på serveren, og 4 biod-dæmoner lanceres på klienterne).

Figur 2. Skriveoperation i NFS v2.

En meget vigtig egenskab ved NFS v2 er, at skrivninger ikke cachelagres på serversiden (se figur 2). Dette blev gjort for at sikre høj pålidelighed af NFS-tjenesten og giver dig mulighed for at garantere dataintegritet efter en servergenstart i tilfælde af en serverfejl. Manglen på skrive-caching er det største problem med NFS v2. I skriveoperationer er NFS betydeligt ringere end konkurrerende teknologier, selvom det i læseoperationer ikke taber meget til dem. Den eneste metode til at bekæmpe lav skriveydelse er at bruge diskundersystemer med en strømuafhængig indbygget cache, som i ret dyre RAID-arrays.

Når du arbejder i distribueret og globale netværk NFS v2 har en anden ulempe på grund af valget af UDP som transportprotokol for tjenesten. Som du ved, garanterer UDP ikke levering af pakker; desuden svarer den rækkefølge, pakker modtages i, muligvis ikke til den rækkefølge, de sendes i.

Dette kan føre til følgende to ubehagelige konsekvenser: pakketab og en lang forsinkelse i behandlingen. Forestil dig, at en klient udfører en læseoperation på en stor fil. I dette tilfælde skal serveren sende flere pakker for at fylde klientens cachebuffer. Hvis en af ​​pakkerne går tabt, vil klienten blive tvunget til at gentage anmodningen igen, og serveren vil blive tvunget til at generere svar osv.

Situationen med forsinkelse i behandlingen af ​​RPC-anmodninger på grund af f.eks. stor serverbelastning eller netværksproblemer er også ret ubehagelig. Hvis den angivne tidsgrænse overskrides, vil klienten antage, at pakken er tabt, og vil forsøge at gentage anmodningen. For mange NFS-operationer er dette ikke et problem, da selv skriveoperationen kan gentages af serveren. Men hvad med operationer som "fjern mappe" eller "omdøb fil"? Heldigvis understøtter de fleste NFS-implementeringer server-side caching af duplikerede anmodninger. Hvis serveren modtager en gentagen anmodning om en handling inden for en kort periode, ignoreres en sådan anmodning.

RPC-systemet sporer ikke forbindelsestilstand, hvilket skaber problemer, når flere klienter får adgang til den samme fil på samme tid. Der er to vanskeligheder her:

• hvordan man låser en fil, især når man skriver til den;
• Hvordan garanterer man låsenes integritet i tilfælde af et nedbrud og genstart af NFS-serveren eller -klienten?

For at gøre dette bruger NFS to specielle dæmoner: rpc.lockd er ansvarlig for at låse filer, og rpc.statd er ansvarlig for at overvåge tilstanden af ​​låse (se figur 3). Disse dæmoner kører på både klient- og serversiden. Dæmonerne rpc.lockd og rpc.statd er tildelt to specielle mapper (sm og sm.bak), hvor låseinformation er gemt.

En unik og ganske praktisk ekstra service, automounter, giver dig mulighed for automatisk at montere filsystemer, når brugerprocesser får adgang til dem. Efterfølgende forsøger automounter periodisk (en gang hvert femte minut som standard) at afmontere systemet. Hvis den er optaget (f.eks. er en fil åben), så fortsætter tjenesten med at arbejde i normal tilstand. Hvis filsystemet ikke længere er tilgået, afmonteres det automatisk. Automounter-funktionen er implementeret af flere programmer, hvor amd og autofs er særligt populære blandt dem.

NFS V3 FUNKTIONER

Den tredje version af NFS er fuldstændig bagudkompatibel med den anden version, dvs. NFS v3-serveren "forstår" NFS v2- og NFS v3-klienter. Ligeledes kan en NFS v3-klient få adgang til en NFS v2-server.

En vigtig innovation i NFS v3 er understøttelse af TCP-transportprotokollen. UDP er fantastisk til lokale netværk, men er ikke egnet til langsomme og ikke altid pålidelige globale kommunikationslinjer. I NFS v3 multiplekses al klienttrafik til en enkelt TCP-forbindelse.

I NFS v3 øges cachebufferens størrelse til 64 KB, hvilket har en gavnlig effekt på ydeevnen, især set i lyset af den aktive brug af højhastighedsnetværksteknologierne Fast Ethernet, Gigabit Ethernet og ATM. Derudover giver NFS v3 dig mulighed for at gemme oplysninger, der er cachelagret på klienten, ikke kun i RAM, men også på klientens lokale disk (retfærdigvis er det værd at bemærke, at nogle NFS v2-implementeringer også giver denne funktion). Denne teknologi er kendt som CacheFS.

Figur 4. Skriveoperation i NFS v3.

Men måske kan en endnu vigtigere innovation af NFS v3 betragtes som en radikal stigning i ydeevnen på skriveoperationer. Nu udføres caching af optaget information også på serversiden, mens registrering og bekræftelse af kendsgerningen af ​​at skrive data til disk udføres ved hjælp af en speciel commit-anmodning (se figur 4). Denne teknologi kaldes sikker asynkron optagelse. Efter at dataene er blevet sendt til serverens cache, sender klienten den en commit-anmodning, som starter en skriveoperation til serverens disk. Til gengæld, efter at have skrevet information til disken, sender serveren klienten bekræftelse på dens succesfulde afslutning.

Nyt i NFS v3 er understøttelse af 64-bit filsystemer og forbedret understøttelse af ACL'er.

Hvad angår fremtiden, promoverer Sun nu WebNFS-teknologi, hvis brug giver adgang til filsystemer fra enhver webbrowser eller gennem programmer skrevet i Java. Der er ingen grund til at installere nogen klientsoftware. WebNFS (ifølge Sun) giver en ydelsesforstærkning på tre til fem gange i forhold til ftp eller HTTP.

KONKLUSION

Ved at kende principperne for drift af NFS-protokoller kan administratoren konfigurere tjenesten optimalt. NFS-netværksfilsystemet er ideelt til UNIX-netværk, da det kommer med næsten alle versioner af dette operativsystem. Desuden er NFS-understøttelse implementeret på UNIX-kerneniveau. Som Linux begynder gradvist at tage på i vægt på niveauet stationære computere, så har NFS en chance for at opnå anerkendelse også her. Desværre skaber brug af NFS på Windows-klientcomputere visse problemer forbundet med behovet for at installere specialiseret og ret dyrt klientsoftware. I sådanne netværk synes brugen af ​​SMB-tjenester, især Samba-software, mere at foretrække. Vi vender dog tilbage til SMB-produkter til UNIX i et af de kommende LAN-problemer.