我和我的客户已经在 AWS 上合作了很长时间，但现在我需要削减成本才能继续提供服务。在 AWS 上，我使用 RSync 保持某些文件夹同步，使用 DRDB 提供高可用性和透明故障转移，始终为每台客户端计算机提供可操作且随时可用的镜像。
现在我不能继续使用 DRBD，因为我正在迁移的更便宜的云解决方案只为每台机器提供一个只有一个分区且没有 LVM 的 Ubuntu 14.04 LTS，这个云平台也成为我的一些客户的必需品。
我正在考虑的解决方案是将 shell 脚本安排到一侧的每日 BKP，通过 SSH 将其传输到另一侧并恢复 BKP，这会变得复杂、容易出错，并且需要大量的工作来开发和管理。
我的许多客户只是 Wordpress+Mysql 并接受一天的延迟，我正在寻找替代方案来提供“高可用性”，即使它会带来一天的延迟，也不会迫使我为受限上下文中的每种情况开发和管理脚本。
答案1
如果您确实无法使用块设备（DRBD 可能更适合并且您已经有使用它的经验），GlusterFS 可以为您提供您在文件级别寻求的复制功能。
Gluster“砖块”，虽然理想情况下是具有自己的以 XFS 结尾的薄 LVM 堆栈的单一存储设备，但实际上可以是节点上的任何符合 POSIX 的文件系统（甚至只是一个目录，而不是专用的 FS）。
这些砖块被聚合成一个统一的“卷”，具有“副本”策略，该策略定义现在许多砖块将使用任何给定的文件进行写入 - 在这种情况下可能是副本 2 或 3。如果可能的话，这些副本将努力位于不同的节点上。
Gluster 的故障语义还不如 DRBD 那样连贯。裂脑情况更容易实现，因为数据复制是连接客户端的责任（它将所有写入的 N 个副本发送到每个 Gluster 节点，而不是写入然后复制数据的主节点）。但是，由于使用复制时每个砖块都是一个完整的文件系统，具有完全可读的数据，因此解决具有不同数据的裂脑可能更容易。
它不会像 DRBD 那么快，但也许你不需要它？