云原生时代 存储长什么样？

　　科技云报道原创。

　　据IDC称，到2023年，将有超5亿的应用和服务以云原生的方式进行开发和部署，这一数字与过去40年以来人们开发的应用总数相当。

　　云原生的加速发展为每个行业带来新的竞争需求，云原生和容器正在迅速转变为应用程序开发和底层云基础设施服务的新蓝图。

　　但值得注意的是，据CNCF调查显示，目前存储系统依然是云原生场景使用和部署中面临的最主要障碍之一。

　　云原生环境对存储带来新挑战

　　存储系统一直以来都是基础设施软件中的核心之一。无论业务采用什么样的运行环境和架构，都离不开存储系统的支撑。

　　在过去的30年中，业务系统的运行环境经历了巨大的变化，从单独部署的物理机，小规模部署的虚拟化环境，大规模部署的云环境，以及目前的云原生平台。在这个变革的过程中，业务系统对平台敏捷性的要求越来越高。

　　在物理机时代，运维人员需要手动配置存储系统和部署业务系统，业务上线以周为单位。而在云原生时代，每分钟都可能发布新的应用版本，每天都可能有大量的业务要上线。

　　这意味着，云原生时代的存储系统，除了要满足性能、稳定性、可靠性的要求以外，还要满足业务系统对敏捷性的要求，能够通过统一的编排系统配合业务上线，并且可以实现快速扩容。

　　同时，为了减轻运维管理员的工作负担，存储系统自身的自动化运维能力，也成为运维团队关注的核心焦点。

　　尽管在云原生技术日益普及的今天，在Kubernetes上运行无状态应用已经非常成熟，平滑扩展能力也很强，但对于有状态的应用，数据需要持久化存储，还有很大提升的空间，面临着很多挑战。

　　据CNCF对于“在使用/部署容器过程中遇到的挑战”的调查报告中显示，云原生存储遇到的挑战表现在以下几个方面：

　　易用性：存储服务部署、运维复杂，云原生化程度低，缺少与主流编排平台整合

　　高性能：大量应用IO访问，IOPS需求高，低时延，性能成为应用运行效率瓶颈

　　高可用：云原生存储已经应用到生产环境，需要高可靠/高可用，不能出现单点故障

　　敏捷性：PV快速创建、销毁、平滑的扩展/收缩，PV随Pod迁移而快速迁移

　　云原生存储应具备哪些特点?

　　云原生存储作为一种存储系统，可靠性、性能、高可用等特点都是必不可少的。除此之外，云原生环境对存储系统提出了更高的要求。

　　面对诸多挑战云原生存储应具备哪些特点呢?

　　尽量减少环境依赖

　　云原生存储系统应尽量不对软硬件环境存在任何依赖，例如对内核的依赖，对特定的网络设备和磁盘型号的依赖等等。只有尽量少的依赖，才能够做到最大的适配性。

　　避免资源消耗过高

　　云原生存储系统以容器的形式和业务系统混合部署在容器平台上。如果存储系统占用过多的计算资源(CPU、内存)，则会导致整体投入成本太高。

　　声明式运维方式

　　存储系统应支持通过声明式的接口进行运维管理，同时支持一定程度的自动化运维，包括在线扩容、升级等等。当发生硬件故障时，存储服务可以自动恢复，以保证业务系统不受影响。

　　云原生生态

　　云原生存储还需要能够很好地和其他云原生基础设施配合，例如云原生数据库，使得云原生数据库可以真正的在公有云和私有云都能够得到一致的用户体验。同时，云原生存储应该很好地和云原生的运维生态系统结合，包括监控、报警、日志处理等待。

　　总体而言，云原生存储系统可以运行在各种不同服务商提供的公有云环境或私有云环境中，并且为运维人员提供相同接口和运维方式，极大降低运维团队的负担。

　　市场上的云原生存储方案

　　为了更好的理解在云环境中如何构建云原生存储，先看几个在Kubernetes企业环境中部署主流的云原生存储方案。

　　Ceph on Kubernetes with Rook

　　Ceph是圣克鲁兹加利福尼亚大学的Sage Weil在2003年开发的，也是他博士学位项目中的一部分。Ceph LTS成熟稳定、高可用、生态强大，在云原生时代和Kubernets紧密集成。

　　Ceph基于RADOS(Reliable Autonomic Distributed Object Store)的高可用存储，在云原生时代之前已经广泛生产部署的高可用存储，支持最广泛的块存储RBD、文件POSIX Cephfs，以及对象存储访问协议。

　　RedHat/SUSE目前是Ceph最主要的商业化支持者，在多个容器平台落地案例中，RBD、CephFS 都被采用作为容器平台实施的主要存储，用来弥补基础云存储的缺失。

　　Rook目前是在Kubernetes产品级可用的部署和运维Ceph编排工具。

　　Portworx

　　Portworx以容器服务的方式部署，每个节点称为PX，向下对接各种公有云的块存储或者裸金属服务器，向上提供块或文件服务。

　　不绑定硬件形态和厂商，可接入任何一家公有云或者自建服务器集群(只需支持iSCSI或FC 协议)，目前Portworx主打能力云灾备DR、多云复制，具备完备的快照(ROW)、多云管理、同步复制(RTO，秒级)异步复制(RPO<=15min)，可以通过Kubernetes CRD申明方式，优雅实现持久化云下应用带数据自动迁移云上能力。PX可以独立部署，并不强依赖Kubernetes的容器网络。

　　OpenEBS

　　OpenEBS基于Kubernetes构建的开源版EBS，软件定义PV：将各种介质，包括本地磁盘、云等各种存储统一池化和管理。使用iSCSI作为存储协议。没有绑定某一个厂商的存储，可以灵活的接入各种存储的一个原因。

　　从某种意义上，OpenEBS也是更加灵活、轻量。但是强依赖容器网络，增加了抽象层OpenEBS layer, 写入操作要通过抽象层，并且每个卷PV都有独立的controller，增加了额外的开销，虽然可以做到更灵活，但相比于Portworx、Ceph来说，其在性能上有比较大的劣势。

　　目前，已经有大量的企业在将自身的存储能力引入到Kubernetes中。

　　在CNCF公布的《2019 Cloud Native Computing Foundation》市场调研中，分析了当前和未来K8s采用情况，其中许多用户将他们当前的存储和云的供应商列为云原生候选名单中。

　　调查显示，在云原生存储的选择上，用户最常使用Amazon EBS、Google Persistent Disk和Azure Disk Storage。

　　第二梯队的是Ceph、CSI和Gluster，其中37%的Gluster用户也使用Ceph。Ceph和Gluster是分布式文件系统，在多个节点之间添加了持久层。但是，它们没有很好地集成到K8s工具和工作流中，因而可能更难以维护和配置。

　　剩下的第三梯队产品，基本是由以存储为中心的服务商提供的服务，如Dell EMC、NetApp和Pure Storage。最初，Kubernetes集成了卷插件以连接到这些产品的存储后端。不幸的是，上游Kubernetes发行版变得十分臃肿。这意味着对插件的任何微小更新或更改都要重建和编译整个代码。

　　而对于传统存储，客户可能会有更多抱怨声。例如，选择Pure Storage的客户中有46%的在处理与容器相关的存储方面遇到了挑战，而Kubernetes的普通用户这一比例仅为27%。尽管有13%的用户使用了容器存储接口(CSI)，但问题难免还是会出现。

　　事实情况是，传统存储供应商包括纯容器存储服务商在内，正有转向CSI的趋势。虽然总体上只有13%的用户在考虑使用CSI，但在存在存储挑战的用户群中，对CSI的需求一跃升至22%。

　　结语

　　随着云原生时代的到来，越来越多的业务系统会采用云原生架构。存储系统作为承载业务稳定运行的核心组件，在云原生的架构下，其重要性也相应地逐渐提高。

　　事实上，云原生存储遇到的性能、弹性、高可用、加密、隔离、可观测性、生命周期等方面的问题，不但需要存储产品层次的改进，更需要在云原生的控制/数据平面的改进，以推进云原生存储的演进，而这正是新老存储厂商有待优化和提供的服务空间。