我正在考虑将我们的一些服务器和应用程序迁移到coreOS环境。 我在这里看到的一个问题是持久化数据的pipe理，因为在将容器移动到新机器时，coreOS不处理Docker卷。 经过一番研究，我发现glusterFS声称是一个集群文件系统，可以解决我所有的问题。
我目前的想法是这样的：我有一个glusterFS容器，作为每个coreOS机器上的特权容器来运行，并公开一个存储，例如/mnt/gluster 。 在我的Dockerfile我指定我的所有卷都应该安装在这个path上。
接下来我考虑的是哪些容器应该获得自己的容量，哪些容器应该共享一个容器。 例如，每个mysql容器都可以获得自己的卷，因为它本身可以处理复制。 我不想乱搞。 服务于同一网站的Web服务器会正确使用像“用户上传的图片”等相同的音量，因为他们无法复制这些数据。
有没有人试过这样的东西，还是有什么我错过了？
我们已经部署了一个与Atomic（ http://www.projectatomic.io/ ）而不是CoreOS类似的安装程序到一个复制的非分布式GlusterFS存储系统和三个副本-2集。 这工作得很好。
但是，您需要记住GlusterFS的一些特殊特性。 就像Brian已经提到的那样，Gluster最重要的是保持一致性和可靠性。 更频繁的更改发生的越多，复制正在发生。 这意味着很多，我的意思是很大的压力，你的系统。
注意你的IO子系统是快速的（这是存储），用最快的networking连接连接你的Gluster节点。 如果你只有GBit，聚合！ 最后一点，存储系统必须运行严重的计算能力，Gluster做了很多计算来检查它的状态。 这就是说，即使在高负荷下，Gluster也能提供。
重新考虑你的MySQL策略。 Gluster为您进行复制，并在交付时提供sorting负载平衡。 使用Gluster可能会更快。
使用glusterfs将取决于您使用的存储后端。 作为一个集群文件系统，它的目的是集群物理存储，使其显示为一个大的连续卷。 这个官方快速入门指南对这个过程有一个很好的解释。
如果您的设置使用两个或更多单独的后端存储服务器或类似的东西来存储所有docker卷，那么使用glusterfs或其他类似的并行文件系统可能会提供显着的性能优势。 如果是这种情况，您还可以考虑使用Lustre ，它在HPC社区中被广泛用作并行文件系统。
如此一来，调整，debugging和configuration并行/集群文件系统可能是一项耗时的工作，需要大量的专业知识，耐心，有时还愿意重新开始。 确保并行文件系统提供的性能有益于设置和维护所需的工作量是值得的。