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

Текущая версия от 17:42, 1 июля 2015

Эта страница была перемещена с 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

Файловые системы

ATA over Ethernet • Btrfs • BtrFS • Ceph • GlusterFS • JeOS на Btrfs • NFS • NFS сервер с Kerberos авторизацией • NFSv4 • NTFS3G • OCFS2 • Tmpfs • Установка Alt Linux на Btrfs • Устранение проблем автомонтирования NTFS • Файловые системы • Категория:BtrFS

@@ Строка 1: / Строка 1: @@
-[[Category:Documentation]]
 {{MovedFromFreesourceInfo|AltLinux/Dokumentacija/NFSv4}}
 == Сервер NFSv4 для NFSv[34] клиентов ==
-__TOC__
 === Общая настройка сервера NFSv4 ===
-Задача -- экспортировать часть ФС (<tt>/ftp/pub</tt>) с iso`шками и репозитариями (часть репозитариев -- подмонтированные iso).
+Задача — экспортировать часть ФС (<tt>/ftp/pub</tt>) с iso`шками и репозиториями (часть репозиториев — подмонтированные iso).
-Применил лобовое решение, описанное в [http://www.citi.umich.edu/projects/nfsv4/linux/using-nfsv4.html#exports http://www.citi.umich.edu/projects/nfsv4/linux/using-nfsv4.html#exports], адаптираванно для моего случая:
+Применил лобовое решение, описанное в [http://www.citi.umich.edu/projects/nfsv4/linux/using-nfsv4.html#exports http://www.citi.umich.edu/projects/nfsv4/linux/using-nfsv4.html#exports], адаптировано для моего случая:
 <pre>mkdir -p /export/pub
 mount --rbind /ftp/pub /export/pub</pre>
-Теперь в <tt>/export/pub</tt> доступно всё содержимое <tt>/ftp/pub</tt>, в том числе -- и смонтированные туда <tt>/ftp/pub/foo*</tt> (содержимое соответствующего <tt>/ftp/pub/ISO/foo*.iso</tt>). Несмотря на это, в <tt>/etc/exports</tt> придётся упомянуть <u>каждую</u> из неявно (за счёт <tt>mount --rbind</tt>) подмонтированных в <tt>/export/pub/*</tt> ФС: иначе клиенты их видеть не будут.
+Теперь в <tt>/export/pub</tt> доступно всё содержимое <tt>/ftp/pub</tt>, в том числе — и смонтированные туда <tt>/ftp/pub/foo*</tt> (содержимое соответствующего <tt>/ftp/pub/ISO/foo*.iso</tt>). Несмотря на это, в <tt>/etc/exports</tt> придётся упомянуть <u>каждую</u> из неявно (за счёт <tt>mount --rbind</tt>) подмонтированных в <tt>/export/pub/*</tt> ФС: иначе клиенты их видеть не будут.
 В <tt>/etc/exports</tt> мне потребовалось примерно следующие (сильно упрощённо):
@@ Строка 24: / Строка 20: @@
 /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]):
@@ Строка 31: / Строка 27: @@
 Эта точка станет корнем для NFSv4.</pre>
-Т. е.  код ниже, тоже работает:
+То есть код ниже, тоже работает:
 <pre>/export (ro,nohide,fsid=0)
 /export/pub (ro,nohide)
@@ Строка 38: / Строка 34: @@
 /export/pub/foo<N> (ro,nohide)</pre>
-<div style="display: inline; color: red;">Примечание: При экспортировании чего либо нерасположеного в <tt>/export</tt> (например <tt>/ftp/pub</tt> непосредствено) -- экспортированное доступно только по NFSv3. (Точнее -- уменя наблюдалась такая картина.)</div>
+<div style="display: inline; color: red;">Примечание: При экспортировании чего либо нерасположеного в <tt>/export</tt> (например <tt>/ftp/pub</tt> непосредствено) — экспортированное доступно только по NFSv3. (Точнее — уменя наблюдалась такая картина.)</div>
-Если невдаваться в подробности (настройка firewall -- ниже), то с сервером всё.
+Если не вдаваться в подробности (настройка firewall — ниже), то с сервером всё.
 === Монтирование клиентом ===
-На клиенте всё монтируется в одной точке, но пути к ресурсу для NFSv4 и NFSv3 разлечаются:
+На клиенте всё монтируется в одной точке, но пути к ресурсу для NFSv4 и NFSv3 различаются:
 <pre>mount -t nfs4 <сервер>:/ <точка монтирования>
 mount -t nfs <сервер>:/export <точка монтирования></pre>
-<div style="display: inline; color: red;">При этом как <tt>mount -t nfs4</tt> смонтировать удаётся только содержимое <tt>/export</tt>: при экспорте какого нибудь <tt>/ftp/pub</tt> напрямую -- он доступен только по <tt>mount -t nfs</tt>...</div>
+<div style="display: inline; color: red;">При этом как <tt>mount -t nfs4</tt> смонтировать удаётся только содержимое <tt>/export</tt>: при экспорте какого нибудь <tt>/ftp/pub</tt> напрямую — он доступен только по <tt>mount -t nfs</tt>…</div>
+Если при выполнении монтирования команда 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://ipesin.linux.kiev.ua/translations/rhm/tipstricks10.htm] и [http://nfs.sourceforge.net/nfs-howto/ar01s06.html http://nfs.sourceforge.net/nfs-howto/ar01s06.html]
+Так как для меня критична одновременная поддержка клиентов обоих версий NFS (v4 и v3), то фиксацию и открытие портов выполнял по рецептам для NFSv3, как для более беспроблемного варианта. (Меня убеждают что NFSv4 требования мягче. Причин не верить у меня нет, но и специально не проверял.) Использовал [http://ipesin.linux.kiev.ua/translations/rhm/tipstricks10.htm http://ipesin.linux.kiev.ua/translations/rhm/tipstricks10.htm] и [http://nfs.sourceforge.net/nfs-howto/ar01s06.html http://nfs.sourceforge.net/nfs-howto/ar01s06.html]
 Фиксировал и открывал на серверном firewall следующие:
-* <tt>nfs</tt> -- работает по 2049 tcp/udp по умолчанию. Если требуется сдвинуть специально -- см. [[altbug:9769]]
+* <tt>nfs</tt> — работает по 2049 tcp/udp по умолчанию. Если требуется сдвинуть специально — см. [[altbug:9769]]
-* <tt>mountd</tt> -- параметром <tt>MOUNTD_PORT</tt> (в <tt>/etc/sysconfig/nfs</tt>)
+* <tt>mountd</tt> — параметром <tt>MOUNTD_PORT</tt> (в <tt>/etc/sysconfig/nfs</tt>)
-* <tt>nlockmgr</tt> -- параметрами <tt>nlm_tcpport</tt> и <tt>nlm_udpport</tt> модуля <tt>lockd</tt> (строка вида <tt>options lockd nlm_tcpport=N nlm_udpport=M</tt> в <tt>/etc/modules.conf</tt>)
+* <tt>nlockmgr</tt> — параметрами <tt>nlm_tcpport</tt> и <tt>nlm_udpport</tt> модуля <tt>lockd</tt> (строка вида <tt>options lockd nlm_tcpport=N nlm_udpport=M</tt> в <tt>/etc/modules.conf</tt>)
-* <tt>portmapper</tt> -- стандартные 111 tcp/udp
+* <tt>portmapper</tt> — стандартные 111 tcp/udp
 С firewall на клиентах пока не экспериментировал. Есть подозрение, что там придётся фиксировать и открывать порт для status (см.
@@ Строка 65: / Строка 63: @@
 .
+=== Частые проблемы ===
+==== 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)
@@ Строка 79: / Строка 94: @@
 * [http://lists.altlinux.org/pipermail/sysadmins/2006-July/001717.html http://lists.altlinux.org/pipermail/sysadmins/2006-July/001717.html]
 * [http://lists.altlinux.org/pipermail/sysadmins/2006-July/001723.html http://lists.altlinux.org/pipermail/sysadmins/2006-July/001723.html]
+[[Category:FileSystems]]
+{{Category navigation|title=Файловые системы|category=FileSystems|sortkey={{SUBPAGENAME}}}}