Redigeeri

Jagamisviis:

Azure Load Balancer algorithm

  • Artikkel

Azure Load Balancer is Azure's most performant Load Balancer all while keeping latency ultra-low. To learn more about Azure Load Balancer, visit Azure Load Balancer overview or Azure Load balancer components.

Azure Load Balancer uses a tuple-based hashing as the load-balancing algorithm.

Load balancing algorithm

By creating a load balancer rule, you can distribute inbound traffic flows from a load balancer's frontend to its backend pools. Azure Load Balancer uses a five-tuple hashing algorithm for the distribution of inbound flows (not bytes). Load balancer rewrites the headers of TCP/UDP headers flows when directing traffic to the backend pool instances (load balancer doesn't rewrite HTTP/HTTPS headers). When the load balancer's health probe indicates a healthy backend endpoint, backend instances are available to receive new traffic flows.

By default, Azure Load Balancer uses a five-tuple hash.

The five-tuple includes:

  • Source IP address
  • Source port
  • Destination IP address
  • Destination port
  • IP protocol number to map flows to available servers

You can also use session affinity distribution mode which uses two-tuple or three-tuple based load balancing.

Azure Load Balancer supports any TCP/UDP application scenario and doesn't close or originate flows. Load balancer also doesn't interact with the payload of any flow. Application payloads are transparent to the load balancer. Any UDP or TCP application can be supported.

Load balancer operates on layer 4 and doesn't provide application layer gateway functionality. Protocol handshakes always occur directly between the client and the backend pool instance. Because the load balancer doesn't interact with the TCP payload nor does it provide TLS offload, you can build comprehensive encrypted scenarios. Using load balancer gains large scale-out for TLS applications by ending the TLS connection on the VM itself. For example, your TLS session keying capacity is only limited by the type and number of VMs you add to the backend pool.

A response to an inbound flow is always a response from a virtual machine. When the flow arrives on the virtual machine, the original source IP address is also preserved. Every endpoint is answered by a VM. For example, a TCP handshake occurs between the client and the selected backend VM. A response to a request to a front end is a response generated by a backend VM. When you successfully validate connectivity to a front end, you're validating the connectivity throughout to at least one backend virtual machine.

Next steps