Domov › Nastavení › Nfs protokol co. Síťová souborová služba. Co je potřeba, aby to fungovalo

Nfs protokol co. Síťová souborová služba. Co je potřeba, aby to fungovalo

Dobré odpoledne, čtenáři a hosté. Mezi příspěvky byla velmi dlouhá pauza, ale jsem zpět v akci). V dnešním článku se podívám práce protokol NFS , stejně jako nastavení serveru NFS a klienta NFS v systému Linux.

Úvod do NFS

NFS (Síť Systém souborů - síťový souborový systém) dle mého názoru - ideální řešení na lokální síti, kde je potřeba rychlá (rychlejší ve srovnání se SAMBA a méně náročná na zdroje ve srovnání se vzdálenými souborovými systémy s šifrováním - sshfs, SFTP atd...) výměna dat a není na přední bezpečnost přenášené informace. protokol NFS umožňuje připojit vzdálené systémy souborů přes síť do místního adresářového stromu, jako by to byl souborový systém připojeného disku. Tedy lokální aplikace může pracovat se vzdáleným souborovým systémem jako s lokálním. Ale musíte být opatrní (!). nastavení NFS, protože při určité konfiguraci je možné zmrazit operační systém klienta při čekání na nekonečné I/O. protokol NFS práce založené protokol RPC, což je stále mimo mé chápání)), takže materiál v článku bude trochu vágní... Než budete moci používat NFS, ať už je to server nebo klient, musíte se ujistit, že vaše jádro podporuje soubor NFS systém. Můžete zkontrolovat, zda jádro podporuje souborový systém NFS, vyhledáním přítomnosti odpovídajících řádků v souboru /proc/filesystems:

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

Pokud zadané řádky v souboru /proc/filesystems se nezobrazí, musíte nainstalovat balíčky popsané níže. To vám s největší pravděpodobností umožní nainstalovat závislé moduly jádra pro podporu požadovaných souborových systémů. Pokud se po instalaci balíčků v zadaném souboru nezobrazí podpora NFS, budete muset tuto funkci povolit.

Příběh Síťový souborový systém

protokol NFS vyvinutý společností Sun Microsystems a ve své historii má 4 verze. NFSv1 byl vyvinut v roce 1989 a byl experimentální, běžící na protokolu UDP. Verze 1 je popsána v . NFSv2 byla vydána ve stejném roce 1989, popsaná stejným RFC1094 a také založená na protokolu UDP, přičemž neumožňovala číst ze souboru více než 2 GB. NFSv3 dokončena v roce 1995 a popsána v . Hlavními inovacemi třetí verze byla podpora souborů velká velikost, byla přidána podpora protokolu TCP a velkých TCP paketů, což výrazně zrychlilo výkon technologie. NFSv4 dokončena v roce 2000 a popsána v RFC 3010, revidována v roce 2003 a popsána v . Čtvrtá verze zahrnovala vylepšení výkonu, podporu různých autentizačních prostředků (zejména Kerberos a LIPKEY využívající protokol RPCSEC GSS) a seznamy řízení přístupu (typy POSIX i Windows). NFS verze v4.1 byla schválena IESG v roce 2010 a obdržela číslo . Důležitou novinkou ve verzi 4.1 je specifikace pNFS - Parallel NFS, což je mechanismus pro paralelní klientský přístup NFS k datům z více distribuovaných NFS serverů. Přítomnost takového mechanismu ve standardu síťového souborového systému pomůže vybudovat distribuované „cloudové“ úložiště a informační systémy.

NFS server

Od té doby, co máme NFS- Tohle síť souborový systém, pak je to nutné. (můžete si také přečíst článek). Dále je nutné. V Debianu je to balíček nfs-kernel-server A nfs-běžný, v RedHat je to balíček nfs-utils. A také musíte povolit, aby démon běžel na požadovaných úrovních provádění OS (příkaz v RedHat - /sbin/chkconfig nfs zapnuto, v Debianu - /usr/sbin/update-rc.d Výchozí nastavení nfs-kernel-server).

Nainstalované balíčky v Debianu se spouštějí v následujícím pořadí:

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx 1 kořenový adresář 20. října 18 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 kořenový adresář 27. října> 01:23 S16nfs-server -> ../init.d/nfs-common lrwxrwxrwx 1 root /nfs-kernel-server

To znamená, že začíná jako první nfs-běžný, pak samotný server nfs-kernel-server. V RedHatu je situace podobná, s jedinou výjimkou, že se nazývá první skript nfslock a server se nazývá jednoduše nfs. O nfs-běžný Webová stránka debianu nám říká toto doslovně: sdílené soubory pro klienta a server NFS, musí být tento balíček nainstalován na počítači, který bude fungovat jako klient nebo server NFS. Balíček obsahuje programy: lockd, statd, showmount, nfsstat, gssd a idmapd. Zobrazení obsahu spouštěcího skriptu /etc/init.d/nfs-common můžete sledovat následující sekvenci práce: skript kontroluje přítomnost spustitelného binárního souboru /sbin/rpc.statd, kontroluje přítomnost v souborech /etc/default/nfs-common, /etc/fstab A /etc/exports parametry, které vyžadují spuštění démonů idmapd A gssd , spustí démona /sbin/rpc.statd , poté před spuštěním /usr/sbin/rpc.idmapd A /usr/sbin/rpc.gssd zkontroluje přítomnost těchto spustitelných binárních souborů a poté pro démon /usr/sbin/rpc.idmapd kontroluje dostupnost sunrpc, nfs A nfsd, stejně jako podpora souborového systému rpc_pipefs v jádře (to znamená mít jej v souboru /proc/filesystems), pokud je vše úspěšné, začíná /usr/sbin/rpc.idmapd . Navíc pro démona /usr/sbin/rpc.gssd kontroly modul jádra rpcsec_gss_krb5 a spustí démona.

Pokud si prohlédnete obsah Spouštěcí skript serveru NFS v Debianu ( /etc/init.d/nfs-kernel-server), pak můžete postupovat v následujícím pořadí: při spuštění skript zkontroluje existenci souboru /etc/exports, dostupnost nfsd, dostupnost podpory souborový systém NFS v (tj. v souboru /proc/filesystems), pokud je vše na svém místě, spustí se démon /usr/sbin/rpc.nfsd , poté zkontroluje, zda je parametr zadán NEED_SVCGSD(nastaveno v souboru nastavení serveru /etc/default/nfs-kernel-server) a pokud je zadán, spustí démona /usr/sbin/rpc.svcgssd , spustí démona jako poslední /usr/sbin/rpc.mountd . Z tohoto skriptu je to jasné Provoz NFS serveru se skládá z démony rpc.nfsd, rpc.mountd a pokud se používá ověřování Kerberos, pak démon rcp.svcgssd. V red hat stále běží démon rpc.rquotad a nfslogd (Z nějakého důvodu jsem v Debianu nenašel informace o tomto démonovi a důvodech jeho absence, zřejmě byl smazán...).

Z toho je jasné, že Server Network File System se skládá z následujících procesů (čti: démoni), který se nachází v adresářích /sbin a /usr/sbin:

V NFSv4 se při použití Kerberos spouštějí další démoni:

rpc.gssd- Démon NFSv4 poskytuje metody ověřování prostřednictvím GSS-API (autentizace Kerberos). Funguje na klientovi i serveru.
rpc.svcgssd- NFSv4 serverový démon, který poskytuje autentizaci klienta na straně serveru.

portmap a protokol RPC (Sun RPC)

Kromě výše uvedených balíčků vyžadují NFSv2 a v3 doplňkový balíček portmap(v novějších distribucích nahrazeno přejmenováním na rpcbind). Tento balíček obvykle se instaluje automaticky s NFS jako závislý a implementuje provoz RPC serveru, to znamená, že je zodpovědný za dynamické přidělování portů pro některé služby registrované v RPC server. Doslova podle dokumentace se jedná o server, který převádí čísla programů RPC (Remote Procedure Call) na čísla portů TCP/UDP. portmap funguje na několika entitách: RPC volání nebo požadavky, TCP/ UDP port ami,verze protokolu(tcp nebo udp), čísla programů A verze softwaru. Démon portmap je spuštěn skriptem /etc/init.d/portmap před spuštěním služeb NFS.

Stručně řečeno, úkolem serveru RPC (Remote Procedure Call) je zpracovávat volání RPC (takzvané procedury RPC) z místních a vzdálených procesů. Pomocí volání RPC se služby registrují nebo odstraňují do/z mapovače portů (také známý jako mapovač portů, aka portmap, aka portmapper, aka, v nových verzích, rpcbind) a klienti používají volání RPC k odesílání požadavků na mapovač portů, aby získali potřebné informace. . Uživatelsky přívětivé názvy programových služeb a jejich odpovídající čísla jsou definována v souboru /etc/rpc. Jakmile jakákoli služba odešle odpovídající požadavek a zaregistruje se na RPC serveru v mapovači portů, RPC server přiřadí, namapuje ke službě porty TCP a UDP, na kterých se služba spustila, a uloží do jádra odpovídající informace o běžící služba (název), služba s jedinečným číslem (v souladu s /etc/rpc), o protokolu a portu, na kterém služba běží a o verzi a poskytovaných službách uvedené informace klienty na vyžádání. Samotný převodník portů má číslo programu (100000), číslo verze - 2, port TCP 111 a port UDP 111. Výše jsem při specifikaci složení démonů serveru NFS uvedl hlavní čísla programů RPC. Pravděpodobně jsem vás tímto odstavcem trochu zmátl, takže řeknu základní frázi, která by měla vše objasnit: hlavní funkcí mapovače portů je vrátit se na žádost klienta, který poskytl číslo programu RPC (resp. číslo programu RPC) a verzi k němu (klientovi) portu, na kterém běží požadovaný program. Pokud tedy klient potřebuje přistupovat k RPC pomocí konkrétního čísla programu, musí nejprve kontaktovat proces mapování portů na serveru a určit číslo komunikačního portu se službou RPC, kterou potřebuje.

Provoz RPC serveru může být reprezentován následujícími kroky:

Převaděč portů by se měl spustit jako první, obvykle při startu systému. Tím se vytvoří koncový bod TCP a otevře se port TCP 111. Také se vytvoří koncový bod UDP, který čeká, až datagram UDP dorazí na port UDP 111.
Při spuštění program běžící prostřednictvím serveru RPC vytvoří koncový bod TCP a koncový bod UDP pro každou podporovanou verzi programu. (Server RPC může podporovat více verzí. Klient specifikuje požadovanou verzi při volání RPC.) Každé verzi služby je přiřazeno dynamicky přiřazené číslo portu. Server zaprotokoluje každý program, verzi, protokol a číslo portu provedením příslušného volání RPC.
Když klientský program RPC potřebuje získat potřebné informace, zavolá rutinu překladače portů, aby získal dynamicky přiřazené číslo portu pro zadaný program, verzi a protokol.
V reakci na tento požadavek vrátí sever číslo portu.
Klient odešle zprávu s požadavkem RPC na číslo portu získané v kroku 4. Pokud je použito UDP, klient jednoduše odešle UDP datagram obsahující výzvu RPC na číslo portu UDP, na kterém běží požadovaná služba. V odezvě služba odešle datagram UDP obsahující zprávu odpovědi RPC. Pokud je použit TCP, klient se aktivně otevře na čísle portu TCP požadované služby a poté odešle zprávu o výzvě RPC přes navázané spojení. Server odpoví zprávou odpovědi RPC na připojení.

Chcete-li získat informace ze serveru RPC, použijte nástroj rpcinfo. Při zadávání parametrů -p hostitel program zobrazí seznam všech registrovaných programů RPC na hostitelském hostiteli. Bez zadání hostitele program zobrazí služby na localhost. Příklad:

ARCHIV ~ # rpcinfo -p prog vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 59451 stav 100024 1 tcp 60831 1nlock 0.mlock 0 21 3 udp 44310 nlockmgr 100021 4 udp 44310 nlockmgr 100021 1 tcp 44851 nlockmgr 100021 3 tcp 44851 nlockmgr 100021 4 tcp 44851 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 2049 nfs 003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100005 1 udp 51306 namontovaný 100005 1 tcp 414 namontovaný 100005 2 udp 51306 namontovaný 100005 2 tcp 41405 namontovaný 100005 3 udp 51306 namontovaný 100005 3 tcp 41405 namontovaný

Jak vidíte, rpcinfo zobrazuje (ve sloupcích zleva doprava) registrované číslo programu, verzi, protokol, port a název. Pomocí rpcinfo můžete odebrat registraci programu nebo získat informace o konkrétní službě RPC (další možnosti v man rpcinfo). Jak můžete vidět, démoni portmapper verze 2 jsou registrováni na udp a tcp porty, rpc.statd verze 1 na portech udp a tcp, zámek NFS správce verzí 1,3,4, nfs serverový démon verze 2,3,4, stejně jako montážní démon verze 1,2,3.

NFS server (přesněji démon rpc.nfsd) přijímá požadavky od klienta ve formě UDP datagramů na portu 2049. Přestože NFS pracuje s překladačem portů, který umožňuje serveru používat dynamicky přidělované porty, port UDP 2049 je ve většině implementací pevně zakódován do NFS.

Operace protokolu síťového systému souborů

Montáž vzdáleného NFS

Proces připojení vzdáleného souborového systému NFS lze znázornit následujícím diagramem:

Popis protokolu NFS při připojení vzdáleného adresáře:

Na serveru a klientovi je spuštěn RPC server (obvykle při bootování), který je obsluhován procesem portmapper a registrován na portu tcp/111 a udp/111.
Spustí se služby (rpc.nfsd, rpc.statd atd.), které jsou registrovány na RPC serveru a registrovány na libovolných síťových portech (pokud není v nastavení služby určen statický port).
příkaz mount na klientském počítači odešle do jádra požadavek na připojení síťového adresáře s uvedením typu systému souborů, hostitele a samotného adresáře, které jádro odešle a vytvoří požadavek RPC na proces portmap na serveru NFS na portu udp /111 (pokud na klientovi není nastavena možnost pracovat přes tcp )
Jádro serveru NFS se dotazuje RPC na přítomnost démona rpc.mountd a vrátí jádru klienta síťový port, na kterém démon běží.
mount odešle požadavek RPC na port, na kterém běží rpc.mountd. Server NFS nyní může ověřit klienta na základě jeho adresy IP a čísla portu, aby zjistil, zda klient může připojit zadaný systém souborů.
Démon připojení vrací popis požadovaného systému souborů.
Klientův příkaz mount vydá systémové volání mount, aby přiřadilo popisovač souboru získaný v kroku 5 k místnímu bodu připojení na hostitelském počítači klienta. Popisovač souboru je uložen v kódu NFS klienta a od této chvíle bude jakýkoli přístup uživatelských procesů k souborům v systému souborů serveru používat jako výchozí bod popisovač souboru.

Komunikace mezi klientem a NFS serverem

Typický přístup ke vzdálenému systému souborů lze popsat následovně:

Popis procesu přístupu k souboru umístěnému na serveru NFS:

Klientovi (uživatelskému procesu) je jedno, zda přistupuje k místnímu souboru nebo k souboru NFS. Jádro interaguje s hardwarem prostřednictvím modulů jádra nebo vestavěných systémových volání.
Modul jádra kernel/fs/nfs/nfs.ko, který provádí funkce klienta NFS, odesílá požadavky RPC na server NFS prostřednictvím modulu TCP/IP. NFS obvykle používá UDP, ale novější implementace mohou používat TCP.
Server NFS přijímá požadavky od klienta jako datagramy UDP na portu 2049. Ačkoli NFS může pracovat s překladačem portů, který serveru umožňuje používat dynamicky přidělované porty, port UDP 2049 je ve většině implementací pevně zakódován pro NFS.
Když server NFS obdrží požadavek od klienta, je předán rutině pro přístup k místnímu souboru, která poskytuje přístup k místnímu disku na serveru.
Výsledek přístupu na disk se vrátí klientovi.

Nastavení serveru NFS

Nastavení serveru obecně sestává ze zadání místních adresářů povolených pro připojení vzdálené systémy v souboru /etc/exports. Tato akce se nazývá exportní adresářová hierarchie. Hlavními zdroji informací o exportovaných katalozích jsou následující soubory:

/etc/exports- hlavní konfigurační soubor, který ukládá konfiguraci exportovaných adresářů. Používá se při spouštění NFS a obslužným programem exportfs.
/var/lib/nfs/xtab- obsahuje seznam adresářů připojených vzdálenými klienty. Používá se démonem rpc.mountd, když se klient pokusí připojit hierarchii (vytvoří se záznam pro připojení).
/var/lib/nfs/etab- seznam adresářů, které mohou být připojeny vzdálenými systémy, s uvedením všech parametrů exportovaných adresářů.
/var/lib/nfs/rmtab- seznam adresářů, které nejsou aktuálně neexportovány.
/proc/fs/nfsd- speciální souborový systém (kernel 2.6) pro správu serveru NFS.
- exportů- seznam aktivních exportovaných hierarchií a klientů, kterým byly exportovány, a také parametry. Jádro získává tyto informace z /var/lib/nfs/xtab.
- vlákna- obsahuje počet vláken (lze také změnit)
- pomocí filehandle můžete získat ukazatel na soubor
- atd...
/proc/net/rpc- obsahuje „surové“ statistiky, které lze získat pomocí nfsstat, stejně jako různé mezipaměti.
/var/run/portmap_mapping- informace o službách registrovaných v RPC

Poznámka: Obecně je na internetu spousta výkladů a formulací účelu souborů xtab, etab, rmtab, ani na http://nfs.sourceforge.net/ nevím, komu věřit není jasné.

Nastavení souboru /etc/exports

V nejjednodušším případě je soubor /etc/exports jediným souborem, který vyžaduje úpravu pro konfiguraci serveru NFS. Tento souborřídí následující aspekty:

Jaké klienty může přistupovat k souborům na serveru
Které hierarchie? k adresářům na serveru má přístup každý klient
Jak budou vlastní jména zákazníků být zobrazeny na místní jména uživatelů

Každý řádek exportovaného souboru má následující formát:

export_point client1 (options) [client2(options) ...]

Kde export_point absolutní cesta exportované hierarchie adresářů, klient1 - n jméno jednoho nebo více klientů nebo IP adres oddělených mezerami, kterým je povoleno připojení export_point . Možnosti popsat pravidla pro montáž klienta, specifikované dříve možnosti .

Tady je jeden typický exportuje příklad konfigurace souboru:

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

V v tomto příkladu soubory počítačů a 10.0.0.1 mají povolen přístup k exportnímu bodu /archiv1, zatímco hostitel souborů má přístup pro čtení/zápis a hostitel 10.0.0.1 a podsíť 10.0.230.1/24 mají přístup pouze pro čtení.

Popisy hostitelů v /etc/exports jsou povoleny v následujícím formátu:

Názvy jednotlivých uzlů jsou popsány jako soubory nebo soubory.DOMAIN.local.
Maska domény je popsána v následujícím formátu: *DOMAIN.local zahrnuje všechny uzly domény DOMAIN.local.
Podsítě jsou specifikovány jako páry IP adresa/maska. Například: 10.0.0.0/255.255.255.0 zahrnuje všechny uzly, jejichž adresy začínají 10.0.0.
Nastavení jména síťová skupina@myclients mající přístup ke zdroji (při použití serveru NIS)

Obecné možnosti pro export hierarchií adresářů

Soubor exportů používá následující obecné možnosti(volby používané ve výchozím nastavení ve většině systémů jsou uvedeny jako první, jiné než výchozí v závorkách):

auth_nlm (no_auth_nlm) nebo secure_locks (insecure_locks)- určuje, že server by měl vyžadovat ověření požadavků na zámek (pomocí protokolu NFS Lock Manager).
nohide (skrýt)- pokud server exportuje dvě hierarchie adresářů, přičemž jedna je vnořená (připojená) ve druhé. Klient musí explicitně připojit druhou (podřízenou) hierarchii, jinak se bod připojení podřízené hierarchie zobrazí jako prázdný adresář. Volba nohide má za následek druhou hierarchii adresářů bez explicitního připojení. ( poznámka: Tuto možnost jsem nemohl zprovoznit...)
ro(rw)- Umožňuje pouze čtení (zápis) požadavků. (Nakonec, zda je možné číst/zapisovat nebo ne, se určuje na základě práv systému souborů a server není schopen rozlišit požadavek na čtení souboru od požadavku na provedení, takže umožňuje čtení, pokud uživatel četl nebo vykonávat práva.)
bezpečný (nejistý)- vyžaduje, aby požadavky NFS přicházely ze zabezpečených portů (< 1024), чтобы программа без root práva nelze připojit hierarchii adresářů.
kontrola_podstromu (no_kontrola_podstromu)- Pokud je exportován podadresář souborového systému, ale ne celý souborový systém, server zkontroluje, zda je požadovaný soubor v exportovaném podadresáři. Zakázání ověřování snižuje zabezpečení, ale zvyšuje rychlost přenosu dat.
synchronizace (asynchronní)- určuje, že server by měl odpovídat na požadavky pouze po zapsání změn provedených těmito požadavky na disk. Možnost async říká serveru, aby nečekal na zapsání informací na disk, což zlepšuje výkon, ale snižuje spolehlivost, protože V případě přerušení spojení nebo selhání zařízení může dojít ke ztrátě informací.
wdelay (no_wdelay)- Instruuje server, aby zpozdil provádění požadavků na zápis, pokud následný požadavek na zápis čeká na vyřízení, zapisování dat ve větších blocích. To zlepšuje výkon při odesílání velkých front příkazů zápisu. no_wdelay určuje, že se nemá zpožďovat provádění příkazu zápisu, což může být užitečné, pokud server přijímá velké množství nesouvisejících příkazů.

Exportujte symbolické odkazy a soubory zařízení. Při exportu adresářové hierarchie obsahující symbolické odkazy musí být objekt odkazu přístupný pro klientský (vzdálený) systém, to znamená, že musí platit jedno z následujících pravidel:

Soubor zařízení patří k rozhraní. Když exportujete soubor zařízení, exportuje se toto rozhraní. Pokud klientský systém nemá zařízení stejného typu, exportované zařízení nebude fungovat. V klientském systému můžete při připojování objektů NFS použít volbu nodev, aby se nepoužívaly soubory zařízení v připojených adresářích.

Výchozí možnosti v různé systémy se mohou lišit, lze je zobrazit v souboru /var/lib/nfs/etab. Po popisu exportovaného adresáře v /etc/exports a restartování serveru NFS se všechny chybějící možnosti (čti: výchozí možnosti) projeví v souboru /var/lib/nfs/etab.

Možnosti zobrazení (shody) ID uživatele

Pro lepší pochopení následujícího bych vám doporučil přečíst si článek. Každý uživatel Linuxu má vlastní UID a hlavní GID, které jsou popsány v souborech /etc/passwd A /etc/group. Server NFS předpokládá, že operační systém vzdáleného hostitele ověřil uživatele a přiřadil jim správné UID a GID. Export souborů poskytuje uživatelům klientského systému stejný přístup k těmto souborům, jako kdyby byli přihlášeni přímo na server. V souladu s tím, když klient NFS odešle požadavek na server, server použije UID a GID k identifikaci uživatele v místním systému, což může vést k některým problémům:

uživatel nemusí mít stejné identifikátory v obou systémech, a proto může mít přístup k souborům jiného uživatele.
protože na uživatel root Identifikátor je vždy 0, pak je tento uživatel mapován na lokálního uživatele v závislosti na zadaných možnostech.

Následující možnosti nastavují pravidla pro zobrazení vzdálených uživatelů v místních:

root_squash (no_root_squash)- S uvedenou možností root_squash, požadavky od uživatele root jsou mapovány na anonymní uid/gid nebo na uživatele uvedeného v parametru anonuid/anongid.
no_all_squash (all_squash)- Nemění UID/GID připojujícího se uživatele. Volba all_squash nastaví zobrazení VŠECH uživatelů (nejen root) jako anonymních nebo zadaných v parametru anonuid/anongid.
anonuid= UID A anongid= GID - Explicitně nastaví UID/GID pro anonymního uživatele.
map_static= /etc/file_maps_users - Určuje soubor, ve kterém můžete nastavit mapování vzdáleného UID/GID na místní UID/GID.

Příklad použití souboru mapování uživatele:

ARCHIV ~ # cat /etc/file_maps_users # Mapování uživatelů # vzdálený místní komentář uid 0-50 1002 # mapování uživatelů se vzdáleným UID 0-50 na místní UID 1002 gid 0-50 1002 # mapování uživatelů se vzdáleným GID 0-50 na místní GID 1002

Správa serveru NFS

Server NFS je spravován pomocí následujících nástrojů:

nfsstat
showmsecure (nezabezpečené) připojení

nfsstat: Statistiky NFS a RPC

Obslužný program nfsstat umožňuje zobrazit statistiky serverů RPC a NFS. Možnosti příkazu lze nalézt v man nfsstat.

showmount: Zobrazení informací o stavu NFS

utilita showmount dotazuje démona rpc.mountd na vzdáleném hostiteli na připojené systémy souborů. Ve výchozím nastavení je vrácen seřazený seznam klientů. Klíče:

--vše- zobrazí se seznam klientů a přípojných bodů s uvedením, kam klient připojil adresář. Tyto informace nemusí být spolehlivé.
-- adresáře- zobrazí se seznam přípojných bodů
-- vývoz- zobrazí se seznam exportovaných souborových systémů z pohledu nfsd

Když spustíte showmount bez argumentů, na konzoli se vytisknou informace o systémech, které se mohou připojit místní katalogy. Hostitel ARCHIV nám například poskytuje seznam exportovaných adresářů s IP adresami hostitelů, kteří mají povoleno připojit zadané adresáře:

SOUBORY ~ # showmount --exportuje archiv Seznam exportů pro archiv: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

Pokud v argumentu zadáte název hostitele/IP, zobrazí se informace o tomto hostiteli:

ARCHIV ~ # soubory showmount clnt_create: RPC: Program není zaregistrován # tuto zprávuříká nám, že na hostiteli FILES neběží démon NFSd

exportfs: správa exportovaných adresářů

Tento příkaz obsluhuje exportované adresáře uvedené v souboru /etc/exports, přesnější by bylo napsat, že neslouží, ale synchronizuje se se souborem /var/lib/nfs/xtab a odstraní ty neexistující z xtabu. exportfs se provede při spuštění démona nfsd s argumentem -r. Obslužný program exportfs v režimu jádra 2.6 komunikuje s démonem rpc.mountd prostřednictvím souborů v adresáři /var/lib/nfs/ a nekomunikuje přímo s jádrem. Bez parametrů zobrazí seznam aktuálně exportovaných systémů souborů.

parametry exportfs:

[client:název-adresáře] - přidat nebo odebrat zadaný systém souborů pro zadaného klienta)
-v - zobrazí další informace
-r - znovu exportovat všechny adresáře (synchronizovat /etc/exports a /var/lib/nfs/xtab)
-u - odebrat ze seznamu exportovaných
-a - přidat nebo odebrat všechny systémy souborů
-o - možnosti oddělené čárkami (podobně jako možnosti používané v /etc/exports; tj. můžete změnit možnosti již připojených souborových systémů)
-i - při přidávání nepoužívejte /etc/exports, pouze aktuální volby příkazového řádku
-f - resetuje seznam exportovaných systémů v jádře 2.6;

NFS klient

Před přístupem k souboru na vzdáleném souborovém systému musí klient (klientský OS). namontovat to a přijímat ze serveru ukazatel na to. Připojení NFS lze provést pomocí nebo pomocí jednoho z množících se automatických montážních zařízení (amd, autofs, automount, supermount, superpupermount). Proces instalace je dobře znázorněn na obrázku výše.

Na klienti NFS není třeba spouštět žádné démony, funkce klienta spustí modul jádra kernel/fs/nfs/nfs.ko, který se používá při připojování vzdáleného souborového systému. Exportované adresáře ze serveru lze na klienta připojit následujícími způsoby:

ručně pomocí příkazu mount
automaticky při zavádění, při připojování souborových systémů popsaných v /etc/fstab
automaticky pomocí démona autofs

Třetí metodu s autofs v tomto článku nebudu uvažovat kvůli jejím objemným informacím. Možná bude v dalších článcích samostatný popis.

Připojení systému síťových souborů pomocí příkazu mount

Příklad použití příkazu mount je uveden v příspěvku. Zde se podívám na příklad příkazu mount pro připojení souborového systému NFS:

SOUBORY ~ # mount -t nfs archiv:/archiv-small /archivs/archiv-small FILES ~ # mount -t nfs -o ro archiv:/archiv-big /archivs/archiv-big FILES ~ # mount ..... .. archiv:/archiv-small na /archivs/archiv-small type nfs (rw,addr=10.0.0.6) archiv:/archiv-big on /archivs/archiv-big type nfs (ro,addr=10.0.0.6)

První příkaz připojí exportovaný adresář /archiv-malý na serveru archiv do místního bodu připojení /archivs/archiv-small s výchozími možnostmi (tj. čtení a zápis). Ačkoli příkaz mount PROTI nejnovější distribuce dokáže pochopit, jaký typ souborového systému se používá, i bez určení typu, přesto uveďte parametr -t nfsžádoucí. Druhý příkaz připojí exportovaný adresář /archiv-velký na serveru archiv do místního adresáře /archiv/archiv-velký s možností pouze pro čtení ( ro). příkaz mount bez parametrů nám jasně ukazuje výsledek montáže. Kromě možnosti pouze pro čtení (ro) je možné zadat další Základní možnosti při montáži NFS:

nosuid - Tato možnost zakazuje spouštění programů z připojeného adresáře.
nodev(žádné zařízení – není zařízení) – Tato možnost zakazuje použití znakových a blokových speciálních souborů jako zařízení.
zámek (nolock)- Umožňuje zamykání NFS (výchozí). nolock deaktivuje zamykání NFS (nespustí démona lockd) a je užitečný při práci se staršími servery, které nepodporují zamykání NFS.
mounthost=jméno- Název hostitele, na kterém běží démon připojení NFS - mountd.
mountport=n - Port používaný démonem mountd.
port=n- port používaný pro připojení k serveru NFS (výchozí hodnota je 2049, pokud démon rpc.nfsd není registrován na serveru RPC). Pokud n=0 (výchozí), NFS se dotazuje na mapu portů na serveru, aby určil port.
rsize=n(velikost bloku čtení – velikost bloku čtení) – Počet bajtů přečtených najednou ze serveru NFS. Standardní - 4096.
wsize=n(velikost bloku zápisu – velikost bloku zápisu) – Počet bajtů zapsaných najednou na server NFS. Standardní - 4096.
TCP nebo udp- Pro připojení NFS použijte protokol TCP nebo UDP.
bg- Pokud ztratíte přístup k serveru, zkuste to znovu pozadí, abyste neblokovali proces spouštění systému.
fg- Pokud ztratíte přístup k serveru, zkuste to znovu v režimu priority. Tato možnost může zablokovat proces spouštění systému opakovanými pokusy o připojení. Z tohoto důvodu se parametr fg používá především pro ladění.

Možnosti, které ovlivňují ukládání atributů do mezipaměti na připojení NFS

Atributy souboru, uložené v (inodech), jako je čas modifikace, velikost, pevné odkazy, vlastník, se obvykle mění zřídka u běžných souborů a ještě méně často u adresářů. Mnoho programů, jako je ls, přistupuje k souborům pouze pro čtení a nemění atributy souborů ani obsah, ale plýtvá systémovými prostředky na drahé síťové operace. Abyste se vyhnuli plýtvání zdroji, můžete cache tyto atributy. Jádro používá čas úpravy souboru k určení, zda je mezipaměť zastaralá, porovnáním času úpravy v mezipaměti a času úpravy samotného souboru. Mezipaměť atributů se pravidelně aktualizuje v souladu se zadanými parametry:

ac (noac) (mezipaměť atributů- ukládání atributů do mezipaměti) - Umožňuje ukládání atributů do mezipaměti (výchozí). Přestože volba noac zpomaluje server, zabraňuje zastarávání atributů, když více klientů aktivně zapisuje informace do společné hierarchie.
acdirmax=n (maximální soubor adresáře mezipaměti atributů- maximální ukládání atributů do mezipaměti na soubor adresáře) - Maximální množství sekund, které NFS čeká před aktualizací atributů adresáře (výchozí 60 sekund)
acdirmin=n (minimální soubor adresáře mezipaměti atributů- minimální ukládání atributů do mezipaměti pro soubor adresáře) - Minimální počet sekund, po které NFS čeká před aktualizací atributů adresáře (výchozí 30 sekund)
acregmax=n (atribut cache normální soubor maximum- maximum mezipaměti atributů pro běžný soubor) - Maximální počet sekund, po které NFS čeká před aktualizací atributů běžného souboru (výchozí 60 sekund)
akregmin=n (mezipaměť atributů běžný soubor minimum- minimální ukládání atributů do mezipaměti pro běžný soubor) - Minimální počet sekund, po které NFS čeká před aktualizací atributů běžného souboru (výchozí 3 sekundy)
actimeo=n (vypršel časový limit mezipaměti atributů- časový limit ukládání atributů do mezipaměti) - Nahradí hodnoty pro všechny výše uvedené možnosti. Pokud není zadáno actimeo, pak výše uvedené hodnoty převezmou výchozí hodnoty.

Možnosti zpracování chyb NFS

Následující možnosti řídí, co NFS dělá, když server neodpovídá nebo když se vyskytnou chyby I/O:

fg(bg) (popředí - popředí, pozadí- background) - Pokusy o připojení neúspěšného NFS na popředí/pozadí.
tvrdý (měkký)- po dosažení časového limitu zobrazí konzoli zprávu "server neodpovídá" a pokračuje v pokusu o připojení. S danou možností měkký- během časového limitu informuje program, který volal operaci, o I/O chybě. (doporučuje se nepoužívat soft možnost)
nointr (intr) (žádné přerušení- nepřerušovat) - Neumožňuje signály přerušit operace se soubory v pevně připojené hierarchii adresářů, když je dosaženo velkého časového limitu. intr- umožňuje přerušení.
retrans=n (hodnotu opětovného přenosu- význam retransmisi) - Po n malých prodlevách NFS vygeneruje velký časový limit (výchozí 3). Velký časový limit zastaví operace nebo vytiskne na konzolu zprávu „server neodpovídá“ v závislosti na tom, zda je zadána možnost hard/soft.
opakovat=n (opakovat hodnotu- hodnota opakování) - Počet minut, po které bude služba NFS opakovat operace připojení, než se vzdá (výchozí 10000).
timeo=n (hodnota časového limitu- hodnota časového limitu) - Počet desetin sekundy, po kterou služba NFS čeká před opětovným přenosem v případě RPC nebo malého časového limitu (výchozí 7). Tato hodnota se zvyšuje s každým časovým limitem až do maximální hodnota 60 sekund nebo dokud nenastane velký časový limit. V případě vytížené sítě, pomalého serveru nebo když požadavek prochází více směrovači nebo branami, zvýšení této hodnoty může zlepšit výkon.

Automatické připojení NFS při bootování (popis souborových systémů v /etc/fstab)

Optimální čas pro konkrétní hodnotu přenášeného paketu (hodnoty rsize/wsize) můžete vybrat pomocí příkazu ping:

SOUBORY ~ # ping -s 32768 archiv PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) bajtů dat. 32776 bajtů z archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 čas=0,931 ms 32776 bajtů z archiv.domain.local (10.0.0.6): icmp_req=2 ttl=64 ms77 bajtů 358 z archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 čas=1,03 ms 32776 bajtů z archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 čas=1,00 ms z archivu 32776 bajtů .domain.local (10.0.0.6): icmp_req=5 ttl=64 čas=1,08 ms ^C --- archiv.DOMAIN.local statistika pingu --- 5 odeslaných paketů, 5 přijatých, 0 % ztráta paketů, čas 4006 ms rtt min/prům/max/mdev = 0,931/1,002/1,083/0,061 ms

Jak vidíte, při odesílání paketu o velikosti 32768 (32Kb) se jeho doba cesty z klienta na server a zpět pohybuje kolem 1 milisekundy. Pokud tento čas přesáhne 200 ms, měli byste přemýšlet o zvýšení hodnoty timeo tak, aby převyšovalo hodnotu výměny třikrát až čtyřikrát. Proto je vhodné provést tento test při velkém zatížení sítě.

Spuštění NFS a nastavení brány firewall

Poznámka byla zkopírována z blogu http://bog.pp.ru/work/NFS.html, za což mnohokrát děkujeme!!!

Spusťte server NFS, připojte, zablokujte, kvótu a stav se „správnými“ porty (pro firewall)

Je vhodné nejprve odpojit všechny prostředky na klientech
zastavte a zakažte spouštění rpcidmapd, pokud neplánujete používat NFSv4: chkconfig --level 345 rpcidmapd off service rpcidmapd stop
v případě potřeby povolte spuštění služeb portmap, nfs a nfslock: chkconfig --levels 345 portmap/rpcbind na chkconfig --levels 345 nfs na chkconfig --levels 345 nfslock on
v případě potřeby zastavte služby nfslock a nfs, spusťte portmap/rpcbind, uvolněte službu modulů nfslock stop službu nfs stop službu portmap start # služba rpcbind start umount /proc/fs/nfsd služba rpcidmapd stop rmmod nfsd služba autofs stop # někde později to musí být spuštěn rmmod nfs rmmod nfs_acl rmmod lockd
otevřít porty v
- pro RPC: UDP/111, TCP/111
- pro NFS: UDP/2049, TCP/2049
- pro rpc.statd: UDP/4000, TCP/4000
- pro uzamčené: UDP/4001, TCP/4001
- pro namontované: UDP/4002, TCP/4002
- pro rpc.rquota: UDP/4003, TCP/4003
pro server rpc.nfsd přidejte řádek RPCNFSDARGS="--port 2049" do /etc/sysconfig/nfs
pro připojovací server přidejte řádek MOUNTD_PORT=4002 do /etc/sysconfig/nfs
pro konfiguraci rpc.rquota pro nové verze je třeba přidat řádek RQUOTAD_PORT=4003 do /etc/sysconfig/nfs
pro konfiguraci rpc.rquota je nutné pro starší verze (musíte však mít balíček kvót 3.08 nebo novější) přidat do /etc/services rquotad 4003/tcp rquotad 4003/udp
zkontroluje přiměřenost /etc/exports
spusťte služby rpc.nfsd, mountd a rpc.rquota (rpcsvcgssd a rpc.idmapd jsou spuštěny současně, pokud si je zapamatujete smazat) služba nfsd start nebo v nových verzích služba nfs start
pro blokovací server pro nové systémy přidejte řádky LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001 do /etc/sysconfig/nfs
pro lock server pro starší systémy přidejte přímo do /etc/modprobe[.conf]: options lockd nlm_udpport=4001 nlm_tcpport=4001
navázat stavový server rpc.statd na port 4000 (u starších systémů spusťte rpc.statd s přepínačem -p 4000 v /etc/init.d/nfslock) STATD_PORT=4000
spustit službu lockd a rpc services.statd nfslock start
ujistěte se, že všechny porty jsou normálně svázány pomocí "lsof -i -n -P" a "netstat -a -n" (některé porty používají moduly jádra, které lsof nevidí)
pokud před „přestavbou“ server používali klienti a nebylo možné je odpojit, budete muset restartovat služby automatického připojování na klientech (am-utils, autofs)

Příklad konfigurace serveru NFS a klienta

Konfigurace serveru

Pokud chcete, aby byl váš sdílený adresář NFS veřejný a zapisovatelný, můžete použít tuto možnost all_squash v kombinaci s opcemi anonuidní A anongid. Chcete-li například nastavit oprávnění pro uživatele „nikdo“ ve skupině „nikdo“, můžete provést následující:

ARCHIV ~ # cat /etc/exports # Přístup pro čtení a zápis pro klienta na 192.168.0.100, s přístupem rw pro uživatele 99 s gid 99 /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99) # Přístup ke čtení a zápisu pro klienta na 192.168.0.100, s přístupem rw pro uživatele 99 s gid 99 /soubory 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

To také znamená, že pokud chcete povolit přístup k zadanému adresáři, nikdo.nobody nesmí být vlastníkem sdíleného adresáře:

muž mount
muž exportuje
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm - Výkon NFS od IBM.

S pozdravem, McSim!

Síťové souborové systémy

Jednou z nejužitečnějších funkcí, které lze dosáhnout pomocí sítě, je sdílení souborů prostřednictvím síťového souborového systému. Běžně používaný systém se nazývá Network File System nebo NFS, který vyvíjí společnost Sun Corporation.

Při práci se síťovým souborovým systémem jsou prováděny jakékoli operace se soubory místní počítač, jsou přenášeny přes síť na vzdálený počítač. Když je spuštěn síťový souborový systém, program považuje všechny soubory za zapnuté vzdálený počítač jsou umístěny na počítači, kde běží. Oddělování informací prostřednictvím takového systému tedy nevyžaduje žádné změny programu.

Mail

E-mail je nejdůležitějším prostředkem komunikace mezi počítači. E-maily jsou uloženy v jednom souboru ve speciálním formátu. Ke čtení a odesílání dopisů se používají speciální programy.

Každý uživatel má samostatnou poštovní schránku, soubor, kde jsou uloženy informace ve speciálním formátu, ve kterém je uložena příchozí pošta. Pokud do počítače dorazí dopis, program pro zpracování pošty najde soubor poštovní schránky odpovídajícího uživatele a přijatý dopis tam přidá. Pokud je schránka uživatele umístěna na jiném počítači, pak je dopis přesměrován na tento počítač, kde je dále zpracováván.

Poštovní systém se skládá z mnoha různých programů. Doručování dopisů do lokálních nebo vzdálených schránek provádí jeden program (například sendmail nebo smail), zatímco pro běžné odesílání nebo prohlížení dopisů se používá velké množství různých programů (například soubory Mailbox). jsou obvykle uloženy v adresáři / var/spool/mail.

Otázky

1. Co je NOS a jaký je jeho účel?

2. Jaké síťové funkce plní síťový operační systém?

3. Z jakých částí se skládá struktura NOS?

4. Co je přesměrovač?

5. Jak se dělí síťové operační systémy podle přístupových práv ke zdrojům?

6. Jak se dělí síťové operační systémy podle měřítka sítí?

7. Jak závisí vlastnosti síťového operačního systému na měřítku sítí?

8. Popište síťový operační systém NetWare od společnosti Novell.

9. Jaké prvky tvoří strukturu síťového operačního systému NetWare?

10. Popište souborový systém síťového operačního systému NetWare.

11. Jaké úrovně protokolů podporuje síťový operační systém NetWare?

12. Vyjmenujte funkce protokolů IPX, SPX.

13. Popište síťový operační systém Windows NT.

14. Vyjmenujte úlohy síťového operačního systému Windows NT.

15. Z jakých prvků se skládá struktura síťového operačního systému Windows NT?

16. Popište souborový systém síťového OS Windows NT.

17. Jaké bezpečnostní principy se používají v síťovém operačním systému Windows NT?

18. Vyjmenujte vlastnosti síťového operačního systému Windows NT z pohledu implementace síťových nástrojů.

19. Pojmenujte vlastnosti síťového operačního systému Windows NT.

20. Jaká jsou použití Windows NT?

21. Popište síťový operační systém UNIX.

22. Vyjmenujte funkce síťového operačního systému UNIX.

23. Charakterizujte souborový systém síťového OS UNIX.

24. Jaké bezpečnostní principy používá UNIX?

25. Uveďte přehled síťového operačního systému Linux.

Když mluvíme oÓ počítačové sítě, 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í úložiště. NFS, stejně jako mnoho jiných protokolů, je založen na Otevřený systém Network Computing Remote Procedure Call (ONC RPC).

Jinými slovy, co je NFS? Tento otevřený standard, definovaný v Request for Comments (RFC), umožňující 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 vlastnictví Sunu, určil nová verze jako v2, aby bylo možné 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 předvedena ř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 načtení dat a atributů spolu s názvy souborů při skenování adresáře;
mnoho dalších vylepšení.

Během uvedení verze 3 se začala zvyšovat podpora TCP jako protokolu transportní vrstvy. Použití TCP jako prostředku přenosu dat, prováděné pomocí NFS přes WAN, začalo přenos umožňovat velké velikosti soubory pro prohlížení a nahrávání. Díky tomu byli vývojáři schopni překonat 8 KB omezení vyplývající z 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. Proto WebNFS, rozšíření pro verze 2 a 3, protokol umožňuje přístup k síti Souborové systémy se snadněji integrují do webových prohlížečů a umožňují práci přes brány firewall.

Různé protokoly skupiny třetích stran se také staly spojeny s NFS. 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“.

Zároveň jsou protokoly SMB a NetWare (NCP) používány častěji než NFS v systémech běžících Microsoft Windows. 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ý scénář Unixový styl, 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. Společnost 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 bezplatné vývojářské komunitě software 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ů. Takže to jde dál jednoduché dělení jména/údaje.

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 lze některé soubory sdílet 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 s datovou sadou, patřící do skupiny NFS.

Network File System (NFS) je řešení pro sdílení souborů pro organizace, které používají smíšená počítačová prostředí Windows a Unix/Linux. Soubor systém NFS Umožňuje sdílet soubory mezi určenými různými platformami při spuštění operačního systému Windows Server 2012 Služby NFS v systému Windows Server 2012 zahrnují následující funkce a vylepšení.

1. Active Directory Search. Pro přístup k souborům máte možnost používat Windows Active Directory. Rozšíření schématu Identity Management for Unix pro Active Directory obsahuje pole Unix User identifier (UID) a group identifier (GID). To umožňuje Serverové služby pro NFS a Client for NFS mapování zobrazení uživatelských účtů Windows na Unix přímo z Active Directory Domain Services. Správa identit pro Unix usnadňuje správu mapování uživatelských účtů Windows v Unixu na Active Directory Domain Services.

2. Vylepšený výkon serveru. Služby pro NFS zahrnují ovladač filtru souborů, který výrazně snižuje celkovou latenci při přístupu k souborům na serveru.

3. Podpora speciálních unixových zařízení. Služby pro NFS podporují speciální unixová zařízení (mknod).

4. Rozšířená podpora Unixu. Služby pro NFS podporují následující verze Unix: Sun Microsystems Solaris verze 9, Červený klobouk Linux verze 9, IBM AIX verze 5L 5.2 a Hewlett Packard HP-UX verze 11i, stejně jako mnoho moderních distribucí Linuxu.

Jedním z nejběžnějších scénářů, který vytváří potřebu NFS, je umožnit uživatelům přístup Prostředí Windows na systém plánování podnikových zdrojů (ERP) založený na Unixu. V systému ERP mohou uživatelé vytvářet sestavy a/nebo exportovat finanční data do Microsoft Excel pro další analýzu. Souborový systém NFS umožňuje přístup k těmto souborům, zatímco jsou stále v prostředí Windows, což snižuje potřebu specializovaných technických dovedností a čas strávený exportem souborů pomocí skriptu Unix a jejich následným importem do konkrétní aplikaci Windows.

Může také nastat situace, kdy máte unixový systém, který se používá k ukládání souborů na nějakém druhu Storage Area Network (SAN). Spouštění služeb NFS zapnuto Stroj s Windows Server 2012 umožňuje uživatelům v organizaci přistupovat k souborům tam uloženým bez režie skriptování na straně Unixu.

Před instalací Služeb NFS musíte odebrat všechny dříve nainstalované součásti NFS, jako jsou součásti NFS, které byly součástí dodávky Služby pro Unix.

Komponenty služeb NFS

K dispozici jsou následující dvě součásti služeb NFS.

1. Server pro NFS(Server pro NFS). Počítač se systémem Unix obvykle nemá přístup k souborům umístěným v počítači se systémem Windows. Počítač se systémem Windows Server 2012 R2 a Server pro NFS však může fungovat jako souborový server pro počítače se systémem Windows a Unix.

2. Klient pro NFS(Klient pro NFS). Počítač se systémem Windows obvykle nemá přístup k souborům umístěným v počítači se systémem Unix. Počítač se systémem Windows Server 2012 R2 a funkcí Client for NFS však může přistupovat k souborům uloženým na serveru NFS založeném na systému Unix.

Instalace serveru pro systém souborů NFS pomocí prostředí PowerShell

Podívejme se, jak pomocí PowerShellu nainstalovat roli NFS na server a vytvořit sdílenou složku NFS.

1. Otevřete Okno Windows PowerShell přes hlavní panel jako účet správce.

2. Chcete-li nainstalovat roli NFS na server, zadejte následující příkazy:

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

3. Zadejte níže uvedený příkaz pro vytvoření nového sdíleného souborový prostředek NFS:

PS C:\> New-NfsShare -Název "Test" -Cesta "C:\Shares\Test"

4. Chcete-li zobrazit všechny nové rutiny prostředí PowerShell specifické pro NFS, které jsou k dispozici v systému Windows Server 2012 R2, spusťte následující příkaz:

PS C:\>Get-Command -modul NFS

5. Klepněte na složku C:\Shares\Test klikněte pravým tlačítkem myši, vyberte „vlastnosti“ a poté přejděte na kartu Sdílení NFS. Klikněte na tlačítko Spravovat sdílení NFS. NFS přístup), v zobrazeném dialogovém okně můžete spravovat oprávnění pro přístup ke složce, povolit anonymní přístup, nakonfigurujte nastavení kódování souborů. Složku můžete sdílet přes NFS pomocí dialogového okna Rozšířené sdílení NFS bez použití PowerShellu.

Nastavení standardních rozlišení

Nyní budeme muset otevřít některé porty brány firewall, aby NFS fungoval. Porty potřebné pro normální fungování Služby NFS jsou uvedeny v tabulce níže.

1.4 Síťový souborový systém

Systém souborů CIFS dominuje na trhu síťových systémů souborů platformy 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). Kromě toho poskytuje NFS 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ý vrátí popisovač souboru. . 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 představuje výhradně důležitá struktura data, která se používají 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 zlepš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 s ohledem na silné a slabé stránky NFS a nyní, alespoň mezi zákazníky, je CIFS/SMB stále běžnější a NFS se vyvíjí, aby využil předností a slabin 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 odstraněny protokoly pro připojení a mapování portů. Zamykání bylo navíc 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í protokol, který poskytuje možnost detekovat přetížení sítě. To znamená, že klienti a servery NFS postupně přejdou na TCP protokol místo UDP, který se obvykle 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). Styl Windows N.T. To zlepšuje komunikaci mezi systémy souborů a posiluje 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). veřejný klíč server. Server dešifruje data se svými soukromý klíč, extrakty 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ý test Pro detekci takových problémů bude soubor zkopírován 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í k souborům 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é problémy.
■ 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.

Oblíbené v kategorii: