Azure 负载均衡器算法Azure Load Balancer algorithm

负载均衡器针对 UDP 和 TCP 应用程序提供了多种功能。Load balancer provides several capabilities for both UDP and TCP applications.

负载均衡算法Load balancing algorithm

你可以创建负载均衡规则，以将来自前端的流量分配到后端池。You can create a load-balancing rule to distribute traffic from the frontend to a backend pool. Azure 负载均衡器使用哈希算法来分配入站流（非字节）。Azure Load Balancer uses a hashing algorithm for distribution of inbound flows (not bytes). 负载均衡器会重写发往后端池实例的流的标头。Load balancer rewrites the headers of flows to backend pool instances. 当运行状况探测指示后端终结点正常时，可以使用一个服务器来接收新流量。A server is available to receive new flows when a health probe indicates a healthy back-end endpoint.

默认情况下，负载均衡器使用五元组哈希。By default, Load balancer uses a Five-tuple hash.

哈希包括：The hash includes:

  • 源 IP 地址Source IP address
  • 源端口Source port
  • 目标 IP 地址Destination IP address
  • 目标端口Destination port
  • 用于将流映射到可用服务器的 IP 协议号IP protocol number to map flows to available servers

与源 IP 地址的关联是使用二元组或三元组哈希创建的。Affinity to a source IP address is created by using a two or three-tuple hash. 同一个流的数据包将会抵达负载均衡前端后面的同一实例。Packets of the same flow arrive on the same instance behind the load-balanced front end.

当客户端从同一源 IP 启动新流时，源端口将会更改。The source port changes when a client starts a new flow from the same source IP. 因此，五元组哈希可能会导致流量定向到不同的后端终结点。As a result, the five-tuple hash might cause the traffic to go to a different backend endpoint. 有关详细信息，请参阅配置 Azure 负载均衡器的分配模式。For more information, see Configure the distribution mode for Azure Load Balancer.

下图显示了基于哈希的分配：The following image displays the hash-based distribution:

基于哈希的分发

图：基于哈希的分发Figure: Hash-based distribution

应用程序独立性和透明度Application independence and transparency

负载均衡器不直接与 TCP、UDP 或应用程序层进行交互。Load balancer doesn't directly interact with TCP or UDP or the application layer. 可以支持任何 TCP 或 UDP 应用程序方案。Any TCP or UDP application scenario can be supported. 负载均衡器不会关闭或发起流，也不会与流的有效负载进行交互。Load balancer doesn't close or originate flows or interact with the payload of the flow. 负载均衡器不提供任何应用程序层网关功能。Load balancer doesn't provide application layer gateway functionality. 协议握手始终直接在客户端与后端池实例之间进行。Protocol handshakes always occur directly between the client and the back-end pool instance. 对入站流做出的响应始终是来自虚拟机的响应。A response to an inbound flow is always a response from a virtual machine. 当流抵达虚拟机时，也会保留原始的源 IP 地址。When the flow arrives on the virtual machine, the original source IP address is also preserved.

  • 每个终结点由某个 VM 应答。Every endpoint is answered by a VM. 例如，TCP 握手在客户端与选定的后端 VM 之间发生。For example, a TCP handshake occurs between the client and the selected back-end VM. 对前端请求做出的响应是后端 VM 生成的响应。A response to a request to a front end is a response generated by a back-end VM. 成功验证与前端的连接后，将会验证与至少一个后端虚拟机的整个连接。When you successfully validate connectivity to a front end, you're validating the connectivity throughout to at least one back-end virtual machine.
  • 应用程序有效负载对于负载均衡器是透明的。Application payloads are transparent to the load balancer. 可以支持任何 UDP 或 TCP 应用程序。Any UDP or TCP application can be supported.
  • 由于负载均衡器不会与 TCP 有效负载进行交互并提供了 TLS 卸载，因此你可以构建全面的加密方案。Because the load balancer doesn't interact with the TCP payload and provide TLS offload, you can build comprehensive encrypted scenarios. 使用负载均衡器可通过在 VM 自身上终止 TLS 连接来实现 TLS 应用程序的大规模横向扩展。Using load balancer gains large scale-out for TLS applications by ending the TLS connection on the VM itself. 例如，将会根据添加到后端池的 VM 类型和数目限制 TLS 会话密钥容量。For example, your TLS session keying capacity is only limited by the type and number of VMs you add to the back-end pool.

后续步骤Next steps