ELB 跨可用区平衡 DNS 解析与粘性会话答案

【问题标题】：ELB cross-AZ balancing DNS resolution with Sticky sessionsELB 跨可用区平衡 DNS 解析与粘性会话
【发布时间】：2019-07-24 03:04:54
【问题描述】：

我正在准备 AWS 认证，并遇到了一个关于为 2 个可用区中的实例启用粘性会话的 ELB 的问题。问题是来自其中一个 AZ 中基于软件的负载测试器的请求最终仅出现在该 AZ 中的实例中，而不是分布在 AZ 中。同时，来自客户的定期请求平均分布在 AZ 中。解决负载测试器问题的正确答案是：

强制基于软件的负载测试器在每次运行之前重新解析 DNS 请求；
使用第三方负载测试服务从全球分布的客户。

我不确定我是否能理解这种情况。在 ELB IP 解析方面，Route 53 的默认行为是什么？在任何情况下，这些 DNS 记录都有 60 秒的 TTL。在每个请求上重新解析 DNS 不是多余的吗？此外，DNS解析是DNS服务本身的责任，不是负载测试软件的责任，不是吗？我可以理解来自同一个实例的请求，上面有负载测试软件，会转到同一个 LBed EC2，但为什么它必须是同一个 AZ 中的一个实例？它只能通过基于地理位置或延迟的路由来实现，但我在规范中找不到任何东西，无论这些是默认的。

【问题讨论】：

标签： amazon-web-services dns amazon-route53 amazon-elb

【解决方案1】：

当 ELB 位于多个可用区中时，它始终具有多个公共 IP 地址 - 每个区域至少一个。

当您在 DNS 查找中请求这些记录时，您会获得所有这些记录（假设不是很多）或其中的一个子集（如果数量很大，在具有大量流量），但它们是无序的。

如果负载测试软件解析了端点的 IP 地址并恰好保留了其中一个 IP 地址（这是可能的结果），那么所有流量都将流向平衡器的一个节点，该节点位于一个区域，并将流量发送到该区域中的实例。

但是...

跨区域负载平衡

负载平衡器的节点将来自客户端的请求分发到已注册的目标。启用跨区域负载均衡后，每个负载均衡器节点都会在所有已启用的可用区中的已注册目标之间分配流量。禁用跨区域负载均衡时，每个负载均衡器节点仅在其可用区中的已注册目标之间分配流量。

https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html

如果配置了粘性，则这些会话最初会位于一个 AZ 中，然后会停留在该 AZ 上，因为它们会停留在它们着陆的初始实例上。如果启用了跨区域，则结果不是很清楚，但是在这种情况下（当第一次建立粘性时），平衡器节点可能更喜欢自己区域中的实例，或者这并不是问题的重点。粘性需要协调，并且由于距离（通常

实际上，配置负载测试软件为每个请求重新解析端点并不是真正解决方案的重点——重点是确保（1）负载测试软件使用所有这些并且不完全锁定其中一个，并且 (2) 如果由于平衡器在负载下横向扩展而有更多可用地址，则负载测试软件会扩展其目标池。

无论如何，这些 DNS 记录都有 60 秒的 TTL。每次请求都重新解析 DNS 不是多余的吗？

软件可能看不到 TTL，可能不遵守 TTL，并且如上所述，即使有多个可用的答案，它也可能坚持一个答案，因为它只需要一个即可建立连接。每个请求都不是绝对必要的，但它确实解决了问题。

此外，DNS 解析是 DNS 服务本身的责任，而不是负载测试软件，不是吗？

在这种情况下，“解析 DNS”仅意味着进行 DNS 查找，无论在特定实例中意味着什么，无论是使用操作系统的 DNS 解析器还是直接查询递归 DNS 服务器。当软件与主机名建立连接时，它会“解析”（查找）相关的 IP 地址。

另一个解决方案，“使用第三方负载测试服务从全球分布的客户端发送请求”，偶然解决了这个问题，因为分布式客户端——即使他们坚持第一个他们看到的地址——更有可能看到所有可用的地址。 “全球”分布方面令人分心。

ELB 依赖于通过其面向外部的节点随机到达的请求作为平衡策略的一部分。设计忽略这一点的负载测试软件未正确测试 ELB。两种解决方案都以不同的方式缓解了这个问题。

【讨论】：

谢谢，迈克尔。 “但是对于平衡器来说，更愿意为没有建立关联的会话选择其本地区域的实例是有意义的” - 一方面，是的，但另一方面 - 如果存在流量，它可能会导致真正不平衡的分布主要来自特定的可用区。
关于跨区域平衡 - 我确信这是暗示的，因为问题还说来自一部分用户的常规流量均匀分布在两个 AZ 上。而且似乎不太清楚为什么以及如何默认为 AutoScaling 配置 Route53+ELB。正如您所提到的：“如果启用了跨区域，结果就不是那么清楚了”
No... 正常流量倾向于均匀分布即使没有跨区域平衡，因为请求随机到达各个平衡器节点，这是由于来自 Route 53 的 DNS 响应。各个浏览器倾向于执行问题中描述的完全相同的事情——解析一次，并坚持使用一个 IP 地址——但由于浏览器很多，因此自然会产生平衡效应。 ELB 部分依赖于无序/循环 DNS 记录的平衡效果，这就是不重复 DNS 查找的负载测试工具会以这种方式运行的原因。
好吧，如果所有可用区的实例数都相同(docs.aws.amazon.com/elasticloadbalancing/latest/userguide/…) ...问题中就是这种情况。
无论如何，我想现在很清楚了。默认的 Route 53 策略可能是基于循环的 Single。该 IP 可以缓存在操作系统或软件本身的 DNS 缓存中（例如，JVM 似乎也使用了 DNS 缓存）。

【解决方案2】：

粘性是问题，请看这里：https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

负载均衡器使用特殊的 cookie 将会话与处理初始请求的实例，但遵循策略中指定的应用程序 cookie 的生命周期配置。负载均衡器只插入一个新的粘性 cookie 如果应用程序响应包含新的应用程序 cookie。这负载平衡器粘性 cookie 不会随每个请求更新。如果应用程序 cookie 被显式删除或过期，会话在发布新的应用程序 cookie 之前停止粘性。

第一个解决方案，重新解析 DNS 将创建新会话，这将打破 ELB 的粘性。第二种解决方案是使用多个客户端，如果全球分布的客户端数量很大，粘性不是问题。

第 2 部分：无法添加为评论，太长了：

是的，我的回答是简单且不完整。

我们知道的是，ELB 是 2 个可用区，将有 2 个具有不同 IP 的节点。不清楚有多少IP，取决于请求的数量和每个AZ上的服务器数量。 Route 53 为每个新请求轮换 IP，第一次在 NodeA-IP、NodeB-IP 中，第二次是 NodeB-IP、NodeA-IP。负载测试应用程序将在每个新请求中获取第一个 IP，在 2 个可用区之间进行平衡。因为节点只能在其 AZ 内路由，所以如果粘性 cookie 是针对 NodeA 并且请求到达 NodeB ，则 NodeB 会将其发送到 AZ2 中的一个服务器，而忽略 AZ 1 中的服务器的 cookie。

我需要运行一些测试，使用带有经典 ELB 和 2 AZ 的 Route53 快速测试，并且每次 IP 都在旋转。如果我有 AZ 1 的粘性 cookie 并且我到达节点 2，我想测试的内容不会将我转发到节点 1（如果没有可用的服务器，文档中描述了这个有趣的流程）。希望短时间内有更新。

【讨论】：

很明显，问题是关于粘性的（甚至从测试本身的问题来看），但在这种情况下，它不是来自应用程序端的 cookie； DNS 解析本身与会话无关。会话作为 Cookies（HTTP 级别）添加，DNS 用于域到 IP 的映射，与 Cookies 无关。请提供更多详细信息/链接，否则我将不得不对您的答案投反对票。对不起。
请查看我评论的第 2 版，抱歉迟到了
谢谢！它现在确实回答了一些问题。那么，您是说默认情况下 Route 53 将返回所有 ELB IP（根据 Route 53 的限制，我猜最多为 8 个），但一直在轮换它们？ “节点只能在他的 AZ 内路由”——这是基于 LB 上未启用跨 AZ 功能的假设。

【解决方案3】：

刚刚发现另一个证据表明 Route 53 返回多个 IP 并轮换它们以用于 ELB 扩展场景：

默认情况下，当客户端执行 DNS 解析时，Elastic Load Balancing 将返回多个 IP 地址，记录在每个 DNS 解析请求上随机排序。随着流量配置文件的变化，控制器服务将扩展负载均衡器以处理更多请求，在所有可用区中均等地扩展。

然后：

为确保客户端利用增加的容量，Elastic Load Balancing 对 DNS 记录使用 60 秒的 TTL 设置。将这种不断变化的 DNS 记录纳入测试至关重要。如果您不确保重新解析 DNS 或使用多个测试客户端来模拟增加的负载，则当 Elastic Load Balancing 实际上分配了更多 IP 地址时，测试可能会继续命中单个 IP 地址。

一开始我没有意识到，即使常规流量均匀分布在 AZ 之间，也并不意味着启用了跨区域负载平衡。正如迈克尔指出的那样，常规流量自然会通过不同的位置并最终到达不同的可用区。并且由于测试中没有明确提及，可能还没有实现跨可用区平衡。

https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/

【讨论】：