IEEE HPCA 2024｜LiteIO：高性能、轻量级的存储池化架构

2024 年 3 月 2 日至 3 月 6 日，在英国爱丁堡举行了第 30 届 IEEE 高性能计算机体系结构国际研讨会 HPCA（30th IEEE International Symposium on High-Performance Computer Architecture），HPCA 是计算机体系结构领域的四大顶级会议之一，由阿里云服务器研发团队和蚂蚁数据基础设施与高可用团队合作完成的论文《LightPool: A NVMe-oF-based High-performance and Lightweight Storage Pool Architecture for Cloud-Native Distributed Database 》入选，本届会议共收到 410 篇投稿，最终接受 75 篇，录用率 18.3%。其中提到的 LightPool 就是我们的开源产品 LiteIO。

• 开源项目地址：https://github.com/eosphoros-ai/liteio

论文背景

论文阐述了在云计算背景下，阿里云服务器研发团队和蚂蚁数据基础设施与高可用团队在数据库面临存储的性能、成本、稳定性的多重压力下，以其面向云原生业务快速高效的软硬件融合解决问题的能力，创新性的提出了一种全新的基于云原生的本地存储池化架构，该架构不仅能在性能上能和本地存储媲美，同时融入了云原生架构，解决了本地存储的弹性问题，在业务上能显著的降低业务的存储使用成本，提升存储的资源利用率。

论文解读

分布式数据库面临的存储选择

数据库作为企业关键的 IT 基础设施，承担着存储、访问和分析关键数据的重要任务，它直接关联到运营效率的提升、客户体验的改善，以及数据驱动决策的支持。企业的业务特性对数据库提出了高可用性、高性能和低成本的需求；在此背景下，作为数据库底层支撑的存储服务类型选择显得至关重要。

目前，数据库的三种主要基础架构分别为：

1. 计算存储结合：这种本地存储服务以其高性能、低成本的优势而受到青睐。然而，它可能导致资源调度问题和资源利用率的不均衡，即服务器与业务需求的不匹配可能会造成资源的碎片化，降低了单个服务器资源的使用效率。

2. 计算存储分离（ECS + EBS/S3）：计算存储分离架构利用分布式云存储的能力解决资源碎片问题。尽管如此，分布式存储服务可能会带来较大的爆炸半径（从计算端到存储端的高收敛比）、增加成本（存储层额外的数据副本）和增加延迟（较长的 I/O 链路）。这一架构适用于中小规模业务，但对于那些对集群规模、I/O 性能、吞吐量和成本敏感的大型业务来说，可能并不合适。

3. 共享存储架构（例如 PolarStore、Aurora、Oracle RAC）：共享存储架构能够有效解决上述问题，通过与存储产品内核深度集成的共享分布式存储，它能够在降低成本和减少副本的同时提供满意的性能。但是，这种方案的通用性较差，每个存储产品都需要深度定制和优化。

在蚂蚁的业务场景中，整个数据库产品（包括 RDBMS、KV、Doc）的规模非常庞大。我们的目标是在不降低稳定性和性能的前提下，解决当前基于计算存储结合架构中的资源碎片问题，降低成本并提升资源效率。

为了提升资源效率和解决资源碎片问题，最直接且有效的方法是将闲置资源以内销（产品自用）或外销（供其他产品使用）的形式利用起来。分布式存储架构和共享存储架构均能解决这一问题，但在满足大规模和多样化存储需求的通用性和稳定性方面仍有不足。鉴于此，我们开始探索 HPC（High-Performance Computing）高性能存储服务，并设计了 LightPool 存储服务，该服务通过池化所有服务器上的存储资源，在不牺牲稳定性和性能的条件下，显著提高了存储资源的使用效率。

云原生下的本地存储池化架构

LightPool 的集群架构如上图所示，LightPool 的整体架构包含了几个关键设计：

1. 云原生设计，调度机制基于 k8s 设计，标准 CSI 接口，容器化部署；

2. 高性能，轻量化存储引擎，支持本地零拷贝挂载，支持多种存储介质；

3. 基于高性能存储互联协议 NVMe over Fabric，支持 TCP，RDMA，运行在 overlay 网络；

上图集群中包含了不同的 ECS 服务器，其中存储型的 ECS（如 Node 1）搭载了大量的本地 SSD，而计算型的 ECS 如（Node 2 和 Node 3）搭载了少量甚至不搭载本地 SSD。这种服务器的配置在现实中较为常见，源于上层不同的业务因为不同的负载对服务器的需求不同，但是随着服务器数量和业务的变更，后续又往往会考虑不同的业务进行服务器资源的共池来提升资源的使用效率。在这种情况下当业务通过容器在整个资源池进行动态调度和部署的时候，需要同时考虑 CPU，内存，磁盘三个维度的资源，而数据库业务对存储的大容量需求进一步导致了调度的复杂度，使得资源池的资源利用率无法达到较高的水平。LightPool 架构目的就是这种情况下解耦了调度对磁盘的耦合性，使得容器调度主要聚集考虑 CPU 和内存，磁盘可以通过弹性的方式进行挂载，从而解决资源利用的问题。

LightPool 集群角色分为控制节点和工作节点：

1. 控制节点，负责集群所有 SSD 的池化管理，SSD 资源的分配和回收的管控，控制节点融入了 k8s 管控框架，通过资源调度器的方式和 k8s 的 master 服务进行交互，和 k8s master 节点部署在一起，控制节点只会在容器申请 / 释放存储资源的时候介入，而在 IO 的正常读写阶段，控制节点被 bypass，IO 的读写只会在工作节点之间交互。

2. 工作节点，运行了业务的容器，同时部署了 LightPool 的存储引擎以及 CSI 插件，存储引擎负责接管工作节点上的所有本地存储资源，CSI 插件等负责容器申请到的存储资源的挂载。在控制节点完成容器存储资源的分配后，容器所在的工作节点和存储资源所在的工作节点之间通过 NVMe over Fabric 高性能存储协议互联，实现了本地存储的弹性。

该架构和传统的分布式存储相比，没有元数据服务器的单点瓶颈，因此爆炸半径大大缩小，在实际业务中，同时其轻量化的存储引擎和互联协议的设计使得整个存储部署非常轻量化，对集群的资源消耗非常小，最后 LightPool 存储服务本身也可以通过容器进行部署，从而真正实现了云原生的设计。

云原生调度设计

集群控制平面节点上的 Controller 和 Agent 是 LightPool 的核心组件。Controller 管理存储资源，并从存储池中分配存储卷。Controller 维护集群中所有存储资源的整体视图，并根据工作节点的请求分配存储卷。存储调度器采用调度策略，识别具有足够自由存储空间的目标工作节点，以满足请求的存储容量。

随后，卷管理器通知目标工作节点创建具有指定容量的自由卷。最后，发起请求的工作节点上的 kubelet 通过 NVMe-oF 连接调用 CSI 驱动程序中的实现调用，与目标工作节点上相应卷建立连接。

Agent 安装在每个后端节点上，除了管理该节点上的存储资源以外，还需要配合调度器，上报所在后端节点的健康状态。维持 Agent 心跳是十分必要的，因为当节点发生严重故障时，需要有机制可以让中心调度器感知到节点故障，从而让节点变为不可调度。

LightPool 参考了 K8S Node 的心跳机制，复用了 Lease 对象，用于记录心跳。Agent 端负责更新 Lease 对象的 RenewTime, Controller 端负责检测这个心跳是否超时，如果超时则认为这个节点对应的 StoragePool 不可调度。StoragePool 生命周期和 K8S Node 绑定，Node 被下线后，StoragePool 也会联动标记下线。

Controller 调度器需要预先把集群中资源加载到内存中，预加载过程通过 EventHandler 实现，确保先加载完成才能提供调度服务。

调度过程参考了 Pod 的调度流程，先经过一系列 Filter 过滤符合条件的节点，再经过计算 Priority 打分，挑选比较合适的节点。默认的过滤器包含：

• 基本过滤器, 根据 StoragePool 状态，剩余资源，卷的 PositionAdvice 参数等进行过滤

• 亲和过滤器, 根据 Node 或者 Pool 的标签亲和进行过滤

LightPool 支持在代码中自定义过滤器，通过配置确定是否启用和过滤顺序。

默认的 Priority 有 优先使用资源较少的节点，根据 PositionAdvice 参数判断优先性。

因为需要考虑本地盘调度，LightPool 提供了两种方案去实现保证本地盘调度正确性，一种是 更新 K8S Node 的扩展资源，表示本地存储资源，当节点分配远程盘后，联动减少节点的扩展资源。这种方式在低并发调度时效果较好，不会有太多冲突。

另一种是对接了 K8S 的 Scheduler Framework 把本地存储调度融入 K8S 调度器。每次调度 Pod 时，在绑定调度结果之前，可以在内存中保留预分配的计算和存储资源，这样可以保证调度的正确性。

存储引擎设计

LightPool 存储引擎作为存储系统的核心组件，LightPool 针对存储引擎做了很多创新性的设计：

1. 基于用户态的轻量化设计，用户态的设计思想也在典型的分布式存储中被大量应用，主要考虑性能和稳定性以及可运维性，而在 LightPool 存储引擎中除了考虑上述因素外，还考虑到云原生的环境下存储引擎本身可以通过容器化方式进行部署。

2. 本地零拷贝存储协议，LightPool 架构下所有业务访问存储均需要通过 LightPool 存储引擎，哪怕是业务访问本机的 SSD，在这种情况下本地访问路径因增加了 LightPool 的存储层，当存储需处理高带宽和高 IOPS 时，会对存储引擎产生很大的 CPU 压力，导致延时上升，这使得存储引擎需要预留较多的 CPU 资源， LightPool 创新性的提出了自研的零拷贝存储协议，零拷贝存储协议在本地存储访问时，摒弃了 TCP 传输协议，实现了一个更轻量化的自研存储协议，该协议能实现全路径只处理存储命令，而业务实际的数据会直接在 SSD 硬件和业务 buffer 间传输，避免了使用传统的 NVMe over TCP 在本地挂载时的两次数据拷贝。延时，吞吐性能加大的得到了提升，而 CPU 消耗显著的下降。

3. 多存储介质支持，LightPool 存储引擎对物理存储介质进行了逻辑卷的管理，对外提供了如快照，raid 等功能特性，同时 LightPool 存储引擎还支持混合 SSD 的部署，比如基于 QLC SSD 的缓存优化技术，让业务真正的摆脱了和 SSD 硬件的耦合，更容易进一步通过 QLC 和 ZNS 等存储技术进行持续的降成本。

高可用的设计

蚂蚁数据库业务承接了蚂蚁的核心关键数据服务，其稳定性和可靠性的要求极高，尽管上层如 OceanBase 等分布式数据库上层已经做了多个副本实例的设计，可以在出现故障的时候实现业务的不中断和数据可靠，但是底层的存储故障仍然会导致数据库在某个时间窗口能产生业务抖动。LightPool 为了实现线上业务的 always online，结合业务的需求，设计了两大关键性高可用技术，分别是热升级和热迁移技术。

1. 热升级技术，存储系统作为业务的底层核心基础设施，热升级技术是解决系统迭代升级和稳定性快速修复的一个非常关键的特性，LightPool 的热升级技术相比传统的分布式存储有所不同。一方面，LightPool 不依赖副本技术去实现升级，因为在很多的业务场景 LightPool 就是以单副本的形式进行部署。另一方面，LightPool 在升级的中断时间上做了非常极致的设计，整个存储引擎的热升级时间保持在百 ms 级别，<1s。

2. 热迁移技术，LightPool 在大部分场景作为单副本的存储系统，而由于 LightPool 的存储池化设计并未像传统的分布式存储，将所有的存储资源视做一个磁盘，其不同的工作节点间的存储资源是独立的分配，为了解决在部分极端场景下，存储的分配出现了不均衡或者运维的需要，比如某个工作节点出现了故障和异常，需要迁移数据，热迁移技术可以使得业务不中断的情况下，将后端的存储从一个工作节点迁移到另外一个工作节点，如上图所示。

加入我们

你是否正在考虑降本增效的 FinOps 项目？你是否也在考虑通用存储计算分离架构设计？你是否也是存储技术的爱好者？欢迎你参与 LiteIO 开源社区，我们期待你的加入。

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