Custom Probe for IaaS Load Balanced sets in Windows Azure and ACL – Part 1

In Windows Azure, if a group of IaaS VM’s need load balancing, for example when hosting a Web Farm, this can be done by putting them in a Load Balanced set. Further, the health of individual VM’s in the load balanced set can be monitored using a Custom probe to decide if any of these need to be removed or added back to the farm. The interesting thing about the custom probes is that they enable the ability to monitor something meaningful and very application specific rather than simply accepting a VM to be healthy if it is alive. A VM could very well be alive and yet not be doing what the application needs it to. Finally, the public endpoint exposed by the Load Balanced set (LB set) may be protected by ACL’s (Access Control List) to allow traffic only from designated IP Address ranges, if so desired.

Both features – the Custom probes and the ACL’s – have been around for some time and are well documented officially as well as in blogs. My personal favorites are the blogs by Michael Washam at Creating Highly Available Workloads with Windows Azure and Network Access Control List Capability in Windows Azure Powershell. Despite this, I have found myself answering questions on the mechanics of using these features. The purpose of the present note is to have a fresh take at Custom probes and ACL’s using a walkthrough of a scenario, and revisit some of the questions that I have come across.

Assorted facts

Before showing a walkthrough, an assortment of questions that usually come up in discussions, are addressed in this section.

LB sets and Custom probes

  • What exactly is the purpose of the Custom probes in LB sets? IaaS VM’s in a Cloud Service can in fact be added to a Load Balanced set with or without a custom probe. The Load Balanced endpoint however needs to know which VM’s within the set are active. This information is provided by an agent that runs on the host node which monitors the VM’s located there; see Figure 1. If there is no custom probe, the best that the agent can do is check if the VM’s are alive. With custom probes, the application developer gets a chance to implement some custom logic within the VM’s to respond to health check.

Figure 1: VM’s in an LB set with Custom probes for health check

  • Custom probes are completely independent of the type of O/S (Windows or Linux) running within the VM.
  • There are two types of probe protocols: TCP, and HTTP, though the HTTP is the more popular.
  • The port designated for probe can be any port. It does not have to be port 80 for HTTP Probe-protocol. In fact, I prefer a port other than port 80 to keep things separate – the main website on port 80 and the custom probe on some other port. However, the Azure portal displays a “Port mismatch” warning if, while configuring the LB set, the probe port is chosen to be different from the port on the endpoint. The warning can be ignored.
  • The custom logic can be implemented in any process listening on the designated Probe-port. It does not have to be IIS, although IIS is very convenient.
  • Load Balanced sets with custom probes can be created in Azure portal through UI or alternatively using Powershell: Set-AzureLoadBalancedEndpoint. Also, see the blog post referenced above.
  • The Load Balanced set discussed here is for VM’s in a single Cloud Service in a single datacenter. If HA/DR capability across datacenter is needed, consider Windows Azure Traffic Manager.

ACLs for Endpoints

  • ACLs work only for Public endpoints, not for private IP addresses in Azure.
  • The endpoint could be for a stand-alone Cloud Service or for one located in a VNet (Virtual Network).
  • For now, ACL work only for IaaS VM’s but in future PaaS endpoints will be supported also.
  • ACLs can be applied to a regular public endpoint, or to a load-balanced endpoint (LB set). The blog post referenced above discusses the syntax for both cases, if using Powershell.
  • ACLs can also be applied through the Azure portal UI.
  • The Remote-subnet specified in the definition of ACL must also be a publicly visible address space. It cannot be a private IP Address range.
  • The Remote-subnet is only a notation meant to allow the specification of a range of addresses. But one can always specify a single remote IP Addresses also, using the /32 in CIDR notation; for example: 175.1.0.1/32 means just the IP address 175.1.0.1.
  • ACLs are independent of the guest O/S in the VM’s (Windows or Linux).
  • When using Powershell, one can create a template – the AclConfig – using New-AzureAclConfig and Set-AzureAclConfig. This is a very useful feature as the template can then be reused many times. The AclConfig can also be retrieved from an existing endpoint on a VM using the Get-AzureAclConfig and then reused.
  • Multiple Rules can be added to the same ACL (i.e. AclConfig). The Rules within a single ACL (AclConfig) constitute an ordered list, where higher-order (or lower in the portal based list) take precedence.