Converting Availability Set Virtual Machines to Azure Managed Disks

In this post, I will explain the benefits of using Azure Managed Disks with availability sets. I will also show how to convert virtual machines in an availability set with unmanaged disks to Managed Disks. These will respect the protection offered by the availability set.
 

 

Availability Sets

Azure uses availability sets for virtual machines in a few ways:

• Fault domains: Virtual machines in a common availability set are spread across fault domains. This means that if there is an unplanned localized outage, such as a top-of-rack (ToR) switch failure, the other virtual machines in the availability set are unaffected. A scenario might be, the service offered by a set of load-balanced web servers survives the outage because the remaining web servers pick up the load of the down machine.
• Update domains: Microsoft patches the Hyper-V hosts used by Azure several times per year. They use a rolling upgrade. Hosts have upgraded one update domain at a time. Virtual machines in a common availability set are spread out across multiple update domains. Imagine that you have two domain controllers. If Microsoft reboots a set of hosts because of host updates, then only one of your domain controllers will be offline. This is because of host reboots and the use of an availability set for the domain controllers.

Managed Disks

Availability sets sound like they give us ample protection but there was still a remaining single point of failure. The storage of the virtual machine disks was this point. It was possible for the virtual hard disks of virtual machines to be placed into a single Azure storage cluster. This cluster provides triple-redundancy of storage (LRS) to protect you against disk or JBOD (a tray of just-a-bunch-of-disks) failure and/or maintenance. It does not protect you against a certain outage profile. For example, a virtual machine availability set protects you against a localized outage within a fault domain. A similar style of outage in the Azure storage cluster could bring down all 3 copies of your virtual machines’ disks.
Managed Disks for virtual machines offer many benefits. This is quickly summarized as, “Azure just takes care of all the disk placement for you.” One of those benefits is that if you use Managed Disks with virtual machines in an availability set, then Azure will disperse the disks of the machines across different storage clusters within the data center. If one of the storage clusters fails, then the other copies of your disks remain online. Your service also remains online.

Converting Availability Sets to Managed Disks

It is possible to convert an availability set of virtual machines from unmanaged disks to Azure Managed Disks. The process understands that you require the service in the availability set to remain online throughout the upgrade process. The upgrade is done one virtual machine at a time. I have added a sleep command after each upgrade. This will occur before the next upgrade starts to add a buffer. Alternatively, you can request manual confirmation that the process should continue after each virtual machine upgrades. This would allow you to check that the last virtual machine is OK before allowing the upgrade to take place for the next machine in the availability set.
The conversion process is done using PowerShell. Note that you should have the latest version of the PowerShell modules. At the time of writing (February 2017), you also need to have the very latest ARM Compute module but this will probably be folded into later bundled installations:

Install-Module AzureRM.Compute -RequiredVersion 2.6.0 -AllowClobber

The PowerShell script for doping the conversion of virtual machines in an availability set is shared below:

CLS
$ResourceGroupName = "rg-petri"
$AVSetName = "as-petri"
$SubscriptionID = "1a2b3c45-aa12-1a23-12a3-a1bcdefg345h"
$Delay = 60
Login-AzureRmAccount
Select-AzureRmSubscription -SubscriptionId $SubscriptionID
Write-Host "`nRetrieving the availability set, $AVSetName"
$AVSet =  Get-AzureRmAvailabilitySet -ResourceGroupName $ResourceGroupName -Name $avSetName
Update-AzureRmAvailabilitySet -AvailabilitySet $AVSet -Managed
foreach($VMInstance in $ AVSet.VirtualMachinesReferences)
    {
    $VM =  Get-AzureRmVM -ResourceGroupName $ResourceGroupName | Where-Object {$_.Id -eq $VMInstance.id}
    $VMName = $VM.Name
    Write-Host "`nWorking on the virtual machine, $VMName"
    Stop-AzureRmVM -ResourceGroupName $ResourceGroupName -Name  $VMName -Force
    Write-Host "`nConverting the disks of virtual machine, $VMName, and then starting it"
    ConvertTo-AzureRmVMManagedDisk -ResourceGroupName $ResourceGroupName -VMName $VMName
    Write-Host "`nSleeping for $Delay seconds before proceeding"
    Sleep $Delay
    #You can replace the previous two lines with the following to allow for a manual verification before proceeding
    #Read-Host "Press Enter/Return to continue to the next virtual machine"
    }

 
A few variables define the environment that will be upgraded:

• ResourceGroupName: The name of the resource group that contains the availability set and virtual machines
• AVSetName: The name of the availability set
• SubscriptionID: The GUID of the subscription that contains the resources
• Delay: How many seconds you want the script to wait between upgrading virtual machines

The first part of the script will request you to log into your Azure administrator account and then it will select the subscription that you defined in the SubscriptionID variable.
The AVSetName variable is used to retrieve the availability set resource and then the availability set is upgraded to a managed state. This supports the concept of Managed Disks. It instructs Azure to spread Managed Disks in the availability set across different storage clusters.
A for loop will then run and perform an upgrade on each virtual machine in the availability set. This will happen one at a time:

1. The virtual machine is shut down to enable the upgrade.
2. An upgrade command is run to convert the disks of the machine to Managed Disks. The process will automatically start up the virtual machine.
3. A delay command pauses the script for the number of seconds stored in the Delay variable.

Note that I added a line, commented out using #, that you can use instead of the Sleep cmdlet. Doing this would replace the timed delay with a manual control, which stops the script from running until you press enter. You can use this approach if you want to manually check a converted virtual machine before continuing.