蚂蚁集团去中心化的高性能存储服务 LiteIO 正式开源

在传统分布式存储盛行的时代，LiteIO 作为点对点块设备服务的代表作，在蚂蚁集团内部实践中，带来了极大的业务与技术收益。并在近期由阿里云软硬件结合研发团队与蚂蚁集团数据库技术团队联合撰写的论文《LightPool: A NVMe-oF-based High-performance and Lightweight Storage Pool Architecture for Cloud-Native Distributed Database 》，被 HPCA‘24 论文评审结果收录，CCF-A 类论文也肯定了 LiteIO 的技术先进性。趁着这个机会，我们非常荣幸的宣布蚂蚁集团去中心化的高性能存储服务 LiteIO 正式开源。将我们的技术与全世界的开发者共享，激发更多的创意和想法，我们相信，对于数据库、存储产品类有状态的、有产品层多副本能力的产品，需要 LiteIO 这样的点对点技术来适配当下的 FinOps。

我们希望吸引更多社区的想法，只有通过开放和协作，LiteIO 才能够迎接更多的挑战，解决更多的问题，并为用户带来更多的价值，让 LiteIO 项目走得更远，成为云原生时代，存储使用的一种标准范式。

开源项目仓库：
https://github.com/eosphoros-ai/liteio

LiteIO 是一款高性能、易扩展的云原生块设备服务，专为超融合架构下的 Kubernetes 设计。在蚂蚁集团内部孵化 3 年并大规模应用在生产环境，为蚂蚁集团全数据型、存储型产品提供稳定、高效、易扩展的磁盘服务。

LiteIO 是将本地磁盘 / 逻辑卷，通过网络的方式共享给远程其他服务器使用，结合云原生 Kubernetes 的调度，将一系列磁盘统一管理、池化的通用技术。点对点的技术设计，相较传统分布式存储，有效地控制住硬件故障所带来的爆炸半径，同时去除存储冗余，有更多使用空间。

在降本增效的时代，FinOps 显得格外重要，尤其像蚂蚁集团这种存储服务器规模庞大的体系，全局 1% 的存储利用率提升都会带来巨大的成本经济收益。因此需要再成本优化、保证通用性的同时稳定性不降。

数据库是一种重 IO 的软件系统，对于 IO 的稳定性和性能要求极高，一般生产系统都将数据库部署在本地磁盘的服务器上，这将带来两个问题：

• 利用率不均：IO 密集型和计算密集型的 workload 不同，这就会出现一台机器计算用完而存储富裕，亦或者存储用完计算还富裕，且通过调度也很难做到全局最优解。

• 扩展性差：当出现存储不足，需要 scale up 存储，不得不通过迁移的手段换一台更大存储的服务器，拷贝数据的过程长。

传统分布式存储也是一种不错的解决方案，但在数据库领域，它将带来几个方面的问题：

• 副本数上升（成本）：分布式存储的优势在于通过 EC、多副本技术将存储池化，对于单硬件故障有很好的保护，但通过 EC、多副本技术造成单份数据副本在此架构下副本数将大于 1，往往副本数在 1.375~2 之间。数据库作为业务服务重要的组成，往往在上层有异 AZ、异地容灾的要求，在另一个 AZ 已经有数据库层面的备副本。总数据副本数会增加。

• 爆炸半径大（稳定性）：分布式存储一般有一层中心式的 Meta 层，故障将带来全局性异常。

LiteIO 采用去中心化的设计思路，基于 SPDK 数据引擎以及高性能 NVMe-over-Fabric 协议，将计算节点直接连到远程存储节点，通过高效的协议和后端 I/O 轮询，提供接近本地磁盘的高性能。点对点的设计配合 K8S 的调度控制，有效的控制单硬件故障所影响的服务。

基于 LiteIO，可以将服务器中无法分配的存储，按需分给远程计算节点使用，同时全局配合调度，将全局存储池化，从而提升全局的存储利用率。

例如有两种型号的服务器，计算密集型 96C 4T，存储密集型 64C 20T，假设存储机型的 CPU 已经分配完还剩 5T 磁盘，计算机型还有 CPU 但无磁盘可分，使用 LiteIO 可以将计算机型的 CPU + 存储机型的剩余磁盘组合成新的容器提供服务，同时提升了计算、存储利用率。

LiteIO 是一个通用的存储服务技术，作用于存储逻辑卷，配合 K8S 上层容器或应用看到的和本地磁盘无差别，不论是直接读写块设备 bdev 还是将块设备做成任何文件系统均可以，不需要上层服务做任何修改，不论是 OceanBase、MySQL、PostgreSQL 这样的数据库，或者 Java、Python、Go 写的应用服务均可以将它用作一块普通磁盘使用。

LiteIO 的通用的存储计算分离能力，使得 Scale 变得无比简单。配合感知与调度系统，部署一个 MySQL 实例就天然具备了 Serveless 能力。当 MySQL 的算力不够时，通过 LiteIO 将 MySQL 存储挂到一台更大算力的容器即可快速完成 scale up。当 MySQL 存储空间不足时，从其他存储节点挂一块磁盘即可完成无损扩容。

LitelO 使用 NVMe-oF 协议来提升性能，NVME-oF 协议可以充分利用新兴 NVMe 设备的固有并行性和多队列功能。而 iSCSI 在访问 NVMe SSD 时，性能损失高达 40％，并在协议转换等其他操作时也会消耗多于 30％的 CPU 资源。NVMe-oF 在性能方面优于 iSCSI，可以提供接近本地连接的 NVMe SSD 的性能。因此，在 LiteIO 中采用 NVMe-oF 可以最大程度地减少访问存储池中的存储资源时的开销，以提供接近原生磁盘的高性能。LiteIO 采用了 NVMe over Fabric（TCP）作为远程存储协议，以便集群中的其他节点访问存储资源。

传统分布式存储架构下，一个 Write IO 需要经过查询元数据、写元数据、写多副本数据三个过程，整个过程需要多次网络交互；而在 LitelO 架构下，由于单副本机制，点对点访问，前端 bdev 和后端 vol 一一映射，不需要额外的 rootserver 或者 metaserver 来管理全局元数据，IO 链路中只有一次跨网络访问，同时也不需要考虑多副本写带来的数据传输延迟，数据放大的问题，使得 LitelO 有更高的 IO 吞吐和更低的 IO 延迟

在访问本地磁盘时，I/O 请求和数据在 NoF-Initiator 和 NoF-Engine 之间通过 tcp-loopback 传输，但是这个过程涉及许多冗余的数据拷贝。为了消除这些拷贝并减少 CPU 开销，我们提出了一种新颖的零拷贝传输方式，用于 LiteIO 的本地访问。对于 I/O 请求，零拷贝传输采用 NoF-Initiator 和 NoF-Engine 之间的共享内存。对于数据，我们提出了一种 DMA 重映射机制，使本地存储设备可以直接访问应用程序缓冲区。零拷贝传输抛弃了 TCP 堆栈，并消除了用户缓冲区和内核之间的冗余数据拷贝，实现了访问本地存储资源时接近本地性能的效果。

充分考虑到作为数据链路上的关键一环的 LiteIO 也会面临功能升级，我们实现了在升级 LiteIO 的过程中，让前端业务无感，IO 短时间抖动（<100ms），同时机头挂载的 nvme 盘符不会发生改变。

Target 整体框架如下图所示，在热升级期间必须保持 nvmf 的网络连接不可中断，否则 host 侧会感知并去重连或者删除盘符，热升级采用旧的 target 程序 fork 新的 target 程序并加载新的二进制文件来实现，整个热升级过程中 IO 不可丢失，新旧进程的切换速度要快。基于热升级框架的简单性设计原则，热升期间下图中绿色的 TCP 或 RDMA 连接为必须保持的上下文，其他模块均无需保存上下文状态，网络连接的保持通过父子进程继承文件描述符的方式实现。

卷热迁移特性是为了在不影响业务的情况下，将卷的数据从原 Target 迁移到新的 Target，当迁移完成时由 Host 端完成链路的切换，从而实现业务无感切换到新的 Target。

热迁移过程中，将原 Target 的数据发送到新 Target 采用的方法是多轮循环迭代。每一轮开始前都会从卷获取一份 data map，然后根据这个 map 进行数据的拷贝。初始轮可能需要拷贝较多的数据，后续每一轮只需要拷贝上一轮迁移过程中新修改（write, discard）的数据。在保证迁移带宽大于新写入数据带宽的前提下，经过多轮拷贝后原 Target 和新 Target 之间的数据差异会逐渐缩小，从而可以停 IO 进行最后一轮的拷贝。

LiteIO 对接了 CSI 的 Snapshot 相关的接口，允许用户使用 K8S 社区的 Snapshot 资源对 LiteIO 卷创建快照。快照能力与底层数据引擎有关，LiteIO 支持两种引擎：LVM 和 SPDK。LVM 的快照能力是 VG/LV 提供的， NoF-Engine 的快照能力是 SPDK LVS 提供的。LVM 和 SDPK 都是单机引擎，要求 Snapshot 和 原始 LV 必须在同一台机器，这就意味着，在创建原始 LV 时，就需要预留一定空间给快照，如果没有预留空间，则无法保证创建 Snapshot 一定成功。

LiteIO 对接了 CSI 的 ExpandVolume 相关接口，用户可以通过修改 PVC 磁盘空间，实现磁盘在线扩容。对于 LVM 引擎，LV 扩容无需修改，NoF-Engine 暴露远程盘的流程中新增了 bdev_aio_resize RPC 调用，实现了远程盘的在线扩容。扩容同样有一些限制，原因也和快照一样，由于 LVM, SPDK 都是单机引擎，无法保证单机上有足够空间扩容。

点对点的数据链路模式，不可避免还是会产生一些存储资源碎片。LiteIO 支持将这些碎片组合起来，变为一个卷供业务使用。这也带来一个故障率提升问题，假设提供碎片的任意一个节点故障，则这个卷不可用。内部恰好有这样一个业务 LDG 可以容忍这样的故障率，物尽其用。LDG(logic data guard) 设计旨在构建常态化逻辑主备数据库，提供一站式的主备库生命周期管理和应用使用管控平台，为提升稳定性，减小运维过程中由于升级，维护，意外等产生的数据风险进行规避, 同时提升数据操控的能力。

LitelO 还提供 Thin provisioning 能力，在单机维度实现存储的超卖，适合于像 Mysql 等存储非预填充空间的存储产品使用，Thin provisioning 结合热迁移能力，可以在单机存储空间不足时，快速无缝迁移数据到空间空闲的节点；由于 LitelO 不是分布式存储架构，对 Thin provisioning 功能的使用需要精确控制超卖比例和和超卖资源总量，保障空间不足时能快速迁移，避免业务受损

LiteIO 广泛地应用在蚂蚁集团数万台生产服务器，整体提升了 25% 的存储利用率，极大地优化了资源服务成本。与本地存储相比，LiteIO 带来的额外 IO Latency 仅约为 2.1 us。其通用的存储计算分离架构，不仅服务于数据库产品，同时也为蚂蚁其他计算产品、应用服务提供了存储计算分离以及 Serverless 的能力。配合热升级、热迁移、Kubernetes 生态，使其在日常运维中不增加额外的运维负担。快照、多盘聚合等能力让其有更多灵活的使用与玩法。针对 LiteIO 在蚂蚁集团的最佳实践，后续有系列文章分享，敬请期待。