将Docker卷存储在glusterfs中是一个好主意吗？

我目前正在考虑将我们的某些服务器和应用程序迁移到coreOS环境。我在这里看到的问题之一是持久性数据的管理，因为将容器移至新计算机时coreOS无法处理Docker卷。经过一些研究，我发现glusterFS声称是可以解决我所有问题的群集文件系统。

我当前的想法是：我有一个glusterFS容器，该容器在我的每台coreOS机器上作为特权容器运行，并公开一个存储，/mnt/gluster例如。在我Dockerfile的文件中，我指定所有卷都应安装在该路径上。

我考虑的下一件事是哪些容器应该获得自己的卷，哪些容器应该共享一个。例如，每个mysql容器都有自己的卷，因为它能够自己处理复制。我不想搞混。服务于同一网站的Web服务器将正确使用相同的卷来存储“用户上传的图像”等内容，因为它们无法复制这些数据。

有没有人尝试过这样的事情，或者我错过了什么？

我们已经使用Atomic（http://www.projectatomic.io/）而不是CoreOS 部署了一个类似的设置，并将其部署到具有三套replica-2套的复制的非分布式GlusterFS存储系统中。这很好。

但是，您需要牢记GlusterFS的一些特殊特性。就像Brian已经提到的那样，Gluster首先将一致性和可靠性放在首位。更改越频繁，复制就越多。这给您的系统带来很大压力，我的意思是很多。

请注意，您的IO子系统要快（不是，它是存储），用可用的最快网络连接来连接Gluster节点。如果只有GBit，请汇总！最后但并非最不重要的一点是，存储系统必须具有强大的计算能力，Gluster进行了大量计算以检查其状态。话虽如此，即使在高负载下，Gluster也能实现。

重新考虑您的MySQL策略。Gluster为您执行复制，并在交付时提供某种负载平衡。使用Gluster实际上可能更快。

glusterfs的使用将取决于您所使用的存储后端。作为群集文件系统，它旨在群集物理存储，因此它看起来像一个大的连续卷。该官方快速入门指南对过程进行了很好的说明。

如果您的设置使用两个或多个单独的后端存储服务器或类似的东西来存储所有docker卷，则使用glusterfs或其他类似的并行文件系统可能会提供明显的性能优势。如果是这种情况，您还可以考虑使用Luster，它在HPC社区中被广泛用作并行文件系统。

话虽如此，调试，调试和配置并行/群集文件系统可能是一项耗时的工作，需要大量的专业知识，耐心，有时还希望从头开始重新启动。谨慎的做法是，确保并行文件系统所提供的性能优势值得安装和维护所需的精力。