如何在Amazon EC2上部署可伸缩，可靠的haproxy集群？

好吧，我从来没有在SmugMug自己的层面上build立一个AWS负载平衡解决scheme，但只是想到理论和AWS的服务，就想到了一些想法。

最初的问题是缺less一些会影响负载平衡devise的事情：

1. 粘滞的会议或不？ 最好不要使用粘性会话，而是让所有负载均衡器（LB）使用循环（RR）或随机后端select。 RR或随机后端select是简单的，可扩展的，并且在所有情况下都提供均匀的负载分配。
2. 是不是SSL？ 无论SSL是否在使用中，以及请求的百分比，通常都会影响负载均衡devise。 通常最好尽早终止SSL，以简化证书处理过程，并使SSL CPU负载远离Web应用程序服务器。

我从如何保持负载平衡层本身高度可用的angular度回答。 保持应用程序服务器HA正好与L7负载均衡器内置的运行状况检查一起完成。

好吧，应该有几个想法：

1）“AWS方式”：

• 第一层，在最前面，使用L4（TCP / IP）模式的ELB。
• 第二层，使用您select的L7负载平衡器（nginx，HAProxy，Apache等）的EC2实例。

好处/想法： L7负载平衡器可以是相当简单的EC2 AMI，全部从相同的AMI克隆并使用相同的configuration。 因此，Amazon的工具可以处理所有的HA需求： ELB监视L7负载均衡器。 如果L7 LB死亡或无响应，ELB和Cloudwatch会自动产生一个新实例并将其带入ELB池。

2）“监控方式的DNS循环”：

• 使用基本的DNS轮询function，通过几个IP地址获得粗粒度的负载分配。 我们只是说你为你的站点发布3个IP地址。
• 这三个IP中的每一个都是一个AWS弹性IP地址（EIA），绑定到一个EC2实例，并带有您select的L7负载均衡器。
• 如果一个EC2 L7 LB死亡， 一个兼容的用户代理（浏览器） 应该只使用其他IP地址之一 。
• 设置外部监控服务器。 监视3个EIP中的每一个。 如果一个人没有响应，请使用AWS的命令行工具和一些脚本将EIP移动到另一个EC2实例。

优点/想法：合规的用户代理应该自动切换到另一个IP地址，如果没有响应。 因此，在发生故障的情况下，只有三分之一的用户会受到影响，其中大多数用户不应该注意到任何事情，因为他们的UA会悄悄地故障转移到另一个IP。 而您的外部监控盒会发现EIP没有反应，并在几分钟内纠正这种情况。

3）DNS RR到HA服务器对：

基本上这是Don自己对一对服务器之间简单心跳的build议，但是对于多个IP地址简化了。

• 使用DNS RR，为服务发布一些IP地址。 按照上面的例子，让我们只是说你发布3个IP。
• 这些IP中的每一个去往一对 EC2服务器，所以共有6个EC2实例。
• 这些对中的每一对都使用Heartbeat或其他高可用性解决scheme与AWS工具一起在活动/被动configuration中保留1个IP地址。
• 每个EC2实例都安装了您select的L7负载均衡器。

好处/想法：在AWS的完全虚拟化环境中，推理L4服务和故障转移模式并不那么容易。 通过简化到只保留1个IP地址的同一台服务器，就可以更简单地推理和testing。

结论：再一次，我没有真正尝试过任何这种生产。 从我的直觉来看，L4模式下的ELB选项，以及L7 LB模式下的自我pipe理EC2实例似乎与AWS平台的精神最为一致，亚马逊最有可能在后面进行投资和扩张。 这可能是我的第一select。

如果你没有做粘滞的会话，或者如果你使用的是tomcat / apache风格（将节点ID添加到sessionid中，而不是在LB中存储状态），那么我会在一组haproxies前面使用ELB。 ELB里面有一个健康检查，所以你可以让它监视haproxies并把任何一个down掉的池子里。 比心跳故障切换less设置。

就传播变化而言，我没有一个很好的答案。 傀儡非常适合初始configuration和实施更改，但对于添加/删除节点，您往往希望获得比30分钟轮询间隔更快的响应。

我自己没有用过，但是我看到很多人提到用傀儡来处理EC2上的这类问题