Клиент NFS не восстанавливается, если сервер перезагружается.

Есть две машины: (a) это сервер NFS, а (b) это клиент NFS.
Когда машина (a) перезагружается, есть ли способ восстановить клиента NFS на машине (b) без перезагрузки?

Я не понимаю, что вы имеете в виду под словом восстановить, но если вы имеете в виду перемонтировать, то да, это так же просто, как sudo mount -a.

Вы можете попробовать umount -f mountpoint

Я видел это много раз на своих машинах RHEL 7, подключенных к серверу NFS на Windows. Команда umount не удастся, но она освободит все, что мешает клиенту работать.

Есть как минимум три возможных проблемных места:

• rpc.statd и его назначение портов
• имена хостов, используемые внутри протокола NFS
• непостоянно назначенные идентификаторы файловых систем (fsid) на стороне сервера

rpc.statd

Если доля NFS жестко смонтирована, любые процессы, обращающиеся к доле, будут зависать во время перезагрузки сервера NFS, но они должны восстановиться автоматически, как только сервер NFS полностью запустится. Если этого не происходит, что-то не так.

NFS версии 4 имеет все функции восстановления, использующие один и тот же сетевой порт (обычно 2049/TCP), но более старые версии протокола имели подпротокол Network Status Monitor как отдельную службу, обычно известную как rpc.statd. Этот процесс должен работать как на клиентах NFSv2/v3, так и на серверных системах, и как клиент, так и сервер NFS должны иметь возможность подключаться к rpc.statd другой стороны, иначе соединение NFS может не восстановиться нормально после перезагрузки любой системы. (Смотрите man sm-notify если вам нужны дополнительные сведения. Ищите абзац под названием NSM OPERATION IN DETAIL; sm-notify — это компонент, активно отправляющий уведомление о перезагрузке на rpc.statd.)

Исторически rpc.statd находился на динамически назначаемом номере порта, и вы должны были сначала запросить службу portmapper/rpcbind (всегда на порту 111, как UDP, так и TCP) о номере порта, который в настоящее время используется rpc.statd.

Такие динамически назначаемые порты нежелательны в современных сетях с файрволами, так как наилучшая практика — разрешать трафик на минимально необходимом количестве портов. Поэтому, если между сервером NFSv2/v3 и его клиентами есть какие-либо файрволы, использование фиксированных номеров портов для rpc.statd и других подпротоколов NFSv2/v3 будет важным шагом к улучшению надежности NFS.

Точная процедура будет зависеть от ОС и её версии: в конечном итоге это обычно будет являться дополнительной опцией и номером порта для процесса rpc.statd, но многие ОС и дистрибуции Linux включают некоторую функциональность для этого, поэтому вам может потребоваться просто раскомментировать настройку в файле конфигурации или переменную оболочки в сценарии запуска rpc.statd.

В сервере NFSv3 номера портов rpc.mountd и lockd/nlockmgr должны также быть закреплены за фиксированными значениями. В клиентах вам нужно будет заботиться только о rpc.statd (и возможно о lockd, если вы используете файловую блокировку на NFS).

В RHEL 7 и более старых вы можете достичь этого, добавив эти строки в конец /etc/sysconfig/network:

LOCKD_TCPPORT=4045
LOCKD_UDPPORT=4045
STATD_PORT=4046
MOUNTD_PORT=4047
# PCNFSD_PORT=4048
RQUOTAD_PORT=4049

В RHEL 8 и более новых есть закомментированные строки-примеры в /etc/nfs.conf. Раскомментируйте и отредактируйте строки, чтобы получилось это:

[lockd]
port=4045
udp-port=4045

[mountd]
port=4047

[statd]
port=4046

В Debian и родственных дистрибуциях необходимые настройки находятся в других файлах:

• STATDOPTS="-p 4046" в /etc/default/nfs-common
• RPCMOUNTDOPTS="-p 4047" в /etc/default/nfs-kernel-server
• options lockd nlm_udpport=4045 nlm_tcpport=4045 в /etc/modprobe.d/nfs-options.conf (создайте его, если он не существует).

После добавления этих настроек и перезапуска соответствующих служб NFS (или перезагрузки) вы можете использовать rpcinfo -p для подтверждения, что подпротоколы NFSv3 теперь будут получать фиксированные номера портов.

(Упомянутые выше номера портов также используются по умолчанию службой NFSv3 устройства NAS от NetApp, за исключением того, что NetApp поместит rpc.mountd на порт 635.)

Имена хостов

Протокол rpc.statd использует имена хостов, а не IP-адреса: оба, и клиент, и сервер, должны иметь возможность определять своё каноническое имя хоста по IP-адресу. Если это невозможно сделать, то sm-notify не сможет отправить действительное уведомление о перезагрузке другой стороне NFS-соединения, и восстановление после перезагрузки может не произойти.

Существует асимметрия в протоколе NFS: сервер NFS автоматически узнает имена хостов своих клиентов (известные как caller_name в протоколе NFS) и передаст их серверу rpc.statd, но нет аналогичного взаимодействия, которое информировало бы клиента об имени сервера. Поэтому, если команда mount была указана с использованием IP-адреса, и клиент не может снова сопоставить этот IP-адрес с именем хоста, то клиент не будет знать, под каким именем сервер NFS будет называться сам, когда он отправляет уведомление о перезагрузке на клиентский rpc.statd.

Это предполагает, что использование IP-адресов в команде mount может быть плохой идеей, если вы хотите, чтобы NFS-монтирование автоматически восстанавливалось после успешной перезагрузки сервера. Вам также нужно будет убедиться, что имя, используемое в команде клиента mount, совпадает с именем, которое сервер NFS фактически использует для себя.

Непостоянные fsid

Современные серверы Linux NFS автоматически используют UUID файловых систем (если они доступны) в качестве fsid NFS. Эти fsid по умолчанию должны быть постоянными.

Но старые Unix-системы и другие реализации NFS могут все еще использовать старый стиль fsid с небольшими целыми числами, и некоторые из них могут даже назначать их случайным образом в непостоянной манере, если не указано иное. Если это так, то после перезагрузки сервера NFS клиент будет выдавать сообщения об ошибке stale file handle при попытке доступа к смонтированной NFS-части, пока эта часть не будет размонтирована и снова смонтирована. Исправление для этого заключается в обеспечении того, чтобы fsid были назначены постоянно на сервере NFS.

(Я однажды видел это, когда трое систем HP-UX, работающих в кластере отказа (HP ServiceGuard), действовали как отказоустойчивый сервер NFS. Если fsid не были явно определены в конфигурации экспорта/доли NFS, клиенты терпели неудачу после того, как служба NFS переходила с одного узла на другой, что сводило на нет цель кластера отказа. После закрепления fsid переходы начали работать, как ожидалось.)