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

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…