☰

如果服务器重新启动，NFS 客户端不会恢复

tag-icon • tag-icon mount nfs
如果服务器重新启动，NFS 客户端不会恢复

有两台机器：(a) 是 NFS 服务器，(b) 是 NFS 客户端。
当计算机 (a) 重新启动时，是否有办法在不重新启动的情况下恢复计算机 (b) 上的 NFS 客户端？

答案1

我不明白你这个词的意思，recover但如果你的意思remount是，那就是简单的sudo mount -a。

答案2

你可以尝试一个umount -f mountpoint

我在连接到 Windows NFS 服务器的 RHEL 7 计算机上经常看到这种情况。 umount 命令将会失败，但它会释放阻止客户端运行的任何内容。

答案3

至少存在三个可能的问题点：

  • rpc.statd及其端口分配
  • NFS 协议内部使用的主机名
  • fsid服务器端非持久分配的文件系统 ID

rpc.statd

如果 NFS 共享是硬安装的，则任何访问该共享的进程都将在 NFS 服务器重新启动期间挂起，但一旦 NFS 服务器完全启动并再次运行，它们就会自动恢复。如果这没有发生，那就是出了问题。

NFS 版本 4 的所有恢复功能都使用相同的网络端口（通常为 2049/TCP），但较旧的协议版本将网络状态监视器子协议作为单独的服务，通常称为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.statdNFSv2/v3 子协议和其他 NFSv2/v3 子协议使用固定端口号将是提高 NFS 可靠性的重要一步。

确切的过程将取决于操作系统及其版本：最终它通常最终成为该rpc.statd进程的添加选项和端口号，但许多操作系统和 Linux 发行版都包含一些此功能，因此您可能需要取消注释中的设置启动脚本中的配置文件或 shell 变量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 及更高版本中，.txt 文件中有注释掉的示例行/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=4045in /etc/modprobe.d/nfs-options.conf（如果不存在则创建它）。

添加这些设置并重新启动相应的 NFS 服务（或重新启动）后，您可以用来rpcinfo -p确认 NFSv3 子协议现在将获取固定端口号。

（上述端口号也是NetApp NAS 设备的 NFSv3 服务将默认使用，但 NetApp 将放置rpc.mountd到端口 635。）

主机名

该协议rpc.statd使用主机名，而不是 IP 地址：客户端和服务器都必须能够从 IP 地址查找其规范主机名。如果无法做到这一点，则sm-notify无法向 NFS 连接的另一方发送有效的重新启动通知，并且重新启动后的恢复可能会失败。

NFS 协议中存在不对称性：NFS 服务器会自动了解其客户端的主机名（caller_name在 NFS 协议中称为 s）并将其提供给服务器端rpc.statd，但没有等效的交互来通知客户端服务器的主机名。因此，如果mount使用 IP 地址指定命令，并且客户端无法将该 IP 地址反向映射到主机名，那么客户端将不知道 NFS 服务器在向 NFS 服务器发送重新启动通知时将调用自己的名称。客户端rpc.statd。

这表明，mount如果您希望 NFS 装载能够从服务器成功重新启动后自动恢复，那么在命令中使用 IP 地址可能不是一个好主意。您还必须确保客户端mount命令中使用的名称与 NFS 服务器实际使用的名称相匹配。

非持久fsid性

现代 Linux NFS 服务器将自动使用文件系统 UUID（如果可用）作为 NFS fsid。默认情况下，这些fsids 应该是持久的。

但是较旧的 Unix 和其他 NFS 实现可能仍然使用较旧的小整数样式fsid，其中一些甚至可能以非持久方式随机分配它们，除非另有配置。如果是这样，那么在 NFS 服务器重新启动后，客户端stale file handle在尝试访问已挂载的 NFS 共享时将产生错误消息，直到卸载并重新挂载共享为止。解决此问题的方法是确保fsid在 NFS 服务器上持久分配这些 s。

（我曾经在作为故障转移集群 (HP ServiceGuard) 运行的三个 HP-UX 系统充当容错 NFS 服务器时看到过这种情况。如果fsid未在 NFS 导出/共享配置中显式定义这些 s，则客户端将NFS 服务从一个节点故障转移到另一个节点后失败，这违背了故障转移集群的目的。在确定了 s 后fsid，故障转移开始按预期工作。）

相关内容