我正在寻求一些在我之前做过这件事的人的指导和建议。我有一个托管在单个 VPS 中的 Web 应用程序。现在我正在设置基础架构以进行扩展并使其具有高可用性。
我愿意使用两台 Web 服务器来托管我的 Web 应用文件 + 用户文件（如图像）。由于我需要在两个节点上复制文件，因此我打算使用 glusterfs（每个节点将同时是 gluster-server 和 gluster-client），如果您只有 2 个节点，这里很多人推荐使用 glusterfs 而不是 DRBD。
我已经成功设置它并且它运行良好，但我有一个特定需求，我不知道如何实现它以及是否可以通过 glusterfs 或任何其他软件来实现。
与任何其他应用程序一样，您总是会修复错误并添加新功能，然后关闭生产网站进行维护，以便能够应用补丁并复制新的 Web 应用程序内容。 有没有可能这样做：
- 由于我将使用 HaProxy 作为负载均衡器，所以我可以将 node1 的状态更改为维护，并让 node2 处理所有流量。
停止文件复制并更新node1中/var/www的内容。- 从 HaProxy 关闭节点 2 进行维护并占用节点 1 来
处理流量。 - 重新启动文件复制并告诉 glusterfs 将内容从节点 1 镜像到节点 2，而不是反之。如果有办法考虑节点 1 离线时创建的所有用户文件（在特定文件夹下），那将是一个很好的奖励。
答案1
这对于双节点 Gluster 实现来说比较棘手。
我们遇到的第一个问题是如何处理脑裂情况，这可能是您故意造成的。在您描述的场景中，您将只修改一个节点，然后在 Gluster 的客户端复制之外修改另一个节点。Gluster 本身传统上不会在节点之间复制，而是依靠客户端以扇出方式同时写入和读取所有节点。因此，客户机器主要负责“复制”，而不是服务器到服务器的复制。所以我们确实需要确保客户端可以随时访问所有相关的 Gluster 节点。
在导致裂脑后，当您将此卷连上两块砖并联机时，您会发现 Gluster 拒绝继续激活该卷，直到你在砖块级别手动修复裂脑问题。它会告诉你什么是裂脑，但你已经知道了，因为你是直接责任方。这是因为只有两个节点，没有第三个节点在分析是否应该从“主导”副本覆盖数据时充当决胜局。3n Gluster 卷在大多数情况下可以自我修复，但不能保证你想要的行为。
为了避免这种情况，如果您仍打算使用 GlusterFS，则需要认真重新考虑该策略。Gluster 的设计目的不是故意造成脑裂，也不是传统的“故障转移”系统。它旨在同时在所有节点上访问，并且可以使用多数规则（或长时间离线手动干预）处理节点故障。
一个合理的 GlusterFS 解决方案：
您可以在节点上创建一个新的 GlusterFS 卷，并在停止通过 HAproxy 向其提供服务后将其安装在您打算写入新 Web 内容的节点上。然后切换到该节点，并在其他节点上安装相同的 GlusterFS 卷。完成后丢弃旧的 Gluster 卷。
这将改变你的步骤如下：
1）因为我将使用 HaProxy 作为负载均衡器，所以我可以将 node1 的状态更改为维护，并让 node2 处理所有流量。
2）在两个节点上从新砖块创建一个新的 GLusterFS 卷，并以维护模式将此卷挂载到节点的 app / web 目录中，首先卸载原始卷。
3) 将所有相关的新数据和未更改的数据复制到这个新的 Gluster 卷。
4）从 HaProxy 关闭节点 2 进行维护并启动节点 1 来处理流量。
5）在节点 2 上挂载新的 Gluster 卷，首先卸载旧的卷
6）让 HAproxy 再次负载平衡服务，因为我们将再次拥有一个正常工作的主动/主动集群。
7）当我们不再需要旧的 GlusterFS 卷时，将其删除。
这将确保您的服务保持在线，并且不会出现可怕的裂脑情况。关于您的砖块：砖块只是一个目录，不必是单独的文件系统。只需在文件系统的根目录使用不同的目录，您就可以让新砖块与旧砖块位于同一文件系统上。这样，您就不需要大量的磁盘空间来执行在线服务更新。
替代解决方案：
DRDB 在服务器到服务器复制环中处理数据，您可以强制一个节点任意复制到其他节点。对于主动/主动负载平衡集群来说，它不太好，因为您必须在其上使用像 OCFS2 这样的文件系统。然而，它是一个传统的复制系统，很乐意遵守您当前的计划。
澄清：
您不需要三节点集群来实现我上面描述的 GlusterFS 计划。两个节点就足够了。