【阅读原文】戳：IEEE HPCA 2024｜LightPool：高性能、轻量级的存储池化架构
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%。
论文背景
论文阐述了在云计算背景下，阿里云基础设施服务器研发团队和蚂蚁数据基础设施与高可用团队在数据库面临存储的性能、成本、稳定性的多重压力下，以其面向云原生业务快速高效的软硬件融合解决问题的能力，创新性的提出了一种全新的基于云原生的本地存储池化架构，该架构不仅能在性能上能和本地存储媲美，同时融入了云原生架构，解决了本地存储的弹性问题，在业务上能显著的降低业务的存储使用成本，提升存储的资源利用率。
论文解读
分布式数据库面临的存储选择
数据库作为企业关键的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的存储池化设计并未像传统的分布式存储，将所有的存储资源视做一个磁盘，其不同的工作节点间的存储资源是独立的分配，为了解决在部分极端场景下，存储的分配出现了不均衡或者运维的需要，比如某个工作节点出现了故障和异常，需要迁移数据，热迁移技术可以使得业务不中断的情况下，将后端的存储从一个工作节点迁移到另外一个工作节点，如上图所示。
展望未来
近年来，阿里云服务器研发团队在基础技术研究领域迈出了坚实且创新的步伐，连续5年在HPCA/ISCA/MICRO三大体系结构顶会上展现卓越的科研实力，屡获佳绩。特别是在数据中心算力资源利用率和稳定性提升、软硬件融合高性能卸载，以及Chiplet软件生态建设等方面取得优异的成果，持续构筑飞天操作系统最结实的硬件基础设施底座。
未来，面向大内存计算时代和AI算力需求爆炸的场景；阿里云将持续围绕基于CXL的新型计算架构创新，结合云计算基础设施的规模效益，将基础研究成果转化为工程实践的能力，为客户和整个行业提供更高效、更优质的云服务解决方案。
我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。
