Taking the guesswork out of Azure VM size selection

By David Summers, Consultant, Data^#3

[Reading time: 6 mins]

One of the questions I receive frequently in the Azure space is “How do I pick the size of my Virtual Machines (VM’s)?”

Well –  this is not a simple question to answer. The challenge is that there is no one size fits all size for an Azure VM role. It all depends on a large collection of factors. As with all things in Azure, I always work from the limits and then step up to what is possible.

Let’s look at what VM role sizes we have at the moment.

The following PowerShell code will list out all the available Azure VM Role Sizes.

Get-AzureRoleSize | Select InstanceSize, Cores, @{Name=‘MemoryInGb’;Expression={[MATH]::Ceiling(($_.MemoryinMb /1024))}}, MaxDataDiskCount | Sort Cores,MemoryInGb,MaxDataDiskCount

For reference, what we can see above is the total number of Role Sizes available. Therefore, at this stage we have a 1 out of 71 choice ratio.

Get-AzureRoleSize | Select InstanceSize, Cores, @{Name=‘MemoryInGb’;Expression={[MATH]::Ceiling(($_.MemoryinMb /1024))}}, MaxDataDiskCount | Where {$Locations -contains $_.InstanceSize} | Sort Cores,MemoryInGb,MaxDataDiskCount

As you can see above, we have a nice selection of various sizes with a fairly flexible compute allocations.

Let’s step through the first limit – Region Availability.

How many of these VMs are available within my Region? As you may know, not all services are available in all regions at the same time, Microsoft’s release cadence dictates that new services are rolled out gradually across the globe. First, we filter this list to show us what is available.

The per region VMRoleSizing is unfortunately not stored in the Get-AzureRoleSize commandlet, so we need to query the Azure Location and then compare the results.

This will return the 2 Australian Regions and define a new variable containing a unique list of potential Role Sizes (67) in this example.

PowerShell: $Locations = (Get-AzureLocation | Where {$_.Name -like “Australia*”}).VirtualMachineRoleSizes | Sort -Unique

Now we can do a comparison by checking if the AzureRoleSize.InstanceSize is contained within the $Locations variable.

(Get-AzureRoleSize | Select InstanceSize, Cores, @{Name=‘MemoryInGb’;Expression={[MATH]::Ceiling(($_.MemoryinMb /1024))}}, MaxDataDiskCount | Sort Cores,MemoryInGb,MaxDataDiskCount | Measure).Count

Just for reference, the 4 Role Sizes that were not available in Australia were:

Second Limit – Storage Capacity.

Now this is an interesting one (until VHDX support is added) we then filter on the Max total disk allocation for our VM types. Since we are currently limited to 1TB total capacity per virtual disk, we need to look at the storage requirements for the VM to be provisioned. If we need to allocate a 3TB spanned volume to a VM, then we need to filter out VMs that have less than 4 Data disks. We get more restrictive with each step up of required capacity.

Get-AzureRoleSize | where {$_.MaxDataDiskCount -ge 4} | Select InstanceSize, Cores, @{Name=‘MemoryInGb’;Expression={[MATH]::Ceiling(($_.MemoryinMb /1024))}}, MaxDataDiskCount | Where {$Locations -contains $_.InstanceSize} | Sort Cores,MemoryInGb,MaxDataDiskCount

We are now down to 57 Options. Getting easier…

Third Limit – Licensing.

 I put this before compute requirements as it has a dramatic impact on our remaining VM choices. For example, if we are going to use Software Assurance with License Mobility licencing for SQL Enterprise and we have only purchased a single 4 Core pack, then we cannot go for more than 4 CPUs or we will be in breach of our licensing.

Get-AzureRoleSize | where {$_.MaxDataDiskCount -ge 4} | Where {$_.Cores -le 4} | Select InstanceSize, Cores, @{Name=‘MemoryInGb’;Expression={[MATH]::Ceiling(($_.MemoryinMb /1024))}}, MaxDataDiskCount | Where {$Locations -contains $_.InstanceSize} | Sort Cores,MemoryInGb,MaxDataDiskCount

Fourth Limit – High performance IOPS requirement.

If I need to allow for greater than 500 IOPS per virtual disk then I need to look into using Premium Storage, this fast storage is not available for all VM types. For the most part, there is an S series VM equivalent for most of the normal VM types, but not all of them. If I need premium storage, then I filter on DS series VMs. NOTE: My personal recommendation is that if you do not need Premium Storage now, but may need it later then use a DS series straight off the bat. You will thank me later as that will save having to redeploy your VM to a DS series, plus there is no price difference between a D and a DS series (as long as the OS disk is deployed on Standard Storage).

Now this one is a bit tricky to filter on, as the Get-AzureVMImage is easier for returning premium Storage support, however since we know that VMRoleSizes with an *s* suffix have premium disk support, we can just perform a lookup for the existence of an S after the underscore split of the InstanceSize name.

PowerShell: Get-AzureRoleSize | where {$_.MaxDataDiskCount -ge 4} | Where {$_.Cores -le 4} | where {($_.InstanceSize.Split(“_”)[1] -like “*s*”)} | Select InstanceSize, Cores, @{Name=‘MemoryInGb’;Expression={[MATH]::Ceiling(($_.MemoryinMb /1024))}}, MaxDataDiskCount | Where {$Locations -contains $_.InstanceSize} | Sort Cores,MemoryInGb,MaxDataDiskCount

(Not bad for a PowerShell one liner!)

We are now down to 12 Options that satisfy the minimum requirements for the new VM.

Finally, we look at the performance requirements (Compute).

At this stage, our list is fairly short and our last decision point is how much memory and CPU does the VM need. Of course the CPU decision may have already been locked by the licensing step.

Putting this all together, let’s say that I have the following requirements for a VM:

• Region = Australia EastSouth East
• Disk Capacity = 2×1 TB volume and 1×2 TB volume
• Licensing = Windows Server and SQL Enterprise (8 Core with SA+LM)
• IOPS  = 10,000 per 1 TB Volume and 20,000 for the 2 TB volume
• CPU = Minimum 2 Cores
• RAM = Minimum 8 GB

Our destination VM size = Standard_DS3_v2

Why? Using the above guidelines for filtering, we ended with this potential list of applicable role sizes.

We had to pick a DS series for the Premium Storage requirement. We could not use any of the Role Sizes above the F4S due to the disk requirements. We had to provide 4 Disks in total to reach the required capacity 2x1TB virtual Disks and 2x1TB virtual Disks configured as a simple storage space to provide 2TB of total capacity.

However, due to the IOPS requirements we had to double the virtual disk allocation. Premium disk provides 5,000 IOPS per virtual disk. To reach the IOPS requirements we had to provision 2x2x1TB virtual Disks configured as 2 simple storage spaces 4x1TB Virtual disks configured as a Simple Storage Space.

Since it is relatively easy to scale a VM up or down (as long as it is in the same generation type, i.e. DS1 to DS2 is very straight forward. DS1 to GS1 requires a lot more effort), we picked the lowest cost VM (the F Series was not selected, as that is more suited to Batch processingWeb Servers and Game Hosting).

In conclusion, know the limits before you pick the VM size.

It also helps to know what’s in the pipeline for Azure services and constantly keep up to date with new features as they are released. Ironically this Blog is likely to be outdated as soon as it is published, since Microsoft are rapidly accelerating development of new and existing Azure Services.

Remember that Data^#3 is here to help if you need someone to take the guess work out of the equation.

Happy Clouding!

Hot Tips

For SQL servers, there is nearly no difference between 1-2-4 Cores running cost if you are using the consumption (PAYG) licensing so it makes sense to always go for 4 Cores to start with. The price does jump dramatically when stepping from 4 to 8 cores though.

Where possible always pick a D series over an A series. The A’s are Gen-1 machines and are based on AMD chipsets. The D’s are Intel based and operate on average 30% faster. Also if possible go for a Dv2, as they are faster again (for the same price of a D series).