Updating Azure VM Scale Set without downtime with Rolling Updates

Recently Azure started supporting updating a VM Scale Set properties and/or image in a rolling fashion. This way, instances are updated from time to time, automatically and after an application probe to ensure it’s done without causing application downtime during the update.

This article will explain how you configure your VM Scale Set (or just VMSS for brevity) and the peripheral components required for this to work.

Requirements

To be able to check the state of the virtual machine during a rolling update, we need a way to tell Azure if the application is up or not and this is done via a load balancer health probe. Pay attention that what is inspected is the application state via a LB health probe and not the VM state. This way we can be sure the update takes into consideration the application startup time, current state, issues caused by the update and so on.

Checking how your VMSS is now regarding the type of upgrade policy

To check the type of upgrade policy in place, you execute the following command:

az vmss show — name <vmss name> — resource-group <resource-group-name> — query upgradePolicy

The mode attribute will tell the type of upgrade which by default is Manual meaning that changes to the VMSS properties will require a manual upgrade of the instances. The picture bellow shows how this works and how results are displayed:

Checking VMSS upgrade policy

Trying to change the upgrade policy

If we try to change the upgrade mode, we get an error indicating that a health probe is mandatory for the upgrade mode to be set as Rolling as can be seen bellow.

Trying to change the upgrade policy

If you deployed a load balancer along with your VM Scale Set you probably already have a health probe pointing to port 80. If this is only a test you can use it as we are going to do here or if you are doing this for a real application, you should remove this probe which comes by default and create one pointing to your application.

To inspect the probe which comes by default with the load balancer attached to the VMSS at creation time, you can run the following command:

az network lb probe show --resource-group <resource-group-name> --lb-name <load-balancer-name> --name <health-probe-name>

If you created a new probe, use the names you gave, if you are using the default probe, the name will be tcpProbe.

Take note of the ID of the probe, which is the first ID shown (make sure you don’t copy the ID of the load balancing rule!).

Associating the probe to the VMSS

Execute the following command to associate the probe with the VMSS:

az vmss update --name <vmss-name> --resource-group <resource-group-name> --query virtualMachineProfile.networkProfile.healthProbe --set virtualMachineProfile.networkProfile.healthProbe.id='<id that you copied in the step before>'

Execute the following command to update the instances and add the health probe:

az vmss update-instances --name <vmss-name> --resource-group <resource-grou-name> --instance-ids *

After that, we can make a change and watch the rolling update in execution.

Changing a property and watching the rolling update

If we change a property from the VMSS we can watch the rolling update take place, for example, if we change the VMSS Image reference with a command similar to the following one:

az vmss update --name <vmss-name> --resource-group <resource-group-name> --set virtualMachineProfile.storageProfile.imageReference.id="<id of the new image>"

We will see the rolling update in place with part of the VMs being updated while the others are still running:

And the application will still be running and while the update is executing. The new version will come up depending on the instance that you reach:

This proves that we are updating the VMSS while the application is still running and no downtime is employed.