Premium Storage and IOPS on Azure

Premium Storage was announced before Christmas and went GA in April 2015. If you haven’t looked at it, it’s a must if you are running workloads that have performance dependencies on disk I/O. It’s a little confusing on disk sizes like P10, P20 and P30 and how you should interpret what is written on the internet on official documentation and other blogs. However, seeing is believing, so I’ll start with showing you the difference.

If you want the executive summary of this blog post – Use Premium Storage for I/O intensive workloads. The DS14 VM with a single P30 premium storage disk achieves 30000 IOPS. You can go beyond that if you stripe multiple premium storage disks into a volume.

IOPS Performance depends on VM size

The IOPS performance on Premium Storage has to do with what VM size you pick and what disk size you have, so first we have to understand the D-series VM-sizes.

The D-series of VMs come in two groups of 4 VMs. Group one consists of D1-D2-D3-D4 and group two is D11-D12-D13-D14. Looking at the number of cores (blue bars), the first group has 1-2-4-8 cores in the VMs while the second group has 2-4-8-16 cores, ie for each step up in model, you double the cores. If you look at the RAM (orange bar), it is the same where the first group has RAM size of 3.5-7-14-28 GB and the second 14-28-56-112.

D-series_VM-sizes

Azure Documented Performance values for Premium Storage

The below diagram is from the Azure documentation (see references at bottom) and illustrates what number of IOPS is achievable per VM size DS1 through DS14. As you can see the bars resets after half, which is due to the dependancy between the number of CPU cores in the VM and the max IOPS you can get out of the VM type. The Disk Bandwith in MB/s (almost invisible in the diagram) have a linear relationship to the number of CPU cores. 1 core is 32 MB/s, 2 are 64, etc. The naming of the VMs are so that the difference between D1 and D2 is the same as the difference between a D11 and D12 – cores and RAM doubles when you step up. So if you really are going for IOPS, you should pick a VM with the most cores, which is D4 or D14. Not too suprisingly, the price follows the same pattern.

Max_IOPS_per_VMSize

In the documentation you also have IOPS specified per disk. This makes it a little confusing, because here you have a new max of 5000 IOPS. Think of it like this – this is what a single attached disk can do, given that the local hard drives on the computer sends all read/writes directly to it. The max and limits above are what a VMs of different sizes can do regardless of underlying storage subsystem and the values below is what the storage subsystem can do regardless of the VM it’s attached to.

Max_IOPS_per_DIskType

Disk sizes P10, P20 and P30 are implicit with regards to how large disk you create. If you attach a 500GB disk to your VM, it will be a P20 disk with the above limitations of a P20 disk. If you attach a disk of size 513GB, it will be a P30 disk. So, be carefull when selecting disk sizes. I choose 600 GB disks in my tests to get the P30 performance level.

You have a few VMs and Disk Types that isn’t the best match. Using 100GB (P10) disks with a DS14 is kind of scilly, because the DS14 has 512 MB/s as a max, while the P10 disk only serves you 100 MB/s. Guess where the bottleneck will be? On the other side of the stick, using a 600GB disk (P30)  on a DS2 VM means that although the DS2 can handle the IOPS (6400 > 5000), the MB/s will not handle it (64 < 200). The P30 disk will not be stressed out here.

The Tests and my Test Results

Reading the documentation made me think of the expression “you can only learn how to swim if you are in the water”, meaning you can read the documentation until you know it by heart but there is nothing that beats testing it yourself. So, that’s what I did.

I tested every VM (except the D1 which isn’t really the VM for I/O bound workloads) with a 600 GB Data Disk with ReadOnly cache. This means I used a P30 disk in order to be sure I had the most muscles available at the Azure Premium Storage layer. For the DS2 VM, I did test it twice to compare using a P20 disk and a P30 disk. The data disks where a simple volume using 64K as the Allocation Unit Size.

I used the IOMeter tool to measure IOPS and to have a documented way of measuring IOPS on the VMs, I followed this video on how to run the iometer tool – https://www.youtube.com/watch?v=XkOUGbsnGn0. ..

IOS_TestResults

The first observation you can make when looking at the diagram above is that it is clear why Microsoft created Premium Storage. It is Premium Storage that gets IOPS going, and if you are using standard storage, you’re stuck with IOPS that isn’t really that impressive. However, those who say that Azure is slow (and there have been a few pressreleases stating that the small Cloud Vendor X beats the big ones, including Azure) haven’t for sure used Premium Storage when they tested IOPS. Whithout going into multiple disks being striped and trying to gain more than what a disk gives you, etc etc, the DS14 VM gave us 30000 IOPS on a P30 disk. That is as close as you get on the SSD drive you have on your brand new laptop!

The second observation is that the diagram shows resemblance to the other diagrams in that you have two groups of four, but it’s not as clean as the others. So, there will be room for performance tweaking to see what is really the perf you need for your money. CPU cores is stronly correlated with IOPS, but it also has a linear correlation with price. Ie, IOPS will cost you money.

How do you go beyond 30000 IOPS?

I tested on a single volume on Windows using a single disk disk attached to Azure Premium Storage. Getting beyond this is a puzzle where you need a IT infrastructure pro who can stripe multiple disks into a volume based on the VM size you like, the storage size requirements you have and the IOPS you would like. It’s not a trivial business to do that, but it’s technically possible.

Summary

I have shown you what Premium Storage is and tested what you get with the tool iometer on every DS type VM there is. If you have a workload that is not performing the way you expected, my advice is:

  • Redeploy the VM to using P30 Premium Storage disks and retest it with a machine with as many cores as you can afford, preferably a DS14.
  • If you find that the performance problems went away, track you way backwards on the DS VM types and see where your price/performance axis cross

If you encounter any individual, organization or media that say Azure is slow, please ask them to retest using Premium Storage. Chances are they based their statement on something that ran on standard storage.

References

Azure documentation on Premium Storage
https://azure.microsoft.com/en-us/documentation/articles/storage-premium-storage-preview-portal/

Technet blog on SQL Server and Premium Storage
http://blogs.technet.com/b/dataplatforminsider/archive/2015/04/23/azure-premium-storage-provides-highest-performance-for-sql-server-in-azure-vm.aspx

Storage Spaces on Windows Server 2012
https://technet.microsoft.com/en-us/library/jj822938.aspx