排查您的 Network Load Balancer 问题 - Elastic Load Balancing
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

排查您的 Network Load Balancer 问题

以下信息可帮助您排查与 Network Load Balancer 相关的问题。

已注册目标未处于可用状态

如果目标进入 InService 状态所花费的时间超过预期,则该目标可能无法通过运行状况检查。您的目标未处于可用状态,除非通过一次运行状况检查。有关更多信息,请参阅 目标组的运行状况检查

验证您的实例是否通过运行状况检查,然后检查以下各项:

安全组不允许流量

与实例关联的安全组必须允许来自负载均衡器的使用运行状况检查端口和运行状况检查协议的流量。有关更多信息,请参阅 目标安全组

网络访问控制列表 (ACL) 不允许流量

与实例子网以及负载均衡器子网关联的网络 ACL 必须允许来自负载均衡器的流量和运行状况检查。有关更多信息,请参阅 网络 ACL

请求未路由至目标

检查以下各项:

安全组不允许流量

与实例相关联的安全组必须允许侦听器端口上来自客户端 IP 地址 (如果目标通过实例 ID 指定) 或负载均衡器节点 (如果目标通过 IP 地址指定) 的流量。有关更多信息,请参阅 目标安全组

网络访问控制列表 (ACL) 不允许流量

与 VPC 的子网关联的网络 ACL 必须允许负载均衡器和目标在侦听器端口上双向通信。有关更多信息,请参阅 网络 ACL

目标处于未启用的可用区中

如果您在可用区中注册目标但未启用该可用区,这些已注册目标将无法从负载均衡器接收流量。

实例位于对等的 VPC 中

如果您在与负载均衡器 VPC 对等的 VPC 中拥有实例,则必须通过 IP 地址而不是实例 ID 将这些实例注册到负载均衡器。

目标接收比预期更多的运行状况检查请求

Network Load Balancer 的运行状况检查是分布式的,使用共识机制来确定目标运行状况。因此,目标可以接收的运行状况检查数量可以超过通过 HealthCheckIntervalSeconds 设置配置的数量。

目标接收比预期更少的运行状况检查请求

检查是否启用了 net.ipv4.tcp_tw_recycle。已知此设置会导致负载均衡器出现问题。net.ipv4.tcp_tw_reuse 设置被认为是更安全的替代设置。

运行状况不佳的目标收到来自负载均衡器的请求

当所有注册的目标皆运行状况不佳时,就会发生这种情况。如果至少有一个运行正常的已注册目标,则网络负载均衡器仅将请求路由到运行正常的已注册目标。

如果只有运行状况不佳的已注册目标,则网络负载均衡器会将请求路由到所有已注册目标(即失效时开放模式)。当所有目标都运行状况不佳且相应的可用区没有运行正常的目标可供发送请求时,网络负载均衡器会执行此操作,而不是从 DNS 中删除所有 IP 地址。

由于主机标头不匹配,目标无法通过 HTTP 或 HTTPS 运行状况检查

运行状况检查请求中的 HTTP 主机标头包含负载均衡器节点和侦听器端口的 IP 地址,但不包含目标和运行状况检查端口的 IP 地址。如果要通过主机标头映射传入请求,则必须确保运行状况检查与任何 HTTP 主机标头匹配。另一种选择是在其他端口上添加单独的 HTTP 服务,并配置目标组,改为使用该端口进行运行状况检查。或者,可以考虑使用 TCP 运行状况检查。

无法将安全组与网络负载均衡器关联

如果创建网络负载均衡器时没有关联安全组,则在创建后将无法关联安全组。您只能在创建时将安全组与负载均衡器相关联,或将安全组与最初使用安全组创建的现有负载均衡器相关联。

无法删除所有安全组

如果创建网络负载均衡器时关联了安全组,则必须始终至少有一个与之关联的安全组。您不能从负载均衡器中同时删除所有安全组。

TCP_ELB_Reset_Count 指标升高

对于客户端通过网络负载均衡器发出的每个 TCP 请求,都将跟踪该连接的状态。如果客户端或目标通过连接发送数据的间隔超过空闲超时期限,则连接将关闭。如果客户端或目标在空闲超时期限后发送数据,则会收到一个 TCP RST 数据包,以指示连接不再有效。此外,如果目标运行不正常,除非运行不正常的目标触发了负载均衡器故障断开,否则负载均衡器会为关联到目标的客户端连接上收到的数据包发送 TCP RST。

如果您在 UnhealthyHostCount 指标升高之前或之时看到 TCP_ELB_Reset_Count 指标出现峰值,则可能是发送了 TCP RST 数据包,因为目标开始失败但尚未被标记为运行不良。如果您在 TCP_ELB_Reset_Count 中看到持续升高且目标未被标记为运行不良,则可以查看 VPC 流日志,以便客户端发送与过期流相关的数据。

从目标到其负载均衡器的请求连接超时

检查目标组是否启用了客户端 IP 保留。启用客户端 IP 保留后,不支持 NAT 环回(也称为发夹转换)。如果实例是它注册到的负载均衡器的客户端,且它启用了客户端 IP 保留,则连接仅在请求路由到不同的实例时才会成功。如果请求路由到发送请求的同一个实例,连接会超时,因为源地址和目的地 IP 地址相同。

如果实例必须将请求发送到它注册到的负载均衡器,请执行下列操作之一:

  • 禁用客户端 IP 保留。

  • 确保必须相互通信的容器位于不同的容器实例上。

当将目标移到 Network Load Balancer 时,性能会下降

Classic Load Balancer 和 Application Load Balancer 都使用多路复用连接,但 Network Load Balancer 不使用。因此,您的目标可能会在 Network Load Balancer 后面收到更多的 TCP 连接。请确保您的目标准备好处理它们可能会收到的连接请求量。

如果您的 Network Load Balancer 与 VPC 终端节点服务关联,则它可以支持到每个唯一目标(IP 地址和端口)的 55,000 个并发连接或每分钟大约 55,000 个连接。如果连接数超过该值,则会增大出现端口分配错误的几率。可以使用 PortAllocationErrorCount 指标跟踪端口分配错误。要修复端口分配错误,请将更多目标添加到目标组。有关更多信息,请参阅 CloudWatch 您的 Network Load Balancer 的指标

启用客户端 IP 保留时发生间歇性连接失败

如果启用客户端 IP 保留,则可能会遇到与目标上观察到的套接字重用相关的 TCP/IP 连接限制。如果客户端或客户端前面的 NAT 设备在同时连接到多个负载均衡器节点时使用相同的源 IP 地址和源端口,则可能会出现这些连接限制。如果负载均衡器将这些连接路由到同一个目标,则这些连接对目标来说似乎是来自同一源套接字,从而导致连接错误。当发生这种情况时,客户端可能会重试(如果连接失败)或重新连接(如果连接中断)。您可以通过增加源临时端口的数量或增加负载均衡器的目标数来减少此类连接错误。您可以通过禁用客户端 IP 保留或禁用跨区域负载均衡来防止此类连接错误。

此外,启用客户端 IP 保留后,如果连接到 Network Load Balancer 的客户端也连接到负载均衡器后面的目标,则连接可能会失败。要解决此问题,您可以在受影响的目标组上禁用客户端 IP 保留。或者,让您的客户端仅连接到 Network Load Balancer,或者仅连接到目标,但不能同时连接到此两者。

TCP 连接延迟

启用跨区负载平衡和客户端 IP 保留时,连接到同一负载均衡器上不同 IP 的客户端可能会路由到同一个目标。如果客户端对这两个连接使用相同的源端口,则目标将收到看似重复的连接,这可能导致连接错误和因建立新连接而导致 TCP 延迟。您可以通过禁用跨区负载均衡来防止此类连接错误。有关更多信息,请参阅 跨可用区负载均衡

预置负载均衡器时可能出现故障

Network Load Balancer 在预置时可能失败的原因之一是您使用已在其他地方指定或分配的 IP 地址(例如,为 EC2 实例分配的辅助 IP 地址)。此 IP 地址阻止设置负载均衡器,其状态为 failed。您可以通过取消分配关联的 IP 地址并重试创建过程来解决此问题。

DNS 名称解析包含的 IP 地址少于已启用的可用区

理想情况下,可用区中至少有一台运行正常的主机时,网络负载均衡器会为每个已启用的可用区提供一个 IP 地址。特定可用区中没有运行正常的主机并且禁用了跨区域负载均衡时,系统将从 DNS 中删除此可用区的相应网络负载均衡器的 IP 地址。

例如,假设您的网络负载均衡器启用了三个可用区,则所有可用区都至少有一个运行正常的已注册目标实例。

  • 如果可用区 A 中的已注册目标实例运行状况不佳,则系统将从 DNS 中删除网络负载均衡器的可用区 A 的相应 IP 地址。

  • 如果任意两个已启用的可用区没有运行正常的已注册目标实例,则系统将从 DNS 中删除网络负载均衡器的相应两个 IP 地址。

  • 如果在所有已启用的可用区中没有运行正常的已注册目标实例,则系统会启用失效时开放模式,并且 DNS 将在结果中提供来自三个已启用可用区的所有 IP 地址。