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

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

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

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

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

架构——我经常说，单个容器如何跑起来并不算是一个特别有趣的问题；真正的挑战来自于大规模下的容器管理。在只有几十或几百容器的小环境里，持久化存储实现的糟糕架构可能并不会成为一个问题。但是一旦增长到成千上万的容器规模时，情况就不是这样了。当大量容器都是临时运行并且不断迁移或者说在新的容器宿主机上重新实例化时，它们所依赖的持久化存储如果是紧耦合到特定容器宿主机的话将会极大地影响到整个容器架构的可扩展和弹性伸缩能力。试想一下构建一个大型云原生应用所使用的容器宿主机依赖于SAN存储来实现持久化的场景吧；你的可扩展能力会被牢牢限制在可以连接到相同的SAN存储卷的服务器数量。又或者甚至于如果你使用像ZFS这样的共享文件系统来实现持久化的话，从一个容器主机移动到另一个卷所需的时间通常要比新起一个容器更久一些。这就产生了一个容器里快速拉起一个应用的需求与挂载持久化存储层必需的耗时两者之间的相互冲突。

行为模式——我同样也认为对传统的存储模式及解决方案的依赖恰恰正是加深了对云原生设计的反模式。我已经看到一些这样的案例，用户已经将整个应用服务器，包括他们对于传统存储的依赖，从虚拟机迁移到了容器，然后他们就开始纳闷为什么他们无法得到容器理应带来的全部收益。通过提供更多的持久化存储选择，我们是否在将用户引导偏离像12要素应用这样的云原生应用的设计模式，然后使得他们背离未来的趋势？正如我经常说地那样，每一个架构方案必然会附带一些必须遵守的约束。我们不应该暗示用户，他们可以使用旧的设计模式，然后仍然可以得到云原生应用程序容器所能带来的全部收益。

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

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

原文发布时间为：2016-03-16

本文作者：colstuwjx

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：持久化存储对容器来说真的适合吗?