Почему стандартная настройка 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 рабочих дня. Точную стоимость рассчитаем после аудита. Ждём вашу заявку!
