☰

网络文件系统在高 I/O 速度下出现故障

tag-icon • tag-icon storage network-storage
网络文件系统在高 I/O 速度下出现故障

我是集群上的一名用户，使用 NFS 来满足我们的数据存储需求。最近，我一直在运行一个管道，该管道在某些操作期间具有非常高的 I/O。

我们认为导致问题的程序名为 Bowtie，是生物信息学管道中的对齐器。简而言之，我们将每个文件 100 万行的碎片文件中的字母序列与包含整个词典的另一个文件进行比较。（这是对算法的过度简化）

此词典在过程中进行内存映射。我对集群上的三个节点有队列提交权限。

节点：节点1 节点2 节点3 节点4 节点5 节点6 节点7

我的右边：节点1 节点2 节点3

我可用的处理器数量：128 个处理器或 128 个运行队列槽。

为了在集群上运行，主文件被分成每 100 万行的块，然后使用 SGE 启动所有作业。

此时字典已加载到每个节点的内存中，即 Node1 2 和 3

对于队列槽上的每个活动作业，我都打开了以下文件处理程序

1 个包含要运行的代码的作业文件 1 个包含进程退出代码的代码文件 1 个 SGE 生成的 STDOUT 文件 1 个 SGE 生成的 STDERR 文件 1 个文件块 1 个输出文件

这意味着在此过程中，我在远程数据存储上打开了 768+3 个文件处理程序，尽管前四个文件对于管道中的每个脚本来说都是恒定的。

每当发生这种情况时，数据存储上的 NFS 服务器就会崩溃，并且整个集群都会瘫痪，因为存储变得无响应。

我们的 IT 人员表示，这可能是由于此过程中的 I/O 较高，并且 NFS 可能仅适用于小型集群，而不适用于大型集群。

因此，我们想出了一个解决方案，计划在其中一个节点上运行此过程。但这样一来，拥有一个集群的意义就被否定了，因为我们会将数据写入节点的磁盘，而不是所有集群共享的数据存储。

我不相信 NFS 是为小规模集群构建的，并且从未在大型企业级解决方案中成功实施。NFS 突然断开网络连接是否还有其他原因？

我确信进程问题是导致集群冻结的原因，但我不相信它所需的读/写速度是导致失败的原因。你们中有人以前遇到过这样的问题吗？完整的协议迁移是我们唯一的解决方案吗？

答案1

多年来学到的一些建议。

  1. 最小化 NFS 服务器上的负载：

设置 NFS 导出选项：async,insecure,no_subtree_check

设置 NFS 挂载选项soft,noatime,nodiratime,nolock,vers=3

还设置：noatime,nodiratime在数据/tmp/scratch 挂载上。确保 NFS 加密已关闭以减少负载。停止 NFS 锁定过程。

  1. 尝试在所有主机上为网络启用 JUMBO 帧（如果网络设备支持） - 将 MTU 设置为 9k 左右。

  2. 确保使用 raid10 存储（不惜一切代价避免使用 raid5/6）进行随机写入 IO。有 SSD 吗？

  3. 最大化打开的 FS 句柄数（在某些系统上默认为 2K），将其设置为 1M 左右。

  4. 是否有可能将包含输入数据的映射数据库复制到本地临时节点存储，然后作为单独的步骤合并/排序生成的 sam 文件？

  5. 增加处理块的大小（以便处理至少 30 分钟或更长时间。

  6. 如果可能的话尽可能在最高层次上分工（尝试在 10 个不同的节点上并行映射/排序 10 个单独的基因组/样本，而不是尝试使用 10 个主机串联映射每个基因组）。所有进程完成后，尝试检查点。

  7. 修改程序源，以便它以更大的块读取数据 - 例如 1M 而不是 4k。

  8. 请注意 CPU/RAM 互连争用（尤其是在 AMD 4-8 插槽系统上），有时在 48 核机器上运行 12-24 个线程比 48 个线程快得多。尝试不同的利用率级别。确保 NUMA 已打开并配置为多 CPU 系统。在启用 NUMA 的情况下重新编译。

PS：管理一个高效的集群类似于规划/管理一个拥有 1000 多名工人的建筑工地......

相关内容