当容器遇见存储 焱融云完美缔造容器神话

　　IT领域，变革的速度令人瞠舌。快速增长的数据，云计算规模的处理正推动企业向着更高效、更可靠和可扩展的方向前行。传统的应用架构已日趋极限，所幸的是，最被看好的容器化技术正成为应对上述难题的妙药良方。

容器触发无限场景

　　现实工作中，企业云工程师经常会遇到这样的问题：程序在我这儿跑得好好的，怎么到你那里就不行了?系统好卡，是哪个进程把CPU给吃光了?这套系统我已经搭建好了，要不你再重新搭建一遍?每每出现这类问题，容器技术都成为解决它们的不二法宝。

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

　　众所周知，很长一段时间，IaaS平台主要基于虚拟机承载业务服务。但随着业务复杂度的升高，每一个虚拟机都是一个完整的操作系统，所以需要给其分配物理资源。而当虚拟机数量增多时，操作系统本身消耗的资源势必增多。此外，由于开发与运维的环，比较复杂。所以在部署上线应用时，企业依旧需要花费不少时间去处理环境不兼容的问题。因此虚拟机分发慢，资源耗用大，无法体现配置既代码的弊端逐步体现出来。

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

持久化存储造就容器难题

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

　　对于企业级用户来说，业务庞杂、高耦合低内聚、平台各异、语言各异等是共通的系统属性。容器的出现让企业真正可以聚焦在业务本身，而不受运维开发的困扰。但是当企业在将传统应用容器化的时候，也面临一些挑战。他们希望通过持久化存储以保证高可靠、高可用和高性能。

　　但容器本身并不提供持久化存储的解决方案。存储在容器内部的任何内容，在容器被销毁以后，数据将自动消失，例如网站页面、配置文件、数据库和大数据应用等。因此在企业真正运行环境中，如何实现容器持久化存储一直是业界的热点问题。

当容器遇见存储

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

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

　　在现有的容器管理平台中,例如Kubernetes,已经内在支持了广泛的存储插件，典型的可分为两部分。首先是文件存储，例如 CephFS、GlusterFS、NFS等。CephFS, GlusterFS尽管有庞大的社区的支持，但成熟度上还需要进一步验证。同时在大型集群的环境下它们还无法达到企业级稳定性、可靠性的要求，在高可靠、高性能场景也有着架构上的不足。而NFS在性能上存在不足。其次是块存储，例如Ceph RBD、SAN存储等。对于这类存储，本身并不支持多读写的需求，而对复杂的容器业务系统又是强需求。

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

　　值得注意的是，从2018年Gartner技术趋势图中，我们发现专门针对容器应用场景的持久化存储Container-Native Storage正处于明显上升趋势。那么Container-Native Storage 与企业日常的存储有什么差别呢?可以用四句话来诠释，首先它专门为支持容器而设计;其次它能够满足应用的扩展以及性能需求;第三它与容器管理系统深度整合;最后它支持大量系统的并行访问。

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

企业级容器存储的五大特性

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

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

　　第二，丰富的读写模式支持。为了满足业务的需求，容器存储对于ReadWriteMany的支持也是一个必备的选项。

　　第三，数据跟随。容器数据的跟随意味着数据必须能够快速的在全局可见。

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

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

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

焱融高性能超融合容器存储完美缔造容器神话

　　纵观目前业界发展，成熟的容器存储方案还在探索的过程中。加之用户的需求量巨大，所以越来越多的容器存储产品在市场上涌现。

　　焱融云作为新一代超融合产品研发的倡导者，一直走在技术的前沿。他们认为超融合从早期支持vmware esxi到xen、hyper-v，再到kvm，随着容器应用的快速普及，新一代的超融合产品将是支持容器化应用场景的最佳实践。

　　为了实现这个愿景，2017年焱融云针对容器技术趋势预判，走访容器客户，在现有技术经验积累下提早技术布局，打造了焱融高性能超融合容器存储，并最终在2018年6月推出国内第一家企业级Container-Native Storage产品，完美支持容器存储场景。而据记者了解，该产品具备以下七大优势。

　　首先，它具备高性能分布式文件接口，全分布式元数据集群;

　　其次，支持容器以及Namespace级别的Quota配置，QoS限速;

　　第三，它与容器平台的深度整合。在KubernetesV1.10.5以下版本中，可使用 Flex Volume插件支持静态与动态的卷创建。在KubernetesV1.10.5及以上版本，可以使用CSI plugin支持静态与动态卷的创建;

　　第四，它支持RWO/ROX/RWX三种访问方式，满足各种应用对存储的使用要求，并且针对不同的访问方式做深度优化;

　　第五，它的高性能客户端以及缓存层，提高数据访问的效率与性能;

　　第六，它有效控制了故障以及扩容的场景下对业务数据的影响，在大规模集群场景下相比其他方案对容器应用影响时间、范围最小;

　　第七，打造了优异的高并发任务下的读写性能;

　　最后，它支持融合、分离的多种部署方式。

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

革命，才刚刚开始

　　以虚拟机形式呈现的服务器虚拟化花费了十年才替代掉企业数据中心中应用程序专用的物理服务器。现在，容器化应用程序似乎将会在一两年内替换许多完整的虚拟机应用。而在这其中，最大挑战在于我们能否为容器快速提供企业级持续性数据存储。

　　不得不承认，当下容器持久化存储依然有待发展和成熟，焱融云正努力持续创新，为开发人员和管理员提供更加无缝的体验，帮助他们在容器化环境中管理存储，从而加速企业的容器和微服务的革命。

　　革命，才刚刚开始。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。