Implementing Azure Internal Load Balancing

One of the recently announced new features of Azure is Internal Load Balancing (ILB) support. For a long time it’s been possible to define external endpoints for a virtual machine running in Azure. If you have multiple virtual machines you can configure the same endpoint on each and allow Azure to load balance traffic across them.

By distributing traffic across multiple hosts you’re able to service a greater number of incoming requests.

Load balancing can also help with high-availability: if a host in your load balanced set becomes unavailable (as judged by the configured probe behaviour) the Azure load balancer will stop sending traffic to it.

While this is useful for internet facing scenarios, until this week, if you were using the virtual private network functionality Azure offers, you couldn’t make use of it. As a result you’d end up having to implement Windows NLB or similar solutions – additional configuration and complexity that frankly, you probably don’t want. With the introduction of Azure ILB however, we can delegate the load balancing to Microsoft’s infrastructure instead.

The feature is only in preview for now so there are one or two wrinkles around configuration and it needs planning up front.

Pre-requisites

Prior to beginning I’m going to assume you’ve already got an Azure account and a subscription setup. You’ll also need to have setup a site-to-site VPN. There are plenty of resources out there which you can use to help get you to this point.

Create Regional Virtual Network

As noted in Scott Guthrie’s blog post announcing the new feature, “ILB is available only with new deployments and new virtual networks”. What isn’t obvious however, is that in order to be able to create an ILB you also need to be using another new feature: regional virtual networks.

As noted in the FAQ of that post about regional virtual networks, “The newly announced features [Reserved IP, Internal load balancing and Instance level Public IP] are all managed at a regional level, hence they are only available for deployments going into a Regional Virtual Network.”

The blog post does a good job of explaining how to create a regional virtual network but in summary it’s a case of:

  • Create a virtual network as normal
  • Export the virtual network configuration to XML
  • Delete your virtual network
  • Edit the downloaded XML and change AffinityGroup=”<NameOfYourAffinityGroup>” to Location=”<NameOfYourRegion”>
  • Recreate your virtual network with the updated XML configuration as input

Once you have your regional virtual network created  you can go ahead and create a cloud service and add VMs to it as normal.

Add an Internal Load Balancer Instance

Once you have a cloud service configured you can create an ILB associated with it. For the time being this is only possible through PowerShell but hey, you’re scripting all this configuration anyway so that you can re-do it quickly, easily and reliably in the future, right?

The commandlet you need is Add-AzureInternalLoadBalancer. You’ll need to pass in the  name of the cloud service you want to ultimately create the load balanced endpoint for, as well as picking a name for the ILB. You’ll need this later so name it sensibly. Optionally, you can specify an  IP and subnet within your virtual network to be used.

Add EndPoints to VMs in the Load Balanced Set

Each VM that’ll service requests needs to have an endpoint created and associated with the ILB you just created. Again, this can only be done through PowerShell at this time but the syntax is similar to creating a normal endpoint using the Add-AzureEndpoint commandlet except you use the -InternalLoadBalancerName parameter to specify the ILB you created earlier.

You’ll need to run something like the following command for each machine you want to add to your load balanced set:

If you’ve followed the content of this post to this point the above command will fail. This is due to another wrinkle with the way ILB works currently. For some reason you can’t create an endpoint attached to an ILB unless there’s at least one external endpoint defined somewhere in your deployment. I haven’t yet narrowed down the specifics of this external endpoint requirement so for the time being I simply created a dummy external endpoint on a random high port then attached an ACL to that endpoint to block any traffic to it.

Having done that, I was able to add internal endpoints for each VM with no problems.

All that remained was to confirm the load balancer was working as expected.

Conclusion

A site-to-site VPN was already a compelling way to extend your on-premises infrastructure into Azure IaaS. This new internal load balancer functionality further eases the migration of on-premises workloads to the cloud.

I’m excited to try spinning up a load balanced Office Web Apps farm as well as a SharePoint farm with load balanced web front ends.

I’ll be sure to post my findings here.