引言
随着云原生技术日益遍及的明天，在 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 为什么适宜云原生存储
NeonIO 简介
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 为什么适宜云原生存储：
易用性
1. 组件容器化：服务组件、CSI、Portal 容器化
2. 反对 CSI：提供规范的 IO 接入能力，可动态、动态创建 PV
3.UI 界面，运维不便：
存储运维操作界面化、告警、监控可视治理；
有基于 PV 粒度的性能监控，如 IOPS、吞吐量，能够疾速定位到热点 PV；
有基于 PV 粒度的 Qos，可能保障用户高优先级的服务质量。
4. 与云原生高度交融：
反对 Promethus，通过 ServiceMonitor 把 NeonIO 的采集指标裸露给 Promethus、Grafana，进行图形化展现。
同时 UI 界面可与 Promethus 对接，展现其余云原生监控的指标，如 node-exporter 的磁盘 IO 负载、带宽等。
平台化的运维形式，存储的扩容、降级、劫难复原运维操作、只须要 Kubernetes 的一些命令即可实现，不须要额定把握过多的存储相干的运维常识。
服务发现、分布式协调反对 etcd、元数据的治理，应用 CRD 的形式。
5. 一键式部署：：helm install neonio ./neonio –namespace kube-system
6. 和 Rook-Ceph 比照，部署简略灵便：
高性能
性能单 PV IOPS 100K，时延亚毫秒。
1. 全闪的分布式存储架构
集群中所有节点独特承当压力，IO 性能随着节点减少而线性增长。
存储介质反对 NVME SSD。
反对 RDMA：通过高速的 RDMA 技术将节点连贯。
2. 极短的 IO 门路：摈弃文件系统，自研元数据管理系统，使 IO 门路极短。
3. 应用 HostNetwork 网络模式
益处：
Store CSI Pod 应用 HostNetwork，间接应用物理网络，缩小网络档次
管理网络、前端网络、数据同步网络拆散，防止网络竞争；
高可用
1. 服务组件可靠性与可用性
治理服务默认应用 3 正本 Pod，正本数能够配置，举荐应用 3/5 正本，任何一 Pod 因故障无奈提供服务，还有其余 Pod 提供服务
应用探针检测 Pod 服务是否可用，是否存活，检测到 Pod 服务部可用剔除组件服务，检测到 Pod 死掉后重启 Pod，使其重新启动服务
2. 数据的可靠性与可用性
Volume 分片为 Shard
每个 Shard 独立抉择存储地位
每个 Shard 的 3 个正本存储在不同的物理节点上
写入时同步写入 3 个正本，强统一
读取时只从主正本读
正本数按 volume 可配
敏捷性
Pod 跨节点重建高效：2000PV 的挂载 / 卸载 16s。
批量创立 PV 能力：2000PV 的创立 5min。
NeonIO 性能体现
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/dbe…
图中黄色示意的是 NeonIO，第一张图纵坐标是 IOPS，第二张图纵坐标是毫秒，从后果来看，无论是单正本还是 3 正本，NeonIO 在 IOPS、时延都有显著的劣势。
NeonIO 利用场景
Devops 场景：批量疾速创立 / 销毁 PV 能力，2000PV 创立 5min。
数据库场景：WEB 网站后端数据库 MySQL 等提供稳固的长久化存储，提供高 IOPS、低时延。
大数据利用剖析场景：提供超大容量，PV 可扩容到 100TB。