容器的持久化存储

jopen 9年前

【编者注】本文是该系列的第二篇文章,讨论了容器的持久化存储的问题。从持久化的定义到持久化的理解,并且对目前容器持久化的三种方案进行了回顾。尽管本文只是个概括性的介绍,但对于理解容器的持久化存储还是很有帮助的。

本篇文章是 前一篇 文章关于询问“持久化存储对于容器是否是个好主意”的后续。我收到了很多关于前一篇文章的反馈,各方面的观点都有。于是,我认为值得回应一下对于持久化存储的三种"观点"。观点是加了引号的,因为我准备使用一句格言来论述:仅仅是因为你能做到,而并不是说明你应该去做。

在本文讨论持久化存储之前,先来从声明持久化存储的范畴。我已经同一些读者讨论过,在运行各类应用时如何能够不用持久化数据的。声明下,运行容器并不意味着完全摒弃数据持久化。但是,容器的传统持久层已经采用对象存储,如S3,数据库作为一项服务使用,如RDS,并且,数据库运行在虚拟机上或者裸机上。

在每个应用场景中,数据并不是存储在容器文件系统中,而是通过网络进行访问。当在这两篇博文中讨论持久化存储时,我们指的是挂载一个卷到容器宿主并且链接到容器,卷存在于容器之外,并且用于持久化事务数据。这些卷是容器宿主机上的本地存储,但它同样可以被网络文件系统和网络块存储使用。

关于事务数据持久化,我们来回顾下容器存储的三种方案:

  1. 原生云:按照纯粹的原生云的设计模式,例如那些 Twelve-Factor 应用提出的大纲。这个方案假定持久化数据并不是存储在容器中,而是作为后端服务,例如对象存储和数据库即服务。这个方案可以确保容器和它们的数据持久化支持服务松耦合,同时也不需要那些会限制扩展的依赖。弹性不是通过共享基础设施提供,例如网络存储,而是通过应用运行在容器中,容器与容器管理平台的配合工作。
  2. 把容器作为虚拟机:为了利用容器带来的应用便携性的优点,一些用户将容器作为轻量虚拟机来使用。在这种方案中,一部分直接使用遗产应用,例如Oracle,同时将他们从虚拟机中迁移到容器里。这包括挂载共享网络存储卷到容器中作为数据存储使用。尽管这种架构可以起作用,它同样带来了实际的条件和限制。例如,重启一个容器,甚至一个共享存储,已经不同于在vSphere中重启虚拟机的核模式。当一个容器在一个新的容器宿主机上重启,它的期望是这个应用能够通过重启到数据库卷链接来恢复。相对于遗产应用假定为虚拟机基础设置将处理恢复,而不是需要设计应用。同样,如果便携性是迁移到容器中的一个原因,采用它们来替代虚拟机来安装遗产应用是这种便携性的反模式。在大卷中存储数据是紧耦合在容器上,这使得便携性非难实现。像这样的限制使得一个虚拟机直接容器化存在很多问题。
  3. 混合:由于没找到一个更好的词,第三种方案我将之称为混合,利用容器和卷来应对带事务持久要求的应用。然而,与上一中方法不同,这个方案缩小持久化存储方案的应用使用场景,它不需要共享基础设施来实现弹性和恢复。例如非关系型数据库,如Cassandra,它有可用性架构在应用程序层,并且它比遗产应用程序有不同的基础设施预期。在这个方案中,持久层产生价值,不是通过弹性,而是通过可编程和灵活,例如通过优秀设计的API来扩展存储。这个方案结合了持久层和或多或少的纯原生云设计模式。

这篇文章中,我只是提供对该话题的一个整体回顾。我将会提供更多的细节关于上面提到的几个方案。同时,如果你计划参加在奥斯汀举行的OpenStack Summit,并且想听到关于这个话题的更多内容。我、来自SolidFire的John Griffith以及来自IBM的Shamail Tahir已经提交了一个关于容器持久化存储的话题。请认真考虑为这个话题投票,投票期为2月9日至2月17日。同样的,欢迎给这篇博文进行反馈、修正或者反驳。

原文链接: Follow Up Post: Using Persistent Storage With Containers (翻译:陈杰)

===================================================

译者介绍

陈杰,北京理工大学计算机学院在读博士,研究方向是自然语言处理在企业网络信誉评价方面的应用,平时也乐于去实现一些突发的想法。在疲于配置系统环境时发现了Docker,跟大家一起学习、使用和研究Docker。

来自: http://dockone.io/article/1051