Nfs protokoll hva. Hva er NFS? Nettverksfilsystem. Filsystemets nettverkstilgangsprotokoll. Hvordan det hele begynte

Legg igjen en kommentar 6,950

Her, hva er det neste? Hvordan se filmer og lytte musikkfiler som lastet ned? Trenger du virkelig å brenne dem til plater og overføre dem på denne måten til en datamaskin med GUI? Eller må du kopiere dem over treg SFTP? Nei! NFS kommer til unnsetning! Nei, dette er ikke en serie med racingspill, men Network Filsystem(Nettverksfilsystem).
Network File System (NFS) er et nettverksfilsystem som lar brukere få tilgang til filer og kataloger på eksterne datamaskiner som om filene og katalogene var lokale. Hovedfordelen med et slikt system er at individuelle arbeidsstasjoner kan bruke mindre av sin egen diskplass, siden de delte dataene lagres på en egen maskin og er tilgjengelig for andre maskiner på nettverket. NFS er klient-server-applikasjon... Det vil si at en NFS-klient må være installert på brukerens system, og en NFS-server på datamaskinene som gir deres diskplass.

Installere og konfigurere en NFS-server (192.168.1.2)

1. Installer. Etter å ha koblet til datamaskinen via SSH av serveren, eller ganske enkelt i konsollen, skriv inn:

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

Dette vil også installere NFS-serveren nødvendig pakke portkart.

2. Konfigurering. For å konfigurere listen over kataloger som vi vil åpne og listen til hvem vi vil åpne dem, rediger filen / etc / eksporter :

Sudo nano / etc / eksporter / data 192.168.1.1/24(rw,no_root_squash,async)

I eksemplet ovenfor åpnet vi katalogen på serveren / data og dens underkataloger for delt bruk av alle datamaskiner med IP: 192.168.1.1 - 192.168.1.255 med lese- og skriverettigheter.

Et annet eksempel:

/ home / serg / 192.168.1.34 (ro, asynkron)

Dette eksemplet gjør hjemmekatalogen til brukerserg tilgjengelig i skrivebeskyttet modus for datamaskinen med IP 192.168.1.34. Alle andre datamaskiner på nettverket vil ikke ha tilgang til denne katalogen.

Tilgjengelige alternativer:

  • ro - skrivebeskyttet tillatelse. Du trenger ikke spesifisere det, siden det er installert som standard;
  • rw - gir klienter skrivetilgang;
  • no_root_squash - som standard root-brukeren på klientmaskin vil ikke ha tilgang til offentlige kataloger på serveren. Med dette alternativet fjerner vi denne begrensningen. Av sikkerhetsmessige årsaker er det best å ikke gjøre dette;
  • noaccess - nekter tilgang til den angitte katalogen. Det kan være nyttig hvis du tidligere har satt tilgang for alle nettverksbrukere til en bestemt katalog, og nå vil du begrense tilgangen i underkatalogen til kun noen brukere.

Nå må du starte nfs-kernel-server på nytt:

Sudo /etc/init.d/nfs-kernel-server restart

Hvis du etter det vil endre noe i filen / etc / eksporter , så for at endringene skal tre i kraft, kjør bare følgende kommando:

Sudo exportfs -a

Alt. NFS-serveren er installert og konfigurert. Du kan gå til NFS-klienten.

Installere og konfigurere NFS-klienten

1. Installasjon. Vi utfører følgende i terminalen til datamaskinen som skal kobles til:

Sudo apt-get install portmap nfs-common

2. Innstilling. Først, la oss lage en katalog der den eksterne mappen skal monteres:

Cd ~ mkdir data

Du kan montere på to måter - hver gang manuelt eller ved å skrive monteringsalternativene til en fil / etc / fstab.

Metode 1. Montering manuelt
Lag en tekstfil på skrivebordet eller i en annen mappe:

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

Vi skriver til den:

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

Vi gjør det kjørbart:

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

Nå når jeg trenger å koble til serveren, kjører jeg dette skriptet i terminalen slik at jeg kan skrive inn passordet for sudo.

Metode 2. Legge til / etc / fstab
Åpne / etc / fstab:

Sudo nano / etc / fstab

Og legg til en linje på slutten av filen:

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

Merk følgende! Erstatt 192.168.1.2:/data med IP- eller servernavnet og banen til den delte katalogen. Monteringsalternativer kan endres.

Alternativ hard binder katalogen på klienten til serveren, og hvis serveren faller av, kan datamaskinen også fryse. Alternativ myk, som navnet tilsier, er ikke så kategorisk.

Etter å ha lagret filen, kan du montere den eksterne mappen.

Network File System (NFS) er en fildelingsløsning for organisasjoner som har blandede Windows- og Unix/Linux-maskinmiljøer. NFS-filsystemet gjør det mulig å åpne delt tilgang til filer mellom de angitte ulike plattformene med et fungerende operativsystem Windows Server 2012. NFS-tjenester i Windows Server 2012 inkluderer følgende funksjoner og forbedringer.

1. Søk i Active Directory. Du har muligheten til å bruke Windows Active Directory for å få tilgang til filer. Identity Management for Unix-skjemautvidelsen for Active Directory inneholder feltene Unix-brukeridentifikator (UID) og gruppeidentifikator (GID). Dette tillater tjenester Server for NFS (Server for NFS) og Client for NFS (Client for NFS) viser kontotilordninger Windows-brukere på Unix direkte fra Active Directory Domain Services. Identity Management for Unix gjør det enkelt å administrere tilordningen av Windows-brukerkontoer til Unix i Active Directory Domain Services.

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

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

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

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

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

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

NFS Services-komponenter

Følgende to komponenter av NFS er tilgjengelige.

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

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

Installere server for NFS ved å bruke PowerShell

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

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

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

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

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

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

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

PS C: \> Get-Command -Module NFS

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

Sette standard tillatelser

Nå må vi åpne noen porter på brannmuren for at NFS skal fungere. Portene som kreves for at NFS skal fungere riktig, vises i tabellen nedenfor.

NFS: Et praktisk og fremtidssikkert nettverksfilsystem

Nettverksfilsystem Er en nettverksabstraksjon på toppen av et vanlig filsystem, som lar en ekstern klient få tilgang til det over nettverket på samme måte som når du får tilgang til lokale filsystemer. Selv om NFS ikke er den første nettverkssystem, har det utviklet seg til å bli det mest funksjonelle og etterspurte nettverksfilsystemet i UNIX® i dag. NFS lar flere brukere dele et felles filsystem og sentraliserer data for å minimere mengden diskplass som kreves for å lagre dem.

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

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 Data Access Protocol (DAP) og var en del av DECnet-protokollpakken. Som med TCP / IP, har DEC publisert spesifikasjoner for sine nettverksprotokoller, inkludert DAP.

NFS var det første moderne nettverksfilsystemet bygget over IP. Prototypen kan betraktes som et eksperimentelt filsystem utviklet av Sun Microsystems på begynnelsen av 1980-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.

Deretter ble standarden oppdatert til NFSv3-versjonen definert i RFC 1813. Denne versjonen av protokollen var mer skalerbar enn tidligere og støttede filer større størrelse(mer enn 2 GB), asynkront opptak og TCP as transportprotokoll... NFSv3 satte retningen for filsystemer for WAN-nettverk (wide area). I 2000, som en del av RFC 3010-spesifikasjonen (revidert i RFC 3530-versjonen), ble NFS portert til bedriftsmiljøet. Sun introduserte sikrere NFSv4 med stateful støtte (tidligere versjoner av NFS støttet ikke statefulness, det vil si at de var statsløse). Foreløpig er den nyeste versjonen av NFS versjon 4.1, definert i RFC 5661, der protokollen ved hjelp av utvidelsen pNFS støtte for parallell tilgang for distribuerte servere er lagt til.

Historien om NFS-utvikling, 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 ekstremt stabilt og bærbart nettverksfilsystem med enestående skalerbarhet, ytelse og servicekvalitet. Med økende hastighet og avtagende latens for datautveksling i nettverket, fortsetter NFS å være en populær måte å implementere filsystemet i nettverket. Selv med LAN oppmuntrer virtualisering til lagring av data på nettverket for å gi virtuelle maskiner ekstra mobilitet. NFS støtter også de nyeste datamiljøene designet for å optimalisere virtuelle infrastrukturer.

NFS arkitektur

NFS bruker en standard klient-server-arkitekturmodell (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 inne i klientens lokale filområde.

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

På Linux® gir en virtuell filsystemsvitsj (VFS) muligheten til å støtte flere filsystemer (som et filsystem) på en enkelt vert samtidig. 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/O-forespørsler, i stedet for å bli behandlet lokalt på verten, kan rutes til nettverket for kjøring.

VFS bestemmer at forespørselen den mottar er NFS og sender den til NFS-behandleren i kjernen. NFS-behandleren behandler I/O-forespørselen og oversetter den til en NFS-prosedyre (ÅPNE, FÅ TILGANG, OPPRETT, LES, LUKK, FJERN, etc.). Disse prosedyrene, beskrevet i en separat RFC-spesifikasjon, definerer oppførselen til NFS-protokollen. Den nødvendige prosedyren velges basert på 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 NFS-forespørselen 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 bruker samme format for samme datatyper. 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 overtar arbeidet med typekonvertering til standardrepresentasjon (XDR) slik at plattformer som bruker ulike arkitekturer kan samhandle og dele filsystemer. XDR definerer et bitformat for typer som float, og byte-rekkefølge for typer som faste og variable lengder. Selv om XDR først og fremst er kjent for sin bruk i NFS, kan denne spesifikasjonen være nyttig når du må jobbe i samme miljø med forskjellige arkitekturer.

Etter at XDR konverterer dataene til standardrepresentasjon, sendes forespørselen over nettverket ved hjelp av en spesifikk transportprotokoll. Tidlige implementeringer av NFS brukte UDP, men i dag brukes TCP for mer robusthet.

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


For nettverk med flott tid venter i NFSv4 tilbyr en spesiell sammensatt prosedyre ( sammensatt prosedyre). Denne prosedyren lar deg legge inn flere RPC-anrop innenfor en enkelt forespørsel for å minimere kostnadene ved å sende forespørsler over nettverket. Denne prosedyren implementerer også mekanismen for tilbakeringingsfunksjoner for å motta svar.

NFS-protokoll

Når en klient starter opp med NFS, er det første trinnet monteringsoperasjonen, som er å montere det eksterne filsystemet til det lokale filsystemområdet. Denne prosessen begynner med et kall til monteringsprosedyren (en av Linux-systemfunksjonene), som omdirigeres gjennom VFS til NFS-komponenten. Deretter bruker du et RPC-kall til get_port-funksjonen på ekstern server portnummeret som skal brukes til montering bestemmes, og klienten sender en monteringsforespørsel via RPC. Denne forespørselen på serversiden håndteres av en spesiell rpc.mountd-demon som er ansvarlig for mount-protokollen ( montere protokoll). Daemonen bekrefter 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, spesifiseres filsystembeskrivelsen i svaret til mount RPC-prosedyren. Klienten beholder informasjon om de lokale og eksterne monteringspunktene og er i stand til å gjøre I/O-forespørsler. Monteringsprotokollen er ikke feilfri fra et sikkerhetssynspunkt, så NFSv4 bruker interne RPC-anrop i stedet, som også kan manipulere monteringspunkter.

For å lese en fil må du først åpne den. Det er ingen OPEN-prosedyre i RPC; i stedet bekrefter klienten ganske enkelt at den angitte filen og katalogen finnes på det monterte filsystemet. Klienten starter med å lage en RPC GETATTR-forespørsel for katalogen, som returnerer katalogens attributter eller en indikator på at katalogen ikke eksisterer. Deretter foretar klienten en RPC LOOKUP-forespørsel for å sjekke eksistensen av filen. Hvis filen eksisterer, sendes det en RPC GETATTR-forespørsel for å finne ut filattributtene. Ved å bruke informasjonen hentet fra vellykkede LOOKUP- og GETATTR-anrop, oppretter klienten en filbeskrivelse som presenteres for brukeren for fremtidige forespørsler.

Etter at filen er identifisert på det eksterne filsystemet, kan klienten utstede RPC READ-forespørsler. Denne forespørselen består av en filbeskrivelse, tilstand, offset og antall byte som skal leses. Klienten bruker staten ( stat) for å finne ut om operasjonen kan utføres i dette øyeblikket, dvs. om filen er låst. Offset ( offset) indikerer hvor du skal begynne å lese, og byte-telleren ( telle) bestemmer hvor mange byte som skal leses. Som et resultat av et RPC READ-kall returnerer ikke serveren alltid så mange byte som forespurt, men den sender alltid sammen med returnerte data 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, som kan brukes til å studere de viktigste aspektene ved utviklingen av NFS-teknologi.

Før bruken av NFSv4, for å utføre filbehandlingsoppgaver som montering, låsing, etc. det var spesielle tilleggsprotokoller. I NFSv4 har filbehandlingsprosessen blitt forenklet til en enkelt protokoll; i tillegg, siden denne versjonen UDP ikke lenger brukes som en transportprotokoll. NFSv4 inkluderer støtte for UNIX og Windows® filtilgangssemantikk, som gjør at NFS kan integreres naturlig i andre operativsystemer.

NFSv4.1 introduserte konseptet parallell NFS(parallell NFS - pNFS). For å gi mer skalerbarhet implementerer NFSv4.1 en arkitektur der data og metadata ( markering) er distribuert på tvers av enheter på en måte som ligner på klyngede filsystemer. Som illustrert deler pNFS økosystemet inn i tre pilarer: 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 ønsker å få tilgang til en fil, sender serveren den "markup"-metadata. Metadataene inneholder informasjon om plasseringen av filen på lagringsenheter. Med denne informasjonen kan klienten få tilgang til lagring direkte uten å måtte samhandle med serveren, noe som forbedrer skalerbarhet og ytelse. Når klienten er ferdig med å jobbe med filen, bekrefter han endringene som er gjort i filen og dens "markup". Om nødvendig kan serveren be om markup-metadata fra klienten.

Med introduksjonen av pNFS har flere nye operasjoner blitt lagt til NFS-protokollen for å støtte denne mekanismen. LayoutGet-metoden brukes til å hente metadata fra serveren, LayoutReturn-metoden "frigjør" metadata "fanget" av klienten, og LayoutCommit-metoden laster "markup" mottatt fra klienten inn i depotet slik at det er tilgjengelig for andre brukere. Serveren kan tilbakekalle metadataene fra klienten ved å bruke LayoutRecall-metoden. "Merkte" metadata er spredt over flere lagringsenheter for å gi samtidig tilgang og høy ytelse.


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

NFS fortsetter å utvikle seg og NFSv4.2-kravene ble publisert i september 2010. Noen av innovasjonene er relatert til den observerte migreringen av lagringsteknologier mot virtualisering. For eksempel, i virtuelle miljøer med en hypervisor, er dataduplisering høyst sannsynlig (flere operativsystemer leser/skriver og hurtigbufrer de samme dataene). Derfor er det ønskelig at lagringssystemet som helhet forstår hvor duplisering skjer. Denne tilnærmingen kan 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 er utstyrt med sin egen interne datakraft, kopiering er introdusert på serversiden, noe som gjør det mulig å redusere belastningen ved kopiering av data til internt nettverk når det effektivt kan gjøres på selve lagringsenheten. Andre innovasjoner inkluderer underfilbufring for flash og anbefalinger for tilpasning av I/O på klientsiden (for eksempel ved å bruke mapadvise).

NFS-alternativer

Selv om NFS er det mest populære nettverksfilsystemet på UNIX og Linux, finnes det andre nettverksfilsystemer i tillegg til det. Windows®-plattformen bruker oftest SMB, også kjent som CIFS; Windows støtter imidlertid også NFS, og det samme gjør Linux SMB.

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

Også verdt å nevne er filsystemene OpenAFS (Open Source-versjonen av Andrew Distributed File System utviklet ved Carnegie Mellon University og IBM), GlusterFS (et distribuert filsystem for generell bruk for organisering av skalerbar datalagring) og Luster (en massivt parallell nettverksfil system for klyngeløsninger). Alle disse åpen kildekode-systemene kan brukes til å bygge distribuert lagring.

Konklusjon

Utviklingen av NFS-filsystemet fortsetter. I likhet med Linux, egnet for å støtte budsjett-, innebygde og høyytelsesløsninger, tilbyr NFS en arkitektur med skalerbare lagringsløsninger som passer både for enkeltpersoner og organisasjoner. Når vi ser på veien NFS har gått og dens fremtidige utvikling, blir det klart at dette filsystemet vil fortsette å endre måten vi tenker på hvordan fillagringsteknologier implementeres og brukes.

God tid, lesere og gjester. Det var en veldig lang pause mellom innleggene, men jeg er tilbake i kamp). I dagens artikkel vil jeg vurdere NFS-protokolloperasjon, og konfigurere en NFS-server og NFS-klient på Linux.

En introduksjon til NFS

NFS (Nettverksfilsystem - nettverksfilsystem) etter min mening - en ideell løsning i et lokalt nettverk, hvor rask (raskere enn SAMBA og mindre ressurskrevende sammenlignet med eksterne filsystemer med kryptering - sshfs, SFTP, etc ...) datautveksling er nødvendig og ikke er på fremste sikkerhet for overført informasjon. NFS-protokoll muliggjør montere eksterne filsystemer over et nettverk i et lokalt katalogtre som om det var et montert diskfilsystem. Dermed kan lokale applikasjoner fungere med det eksterne filsystemet som med det lokale. Men du må være forsiktig (!) Med sette opp NFS, fordi med en viss konfigurasjon er det mulig å suspendere klientens operativsystem, mens du venter på uendelig I / O. NFS-protokoll basert på arbeid RPC-protokoll, som ennå ikke egner seg til 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-filsystemet. Du kan sjekke om kjernen støtter NFS-filsystemet ved å se etter tilstedeværelsen av de tilsvarende linjene i filen / proc / filsystemer:

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

Hvis de angitte linjene i filen / proc / filsystemer mislykkes, må du installere pakkene beskrevet nedenfor. Dette vil mest sannsynlig installere avhengige kjernemoduler for å støtte de ønskede filsystemene. Hvis etter installasjon av pakker, vises ikke NFS-støtte i den angitte filen, vil det være nødvendig, med inkludering av 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, arbeidet med UDP-protokoll... Versjon 1 er beskrevet i. NFSv2 ble utgitt i samme 1989, ble beskrevet av samme RFC1094 og var også basert på UDP-protokollen, samtidig som du ikke kunne lese mer enn 2 GB fra en fil. NFSv3 revidert i 1995 og beskrevet i. De viktigste nyvinningene til den tredje versjonen var støtte for store filer, lagt til støtte for TCP-protokollen og store TCP-pakker, noe som betydelig akselererte teknologiens drift. NFSv4 ferdigstilt i 2000 og beskrevet i RFC 3010, revidert i 2003 og beskrevet i. Den fjerde versjonen inkluderte ytelsesforbedringer, støtte ulike virkemidler Autentisering (spesielt Kerberos og LIPKEY som bruker RPCSEC GSS-protokollen) og ACL-er (både POSIX- og Windows-typer). NFS v4.1 ble godkjent av IESG i 2010, og fikk nummeret. En viktig nyvinning av versjon 4.1 er spesifikasjonen pNFS - Parallel NFS, en mekanisme for parallell tilgang til en NFS-klient til dataene til mange distribuerte NFS-servere. Tilstedeværelsen av en slik mekanisme i nettverksfilsystemstandarden vil bidra til å bygge distribuerte "sky"-lagringer og informasjonssystemer.

NFS server

Siden vi har NFS- dette er Nettverk filsystem er nødvendig. (Du kan også lese artikkelen). Videre er det nødvendig. På Debian er dette pakken nfs-kjerneserver og nfs-vanlig, i RedHat er dette pakken nfs-utils... Og også, det er nødvendig å aktivere lanseringen av demonen på de nødvendige OS-kjørenivåene (kommandoen i RedHat er / sbin / chkconfig nfs på, i Debian - /usr/sbin/update-rc.d nfs-kernel-server standarder).

Installerte pakker i Debian kjøres 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 manuset kalles nfslock og serveren kalles ganske enkelt nfs... Om nfs-vanlig debian-siden forteller oss bokstavelig talt følgende: vanlige filer for NFS-klient og -server, må denne pakken installeres på en maskin som fungerer som en NFS-klient eller -server. Pakken inkluderer programmer: lockd, statd, showmount, nfsstat, gssd og idmapd... Ved å se innholdet i oppstartsskriptet /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, sjekker for tilstedeværelse i filer / etc / default / nfs-common, / etc / fstab og / etc / eksporter parametere som krever startdemoner idmapd og gssd , starter demonen /sbin/rpc.statd , så før du starter /usr/sbin/rpc.idmapd og /usr/sbin/rpc.gssd sjekker for tilstedeværelsen av disse kjørbare binærfilene, deretter for daemon /usr/sbin/rpc.idmapd sjekker for sunrpc, nfs og nfsd, samt støtte for filsystemet rpc_pipefs i kjernen (det vil si dens tilstedeværelse i filen / proc / filsystemer), hvis alt er vellykket, kjører 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 / eksporter, Tilgjengelighet nfsd, tilgjengelighet av støtte NFS filsystem i (det vil si i filen / proc / filsystemer), hvis alt er på plass, startes demonen /usr/sbin/rpc.nfsd , sjekker deretter om parameteren er satt NEED_SVCGSSD(sett i serverinnstillingsfilen / etc / default / nfs-kernel-server) og, hvis gitt, starter demonen /usr/sbin/rpc.svcgssd , den siste som startet demonen /usr/sbin/rpc.mountd ... Fra dette skriptet kan du se det NFS serverdrift består av daemoner rpc.nfsd, rpc.mountd og hvis Kerberos-autentisering brukes, da daemonen rcp.svcgssd. Daemonen rpc.rquotad og nfslogd kjører fortsatt i den røde hatten (Av en eller annen grunn fant jeg ikke informasjon om denne demonen i Debian og årsakene til dens fravær, tilsynelatende slettet ...).

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

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

  • rpc.gssd- NFSv4-demonen tilbyr autentiseringsmetoder gjennom GSS-API (Kerberos Authentication). 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 arbeid NFSv2 og v3 tilleggspakke kreves portkart(i nyere distribusjoner, erstattet av omdøpt i rpcbind). Denne pakken installeres vanligvis automatisk med NFS som en avhengig og implementerer driften av RPC-serveren, det vil si at den er ansvarlig for den dynamiske tilordningen av porter for noen tjenester som er registrert i RPC-serveren. Bokstavelig talt, ifølge dokumentasjonen, er dette en server som konverterer Remote Procedure Call (RPC) programnumre 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 startes av /etc/init.d/portmap-skriptet før du starter NFS-tjenester.

Kort sagt, jobben til en RPC-server (Remote Procedure Call) er å behandle RPC-anrop (aka 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 rpcbind, i nyere versjoner), og klienter som bruker RPC-anrop som dirigerer forespørsler til portmapperen, får nødvendig informasjon... Brukervennlige programtjenestenavn og deres tilsvarende numre er definert i / etc / rpc. Så snart en tjeneste har sendt en tilsvarende forespørsel og registrert seg med RPC-serveren i portmapperen, tildeler RPC-serveren TCP- og UDP-portene til tjenesten som tjenesten ble startet på og lagrer i kjernen den tilsvarende informasjonen om kjører tjeneste (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 hovedsetningen, som burde klargjøre: hovedfunksjonen til portkartleggeren er å returnere 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 portnummeret for å kommunisere med RPC-tjenesten den trenger.

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

  1. Portomformeren må startes først, vanligvis ved systemoppstart. Dette oppretter et TCP-endepunkt og åpnes TCP-porter 111. Det opprettes 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 du foretar et RPC-anrop.) Et dynamisk tilordnet portnummer tildeles hver versjon av tjenesten. Serveren registrerer hvert program, versjon, protokoll og portnummer ved å foreta riktig RPC-anrop.
  3. Når RPC-klientprogrammet trenger informasjonen det trenger, kaller det en portmapper-rutine for å få et dynamisk tildelt portnummer for et gitt program, versjon og protokoll.
  4. Som svar på denne forespørselen returnerer nord portnummeret.
  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-anropsmeldingen til UDP-portnummeret som den forespurte tjenesten kjører på. Som svar sender tjenesten et UDP-datagram som inneholder en RPC-svarmelding. Hvis TCP er i bruk, åpner klienten aktivt TCP-portnummeret til den forespurte tjenesten og sender deretter en RPC-anropsmelding over den etablerte forbindelsen. Serveren svarer med en RPC-svarmelding over tilkoblingen.

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

ARCHIV ~ # rpcinfo -p prog-ma versjon proto port 100000 2 tcp 111 portmapperen 100000 2 UDP 111 portmapperen 100024 en UDP 59451 status 100024 en tcp 60872 status 100021 en UDP 44310 nlockmgr 100021 3 UDP 44310 nlockmgr 100021 4 UDP 44310 nlock 44851 nlockmgr 100021 3 tcp 44851 nlockmgr 100021 4 tcp 44851 nlockmgr 100003 2 tcp 2049 NFS 100003 3 TCP 2049 NFS 100003 4 tcp 2049 NFS 100003 2 UDP 2049 NFS 100003 3 UDP 2049 NFS 100003 4 UD5 tcp 2049 NFS-1000030 en feste 41405 mountd 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 registreringen av et program eller få informasjon om en egen tjeneste RPC (flere alternativer i man rpcinfo). Som du kan se, er portmapper versjon 2-demoner 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 2,3,4, samt mount daemon versjoner 1,2,3.

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

Network File System Protocol Operation

Monter ekstern 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), betjenes av portmapper-prosessen og registreres på tcp / 111- og udp / 111-portene.
  2. Det startes tjenester (rpc.nfsd, rpc.statd, etc.), som registreres på RPC-serveren og registreres på vilkårlige nettverksporter (med mindre en statisk port er spesifisert i tjenesteinnstillingene).
  3. mount-kommandoen på klientdatamaskinen sender en forespørsel til kjernen om å montere en nettverkskatalog med en indikasjon på filsystemtype, vert og selve katalogen, kjernen sender en RPC-forespørsel til portmap-prosessen på NFS-serveren på udp / 111-port (hvis klienten ikke har muligheten til å jobbe via tcp)
  4. NFS-serverkjernen undersøker RPC for 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å. Nå kan NFS-serveren validere klienten 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. Problemer med klientmonteringskommandoen systemanrop mount for å binde filbeskrivelsen oppnådd i trinn 5 til det lokale monteringspunktet på klientverten. Filbeskrivelsen lagres i NFS-klientkoden, og fra dette tidspunktet vil all tilgang fra brukerprosesser til filer på serverens filsystem bruke filbeskrivelsen som utgangspunkt.

Kommunikasjon mellom klient og NFS-server

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

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

  1. Klienten (brukerprosessen) bryr seg ikke om den får tilgang til lokal fil eller til en NFS-fil. Kjernen tar for seg interaksjonen med maskinvaren gjennom kjernemoduler eller innebygde systemanrop.
  2. Kjernemodul kjerne / fs / nfs / nfs.ko, som fungerer som en NFS-klient og sender RPC-forespørsler til NFS-serveren gjennom 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 portmapper, 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 den lokale filtilgangsrutinen, 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 vanligvis av å spesifisere lokale kataloger som skal tillates å montere eksterne systemer i fil / etc / eksporter... Denne handlingen kalles eksportkataloghierarki... De viktigste kildene til informasjon om eksporterte kataloger er følgende filer:

  • / etc / eksporter- hovedkonfigurasjonsfilen som lagrer konfigurasjonen til de eksporterte katalogene. Brukes når du starter NFS og exportfs-verktøyet.
  • / var / lib / nfs / xtab- inneholder en liste over kataloger montert av eksterne klienter. Brukes av rpc.mountd-demonen når en klient prøver å montere et hierarki (en mount-post opprettes).
  • / var / lib / nfs / etab- en liste over kataloger som kan monteres av eksterne systemer, som indikerer alle parametere for de eksporterte katalogene.
  • / var / lib / nfs / rmtab- en liste over kataloger som ikke eksporteres for øyeblikket.
  • / 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 henter denne informasjonen fra / var / lib / nfs / xtab.
    • tråder- inneholder antall tråder (kan også endres)
    • ved å bruke filehandle kan du få en filpeker
    • og så videre...
  • / proc / net / rpc- inneholder råstatistikk som kan hentes ved hjelp av nfsstat, samt ulike cacher.
  • / var / run / portmap_mapping- informasjon om registrert i RPC-tjenester

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

Konfigurering av / etc / eksportfilen

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

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

Hver linje i eksportfilen har følgende format:

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

Hvor eksportpunkt absolutt vei det eksporterte kataloghierarkiet, klient1 - n navnet på én eller flere klienter eller IP-adresser, atskilt med mellomrom, som er tillatt å montere eksportpunkt . Alternativer beskriv monteringsreglene for klient spesifisert før alternativer .

Her er en typisk eksempel eksportfilkonfigurasjon:

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

V dette eksemplet datamaskiner filer og 10.0.0.1 har tilgang til eksportpunktet / arkiv1, mens filverten leses/skrives, og 10.0.0.1-verten og 10.0.230.1/24-undernettet er skrivebeskyttet.

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

  • Navn individuelle noder beskrevet som filer eller files.DOMAIN.local.
  • Domenemasker 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 starter med 10.0.0.
  • Angi navnet på @myclients-nettverksgruppen som har tilgang til ressursen (når du bruker en NIS-server)

Generelle eksportalternativer for kataloghierarkier

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

  • 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 en nestet (montert) i den andre. Klienten må eksplisitt montere det andre (underordnede) hierarkiet, ellers vil monteringspunktet til det underordnede hierarkiet 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å filsystemtillatelsene, mens serveren ikke er i stand til å skille en filleseforespørsel fra en utførelsesforespørsel, så den tillater lesing hvis brukeren har lest eller utført tillatelser.)
  • 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)- indikerer at serveren bare skal svare på forespørsler etter at endringene som er 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 tap av informasjon er mulig i tilfelle en frakoblet tilkobling eller utstyrssvikt.
  • wdelay (ingen_wdelay)- Ber serveren om å utsette utføringen av skriveforespørsler hvis en påfølgende skriveforespørsel venter, skriver data i større blokker. Dette forbedrer ytelsen når du sender store skrivekøer. no_wdelay instruerer om ikke å utsette utførelsen av kommandoen for skriving, noe som kan være nyttig hvis serveren mottar et stort nummer av lag som ikke er relatert til hverandre.

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

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

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

Alternativer for visning av bruker-ID (samsvar).

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 / gruppe... NFS-serveren antar at operativsystemet til den eksterne verten har autentisert brukerne og tildelt dem de riktige UIDene og GIDene. Eksport av filene gir brukere på klientsystemet den samme tilgangen til disse filene som om de logget på direkte på serveren. Følgelig, når en NFS-klient sender en forespørsel til en server, bruker serveren UID og GID for å identifisere brukeren i lokalt system, som kan føre til noen problemer:

  • brukeren har kanskje ikke samme identifikatorer i begge systemene og kan følgelig få tilgang til filene til en annen bruker.
  • siden root-brukeren har en identifikator på alltid 0, deretter tilordnes denne brukeren lokal bruker avhengig av de angitte alternativene.

Følgende alternativer definerer reglene for å kartlegge eksterne brukere til lokale:

  • root_squash (ingen_root_squash)- Med det gitte alternativet 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 ALLE brukere (ikke bare root) til å vises som anonyme 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 angi kartlegging av ekstern UID / GID - lokal UID / GID.

Et eksempel på bruk av en brukertilordningsfil:

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

NFS serveradministrasjon

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

  • nfsstat
  • showmsecure (usikker) ount

nfsstat: NFS- og RPC-statistikk

nfsstat-verktøyet lar deg se statistikken til RPC- og NFS-servere. Kommandoalternativer kan vises i man nfsstat.

showmount: viser NFS-statusinformasjon

Showmount-verktøy spør rpc.mountd daemon på den eksterne verten for 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 er gitt
  • --eksport- gir en liste over eksporterte filsystemer fra nfsds synspunkt

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

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

Hvis du spesifiserer vertsnavnet / IP 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 / eksporter, vil det være mer nøyaktig å skrive tjener ikke, men synkroniseres 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 filene i / var / lib / nfs / katalogen og kommuniserer ikke direkte med kjernen. Uten parametere viser de eksporterte filsystemene.

Eksportfs alternativer:

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

NFS-klient

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

På NFS-klienter ingen demoner trenger å startes, klientfunksjoner kjører kjernemodulen kjerne / fs / nfs / nfs.ko som brukes når du monterer et eksternt filsystem. Eksporterte kataloger fra serveren kan monteres på klienten på følgende måter:

  • manuelt ved å bruke monteringskommandoen
  • automatisk ved oppstart, ved montering av 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 i de følgende artiklene vil det være en egen beskrivelse.

Monter nettverksfilsystemet med mount-kommandoen

Et eksempel på bruk av mount-kommandoen er presentert i innlegget. Her er et eksempel på en mount-kommando 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 on / archivs / archiv-small type nfs (rw, addr = 10.0.0.6) archiv: / archiv-big on / 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 / arkiver / arkiv-liten med standardalternativer (dvs. les og skriv). Selv om mount kommando i de siste distribusjonene vet den hvordan den skal forstå hvilken type filsystem som brukes uten å spesifisere typen, spesifiser fortsatt parameteren -t nfsønskelig. Den andre kommandoen monterer den eksporterte katalogen / arkiv-stor på server arkiv til lokal katalog / arkiver / arkiv-stort med skrivebeskyttet alternativ ( ro). Monteringskommando uten parametere viser den tydelig monteringsresultatet for oss. 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 for eldre servere som ikke støtter NFS-låsing.
  • mounthost = navn- Vertsnavnet som NFS mount daemon kjører på - mountd.
  • mountport = n - Porten som brukes av mountd-demonen.
  • port = n- port som brukes til å koble til NFS-serveren (som standard 2049 hvis rpc.nfsd-demonen ikke er registrert på RPC-serveren). Hvis n = 0 (standard), vil NFS spørre portkartet på serveren for å bestemme porten.
  • rstørrelse = n(les blokkstørrelse) - Antall byte lest på en gang fra NFS-serveren. Standard - 4096.
  • wsize = n(skriveblokkstørrelse) - Antall byte skrevet på en gang til NFS-serveren. Standard - 4096.
  • tcp eller utp- For å montere NFS, bruk henholdsvis TCP- eller UDP-protokollen.
  • bg- Hvis du mister tilgangen til serveren, prøv på nytt i bakgrunnen for ikke å blokkere systemoppstartsprosessen.
  • fg- Hvis du mister tilgangen til serveren, prøv på nytt i prioritetsmodus. Dette alternativet kan blokkere oppstartsprosessen ved å gjenta monteringsforsøk. Av denne grunn brukes fg-parameteren primært til feilsøkingsformål.

Alternativer som påvirker attributtbufring når NFS monteres

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å unødvendig sløsing med ressurser kan du cache gitte attributter... Kjernen bruker endringstiden til en fil for å finne ut om hurtigbufferen er utdatert ved å sammenligne endringstiden i hurtigbufferen med endringstiden til selve filen. Attributtbufferen oppdateres med jevne mellomrom i henhold til de angitte parameterne:

  • ac (noac) (attributtbuffer- attributt caching) - Aktiverer attributt caching (standard). Selv om noac-alternativet bremser serveren, unngår det utløp av attributter når flere klienter aktivt skriver informasjon til det delte hierarkiet.
  • acdirmax = n (attributt cache katalogfil maksimum- attributt caching maksimum for en katalogfil) - Maksimalt antall sekunder som NFS venter før oppdatering av katalogattributter (standard 60 sekunder)
  • acdirmin = n (attributt cache katalogfil minimum- attributtbufring i det minste for en katalogfil) - Minimum antall sekunder som NFS venter før oppdatering av katalogattributter (som standard 30 sekunder)
  • acregmax = n (attributt cache vanlig fil maksimum- attributtbufring på det meste for vanlig fil) - Maksimalt antall sekunder som NFS vil vente før oppdatering av attributtene til en vanlig fil (standard 60 sekunder)
  • acregmin = n (attributt cache vanlig fil minimum- attributtbufring i det minste for en vanlig fil) - Minimum antall sekunder som NFS venter før oppdatering av attributtene til en vanlig fil (3 sekunder som standard)
  • acttimeo = n (tidsavbrudd for attributtbuffer- tidsavbrudd for attributtbufring) - Overstyrer verdiene for alle alternativene ovenfor. Hvis acttimeo ikke er spesifisert, er verdiene ovenfor satt til standardverdiene.

NFS feilhåndteringsalternativer

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

  • fg (bg) (forgrunnen- forgrunnen, bakgrunn- bakgrunn) - Prøv å montere en mislykket NFS i forgrunnen / bakgrunnen.
  • hard myk)- viser meldingen "serveren svarer ikke" til konsollen når tidsavbruddet er nådd og fortsetter monteringsforsøkene. Med det gitte alternativet myk- hvis timeout oppstår, informerer programmet som kalte operasjonen om en I/O-feil. (det myke alternativet anbefales ikke å bruke)
  • nointr (intr) (ingen avbrudd- ikke avbryt) - Hindrer signaler fra å forstyrre filoperasjoner i det hardmonterte kataloghierarkiet når en lang tidsavbrudd er nådd. intr- muliggjør avbrudd.
  • retrans = n (gjenoverføringsverdi- retransmission verdi) - Etter n små timeouts genererer NFS en stor timeout (3 som standard). En lang tidsavbrudd stopper driften eller viser en "server svarer ikke"-melding til konsollen, avhengig av det harde/myke alternativet som er spesifisert.
  • prøv på nytt = n (prøve på nytt verdi- Prøv på nytt verdi) - Antall minutter NFS-tjenesten prøver å montere operasjoner på nytt før de gir opp (10 000 som standard).
  • timeo = n (tidsavbruddsverdi- timeout-verdi) - Antall tideler av et sekund å vente NFS tjeneste før reoverføring i tilfelle RPC eller lav timeout (standard 7). Denne verdien øker med hver tidsavbrudd, opptil maksimalt 60 sekunder, eller til en lang tidsavbrudd oppstår. På et travelt nettverk, en treg server, eller når en forespørsel går gjennom flere rutere eller gatewayer, kan økning av denne verdien forbedre ytelsen.

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

Finn den optimale tiden for en viss verdi 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 = 69 5 ttl = 2 5 ttl = 2 5 ttl s . 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 ms x 3270 ms = 3270 ms x 1. .domain.local (10.0.0.6): icmp_req = 5 ttl = 64 tid = 1,08 ms ^ C --- archiv.DOMAIN.local ping-statistikk --- 5 pakker overført, 5 mottatt, 0 % pakketap, tid 4006ms rtt min / gjennomsnitt / maks / mdev = 0,931 / 1,002 / 1,083 / 0,061 ms

Som du kan se, når du sender en pakke på 32768 (32Kb) størrelse, flyter reisetiden fra klienten til serveren og tilbake i området 1 millisekund. Hvis den gitte tiden vil gå av skala om 200 ms, så 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 en sterk nettverksbelastning.

Starte NFS og konfigurere brannmur

Notatet er kopiert fra bloggen http://bog.pp.ru/work/NFS.html, som tusen takk til ham !!!

Start NFS-server, monter, lås, kvote og status med "riktige" porter (for brannmur)

  • det anbefales å først avmontere alle ressurser på klienter
  • stopp og la rpcidmapd starte hvis du ikke planlegger å bruke NFSv4: chkconfig --nivå 345 rpcidmapd off service rpcidmapd stop
  • om nødvendig, aktiver starten av portmap-, nfs- og nfslock-tjenestene: chkconfig --levels 345 portmap / rpcbind på chkconfig --levels 345 nfs på chkconfig --levels 345 nfslock på
  • om nødvendig, stopp nfslock og nfs tjenester, start portmap / rpcbind, last ut moduler tjeneste nfslock stopp tjeneste nfs stopp tjeneste portmap start # tjeneste rpcbind start umount / proc / fs / nfsd tjeneste rpcidmapd stopp rmmod nfsd tjeneste autofs må stoppe # et sted senere kjør 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, legg til linjen RQUOTAD_PORT = 4003 til / etc / sysconfig / nfs
  • for å konfigurere rpc.rquota er det nødvendig for eldre versjoner (du må likevel ha quota 3.08 eller nyere pakken) legg til rquotad 4003 / tcp rquotad 4003 / udp til / etc / services
  • vil sjekke tilstrekkeligheten av / etc / eksporter
  • start tjenestene rpc.nfsd, mountd og rpc.rquota (samtidig startes rpcsvcgssd og rpc.idmapd, hvis du ikke har glemt å fjerne dem) service nfsd start eller i nye versjoner service nfs start
  • for låseserveren for nye systemer legg til linjene LOCKD_TCPPORT = 4001 LOCKD_UDPPORT = 4001 til / etc / sysconfig / nfs
  • for en låseserver for eldre systemer legg direkte til /etc/modprobe [.conf]: options lockd nlm_udpport = 4001 nlm_tcpport = 4001
  • bind statusserveren rpc.statd til port 4000 (for gamle systemer, kjør rpc.statd med -p 4000-svitsjen i /etc/init.d/nfslock) STATD_PORT = 4000
  • start tjenester låst og rpc.statd tjeneste nfslock start
  • sørg for at alle porter er riktig bundet med "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 tjenestene på klientene på nytt automatisk montering(am-utils, autofs)

Eksempel på NFS-server- og klientkonfigurasjon

Serverkonfigurasjon

Hvis du vil gjøre den partisjonerte NFS-katalogen åpen og skrivbar, kan du bruke alternativet all_squash i kombinasjon med alternativer anonuid og anongid... For å angi rettighetene for brukeren "ingen" i gruppen "ingen", kan du for eksempel gjøre følgende:

ARCHIV ~ # cat / etc / exports # Lese-/skrivetilgang for klient på 192.168.0.100, med rw-tilgang for bruker 99 med gid 99 / filer 192.168.0.100 (rw, sync, all_squash, anonuid = 99, anongid = 99) ) # Lese-/skrivetilgang for klient på 192.168.0.100, med rw-tilgang for bruker 99 med gid 99 / filer 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.

Hilsen, Mc.Sim!

NFS (Nettverksfilsystem)- en nettverksprotokoll for tilgang til filer og filsystemet til NFS-serveren, populær i Linux / UNIX OS-familien, samt ulike lagringssystemer. Microsoft, som ikke ønsket å ligge bak konkurrentene, introduserte grunnleggende NFS-serverfunksjonalitet tilbake i Windows Server 2003 R2. I påfølgende versjoner av serverplattformer Microsofts evner den innebygde NFS Windows-serveren utvidet, ny funksjonalitet og administrasjonsverktøy dukket opp. NFS-server i Windows Server 2012 er nok en milepæl i utviklingen av denne teknologien.

Hva er nytt for oss Microsoft-utviklere i dette produktet? Nye funksjoner i NFS Server i Windows Server 2012:

  1. NFS v4.1-støtte... Støtte for den nyeste versjonen av NFS 4.1 er en av hovedinnovasjonene i Windows Server 2012. Sammenlignet med NFS v3 gir denne protokollen økt sikkerhet, ytelse og interoperabilitet, full implementering av alle aspekter av RFC 5661.
  2. Ut av boksen ytelse. Ved å bruke den nye RPC-XDR-transportinfrastrukturen kan optimal NFS-serverytelse oppnås rett ut av esken uten behov for finjustering systemparametere. Optimal ytelse oppnås gjennom automatisk tuning av cache, sammenslåing av arbeidsprosesser og dynamisk bassengadministrasjon basert på deres belastning.
  3. Forenklet distribusjon og administrasjon... Dette faktum ble oppnådd på grunn av:
    • - 40+ PowerShell-cmdlets for å konfigurere NFS-server og administrere delte mapper
    • - et enkelt grafisk administrasjonsgrensesnitt som lar deg administrere både SMB- og NFS-andeler samtidig, samt filscreeningsinnstillinger, etc.
    • - fikse RPC-porten (port 2049) for enkel konfigurering av brannmurer
    • - ny leverandør WMI v2
    • - forenklet identifikasjon på grunn av en flat kartleggingsfil
  4. NFSv3-forbedringer... Ved å raskt sende failover-varsler til klienter av Network Status Monitor (NSM), håndterer eldre NFS-klienter failover raskere og bedre, noe som betyr mindre nedetid.

Så NFS-serveren i Windows Server 2012 har blitt kraftig forbedret når det gjelder enkel distribusjon, skalerbarhet, stabilitet, tilgjengelighet, pålitelighet, sikkerhet og kompatibilitet. Delte mapper kan nås samtidig via SMB og NFS, noe som betyr at Windows Server 2012 kan brukes som lagring i heterogene nettverk.

NFS-server i Windows Server 2012 kan installeres ved hjelp av GUI og Powershell. For å installere en NFS-server ved hjelp av et grafisk grensesnitt, åpne og kontroller komponenten i rollen Fil- og lagringstjenester Server for NFS.

Etter å ha fullført installasjonen av NFS-komponenten, må serveren startes på nytt.

Det er også enkelt å installere den samme rollen ved å bruke Powershell, bare kjør kommandoen:

Legg til Windows-funksjonen "FS-NFS-Service"

Konfigurere en delt NFS-mappe i Windows Server 2012

Deretter vil vi vise hvordan, ved å bruke rollen vi installerte, oppretter en NFS-andel ( delt mappe) på Windows server... Det er flere måter å opprette en NFS-deling på igjen: ved hjelp av det grafiske grensesnittet eller Powershell.

Opprett en NFS-andel ved å bruke Server Manager-konsollen

Åpne konsollen Server Manager, gå til delen Aksjehåndtering(er inne i rollen Fil- og lagringstjenester).
I kontekstmenyen starter du veiviseren for ny delt katalog - Ny del...

Velg type baller NFSDel -Rask

Deretter må du angi type autentisering NFS-klienter: kanskje bruke som Kerberos-autentisering og anonym.

Anta at forbrukeren av den opprettede NFS-ressursen vil være en ESXi-virtualiseringsserver, der det ikke er noen mulighet til å autentisere NFS-tilkoblinger (ESXi støtter ikke NFSv4). Derfor vil autentiseringstypen være Ingen serverautentisering, legger vi også merke til alternativene Aktiver ikke-tilordnet brukertilgang og Tillat utilordnet brukertilgang via UID / GID.

For å beskytte den opprettede NFS-andelen litt mot tredjepartstilgang, vil vi begrense tilgangen til NFS-ressursen med klientens IP-adresse.

Vert: 192.168.1.100
Språkkoding: BIG5
Del tillatelser: Les Skriv
Tillat root-tilgang: Ja

Deretter gjenstår det å sjekke at på NTFS-nivået har brukeren som den tilkoblede brukeren er tilordnet lese-/skrivetilgang (hvis du bestemmer deg for å bruke anonym tilgang, må du gi Everyone-brukeren fulle r/w-rettigheter på NTFS nivå).

Hvordan lage en NFS-andel ved hjelp av Powershell

La oss lage en ny NFS-andel:

New-NfsShare -Navn "NFS" -Path "d: \ shares \ nfr" -AllowRootAccess $ true -Tillatelse Leseskriving -Autentiseringssys

La oss gi tilgang til ballen for IP-adressen 192.168.1.100 og sette kodingen til BIG5 (muligheten til å se innholdet av NFS-baller for ESXi-klienten).

Grant-NfsSharePermission -Navn "NFS" -ClientName 192.168.1.100 -ClientType vert -LanguageEncoding BIG5

Den opprettede NFS-ballen kan for eksempel brukes som et NFS-datalager i et virtualiseringsmiljø, eller for å få tilgang til data fra andre Unix-lignende klienter. Hvordan montere en NFS-andel i Windows - klienter er beskrevet i artikkelen.



© Copyright 2017, https://qzoreteam.ru