As organizations migrate their on-premises systems and applications to Microsoft Azure’s Infrastructure-as-a-Service, eliminating single points of failure and providing fault tolerance and resiliency for cloud-hosted infrastructure is just as important as it is on-premises. In the datacenter, often this is provided with the use of hardware load balancers to distribute traffic to multiple redundant systems. This is necessary to reduce or eliminate system downtime or service disruption in the event of a failure (application or hardware) and to increase uptime during planned outages for maintenance or upgrades. Moving infrastructure to the cloud presents a unique challenge in that respect.
Today, Microsoft Azure provides network load balancing for public endpoints. That is, systems hosted in Azure that are publicly accessible. However, there is an important need to provide load balancing services for systems that are not public facing. Examples of this would include non-Internet accessible systems that are accessed only from the on-premises network via site-to-site VPN or from other virtual machines hosted in Azure. Also, network load balancing is often required for middle-tier or back end systems in multi-tiered architectures.
To meet these needs, Microsoft recently announced the public preview of Azure Internal Load Balancing. It is now possible to create a network load balancer that includes endpoints that are not public facing. In this month’s article I’ll demonstrate how to configure an Azure Internal Load Balancer for two Azure virtual machines that are configured as web servers. I’ll create an Azure Internal Load Balancer to provide high availability for this web service for private, internal access only. The load balanced cluster will not be publicly available. I will also demonstrate how to view Azure Internal Load Balancer configuration and how to remove an Internal Load Balancer as well.
As of this writing, Azure Internal Load Balancing can only be configured using PowerShell. If you’re not yet up to speed with PowerShell in Azure, be sure to read Introduction to PowerShell with Windows Azure before proceeding.
To take advantage of Azure Internal Load Balancing, all endpoints must be Standard VMs. Basic VMs are not supported and must be converted to Standard in order to leverage this new service. Azure Internal Load Balancers can be configured using an IP address assigned dynamically from the virtual network, or they can be configured using a static address. The latter is probably preferred, so I’ve included that in my examples below. Please note that existing public load balanced endpoints cannot be converted to use the Azure Internal Load Balancer. In addition, it is possible to use Azure Internal Load Balancer for Azure Platform-as-a-Service (PaaS). However, Azure Internal Load Balancer configuration for PaaS is outside the scope of this article.
Create an Internal Load Balancer
Once you’ve identified the Azure virtual machines you’d like to configure to use internal load balancing, open an elevated PowerShell window and add your Azure account. Next, create an Azure internal load balancer by executing the following PowerShell commands:
Add-AzureInternalLoadBalancer -ServiceName <service_name> -InternalLoadBalancerName <name> -SubnetName <subnet_name> -StaticVNetIPAddress <ip_address>
Once the Azure Internal Load Balancer has been created, you can review the configuration of the internal load balancer by executing the following PowerShell commands:
Get-AzureInternalLoadBalancer -ServiceName <service_name>
Assign Endpoints to the Internal Load Balancer
Once the Azure Internal Load Balancer has been successfully created, it will be necessary to assign virtual machine endpoints to the load balancer. To assign endpoints to the Azure internal load balancer execute the following PowerShell commands. Repeat these commands for each virtual machine in the load balanced set.
Get-AzureVM -ServiceName <service_name> -Name <vm_name> | Add-AzureEndpoint -Name <endpoint_name> -Protocol <protocol> -LocalPort <local_port> -PublicPort <public_port> -DefaultProbe -InternalLoadBalancerName <name> -LBSetName <name> | Update-AzureVM
Once complete you can update internal DNS to point the application’s fully qualified domain name (FQDN) to resolve to the virtual IP address assigned to the Azure internal load balancer. The application should now be functioning as a load balanced resource.
Remove an Azure Internal Load Balancer
To remove an Azure internal load balancer, it is first necessary to remove the load balanced endpoints from each virtual machine in the cluster. To do this, execute the follow PowerShell commands for each virtual machine in the load balanced set.
Get-AzureVM -ServiceName <service_name> -Name <vm_name> | Remove-AzureEndpoint -Name <endpoint_name> | Update-AzureVM
Once the endpoints have been removed from all virtual machines in the set, execute the following PowerShell command to remove the Azure internal load balancer itself.
Remove-AzureInternalLoadBalancer -ServiceName RH-AzureLab
Microsoft Azure continues to add features and functionality on an almost daily basis it seems. Although network load balancing has been available for public facing endpoints, it wasn’t until just recently that Microsoft introduced support for creating load balancers for internal, non-public facing services. This is a vital component that can be leveraged to eliminate single points of failure in cloud-hosted infrastructure to improve availability and reduce system downtime for both planned and unplanned outages. Today the configuration of Azure Internal Load Balancers is performed exclusively using PowerShell. In the future that is likely to change and will probably be integrated in to the Azure GUI management console at some point. For now, if you have a requirement to provide load balancing for services that are accessible only from within Azure, or from the on-premises network via site-to-site VPN, the Azure Internal Load Balancer will definitely meet your needs. And, as always, watch for continuing improvements in this feature as it is sure to be further enhanced moving forward.