Marico's space
最近折腾 HPC 集群存储方案，踩了几个坑，这篇把 NFS 和并行文件系统的选择问题说清楚。
搭建或扩展 HPC 集群时，存储设计是最大的架构决策之一。很多中小规模集群起步选择 NFS，简单、可靠、好维护。但随着业务增长，存储往往成为隐藏的性能瓶颈。
所以真正的问题是：
什么时候 NFS 就够了，什么时候其实需要 Lustre、BeeGFS 这类并行文件系统？
这篇文章拆解几个实际影响因素，帮助 HPC 运维做判断。
NFS 是集中式文件共享系统，计算节点从一个存储服务器访问数据。
运维喜欢它的原因：
常见 HPC 用途：
并行文件系统将存储操作分布到多个服务器和磁盘上同时执行。
典型代表：
为什么需要它们：
这类系统的设计目标是：
一个常见误解是：
"大集群 = 必须用并行文件系统。"
不一定。
一个 500 节点的集群跑轻量级 CPU 仿真，NFS 可能完全够用。
而一个 20 节点的 GPU AI 集群，可能几天内就把 NFS 压垮。
这通常是第一个预警信号。
NFS 表现良好的场景：
问题开始出现的场景：
典型症状：
如果存储服务器成为集群瓶颈，就应该考虑并行存储了。
不同应用对存储的压力差异很大。
NFS 能应付的场景：
并行文件系统更擅长的场景：
举例：
仿真任务写入：
深度学习任务：
这是 HPC 存储中最容易被忽视的瓶颈之一。
元数据操作包括：
AI 和基因组学负载经常产生：
NFS 在元数据风暴下表现极差，因为只有单台服务器处理所有请求。
并行文件系统将元数据处理分散到多台服务器。
问自己一个问题：
集群需要多少聚合带宽？
举例：
如果有：
单台 NFS 服务器很难持续维持这个水平。
并行存储专门为聚合吞吐量扩展设计。
GPU 集群会极速暴露存储短板。
原因：
GPU 处理数据比 CPU 快得多，可能会空等存储。
常见现象：
对于现代 AI 集群，存储吞吐量变得和 GPU 性能一样重要。
大型 HPC 任务会定期将状态保存到磁盘。
这就是检查点机制。
NFS 吃力的情况：
这会导致：
并行文件系统分散写操作，应对突发流量能力强得多。
眼光要超越今天。
NFS 通常够用的场景：
并行存储变得有吸引力的场景：
后续迁移是可能的，但很痛苦。
提前规划省去运维麻烦。
使用 NFS 时：
如果那台服务器挂了：
并行文件系统通常支持：
在生产 HPC 环境中，这一点至关重要。
以下情况 NFS 仍然是合理的 HPC 方案：
很多成功的 HPC 环境跑 NFS 跑了好几年没出大问题。
不要因为觉得"企业级"就部署复杂的并行存储。
运维简单性很重要。
如果观察到以下现象，应该认真评估并行存储：
到了这个阶段，存储不再是基础设施问题。
它直接影响应用性能。
继续用 NFS 如果：
迁移到并行存储如果：
HPC 存储架构没有通用答案。
最好的存储系统不是最先进的那个。
而是能匹配负载特征、随需求扩展、保持运维可控、提供稳定性能的那个。
对很多集群来说，NFS 仍然是正确选择。
但一旦存储开始限制计算性能，并行文件系统就不再是可选项，而是必要的基础设施。
原文链接：https://dev.to/...