我有一个像这样的 3 层网络解决方案：
- 具有负载平衡 + 代理 + 静态内容的前端
- 后端有 2 个 Apache Web 服务器，每个服务器服务于不同的站点
- 将内容推送到 apache Web 服务器的发布系统
因此，我正在为后端的 Web 服务器开发具有高可用性的解决方案。我的想法是在后端服务器之间复制内容，如果一个失败，另一个将为所有站点提供服务（这可以是手动的或使用 Heartbeat）。
问题是这些站点在总大小和文件数量方面都很大。我尝试使用 rsync 在服务器之间复制内容，但这需要很长时间。我也想过使用 NFS 来共享内容，但这不是高可用性的选项。另一种方法是发布系统将内容推送到两个 Web 服务器，但是如果我将另一个 Web 服务器放在后端会发生什么？
有一个更好的方法吗？我不需要两台服务器同时提供相同的内容，但是必须同步相同的内容。
您确实应该考虑使用多节点文件系统（例如 OCFS 或 GFS）的 DRBD（基于 TCP/IP 的 RAID-1）。
您还可以考虑获得一个 SAN，您也可以在该 SAN 上放置这些文件系统中的任何一个。
使用 SAN 而不是 NFS 服务器，RAID 将处理高可用性。
您可以将 HAProxy + Keepalived 用于负载均衡器。对于复制，请考虑光链路，如果以太网不能满足您的需求。RSync 是非常有效的 IMAO（使用压缩数据的“-z”选项，它发现它非常有效）。至少，如果您想要高性能，您可以将两个 Apache 作为 VM 托管在同一台服务器上，并添加一些带有漂亮 RAID 卡的漂亮磁盘（15K rpm）。这应该为您提供您正在寻找的可用性
我在 Debian Lenny 上使用 Heartbeat2 进行故障转移，效果很好。我有一个 Web 应用程序，它由一个 Web 服务器提供服务，如果出现问题（例如，一个 2 节点主动-被动集群），它将故障转移到另一个。Web 应用程序数据位于文件系统和 MySQL 数据库中。我们使用 MySQL Master-Master 复制模式来处理数据库应用数据的镜像。当我们实时推送更新时，其余部分由 rsync 处理。该设置在过去 6 个月中一直在生产中运行，并且在现实生活中的事件中运行良好。因此，我认为我们的整体正常运行时间又增加了 9 个。
我很惊讶您的 rsync 需要很长时间，因为您的 Web 服务器可能位于同一个数据中心或同一个国家/地区，除非它们是像 ISO 这样的大文件。可能值得检查您使用的 rsync 选项是否可以优化。