How does Azure Load Balancer distribute traffic across VMs?

Azure Load Balancer is a core component for building highly available and scalable applications in Azure. It efficiently distributes incoming network traffic across multiple Virtual Machines (VMs) within a backend pool, ensuring optimal resource utilization and continuous service availability. This guide delves into the mechanisms Azure Load Balancer employs for traffic distribution, its key features, and important considerations for effective deployment.

How Azure Load Balancer Works: The Core Mechanism

At its heart, Azure Load Balancer distributes traffic across healthy VMs within a backend pool primarily using a hashing algorithm. It directs traffic based on various aspects of the incoming connection, ensuring that requests are routed efficiently and, where necessary, consistently.

Hashing Algorithms and Session Persistence

Azure Load Balancer utilizes a hash-based distribution method. A hash function takes relevant traffic data (such as source IP, destination IP, and ports) and computes a hash value. This value then determines which VM in the backend pool receives the traffic. This approach is crucial for maintaining session persistence, directing subsequent requests from the same client within the same session to the same VM.

Azure offers different hashing algorithms, often referred to by the number of elements they consider:

• 5-tuple hash: This is the default and most common algorithm. It considers the source IP address, source port, destination IP address, destination port, and protocol type. This provides the strongest session persistence, as a specific client’s connection (or flow) will consistently go to the same backend VM for its entire duration. This is ideal for applications requiring session state, such as shopping carts or interactive web applications.
• 3-tuple hash: This algorithm considers the source IP address, destination IP address, and protocol type. It offers less session persistence than the 5-tuple but can provide more even distribution for certain scenarios.
• 2-tuple hash: This algorithm considers only the source IP address and destination IP address. It provides the weakest session persistence but can lead to a more even distribution of traffic across VMs, making it suitable for stateless applications or APIs where session affinity is not required.

The choice of algorithm depends on your application’s specific requirements for session persistence versus even distribution.

Ensuring Health and Availability

Beyond traffic distribution, Azure Load Balancer plays a vital role in maintaining the health and availability of your application by continuously monitoring the backend VMs.

Health Probes

Health probes are essential for monitoring the health and availability of the VMs in the backend pool. These probes are regular checks performed by the load balancer to each VM. If a VM fails a health probe repeatedly, it is automatically removed from the active backend pool, ensuring that traffic is not directed to failing or unresponsive instances.

Azure Load Balancer supports different types of health probes:

• TCP probes: These check if a specific port on the VM is listening and responsive.
• HTTP probes: These send an HTTP GET request to a specified path on the VM. The VM is considered healthy if it responds with a successful HTTP status code (e.g., 200 OK) within a configured timeout.
• HTTPS probes: Similar to HTTP probes, but they use HTTPS, providing an encrypted health check.

Configurable parameters for health probes include probe interval (how often checks are performed), unhealthy threshold (how many consecutive failures before a VM is marked unhealthy), and probe timeout (how long to wait for a response). These parameters should be tuned based on your application’s startup times and responsiveness.

Backend Pools

Backend pools are logical groups of VMs that are designated to receive traffic from the load balancer. VMs can be added to or removed from a backend pool dynamically, allowing for seamless scaling, maintenance, and updates without interrupting service. This flexibility is key to efficient resource utilization and application management.

Integration for Resiliency and Scale

Azure Load Balancer integrates seamlessly with other Azure services to enhance the redundancy and scalability of your deployments.

• Availability Sets: When VMs are placed in an Availability Set, they are distributed across different fault domains (isolated hardware racks) and update domains (groups of VMs that can be updated simultaneously). This protects your application from single points of failure, such as hardware failures or planned maintenance events, by ensuring that not all VMs are affected at once. Azure Load Balancer ensures traffic is distributed across these resiliently deployed VMs.
• Virtual Machine Scale Sets (VMSS): Virtual Machine Scale Sets allow for automated scaling of VMs based on demand or predefined schedules. When integrated with an Azure Load Balancer, VMSS can automatically add or remove VM instances from the load balancer’s backend pool, providing elasticity and high availability. This simplifies management and ensures your application can handle varying traffic loads efficiently.

Key Considerations & Best Practices

Load Balancer SKUs: Basic vs. Standard

Azure Load Balancer offers two SKUs: Basic and Standard. The Standard SKU is recommended for production workloads due to its advanced capabilities, including:

• Support for Availability Zones, providing higher resilience against datacenter-level outages.
• Increased scale limits for backend pool size and rules.
• Integration with Virtual Machine Scale Sets by default.
• Enhanced monitoring and diagnostics capabilities.
• Outbound connections are explicitly defined through outbound rules.

For critical production environments, the Standard SKU offers superior reliability and scalability.

Advanced Health Probe Configuration

Proper health probe configuration is vital. For applications with longer startup times, you might need to adjust the probe interval and unhealthy threshold to prevent VMs from being prematurely marked unhealthy. Customizing the probe path to a specific application endpoint (e.g., /healthcheck) that truly indicates application readiness, rather than just server availability, provides more accurate health monitoring.

Algorithm Choice and Session Persistence Scenarios

The selection of the load balancing algorithm (5-tuple, 3-tuple, or 2-tuple hash) directly impacts session persistence. For applications like e-commerce platforms requiring strong session affinity (e.g., for shopping carts), the 5-tuple hash is ideal. For stateless APIs or applications where even distribution is prioritized over session persistence, a 2-tuple hash might be more suitable. Understanding your application’s session requirements is crucial for making the right choice.

Troubleshooting Common Issues

When troubleshooting Azure Load Balancers, common issues include VMs not receiving traffic or health probes failing. Key diagnostic tools and techniques include:

• Reviewing Azure diagnostics and network monitoring tools to check network connectivity, NSG (Network Security Group) rules, and routing.
• Analyzing Load Balancer metrics and logs to identify health probe failures, traffic flow patterns, and potential bottlenecks.
• Verifying Network Security Group rules to ensure that traffic is not being blocked to the backend VMs or the health probe ports.
• Checking VM operating system firewall settings to ensure they are not blocking incoming traffic or health probe requests.

Proactive monitoring and understanding traffic flow are key to quickly resolving issues.

None