Domov › Internet › protokol NFS

protokol NFS

1.4 Síťový souborový systém

Systém souborů CIFS dominuje na trhu síťových souborových systémů pro platformu Windows. Na platformě UNIX je hlavním z nich Network File System (NFS). NFS je navíc považován za první široce přijatý souborový systém, který se datuje do poloviny 80. let. Navzdory některým společným funkcím mezi CIFS a NFS (síťové souborové systémy, které klientům umožňují přístup k serverovým prostředkům), mají tyto systémy zcela odlišné architektonické prvky. S vydáním NFS verze 4 byly některé rozdíly revidovány.
Protokol CIFS ukládá data služeb specifická pro každého klienta. Před verzí 3 si systém souborů NFS neuchovával stav klienta, který se ve verzi 4 změnil.
Klient NFS „nevyjednává“ se serverem NFS za účelem vytvoření relace. Bezpečnostní opatření jsou přijímána pro celou relaci nebo každou komunikaci mezi klientem a serverem. Implementace druhé možnosti je neúměrně nákladná, takže NFS ponechává odpovědnost za zabezpečení na klientovi. Server „předpokládá“, že uživatelská ID na klientských a serverových systémech jsou stejná (a klient ověřil identitu uživatele předtím, než mu umožnil zaregistrovat se pod zadaným ID). NFS navíc poskytuje určitou úroveň zabezpečení řízením seznamu souborových systémů, které může klient připojit. Pokaždé, když klient CIFS otevře soubor, přijme popisovač souboru (tj. servisní data, která musí server uložit) a použije je k provádění operací čtení nebo zápisu na straně klienta, server NFS se dotáže serveru, který soubor vrátí. zacházet s. Tento deskriptor souboru zpracovávají klienti, kteří podporují standardy NFS 3 a NFS 2. Klient ukládá výsledný deskriptor souboru do mezipaměti a očekává, že bude vždy odkazovat na stejný soubor.
Pro ty, kteří jsou obeznámeni s UNIXem, deskriptor souboru obvykle sestává z čísla inodu, počtu generování inodu a ID souboru, který je spojen s diskovým oddílem. Stačí říci, že inode je extrémně důležitá datová struktura používaná v souborových systémech UNIX. Je uloženo dostatečné množství informací pro odstranění úchytů uložených v mezipaměti klientů, pokud se odpovídající soubor pro úchyt změnil a úchyt musí ukazovat na jiný soubor. Pokud je například soubor odstraněn a na jeho místo je zkopírován soubor se stejným názvem, změní se počítadlo generování inodů a deskriptor souboru uložený v mezipaměti klienta bude neplatný. Systém souborů NFS 4 má rozdíly v implementaci.
Někteří klienti NFS provádějí ukládání do mezipaměti na straně klienta ukládáním dat na disky, což je podobné ukládání do mezipaměti CIFS. Někteří klienti NFS také mění hodnotu časových limitů v závislosti na době odezvy serveru. Čím pomaleji server reaguje, tím větší je hodnota časového limitu a naopak.
Souborový systém NFS byl navržen jako nezávislý na transportu a zpočátku používal transportní protokol UDP. Různé typy NFS mohou používat TCP a další protokoly.

1.4.1 Síťový souborový systém verze 3

Souborový systém NFS 3 zlepšuje výkon, zejména u velkých souborů, tím, že umožňuje klientovi a serveru dynamicky vybrat maximální množství dat, která se při zápisu nebo čtení přenesou v jednom logickém paketovém prvku. V souborovém systému NFS 2 byla velikost paketu omezena na 8 KB. Jinými slovy, klient mohl poslat maximálně 8 KB v požadavku na zápis a server mohl poslat maximálně 8 KB v odpovědi na požadavek čtení. Kromě toho má NFS 3 předefinované offsety souborů a velikosti dat. Toto jsou nyní 64bitové hodnoty namísto 32bitových v NFS 2.
Níže jsou uvedeny některé funkce NFS 3.
■ Popisovače souborů v NFS 3 mají proměnnou velikost; jejich maximální velikost je 64 bitů.
■ Systém souborů NFS 3 umožňuje klientům a serverům vybrat si maximální velikost názvů souborů a adresářů.
■ NFS 3 definuje seznam chyb, které může server vrátit klientům. Server musí vrátit jednu ze zadaných chyb nebo žádnou chybu.
■ V systému NFS 3 má server povoleno ukládat do mezipaměti data, která klient odeslal s požadavkem na zápis. Server může data ukládat do mezipaměti a odeslat odpověď na požadavek klientovi před zapsáním dat na disk. Byl také přidán příkaz COMMIT, který umožňuje klientovi zajistit, aby všechna odeslaná data byla zapsána na disk. To umožňuje dosáhnout rovnováhy mezi zvýšením výkonu a zachováním integrity dat.
■ NFS 3 snižuje počet operací požadavek/odpověď mezi klientem a serverem. Za tímto účelem jsou spolu s počátečním požadavkem odeslána data atributů souboru. V NFS 2 musel klient získat názvy souborů a deskriptor pro každý soubor, teprve potom byly přeneseny atributy souboru.

1.4.2 Síťový souborový systém verze 4

NFS 4 zcela přepracoval základní principy a implementoval mnoho funkcí specifických pro CIFS, což některé zastánce NFS značně rozrušilo. Pokud se podíváte na historii síťových souborových systémů, můžete vidět, že NFS se rozšířilo. Souborový systém SMB byl navržen tak, aby zohlednil silné a slabé stránky NFS a nyní, alespoň mezi zákazníky, je CIFS/SMB běžnější a NFS se vyvíjí, aby zohlednil výhody a nevýhody CIFS/SMB. Níže jsou uvedeny funkce, které byly přidány do NFS 4 za účelem zlepšení výkonu, zabezpečení a interoperability s CIFS.
■ NFS 4 zavedl požadavek COMPOUND, který umožňuje sbalit více požadavků do jednoho požadavku a více odpovědí do jediné odpovědi. Tato inovace je navržena tak, aby zlepšila výkon snížením zatížení sítě a snížením latence, když požadavky a odpovědi putují sítí. Pokud to zní trochu jako funkce CIFS AndX SMB (viz oddíl 3.3.5.1), nemusí to být jednoduchá náhoda.
■ Network File System verze 4 přebírá některé funkce z WebNFS společnosti Sun. Zejména NFS 4 podporuje některé sekundární protokoly v základní specifikaci, díky čemuž je NFS vhodnější pro použití s firewally. NFS 3 a starší používaly speciální protokol k připojení sdílené složky serveru do stromu místního systému souborů. Protože služba protokolu připojení neměla přiřazený port TCP nebo UDP, klient nejprve odeslal požadavek démonovi portmapperu, který poskytuje číslo portu, na kterém služba připojení naslouchá požadavkům. Na procesu se tedy kromě NFS podílely i montážní a portové mapovací protokoly. Navíc, protože služba připojení mohla používat libovolný port, konfigurace firewallu byla velmi obtížná. V NFS 4 byly protokoly pro připojení a mapování portů odstraněny. Kromě toho bylo zamykání zahrnuto do základní specifikace protokolu NFS a protokol NLM (Network Lock Manager), který se používal v dřívějších verzích NFS, byl trvale zastaralý.
■ Souborový systém NFS 4 vyžaduje použití transportního protokolu, který poskytuje schopnost detekovat přetížení sítě. To znamená, že klienti a servery NFS postupně přejdou na TCP namísto UDP, který se běžně používá s NFS 3.
■ NFS 2 a NFS 3 umožňovaly použití znakové sady U.S. ASCII nebo ISO Latin 1. To způsobovalo problémy, když klient používající jednu znakovou sadu vytvořil soubor a k tomuto souboru přistupoval klient používající jinou znakovou sadu. NFS 4 používá znakovou sadu UTF-8, která podporuje kompaktní kompresi 16bitových a 32bitových znaků pro přenos po síti. Znaková sada UTF-8 navíc obsahuje dostatek informací, aby se předešlo problémům při vytváření souboru pomocí jedné znakové sady a přístupu k souboru pomocí jiné sady.
■ Systém souborů NFS 4 vyžaduje, aby klient zpracovával deskriptory souborů samostatně. V systému NFS 3 mohl klient ukládat do mezipaměti popisovač jako objekt, zatímco server zajistil, aby popisovač vždy ukazoval na soubor. NFS 4 definuje dva typy deskriptorů souborů. Jeden se nazývá perzistentní deskriptory souborů a má schopnosti deskriptorů souborů z NFS 3. Druhý, dočasné deskriptory souborů, předpokládá, že platnost deskriptoru vyprší po určité době nebo události. Toto je funkce pro servery, jejichž systémy souborů (například NTFS) nemohou poskytovat konzistentní mapování mezi zobrazenými soubory a popisovači.
■ NFS 4 přidává podporu operací OPEN a CLOSE, jejichž sémantika umožňuje interakci s klienty CIFS. Příkaz OPEN vytvoří stavová data na serveru.
■ Podpora požadavku OPEN NFS 4 umožňuje klientovi zadat požadavek na otevření souboru, který je strukturován podobně jako požadavky na otevření aplikace Windows. Podporována je také volba sdílení souboru s jinými klienty nebo výhradního přístupu k souboru.

1.4.2.1 Zabezpečení NFS 4

Souborový systém NFS 4 umožňuje zvýšit bezpečnost uložených dat. Zejména NFS 4 přidává podporu pro více atributů souborů. Jedním z těchto atributů je seznam řízení přístupu (ACL) ve stylu Windows NT. To umožňuje lepší interoperabilitu mezi systémy souborů a silnější strukturu zabezpečení.
Zatímco v NFS 2 a NFS 3 bylo použití bezpečnostních prvků pouze doporučeno, v NFS 4 se stalo povinným. Souborový systém NFS 4 vyžaduje implementaci bezpečnostního mechanismu využívajícího rozhraní RPCSEC_GSS (Generic Security Services) obecně a zejména protokoly Kerberos 5/LIPKEY. Všimněte si, že RPCSEC_GSS jednoduše funguje jako API a transportní mechanismus pro štítky a data související se zabezpečením. Souborový systém NFS 4 umožňuje více schémat ověřování a zabezpečení a možnost vybrat si vhodné schéma pro klienty a servery.
Věnujme trochu pozornosti studiu technologie LIPKEY, která využívá kombinaci symetrického a asymetrického šifrování. Klient zašifruje uživatelská data a heslo pomocí náhodně generovaného 128bitového klíče. Šifrování se provádí pomocí symetrického algoritmu, tzn. pro dešifrování je nutné použít stejný klíč. Protože server potřebuje tento klíč k dešifrování zpráv, musí být serveru odeslán náhodně vygenerovaný klíč. Klient zašifruje klíč (který je náhodně vygenerován) pomocí veřejného klíče serveru. Server dešifruje data pomocí svého soukromého klíče, extrahuje symetrický klíč a dešifruje uživatelská data a heslo.
Klienti mohou ověřovat servery pomocí certifikátu serveru a k ověření certifikátu se používají služby certifikační autority. Jednou z populárních metod hackování je zachytit „mimozemské“ datové pakety a poté je po určité době odeslat. Při použití Kerberos přidá systém souborů NFS do každého paketu časové razítko. Server zaznamenává nedávno přijatá časová razítka a porovnává je s časovými razítky nových RPC paketů. Pokud jsou časová razítka paketů starší než dříve přijatá serverem, server přijaté pakety ignoruje

1.5 Problémy s přístupem při použití více protokolů

Několik společností začalo nabízet systémy, které současně podporují CIFS, NFS a další klienty síťového souborového systému. Prodejci odvedli spoustu práce při snaze překonat technické problémy, které vyvstávají u zákazníků, kteří potenciálně používají různé operační systémy a systémy souborů. Upozorňujeme, že problémy nevznikají s daty samotnými, ale s metadaty souborů. Jednoduchým testem takových problémů by bylo zkopírovat soubor ze serveru na klienta a zpět na server (nebo naopak). Jakmile je soubor umístěn do počátečního zdroje, metadata by měla obsahovat základní hodnoty, tj. Oprávnění souborů a časová razítka by se neměla měnit. Pokud to není pravda, problém byl zjištěn.
Následují příklady některých možných technických problémů.
■ Různé operační systémy používají různé metody ke sledování přístupových oprávnění uživatelů a skupin.
■ Různé operační systémy a systémy souborů mají různou sémantiku pro otevírání a zamykání souborů.
■ Konvence pojmenovávání souborů se používají různými způsoby. Různé systémy souborů mají různé reprezentace maximální velikosti názvu souboru, velikosti malých a velkých písmen v názvu souboru a znakové sady povolené v názvech.
■ Data a jejich struktura se v různých souborových systémech liší; například některé systémy souborů sledují dvě časová razítka, zatímco jiné sledují tři časová razítka (čas posledního přístupu k souboru, poslední úpravy souboru a vytvoření souboru). I když oba systémy souborů sledují dvě časová razítka, jednotky měření se mohou lišit. Dalším příkladem jsou jednotky pro měření offsetů v souborech. Některé systémy souborů podporují 32bitové posuny a některé podporují 16 nebo 64bitové posuny.
■ Problémy s adresováním zobrazených zámků. Server CIFS vynucuje zamykání: pokud jeden klient zamkl oblast souboru, pak jakákoli operace zápisu do této oblasti souboru jiným klientem povede k chybě. Vynucené zamykání však není podporováno servery NFS. Proto musíte zvolit, zda bude zámek vynucen, což povede k odeslání chybové zprávy klientovi NFS.

Když se mluví o počítačových sítích, můžete často slyšet zmínku o NFS. Co tato zkratka znamená?

Jedná se o protokol distribuovaného systému souborů původně vyvinutý společností Sun Microsystems v roce 1984, který umožňuje uživateli na klientském počítači přistupovat k souborům přes síť, podobně jako při přístupu k místnímu úložišti. NFS, stejně jako mnoho jiných protokolů, je založen na systému Open Network Computing Remote Procedure Call (ONC RPC).

Jinými slovy, co je NFS? Jedná se o otevřený standard definovaný Request for Comments (RFC), který umožňuje komukoli implementovat protokol.

Verze a variace

Vynálezce použil pouze první verzi pro své vlastní experimentální účely. Když vývojový tým přidal významné změny do původního NFS a vydal jej mimo autorství Sunu, označil novou verzi jako v2, aby mohl otestovat interoperabilitu mezi distribucemi a vytvořit záložní řešení.

NFS v2

Verze 2 zpočátku fungovala pouze přes User Datagram Protocol (UDP). Jeho vývojáři chtěli zachovat serverovou stranu bez blokování implementovaného mimo hlavní protokol.

Rozhraní virtuálního systému souborů umožňuje modulární implementaci, která se odráží v jednoduchém protokolu. Do února 1986 byla demonstrována řešení pro operační systémy jako System V release 2, DOS a VAX/VMS využívající Eunice. NFS v2 umožňovalo čtení pouze prvních 2 GB souboru kvůli 32bitovým omezením.

NFS v3

První návrh na vývoj NFS verze 3 u Sun Microsystems byl oznámen krátce po vydání druhé distribuce. Hlavní motivací bylo pokusit se zmírnit výkonnostní problém synchronního nahrávání. Do července 1992 praktická vylepšení vyřešila mnoho nedostatků NFS verze 2 a zůstala pouze nedostatečná podpora souborů (64bitové velikosti souborů a offsety souborů).

podpora 64bitových velikostí souborů a posunů pro zpracování dat větších než 2 gigabajty (GB);
podpora asynchronního nahrávání na serveru pro zlepšení výkonu;
další atributy souborů v mnoha odpovědích, aby se zabránilo jejich opětovnému načítání;
operace READDIRPLUS pro získání dat a atributů spolu s názvy souborů při skenování adresáře;
mnoho dalších vylepšení.

Během představení verze 3 se začala zvyšovat podpora TCP jako protokolu transportní vrstvy. Použití TCP jako prostředku pro přenos dat, prováděné pomocí NFS přes WAN, začalo umožňovat přenos velkých velikostí souborů pro prohlížení a zápis. Díky tomu byli vývojáři schopni překonat 8 KB limity stanovené protokolem User Datagram Protocol (UDP).

Co je NFS v4?

Verze 4, ovlivněná Endres File System (AFS) a Server Message Block (SMB, také nazývaná CIFS), zahrnuje vylepšení výkonu, poskytuje lepší zabezpečení a zavádí protokol shody.

Verze 4 byla první distribucí vyvinutou Internet Engineering Task Force (IETF) poté, co Sun Microsystems outsourcoval vývoj protokolu.

NFS verze 4.1 si klade za cíl poskytovat podporu protokolů pro využití clusterových serverových nasazení, včetně schopnosti poskytovat škálovatelný paralelní přístup k souborům distribuovaným na více serverech (rozšíření pNFS).

Nejnovější protokol souborového systému, NFS 4.2 (RFC 7862), byl oficiálně vydán v listopadu 2016.

Další rozšíření

S vývojem standardu se objevily odpovídající nástroje pro práci s ním. WebNFS, rozšíření pro verze 2 a 3, tedy umožňuje snazší integraci Network File System Access Protocol do webových prohlížečů a umožňuje práci napříč firewally.

S NFS se také spojily různé protokoly třetích stran. Nejznámější z nich jsou:

Network Lock Manager (NLM) s podporou bajtového protokolu (přidáno pro podporu API pro zamykání souborů UNIX System V);
Vzdálená kvóta (RQUOTAD), která umožňuje uživatelům NFS zobrazit kvóty úložiště na serverech NFS;
NFS over RDMA je adaptací NFS, která používá jako přenosové médium vzdálený přímý přístup do paměti (RDMA);
NFS-Ganesha je NFS server běžící v uživatelském prostoru a podporující CephFS FSAL (File System Abstraction Layer) pomocí libcephfs.

Platformy

Network File System se často používá s operačními systémy Unix (jako jsou Solaris, AIX, HP-UX), MacOS společnosti Apple a operačními systémy podobnými Unixu (jako jsou Linux a FreeBSD).

Je také k dispozici pro platformy jako Acorn RISC OS, OpenVMS, MS-DOS, Microsoft Windows, Novell NetWare a IBM AS/400.

Alternativní protokoly pro vzdálený přístup k souborům zahrnují Server Message Block (SMB, také nazývaný CIFS), Apple Transfer Protocol (AFP), NetWare Core Protocol (NCP) a OS/400 Server File System (QFileSvr.400).

To je způsobeno požadavky NFS, které jsou zaměřeny většinou na unixové „shelly“.

Protokoly SMB a NetWare (NCP) se však na systémech se systémem Microsoft Windows používají častěji než NFS. AFP je nejběžnější na platformách Apple Macintosh a QFileSvr.400 je nejběžnější na OS/400.

Typická implementace

Za předpokladu typického scénáře ve stylu Unixu, ve kterém jeden počítač (klient) potřebuje přístup k datům uloženým na jiném (server NFS):

Server implementuje procesy Network File System, které ve výchozím nastavení běží jako nfsd, aby svá data zpřístupnil klientům veřejně. Správce serveru určuje, jak exportovat názvy adresářů a nastavení, obvykle pomocí konfiguračního souboru /etc/exports a příkazu exportfs.
Správa zabezpečení serveru zajišťuje, že dokáže rozpoznat a schválit ověřeného klienta. Jeho síťová konfigurace zajišťuje, že způsobilí klienti s ním mohou vyjednávat prostřednictvím jakéhokoli systému brány firewall.
Klientský počítač požaduje přístup k exportovaným datům, obvykle vydáním příkazu. Dotazuje se na server (rpcbind), který používá port NFS, a následně se k němu připojí.
Pokud vše proběhne bez chyb, uživatelé na klientském počítači budou moci prohlížet a pracovat s nainstalovanými systémy souborů na serveru v rámci povolených parametrů.

Je třeba také poznamenat, že může dojít také k automatizaci procesu Network File System – možná pomocí etc/fstab a/nebo jiných podobných nástrojů.

Dosavadní vývoj

Do 21. století konkurenční protokoly DFS a AFS nedosáhly žádného většího komerčního úspěchu ve srovnání se Network File System. IBM, která dříve získala všechna komerční práva na výše uvedené technologie, darovala většinu zdrojového kódu AFS komunitě svobodného softwaru v roce 2000. Projekt Open AFS existuje dodnes. Na začátku roku 2005 IBM oznámila konec prodeje AFS a DFS.

V lednu 2010 společnost Panasas navrhla NFS v 4.1 založené na technologii, která zlepšuje možnosti paralelního přístupu k datům. Protokol Network File System v 4.1 definuje metodu pro oddělení metadat systému souborů od umístění konkrétních souborů. Jde tedy nad rámec pouhého oddělení názvu/dat.

Co je NFS této verze v praxi? Výše uvedená funkce jej odlišuje od tradičního protokolu, který obsahuje názvy souborů a jejich data pod jedním připojením k serveru. S Network File System v 4.1 mohou být některé soubory sdíleny mezi víceuzlovými servery, ale zapojení klienta do sdílení metadat a dat je omezené.

Při implementaci čtvrté distribuce protokolu je server NFS sadou serverových prostředků nebo komponent; předpokládá se, že jsou řízeny serverem metadat.

Klient stále kontaktuje jediný server metadat, aby mohl procházet jmenným prostorem nebo s ním interagovat. Při přesouvání souborů na server a ze serveru může přímo interagovat se sadou dat vlastněných skupinou NFS.

Síťové služby

Přednáška 10

Nazývá se sada serverových a klientských částí operačního systému, které poskytují přístup ke konkrétnímu typu počítačového zdroje prostřednictvím sítě síťová služba. Klientská část odesílá síťové požadavky na serverovou část jiného počítače. Serverová část uspokojuje požadavky na místní serverové prostředky. Klientská část je aktivní, serverová část pasivní.

V síťové komunikaci hraje významnou roli síťový přístup k systému souborů. V tomto případě se tvoří klientská a serverová část spolu se síťovým souborovým systémem spisová služba

Klíčovou součástí distribuovaného OS je síťový souborový systém. Síťový souborový systém je podporován jedním nebo více počítači ukládajícími soubory (souborové servery)

Klient počítače připojují nebo připojují tyto systémy souborů ke svým lokálním systémům souborů

Spisová služba zahrnuje serverové programy a klientské programy, které komunikují přes síť pomocí protokolu.

Souborové služby zahrnují samotnou souborovou službu (operace se soubory) a adresářovou službu (správa adresářů)

Model síťové souborové služby obsahuje následující prvky:

Místní systém souborů (FAT, NTFS)

Rozhraní místního systému souborů (systémová volání)

Server síťového systému souborů

Klient síťového souborového systému (Windows Explorer, UNIX shell atd.)

Rozhraní síťového systému souborů (opakuje volání místního systému souborů)

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

Rozhraní síťového systému souborů

Existuje několik typů rozhraní, která se vyznačují:

Struktura souboru. Většina síťových souborových systémů podporuje ploché soubory

Modifikovatelnost souboru. Většina síťových souborových systémů má schopnost upravit soubor. Některé distribuované systémy souborů zakazují operace úprav. Je možné pouze vytvářet a číst. U takových souborů je jednodušší organizovat ukládání do mezipaměti a replikaci.

Sémantika oddělení souborů:

Sémantika UNIX (centralizovaný). Pokud čtení následuje po více zápisech, přečte se nejnovější aktualizace. Tento princip je také možný v distribuovaném souborovém systému za předpokladu, že existuje jeden souborový server a na klientovi není žádné ukládání souborů do mezipaměti.

Sémantika relace. Změny začínají po otevření souboru a jsou dokončeny po zavření souboru. Jinými slovy, u ostatních procesů jsou změny viditelné až po zavření souboru. V tomto případě nastává problém při sdílení souboru. Sémantika neměnných souborů. Soubor lze pouze vytvořit a číst. Soubor můžete také znovu vytvořit pod jiným názvem. Soubor tedy nelze upravit, ale lze jej nahradit novým souborem. Není problém se sdílením.

Transakční mechanismus. Jedná se o způsob práce se sdílenými soubory pomocí transakčního mechanismu (nedělitelné operace)

Řízení přístupu. Například pro Windows NT/2000 existují dva mechanismy: na úrovni adresářů (pro FAT) a na úrovni souborů (NTFS)

Přístupová jednotka. Kompletní model nahrávání/stahování souborů (FTP). Druhým modelem je použití souborových operací.

Protokol NFS (Network File Server) je otevřený standard pro poskytování vzdáleného uživatelského přístupu k systémům souborů. Centralizované souborové systémy na něm postavené usnadňují každodenní úkoly, jako je zálohování nebo antivirová kontrola, a konsolidované diskové oddíly se udržují snadněji než mnoho menších, distribuovaných.

Kromě poskytování centralizovaného úložiště se NFS ukázalo jako velmi užitečné pro další aplikace, včetně bezdiskových a tenkých klientů, síťového klastrování a spolupráce middlewaru.

Lepší pochopení jak samotného protokolu, tak detailů jeho implementace usnadní zvládnutí praktických problémů. Tento článek je věnován NFS a skládá se ze dvou logických částí: nejprve popisuje samotný protokol a cíle stanovené při jeho vývoji a poté implementaci NFS v Solarisu a UNIXu.

KDE TO VŠE ZAČALO...

Protokol NFS byl vyvinut společností Sun Microsystems a na internetu se objevil v roce 1989 jako RFC 1094 pod následujícím názvem: Network File System Protocol Specification (NFS). Zajímavostí je, že strategie Novellu v té době směřovala k dalšímu zlepšování souborových služeb. Až do nedávné doby, než se rozběhlo hnutí s otevřeným zdrojovým kódem, se Sun zdráhal sdílet tajemství svých síťových řešení, ale už tehdy společnost chápala důležitost interoperability s jinými systémy.

RFC 1094 obsahoval dvě původní specifikace. V době svého zveřejnění Sun již vyvíjel další, třetí verzi specifikace, která je uvedena v RFC 1813 „NFS Version 3 Protocol Specification“. Verze 4 tohoto protokolu je definována v RFC 3010, protokol NFS verze 4.

NFS je široce používán na všech typech hostitelů UNIX, v sítích Microsoft a Novell a na řešeních IBM, jako jsou AS400 a OS/390. Ačkoli je NFS mimo království sítí neznámý, je možná nejrozšířenějším síťovým souborovým systémem nezávislým na platformě.

UNIX BYL GENEZE

Přestože je NFS platformově nezávislý systém, jeho předkem je UNIX. Jinými slovy, hierarchická architektura architektury a metody přístupu k souborům, včetně struktury systému souborů, způsobů identifikace uživatelů a skupin a technik zpracování souborů, jsou všechny velmi podobné souborovému systému UNIX. Například souborový systém NFS, který je konstrukčně identický se souborovým systémem UNIX, je připojen přímo k němu. Při práci s NFS na jiných operačních systémech podléhají parametry identifikace uživatele a přístupová práva k souborům mapování.

NFS

NFS je navržen pro použití v architektuře klient-server. Klient přistupuje k systému souborů exportovanému serverem NFS prostřednictvím přípojného bodu na klientovi. Tento přístup je obvykle pro klientskou aplikaci transparentní.

Na rozdíl od mnoha systémů klient-server používá NFS k výměně informací vzdálená volání procedur (RPC). Klient obvykle naváže spojení se známým portem a poté v souladu s protokolem odešle požadavek na provedení konkrétní akce. V případě vzdáleného volání procedur klient vytvoří volání procedury a poté jej odešle na server k provedení. Podrobný popis NFS bude uveden níže.

Předpokládejme například, že klient připojil adresář usr2 do místního kořenového systému souborů:

/root/usr2/ -> remote:/root/usr/

Pokud klientská aplikace potřebuje prostředky z tohoto adresáře, jednoduše odešle operačnímu systému požadavek na něj a název souboru, který udělí přístup prostřednictvím klienta NFS. Jako příklad uveďme jednoduchý příkaz UNIX cd, který „neví nic“ o síťových protokolech. Tým

CD /root/usr2/

umístí pracovní adresář na vzdálený souborový systém, „aniž by si uvědomoval“ (uživatel to také nepotřebuje), že souborový systém je vzdálený.

Po obdržení požadavku NFS server zkontroluje, zda má uživatel právo požadovanou akci provést a v případě kladné odpovědi ji provede.

POZNÁME SE LÉPE

Z pohledu klienta se proces lokálního připojení vzdáleného souborového systému pomocí NFS skládá z několika kroků. Jak bylo zmíněno, klient NFS vydá vzdálené volání procedury, aby ji provedl na serveru. Všimněte si, že v systému UNIX je klientem jeden program (příkaz mount), zatímco server je ve skutečnosti implementován jako několik programů s následující minimální sadou: služba mapování portů, démon připojení a server NFS.

Příkaz client mount nejprve komunikuje se službou překladu portů serveru, která naslouchá požadavkům na portu 111. Většina implementací příkazu client mount podporuje více verzí NFS, což zvyšuje pravděpodobnost nalezení společné verze protokolu pro klienta a server. Vyhledávání se provádí počínaje nejvyšší verzí, takže když je nalezena společná, automaticky se stane nejnovější verzí podporovanou klientem a serverem.

(Předložený materiál je zaměřen na třetí verzi NFS, protože je v současnosti nejrozšířenější. Čtvrtá verze zatím není podporována většinou implementací.)

Služba překladu portů serveru odpovídá na požadavky na základě podporovaného protokolu a portu, na kterém běží démon připojení. Klientský program připojení nejprve vytvoří připojení k démonu připojení serveru a poté mu vydá příkaz připojení prostřednictvím RPC. Pokud je tento postup úspěšný, pak se klientská aplikace připojí k serveru NFS (port 2049) a pomocí jedné z 20 vzdálených procedur definovaných v RFC 1813 a uvedených v tabulce 1 získá přístup ke vzdálenému systému souborů.

Význam většiny příkazů je intuitivní a nezpůsobuje správcům systému žádné potíže. Následující výpis získaný pomocí tcdump ilustruje příkaz read vytvořený příkazem cat UNIX pro čtení souboru s názvem test-file:

10:30:16.012010 eth0 > 192.168.1.254.

3476097947 > 192.168.1.252.2049: 144 vyhledávání fh 32.0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254.

3476097947 > 192.168.1.252.2049: 144 vyhledávání fh 32.0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.2589.347 odpověď 24 307 (DF) 10:30: 16.012729 eth0 192.168 .1.254.3476097947: odpověď ok 128 vyhledávání fh 32.0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 čtení fh 32.0/ 224307 4096 bajtů @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 čtení fh 32.0/ 224307 4096 bajtů @ 0 10:30:16.013650 eth0 192.168.49258.01 čtení ) 0:16.013650 eth0 192.168.1.254.3492875163 : odpovědět ok 108 přečtení (DF)

NFS byl tradičně implementován přes UDP. Některé verze NFS však podporují TCP (podpora TCP je definována ve specifikaci protokolu). Hlavní výhodou TCP je efektivnější mechanismus opětovného přenosu v nespolehlivých sítích. (Pokud u protokolu UDP dojde k chybě, je znovu odeslána kompletní zpráva RPC skládající se z několika paketů UDP. S protokolem TCP se znovu odešle pouze poškozený fragment.)

PŘÍSTUP NFS

Implementace NFS obvykle podporují čtyři způsoby udělování přístupových práv: prostřednictvím atributů uživatele/souboru, na úrovni sdílených prostředků, na úrovni hlavního uzlu a jako kombinaci dalších metod přístupu.

Přístup k hlavnímu uzlu vám umožňuje připojit souborový systém pouze na konkrétní uzly, což je obecně dobrý nápad, protože souborové systémy lze snadno vytvořit na jakémkoli uzlu s podporou NFS.

Kombinovaný přístup jednoduše kombinuje výše uvedené typy (například přístup na sdílené úrovni s přístupem uděleným konkrétnímu uživateli) nebo umožňuje uživatelům přistupovat k NFS pouze z určitého uzlu.

NFS VE STYLU PENGUIN

Materiál související s Linuxem je založen na Red Hat 6.2 s jádrem verze 2.4.9, který je dodáván s nfs-utils verze 0.1.6. Existují také novější verze: v době psaní tohoto článku je nejnovější aktualizace balíčku nfs-utils 0.3.1. Lze jej stáhnout z: .

Balíček nfs-utils obsahuje následující spustitelné soubory: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount a statd.

Bohužel podpora NFS je někdy pro správce Linuxu zdrojem zmatků, protože dostupnost konkrétní funkce přímo závisí na číslech verzí jak jádra, tak balíčku nfs-utils. Naštěstí se věci v této oblasti zlepšují, nejnovější distribuce obsahují nejnovější verze obou. Pro předchozí verze poskytuje sekce 2.4 NFS-HOWTO kompletní seznam systémových funkcí dostupných pro každou kombinaci jádra a balíčku nfs-utils. Vývojáři udržují zpětnou kompatibilitu balíčku s dřívějšími verzemi, přičemž věnují velkou pozornost zajištění bezpečnosti a eliminaci softwarových chyb.

Podpora NFS by měla být spuštěna během kompilace jádra. V případě potřeby by měla být do jádra přidána schopnost pracovat s NFS verze 3.

U distribucí, které podporují linuxconf, je snadné nakonfigurovat služby NFS pro klienty i servery. Rychlý způsob instalace NFS pomocí linuxconf však neposkytuje informace o tom, jaké soubory byly vytvořeny nebo upraveny, což je velmi důležité pro to, aby správce znal situaci v případě selhání systému. Architektura NFS na Linuxu je volně spojena s verzí BSD, takže potřebné podpůrné soubory a programy mohou správci s BSD, Sun OS 2.5 nebo staršími verzemi NFS snadno najít.

Soubor /etc/exports, stejně jako v dřívějších verzích BSD, definuje systémy souborů, ke kterým mají klienti NFS povolen přístup. Kromě toho obsahuje řadu dalších funkcí souvisejících se správou a bezpečnostními otázkami, které správci poskytují prostředky pro jemné doladění. Jedná se o textový soubor sestávající z položek, prázdných nebo komentovaných řádků (komentáře začínají symbolem #).

Řekněme, že chceme klientům poskytnout přístup pouze pro čtení k adresáři /home v uzlu Lefty. To by odpovídalo následující položce v /etc/exports:

/home (ro)

Zde musíme systému sdělit, které adresáře zpřístupníme pomocí démona připojení rpc.mountd:

# exportfs -r exportfs: V /home (ro) není zadán žádný název hostitele, zadejte *(ro), abyste se vyhnuli varování #

Po spuštění příkaz exportfs vydá varování, že /etc/exports neomezuje přístup k určitému uzlu, a vytvoří odpovídající záznam v /var/lib/nfs/etab z /etc/exports, který řekne, které zdroje lze zobrazit pomocí cat :

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

Další možnosti uvedené v etab zahrnují výchozí hodnoty používané systémem NFS. Podrobnosti budou popsány níže. Chcete-li poskytnout přístup k adresáři /home, musíte spustit příslušné služby NFS:

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

Kdykoli po spuštění démona připojení (rpc.mountd) můžete zobrazit jednotlivé soubory dostupné pro výstup zobrazením obsahu souboru /proc/fs/nfs/exports:

# cat /proc/fs/nfs/exports # Verze 1.0 # Klient cesty (příznaky) # IP adresy /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

Totéž lze zobrazit pomocí příkazu showmount s parametrem -e:

# showmount -e Exportovat seznam pro leváky: /home (všichni) #

Když trochu skočíme dopředu, příkaz showmount lze také použít k určení všech připojených souborových systémů nebo jinými slovy ke zjištění, které uzly jsou klienty NFS pro systém, na kterém je spuštěn příkaz showmount. Příkaz showmount -a zobrazí seznam všech přípojných bodů klienta:

# showmount -a Všechny body připojení vlevo: 192.168.1.252:/home #

Jak je uvedeno výše, většina implementací NFS podporuje různé verze tohoto protokolu. Implementace Linuxu umožňuje omezit seznam verzí NFS, které lze spustit, zadáním přepínače -N pro démona připojení. Chcete-li například spustit NFS verze 3 a pouze verze 3, zadejte následující příkaz:

# rpc.mountd -N 1 -N 2

Častým uživatelům může být nepohodlné, že linuxový démon NFS (rpc.nfsd) čeká na balíčky verze 1 a verze 2, i když to má požadovaný účinek v podobě nepodpory odpovídajícího protokolu. Doufejme, že vývojáři budoucích verzí provedou potřebné opravy a podaří se jim dosáhnout větší konzistence mezi součástmi balíčku ve vztahu k různým verzím protokolu.

"PLAVÁT S TUČŇÁKY"

Přístup k výše nakonfigurovanému Lefty, exportovatelnému souborovému systému NFS založenému na Linuxu, závisí na operačním systému klienta. Styl instalace pro většinu operačních systémů rodiny UNIX je stejný jako u původních systémů Sun OS a BSD nebo novějších Solaris. Jelikož je tento článek o Linuxu i Solarisu, podívejme se na konfiguraci klienta Solaris 2.6 z pohledu navázání spojení s linuxovou verzí NFS, kterou jsme popsali výše.

Díky funkcím zděděným ze Solaris 2.6 jej lze snadno nakonfigurovat tak, aby fungoval jako klient NFS. To vyžaduje pouze jeden příkaz:

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

Za předpokladu, že předchozí příkaz mount byl úspěšný, příkaz mount bez parametrů vypíše následující:

# mount / on /dev/dsk/c0t0d0s0 čtení/zápis/setuid/ velké soubory v pondělí 3. září 10:17:56 2001 ... ... /tmp/tmp2 na 192.168.1.254:/home čtení/zápis/vzdálené na Po 3. září 23:19:25 2001

Pojďme analyzovat výstup tcpdump přijatý na uzlu Lefty poté, co uživatel zadal příkaz ls /tmp/tmp2 na uzlu Sunny:

# tcpdump host lefty a host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:07:43.490678 sunnyn.nfs 2191983953: odpověď ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: Neznámý/f0401 3,491463 levý. mcwrite.n.nfs > sunny.2191983954: odpověď ok 120 přístup c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus fh 8tes 7791/0.0 000 (DF) 06 :07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: odpověď ok 1000 readdirplus (DF)

Vidíme, že uzel Sunny požaduje popisovač souboru (fh) pro ls, na což uzel Lefty odpoví OK a vrátí strukturu adresářů. Sunny poté zkontroluje oprávnění k přístupu k obsahu adresáře (132 přístup fh) a obdrží od Lefty odpověď na povolení. Sunny node pak načte celý obsah adresáře pomocí rutiny readdirplus. Vzdálená volání procedur jsou popsána v RFC 1813 a jsou uvedena na začátku tohoto článku.

Ačkoli je sekvence příkazů pro přístup ke vzdáleným souborovým systémům velmi jednoduchá, řada okolností může způsobit, že se systém nepřipojí správně. Před připojením adresáře musí již bod připojení existovat, jinak musí být vytvořen pomocí příkazu mkdir. Obvykle je jedinou příčinou chyb na straně klienta nedostatek místního adresáře pro připojení. Většina problémů spojených s NFS je způsobena nesouladem mezi klientem a serverem nebo nesprávnou konfigurací serveru.

Nejjednodušší způsob, jak vyřešit problémy na serveru, je z uzlu, na kterém server běží. Pokud však za vás server spravuje někdo jiný, není to vždy možné. Rychlý způsob, jak zajistit, aby byly příslušné služby serveru správně nakonfigurovány, je použít příkaz rpcinfo s volbou -p. Z hostitele Solaris Sunny můžete určit, které procesy RPC jsou registrovány na hostiteli Linux:

# rpcinfo -p 192.168.1.254 program versus proto portová služba 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 stav 100024 104 0udtc 29 10 mount d /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Všimněte si, že zde jsou uvedeny také informace o verzi, což je docela užitečné, když systém vyžaduje podporu pro různé protokoly NFS. Pokud na serveru neběží nějaká služba, je nutné tuto situaci opravit. Pokud se připojení nezdaří, následující příkaz rpcinfo -p vám pomůže určit, že služba připojená na serveru není spuštěna:

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

Příkaz rpcinfo je velmi užitečný pro zjištění, zda je konkrétní vzdálený proces aktivní. Parametr -p je nejdůležitější z přepínačů. Chcete-li vidět všechny funkce rpcinfo, podívejte se na manuálovou stránku.

Dalším užitečným nástrojem je příkaz nfsstat. S jeho pomocí můžete zjistit, zda klienti skutečně přistupují k exportovanému souborovému systému, a také zobrazit statistické informace v souladu s verzí protokolu.

A konečně dalším docela užitečným nástrojem pro určování příčin selhání systému je tcpdump:

# tcpdump host lefty a host sunny -s512 tcpdump: poslech na eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF93816: lefty.mcwrite.n.nfs > sunny.2191984020: odpověď ok CHYBA vyhledávání 116: Žádný takový soubor nebo adresář (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 Neznámý/attr DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: odpověď ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:2289 sunny.y .n.nfs : 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: odpověď v pořádku 116 CHYBA vyhledávání: Žádný takový soubor nebo adresář (DF) 06:29: 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 vytvořit fh Neznámý/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > vytvořit sunny.2191984023: odpovědět Povolení odepřeno (DF)

Výše uvedený seznam, vytvořený provedením příkazu touch test.c, ukazuje následující sekvenci akcí: nejprve se dotykový příkaz pokusí o přístup k souboru s názvem test.c, poté hledá adresář se stejným názvem a po neúspěšných pokusech pokouší se vytvořit soubor test.c , což také nevede k úspěchu.

Pokud je souborový systém připojen, většina běžných chyb souvisí s normálními oprávněními UNIX. Použití uid nebo NIS+ na Sun pomáhá vyhnout se globálnímu nastavení oprávnění pro všechny systémy souborů. Někteří administrátoři praktikují „otevřené“ adresáře, kde je přístup pro čtení udělen „celému světu“. Tomu je však třeba se z bezpečnostních důvodů vyhnout. Bez ohledu na obavy o bezpečnost je tento přístup stále špatnou praxí, protože uživatelé jen zřídka vytvářejí data se záměrem, aby byla čitelná pro každého.

Přístup privilegovaného uživatele (root) k připojeným souborovým systémům NFS je řešen odlišně. Aby nedošlo k udělení neomezeného přístupu privilegovanému uživateli, jsou požadavky od privilegovaného uživatele zpracovány tak, jako by přicházely od uživatele nikdo. Tento výkonný mechanismus omezuje privilegovaný přístup uživatelů ke globálně čitelným a zapisovatelným souborům.

VERZE NFS SERVER SOLARIS

Konfigurace Solarisu, aby fungoval jako server NFS, je stejně snadná jako u Linuxu. Příkazy a umístění souborů se však mírně liší. Když se Solaris spustí, po dosažení úrovně běhu 3 se automaticky spustí služby NFS a exportují se všechny systémy souborů. Chcete-li tyto procesy spustit ručně, zadejte příkaz:

#/usr/lib/nfs/mountd

Chcete-li spustit démona připojení a server NFS, zadejte:

#/usr/lib/nfs/nfsd

Počínaje verzí 2.6 již Solaris nepoužívá exportní soubor k určení, které systémy souborů se mají exportovat. Soubory jsou nyní exportovány pomocí příkazu share. Řekněme, že chceme umožnit vzdáleným hostitelům připojit /export/home. Chcete-li to provést, zadejte následující příkaz:

Share -F nfs /export/home

Bezpečnostní opatření

ZABEZPEČENÍ V LINUXU

Některé systémové služby NFS založené na Linuxu mají další mechanismus pro omezení přístupu prostřednictvím řídicích seznamů nebo tabulek. Na interní úrovni je tento mechanismus implementován pomocí knihovny tcp_wrapper, která ke generování seznamů řízení přístupu používá dva soubory: /etc/hosts.allow a /etc/hosts/deny. Komplexní přehled pravidel pro práci s tcp_wrapper je nad rámec tohoto článku, ale základní princip je následující: srovnání se nejprve provede s etc/hosts.allow a poté s /etc/hosts. odmítnout. Pokud pravidlo není nalezeno, požadovaná systémová služba není prezentována. Chcete-li obejít tento poslední požadavek a poskytnout velmi vysokou úroveň zabezpečení, můžete na konec souboru /etc/hosts.deny přidat následující záznam:

VŠECHNY: Všechny

Poté můžete použít /etc/hosts.allow k nastavení jednoho nebo druhého provozního režimu. Například soubor /etc/hosts. allow, který jsem použil při psaní tohoto článku, obsahoval následující řádky:

Lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:1125.165.stat.192.155/055 68.1.0/255.255.255.0

To umožňuje určitý typ přístupu k hostitelům před udělením přístupu na úrovni aplikace. V systému Linux je přístup na úrovni aplikace řízen souborem /etc/exports. Skládá se z položek v následujícím formátu:

Exportovat adresář (mezera) hostitel|síť (možnosti)

"Exportní adresář" je adresář, pro který může démon nfsd zpracovávat požadavky. "Uzel|síť" je uzel nebo síť, která má přístup k exportovanému systému souborů, a "volby" definují omezení, která démon nfsd ukládá na použití tohoto sdíleného zdroje - přístup pouze pro čtení nebo mapování ID uživatele. .

Následující příklad poskytuje celé doméně mcwrite.net přístup pouze pro čtení k /home/mcwrite.net:

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

Další příklady lze nalézt v manuálové stránce exportů.

ZABEZPEČENÍ NFS V SOLARISU

V Solarisu je možnost poskytovat přístup k NFS podobná jako v Linuxu, ale v tomto případě jsou omezení nastavena pomocí určitých parametrů v příkazu share s přepínačem -o. Následující příklad ukazuje, jak povolit připojení /export/mcwrite.net pouze pro čtení na libovolném hostiteli v doméně mcwrite.net:

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

Manuální stránka pro share_nfs podrobnosti o udělení přístupu pomocí kontrolních seznamů na Solarisu.

Internetové zdroje

NFS a RPC nejsou bez děr. Obecně řečeno, NFS by se neměl používat při surfování na internetu. Nemůžete udělat díry do firewallů, abyste umožnili jakýkoli druh přístupu přes NFS. Pečlivě sledujte všechny vznikající opravy RPC a NFS a mnoho zdrojů informací o zabezpečení vám může pomoci. Dva nejoblíbenější zdroje jsou Bugtraq a CERT:

První z nich lze pravidelně prohlížet při hledání potřebných informací nebo přihlášením k odběru pravidelných newsletterů. Druhý z nich možná neposkytuje tak pohotové informace ve srovnání s jinými, ale v poměrně úplném objemu a bez odstínu senzacechtivosti, který je typický pro některé stránky věnované informační bezpečnosti.

NFS: pohodlný a slibný síťový souborový systém

Síťový souborový systém je síťová abstrakce nad běžným souborovým systémem, která umožňuje vzdálenému klientovi přistupovat k němu přes síť stejným způsobem jako při přístupu k lokálním souborovým systémům. Ačkoli NFS nebyl první síťový souborový systém, vyvinul se tak, aby se stal dnes nejschopnějším a nejoblíbenějším síťovým souborovým systémem v UNIXu. NFS umožňuje více uživatelům sdílet společný systém souborů a centralizuje data, aby se minimalizovalo místo na disku potřebné k jejich uložení.

Tento článek začíná stručným přehledem historie NFS a poté se přesune ke zkoumání architektury NFS a toho, jak by se mohla v budoucnu vyvíjet.

Stručná historie NFS

První síťový souborový systém se jmenoval FAL (File Access Listener) a byl vyvinut v roce 1976 společností DEC (Digital Equipment Corporation). Jednalo se o implementaci protokolu DAP (Data Access Protocol) a byl součástí sady protokolů DECnet. Stejně jako u TCP/IP, DEC zveřejnila specifikace pro své síťové protokoly, včetně protokolu DAP.

NFS byl první moderní síťový souborový systém postavený na protokolu IP. Jeho prototyp lze považovat za experimentální souborový systém vyvinutý v Sun Microsystems na počátku 80. let. Vzhledem k popularitě tohoto řešení byl protokol NFS představen jako specifikace RFC a následně se vyvinul v NFSv2. NFS se rychle etabloval jako standard díky své schopnosti spolupracovat s jinými klienty a servery.

Standard byl následně aktualizován na NFSv3, definovaný v RFC 1813. Tato verze protokolu byla škálovatelnější než předchozí verze a podporovala větší velikosti souborů (větší než 2 GB), asynchronní zápis a TCP jako transportní protokol. NFSv3 udával směr pro vývoj souborových systémů pro rozlehlé sítě (WAN). V roce 2000 přinesl RFC 3010 (revidovaný jako RFC 3530) NFS do podnikového prostředí. Sun představil bezpečnější NFSv4 se stavovou podporou (předchozí verze NFS nepodporovaly stavové úložiště, tj. byly klasifikovány jako bezstavové). V současné době je nejnovější verzí NFS verze 4.1, definovaná v RFC 5661, která přidává do protokolu rozšířením pNFS byla přidána podpora paralelního přístupu pro distribuované servery.

Historie NFS, včetně konkrétních RFC popisujících jeho verze, je znázorněna na obrázku 1.

Překvapivě je NFS ve vývoji téměř 30 let. Jedná se o výjimečně stabilní a přenosný síťový souborový systém s vynikající škálovatelností, výkonem a kvalitou služeb. S rostoucí rychlostí a klesající latencí při komunikaci v rámci sítě je NFS stále oblíbeným způsobem implementace souborového systému v síti. I v případě lokálních sítí virtualizace podporuje ukládání dat v síti, aby virtuálním strojům poskytla další mobilitu. NFS také podporuje nejnovější modely výpočetního prostředí zaměřené na optimalizaci virtuálních infrastruktur.

Architektura NFS

NFS používá standardní architektonický model klient-server (jak je znázorněno na obrázku 2). Server je zodpovědný za implementaci sdíleného systému souborů a úložiště, ke kterému se klienti připojují. Klient implementuje uživatelské rozhraní ke sdílenému souborovému systému připojenému do lokálního souborového prostoru klienta.

Obrázek 2. Implementace modelu klient-server v architektuře NFS

V Linuxu poskytuje přepínač virtuálního souborového systému (VFS) prostředky pro podporu více systémů souborů (například souborový systém ISO 9660 na disku CD-ROM a souborový systém ext3fs na místním pevném disku) současně na jednom hostiteli. . Virtuální přepínač určuje, na kterou jednotku je požadavek zadán, a tedy který souborový systém by měl být použit ke zpracování požadavku. Proto má NFS stejnou kompatibilitu jako jiné systémy souborů používané v Linuxu. Jediný rozdíl oproti systému NFS spočívá v tom, že místo toho, aby byly zpracovány lokálně na hostiteli, mohou být I/O požadavky odesílány do sítě k provedení.

VFS určí, že přijatý požadavek je NFS a předá ho obsluze NFS umístěné v jádře. Obslužná rutina NFS zpracuje I/O požadavek a převede jej do NFS procedury (OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE atd.). Tyto postupy popsané v samostatné specifikaci RFC definují chování protokolu NFS. Požadovaná procedura je vybrána v závislosti na požadavku a je provedena pomocí technologie RPC (remote procedure call). Jak jeho název napovídá, RPC umožňuje volání procedur mezi různými systémy. Služba RPC zřetězí požadavek NFS se svými argumenty a odešle výsledek příslušnému vzdálenému hostiteli, poté sleduje příjem a zpracování odpovědi, aby ji vrátil žadateli.

RPC také obsahuje důležitou vrstvu XDR ( externí reprezentace dat- nezávislá reprezentace dat), zajišťující, že všichni uživatelé NFS používají stejný formát pro stejné typy dat. Když platforma odešle požadavek, datový typ, který používá, se může lišit od datového typu použitého na hostiteli zpracovávajícím požadavek. Technologie XDR se stará o práci při převodu typů do standardní reprezentace (XDR), aby platformy využívající různé architektury mohly vzájemně spolupracovat a sdílet systémy souborů. XDR definuje bitový formát pro typy, jako je float, a pořadí bajtů pro typy, jako jsou pole s konstantní a proměnnou délkou. Ačkoli je XDR primárně známé pro své použití v NFS, tato specifikace může být užitečná ve všech případech, kdy musíte pracovat ve stejném prostředí s různými architekturami.

Poté, co XDR přeloží data do standardní reprezentace, je požadavek odeslán přes síť pomocí specifického transportního protokolu. Dřívější implementace NFS používaly UDP, ale dnes se pro větší spolehlivost používá TCP.

Podobný algoritmus se používá na straně serveru NFS. Požadavek putuje po síťovém zásobníku přes vrstvu RPC/XDR (pro převod datových typů podle architektury serveru) a na server NFS, který je zodpovědný za zpracování požadavku. Tam je požadavek předán démonu NFS, aby určil cílový souborový systém, kterému je adresován, a poté znovu přejde do VFS, aby získal přístup k tomuto systému souborů na místním disku. Kompletní schéma tohoto procesu je znázorněno na obrázku 3. V tomto případě je místním souborovým systémem serveru standardní souborový systém Linux, například ext4fs. V podstatě NFS není souborový systém v tradičním slova smyslu, ale protokol pro vzdálený přístup k souborovým systémům.

Pro sítě s dlouhou latencí nabízí NFSv4 speciální složený postup ( složený postup). Tento postup umožňuje umístit více volání RPC v rámci jednoho požadavku, aby se minimalizovaly náklady na odesílání požadavků přes síť. Tento postup také implementuje mechanismus funkce zpětného volání pro příjem odpovědí.

protokol NFS

Když klient začne používat NFS, první akcí je provedení operace připojení, což je připojení vzdáleného systému souborů do prostoru lokálního systému souborů. Tento proces začíná voláním procedury mount (jedna z funkcí systému Linux), která je přesměrována přes VFS na komponentu NFS. Potom volání RPC funkce get_port na vzdáleném serveru určí číslo portu, který bude použit pro připojení, a klient odešle požadavek na připojení prostřednictvím RPC. Tento požadavek na straně serveru zpracovává speciální démon rpc.mountd, který je zodpovědný za protokol připojení ( montážní protokol). Démon zkontroluje, zda je souborový systém požadovaný klientem v seznamu systémů dostupných na daném serveru. Pokud požadovaný systém existuje a klient k němu má přístup, odpověď RPC na připojení udává deskriptor systému souborů. Klient uchovává informace o místních a vzdálených přípojných bodech a je schopen zadávat I/O požadavky. Protokol připojení není bezpečný z hlediska zabezpečení, takže NFSv4 místo toho používá interní volání RPC, která mohou také spravovat body připojení.

Chcete-li číst soubor, musíte jej nejprve otevřít. Místo toho v RPC neexistuje žádná procedura OPEN, klient jednoduše zkontroluje, že zadaný soubor a adresář existuje v připojeném systému souborů. Klient začíná zadáním požadavku GETATTR RPC do adresáře, který vrátí atributy adresáře nebo indikátor, že adresář neexistuje. Dále, aby zkontroloval přítomnost souboru, klient vydá požadavek LOOKUP RPC. Pokud soubor existuje, provede se na něj požadavek GETATTR RPC, aby se zjistily atributy souboru. Pomocí informací získaných z úspěšných volání LOOKUP a GETATTR klient vytvoří popisovač souboru, který je poskytován uživateli pro budoucí požadavky.

Jakmile je soubor identifikován ve vzdáleném systému souborů, může klient zadávat požadavky RPC READ. Tento požadavek se skládá z deskriptoru souboru, stavu, offsetu a počtu bajtů ke čtení. Klient používá stav ( stát) zjistit, zda lze operaci v tuto chvíli provést, tzn. Je soubor uzamčen? Offset ( offset) označuje, na jaké pozici začít číst, a počítadlo bajtů ( počítat) určuje, kolik bajtů je třeba přečíst. V důsledku volání RPC READ server nevrací vždy tolik bajtů, kolik bylo požadováno, ale spolu s vrácenými daty vždy hlásí, kolik bajtů bylo odesláno klientovi.

Inovace v NFS

Největší zájem jsou o dvě nejnovější verze NFS – 4 a 4.1, jejichž příklady si můžete prostudovat nejdůležitější aspekty vývoje technologie NFS.

Než byl NFSv4 k dispozici pro provádění úloh správy souborů, jako je připojení, zamykání atd. existovaly speciální doplňkové protokoly. V NFSv4 byl proces správy souborů zjednodušen na jediný protokol; Počínaje touto verzí se navíc UDP již nepoužívá jako transportní protokol. NFSv4 zahrnuje podporu sémantiky přístupu k souborům v systémech UNIX a Windows®, což umožňuje NFS přirozeně se integrovat do jiných operačních systémů.

NFSv4.1 představil koncept paralelní NFS(paralelní NFS - pNFS). Pro zajištění vyšší úrovně škálovatelnosti implementuje NFSv4.1 architekturu, ve které data a metadata ( označení) jsou distribuovány mezi zařízeními podobným způsobem, jako se to dělá v clusterových souborových systémech. Jak je znázorněno v , pNFS rozděluje ekosystém na tři složky: klient, server a úložiště. V tomto případě se objeví dva kanály: jeden pro přenos dat a druhý pro přenos řídicích příkazů. pNFS odděluje data od metadat, která je popisují, a poskytuje dvoukanálovou architekturu. Když chce klient získat přístup k souboru, server mu odešle metadata s „označením“. Metadata obsahují informace o umístění souboru na úložných zařízeních. Jakmile má klient tyto informace, může k úložišti přistupovat přímo, aniž by musel interagovat se serverem, což zlepšuje škálovatelnost a výkon. Když klient ukončí práci se souborem, potvrdí provedené změny v souboru a jeho „označení“. V případě potřeby si server může od klienta vyžádat metadata s označením.

S příchodem pNFS bylo do protokolu NFS přidáno několik nových operací na podporu takového mechanismu. Metoda LayoutGet se používá k načtení metadat ze serveru, metoda LayoutReturn „uvolňuje“ metadata „zachycená“ klientem a metoda LayoutCommit načítá „rozvržení“ přijaté od klienta do úložiště, aby bylo dostupné ostatním uživatelům. Server může vyvolat metadata z klienta pomocí metody LayoutRecall. „Tagged“ metadata jsou distribuována na více úložných zařízeních, aby byl zajištěn paralelní přístup a vysoký výkon.

Data a metadata jsou uložena na úložných zařízeních. Klienti mohou provádět přímé I/O požadavky na základě přijatého označení a server NFSv4.1 ukládá a spravuje metadata. Tato funkce sama o sobě není nová, ale pNFS přidal podporu pro různé způsoby přístupu k úložným zařízením. Dnes pNFS podporuje použití blokových protokolů (Fibre Channel), objektových protokolů a samotného NFS (ani ve formě pNFS).

Vývoj NFS pokračuje a v září 2010 byly zveřejněny požadavky na NFSv4.2. Některé z inovací souvisí s probíhající migrací technologií pro ukládání dat směrem k virtualizaci. Například ve virtuálních prostředích s hypervizorem velmi pravděpodobně dochází k duplikaci dat (více operačních systémů čte/zapisuje a ukládá do mezipaměti stejná data). Z tohoto důvodu je žádoucí, aby úložný systém jako celek pochopil, kde dochází k duplikaci. Tento přístup pomůže ušetřit prostor mezipaměti klienta a celkovou kapacitu úložiště. NFSv4.2 navrhuje k vyřešení tohoto problému použít "blokovou mapu sdílených bloků". Vzhledem k tomu, že moderní úložné systémy jsou stále více vybaveny vlastním interním výpočetním výkonem, zavádí se kopírování na straně serveru, aby se snížilo břemeno kopírování dat přes interní síť, když to lze efektivně provádět na samotném úložném zařízení. Mezi další inovace patří ukládání do mezipaměti podsouborů pro flash paměť a doporučení pro ladění I/O na straně klienta (jako je použití mapadvise).

NFS alternativy

Ačkoli je NFS nejoblíbenějším síťovým souborovým systémem v UNIXu a Linuxu, existují kromě něj i další síťové systémy souborů. Na platformě Windows® se nejčastěji používá SMB, také známý jako CIFS; OS Windows však také podporuje NFS, stejně jako Linux podporuje SMB.

Jeden z nejnovějších distribuovaných souborových systémů podporovaných na Linuxu, Ceph, je od základu navržen jako souborový systém odolný proti chybám a vyhovující standardu POSIX. Více informací o Cephu naleznete v sekci.

Za zmínku také stojí souborové systémy OpenAFS (Open Source verze distribuovaného souborového systému Andrew, vyvinutá na Carnegie Mellon University a IBM Corporation), GlusterFS (univerzální distribuovaný souborový systém pro organizaci škálovatelného úložiště dat) a Luster (masivně paralelní síťový souborový systém pro clusterová řešení). Všechny tyto open source systémy lze použít k vybudování distribuovaného úložiště.

Závěr

Vývoj souborového systému NFS pokračuje. Podobně jako operační systém Linux, který může podporovat jak low-end, vestavěná, tak i high-end řešení, NFS poskytuje architekturu pro škálovatelná úložná řešení vhodná pro jednotlivce i organizace. Když se podíváte na cestu, kterou již NFS urazil, a na vyhlídky jeho budoucího vývoje, je jasné, že tento souborový systém bude i nadále měnit způsob, jakým přemýšlíme o tom, jak jsou implementovány a používány technologie ukládání souborů.

Oblíbené v kategorii: