设置
我管理一个网站的后端，该网站目前位于一个节点上，使用 Nginx（Web 服务器）、Neo4J（数据库）和 Wildfly（应用服务器）。该网站的流量很大，以至于我们在当前的“一体化”节点上都受到存储和内存资源的限制，因此我又实例化了两个 VPS 节点（总共 3 个），这些节点将仅运行 WildFly。
我已成功配置 Nginx，以根据网站 URI 中包含的用户 ID 在 3 个节点上使用“哈希”负载平衡功能，以确保用户始终路由到运行 Wildfly 的同一 VPS 节点，以优化缓存。
3 个节点中的每一个都有自己的 150GB 高可用性块存储（由 VPS 提供商维护），其中包含一个/images安装的目录，Wildfly 应用程序将在其各自的节点上从/向其读取/写入图像文件。
更新
图像文件应该是一次写入/多次读取的（至少在名义情况下），因此新图像会一直被创建，但现有图像很少被更新。此外，由于 Nginx 的哈希负载平衡，每个 Wildfly 节点应该拥有路由到它的客户端所需的所有映像。复制的需求实际上有两个方面：
- 由于每个节点都拥有来自其他节点的所有数据，因此可以透明地添加或删除 Wildfly 节点
- 由于所有内容都集中在一个地方，因此备份更加容易
此外，每个 VPS 节点都是私有千兆 VLAN 的一部分，VPS 提供商为同一数据中心内的所有节点（我的所有节点都是其中之一）启用该 VLAN。复制数据将遍历此链接。
问题
由于应用程序现在是分布式的，我希望/images3 个节点上的每个目录都能完全复制。尽管 Nginx 的“哈希”负载平衡可确保每个用户的节点使用一致，但我希望目录的内容/images是所有三个节点的并集，以防其中一个节点发生故障，需要将用户重新分配到其他可用节点。
问题
解决上述问题的最佳方法是什么？据我所知，rsync这不是适合这项工作的工具。有这个服务器故障问题其本质上是相似的，但已有 12 年的历史了，而且我确信从那时起数据复制方面已经取得了一些进展。
在我的研究中，我偶然发现集群文件系统这看起来很有希望，但不清楚如何设置它来解决我的问题。我是否应该将每个节点上的每个高可用性块存储设备都设为单个“砖块”，然后将其组合成单个 Gluster 卷？我假设我随后/images在此单个 Gluster 卷上创建目录，并通过本机 FUSE 客户端将其安装到每个节点？我的直觉告诉我这是不正确的，因为每个节点同时是客户端和服务器，因为它们都贡献了一个“砖块”并读取/写入 Gluster 卷，这似乎不合常规。
答案1
SAN 模型假设您拥有高可用性块存储服务 - 您可以在文件级别实现相同的服务 - 但这意味着添加更多节点（或在现有主机上增加额外工作负载）。而使 NFS 具有高可用性则有点棘手。
块级复制的另一种选择是使用 DRBD。但对于传统文件系统，让文件系统由多个主机挂载并不是一个好主意。它可以与 GFS2 等结合使用。但这仍然相当复杂和深奥。结合反向代理上的 HTTP 缓存，您可以将缓存作为首选位置，其次是“主”Web 服务器，并将本地存储作为第三个后备选项，这意味着您仍在处理本地文件系统上的大多数读取，但只有在节点关闭时才会出现复制滞后的问题。
然后有复制的文件系统 - GlusterFS 可能是这里最好的选择，并且您对其工作原理的解释似乎是准确的 - 但您的担心并不准确；这正是 glusterFS 预期的使用方式。
您提到了 VPS：虚拟机管理程序可能已经提供了跨多个主机共享块设备的机制（例如 AWS 上的 io2、Proxmox 上的共享卷和目录存储），但您仍然需要在这里使用并行文件系统（GFS2）。
这里简单提一下 ZFS 复制 - 它很棒但实际上只在 2 个节点之间有效。
但实际上你的选择取决于你在问题中没有提到的两个具体条件：文件变化的速度有多快？它们是如何变化的？也许你所需要的只是同步（文档中有指向其他解决方案的链接）或者甚至 rsync。