Vinden Netwerk

bestandssystemen Een van de handigste functies die via het netwerk kunnen worden bereikt, is het delen van bestanden via een netwerkbestandssysteem. Meestal wordt een systeem genoemd Netwerkbestand

Systeem of NFS, ontwikkeld door Sun Corporation.

Wanneer u met een netwerkbestandssysteem werkt, worden alle bewerkingen op bestanden die op de lokale computer worden uitgevoerd, via het netwerk naar de externe machine overgebracht. Wanneer een netwerkbestandssysteem actief is, gaat het programma ervan uit dat alle bestanden op de externe computer zich bevinden op de computer waarop het draait. Het scheiden van informatie via een dergelijk systeem vereist dus geen wijzigingen in het programma.

Mail E-mail is het belangrijkste communicatiemiddel tussen computers. E-mails

opgeslagen in één bestand in een speciaal formaat. Voor het lezen en versturen van brieven worden speciale programma’s gebruikt. Elke gebruiker heeft een aparte mailbox, een bestand waarin informatie in een speciaal formaat wordt opgeslagen inkomende post

. Als er een brief op de computer binnenkomt, zoekt het postverwerkingsprogramma het mailboxbestand van de corresponderende gebruiker op en voegt daar de ontvangen brief toe. Als de mailbox van de gebruiker zich op een andere computer bevindt, wordt de brief naar deze computer doorgestuurd en daar verder verwerkt. Het mailsysteem bestaat uit veel verschillende programma's. Het bezorgen van brieven aan lokale of externe mailboxen wordt uitgevoerd door één programma (bijvoorbeeld sendmail of smail), terwijl het voor het regelmatig verzenden of bekijken van brieven wordt gebruikt groot aantal verschillende programma's (bijvoorbeeld Pine of Elm). Bestanden brievenbussen

meestal opgeslagen in de map /var/spool/mail.

Vragen

1. Wat is de NOS en wat is het doel ervan?

2. Welke netwerkfuncties voert een netwerkbesturingssysteem uit?

3. Uit welke onderdelen bestaat de NOS-structuur?

4. Wat is een redirector?

5. Hoe worden netwerkbesturingssystemen verdeeld op basis van toegangsrechten tot bronnen?

6. Hoe worden netwerkbesturingssystemen verdeeld volgens de schaal van netwerken?

7. Hoe zijn de eigenschappen van een netwerkbesturingssysteem afhankelijk van de schaal van netwerken?

8. Beschrijf het NetWare-netwerkbesturingssysteem van Novell.

10. Beschrijf het bestandssysteem van het NetWare-netwerkbesturingssysteem.

11. Welke protocolniveaus ondersteunt het netwerkbesturingssysteem? NetWare-systeem?

12. Maak een lijst van de functies van de IPX- en SPX-protocollen.

13. Beschrijf het Windows NT-netwerkbesturingssysteem.

14. Maak een lijst van de taken van het Windows NT-netwerkbesturingssysteem.

15. Uit welke elementen bestaat de structuur van het Windows NT-netwerkbesturingssysteem?

16. Beschrijf het bestandssysteem van het Windows NT-netwerkbesturingssysteem.

17. Welke beveiligingsprincipes worden gebruikt in het Windows NT-netwerkbesturingssysteem?

18. Noem de kenmerken van het Windows NT-netwerkbesturingssysteem vanuit het oogpunt van de implementatie van netwerktools.

19. Geef de eigenschappen van het Windows NT-netwerkbesturingssysteem een ​​naam.

20. Wat zijn de gebieden Windows gebruiken NT?

21. Beschrijf het UNIX-netwerkbesturingssysteem.

22. Maak een lijst van de functies van het UNIX-netwerkbesturingssysteem.

23. Karakteriseer het bestandssysteem van het UNIX-netwerkbesturingssysteem.

24. Welke beveiligingsprincipes worden door UNIX gebruikt?

25. Geef een overzicht van het Linux-netwerkbesturingssysteem.

Network File System (NFS) is een oplossing voor het delen van bestanden voor organisaties met gemengde Windows- en Unix/Linux-machineomgevingen. Met het NFS-bestandssysteem kunt u openen algemene toegang naar bestanden tussen gespecificeerde verschillende platforms terwijl het besturingssysteem actief is Windows-server 2012: NFS Services in Windows Server 2012 bevat de volgende functies en verbeteringen.

1. Zoeken in Actieve map. Je hebt de mogelijkheid om te solliciteren Windows actief Directory voor toegang tot bestanden. De Identity Management for Unix-schema-extensie voor Active Directory bevat Unix-gebruikers-ID (UID) en groeps-ID (GID)-velden. Hierdoor kunnen de Server voor NFS- en Client voor NFS-services accounttoewijzingen bekijken Windows-gebruikers op Unix rechtstreeks vanuit services domein Actief Directory (Active Directory Domain Services). Identity Management for Unix maakt het eenvoudiger om de toewijzing van Windows-gebruikersaccounts op Unix aan Active Directory Domain Services te beheren.

2. Verbeterde serverprestaties. Services voor NFS bevatten een bestandsfilterstuurprogramma dat de algehele latentie bij toegang tot bestanden op de server aanzienlijk vermindert.

3. Ondersteuning voor speciale Unix-apparaten. Services voor NFS ondersteunen speciale Unix-apparaten (mknod).

4. Uitgebreide Unix-ondersteuning. Services for NFS ondersteunt de volgende Unix-versies: Sun Microsystems Solaris versie 9, Red Hoed Linux versie 9, IBM AIX versie 5L 5.2 en Hewlett Packard HP-UX versie 11i, evenals vele moderne Linux-distributies.

Een van de meest voorkomende scenario's waarbij NFS nodig is, is het blootstellen van een op Unix gebaseerd ERP-systeem (Enterprise Resource Planning) aan Windows-gebruikers. In het ERP-systeem kunnen gebruikers rapporten maken en/of financiële gegevens exporteren naar Microsoft Excel voor verdere analyse. Dankzij het NFS-bestandssysteem zijn deze bestanden toegankelijk terwijl ze zich nog in de Windows-omgeving bevinden, waardoor de behoefte aan gespecialiseerde technische vaardigheden en de tijd die wordt besteed aan het exporteren van bestanden met behulp van een Unix-script en het vervolgens importeren in een specifieke Windows-toepassing worden verminderd.

Er kan zich ook een situatie voordoen waarin u een Unix-systeem heeft dat wordt gebruikt om bestanden op een soort Storage Area Network (SAN) op te slaan. Door NFS-services op een Windows Server 2012-machine uit te voeren, hebben gebruikers in een organisatie toegang tot de bestanden die daar zijn opgeslagen, zonder de overhead van Unix-scripting.

Voordat u NFS Services installeert, moet u eventuele eerdere geïnstalleerde componenten NFS, zoals de NFS-componenten die zijn meegeleverd met Services for Unix.

NFS Services-componenten

De volgende twee NFS-servicecomponenten zijn beschikbaar.

1. Server voor NFS(Server voor NFS). Normaal gesproken heeft een Unix-computer geen toegang tot bestanden op een Windows-computer. Een computer met Windows Server 2012 R2 en Servercomponent voor NFS, kan fungeren als bestandsserver voor Windows- en Unix-computers.

2. Client voor NFS(Cliënt voor NFS). Normaal gesproken heeft een Windows-computer geen toegang tot bestanden op een Unix-computer. Een computer met Windows Server 2012 R2 en de functie Client voor NFS heeft echter toegang tot bestanden die zijn opgeslagen op een Unix-gebaseerde NFS-server.

Server voor NFS installeren met PowerShell

Laten we eens kijken hoe we PowerShell kunnen gebruiken om de NFS-rol op een server te installeren en een NFS-bestandsshare te maken.

1. Openen Windows-venster PowerShell via de taakbalk als beheerdersaccount.

2. Voer de volgende opdrachten in om de NFS-rol op de server te installeren:

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

3. Voer de volgende opdracht in om een ​​nieuwe NFS-bestandsshare te maken:

PS C:\> Nieuw-NfsShare -Naam "Test" -Pad "C:\Shares\Test"

4. Voer de volgende opdracht uit om alle nieuwe NFS-specifieke PowerShell-cmdlets te bekijken die beschikbaar zijn in Windows Server 2012 R2:

PS C:\>Get-Command -Module NFS

5. Klik met de rechtermuisknop op de map C:\Shares\Test, selecteer “eigenschappen” en ga vervolgens naar het tabblad NFS Sharing. Klik op de knop NFS delen beheren. NFS-toegang), in het dialoogvenster dat verschijnt, kunt u de toegangsrechten voor mappen beheren, anonieme toegang toestaan ​​en instellingen voor bestandscodering configureren. U kunt een map delen via NFS met behulp van het dialoogvenster NFS Advanced Sharing zonder PowerShell te gebruiken.

Standaardresoluties instellen

Nu zullen we enkele firewallpoorten moeten openen om NFS te laten functioneren. De poorten die nodig zijn voor de normale werking van NFS-services worden weergegeven in de onderstaande tabel.

Het belangrijkste onderdeel van elk gedistribueerd systeem is het bestandssysteem, dat in dit geval ook gedistribueerd is. Net als bij gecentraliseerde systemen is de functie van het bestandssysteem het opslaan van programma's en gegevens en het bieden van toegang aan clients. Een gedistribueerd bestandssysteem wordt onderhouden door een of meer computers die bestanden opslaan. Bestandsservers bevatten doorgaans hiërarchische bestandssystemen, elk met een hoofdmap en mappen op een lager niveau. In veel netwerkbestandssystemen kan een clientcomputer deze bestandssystemen aan de lokale bestandssystemen koppelen en koppelen, waardoor de gebruiker gemakkelijk toegang krijgt tot externe mappen en bestanden. In dit geval verplaatsen de gegevens van de gekoppelde bestanden zich niet fysiek ergens heen, maar blijven ze op de servers staan.

Vanuit softwareoogpunt is een gedistribueerd bestandssysteem (FS) een netwerkservice die serverprogramma's en clientprogramma's omvat die met elkaar communiceren via een specifiek protocol. De bestandsservice in gedistribueerde bestandssystemen bestaat uit twee functioneel verschillende delen: de bestandsservice zelf en de directoryservice van het bestandssysteem. De eerste gaat over operaties op aparte bestanden, zoals lezen, schrijven of toevoegen (wijzigen), en de tweede - met het maken en beheren van mappen, het toevoegen en verwijderen van bestanden uit mappen, enz.

In een goed georganiseerd gedistribueerd systeem weten gebruikers niet hoe het bestandssysteem is geïmplementeerd (hoeveel bestandsservers, waar ze zich bevinden, hoe ze werken). Idealiter zou een netwerkbestandssysteem er voor een gebruiker op zijn computer uit moeten zien als het zijne, dat wil zeggen volledig transparant moeten zijn. In werkelijkheid voldoen netwerkbestandssystemen echter nog niet volledig aan dit ideaal.

Een netwerkbestandssysteem bevat doorgaans de volgende elementen:

Lokale bestandssystemen;

Lokale bestandssysteeminterfaces;

Netwerkbestandssysteemservers;

Netwerkbestandssysteemclients;

Netwerkbestandssysteeminterfaces;

Netwerkbestandssysteem client-serverprotocol.

Netwerk FS-clients zijn programma's die worden uitgevoerd op talloze computers die op het netwerk zijn aangesloten. Deze programma's dienen applicatieverzoeken uit om toegang te krijgen tot bestanden die zijn opgeslagen op externe computers. De netwerk-FS-client verzendt verzoeken via het netwerk naar een andere softwarecomponent: de netwerk-FS-server die op een externe computer draait. De server kan, nadat hij een verzoek heeft ontvangen, dit zelf uitvoeren of, wat gebruikelijker is, het verzoek ter verwerking doorgeven aan het lokale bestandssysteem. Na ontvangst van een antwoord van de lokale FS verzendt de server dit via het netwerk__

De netwerk-FS-client en -server communiceren met elkaar via het netwerk met behulp van een specifiek protocol. Als de lokale en netwerk-FS-interfaces samenvallen, kan dit protocol vrij eenvoudig zijn. Eén mechanisme dat voor dit doel wordt gebruikt, kan het RPC-mechanisme zijn.

In Windows-besturingssystemen is de belangrijkste netwerkbestandsservice het SMB-protocol (Server Message Block), dat gezamenlijk is ontwikkeld door Microsoft, Intel en IBM. De nieuwste uitgebreide versies heten Common Internet File System, CIFS.

Het protocol werkt door toepassingsniveau OSI-modellen. SMB gebruikt verschillende transportprotocollen om zijn berichten over het netwerk te verzenden. Historisch gezien was het eerste protocol NetBIOS (en de latere versie NetBEUI), maar nu kunnen SMB-berichten worden verzonden met behulp van andere protocollen (TCP/UDP en IPX).

SMB behoort tot de klasse van verbindingsgerichte protocollen. Het werk begint ermee dat de client een speciaal bericht naar de server verzendt met het verzoek om verbinding. Als de server klaar is om een ​​verbinding tot stand te brengen, reageert deze met een bevestigingsbericht. Zodra de verbinding tot stand is gebracht, kan de client contact opnemen met de server door deze opdrachten te sturen om bestanden en mappen in SMB-berichten te manipuleren. Tijdens de werking kunnen zich een aantal situaties voordoen die de effectiviteit van externe bestandstoegang kunnen beïnvloeden:

1. Fout in de computer waarop de netwerkbestandssysteemserver draait tijdens een communicatiesessie met de client. Het lokale bestandssysteem onthoudt de status van opeenvolgende bewerkingen die de toepassing op hetzelfde bestand uitvoert door een interne tabel bij te houden bestanden openen(systeemaanroepen openen, lezen, schrijven veranderen de status van deze tabel). Wanneer het systeem crasht, gaat de tabel met geopende bestanden verloren nadat de servercomputer opnieuw is opgestart. In dit geval kan de toepassing die op de clientcomputer wordt uitgevoerd, niet blijven werken met bestanden die vóór de crash open waren.

Eén oplossing voor het probleem is gebaseerd op het overbrengen van de functie van het onderhouden en opslaan van een tabel met geopende bestanden van de server naar de client. Met deze organisatie wordt het client-server-protocol vereenvoudigd, omdat het opnieuw opstarten van de server alleen maar tot een onderbreking van de service leidt.

2. Grote servicevertragingen als gevolg van netwerkverzoeken en het opnieuw opstarten van de bestandsserver wanneer een groot aantal clients verbinding maakt. Een oplossing voor het probleem kan zijn om bestanden (gedeeltelijk of geheel) aan de clientzijde in de cache op te slaan. In dit geval moet het protocol echter rekening houden met de mogelijkheid van de vorming van meerdere kopieën van hetzelfde bestand, die onafhankelijk kunnen worden gewijzigd door verschillende gebruikers, dat wil zeggen dat het protocol consistentie moet garanderen tussen kopieën van bestanden die beschikbaar zijn op verschillende computers.

3. Gegevensverlies en vernietiging van de integriteit van het bestandssysteem tijdens storingen en storingen van computers die de rol van bestandsservers spelen. Om de fouttolerantie van een netwerk-FS te vergroten, kunt u meerdere kopieën van elk bestand (of de gehele FS) op verschillende servers opslaan. Dergelijke kopieën van een bestand worden replica's genoemd.

Bestandsreplicatie verbetert niet alleen de fouttolerantie, maar lost ook het probleem van overbelasting van bestandsservers op door bestandsaanvragen over meerdere servers te verdelen, waardoor de prestaties van het bestandssysteem worden verbeterd.

4. Authenticatie wordt uitgevoerd op de ene computer, bijvoorbeeld op de client, en autorisatie, dat wil zeggen het controleren van toegangsrechten tot mappen of bestanden, wordt uitgevoerd op een andere computer, die als bestandsserver fungeert. Dit algemene probleem voor alle netwerkdiensten moet worden opgelost door het client-serverprotocol voor bestandsservices.

De genoemde problemen worden uitgebreid opgelost door een dienst te creëren voor gecentraliseerde authenticatie, replicatie, caching, enz. aanvullende diensten worden weerspiegeld in het protocol voor interactie tussen clients en servers, waardoor verschillende protocollen van dit type ontstaan ​​die een of andere reeks extra functies ondersteunen. Daarom kunnen er voor dezelfde lokale FS verschillende netwerk-FS-protocollen zijn (Fig. 5.30). Tegenwoordig is het NTFS-bestandssysteem dus toegankelijk via SMB, NCP (NetWare Control Protocol) en NFS (Network File System - netwerkbestandssysteemprotocol van Sun Microsystems, gebruikt in verschillende versies van het UNIX-besturingssysteem).

Aan de andere kant kan met hetzelfde protocol externe toegang tot lokale FS worden geïmplementeerd verschillende soorten. Het SMB-protocol wordt bijvoorbeeld gebruikt om niet alleen toegang te krijgen tot FAT-bestandssystemen, maar ook tot NTFS- en HPFS-bestandssystemen (Fig. 5.31). Deze bestandssystemen kunnen zich op verschillende of op dezelfde computer bevinden.__

Testvragen voor hoofdstuk 5

1. Welke voordelen hebben netwerken ten opzichte van afzonderlijk gebruik van computers?

2. Zijn de fysieke en logische netwerktopologieën altijd hetzelfde?

3. Hoe worden netwerken geclassificeerd op basis van de omvang van het dekkingsgebied?

4. Welke computer kan als server op het netwerk fungeren?

5. Wat is een bestandsserver en printserver?

6. Welke functies vervullen registratieservers?

7. Welke functies vervullen servers voor externe toegang?

8. Wat is een proxyserver?

9. Maak een lijst van mogelijke clients van het computernetwerk.

10. Wat zijn ‘thick’ en ‘thin’ clients in een computernetwerk?

11. Hoe versta je de term ‘segmentatie’ van een netwerk?

12. Wat is een MAC-adres?

13. Waarin verschilt een gedistribueerd besturingssysteem van een via een netwerk verbonden besturingssysteem? Bestaan ​​er tegenwoordig werkelijk gedistribueerde netwerksystemen?

14. Noem de belangrijkste componenten van een netwerkbesturingssysteem. Wat is een netwerkdienst? Welke netwerkdiensten kunt u noemen?

15. Sommige netwerkdiensten zijn niet gericht op de gebruiker, maar op de beheerder. Welke diensten zijn dit?

16. Wat waren de eerste netwerkbesturingssystemen? Welke benaderingen voor het creëren van netwerkbesturingssystemen worden momenteel gebruikt?

17. Noem de karakteristieke kenmerken van peer-to-peer-netwerken. Wat is het belangrijkste kenmerk van een multi-peer netwerk?

18. Wat is een server-besturingssysteem? Wat zijn ze? Hoe verschilt een server-besturingssysteem van een client-besturingssysteem?

19. Hoeveel varianten van tweeledige schema's worden er gebruikt voor gedistribueerde applicatieverwerking?

20. Wat is er goed aan applicatieverwerking op twee niveaus als de server en de client samenwerken?

21. Zijn er voordelen verbonden aan het drieledige systeem voor de verwerking van aanvragen, welke zijn dat dan?

22. Hoe kunnen processen samenwerken in gedistribueerde systemen?

23. Wat zijn de belangrijkste primitieven die worden gebruikt in het netwerk-OS-transportsysteem?

24. Hoe is de synchronisatie van processen op het netwerk georganiseerd?

25. Wat wordt bedoeld met externe procedureaanroepen?

Konstantin Pyanzin

Belangrijkste kenmerken van het NFS-bestandssysteem op het UNIX-platform.

Geluk is wanneer onze verlangens samenvallen met de capaciteiten van andere mensen.

"Vremechko"

Netwerkbestandssystemen hebben een belangrijke rol gespeeld, spelen en zullen dat blijven doen in de informatie-infrastructuur. Ondanks de groeiende populariteit van applicatieservers blijft de bestandsservice een universeel middel om collectieve toegang tot informatie te organiseren. Bovendien fungeren veel applicatieservers ook als bestandsservers.

Het UNIX-besturingssysteem beleeft momenteel een soort renaissance en heeft een groot deel van deze toenemende belangstelling te danken aan het vrij verkrijgbare Linux-besturingssysteem. Desktopcomputers gebruiken echter verschillende Windows-opties In de eerste plaats Windows 9x en Windows NT/2000, hoewel ook hier vrij verspreide varianten van UNIX geleidelijk aan burgerschap winnen.

Voor veel organisaties is het hosten van een netwerkbestandsservice op UNIX-computers een zeer aantrekkelijke oplossing, op voorwaarde dat de service dat wel heeft voldoende prestaties en betrouwbaarheid. Gezien de talrijke verschillen in UNIX- en Windows-bestandssystemen, voornamelijk in bestandsnaamgevingsschema's, toegangsrechten, vergrendelingen en systeemoproepen Bij de toegang tot bestanden is het garanderen van toegangtransparantie in een heterogene UNIX/Windows-omgeving van bijzonder belang. Bovendien worden UNIX-bestandsservers vaak geïnstalleerd als aanvulling op bestaande Windows NT- en NetWare-servers.

Voor het UNIX-besturingssysteem zijn er implementaties van alle min of meer populaire netwerkbestandssystemen, inclusief de systemen die worden gebruikt in Microsoft (SMB), NetWare (NCP) en Macintosh (AFP) netwerken. Natuurlijk hebben UNIX-netwerken hun eigen protocollen, met name NFS en DFS. Houd er rekening mee dat elke UNIX-server tegelijkertijd NFS- en SMB-services kan bieden (evenals NCP en AFP) en zo extra flexibiliteit kan bieden bij het creëren van een netwerkinfrastructuur.

Ondanks de verscheidenheid aan UNIX-netwerkbestandssystemen zijn de onbetwiste leiders NFS (Network File System, letterlijke vertaling - netwerkbestandssysteem) en SMB (Service Message Block). Dit artikel bespreekt de mogelijkheden van NFS. Tegelijkertijd zijn we van plan om in een van de komende uitgaven stil te staan ​​bij de kenmerken van het MKB-werk UNIX-platform en in de eerste plaats het Samba-product, dat zich goed heeft bewezen op UNIX/Windows-netwerken.

NFS-VERSIES

De eerste implementatie van het NFS-netwerkbestandssysteem werd in 1985 door Sun Microsystems ontwikkeld. Sindsdien is NFS wijdverspreid in de UNIX-wereld, met tientallen miljoenen installaties. Naast UNIX heeft het NFS-systeem als serverplatform toepassing gevonden in besturingssystemen VMS, MVS en zelfs Windows.

NFS is het oorspronkelijke bestandssysteem voor UNIX en volgt als geen ander de logica van UNIX-bestandsbewerkingen. Dit is van toepassing op de bestandsnaamruimte en machtigingen. Bovendien is NFS-ondersteuning standaard ingebouwd in de kernel van alle populaire versies van UNIX-achtige besturingssystemen.

Momenteel wordt NFS vertegenwoordigd door de tweede en derde versie (de eerste versie van NFS is nooit op de markt verschenen). Ondanks een aantal beperkingen is NFS v2 erg populair; het maakt deel uit van de vrij verspreide UNIX (in het bijzonder Linux), evenals van enkele commerciële UNIX.

De derde versie van NFS werd halverwege de jaren negentig ontwikkeld door gezamenlijke inspanningen van Sun, IBM, Digital en andere bedrijven om de prestaties, de beveiliging en het beheergemak van het netwerkbestandssysteem te verbeteren. NFS v3 is achterwaarts compatibel met de vorige NFS-specificatie, d.w.z. NFS-server v3 kan niet alleen NFS v3-clients bedienen, maar ook NFS v2-clients.

Ondanks zijn vrij lange aanwezigheid op de markt, is NFS v3 nog steeds inferieur aan NFS v2 wat betreft het aantal installaties. Op basis van deze overwegingen zullen we ons eerst concentreren op de belangrijkste kenmerken van NFS v2, en vervolgens kennis maken met de innovaties in de derde versie van NFS.

Houd er rekening mee dat specifieke implementaties van dezelfde versie van NFS enigszins van elkaar kunnen verschillen. De verschillen hebben voornamelijk betrekking op de samenstelling van de demonen, hun namen, locatie en titel configuratiebestanden NFS. Bovendien zijn NFS-implementaties afhankelijk van de mogelijkheden en kenmerken van UNIX zelf. NFS v2 ondersteunt bijvoorbeeld ACL's, maar alleen op varianten van UNIX waarbij dergelijke ondersteuning in de kernel is ingebouwd. Daarom, wanneer NFS-beschrijving we zullen het meest algemene geval bekijken.

NFS V2-PROTOCOLLEN

Figuur 1 toont het NFS v2-netwerkmodel volgens de referentie OSI-model. In tegenstelling tot de meeste TCP/IP-netwerkdiensten maakt NFS expliciet gebruik van presentatie- en sessieprotocollen. NFS werkt op basis van het concept van remote procedure calls (RPC). Volgens dit concept, bij toegang externe bron(bijvoorbeeld naar een bestand), voert een programma op de lokale computer een normale systeemaanroep uit (laten we zeggen een aanroep naar de functie voor het openen van bestanden), maar in feite wordt de procedure op afstand uitgevoerd - op de bronserver. In dit geval kan het gebruikersproces niet bepalen of de oproep lokaal of op afstand wordt gedaan. Nadat is vastgesteld dat het proces toegang krijgt tot een bron op een externe computer die als server fungeert, verpakt de kernel of een speciale daemon van het systeem de argumenten van de procedure samen met de identificatie ervan in een netwerkpakket, opent een communicatiesessie met de server en stuurt het ernaar door. dit pakket. De server pakt het ontvangen pakket uit, bepaalt de gevraagde procedure en argumenten, en voert vervolgens de procedure uit. Vervolgens stuurt de server de procedureretourcode naar de client, die deze doorgeeft aan het gebruikersproces. RPC voldoet dus volledig aan de sessielaag van het OSI-model.

Er rijst een terechte vraag: waarom netwerkmodel Heeft NFS een speciaal presentatielaagprotocol nodig? Het punt is dat Sun wijselijk vertrouwde op het gebruik van NFS in heterogene netwerken, waar computers verschillende systeemarchitecturen hebben, inclusief een verschillende bytevolgorde in een machinewoord, verschillende drijvende-kommarepresentaties, incompatibele grenzen voor structuuruitlijning, enz. Omdat het RPC-protocol Bij het verzenden van procedureargumenten, dat wil zeggen gestructureerde gegevens, is de aanwezigheid van een protocol op presentatieniveau een dringende behoefte in een heterogene omgeving. Dit is het externe datarepresentatieprotocol (eXternal Data Representation, XDR). Het beschrijft de zogenaamde canonieke vorm van datarepresentatie, die onafhankelijk is van de processorsysteemarchitectuur. Bij het verzenden van RPC-pakketten vertaalt de client lokale gegevens in canonieke vorm, en de server doet de omgekeerde bewerking. Dat moet in gedachten worden gehouden canonieke vorm XDR komt overeen met de gegevensrepresentatie die is aangenomen voor de SPARC- en Motorola-processorfamilies. Bij servers die een vergelijkbare vorm van gegevenspresentatie implementeren, kan men hierdoor een (hoewel hoogstwaarschijnlijk microscopisch klein) prestatievoordeel behalen ten opzichte van concurrenten in geval van intensieve toegang tot de bestandsserver.

In NFS v2 als transportprotocol UDP is geselecteerd. De ontwikkelaars verklaren dit door het feit dat de RPC-sessie een korte periode duurt. Bovendien is elk RPC-pakket, vanuit het oogpunt van het uitvoeren van procedures op afstand, op zichzelf staand, dat wil zeggen dat elk pakket volledige informatie bevat over wat er op de server moet worden uitgevoerd, of over de resultaten van de procedure. RPC-services zijn doorgaans verbindingsloos, wat betekent dat de server geen informatie opslaat over welke clientverzoeken in het verleden zijn verwerkt, zoals waar in een bestand de client voor het laatst gegevens heeft gelezen. Voor een netwerkbestandssysteem is dit een duidelijk voordeel in termen van betrouwbaarheid, aangezien de client de bestandsbewerkingen onmiddellijk kan voortzetten nadat de server opnieuw is opgestart. Maar dit schema is beladen met problemen bij het schrijven en vergrendelen van bestanden, en om deze te omzeilen, werden NFS-ontwikkelaars gedwongen verschillende oplossingen te gebruiken (het gebruik van UDP geeft aanleiding tot een andere reeks specifieke problemen, maar we zullen daar later op ingaan).

Een belangrijk verschil tussen de RPC-services in NFS en andere netwerkserverservices is dat ze geen gebruik maken van de inetd super daemon. Gewone netwerkdiensten, zoals telnet of rlogin, worden doorgaans niet als daemon gestart bij het opstarten van het systeem, hoewel dit niet verboden is. Meestal gebruiken ze de zogenaamde superdaemon inetd, die "luistert" naar softwarepoorten TCP-protocollen en UDP. Services worden gespecificeerd in het configuratiebestand van de superdaemon (meestal /etc/inetd.conf). Wanneer een verzoek van de client op de softwarepoort wordt ontvangen, start inetd de corresponderende netwerkservice (bijvoorbeeld in.rlogind) als een onderliggend proces, dat het verzoek verwerkt.

RPC-services maken geen gebruik van de inetd-superdaemon omdat, zoals opgemerkt, een RPC-sessie slechts een zeer korte tijd duurt, in feite slechts de duur van een enkel verzoek. Dat wil zeggen dat inetd voor elk verzoek gedwongen zou worden een nieuw onderliggend proces van de RPC-service te lanceren, wat erg duur is voor UNIX. Om vergelijkbare redenen kan een RPC-proces geen nieuwe processen voortbrengen en kan het niet meerdere verzoeken tegelijk verwerken. Om de prestaties te verbeteren, worden RPC-services daarom uitgevoerd als meerdere daemon-instances die tegelijkertijd worden uitgevoerd. Het aantal instances van een bepaalde daemon houdt echter niet direct verband met het aantal clients. Zelfs één daemon kan veel clients bedienen, maar kan tegelijkertijd één verzoek verwerken, de rest wordt in een wachtrij geplaatst.

Nog één ding belangrijk verschil Het verschil tussen RPC-services en reguliere netwerkservices is dat ze geen vooraf gedefinieerde software-UDP-poorten gebruiken. In plaats daarvan wordt een zogenaamd port mapping-systeem gebruikt. Om dit te ondersteunen wordt een speciale portmap-daemon geïnitialiseerd wanneer het systeem opstart. Als onderdeel van het poortvertaalsysteem wordt aan elke RPC-service een programmanummer, versienummer, procedurenummer en protocol (UDP of TCP) toegewezen. Het programmanummer identificeert op unieke wijze een specifieke RPC-service. De relatie tussen RPC-servicenamen en programmanummers kan worden getraceerd op basis van de inhoud van het bestand /etc/rpc. Elk RPC-programma ondersteunt vele procedures, die worden geïdentificeerd door hun procedurenummers. De procedurenummers zijn te vinden in de bijbehorende headerbestanden: voor de NFS-service zijn ze bijvoorbeeld gespecificeerd in het bestand /usr/include/nfs/nfs.h.

In het bijzonder heeft de NFS-service programmanummer 100003 en omvat procedures zoals "open bestand", "leesblok", "maak bestand", enz. Bij het aanroepen van procedures op afstand wordt het serviceprogrammanummer doorgegeven samen met de procedureargumenten in de RPC-pakket, procedurenummer en versienummer. Het versienummer wordt gebruikt om de mogelijkheden van de service te identificeren. Feit is dat ontwikkelaars de NFS-service voortdurend verbeteren en dat elke nieuwe versie volledig achterwaarts compatibel is met de vorige.

Het werkingsprincipe van de portmap-vertaler is vrij eenvoudig. Wanneer een RPC-service wordt geïnitialiseerd (in het bijzonder op het moment dat het besturingssysteem opstart), wordt deze geregistreerd met behulp van de portmap-daemon. Wanneer de RPC-service op een server wordt gestart, zoekt hij naar een onbezette softwarepoort, reserveert deze voor zichzelf en rapporteert het poortnummer aan de portmap-daemon. Om met de server te kunnen communiceren, moet de RPC-client eerst contact opnemen met de poortmap van de server en vragen welke softwarepoort wordt bezet door een bepaalde RPC-service op de server. Alleen dan kan de klant rechtstreeks contact opnemen met de dienst. In sommige gevallen communiceert de client indirect met de gewenste service, dat wil zeggen dat hij eerst contact opneemt met de portmap-daemon, die namens de client de RPC-service aanvraagt. In tegenstelling tot RPC-services is de portmap-poortvertaler altijd gebonden aan een vooraf gedefinieerde poort 111, zodat de cliënt op de standaardmanier met de portmap communiceert.

SAMENSTELLING VAN NFS V2

In het algemeen bevat de NFS-server, naast portmap, de daemons rpc.mountd, nfsd, rpc.lockd en rpc.statd. Op een NFS-clientmachine die op een UNIX-platform draait, moeten de daemons biod (optioneel), rpc.lockd en rpc.statd actief zijn.

Zoals eerder vermeld ondersteunt UNIX NFS op kernelniveau, dus niet alle daemons zijn nodig, maar ze kunnen de prestaties van bestandsbewerkingen aanzienlijk verbeteren en schrijfvergrendeling van bestanden mogelijk maken.

De daemon rpc.mountd verwerkt clientverzoeken om bestandssystemen te mounten. De mount-service wordt geïmplementeerd als een afzonderlijke daemon, aangezien het mount-protocol dat niet is onderdeel van NFS. Dit komt omdat de mount-bewerking nauw verbonden is met de syntaxis van bestandsnamen, en de principes voor bestandsnaamgeving verschillen tussen UNIX en bijvoorbeeld VMS.

De nfsd-daemon accepteert en onderhoudt NFS RPC-verzoeken. Om de prestaties te verbeteren, worden doorgaans meerdere exemplaren van nfsd op de server uitgevoerd.

De daemon rpc.lockd, die zowel op de client als op de server draait, is ontworpen om bestanden te vergrendelen, terwijl de daemon rpc.statd (die ook op de server en client draait) statistieken bijhoudt over vergrendelingen voor het geval ze automatisch moeten worden hersteld als de NFS-service loopt vast.

De biod-daemon die op de client draait, kan vooruitlezen en lazy-write-bewerkingen uitvoeren, wat de prestaties aanzienlijk verbetert. De aanwezigheid van biod is echter niet vereist om te kunnen werken. Om de prestaties verder te verbeteren, kunnen meerdere biod-daemons op de clientmachine worden geladen.

Een andere daemon die op de server draait, is verantwoordelijk voor authenticatie- en afdrukservices voor DOS/Windows-clients; deze heet pcnfsd, op andere in.pcnfsd.

Bovendien bevat het NFS-pakket verschillende systeemhulpprogramma's en diagnostische programma's (showmount, rpcinfo, exportfs, nfsstat).

EXPORTREGELS

De bestandssystemen en mappen die clients op afstand kunnen aankoppelen op de NFS-server moeten expliciet worden gespecificeerd. Deze procedure wordt in NFS het "exporteren" van bronnen genoemd. Tegelijkertijd zendt een NFS-server, in tegenstelling tot bijvoorbeeld een SMB-server, geen lijst met geëxporteerde bronnen uit. De client kan een dergelijke lijst echter opvragen bij de server. Aan de serverzijde is de rpc.mountd-daemon verantwoordelijk voor het afhandelen van mount-aanvragen.

Het exporteren van NFS-bestandsbronnen volgt vier basisregels.

1. Het bestandssysteem kan in zijn geheel of in delen, zoals mappen en bestanden, worden geëxporteerd. Houd er rekening mee dat de grootste geëxporteerde eenheid het bestandssysteem is. Als op de server een bepaald bestandssysteem (/usr/bin) is aangekoppeld in de hiërarchie onder een ander bestandssysteem (/usr), heeft het exporteren van het /usr-systeem geen invloed op het /usr/bin-systeem.
2. Je kunt alleen lokaal exporteren bestandsbronnen Met andere woorden: als het bestandssysteem van iemand anders op de server is aangekoppeld, dat wil zeggen op een andere server, kan het niet opnieuw worden geëxporteerd.
3. U kunt geen submappen van een reeds geëxporteerd bestandssysteem exporteren, tenzij het afzonderlijke bestandssystemen zijn.
4. U kunt de bovenliggende mappen van een map die al is geëxporteerd niet exporteren, tenzij de bovenliggende map een onafhankelijk bestandssysteem is.

Elke overtreding van deze regels zal resulteren in een fout in de NFS-werking.

De tabel met geëxporteerde bronnen bevindt zich in het bestand /etc/exports. Helaas is de syntaxis van dit bestand UNIX-specifiek, dus we gebruiken Solaris als voorbeeld. Het bestand /etc/exports bestaat uit tekstreeksen, met het formaat:

-,...

Enkele van de meest populaire opties staan ​​vermeld in Tabel 1. In feite beschrijven de opties de toegangsrechten van clients tot de geëxporteerde bronnen. Het is belangrijk om te onthouden dat de machtigingen die tijdens het exporteren worden vermeld, op geen enkele manier de machtigingen overschrijven die rechtstreeks op het bestandssysteem van toepassing zijn. Als het bestandssysteem bijvoorbeeld schrijfbaar wordt geëxporteerd en een bepaald bestand een alleen-lezen attribuut heeft, is het niet mogelijk dit te wijzigen. Bij het exporteren fungeren de toegangsrechten dus als een extra filter. Bovendien, als bijvoorbeeld een bestandssysteem wordt geëxporteerd met de ro (alleen-lezen) optie, dan heeft de client het recht om het te mounten met de rw (lezen/schrijven) optie, maar een poging om te schrijven zal resulteren in een foutmelding.

Met de toegangsoptie kunt u hosts opgeven met het recht om een ​​bron te koppelen. Dienovereenkomstig heeft geen enkele andere host, behalve degene die daarin worden genoemd, de mogelijkheid om de bron te mounten en daarom bewerkingen uit te voeren.

De lijst met hosts die informatie kunnen schrijven, wordt gespecificeerd met behulp van de rw-optie. Als de rw-optie geen lijst met hosts specificeert, heeft elke host het recht om te schrijven.

Met de root-optie kunt u hosts opgeven waarop lokale root-superusers ontvangen wortelrechten server naar de geëxporteerde bron. Anders, zelfs als de host rw-rechten krijgt, is de rootgebruiker daarop gelijk aan de gebruiker niemand (uid=-2), dat wil zeggen een gebruiker met minimale toegangsrechten. Het bovenstaande is specifiek van toepassing op toegangsrechten tot een externe bron en heeft geen invloed op de toegangsrechten tot lokale clientbronnen.

De anon- en secure-opties zullen worden besproken bij het beschrijven van het NFS-authenticatieschema.

INSTALLATIEREGELS

Als de geëxporteerde bronnen voor de server kunnen fungeren als een bestandssysteem of een aparte map, dan zien ze er voor de client altijd uit als bestandssystemen. Omdat NFS-ondersteuning is ingebouwd in de UNIX-kernel, wordt de bewerking van het mounten van NFS-bestandssystemen uitgevoerd door het standaard mount-hulpprogramma (er is geen aparte daemon vereist om NFS te mounten), en hoeft u alleen maar op te geven dat het aangekoppelde bestandssysteem NFS is. Een andere manier om te mounten is het gebruik van het bestand /etc/fstab (/etc/filesystems in sommige versies van UNIX). IN in dit geval systemen op afstand NFS (evenals lokale) wordt aangekoppeld tijdens de opstartfase van het besturingssysteem. Mountpunten kunnen elk willekeurig punt zijn, ook als onderdeel van andere NFS-bestandssystemen, d.w.z. NFS-systemen kunnen over elkaar heen worden “geregen”.

De basisopties voor NFS-aankoppeling staan ​​vermeld in Tabel 2.

Met de bg-optie kunt u inmounten achtergrond, in dit geval kunt u andere mount-opdrachten uitvoeren.

Het paar harde/zachte opties lijkt erg interessant. Bij een "harde" mount zal de client koste wat het kost proberen het bestandssysteem te mounten. Als de server niet beschikbaar is, zal de hele NFS-service vastlopen: processen die toegang hebben tot het bestandssysteem zullen in een wachtstand gaan totdat RPC-verzoeken zijn voltooid. Vanuit het oogpunt van gebruikersprocessen ziet het bestandssysteem eruit als een zeer trage lokale schijf. Wanneer de server terugkeert naar werkende staat de NFS-service blijft functioneren alsof er niets is gebeurd. Met behulp van de intr-optie kunt u het harde mount-proces onderbreken met behulp van het INTERRUPT-systeemsignaal.

Tijdens een zachte aankoppeling zal de NFS-client verschillende pogingen doen om verbinding te maken met de server, zoals gespecificeerd door de retans- en timeo-opties (sommige systemen ondersteunen ook een speciale optie voor opnieuw proberen). Als de server niet reageert, geeft het systeem een ​​foutmelding weer en stopt het met de poging om te mounten. Vanuit het oogpunt van de logica van bestandsbewerkingen wanneer de server uitvalt, emuleert een “zachte” mount een lokale schijfstoring. Als de optie retrans (opnieuw proberen) niet is opgegeven, is het aantal nieuwe pogingen beperkt tot de standaardwaarde voor het gegeven UNIX-systeem. De retrans- en timeo-opties zijn niet alleen van toepassing op aankoppelingen, maar ook op alle RPC-bewerkingen die worden uitgevoerd op het NFS-bestandssysteem. Dat wil zeggen, als de client een schrijfbewerking uitvoert en er op dat moment een storing is op het netwerk of op de server, zal de client proberen de verzoeken te herhalen.

De vraag welke modus, ‘zacht’ of ‘hard’, beter is, kan niet eenduidig ​​worden beantwoord. Als de data op de server consistent moeten zijn als deze tijdelijk uitvalt, dan verdient een “harde” mount de voorkeur. Deze modus is ook onmisbaar in gevallen waarin de aangekoppelde bestandssystemen programma's en bestanden bevatten die essentieel zijn voor de werking van de client, met name voor schijfloze machines. In andere gevallen, vooral wanneer waar we het over hebben Wat betreft alleen-lezensystemen lijkt de zachte montagemodus de voorkeur te hebben.

AUTHENTICATIE EN VEILIGHEID

Zoals opgemerkt, staat elk RPC-pakket op zichzelf. Bovendien biedt NFS over het algemeen geen statefulness, dat wil zeggen dat het niet bijhoudt welke verzoeken klanten eerder hebben gedaan, en dat het de prestaties van de klant niet bijhoudt. Daarom blijkt het beveiligingsprobleem uiterst relevant te zijn in systemen die gebruikmaken van externe procedureaanroepen.

In NFS wordt authenticatie uitsluitend uitgevoerd in de fase van het aankoppelen van het bestandssysteem en alleen op basis van de domeinnaam (of IP-adres) van de clientmachine. Dat wil zeggen, als een NFS-client (hier bedoelen we een computer, niet een computergebruiker) contact opneemt met de server met een mount-verzoek, bepaalt de server de toegangsrechten met behulp van de tabel /etc/exports, en wordt de client geïdentificeerd aan de hand van de naam (IP adres) van de computer. Als de klant bepaalde bewerkingen op de geëxporteerde bron mag uitvoeren, krijgt hij een bepaald “magisch nummer” (magische cookie) te horen. In de toekomst moet de klant dit nummer in elk RPC-verzoek opnemen om zijn inloggegevens te bewijzen.

Dit is in feite de hele eenvoudige set clientauthenticatietools; gebruikers worden op geen enkele manier geverifieerd. Elk RPC-verzoek bevat echter de uid van de gebruiker die het verzoek heeft geïnitieerd, en een lijst met groeps-ID's, gid, waartoe de gebruiker behoort. Maar deze identificatiegegevens worden niet gebruikt voor authenticatie, maar om de toegangsrechten van een specifieke gebruiker tot bestanden en mappen te bepalen.

Houd er rekening mee dat uid en gid aan de clientzijde worden bepaald, niet aan de serverzijde. Daarom worden beheerders geconfronteerd met het probleem van het coördineren van de inhoud van /etc/passwd (en /etc/group) tussen clients en NFS-servers, zodat gebruiker Vasya op de server niet de rechten van gebruiker Petya krijgt toegewezen. Voor grote netwerken dit brengt ernstige moeilijkheden met zich mee. Om de consistentie van de gebruikersdatabase te garanderen, evenals van systeembestanden zoals /etc/hosts, /etc/rpc, /etc/services, /etc/protocols, /etc/aliases, enz., kunt u de netwerkinformatieservice gebruiken System, NIS), ontwikkeld door Sun in 1985 en opgenomen in de meeste versies van UNIX (de meer geavanceerde versie NIS+ wordt niet veel gebruikt). NIS is een informatieservice, die enigszins doet denken aan de directoryservice van Windows NT, waarmee systeembestanden centraal kunnen worden opgeslagen en verwerkt. Overigens is NIS gebouwd op hetzelfde principe als NFS, en gebruikt het met name de RPC- en XDR-protocollen.

Een ander belangrijk kenmerk van NFS is dat elk RPC-verzoek een lijst bevat met de gid-groepen van de gebruiker. Om de grootte van het RFC-pakket te beperken, beperken de meeste NFS-implementaties het aantal groepen tot niet meer dan 8 of 16. Als een gebruiker lid is van meer groepen, kan dit leiden tot fouten bij het bepalen van de rechten op de server. Dit probleem is zeer relevant voor bedrijfsbestandsservers. Een radicale oplossing is het gebruik van ACL's, maar helaas ondersteunen niet alle UNIX-smaken deze.

Het authenticatiesysteem van NFS is erg slecht en biedt geen mogelijkheden betrouwbare bescherming. Iedereen die met NFS te maken heeft gehad, weet hoe gemakkelijk het is om de beveiliging ervan te omzeilen. Om dit te doen is het niet eens nodig om methoden te gebruiken voor het vervalsen van IP-adressen (IP-spoofing) of namen (DNS-spoofing). Een aanvaller hoeft alleen maar het ‘magische getal’ te onderscheppen, en in de toekomst kan hij namens de klant acties uitvoeren. Bovendien verandert het "magische getal" pas bij de volgende herstart van de server.

Op talrijk Internetservers Je kunt andere, waaronder zeer exotische, methoden ontdekken om NFS te hacken. Het aantal ontdekte ‘gaten’ loopt in de duizenden. Daarom wordt aanbevolen NFS v.2 alleen te gebruiken binnen beveiligde netwerken.

Op basis van deze overwegingen heeft Sun het SecureRPC-protocol ontwikkeld met behulp van zowel asymmetrische als symmetrische coderingssleutels. Tegelijkertijd cryptografische methoden worden gebruikt om niet alleen hosts, maar ook gebruikers te authenticeren. De gegevens zelf zijn echter niet gecodeerd. Helaas worden, vanwege exportbeperkingen van de Amerikaanse overheid, niet alle UNIX-systemen geleverd met SecureRPC-ondersteuning. Daarom zullen we niet stilstaan ​​bij de mogelijkheden van dit protocol. Als uw versie van UNIX echter SecureRPC ondersteunt, zal Hal Stein's boek "Managing NFS and NIS", uitgegeven door O'Reilly & Associates, van onschatbare waarde zijn bij het opzetten ervan.

Een ander probleem doet zich voor bij NFS-clients op MS-DOS- en Windows 3.x/9x-platforms. Deze systemen zijn bedoeld voor één gebruiker en het is niet mogelijk om de gebruiker te identificeren met behulp van normale NFS-tools. Om DOS/Windows-gebruikers te identificeren, wordt de pcnfsd-daemon op de server gestart. Bij het verbinden (mounten) van NFS-schijven op de clientcomputer, wordt om de gebruikersnaam en het wachtwoord gevraagd, waardoor niet alleen identificatie, maar ook authenticatie van gebruikers mogelijk is.

Hoewel Windows NT meerdere gebruikers kan gebruiken, zijn de gebruikersdatabase en het gebruikersidentificatieschema incompatibel met UNIX. Daarom worden NFS-clientsites gebaseerd op Windows NT ook gedwongen de mogelijkheden van pcnfsd te gebruiken.

Naast gebruikersauthenticatie kunt u met pcnfs ook naar UNIX afdrukken cliënt plaatsen DOS/Windows. Het is waar dat Windows NT aanvankelijk het programma LPR.EXE bevatte, waarmee ook op UNIX-servers kan worden afgedrukt.

Om toegang te krijgen tot de bestandsservice en NFS-service op DOS/Windows-machines moet u speciale clientsoftware installeren, en de prijzen voor deze producten zijn behoorlijk hoog.

Laten we echter terugkeren naar de exportopties voor NFS-bestanden (zie Tabel 1). De anon-optie bepaalt de gebruikersidentificatie-uid in het geval dat de DOS/Windows-gebruiker zichzelf niet kon authenticeren (stel het verkeerde wachtwoord in) of wanneer de gebruiker van de host die via SecureRPC is verbonden, de authenticatie mislukte. Standaard heeft anon uid=-2.

De beveiligde optie wordt gebruikt wanneer het SecureRPC-protocol wordt gebruikt.

ARCHITECTONISCHE EIGENSCHAPPEN VAN NFS V2

NFS-bestandssystemen moeten aan twee voorwaarden voldoen (dezelfde vereisten gelden overigens niet alleen voor NFS, maar ook voor andere netwerkbestandssystemen).

1. Vanuit het perspectief van een cliënt gebruikersprogramma's Het NFS-bestandssysteem bevindt zich alsof het is ingeschakeld lokale schijf. Programma's kunnen geen onderscheid maken NFS-bestanden uit gewone bestanden.
2. De NFS-client kan niet bepalen welk platform als server wordt gebruikt. Dit kan UNIX, MVS of zelfs Windows NT zijn. Verschillen in serverarchitectuur hebben alleen invloed op specifieke bewerkingen, niet op NFS-mogelijkheden. Voor de klant bestandsstructuur NFS is vergelijkbaar met een lokaal systeem.

Het eerste niveau van transparantie wordt bereikt door UNIX's gebruik van het Virtual File System (VFS). VFS is niet alleen verantwoordelijk voor de interactie met NFS, maar ook voor lokale systemen zoals UFS, ext2, VxFS, enz.

Het tweede niveau van transparantie wordt bereikt door het gebruik van zogenaamde virtuele knooppunten (vnodes), waarvan de structuur kan worden gecorreleerd met inodes in UNIX-bestandssystemen.

Bewerkingen op bestandsbestanden NFS-systemen zijn VFS-bewerkingen, terwijl de interactie met individuele bestanden en mappen wordt bepaald door vnode-bewerkingen. Het RPC-protocol van NFS v2 beschrijft 16 procedures die verband houden met bewerkingen, niet alleen op bestanden en mappen, maar ook op hun attributen. Het is belangrijk om te begrijpen dat RPC-oproepen en de vnode-interface verschillende concepten zijn. vnode-interfaces definiëren OS-services voor toegang tot bestandssystemen, ongeacht of deze lokaal of extern zijn. RPC van NFS is een specifieke implementatie van een van de vnode-interfaces.

Lees-/schrijfbewerkingen worden aan de clientzijde in de cache opgeslagen, dat wil zeggen dat de client de inhoud van bestanden en mappen in de cache opslaat. Normaal gesproken is de NFS-cachebuffergrootte 8 KB. Als er biod-daemons op de client draaien, wordt het lezen vooraf gedaan en wordt het schrijven in de luie modus gedaan. Als een gebruikersproces bijvoorbeeld informatie schrijft, worden de gegevens verzameld in een cachebuffer voordat ze worden doorgestuurd, meestal in een enkel RPC-pakket. Wanneer een schrijfbewerking wordt uitgevoerd, geeft de kernel onmiddellijk de controle over het proces terug, en worden de functies voor het doorsturen van RPC-verzoeken overgebracht naar biod. Als de biod-daemons niet actief zijn en de kernel geen multi-threaded RPC-verwerking ondersteunt, moet de kernel het doorsturen van RPC-pakketten in single-threaded modus afhandelen, en gaat het gebruikersproces in een staat van wachten tot het doorsturen is voltooid. . Maar in dit geval wordt nog steeds de NFS-cache gebruikt.

Naast de inhoud van NFS-bestanden en -mappen worden bestands- en mapkenmerken aan de clientzijde in de cache opgeslagen en wordt de kenmerkencache periodiek bijgewerkt (meestal elke paar seconden). Dit komt door het feit dat de waarde van de attributen kan worden gebruikt om de status van een bestand of map te beoordelen. Laten we deze aanpak met een voorbeeld toelichten. Wanneer een gebruiker een leesbewerking vanuit een bestand uitvoert, wordt de inhoud van het bestand in de NFS-cache geplaatst, maar worden de attributen van het bestand (aanmaak-/updatetijd, grootte, etc.) ook in de attribuutcache geplaatst. Als op dit moment een andere client naar hetzelfde bestand schrijft, kan dit ertoe leiden dat de inhoud in de caches van verschillende clients niet overeenkomt. Omdat de attribuutcache van de eerste client echter elke paar seconden wordt bijgewerkt, kan deze vaststellen dat de attributen zijn gewijzigd (in dit geval het tijdstip waarop het bestand is bijgewerkt). De client moet dus een updatebewerking uitvoeren op de inhoudcache van het bestand. (deze handeling wordt automatisch uitgevoerd).

Om clientverzoeken te kunnen verwerken, moeten nfsd-daemons op de server draaien. In dit geval slaan de daemons informatie op in het cachegeheugen bij het lezen van serverschijven. Alle daemons bedienen dezelfde wachtrij met clientverzoeken, wat een optimaal gebruik van processorbronnen mogelijk maakt.

Helaas is het bepalen van het optimale aantal biod- en nfsd-daemons erg moeilijk. Aan de ene kant geldt: hoe groter het aantal actieve daemons, hoe groter het aantal verzoeken dat tegelijkertijd kan worden verwerkt; aan de andere kant kan het vergroten van het aantal daemons een negatieve invloed hebben op de systeemprestaties als gevolg van de toegenomen procesomschakelingsoverhead. Het nauwkeurig afstemmen van NFS is een zeer vervelende procedure en vereist dat niet alleen rekening wordt gehouden met het aantal clients en gebruikersprocessen, maar ook met kenmerken als de schakeltijd tussen procescontexten (dat wil zeggen kenmerken van de processorarchitectuur), de grootte RAM, systeembelasting, etc. Het is beter om dergelijke instellingen experimenteel te bepalen, hoewel in de meeste gevallen de standaardinstellingen voldoende zijn (meestal worden er 8 nfsd-daemons uitgevoerd op de server en 4 biod-daemons op de clients).

Figuur 2. Schrijfbewerking in NFS v2.

Erg belangrijk kenmerk NFS v2 houdt in dat schrijfbewerkingen niet in de cache aan de serverzijde worden opgeslagen (zie Figuur 2). Dit is gedaan om een ​​hoge betrouwbaarheid van de NFS-service te garanderen en om de gegevensintegriteit te garanderen na het opnieuw opstarten van de server in het geval van een serverstoring. Het gebrek aan schrijfcaching is het grootste probleem met NFS v2. Bij schrijfbewerkingen is NFS aanzienlijk inferieur aan concurrerende technologieën, hoewel het bij leesbewerkingen daar weinig aan verliest. De enige methode om lage schrijfprestaties te bestrijden is het gebruik van schijfsubsystemen met een stroomonafhankelijke ingebouwde cache, zoals in vrij dure RAID-arrays.

Bij het werken in gedistribueerde en mondiale netwerken heeft NFS v2 nog een ander nadeel vanwege de keuze voor UDP als transportprotocol voor de dienst. Zoals u weet, garandeert UDP de bezorging van pakketten niet; bovendien komt de volgorde waarin pakketten worden ontvangen niet overeen met de volgorde waarin ze worden verzonden.

Dit kan tot de volgende twee onaangename gevolgen leiden: pakketverlies en een lange vertraging bij de verwerking ervan. Stel je voor dat een client een leesbewerking uitvoert op een groot bestand. In dit geval moet de server verschillende pakketten verzenden om de cachebuffer van de client te vullen. Als een van de pakketten verloren gaat, wordt de client gedwongen het verzoek opnieuw te herhalen en wordt de server gedwongen antwoorden te genereren, enz.

De situatie van vertraging bij het verwerken van RPC-verzoeken als gevolg van bijvoorbeeld zware serverbelasting of netwerkproblemen is ook behoorlijk onaangenaam. Als de opgegeven tijdslimiet wordt overschreden, gaat de client ervan uit dat het pakket verloren is gegaan en probeert hij het verzoek te herhalen. Voor veel NFS-bewerkingen is dit geen probleem, omdat zelfs de schrijfbewerking door de server kan worden herhaald. Maar hoe zit het met bewerkingen als "directory verwijderen" of "bestand hernoemen"? Gelukkig ondersteunen de meeste NFS-implementaties het cachen van dubbele verzoeken op de server. Als de server binnen korte tijd een herhaald verzoek ontvangt voor een bewerking, wordt een dergelijk verzoek genegeerd.

Het RPC-systeem houdt de verbindingsstatus niet bij, wat problemen veroorzaakt wanneer meerdere clients tegelijkertijd toegang hebben tot hetzelfde bestand. Er zijn hier twee moeilijkheden:

• hoe u een bestand kunt vergrendelen, vooral wanneer u ernaar schrijft;
• hoe kan ik de integriteit van vergrendelingen garanderen in het geval van een crash en herstart van de NFS-server of -client?

Om dit te doen gebruikt NFS twee speciale daemons: rpc.lockd is verantwoordelijk voor het vergrendelen van bestanden, en rpc.statd is verantwoordelijk voor het monitoren van de status van vergrendelingen (zie Figuur 3). Deze daemons draaien zowel aan de client- als aan de serverzijde. Aan de daemons rpc.lockd en rpc.statd zijn twee speciale mappen toegewezen (sm en sm.bak), waar vergrendelingsinformatie wordt opgeslagen.

Met een unieke en erg handige aanvullende service, automounter, kunt u automatisch bestandssystemen aankoppelen wanneer gebruikersprocessen er toegang toe krijgen. Vervolgens probeert automounter periodiek (standaard één keer per vijf minuten) het systeem te ontkoppelen. Als het bezet is (er staat bijvoorbeeld een bestand open), dan blijft de dienst doorwerken normale modus. Als het bestandssysteem niet langer toegankelijk is, wordt het automatisch ontkoppeld. De automounter-functie wordt door verschillende programma's geïmplementeerd, waarvan amd en autofs bijzonder populair zijn.

NFS V3-FUNCTIES

De derde versie van NFS is volledig achterwaarts compatibel met de tweede versie, dat wil zeggen dat de NFS v3-server NFS v2- en NFS v3-clients “begrijpt”. Op dezelfde manier heeft een NFS v3-client toegang tot een NFS v2-server.

Een belangrijke innovatie in NFS v3 is ondersteuning voor het TCP-transportprotocol. UDP is geweldig voor lokale netwerken, maar is niet geschikt voor langzame en niet altijd betrouwbare wereldwijde communicatielijnen. In NFS v3 wordt al het clientverkeer gemultiplext in één enkele TCP-verbinding.

In NFS v3 werd de cachebuffergrootte vergroot tot 64 KB, wat een gunstig effect had op de prestaties, vooral in het licht van het actieve gebruik van hogesnelheidsnetwerken Snelle technologieën Ethernet, Gigabit Ethernet en ATM. Bovendien kunt u met NFS v3 informatie die op de client in de cache is opgeslagen, niet alleen in het RAM-geheugen opslaan, maar ook op de lokale schijf van de client (in alle eerlijkheid is het de moeite waard om op te merken dat sommige NFS v2-implementaties deze functie ook bieden). Deze technologie staat bekend als CacheFS.

Figuur 4. Schrijfbewerking in NFS v3.

Maar misschien kan een nog belangrijkere innovatie van NFS v3 worden beschouwd als een radicale verhoging van de prestaties bij schrijfbewerkingen. Nu wordt het cachen van opgenomen informatie ook aan de serverzijde uitgevoerd, terwijl registratie en bevestiging van het schrijven van gegevens naar schijf wordt uitgevoerd met behulp van een speciaal commit-verzoek (zie figuur 4). Deze technologie wordt veilige asynchrone opname genoemd. Nadat de gegevens naar de cache van de server zijn verzonden, stuurt de client een commit-verzoek, dat een schrijfbewerking naar de schijf van de server initieert. Op zijn beurt stuurt de server, na het schrijven van informatie naar schijf, de client een bevestiging van de succesvolle voltooiing ervan.

Nieuw in NFS v3 is ondersteuning voor 64-bit bestandssystemen en verbeterde ondersteuning voor ACL's.

Wat de toekomst betreft, maakt Sun nu reclame voor de WebNFS-technologie, waarmee u vanaf elk apparaat toegang kunt krijgen tot bestandssystemen Webbrowser of via applicaties geschreven in Java. Er hoeft geen clientsoftware te worden geïnstalleerd. WebNFS levert (volgens Sun) een prestatiewinst op van drie tot vijf keer ten opzichte van ftp of HTTP.

CONCLUSIE

Als de beheerder de werkingsprincipes van NFS-protocollen kent, kan hij de service optimaal configureren. Het NFS-netwerkbestandssysteem is ideaal voor UNIX-netwerken, omdat het bij bijna alle versies van dit besturingssysteem wordt geleverd. Bovendien is NFS-ondersteuning geïmplementeerd op UNIX-kernelniveau. Nu Linux geleidelijk aan gewicht begint te winnen op desktopniveau, heeft NFS ook hier de kans om erkenning te krijgen. Helaas veroorzaakt het gebruik van NFS op Windows-clientcomputers bepaalde problemen die verband houden met de noodzaak om gespecialiseerde en vrij dure clientsoftware te installeren. In dergelijke netwerken lijkt het gebruik van de SMB-service, en met name Samba-software, meer de voorkeur te verdienen. In een van de komende LAN-problemen komen we echter terug op SMB-producten voor UNIX.

Iedereen weet dat op UNIX-systemen een bestandssysteem logischerwijs een verzameling fysieke bestandssystemen is die op één enkel punt zijn aangesloten. Een van de belangrijkste voordelen van een dergelijke organisatie is naar mijn mening de mogelijkheid om de structuur van een bestaand bestandssysteem dynamisch te wijzigen. Dankzij de inspanningen van de ontwikkelaars hebben we tegenwoordig ook de mogelijkheid om een ​​bestandssysteem van vrijwel elk type en op elke handige manier aan te sluiten. Met “methode” wil ik allereerst het vermogen van de OS-kernel benadrukken om via netwerkverbindingen met bestandssystemen te werken.

Veel netwerkprotocollen bieden ons de mogelijkheid om met externe bestanden te werken, of het nu FTP, SMB, Telnet of SSH is. Dankzij het vermogen van de kernel om uiteindelijk niet afhankelijk te zijn van het type bestandssysteem dat wordt aangesloten, hebben we de mogelijkheid om alles te verbinden en hoe we maar willen met behulp van het mount-programma.

Vandaag wil ik het hebben over NFS - Netwerkbestandssysteem. Met deze technologie kunt u individuele FS-punten op een externe computer verbinden met het bestandssysteem lokale computer. Mezelf NFS-protocol Hiermee kunt u snel, veilig en betrouwbaar bewerkingen met bestanden uitvoeren. Wat hebben we nog meer nodig? :-)

Wat is er nodig om dit te laten werken

Om niet lang te zeuren over het onderwerp NFS-versies en hun ondersteuning in verschillende kernels, gaan we er onmiddellijk van uit dat je kernelversie niet lager is dan 2.2.18. IN officiële documentatie beloven de ontwikkelaars volledige ondersteuning NFS versie 3-functionaliteit in deze kernel en latere versies.

Installatie

Om de NFS-server in mijn Ubuntu 7.10 - de Gutsy Gibbon - te laten draaien, moest ik de pakketten nfs-common en nfs-kernel-server installeren. Als u alleen een NFS-client nodig heeft, hoeft nfs-kernel-server niet geïnstalleerd te worden.

Serverconfiguratie

Nadat alle pakketten met succes zijn geïnstalleerd, moet u controleren of de NFS-daemon actief is:

/etc/init.d/nfs-kernel-serverstatus

Als de daemon niet actief is, moet u deze starten met de opdracht

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

Nadat alles succesvol is gestart, kunt u beginnen met het exporteren van het bestandssysteem. Het proces zelf is heel eenvoudig en kost minimale tijd.

Het hoofdconfiguratiebestand van de NFS-server bevindt zich in /etc/exports en heeft het volgende formaat:

Directory machine1(optie11,optie12) machine2(optie21,optie22)

map — absoluut pad naar de FS-servermap waartoe u toegang moet verlenen

machineX— DNS-naam of IP-adres clientcomputer van waaruit toegang is toegestaan

optieXX— FS-exportparameters, de meest gebruikte:

• ro- Bestandstoegang is alleen-lezen
• rw— lees-/schrijftoegang wordt verleend
• geen_root_squash— als je als root verbinding maakt met een NFS-bron, zal de server, omwille van de veiligheid, standaard toegang krijgen tot bestanden als de niemand-gebruiker. Als u deze optie echter inschakelt, worden bestanden op de server als root benaderd. Wees voorzichtig met deze optie.
• no_subtree_check— als u niet de gehele partitie op de server exporteert, maar slechts een deel van het bestandssysteem, zal de daemon standaard controleren of het opgevraagde bestand zich fysiek op dezelfde partitie bevindt of niet. Als u de gehele partitie exporteert of als het koppelpunt van het geëxporteerde bestandssysteem geen invloed heeft op bestanden van andere fysieke volumes, kunt u deze optie inschakelen. Dit geeft u een verhoging van de serversnelheid.
• synchroniseren— schakel deze optie in als er een mogelijkheid bestaat van een plotselinge verbindingsverlies of stroomuitval van de server. Als deze optie niet is ingeschakeld, bestaat er een zeer groot risico op gegevensverlies als de NFS-server plotseling stopt.

Laten we dus zeggen dat we toegang moeten geven tot de ashep-desktopcomputer tot de map /var/backups van de ashep-laptopcomputer. Directory-toegang is vereist om back-upbestanden van asep-desktop te kopiëren. Mijn bestand is als volgt geworden:

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

Nadat u de regel aan /etc/exports hebt toegevoegd, moet u de NFS-server opnieuw opstarten om de wijzigingen door te voeren.

/etc/init.d/nfs-kernel-server opnieuw opstarten

Dat is het. U kunt beginnen met het verbinden van de geëxporteerde FS op de clientcomputer.

Klantconfiguratie

Aan de clientzijde wordt het externe bestandssysteem op dezelfde manier aangekoppeld als alle andere: met het mount-commando. Bovendien verbiedt niemand je om /etc/fstab te gebruiken als je de FS automatisch moet verbinden wanneer het besturingssysteem opstart. De mount-optie ziet er dus als volgt uit:

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

Als alles goed is gegaan en je tijdens het opstarten automatisch verbinding moet maken met de externe FS, voeg dan gewoon de regel toe aan /etc/fstab:

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

Wat nog meer

We hebben dus een praktisch, klein overzicht van de mogelijkheden van NFS. Dit is natuurlijk maar een klein deel van wat NFS kan doen. Dit is voldoende voor gebruik thuis of op een klein kantoor. Als dit niet genoeg voor je is, raad ik je aan eerst te lezen