How to Setup availability sets on Windows Azure together with a load-balanced set of endpoints

Availability Sets on Windows Azure

If you wonder why we care about availability sets you better read here

One VM == availability not guaranteed

We will need to setup availability sets and redundant Virtual Machines (VMs) and services for apparent reasons. We are going to implement an Availability set where problems on the datacenter where you host your application or scheduled maintenance tasks may not bring down your precious service.

According to Microsoft and by reading closely their Windows Azure SLA (until today) we see that Microsoft ensures a 99.95% availability if and only if you have availability sets deployed.

The way to setup availability sets and whatever is contained in them, depends heavily on the nature of your application.

How to create VMs in Availability Sets

Microsoft provides an excellent guide for the process. To my opinion it is straight forward but we need to pay attention to the following:

a) If you only have one VM you will see a nice message from Microsoft when you check your dashboard saying that the SLA cannot be guaranteed without at least another one VM.

b) In order to create a VM that belongs to an Availability Set we can only create it by selecting the “From Gallery” option!

c) You can:

  • Create the first virtual machine and the availability set at the same time. Then add VMs to the availability set. The additional VMs may have to be rebooted!
  • Create virtual machines, create an availability set and then add all of the machines to the set. They may all have to be rebooted!

d) As it seems, availability sets are bounded to a specific cloud service. Thus you cannot have an availability set shared among different cloud services.

REFERENCE: The process of setting up the VMs and availability sets is described in here.

By the end of the above process we should have (at least) 2 VMs belonging to the same availability set.

NOTE: If you quickly check your VMs on the Azure Dashboard you’ll notice that the DNS NAME and the Public Virtual IP (VIP) of the two VMs are the same. On the contrary they have different SSH Details. More specifically the second VM can be accessed through SSH using the same public DNS name but by using a different port.

Alternatively you can log on the VM accessed through the public IP on port 22 and then use the internal IP to access again the second VM again on port 22, although I don’t see why would anyone want to do it that way :D.

This is a side-effect of having multiple VMs on the same Cloud Service, which is of course a requirement if we want to use availability sets.

How to setup a load-balanced set of endpoints

Initially and due to the same Public Virtual IP (VIP) I had the impression that if I shut down one of the VMs and try to connect on the VIP, I would be automatically redirected to the one running. As it seems this is not the case.

In order to route traffic between the two VMs of the same availability set we’ll also have to setup a load-balanced set of endpoints, you can find all the gory details of how to do it here.

The process in a nutshell is:

  1. Select the first VM
  2. create endpoints (e.g. port 80 for http)
  3. assign them on a load balancing set
  4. Add the other VMs

Keep in mind though that there are some restrictions on which ports/services you can load balance, for example port 22 cannot be assigned to a load balancing set so my dreams for always being able to SSH on something…. are ruined :(. Nevertheless, you can have your favourite web server running on the ports you have selected to be load-balanced on both your VMs and the Azure platform guarantees that your traffic will end up on one or the other depending on which one is currently running, but one of them will always be there accepting requests from your beloved clients.

Now you might want to continue to the next steps on:


[1] Windows Azure SLA

[2] Azure Guide: Manage the availability of Virtual Machines

[3] Azure Guide: Load Balancing Virtual Machines