☰

NFS 客户端在重启后无法获取服务器

tag-icon • tag-icon debian google-cloud-platform nfs google-compute-engine
NFS 客户端在重启后无法获取服务器

编辑 ：

总结一下，这是 NFS 服务器更改 IP 地址而 NFS 客户端未获取新地址的问题。我可以看到tcpdump客户端仍然尝试在端口 2049 上联系旧 IP 地址。

我们在 中定义了几个这样的 NFS 挂载点/etc/fstab。如你所见，这是 NFS v3。

storage-1:/data/medias/media /var/www/myproject/data/media nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0
storage-1:/data/medias/secure /var/www/myproject/web/secure nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0
storage-1:/data/tobeprocessed /var/www/myproject/data/tobeprocessed nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0
storage-1:/data/ftp /var/ftp nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0

重新启动服务器时，我们必须卸载并重新安装每个端点，否则客户端将无法访问 NFS 服务器。我尝试在重新启动后最多 5 分钟后卸载并重新安装。

NFS 服务器重新启动后，ls /var/www/myproject/data/media控制台就会挂起。

我还可以在中看到以下消息/var/log/syslog：

Sep 16 11:24:36 encoder-1 kernel: [69688.160102] nfs: server storage-1 not responding, still trying
Sep 16 11:30:15 encoder-1 kernel: [70027.744042] nfs: server storage-1 not responding, still trying

当我在客户端上umount连接mount其中一个 nfs 目录时，我就可以访问它。但是，除非我也连接umount它们，否则我无法访问其他目录mount。

如果有人知道这个可能的解决方案，我愿意倾听。请注意，这rpcinfo表明客户端能够联系服务器，如下所示。

有一个 NFS 服务器、4 个 NFS 客户端，总共 12 个挂载点。

rpcinfo -p storage-1来自客户端的结果：

[0]root@encoder-1:/var/log # rpcinfo -p storage-1
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  52115  status
    100024    1   tcp  57907  status
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100227    3   tcp   2049
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100227    3   udp   2049
    100021    1   udp  59603  nlockmgr
    100021    3   udp  59603  nlockmgr
    100021    4   udp  59603  nlockmgr
    100021    1   tcp  47716  nlockmgr
    100021    3   tcp  47716  nlockmgr
    100021    4   tcp  47716  nlockmgr
    100005    1   udp    892  mountd
    100005    1   tcp    892  mountd
    100005    2   udp    892  mountd
    100005    2   tcp    892  mountd
    100005    3   udp    892  mountd
    100005    3   tcp    892  mountd

启用 NFS 调试跟踪时正如这里解释的那样，我们收到以下日志消息：

Sep 17 05:35:00 encoder-1 kernel: [135112.160230] nfs: server storage-1 not responding, still trying
Sep 17 05:53:47 encoder-1 kernel: [136240.018538] NFS: nfs_lookup_revalidate(///) is valid
Sep 17 05:53:47 encoder-1 kernel: [136240.018538] NFS: revalidating (0:12/5242881)
Sep 17 05:53:47 encoder-1 kernel: [136240.018538] NFS call  getattr

答案1

我认为这可能是解析主机名的问题。我注意到，即使解析似乎在系统和网络上正常工作，NFS 挂载过程似乎偶尔会出现问题。我会将主机名更改为实际的 IP 地址并尝试一下。假设 FQDN 是 storage-1.example.org，它将解析为 192.0.2.11，然后执行以下操作：

192.0.2.11:/data/medias/media /var/www/myproject/data/media nfs bg,rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0

即使这不能解决问题，我个人认为使用 IP 地址而不是主机名或 FQDN 是更好的选择。但我明白您可能出于某些原因不想这样做。

笔记：我添加了背景选项，如果安装时间较长，该选项将使安装过程在后台运行，以加快启动速度。是否喜欢这个由您决定。我想提一下，因为当有多个 NFS 安装点，并且每个安装点都需要较长时间（或超时）时，启动时间很容易超过一小时。

相关内容