Встановлення та налаштування NFS сервера та NFS клієнта. Монтування файлової системи Network Files System командою mount. З чого все починалося

Ось, а що далі? Як подивитися фільми та прослухати музичні файлиякі скачали? Невже потрібно записувати їх на диски та переносити їх таким чином на комп'ютер із GUI? Або доведеться копіювати їх за повільним SFTP? Ні! На допомогу приходить NFS! Ні, це не серія гоночних ігор, а Network File System (Мережева Файлова Система).
Network File System (NFS) - це мережна файлова система, що дозволяє користувачам звертатися до файлів і каталогів, розміщених на віддалених комп'ютерах, начебто ці файли і каталоги були локальними. Головною перевагою такої системи є те, що окремо взяті робочі станції можуть використовувати менше власного дискового простору, оскільки дані, що спільно використовуються, зберігаються на окремій машині і доступні для інших машин в мережі. NFS - це клієнт-серверний додаток. Тобто в системі користувача має бути встановлений NFS-клієнт, а на комп'ютерах, які надають свій дисковий простір – NFS-сервер.

Встановлення та налаштування NFS-сервера (192.168.1.2)

1. Встановлюємо. З'єднавшись по SSH з комп'ютером сервером або просто в його консолі вводимо:

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

Це встановить NFS-сервер, а також потрібний пакет portmap.

2. Налаштовуємо. Для налаштування списку дирректорій які ми хочемо відкрити та списку кому ми хочемо їх відкрити відредагуємо файл /etc/exports :

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

У наведеному вище прикладі ми відкрили на сервері директорію /data та її піддиректорії у спільне користування всім комп'ютерам з IP: 192.168.1.1 – 192.168.1.255 з правами читання та запису.

Ще приклад:

/home/serg/ 192.168.1.34(ro,async)

Цей приклад робить доступною домашню директорію користувача serg у режимі лише читання для комп'ютера з IP 192.168.1.34. Всі інші комп'ютери мережі до цієї директорії доступу не будуть.

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

  • ro - права лише на читання. Можна і не вказувати, оскільки вона встановлена ​​за замовчуванням;
  • rw - дає клієнтам право на запис;
  • no_root_squash - за замовчуванням користувач root на клієнтській машиніне матиме доступу до відкритих директорій на сервері. Цією опцією ми знімаємо це обмеження. З метою безпеки цього краще не робити;
  • noaccess – забороняє доступ до зазначеної директорії. Може бути корисною, якщо перед цим ви задали доступ всім користувачам мережі до певної директорії, і тепер хочете обмежити доступ до піддиректорії лише деяким користувачам.

Тепер потрібно перезапустити nfs-kernel-server:

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

Якщо після цього ви захочете змінити щось у файлі /etc/exports , то для того, щоб зміни набули чинності, достатньо виконати таку команду:

Sudo exportfs -a

Всі. NFS-сервер встановлено та налаштовано. Можна переходити до клієнта NFS.

Встановлення та налаштування NFS-клієнт

1. Встановлення. Виконуємо в терміналі комп'ютера, який підключатиметься таке:

Sudo apt-get install portmap nfs-common

2. Налаштування. Для початку створимо директорію в яку монтуватиметься віддалена папка:

Cd ~ mkdir data

Монтувати можна двома способами - щоразу вручну або прописавши опції монтування у файл /etc/fstab.

Спосіб 1. Монтування вручну
Створюємо на робочому столі або в будь-якій іншій папці текстовий файл:

Nano ~/Робочий стіл/nfs-server-connect

Пишемо до нього:

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

Робимо його виконуваним:

Chmod +x ~/Робочий стіл/nfs-server-connect

Тепер, коли необхідно приєднатися до сервера, я виконую цей сценарій у терміналі для того, щоб можна було ввести пароль для sudo.

Спосіб 2. Додавання /etc/fstab
Відкриваємо /etc/fstab:

Sudo nano /etc/fstab

І дописуємо рядок наприкінці файлу:

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

Увага! Замість 192.168.1.2:/data впишіть IP або ім'я сервера та шлях до директорії спільного користування. Опції монтажу можна змінити.

Опція hardжорстко прив'язує директорію на клієнта до сервера і якщо сервер відвалиться, може зависнути і ваш комп'ютер. Опція soft, Як відомо з її назви, не така категорична.

Після збереження файлу можна монтувати віддалену папку.

Користувач може працювати в різний час на різних комп'ютерах. За допомогою файлового сервера вирішується відразу кілька завдань:
  1. регулярне резервне копіюваннявсіх даних: неможливо виконувати цю операцію для кількох десятків чи сотень комп'ютерів, але цілком реально - з єдиного сервера чи кількох серверів.
  2. підвищення надійності зберігання даних: нерозумно кожен комп'ютер мережі оснащувати RAID-масивом, адже переважна більшість файлів на комп'ютері, таких, як встановлені пакетипрограм, які простіше встановити заново, ніж захищати їх від збою; але буде цілком розумним укомплектувати файловий сервер апаратним RAID-масивом або організувати там програмний RAID-масив, хоча б просте віддзеркалення дисків.
  3. зменшення вартості зберігання даних: дорого і неефективно в кожен комп'ютер встановлювати величезний диск на випадок, якщо потрібно зберігати багато даних, але на сервері цілком можна встановити масштабовану дискову підсистемувеликого обсягу.
  4. забезпечення доступу до тих самих даних з будь-якого комп'ютера.

Опис NFS

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

Версії NFS

NFS, розроблена компанією Sun Microsystems, виявилася настільки вдалою, що її реалізації були втілені різними компаніями майже у всіх операційних системах. Існує дещо принципово різних реалізацій NFS. Досить поширена версія NFS 2.0, хоча вже в Solaris 2.5 було введено NFS 3.0. У наступних версіях Solaris, включаючи Solaris 9, NFS були внесені істотні доповнення, але сам протокол залишився сумісним з реалізаціями NFS 3.0 в інших системах. Починаючи з NFS 3.0, підтримується передача пакетів через TCP і UDP, раніше підтримувався тільки UDP.

Будьте уважні! У мережі слід використовувати клієнти та сервери NFS однієї і тієї ж версії. NFS 2.0 можна зустріти у старих системах, наприклад HP-UX 10.0. Спільна робота систем, які використовують різні версії NFS, небажана.

Сумісність NFS та інших служб каталогів, що розділяються.

NFS за змістом та з організації роботи схожа на каталоги, що розділяються(shared folders) системах WindowsАле ці служби використовують абсолютно різні протоколи роботи і між собою не сумісні. Однак існує кілька програмних продуктів, які встановлюють підтримку NFS у системах Windows, тому застосування NFS у мережі з різними операційними системами не становить проблеми, треба лише пам'ятати необхідність використовувати однакові версії NFS .

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

Оскільки комп'ютери на робочих місцях співробітників у Росії зазвичай керуються Windows-системами, як файлові сервери часто використовуються також Windows-системи. Однак нерідко виникає бажання встановити UNIX на файл-сервер, щоб підвищити надійність, скоротити витрати на обладнання або використовувати цей сервер для ряду інших корпоративних потреб: як web-сервер, сервер баз даних і т.п. Щоб не встановлювати додаткове програмне забезпечення для підтримки NFS, в такому випадку достатньо встановити пакет samba на UNIX-машину. Він дозволить їй "прикинутися" Windows-сервером так, щоб усі клієнтські комп'ютери сприймали його як звичайнісінький файл-сервер або принт-сервер Windows-мережі. Пакет samba забезпечує підтримку "рідного" для Windows-мереж протоколу SMB.

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

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

Термінологія NFS

Після налаштування NFS-сервера UNIX-комп'ютер надаватиме доступ зовнішнім користувачам до деяких каталогів своєї файлової системи. Таке надання доступу називається "експортом": кажуть, що система експортує свої каталоги. Як саме каталоги експортуватимуться, визначається списком, який задає системний адміністратор. У більшості систем UNIXцей список міститься у файлі /etc/exports, але в Solaris він знаходиться в іншому файлі - /etc/dfs/dfstab.

NFS працює за допомогою механізму віддаленого виклику процедур ( RPC - Remote Procedure Call).

Що таке RPC

Ідеологія RPC дуже проста та приваблива для програміста. Як зазвичай працює мережевий додаток? Воно слідує деякому протоколу (наприклад, HTTP): формує пакет із запитом, викликає системну функцію встановлення з'єднання, потім функцію відправки пакета, потім чекає пакету у відповідь і викликає функцію закриття з'єднання. Це означає, що вся робота з мережею є турботою програміста, який пише додаток: він повинен пам'ятати про виклик функцій мережевого API системидумати про дії у випадку збоїв мережі.

RPC передбачає інший спосіб обміну даними між клієнтом та сервером. З точки зору програміста, додаток клієнта, що працює за допомогою RPC, викликає функцію на сервері, вона виконується та повертає результат. Пересилання запиту на виконання функції через мережу та повернення результатів від сервера клієнту відбувається непомітно для програми, тому останнє не повинно турбуватися ні про збої мережі, ні про деталі реалізації. транспортного протоколу.

Щоб забезпечити прозорість пересилання даних через мережу, придумана двоступінчаста процедура. На сервері будь-який додаток, що надає свій сервіс через RPC, повинен зареєструватися в програмі, яка називається транслятором портів (port mapper). Функція цієї програми - встановлювати відповідність між номером процедури RPC, яку запросив клієнт, і номером TCP або UDP порту, на якому програма сервера чекає на запити. Взагалі, RPC може працювати не тільки з TCP або UDP. У Solaris реалізована робота на базі механізму TI (TransportIndependent), тому в Solaris транслятор портів називається rpcbind, а не portmap, як у Linux чи FreeBSD.

Додаток, який реєструється у транслятора портів, повідомляє номер програми, номер версії та номери процедур, які можуть оброблятися даною програмою. Ці процедури будуть викликатися згодом клієнтом за номером. Крім цього, додаток повідомляє номери портів TCP та UDP, які будуть використовуватись для прийому запитів на виконання процедур.

Клієнт, який бажає викликати виконання процедури на сервері, спочатку надсилає запит транслятору портів на сервер, щоб дізнатися, який TCP або UDP порт треба відправити запит. Транслятор портів запускається при старті системи та завжди працює на стандартному порту 111. Отримавши відповідь, клієнт відправляє запит на той порт, який відповідає потрібному додатку. Наприклад, сервер NFS працює на порті 2049.

Процедура монтування загального каталогу через NFS

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

Клієнт NFS надсилає запит на монтування віддаленому комп'ютеру, який надає свою файлову систему(зазвичай - деяку її частину) для загального користування. При цьому говорять, що сервер NFS "експортує" той чи інший каталог (маю на увазі - з підкаталогами). Запит від клієнта

Мережна файлова система NFS або Network File System, це популярний протокол мережної файлової системи, який дозволяє користувачам підключати віддалені мережеві каталогина своїй машині та передавати файли між серверами. Ви можете використовувати дисковий простір на іншій машині для своїх файлів і працювати з файлами на інших серверах. По суті, це альтернатива загального доступу Windows для Linux, на відміну від Samba, реалізована на рівні ядра і працює стабільніше.

У цій статті буде розглянуто встановлення nfsу Ubuntu 16.04. Ми розберемо встановлення всіх необхідних компонентів, налаштування спільної папки, а також підключення папок мережі.

Як було зазначено, NFS, це мережна файлова система. Для роботи необхідний сервер, на якому буде розміщено Загальна папката клієнти, які можуть монтувати мережеву папкуяк звичайний дискв системі. На відміну від інших протоколів, NFS надає прозорий доступ до віддаленим файлам. Програми будуть бачити файли як у звичайній файловій системі і працювати з ними як з локальними файлами, nfs повертає тільки запитувану частину файлу, замість файлу цілком, тому ця файлова система буде працювати в системах зі швидким інтернетом або в локальній мережі.

Встановлення компонентів NFS

Перед тим, як ми зможемо працювати з NFS, нам доведеться встановити кілька програм. На машину, яка буде сервером, потрібно встановити пакет nfs-kernel-server, за допомогою якого буде виконано відкриття кулі nfs в ubuntu 16.04. Для цього виконайте:

sudo apt install nfs-kernel-server

Тепер давайте перевіримо, чи правильно встановився сервер. NFS слухає з'єднання як для TCP, так і для UDP на порту 2049. Подивитися чи дійсно зараз використовуються ці порти можна командою:

rpcinfo-p | grep nfs

Також важливо перевірити чи підтримується NFS на рівні ядра:

cat /proc/filesystems | grep nfs

Бачимо, що працює, але якщо ні, потрібно вручну завантажити модуль ядра nfs:

Давайте ще додамо nfs в автозавантаження:

sudo systemctl enable nfs

На клієнтському комп'ютері потрібно встановити пакет nfs-common, щоб мати можливість працювати з цією файловою системою. Вам необов'язково встановлювати компоненти сервера, достатньо лише цього пакета:

sudo apt install nfs-common

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

Ми можемо відкрити NFS доступ до будь-якої папки, але давайте створимо для цього нову:

адреса_папки клієнт (опції)

Адреса папки - це та папка, яку потрібно зробити доступною через мережу. Клієнт - ip-адреса або адреса мережі, з якої можуть отримати доступ до цієї папки. А ось із опціями трохи складніше. Розглянемо деякі з них:

  • rw- дозволити читання та запис у цій папці
  • ro- дозволити лише читання
  • sync- відповідати на наступні запити лише тоді, коли дані будуть збережені на диск (за замовчуванням)
  • async- не блокувати підключення поки дані записуються на диск
  • secure- використовувати для з'єднання тільки порти нижче 1024
  • insecure- Використовувати будь-які порти
  • nohide- не приховувати піддиректорії при відкритті доступу до кількох директорій
  • root_squash- підміняти запити від root на анонімні
  • all_squash- перетворювати всі запити на анонімні
  • anonuidі anongid- Вказує uid і gid для анонімного користувача.

Наприклад, для нашої папки цей рядок може виглядати так:

/var/nfs 127.0.0.1(rw, sync, no_subtree_check)

Коли все було налаштовано, залишилося оновити таблицю експорту NFS:

sudo exportfs -a

Ось і все, відкриття кулі nfs в ubuntu 16.04 завершено. Тепер спробуємо настрої клієнта і спробуємо її примонтувати.

Підключення NFS

Ми не будемо докладно зупинятись на цьому питанні у сьогоднішній статті. Це досить велика тема, яка заслуговує на окрему статтю. Але пару слів я все ж таки скажу.

Щоб підключити мережну папку вам не потрібен ніякий nfs клієнт ubuntu, достатньо використовувати команду mount:

sudo mount 127.0.0.1:/var/nfs/ /mnt/

Тепер ви можете спробувати створити файл у підключеній директорії:

Також ми перегляньте підключені файлові системи за допомогою df:

127.0.0.1:/var/nfs 30G 6,7G 22G 24% /mnt

Щоб вимкнути цю файлову систему, достатньо використовувати стандартний umount:

sudo umount /mnt/

Висновки

У цій статті було розглянуто налаштування nfs ubuntu 16.04, як бачите, все робиться дуже просто та прозоро. Підключення NFS кулі виконується в кілька кліків, за допомогою стандартних команд, а відкриття кулі nfs в ubuntu 16.04 не набагато складніше за підключення. Якщо у вас залишилися питання, пишіть у коментарях!

Схожі записи:


Network file system (NFS)- Протокол мережного доступу до файлових систем, дозволяє підключати віддалені файлові системи.
Спочатку розроблений Sun Microsystems у 1984 р. Основою є Sun RPC: виклик віддаленої процедури (Remote Procedure Call). NFS незалежний від типів файлових систем сервера та клієнта. Існує безліч реалізацій NFS-серверів та клієнтів для різних ОС. В даний час використовується версія NFS v.4, що підтримує різні засобиаутентифікації (зокрема, Kerberos та LIPKEY з використанням протоколу RPCSEC GSS) та списків контролю доступу (як POSIX, так і Windows-типів).
NFS надає клієнтам прозорий доступ до файлів та файлової системи сервера. На відміну від FTP, протокол NFSздійснює доступ тільки до тих частин файлу, до яких звернувся процес, і основна перевага його в тому, що робить цей доступ прозорим. Завдяки цьому будь-який додаток клієнта, який може працювати з локальним файлом, з таким же успіхом може працювати і з NFS файломбез змін самої програми.
NFS клієнти отримують доступ до файлів на сервері NFS шляхом відправки RPC-запитів на сервер. Це може бути реалізовано з використанням звичайних користувальницьких процесів - а саме, NFS клієнт може бути користувальницьким процесом, який здійснює конкретні RPC виклики на сервер, який так само може бути процесом користувача.

Версії
NFSv1 була лише для внутрішнього використання в експериментальних цілях. Деталі реалізації визначені RFC 1094.
NFSv2 (RFC 1094, березень 1989 року) спочатку повністю працювала за протоколом UDP.
NFSv3 (RFC 1813, червень 1995). Описувачі файлів у версії 2 – це масив фіксованого розміру- 32 байти. У версії 3 це масив змінного розміру з розміром до 64 байт. Масив змінної довжини в XDR визначається 4-байтним лічильником, за яким йдуть реальні байти. Це зменшує розмір описувача файлу в таких реалізаціях, як, наприклад, UNIX, де потрібно всього близько 12 байт, проте дозволяє не Unix реалізаціям обмінюватися додатковою інформацією.
Версія 2 обмежує кількість байт на процедури READ або WRITE RPC розміром 8192 байт. Це обмеження не діє у версії 3, що, своєю чергою, означає, що з використанням UDP обмеження буде лише у розмірі IP датаграми (65535 байт). Це дозволяє використовувати великі пакети під час читання та запису в швидких мережах.
Розміри файлів і початкове зміщення в байтах для процедур READ і WRITE стали використовувати 64-бітову адресацію замість 32-бітної, що дозволяє працювати з більшим розміром файлів.
Атрибути файлу повертаються до кожного виклику, який може вплинути на атрибути.
Записи (WRITE) можуть бути асинхронними, тоді як у версії 2 вони мали бути синхронними.
Одна процедура була видалена (STATFS) і семеро були додані: ACCESS (перевірка прав доступу до файлу), MKNOD (створення спеціального файлу Unix), READDIRPLUS (повертає імена файлів у директорії разом з їх атрибутами), FSINFO (повертає статистичну інформаціюпро файлову систему), FSSTAT (повертає динамічну інформацію про файлову систему), PATHCONF (повертає POSIX.1 інформацію про файл) та COMMIT (передає раніше зроблені асинхронні записи на постійне зберігання).
На момент введення версії 3 розробники стали більше використовувати TCP як транспортний протокол. Хоча деякі розробники вже використали протокол TCP для NFSv2, Sun Microsystems додали підтримку TCP у NFS версії 3. Це зробило використання NFS через Інтернет більш здійсненним.
NFSv4 (RFC 3010, грудень 2000 р., RFC 3530, переглянута в квітні 2003), під впливом AFS і CIFS, включила поліпшення продуктивності, високу безпеку, і постала повноцінним протоколом. Версія 4 стала першою версією, розробленою спільно з Internet Engineering Task Force (IETF) після того, як Sun Microsystems передала розвиток протоколів NFS. NFS версії v4.1 була схвалена IESG у січні 2010 року, і отримала номер RFC 5661. Важливим нововведенням версії 4.1 є специфікація pNFS - Parallel NFS, механізм паралельного доступу NFS-клієнта до даних безлічі розподілених NFS-серверів. Наявність такого механізму у стандарті мережної файлової системи допоможе будувати розподілені "хмарні" ("cloud") сховища та інформаційні системи.

Структура NFS
Структура NFS включає три компоненти різного рівня:
Прикладний рівень (власне NFS) - це виклики віддалених процедур (rpc), які виконують необхідні операції з файлами і каталогами на стороні сервера.
Функції рівня подання виконує протокол XDR (eXternal Data Representation), що є міжплатформним стандартом абстракції даних. Протокол XDR описує уніфіковану, канонічну форму представлення даних, яка не залежить від архітектури. обчислювальної системи. При передачі пакетів RPC-клієнт переводить локальні дані в канонічну форму, а сервер робить зворотну операцію.
Сервіс RPC (Remote Procedure Call), що забезпечує запит віддалених процедур клієнтом та їх виконання на сервері, представляє функції сеансового рівня. Підключення мережевих ресурсів
Процедура підключення мережного ресурсу засобами NFS називається "експортуванням". Клієнт може запросити у сервера список ресурсів, що ним експортуються. Сам сервер NFS не займається широкомовною розсилкою списку своїх ресурсів, що експортуються.
Залежно від заданих опцій, ресурс, що експортується, може бути змонтований (приєднаний) "тільки для читання", можна визначити список хостів, яким дозволено монтування, вказати використання захищеного RPC (secureRPC) та ін. Одна з опцій визначає спосіб монтування: "жорстке" ( hard) або "м'яке" (soft).
При "жорсткому" монтуванні клієнт намагатиметься змонтувати файлову систему будь-що-будь. Якщо сервер не працює, це призведе до того, що весь сервіс NFS зависне: процеси, що звертаються до файлової системи, перейдуть у стан очікування закінчення виконання запитів RPC. З точки зору процесів користувача файлова система буде виглядати як дуже повільний локальний диск. При поверненні сервера в робочий стансервіс NFS продовжить функціонування.
При "м'якому" монтуванні клієнт NFS зробить кілька спроб підключитися до сервера. Якщо сервер не відгукується, система видає повідомлення про помилку і припиняє спроби зробити монтування. З погляду логіки файлових операційу разі відмови сервера "м'яке" монтування емулює збій локального диска.
Вибір режиму залежить від ситуації. Якщо дані на клієнті та сервері повинні бути синхронізовані при тимчасовій відмові сервісу, то "жорстке" монтування виявляється кращим. Цей режим незамінний також у випадках, коли файлові системи, що монтуються, містять у своєму складі програми та файли, життєво важливі для роботи клієнта, зокрема для бездискових машин. В інших випадках, особливо коли йдеться про системи "тільки для читання", режим "м'якого" монтування видається більш зручним.

Загальний доступ до змішаної мережі
NFS ідеально підходить для мереж на основі UNIX, оскільки поставляється з більшістю версій цієї операційної системи. Більше того, підтримка NFS реалізована лише на рівні ядра UNIX. Використання NFS на клієнтських комп'ютерах з Windows створює певні проблеми, пов'язані з необхідністю встановлення спеціалізованого та досить дорогого клієнтського програмного забезпечення. У таких мережах використання засобів поділу ресурсів на основі протоколу SMB/CIFS, зокрема ПЗ Samba, виглядає кращим.

Стандарти
RFC 1094 NFS: Network File System Protocol Specification] (March 1989)
RFC 1813 NFS Version 3 Protocol Specification] (June 1995)
RFC 2224 NFS URL Scheme
RFC 2339 An Agreement Between Internet Society, IETF, і Sun Microsystems, Inc. in the matter of NFS V.4 Protocols
RFC 2623 NFS Version 2 and Version 3 Security Issues and NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
RFC 2624 NFS Version 4 Design Considerations
RFC 3010 NFS version 4 Protocol
RFC 3530 Network File System (NFS) version 4 Protocol
RFC 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol

Використовувані джерела
1. ru.wikipedia.org
2. ru.science.wikia.com
3. phone16.ru
4. 4stud.info
5. yandex.ru
6. gogle.com

NFS: зручна та перспективна мережева файлова система

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

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

Коротка історія NFS

Перша мережева файлова система називалася FAL (File Access Listener - обробник доступу до файлів) і була розроблена в 1976 компанією DEC (Digital Equipment Corporation). Вона була реалізацією протоколу DAP (Data Access Protocol – протокол доступу до даних) та входила до пакету протоколів DECnet. Як і у випадку TCP/IP, компанія DEC опублікувала специфікації своїх мережевих протоколів, включаючи протокол DAP.

NFS була першою сучасною мережевою файловою системою, побудованою поверх протоколу IP. Її прообразом можна вважати експериментальну файлову систему, розроблену Sun Microsystems на початку 80-х років. Враховуючи популярність цього рішення, протокол NFS був представлений як специфікація RFC і згодом розвинувся в NFSv2. NFS швидко утвердилася як стандарт завдяки здатності взаємодіяти з іншими клієнтами та серверами.

Згодом стандарт було оновлено до версії NFS v3, визначеної в RFC 1813. Ця версія протоколу була масштабованіша, ніж попередні, і підтримувала файли більшого розміру (більше 2 ГБ), асинхронний запис і TCP як транспортний протокол. NFSv3 задала напрямок розвитку файлових систем для глобальних (WAN) мереж. У 2000 році в рамках специфікації RFC 3010 (переробленої у версії RFC 3530) NFS було перенесено в корпоративне середовище. Sun представила більш захищену NFSv4 з підтримкою збереження стану (stateful) ( попередні версії NFS не підтримували збереження стану, тобто. належали до категорії stateless). на поточний моментостанньою версією NFS є версія 4.1, визначена в RFC 5661, в якій протокол за допомогою розширення pNFSбуло додано підтримку паралельного доступу для розподілених серверів.

Історія розвитку NFS, включаючи конкретні RFC, що описують її версії, показано малюнку 1.


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

Архітектура NFS

NFS використовує стандартну архітектурну модель " клієнт-сервер " (як показано малюнку 2). Сервер відповідає за реалізацію файлової системи спільного доступу та сховища, до якого підключаються клієнти. Клієнт реалізує користувальницький інтерфейсдо загальної файлової системи, змонтованої усередині локального файлового простору клієнта.

Малюнок 2. Реалізація моделі "клієнт-сервер" в архітектурі NFS

В ОС Linux® віртуальний комутатор файлової системи (virtual file system switch - VFS) надає засоби для одночасної підтримкина одному хості декількох файлових систем (наприклад, файлової системи ISO 9660 на CD-ROM та файлової системи ext3fs на жорсткому диску). Віртуальний комутаторвизначає, якого накопичувача виконується запит, і, отже, яка файлова система має використовуватися обробки запиту. Тому NFS має таку ж сумісність, як і інші файлові системи, що застосовуються в Linux. Єдина відмінність NFS полягає в тому, що запити введення/виводу замість локальної обробки на хості можуть бути спрямовані для виконання мережі.

VFS визначає, що отриманий запит відноситься до NFS і передає його в обробник NFS, що знаходиться в ядрі. Обробник NFS обробляє запит введення/виводу і транслює його в NFS-процедуру (OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE і т.д.). Ці процедури, описані в окремій специфікації RFC, визначають поведінку NFS. Необхідна процедуравибирається залежно від запиту та виконується за допомогою технології RPC (дзвінок видаленої процедури). Як можна зрозуміти за назвою, RPC дозволяє здійснювати виклики процедур між різними системами. RPC-служба з'єднує NFS-запит з його аргументами та надсилає результат на відповідний віддалений хост, а потім слідкує за отриманням та обробкою відповіді, щоб повернути його ініціатору запиту.

Також RPC включає важливий рівень XDR ( external data representation– незалежне представлення даних), що гарантує, що всі користувачі NFS для однакових типів даних використовують один і той самий формат. Коли певна платформа відправляє запит, тип даних, що використовується нею, може відрізнятися від типу даних, що використовується на хості, що обробляє цей запит. Технологія XDR бере на себе роботу з перетворення типів на стандартне уявлення (XDR), так що платформи, що використовують різні архітектури, можуть взаємодіяти та спільно використовувати файлові системи. У XDR визначено бітовий формат для таких типів, як float, і порядок байтів для таких типів, як масиви постійної та змінної довжини. Хоча XDR здебільшого відома завдяки застосуванню в NFS, ця специфікація може бути корисною у всіх випадках, коли доводиться працювати в одному середовищі з різними архітектурами.

Після того як XDR переведе дані до стандартного подання, запит передається по мережі за допомогою певного транспортного протоколу. У ранніх реалізаціях NFS використовувався протокол UDPАле сьогодні для забезпечення більшої надійності застосовується протокол TCP.

На стороні сервера NFS застосовується подібний алгоритм. Запит піднімається через мережевий стек через рівень RPC/XDR (для перетворення типів даних відповідно до архітектури сервера) і потрапляє в NFS-сервер, який відповідає за обробку запиту. Там запит передається NFS-демону для визначення цільової файлової системи, якій він адресований, а потім знову надходить до VFS для звернення до цієї файлової системи на локальному диску. Повністю схема цього процесу наведена малюнку 3. У цьому локальна файлова система сервера – це стандартна для Linux файловасистема, наприклад, ext4fs. Насправді NFS – це файлова система у традиційному розумінні цього терміна, а протокол віддаленого доступу до файловим системам.


Для мереж з великим часомочікування в NFSv4 пропонується спеціальна складова процедура ( compound procedure). Ця процедура дозволяє помістити кілька RPC-дзвінків всередину одного запиту, щоб мінімізувати витрати на надсилання запитів по мережі. Також у цій процедурі реалізовано механізм callback-функцій для отримання відповідей.

Протокол NFS

Коли клієнт починає працювати з NFS, першою дією виконується операція mount , яка є монтуванням віддаленої файлової системи в простір локальної файлової системи. Цей процес починається з виклику процедури mount (однієї з системних функцій Linux), який через VFS перенаправляється в NFS-компонент. Потім за допомогою RPC-дзвінка функції get_port на віддаленому сервері визначається номер порту, який використовуватиметься для монтування, і клієнт через RPC надсилає запит на монтування. Цей запит на стороні сервера обробляється спеціальним демоном rpc.mountd , який відповідає за протокол монтування ( mount protocol). Демон перевіряє, що запитана клієнтом файлова система є у списку систем, доступних на даному сервері. Якщо запитана система існує і клієнт має доступ до неї, то у відповіді RPC-процедури mount вказується дескриптор файлової системи. Клієнт зберігає в себе інформацію про локальну та віддалену точку монтування та отримує можливість здійснювати запити введення/виводу. Протокол монтування не є бездоганним з точки зору безпеки, тому NFSv4 замість нього використовуються внутрішні RPC-дзвінки, які також можуть керувати точками монтування.

Для зчитування файлу його потрібно спочатку відкрити. У RPC немає процедури OPEN, натомість клієнт просто перевіряє, що вказаний файлта каталог існують у змонтованій файловій системі. Клієнт починає з виконання RPC-запиту GETATTR до каталогу, у відповідь який повертаються атрибути каталогу чи індикатор, що каталог немає. Далі, щоб перевірити наявність файлу, клієнт виконує RPC-запит LOOKUP. Якщо файл існує, для нього виконується RPC-запит GETATTR , щоб дізнатися про атрибути файлу. Використовуючи інформацію, отриману в результаті успішних дзвінків LOOKUP та GETATTR, клієнт створює дескриптор файлу, який надається користувачеві для виконання майбутніх запитів.

Після того, як файл ідентифікований у віддаленій файловій системі, клієнт може виконувати RPC-запити типу READ. Цей запит складається з дескриптора файлу, стану, зміщення та кількості байт, яку слід рахувати. Клієнт використовує стан ( state), щоб визначити, чи може операція бути виконана в даний момент, тобто. чи не заблоковано файл. Зміщення ( offset) Вказує, з якої позиції слід почати читання, а лічильник байт ( count) визначає, скільки байт необхідно рахувати. В результаті RPC-дзвінка READ сервер не завжди повертає стільки байт, скільки було запрошено, але разом з даними завжди передає, скільки байт було відправлено клієнту.

Інновації в NFS

Найбільший інтерес становлять дві останні версії NFS - 4 і 4.1, на прикладі яких можна вивчити найбільше важливі аспектиеволюція технології NFS.

До появи NFSv4 для виконання таких завдань управління файлами, як монтування, блокування і т.д. існували спеціальні додаткові протоколи. У NFSv4 процес керування файлами був спрощений до одного протоколу; крім того, починаючи з цієї версії UDP більше не використовується як транспортний протокол. NFSv4 включає підтримку UNIX та Windows®-семантики доступу до файлів, що дозволяє NFS "природним" способом інтегруватися в інші операційні системи.

У NFSv4.1 для більшої масштабованості та продуктивності було введено концепцію паралельної NFS(Parallel NFS - pNFS). Щоб забезпечити більший рівень масштабованості, в NFSv4.1 реалізована архітектура, в якій дані та метадані ( розмітка) розподіляються по пристроях аналогічно до того, як це робиться в кластерних файлових системах. Як показано на , pNFS поділяє екосистему на три складові: клієнт, сервер та сховище. При цьому з'являються два канали: один передачі даних, а інший передачі команд управління. pNFS відокремлює дані від метаданих, що їх описують, забезпечуючи двоканальну архітектуру. Коли клієнт хоче отримати доступ до файлу, сервер відправляє метадані з "розміткою". У метаданих міститься інформація про розміщення файлу на пристроях, що запам'ятовують. Отримавши цю інформацію, клієнт може звертатися безпосередньо до сховища без необхідності взаємодіяти з сервером, що сприяє підвищенню масштабованості та продуктивності. Коли клієнт закінчує роботу з файлом, він підтверджує зміни, внесені до файлу та його "розмітку". За потреби сервер може запитати клієнта метадані з розміткою.

З появою pNFS до протоколу NFS було додано кілька нових операцій підтримки такого механізму. Метод LayoutGet використовується для отримання метаданих із сервера, метод LayoutReturn "звільняє" метадані, "захоплені" клієнтом, а метод LayoutCommit завантажує "розмітку", отриману від клієнта, у сховище, тому вона стає доступною іншим користувачам. Сервер може відкликати метадані у клієнта за допомогою методу LayoutRecall. Метадані з "розміткою" розподіляються між декількома пристроями, що запам'ятовують, щоб забезпечити паралельний доступ і високу продуктивність.


Дані та метадані зберігаються на пристроях, що запам'ятовують. Клієнти можуть виконувати прямі запити введення/виводу на основі отриманої розмітки, а сервер NFSv4.1 зберігає метадані та керує ними. Сама по собі ця функціональність і не нова, але в pNFS була додана підтримка різних методів доступу до пристроїв, що запам'ятовують. Сьогодні pNFS підтримує використання блокових протоколів ( Fibre Channel), об'єктних протоколів та власне NFS (навіть не в pNFS-формі).

Розвиток NFS продовжується, і у вересні 2010 року були опубліковані вимоги до NFSv4.2. Деякі з нововведень пов'язані з міграцією технологій зберігання даних у бік віртуалізації. Наприклад, в віртуальних середовищахз гіпервізором ймовірно виникнення дублювання даних (кілька ОС виконують читання/запис і кешування тих самих даних). У зв'язку з цим бажано, щоб система зберігання даних загалом розуміла, де відбувається дублювання. Такий підхід допоможе заощадити простір у кеші клієнта та загальну ємність системи зберігання. У NFSv4.2 для вирішення цієї проблеми пропонується використовувати карту блоків, що знаходяться в спільному доступі(block map of shared blocks). сучасні системизберігання все частіше оснащуються власними внутрішніми обчислювальними потужностями, вводиться копіювання на стороні сервера, що дозволяє знизити навантаження при копіюванні даних у внутрішньої мережі, коли це можна ефективно робити на самому пристрої. Інші інновації включають субфайлове кешування для флеш-пам'яті та рекомендації щодо настроювання вводу-виводу на стороні клієнта (наприклад, з використанням mapadvise).

Альтернативи NFS

Хоча NFS - найпопулярніша мережна файлова система в UNIX і Linux, крім неї існують інші мережеві файлові системи. на платформі Windows® найчастіше застосовується SMB, також відома як CIFS; при цьому Windows також підтримує NFS, так само як і Linux підтримує SMB.

Одна з новітніх розподілених файлових систем, що підтримуються в Linux - Ceph - спочатку спроектована як стійка до відмови POSIX-сумісна файлова система. Додаткову інформацію про Ceph можна знайти у розділі .

Варто також згадати файлові системи OpenAFS (Open Source-версія розподіленої файлової системи Andrew, розробленої в університеті Карнегі-Меллона та корпорації IBM), GlusterFS (розподілена файлова система загального призначеннядля організації масштабованих сховищ даних) та Lustre (мережева файлова система з масовим паралелізмом для кластерних рішень). Всі ці системи з відкритим кодом можна використовувати для побудови розподілених сховищ.

Висновок

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