This article is part of a series of 9 where I am talking about storage benchmarks performed on Microsoft Azure and on-premises. For a better understanding please make sure you read also the other parts:
- Describe what does the Iometer benchmarks will consist of.
- Describe how I configured the Azure VM and the benchmark results for the A3 Standard VM using a single disk hosted by Standard Locally Redundant Storage (LRS).
- Describe how I configured the Azure VM and the benchmark results for the A3 Standard VM using multiple (eight) disks in a RAID-0 (striped) configuration hosted by Standard Locally Redundant Storage.
- Describe how I configured the Azure VM and the benchmark results for the DS3 Standard VM using a single Premium P10 disk hosted by Premium Locally Redundant Storage (LRS).
- Describe how I configured the Azure VM and the benchmark results for the DS3 Standard VM using a single Premium P30 disk hosted by Premium Locally Redundant Storage (LRS).
- Describe how I configured the Azure VM and the benchmark results for the DS3 Standard VM using multiple (two) disks in a RAID-0 (striped) configuration hosted by Premium P30 Locally Redundant Storage.
- Describe how I configured the Azure VM and the benchmark results for the DS3 Standard VM using multiple (eight) disks in a RAID-0 (striped) configuration hosted by Standard Locally Redundant Storage.
- Describe how I configured the Hyper-V on-premises VM and the benchmark results using local HDD and SSD.
- IOPS benchmark detailed conclusions (on-premises and Azure IaaS).
A3 Standard VM using Standard Locally Redundant Storage (LRS) – setup and benchmark results
An important aspect of Azure is that the IOPS and the throughput are limited by the VM series and size. The MS Azure Standard Tier A series A3\large VM is limited to maximum 8 disks with maximum 500 IOPS per disk. Another very important aspect is each standard storage account is limited at 20,000 IOPS. Standard Locally Redundant Storage is the cheapest Azure storage account type. For this type of VM and storage, the default setting of the virtual disk host caching is set to None.
The following PowerShell commands have been used to provision an A3 Standard VM with a single disk hosted by Standard Locally Redundant Storage (benchmark setup).
Add-AzureAccount $subscriptionName = '<YOUR SUBSCRIPTION NAME>' $VMOSStorageAccountName = 'aziowosdisks' $IOStressStorageAccountName = 'aziostressdisks' $location = 'West Europe' $adminName = '<YOUR ADMIN USER NAME>' $adminPassword = '<YOUR PASSWORD>' $vmName ='AZIOA3' $imageFamily = 'Windows Server 2012 R2 Datacenter' $vmSize ='Large' Select-AzureSubscription -SubscriptionName $subscriptionName -Current New-AzureStorageAccount -StorageAccountName $VMOSStorageAccountName -Location $location -Type 'Standard_LRS' New-AzureStorageAccount -StorageAccountName $IOStressStorageAccountName -Location $location -Type 'Standard_LRS' $imageName = Get-AzureVMImage | where { $_.ImageFamily -eq $imageFamily } | sort PublishedDate -Descending | select -ExpandProperty ImageName -First 1 Set-AzureSubscription -SubscriptionName $subscriptionName -CurrentStorageAccount $VMOSStorageAccountName $OSDiskPath = "https://" + $VMOSStorageAccountName + ".blob.core.windows.net/vhds/" + $vmName + "_OS.vhd" $vm = New-AzureVMConfig -Name $vmName -ImageName $imageName -InstanceSize $vmSize -MediaLocation $OSDiskPath Add-AzureProvisioningConfig -Windows -VM $vm -AdminUsername $adminName -Password $adminPassword New-AzureVM -ServiceName $vmName -VMs $VM -Location $location Set-AzureSubscription -SubscriptionName $subscriptionName -CurrentStorageAccount $IOStressStorageAccountName #This will attach a new data disk configured to use the default host caching (None) for Standard_LRS Get-AzureVM $vmName -Name $vmName | Add-AzureDataDisk -CreateNew -DiskSizeInGB 10 -DiskLabel "main" -LUN 0 | Update-AzureVM
The above PowerShell commands created two Standard Locally Redundant Storage accounts:
- aziowosdisks – used to host the OS disk of the VM.
- aziostressdisks – used to host the additional disk mapped to the VM.
The IOPS benchmarks are performed on the additional mapped disk. The aziostressdisks storage account will only host the additional virtual disk (F:\ volume) – so in this way the benchmark tests are not influenced by other workloads.
Benchmark results (A3 Standard VM, F: volume on single disk, hosted by Azure Standard Locally Redundant Storage)
The Iometer results can be downloaded from here.
In the above chart you can see the registered throughput. Very important to be noticed is the fact the 500 IOPS limit per disk doesn’t allow to reach speeds higher than 4.07 MBps (at 32.18 ms average latency). If we take in consideration the 20 ms recommended latency, we can see in some cases the throughput is not that close to the maximum registered value, which indicates clearly the limits are mainly coming from the physical storage (not caused by the QOS limits applied by Azure).
The above chart indicates the IOPS and average latency distribution across different workloads (# of Outstanding I/Os). If we take in consideration the 20 ms recommended latency, we can say whatever is higher than 8 outstanding I/Os (very light workloads) will result in application performance degradation. As can be seen the average latency is growing (up to 2.07 seconds) and gets outside the chart limits.
Combined with the results from the previous chart we can conclude an application who is using this type of storage setup will provide optimal performance if:
- does have a very light storage load (up to 8 outstanding I/Os);
- the expected throughput is between 3.40 – 4.07 MBps;
For this storage setup (a single disk hosted by Azure Standard LRS):
- I recommend it for hosting:
- file shares -> archives (where backups, data changes and data access are rarely performed);
- TEXT and LOG application files (where is necessary to have a cheap tracing in-place);
- web servers -> web site files for systems with low usage;
- user database data files (MDF) only for systems with very low storage usage (read-only databases, archives, legacy data);
- I definitely not recommend it for hosting:
- database Transaction Log Files (LDF) for systems with normal load;
- file shares with constant data changes, or fast response time;
- TEMPDB files;
Continue with Microsoft Azure IAAS – storage benchmarks, comparison with on-premises (part 3).
Hi Viorel, nice post. what do you mean for outstanding I/O?
Hi Antonio,
I provided the explanation in the first part – https://www.vioreliftode.com/index.php/microsoft-azure-iaas-storage-benchmarks-comparison-with-on-premises-part-1/