openebs
1. 简介
OpenEBS是一款使用Go语言编写的基于容器的块存储开源软件。OpenEBS使得在容器中运行关键性任务和需要数据持久化的负载变得更可靠。
OpenEBS是一组存储引擎，允许您为有状态工作负载(StatefulSet)和Kubernetes平台类型选择正确的存储解决方案。 在高层次上，OpenEBS支持两大类卷——本地卷和复制卷
OpenEBS是Kubernetes本地超融合存储解决方案，它管理节点可用的本地存储，并为有状态工作负载提供本地或高可用的分布式持久卷。
1.1 两大类卷
OpenEBS管理k8s节点上存储，并为k8s有状态负载（StatefulSet）提供本地存储卷或分布式存储卷。
-
本地卷（
Local Storage）OpenEBS可以使用宿主机裸块设备或分区，或者使用Hostpaths上的子目录，或者使用LVM、ZFS来创建持久化卷- 本地卷直接挂载到
Stateful Pod中，而不需要OpenEBS在数据路径中增加任何开销 OpenEBS为本地卷提供了额外的工具，用于监控、备份/恢复、灾难恢复、由ZFS或LVM支持的快照等
-
对于分布式卷(即复制卷)
OpenEBS使用其中一个引擎(Mayastor、cStor或Jiva)为每个分布式持久卷创建微服务- 有状态
Pod将数据写入OpenEBS引擎，OpenEBS引擎将数据同步复制到集群中的多个节点。OpenEBS引擎本身作为pod部署，并由Kubernetes进行协调。 当运行Stateful Pod的节点失败时，Pod将被重新调度到集群中的另一个节点，OpenEBS将使用其他节点上的可用数据副本提供对数据的访问 - 有状态的
Pods使用iSCSI(cStor和Jiva)或NVMeoF(Mayastor)连接OpenEBS分布式持久卷 OpenEBS cStor和Jiva专注于存储的易用性和持久性。它们分别使用自定义版本的ZFS和Longhorn技术将数据写入存储。OpenEBS Mayastor是最新开发的以耐久性和性能为设计目标的引擎，高效地管理计算(大页面、核心)和存储(NVMe Drives)，以提供快速分布式块存储
1.2 与传统分布式存储对比
OpenEBS与其他传统存储解决方案不同的几个关键方面:
- 使用微服务体系结构构建，就像它所服务的应用程序一样。
OpenEBS本身作为一组容器部署在Kubernetes工作节点上。使用Kubernetes本身来编排和管理OpenEBS组件 - 完全建立在用户空间，使其高度可移植性，以运行在任何操作系统/平台。
- 完全意图驱动，继承了
Kubernetes易用性的相同原则 OpenEBS支持一系列存储引擎，因此开发人员可以部署适合于其应用程序设计目标的存储技术。
1.3 使用场景
| 应用需求 | 存储类型 | OpenEBS卷类型 |
|---|---|---|
| 低时延、高可用性、同步复制、快照、克隆、精简配置 | SSD/云存储卷 | OpenEBS Mayastor |
| 高可用性、同步复制、快照、克隆、精简配置 | 机械/SSD/云存储卷 | OpenEBS cStor |
| 高可用性、同步复制、精简配置 | 主机路径或外部挂载存储 | OpenEBS Jiva |
| 低时延、本地PV | 主机路径或外部挂载存储 | Dynamic Local PV - Hostpath, Dynamic Local PV - Rawfile |
| 低时延、本地PV | 本地机械/SSD/云存储卷等块设备 | Dynamic Local PV - Device |
| 低延迟，本地PV，快照，克隆 | 本地机械/SSD/云存储卷等块设备 | OpenEBS Dynamic Local PV - ZFS , OpenEBS Dynamic Local PV - LVM |
总的来说：
- 多机环境，如果有额外的块设备（非系统盘块设备）作为数据盘，选用
OpenEBS Mayastor、OpenEBS cStor - 多机环境，如果没有额外的块设备（非系统盘块设备）作为数据盘，仅单块系统盘块设备，选用
OpenEBS Jiva - 单机环境，建议本地路径
Dynamic Local PV - Hostpath, Dynamic Local PV - Rawfile，由于单机多用于测试环境，数据可靠性要求较低。
1.4 CAS介绍
OpenEBS是一个容器附加存储(Container Attached Storage, CAS)的例子。
如上图所示 ，Container Attached Storage是包含由Kubernetes编排的、基于微服务的存储控制器的软件。这些存储控制器可以在Kubernetes运行的任何地方运行，即任何云甚至裸机服务器，或者传统共享存储系统之上，数据本身也通过容器访问。
CAS使您能够利用云原生应用程序的灵活性和可伸缩性。 定义Kubernetes PV (Persistent Volume)的存储软件是基于微服务架构的。 存储软件的控制平面(存储控制器)和数据平面(存储副本)作为Kubernetes Pods运行，因此，使您能够将云原生的所有优势应用到CAS。
CAS优势
- 敏捷
CAS中的每个存储卷都有一个容器化的存储控制器和相应的容器化副本。 因此，围绕这些组件的资源的维护和调优是真正敏捷的。 Kubernetes滚动升级功能可以实现存储控制器和存储副本的无缝升级。可以使用容器cGroups调优CPU和内存等资源配额。
- 存储策略粒度化
将存储软件容器化并将存储控制器专用于每个卷可以带来最大的存储策略粒度。 在CAS体系结构中，可以按卷配置所有存储策略。 此外，您可以监视每个卷的存储参数，并动态更新存储策略，以实现每个工作负载的预期结果。 随着卷存储策略中这种额外粒度级别的增加，存储吞吐量、IOPS和延迟的控制也会增加。
- 云原生
CAS将存储软件装入容器，并使用Kubernetes自定义资源定义(CRDs)来声明低级存储资源，如磁盘和存储池。 这个模型使存储能够无缝地集成到其他云原生工具中。 可以使用Prometheus、Grafana、Fluentd、Weavescope、Jaeger等云原生工具来供应、监控和管理存储资源
PV是CAS中的一个微服务
如上图所示，在CAS架构中，存储控制器和副本的软件完全是基于微服务的，因此不涉及内核组件。 通常，存储控制器POD被调度在与持久卷相同的节点上，以提高效率，副本POD可以被调度在集群节点上的任何位置。 每个副本使用本地磁盘、SAN磁盘和云磁盘的任意组合完全独立于其他副本进行配置。 这为大规模管理工作负载的存储分配提供了巨大的灵活性。
- 超融合非分布式
CAS架构没有遵循典型分布式存储架构。通过从存储控制器到存储副本的同步复制，存储变得高度可用。 卷副本的元数据不是在节点之间共享的，而是在每个本地节点上独立管理。 如果一个节点故障，存储控制器(在本例中是一个无状态容器)将在一个节点上轮转，该节点上运行着第二个或第三个副本，数据仍然可用。
与超融合系统类似，CAS中的卷的存储和性能是可扩展的。由于每个卷都有自己的存储控制器，因此存储可以在一个节点的存储容量允许的范围内进行扩展。 在给定的Kubernetes集群中，随着容器应用程序数量的增加，会增加更多的节点，从而提高存储容量和性能的整体可用性，从而使存储对新的应用程序容器可用。 这一过程与Nutanix等成功的超融合系统非常相似。
2. 架构
OpenESB遵循容器附加存储（CAS）模型，每个卷都有一个专用的控制器POD和一组副本POD。 OpenEBS操作和使用都很简单，因为它看起来和感觉上就像其他云原生和Kubernetes友好的项目。
OpenEBS有许多组件，可以分为以下类别:
-
控制面组件 -
Provisioner,API Server,volume exports,volume sidecars -
数据面组件 -
Jiva、cStor -
节点磁盘管理器 -
Discover,monitor, 管理连接k8s的媒介2.1 控制面
OpenEBS集群的控制平面通常被称为MayaOpenEBS控制平面负责提供卷、相关的卷操作，如快照、克隆、创建存储策略、执行存储策略、导出Prometheus/grafana使用的卷指标，等等。
2.1.1 OpenEBS PV Provisioner
此组件作为POD运行，并做出配置决策,它的使用方式是:
开发人员用所需的卷参数构造一个声明，选择适当的存储类，并在YAML规范上调用kubelet。 OpenEBS PV动态提供程序与maya-apiserver交互，在适当的节点上为卷控制器pod和卷副本pod创建部署规范。 可以使用PVC规范中的注释来控制卷Pod(控制器/副本)的调度。
目前，OpenEBS Provisioner只支持一种绑定类型，即iSCSI。
2.1.2 OpenEBS PV Provisioner
m-apiserver作为POD运行。顾名思义，m-apiserver公开OpenEBS REST api
m-apiserver还负责创建创建卷pod所需的部署规范文件。 在生成这些规范文件之后，它将调用kube-apiserver来相应地调度这些pods。
m-apiserver的另一个重要任务是卷策略管理。OpenEBS为表示策略提供了非常细粒度的规范。 m-apiserver解释这些YAML规范，将它们转换为可执行的组件，并通过容量管理sidecar来执行它们
Maya卷导出器是每个存储控制器pod的sidecar`
这些sidecar将控制平面连接到数据平面以获取统计信息。统计信息的粒度在卷级别。一些统计数据示例如下：
- 卷读取延迟
- 卷写入延迟
- 卷每秒读取速度
- 卷每秒写入速度
- 读取块大小
- 写入块大小
- 容量统计
2.1.4 卷管理
sidecar
Sidecars还用于将控制器配置参数和卷策略传递给卷控制器pod(卷控制器pod是一个数据平面)， 并将副本配置参数和副本数据保护参数传递给卷副本pod。
2.2 数据面
OpenEBS数据平面负责实际的卷IO路径。存储引擎在数据平面实现实际的IO路径。 目前，OpenEBS提供了两个可以轻松插入的存储引擎。它们被称为Jiva和cStor。 这两个存储引擎都完全运行在Linux用户空间中，并基于微服务架构。
-
Jiva
Jiva存储引擎基于Rancher's LongHorn与gotgt开发实现， 使用go语言开发，并运行于用户命名空间下。LongHorn控制器将输入的IO同步复制到LongHorn副本。该副本将Linux稀疏文件视为构建存储特性(如精简配置、快照、重建等)的基础。 -
cStor
cStor数据引擎使用C语言编写，具有高性能的iSCSI target和Copy-On-Write块系统，提供数据完整性、数据弹性和时间点的快照和克隆。cStor有一个池特性，它以条带、镜像或RAIDZ模式聚合一个节点上的磁盘，以提供更大的容量和性能单位。cStor还可以跨区域将数据同步复制到多个节点，从而避免节点丢失或节点重启导致数据不可用。 -
LocalPV
对于那些不需要存储级复制的应用程序，LocalPV可能是很好的选择，因为它能提供更高的性能。 OpenEBS LocalPV与Kubernetes LocalPV类似，不同之处在于它是由OpenEBS控制平面动态提供的， 就像任何其他常规PV一样。
OpenEBS LocalPV有两种类型:hostpath LocalPV和device LocalPV。 hostpath LocalPV指的是主机上的子目录，LocalPV指的是在节点上发现的磁盘(可以是直接连接的，也可以是网络连接的)。 OpenEBS引入了一个LocalPV提供者，用于根据PVC和存储类规范中的一些标准选择匹配的磁盘或主机路径。
2.3 节点磁盘管理器
节点磁盘管理器(NDM)是OpenEBS体系结构中的一个重要组件。 NDM将块设备视为需要监视和管理的资源，就像CPU、内存和网络等其他资源一样。 它是一个在每个节点上运行的守护进程，基于过滤器检测附加的块设备，并将它们作为块设备自定义资源加载到Kubernetes中。这些定制资源旨在通过提供类似于:
- 轻松访问
Kubernetes集群中可用的块设备清单 - 预测磁盘的故障，以帮助采取预防措施
- 允许动态地将磁盘挂载/卸载到存储
Pod中，而无需重新启动在磁盘挂载/卸载的节点上运行的相应NDM Pod
尽管做了上述所有工作，NDM还是有助于提供持久卷的总体简化。
NDM是在OpenEBS安装期间作为守护进程部署的。NDM daemonset发现每个节点上的磁盘，并创建一个名为Block Device或BD的自定义资源。