Understanding Azure Load Balancing Solutions - Azure Load Balancer, Azure Application Gateway and Azure Traffic Manager

Introduction

In this article, we will look at the various load balancing solutions available in Azure and which one should be used in which scenario.

Background

Load balancers are the essential components when it comes to creating high available web applications. We have all used load balancers with traditional on premise servers where our application is running on N instances and a load balancer is sitting in front of these servers and distributing load to them based on some predefined algorithm and connection affinity settings.

Moving to the cloud, we need to understand how we can achieve the same load balancing using Azure components. Load balancing in Cloud applications require much more thought than having a simple load balancer in front of some servers as we could have services hosted on PaaS, we could have services running on separate instances for separate tenants and we could also have applications running on multiple servers that are geographically distributed across the world.

For this reason itself, there are multiple components available in Azure for load balancing. Each of these components have a different purpose and we need to choose the right component for the scenario to be able to achieve the optimal application architecture.

Azure Load Balancing Solutions

There are mainly 3 load balancing components available in Azure.

• Azure Load balancer
• Azure Application gateway
• Azure traffic manager

Let's start understanding each of these components one by one and try to understand when to use each component effectively.

Azure Load Balancer

Azure Load Balancer is a Load Balancer in a more classical sense as it can be used for balancing load for VMs in the same way we were using traditional load balancers with our on premise servers. Now, since Azure load balancer is designed for cloud applications, it can also be used to balance load to containers and PaaS applications along with VMs.

But this similarity with traditional load balancers ends here only mainly because the Azure load balancer that actually works is Transport Layer (Layer 4 of OSI model). Which would mean that it will distribute the network traffic in the same Azure data center but will not be able to use the features that tradition load balancers provided at session and application layer since these are the layer 7 constructs of OSI model.

The load balancer is configured with load balancing rules and these rules work at the port level. It accepts source and destination ports map them together so that whenever it receives a request for the source port, the request is forwarded to a virtual machine from a group of virtual machines (or application in VNET) attached to the load balancer on the destination port.

Azure load balancer can be used in two configuration modes:

• External - Public load balancing
• Internal - Internal load balancing

External - Public Load Balancing

In this mode, load balancer is assigned a public IP address to ensure that the load balancer can accept requests coming in from the internet. The load balancer will get called from the internet by the client applications and services, and then based on the configured rules, it will distribute the incoming traffic over VMs, containers, or apps.

Internal - Internal load balancing

The internal Load Balancer is essentially the same as external, but it uses a private IP address and thus it can be called only from the applications within the virtual network to which it is attached.

Azure load balancer helps us design high availability at the infrastructure level, however since there are scenarios where more advanced features and services are required from our load balancing component like connection affinity, security, SSL termination, etc. we cannot use Azure load balancers. To achieve these advanced features, we need a solution that could handle layer 7 constructs of OSI model, i.e., application, session, etc. Let's look at how we can achieve this in the next section.

Azure Application Gateway

Azure application gateway is a level 7 load balancer and thus it has access to application and session payload which makes it possible for the application gateway to provide much more feature packed load balancing like sticky sessions, connection affinity, etc. Since Application gateways have more information compared to the Azure load balancer, more complex routing and load balancing can be configured. Application gateway acts as a reverse proxy service. It terminates the client connection and forwards request to back endpoints.

IMHO, if we are working at an application level where the load balancer should be available publicly, there are more use cases in which application gateway makes much more sense to use rather than load balancer.

Application gateway can be thought of (Load balancer ++) that is running on layer 7 and provides more features than load balancer. Application gateway can also be used to route traffic based on URL which is very useful when it comes to developing multi-tenant applications where each tenant had separate instances of VMs running and the tenant identifier comer in the URL.

Azure Traffic Manager

So far, we have seen the load balancing solutions that cater to the load balancing within a data center. Load balancers and application gateways are the components that are to be used to achieve High Availability within a data center. But with cloud, we can also architect our applications in such a way that they are geographically distributed. How will we balance the load across geographies then.

Azure traffic manager is exactly for this purpose only. Azure traffic manager uses DNS to redirect requests to an appropriate geographical location endpoint. Traffic Manager does not see the traffic passing between the client and the service. It simply redirects the request based on most appropriate endpoints. Geographical location endpoints are internet facing reachable public URLs.

Azure Traffic Manager works at the DNS level, i.e., it distributes the load over multiple regions and data centers using the rules configured at the DNS level. The client makes a DNS request and, based on the location of the DNS, Azure Traffic Manager will find the nearest region and sends that back to the client via a DNS response.

Designing Highly Available Apps

When we are designing large scale applications that are highly available, we need to use all these components together. The below image shows a scenario where the application is geographically distributed and is using AZURE TRAFFIC MANAGER to choose the nearest region. Then it is using APPLICATION GATEWAY to choose which application server to fetch response from. And finally, using a LOAD BALANCER for infrastructure level load balancing for database servers.

Point of Interest

In this article, we looked at how various Azure load balancing solutions are designed for a specific purpose in mind and using the right one for the right scenario (or a combination of them) can help us in creating highly available applications.

References

• https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview
• https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-introduction
• https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview
• https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-load-balancing-azure

History

• 30^th July, 2018: First version