ELB 跨可用区平衡 DNS 解析与粘性会话
ELB cross-AZ balancing DNS resolution with Sticky sessions
我正在准备 AWS 认证，遇到一个关于 ELB 的问题，它为 2 个 AZ 中的实例启用了粘性会话。问题在于，来自其中一个 AZ 中基于软件的负载测试器的请求最终仅出现在该 AZ 中的实例中，而不是分布在多个 AZ 中。同时，来自客户的定期请求均匀分布在各个可用区中。
解决负载测试器问题的正确答案是：
- 强制基于软件的负载测试器在每次执行之前重新解析 DNS
请求；
- 使用第三方负载测试服务发送请求
全球分布的客户端。
我不确定我能理解这种情况。在 ELB IP 解析方面，Route 53 的默认行为是什么？在任何情况下，这些 DNS 记录都有 60 秒的 TTL。在每个请求上重新解析 DNS 不是多余的吗？此外，DNS 解析是 DNS 服务本身的责任，而不是负载测试软件，不是吗？
我可以理解来自同一个实例的请求，上面有负载测试软件，将转到同一个 LBed EC2，但为什么它必须是同一个 AZ 中的一个实例？它只能通过基于地理位置或基于延迟的路由来实现，但我在规范中找不到任何内容是否是默认的。
粘性问题，请看这里：https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
The load balancer uses a special cookie to associate the session with
the instance that handled the initial request, but follows the
lifetime of the application cookie specified in the policy
configuration. The load balancer only inserts a new stickiness cookie
if the application response includes a new application cookie. The
load balancer stickiness cookie does not update with each request. If
the application cookie is explicitly removed or expires, the session
stops being sticky until a new application cookie is issued.
第一个解决方案，重新解析 DNS 将创建新会话，从而打破 ELB 的粘性。第二种解决方案是使用多个客户端，如果全球分布的客户端数量很大，粘性不是问题。
第 2 部分：无法添加为评论，太长了：
是的，我的回答很简单而且不完整。
我们知道 ELB 是 2 个 AZ，并且会有 2 个不同 IP 的节点。不清楚有多少个 IP ，取决于请求数和每个 AZ 上的服务器数。 Route 53 为每个新请求轮换 IP，第一次是 NodeA-IP、NodeB-IP，第二次是 NodeB-IP、NodeA-IP。负载测试应用程序将在每个新请求中获取第一个 IP，在 2 个 AZ 之间进行平衡。因为 Node 只能在他的 AZ 内路由，如果粘性 cookie 是针对 NodeA 并且请求到达 NodeB ，NodeB 会将它发送到他在 AZ2 中的一台服务器，而忽略 AZ 1 中服务器的 cookie。
我需要 运行 一些测试，使用具有经典 ELB 和 2 个 AZ 的 Route53 快速测试，并且每次 IP 都在轮换。如果我有 AZ 1 的粘性 cookie 并且到达节点 2，我想测试的是不会将我转发到节点 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.
如果配置了粘性，这些会话最初将登陆一个 AZ，然后坚持该 AZ，因为它们坚持他们登陆的初始实例。如果启用了跨区域，则结果不是很清楚，但是在那种情况下（当第一次建立粘性时），平衡器节点可能更喜欢它们自己区域中的实例，或者这并不是真正的问题所在。粘性需要协调，并且由于距离（通常 <10 毫秒），跨 AZ 流量需要非零时间量，但平衡器更愿意 select 实例其本地区域的会话没有建立亲和力。
实际上，配置负载测试软件以重新解析 each 请求的端点并不是解决方案的真正重点——重点是确保 (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，并且如上所述，即使有多个答案可用，它也可能坚持一个答案，因为它只需要一个答案即可建立连接。 Every 请求并不是绝对必要的，但它确实解决了问题。
Besides, DNS resolution is a responsibility of DNS service itself, not load-testing software, isn't it?
To "resolve DNS" 在这种情况下只是意味着进行 DNS 查找，无论在特定实例中意味着什么，无论是使用 OS 的 DNS 解析器还是直接查询递归DNS 服务器。当软件与主机名建立连接时，它 "resolves"（查找）关联的 IP 地址。
另一个解决方案，"use third party load-testing service to send requests from globally distributed clients,"意外地解决了这个问题，因为分布式客户端——即使他们坚持他们看到的第一个地址——更多可能会看到所有可用地址。 "global" 分发方面令人分心。
ELB 依赖于请求在其面向外部的节点上的随机到达作为平衡策略的一部分。设计忽略这一点的负载测试软件无法正确 测试 ELB。两种解决方案都以不同的方式缓解了这个问题。
刚刚发现另一个证据表明 Route 53 returns 多个 IP 并针对 ELB 扩展方案轮换它们：
By default, Elastic Load Balancing will return multiple IP addresses when clients perform a DNS resolution, with the records being randomly ordered on each DNS resolution request. As the traffic profile changes, the controller service will scale the load balancers to handle more requests, scaling equally in all Availability Zones.
然后：
To ensure that clients are taking advantage of the increased capacity, Elastic Load Balancing uses a TTL setting on the DNS record of 60 seconds. It is critical that you factor this changing DNS record into your tests. If you do not ensure that DNS is re-resolved or use multiple test clients to simulate increased load, the test may continue to hit a single IP address when Elastic Load Balancing has actually allocated many more IP addresses.
一开始我没有意识到的是，即使常规流量均匀分布在AZ之间，也不意味着启用了跨区域负载均衡。正如 Michael 指出的那样，常规流量自然会经过不同的位置并最终到达不同的可用区。
由于在测试中没有明确提到，跨可用区平衡可能还没有到位。
https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/
我正在准备 AWS 认证，遇到一个关于 ELB 的问题，它为 2 个 AZ 中的实例启用了粘性会话。问题在于，来自其中一个 AZ 中基于软件的负载测试器的请求最终仅出现在该 AZ 中的实例中，而不是分布在多个 AZ 中。同时，来自客户的定期请求均匀分布在各个可用区中。 解决负载测试器问题的正确答案是：
- 强制基于软件的负载测试器在每次执行之前重新解析 DNS 请求；
- 使用第三方负载测试服务发送请求 全球分布的客户端。
我不确定我能理解这种情况。在 ELB IP 解析方面，Route 53 的默认行为是什么？在任何情况下，这些 DNS 记录都有 60 秒的 TTL。在每个请求上重新解析 DNS 不是多余的吗？此外，DNS 解析是 DNS 服务本身的责任，而不是负载测试软件，不是吗？ 我可以理解来自同一个实例的请求，上面有负载测试软件，将转到同一个 LBed EC2，但为什么它必须是同一个 AZ 中的一个实例？它只能通过基于地理位置或基于延迟的路由来实现，但我在规范中找不到任何内容是否是默认的。
粘性问题，请看这里：https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
The load balancer uses a special cookie to associate the session with the instance that handled the initial request, but follows the lifetime of the application cookie specified in the policy configuration. The load balancer only inserts a new stickiness cookie if the application response includes a new application cookie. The load balancer stickiness cookie does not update with each request. If the application cookie is explicitly removed or expires, the session stops being sticky until a new application cookie is issued.
第一个解决方案，重新解析 DNS 将创建新会话，从而打破 ELB 的粘性。第二种解决方案是使用多个客户端，如果全球分布的客户端数量很大，粘性不是问题。
第 2 部分：无法添加为评论，太长了：
是的，我的回答很简单而且不完整。
我们知道 ELB 是 2 个 AZ，并且会有 2 个不同 IP 的节点。不清楚有多少个 IP ，取决于请求数和每个 AZ 上的服务器数。 Route 53 为每个新请求轮换 IP，第一次是 NodeA-IP、NodeB-IP，第二次是 NodeB-IP、NodeA-IP。负载测试应用程序将在每个新请求中获取第一个 IP，在 2 个 AZ 之间进行平衡。因为 Node 只能在他的 AZ 内路由，如果粘性 cookie 是针对 NodeA 并且请求到达 NodeB ，NodeB 会将它发送到他在 AZ2 中的一台服务器，而忽略 AZ 1 中服务器的 cookie。
我需要 运行 一些测试，使用具有经典 ELB 和 2 个 AZ 的 Route53 快速测试，并且每次 IP 都在轮换。如果我有 AZ 1 的粘性 cookie 并且到达节点 2，我想测试的是不会将我转发到节点 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.
如果配置了粘性，这些会话最初将登陆一个 AZ，然后坚持该 AZ，因为它们坚持他们登陆的初始实例。如果启用了跨区域，则结果不是很清楚，但是在那种情况下（当第一次建立粘性时），平衡器节点可能更喜欢它们自己区域中的实例，或者这并不是真正的问题所在。粘性需要协调，并且由于距离（通常 <10 毫秒），跨 AZ 流量需要非零时间量，但平衡器更愿意 select 实例其本地区域的会话没有建立亲和力。
实际上，配置负载测试软件以重新解析 each 请求的端点并不是解决方案的真正重点——重点是确保 (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，并且如上所述，即使有多个答案可用，它也可能坚持一个答案，因为它只需要一个答案即可建立连接。 Every 请求并不是绝对必要的，但它确实解决了问题。
Besides, DNS resolution is a responsibility of DNS service itself, not load-testing software, isn't it?
To "resolve DNS" 在这种情况下只是意味着进行 DNS 查找，无论在特定实例中意味着什么，无论是使用 OS 的 DNS 解析器还是直接查询递归DNS 服务器。当软件与主机名建立连接时，它 "resolves"（查找）关联的 IP 地址。
另一个解决方案，"use third party load-testing service to send requests from globally distributed clients,"意外地解决了这个问题，因为分布式客户端——即使他们坚持他们看到的第一个地址——更多可能会看到所有可用地址。 "global" 分发方面令人分心。
ELB 依赖于请求在其面向外部的节点上的随机到达作为平衡策略的一部分。设计忽略这一点的负载测试软件无法正确 测试 ELB。两种解决方案都以不同的方式缓解了这个问题。
刚刚发现另一个证据表明 Route 53 returns 多个 IP 并针对 ELB 扩展方案轮换它们：
By default, Elastic Load Balancing will return multiple IP addresses when clients perform a DNS resolution, with the records being randomly ordered on each DNS resolution request. As the traffic profile changes, the controller service will scale the load balancers to handle more requests, scaling equally in all Availability Zones.
然后：
To ensure that clients are taking advantage of the increased capacity, Elastic Load Balancing uses a TTL setting on the DNS record of 60 seconds. It is critical that you factor this changing DNS record into your tests. If you do not ensure that DNS is re-resolved or use multiple test clients to simulate increased load, the test may continue to hit a single IP address when Elastic Load Balancing has actually allocated many more IP addresses.
一开始我没有意识到的是，即使常规流量均匀分布在AZ之间，也不意味着启用了跨区域负载均衡。正如 Michael 指出的那样，常规流量自然会经过不同的位置并最终到达不同的可用区。 由于在测试中没有明确提到，跨可用区平衡可能还没有到位。
https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/