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.
- Windows Azure Storage – Design and Implementation Jump Start
- Get Started with Windows Azure Today Jump Start
- Windows Azure for IT Pros Jump Start
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
“A” Machine Standard Tier
“D” Machine Basic Tier
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
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:
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.
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.
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.