移动云RocketMQ云原生消息队列2.0的弹性存储层的设计与实践

作者｜王维，中国移动云能力中心IaaS产品部rpc产品组研发工程师，主要负责消息队列云原生方向的设计与研发工作

胡宗棠，中国移动云能力中心laaS产品部消息队列&rpc团队的负责人，主要负责消息队列、rpc、配置管理等云原生中间件的架构设计与技术研发工作

1.背景介绍

移动云RocketMQ消息队列产品线，基于kubernetes组件和自定义Operator，在完成全面云原生化后，增加诸多云原生特性，比如一键化部署集群、极致弹性扩缩容和业务无感知热升级/热迁移等。同时，云原生化升级也导致RocketMQ面临多项挑战：

• RocketMQ的Broker Pod节点是有状态的服务，在Broker Pod漂移后如何保证写入本地磁盘的消息数据同步迁移；
• 基于（1）的问题，在移动云RocketMQ云原生消息队列 1.0的架构中，我们采用了Ceph/GlusterFS存储方案来解决该问题。但该方案带来的问题是：外部存储系统的引入，不仅增加了部署/运维的人力成本，而且使得消息队列服务架构复杂化；
• RocketMQ消息队列集群的吞吐量受限于磁盘IO读写速率，相较于直接采用宿主机磁盘存储，引入Ceph/GlusterFS或者其他第三方存储系统会直接影响RocketMQ的性能；

基于上述问题，RocketMQ研发团队在移动云RocketMQ云原生消息队列2.0的架构设计中，基于“CSI + LVM”云原生容器存储技术，结合自研的Operator组件，在RocketMQ消息队列具备极致弹性扩缩等云原生特性的同时，能够承载万亿级数据洪峰，为移动云上客户的业务系统提供低延迟、高并发、高可靠的分布式消息队列云服务。

2.概念概述

1.CSI

CSI[1]（Container Storage Interface ）即容器存储接口，是Kubernetes 目前主推的存储扩展方式。该方式为容器编排系统定义了标准的接口，使得开发者可以更灵活方便的将第三方存储系统与容器工作负载集成。

开发者通过实现CSI 规定的RPC接口（CSI Identity、CSI Controller、CSI Node），即下图中Custom Components部分，协同社区提供的辅助Sidecar容器（External Components）,与Kubernetes 核心组件进行交互，从而实现对自定义容器存储的管理。

（图片出处 [2]）

External Components 是一系列由社区Storage sig小组维护的辅助容器，主要包括如下：

​External-provisioner 

用于实现持久卷（PersistentVolume）的创建、删除等功能

External-attacher 

用于实现持久卷的附着、分离功能

External-snapshotter

用于实现持久卷快照、备份恢复功能

External-resizer

用于实现持久卷的扩容缩容功能

Node-driver-registrar

使用kubelet插件机制向所在节点的kubelet注册用户开发的CSI 驱动信息

Livenessprobe

用于辅助用户CSI插件实现健康检查功能​

这些不同功能的Sidecar容器，由开发者根据自己实际需要选择使用。更详细的使用可以查看官方文档[3]

Custom Components 需要开发者自己实现，由三组RPC接口集合组成，来实现对存储卷整个生命周期的管理。

Identity Service负责对外暴露插件信息，开发者实现的存储插件必须实现该操作集,其中GetPluginCapabilities 根据用户实际实现的RPC操作返回对应的集合。

Controller Service包含一些卷的创建，删除、快照等操作。同样的，用户可以根据实际需要的功能选择性实现接口。实现Controller Service的插件可以根据自身实际需要选择不同的部署方式，通常会使用Deployment 部署单个或少量节点。

Node Service包含一些节点管理的接口。其负责需要和宿主机打交道的操作，例如挂载卸载存储卷等操作，通常会以DaemonSet的方式部署。

2.LVM 

LVM （Logical Volume Manager）即逻辑卷管理器，通过将多个物理分区/硬盘从逻辑上组合成一个更大的虚拟硬盘，从而实现对硬盘容量的弹性管理。

（图片出处 [4]）

以下是LVM中的几个概念

PV 物理卷（Physical Volume）

通常对应一个普通分区或硬盘；

VG 卷组（Volume Group）

由若干个物理卷组成，卷组可以动态添加或者移除物理卷；

PE 物理扩展块（Physical Extend）

PE是LVM的最小存储单位，类似文件系统block；

LV 逻辑卷（Logical Volume）

从卷组中分割出部分空间，形成逻辑卷。用户格式化后挂载文件系统使用；

如下以一个实际使用例子列举部分命令

借助LVM，用户可以根据实际业务需求申请逻辑卷，之后同样也可以按需进行扩/缩容，从而可以实现用户对磁盘空间的按需申请、扩容缩容等需求。

3.基于“CSI+LVM”的RocketMQ消息队列容器存储层设计

通过实现CSI规范，同时借助LVM的能力，即可利用宿主机本地磁盘构建出一个简单的容器存储驱动，实现动态创建卷、对卷的扩缩容等功能。此外，为解决Broker Pod漂移带来的问题，我们在创建PV时添加亲和性，使其绑定原来的Node，由于RocketMQ消息队列集群本身就是采用分布式高可用架构。所以，在某些场景中，屏蔽一定的Pod漂移能力，并不会给RocketMQ消息队列的高可用带来什么影响。

上图展示了移动云消息队列存储部分的架构，其中蓝色部分是由我们实现的CSI插件部分

RocketMQ Operator 

遵循Kubernetes 的资源和控制器理念，通过拓展RocketMQ相关资源（CRD），以实现对RocketMQ集群生命周期的管理。

LVolume

用于整个流程管理存储的自定义资源对象（CRD）。

CSI-Controller-Plugin 

主要实现了CreateVolume、DeleteVolume、ControllerExpandVolume接口，负责LVolume的创建等。

CSI-Node-Plugin

主要实现了NodePublishVolume、NodeUnpublishVolume、NodeExpandVolume操作，内部通过调用LVM命令管理LV（逻辑卷）、PV（物理卷）、VG（卷组）资源，通过使用Cgroup 限制卷读写速率。

下面介绍下主要创建流程：

1. 用户发起创建消息队列后会由RocketMQ Operator创建需要的Kubernetes 资源，其中包括指定StorageClassName的PVC、Pod资源；
2. KubeScheduler调度PVC到指定节点后进入到Provision阶段；
3. 0Sidecar容器 External-provisioner监听到PVC后调用同Pod中的ControllerPugin的CreateVolume接口；
4. ControllerPlugin收到CreateVolume进行一些验证后，创建LVolume对象，用于记录需要创建的卷信息，而后返回成功给External-provisioner；
5. External-provisioner根据返回结果创建PV对象,添加节点亲和性,并和PVC进行绑定；
6. 由于我们不需要对卷Attach，故通过设置CSIDriver的AttachRequired属性为false跳过Attach阶段，而后kubeScheduler调度Pod到指定节点后进入mount阶段；
7. Kubelet监听到绑定到自身节点的Pod后调用NodePlugin的NodePublishVolume接口；
8. NodePlugin收到NodePublishVolume请求后通过调用lvm命令创建逻辑卷，并将卷mount到Pod的指定目录；
9. 而后NodePlugin根据LVolume中的相关信息设置Cgroup限制磁盘读写IO速率；
10. 至此主要流程结束；

4.总结

本文介绍了基于“CSI + LVM”云原生容器存储技术及RocketMQ消息队列在容器存储上的设计与实践，其中实现了基于“CSI +LVM”的容器存储，支持本地卷的动态创建、动态扩缩容、磁盘IO速率限制、拓扑支持等基本功能，同时为移动云云原生消息中间件提供了一种采用本地卷作为容器存储方式。

引用链接

1.CSI规范https://github.com/container-storage-interface/spec

2.CSI图片出处https://kingjcy.github.io/post/cloud/paas/base/kubernetes/k8s-store-csi/

3.CS文档https://kubernetes-csi.github.io/docs/introduction.html

4.LVM图片出处https://www.cnblogs.com/fzhelpdesk/p/16189915.html