Skip to main content

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

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.

Comments

Popular posts from this blog

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

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(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP