我为一家小型 ISP 工作，我们托管大约 250 个域以及与之相关的所有东西：DNS、邮件、垃圾邮件过滤和备份。目前，我们有单独的 DNS 服务器（其中两个）和邮件服务器（外发邮件实际上在辅助 DNS 服务器上，但以前在它自己的服务器上）。过去，这是作为一种保险措施进行的。我们需要做的最后一件事是让一些傻瓜（通常是你真正的）对服务器进行软管处理，连同它一起取出 DNS 和邮件，或者让垃圾邮件发送者堵塞我们传入的 SMTP 服务器，从而阻止发送的外发邮件。在过去，这是一个问题，我们的服务器按照现在的方式设置来解决它。
然而，像 Sun 的 Cobalt RAQ（在过去的日子里）和 Virtualmin 这样的集群解决方案似乎迎合了一体化方法，然后通过冗余服务器处理故障。到目前为止，我已经避免了这种情况，但是我们已经在我们的 Web 服务器上使用 Virtualmin 有一段时间了，我想将其扩展到将它用于高可用性集群。我们的网络合作伙伴最近建立了一个数据中心，它消除了我们所有的其他问题，例如网络、冷却和电源问题，所以现在唯一出问题的就是我在为服务器充电，这在本月早些时候发生了。
我们避免走这条路的一个更大的原因是我们的硬件要求不是特别高。一台服务器可以轻松处理我们托管的所有站点（其中大多数是平面站点）。此外，负载平衡路由器往往既昂贵又复杂。我真正期望做的只是构建一个双节点集群以实现冗余，这样当我对服务器进行软管处理时（尽管这种情况可能很少），在我重建它时我们不会有 8 到 12 个小时的时间。
我需要知道的是如何开始，以及我是否真的能够为这种事情烦恼。
我发现使用负载平衡是我向 Web 服务器引入高可用性的首选解决方案。暂存代码部署、不闲置可用资源和引入冗余具有优势。 LVS是我首选的解决方案。其他人似乎喜欢Pound，我也对HAProxy很感兴趣。使用 LVS，配置 ldirectord 服务器并在 Web 服务器上使用 arptables 可以是一个直接的实现。您可以通过使用heartbeat进行故障转移的主动/被动服务器实现来防止 LVS 的单点故障。
现在，如果您是共享主机销售帐户，那么通过自动故障转移引入高可用性将变得更加复杂。有了这个，您可能必须考虑一个冗余存储解决方案，多个服务器可以使用心跳访问和配置主动/被动服务器。 DRBD似乎在这里很有用。
您可以使用完全开源和商用硬件实现完整的高可用性解决方案，而不会出现单点故障。如果您需要其他建议，我很乐意提供帮助。这是我最喜欢关注的领域之一。
我们最近做的是在我们的集群上设置ucarp ，并设置 4 个相同配置的节点。我们运行一个内部开发的 webapp，所以 4 个节点在不作为前端时实际上是在做后端工作。
UCARP 和我放在一起的一些脚本会在服务节点开始行动时自动在另一个节点上调出一个 IP。NGINX 是我们的前端服务器，它负责确保将请求路由到可用节点。
所有这一切的结果是，我可以在没有警告的情况下敲掉我们 4 个节点中的任何一个，并且服务将在几秒钟内自动迁移到另一个可用节点。（与该节点的现有连接被中断，但在任何给定时刻只有一小部分，当它们重新加载时，其他地方的事情会恢复全速。）UCARP 将检测 IP 连接中的故障 --- 如果其他事情正在发生不好，您必须想办法将 IP 连接从坏节点上断开，以便其他正常运行的节点接管。
所有 4 个节点都挂载了一个 nfs 导出的文件系统，该文件系统由运行 drbd 的一对机器处理