正文
（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 架构深度兼容，便于在容器化环境中进行部署与管理，提升了资源调度与应用的灵活性。
