小米作为寰球出名的科技巨头公司，曾经在数百款产品中广泛应用了 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 用户态过程挂载文件系统，会引入额定的开销。如果宿主机挂载了大量卷，可能会导致内存资源的大量占用。因而，咱们倡议在应用卷的时候提前布局好，能够思考应用子目录形式代替多卷挂载，以缩小内存资源开销。