容器定义存储(CDS)—存储技术的"瘦身"革命



容器定义存储(CDS)—存储技术的"瘦身"革命

ICT架构师技术交流 2016-09-09 19:42

容器技术是最快被数据中心所广泛接受和采用的技术之一，从2013年起，据统计Docker的下载量已经快达到30亿次，容器已经彻底改变了应用部署方式，但是IT基础设施的管理却没有及时跟上。

今天我们就谈谈容器技术在存储中的应用，除了EMC Unity统一存储采用容器实现NAS、复制等增值特性之外，目前已经有初创存储厂商推出容器定义存储(CDS)产品，由于内容太长，所以打算分上下两期来讲。第一讲主要介绍容器如何改变应用部署方式、为什么要通过CDS实现数据中心"轻量化"。下一讲将介绍一个CDS产品和公司(Portworx)，希望分享的一些观点和趋势能对我们国产存储的发展带来一些启示。Portworx是一家美国存储初创公司，它研发了业界第一个容器定义存储系统，基于容器构建，采用容器控制面和数据面实现，致力于为应用容器提供企业级特性、完全媲美裸金属性能的存储系统。

目前SDS和SBS存储产品，使得我们很容易从喜欢的商业服务器获取存储容量和服务，硬件节点可以同时提供计算资源和存储资源(融合架构)，融合了计算和存储能力。但这些存储方案缺少一个全新设计的软件架构，用来部署应用软件和容器，充分利用服务器计算的商品化和微服务化趋势。

就拿传统专业存储为例，管理和运维需要非常专业的技能，需要了解FC，SAN交换机，iSCSI，NFS和CIFS，FCoE等专业知识，如果你想得到企业级存储服务，就必须了解专业存储每个技术和配置细节。

看了这张图片，这一切显得的多么复杂和古老。如果你想建立一个敏捷的数据存储，这或许不是你想看到的画面。回想一下，今天我们是否可以在一个2U外形类似服务器上部署类似存储系统。谷歌、Facebook和其他大型数据中心作为现代数据中心架构的领头羊，已经有团队用专业的技能来建立一个分布式的容错存储系统，利用x86架构的计算和存储。我们看到的只是一堆物理基础设施，通过Scale out x86服务器提供非常易用的存储服务。

随着现代数据中心的发展，新的应用形态(Cloud-native、DevOps、Micro Service等)都要求基于云平台构建(Cloud-native)，这对存储体系结构又有了新的要求，这些要求主要体现在以下几个方面。

• 面向服务的存储配置: 过去基于一个物理服务器或虚拟机配置存储卷的技术、依赖于FCoE、iSCSI等协议的技术已经落后了。

• 卷服务粒度更细、数量更多: 在最现代化的服务模型中，如NoSQL和消息队列，通常被设计成大规模扩展方式。他们部署时需要存储支持更多卷数量、更小的卷容量。而不像过去，一个计算节点通常映射一个大容量卷来提供数据库等应用。

• 存储本地多层化: 目前服务器至少有两个存储层级。基于全球客户服务器采购的实际情况来看，数据中心的服务器来自不同的供应商的多种服务器，不同服务器具有不同的内部容量层。客户希望新的存储结构来理解这些变化和不同，并能自动利用不同存储提供存储服务。

• 存储超融合化: 新服务架构要求数据计算和存储融合。以Hadoop为例，在计算是派遣到服务节点上运行的主机数据。

• 多服务颗粒存储操作: 新型应用程序不是单一的堆栈。而是通过部署在多个节点上的分布式模块进行业务交互组成。企业存储的操作，如快照、检查点还原、复制、配额等，需要提供服务堆栈级别上的支持。所以，我们的存储系统需要能意识到一组分布式x86服务器通过以太网织物绑在一起。

在数据中心中，硬件结构的现状一般是，来自不同供应商的服务器各自为政，不同存储容量和不同类型的服务器并存，Top of Rack交换机的能力也不同，而运行其上的软件是以一个更高的粒度，通过松耦的一组容器化服务运行在不同节点上。那么，我们该如何扩展存储层来与大量相对较薄的服务一起工作呢，当然，常用的做法就是将堆栈拆分成独立的数据可用区和计算区，根据不同SAL的应用需求匹配相应的存储资源。

实质上，上图就是一个容器感知存储架构，该架构要实现如何根据存储需求将数据放置在容器的位置区。这种架构可以支撑一个更大的容器计算集群，同时可以保持存储的性能和时延要求。

面对更细粒度的、自恢复和可发现的面向服务的应用架构，存储也不应该有任何核心的集中元数据服务器，元数据应该分布式存放和去中心化存放，并通过负载均衡等算法或检测协议(Gossip Protocol)实现高效的故障自愈系统和高可靠系统。

Gossip Protocol的通信方式类似流言传播，每个节点状态的变化和更新，立即通过一传十，十传百的方式在集群内广播，而不是由某几个节点逐一传递，所以通信效率非常高效。

为了让存储能感知容器，存储调度也需和容器引擎集成，随着应用软件向更为面向服务的体系结构演进，应用软件的业务流程和调度也发生了变化。我们不再需要手动管理进程，而是自动实现软件的启动、停止和生命周期管理，对软件的运行和SLA需求也要实现自动化。这就要现代流行的调度器来完成，如Mesosphere，Kubernetes，Swarm，Spark等。

新的应用架构都是深度集成这些容器调度器，DevOps开发团队的工作也是基于容器调度器和编排工具进行，所以，对软件定义存储，容器定义存储等基层设施层来说，就可以直接跟这些调度或业务编排层实现集成。这对数据中心实现“轻量化”来说，也变得比较迫切。

容器在单个操作系统运行多个应用，由于它的轻量特性也给应用部署带来很多优势，如占用资源少、启动快、容易部署等，其高效率也意味着数据中心需要较少的硬件和物理空间开销，Docker也是因为开源和强大生态而被全球范围内的企业拥抱。但是容器的应用还是局限在公有云、网站、无状态的应用，还没有大规模进入到数据中心主要业务。一个主要原因是现有容器是基于无状态业务进行优化，到目前为止，还没有健壮和易管理的方法存放有状态的数据，这也跟容器每次访问完后就终止进程的架构有关。

分布式扩展存储架构在设计时，就需要考虑如何以面向服务的数据中心提供不同的存储类型。 面对服务访问所需的多进程、多volume、高吞吐量等诉求时，存储需要从许多运行在不同机器的节点，提供一致的存储服务访问。有时这些容器甚至运行在云上或其他数据中心。面向服务的应用类型包括了:

• 无状态服务: 这些通常是短暂的计算作业，他们依靠一些其他状态的服务实现具体业务。

• 状态数据库服务: 这些通常需要块存储或非共享存储访问。

• 有状态的服务需要的文件或对象访问: 常见的有全局文件或对象的命名空间。

然而，在云计算高度发展今天，新型应用基本上基于Docker等云基础设施构建的Cloud-native应用，而不是从传统物理设施上迁移到云平台的Cloud-based业务。Cloud-native大多采用Micro Service或容器部署，就要求与之相匹配的存储提供存储服务。

为了推进“轻量级”下一代数据中心架构，并充分利用容器技术的特点，数据中心也在面临一场变革，需要替换原来臃肿的架构和基础设施，采用容器架构和容器存储技术来支持业务系统。今天就介绍到这里，下篇我们重点介绍基于容器Portworx存储、一个基于数据和控制面的容器定义存储技术和产品。

文章来自ICT架构师技术交流“ICT_Architect”公众号，关注获取更多精彩内容。

温馨提示：

请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号，获取更多精彩内容。