监控 NFS 挂载是否存在

监控 NFS 挂载是否存在

我们发现的问题是,我们的一些 NFS 挂载目录正在消失。真的消失了。它们在服务器端仍然存在。

在客户端(CentOS 7.4,使用el-repo 的 kernel-ml在版本 4.16.6,nfs-utils-1:1.3.0-0.48.el7) 结束时驱动器无响应。调用ls /mountpoint只是挂起。操作系统仍然认为驱动器已安装 - 重新启动服务器需要硬重置,因为关机过程会在卸载驱动器时挂起。

在日志中我们看到的信息非常少 — 在服务器端我们什么也看不到。有时(但不是每次)我们会在客户端的 /var/log/messages 中看到类似这样的信息:

May 29 16:55:22 papr-res-compute06 kernel: INFO: task STAR:1370 blocked for more than 120 seconds. May 29 16:55:22 papr-res-compute06 kernel: Not tainted 4.16.6-1.el7.elrepo.x86_64 #1 May 29 16:55:22 papr-res-compute06 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 29 16:55:22 papr-res-compute06 kernel: STAR D 0 1370 1351 0x00000080 May 29 16:55:22 papr-res-compute06 kernel: Call Trace: May 29 16:55:22 papr-res-compute06 kernel: __schedule+0x290/0x890 May 29 16:55:22 papr-res-compute06 kernel: ? out_of_line_wait_on_atomic_t+0x110/0x110 May 29 16:55:22 papr-res-compute06 kernel: schedule+0x36/0x80 May 29 16:55:22 papr-res-compute06 kernel: io_schedule+0x16/0x40 May 29 16:55:22 papr-res-compute06 kernel: bit_wait_io+0x11/0x50 May 29 16:55:22 papr-res-compute06 kernel: __wait_on_bit+0x66/0x90 May 29 16:55:22 papr-res-compute06 kernel: out_of_line_wait_on_bit+0x91/0xb0 May 29 16:55:22 papr-res-compute06 kernel: ? bit_waitqueue+0x40/0x40 May 29 16:55:22 papr-res-compute06 kernel: nfs_wait_on_request+0x4b/0x60 [nfs] May 29 16:55:22 papr-res-compute06 kernel: nfs_lock_and_join_requests+0x12a/0x540 [nfs] May 29 16:55:22 papr-res-compute06 kernel: ? radix_tree_lookup_slot+0x22/0x50 May 29 16:55:22 papr-res-compute06 kernel: nfs_updatepage+0x120/0x9f0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: ? nfs_flush_incompatible+0xc5/0x1c0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: nfs_write_end+0xe2/0x3c0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: generic_perform_write+0x10b/0x1c0 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: nfs_file_write+0xd4/0x250 [nfs] May 29 16:55:22 papr-res-compute06 kernel: do_iter_readv_writev+0x109/0x170 May 29 16:55:22 papr-res-compute06 kernel: do_iter_write+0x7f/0x190 May 29 16:55:22 papr-res-compute06 kernel: vfs_writev+0x84/0xf0 May 29 16:55:22 papr-res-compute06 kernel: ? handle_mm_fault+0x102/0x220 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: do_writev+0x61/0xf0 May 29 16:55:22 papr-res-compute06 kernel: SyS_writev+0x10/0x20 May 29 16:55:22 papr-res-compute06 kernel: do_syscall_64+0x79/0x1b0 May 29 16:55:22 papr-res-compute06 kernel: entry_SYSCALL_64_after_hwframe+0x3d/0xa2 May 29 16:55:22 papr-res-compute06 kernel: RIP: 0033:0x7f0cc1563230 May 29 16:55:22 papr-res-compute06 kernel: RSP: 002b:00007fff6f75f2c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000014 May 29 16:55:22 papr-res-compute06 kernel: RAX: ffffffffffffffda RBX: 0000000000002025 RCX: 00007f0cc1563230 May 29 16:55:22 papr-res-compute06 kernel: RDX: 0000000000000002 RSI: 00007fff6f75f300 RDI: 000000000000000a May 29 16:55:22 papr-res-compute06 kernel: RBP: 000000001a7b0860 R08: 0000000000000000 R09: 00007f0cc15b8a00 May 29 16:55:22 papr-res-compute06 kernel: R10: cccccccccccccccd R11: 0000000000000293 R12: 000000000000000a May 29 16:55:22 papr-res-compute06 kernel: R13: 00007fff6f75f300 R14: 0000000000000028 R15: 0000000000001ffd

我们无法可靠地重现此错误。驱动器丢失的情况之间几乎没有共同点 - 这是在拥有大约 40 台服务器和 100 个用户的 HPC 上发生的。通常只影响一台服务器,但会发生在硬件上(Cisco UCSB-B200-M4 w 368GB 和 UCSME-142-M4 w 32GB)。唯一常见的是,有问题的驱动器保存着生物数据,这些数据可能非常大(有时超过半 TB)。

因此,我们希望监控 NFS 驱动器是否启动,因为 SLURM 不断将作业分配给存在此问题的服务器,而这些作业永远不会完成。

我的同事编写了几个 shell 脚本,用于执行ping各种ls操作,并在必要时写入文件和电子邮件。这很聪明,编写起来很有趣(awk!,cut!),但在我看来,这绝对是错误的做法。

快速谷歌搜索显示这nfsiostat可能很有用,但是几乎没有好的说明,现有的内容似乎没有映射到我们的操作系统(特别是“count”是必要的,尽管手册页是这么说的)最重要的是,我们不需要使用情况统计信息。我们需要存在信息。字面意思是“你在 nfsdrive 那里吗,是我 root?”我承认我需要阅读更多有关 nfsiostat 的内容。

我见过的另一种解决方案是从 fstab 中列出的 nfs 挂载转移到使用 autofs。CentOS 文档在两个版本前完成但请声明:

对于一两个挂载来说这不是问题,但是当系统同时维护对许多系统的挂载时,整个系统的性能就会受到影响。

考虑到我们有大约 10-12 个挂载点 - 这算多吗?我的同事建议“很多”应该在 100 个左右。无论如何,这些信息现在已经过时了。查看Redhat 文档,我们看到这是一个复制/粘贴。

我见过这两个勘误表/错误

但我们无法立即升级,因为服务器是生产服务器,并且处于临床环境中。此外,没有迹象表明这显然是我们的问题,而且鉴于我们无法随意重现问题,我们无法在我们的开发机器上进行测试 - 尽管我一直在尝试在我们的开发机器上重现。还有更新的 El Repo kernel-ml 版本,但存在同样的问题 - 无法在一夜之间更新 - 这些服务器通常 24/7 处于 100% 的状态。

所以,我想我有两个问题:

  • 人们所知道的监控驱动器存在的最佳方法是什么(即 - grepping mount 是一个不可接受的答案)
  • 我们是否应该从 /etc/fstab 迁移到 autofs (如果我们这样做,可能还会包括内核和操作系统更新)

相关内容