当容器遇见存储：Container-Native Storage 已来！！

容器技术以及概念，虽然很早就已经存在，例如lxc ，jails等，但自从2013年Docker的横空出世，对容器的管理方式做了更好的封装，尤其是镜像概念及docker build工具的出现，极大的促进了容器技术的普及，同时也使得更多的应用场景成为可能。

容器的典型场景

很长的一段时间，IaaS平台主要基于虚拟机承载业务服务。随着技术的进步，以及业务系统的复杂化，虚拟机的弊端逐步体现出来，例如分发慢，资源耗用大，无法体现配置既代码的特点等。

容器有着镜像小，启动快，占用资源少的特点，解决了虚拟机的不足, 能够更好的适用于无状态的服务，尤其是web服务，DevOps, 微服务等场景。从Docker的角度，只要提供各种容器，相互之间配合，通过搭积木的方式组合起来，就可向上提供服务。

企业应用的新要求

随着中国互联网技术的蓬勃发展，从虚拟化,到 OpenStack再到容器技术，都走向了成熟的商业应用。随着Kubernetes的风头正劲，给容器和业务的管理带来了更多的便利性，企业用户已经开始逐步将原有的运行在虚拟机上的应用迁移到容器上来。

那么企业级用户的业务系统的特性是什么呢？业务庞杂、高耦合低内聚、平台各异、语言各异等等，同时对网络安全和持久化存储有很高的要求，比如要求持久化存储保证高可靠、高可用和高性能

容器在对接企业应用时，存在的主要问题是什么？容器本身并不提供持久化存储的解决方案，存储在容器内部的任何内容，在容器被销毁以后，数据将自动消失，但是随着应用容器的普及，或多或少都会有数据持久化的需求，例如：

1. 网站页面
2. 配置文件
3. 数据库
4. 大数据应用等

容器持久化存储面临的问题

为了保证持久化存储的灵活性以及可访问性，远程网络存储看来是理想的方案，这样既可以利用不同的协议，例如ISCSI, NFS等访问，也可以支持不同介质的存储，例如云存储，SAN设备，或者本地磁盘等，从理论上打通了现有的存储与容器的整合之路。

现有的存储方案真的能很好应对容器存储场景吗？就像虚拟化流行时发现存储不能满足需求一样，今天容器用户依然会发现传统的存储体系依然不能满足容器场景下对存储的需求。

在现有的容器管理平台中,例如Kubernetes, 已经内在支持了广泛的存储插件，典型的可以分为：

a)文件存储，例如 CephFS, GlusterFS, NFS等。 CephFS,GlusterFS尽管有庞大的社区的支持，但成熟度上还需要进一步的验证，同时在大型集群的环境下还无法达到企业级稳定性、可靠性的要求，在高可靠、高性能场景也有着架构上的不足；而NFS在性能上存在不足。

b)块存储，例如Ceph RBD, SAN存储等。对于这类存储，本身并不支持多读写的需求，而对复杂的容器业务系统又是强需求。

容器应用场景下的存储有着自己独特的需求，需要能够对容器级别的存储卷做细粒度的管理，例如Persistent Volume级别的Quota配置，QoS限速，ACL控制，快照等。这就是Container-Native Storage的基本要求。

从2018年最新的Gartner技术趋势图中，我们可以看到，专门针对容器应用场景的持久化存储Container-Native Storage正处于明显的上升趋势。

那么Container-Native Storage 与 我们日常的存储有什么差别呢？

1. 专门为支持容器而设计的
2. 能够满足应用的扩展以及性能需求
3. 与容器管理系统深度整合
4. 支持大量系统的并行访问

另外，为了保证容器的可用性，容器调度平台会在容器或者所在宿主机发生故障时，自动将容器转移到其他的节点上，这意味着在容器迁移到其他节点之后，需要能够无差别的访问原有的存储内容，也就是存储要做到容器跟随。

如何成就企业级的容器存储

容器存储既然是存储，存储的基本功能诸如可靠性、可用性等自然不用再说，随着业务的发展，新的应用形态（Cloud-Native, 微服务等）对容器存储有了新的要求，主要体现在一下几个方面：

1.标准的社区接口对接：容器存储需要与容器管理平台做深度的整合，我们以Kubernetes为例。Kubernetes中内置了Flex Volume与CSI两种支持外部存储的插件化方案，对于存储厂商来说，需要实现静态(static provisioning)与动态(dynamicprovisioning via storage class)的存储卷的生命周期管理，如今Kubernetes社区已经增强了对持久化存储的重视度，从定义标准的CSI存储接口到持续增加容器对持久化存储的标准调用API，可见容器存储提供商需要持续跟进社区计划。

2.丰富的读写模式支持：同时为了满足业务的需求，对于ReadWriteMany的支持也是一个必备的选项。

3.数据跟随：容器数据的跟随意味着数据必须能够快速的在全局可见。

4.最小的扩容、故障带来的影响范围：随着机器规模的增加，磁盘，物理机等发生故障的几率也大幅增加，对于任何一个节点都可能有数十上百个容器在访问的存储来说，如何做到在扩容、故障的情况下，减小业务的影响时间及范围就显得更加重要。

5.海量并行任务下优异的读写性能：随着微服务，应用容器化，集群内容器的实例数量相比虚拟机场景会增加10倍以上，以前一个大型企业可能总共几百个虚拟机，容器化后会演变成上千个容器实例，这就要求在海量并行任务下存储的性能能够持续保障业务需求。

综合起来，一个好的企业级容器存储应该是一个分布式存储，具备良好弹性能力，通过分布式文件接口暴露给容器使用，与容器管理平台融合并提供高可用数据卷功能，提供丰富的基于容器粒度的存储功能，能够让容器感知也能够感知容器变化，甚至于存储整体容器化，同时针对扩容以及故障的影响进行优化，做到最小甚至无影响。

焱融高性能企业级Container-Native Storage

焱融科技一直以来走在技术的前沿，我们认为超融合从早期的支持vmware esxi（Nutanix最早以支持vmware esxi为主）到xen，hyper-v，再到kvm，而随着容器应用的快速普及，我们认为新一代的超融合产品是支持容器化应用场景的。

焱融高性能超融合容器存储是焱融科技在2017年针对容器技术趋势预判， 走访容器客户，在现有技术的经验积累下提早技术布局，最终在2018年6月份推出的国内第一家企业级Container-Native Storage产品，完美支持容器存储场景。此产品提供了如下的特性：

1. 高性能分布式文件接口，全分布式元数据集群
2. 支持容器以及Namespace级别的Quota配置， QoS限速
3. 与容器平台的深度整合。 在KubernetesV1.10.5以下版本中，可以用Flex Volume插件支持静态与动态的卷创建 在KubernetesV1.10.5及以上版本，可以使用CSI plugin支持静态与动态卷的创建
4. 支持RWO/ROX/RWX三种访问方式，满足各种应用对存储的使用要求，并且针对不同的访问方式做了深度优化
5. 高性能客户端以及缓存层，提高了数据访问的效率与性能
6. 有效控制了故障以及扩容的场景下对业务数据的影响，在大规模集群场景下相比其他方案对容器应用影响时间、范围最小
7. 优异的高并发任务下的读写性能
8. 支持融合、分离的多种部署方式

通过FIO的对比测试（本次仅对比了ceph块存储），在高并发模式（采用iodepth=64 + numjobs=32）下的测试结果如下