小米作为全球知名的科技巨头公司,已经在数百款产品中广泛应用了 AI 技术,这些产品包括手机、电视、智能音箱、儿童手表和翻译机等。这些 AI 应用主要都是通过小米的深度学习训练平台完成的。
在训练平台的存储方案中,小米曾尝试了多种不同的存储方式,包括 Ceph+NFS、HDFS 和对象存储挂载等。然而,这些不同的存储方式导致了数据冗余和维护管理成本的增加,同时也带来了扩展性和性能方面的问题。另外,随着公司云原生化进程的推进,越来越多的应用从物理机迁移到容器平台,这进一步增加了对文件存储和多节点共享访问数据的需求。
因此,小米存储团队自 2021 年开始启动了文件存储项目,基于 JuiceFS 构建了一个文件存储平台化产品,并通过 CSI Driver 组件提供了云原生存储的能力,以满足上述各种业务场景对文件存储的需求。
目前,这个平台已经承载了超过 50 亿个文件,总容量 2.5PB 以上,集群吞吐达到每秒 300~400Gbps。业务场景也在不断扩展,涵盖了大模型数据存储、大数据以及数据湖上云等领域。在接下来的内容中,我们将深入介绍小米在这一过程中的设计思路和实践经验。
01 为什么要建设统一的存储平台
一方面,我们面临着以下三方面的需求增长:日益增长的应用场景:随着人工智能业务的发展,我们对大规模文件存储的需求也在快速增长,此外在容器内共享访问数据、存算分离、大数据上云、大模型等场景同样对文件存储有着众多的应用需求,这些场景均需要高效、可靠的文件存储服务。
统一的文件存储方案:在我们立项并进行 JuiceFS 项目之前,在机器学习平台我们采用了 Ceph RBD+NFS、S3 FUSE、HDFS 等多种数据存储方式,我们期望能够统一存储方案,将大部分数据放到同一存储平台,降低维护及数据冗余成本。
混合云场景:小米作为全球化企业,业务遍布全球多个国家,在海外多个区域都会有文件存储相关的业务需求,我们需要满足私有云+公有云一体的文件存储架构。我们预期中的存储平台需要具备如下特性:
-
功能丰富,拥有完善的存储功能,支持 POSIX 等多种访问协议,同时具备易用性,面向云原生平台设计。
-
规模扩展性,能够支撑百亿文件、百 PB 容量规模的文件存储能力,能够弹性扩展。
-
性能与成本,满足 AI 高并发训练等场景的性能需求,服务稳定可靠同时兼顾存储成本。
-
混合云场景,支持多种存储后端,支持云上云下不同应用环境。
-
开发迭代,我们有一个明确的目标,即借助开源项目,不重复造轮子。易于开发扩展与维护, 能够持续迭代。
存储选型:CephFS vs JuiceFS
我们对比了 JuiceFS、CephFS 以及其他一些业界文件系统的性能和功能。JuiceFS 社区文档也提供了一些的对比信息,如果您感兴趣,可以查阅 JuiceFS 社区文档。
首先,CephFS 在我们的需求中有一些无法满足的部分,例如,我们希望在公有云上部署,而 CephFS 可能更适合在 IDC 环境中使用。其次,CephFS 在集群规模达到一定程度时(例如 PB 级别),在平衡和元数据服务器性能方面可能会遇到一些瓶颈。
在 2021 年初,JuiceFS 项目刚刚开源,我们就开始关注了。与 CephFS 等其他开源文件存储系统相比,JuiceFS 采用了插件化的设计思想,为我们提供了更大的灵活性,使我们能够根据自身需求进行定制化开发。JuiceFS 还提供了丰富的产品功能,能够满足我们的特定场景需求。
同时,考虑到 Ceph 作为底层存储服务在小米内部已经大规模应用了多年,我们可以将 Ceph RADOS 作为 JuiceFS 的数据存储池,在 IDC 机房内提供高性能和低延迟的文件存储服务。这是我们在选型时的基本思考,以下这些优势是我们选择了 JuiceFS 作为整体存储服务的基础。
JuiceFS 优势
JuiceFS 采用了数据和元数据分离存储的架构,同时具备完全可插拔的设计,我个人认为这个构想非常出色。在进行基于 JuiceFS 的二次开发时,我们能够轻松地适应内部企业需求,充分利用已有的成熟组件,以满足不同应用场景下的数据管理需求。
JuiceFS 功能十分丰富,它兼容了 POSIX、HDFS、S3 等多种访问协议,支持数据的加密、压缩、文件锁等多项功能,并提供了 CSI 组件的支持,同时还具备相对复杂的扩展功能,这些满足了我们对存储服务的基本需求。
性能方面 JuiceFS 表现卓越,借助其独特的数据切分管理和客户端缓存加速能力,为客户端提供了出色的吞吐性能。
JuiceFS 社区生态非常活跃,根据我所接触到的一些项目,我认为 JuiceFS 社区的运作是最出色的。值得一提的是,在开源之前,JuiceFS 首先在商业领域积累了经验并应用于实际场景中,这为我们提供了许多有价值的借鉴。
通过以上考虑,我们当时决定基于 JuiceFS 构建一个面向云原生设计的、高性能且具有弹性可扩展性的共享文件系统。
02 小米存储平台架构及能力
作为一个文件存储平台,我们的服务是处于底层位置的,旨在满足小米企业内多样的需求场景。这些场景不仅包括自驾等基础应用,还涵盖了容器共享存储、大数据等多种场景。我们的目标是将产品化功能提供给业务部门,增强服务的易用性,使业务方能够更轻松地使用我们的服务。
在上述架构图中,作为存储平台,我们不仅提供了 JuiceFS 文件存储服务,还提供了基于 Ceph RBD 的块存储服务。同时,Ceph 为 JuiceFS 提供了底层对象存储支持。我们还拥有内部的 FDS 对象存储服务,可以适应 IDC 以及各种公有云对象存储,为业务提供无缝的跨多云的服务。我们向上层提供了不同的协议支持,包括块协议、文件协议和对象协议。在更高层次,我们为 PaaS 平台和计算层提供支持,最顶层则是应用层。
小米的 JuiceFS 架构与社区版 JuiceFS 基本相同。在 JuiceFS 客户端方面,我们提供上层协议支持,并与我们的 meta 服务和 data 服务进行底层对接。
我们的项目启动较早,当初在 JuiceFS 开源时,meta 服务的选择仅限于使用 Redis。然而,我们的首个业务需求可能涉及到数亿级别的文件规模,而 Redis 实际上难以有效支持这一规模。
与此同时,我们的产品是一个平台化项目,因此我们决定自行开发一个分布式的 meta 服务,用于统一管理集群,包括之前提到的复杂功能,具备这样的中心化能力实际上会更容易实现我们的目标。为存储元数据信息,我们选择了分布式 meta,基于另外一款开源存储项目 CubeFS 的 meta 模块实现。
优化1:统一集群管理
根据我们的场景需求,我们对 JuiceFS 做了一些优化。”集群统一管理” 这是我们与 JuiceFS 社区版的架构最大的区别,也是我们很多平台功能实现的基础。
在 JuiceFS 社区版中,文件系统之间缺乏统一的管理,用户需要自行设置他们自己的 meta 服务、bucket 等。例如,当业务部门创建一个新的卷时,他们需要自己申请 Redis、bucket、网关等,并设置后台任务,这使得整个过程繁琐且依赖于客户端。如果业务部门需要创建另一个卷,他们必须重复之前的工作,因为所有工作都是在客户端完成的。
小米的主要不同之处在于我们将卷的管理进行了集中,将通用功能下沉,使得业务使用更加便捷。
首先,我们可以看到在这个层次上,最顶层是 meta 服务,分为 master 和 metanode。我们通过 meta master 进行了统一管理,将跨客户端的工作功能集成到了统一的管理层次。这包括基本的管理功能,如卷的创建和删除,以及存储池与 bucket 的管理,还包括一些会话管理机制。一些异步任务由中心统一维护,包括 compaction、数据清理等流程。
由于我们有一个 master 层,因此我们能够提供一些产品功能,包括权限接入,建立了统一的网关,并提供账单服务,以及对应内部控制台的功能接入。
优化2:S3 网关
社区版的 S3 网关可以与一个卷相对应,通常需要进行 Minio 的 AK/SK 配置。我们首先在卷内进行了统一的管理,这使得它能够支持集群内所有卷的访问,并提供了一个统一的 S3 接入域名。
因此,我们在这一层上实现了文件系统的动态加载,使得多个卷可以通过同一个网关服务访问数据。同时,在这一层次上,我们也实现了小米内部 IAM 权限系统的适配,支持多租户的 AK/SK。
在公共参数方面,例如缓冲缓存(--buffer-cache
)、缓存大小(--cache-size
),这些参数可以在多个卷之间全局共享,还有与 meta 相关的连接池实现了共享,支持多个卷的网关管理。
此外,我们在网关服务上提供了一个完备的监控系统,用于监控请求吞吐量、延迟、SLA 等性能指标。
优化3:存储类型及多池管理
在进行了统一管理之后,我们进行了存储类型的封装。对于业务方来说,他们不需要关心数据存储在后端的存储介质或服务提供商。用户只需要选择适合其需求的服务类型。这个系统提供了三种基本类型,包括性能型、容量型和成本型。性能型对应后端的 Ceph SSD 存储,容量型对应机械硬盘,而成本型则对接对象存储。每种类型适用于不同的使用场景,因此提供了不同的吞吐量和延迟水平。
在存储类型方面,我们引入了一层多池管理机制,对底层存储服务进行了统一管理和封装。相对于社区版中卷(bucket)与存储池的一对一关系,我们支持了多池管理功能,主要实现了以下能力:
首先,与业务相关的配置。存储池的配置以及 Ceph 的配置都由元数据系统进行统一管理,无需用户额外配置 Ceph 的环境变量或配置文件。
第二点,我们允许卷设置存储类型,存储类型与存储池关联,并且在数据的切片级别进行记录。存储类型与其绑定的存储池是可以切换的,这样可以满足超大容量卷(百 PB 级别)的存储需求。
我们的多池管理设计主要来源于对 Ceph 的思考。当 Ceph 集群规模达到一定程度时,性能问题可能会显现出来,我们不希望维护特别大规模的 Ceph 集群,而是会建立新的集群,相当于将大容量划分为多个小集群来进行管理。这有利于减少性能开销,减少 OSD 存储故障的概率。同时也降低了管理节点的数量。我们的操作就相当于将存储类型绑定的存储池切换到新的存储池上,旧数据仍然存储在旧存储池中,而新的数据将被存储在新的存储池上,不会产生数据均衡挪动。
此外,我们还有更多操作的空间,可以按切片级别将数据迁移到不同的存储池。基于这一能力,我们可以实现更复杂的功能,如根据文件访问情况的冷热分层、基于 ec 纠删码+ 3 副本的大小 IO 分流优化等。
产品能力
我们为集团内部提供了丰富的产品功能,这些功能在企业内部是非常必要的功能:
-
权限系统:我们接入了 IAM(身份与访问管理)资源权限管理系统,适配通用的鉴权功能,以确保只有经过授权的用户可以访问资源。同时能够根据卷的归属找到相关项目部门及负责人,从而将存储资源精准地定位到实际负责的实体,有助于企业更好地进行管理。
-
控制台:接入小米融合云控制台,我们提供了管理卷和文件的功能,方便业务使用
-
监控:我们为 JuiceFS 集群和客户端提供了监控看板,帮助企业实时了解系统的性能和状态。
-
审计:对文件操作和数据读写进行审计,记录审计日志。这对一些敏感数据的业务非常重要,因为它可以告诉您哪些客户端正在访问文件,以及文件是否曾被篡改或删除。
-
回收站:我们支持回收站功能,可以帮助企业规避因误删数据而带来的风险,让数据更加安全可控。
-
账单:我们提供按不同存储类型和存储容量计费的功能,帮助企业了解和管理存储资源的费用。
大部分业务人员对于存储产品并不十分了解,因此在选择合适的存储类型时常常感到困难。为了帮助内部用户更好地做出选择,我们提供了一些通用场景建议。在控制台的卷文件管理方面,我们采用了类似于 Minio 平台的 S3 网关,用于多卷的文件内容管理,用户能够方便的进行文件管理和分享下载。
基于这些产品能力及云原生 CSI Driver 的功能,我们已经对接了小米容器平台及机器学习 PaaS 平台,业务根据需要选择不同的集群与存储类型使用我们的 JuiceFS 文件存储服务。在容器内使用 JuiceFS 时,我们更倾向于优先采用静态卷的方式来进行接入。首先,静态卷接入的优势在于它们是明确定义和创建的,对其名称和用途都有明确的规定。相比之下,动态卷的使用往往涉及到更复杂的权限管理。另外,对于更底层的 Kubernetes 平台,我们也为该服务提供了静态卷和动态卷两种接入方式。目前,我们的大部分服务都是以原生方式提供的。
分布式 meta
我们的元数据部分则是基于 CubeFS 进行开发的。最早,CubeFS 是由京东开源,是中国第一个开源分布式文件系统,涵盖了元数据(meta)、数据(data)以及最近的纠删码(EC)模块。
然而,当初我们并没有直接采用 CubeFS 的全部,主要有两个原因。首先,我们更希望能够充分利用公有云的资源,而当时的 CubeFS 仅支持自建存储。其次,我们对 Ceph 有更深入的了解,希望能够在底层的数据部分进行灵活替换。因此,当初我们只采用了 CubeFS 的元数据部分。
元数据是基于 Multi Raft 进行全内存实现的,架构分为两个模块:Master 和 Meta。
-
Master 是一个集群管理节点,负责管理存储卷和集群的基本配置信息,以及管理和调度 meta region,并向外部提供 HTTP 接口。
-
meta 作为元信息节点。它通过 Multi Raft 管理 region,并向外部提供 TCP 和 HTTP 接口,支持横向扩展。
数据被划分为不同的 region。每个文件系统都有多个数据分片,按照 inode 区间进行划分。随着数据量的增长,分片的数量也会增加。每个分片都会被均匀地分布在不同的元数据节点上。在一定条件下,会进行分裂操作,以便更好地实现水平扩展。目前,我们的生产环境中最大的一个集群已经拥有了 30 多亿个文件,预计可以扩展到百亿级别。
上图是 meta region 分裂的示意图,如果前两个 region 被写满,它就会变成只读状态。当最后一个 region 的文件数量达一定规模或节点内存用量超过了阈值,那么最后一个分片就会分裂成两个,实现了 region 的横向扩展。
03 应用场景
JuiceFS 的应用场景主要包括 4 个场景:机器学习、文件持久化存储、共享数据访问和大数据分析。目前,机器学习是我们最大的业务领域,大数据及大模型方面我们正在积极探索中。
上图展示了我们整体业务发展的情况。我们的单一集群已经达到了数十亿文件和 PB 级别的数据量,吞吐量达到数百 Gbps 的级别。
在过去的两年中,我们正式地将 JuiceFS 接入到了我们的学习平台。目前,它主要用于提供自动驾驶训练、部分手机训练和新一代语音训练的支持。
去年,我们还支持了容器平台,发布了公共集群,并提供了容器平台的接口,以满足不同应用的需求。接着,我们接入了小爱语音的训练业务。他们以前的部署方式是使用物理机上的 SSD 来运行 NFS 服务。然而,随着数据量的不断增长以及团队规模的扩大,他们很难进行扩容。此外,他们在数据管理方面也面临挑战。因此,去年他们决定采用我们的服务。
今年,我们进行了一些新业务领域的尝试,其中包括将大数据 Iceberg 迁移到云端进行性能验证和比较。此外,在大型模型的存储方面,我们已经支持了完整的存储,包括原始语料的接入、算法训练和基本模型文件的存储。
大数据上云场景探索
在将大数据 Iceberg 迁移到云端的性能验证与同类产品相比,JuiceFS 在多种规格的 IO 读写场景下均表现出色,某些场景性能略优。
如上图所示,时间越短越好,可以看到 JuiceFS 在某些场景的速度更快,某些场景略慢,整体性能可以和公有云产品媲美。同时值得一提的是,我也了解到一些其他的存储产品,在数据组织管理和加速设计方面或多或少受到了 JuiceFS 的启发。
语音场景业务收益
我们目前已经有许多业务迁移并使用了 JuiceFS 文件存储服务,下面是以语音训练业务为例,介绍一下迁移到 JuiceFS 后,给业务方带来的收益:
-
容量收益:语音组数据之前主要存放在 NFS 上,经常遇到某台存储机器被写满,导致该机器上同学无法继续写入的问题。随着训练规模的增加,容量扩展和容量管理都不方便。云平台-云存储组提供的 JuiceFS 理论上可以更好的满足我们的需求。
-
成本收益:JuiceFS 单位容量的成本低于 NFS,目前语音组数据已由(NFS+FDS)迁移至 JuiceFS,根据机器成本计算,每 T 容量每月的成本更低。
-
安全性:语音 NFS 采用 RAID10 与 RAIDO 混部的方式,而目前采用3副本模式存储,JuiceFS 上的数据安全性更有保障。
-
并发性:NFS 在使用时,用户的 IO 经常会集中在某一个存储节点上,某一台存储节点上的某个用户运行重 IO 任务后,同存储节点下的其他用户会受影响。而 JuiceFS 将数据分散到多个节点上,多用户多机并发访问时,用户相互影响小,IO 上限更高。
04 未来规划
更低成本
-
冷热分层:我们鼓励更多地使用公有云对象存储,以降低数据存储成本。
-
IDC 优化:我们引入了高密度机型以减少成本,并对存储方式进行了优化,采用了 EC 纠删码存储方式,并实现了大小 IO 的分离。
-
元数据管理:我们的元数据目前采用了全内存模式,对于大量小文件的应用场景,元数据在内存中的占用可能会相当大,成本很高。为了降低处理成本,我们需要支持 DB 模式,即不再使用全内存存储,而是采用本地的 rocksdb + ssd 方式存储。
提升性能
-
提高全闪存储性能,支持 RDMA、SPDK,降低延时
-
GDS (GPU Direct Storage) 面向 AI 大模型场景,提供高速存储 能力
-
优化 Meta 传输 proto 协议,减少 marshal 开销及数据传输量
丰富功能
-
适配社区版本最新功能,如目录配额功能。
-
希望能实现 JuiceFS 商业版的部分能力,如支持分布式缓存功能,快照功能
-
lifecycle 生命周期管理
-
QoS 限速能力
05 JuiceFS 使用经验分享
-
客户端升级优化:在早期,我们面临了客户端升级的一些挑战。具体来说,Mount Pod 客户端升级要求迁移 Mount Pod 上的所有业务,重新构建 Mount Pod,然后 Mount Pod 才能更新。这一过程非常繁琐,给业务方带来了很多困扰。
为了解决这个问题,我们实现了热重启功能,无需卸载即可升级客户端。通过 Unix Domain Socket 传递
/dev/fuse
文件描述符,并重新构建文件句柄,从而实现了新进程对挂载点的重建。这一改进使得 CSI Driver 升级时则无需重新调度 Mount Pod,大大降低了升级的难度。 -
本地磁盘缓存优化:在容器场景中,客户端磁盘通常是机械硬盘。当需要读取的数据集较大时,如果本地缓存空间有限,会导致缓存命中率非常低。尤其是当将 Ceph 作为存储池时,一般不建议在业务中启用缓存。
-
预读优化:针对偏向于随机读取的场景,预读可能导致带宽大幅增加(高达数十倍)。为了解决这个问题,我们引入了预读放大带宽的监控机制。当预读放大过多时,我们建议业务关闭预读配置。需要指出的是,这种情况相对较为极端,在大多数数据场景中,启用预读仍然可以显著提升性能。
-
客户端开销优化:由于我们是通过 Fuse 用户态进程挂载文件系统,会引入额外的开销。如果宿主机挂载了大量卷,可能会导致内存资源的大量占用。因此,我们建议在使用卷的时候提前规划好,可以考虑使用子目录方式代替多卷挂载,以减少内存资源开销。