我能找到的有关 GlusterFS 复制卷的任何教程都假设两个（所有）块都在同一个专用网络上，这也导致得出结论，它们必须位于同一个数据中心。
例如“问题是，当你想复制到的存储位于远程网络（可能位于不同位置）时，GlusterFS 无法很好地工作。这是因为 GlusterFS 的设计不适合在复制节点之间存在高延迟时工作。”引自https://github.com/GlusterFS/Notes
还https://gluster.readthedocs.io/en/latest/Administrator%20Guide/Geo%20Replication/说复制卷不是为了地理复制而设的，然而 GlusterFS 中真正的“地理复制”机制只创建只读从属，而这并不适用于所有情况。
所以问题是，为什么一般不推荐这样做，因为我还没有找到不同网络上的主机甚至不同数据中心的复制卷的单个示例。
我还可以解释一下为什么我想使用复制卷。我在德国法兰克福的数据中心有一个 vServer (OpenVZ)，在德国纽伦堡还有一个。两者都与 DE-CIX、德国电信等有多个对等连接，并且 vServer 之间的延迟小于 4 毫秒，在我看来，这不能被视为高延迟，无论 GlusterFS 对此的定义是什么。
我在两台服务器上都运行 iRedmail 服务，MariaDB 在主主复制中复制，仅存储邮件配置。邮件存储在磁盘上，我使用 GlusterFS 复制卷来复制它。到目前为止我没有发现任何问题（邮件存储大约 20 GB 的电子邮件，包括附件），我想知道我是否只是运气好，或者是否存在我尚未检测到的问题。无论如何，我更喜欢遵循最佳实践，而我在这种情况下没有这样做，我想知道您对不同数据中心主机的 GlusterFS 复制卷的看法以及“高延迟”实际上意味着什么。
答案1
此问题不仅存在于 GlusterFS，还存在于多种类型的数据存储中。这是因为距离增加会导致延迟增加。建议位于同一子网中，以减少因网络跳跃而导致的延迟。
为了保持数据同步，各个服务器必须确保所有服务器都具有相同的数据视图。对于数据读取，延迟效应通常不是问题。但是，如果多个服务器在同步之前写入同一个块，则可能会发生严重的数据损坏。当更新数据块时，可能会丢失更改，如果正在更新的块是在另一台服务器上的后续更新之前读取的，则数据可能会丢失。
可以使用锁定机制来降低损坏风险。但是，随着延迟的增加，分布式锁的获取和释放时间会更长。在这种情况下，延迟是服务器之间完成往返的时间。数据中心之间通信时有三个因素。
邮件数据存储往往是读取最多的。通常，连接到不同服务器的多个客户端不太可能更新同一个文件或目录。传入的电子邮件消息和读取它们的客户端之间可能会存在一些争用，但延迟不应该是一个重大问题。Maildir 格式的存储应该比其他格式的争用相对较少。但是，它们的重命名和移动活动相对较多，如果您的节点断开连接，可能会导致问题。
- 距离：有线数据在有线上的传输距离约为每纳秒 30 厘米，每微秒 300 米，每毫秒 300 公里。随着距离的增加，延迟会显著增加。
- 交换时间：数据包经过的每个交换机都需要检查、路由、排队和传输数据包。这会增加额外的延迟，并且随着交换机越来越忙，延迟也会增加。
- 网络拥塞：网络可能会拥塞，导致流量排队时间更长，并可能重新路由，从而造成额外延迟。如果拥塞严重，延迟时间可能足够长，从而触发数据包重新传输。