专栏名称: InfoQ
有内容的技术社区媒体。
目录
相关文章推荐
51好读  ›  专栏  ›  InfoQ

中国科学院计算所:从 NFS 到 JuiceFS,大模型训推平台存储演进之路

InfoQ  · 公众号  · 科技媒体  · 2025-05-18 10:15

正文

请到「今天看啥」查看全文


图片

(NFS 架构)

在项目初期,NFS 方案表现尚可。当时平台仅在组内小范围使用,用户数量少,训练与微调任务不多,模型数据量也有限。但随着项目逐步完善,进入全实验室内测阶段,用户数量激增,模型与数据量大幅增加,NFS 方案的局限性逐渐显现。

一方面,大模型文件数量增多,磁盘占用率持续攀升。由于采用本地磁盘,扩容操作繁琐复杂。另一方面,使用 NFS 需自行管理存储,增加了管理难度。更为关键的是,随着用户数量的增加,性能瓶颈问题凸显,模型训练与推理速度显著变慢。例如,原本仅需几十小时即可完成的模型训练任务,在用户数量增多后,耗时大幅延长,甚至出现一个周末过去仍未训练完成的情况。

此外,NFS 缺乏分布式支持,也未找到理想的分布式解决方案。若强行实现,只能复制 NFS 实例,这不仅无法解决单点故障问题,反而可能因服务器宕机导致整个集群存储瘫痪。

JuiceFS 方案引入及优势

为解决上述问题,我们对 JuiceFS 进行了深入调研,并最终选定其作为新的存储方案。JuiceFS 采用数据与元数据分离存储的架构。文件数据本身会被切分保存在对象存储,而元数据则可以保存在 Redis、MySQL、TiKV、SQLite 等多种数据库中,用户可以根据场景与性能要求进行选择。

图片

(JuiceFS 社区版架构图)

在底层对象存储选择上,实验室内部此前已搭建了 MinIO 集群,且运维团队对 MinIO 较为熟悉,因此未进行过多调研,便直接采用。同时,考虑到 Redis 搭建便捷且实验室内部已有 Redis 集群,可直接复用,故选用 Redis 作为元数据引擎。

图片

(引入 JuiceFS 后的架构)

然而,在后续使用过程中,我们发现自行维护对象存储面临诸多困难。运维团队在存储管理方面经验不足,导致各类问题频发。鉴于此,我们计划在未来对存储架构进行优化升级:将自行搭建的 MinIO 集群替换为商业对象存储服务,以提升存储的稳定性与可靠性;将 Redis 升级为 TiKV,以增强分布式存储能力与性能表现。

JuiceFS 的优势

我们之所以选择 JuiceFS,主要基于以下几个关键因素:

  • 高性能与弹性存储:这是我们极为看重的一点。高性能存储能够显著提升模型的推理与训练速度,从而优化整体业务处理效率,满足平台对高效运算的需求。

  • 简单易用与分布式架构:JuiceFS 使用简便,降低了使用门槛与运维复杂度。作为分布式文件系统,它有效规避了单点故障风险,保障了存储系统的稳定性和可靠性,为业务连续性提供了有力支撑。

  • K8s 支持:与底层 K8s 架构深度兼容,便于在容器化环境中进行部署与管理,提升了资源调度与应用的灵活性。







请到「今天看啥」查看全文