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