排查 Azure 负载均衡器后端流量响应问题Troubleshoot Azure Load Balancer backend traffic responses

此页介绍有关 Azure 负载均衡器问题的疑难解答信息。This page provides troubleshooting information for Azure Load Balancer questions.

负载均衡器后端的 VM 不响应已配置数据端口上的通信VMs behind Load Balancer are not responding to traffic on the configured data port

如果后端池 VM 被列为正常且响应运行状况探测,但仍未参与负载均衡,或未响应数据流量,可能是由于以下某项原因:If a backend pool VM is listed as healthy and responds to the health probes, but is still not participating in the Load Balancing, or is not responding to the data traffic, it may be due to any of the following reasons:

  • 负载均衡器后端池 VM 未侦听数据端口Load Balancer Backend pool VM is not listening on the data port
  • 网络安全组要阻止负载均衡器后端池 VM 上的端口Network security group is blocking the port on the Load Balancer backend pool VM
  • 从相同的 VM 和 NIC 访问负载均衡器Accessing the Load Balancer from the same VM and NIC
  • 从参与的负载均衡器后端池 VM 访问 Internet 负载均衡器前端Accessing the Internet Load Balancer frontend from the participating Load Balancer backend pool VM

原因 1:负载均衡器后端池 VM 未侦听数据端口Cause 1: Load Balancer backend pool VM is not listening on the data port

如果 VM 未响应数据流量,这可能是因为参与的 VM 上的目标端口未打开,或者 VM 未侦听此端口。If a VM does not respond to the data traffic, it may be because either the target port is not open on the participating VM, or, the VM is not listening on that port.

验证及解决方法Validation and resolution

  1. 登录到后端 VM。Log in to the backend VM.
  2. 打开命令提示符并运行下列命令,以验证是否有应用程序在侦听数据端口:Open a command prompt and run the following command to validate there is an application listening on the data port:
    netstat -annetstat -an
  3. 如果端口状态未被列为“正在侦听”,请配置适当的侦听端口If the port is not listed with State "LISTENING", configure the proper listener port
  4. 如果端口被标记为“正在侦听”,请检查该端口的目标应用程序是否存在问题。If the port is marked as Listening, then check the target application on that port for any possible issues.

原因 2:网络安全组要阻止负载均衡器后端池 VM 上的端口Cause 2: Network security group is blocking the port on the Load Balancer backend pool VM

如果子网或 VM 上配置的一个或多个网络安全组要阻止源 IP 或端口,则此 VM 无法响应。If one or more network security groups configured on the subnet or on the VM, is blocking the source IP or port, then the VM is unable to respond.

对于公共负载均衡器,将使用 Internet 客户端的 IP 地址在客户端和负载均衡器后端 VM 之间通信。For the public load balancer, the IP address of the Internet clients will be used for communication between the clients and the load balancer backend VMs. 请确保后端 VM 的网络安全组允许使用客户端的 IP 地址。Make sure the IP address of the clients are allowed in the backend VM's network security group.

  1. 列出后端 VM 上配置的网络安全组。List the network security groups configured on the backend VM. 有关详细信息,请参阅管理网络安全组For more information, see Manage network security groups
  2. 在网络安全组列表中,检查:From the list of network security groups, check if:
    • 数据端口上的传入或传出流量是否受到干扰。the incoming or outgoing traffic on the data port has interference.
    • 检查 VM NIC 或子网上是否存在优先级高于允许负载均衡探测和流量的默认规则的“全部拒绝”网络安全组规则(网络安全组必须允许负载均衡器 IP 168.63.129.16 - 即探测端口)a Deny All network security group rule on the NIC of the VM or the subnet that has a higher priority that the default rule that allows Load Balancer probes and traffic (network security groups must allow Load Balancer IP of 168.63.129.16, that is probe port)
  3. 如果某规则要阻止流量,请将其删除并将规则重新配置为允许数据流量。If any of the rules are blocking the traffic, remove and reconfigure those rules to allow the data traffic.
  4. 测试 VM 是否现已开始响应运行状况探测。Test if the VM has now started to respond to the health probes.

原因 3:从相同的 VM 和网络接口访问负载均衡器Cause 3: Accessing the Load Balancer from the same VM and Network interface

如果负载均衡器后端 VM 上托管的应用程序正尝试通过同一网络接口访问同一后端 VM 上托管的其他应用程序,该操作不受支持且会失败。If your application hosted in the backend VM of a Load Balancer is trying to access another application hosted in the same backend VM over the same Network Interface, it is an unsupported scenario and will fail.

解决方法 - 可通以下方法解决该问题:Resolution You can resolve this issue via one of the following methods:

  • 为每个应用程序配置单独的后端池 VM。Configure separate backend pool VMs per application.
  • 在双 NIC VM 中配置应用程序,以便每个应用程序均使用自己的网络接口和 IP 地址。Configure the application in dual NIC VMs so each application was using its own Network interface and IP address.

原因 4:从参与的负载均衡器后端池 VM 访问 Internet 负载均衡器前端Cause 4: Accessing the internal Load Balancer frontend from the participating Load Balancer backend pool VM

如果在 VNet 中配置了内部负载均衡器,并且某个参与的后端 VM 正在尝试访问内部负载均衡器前端,则当将流映射到原始 VM 时会发生故障。If an internal Load Balancer is configured inside a VNet, and one of the participant backend VMs is trying to access the internal Load Balancer frontend, failures can occur when the flow is mapped to the originating VM. 不支持这种情况。This scenario is not supported.

解决方案:有几种方法来取消阻止此方案,包括使用代理。Resolution There are several ways to unblock this scenario, including using a proxy. 评估应用程序网关或其他第三方代理服务器(例如 nginx 或 haproxy)。Evaluate Application Gateway or other 3rd party proxies (for example, nginx or haproxy). 有关应用程序网关的详细信息,请参阅应用程序网关概述For more information about Application Gateway, see Overview of Application Gateway

详细信息 内部负载均衡器不会将出站发起连接转换为内部负载均衡器的前端,因为两者都位于专用 IP 地址空间中。Details Internal Load Balancers don't translate outbound originated connections to the front end of an internal Load Balancer because both are in private IP address space. 公共负载均衡器提供从虚拟网络内部专用 IP 地址到公共 IP 地址的出站连接Public Load Balancers provide outbound connections from private IP addresses inside the virtual network to public IP addresses. 对于内部负载均衡器,此方法可以避免不需要转换的唯一内部 IP 地址空间内发生 SNAT 端口耗尽。For internal Load Balancers, this approach avoids potential SNAT port exhaustion inside a unique internal IP address space, where translation isn't required.

负面影响是,如果来自后端池中 VM 的出站流尝试流向该 VM 所在池中内部负载均衡器的前端,并映射回到自身,则这两个流的分支不会匹配。A side effect is that if an outbound flow from a VM in the back-end pool attempts a flow to front end of the internal Load Balancer in its pool and is mapped back to itself, the two legs of the flow don't match. 由于它们不匹配,因此流会失败。Because they don't match, the flow fails. 如果流未映射回到后端池中的同一 VM(在前端中创建了流的 VM),则该流将会成功。The flow succeeds if the flow didn't map back to the same VM in the back-end pool that created the flow to the front end.

如果流映射回到自身,则出站流显示为源自 VM 并发往前端,并且相应的入站流显示为源自 VM 并发往自身。When the flow maps back to itself, the outbound flow appears to originate from the VM to the front end and the corresponding inbound flow appears to originate from the VM to itself. 从来宾操作系统的角度看,同一流的入站和出站部分在虚拟机内部不匹配。From the guest operating system's point of view, the inbound and outbound parts of the same flow don't match inside the virtual machine. TCP 堆栈不会将同一流的这两半看作是同一流的组成部分。The TCP stack won't recognize these halves of the same flow as being part of the same flow. 源和目标不匹配。The source and destination don't match. 当流映射到后端池中的任何其他 VM 时,流的两半将会匹配,且 VM 可以响应流。When the flow maps to any other VM in the back-end pool, the halves of the flow do match and the VM can respond to the flow.

此方案的缺点在于,当流返回到发起该流的同一后端时将出现间歇性的连接超时。The symptom for this scenario is intermittent connection timeouts when the flow returns to the same backend that originated the flow. 常见的解决方法包括:在内部负载均衡器后插入代理层并使用直接服务器返回 (DSR) 样式规则。Common workarounds include insertion of a proxy layer behind the internal Load Balancer and using Direct Server Return (DSR) style rules. 有关详细信息,请参阅 Azure 负载均衡器的多个前端For more information, see Multiple Frontends for Azure Load Balancer.

可以将内部负载均衡器与任何第三方代理相结合,或使用内部应用程序网关替代 HTTP/HTTPS 的代理方案。You can combine an internal Load Balancer with any third-party proxy or use internal Application Gateway for proxy scenarios with HTTP/HTTPS. 尽管可以使用公共负载均衡器来缓解此问题,但最终的方案很容易导致 SNAT 耗尽While you could use a public Load Balancer to mitigate this issue, the resulting scenario is prone to SNAT exhaustion. 除非有精心的管理,否则应避免此第二种方法。Avoid this second approach unless carefully managed.

后续步骤Next steps

如果上述步骤无法解决问题,请开具支持票证If the preceding steps do not resolve the issue, open a support ticket.