| Category | |
| Azure Load Balancer – Blog No 1 | |
| Time to Read | |
| 25 Minutes | |
| Who should read this blog? | |
| If you want to learn about the load balancer concept in Azure |
Preface
Let me start this blog with a story! This is a very famous story about 2 cats named Lin and Win, who got a freshly baked loaf of bread and started fighting over it that who eats the bread. The fight was intervened by a monkey named LB, LB said let’s see the bigger picture and share the bread, Monkey divided the bread into two pieces and shared it among the cats. The cats sat side by side, munching on their respective portions, and soon discovered that sharing brought them even greater joy than fighting.
The word spread throughout the village, reminding everyone that cooperation and sharing can bring far more happiness than any selfish quarrel.
I am sure you might have heard another version of the story too. Lol !! But our monkey is not a villain. He is a perfect load balancer.
What is Azure Load Balancer?
What is Azure Load Balancer?
In today’s digital era, applications handle a large chunk of data and hence would need several instances of computing resources. These instances need to share the data among themselves evenly so that no one machine gets overloaded while other machines are underutilized.
Azure Load Balancer, a powerful service provided by Microsoft Azure, plays a vital role in achieving these objectives. It acts as a traffic distributor, evenly distributing incoming requests across multiple virtual machines (VMs) or backend resources, thus optimizing performance and preventing overload. In this blog post, we’ll explore the benefits and features of Azure Load Balancer, as well as discuss how it can enhance the availability and scalability of your applications.
How it works?
Azure Load Balancer is a Layer-4 (TCP/UDP) load balancer that enables the distribution of incoming network traffic across multiple backend resources such as VMs, virtual machine scale sets, or availability sets. It acts as a traffic manager, efficiently balancing the workload and enhancing the overall performance of applications.
Most people get confused between Azure Loadbalancer and F5 Loadbalancer LTM. Kindly note while the F5 load balancer is a Layer 7 load balancer that breaks the TCP session, for its frontend it has a TCP session between a client and its Frontend IP address while for the backend it has a TCP session between an automap IP address, and the backend server IP. So F5 does both the SNAT and DNAT in this process.
While Azure Loadbalancer does only DNAT based on the distribution mode selected and does not perform any SNAT operation, the backend server still sees the client IP address as a source. So the TCP session is essentially between the Client and Server machine while the load balancer is bypassed for the actual flow of the traffic post the DNAT.
Azure Load Balancer provides several load-balancing algorithms to suit different application requirements: Below are the distribution modes Azure load balancer supports –
- Hash-Based(5 tuple based)
- Session Persistence ( 2 tuple and 3 tuple based)
Let’s understand them in detail –
Hash-Based Algorithm
Let’s assume we have the following traffic hit the load balancer :
Source IP Address: 10.1.1.1 (Client Ip address)
Source Port: 3000
Destination IP Address: 4.4.4.4(Loadbalancer Frontend IP)
Destination Port: 80
Protocol: TCP
To calculate the hash value, you can concatenate the attributes together and then apply a suitable hash function. Here’s an example using a basic concatenation and hash function approach:
Concatenated String: “10.1.1.1:3000-4.4.4.4:80-TCP”
Assuming we use the SHA-256 hash function for this example, the hash value for these 5 tuples would come as – “7f8be3b58eb1b18a478fdc9978aee2cfd9b1f8c4f54a803ae3b77b3fdd63a28a”
Now let me change the client IP address to 10.1.1.2 while other fields remain the same
Source IP Address: 10.1.1.2 (Client Ip address)
Source Port: 3000
Destination IP Address: 4.4.4.4(Loadbalancer Frontend IP)
Destination Port: 80
Protocol: TCP
the resulting hash sha-256 value would come as – a6a3dcdd10cc635beda1f52f15e773b30ab6151d430180b4e2ef46a5cc1d98e6
The resulting hash value is unique to the combination of the source IP, source port, destination IP, destination port, and protocol. This hash value can be used by the Azure Load Balancer to determine which backend resource should handle the corresponding network traffic. So for the first hash value Azure load balancer could select one machine while for another hash value it could select another machine.
It’s important to note that the actual hashing algorithm and implementation used by Azure Load Balancer may be more complex and optimized for performance and scalability. The example provided above is a simplified demonstration to illustrate the concept of hashing based on the given attributes.
Note
Most people think that load balancer will equally load share between the backend machines,which is not true. Hashing based algorithm is not a round robin method also, it send traffic based on the calculated hash and depnds on the fact that there are multiple combinations of 5 tuple to distribute the traffic evenly(not equally) to backend machines.
Session Persistence
This distribution mode uses a two-tuple (source IP and destination IP) or three-tuple (source IP, destination IP, and protocol type) hash to route to backend instances. When using session persistence, connections from the same client will go to the same backend instance within the backend pool.
Session persistence mode has two configuration types:
- Client IP (2-tuple) – Specifies that successive requests from the same client IP address will be handled by the same backend instance as the destination IP will always be the load balancer frontend IP address.
- Client IP and protocol (3-tuple) – Specifies that successive requests from the same client IP address and protocol combination will be handled by the same backend instance. So the traffic from one client with TCP protocol could choose one backend server while traffic from the same client with UDP protocol could choose a different backend server. Any variation in 3 tuples will calculate the different hash values.
Configuring the distribution Modes
The distribution modes algorithm could be selected as below –
The Default method is hash-based, if you want to choose session persistence choose Client IP if you want to choose 2 tuple-based session persistence, and choose Client Ip and protocol if you want to choose 3 tuple based on your requirement.
