关注行业云原生（8）：云原生应用对数据基础设施的影响

云原生应用的浪潮不可避免会对IT数据基础设施带来一系列影响和变化，最先接触的首先是存储的变化。

如今越来越多的容器被部署到生产环境中，或者部署在物理裸机，或者部署在虚拟机（VM）中。根据Sysdig 2018年收集的数据，生产环境部署的容器数量已经达到了90,000个。

容器的特点是召之即来，挥之即去。对于无状态应用的如此，但是对有状态的应用，有数据显示，有状态的应用已经达到50%，如MySQL、PostgreSQL、MangoDB、RabbitMQ、ElasticSearch等，应用已经比较广泛，但问题也随之而来，当容器“死了”，可以快速重建，但是数据呢？也能够快速重建吗？这也是容器持久化存储的来源。

存储的变化

1.容器数据持久化

为了保持业务连续性，要求容器能够确保数据不丢失，从技术上说，要为容器提供持久化存储支持。如今，普遍采用K8S对于容器进行编排和调度，k8S已经成为事实上的标准。

K8S定义了Flex Volume、CSI两种存储方式，可以通过API调用外部存储为容器服务。可供选择的外部存储，如CephRBD、Ceph iSCSI等，通过yaml文件创建PV（Persistent Volume，持久化卷），借助对虚拟块设备的attach或者detach操作，为容器提供存储。

2. CSI和容器存储？

但是支持Flex Volume、CSI两种存储方式就可以称为容器存储呢？特别是CSI被广为推崇，在K8S CSI 驱动的目录中，从A到Z排列，可以看到很多存储产品，这些产品对于容器持久化存储的支持，效果都是一样的吗？用户可以任意选择吗？

应该说，这些产品解决了容器与存储的对接问题，让容器可以使用存储资源，但是持久性存储更加重点要解决的是故障节点情况下，容器存储快速恢复的问题。一个故障节点往往会包含数十上或者百个容器，如果每个容器都需要借助detach并重新attach到新节点，加上，attach、detach不仅耗时且容易出错，因此这样的操作在现实应用中，效果不佳。

为了解决attach、detach的效率问题，最好的办法就是要使K8S集群中的各个节点可以实时共享访问各个PV（持久化卷），目前K8S定义了的三种访问PV的方式： ReadWriteOnce(RWO)、 ReadOnlyMany(ROX)、ReadWriteMany(RWX)，其中RWX读写模式不可或缺，唯有如此，才能够从K8S节点对容器存储的访问机制上解决了CephRBD、Ceph iSCSI等应对Pod跨节点重建的问题。

在性能方面，容器存储设计的关键是MDS（元数据管理）不能出现瓶颈。以机器学习AI为例，数据训练中需要依赖大量的小文件，规模会达到，从10亿～70亿小文件；此外高性能计算也将涉及到海量文件的处理，其本质就是要避免MDS管理出现。好的解决方案利用可水平扩展的元数据集群架构，采用动态子树的元数据管理算法，来确保MDS的访问效率。

存储IO性能方面，有的方案采用文件切片来保证大文件随机读写性能；并通过支持RoCE或InfiniBand网络， 使用RDMA使操作让性能提升。

热点目录也是造成性能瓶颈的来源，特别对于采用分布式文件系统设计的容器存储而言，当多台服务器集中访问某个单一目录下的文件，就会形成热点目录，对于热点目录并行处理能力不足，就会导致系统崩溃，或者性能低下。为此，采用类似虚拟目录的设计，增强热点目录并行处理能力。

3.数据可视化和管理

容器数据持久化之后，在实际应用的过程中，管理也是用户应该关注的问题，好的产品应该能够满足应用的需求，如故障感知、QoS、PV IO 压力跟踪和定位、Prometheus监控数据、以及对容器存储PV的细粒度监控和管理。

以故障感知为例，当K8S在创建和调度新的具有数据持久化需求的Pod时，该功能能够自动过滤掉CSI插件容器异常和异常的工作节点（Worker Node）。QoS能帮助系统控制应用对有限资源（如IOPS、带宽等）的使用，能够对其进行设置与管理，从而避免有些容器应用因为资源不足，被“活活饿死”的现象。此外，在PV数量倍增的背景下，如何跟踪、监控、定位IO压力大的PV，这成为了容器云平台用户的挑战。帮助管理员快速查看PV内数据层次以及数据温度，进行分析和调；调整PV大小，实现弹性伸缩，这种管理调度的能力，对于容器系统平稳运行保障，效果显著。

Prometheus作为Cloud Native Computing Foundation（CNCF）中的重要一员，其活跃度仅次于 K8S，现在已经成为主流监控系统。容器存储兼容Prometheus也非常必要。

4.海量数据和容灾备份

在容器化的应用中，海量数据共享访问属于其中一种典型场景（例如Drupal、WordPress等内容管理系统，或图片识别、视频编码、视频渲染等应用）。

这些应用场景需要同时满足容器持久化数据共享访问、高性能、低成本三方面要求，其中，高性能和低成本本身就是一对矛盾。以闪存为例，闪存性能高但是价格贵，相比，磁盘便宜但性能差，因此兼顾高性能和低成本，就需要系统设计就具有数据智能分层的能力。

统计数据显示，80%的数据具有较为明显的访问周期性特征，超过一定周期后，数据会逐步趋冷，随后，应用对这些冷数据的读写变得极少。因此，将热数据保存在具有SSD的高性能数据层中，冷数据层直接接入任何第三方提供的具备S3标准接口的对象存储。

容器在访问数据时对数据所处的层次完全无感知。用户可自定义冷数据策略及冷数据自动执行跨层迁移的时间，数据在冷热数据层之间迁移的过程中仍然可读可写，对业务无影响。

在容灾备份方面，有状态Pod跨节点的秒级数据重建解决了当容器节点出现故障，容器快速重建、数据快速恢复的问题。同样的，跨数据中心容器双活的问题也容易实现。数据中心双活的本质是数据问题，分布式存储副本机制，确保了不同数据中心数据的一致性，优先读取本地副本，实现应用跨数据中心的双活，并有效降低读延时。

5.存储趋势变化促进容器发展

存储趋势的变化也会带来容器应用的变化。如今，以容器应用为核心的原生应用是通过IO接口访问数据持久性存储，SSD、HDD还是主要的存储设备，未来SCM（storage-class memory，存储级内存)发展也会原生应用带来更好的性能，以及数据访问的方式。以3D Xpoint 为代表Optane的两种产品形式，Optane Memory和Optane SSD为用户带来的新的选择，未来的数据存储完全可以存储在Optane Memory这种非易失内存存储介质上，带来优于SSD的性能表现。

这种进步更多表现在存储硬件层面的变化，其影响不限于原生应用，但是原生应用也会因为硬件技术的进步，有很多新的应用方式，带来新的表现。以互联网企业为代表，新的硬件技术不断走入实际应用过程中。

计算、网络的变化

云原生应用发展也对网络传输和CPU计算提出了新的需求。

原生应用要求网络传输更加迅速，类似DPDK、SROV、Multus这样的技术得到广泛的应用，其中，DPDK作用在于加速，它通过类似用户态的网络协议栈，减少了网络对于NPU计算资源的中断，从而呈现更好的网络加速的效果。SROV的作用在于网络流量的隔离，以提供更加安全的网络传输效果。

相比，开源Multus提供一个网络端口多接入网络资源的访问。在骨干广域网、城域网普遍采用的NFV技术，很多也运行在容器平台环境下。云原生应用与网路传输深度结合。

同样在计算领域，很多CPU技术也对云原生应用发挥了重要的作用。以容器隔离为例，因为都运行在Linux内核上，如果某些容器应用侵入到内核，势必危害云原生应有的安全运行，这里就需要类似Intel-VT这样的技术。针对容器之间存在的资源争夺问题，RDT这样的技术，也被用于资源的管理和分配。

从本质上说，云原生应用的微服务化，存进了迭代式应用，以及DevOps的开发方式，但大量微服务的调用，也增加管理的复杂性，这种复杂性就需要借助AIOps技术保驾护航，也因为计算核心内置AI加速技术，以及TPU、GPU等技术的进步，催生了AIOps技术进步，也为云原生应用创造了良好的外部应用环境。

后记：

为了帮助传统行业企业加速完成云原生化改造，百易传媒（DOIT）联合Intel、VMware、阿里云、腾讯云、百度云、华为云、浪潮、金山云、红帽、灵雀云、青云、焱融云、xSky、杉岩、青藤云、蚂蚁金服、Portworx、UCloud、DaoCloud、数人云、京东云、网易云、亚信科技、云徙科技、时速云、七牛云、Caicloud才云、CSphere希云（排名不分先后）等国内外领先的云原生应用厂商的专家，共同组织编纂了《行业云原生应用报告指南》白皮书，希望能够为传统行业企业提供帮助。

本文摘自《行业云原生应用告指南》，该白皮书也将于近期发布，欢迎关注！

【未完待续；下期预告：云原生化应用与安全

未经允许不得转载：DOIT » 关注行业云原生（8）：云原生应用对数据基础设施的影响