我正在寻找一些在我之前做过的人的指导和build议。 我有一个Web应用程序托pipe在一个单一的VPS。 现在，我正在build立基础设施来扩大并使其高度可用。
我愿意使用两个Web服务器来托pipe我的Web应用程序文件+用户文件（如图像）。 所以当我需要在两个节点上复制文件时，我打算使用glusterfs（每个节点同时是gluster-server和gluster-client），如果只有2个节点，很多人都推荐使用它。
我已经成功设置它，它的作品像一个魅力，但我有一个特定的需求，我不知道如何实现它，是否可以通过glusterfs或任何其他软件可行。
与其他任何应用程序一样，您总是修复错误并添加新function，然后取下生产网站进行维护，以便能够应用修补程序并复制新的Web应用程序内容。 有没有这样做的机会：
这是棘手的两节点Gluster实现。
我们碰到的第一个问题是处理你们故意创造的裂脑情况。 在你描述的场景中，你将只修改一个节点，然后修改Gluster客户端复制以外的另一个节点。 Gluster本身不会在节点之间进行复制，而是依靠客户端以扇出方式同时写入和读取所有节点。 因此， 客户机主要负责“复制”，而不是服务器到服务器的复制。 所以我们确实需要确保客户端可以随时访问所有相关的Gluster节点。
当你在造成裂脑后将两个砖块连接在一起时，你会发现Gluster拒绝继续激活音量，直到你在砖块级别手动修复裂脑问题。 它会帮你告诉你什么是脑裂，但你已经知道，因为你会是直接负责任的一方。 这是因为只有两个节点，并且在分析数据是否应该从“显性”拷贝覆盖时，没有第三个节点充当仲裁者。 3n Gluster卷在大多数情况下可以自愈，但不能保证你想要的那种行为。
为了避免这种情况，如果您仍然打算使用GlusterFS，则需要对策略进行认真的反思。 Gluster的devise目的不是故意的脑裂，也不是传统的“故障转移”系统。 它旨在同时在所有节点上访问，并且可以使用多数规则处理节点故障（或延长离线手动干预）。
一个合理的GlusterFS解决scheme ：
您可以在节点上创build一个新的GlusterFS卷，并在节点上安装该节点，以便在通过HAproxy停止服务之后，将其写入新的Web内容。 然后切换到该节点并在其他节点上安装相同的GlusterFS卷。 完成后放弃旧Gluster音量。
这会改变你的步骤：
1）因为我打算使用HaProxy作为负载均衡器，那么我可以将node1的状态更改为维护，并让node2处理所有stream量。
2）在两个节点上从新砖创build一个新的GLusterFS卷，并将该卷挂载到处于维护模式的节点的app / web目录中，首先卸载原始卷。
3）将所有相关的新的和未更改的数据复制到这个新的Gluster卷。
4）从HaProxy取下节点2进行维护，并占用node1处理stream量。
5）在节点2上安装新的Gluster卷，首先卸载旧的Gluster卷
6）让HAproxy重新进行负载平衡服务，因为我们将再次有一个工作的主动/主动集群。
7）当我们不再需要时，摆脱旧的GlusterFS卷。
这将确保你保持在线服务，并没有得到一个可怕的裂脑情况。 关于你的砖块：砖块只是一个目录，并不一定是一个单独的文件系统。 你可以通过在文件系统的根目录下使用一个不同的目录来将你的新砖与旧砖放在同一个文件系统上。 这样你就不需要一堆磁盘空间来进行在线服务更新。
另一种解决scheme ：
DRDB处理服务器到服务器复制环中的数据，您可以强制一个节点任意复制到其他节点。 对于主动/主动负载平衡集群来说，这不太好，因为你必须在OCFS2之上使用文件系统。 但是，这是一个传统的复制系统，会高兴地坚持你目前的计划。
澄清 ：
您不需要三节点集群来实现上述的GlusterFS计划。 两个节点将会很好。