我正在准备进行AWS认证，并遇到一个有关ELB的问题，该ELB已为2个AZ中的实例启用了粘性会话。问题在于，来自其中一个可用区的基于软件的负载测试程序的请求仅会在该可用区中的实例中结束，而不会分布在各个可用区中。同时，来自客户的常规请求平均分布在各个可用区中。 解决负载测试程序问题的正确答案是：
我不确定我是否可以理解这种情况。关于ELB IP解析，Route 53的默认行为是什么？无论如何，这些DNS记录具有60秒的TTL。在每个请求上重新解析DNS是否多余？此外，DNS解析是DNS服务本身的责任，而不是负载测试软件的责任，不是吗？ 我可以理解，来自具有负载测试软件的同一实例的请求将发送到同一LBed EC2，但是为什么它必须是同一可用区中的一个实例？只能通过基于地理位置或延迟的路由来实现，但是我在规范中找不到任何默认设置。
答案 0 :(得分：2)
问题在于粘性，请参见此处：https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
负载均衡器使用特殊的cookie将会话与 处理初始请求但遵循的实例 策略中指定的应用程序cookie的生存期 组态。负载均衡器仅插入一个新的粘性cookie 如果应用程序响应包括新的应用程序cookie。的 负载平衡器粘性cookie不会随每个请求更新。如果 应用程序cookie被明确删除或过期，会话 在发出新的应用程序cookie之前不再发粘。
第一个解决方案，即重新解析DNS，将创建新的会话，并且这将打破ELB的粘性。第二种解决方案是使用多个客户端，如果全局分布的客户端数量很大，则粘性不会成为问题。
PART 2：无法添加为注释，时间太长：
是的，我的回答是简单和不完整。
我们知道，ELB是2 AZ，将有2个具有不同IP的节点。不清楚多少IP取决于每个AZ上的请求数和服务器数。路由53为每个新请求轮换IP，第一次是在NodeA-IP，NodeB-IP中，第二次是NodeB-IP，NodeA-IP。负载测试应用程序将在每个新请求中获取第一个IP，并在2个可用区之间保持平衡。因为Node只能在其AZ内部路由，所以如果粘性cookie是针对NodeA的，并且请求到达NodeB，则NodeB会将其发送到AZ2中的一台服务器，而忽略AZ 1中服务器的cookie。
我需要运行一些测试，并使用带有经典ELB和2 AZ的Route53进行快速测试，并且每次IP都在旋转。我要测试的是是否有针对AZ 1的粘性cookie并到达节点2时，将不会将我转发至节点1（如果没有可用的服务器，则在文档中对此有趣的流程进行了说明）。希望在短时间内有更新。
答案 1 :(得分：1)
ELB位于多个可用区域中时，它始终具有多个公共IP地址-每个区域至少一个。
当您在DNS查找中请求这些记录时，您将获得所有这些记录（假设不是很多）或它们的子集（如果数量很多，在具有以下内容的活动群集中就是这种情况）大量流量），但它们是无序的。
如果负载测试软件解析端点的IP地址并精确地保留其中一个IP地址（这很可能会导致结果），那么所有流量都将流向平衡器的一个节点，该节点位于一个区域，并将流量发送到该区域中的实例。
那......
跨区域负载平衡
您的负载均衡器的节点将请求从客户端分发到已注册目标。启用跨区域负载平衡后，每个负载平衡器节点都会在所有启用的可用区中的已注册目标之间分配流量。禁用跨区域负载平衡后，每个负载平衡器节点只会在其可用区域中的所有已注册目标之间分配流量。
如果配置了粘性，则这些会话将首先进入一个可用区，然后坚持该可用区，因为它们坚持要降落的初始实例。如果启用了跨区域，则结果不是很清楚，但是在这种情况下（首次建立粘性时），平衡器节点可能更喜欢自己区域中的实例，或者这并不是问题的重点。粘性需要协调，并且跨AZ流量由于距离（通常<10 ms）而花费的时间不为零，但对于平衡器而言，最好选择其本地区域的实例以建立没有关联的会话。 / p>
实际上，配置负载测试软件以针对每个 请求重新解析端点并不是解决方案的重点-重点是确保（1）负载测试软件使用所有这些，并且不会精确地锁定（1）和（2），如果由于在负载下平衡器向外扩展而导致更多地址可用，则负载测试软件将扩展其目标池。
无论如何，这些DNS记录具有60秒的TTL。在每个请求上重新解析DNS是否多余？
该软件可能看不到TTL，可能无法使用TTL，并且如上所述，即使有多个可用，它也可能坚持一个答案，因为它只需要一个即可建立连接。 每个请求不是严格必需的，但确实可以解决问题。
此外，DNS解析是DNS服务本身的职责，不是负载测试软件，不是吗？
在这种情况下，“解析DNS”仅意味着进行DNS查找，无论在特定实例中是什么意思，无论是使用操作系统的DNS解析器还是直接查询递归DNS服务器。当软件建立与主机名的连接时，它将“解析”（查找）关联的IP地址。
另一种解决方案“使用第三方负载测试服务来发送来自全球分布式客户端的请求” 偶然解决了该问题，因为分布式客户端-即使他们坚持使用第一个客户端他们看到的地址-更有可能看到所有可用地址。 “全球”分布方面令人分心。
ELB依赖于请求在其面向外部的节点上的随机到达，以此作为平衡策略的一部分。设计忽略这一点的负载测试软件不能正确地测试ELB。两种解决方案都以不同的方式缓解了问题。
答案 2 :(得分：0)
刚刚发现另一条证据表明Route 53返回了多个IP并将其轮换用于ELB扩展方案：
默认情况下，当客户端执行DNS解析时，Elastic Load Balancing将返回多个IP地址，并在每个DNS解析请求中对记录进行随机排序。随着流量配置文件的更改，控制器服务将扩展负载均衡器以处理更多请求，并在所有可用区域中均等地扩展。
然后：
为确保客户端利用增加的容量，Elastic Load Balancing在DNS记录上使用TTL设置60秒。将这个不断变化的DNS记录纳入测试至关重要。如果您不能确保重新解析DNS或使用多个测试客户端来模拟增加的负载，则当Elastic Load Balancing实际上分配了更多IP地址时，测试可能会继续命中单个IP地址。
起初我没有意识到的是，即使常规流量在AZ之间平均分配，也不意味着启用了跨区域负载平衡。正如Michael所指出的那样，正常的流量自然会经过各个位置，并最终到达不同的可用区。 而且，正如测试中未明确提及的那样，可能无法使用跨可用区平衡。
https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/