Чому стандартне налаштування NFS — це головний біль?
Stale file handle, неспівпадіння uid/gid та падіння продуктивності через дефолтні параметри — ось що чекає при невірному налаштуванні NFS-сервера. Застосунки падають після перезавантаження, права доступу не відповідають очікуваним, sequential read працює в 10 разів повільніше за можливе. Ми — команда DevOps-інженерів з десятирічним досвідом — вирішуємо ці проблеми під ключ за 1–2 робочі дні.
Приклад з практики: як ми усунули простій на 20 серверах
Нещодавно клієнт звернувся з проблемою: після планового перезавантаження NFS-сервера всі 20 застосунків впали через stale file handle. Аудит показав використання NFSv3 з параметром soft. Ми перевели інфраструктуру на NFSv4, налаштували idmapd і параметри монтування hard,nointr. Відтоді простоїв не було. Пропонуємо вам той самий підхід.
Порівняння версій: NFSv3 проти NFSv4
Правильний вибір версії — основа стабільної роботи. NFSv3 — stateless, працює поверх UDP, не рекомендований для продакшену. NFSv4 — stateful, тільки TCP, підтримує ACL та Kerberos. Порівняння:
| Параметр | NFSv3 | NFSv4 |
|---|---|---|
| Протокол транспортного рівня | UDP/TCP | Тільки TCP |
| Стан | Stateless | Stateful |
| Ідентифікація користувачів | uid/gid | uid/gid + idmapd |
| Безпека | AUTH_SYS | Kerberos, ACL |
| Порти | 111, 2049 та ін. | 2049 |
Для всіх нових проєктів налаштовуємо NFSv4. Виняток — інтеграція з legacy-системами, де потрібен NFSv3.
Чому NFSv4 кращий для продакшену?
NFSv4 вирішує проблему stale file handle завдяки stateful-архітектурі. Протокол використовує тільки TCP, що виключає втрату пакетів. Підтримка Kerberos і ACL дозволяє гнучко керувати доступом. idmapd забезпечує коректне відображення uid/gid навіть при неспівпадінні ідентифікаторів на сервері та клієнті.
Як правильно налаштувати сервер та клієнт?
Встановлення на Ubuntu/Debian:
apt install nfs-kernel-server Конфігурація /etc/exports з поясненнями ключових параметрів:
/srv/nfs/shared 192.168.10.0/24(rw,sync,no_subtree_check,no_root_squash)
/srv/nfs/backups 192.168.10.100(ro,sync,no_subtree_check,all_squash,anonuid=65534,anongid=65534)
/srv/nfs/k8s-data 192.168.10.0/24(rw,sync,no_subtree_check,fsid=100,crossmnt)Застосовуємо та перевіряємо:
exportfs -ra exportfs -v Докладніше про параметри — у документації ядра.
Налаштування продуктивності: 4 кроки
Крок 1 — кількість потоків сервера. У /etc/nfs.conf:
[nfsd] threads=16 vers3=n vers4=y vers4.1=y vers4.2=y 16 потоків для сервера з 8+ ядрами — оптимальне значення. Стандартні 8 потоків можуть стати вузьким місцем при 20+ клієнтах.
Крок 2 — параметри монтування на клієнті. Приклад /etc/fstab:
192.168.10.5:/srv/nfs/shared /mnt/shared nfs4 rw,hard,nointr,rsize=1048576,wsize=1048576,timeo=600,retrans=3,_netdev 0 0 Параметр rsize=1048576 (1 MB) збільшує пропускну здатність на 40% порівняно з дефолтними 128 KB. hard,nointr гарантує, що застосунок не отримає пошкоджених даних при тимчасових мережевих проблемах.
Рекомендовані параметри монтування для різних сценаріїв
| Сценарій | Параметри | Коментар |
|---|---|---|
| База даних | rsize=1048576,wsize=1048576,hard,intr,timeo=600,retrans=3 | Максимальна пропускна здатність, надійність |
| Web-сервер | rsize=65536,wsize=65536,hard,intr,timeo=300 | Середнє навантаження, швидка реакція на збої |
| Бекапи | rsize=1048576,wsize=1048576,soft,timeo=1500,retrans=2 | Допустимі короткі помилки, важлива швидкість |
Крок 3 — тестування. Використовуємо nfsstat для сервера та клієнта.
Крок 4 — моніторинг через Prometheus. Метрики node_nfsd_server_rpcs_total і node_nfsd_disk_bytes_* допоможуть відстежити вузькі місця.
Вирішення проблем з правами (uid/gid)
Перша причина збоїв — неспівпадіння uid/gid. NFS не передає імена користувачів, тільки числові ідентифікатори. Рішення за пріоритетом:
- LDAP/FreeIPA — централізоване управління. Підходить для інфраструктури від 5 серверів.
- Ручна синхронізація
/etc/passwd— для маленьких кластерів. - NFSv4 з idmapd — мапінг через імена. Конфігурація
/etc/idmapd.conf:
[General] Domain = company.local [Mapping] Nobody-User = nobody Nobody-Group = nogroup Як уникнути помилок з правами?
Завжди синхронізуйте uid/gid або через LDAP, або через idmapd. Ігнорування цього правила призводить до того, що файли, створені користувачем на сервері, стають недоступні на клієнті. Наш досвід показує, що LDAP — найнадійніший варіант для інфраструктур від 5 серверів.
Що входить у нашу послугу з налаштування NFS?
Ми пропонуємо комплексне рішення:
- Аудит поточної інфраструктури (мережа, сховища, навантаження)
- Вибір версії протоколу та конфігурація сервера
- Налаштування клієнтів з оптимізацією продуктивності
- Інтеграція з LDAP або синхронізація користувачів
- Налаштування моніторингу (Prometheus + Grafana)
- Документування конфігурації та інструкції для адміністраторів
- Гарантія стабільної роботи — ми надаємо підтримку на 30 днів після здачі.
Зв'яжіться з нами для аудиту вашої NFS-інфраструктури. Замовте налаштування — отримайте консультацію.
Терміни та вартість
Базове налаштування (2-3 клієнти) — 4-8 годин. Повноцінне налаштування з LDAP, відмовостійкістю та моніторингом — 1-2 робочих дні. Точну вартість розрахуємо після аудиту. Чекаємо на вашу заявку!
