关于云计算:在云原生场景下构建企业级存储方案

随着云原生技术日益遍及的明天，在 Kubernetes 上运行无状态利用曾经十分成熟，平滑扩大能力也很强，但对于有状态的利用，数据须要长久化存储，这还有很大晋升的空间，面临着很多挑战。

上图是 CNCF 对于“在应用 / 部署容器的过程中遇到的挑战”做出的调查报告。依据报告的后果，能够总结出云原生存储遇到的挑战体现在以下几个方面：

易用性：存储服务部署、运维简单，云原生化水平低，短少与支流编排平台整合
高性能：大量利用 IO 拜访，IOPS 需要高，低时延，性能成为利用运行效率瓶颈
高可用：云原生存储曾经利用到生产环境，须要高牢靠 / 高可用，不能呈现单点故障
敏捷性：PV 疾速创立、销毁、平滑的扩大 / 膨胀，PV 随 Pod 迁徙而疾速迁徙等

Rook-Ceph：Rook-Ceph 是一个能够提供 Ceph 集群治理能力的 Operator，应用底层云原生容器治理，调度和编排平台提供的性能来执行其职责。

OpenEBS：OpenEBS 存储控制器自身就运行在容器中。OpenEBS Volume 由一个或多个以微服务形式运行的容器组成。

1. 与云原生编排零碎的交融，具备很好的容器数据卷接入能力；
2. 齐全开源，社区较为沉闷，网络资源、应用材料丰盛，容易动手；

Rook-Ceph 有余：

性能差：IO 性能、吞吐、时延等方面都体现欠佳，很难利用在高性能服务场景；
保护老本高：尽管部署、入门简略，但组件多，架构简单，排错艰难，一旦运行中呈现问题解决起来十分辣手，须要有很强的技术团队加以保障；

OpenEBS-hostpath 有余：没有高可用性能，单点故障；
OpenEBS-zfs-localpv 有余：在磁盘上装置 zfs，而后在 zfs 上创立 vol，也是没有高可用性能；

因而多在企业内部测试环境，很少用于长久化要害利用数据，部署到生产环境中；

NeonIO 是一款反对容器化部署的企业级分布式块存储系统，可能给 Kubernetes 平台上提供动态创建（Dynamic Provisioning) 长久存储卷（Persistent Volume) 的能力, 反对 Clone、Snapshot、Restore、Resize 等性能，NeonIO 的结构图如下：

NeonIO 包含的服务组件如下：

zk/etcd: 提供集群发现、分布式协调、选 master 等服务
mysql：提供元数据存储服务，如 PV 存储卷的元数据
center：提供逻辑治理服务，如创立 PV 卷，快照
monitor: 提供监控服务，可能把采集监控指标裸露给 Promethus
store：存储服务，解决利用 IO 的性能
portal：提供 UI 界面服务
CSI：提供 csi 的规范 IO 接入服务

上面从以下几个方面来看 NeonIO 为什么适宜云原生存储：

组件容器化：服务组件、CSI、Portal 容器化
反对 CSI：提供规范的 IO 接入能力，可动态、动态创建 PV
UI 界面，运维不便：
- 存储运维操作界面化、告警、监控可视治理；
- 有基于 PV 粒度的性能监控，如 IOPS、吞吐量，能够疾速定位到热点 PV；
- 有基于 PV 粒度的 Qos，可能保障用户高优先级的服务质量；

与云原生高度交融：
- 反对 Promethus，通过 ServiceMonitor 把 NeonIO 的采集指标裸露给 Promethus、Grafana，进行图形化展现
- 同时 UI 界面可与 Promethus 对接，展现其余云原生监控的指标，如 node-exporter 的磁盘 IO 负载、带宽等
- 平台化的运维形式，存储的扩容、降级、劫难复原运维操作、只须要 Kubernetes 的一些命令即可实现，不须要额定把握过多的存储相干的运维常识
- 服务发现、分布式协调反对 etcd、元数据的治理，应用 CRD 的形式
一键式部署：：helm install neonio ./neonio --namespace kube-system

部署简略灵便：和 Rook-Ceph 比照：

性能	NeonIO	Rook-Ceph
节点布局部署	通过对对应节点打 label	通过批改 cluster.yaml，须要配置节点 IP 配置那些服务
Quick Start	总共 4 步: 1. 查看确保有可给供 neonio 的设施； 2. 查看是否曾经装置 QBD； 3. 增加 helm repo； 4. 装置部署：helm install neonio ./neonio –namespace kube-system	总共 5 步 1. 查看确保有可给供 ceph 的设施； 2. 查看是否曾经装置 RBD； 3.apt-get install -y lvm2 4. 下载代码：git clone –single-branch –branch master https://github.com/rook/rook.git 5.cd rook/cluster/examples/kubernetes/ceph kubectl create -f crds.yaml -f common.yaml -f operator.yaml kubectl create -f cluster.yaml
单机 all-in-one	helm install neonio ./neonio –namespace kube-system –set sc.rep_count=1 –set center.servers=1 —	cd rook/cluster/examples/kubernetes/ceph kubectl create -f crds.yaml -f common.yaml -f operator.yaml kubectl create -f cluster-test.yaml 应用区别与集群部署时的另一个配置 cluster-test.yaml 进行部署，不能做到配置共用
RDMA/TCP	helm install neonio ./neonio –namespace kube-system –set store.type=RDMA	ceph 自身反对 RDMA，rook-ceph 不反对
治理、存储网络拆散 / 共有	helm install neonio ./neonio –namespace kube-system –set store.port=eth0 –set rep_port.port=eth1	ceph 自身 pubic、cluster 网口的拆散专用，rook-ceph 适配简单

性能单 PV IOPS 100K，时延亚毫秒。

全闪的分布式存储架构
- 集群中所有节点独特承当压力，IO 性能随着节点减少而线性增长
- 存储介质反对 NVME SSD
- 反对 RDMA：通过高速的 RDMA 技术将节点连贯
极短的 IO 门路：摈弃文件系统，自研元数据管理系统，使 IO 门路极短

应用 HostNetwork 网络模式

益处：

Store CSI Pod 应用 HostNetwork，间接应用物理网络，缩小网络档次
管理网络、前端网络、数据同步网络拆散，防止网络竞争；

服务组件可靠性与可用性
- 治理服务默认应用 3 正本 Pod, 正本数能够配置，举荐应用 3/5 正本，任何一 Pod 因故障无奈提供服务，还有其余 Pod 提供服务
- 应用探针检测 Pod 服务是否可用，是否存活，检测到 Pod 服务部可用剔除组件服务，检测到 Pod 死掉后重启 Pod，使其重新启动服务
数据的可靠性与可用性

Volume 分片为 Shard
每个 Shard 独立抉择存储地位
每个 Shard 的 3 个正本存储在不同的物理节点上
写入时同步写入 3 个正本，强统一
读取时只从主正本读
正本数按 volume 可配

Pod 跨节点重建高效：2000PV 的挂载 / 卸载 16s
批量创立 PV 能力：2000PV 的创立 5min

Teststand: NeonIO hyper-converged all-in-one cluster (3 nodes, 192.168.101.174 – 192.168.101.176)

Note: All tests use NVMe SSDs. Volume size = 1TiB. Performance tool: https://github.com/leeliu/dbench

图中黄色示意的是 NeonIO，第一张图纵坐标是 IOPS，第二张图纵坐标是毫秒，从后果来看，无论是单正本还是 3 正本，NeonIO 在 IOPS、时延都有显著的劣势。

Devops 场景：批量疾速创立 / 销毁 PV 能力，2000PV 创立 5min
数据库场景：WEB 网站后端数据库 MySQL 等提供稳固的长久化存储，提供高 IOPS、低时延
大数据利用剖析场景：提供超大容量，PV 可扩容到 100TB

本文由博客一文多发平台 OpenWrite 公布！

关于云计算:在云原生场景下构建企业级存储方案

引言

云原生存储的挑战

常见云原生存储解决方案

劣势

劣势

NeonIO 为什么适宜云原生存储

NeonIO 简介

易用性

高性能

高可用

敏捷性

NeonIO 性能体现

NeonIO 利用场景