云原生存储的思考 （一）什么是云原生存储
Abstract
最近有幸参加了有PingCap和CNCF组织的面向云原生面相持久化应用的Meetup，结合最近对云存储，开源存储，云原生存储的思考，对云原生存储到底是什么，需要做些什么，云原生存储未来挑战是什么，做了更多的反思和梳理，一家之言，分享了几个初步观点。
- 云原生存储是云存储UI，面向应用的申明式应用层存储
公有云
Cloud Native Storage = Declarative API + Cloud Storage
专有云
Cloud Native Storage = Declarative API + Native Storage
- 云原生存储是重用云存储基础设施红利，是构建在核心存储，应用存储之上的分层存储，不需要重新发明轮子。
- 云原生控制平面实现效率，自治方面能力，最大化减小存储稳定和安全隐患。
结合企业生产落地场景中，针对目前云原生应用需求，对存储性能，弹性，高可用，加密，隔离，可观测性，生命周期面临着各种挑战，整理出了部分云原生存储v2的解决方案和演进路径。其中就TiDB在云原生架构中的扩容能力，存储选择可行性和演进，以及不同云原生存储的QoS的保障能力和遇到的挑战与会者做了互动沟通。
容器和云原生计算被企业快速接纳
Forrester 预测到2022年， 全球组织／公司在生成环境运行容器化应用，从今天不足30%的比例将大幅度提升到超过75%，企业应用容器化的趋势势不可挡。
从另一方面，根据IDC对未来企业级存储市场的增长趋势预测，云存储的需求相比于2015年，到2020将会有3倍以上的增长，企业存储市场中数据管理类企业核心数据消耗的存储所占的比例将从15%提升到23%，结构化数据和DBMS数据在企业存储市场中将进一步加强。对云原生来说，核心企业应用／智能应用使用云原生存储来部署生产可用的有状态应用呈现加速上升趋势，海外存储巨头EMC，NetApp拥抱云原生，积极布局REX-Ray flexrex，Trident等云原生存储编排方案。
Kubernetes逐渐成为云原生时代的基础设施
过去的一年（2018-2019）中，Kubernetes逐渐成为云原生时代的基础设施，越来越多的互联网，数据库，消息队列等有状态企业核心应用逐步迁移到云原生平台Kubernetes，对不同的云上块存储的性能在时延，和吞吐，以及稳定性上提出了不同的要求，比如
- 毫秒级NvME SSD级别的稳定时延来满足高性能KVstore和数据库需求。
- 随着应用单机部署密度的提升，对块存储单机密度的挑战
- 本地块存储共享，对块存储的弹性和隔离性也提出的更高需求
在云原生环境下，如何以声明方式来满足不同的业务场景，成为了云原生存储在控制面和数据面实现上的挑战。
在智能应用AI场景下，高性能计算, 流式计算也尝试通过Kubernetes云原生平台来部署，使用云存储方式来完成训练，计算，推理等方面的工作，这对云存储在Kubernets环境的选择，使用也提出了挑战。比如，有证据表明Spark生态正在逐步从Hadoop YARN向Kubernets原生的调度器以及扩展调度器 e.g. Gang Scheuler迁移。在云计算环境中，由于成本和存储计算分离的模型，HDFS仍然会以存储协议的方式存在，但存储方式会逐步从HDFS的3副本向对象存储（OSS，S3)迁移。云计算环境中，GPU多机多卡MPI计算，Flink流式计算的Kuberntes化已经逐步成为主流了，存储访问方式也多以对象存储方式。但是使用对象存储过程中，大数据／AI应用的计算效率仍然面临严峻的挑战
- 减少同一节点对同一Block的反复拉起产生的网络IO。
- 减少数据的Shuffle产生的写IO。
- 实现计算对数据感知，计算向数据迁移的就近计算。
目前的Kubernetes调度器以及云存储特性并未给出好的解决方案，所以这也给云原生存储在加速大数据计算，弥补IO吞吐不足提供了发挥的舞台。
大数据离线计算比如基因计算已经通过Kubernetes云原生平台来大规模的运行计算任务
- 对文件存储峰值吞吐10GBps - 30GBps的峰值刚性兑付
需要独立的高吞吐的文件存储的形态，和交付方式在元原生环境下的演进和变革。
容器服务成为云原生时代基础设施
随着企业应用上云越来越多的选择使用容器化方式，容器服务在不同的云厂商都有大幅度的业务增长，容器服务已经逐步成为云原生时代新的基础设施和最佳使用云资源的入口。云原生存储对云计算／云存储来说也有了新的内涵，有必要重新思考云存储和云原生存储的本质区别和联系。
云原生存储和云存储的思考
Cloud Native Storage vs Cloud Storage
对立还是统一？
两者之间的联系？
差异和侧重点？
1. 云原生存储 = 云存储UI，面向应用的申明式应用层存储
云原生存储声明的六要素：
- 容量Size
- 性能IOPS, 吞吐，时延
- 可访问性，共享／独享
- IO可观测性
- QoS
- 多租户隔离
2. 分层存储，重用基础设施红利，不重新发明轮子，针对新的负载类型部分存储形态上移。
3. 在控制平面实现效率，自治方面能力，最大化存储稳定和安全
为了更好的理解在云环境中，如何构建云原生存储，先看几个在Kubernetes企业环境中部署主流的云原生存储，以及对比云存储的形态。
- Ceph on Kubernetes with Rook
- Portworx
- OpenEBS
Ceph on Kubernetes with Rook
Ceph是圣克鲁兹加利福尼亚大学的Sage Weil在2003年开发的，也是他的博士学位项目的一部分。Ceph LTS 成熟稳定，高可用，生态强大在云原生时代和Kubernets紧密集成。Ceph基于RADOS（Reliable Autonomic Distributed Object Store ）的高可用存储，在云原生时代之前2003年发行起已经广泛生产部署的高可用存储，支持最广泛的块存储RBD，文件POSIX Cephfs，以及对象存储访问协议。RedHat／SUSE 目前是Ceph最主要的商业化支持者，在多个容器平台落地案例中RBD，CephFS都被采用作为容器平台实施的主要存储，用来来弥补基础云存储的缺失。
Rook目前是在Kubernetes产品级可用的部署和运维Ceph编排工具。
Ceph的基本架构由数据面OSDs(RADOS)和控制面MON/RBD/RADOSGW/CEPHFS 组成，以CRUSH Algorithm作为核心算法处理数据冗余和高可用, 上层的应用存储通过librados同数据面OSDs直接完成数据的读写。能够支持快照，备份，监控可观测性等能力，可以通过Rook直接通过Kubernetes输出，RedHat／SUSE也提供独立的集群安装能力。
控制面MON/RBD/RADOSGW/CEPHFS
数据面：OSDs(RADOS)
快照，备份，支持IO监控等存储性能监控，支持RBD QoS的服务端限速能力
Portworx
Portworx以容器服务的方式部署，每个节点称为PX，向下对接各种公有云的块存储或者裸金属服务器，向上提供块或文件服务
不绑定硬件形态和厂商，可接入任何一家公有云或者自建服务器集群(只需支持iSCSI或FC协议)，目前Portworx主打能力云灾备DR，多云复制，具备完备的快照(ROW)，多云管理，同步复制（RTO，秒级）异步复制（RPO<=15min), 可以通过Kubernetes CRD申明方式来优雅实现持久化云下应用带数据自动迁移云上能力。PX可以独立部署，并不强依赖Kubernetes的容器网络。
弹性扩展， PX自动识别服务器节点的能力，可动态调度IO
控制面
支持主流容器编排工具：Kubernetes、Mesos、Swarm等
支持IO级别的性能监控
IO面
数据块和元数据打散到不同的节点
使用了缓存和高性能RPC
QOS隔离：不支持
根据底层存储的特性IOPS(4k) 768 - 65024
时延（4k): 0.58ms - 23ms
增值特性
加密（三方秘钥托管，传输加密，落盘加密），支持云厂商KMS集成和Vault
快照(ROW)，多云管理，同步复制（RTO，秒级），异步复制（RPO<=15min）
可扩展性 >1000个节点，>10000个Volume
支持拓扑感知计算
OpenEBS
OpenEBS基于Kubernetes构建的开源版EBS，软件定义PV：将各种介质，包括本地磁盘，云等各种存储统一池化和管理。使用iSCSI作为存储协议。没有绑定某一个厂商的存储，可以灵活的接入各种存储的一个原因。从某种意义上也是更加灵活，轻量。但是强依赖容器网络，增加了抽象层OpenEBS layer, 写入操作要通过抽象层，并且每个卷PV都有独立的controller增加了额外的开销，虽然可以做到更灵活，但相比于Portworx，Ceph在性能上有比较大的劣势。
控制面：扩展容器编排系统，支持超融合。相比块，卷的数量多，卷的大小任意配置，更灵活。
高可用：每个卷可以有多副本，数据实时同步，数据同步是在不同的存储池间进行同步。
快照，备份，监控存储性能功能。
和Cloud-Native Tools有很好的集成：可以使用云原生工具（如Prometheus，Grafana，Fluentd，Weavescope，Jaeger等）来配置，监控和管理存储资源
性能对比
测试环境：3台“2 vCPU 以及 16GB 的内存”虚拟机创建的Azure AKS集群，每台虚机挂载1个1TB的Premium SSD存储，测试工具FIO
在这个测试中，以hostPath为云盘的性能基准
- Portworx性能最好，PX优化了读性能超过了hostPath模式，但写性能应该是在多副本，PX和裸存储之间的交互损失。
- Ceph操作管理复杂，Rook简化了运维复杂性，读性能优化很好，写性能猜测因为写请求进入多个OSDs的通过RPC走以太网造成了数量级的降低。
- OpenEBS微服务架构，猜测因为增加了额外的虚拟层，使用了容器overlay网络，以及额外的controller的内存换出的代价，性能优化空间很大
盘古 vs RADOS
对比以上三种开源／企业存储，为了更容易的理解云存储的架构，我们把盘古的分层架构和Ceph存储的分层做一个对比。
可以把CS（Chunk Server）类比Ceph OSDs服务进程，把盘古的Master进程类比于Ceph MDSs进程。
把云产品块存储类比于Ceph RBD， 文件存储类别于CephFS, 对象存储类比于RADOSGW，本地块存储／高性能文件存储CPFS产品暂没有对应。
随着盘古架构的演进，和盘古2.0的全面推广，用户态TCP网络协议栈的推广，全面的RDMA存储网络，全面优化的RPC性能，上层产品存储也享受到了底层存储变革的巨大红利，进入了亚毫秒级别时延，和百万IOPS的时代，云原生存储也必然是要在产品存储层次之上能够继承这些能力。
云原生存储
通过分析了市场上云原生存储，我们可以发现这些存储都有共同的特征就是支持声明化的API，可以实现对性能，容量，功能等方面实现度量和声明，或多或少对质量／稳定／安全都有不同支持。
- 容量Size
- 性能IOPS, 吞吐，时延
- 可访问性，共享／独享
- IO可观测性
- QoS
- 多租户隔离
进一步来说，云原生负载可以直接通过数据平面无损耗的使用产品存储在1, 2，3的能力，在控制平面继续提升面向用户应用的IO可观测性，应用级的QoS，多租户的隔离能力，通过控制平面接口实现CSI／Flexvolume等可声明的存储接口，并提供对部分存储生命周期的Operator，容器编排把业务应用和存储粘合成为实际的负载声明，可能是更加正确的使用云存储的姿势。
由于公有云的基础设施产品存储的完备，可以使用更加轻量化的数据平面（virio, nfs-utils, cpfs-sdk, oss-sdk)来访问产品存储，
专有云环境差异较大，部分虚拟化或者无虚拟化环境，SAN和裸盘是主要存储方式，需要通过类似构建ceph RADOS或者盘古实现SDS，然后通过数据平面（librados／px/pv-controller）实现存储的访问。
针对vSphere，OpenStack，飞天所构建的专有云，有接近于共有云的存储提供方式，但因为部署模块的差异，也存在不同的控制／数据平面支持能力的差异。
简单来说就是：
公有云 Cloud Native Storage = Declarative API + Cloud Storage
专有云 Cloud Native Storage = Declarative API + Native Storage
公有云，云原生存储做什么，不做什么
- 存储分层，重用基础设施红利，不重新发明轮子
-
云原生存储
-
- 提升数据平面的一致性（kernel／OS／net／client／sdk优化参数和版本控制）
-
- 构建统一的控制平面CSI/Flexvolume/Operator, 提供面向客户声明API
-
- 在调度编排层面实现拓扑感知，实现云盘的zone awareness, 本地盘的node awareness。
-
云原生- 块存储
在控制平面通过与Aliyun Linux 2 OS结合使用Kernel Cgroup blkio实现进程级别的buffer IO控制，提升了在应用层对本地盘，云盘的QoS控制的粒度。通过对本地盘的LVM切分可以实现对单机云盘的密度提升。通过对挂载点／设备IO指标测采集能力，实现IO的可观测性。
容量: 单盘32TB
时延：0.2ms – 10ms
IOPS: 5K – 1M
吞吐： 300Mbps - 4Gbps (本地NvME ESSD: 2GBps)
可访问性： 单可用区独占
QoS：单盘隔离，进程隔离
多租户： 单盘隔离
云原生- 文件存储
在控制平面可以通过对Pod Security Policy和SecuritContext的控制，实现应用的强制UID／GID控制，实现应用对文件系统的ACL控制。控制平面实现对文件系统生命周期的控制，通过对挂载点IO指标测采集能力，实现IO的可观测性。
容量：单文件系统10PB
时延：100微妙 – 10ms
IOPS: 15K – 50K
吞吐： 150Mbps - 20GBps
可访问性： 多集群多可用区共享
QoS：IO争抢
多租户： PSP ACL （namespace）
云原生 - CPFS并行文件系统
在控制平面实现对文件系统ACL控制，对QoS提供客户端限速的可配置性，文件系统提供生命周期的声明式管理能力Operator，再进一步，在云原生环境内实现CPFS文件系统的声明式部署。
容量：单文件系统100PB
时延：0.5ms – 10ms
IOPS: 50K – 1M
吞吐： 10Gbps - 1000GBps
可访问性： 多集群多可用区共享
QoS：支持客户端限速
多租户： PSP ACL （namespace)
云原生存储 v1 – 功能性
今天的云原生存储已经实现了在控制平面／控制平面接口对阿里云产品存储的全品类支持，在数据平面也完成了大部分系统级和客户端层的优化。但随着大量的持久化企业应用和智能化应用的容器化迁移，我们依然面临着更多的问题和挑战，将会在下一篇文章探讨。

