NFSv4: различия между версиями

Версия от 00:14, 14 апреля 2010

Эта страница была перемещена с freesource.info.
Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки.
Просьба по окончанию убрать этот шаблон со страницы.

Сервер NFSv4 для NFSv[34] клиентов

Общая настройка сервера NFSv4

Задача — экспортировать часть ФС (/ftp/pub) с iso`шками и репозиториями (часть репозиториев — подмонтированные iso).

Применил лобовое решение, описанное в http://www.citi.umich.edu/projects/nfsv4/linux/using-nfsv4.html#exports, адаптировано для моего случая:

mkdir -p /export/pub
mount --rbind /ftp/pub /export/pub

Теперь в /export/pub доступно всё содержимое /ftp/pub, в том числе — и смонтированные туда /ftp/pub/foo* (содержимое соответствующего /ftp/pub/ISO/foo*.iso). Несмотря на это, в /etc/exports придётся упомянуть каждую из неявно (за счёт mount --rbind) подмонтированных в /export/pub/* ФС: иначе клиенты их видеть не будут.

В /etc/exports мне потребовалось примерно следующие (сильно упрощённо):

/export (ro,nohide,fsid=0)
/export/pub (ro,nohide,fsid=1)
/export/pub/foo1 (ro,nohide,fsid=2)
/export/pub/foo2 (ro,nohide,fsid=3)
/export/pub/foo<N> (ro,nohide,fsid=<N>)

При этом числа в параметре fsid должны различаться. При совпадении — видна только одна из ФС с совпадающими fsid. Корень для всех экспортируемых систем должен быть указан с fsid=0.

Поправка от ns@ (http://lists.altlinux.org/pipermail/sysadmins/2006-July/001723.html):

Насколько я помню, fsid надо указывать только у /export. То есть только
там, где значение должно равняться "0".
Эта точка станет корнем для NFSv4.

То есть код ниже, тоже работает:

/export (ro,nohide,fsid=0)
/export/pub (ro,nohide)
/export/pub/foo1 (ro,nohide)
/export/pub/foo2 (ro,nohide)
/export/pub/foo<N> (ro,nohide)

Примечание: При экспортировании чего либо нерасположеного в /export (например /ftp/pub непосредствено) — экспортированное доступно только по NFSv3. (Точнее — уменя наблюдалась такая картина.)

Если не вдаваться в подробности (настройка firewall — ниже), то с сервером всё.

Монтирование клиентом

На клиенте всё монтируется в одной точке, но пути к ресурсу для NFSv4 и NFSv3 различаются:

mount -t nfs4 <сервер>:/ <точка монтирования>
mount -t nfs <сервер>:/export <точка монтирования>

При этом как mount -t nfs4 смонтировать удаётся только содержимое /export: при экспорте какого нибудь /ftp/pub напрямую — он доступен только по mount -t nfs…

Если при выполнении монтирования команда mount зависает - значит вероятно, что у вас включена опция использования gssd. Чтобы не мучатся с его настройками, пропишите в файл /etc/sysconfig/nfs параметр SECURE_NFS=no.

NFSv4 и NFSv3 через firewall

Так как для меня критична одновременная поддержка клиентов обоих версий NFS (v4 и v3), то фиксацию и открытие портов выполнял по рецептам для NFSv3, как для более беспроблемного варианта. (Меня убеждают что NFSv4 требования мягче. Причин не верить у меня нет, но и специально не проверял.) Использовал http://ipesin.linux.kiev.ua/translations/rhm/tipstricks10.htm и http://nfs.sourceforge.net/nfs-howto/ar01s06.html

Фиксировал и открывал на серверном firewall следующие:

nfs — работает по 2049 tcp/udp по умолчанию. Если требуется сдвинуть специально — см. altbug:9769

mountd — параметром MOUNTD_PORT (в /etc/sysconfig/nfs)
nlockmgr — параметрами nlm_tcpport и nlm_udpport модуля lockd (строка вида options lockd nlm_tcpport=N nlm_udpport=M в /etc/modules.conf)
portmapper — стандартные 111 tcp/udp

С firewall на клиентах пока не экспериментировал. Есть подозрение, что там придётся фиксировать и открывать порт для status (см. altbug:9770 .

Частые проблемы

Stale NFS file handle

Бывает, что при перезагрузке NFS-сервера обращение к смонтированным ресурсам на NFS-клиентах выдаёт сообщение “Stale NFS file handle”. Обычно это происходит из-за смены идентификатора файловой системы при перезагрузке. Если для обычных устройств он может быть получен из номера устройства, то при использовании LVM он формируется более случайным образом. В man написано что нужно делать:

fsid=num

This option forces the filesystem identification portion of the file handle and file attributes used on the wire to be num instead of a number derived from the major and minor number of the block device on which the filesystem is mounted. Any 32 bit number can be used, but it must be unique amongst all the exported filesystems.

This can be useful for NFS failover, to ensure that both servers of the failover pair use the same NFS file handles for the shared filesystem thus avoiding stale file handles after failover.

Some Linux filesystems are not mounted on a block device; exporting these via NFS requires the use of the fsid option (although that may still not be enough).

Пример:

/nfs4exports 192.168.18.129/26(ro,sync,insecure,no_root_squash,no_subtree_check,fsid=2)

Ссылки

altbug:9770

@@ Строка 21: / Строка 21: @@
 /export/pub/foo<N> (ro,nohide,fsid=<N>)</pre>
-При этом числа в параметре <tt>fsid</tt> должны различаться. При совпадении — видна только одна из ФС с совпадающими <tt>fsid</tt> (нарвался на такое при повторяющемся <tt>fsid=0</tt>, но детально вопрос не исследовал).
+При этом числа в параметре <tt>fsid</tt> должны различаться. При совпадении — видна только одна из ФС с совпадающими <tt>fsid</tt>. Корень для всех экспортируемых систем должен быть указан с <tt>fsid=0</tt>.
 Поправка от ns@ ([http://lists.altlinux.org/pipermail/sysadmins/2006-July/001723.html http://lists.altlinux.org/pipermail/sysadmins/2006-July/001723.html]):