amazon-web-services - ELB 跨可用区通过粘性 session 平衡 DNS 解析

Question

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

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

我不确定我能理解这个场景。在 ELB IP 解析方面，Route 53 的默认行为是什么？无论如何，这些 DNS 记录的 TTL 为 60 秒。每次请求都重新解析 DNS 不是多余的吗？此外，DNS解析是DNS服务本身的责任，而不是负载测试软件的责任，不是吗？我可以理解，来自同一个实例(带有负载测试软件)的请求将发送到同一个 LBed EC2，但为什么它必须是同一可用区中的实例？它只能通过基于地理位置或基于延迟的路由来实现，但我在规范中找不到任何内容是否是默认路由。

Answer 1

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

当您在 DNS 查找中请求这些记录时，您将获得所有这些记录(假设数量不是很多)或它们的子集(如果数量很大，则在事件集群中就是这种情况)大量流量)，但它们是无序的。

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

但是……

Cross-Zone Load Balancing

The nodes for your load balancer distribute requests from clients to registered targets. When cross-zone load balancing is enabled, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones. When cross-zone load balancing is disabled, each load balancer node distributes traffic across the registered targets in its Availability Zone only.

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

如果配置了粘性，这些 session 最初将登陆一个可用区，然后粘在该可用区，因为它们会粘在它们登陆的初始实例上。如果启用跨区域，结果并不那么清楚，但在这种情况下(首次建立粘性时)，平衡器节点可能更喜欢自己区域中的实例，或者这并不是问题的重点。粘性需要协调，并且由于距离(通常 <10 毫秒)，跨可用区流量需要非零时间，但平衡器更愿意为没有建立关联的 session 选择其本地区域的实例是有意义的。

事实上，配置负载测试软件以重新解析每个请求的端点并不是解决方案的真正重点 - 重点是确保 (1) 负载测试软件使用所有这些地址，并且不会恰好锁定其中一个，并且 (2) 如果由于平衡器在负载下扩展而导致更多地址变得可用，则负载测试软件会扩展其目标池。

In any case, those DNS records have 60 seconds TTL. Isn't it redundant to re-resolve DNS on every request?

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

Besides, DNS resolution is a responsibility of DNS service itself, not load-testing software, isn't it?

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

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

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