NFS ( Публикация и монтирование удалённых NFS-ресурсов. )

OS: "Linux Debian 5/6/7 (Lenny/Squeeze/Wheezy)".

NFS подсистема древняя (в смысле богатая историей). Исторически сложилась ситуация, когда она считается базовым функционалом UNIX (а по наследству и Linux, и BSD). Несмотря на то, что NFS, по сути, является отдельной подсистемой вроде HTTP-сервера или иного сервера приложений, конфигурируемого отдельно от несущей операционной системы, ситуация с настройкой NFS несколько иная - для версий "2" и "3" запустить "просто NFS", без корректировки параметров смежных уровней абстракции нереально. С версией NFSv4 ситуация сильно улучшилась (теперь NFS практически автономный сервис), но разработчики излишне, на мой взгляд, озабочены поддержкой обратной совместимости и обеспечением работы подсистемы в условиях эксплуатации оной "дураком", запуская сразу все её составляющие, даже никому не нужные уже лет десять; очень неприятно, знаете ли, знать, что кроме нужного сервиса принимающего подключения по протоколу NFSv4, на сервере запущено ещё с десяток сервисов, обеспечивающих работу с протоколами NFSv1, NFSv2 и NFSv3. Мало того, что ненужные сервисы элементарно занимают неиспользуемыми ими ресурсы, так их наличие ещё и вносит путаницу в процесс первичной настройки и локализации неисправностей в последствии; мало где я читал столько чепухи, сколько в ветках обсуждения процедур настройки NFS разного рода интернет форумов - местами просто феерия непонимания связи параметров конфигурирования с целями такового.

Заинтересовавшимся рекомендую сразу начать читать здесь: http://wiki.linux-nfs.org/

Я буду использовать в работе только NFSv4 и только на транспорте TCP (главное преимущество TCP - более эффективный механизм повторной передачи, что компенсирует возможные сбои в работе, позволяя продолжать её даже на приходящем в неисправность оборудовании). Отключить поддержку NFSv2 и NFSv3 в Debian Linux Lenny/Squeeze/Wheezy исправлением значений пары-тройки переменных нельзя (так, что бы изменения сохранились бы при обновлении конфигурируемых пакетов) и здесь я даже не буду этого делать, оставив конфигурацию сервисов "по умолчанию"; далее мы будем управлять таковой "на лету", путём воздействия на неё из "командной строки". Для энтузиастов позже напишу отдельную заметку о запуске NFS с поддержкой только одной, нужной нам, версии "4".


Устанавливаем необходимые пакеты:


APT-пакет "nfs-server" - виртуальный и объединяет собой как минимум "nfs-common", "nfs-kernel-server" и "portmap". Любителям точности можно устанавливать непосредственно целевые пакеты.

Надо заметить, что сборщик пакетов NFS в Debian совсем не заинтересован в детальной проработке их конфигурации; что-то можно настроить, а что-то нельзя, несмотря на то, что препятствий к этому с точки зрения воздействия на целевое программное обеспечение нет никаких. Отключить всё не получится, но на некоторые составляющие мы можем повоздействовать через предусмотренные конфигурационный файлы. Корректируем два файла, применяя значения указанным переменным:





В итоге мы чуть уменьшили количество задействуемых компонентов, в целом оставив конфигурацию "по умолчанию".

Перезапустим сервисы NFS с обновлёнными настройками:


Возможно попытка запуска ненастроенного NFS-сервера не будет успешной и сопровождаться следующим сообщением об ошибке:


В "Linux Debian Lenny/Squeeze" можно было запустить NFS-сервер с пустым перечнем экспортируемых ресурсов - вхолостую, так сказать. Это удобно, когда сразу после старта системы в объявлении ресурсов нет необходимости или возможности. В "Debian Wheezy" эту возможность прикрыли, прерывая запуск NFS-сервера в случае пустых файлов "/etc/exports" и "/etc/exports.d/*exports". Глупо, надо заметить, и придётся с этим побороться.

Переделывать стартовый скрип не вижу смысла - мало ли что ещё поменяется в следующих реализациях, о чём я своевременно не узнаю? Потому просто подставим на публикацию в файле "/etc/exports" корень NFS, доступ к которому разрешим только на чтение:





Сразу можно будет посмотреть, опубликовался ли наш ресурс:



Нашему серверу достаточно иметь запущенными всего пару сервисов, удостоверимся в их наличии:



Опять же, в плане сетевых подключений для поддержания NFSv4 поверх TCP нам требуется прослушивание лишь одного порта "TCP:2049":



Как я уже упоминал выше, мы будем использовать только NFSv4 поверх TCP. По умолчанию запускается масса сервисов, обеспечивающих поддержку всей линейки протоколов NFS как на транспорте TCP, так и на UDP. Можете полюбоваться на них, запросив с помощью утилиты "rpcinfo" перечень зарегистрированных на сервере RPC-процессов:


На этом предварительную настройку подсистемы NFS будем считать завершённой.

Следующим, по сути первым, этапом будет оформление публикуемых (экспортируемых) ресурсов в должном виде.

Реализация NFSv4 не поддерживает публикацию произвольных веток файловых систем; теперь требуется предварительно создать некую отправную точку, которая объявляется условным корнем файловой системы, содержимое которой уже доступно для публикации (экспортирования). Получается своего рода "chroot"; надо полагать, это сделано в целях повышения уровня безопасности "от дурака", что бы случайно не раскрыть всем окружающим важные ресурсы.

Заведём себе такую точку сбора:


Непосредственно в директории выделенной для публикации можно разместить соответствующие ресурсы, а можно смонтировать их сюда с помощью функционала "--bind" (создавая синоним ресурса, а не ссылку на таковой, как некоторые неверно считают; преимуществом этого способа над символьными ссылками является возможность обходить ограничения доступа к файловой системе, возникающие перед процессами, запущенными в среде "chroot"):


Удостоверимся, что ресурс успешно смонтирован:



Следующим шагом станет определение локальных прав собственности публикуемых (экспортируемых) ресурсов и правил доступа к таковым удалёнными клиентами.

Специфика NFS в том, что (до последнего времени, когда стала возможной аутентификация подключающихся пользователей с помощью Kerberos) сервер доверяет клиенту и принимает "на веру" заявленные им при доступе к ресурсам UID и GID, на основании которых определяется, имеет клиент право доступа к ресурсам или нет. Предполагается, что в пределах схемы существует общее пространство имен пользователей, то есть пользователь "storage" на любом клиентском (с точки зрения сервера NFS) компьютере имеет то же имя и тот же идентификатор, что и пользователь "storage" на сервере NFS; по умолчанию, если GID и UID клиента не обнаруживаются на сервере, их значения транслируются в значения пользователя "nobody:nogroup" сервера. В NFSv4 трансляцией имён и идентификаторов занимается сервис "idmapd".

Соответственно, самое простое, что мы можем сделать для обеспечения возможности операций чтения и записи с ресурсам, так это сделать их собственником пользователя "nobody:nogroup", разрешив ему всё необходимое. Однако, я считаю, что лучше завести специального пользователя как на сервере так и на клиенте, задав им при создании идентичные UID и GID, хотя бы и для того, что бы в последствии наладить полноценное удостоверение подлинности клиента при обращении к серверу, попутно избежав выдачи слишком высокого уровня доступа к ресурсам пользователю "nobody:nogroup", который по идее (в рамках которой он создавался) вообще не должен иметь возможности изменять что либо.

Добавляем пользователя, собственника ресурсов хранилища публикуемых с помощью NFS:


Естественно, что цифровые значения UID и GID необходимо подобрать несовпадающие с уже имеющимися во всех задействованных в схеме системах.

Обращаю внимание на то, что я лишил пользователя "storage" возможности работать в так называемой "оболочке", иначе говоря, от имени пользователя можно запустить приложение или обратится к ресурсам, но нельзя будет работать в "командной строке".

Делаем пользователя и группу "storage:storage" собственниками содержимого хранилища:


Пока не заведена система удостоверения подлинности подключающихся клиентов проще всего указать ключами "all_squash, anonuid=1500, anongid=1500" серверу NFS считать всех анонимными пользователями и преобразовывать их UID и GID в значения локального пользователя "storage:storage", собственника ресурсов хранилища. Тогда мы сможем обратится к ресурсам от имени любого пользователя; в данном упрощённом варианте пользователи с идентичными именами, UID и GID на всех серверах и клиентах схемы нужны более для того, что бы корректно отображать параметры доступа на удалённых узлах, явно показывая в выводе утилит вроде "ls" собственника ресурсов и права доступа к таковым.


Отменить экспортирование:


Где:


Проверяем, успешно ли опубликованы ресурсы:



На стороне сборки опубликованных NFS-ресурсов потребуется провести несколько иные работы.

Установим утилиты подключения к NFS-ресурсам и монтирования их в локальную файловую систему:


Чуть подправим конфигурацию NFS-клиента:




Добавляем пользователя, собственника ресурсов хранилища, публикуемых с помощью NFS:


Создаём директорию, в которую будем монтировать NFS-ресурсы:


Запрашиваем перечень доступных для монтирования удалённых NFS-ресурсов:



Ранее, в настройках NFSv4-сервера мы обозначили директорию "/mnt/export" корневой для клиентов с помощью опции "fsid=0". Теперь при монтировании с NFSv4-клиента следует указывать целевые ресурсы отталкиваясь не от корневой директории NFS-сервера, а от своеобразного "chroot" по адресу "/mnt/export". То есть, если требуется смонтировать ресурс "/mnt/export/resource", нужно монтировать "/resource":


Иногда удобнее позволить NFS-клиенту уведомлять приложение использующее его ресурсы о проблемах со смонтированной файловой системой. Для этого монтируем файловую систему с опцией "soft", указываю количество попыток перемонтирования до вывода сообщения об ошибке опцией "retrans=5" (пять раз) и указываем таймаут для запроса опцией "timeo=600" (минута, в десятых долях секунды):




Важный аспект оптимизации производительности - заранее определяемый размер передаваемого пакета данных. Если пакет меньше оптимально - их будет передаваться избыточно много (затраты ресурсов на формирование пакетов), а если больше оптимально - на каком-то из уровней будут затрачиваться ресурсы на из дробление, инкапсуляцию и последующую сборку. Полагаю отталкиваться при выборе оптимального размера пакетов следует исходя из неизменяемых значений - например размера блока файловой системы хранения (как правило он уже установлен исходя из параметров аппаратуры). Узнать его можно следующим образом:


В современных блочных устройствах это будет "4096" байт, скорее всего. Тогда подгоним размер пакета под это значение, установив соответствующие опции "rsize=4096,wsize=4096".

Переход к настройкам автоматизации публикации NFS-ресурсов.