NFSv4 забезпечує уніфікований доступ до мережі. Заходи щодо забезпечення безпеки. Встановлення та налаштування клієнтської частини NFS

NFS

Рівень (за моделлю OSI):	Прикладний
Сімейство:	стек протоколів TCP/IP
Порт/ID:	67, 68/UDP
Призначення протоколу:	Отримання конфігурації мережі
Специфікація:	RFC 2131
Основні реалізації (сервери):	dhcpd, ISC DHCP Server, Infoblox
Набрав чинності з:	1990

NFS абстрагований від типів файлових систем як сервера, так і клієнта, існує безліч реалізацій NFS-серверів та клієнтів для різних операційних систем та апаратних архітектур. Найбільш зріла версія NFS - v.4, що підтримує різні засоби аутентифікації (зокрема, Kerberos та LIPKEY з використанням протоколу RPCSEC GSS) та списків контролю доступу (як POSIX, так і Windows-типів).

Загальна організація NFS

NFS надає клієнтам прозорий доступдо файлів та файлової системи сервера. На відміну від FTP , протокол NFS здійснює доступ тільки до тих частин файлу, до яких звернувся процес, і основна перевага в тому, що він робить цей доступ прозорим. Це означає, що будь-який додаток клієнта, який може працювати з локальним файлом, з таким же успіхом може працювати і з файлом NFS, без будь-яких модифікацій самої програми.

NFS-клієнти отримують доступ до файлів на NFS-сервері шляхом надсилання RPC-запитів на сервер. Це може бути реалізовано з використанням звичайних користувальницьких процесів - а саме, NFS-клієнт може бути процесом користувача, який здійснює конкретні RPC-дзвінки на сервер, який так само може бути користувальницьким процесом.

Важливою частиною останньої версії стандарту NFS (v4.1) стала специфікація pNFS, орієнтована на забезпечення розпаралеленої реалізації загального доступудо файлів, що збільшує швидкість передачі даних пропорційно до розмірів і ступеня паралелізму системи.

Історія

Протокол NFS має у своїй історії 4 версії.

Перша версія застосовувалася тільки для внутрішнього використанняв Sun в експериментальних цілях. Версія 2 випущена у березні 1989 року, спочатку повністю працювала по протоколу UDP. Розробники вирішили не зберігати даних про внутрішній стан усередині протоколу, як приклад, блокування, реалізоване поза базовим протоколом. Люди, залучені до створення NFS версії 2 - Рості Сендберг (Rusty Sandberg,) Боб Лайон (Bob Lyon), Білл Джой і Стів Клейман (Steve Kleiman).

NFSv3 вийшла в червні 1995 року, в ній додана підтримка дескрипторів файлів змінного розміру до 64 байт (у версії 2 - масив фіксованого розміру 32 байти), знято обмеження на 8192 байти в RPC-дзвінках читання та запису ( викликах обмежений лише межею для UDP-датаграми – 65535 байт), реалізована підтримка файлів великих розмірів, підтримані асинхронні викликиоперацій запису, до процедур READ та WRITE додані виклики ACCESS (перевірка прав доступу до файлу), MKNOD (створення спеціального файлу Unix), READDIRPLUS (повертає імена файлів у директорії разом з їх атрибутами), FSINFO (повертає статистичну інформаціюпро файлову систему), FSSTAT (повертає динамічну інформацію про файлову систему), PATHCONF (повертає POSIX.1-інформацію про файл) та COMMIT (передає раніше зроблені асинхронні записи на постійне зберігання). На момент введення версії 3 відзначено зростання популярності серед розробників протоколу TCP. Деякі незалежні розробники самостійно додали підтримку протоколу TCP для NFS версії 2 як транспортного, Sun Microsystems додали підтримку TCP в NFS в одному з додатків до версії 3. З підтримкою TCP підвищилися практична можливість використання NFS у глобальних мережах.

NFSv4 випущена у грудні 2000 року під впливом AFS та CIFS, до неї включені покращення продуктивності та безпеки. Версія 4 стала першою версією, розробленою спільно з Internet Engineering Task Force (IETF). NFS версії v4.1 була схвалена IESG у січні 2010 року ( нова специфікація, Обсягом 612 сторінок, стала відома як найдовший документ, схвалений IETF). p align="justify"> Важливим нововведенням версії 4.1 є специфікація pNFS - Parallel NFS, механізму паралельного доступу NFS-клієнта до даних безлічі розподілених NFS-серверів. Наявність такого механізму у стандарті мережної файлової системи допоможе будувати розподілені хмарні сховищата інформаційні системи.

Цілі розробки

Початковими вимогами при розробці NFS були:

потенційна підтримка різних операційних систем (не тільки UNIX), щоб сервери та клієнти NFS можна було б реалізувати в різних операційних системах;
протокол не повинен залежати від певних апаратних засобів;
мають бути реалізовані прості механізми відновлення у разі відмов сервера чи клієнта;
додатки повинні мати прозорий доступ до віддалених файлів без використання спеціальних дорожніх імен або бібліотек та без перекомпіляції;
для UNIX-клієнтів має підтримуватися семантика UNIX;
продуктивність NFSмає бути порівнянна з продуктивністю локальних дисків;
реалізація має бути залежною від транспортних засобів.

Принцип роботи NFS

NFS будується по Крайній міріз двох основних частин: сервера та однієї чи більшої кількості клієнтів. Клієнт звертається до даних, що знаходяться на сервері, у режимі віддаленого доступу. Для того, щоб це нормально функціонувало, потрібно налаштувати та запустити кілька процесів. Реалізація NFS складається з кількох компонентів. Деякі локалізовані або на сервері, або на клієнті, а деякі використовуються і на обох сторонах з'єднання. Деякі компоненти не потрібні для забезпечення основних функціональних можливостей, але є частиною розширеного інтерфейсу NFS.

Протокол NFS визначає набір запитів (операцій), які можуть бути направлені клієнтом до сервера, а також набір аргументів та значення, що повертаються для кожного з цих запитів. Версія 1 цього протоколу існувала тільки в надрах Sun Microsystems і ніколи не було випущено. Усі реалізації NFS (у тому числі NFSv3) підтримують версію 2 NFS (NFSv2), яка вперше була випущена у 1985 році у SunOS 2.0. Версія 3 протоколу була опублікована у 1993 році та реалізована деякими фірмами-постачальниками.

Протокол віддаленого виклику процедур (RPC) визначає формат усіх взаємодій між клієнтом та сервером. Кожен запит NFS надсилається як пакет RPC. На сервері працюють такі даемони:

rpc.nfsd - Основний даемон сервера NFS - nfsd (у нових версіях іноді називається nfsd4). Цей демон обслуговує запити клієнтів NFS. Параметр RPCNFSDCOUNT у файлі /etc/default/nfs-kernel-server у Debian і NFSDCOUNT у файлі /etc/sysconfig/nfs у RedHat визначає кількість демонів, що запускаються (за замовчуванням - 8). (RPC програма 100003)
rpc.mountd - Даемон монтування NFS mountd обробляє запити клієнтів на монтування каталогів. Демон mountd працює на серверах NFS. (RPC програма 100005)
rpc.statd - Даемон спостереження за мережевим станом (він же Network Status Monitor, він же NSM). Він дозволяє коректно скасовувати блокування після збою/перезавантаження. Для сповіщення про помилку використовує програму /usr/sbin/sm-notify. Демон statd працює як на серверах, і на клієнтах. Раніше даний сервербув необхідний роботи rpc.lockd, але за блокування зараз відповідає ядро. (RPC програма 100021 та 100024 - у нових версіях)
rpc.lockd - Даемон блокування lockd (він же NFS lock manager (NLM)) обробляє запити на блокування файлів. Демон блокування працює як на серверах, і на клієнтах. Клієнти запитують блокування файлів, а сервери його дозволяють. (застарілий і в нових дистрибутивах не використовується як демон. Його функції в сучасних дистрибутивах (з ядром старше 2.2.18) виконуються ядра (lockd). (RPC програма 100024)
rpc.idmapd - Даемон idmapd для NFSv4 на сервері перетворює локальні uid/gid користувачів у формат виду ім'я@домен, а сервіс на клієнті перетворює імена користувачів/груп виду ім'я@домен на локальні ідентифікатори користувача та групи (згідно з конфігураційним файлом /etc/idmapd .conf).

Клієнт може запустити також даемон, званий nfsiod. nfsiod обслуговує запити від сервера від сервера NFS. Він необов'язковий, збільшує продуктивність, проте для нормальної та правильної роботине вимагається. У NFSv4 при використанні Kerberos додатково запускаються демони:

rpc.gssd - Даемон NFSv4 забезпечує методи аутентифікації через GSS-API (Kerberos-аутентифікація). Працює на клієнті та сервері.
rpc.svcgssd – Даемон сервера NFSv4, який забезпечує перевірку справжності клієнта на стороні сервера.

Даемони старих версій (NFS v.3 і нижче):

nfslogd - даемон журналів NFS фіксує активність для експортованих файлових систем, працює на серверах NFS
rpc.rquotad - сервер віддалених квот надає інформацію про квоти користувачів у віддалених файлових системах, може працювати як на серверах, так і на клієнтах.

Крім зазначених вище пакетів, для коректної роботи NFSv2 та v3 потрібно додатковий пакет portmap (у новіших дистрибутивах замінений на перейменований на rpcbind). Sun RPC - це сервер, який перетворює номери програм RPC (Remote Procedure Call) у номери портів TCP/UDP.

portmap оперує кількома сутностями:

RPC-дзвінками або запитами
TCP/UDP портами, версією протоколу (tcp чи udp)
номерами програм та версіями програм

Даемон portmap запускається скриптом /etc/init.d/portmap до старту NFS-сервісів.

Робота сервера RPC (Remote Procedure Call) полягає в обробці RPC-дзвінків (т.зв. RPC-процедур) від локальних та віддалених процесів. Використовуючи RPC-дзвінки, сервіси реєструють або видаляють себе в/з перетворювача портів (portmap, portmapper, він, у нових версіях, rpcbind), а клієнти за допомогою RPC-дзвінків направляючи запити до portmapper отримують необхідну інформацію.

Роботу RPC-сервера можна представити такими кроками:

Перетворювач портів повинен стартувати першим, зазвичай під час завантаження системи. При цьому створюється кінцева точка TCP і здійснюється відкриття TCP порту 111. Також створюється кінцева точка UDP, яка чекає, коли на UDP порт 111 прибуде датаграма UDP.
При старті програма, що працює через сервер RPC, створює кінцеву точку TCP і кінцеву точку UDP для кожної підтримуваної версії програми. (Сервер RPC може підтримувати кілька версій. Клієнт вказує необхідну версію при надсиланні RPC-дзвінка.) Номер порту, що динамічно призначається, закріплюється за кожною версією сервісу. Сервер реєструє кожну програму, версію, протокол та номер порту, здійснюючи відповідний RPC-дзвінок.
Коли програмі клієнта RPC необхідно отримати необхідну інформацію, вона викликає виклик процедуру перетворювача портів, щоб отримати номер порту, що динамічно призначається, для заданої програми, версії і протоколу.
У відповідь цей запит північ повертає номер порту.
Клієнт відправляє повідомлення RPC-запит на номер порту, отриманий у пункті 4. Якщо використовується UDP, клієнт просто надсилає UDP датаграму, що містить повідомлення RPC-дзвінка, на номер UDP порту, на якому працює сервіс, що запитує. У відповідь сервіс надсилає UDP датаграму, що містить повідомлення RPC відгуку. Якщо використовується TCP, клієнт здійснює активне відкриття на номер TCP порту необхідного сервісу і потім надсилає повідомлення виклику RPC встановленому з'єднанню. Сервер відповідає повідомленням відгуку RPC з'єднання.

Для отримання інформації від сервера RPC використовується утиліта rpcinfo, вона відображає номер зареєстрованої програми, версію, протокол, порт і назву. За допомогою rpcinfo також можна видалити реєстрацію програми або отримати інформацію про окремий сервіс RPC. При наведенні параметрів -p host програма виводить список усіх зареєстрованих RPC програм на хості host. Без вказівки хоста програма виведе послуги на localhost.

NFS сервер (точніше даемон rpc.nfsd) отримує запити від клієнта у вигляді UDP датаграм на порт 2049. Незважаючи на те, що NFS працює з перетворювачем портів, що дозволяє серверу використовувати порти, що динамічно призначаються, UDP порт 2049 жорстко закріплений за NFS в більшості реалізацій .

Опис процесу звернення до файлу на сервері NFS:

Клієнту (процесу користувача) байдуже, чи отримує він доступ до локального файлу або до NFS файлу. Ядро займається взаємодією із залізом через модулі ядра або вбудовані системні виклики.
Модуль ядра kernel/fs/nfs/nfs.ko, який виконує функції NFS клієнта, відправляє RPC запити NFS серверу через модуль TCP/IP. NFS зазвичай використовує UDP, проте нові реалізації можуть використовувати TCP.
NFS сервер отримує запити від клієнта у вигляді UDP датаграм на порт 2049. Незважаючи на те, що NFS може працювати з перетворювачем портів, що дозволяє серверу використовувати порти, що динамічно призначаються, UDP порт 2049 жорстко закріплений за NFS в більшості реалізацій.
Коли сервер NFS отримує запит від клієнта, він передається локальній підпрограмі доступу до файлу, яка забезпечує доступ до локальному дискуна сервері.
Результат обігу диска повертається клієнту.

Налаштування сервера NFS

Налаштування сервера в цілому полягає в завданні локальних каталогів, дозволених для встановлення віддаленими системами у файлі /etc/exports. Ця дія називається експортом ієрархії каталогів. Основними джерелами інформації про експортовані каталоги є такі файли:

Структура папки Root

/etc/exports - основний конфігураційний файл, що містить у собі конфігурацію експортованих каталогів. Використовується при запуску NFS та утиліті exportfs.
/var/lib/nfs/xtab – містить список каталогів, монтованих віддаленими клієнтами. Використовується демоном rpc.mountd, коли клієнт намагається змонтувати ієрархію (створюється запис про монтування).
/var/lib/nfs/etab - список каталогів, які можуть бути змонтовані віддаленими системами із зазначенням усіх параметрів експортованих каталогів.
/var/lib/nfs/rmtab - список каталогів, які не розекспортовані на даний момент.
/proc/fs/nfsd – спеціальна файлова система (ядро 2.6) для управління NFS сервером.
/proc/net/rpc - містить "сиру" (raw) статистику, яку можна отримати за допомогою nfsstat, а також різні кеші.
/var/run/portmap_mapping - інформація про зареєстровані в RPC сервісах.

У файлі exports використовуються такі загальні опції:

auth_nlm (no_auth_nlm) або secure_locks (insecure_locks) – вказує, що сервер повинен вимагати автентифікацію запитів на блокування (за допомогою протоколу NFS Lock Manager (диспетчер блокування NFS)).
nohide (hide) - якщо сервер експортує дві ієрархії каталогів, при цьому одна вкладена (примонтована) в іншу. Клієнту необхідно явно змонтувати другу (дочірню) ієрархію, інакше точка монтування дочірньої ієрархії виглядатиме як порожній каталог. Опція nohide призводить до появи другої ієрархії каталогів без явного монтування.
ro - Дозволяє лише запити на читання.
rw - Дозволяє запити на запис.
secure (insecure) - вимагає, щоб запити NFS надходили із захищених портів (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
subtree_check (no_subtree_check) - Якщо експортується підкаталог фалової системи, але не вся файлова система, сервер перевіряє, чи файл в експортованому підкаталозі. Вимкнення перевірки зменшує безпеку, але збільшує швидкість передачі даних.
sync (async) – вказує, що сервер повинен відповідати на запити лише після запису на диск змін, виконаних цими запитами. Опція async показує серверу не чекати запису інформації на диск, що підвищує продуктивність, але знижує надійність, т.к. у разі обриву з'єднання або відмови обладнання можлива втрата інформації.
wdelay (no_wdelay) - вказує серверу затримувати виконання запитів на запис, якщо очікується наступний запит на запис, записуючи дані більшими блоками. Це підвищує продуктивність при надсиланні великих черг команд на запис. no_wdelay вказує не відкладати виконання команди на запис, що може бути корисно, якщо сервер отримує велику кількість команд, не пов'язаних один з одним.

Керування сервером NFS

Керування сервером NFS здійснюється за допомогою наступних утиліт:

nfsstat
showmsecure (insecure)ount
exportfs

Утиліта nfsstat дозволяє переглянути статистику RPC і NFS серверів.

showmount

Утиліта showmount запитує демон rpc.mountd на віддаленому хості про змонтовані файлові системи. За промовчанням видається відсортований список клієнтів. Команди:

--all - видається список клієнтів та точок монтування із зазначенням куди клієнт примонтував каталог. Ця інформація може бути ненадійною.
--directories - видається список точок монтування.
--exports - видається список файлових систем, що експортуються з точки зору nfsd.

При запуску showmount без аргументів на консоль буде виведена інформація про системи, яким дозволено монтувати локальні каталоги.

exportfs

Ця команда синхронізує експортовані каталоги, задані у файлі /etc/exports, із файлом /var/lib/nfs/xtab і видаляє з xtab неіснуючі. exportfs виконується під час запуску демона nfsd з аргументом -r. Утиліта exportfs в режимі ядра 2.6 спілкується з демоном rpc.mountd через файли каталогу /var/lib/nfs/ і не спілкується безпосередньо з ядром. Без параметрів видає список поточних файлових систем, що експортуються. Параметри exportfs:

[клієнт:ім'я-каталогу] - додати або видалити вказану файлову систему для вказаного клієнта)
-v - виводити більше інформації
-r - переекспортувати всі каталоги (синхронізувати /etc/exports та /var/lib/nfs/xtab)
-u - видалити зі списку експортованих
-a - додати або видалити всі файлові системи
-o - опції через кому (аналогічний опціям застосовуваним в / etc / exports; т.ч. можна змінювати опції вже змонтованих файлових систем)
-i - не використовувати /etc/exports при додаванні тільки параметри поточного командного рядка
-f – скинути список експортованих систем у ядрі 2.6.

Монтування файлової системи Network Files System командою mount

Приклад команди mount для монтування файлової системи NFSу Debian:

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

Перша команда монтує експортований каталог /archiv-small на сервері archiv у локальну точку монтування /archivs/archiv-small з параметрами за промовчанням (тобто для читання та запису). Друга команда монтує експортований каталог /archiv-big на сервері archiv у локальний каталог /archivs/archiv-big з опцією лише для читання (ro). Команда mountбез параметрів наочно відображає результат монтування. Крім опції тільки читання (ro), можна встановити інші основні опції при монтуванні NFS :

nosuid - Ця опція забороняє виконувати setuid програми зі змонтованого каталогу.
nodev (no device - не пристрій) - Дана опція забороняє використовувати як пристрої символьні та блокові спеціальні файли.
lock (nolock) - Дозволяє блокувати NFS (за замовчуванням). nolock вимикає блокування NFS (не запускає демон lockd) і зручна при роботі зі старими серверами, які не підтримують блокування NFS.
mounthost=ім'я - Ім'я хоста, на якому запущено демон монтування NFS - mountd.
mountport=n - Порт, який використовується демоном mountd.
port=n - порт, який використовується для підключення до NFS серверу (за умовчанням 2049, якщо демон rpc.nfsd не зареєстрований на RPC-сервері). Якщо n=0 (за замовчуванням), NFS надсилає запит до portmap на сервері, щоб визначити порт.
rsize = n (read block size - розмір блоку читання) - Кількість байтів, що читаються за один раз з NFS-сервера. Стандартно – 4096.
wsize=n (write block size - розмір блоку записи) - Кількість байтів, записуваних один раз на NFS-сервер. Стандартно – 4096.
tcp або udp - Для встановлення NFS використовувати протокол TCP або UDP відповідно.
bg - При втраті доступу до сервера, повторювати спроби в фоновому режиміщоб не блокувати процес завантаження системи.
fg - При втраті доступу до сервера, повторювати спроби у пріоритетному режимі. Цей параметр може заблокувати процес завантаження системи повторення спроб монтування. З цієї причини параметр fg використовується переважно при налагодженні.
Опції, що впливають на кешування атрибутів при монтуванні NFS
Атрибути файлів, що зберігаються в inod ( індексних дескрипторів), такі як час модифікації, розмір, жорсткі посилання, власник зазвичай змінюються не часто для звичайних файлів і ще рідше - для каталогів. Ядро використовує час модифікації файлу, щоб визначити чи застарів кеш, порівнюючи час модифікації в кеші та час модифікації самого файлу.

Кеш атрибутів періодично оновлюється відповідно до заданих параметрів:

ac (noac) (attrebute cache - кешування атрибутів) - Дозволяє кешування атрибутів (за замовчуванням). Хоча опція noac уповільнює роботу сервера, вона дозволяє уникнути старіння атрибутів, коли кілька клієнтів активно записують інформацію у загальну ієрархію.
acdirmax=n (attribute cache directory file maximum - кешування атрибуту максимум для файлу каталогу) - Максимальна кількістьсекунд, яке NFS очікує до оновлення атрибутів каталогу (за замовчуванням 60 сек.)
acdirmin=n (attribute cache directory file minimum - кешування атрибуту мінімум для файлу каталогу) - Мінімальна кількість секунд, що NFS очікує до оновлення атрибутів каталогу (за замовчуванням 30 сек.)
acregmax=n (attribute cache regular file maximum - кешування атрибуту максимум для звичайного файлу) - Максимальна кількість секунд, що NFS очікує до оновлення атрибутів звичайного файлу (за замовчуванням 60 сек.)
acregmin = n (attribute cache regular file minimum - кешування атрибуту мінімум для звичайного файлу) - Мінімальна кількість секунд, що NFS очікує до оновлення атрибутів звичайного файлу (за замовчуванням 3 сек.)
actimeo=n (attribute cache timeout - тайм-аут кешування атрибутів) - Замінює значення для всіх вишуканих опцій. Якщо actimeo не заданий, вищезазначені значення набувають значення за замовчуванням.

Опції обробки помилок NFS

Наступні опції керують діями NFS за відсутності відповіді від сервера або у разі виникнення помилок вводу/виводу:

fg (bg) (foreground - передній план, background - задній план) - робити спроби монтування відмовила NFS на передньому плані/у фоні.
hard (soft) - виводить на консоль повідомлення "server not responding" при досягненні таймауту та продовжує спроби монтування. При заданій опції soft - при таймууті повідомляє програму про помилку введення/виводу, що викликала операцію.
nointr (intr) (no interrupt - не переривати) - Не дозволяє сигналам переривати файлові операції у жорстко змонтованій ієрархії каталогів при досягненні великого таймууту. intr - дозволяє переривання.
retrans=n (retransmission value - значення повторної передачі) - Після n малих таймаутів NFS генерує великий таймаут (за замовчуванням 3). Великий тайм-аут припиняє виконання операцій або виводить на консоль повідомлення "server not responding", залежно від вказівки опції hard/soft.
retry=n (retry value - значення повторної спроби) - Кількість хвилин повторень служби NFS операцій монтування, перш ніж здатися (за замовчуванням 10000).
timeo=n (timeout value - значення тайм-аут) - Кількість десятих часток секунди очікування службою NFS до повторної передачі у разі RPC або малого тайм-аут (за замовчуванням 7). Це значення збільшується при кожному таймуті до максимального значення 60 секунд або до великого таймууту. У разі зайнятої мережі, повільного сервера або при проходженні запиту через кілька маршрутизаторів або шлюзів, збільшення цього значення може підвищити продуктивність.

Підвищення продуктивності NFS

На продуктивність NFS можуть впливати кілька параметрів, особливо під час роботи через повільні з'єднання. При роботі з повільними та високонавантаженими з'єднаннями, бажано використовувати параметр hard, щоб таймаути не призвели до припинення роботи програм. Але необхідно усвідомлювати, що якщо змонтувати файлову систему через NFS з параметром hard через fstab, а віддалений хост виявиться недоступним, то завантаження системи відбудеться зависання.

Одним із способів підвищення продуктивності NFS - збільшення кількості байтів, що передаються за один раз. Розмір 4096 байт занадто малий для сучасних швидких з'єднань, збільшуючи це значення до 8192 і більше можна експериментальним шляхом знайти оптимальну швидкість.

Так само, не варто упускати з уваги та налаштування тайм-аутів. NFS очікує відповіді на пересилання даних протягом проміжку часу, зазначеного в опції timeo, якщо відповіді за цей час не отримано, то виконується повторне пересилання. На завантажених і повільних з'єднаннях цей час може бути меншим за час реакції сервера і здібності каналів зв'язку, внаслідок чого можуть бути зайві повторні пересилання, що уповільнюють роботу. За умовчанням, timeo дорівнює 0,7 сек (700 мілісекунд). після виявлення факту обриву зв'язку протягом 700 мс сервер здійснить повторне пересилання і подвоїть час очікування до 1,4 сек., збільшення timeo триватиме до максимального значення 60 сек.

NFS (Network File System)— мережний протокол доступу до доступу до файлів та файлової системи NFS-сервера, популярний у сімейства ОС Linux/UNIX, а також різних систем зберігання. Microsoft також, не бажаючи відставати від конкурентів, впровадила базовий функціонал сервера NFS ще в Windows Server 2003 R2. У наступних версіях серверних платформМайкрософт можливості вбудованого NFS Windows сервера розширювалися, з'являвся новий функціоналта засоби управління. NFS сервер у Windows Server 2012 – чергова віха у розвитку даної технології.

Що нового пропонують розробники Microsoft у цьому продукті? Нові можливості NFS сервера у Windows Server 2012:

Підтримка стандарту NFS v4.1. Підтримка останньої версії NFS 4.1 – одна з основних новацій Windows Server 2012. У порівнянні з NFS v3 цей протокол забезпечує підвищену безпеку, продуктивність та сумісність, повністю реалізуючи всі аспекти RFC 5661.
Продуктивність із коробки.Завдяки використанню нової транспортної інфраструктури RPC-XDR оптимальна продуктивність NFS сервера може бути досягнута відразу «з коробки» без необхідності тонкого налаштування параметрів системи. Оптимальна продуктивність досягається за рахунок кешу, що автоматично налаштовується, поділу робочих процесів на пули і динамічне управління пулами, засноване на їх навантаженні.
Спрощене розгортання та управління. Цей фактдосягнуто за рахунок:
- — більше 40 командлетів PowerShell для налаштування сервера NFS та керування спільними папками
- - простого графічного інтерфейсууправління, що дозволяє одночасно керувати як SMB, так і NFS кулями, а також налаштуваннями скринінгу файлів та .
- - фіксації RPC порту (порт 2049) для простоти налаштування фаєрволів
- нового провайдера WMI v2
- - Спрощена ідентифікація за рахунок плоского файлу мапінга
Поліпшення в NFSv3. За рахунок швидкої відправки клієнтам повідомлень про збої монітором NSM (Network Status Monitor), старі NFS клієнти краще та швидше обробляють процедуру failover, що означає менший час простою.

Отже, NFS сервер у Windows Server 2012 значно покращено з погляду простоти розгортання, масштабованість, стабільність, доступність, надійність, безпеку та сумісність. Загальні папки можуть бути одночасно доступні за протоколами SMB і NFS, що означає можливість використання Windows Server 2012 як сховища в гетерогенних мережах.

NFS сервер у Windows Server 2012 можна встановити за допомогою GUI та Powershell. Щоб встановити сервер NFS за допомогою графічного інтерфейсу, відкрийте і всередині ролі файлового сервера(File and Storage Services) позначте компонент Server for NFS.

Після встановлення компонента NFS, сервер необхідно перезавантажити.

Встановлення цієї ролі за допомогою Powershell також не викликає труднощів, просто виконайте команду:

Add-WindowsFeature "FS-NFS-Service"

Налаштування спільної папки NFS у Windows Server 2012

Далі ми покажемо, як за допомогою встановленої нами ролі створити NFS кулі (загальну папку) на сервері Windows. Створити NFS кулі можна ще кількома способами: за допомогою графічного інтерфейсу або Powershell.

Створення загального каталогу NFS за допомогою консолі Server Manager

Відкрийте консоль Server Manager , перейдіть до розділу Share management(перебуває всередині ролі File and Storage Services).
У контекстному меню запустіть майстер створення нового загального каталогу. New Share…

Виберіть тип кулі NFSShareQuick

Потім необхідно задати тип аутентифікації NFS клієнтів: можливо, задіяти як аутентифікацію Kerberos, так і анонімну.

Припустимо, як споживача створюваного NFS ресурсу виступатиме сервер віртуалізації ESXi, у якому можливість аутентифікувати NFS з'єднання відсутня (ESXi не підтримує NFSv4). Тому тип аутентифікації буде No Server Authentication, відзначимо також опції Enable unmapped user accessі Allow unmapped user access by UID/GID.

Щоб трохи убезпечити створювану NFS кулі від доступу сторонніх осіб, обмежимо доступ до NFS ресурсу за адресою IP клієнта.

Host: 192.168.1.100
Language Encoding: BIG5
Share Permissions: Read/Write
Allow root access: Yes

Далі залишилося перевірити, що на рівні NTFS користувач, у якого працює підключається користувач, має доступ на читання / запис (якщо вирішено задіяти анонімний доступ, доведеться користувачу Everyone дати повні r/w права лише на рівні NTFS).

Як створити NFS кулі за допомогою Powershell

Створимо нову NFS кулі:

New-NfsShare -Name "NFS" -Path "d:\shares\nfr" -AllowRootAccess $true -Permission Readwrite -Authentication sys

Дозволимо доступ до кулі для IP адреси 192.168.1.100 і задамо кодування BIG5 (можливість перегляду вмісту NFS куль для клієнта ESXi).

Grant-NfsSharePermission -Name “NFS” -ClientName 192.168.1.100 -ClientType host -LanguageEncoding BIG5

Створену NFS кулі можна використовувати, наприклад, як NFS-datastore у середовищі віртуалізації, або для доступу до даних з інших Unix-like клієнтів. Як змонтувати NFS кулі у Windows – клієнтах описано у статті.

Коли йдеться про комп'ютерних мережах, часто можна почути згадку NFS. Що таке означає ця абревіатура?

Це протокол розподіленої файлової системи, спочатку розроблений компанією Sun Microsystems в 1984 році, що дозволяє користувачеві на клієнтському комп'ютері отримувати доступ до файлів через мережу, подібно до доступу до локальному сховищу. NFS, як і багато інших протоколів, ґрунтується на системі Open Network Computing Remote Procedure Call (ONC RPC).

Інакше кажучи, що таке NFS? Це відкритий стандарт, визначений у Request for Comments (RFC), що дозволяє реалізувати протокол.

Версії та варіації

Винахідник використовував лише першу версію для власних експериментальних цілей. Коли команда розробників додала суттєві зміни до початкової NFS і випустила її за межами авторства Sun, вони позначили нову версіюяк v2, щоб можна було протестувати взаємодію між дистрибутивами та створити резервний варіант.

NFS v2

Версія 2 спочатку працювала лише за протоколом User Datagram Protocol (UDP). Її розробники хотіли зберегти серверну сторону без блокування, реалізованого поза основного протоколу.

Інтерфейс віртуальної файлової системи дозволяє виконувати модульну реалізацію, відбиту у простому протоколі. До лютого 1986 були продемонстровані рішення для таких операційних систем, як System V release 2, DOS і VAX/VMS з використанням Eunice. NFS v2 дозволяв зчитувати лише перші 2 ГБ файлу через 32-розрядні обмеження.

NFS v3

Перша пропозиція з розробки NFS версії 3 у Sun Microsystems була озвучена невдовзі після випуску другого дистрибутива. Головною мотивацією була спроба пом'якшити проблему продуктивності синхронного запису. До липня 1992 року практичні доопрацювання дозволили вирішити багато недоліків NFS версії 2, залишивши при цьому лише недостатню підтримку файлів (64-розрядні розміри та зміщення файлів).

підтримку 64-бітних розмірів та зміщень файлів для обробки даних розміром понад 2 гігабайти (ГБ);
підтримку асинхронного запису на сервері підвищення продуктивності;
додаткові атрибути файлів у багатьох відповідях, що дозволяють уникнути їх повторного вилучення;
операцію READDIRPLUS для отримання даних та атрибутів разом з іменами файлів під час сканування каталогу;
багато інших покращень.

Під час введення версії 3 підтримка TCP як протокол транспортного рівня почала збільшуватися. Використання TCP як засіб передачі даних, виконаного з використанням NFS через WAN, стало дозволяти передавати великі розмірифайлів для перегляду та запису. Завдяки цьому розробники змогли подолати межі обмежень у 8 КБ, що накладаються протоколом користувацьких дейтаграм (UDP).

Що таке NFS v4?

Версія 4, розроблена під впливом Ендрської файлової системи (AFS) і блоку повідомлень сервера (SMB, також звана CIFS), включає підвищення продуктивності, забезпечує кращу безпеку і вводить протокол з дотриманням встановлених умов.

Версія 4 стала першим дистрибутивом, розробленим у Цільовій групі Internet Engineering Task Force (IETF) після того, як Sun Microsystems передала розробку протоколів стороннім фахівцям.

NFS версія 4.1 спрямована на надання підтримки протоколу для використання кластерних розгортань серверів, включаючи можливість надання масштабованого паралельного доступу до файлів, розподілених між кількома серверами (розширення pNFS).

Новий протокол файлової системи – NFS 4.2 (RFC 7862) – був офіційно випущений у листопаді 2016 року.

Інші розширення

З розвитком стандарту з'явилися відповідні інструменти для роботи з ним. Так, WebNFS, розширення для версій 2 і 3, дозволяє протоколу мережного доступу до файлових систем легше інтегруватися у веб-браузер і активувати роботу через брандмауери.

Різні протоколи сторонніх груп також стали асоціюватися з NFS. З них найбільш відомими виступають:

Network Lock Manager (NLM) з підтримкою протоколу байтів (доданий для підтримки API-блокування файлів UNIX System V);
віддаленої квоти (RQUOTAD), що дозволяє користувачам NFS переглядати квоти на зберігання даних на серверах NFS;
NFS через RDMA - адаптація NFS, яка використовує дистанційний прямий доступ до пам'яті (RDMA) як засіб передачі;
NFS-Ganesha - сервер NFS, що працює в просторі користувача і підтримує CephFS FSAL (рівень абстракції файлової системи) з використанням libcephfs.

Платформи

Network File System часто використовується з операційними системами Unix (такими як Solaris, AIX, HP-UX), MacOS від Apple та Unix-подібними ОС (такими як Linux та FreeBSD).

Він також доступний для таких платформ, як Acorn RISC OS, OpenVMS, MS-DOS, Microsoft Windows, Novell NetWare та IBM AS/400.

Альтернативні протоколи віддаленого доступу до файлів включають блок повідомлень сервера (SMB, також званий CIFS), протокол передачі Apple (AFP), базовий протокол NetWare (NCP) та файлову систему сервера OS/400 (QFileSvr.400).

Це пов'язано з вимогами NFS, які орієнтовані здебільшого на Unix-подібні оболонки.

При цьому протоколи SMBі NetWare (NCP) застосовуються частіше, ніж NFS, в системах під керуванням Microsoft Windows. AFP найбільш поширений у платформах Apple Macintosh, а QFileSvr.400 найчастіше зустрічається в OS/400.

Типова реалізація

Передбачаючи типовий сценарій у стилі Unix, в якому одному комп'ютеру (клієнту) потрібен доступ до даних, що зберігаються на іншому (сервер NFS):

Сервер реалізує процеси Network File System, запущені за умовчанням як nfsd, щоб зробити дані загальнодоступними для клієнтів. Адміністратор сервера визначає, як експортувати імена та параметри каталогів, зазвичай використовуючи файл конфігурації/etc/exports та команду exportfs.
Адміністрація безпеки сервера гарантує, що він зможе розпізнавати та затверджувати перевіреного клієнта. Конфігурація мережі гарантує, що відповідні клієнти можуть вести переговори з ним через будь-яку систему брандмауера.
Клієнтська машина запитує доступ до експортованих даних, зазвичай, шляхом видачі відповідної команди. Вона запитує сервер (rpcbind), який використовує порт NFS, і потім підключається до нього.
Якщо все відбувається без помилок, користувачі клієнтській машинізможуть переглядати та взаємодіяти зі встановленими файловими системами на сервері в межах дозволених параметрів.

Слід звернути увагу на те, що автоматизація процесу Network File System також може мати місце - можливо, з використанням etc/fstab та/або інших подібних засобів.

Розвиток на сьогодні

До 21-го століття протоколи-конкуренти DFS та AFS не досягли будь-якого великого комерційного успіху в порівнянні з Network File System. Компанія IBM, яка раніше придбала всі комерційні права на вищезазначені технології, безоплатно передала більшу частину вихідного коду AFS спільноті вільних розробників програмного забезпечення у 2000 році. Проект Open AFS існує й у наші дні. На початку 2005 року IBM оголосила про завершення продажів AFS та DFS.

У свою чергу, у січні 2010 року компанія Panasas запропонувала NFS v 4.1 на основі технології, що дозволяє покращити можливості паралельного доступу до даних. Протокол Network File System v 4.1 визначає метод поділу метаданих файлової системи з розташування певних файлів. Таким чином, він виходить за рамки простого поділу імен/даних.

Що таке NFS цієї версії на практиці? Вищезгадана особливість відрізняє його від традиційного протоколу, який містить імена файлів та їх даних під однією прив'язкою до сервера. При реалізації Network File System v 4.1 деякі файли можуть розподілятися між багатовузловими серверами, проте участь клієнта у розділенні метаданих та даних обмежена.

При реалізації четвертого дистрибутива протоколу NFS-сервер є набір серверних ресурсівабо компонентів; передбачається, що вони контролюються сервером метаданих.

Клієнт, як і раніше, звертається до одного серверу метаданих для обходу або взаємодії з простором імен. Коли він переміщує файли на сервер і з нього, він може взаємодіяти безпосередньо з набором даних, що належать групі NFS.

Для роздачі файлів усередині локальної мережі можна виділити такі технології (розглядаються системи на базі Linux):

Network File System (NFS) – протокол мережного доступу до файлових систем;
Files transferred over Shell protocol (FISH) - мережевий протокол, який використовує або RSHпередачі файлів між комп'ютерами;
Secure SHell FileSystem (SSHFS) – клієнт файлової системи для монтування дискових пристроївна віддалених системах, для взаємодії з віддаленою системою використовується SFTP;
Samba – пакет програм, які дозволяють звертатися до мережним дискамта принтерам на різних операційних системах за протоколом SMB/CIFS;

У цій статті мова піде про NFS.

NFS (Network File System)корисна, коли потрібно роздати файли/директорії всім усередині мережі. Прозорість доступу за допомогою NFSдозволяє клієнтам підключити віддалену файлову систему як локальну директорію, причому файлові системи можуть бути різних типів. Це означає, що будь-яка програма клієнта, яка може працювати з локальним файлом, з таким же успіхом може працювати і з файлом підключеним по NFSбез будь-яких модифікацій самої програми.

До переваг NFSможна віднести:

зменшення навантаження на процесор;

відображення спільно використовуваних ресурсів як традиційних директорій у системі;

На даний момент доступна NFS v4.1, в якій запровадили нову можливість pNFSщо дозволяє розпаралелити реалізацію загального доступу до файлів. Також є розширення для NFS 2 та 3 - WebNFS, яка дозволяє легше інтегруватися в веб-браузери і дає можливість працювати через брандмауер.

Схема роботи NFSпротоколу.

Встановлення та налаштування NFS-сервер під Linux

Перевіримо, чи підтримує система NFS

Cat /proc/filesystems | grep nfs

Під Arch Linuxсервер та клієнт перебувати в одному пакеті

Yaourt -S nfs-utils

Для встановлення сервера ( nfs-kernel-server) та клієнта ( nfs-common) під Ubuntuнеобхідні пакети

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

Далі в замітці для сервера використовуватиметься IP 192.168.1.100 . Для того щоб за сервером завжди був закріплений один і той же IP необхідно в DHCP-сервері (найчастіше роутер) вказати роздачу конкретної IP конкретної MAC-адреси. Або підняти свій локальний DNS-сервер. Наприклад, або .

MAC-адресу можна дізнатися за допомогою ifconfig (поле etherв Arch Linux).

NFSv4припускає, що є коренева директорія, всередині якої вже розташовані файли для роздачі. Наприклад, /srv/nfs- корінь, /srv/nfs/audio- Директорія для роздачі музики. Якщо не дотримуватися цієї нової вказівки у версії 4 , то можна отримати помилку при підключенні клієнтом:

Mount.nfs: access denied by server while mounting 192.168.1.100:/home/proft/torrents

Якщо все ж таки хочеться використовувати на сервері підхід без кореневої-директорії для NFS, то при монтуванні клієнтом треба явно вказати версію 3

# для команди mount mount -o "vers=3" 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents # для fstab 192.168.1.100:/home/proft/torrents /home/proft/nfs/ torrents nfs soft,nfsvers=3 0 0

Я буду використовувати NFSv4з root-директорією в /srv/nfs/та монтуванням вкладених директорій за допомогою mount --bind .

Припустимо, що ми хочемо

роздавати директорію ~/torrentsз rwдоступом для всіхусередині локальної мережі;
роздавати директорію ~/photosз roдоступом для хоста з IP 192.168.1.101 ;

Для початку створимо кореневу директоріюта необхідні вкладені.

Sudo mkdir -p /srv/nfs/(torrents,photos)

Примонтуємо існуючі директорії torrents, photosв /srv/nfs.

# sudo vim /etc/fstab /home/proft/torrents /srv/nfs/torrents none bind 0 0 /home/proft/photos /srv/nfs/photos none bind 0 0

Відредагуємо /etc/exports, в якому описуються всі директорії для спільного доступу

# sudo vim /etc/exports # формат файлу: directory allowed-hosts(options) /srv/nfs/torrents 192.168.1.1/24(rw,async) /srv/nfs/photos 192.168.1.101(ro,async)

Зверніть увагу на відсутність пробілу між allowed-hostsі (options). Наявність пропуску вводить інше трактування правил.

Доступні опції:

ro (rw) - дозволити доступ лише читання (читання/запис);
subtree_check (no_subtree_check) - у деяких випадках доводиться експортувати не весь розділ, лише його частина. При цьому сервер NFSповинен виконувати додаткову перевірку звернень клієнтів, щоб переконатися, що вони роблять спробу доступу лише до файлів, які у відповідних подкаталогах. Такий контроль піддерева ( subtree checks) Дещо уповільнює взаємодію з клієнтами, але якщо відмовитися від нього, можуть виникнути проблеми з безпекою системи. Скасувати контроль піддерева можна за допомогою опції no_subtree_check. Опція subtree_check, Що включає такий контроль, передбачається за умовчанням. Контроль піддерева можна не виконувати в тому випадку, якщо каталог, що експортується, збігається з розділом диска;
sync (async) – вказує, що сервер повинен відповідати на запити лише після запису на диск змін, виконаних цими запитами. Опція asyncпоказує серверу чекати запису інформації на диск, що підвищує продуктивність, але знижує надійність, т.к. у разі обриву з'єднання або відмови обладнання можлива втрата даних;
noaccess – забороняє доступ до зазначеної директорії. Може бути корисною, якщо перед цим було задано доступ всім користувачам мережі до певної директорії, і тепер хочете обмежити доступ у піддиректорії лише деяким користувачам;
no_root_squash – за замовчуванням користувач rootна клієнтській машині не матиме тих же прав до директорії на сервері. Ця опція знімає це обмеження;
nohide - NFSавтоматично не показує нелокальні ресурси (наприклад, примонтовані за допомогою mount --bind); ця опція включає відображення таких ресурсів;
insecure - використання непривілейованих портів (>1024);

Запускаємо NFS-сервер

# під archlinux sudo systemctl start rpc-idmapd.service rpc-mountd.service # під ubuntu sudo /etc/init.d/nfs-kernel-server start

Надалі при зміні конфігураційного файлу достатньо його перечитати командою:

Sudo exportfs -rav

Команда rpcinfo-p | grep nfs дозволяє перевірити успішність запуску сервера.

Клієнт під Linux

Встановлення

# під archlinux yaourt -S nfs-utils # під ubuntu sudo apt-get install portmap nfs-common

Створимо директорії для монтування мережевих ресурсів torrentsі photos

Mkdir -p ~/nfs/(torrents,photos)

Для ручного монтування виконаємо

192.168.1.100:/srv/nfs/torrents /home/proft/nfs/torrents sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nf /proft/nfs/photos

Опція softвказує тихо скасувати спроби підключити кулі після певної кількості часу (час задається опцією retrans). Детальніше у man nfs.

Цей спосіб не дуже зручний, оскільки кожного разу після перезавантаження доведеться виконувати ці команди. Зробимо монтування автоматичним.

Для автоматичного монтування редагуємо файл /etc/fstab

# sudo vim /etc/fstab 192.168.1.100:/srv/nfs/torrents /home/proft/net/torrents nfs rw,soft 0 0 192.168.1.100:/srv/nfs/photos /home/proft/net/photo ro,soft 0 0

Але й цей спосіб має свої недоліки, наприклад, якщо сервер не доступний, то завантаження клієнта може підвиснути через спроби підключитися до NFS-сервера. Для виправлення цього див. AutoFS.

AutoFS - автоматичне підключеннямережевих ресурсів

Є можливість монтувати віддалений ресурсза допомогою AutoFSпри першому зверненні та автоматично відмонтувати за відсутності активності.

AutoFSвикористовує для налаштування шаблони, розташовані в /etc/autofs. Основний шаблон називається auto.master, він може вказувати на один або кілька інших шаблонів для конкретних типівносіїв.

Встановлення

# під archlinux yaourt -S autofs # під ubuntu sudo apt-get install autofs

Існує кілька способів зазначити способи автомонтування. Я використовую такий: /home/proft/nfsавтоматично створюється директорія з ім'ям сервера NFS, в якій автоматично створюються доступні директорії на сервері.

# sudo vim /etc/autofs/auto.master /home/proft/nfs /etc/autofs/auto.nfs --timeout=60

Додатковий параметр timeoutвстановлює кількість секунд після яких пристрій буде розмонтовано. Параметр ghostвказує що налаштовані ресурси будуть відображатися завжди, а не тільки тоді, коли вони доступні (ця опція включена за замовчуванням у AutoFS 5)

Опишемо в /etc/autofs/auto.nfs NFS-сервер та root-директорію.

# sudo vim /etc/autofs/auto.nfs nfsserver 192.168.1.100:/srv/nfs

Тепер при першому зверненні /home/proft/nfs/torrentsстанеться автоматичне монтування NFS-ресурсу.

Перезапустимо службу autofs:

# під archlinux sudo systemctl restart autofs # під ubuntu sudo /etc/init.d/autofs restart

Також можна вказати час очікування доступності NFS-ресурсу. Для цього необхідно змінити значення MOUNT_WAIT.

# під archlinux # sudo vim /etc/conf.d/autofs MOUNT_WAIT=5 # під ubuntu sudo /etc/default/autofs MOUNT_WAIT=5

Форсування використання NFS v3

В деяких випадках NFSv4може працювати повільно. Для виправлення цього можна вказати використовувати третю версію.

» і вже маєш уявлення про «мережеву файлову систему», її можливості та ступінь захищеності. Однак у зазначеній статті все розбиралося в основному з погляду клієнта ... а от як бути якщо тобі захотілося мати власний NFS-сервер? (прим.: «набути» не означає «зламати», а значить «встановити і налаштувати»).

Ну, а якщо бажання таке у тебе з'явилося, то перше питання, яке ти маєш поставити собі: «А нафіга козі баян?». Бо ставити NFS-сервер у себе вдома
досить безглуздо - ніхто не оцінить, а от якщо тобі пощастило адмінити в конторі «людей у чорному», або в новомодній Додому мережі» - Тоді зовсім інша справа ...

Запустити сам сервер справа досить нехитра, якщо ти читав попередню статтю, цілком з цим впораєшся. Отже, тобі знадобляться такі демони:

nfsd - безпосереднє обслуговування протоколу
NFS;
mountd - обслуговування операцій монтування;
rpc.portmap - демон портів RPC; потрібен оскільки запити до NFS-сервера передаються у вигляді пакетів
RPC;

Як це зробити? Дуже просто - сходи у файл "/etc/rc.d/rc.inet2" і розкоментуй відповідні рядки. Все можна вважати, що первинний запускзроблений, трохи складніше буде все це налаштувати.
Перше, що треба вирішити, — це хто і які права має щодо тієї чи іншої інформації. Це налаштовується за допомогою файлу /etc/exports. Дозволи бувають «на читання» та «на читання та запис». Як це налаштовується, описано в «Основах
NFS».

Друге - це звичайно навантаження на сервер, тобто. кількість активних користувачів та їх зразкові запити. Запити до NFS-серверу зазвичай ділять на два типи: перший – коли клієнт працює з атрибутами, другий – коли клієнт запитує безпосередньо дані. Запити першого типу - це пошук файлу, зчитування списку дозволів і т.д., звичайно, ти розумієш, що вони слабо навантажують мережу. Запити другого типу - це передача та прийом від клієнта безпосередньо вмісту файлів; і саме тут постає питання: «що і як часто передаватиметься?» Цей особливо актуальний, якщо ти маєш мережу в 10 Мбіт/сек (ну простіше кажучи — стандартна російська мережа). Якщо ти знаєш, то 10 Мбіт/сек - це трохи більше 1 Мбайт на секунду; Звичайно, якщо постійно будуть передаватися файли розміром в десятки мегабайт, то мережа просто помре. Якщо твоя ситуація саме така, то тобі знадобиться встановити кешування даних на клієнтській машині (демон biod). Тоді, одного разу зажадавши якийсь файл і звернувшись до нього повторно, клієнт не «качати» його наново з сервера, а візьме у себе з кешу; при цьому регулярно перевірятиметься чи не змінився файл на сервері, якщо ж факт зміни буде виявлено, то файл у кеші буде замінений «свіжою версією»
(як ти розумієш, перевірка «змінився чи файл» — це запит «за атрибутами», який найчастіше в сотні разів менший, ніж сам файл).

Що ж: NFS-сервер ми запустили, дозволи на доступ визначили, з навантаженням розібралися… Тепер залишилося забити гвинт необхідною інфою та користуватися
можливостями NFS на повну котушку.

Замість висновку:

Якщо перед тобою стоїть питання організації обміну даними в мережі, то не роздумуючи вибирай NFS — NFS на три голови вище за голову вище, ніж
FTP і на голову вище віндових «куль», а в налаштуванні не така вже й складна.