top of page

Azure Local Performance Testing (Storage)

  • alynpeden
  • Mar 18
  • 3 min read

Updated: Apr 23



We have been doing a series of various performance testing with Azure Local specifically around EUC workloads, we will continue to share these on our Tech Talk site as we write them up. This particular test was shared at EUC forum in London and if you have any tests you would like to see then please get in touch.


Azure Local has a very different storage architecture than Nutanix where read and write IOPS is typically kept local on each node. Azure local assigns a specific node with the active volume then replicates that volume to other nodes on (typically) a dedicated storage network using Remote Direct Memory Access (RDMA) like the example below;


There are various storage volume configurations depending on your requirement that you can read more about here


When we 1st looked at this set up I immediately thought what would happen if the node where my active volume was running became saturated? would that impact other virtual machines on other nodes accessing that storage volume?


To review the Auxilium Test Lab environment please check out our post here. For these tests we used the EUC Score toolset that you can read more about here and a huge thank you to Dr Bernhard Tritsch who has supported Auxilium in learning and adopting his methods, we highly recommend you check out EUC Score.


Tests were ran on Windows 11 23H2 running on Node 2 while the Storage (Mirror) was running on Node 1 with its volumes being replicated to Node 2 and 3. Storage network was running on a dedicated 10GB network uplinked to a Top of Rack (TOR) switch. In order to saturate the CPU on Node 1 a virtual machine with 100% of host resources assigned to it was set with CPUStress running. Nothing else was running on the cluster.


Baseline Test


The 1st step in evaluating the impact of host saturation on storage was establishing a baseline score and to do this we utilised 2 Sim Loads from the EUC Score toolset both of which ran for 5 minutes. You can read a more detailed explanation about the Storage Sim load tests here


  1. SL3-IOPS - Storage read/write performance test. Measure the time to read five EUC Score data files from EUCScore\Data and write them 100 times to four different user profile folders: User profile root, AppData\Roaming, AppData\Local, and AppData\Local/Temp.


  1. SL3-UserProfileLarge - Storage write performance test. Create an array in memory with 50 strings, each containing 600 characters. Randomly read strings from the array to create 20 files with 15000 lines each. Store files across four user profile folders (root, roaming, local, temp).


SL3-IOPS - Establishing a baseline

Full test can be viewed here


SL3-UserProfileLarge - Establishing a baseline

Full test can be viewed here


Now with a good score especially on the IOPS test we now run the exact same test again on with Node 1 being saturated, you can see below a screenshot from Windows Admin Centre for Node 1



SL3-IOPS-AZL-MAX - Host CPU Saturated

Full test can be viewed here


SL3-UserProfileLarge - Host CPU Saturated

Full test can be viewed here


Summary


Our tests have demonstrated that when an Azure Local host containing an active volume experiences CPU saturation, there is no impact on other virtual machines running on separate hosts that are accessing the same volume. This highlights the robust isolation and performance efficiency of Azure Local, ensuring that workload spikes on one host do not degrade storage performance for VMs on other hosts.


This outcome is particularly significant as it showcases the effectiveness of RDMA (Remote Direct Memory Access) in enabling high-performance, low-latency communication between hosts. The ability of RDMA to bypass CPU bottlenecks and offload network processing ensures that storage access remains consistent and unaffected, even under heavy computational loads.




 
 
 

Comments


Never Miss a Post.
Subscribe Now!

Thanks for submitting!

  • Youtube
  • Grey Twitter Icon
Tech Talk Lockup.png
bottom of page