在统一存储底座的选型过程中途虎养车参考了盘古在大规模 AI 存储场景中的架构思路并结合自身私有云环境和已有 Ceph 存储基础最终选择以 JuiceFS TiKV Ceph RADOS 的组合式方案构建统一 AI 存储基座。该系统统一支撑 AI 训练、AI 推理和大数据处理等场景目前已支撑亿级文件规模在低并发基准测试中小文件顺序写性能最高提升 5 倍小文件读性能最高提升 3 倍。本文将围绕选型思路、架构设计和生产落地展开重点介绍途虎养车如何在已有 Ceph 基础设施上构建统一 AI 存储基座并从 Ceph RADOS 数据路径、纠删码 Pool 容量效率、小文件写放大优化和容器化稳定性治理等角度分享统一存储底座在生产环境中的实践经验与后续规划。01 建设背景从多套存储并存到统一云存储底座在业务快速发展的早期阶段存储系统更多是围绕具体业务需求独立建设以满足当时的交付效率和场景诉求。随着系统规模扩大这种按场景建设的方式逐渐形成了多套存储并存的格局。尤其是在业务向大规模 AI 训练、AI 推理和云原生计算演进后底层存储在架构统一性、数据流动性、运维复杂度和性能稳定性方面的问题开始集中显现。主要痛点体现在以下几个方面。第一运维成本较高。线上长期并存 NFS、Alluxio、MinIO、Ceph、SeaweedFS 以及各类云盘等多套存储系统。不同系统的部署方式、访问接口、运维模型和故障处理方式各不相同导致整体技术栈较为割裂。随着集群规模扩大日常维护、容量规划、故障排查和版本升级的复杂度持续上升。第二数据孤岛问题明显。不同存储系统之间缺乏统一的数据访问路径数据在文件存储、对象存储和大数据访问体系之间流动成本较高。在 AI 训练场景中核心训练链路通常依赖 POSIX 文件语义而周边的数据处理、模型管理、备份归档等工具链又大量使用对象存储接口。多种访问方式之间无法自然互通导致数据需要在不同系统之间反复迁移或同步增加了链路复杂度和存储冗余。第三数据规模增长带来成本压力。随着业务规模持续扩大文件数量和数据总量都在快速增长。与此同时硬件采购、机房资源和存储运维成本也在上升。如何在保证可靠性和性能的前提下提高存储资源利用率、降低总体拥有成本成为基础设施建设中必须重点考虑的问题。第四AI 负载对性能和可靠性提出了更高要求。AI 训练、AI 推理、存算分离和大数据计算等场景对底层存储的并发能力、吞吐能力、访问时延和稳定性提出了更高要求。尤其是在大规模小文件访问、多机并发读取、模型文件加载和在线推理服务中存储系统不仅要具备稳定的容量支撑能力还需要在高并发场景下保持可预期的性能表现。在上述背景下原有多套存储系统并存的方式已经难以支撑业务的长期演进。我们希望通过统一云存储底座的建设逐步收敛分散的存储能力降低多套系统并行带来的运维复杂度并提升数据在不同计算形态之间的流动效率。从建设目标来看这套统一云存储底座需要重点覆盖两类能力方向。一是面向基础设施与虚拟化负载的块存储能力。这类能力主要服务于私有云和虚拟机环境目标是为云盘、虚拟机镜像和传统基础设施服务提供高性能、高可靠的块存储支撑。二是面向云原生与多元化计算负载的数据访问能力。这类能力主要服务于 Kubernetes 等容器化环境覆盖传统微服务、大数据计算、AI 训练、AI 推理以及向量数据库等新型中间件负载。其中AI 训练和 AI 推理对文件语义、对象接口、数据吞吐、小文件性能和多机并发访问能力提出了更集中的挑战。因此统一云存储底座的建设既包括面向虚拟化环境的块存储能力也包括面向 AI 与云原生负载的数据访问能力。下文将重点展开后者即如何基于 JuiceFS 构建统一的数据访问底座支撑 AI 训练、AI 推理和大数据处理等场景。02 基于 JuiceFS 建设统一 AI 存储基座盘古架构参照与技术权衡在统一存储基础设施的建设过程中我们重点参考了阿里云在 2023 年公开展示的面向 AI 场景优化的自研分布式存储系统“盘古”。通过分析其面向大规模训练场景的存储架构演进思路我们结合自身私有云环境、已有存储基础和业务负载特点对统一存储底座的技术路线进行了系统性的对比与权衡。如果将分布式存储系统拆解为元数据层和数据存储层可以看到盘古与 JuiceFS Ceph RADOS 在目标上有一定相通之处二者都需要支撑大规模数据访问、存算分离、多协议接入和高可靠存储。但在具体实现路径上两者存在明显差异。阿里云盘古采用分布式 Master 架构这是一种典型的中心化高可用集群方案。在公有云多租户、超大规模和高弹性的基础设施环境下中心化调度可以更好地感知集群状态并在坏盘、机器上下线、故障隔离等场景中降低对线上任务的影响从而提升整体系统的稳定性和可运维性。image与此相比JuiceFS Ceph RADOS 采用组合式落地路径通过 JuiceFS 承担统一文件系统层由后端元数据引擎和 Ceph RADOS 分别承载元数据与数据存储能力。Ceph 通过 CRUSH 算法实现数据分布和故障域管理底层数据组织更加去中心化。在“存算分离”的设计思想下盘古与 JuiceFS Ceph RADOS 体现出不同的工程权衡。盘古采用偏重客户端的技术路径。当用户在计算节点挂载并写入盘古存储时无论底层采用三副本策略还是采用 9:3、4:2 等纠删码EC架构数据切片分发、EC 计算和校验等逻辑都可以在客户端侧承担更多工作。这种设计能够减轻后端存储服务器的计算压力有利于支撑公有云级别的大规模扩展但也会在一定程度上消耗业务计算节点的网络和 CPU 资源并提高客户端复杂度。imageJuiceFS Ceph RADOS 架构则更偏向“轻客户端 后端存储集群承载数据可靠性”的模式。在该架构中JuiceFS 客户端主要负责文件系统语义、元数据交互、缓存管理和数据访问调度实际数据写入 Ceph RADOS 后底层采用多副本还是纠删码主要由 Ceph 存储集群内部完成。这样可以让计算节点侧保持相对轻量降低对业务训练进程的干扰同时复用已有 Ceph 存储资源。对于我们的私有云环境而言重新建设一套类似盘古的一体化分布式存储系统意味着较高的研发和运维投入。相比之下基于 JuiceFS Ceph RADOS 的组合式方案可以在已有 Ceph 资源基础上快速构建统一文件系统层并通过多协议接入能力支撑 AI 训练、AI 推理和大数据处理场景。统一 AI 存储基座架构我们最终选择基于 JuiceFS 构建统一 AI 存储基座。整体架构从上至下可以分为四个层级。第一层是工作负载层。这一层涵盖虚拟机、Kubernetes 容器化业务、传统微服务架构以及 AI 训练、AI 推理和大数据 Spark 计算任务。第二层是缓存层。缓存层包括分布式数据缓存池DataCache Pool与分布式键值缓存池KVCache Pool。其中DataCache 主要用于加速训练数据集、模型文件和热点文件的重复读取降低后端存储压力KVCache 则面向大模型推理场景用于在多级存储体系中承载上下文数据的缓存与访问加速提升在线推理服务的响应效率。image第三层是存储协议层。JuiceFS 在这一层提供统一的数据访问入口。AI 训练任务可以通过 POSIX FUSE 或 CSI Driver 访问数据大数据 Spark 任务可以通过 JuiceFS Hadoop Java SDK 接入对象存储工具链可以通过 S3 Gateway 访问同一份数据。通过这种方式文件存储、对象存储和大数据访问接口可以围绕同一套底层数据形成统一访问路径减少不同存储系统之间的数据搬运和重复存储。需要说明的是虚拟机云盘等块存储场景主要由 Ceph RBD 承担它属于整体云存储体系中的块存储能力本文重点讨论的是基于 JuiceFS 构建的文件、对象和大数据访问底座。二者可以共享底层 Ceph 资源体系但在访问语义和服务对象上需要区分。第四层是存储引擎层。JuiceFS 采用数据与元数据分离的架构。对于亿级文件规模的文件系统来说元数据能力直接影响路径解析、目录遍历、文件属性查询、小文件访问以及并发任务启动时的整体性能。TiKV 具备分布式事务、强一致性、高可用和水平扩展能力能够为大规模文件系统提供稳定的元数据支撑。于是在元数据层我们构建了一个由五个节点组成的 TiKV 分布式集群。在数据层我们采用 Ceph RADOS 作为 JuiceFS 的底层数据存储引擎。Ceph RADOS 可以复用现有私有云存储资源降低重复建设成本同时通过构建纠删码 Pool 存放物理数据可以在保证可靠性的前提下提升物理磁盘净容量利用率缓解数据规模增长带来的存储成本压力。在这套架构下系统的数据通信可以划分为两条路径一条是客户端与元数据引擎 TiKV 之间的元数据交互路径主要负责路径查找、目录结构、文件属性和状态信息等操作另一条是客户端与底层数据存储引擎 Ceph RADOS 之间的数据读写路径主要负责实际数据块的存取。通过 libradosJuiceFS 可以与底层 Ceph RADOS 进行数据交互。相比传统网关型存储架构这种方式减少了多层转发开销使客户端在完成元数据交互后能够更直接地访问底层存储集群从而缩短数据访问链路。image03 生产落地与优化实践核心场景落地与存储体系收敛在大模型业务场景中公司已划分专门的自建算力集群用于承载通义千问、MiniMax 等模型推理服务。同时内部业务线自研的各类定制化模型在通过生产验证后也已逐步接入 JuiceFS 文件系统。由此核心大模型推理与训练应用开始统一接入新的文件存储底座原有网络文件系统集群和 Alluxio 存储集群也进入分批下线阶段。在核心中间件与后台备份场景中包括大规模 ClickHouse 应用在内线上多类核心中间件系统以及全量业务生产备份任务也已完成对 JuiceFS 文件系统的接入。随着统一文件底座在容量、稳定性和访问效率方面逐步验证原有 MinIO、SeaweedFS 等存储集群也开始进入停机和下线序列从而降低多套存储系统并存带来的日常维护复杂度。AI 训练与推理场景的缓存加速针对 AI 训练场景训练数据通常具有“一次生成、多次读取”的特点。我们利用 JuiceFS 社区版的本地数据缓存能力将训练集中的热点数据缓存在计算节点侧从而降低后端存储压力并提升多机并发读取效率。针对大模型推理场景模型在对外提供在线服务或进行 Token 迭代生成时对上下文数据加载的延迟和吞吐较为敏感。在单机显存和内存容量有限的情况下我们通过分层缓存机制对上下文数据进行分级缓存和访问加速从而提升在线推理服务的响应效率。性能压测与小 I/O 调优在统一存储底座落地后我们重点验证了海量小文件场景下的读写性能。基于前文所述的 JuiceFS Ceph RADOS 架构我们使用 juicefs bench 与 fio 对小文件读写和随机 I/O 能力进行了压测对比以评估该方案在关闭本地缓存、低并发条件下的实际表现。为尽量排除缓存因素对结果的影响测试中关闭了所有本地缓存以透传模式进行压测。需要说明的是该轮测试主要用于快速验证架构可行性当时仅在客户端配置了 4 个并发线程进行局部测算因此测试数据并不代表集群的真实性能峰值。即便在低并发的基准测试条件下JuiceFS Ceph RADOS 方案相比原有 JuiceFS MinIO 方案仍体现出明显的性能提升image小文件写入性能提升明显。 小文件写性能提升约 5.5 倍单文件写入耗时也明显下降。小文件读取性能提升约 3.2 倍。 读取速率和单文件读取耗时均有改善。随机 I/O 能力整体提升。 随机读写的吞吐和 IOPS 均有不同程度提升其中随机写 IOPS 提升超过 3 倍。从架构层面看JuiceFS MinIO 方案需要经过 S3 接口和对象存储服务链路而 JuiceFS Ceph RADOS 方案可以通过 librados 更直接地与底层存储集群交互减少网关层转发开销。因此在小文件写入和随机写入等对访问链路较敏感的场景下Ceph RADOS 后端表现出更明显的性能优势。不过在随机读取小文件的测试中由于关闭了本地缓存数据仍需要从底层物理盘实时检索因此读取性能没有像写入一样出现数倍提升但整体仍保持了约 1.4 倍的稳定提升。小文件空间放大与写放大优化在纠删码EC模式下传统的 EC 算法需要根据条带单元Stripe Unit进行对齐。在 63 的场景下即使写入一个 10 字节的超小文件系统也需要填充 6 个 Data Chunk 至 4KB再叠加 3 个 Coding Chunk导致实际物理占用高达 36KB造成严重的写放大和几千倍的空间浪费。image为缓解这一问题我们通过升级引入 Ceph 的 Fast EC 特性对小对象写入进行优化。一方面Fast EC 可以缓解小文件空间放大问题。开启后小对象不再强制填充整个条带而是仅写入所需条带。以 10 字节小文件为例逻辑大小仍然保持 10 字节物理空间则占用第一个条带在最小分配单元为 4KB 并叠加校验数据后物理空间占用可降至 16KB。另一方面Fast EC 也有助于提升小 I/O 场景下的读写效率。读取时无需读取完整条带只需提取所需数据写入时则可以利用奇偶校验增量写入PDW减少不必要的网络交互和 I/O 消耗从而改善小文件整体读写性能。JuiceFS Mount Pod 稳定性优化在容器化环境下AI 训练应用曾偶发 Bad file descriptor 报错严重影响训练效率排查后发现与 Mount Pod 的 OOM内存溢出有关。image第一类是元数据备份引发的周期性 OOM。当集群文件数量达到千万级甚至亿级时JuiceFS 默认每小时执行的周期性元数据备份会产生较大的备份文件。由于该备份任务会随机选择集群中的客户端执行而底层 RADOS 架构对单次 Object 写入存在大小限制例如 128MB因此在大规模文件系统场景下备份任务可能高频失败并进一步导致 Mount Pod 内存持续增长最终触发 OOM。针对这一问题我们关闭了 Mount Pod 的自动备份能力禁止在线客户端执行自动备份改由专用定时任务在后台统一处理元数据备份从而避免业务客户端承担额外的备份压力。image第二类是页缓存增长引发的偶发性 OOM。在业务频繁读取大量本地缓存时Linux 内核页缓存会持续上升。此时即使容器实际资源使用量只有约 1.1GBKubernetes 的 OOM 判断仍可能以 working_set_bytes 为依据。由于该指标包含页缓存当其上升到较高水平例如 33.5GB 时就可能触发 OOM Kill导致客户端偶发断连。针对这一问题我们首先结合历史监控数据合理调大并设置 limits.memory。其次对缓存资源进行物理隔离避免所有 PVC 共享同一个本地缓存目录。对于 CPU 节点等内存相对较小的机器则将本地缓存容量Data Cache Size限制在合理区间例如 10GB 至 50GB并在达到上限后开启主动回收机制避免容器内核页缓存无序增长。通过上述优化Mount Pod 在大规模文件系统和高频缓存访问场景下的稳定性得到改善也为后续更多 AI 训练和推理任务接入统一文件底座提供了保障。04 未来规划围绕 AI 云存储基础设施的持续演进我们后续将重点推进三个方向从私有云到混合云的统一管理随着 AI 训练任务在私有云与公有云之间并行调度存储底座需要进一步提升跨环境的数据管理能力。后续我们将在现有私有化 Ceph RADOS 架构基础上继续探索 JuiceFS 对公有云对象存储的接入能力。通过将跨云数据同步、数据分布和访问路径管理尽可能下沉到存储层可以减少上层训练任务对不同云环境差异的感知使应用侧能够获得更加一致的挂载路径和访问体验。这样既有利于提升训练任务在不同算力环境之间的迁移效率也能降低多云环境下的数据管理复杂度。推进湖仓一体化减少跨系统数据搬运过去HDFS 离线大数据集群与算法存储集群之间往往需要依赖同步工具进行数据搬运。这种方式不仅增加了链路复杂度也容易带来数据冗余、同步延迟和管理成本。后续我们计划进一步引入和完善 JuiceFS Hadoop Java SDK 的使用方式使算法层的 Spark 任务能够直接读写底层统一存储池。通过这种方式大数据计算、算法训练和数据归档可以围绕同一套存储底座协同运行减少不同系统之间的数据复制和重复存储从而进一步打破数据孤岛推动存算分离和湖仓一体化落地。构建多级分层存储支撑大模型推理加速随着大模型推理服务规模扩大单一存储介质已经难以同时满足成本、容量和访问延迟要求。后续我们将从数据层分层和 KVCache 分层两个方向推进能力建设。在数据层分层方面当前 JuiceFS 的数据分层能力更多面向公有云对象存储场景。针对私有化 Ceph RADOS 环境我们计划与社区继续合作探索在同一套 JuiceFS 文件系统下挂载多个不同性能等级的 Ceph 存储池例如 NVMe Pool 与 HDD Pool使不同冷热程度、不同访问频率的数据能够进入更合适的存储层级。