Skip to main content

Azure Load Balancers - HTTP/External/Internal/Global load balancers

By
In this post we'll take a look on different types of load balancers that are available in Azure. The main scope is to understand what is the role of each load balancer and when we shall use each type of load balancer.

What is a Load Balancer?
It is a system that distributes the workload across multiple instances.
For more information related to how does it work and what are the base principles I invite you to take a look on Wikipedia - https://en.wikipedia.org/wiki/Load_balancing_(computing).

What types of Load Balancer are available on Azure?
Personally I would say that there are 4 types of load balancers that are available on Azure:

  • HTTP based Load Balancer
  • Internal Load Balancer
  • External Load Balancer
  • Global Load Balancer
Each of them can be used in different situations and they never exclude each others. This means that you might need to use multiple types of Load Balancer, based on what you want to achieve. 

HTTP based Load Balancer (Application Gateway)
The most common one in our days and comes out of the box in Azure. It is used to distribute HTTP traffic between multiple instances. 
Remarks: You will find HTTP based Load Balancer in Azure with the following name: Application Gateway.

This Load Balancer has the capacity to manage stateful connection (sticky connections), where requests from the same system/user will be redirected all the time to the same machine. Additional to this, for SSL connections, the secure connection is terminated on the Load Balancer itself. It means higher performance, but content is decrypted at Application Gateway level, content checked and encrypted again to be redirected to the target instance (SSL offload).

Application Gateway is not free. Even if it is included in some services out of the box (like App Service), for other cases like when you have VMs behind it, you'll need to pay per hour and the amount of data that is processed. 

Internal Load Balancer
It is an internal Load Balancer used to balancer internal connection between instances (VMs) that are not public available (from the internet). it is used to distribute requests that are coming from other systems that are in the same Virtual Network with the instances that are balanced (see below diagram).

An Internal Load Balancer can be configuring by creating a Load Balancer and adding it to the Azure Virtual Network. Once you done this,  you'll need to define rules to block/allow traffic based on your needs. In comparison with the next type of load balancer, Internal Load Balancer is free.

External Load Balancer
Similar with Internal Load Balancer, but used to balance incoming traffic that comes outside the Azure Virtual Network. Very often, everything that is outside the Virtual Network is called internet, because you don't have any control on it.
In contrast with HTTP based Load Balancer, the SSL connection is terminated at instance level. The redirection decision is done at transport and network layer. Because of this, this kind of balance can be used only for stateless connection (2 requests are not guaranteed that will be redirected to the same instance).


Similar with Application Gateway load balancer.

Global Load Balancer
The concept of having a Global Load Balancer can be used when you have multiple deployment of the same system in different Azure Regions. Global Load Balancer runs at Global scale, on all Azure Regions and is able to detect when one of the deployments has issues and can redirect traffic to another one. 
The service that stays behind it is Azure Traffic Manager and allows us to balance the load based on different criterias, including client location. It can be used with success especially for high distributed systems.
In contrast with previous load balancers that in one way or another resides closer to your application (system), Global Load Balancer resides on all Azure Regions and from some perspective is completely outside your system.

Can I use multiple Load Balancer for the same system?
Yes, you can and it is highly recommended. Let's take a example of a system that is deployed in multiple location (Asia, USA, Europe). The system is offering a image processing system, that allows people to count how many people are in a picture
The system contains a web endpoint used to submit pictures and a bunch of VMs running Linux that are processing the image. There are different types of VMs that analyze the image (one analyze and do the actual count, one do some pre-processing of the image and other types of VMs are isolate the human faces.


As you can see above in the diagram, Image Pre-Processing and Image Processing are in the same virtual network, behind an internal load balancer and automatically distribute the load. The image analyser VMs are accessible from the web applications - because of this an external load balancer needs to be used.
Web Applications already have an Application Gateway in front of them that balance the load. Additional to this, the system is deployed in 3 different regions across the globe. This means that we need a global load balancer to redirect the requests to the appropriate Azure Region when the system is deployed. Additional to this, global load balancer is able to detect a failure of the system and redirect traffic to the healthy regions, where the system runs as expected.

Conclusion
In this post we discover what are the 4 types of Load Balancers that are available on Azure. We shall remember the following things:

  • Global Load Balancer (Traffic Manager) - It offers us requests distribution across regions
  • HTTP based Load Balancer (Application Gateway) - It offers us requests distribution for HTTP(s) requests for most of Azure Services
  • External Load Balancer - Allows us to balance traffic that comes outside our Virtual Network
  • Internal Load Balancer - Allows us to balance traffic that comes from our Virtual Network to other systems that are in the same Virtual Network
The last two types of load balancers are most common used together with VMs.
Labels:

Comments

Post a Comment

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

By
After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(...
Post a Comment
Read more

How to audit an Azure Cosmos DB

By
In this post, we will talk about how we can audit an Azure Cosmos DB database. Before jumping into the problem let us define the business requirement: As an Administrator I want to be able to audit all changes that were done to specific collection inside my Azure Cosmos DB. The requirement is simple, but can be a little tricky to implement fully. First of all when you are using Azure Cosmos DB or any other storage solution there are 99% odds that you’ll have more than one system that writes data to it. This means that you have or not have control on the systems that are doing any create/update/delete operations. Solution 1: Diagnostic Logs Cosmos DB allows us activate diagnostics logs and stream the output a storage account for achieving to other systems like Event Hub or Log Analytics. This would allow us to have information related to who, when, what, response code and how the access operation to our Cosmos DB was done. Beside this there is a field that specifies what was th...
Post a Comment
Read more

Cloud Myths: Cloud is Cheaper (Pill 1 of 5 / Cloud Pills)

By
Cloud Myths: Cloud is Cheaper (Pill 1 of 5 / Cloud Pills) The idea that moving to the cloud reduces the costs is a common misconception. The cloud infrastructure provides flexibility, scalability, and better CAPEX, but it does not guarantee lower costs without proper optimisation and management of the cloud services and infrastructure. Idle and unused resources, overprovisioning, oversize databases, and unnecessary data transfer can increase running costs. The regional pricing mode, multi-cloud complexity, and cost variety add extra complexity to the cost function. Cloud adoption without a cost governance strategy can result in unexpected expenses. Improper usage, combined with a pay-as-you-go model, can result in a nightmare for business stakeholders who cannot track and manage the monthly costs. Cloud-native services such as AI services, managed databases, and analytics platforms are powerful, provide out-of-the-shelve capabilities, and increase business agility and innovation. H...
Post a Comment
Read more