我目前正在考虑将我们的一些服务器和应用程序迁移到核心操作系统环境。我在这里看到的一个问题是持久数据的管理，因为 coreOS 在将容器移动到新机器时不会处理 Docker 卷。经过一番研究，我发现集群文件系统据称它是一个可以解决我所有问题的集群文件系统。
我目前的想法是这样的：我有一个 glusterFS 容器，它作为特权容器在我的每台 coreOS 机器上运行，并公开一个存储，/mnt/gluster例如。在我的Dockerfiles 中，我指定所有卷都应安装在此路径上。
我接下来考虑的是哪些容器应该获得自己的卷，哪些容器应该共享一个卷。例如，每个mysql容器都会获得自己的卷，因为它能够自己处理复制。我不想弄乱这一点。为同一网站提供服务的 Web 服务器应该使用相同的卷来存储“用户上传的图片”等内容，因为它们无法复制这些数据。
有人尝试过这样的事情吗？或者我遗漏了什么吗？
答案1
我们已经部署了类似的设置与Atomic（http://www.projectatomic.io/) 而不是 CoreOS，而是使用具有三个 replica-2 集的复制非分布式 GlusterFS 存储系统。这非常有效。
但是，您需要记住 GlusterFS 的一些特殊特性。正如 Brian 之前提到的，Gluster 将一致性和可靠性放在首位。更改越频繁，复制就越多。这会给您的系统带来很大（我的意思是非常大）的压力。
注意确保你的 IO 子系统速度快（呃，它是存储），使用最快的网络连接连接你的 Gluster 节点。如果你只有 GBit，那就聚合吧！最后但并非最不重要的是，存储系统必须具有强大的计算能力，Gluster 会进行大量计算来检查其状态。话虽如此，即使在高负载下，Gluster 也能满足要求。
重新考虑您的 MySQL 策略。Gluster 为您进行复制，并在交付中提供某种负载平衡。使用 Gluster 实际上可能更快。
答案2
glusterfs 的使用取决于您使用的存储后端。作为集群文件系统，它旨在将物理存储集群化，使其看起来像一个大的连续卷。这官方快速入门指南对该过程有很好的解释。
如果您的设置使用两个或更多单独的后端存储服务器或类似的东西来存储所有 docker 卷，那么使用 glusterfs 或其他类似的并行文件系统可能会带来显着的性能优势。如果是这种情况，您还可以考虑使用光泽，它在 HPC 社区中被广泛用作并行文件系统。
话虽如此，调整、调试和配置并行/集群文件系统可能是一项耗时的任务，需要大量的专业知识、耐心，有时还需要从头开始的意愿。明智的做法是确保并行文件系统提供的性能优势值得为设置和维护它付出的努力。