方法描述
该论文提出了一种名为LightPool的存储池系统，旨在提高云原生分布式数据库集群的存储资源利用率、降低TCO，并提供高性能的存储服务。LightPool采用了NVMe over Fabrics协议来共享存储资源，并且没有数据副本。它通过动态分配存储资源给任意节点的方式来增强存储资源利用率。同时，LightPool还优化了软件栈以减少性能损失。
方法改进
相比于其他分布式存储方案，LightPool有以下改进：
采用NVMe over Fabrics协议：该协议能够充分利用并行性和多个队列的NVMe设备，提供更高的性能。
没有多余的数据副本：与数据库级别的数据可靠性相比，冗余数据副本会增加成本和复杂度。
轻量级存储池架构：专注于高存储性能，尽可能地降低软件堆栈的开销。
解决的问题
该论文主要解决了以下问题：
存储资源利用率低：在现有的云计算数据中心中，存储资源利用率往往较低，因为它们通常使用本地存储或独立的存储集群。
成本高昂：由于需要额外的专用存储集群和网络基础设施，存储解决方案的成本很高。
性能瓶颈：由于带宽瓶颈和网络架构等因素，基于存储集群的存储解决方案的性能可能会受到限制。
复杂的软件堆栈：一些分布式存储方案具有复杂的软件堆栈，这可能导致性能损失和故障率增加。
论文实验
本文介绍了作者在LightPool上的实验内容，并通过与其它存储方案的比较来评估其性能表现。具体来说，作者进行了以下实验：
实验设置：使用了4个节点的Kubernetes集群和centos:7 docker镜像，对LightPool进行了部署和测试。
基准线和对照方法：将本地磁盘作为基准线，同时测试了LightPool和不带零拷贝机制的LightPool以及Mayastor等主流云原生存储解决方案。
性能评估：使用FIO生成随机和顺序读写测试用例，评估了不同存储方案的IOPS、带宽和平均延迟等指标。
可扩展性评估：测试了LightPool在1-12个NVMe SSD上的性能表现。
真实世界应用评估：选择RocskDB作为真实世界应用程序，测试了LightPool在该应用程序中的性能表现。
可用性评估：测试了LightPool在热升级和热迁移过程中的I/O暂停时间和数据迁移带宽等指标。
综合以上实验结果，可以得出以下结论：
LightPool能够实现接近本地磁盘的性能表现，且相比Mayastor等主流云原生存储解决方案具有更好的性能表现。
LightPool具有良好的可扩展性，在多个NVMe SSD上仍能保持较高的性能表现。
LightPool在真实世界应用程序中也表现出色，能够提供接近本地磁盘的性能表现。
LightPool具有较好的可用性，能够在热升级和热迁移过程中保持稳定的性能表现。
总之，LightPool作为一种轻量级的用户级别存储引擎，具有较高的性能表现和可用性，适用于不需要多份数据副本但需要高带宽和容量的云工作负载。
文章优点
该论文提出了一种名为LightPool的新型高性能存储池架构，旨在提高云原生分布式数据库集群的资源利用率。该架构通过将计算节点中的存储盘集成到存储池中，并使用NVMe-oF协议统一管理和分配存储资源，从而实现了跨节点共享集群存储资源的目的。作者在阿里云OceanBase集群上部署了LightPool，并取得了显著的效果提升，使得存储资源利用率达到65%，相比之前提高了约25个百分点。此外，该论文还分享了LightPool的设计思路、实现细节以及部署经验，对于其他类似场景下的存储优化具有一定的参考价值。
方法创新点
该论文的主要贡献在于提出了LightPool这一新颖的存储池架构，并将其应用于云原生分布式数据库集群中。与传统的本地存储方案相比，LightPool采用了NVMe-oF协议来实现高速数据传输，同时还采用了轻量级IO栈和零拷贝机制来进一步提升性能表现。此外，该论文还设计了热升级和热迁移机制，以保证系统的高可用性和可靠性。这些创新点为解决存储资源利用率低的问题提供了新的思路和解决方案。
未来展望
随着云计算技术的发展，越来越多的企业开始采用云原生分布式数据库来满足业务需求。然而，在实际应用中，存储资源利用率低仍然是一个普遍存在的问题。因此，如何进一步提高存储资源的利用率，降低存储成本，成为了一个重要的研究方向。基于此，可以考虑以下几个方面的未来研究：
深入研究存储池算法：目前的存储池算法主要集中在资源的动态调度和负载均衡方面，但是还有很多需要探索的地方，例如如何更好地处理不同工作负载之间的冲突，如何根据应用程序的需求自动调整存储池的大小等。
探索更高效的存储协议：NVMe-oF协议是当前最流行的高速存储协议之一，但是在实际应用中仍然存在一些瓶颈，例如网络带宽限制、延迟等问题。因此，可以考虑研究其他更高效的存储协议，如RDMA等。
提高存储系统的可扩展性：随着业务规模的不断扩大，存储系统也需要具备更高的可扩展性。因此，可以考虑研究如何通过增加存储节点或使用多路径访问等方式来提高存储系统的可扩展性。
研究如何更好地保护数据安全：在分布式环境中，数据的安全性是一个非常重要的问题。因此，可以考虑研究如何使用加密技术或其他安全措施来保护数据的安全性。
论文笔记
NVM Express (NVMe) [31] 是一种高性能协议，用于通过PCIe总线访问本地非易失性存储设备。由于其在带宽和延迟方面远远优于HDD和SATA-SSD的性能，NVMe SSD广泛应用于云数据中心以满足对I/O密集型应用程序不断增长的需求。
为了使远程服务器上的NVMe设备能够通过不同的网络结构进行访问，NVMe工作组提出了作为NVMe扩展的NVMe over Fabrics（NVMe-oF） [31] 。NVMe-oF允许访问高吞吐量、低延迟的远程NVMe设备，并实现与本地连接的NVMe SSD相当的性能。它在性能和CPU资源消耗上都优于现有的远程存储协议如iSCSI [17] 。
存储协议选择。LightPool采用NVMe over Fabric作为远程存储协议，以共享节点之间的存储资源。NVMe-oF是实现高性能存储池的最佳选择。与iSCSI相比，NVMe-oF可以充分利用新兴的NVMe设备固有的并行性和多个队列。特别是，在访问NVMe SSD时，iSCSI会遭受高达40％的性能损失，并且需要消耗额外的操作（例如协议转换），从而导致CPU资源消耗增加30％[17]。根据先前的工作[17]报告，NVMe-oF可以提供接近本地连接NVMe SSD的性能。因此，采用NVMe-oF可以在我们的存储池中访问存储资源时最小化开销，以实现高性能。
布线选择。我们选择了TCP而不是RDMA作为NVMe-oF的网络协议，在云数据中心，TCP稳定且不需要硬件支持，因此部署规模较大；相比之下，RDMA有部署规模限制，并需要硬件支持，不能在所有OceanBase集群的所有机器上部署。因此采用TCP可以实现LightPool在现有集群的大规模部署。未来随着硬件的发展，LightPool将支持RDMA。
没有数据副本。LightPool在存储系统级别实现无数据副本，而不是像其他分布式存储方案那样使用多个副本。通常情况下，使用LightPool的云原生分布式数据库会在数据库级别使用多个数据副本，这意味着应用程序将多个副本存储在存储系统中。同时，不必要的数据冗余会导致进一步增加存储成本。另一方面，在存储系统中使用多个副本可能会导致更复杂的软件堆栈设计和性能损失。因此，采用无数据副本方案可以降低存储成本和性能损失。
没有副本？存储常用的不都是有副本的吗？
工作节点上的组件。每个LightPool工作节点运行LightPool元素，包括LightPool Engine、LightPool Agent、CSI驱动程序和LightPool Initiator，如图4所示。LightPool Engine管理每个节点的存储设备。LightPool Agent从LightPool Engine获取存储信息并将其报告给LightPool Controller。当Pod被调度到节点时，CSI驱动程序会通知LightPool Initiator连接到目标工作节点上的LightPool Engine。
存储聚合。在集群的初始阶段，每个工作节点上的LightPool-Agent通过RPC从LightPool-Engine获取可用存储资源的信息。然后，LightPool-Controller收集这些信息并将其存储在一个列表中，在该列表中的每个条目包含一个工作节点的信息。
存储池维护。LightPool-Controller维护一个节点列表，其中包含每个集群节点的工作节点和存储信息。存储信息包括分配给应用程序容器的卷以及所有可用存储资源，分别跟踪所有持久卷（PV）和所有可用存储资源。简而言之，LightPool-Controller可以高效地管理存储池，并通过节点列表调度可用存储资源到应用程序容器。
分配策略。当创建一个新的应用程序容器时，Kubernetes控制平面节点上的LightPool-Controller接收存储要求，并选择一个工作节点作为目标。然后，所选工作节点上的LightPool-Agent为容量分配一定数量的卷，并通知LightPool-Engine等待连接。
它们满足用户的本地/远程偏好和剩余可用容量的比率。最后，选择得分最高的工作节点作为目标工作节点。因此，存储调度器优先从具有较少空闲存储容量的节点分配存储资源以减少碎片化，并且在将来可以为大容量存储分配请求保留单个节点上的足够空间
存储位置由LightPool控制器确定，可以是本地或远程。LightPool中的I/O路径的两种类型如图5所示。涉及I/O路径的关键组件包括应用程序Pod、LightPool Initiator、LightPool Engine和存储设备。在LightPool中，应用程序可以通过NVMe-oF I/O堆栈访问本地和远程工作节点上的存储资源。
远程I/O路径。图5a展示了LightPool中的远程I/O路径。LightPool-Initiator在内核中向应用程序Pod呈现标准NVMe块设备，以访问存储资源，并且应用程序Pod对物理磁盘的位置是未知的。LightPool-Initiator接收应用程序发出的I/O请求并将其通过TCP堆栈（NIC）转发到目标工作节点上的远程用户级LightPool-Engines。LightPool-Engine会将这些请求转换为NVMe命令，并通知物理存储设备获取这些命令。接下来，存储设备获取NVMe命令并将数据读写到LightPool-Engine的数据缓冲区。然后，LightPool-Engine通过TCP将数据发送给LightPool-Initiator。最后，数据被复制到应用程序缓冲区。
本地I/O路径与零拷贝机制。图5b演示了应用程序Pod访问同一工作节点上存储资源的本地I/O路径。我们通过设置IOMMU页表并在I/O请求到达发起者时替换用户缓冲区地址来实现DMA重映射。步骤1和2与远程I/O路径相同。原本，在访问本地磁盘时，I/O请求和数据通过tcp-loopback在LightPool-Initiator和LightPool-Engine之间传输。然而，这个过程涉及两次冗余的数据拷贝，导致性能下降和CPU开销。为了消除上述问题，我们在LightPool中提出了一种新型的零拷贝本地访问运输。对于I/O请求传输，零拷贝运输采用LightPool-Initiator和LightPool-Engine之间的共享内存。LightPool-Initiator将I/O请求转换为NVMe命令，并用注册在IOMMU页表中的IOVA替换用户缓冲区地址。LightPool-Engine接收NVMe命令，将其放入提交队列，并通知物理存储设备获取这些命令。对于数据，我们提出了DMA重映射机制，使本地存储设备可以直接访问应用程序缓冲区。零拷贝运输采用共享内存，消除了用户缓冲区和内核之间的冗余数据拷贝，从而在访问本地存储资源时接近原生性能。
存储服务可用性与存储性能同样重要。为了向容器提供高可用的存储服务，我们设计了LightPool的热升级和热迁移机制，可以分别在不感知应用程序的情况下对LightPool Engine进行升级，并将容器数据迁移到其他节点。
热升级。LightPool Engine是LightPool IO路径上的关键组件之一，需要定期升级以添加新功能并修复错误。因此，我们提出了一种热升级机制来确保LightPool Engine的升级过程不会中断应用程序IO。
当热升级开始时，LightPool Engine首先进入热升级状态，并调用fork系统调用来创建一个子进程，该子进程是新的LightPool Engine版本。这个子进程会等待父进程（旧版LightPool Engine）完成。然后，父进程停止接收I/O请求并等待进程中的请求完成。接下来，它会关闭所有子系统并将自己标记为退出。在此期间，应用程序发送的I/O请求会被阻塞但不会引发错误。当子进程发现父进程已退出后，子进程根据配置文件恢复子系统并重新建立TCP连接与发起者。最后，子进程（新版LightPool Engine）开始处理I/O请求并完成热升级过程。
A 在热迁移开始时，管理员首先在新存储工作节点上创建与旧存储工作节点上的目标子系统相同的NQN和uuid的目标子系统。然后LightPool-Initiator通过多路径连接到新的目标子系统，并将新的连接设置为不可用。
B LightPool-Initiator上的热迁移模块在旧工作节点上启动数据复制多个周期。在第一个周期中，热迁移模块复制所有数据。同时，它使用位图记录每个LBA地址对应的是否被修改（写入或丢弃操作）。在接下来的周期中，热迁移模块将记录在位图中的当前周期复制的修改的数据复制到新的存储工作节点，同时使用一个新的位图记录当前周期的复制修改。最后，如果需要复制的数据可以在3-5秒内完成，则热迁移模块通知LightPool-Initiator暂停提交应用程序请求并进行数据复制。
C 在最后一个数据复制周期后，LightPool-Initiator会通过删除旧连接并启用新连接来切换I/O路径到新存储工作节点的目标子系统。由于多路径保留了用于应用程序容器的/dev/nvme0n1设备，因此热迁移过程避免了由于块设备消失而导致的服务中断和重新挂载操作。
结果，在整个热升级和热迁移过程中，用户可以像往常一样读写数据而不会中断存储服务和IO错误。我们通过这些功能增强了LightPool的可用性。
评论区