Introduction to Azure VM Managed Disks

In this post, I will explain the new mechanism that Microsoft has just introduced for providing virtual machine storage in Azure, called Managed Disks.
 

 

The Old Solution

The legacy method for deploying virtual machines in Azure went as follows:

1. Create a storage account: Similar to a LUN in usage, this is a way to carve out a slice of storage from Azure, and it allows you to place blobs into it. A virtual machine’s virtual hard disk (of the VHD format) is stored here as a blob, and is used as a disk (under the Disk billing rate).
2. Create a virtual machine: A virtual machine is deployed. The OS disk is placed into a storage account.
3. Add data disks: Data disks are the best place to store data (performance, support, and management) in Azure virtual machines. These data disks are also kept in a storage account.

This means that there is a two-step process for creating a new virtual hard disk. Using storage accounts also brings in an element of planning.
Each standard (HDD-based) virtual hard disk has a supposed (I’ve seen it burst well beyond this) rate limit of 500 IOPS. A single storage account has a rate limit of 20,000 IOPS. This means that a single storage account is capable of supporting 40 standard virtual hard disks at full throttle. If you need to scale out, then you need more than 1 storage account.
Each storage account requires a globally unique name; this is because the name is used to create a globally unique DNS name, by which you can connect to the storage account using a secret access key. More storage accounts require more unique names. I’ve introduced a random element to naming my storage accounts, but this would go against the naming standards of many organizations.
Those who are creating their own images also faced issues (in Azure Resource Manager or ARM). A virtual hard disk image can only be deployed inside the same storage account; this means that if you need lots of virtual machines, you have to copy and manage the single image disk across each storage account.
What if we could dispense with storage accounts for the placement of virtual hard disks (we still need some for keeping virtual machines diagnostics data)? What if we could say “I want some disks, just store them somewhere safe for me”? This is exactly what Microsoft has given us with Managed Disks.

Managed Disks

With Managed Disks, Microsoft is handling the storage on your behalf; you don’t need to create storage accounts for virtual machine disks anymore. You can deploy either standard (HDD) or premium (SSD) Managed Disks, with LRS fault tolerance (3 copies in a single datacenter) – there is no GRS option, but we’ll get geo-fault tolerance from Azure Site Recovery at a later point (discussed at Ignite 2016). Reduced management is a huge benefit by itself, but there are more.

Increased Reliability

Ideally, we should place our virtual machines into availability sets. This provides us with service uptime, an SLA from Microsoft, and enables the usage of the load balancer. Virtual machines that are in an availability set will have their Managed Disks placed into different parts of Azure storage (storage scale units or stamps) to provide similar levels of resilience. If one of the storage scale units fails, only the virtual machines with disks in that stamp will fail, ensuring that the rest of the service in the availability set continues to run.

More Security

Managed disks are true managed resources in the resource group, just like NICs and virtual machines. You can use role-based access control (RBAC) to limit who can do what with your Managed Disks.

Easier Scaling Out

You don’t have to worry about the 20,000 IOPS limit of a storage account anymore; just deploy more virtual machines with Managed Disks, and Azure handles the placement of your disks.
If you are creating your own generalized images, then you don’t have to copy them to multiple storage accounts anymore – you simply store the image (a virtual hard disk) in a single storage account (as a blob) in each required region.
You can have up to 10,000 Managed Disks in a single Azure subscription – it’s 2,000 by default but you can have it increased by calling Microsoft Support. If you are into on-demand scaling, then virtual machine scale sets (VMSS) can handle up to 1,000 virtual machines with Managed Disks.

Snapshots

Here we go with a term that I dislike greatly and was glad to see the back of in Hyper-V: snapshots. You can create snapshots of Managed Disks (I didn’t say a “of virtual machines” here). A snapshot is a full copy of a disk as the disk was when the snapshot was taken. Support for incremental snapshots (as in Hyper-V) will come at a later time.
Right now, snapshots are very simple. There isn’t a coordinated snapshot process. Snapshots are done on a disk by disk basis. If a virtual machine has a single Managed Disk, then creating a snapshot is simple and reliable. If a virtual machine has multiple disks, then taking a snapshot will be a disk-by-disk operation that will lead to consistency issues. Note that doing this more complex snapshot is not currently supported – my guess is that we are seeing typical cloud development here; a basic function has been released and it will be improved over time if there is demand for improvement.
A cool trick with a snapshot is to create another Managed Disk from it, and then use that disk as the basis of another virtual machine — an identical copy, so not a good way to scale out, but great for troubleshooting or copying a lab.

Azure Backup

Microsoft launched Managed Disks with support from Azure Backup, which was critical for production usage of the new storage option. Note that Azure Disk Encryption (ADE) is not currently supported by Azure Backup.

Pricing

I’m not going to post the current prices here – this stuff is always changing and is region/currency dependent. What I will say is that:

• You pay for the size of the disk, not the amount of data contained, which is a change from standard disks in storage accounts.
• The pricing is based on brackets. For example, if you deploy a 100GB data disk, it is charged for based on the S10 (128GB) price.
• A snapshot is a full disk copy and is charged for as such.
• Managed Disks look like they will be more affordable than disks in storage accounts.
• Microsoft has launched a special promotion price for the first six months.

Converting Disks

There is a fairly simple process for converting from a machine with storage account-based disks to Managed Disks; it does require you to power down the virtual machine, but the conversion is pretty quick.

One of the nice perks of Managed Disks is the ability to easily convert from standard (HDD) to premium (SSD) managed disks. Some of my customers deploy “S” virtual machines (capable of premium storage) with standard disks just in case they need the performance boost of SSD at a later time. Making that change will be much easier with Managed Disks.

The 1023GB Limit

You Azure veterans are dying to know what’s happened to the 1023GB limit of virtual hard disks. I’m sorry; nothing has changed here. If you need a data volume that is larger than 1023GB, then you need to span virtual hard disks (which does incrementally improve performance of the volume).

Do we Still Need Storage Accounts?

Yes, we do. If you want to enable diagnostics, then the data is stored in a storage account (Microsoft says this will migrate to Managed Disks at a later time). You might use Storage Accounts to store generalized images, scripts, and other items, too.