Azure Disk IOPS and Virtual Machines in IaaS


Hello Folks,

A couple weeks ago,  I delivered a talk about Microsoft Azure to a group of IT Pros in Halifax Nova Scotia. (I always enjoy going back there).  After the day was over I ended up having some sizing discussion with some of the attendees that stuck around for a bit. “How do we match the performance we have on premise?” one asked.  That simple question started the conversation.  Performance of a virtual machine is not just a function of CPU and cores.  “Rightsizing” your VMs can be very important is you want to get the performance your expecting.

This article will not look at the complete sizing exercise.   We’ll limit ourselves to IOPS (Input/Output Operations Per Second) a common performance measurement used to benchmark computer storage devices.

Before diving into this. I do recommend the following MVA modules as primer.

I can’t tell you how many IOPS your workloads will require.  Only the app vendor can do that or you can monitor any existing deployment of the workload you want to move to the cloud and configure your target virtual machine to match or exceed that requirement.

Azure virtual Machines come in three Type A, D and now recently announced, G.  Each of these have multiple sizes. (depicted in the tables below, except for the G machines. you can find the specs here.  but no info on the maximum data disks).

“A” Machine Basic Tier

image

“A” Machine Standard Tier

image

“D” Machine Basic Tier

SNAGHTML2afcdf1

On any of these machines the target IOPS is 500 per disk. For these test I created a VM based on a Standard_A4 (8 cores, 14 GB memory).  In the first test I attached 1 standard disk

image

image

and configured a Storage pool using that disk

From that machine I downloaded and installed SQLIO from http://www.microsoft.com/en-ca/download/details.aspx?id=20163.  SQLIO is a free tool provided by Microsoft which can also be used to determine the I/O capacity of a given configuration. So using this tool I tested the IO profile of the server with one standard drive.

To test, I used the following command:

SQLIO -kRW -s60 -o8 -b8 f:\testfile.dat

The -k option, which specifies the I/O type (R for read operations and W for write operations)

The -s option to specify the test duration in seconds.

The -o, which indicates the number of I/Os that can be outstanding in a single thread. In this case, I’ve specified 8, so each thread can support up to eight outstanding I/O requests.Next we come to the -b option. This is the I/O block size in kilobytes (KB). In the example, I specified 64.

The last option in the command is -F, which points to the configuration file and the parameters defined within it. When you run the command, it creates the test file on the target drive and returns details about the execution, as shown in the following results:

image

To contrast the test with a sigle disk. I created a new VM with the exact same specs, to witch I attached the maximum number of disks to it (4) and created a storage pool with all 4 drives as a stripe set.  After running the same IO test with SQLIO. I got the following results.

image

So,  as stated in Microsoft Azure documentation we did get approximately 500 IOPS on a single disk target and 1130 IOPS for a stripe set across 4 disks.

Premium Storage

At TechEd Europe Microsoft announces Azure Premium Storage.  This will be a new type of SSD-based storage, designed to support I/O intensive workloads. That means that you will be able to provision a persistent disk and configure the size and performance characteristics that will meet your requirements.

Just like we did today, you’ll be able to attach several persistent disks to a VM, stripe across them and deliver to your applications up to 32 TB of storage per VM with more than 50,000 IOPS per VM at less than one millisecond latency for read operations.

I can’t wait to test premium storage.  should be fun.

Cheers!

Signature

Pierre Roman
Twitter | Facebook | LinkedIn

Comments (2)

  1. Philip Elder says:

    Sorry, I didn't realize I was not signed in.

    Based on this post I surmise that we would need to do the following to enable more in-VM IOPS where we don't require a huge VM:

    1: Create a new VM that allows for the number of VHDs we estimate will allow the required IOPS needed
    2: Configure that VM, set up the storage, and get our LoB ready for deployment
    3: Once ready back the VM off to a lower status VM leaving the attached storage in place
    4: Pay for the extra storage not the high-end VM

    That should about do it. 🙂

    Philip

  2. Pierre Roman says:

    Hey Phil,

    when you say "back the VM off to a lower status VM". Do you mean changing the machine from a A4 to an A2 machine? if so, that may not work. As you can see in the tables I put in the articles each class of machines will support a pre-determined number of attached
    VHDs.

    so "backing the VM off to a lower status VM" will limit the number of disks attached and will break your stripe set.

    P.

Skip to main content