转载

持久化存储对容器来说真的适合吗?

【编者的话】持久化存储对于容器来说是否真的适合？本文作者主要围绕十二要素设计模式及容器架构方面对这一话题发表了自己的见解。

持久化存储对容器来说真的适合吗?

容器的持久化存储究竟有何价值是我最近一直在思考的一件事情，因此我也希望我本人以及我所听到的一些其他人士的见解能够引起大家对于这一问题更多的关注。尤其是，那些我所能想到的比我聪明并且深入探讨过这一问题的人所发表的观点，他们之中，比如有来自 EMC{code} 的 Clint Kitson ， SolidFire 的 John Griffith ， ClusterHQ 的 Ryan Wallner ，以及 IBM 的 Shamail Tahir 。

考虑到有些朋友对于这个话题还很陌生，请允许我先快速介绍一些相关的历史背景。近几年，容器正迅速成为遵循 12要素应用设计模式的云原生应用的标准部署单元。这些模式里讨论到的其中两个便是无状态应用程序以及支持服务。它的理念便是一个容器运行一个应用程序，应用本身应该是无状态和临时性的，需要持久化的数据则写到像一个存储卷上的数据库这样的支持服务。但即便如此，支持服务也应被视为和容器是松耦合的，并且可以在任何时间被换出，而不需要对应用程序作出任何重大变更的附加资源。传统观点认为，既然如此，那么容器应该尽可能的避免使用支持服务作为持久化存储，甚至于哪怕是用到了持久化存储，他们也应该是弱耦合地关联上，而不应该采用那些很难换出的存储资源。至于后者的具体例子的话，大概可以包括像对象存储这样通过URL访问而不会紧耦合地挂载到本地。此外，在给定容器用于一个云原生应用时应该具备临时性特征的前提下，富数据及弹性基础设施服务的解决方案也不应当再需要支持持久化存储。最后，云原生应用应该被设计成向外可扩展的，但是倘若容器必须关联上那些紧耦合到容器宿主机上并且不是默认可扩展的存储资源的话它将很难实现这一点。关于这块这里如果要展开讲的话还有很多，限于篇幅，这块内容我将会留到之后的文章。

尽管如此，仍然有一部分人坚持（一语双关）为容器带来持久化存储的想法，尤其是块卷这样的事务存储。这里面有多重原因。某些案例里，一个应用需要数据落地并且像对象存储或者网络文件系统这样的后端可能无法满足它的性能需求；这里面最典型的莫过于一个像MySQL或者Postgres这样无法设计成同NoSQL数据库那样向外扩展的SQL数据库。又比如，一个正在迁移到容器及云原生应用的企业可能希望尽可能利用现有的技术，例如一个存储阵列。为了满足这一需求，一些开源的解决方案也应时而生，它们是：

Docker的可插拔存储卷 —— 允许Docker容器将数据存储在第三方的存储系统，比如Ceph，EMC存储等。
ClusterHQ的Flocker —— 允许一个数据卷和它的容器从一台容器宿主机迁移到另外一台上。
EMC的Dogged项目及REX-ray项目 —— 将卷管理嵌入到Docker里并且使得持久化存储更易于实现。
针对Docker数据卷的SolidFire插件 —— 在Docker环境里提供了使用SolidFire存储集群作为后端设备的功能。

如果想了解这些解决方案更多的详情，可以点击上述链接来查看相关项目的具体文档。

那么针对容器的持久化存储，我所担忧的地方到底在哪呢？这里面我想指出的有两点 —— 一个是架构上的，另外一个则是行为方面。简要起见，我会尽量保证我的论述简明扼要。

架构 —— 我经常说，单个容器如何跑起来并不算是一个特别有趣的问题;真正的挑战来自于大规模下的容器管理。在只有几十或几百容器的小环境里，持久化存储实现的糟糕架构可能并不会成为一个问题。但是一旦增长到成千上万的容器规模时，情况就不是这样了。当大量容器都是临时运行并且不断迁移或者说在新的容器宿主机上重新实例化时，它们所依赖的持久化存储如果是紧耦合到特定容器宿主机的话将会极大地影响到整个容器架构的可扩展和弹性伸缩能力。试想一下构建一个大型云原生应用所使用的容器宿主机依赖于SAN存储来实现持久化的场景吧；你的可扩展能力会被牢牢限制在可以连接到相同的SAN存储卷的服务器数量。又或者甚至于如果你使用像ZFS这样的共享文件系统来实现持久化的话，从一个容器主机移动到另一个卷所需的时间通常要比新起一个容器更久一些。这就产生了一个容器里快速拉起一个应用的需求与挂载持久化存储层必需的耗时两者之间的相互冲突。
行为模式 —— 我同样也认为对传统的存储模式及解决方案的依赖恰恰正是加深了对云原生设计的反模式。我已经看到一些这样的案例，用户已经将整个应用服务器，包括他们对于传统存储的依赖，从虚拟机迁移到了容器，然后他们就开始纳闷为什么他们无法得到容器理应带来的全部收益。通过提供更多的持久化存储选择，我们是否在将用户引导偏离像12要素应用这样的云原生应用的设计模式，然后使得他们背离未来的趋势？正如我经常说地那样，每一个架构方案必然会附带一些必须遵守的约束。我们不应该暗示用户，他们可以使用旧的设计模式，然后仍然可以得到云原生应用程序容器所能带来的全部收益。

这里面也许还有很多值得讨论，这里我先告一段落... 当涉及到具体技术层面时我并不是一个顽固派，并且我也不相信我们就应该抛弃所有的持久化存储方案。我同意对于容器而言持久化存储同样也有一席之地的观点，但是前提是它正确地定位到了当前出现的一些问题，并且我们愿意去教导和帮助用户去了解他们自身所处环境的限制。有时候如果一个存储解决方案仅仅只是“技术上”可行的话其实也就意味着对它的否定，因为它没有遵循一个正确的设计模式。或许这也意味着所有为容器提供的持久化存储均需遵循所谓的云原生设计模式。最起码，它意味着我们需要让用户获悉关于这些持久化存储解决方案的具体利弊。

我衷心地希望这篇文章可以开启一个关于这一话题的积极讨论。如今我已经表达了我想说的，还有Clint, John, Ryan, Shamail, 以及其他人的见解，哪一位道出了你的心声呢？

原文链接： is-persistent-storage-good-for-containers （翻译：吴佳兴)

相关文章：容器的持久化存储（二）

原文 http://dockone.io/article/1127

正文到此结束