如何在 Amazon EC2 上部署可扩展、可靠的 haproxy 集群？

Question

我们需要一些比 ELB 提供的更高级的功能（主要是 L7 检查），但是如何使用 EC2 使用诸如 haproxy 之类的东西来处理诸如心跳和高可用性之类的事情并不明显。我们很有可能在集群中需要 3 个或更多 haproxy 节点，因此两个节点之间的简单心跳是行不通的。

似乎在 haproxy 节点前面有一个心跳层是可行的方法，可能使用 IPVS，但是随着 EC2 集群的变化处理配置更改（通过有意的更改，如扩展，或无意的，如丢失EC2 节点）似乎很重要。

优选地，该解决方案将跨越至少两个可用区。

回答问题：不，会话没有粘性。是的，我们需要 SSL，但理论上这可以完全由另一个设置处理 - 我们能够将 SSL 流量定向到与非 SSL 流量不同的位置。

Answer 1

好吧，我自己从未构建过流量达到 SmugMug 级别的 AWS 负载平衡解决方案，但只要考虑理论和 AWS 的服务，我就会想到几个想法。

最初的问题缺少一些往往会影响负载平衡设计的东西：

1. 粘性会话与否？最好不要使用粘性会话，而是让所有负载均衡器 (LB) 使用循环 (RR) 或随机后端选择。RR 或随机后端选择简单、可扩展，并在所有情况下提供均匀的负载分布。
2. SSL 与否？SSL 是否在使用中，以及请求的百分比，通常对负载平衡设计有影响。通常最好尽早终止 SSL，以简化证书处理并使 SSL CPU 负载远离 Web 应用程序服务器。

我是从如何保持负载均衡层本身高可用的角度来回答的。保持应用服务器 HA 只是通过内置于 L7 负载平衡器中的健康检查完成。

好的，一些应该可行的想法：

1）“AWS方式”：

• 第一层，在最前面，在 L4 (TCP/IP) 模式下使用 ELB。
• 第二层，将 EC2 实例与您选择的 L7 负载均衡器（nginx、HAProxy、Apache 等）一起使用。

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

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

• 使用基本的 DNS 循环法在几个 IP 地址上获得粗粒度的负载分布。假设您为您的站点发布了 3 个 IP 地址。
• 这 3 个 IP 中的每一个都是 AWS 弹性 IP 地址 (EIA)，绑定到 EC2 实例，并带有您选择的 L7 负载均衡器。
• 如果 EC2 L7 LB 失效，则兼容的用户代理（浏览器）应该只使用其他 IP 之一。
• 设置外部监控服务器。监控 3 个 EIP 中的每一个。如果一个人变得无响应，请使用 AWS 的命令行工具和一些脚本将 EIP 移动到另一个 EC2 实例。

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

3) DNS RR 到成对的 HA 服务器：

基本上，这是唐自己关于一对服务器之间简单心跳的建议，但针对多个 IP 地址进行了简化。

• 使用 DNS RR，为服务发布多个 IP 地址。按照上面的示例，假设您发布了 3 个 IP。
• 这些 IP 中的每一个都转到一对EC2 服务器，因此总共有 6 个 EC2 实例。
• 这些对中的每一对都使用 Heartbeat 或其他 HA 解决方案以及 AWS 工具，以在主动/被动配置中保持 1 个 IP 地址的活动。
• 每个 EC2 实例都安装了您选择的 L7 负载均衡器。

优势/想法：在 AWS 的完全虚拟化环境中，实际上并不容易推理 L4 服务和故障转移模式。通过简化为仅保留 1 个 IP 地址的一对相同服务器，推理和测试变得更简单。

结论：同样，我实际上还没有在生产中尝试过任何这些。就我的直觉而言，选项一采用 L4 模式的 ELB，以及作为 L7 LB 的自我管理的 EC2 实例似乎最符合 AWS 平台的精神，也是亚马逊最有可能在以后投资和扩展的地方。这可能是我的第一选择。