电子发烧友App
作者 | ***（壮怀） 阿里云智能事业群高级技术专家
导读：新的企业负载／智能工作负载容器化、迁云、存储方面遇到的性能、弹性、高可用、加密、隔离、可观测性以及生命周期等方面的问题，不但需要存储产品层次的改进，更需要在云原生的控制／数据平面的改进，推进云原生存储和云存储的演进。本文将介绍一下问题场景，探讨可行的解决方案，最终得出云原生存储以及云存储目前可以做什么和未来还需要做什么。
引言
最近有幸参加了由 Infra Meetup 联合 Kubernetes & Cloud Native Meetup 共同组织的面向云原生持久化应用的 Meetup，结合最近对云存储、开源存储、云原生存储的思考，对云原生存储到底是什么，需要做些什么，云原生存储未来挑战是什么，做了更多的反思和梳理，一家之言，分享了几个初步观点。
随着云原生应用对可迁移性、扩展性和动态特性的需求，相应的，对云原生存储也带来了密度、速度、混合度的要求，所以对云存储基本能力又提出了在效率、弹性、自治、稳定、应用低耦合、GuestOS 优化、安全等方面的诉求。
云原生现状
容器和云原生计算被企业快速接纳
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 云原生平台来部署，使用云存储方式来完成训练、计算、推理等方面的工作，这对云存储在 Kubernetes 环境的选择及使用方面提出了挑战。比如，有证据表明 Spark 生态正在逐步从 Hadoop YARN 向 Kubernetes 原生的调度器以及扩展调度器 e.g. Gang Scheuler 迁移。
在云计算环境中：由于成本和存储计算分离的模型，HDFS 仍然会以存储协议的方式存在，但存储方式会逐步从 HDFS 的 3 副本向对象存储（OSS，S3）迁移；GPU 多机多卡 MPI 计算、Flink 流式计算的 Kubernetes 化已经逐步成为主流，存储访问方式也多以对象存储方式呈现。
但是在使用对象存储过程中，大数据／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 也提供独立的集群安装能力。
Ceph 的一些基本架构特征和能力：
控制面：MON/RBD/RADOSGW/CEPHFS；
数据面：OSDs(RADOS)；
快照、备份、支持 IO 监控等存储性能监控，支持 RBD QoS 的服务端限速能力。
Portworx
Portworx 以容器服务的方式部署，每个节点称为 PX，向下对接各种公有云的块存储或者裸金属服务器，向上提供块或文件服务。
不绑定硬件形态和厂商，可接入任何一家公有云或者自建服务器集群(只需支持 iSCSI 或 FC 协议)，目前 Portworx 主打能力云灾备 DR、多云复制，具备完备的快照(ROW)、多云管理、同步复制（RTO，秒级）异步复制（RPO<=15min)，可以通过 Kubernetes CRD 申明方式，优雅实现持久化云下应用带数据自动迁移云上能力。PX 可以独立部署，并不强依赖 Kubernetes 的容器网络。
Portworx 的一些基本功能／性能特征：
弹性扩展， 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 来说，其在性能上有比较大的劣势。
OpenEBS 的一些基本功能／性能特征：
控制面：扩展容器编排系统，支持超融合。相比块而言，卷的数量多且卷的大小任意配置，更加灵活；
高可用：每个卷可以有多副本，数据实时同步，数据同步是在不同的存储池间进行同步；
快照、备份、监控存储性能功能；
和 Cloud-Native Tools 有很好的集成：可以使用云原生工具（如 Prometheus，Grafana，Fluentd，Weavescope，Jaeger 等）来配置，监控和管理存储资源。
理解云存储
盘古 vs RADOS
对比以上三种开源／企业存储，为了更容易的理解云存储架构，我们把盘古的分层架构和 Ceph 存储的分层做一个对比。
可以把 CS（Chunk Server）类比 Ceph OSDs 服务进程，把盘古的 Master 进程类比于 Ceph MDSs 进程。
把云产品块存储类比于 Ceph RBD， 文件存储类别于 CephFS, 对象存储类比于 RADOSGW，本地块存储／高性能文件存储 CPFS 产品暂没有对应。
随着盘古架构的演进，和盘古 2.0 的全面推广、用户态 TCP 网络协议栈的推广、全面的 RDMA 存储网络、全面优化的 RPC 性能，上层产品存储也享受到了底层存储变革的巨大红利，进入了亚毫秒级别时延，和百万 IOPS 的时代，云原生存储也必然是要在产品存储层次之上，能够继承这些能力。
云原生存储在公有云和专(私)有云中的差异
通过分析了市场上云原生存储，我们可以发现这些存储都有共同的特征就是支持声明化的 API，可以实现对性能、容量、功能等方面的度量和声明，或多或少对质量／稳定／安全都有不同支持。
进一步来说，云原生负载可以直接通过数据平面无损耗的使用产品存储在容量、性能、可访问性的能力，在控制平面继续提升面向用户应用的 IO 可观测性、应用级的 QoS、多租户的隔离能力，通过控制平面接口实现 CSI／Flexvolume 等可声明的存储接口，并提供对部分存储生命周期的 Operator，容器编排把业务应用和存储粘合成为实际的负载声明，可能是更加正确使用云存储的姿势。
由于公有云的基础设施产品存储的完备，可以使用更加轻量化的数据平面（virtio, 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 – 功能性
今天的云原生存储已经实现了在控制平面／控制平面接口对阿里云产品存储的全品类支持，在数据平面也完成了大部分系统级和客户端层的优化。但随着大量的持久化企业应用和智能化应用的容器化迁移，我们依然面临着更多的问题和挑战。
在整个云原生存储 v1 的开发过程中，感谢阿里云存储团队，在文件存储、块存储和对象存储的通力合作和帮助，共同打造的云原生时代的存储。
随着云原生应用对可迁移性，扩展性和动态特性的需求，对云原生存储也带来了相应的密度，速度，混合度的要求，所以对云存储基本能力之上又提出了在效率，弹性，自治，稳定，应用低耦合，GuestOS优化，安全等方面的诉求。新的企业负载／智能工作负载容器化，迁云，存储方面遇到的性能，弹性，高可用，加密，隔离，可观测性，生命周期等方面的问题，不但是需要存储产品层次的改进，更需要在云原生的控制／数据平面的改进，推进云原生存储和云存储的演进，这是对云原生存储v2的展望和规划，我们会在后续文章进一步揭示这些新的场景，需求，方案以及发展方向。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
工商网监
评论