4

我一直在研究高可用性解决方案，例如 heartbeat，以及当 haproxy 负载均衡器出现故障时进行故障转移的 keepalived。我意识到，虽然我们想要高可用性，但在任何时候运行 2 个负载均衡器实例的支出范围内，这并不是真正的要求，以便我们获得即时故障转移（尤其是一磅在我们的设置中将是多余的）。

如果当前负载均衡器已停止工作，我的替代解决方案是从 AMI 启动一个新的负载均衡器 EC2 实例，并将其与我们的域名指向的弹性 IP 相关联。这应该确保停机时间限制在启动新实例和关联弹性 ip 所需的时间，鉴于我们目前的情况，这似乎是高可用性的合理成本有效的解决方案，特别是因为我们可以轻松地进行多 av区。我希望使用以下步骤来做到这一点：

  1. 准备负载均衡器的 AMI
  2. 启动一个充当负载均衡器的 ec2 实例并为其分配弹性 IP
  3. 让微型服务器定期 ping 当前的负载均衡器（无论如何，我们总是有一个额外的微型服务器在运行）
  4. 如果 ping 超时，请使用负载均衡器 AMI 启动新的 EC2 实例
  5. 将弹性 ip 关联到新实例
  6. 关闭旧的负载均衡器实例
  7. 对新实例重复步骤 3

我知道如何在我的脚本中运行命令来启动和关闭 EC2 实例、将弹性 IP 地址关联到实例以及 ping 服务器。

我的问题是这里合适的 ping 是什么？定期进行标准 ping 就足够了，什么是好的间隔？或者这是一种相当简单的方法，并且我应该进行更智能的健康检查？

另外，如果有人预见到这种方法有任何问题，请随时发表评论

4

2 回答 2

6

我完全了解您来自哪里，我的公司处于相同的位置。我们关心拥有一个高度可用的容错系统，但是开销成本对于我们获得的流量来说根本不可行。

  1. 我对您的解决方案的一个问题是您假设微实例和负载均衡器不会同时死亡。以我在亚马逊的经验，我可以告诉你，这完全有可能发生，无论多么不可能，有可能导致你的负载均衡器死机的任何原因也可能导致微实例失效。
  2. 另一个潜在问题是您还假设您将始终能够在停机期间启动另一个替换实例。事实并非如此，例如几天前亚马逊在他们的 us-east-1 地区发生的中断。停电导致其中一个区域断电。当他们恢复供电并开始恢复实例时，他们的 API 由于负载过大而无法正常工作。在此期间，它们花了将近 1 个小时才可用。如果像这样的中断破坏了您的负载均衡器并且您无法启动另一个，那么您将失败。

话虽如此。我发现亚马逊提供的 ELB 对我来说是一个更好的解决方案。我不确定使用 HAProxy 背后的原因是什么，但我建议调查 ELB，因为它们将允许您执行诸如自动缩放等操作。

对于您创建的每个 ELB，亚马逊会在每个已注册实例的区域中创建一个负载均衡器。在亚马逊严重停电期间，这些仍然容易受到某些问题的影响，例如上述问题。例如，在此停机期间，我无法向负载均衡器添加新实例，但我当前的实例（不受停电影响的实例）仍在处理请求。

更新 2013-09-30

最近，我们更改了我们的基础架构以使用 ELB 和 HAProxy 的组合。我发现 ELB 提供了最好的可用性，但它使用 DNS 负载平衡这一事实对我的应用程序并不适用。所以我们的设置是在一个 2 节点 HAProxy 集群前面的 ELB。使用我为 AWS 创建的这个工具HAProxyCloud，我可以轻松地将 Auto Scaling 组添加到 HAProxy 服务器。

于 2012-07-03T17:26:27.677 回答
1

我知道这有点老了，但是您建议的解决方案过于复杂，有一种更简单的方法可以完全满足您的要求...

只需将您的 HAProxy 机器和您的自定义 AMI 放在一个最小和最大 1 个实例的自动扩展组中。这样，当您的实例出现故障时，ASG 将使其恢复正常，EIP 等等。无需外部监控，即使不是更快地响应停机实例也是如此。

于 2015-05-14T05:50:23.067 回答