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.

Exposing Azure Storage Account Monitoring/Logs Via PowerBI

Monitoring Azure services is a complex task that is constantly evolving.  Not only are features changing (Azure Security Center, Operational Insights, Application Insights), the exact view they provide into a particular application can be spotty at best.  Obviously this is an area that Microsoft is working heavily on, and recent announcements regarding OMS are strides in this direction.  The goal, of course, is to provide a central, unified view into an application and the various components that support it.

One service that is core to almost everything provisioned in Azure is storage.  The storage team has worked on providing several metrics/monitoring/logging tools to help customers.  That is a good step one: access to the data.  Visualizing this data, however, leaves some room for improvement.

Currently:

1) You can use the old portal
The old portal provides a monitoring page that you can access.  You can add metrics to it, and view those metrics over a pre-defined period.  You can learn more about this toolset here.

2) You can use the new portal
The new portal is constantly under development.  Right now, you can select your storage blades and add a tile from a pre-set list of visualizations.  This is pretty cool feature, and combining this with the "dashboard" feature of the new portal will lead to some interesting monitoring capabilities.

The ultimately problem with the above two solutions is they are currently Azure specific.  In this day and age, it is rare to have an entire solution living in one single environment.  The visualizations provided are also determined by Microsoft.

In comes PowerBI

PowerBI is almost like the swiss-army knife of reporting.  It combines some really cool visualizations, a versatile query language, and the ability to add multiple data sources to a single report/dashboard.  This really allows us to start building application wide monitoring dashboards.

From an Azure storage perspective, the team has done a great job by making the monitoring/logging data accessible to everyone.  You can read more about this here.  In short, monitoring metrics are stored in non-visible tables in Azure Table Storage located on the storage account that you enabled monitoring.  As such, you can use this as a data source into powerbi.

Unfortunately, at time of writing, PowerBI does not support Azure Tables as a data source directly from the web interface.  So, for this you will have to use PowerBI desktop.

You can read this post to learn how to add Azure Table Storage as a data source in your PowerBI dashboards.  The one caveat here is that the tables for monitoring will not be returned from any list command (which is what PowerBI uses to get the list of tables).  As such, you need to use the following code snip-it to access your monitoring tables:

    Source = AzureStorage.Tables("<<storage account name>>"),
    HourlyMetricsTable = Source{[Name="$MetricsHourPrimaryTransactionsBlob"]}[Data],

If you put that at the start of your query (see this link for information on how to get to the advanced query editor), you will be able to access the tables and perform any post tasks you require.

You can find a list of the monitoring tables and schema information here.

One you have established the access, you can create whatever your heart desires (or your client for that matter).  Here is an example I hacked up.

I personally plan to use this type of reporting for performance baseline/monitoring purposes.  Have fun!

Course Review: Security in a Cloud-Enabled World

Just recently released, I decided to spend some time watching "Security in a Cloud-Enabled World" on MVA.

Overall I thought it was a pretty good course, although not what I expected it to be.  The course was broken down into 2 sections, the first focusing on Microsoft's role as a Trusted cloud provider and the second being a list of roadmaps that should be considered when clients chose a cloud provider to host their solutions.

Here are a couple of points I made about the course:

1)  It is good to get validated on what I am currently doing.  When I engage as an SA on a project, I review many aspects of the roadmaps outlined in this course.  This is good validation that I am on the right path.

2)  If you want to skip several hours of boring content, just read the poster and do the quizzes. 

3)  I am not a big fan of using "user reviews" when judging how secure a cloud provider or solution is.  In the second module, many references to how users perceived the security/availability of their solutions in the cloud.  Most, as you could expect, were favorable of the cloud.  While interesting material, it has been well documented that security is a lemons market.  While I am not saying that Azure's security stance is bad, I do think that ultimately it is very difficult for customers or end users to make even an educated guess on the subject.

4)  There was an inherent lack of focus on how to do things in Azure.  While I guess that wasn't the point of the course, I think that this material needs to be covered somewhere.  In one module, the presenter talks at length about access to the administrative consoles.  Some info is provided on MFA and about how to configure subscriptions for security, but no info is presented on how to audit these admin accounts, control these admin accounts, tie these admin accounts to PAM toolsets, etc.  I think there is a lot of room for content like this.

Overall it was a good course.  It was well structured, and provides a good framework for review when designing out cloud solutions.