Introduction to Azure Load Balancer
Load balancers enable scaling and high availability for applications and services. A load balancer consists of three components: frontend, backend, and routing rules.
Load balancers route requests from the frontend to the backend, where several instances of a service are deployed. This can be used for performance, distributing traffic evenly amongst endpoints in the backend, or for high availability, using several instances of services to ensure at least one endpoint is always accessible.
We will configure Azure internal Load Balancer, Azure Public Load Balancer, Backend Pool, Health probes, Azure load balancer rules, Azure inbound NAT rules and Azure Explicit outbound rules
 |
| Fig 1.1- Introduction to Azure Load Balancer |
1. Azure Internal Load Balancer
Lets start with creating the load balancer in Azure. As you know that Microsoft supports internal and public load balancers. Here in this section we are going to create an internal Load Balancer.
The internal load balancer is assigned a private IP address from the virtual network's subnet range for the frontend and targets the private IP addresses of backend services (often Azure virtual machines). Internal load balancers are typically used for non-internet-facing services that can only be accessible within the virtual network.
Step 1: Login to the Azure portal with your credentials
https://portal.azure.com
Step 2: Select Create a resource, then Load Balancer under Networking services.
Step 3: In the new pane, we must select a Subscription option and a Resource group option for where the load balancer is to be created. Then, we must provide information for the Name, Region, Type, and SKU options. In this case, we select Internal for Type to deploy an internal load balancer and set SKU to Standard.
Finally, we must select the virtual network and subnet with which the load balancer will be attached, as well as information about the IP address assignment, which can be static or dynamic.
Step 4: After entering all the necessary information, pick the Review + Create option to validate and deploy the load balancer.
2. Azure Public Load Balancer
The second type of load balancer in Azure is the public load balancer. The key difference is that a public load balancer is assigned a public IP address in the frontend and receives requests via the internet. The requests are routed to endpoints in the backend.
Step 1: Login to the Azure portal with your credentials
https://portal.azure.com
Step 2: Select Create a resource, then Load Balancer under Networking services.
Step 3: To create the load balancer, pick the Subscription and Resource group options in the new pane. Next, submit information for Name, Region, Type, and SKU. To deploy a public load balancer, select Public as the type and set SKU to Standard. Choosing Public as the load balancer type will somewhat modify the window.
We won't be able to choose a virtual network or subnet like we could with the internal load balancer. We can select options for Public IP address (new or existing), SKU, assignment, and IPv6.
The load balancer SKU determines the public IP address SKU, which is automatically transferred to the IP address.
Step 4: After entering all the necessary information, pick the Review + Create option to validate and deploy the load balancer.
3. Backend Pool Azure LB
After the load balancer is created, either internally or publicly, we need to configure it further in order to start using it. During the creation process, we define the frontend of the load balancer and know where traffic needs to go to reach the load balancer. But, in order to define where that traffic needs to go after reaching the load balancer, we must first define a backend pool.
Step 1: Login to the Azure portal with your credentials
https://portal.azure.com
Step 2: In order to create the backend pool, we must do the following:
In the Azure portal, locate the previously created load balancer (either internal or
public). In the Load balancer pane, under Settings, select Backend pools. Select Add to
add the new backend pool
Step 3: Click Add and a new pane will open. Here we can add the VMs we want to associate with the backend pool. Note that the VMs must be in the same virtual network as the load balancer and in the same availability set. Select the VMs that you want to add to the backend pool
Step 4: After the VMs are selected, they will appear under the Virtual machines list for creating the pool. Click Add to create the backend pool with the associated VMs
Step 5: The backend pool creation process takes a few minutes after entering the configuration. Following that, the linked resources will appear in the backend pool list.
4. Azure LB Health Probes
After defining the frontend and backend of the load balancer, traffic is distributed evenly to endpoints in the backend. What happens if one of the endpoints is unavailable? If the issue is not detected, some requests may fail temporarily or permanently. The load balancer sends requests to defined endpoints in the backend pool, which fail if directed to an unavailable server.
The load balancer includes two more components: health probes and rules. These components identify issues and define appropriate responses.
Step 1: To create a new health probe in the load balancer, we must do the following:
In the Azure portal, locate the previously created load balancer (either internal
or public). In the Load balancer pane, under Settings, select Health probes. Select Add to
add a new health probe
Step 2: In the Load balancer pane, under Settings, select Health probes. Select Add to add a new health probe. In the new pane, we need to provide information about the health probe's Name and IP version, or Protocol, we want to use, as well as configuring the Port, Interval, and Unhealthy threshold options
Step 3: After we select OK, the new health probe will be created and will appear on the list of available health probes associated with the load balancer
5. Azure LB Rules
The rules bind everything together and specify which health probe (if many) will monitor which backend pool. Rules enable port mapping from a load balancer's frontend to the backend pool, creating port relationships and forwarding incoming traffic.
Step 1: In the Azure portal, locate the previously created load balancer (either internal or public). In the Load balancer pane, under Settings, select Load balancing rules. Select Add to add a load balancing rule
Step 2: To configure a load balancer, enter the name, IP version, frontend IP address (if multiple), protocol, and port mapping (incoming traffic will be redirected to the backend port).
If we enable high-availability ports (only available on internal load balancers), this will remove the protocol options and enable load balancing on all ports for TCP and UDP protocols. Furthermore, we need to provide information for the Backend Port, Backend pool, Health probe, Session persistence, and Idle timeout (minutes) settings, and decide whether we want to use a Floating IP.
Step 3: After we select OK, a new rule will be created, which will appear on the list of available load balancing rules.
Frontend IP address is used and which backend the pool traffic will be forwarded to. The health probe is assigned to monitor the endpoints in the backend pool and to keep track of whether there are any unresponsive endpoints. We also create a port mapping that will determine which protocol and port the load balancer will listen on and, when the traffic arrives, where this traffic will be forwarded.
As its default distribution mode, Azure Load Balancer uses a five-tuple hash (source IP, source port, destination IP, destination port, and protocol type). If we change the session persistence to Client IP, the distribution will be two-tuple (requests from the same client IP address will be handled by the same VM). Changing session persistence to Client IP and protocol will change the distribution to three-tuple (requests from the same client IP address and protocol combination will be handled by the same VM).
6. Azure LB inbound NAT Rules
Azure Load Balancer has the option to enable inbound network address translation (NAT) rules. These rules redirect traffic from a certain port on the frontend to a specific port on the backend.
Inbound NAT rules direct traffic to a specific VM, whereas load balancer rules route traffic to a backend pool.
Step 1: Login to the Azure portal with your credentials
https://portal.azure.com
Step 2: In the Azure portal, locate the previously created load balancer (either internal or public). In the Load balancer pane, under Settings, select Inbound NAT rules. Select Add to add a new inbound NAT rule.
Step 3: we must enter information for the Name, Frontend IP address, IP Version (determined by the frontend IP address), Service, Protocol, and Port sections. We may also change the Idle timeout, which is set at four minutes by default. Choose Target virtual machine and Network IP configuration for the same machine (if the VM has several IP configurations).
Step 4: After we select OK, a new inbound NAT rule will be created.
7. Azure LB Explicit Outbound Rules
When creating load balancing rules, we can create implicit outbound rules. This will enable Source Network Address Translation (SNAT) for VMs in the backend pool and allow them to access the internet over the load balancer's public IP address (specified in the rule).
However, in some cases, implicit rules are insufficient, and we must define explicit outbound rules. Only public load balancers with the Standard SKU support explicit outbound rules (and SNAT in general).
Step 1: In the Azure portal, locate the previously created public load balancer. In the Load balancer pane, under Settings, select Outbound rules. Select Add to add the load balancing rule
Step 2: In the Outbound rules pane, enter the rule name and pick the Frontend IP address, Protocol (All, TCP, or UDP), Idle timeout, TCP reset, and Backend pool fields. To allocate ports, select options for port allocation, outbound ports, ports per instance (disabled when the maximum number of backend instances is selected), and maximum number of backend instances.
Outbound rules are based on frontend IP addresses, backend pool instances, and connections. Frontend IP addresses have a restricted number of available ports for connections.
Assigning extra IP addresses to the frontend increases the number of authorized connections. However, the number of connections per backend instance reduces as the number of instances increases.
If we set the default number of outbound ports, they are allocated automatically and without our intervention. If a VM scale set contains the default number of instances, port allocation is automatically performed for each VM. As the number of instances in a scale set increases, each VM's port allocation decreases.
To prevent this, change port allocation to manual and limit the number of instances or ports per instance. This ensures each VM has dedicated ports and prevents connection drops.
