Принципи використання файлової системи NFS для створення спільних мережевих ресурсів на базі Linux-систем

Створення спільних мережевих ресурсів у межах кластера є невід’ємною частиною роботи мережевих адміністраторів. Для конфігурування таких кластерів може бути використано низку програмних засобів, наприклад, таких як NCP (NetWare Core Protocol), SMB (Server Message Block) та деякі інші.

Однак для Linux-подібних систем найбільш поширеним є мережевий протокол NFS (Network File System), орієнтований на роботу з різними типами файлових систем. На відміну, наприклад, від FTP, він забезпечує прозорий доступ до віддалених файлів, коли робота з ними нічим не відрізняється від роботи з локальними файлами.

Розглянемо особливості протоколу та приклади його практичного застосування.

Характеристики протоколу NFS

Протокол розроблений компанією Sun Microsystems на базі відкритого мережевого протоколу виклику віддалених процедур RPC (Open Network Computing Remote Procedure Call).

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

Клієнти отримують доступ до серверних ресурсів шляхом надсилання серверу запитів у форматі RPC.

Наведемо деякі з найважливіших характеристик NFS:

• Незалежність від апаратної конфігурації вузлів;
• Підтримка більшості відомих операційних систем (ОС) – Windows, Mac OS, IBM i та ін.;
• Відновлення після збою клієнта або сервера;
• Прозорий доступ до віддалених ресурсів без перекомпіляції, використання шляхів і бібліотек;
• Продуктивність, співставна з продуктивністю дискових накопичувачів;
• Для клієнта віддалені й локальні файли виглядають однаково;
• Можливість використання для транспорту стеку протоколів TCP/IP;
• Сервер приймає запити від клієнта на фіксований порт 2049;
• Підвищена продуктивність завдяки використанню кількох NFS-серверів або користувацьких nfsd-процесів залежно від конфігурації системи;
• Кожен із вузлів кластера може виконувати функції як сервера, так і клієнта.

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

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

Практичне використання NFS

На практиці найчастіше використовуються два підходи до організації кластера на базі NFS:

• Використання спільного сховища на сервері;
• Використання віддалених домашніх каталогів користувачів замість локальних.

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

Розглянемо шляхи реалізації кожного з підходів у випадку, коли кластер складається з двох вузлів під управлінням Ubuntu 22.04.

Налаштування спільного сховища

У цьому випадку немає потреби в наданні root-доступу до серверних ресурсів із боку клієнтів, а отже, сервер не піддаватиметься небезпеці. Розробники передбачили спосіб реалізації такої архітектури.

За замовчуванням протокол налаштований таким чином, що всі root-команди клієнта автоматично перетворюються на команди облікового запису nobody:nogroup. Адміністратору необхідно лише змінити власника спільного ресурсу на сервері для відповідності параметрам зазначеного облікового запису.

Оновлення системи

Перед установленням серверної частини програми необхідно оновити програмне середовище сервера.
Для цього скористаємося такими командами:

$ sudo apt update
$ sudo apt list --upgradable

Встановлення та активація NFS-сервера

Після успішного виконання оновлення можна переходити до встановлення програми:

$ sudo apt install nfs-kernel-server

Після запуску команди в терміналі почнеться процес розгортання застосунку.
У останньому вікні виводу команди з’явиться повідомлення: «Setting up nfs-kernel-server 1:2.6.1 …», що свідчитиме про успішне завершення процесу встановлення.

Після цього необхідно запустити NFS-сервер:

$ sudo systemctl start nfs-kernel-server.service

Створення спільного ресурсу на сервері

Створимо спільний каталог на сервері з іменем all_users:

$ sudo mkdir /var/nfs/all_users -p

Власником створеного каталогу буде користувач root.
Змінимо власника, щоб NFS блокував адміністративні запити, про що вже згадувалося вище:

$ sudo chown nobody:nogroup /var/nfs/all_users

Тепер спільний ресурс налаштований і практично готовий до експорту. Залишилося лише встановити параметри експорту, що визначають права доступу та деякі інші характеристики.

Для цього скористаємося системним файлом /etc/exports. Відкриємо його за допомогою редактора nano:

$ sudo nano /etc/exports

У відкритий файл вставимо такий рядок:

/var/nfs/all_users 178.21.139.65(rw,sync,no_subtree_check)

Зазначені в дужках опції мають такі значення:

• rw – дозволяє запис і зчитування даних;
• sync – забезпечує фіксацію поточного стану каталогу перед кожною відповіддю клієнту;
• no_subtree_check – вимикає перевірку вкладеного дерева сервером під час перевірки доступності файлу.

Налаштування UFW

Для можливості безперешкодного доступу клієнта до спільного ресурсу через порт сервера 2049 потрібно внести зміни в налаштування брандмауера.

Спочатку активуємо його:

$ sudo ufw enable

У результаті повинно з’явитися повідомлення:
«Firewall is active and enabled …»

Переглянемо чинні на даний момент правила:

$ sudo ufw status

На виході з’явиться щось подібне до наступного:

To                      Action               From
80/tcp                  ALLOW                Anywhere
22/tcp                  ALLOW                Anywhere
80/tcp (v6)             ALLOW                Anywhere (v6)
22/tcp (v6)             ALLOW                Anywhere (v6)

Додамо правило:

$ sudo ufw allow from 178.21.139.65 to any port nfs

Де 178.21.139.65 – IP-адреса нашої клієнтської машини.

У результаті виконання команди з’явиться повідомлення: «Rule added», що свідчитиме про успішне виконання операції.

Після перевірки чинних правил брандмауера до наведених вище записів додасться такий рядок:

To                      Action               From
2049                    ALLOW                178.21.139.65

Це означатиме, що доступ до сервера з боку клієнта тепер відкрито.

Налаштування клієнта

На клієнтській машині також потрібно виконати оновлення програмного середовища, як ми зробили раніше для сервера, після чого встановити клієнтську частину програми за допомогою команди:

$ sudo apt install nfs-common

Після успішного встановлення у виводі з’явиться повідомлення такого виду:
«Setting up nfs-common 1:2.6.1…»

Налаштування віддаленого домашнього каталогу користувача

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

Для конфігурації кластера будемо використовувати наявний на сервері каталог home.

Внесемо потрібні зміни у файл /etc/exports:

$ sudo nano /etc/exports

У відкритий файл вставимо такий рядок:

/home  178.21.139.65(rw,sync,no_root_squash,no_subtree_check)

Тут параметр no_root_squash вимикає налаштування протоколу NFS, встановлені за замовчуванням, що дає змогу клієнту отримати root-доступ до домашнього каталогу. Значення решти параметрів ми розглядали вище.

Монтування серверних ресурсів на клієнтській машині

Незалежно від типу конфігурації кластера використовуються ті самі операції монтування спільних ресурсів. Наведемо послідовність дій із монтування каталогів для обох розглянутих раніше випадків.

Створимо однойменні з серверними ресурсами порожні каталоги на клієнті:

$ sudo mkdir -p /nfs/all_users
$ sudo mkdir -p /nfs/home

Команди монтування матимуть такий вигляд:

$ sudo mount 178.21.139.66:/var/nfs/all_users /nfs/all_users
$ sudo mount 178.21.139.66:/home /nfs/home

Де 178.21.139.66 — IP-адреса сервера.

Перевіримо результат виконання наведених команд:

$ df -h

У результаті виконання команди ми маємо отримати приблизно такі дані:

Можна переконатися, що у нашому випадку спільні ресурси успішно змонтовано на клієнтській машині.

Перевірка доступу

Перевіримо доступність серверних ресурсів. Для цього у спільному каталозі all_users створимо тестовий файл з іменем all_users.new:

$ sudo touch /nfs/all_users/all_users.new

Перевіримо права власника:

$ ls -l /nfs/all_users/all_users.new

Результат має бути приблизно таким:

-rw-r--r-- 1 nobody nogroup 0 Mar 12 11:06 /nfs/all_users/all_users.new

Такий результат свідчить про те, що спільний ресурс налаштований правильно, оскільки його власником є nobody nogroup, а не root-користувач. Це означає, що клієнт не зможе виконувати тут дії, які потребують прав адміністратора.

Аналогічним чином створимо тестовий файл з іменем home.new у віддаленому домашньому каталозі:

$ sudo touch /nfs/home/home.new

Перевіримо права власника:

$ ls -l /nfs/home/home.new

Вихід команди:

-rw-r--r-- 1 root root 0 Mar 12 11:12 /nfs/home/home.new

Можна переконатися, що власником файлу є root-користувач. Це означає, що адміністративні дії клієнта тут дозволені, що повністю відповідає нашим початковим налаштуванням.

Автоматизація операції монтування

Після кожного перезапуску клієнтської машини відбувається скидання змонтованих спільних ресурсів, якщо вони не прописані у файлі /etc/fstab. Якщо ж вони там прописані, монтування виконується автоматично.

Додати потрібні записи у файл можна за допомогою команди:

$ sudo nano /etc/fstab

Вставимо у файл такі рядки:

178.21.139.66:/var/nfs/all_users /nfs/all_users nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
178.21.139.66:/home /nfs/home nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Після збереження внесених змін монтування ресурсів виконуватиметься автоматично.

У разі необхідності відключити автоматичне монтування достатньо закоментувати наведені вище записи або видалити параметр auto.