云原生时代需要什么样的存储系统
存储系统作为支撑业务系统的基础设施软件的核心之一，一直处于不断变化和革新中。从早期的物理机时代、到虚拟化技术的成熟普及，到现在大规模部署的云环境都有存储系统在背后默默支撑。近年来，以容器、微服务、DevOps 为代表的云原生技术，受到了市场的广泛关注，其能够更好地支持企业的云原生应用、自动化管理和业务创新，满足用户在任何时间、任何地点对任何应用的响应需求。相应地，存储系统作为支撑数据持久化、承载业务稳定运行的核心组件,同样面临深刻变革。
什么是云原生存储？
要理解云原生存储，我们首先要了解云原生技术的概念，CNCF 对云原生定义如下：
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
简言之：云原生应用和传统应用并没有一个标准的划分界限，其描述的是一种技术倾向，即越符合以下特征的应用越云原生：
-
应用容器化
-
服务网格化
-
声明式 API
-
运行可弹性扩展
-
自动化的 DevOps
-
故障容忍和自愈
-
平台无关，可移植的
云原生存储的概念来源于云原生应用，顾名思义：一个应用为了满足云原生特性的要求，其对存储所要求的特性是云原生存储的特性，而满足这些特性的存储方案，可以称其为云原生的存储。
为什么需要云原生存储？
云原生存储依然是容器化面临的主要挑战之一
根据 CNCF 的调研报告：在使用/部署容器过程中遇到的挑战中，依然有高达 29% 的人选择存储。存储几乎和安全问题一样，成为应用容器化过程中的主要难点。
目前，云原生存储遇到的挑战表现在以下几个方面：
易用性：存储服务部署、运维复杂，云原生化程度低，缺少与主流编排平台整合。
高性能：大量应用 IO 访问，IOPS 需求高，低时延，性能成为应用运行效率瓶颈。
高可用：云原生存储已经应用到生产环境，需要高可靠/高可用，不能出现单点故障。
敏捷性：PV 快速创建、销毁、平滑的扩展/收缩，PV 随 Pod 迁移而快速迁移等。
有状态应用现在已成为容器存储的主体
随着 Kubernetes 的应用程度加强，并且伴随着 IoT、5G、AI 等技术的成熟，越来越多的有状态应用被搬上容器平台。根据 CNCF 的调研报告，已经有超过一半的用户已经在容器中运行有状态应用，并且有 23% 的用户正在评估或计划在容器中部署有状态应用。
通常，有状态应用对存储的有如下三点需求：
① Volume 拥有独立与pod的生命周期。
② Volume 中的数据是可以持久保留的。
③每个 pod 与其使用的存储关系是稳定的，不会因升级等因素而发生变化。
当然不同类型的应用具有不同的 IO 特点，对于存储有不同需求：
-
数据库 —— 交易型数据库（OLTP） MySQL 和 PostgreSQL 通常承载的都是核心交易类业务，对存储系统的数据可靠性、性能要求极高。
-
AI/ML —— ML 应用程序, TensorFlow 使用分布式计算处理不同进程中的图形部分，每个进程都可以在单独的容器中运行。
-
大数据分析 —— 分析型数据库（OLAP），如 Spark，存储系统的可靠性以及延迟的要求都不像 OLTP 数据库那么高，需要大容量存储。
-
HPC/渲染 —— 如图形绘制和视频转码工具，都可以使用应用程序实例集群化来处理大型批处理作业。
-
Devops —— Jenkins/Gitlab，通常 Jenkins 基于主从模型构建分布式集群，即会使用一个文件目录来维护其状态。因此，需要在不同主机上的容器之间共享该目录。
多云环境带来的云原生挑战
如今，越来越多的 IT 组织正在构建混合云和多云环境以支撑其业务运行。从容器的角度来看，我们知道在多个云平台上运行应用程序已经成为了容器技术使用的主要驱动力，带来了远超以往的益处，如开发者效率的提升以及支持微服务等。但是，多云以统一的方式管理、保护和部署存储可能具有挑战性：
-
多个 API —— 云服务通过 API 进行通信。虽然 RESTful API 有一些标准化，但不同的提供者会创建不同的 API 结构。这可以包括不同的规则结构或不同的语言。这些差异需要应用程序自定义以实现跨服务通信。
-
兼容性问题 —— 为了顺利集成到单一环境中，存储服务需要跨云兼容。这意味着服务需要适应相同的数据结构并允许与相同的工具集成。
-
复杂的管理 —— 很难确保跨云服务和环境的可见性。它需要集中监控和联合服务，例如身份和访问控制。如果没有中心化，服务可能会出现配置差异或错误，并增加脆弱性。
如何选择云原生存储
常见云原生存储方案
OpenEBS
OpenEBS 是目前 CAS（Container Attached Storage）的一种开源实现方案，因此它直接运行在 Kubernetes 平台上，通过 Kubernetes 平台进行编排与调度。
OpenEBS 支持如下三种存储类型，分别为 cStor、Jiva 以及 LocalPV。
特点：
-
每个 Volume 都由一个轻量级的 Controller 来管理，这个 Controller 可以是一个单独的 Pod。
-
这个 Controller 与使用该 Volume 的应用 Pod 在同一个 Node（Sidecar 模式）。
-
不同的 Volume 的数据使用多个独立的 Controller Pod 进行管理。
OpenEBS 存储引擎选择：
Jiva：适用于低容量的工作负载，比如内部测试、个人体验上。
Cstor：存储级别上具有高可用性、快照、克隆等的应用，比如 MYSQL、GitLab、Jinkens 等。
LocalPV：要求高性能、低延迟，通常更适合分布式的应用，这些应用本质就是分布式的，内置的高可用性，比如Zookeeper、Prometheus、Cassandra、MongoDB、Elastic 等。
Prometheus 生成警报，需要低延迟存储而不是复制存储，因此选择 LocalPV。
Rook-Ceph
Rook 的目标并不是重新造轮子实现一个全新的存储系统，最开始 Rook 项目仅仅专注于如何实现把 Ceph 运行在 Kubernetes 平台上，Rook Ceph 则同时提供了块存储、共享文件系统存储以及对象存储接口。
Rook 除了能支持 Ceph，还支持：EdgeFS、CockroachDB、Cassandra、NFS、Yugabyte DB。不同的存储通过不同的 Operator 实现，但使用起来基本一致，Rook 屏蔽了底层存储系统的差异。
两种存储方案对比
OpenEBS 和 Rook 的优点
-
支持 CSI，具有很好的容器数据卷接入能力。
-
社区较为活跃，网络资源、使用资料丰富，容易入手。
-
与云原生编排系统高度融合，能够完全用云原生的思维对存储系统进行部署、升级、扩容等运维管理。
不足之处
-
OpenEBS/Rook 性能差，IO 性能、吞吐、时延等方面都表现欠佳，很难应用在高性能服务场景。
-
Rook维护成本高，虽然部署、入门简单，但组件多，架构复杂，排错困难，一旦运行中出现问题解决起来非常棘手，需要有很强的技术团队加以保障。
-
OpenEBS LocalPV 虽然性能高，但是没有高可用性，单点故障，而且缺少企业级特性克隆、快照等特性。
QingStor 的云原生存储及应用实践
QingStor NeonIO 是一款支持容器化部署的企业级分布式块存储系统，能够给Kubernetes 平台上提供动态创建（dynamic provisioning) 持久存储卷（persistent volume) 的能力，支持 clone、snapshot、resstore、resize 等功能。
NeonIO 架构图
NeonIO 架构如图上所示。
zk/etcd: 提供集群发现、分布式协调、选 master 等服务
mysql：提供元数据存储服务，如 PV 存储卷的元数据
center：提供逻辑管理服务，如创建 PV 卷，快照
monitor: 提供监控服务，能够把采集监控指标暴露给 Prometheus
store：存储服务，处理应用 IO 的功能
portal：提供 UI 界面服务
CSI：提供 CSI 的标准 IO 接入服务
NeonIO 的特点
简单易用
-
全栈组件容器化：服务组件、CSI、Portal 容器化
-
完整实现 CSI 接口：提供标准的 IO 接入能力，可静态、动态创建 PV
-
UI 界面，“零“运维
-
存储运维操作界面化、告警、监控可视管理。
-
基于 PV 粒度的性能监控，如 IOPS、吞吐量，可以快速定位到热点 PV。
-
基于 PV 粒度的 QoS，保证用户高优先级的服务质量。
-
存储的扩容、升级、灾难恢复运维操作，基于 K8s 命令即可完成。
-
-
与云原生高度融合
（1）支持Prometheus，通过ServiceMonitor把NeonIO的采集指标暴露给Prometheus、Grafana，进行图形化展示。
（2）同时UI界面可与 Prometheus 对接，展示其他云原生监控的指标，如 node-exporter 的磁盘 IO 负载、带宽等。
（3）服务发现、分布式协调支持 etcd、元数据的管理，使用 CRD 的方式。
- 一键式部署：采用 Operator 方式部署，并实现集群服务自动启动
超高性能
- 全闪的分布式存储架构
（1）集群中所有节点共同承担压力，IO 性能随着节点增加而线性增长；
（2）存储介质支持 NVME SSD；
（3）支持 RDMA：通过高速的 RDMA 技术将节点连接。
-
极短的 IO 路径：抛弃文件系统，自研元数据管理系统，使 IO 路径极短。
-
使用 HostNetwork 网络模式
好处：
（1）Store CSI Pod 使用 HostNetwork，直接使用物理网络，减少网络层次。
（2）管理网络、前端网络、数据同步网络分离，避免网络竞争。
高可用
- 服务组件可靠性与可用性
(1) 管理服务默认使用 3 副本 Pod，副本数可以配置，推荐使用 3/5 副本，任何一 Pod 因故障无法提供服务，还有其他 Pod 提供服务。
(2) 使用探针检测 Pod 服务是否可用，是否存活，检测到 Pod 服务不可用剔除组件服务， 检测到 Pod down 掉后重启 Pod，使其重新启动服务。
- 数据的可靠性与可用性
(1) Volume 分片为 Shard
(2) 每个 Shard 独立选择存储位置
(3) 每个 Shard 的 3 个副本存储在不同的物理节点上
(4) 写入时同步写入 3 个副本，强一致
(5) 读取时只从主副本读
(6) 副本数按 volume 可配
敏捷性
-
Pod 跨节点重建高效：2000PV 的挂载/卸载 16s
-
批量创建 PV 能力：2000PV 的创建 5 min
NeonIO 性能表现
测试平台：NeonIO 超融合一体机集群（3 个节点，192.168.101.174 - 192.168.101.176）
注意：所有测试均使用 NVMe SSD。卷大小 = 1TiB。性能工具
图中黄色表示的是 NeonIO，第一张图纵坐标是 IOPS，第二张图纵坐标是毫秒，从结果来看，无论是单副本还是 3 副本，NeonIO 在 IOPS、时延都有明显的优势。
NeonIO 应用场景
-
Devops 场景：批量快速创建/销毁 PV 能力，2000PV 创建 5min 。
-
数据库场景：WEB 网站后端数据库 MySQL 等提供稳定的持久化存储，提供高IOPS、低时延。
-
大数据应用分析场景：提供超大容量，PV 可扩容到 100TB。
-
计算和存储分离部署场景：K8s 集群 1 部署 NeonIO，K8s 集群 2 通过 CSI 使用 K8s 集群 1 的 NeonIO 存储。
作者
杨兴祥 QingStor 高级软件工程师
本文由博客一文多发平台 OpenWrite 发布！