如何进行容器的存储选择

2016年01月 · 麦子迈

在这个云计算的大背景下,越来越多的计算,存储和网络选择呈现给用户。其中计算方面就包括以虚拟化技术为代表的 KVM, XEN 等,以容器技术为代表的 LXC,Docker,OpenVZ 等。在存储上应用也面临多种类型接口的选择,如传统底层存储技术接口 Block、File 或者应用层存储 SQL,同时 NOSQL、键值和对象接口也被广泛接受。那么用户如何在云平台上选择并构建基础设施栈就成为一个重要命题。

而容器作为最近新兴的技术正受到广泛的用户关注,相对于传统虚拟化技术而言,容器技术在性能上能够利用共享内核得到更低的基准损耗,更好的资源共享,从而获得更快的启动速度。而存储技术能够通过这些固有优势获得更高效,路径更短的 IO,并且因为高度聚合的镜像文件而获得高效部署。新兴的容器 Host OS 比如 CoreOS,Atomic,RancherOS 或者 Snappy Ubuntu 都通过其微服务和卓越的运行环境而广泛推崇。

这篇文章主要从虚拟化和容器的差异讨论存储技术面对容器变迁的挑战问题和机遇。

资源粒度

那么这里我们简单的看下容器化和虚拟化的主要区别:

容器的存储选择1

虚拟化技术本质上是物理抽象,提供的是一套完整模拟物理环境的平台,从业务上也是以虚拟机为中心的应用生命周期,提供的是虚拟机粒度的隔离。因此从上图可以简单的横向切分底层虚拟平台和上层应用服务,做到应用无感知。而容器技术作为一个新热点抛弃了对于传统 IT 中心化的思想,强调对于业务层面的隔离,纵向隔离不同的应用,对于资源的利用来说粒度更加精细化。因此,延伸而出新的运行环境提供方式,微服务化,多实例,多版本并且最大化弹性和最小化损耗。而这些优势的背后即计算轻量化的麻烦是框架调度更加复杂化。

块还是文件?

从虚拟机到容器,实际上存储所面对的应用场景也发生了变化。广泛的虚拟机场景实际上相对于物理机存储需求并没有本质区别,传统的块存储接口从物理介质的特性中抽离并承载大多数存储数据,到虚拟机中块存储接口更是大放异彩,从这个角度来说,虚拟机化技术是物理机环境的强化。

而从存储场景上来看,主要是镜像盘,通用应用存储(如 HTTP/FTP/业务数据等),高性能场景(数据库/系统软件),超大容量场景(视频/日志),大数据场景。虚拟化相对于物理机存储增强了可靠性和可用性的目标。

那么随之而来的问题就是容器是否应该跟随虚拟机使用稳健的块存储接口,回答这个命题可能需要从新回头看块接口的几个特点:

1. 块是一段固定大小的字节

2. 一次读写都是以块为最小单位

3. 磁带,硬盘,NAND 闪存都是以块提供

4. 它既可能以 SCSI 或者光纤直连,也可能是 iSCSI 或者 FCoE 这样的网络通讯传输

5. 数据库和文件系统通常架设在块接口之上

6. 数据不可解释

而文件接口以文件和目录为组织形式的存储布局,通常为 POSIX 或类似协议的 API 形式,它具备更加丰富的数据语意。

在这里我们需要重新回顾虚拟化作为物理机器抽象,其承载的虚拟机具备完整的操作系统(OS Agnostic)和设备驱动栈。而容器其天生的共享并绑定的 OS 使得业务距离相对透明的”底层”仅一步之遥--VFS(Virtual File System),其语意非常丰富。从这里我们需要稍微延伸一下为什么这里强调这一点: 我们都知道传统存储一直想方设法获取应用的特点和存储负载信息来针对性服务,各种 SCSI 协议的扩展或者衍生 Tricky 从而诞生,传统存储在应用端 Agent 可能会走带外通道传递应用 IO 特征到存储系统,但这从来没有真正标准化或者起到核心作用,而 VM 的高隔离性也使得底层存储距离业务负载过远,传统存储在与应用的距离上并没有得到解决,反而更加脱节。因此,容器的应用 IO 距离容器底层系统几乎是没有任何中间层,如此丰富的 IO Hint 为存储带来的是智能化。

容器的存储选择2容器的存储选择3

而另一方面,容器所强调的 cloud-native 应用特点如 CI&CD,横向扩展构建,在应用层实现高可用,强调微服务化,与基础设施解耦无一抗拒着快接口最大的痛点--数据不可解释。而传统应用改造成容器应用的往往仍需要容器间服务内的存储共享,也迫切需要一个共享式文件系统。同时容器带来的细粒度管理使得块设备很难像虚拟机一样仍然与块设备一一对应,多个容器组成的服务往往才能与一个块设备等同。

强调了容器与块设备这么多”不协调”之处,我们仍需要看看容器相对于虚拟机的特色存储场景是哪些:

1. 一个 native 的 copy-on-write 文件系统用来 Boot

2. 一个共享文件系统用来承载一系列工具和应用信息来供给大量的容器实例

3. 大数据

剩下的仍然是高性能的 SQL 和 NOSQL 数据服务,海量对象存储系统等。

数据感知

从上段的分析来看,文件接口在容器时代似乎迎来了新的篇章。那么对应到具体场景,我们该如何利用文件接口改造整个存储底层。这里我们引入统一存储的概念,从底层本质上来说,块是一段段匿名的数据记录,每个块设备之间是完全隔离的存在。而文件接口所构建的丰富语意使得数据的目录间,系统间流动都非常自然。

容器的存储选择4

举个例子,在 AWS 的 EMR 使用模型中,用户可以利用存放在 S3 中的源数据启动大量虚拟机来进行 MapReduce 处理,获得结果仍然导出到 S3。对于典型的数据分析案例来说,原始信息对应的是海量数据在集群内的来回传输,而通常分析数据又是来源于在线业务,因此,按照 EMR 的使用模型,用户被分析数据通常需要经历从在线存储系统归档到 S3,再恢复到 Hadoop 中分析并输出结果的漫长旅程。

容器的存储选择5

如果使用文件接口作为可能的应用场景接口,那么从在线到离线分析可能仅仅是一次元数据的更新。仍然举 EMR 的使用模型,文件接口的语意可以被弱化解析成 S3 这样的对象存储协议,那么从 S3 到大数据存储系统仅仅是一次元数据的映射,而 Hadoop 完全能够直接运行在共享 VFS 之上,最后的结果也可以按照 S3 导出,而整个过程的耗时可能真正都留给了纯粹的计算逻辑。相对于之前的数据流动,整个业务的完成时间大大缩短。

这仅仅是一个场景,文件接口带来的语意复杂性的背后是一体化的数据存储。