正文
(NFS 架构)
在项目初期,NFS 方案表现尚可。当时平台仅在组内小范围使用,用户数量少,训练与微调任务不多,模型数据量也有限。但随着项目逐步完善,进入全实验室内测阶段,用户数量激增,模型与数据量大幅增加,NFS 方案的局限性逐渐显现。
一方面,大模型文件数量增多,磁盘占用率持续攀升。由于采用本地磁盘,扩容操作繁琐复杂。另一方面,使用 NFS 需自行管理存储,增加了管理难度。更为关键的是,随着用户数量的增加,性能瓶颈问题凸显,模型训练与推理速度显著变慢。例如,原本仅需几十小时即可完成的模型训练任务,在用户数量增多后,耗时大幅延长,甚至出现一个周末过去仍未训练完成的情况。
此外,NFS 缺乏分布式支持,也未找到理想的分布式解决方案。若强行实现,只能复制 NFS 实例,这不仅无法解决单点故障问题,反而可能因服务器宕机导致整个集群存储瘫痪。
为解决上述问题,我们对 JuiceFS 进行了深入调研,并最终选定其作为新的存储方案。JuiceFS 采用数据与元数据分离存储的架构。文件数据本身会被切分保存在对象存储,而元数据则可以保存在 Redis、MySQL、TiKV、SQLite 等多种数据库中,用户可以根据场景与性能要求进行选择。
(JuiceFS 社区版架构图)
在底层对象存储选择上,实验室内部此前已搭建了 MinIO 集群,且运维团队对 MinIO 较为熟悉,因此未进行过多调研,便直接采用。同时,考虑到 Redis 搭建便捷且实验室内部已有 Redis 集群,可直接复用,故选用 Redis 作为元数据引擎。
(引入 JuiceFS 后的架构)
然而,在后续使用过程中,我们发现自行维护对象存储面临诸多困难。运维团队在存储管理方面经验不足,导致各类问题频发。鉴于此,我们计划在未来对存储架构进行优化升级:将自行搭建的 MinIO 集群替换为商业对象存储服务,以提升存储的稳定性与可靠性;将 Redis 升级为 TiKV,以增强分布式存储能力与性能表现。
我们之所以选择 JuiceFS,主要基于以下几个关键因素:
-
高性能与弹性存储:这是我们极为看重的一点。高性能存储能够显著提升模型的推理与训练速度,从而优化整体业务处理效率,满足平台对高效运算的需求。
-
简单易用与分布式架构:JuiceFS 使用简便,降低了使用门槛与运维复杂度。作为分布式文件系统,它有效规避了单点故障风险,保障了存储系统的稳定性和可靠性,为业务连续性提供了有力支撑。
-
K8s 支持:与底层 K8s 架构深度兼容,便于在容器化环境中进行部署与管理,提升了资源调度与应用的灵活性。