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

Question

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

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

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

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

Answer 1

我们已经使用 Atomic ( http://www.projectatomic.io/ ) 而不是 CoreOS 将类似设置部署到具有三个副本 2 集的复制非分布式 GlusterFS 存储系统。这非常有效。

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

注意你的 IO 子系统是快速的（呃，它是存储），用最快的可用网络连接连接你的 Gluster 节点。如果您只有 GBit，请聚合！最后但并非最不重要的一点是，存储系统必须具有强大的计算能力，Gluster 会进行大量计算来检查其状态。也就是说，即使在高负载下，Gluster 也能提供。

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

Answer 2

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

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

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