为什么 Elastic Load Balancing 不均衡路由我的负载均衡器流量？

简短描述

在以下情况下，ELB 可能会将流量不均衡地路由至您的目标：

• 客户端使用包含过期 TTL 的 DNS 记录将请求路由至负载均衡器节点的不正确 IP 地址。
• 已为负载均衡器启用粘性会话（会话绑定）。粘性会话使用 cookie 帮助客户端在 cookie 的生命周期内保持与同一实例的连接，这可能会随着时间的推移导致不均衡。
• 可用的正常实例并未均匀分布在可用区中。
• 特定容量类型的实例并未均匀分布在可用区中。
• 客户端和实例之间存在长期 TCP 连接。
• 该连接使用 WebSocket。

解决方法

确认流量不均衡

分析 ELB 访问日志（如果可用），以确认流量不均衡。使用命令行工具查找由负载均衡器路由到特定应用程序的请求数。

对于 Application Load Balancer：

awk '{print $5}' *.log | awk -F ":" '{print $1}' | sort | uniq -c | sort -r

对于 Classic Load Balancer：

awk '{print $4}' *.log | awk -F ":" '{print $1}' | sort | uniq -c | sort -r

ELB 将每个 ELB 节点的单独文件添加到存储桶中。您可以比较特定时间段内访问日志文件中的行数。

刷新 DNS 缓存

基于过期的 DNS 条目进行路由会导致不同可用区之间的 RequestCount 模式不均衡。有关更多信息，请参阅 Application Load Balancer 指标或 Classic Load Balancer 指标。刷新客户端的 DNS 缓存，以确保它将当前 DNS 记录用于负载均衡器节点。

**注意：**启用跨区域负载均衡后，负载均衡器仍能够在实例级别均衡请求。

对于使用 nscd 进行 DNS 缓存的 Linux 客户端，请运行以下命令之一：

sudo /etc/init.d/nscd restart

# service nscd restart

# service nscd reload

对于使用 dnsmasq 进行 DNS 缓存的 Linux 客户端，请运行以下命令之一：

$ sudo /etc/init.d/dnsmasq restart

# service dnsmasq restart

对于使用 BIND 进行 DNS 缓存的 Linux 客户端，请运行以下命令之一：

# /etc/init.d/named restart

# rndc restart

# rndc exec

对于 Windows 客户端，请运行以下命令：

ipconfig /flushdns

**注意：**如果您已清除客户端的 DNS 缓存，但仍遇到缓存问题，请确保您的客户端应用程序未缓存 DNS 记录。

检查粘性会话配置

如果使用基于持续时间的会话粘性，请为您的特定使用案例配置适当的 cookie 过期时间。有关更多信息，请参阅：

• 粘性会话 (Application Load Balancer)
• 基于持续时间的会话粘性 (Classic Load Balancer)

如果从单个应用程序设置会话粘性，请尽可能使用会话 cookie 而不是永久性 cookie。有关更多信息，请参阅应用程序控制的会话粘性 (Classic Load Balancer)。

检查跨可用区的正常实例分配

如果您的可用区中可用正常实例的数量不相等，并且已禁用跨区域负载均衡，则 ELB 必须在受影响的可用区中的较少实例之间均衡请求。剩余的正常实例将处理更多的请求以进行补偿，这可能会对性能产生负面影响。

**注意：**跨实例或可用区的流量负载不均衡并不一定意味着资源利用率也不均衡。例如，当负载均衡器进程后面的一个或多个实例的请求速度比其他实例快时，就会发生不均衡。

在每个启用的可用区中保持相同数量的实例。要将更多实例添加为负载均衡器目标，请参阅：

• 在目标组中注册目标 (Application Load Balancer)
• 注册或取消注册目标 (Network Load Balancer)
• 注册或取消注册 Classic Load Balancer 的 EC2 实例

对于 Classic Load Balancer 和 Network Load Balancer，请考虑启用跨区域负载均衡，以在实例级别而不是可用区级别分配请求。有关更多信息，请参阅跨区域负载均衡 (Network Load Balancer) 或为 Classic Load Balancer 配置跨区域负载均衡。始终为 Application Load Balancer 启用跨区域负载均衡。

检查实例类型分配

具有 HTTP 或 HTTPS 侦听器的 Classic Load Balancer 可能会将更多流量路由到容量更大的实例类型。此分配旨在防止容量较低的实例类型具有过多的未完成请求。有关更多信息，请参阅实例类型。最佳做法是使用相近的实例类型和配置，以减少容量差距和流量不均衡的可能性。

如果在不同的 Amazon 系统映像 (AMI) 上运行相近容量的实例，也可能会出现流量不均衡。在这种情况下，为了支持更高容量的实例类型，流量不均衡是可取的。

检查长期 TCP 连接

Elastic Load Balancing 使用轮询调度算法来路由 TCP 流量。客户端和实例之间的长期 TCP 连接在设计上会导致流量负载分配不均衡。因此，新实例需要更长的时间才能达到连接平衡。请务必检查可能导致问题的长期 TCP 连接的指标。另请注意，对于 TCP 侦听器，负载均衡器仅在连接级别分配流量。例如，这意味着经常重复使用连接来发送和接收多个 HTTP 请求的客户端可能会在实例级别产生不均衡的流量。如果您的应用程序支持更高层的网络协议（例如 HTTP、HTTPS、WebSocket 或 HTTP2），请考虑迁移到第 7 层负载均衡器。

检查负载均衡器的 RequestCount 模式和其他相关指标。有关更多信息，请参阅：

• Application Load Balancer 指标
• Network Load Balancer 的 CloudWatch 指标
• Classic Load Balancer 指标

检查 WebSocket 连接

使用带有 WebSocket 连接的负载均衡器的客户端在客户端和目标之间使用 1:1 连接。在 WebSocket 连接期间，此连接仍然锁定在目标上，从而导致流量分配不均衡。Application Load Balancer 为 WebSocket 提供原生支持。只有升级到 WebSocket 的新 HTTP 请求才会到达新目标。WebSocket 还可用于具有第 4 层侦听器的 Classic Load Balancer 和 Network Load Balancer。

有关详细信息，请参阅侦听器配置。

---