AWS - Elastic Load Balancing 是不是真的阻止了 LOAD BALANCER 故障转移？

Posted 2023-03-04

【中文标题】AWS - Elastic Load Balancing 是不是真的阻止了 LOAD BALANCER 故障转移？

【英文标题】：AWS - Does Elastic Load Balancing actually prevent LOAD BALANCER failover?AWS - Elastic Load Balancing 是否真的阻止了 LOAD BALANCER 故障转移？

【发布时间】：2018-11-16 18:56:44

【问题描述】：

我直接从一些 AWS 文档中获得了这一点：

“随着应用程序的流量随时间变化，Elastic Load Balancing 会扩展您的负载均衡器并更新 DNS 条目。请注意，DNS 条目还将生存时间 (TTL) 指定为 60秒，确保可以快速重新映射 IP 地址以响应不断变化的流量。”

两个问题：

1) 我最初的印象是，单个静态 IP 地址会映射到 AWS 负载均衡器的多个实例，从而导致均衡器级别的容错，例如，如果一台机器因任何原因崩溃，静态注册到我的域名的 IP 地址将简单地动态“移动”到另一个平衡器实例并继续服务请求。 这是错的吗？ 根据上面来自 AWS 的引用，似乎这里发生的唯一魔术是 AWS 的 DNS 服务器为您的 AWS 注册域名保存了多个 A 记录，并且在 60 秒后没有连接从客户端，TTL 过期并且亚马逊的 DNS 条目被更新为仅开始向活动 IP 发送请求。这在连接失败的客户端仍然需要 60 秒。对或错？为什么？

2) 如果上述情况属实，如果我使用例如 GoDaddy 的主机提供商，输入多个“A”名称记录并将 TTL 设置为 60 秒，它在功能上是否等效？

谢谢！

【参考方案1】：

ELB 被分配了一个 DNS 名称，然后您可以将其分配给 A 记录作为别名，see here。如果您的 ELB 设置有多个实例，则您可以定义运行状况检查。您可以确定检查的路径、频率以及失败次数表明实例已关闭（例如，检查 / 每 10s 并使用 5s 超时，如果失败 2 times 则认为它不健康。当实例变得不健康，所有剩余的实例仍然可以毫无延迟地正常处理请求。如果实例返回到健康状态（例如，它通过 2 连续检查），那么它将作为负载均衡器中的健康主机返回。

引用所指的是负载均衡器本身。如果它有问题或 AZ 变得不可用，它会描述底层 ELB DNS 记录发生的情况，而不是您分配给它的别名记录。

流量是否受到影响部分取决于您的设置如何处理会话。无论它们是 sticky 还是由另一个系统（如 elasticache 或您的数据库）处理。

【讨论】：

基本上，您购买了一个托管在 AWS 上的域，在 Amazon 的 DNS 系统中创建一个 DNS 条目，然后 Route 53 将接收该域名的请求并将请求映射到一个或多个 IP 地址（您的个人负载均衡器主机是否构成您的 ELB）？有了这个逻辑，我假设 Route 53 插入运行状况检查，并且只路由到“up”负载均衡器？

Route53 将始终路由到 ELB。 ELB 处理您的哪些主机已启动。 ELB DNS 记录在任何给定时间路由到几个 IP。您的 ELB 在任何给定时间都在多个区域中启动。

对。所以让我看看我是否明白你在说什么。 Route53 负责 DNS 条目。当最终用户在 URL 中输入域时，如果您选择通过别名记录将域指向您的 ELB，它将（通过 route53）解析到您的 ELB。从那里，ELB 根据运行状况检查确定将请求转发到和通过哪个单独的 LB 主机。不过，最重要的是，最终用户对您的域名的请求将（假设）始终到达您的 ELB，因此是您的 LB 实例之一。对吗？

是的，这就是它的要点。

正确。只要您的健康检查配置为在出现故障时相对较快地失败。一旦主机不健康，它就不会再在那里发送流量了。