云原生存储工具的选型和应用探讨-云原生存储

云原生存储的概念来源于云原生应用，顾名思义：一个应用为了满足云原生特性的要求，其对存储所要求的特性是云原生存储的特性，而满足这些特性的存储方案，可以称其为倾向云原生的存储。

图1

如上图1所示，云原生应用对于存储的要求，可以概括为三方面：

敏捷化需求：可以灵活的将块设备在不同节点进行快速的挂载切换；提供存储服务的问题自动修复能力，减少人为干预；提供更加灵活的卷大小配置能力。
监控需求：提供更细粒度（目录）的监控能力；提供更多维度的监控指标，如读写时延、读写频率、IO分布等指标。
租户隔离需求：让共享文件系统的不同租户之间实现文件系统级别的隔离效果；容器编排层实现基于名词空间、PSP策略的编排隔离能力，保证不同租户从应用部署侧即无法访问其他租户的存储卷服务。

满足以上需求的存储工具，又可以分为以下几类：

以上满足云原生基本要求的存储方案中，公有云存储、商业化的私有云存储的部署位置和成本的限制，无法完全应用在私有云环境，而基于开源架构自建的云存储，可靠性不高，且维护成本高，还无法完全与云原生集群实现一体化运营。所以下文将重点介绍开源的容器化存储方案。

图2

如上图2所示，目前比较主流的开源容器存储解决方案，主要包括：

基于云原生社区重新造轮子--原生方案：基于容器化和k8s的应用场景，单独开发一套比较轻量的分布式存储系统。典型的开源项目有Longhorn、OpenEBS。
移植传统的分布式存储--移植方案：基于传统的分布式存储框架，进行容器化和k8s的编排，移植到k8s集群中部署。典型的开源项目有rook+ceph^[3]、heketi+glusterfs^[4]、minio^[5]。

笔者所在的项目对开源容器存储方案进行初步调研后认为minio仅可以提供对象存储服务，无法进行磁盘挂载，而heketi+gluster的开源项目已停止维护，所以首先将minio和heketi+gluster的方案排除。

Longhorn最早由Rancher社区创建和开发，完全使用容器和微服务实现分布式块存储。Longhorn为每个块设备卷创建一个专用的存储控制器，并在跨多个节点上存储的多个副本同步复制该卷。存储控制器和副本本身使用Kubernetes进行编排。

Longhorn设计有两层：数据平面(data plane)和控制平面(control plane)。Longhorn Engine是存储控制器对应数据平面，Longhorn Manager对应控制平面。

控制引擎：负责在Kubernetes集群中创建和管理卷，并处理来自UI或Kubernetes卷插件的API调用。当Longhorn Manager被要求创建一个卷时，它会在该卷所连接的节点上创建一个Longhorn Engine实例。
数据引擎：始终在与使用Longhorn volume的Pod相同的节点中运行。它跨存储在多个节点上的多个副本同步复制卷。引擎(Engine)和副本(replicas)使用Kubernetes进行编排。

OpenEBS是kubernetes下与容器原生和容器附加存储类型相关的开源项目之一，由CloudByte最早研发，并开源到CNCF。基于GO语言进行开发，通过为每个工作负载指定专用的存储控制器，OpenEBS遵循容器附加存储或CAS的原则，允许操作员和管理员根据工作量动态调整卷的大小。

OpenEbs分为了控制面板和数据面板，其中：

控制面板：包含了节点组件和集群组件两类pod，其中NDM(Node Disk Manager)负责识别和管理每个节点上的磁盘；m-apiserver暴露了存储REST API，并承担了大部分的卷策略处理和管理。Provisioner实现了K8s中PVC同m-apiserver的交互。NDM Operator用户控制NDM的初始化和生命周期管理。
数据面板：分为cStor、Jiva、LocalPV三种不同的pod与业务pod伴生存在。其中Jiva实际上就是使用的Longhorn引擎；而LocalPV就是K8S的本地PV模式，副本无法复制，故障无法转移。

Rook本身并不是一个分布式存储系统，而是利用Kubernetes平台的强大功能，通过Kubernetes Operator为每个存储提供商提供服务。它将分布式存储系统转变为自我管理、自我扩展、自我修复的存储服务。

Ceph是圣克鲁兹加利福尼亚大学的sage weil在2003年开发的，也是他的博士项目的一部分。初始原型是大约4万行c++代码的ceph文件系统，2006年遵循LGPL协议进行开源。

Ceph架构主要有两个核心模块：监视器(MON)、存储器(OSD)。此外还包括了一个基于aws s3的对象存储网关RadosGW；块存储、文件存储相关的系统插件。其中：

Rook+Ceph的组合解决方案是目前比较成熟的一套Ceph容器化部署移植方案，Rook在其中主要完成Ceph集群的初始化和状态挂你、Kubernetes对接的工作，真正的存储业务逻辑都还是由容器化运行的Ceph集群来实现。

在笔者的测试环境依次对以上三个开源容器化存储工具的功能和性能测试情况来看，三者的比较情况如下表1所示：

表1

笔者所在项目综合考虑了三者的优缺点、磁盘性能损耗和维护复杂度后，认为Longhorn不支持条带化的缺点可以通过挂载Linux卷组的方式予以规避，所以最终选择使用Longhorn。

为每个节点安装ISCSI（小型计算机网络接口）守护进程，如果集群节点都已安装，则无需此操作。

yum install -y iscsi-initiator-utils && systemctl enable --now iscsid.

如下图6，将Longhorn仓库添加到rancher应用商店当中，这样就可以在rancher的应用商店列表中看到Longhorn应用了。

图6

如下图7和8，在rancher的应用商店列表中选择Longhorn并安装，就可以在这里预设longhorn的域名、默认路径、默认副本数等。

图7

图8

所有组件安装完成后，通过上一步设定的Longhorn域名，就可以打开主页的UI，进行存储路径、自动备份、劵分配和挂载等操作了。

图9

用户除了通过上图9的页面去创建PVC之外，也可以直接在rancher页面的PVC创建页面中选择使用Longhorn作为StorageClass，如下图10所示。

图10

到这里，就完成了云原生存储工具选型和应用的初步探讨，虽然笔者的项目出于易维护性和成本的考虑最终选择了Longhorn，但Rook+Ceph和OpenEBS两套方案，在特定条件下，还是具备其使用价值的。而有条件的项目，使用共有云或购买商业的私有云存储也都是不错的选项。