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 -

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.

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.


Popular posts from this blog

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 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 …

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…