使用两个网站托pipe更好的可用性

这一切都取决于情况。 实现更高可用性的标准方式确实是负载平衡器。 问题是你至less需要两个负载均衡器

一个小小的图画来说清楚：

+-----------+ +--->| Backend 1 | +----------------+ | +-----------+ WAN --->| Loadbalancer 1 |---+ +----------------+ | +-----------+ | +--->| Backend 2 | | Fallback +-----------+ v + - - - - - - - -+ | Loadbalancer 2 | + - - - - - - - -+ 

说明

负载平衡器在所有后端服务器和广告代理之前站立到后端服务器的所有请求。 辅助负载均衡器保持在线状态，并检查主要平衡器是否可到达。 如果在任何情况下主负载均衡器都会closures，那么辅助负载均衡器将接pipe他的IP并开始服务。

（这个configuration的优点）

• 负载平衡器本身分配stream量，而不会有太多负载，从而可以为后端服务器提供更多的用户[1]
• 负载均衡器可以检测到后端是否无法处理stream量，并可以停止发送stream量[2]
• 负载均衡器可以为后端caching静态文件
• 负载均衡器可以终止SSL [3] [4]
• 如果负载平衡器发生故障，则可以在没有停机的情况下回退到次级平衡器[5] [6]

缺点

• 它靠了更多的钱
• 如果平衡器前面的networking出现故障，这也无济于事。

脚注

[1]当然，负载均衡器需要比后端服务器的最大带宽总和更多的带宽（这不一定取决于应用程序的接口的最大带宽）

[2]这不仅是好的。 如果两个后端都处于或接近其最大容量，并且负载均衡器将其中一个降低，则另一个后端将获得所有stream量，并且整个事件都会崩溃。 这需要很好的调整

[3]实际上负载均衡器必须这样做，如果他不想通过连接盲目路由stream量。

[4]也许你必须重新build立一个新的ssl连接后，如果你不信任后端networking

[5]你必须确定，当小学时，它停留下来，直到你想再次，以防止像两次使用和IP使用两次

[6]你必须弄清楚负载平衡器之间的连接是非常非常稳定的

如果你有单一的负载平衡器，在高可用性方面没有太多的帮助，你仍然会有单点故障。 CDN曾经是一种方式，但是您可能想等待更多的答案。

即使您在第三个位置有一个负载平衡器（您可以将它们configuration在高可用性主备中），仍然容易出现networking问题。 由于您的两个VPS可能位于两个不同的数据中心，因此您的负载均衡器可能会联系VPS，请求并将响应转发给客户端，因此，如果包含平衡器的数据中心脱机或遇到networking问题你的2 VPS是没用的。

一个粗略的conf可能是：

• 将DRBD分区挂载到两台服务器上
• 移动drbd分区中的conf / web / db
• 更改DNS设置，因为它在两台服务器上循环

我做了以下假设：

• 你没有很多更新（你可能会杀死你的networking吞吐量）
• 该网站不是一家商店

无论如何，在这个configuration中没有自动故障检测和响应。

所发布的一切都是正确的。 不过，我可以看到一个不同的方法来达到所描述的目标（由第三方托pipe公司托pipe的回退系统）：

DNS后备

使用这种方法，DNS提供程序会检查主系统的可用性，并在检查的系统没有正确响应的情况下切换到备用系统。

市场上有相当多的供应商提供这种服务（Amazon Route 53，DNS Made Easy …）。 另外，你将得到一个更快的DNS系统（世界范围的传播，任何监听的DNS服务器）。

但是 – 这不是高可用性！ 如果发生中断，需要一些时间来识别中断并调整DNS。 但是也许已经足够满足你的要求了。

也许为时太晚，这是有帮助的，因为你已经有你的VPS的设置（虽然我不知道哪个提供商）

但是后来我又遇到了类似的情况。 如果我没有正确记住Amazon EC2，则可以在不同的可用区域中有两个节点（区域内存在可用区域），并且在两者之间实现弹性负载平衡，两个可用区域的可能性同时下降，虽然并非不可能非常渺茫，所以风险蔓延。

数据穿越可用区有收费，但从我记忆中可以忽略不计。