Azure Load Balancing Options

Load balancing has always been a subject that involves many facets and decisions.  There are many things to consider when choosing the right strategy such as:

• Layer X Balancing

Load balancers generally work at the layer 4 or layer 7 (Of the OSI Model).  The tradeoff here is often performance versus features. 

• Balancing algorithms

Depending on the scenarios you are trying to achieve, you may want to utilize algorithms beyond the basics (random, round-robin) such as hash, least connections, least time.

• Session Persistence

Different persistence methods will work for different applications.  Most load balancers use http headers or cookies, but sometimes server side methods such as "Sticky Learn" and "Sticky Route" (yes yes, I know, NGINX terms) might be a better fit.

• Features

Such as SSL termination/offloading, Application Firewalls, protocol support (HTTP/2, SPDY), HTTP acceleration, etc.

As an aside, there are obviously more things to consider when choosing a load balancing strategy.  Further, there is a ton of opinion on the topic.  A really good place to start would be http://1wt.eu/articles/2006_lb/index.html by the author of HAProxy.

For the purpose of this post, I will outline the main options available to deployments in Azure.

Azure Web App Service Default Balancing

For a long time now, web site deployed on Azure had an automatic scaling option.  Obviously, the load balancing technology would need to be aware of any changes to the back-end pool (either programmatically or via health checks or both).  It turns out that the web app service utilizes (or at least seems to) the Application Request Routing (ARR) module in IIS.  You can see a little bit more about this here.  You can learn more about the features of ARR here.  It is important to note that not all ARR features as exposed as part of this service.

Key Points

• Azure managed
• Default in the PaaS Layer (Only used for the PaaS layer)
• Configuration locked down by Microsoft AND not configurable
• Options are not documented
• Session affinity is enabled
• Can monitor Queue depth on IIS
• Monitors CPU usage
• Scope: Local

Azure Application Gateway

Going GA earlier this year, the Application gateway is designed to provide HTTP/HTTPS load balancing to virtual machines.  The main features is the ability to do SSL offloading, cookie-based session affinity, and standard HTTP load balancing.  It is a layer 7 balancer.  From what I can gather, this is probably gen 2 of the Service gateway (Code Repo, Channel 9) 

Key Points

• Azure Managed
• Proxy for Layer 7 (Http/Https ONLY)
• Can load balance for any service on a virtual network OR anything with a  public IP
• Load Balancing: URL Hash + Weight (load, not configurable)
• Health Checks: Standard url check, custom probe, server monitoring
• Session Persistence: cookie
• Scope: Local/Global

Azure Load Balancer

Azure load balancer can be deployed to virtual networks (with some restrictions) to provide Layer 4 balancing.  Further, the load balancer has been enhanced to ensure compliance with services such as SQL Always On.

Key Points

• Azure Managed
• Layer 4 balancing
• Internal and External variants
• Port forwarding options
• Limited monitoring capabilities
• Load Balancing: Hash (2-tuple, 3-tuple, 5-tuple)
• Health Checks: Standard
• Session Persistence: Hash
• Scope: Local

Azure Traffic Manager

The Azure traffic manager is a DNS based load balancer that can operate in multiple modes.  Some say that this type of load balancing is "layer 7" but that is a little misleading.  There is no packet filtering, inspection, etc being done.

Key Points

• Azure Managed
• "Layer 7" DNS based
• Only works on DNS names
• Health Checks: Standard
• Session Persistence: DNS TTL
• Scope: Global

3rd Party Options

There are a host of 3rd party options in the load balancing space.  From an Azure perspective, they fall into two categories.  The first is external to Azure.  These include services such as Incapsula and Cloudflare.  The second is internal to Azure, and generally hosted in IaaS.  These include products from Nginx, Kemp, etc.  While going through each of these options is out of scope for this post, they are included here as options that can be used as required.

Conclusion

The goal of this post was simply to break out the options.  Each of the ones above have various pros and cons that need to be mapped to the application under scope.  The important thing to note is that there is a good set of options to meet the desired goals.