Amazon ec2 Haproxy负载平衡器，EC2，编写我自己的可用性脚本

我一直在研究高可用性解决方案，如heartbeat，并在haproxy负载平衡器出现故障时保持故障切换。我意识到，尽管我们希望获得高可用性，但在这个时候，这并不是一个真正的要求，因为在任何时候都需要运行两个负载平衡器实例，以便实现即时故障切换（特别是在我们的设置中将有一个lb是冗余的情况下）

我的替代解决方案是，如果当前负载平衡器停止工作，则从AMI启动一个新的负载平衡器EC2实例，并将其与我们的域名指向的弹性ip相关联。这将确保停机时间仅限于启动新实例和关联弹性ip所需的时间，考虑到我们目前的情况，弹性ip似乎是一个合理的高可用性经济高效的解决方案，特别是因为我们可以轻松地在多av区域内实现这一点。我希望通过以下步骤实现这一点：

准备负载平衡器的AMI

启动一个充当负载平衡器的ec2实例，并将弹性IP分配给它

让一台微型服务器定期ping当前的负载平衡器（我们总是有一台额外的微型服务器在运行）

如果ping超时，使用负载平衡器AMI启动一个新的EC2实例

将弹性ip与新实例关联

关闭旧的负载平衡器实例

对新实例重复步骤3

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

我的问题是什么样的ping才是合适的？在固定的时间间隔内，标准的ping是否足够？什么是好的时间间隔？或者这是一个相当简单的方法，我应该做一个更聪明的健康检查

---

此外，如果有人预见到这种方法存在任何问题，请随时发表意见

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

我对您的解决方案的一个问题是，您假设微实例和负载平衡器不会同时消亡。根据我在amazon的经验，我可以告诉你，这种情况很有可能发生，尽管不太可能发生，但有可能导致负载平衡器死机的任何因素也会导致micro实例崩溃

另一个潜在问题是，您还假设在停机期间始终能够启动另一个替换实例。但事实并非如此，以亚马逊几天前在其美国东部地区的一次停电为例。停电导致他们的一个区域断电。当他们恢复电源并开始恢复实例时，他们的API由于负载过大而无法正常工作。在这段时间里，他们花了将近一个小时才有空。如果像这样的中断破坏了您的负载平衡器，并且您无法启动另一个负载平衡器，那么您将停机

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

对于您创建的每个ELB，amazon在每个注册了实例的区域中创建一个负载平衡器。在亚马逊出现上述严重停机时，这些系统仍然容易出现某些问题。例如，在此停机期间，我无法向负载平衡器添加新实例，但我的当前实例（未受断电影响的实例）仍在为请求提供服务

更新2013-09-30

---

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

我知道这有点陈旧，但您建议的解决方案过于复杂，有一种简单得多的方法，可以实现您想要实现的目标

---

只需将您的HAProxy机器和您的自定义AMI放在一个自动缩放组中，最小和最大为1个实例。这样，当您的实例失败时，ASG将立即将其恢复，包括EIP和所有。无需外部监控，即使对宕机的实例没有更快的响应，也是如此。

事实上，我已经让ELB运行并对其进行了大量负载测试，现在我正在进行haproxy设置。这一切都与性能有关，ELB似乎无法像我希望的那样处理突发事件，CNAME分辨率增加了延迟。也就是说，ELB消除了容错和自动缩放的所有管理开销，我仍然需要整理haproxy的所有自动缩放脚本。如果ELB无法处理您需要的突发事件，请AWS支持增加ELB实例的默认大小。他们会将您的ELB移动到可以处理您的负载的实例。这是测试时的一个常见问题，我从未在实际用户场景中遇到过这种情况。CNAME的分辨率应该非常低。希望这能有所帮助。基于HAProxy的LB与Amazon ELB的对比是因为HAProxy是云不可知论者。如果你使用ELB，如果你想把你的基础设施转移到另一个云提供商，你有很多工作要做。。。然而，如果你基于HAProxy创建自己的LB，你可以自由地将整个系统转移到你选择的任何云上。。。或者更好的是，只是其中的一部分，关键是您没有被锁定在单个提供程序中。@DGM您可以使用实例用户数据在引导时调用ec2 cli并重新连接它，或者编写