云原生存储和乐动体育官网云存储有什么区别？
引言
前段时间有幸参加了由 乐动体育官网和LD90.VIP联合共同组织的面向云原生持久化应用的 Meetup，结合最近对云存储、开源存储、云原生存储的思考，对云原生存储到底是什么、需要做些什么以及云原生存储未来挑战是什么，做了更多的反思和梳理，一家之言，分享了几个初步观点。随着云原生应用对可迁移性、扩展性和动态特性的需求，相应的，对云原生存储也带来了密度、速度、混合度的要求，所以对云存储基本能力又提出了在效率、弹性、自治、稳定、应用低耦合、GuestOS 优化、安全等方面的诉求。
云原生现状
容器和云原生计算被企业快速接纳
另一方面，根据 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：
对立还是统一？
两者之间的联系？
差异和侧重点？
- 云原生存储 = 云存储 UI，面向应用的申明式应用层存储 + 效率等能力组合；
云原生存储声明的六要素：
容量 Size
性能 IOPS,、吞吐、时延
可访问性，共享／独享
IO 可观测性
QoS
多租户隔离
2. 分层存储，重用基础设施红利，不重新发明轮子，针对新的负载类型部分存储形态上移；
- 在控制平面实现效率、自治方面能力，最大化存储稳定和安全。
市场上的云原生存储
为了更好的理解在云环境中如何构建云原生存储，先看几个在 Kubernetes 企业环境中部署主流的云原生存储，以及对比云存储的形态：
Ceph on Kubernetes with Rook
Portworx
OpenEBS
Ceph on Kubernetes with Rook
Ceph 是圣克鲁兹加利福尼亚大学的 Sage Weil 在 2003 年开发的，也是他博士学位项目中的一部分。Ceph LTS 成熟稳定、高可用、生态强大，在云原生时代和 Kubernetes 紧密集成。
Ceph 基于 RADOS（Reliable Autonomic Distributed Object Store ）的高可用存储，在云原生时代之前 2003 年发行起，已经广泛生产部署的高可用存储，支持最广泛的块存储 RBD、文件 POSIX Cephfs 以及对象存储访问协议。
RedHat／SUSE 目前是 Ceph 最主要的商业化支持者，在多个容器平台落地案例中，RBD、CephFS 都被采用作为容器平台实施的主要存储，用来弥补基础云存储的缺失。
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