NFSv4: различия между версиями
Sb (обсуждение | вклад) м (Правки 192.151.152.58 (обсуждение) откачены к версии VitalyLipatov) |
Нет описания правки |
||
Строка 1: | Строка 1: | ||
{{MovedFromFreesourceInfo|AltLinux/Dokumentacija/NFSv4}} | {{MovedFromFreesourceInfo|AltLinux/Dokumentacija/NFSv4}} | ||
Строка 95: | Строка 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/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] | * [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}}}} |
Текущая версия от 20:42, 1 июля 2015
Сервер 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)
Если не вдаваться в подробности (настройка firewall — ниже), то с сервером всё.
Монтирование клиентом
На клиенте всё монтируется в одной точке, но пути к ресурсу для NFSv4 и NFSv3 различаются:
mount -t nfs4 <сервер>:/ <точка монтирования> mount -t nfs <сервер>:/export <точка монтирования>
Если при выполнении монтирования команда 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)