Створення загальних мережевих ресурсів усередині кластера є невід'ємною частиною роботи мережевих адміністраторів. Для конфігурування таких кластерів може бути використаний ряд програмних засобів, наприклад, таких як 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
На виході команди ми маємо отримати приблизно такі дані:
Filesystem | Size | Used | Avail | Use% | Mounted on |
tmpfs | 192M | 2.4M | 190M | 2% | /run |
/dev/vda2 | 24G | 8.6G | 15G | 38% | / |
tmpfs | 958M | 0 | 958M | 0% | /dev/shm |
178.21.139.66:/var/nfs/all_users | 24G | 18G | 5.8G | 75% | /nfs/all_users |
178.21.139.66:/home | 24G | 18G | 5.8G | 75% | /nfs/home |
Можна переконатись, що в нашому випадку загальні ресурси успішно змонтовані на клієнтській машині.
Перевірка доступу
Перевіримо доступність серверних ресурсів. Для цього у загальному каталозі 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».