Tag Archives: vSphere SIOC

vSphere 6.0 : How SIOC works with Storage IO reservation

HOME, vSphere API,

Storage IO control(aka SIOC) is one of the cool vSphere features since it got introduced in vSphere 4.1. As we know, whenever there is IO resource contention on shared storage, Storage IO control (SIOC) balances IOPS across the VMs based on the IOPS shares allocated to each VMDK on the VM. As IOPS distribution done by SIOC was only based on IOPS shares , in case of IO contention, there was not IOPS distribution guarantee for mission critical VMs. Also it was hard for admins to understand IO intensive worklaods and set the appropriate IOPS shares, in some cases even admin needs to re-calculate IOPS shares allocation based on workloads. Already there is increasing trend of moving tier-1 applications (which requires guaranteed performance) to vSphere. In order to take this trend of moving tier-1 applications on vSphere platform to the next level, it was very critical that SIOC also should consider storage IO reservation to satisfy service level agreements. I am really excited that VMware has added this feature as part of vSphere 6.0, with vSphere 6.0, SIOC is going to obey the storage IO reservation as well in terms of IOPS whenever there is IO contention. This is going to ensure the guaranteed performance in terms of IOPS. As part of vSphere beta program, I got chance to play with this feature & I would say this feature also going to ensure the greater level of IO performance isolation when admin puts more number of VMDKs per LUN. Now in addition to shares & limit, we have “reservation” as well to manage tier-1 IO(disk) intensive workloads using SIOC. It is important again to note that SIOC will only get invoked when there is IO contention ( based on set IO threshold in terms of latency)

In this post we will see couple of examples on how Storage IO reservation works with Storage IO control (SIOC).

Example 1:
Initial setup
-Say, We have 2 ESXi hosts (H1,H2) with 1 VM per host i.e. H1-VM1 & H2-VM2. Both host are attached to shared datastore DS1. i.e. Both VMs are on the datastore DS1( SIOC is enabled).

IOPS Shares/Reservation Configuration
-Initially each VM takes default share values i.e. Normal (say 1000). Hence VM1 & VM2 will have 1000 shares per VM.
-Consider max IOPS capacity of the shared datastore DS1 is 100 & we set IOPS reservation on VM1 as 60 and IOPS reservation on VM2 is NOT set.

How SIOC will behave
-In case IO contention, based on shares VM1 and VM2 will get 50 IOPS each as their shares are 1000 each but if we notice bit closer IOPS reservation set on the VM1 itself is 60, what happens now? When IOPS distribution based on shares per VM is less than the IO reservation set on the VM (this is our case), IOPS distributed to the VM will be based on IOPS reservation. Hence in our case, VM1 will get 60 IOPS and VM2 will get remaining IOPS i.e. 40.
– If reservation would not have there, each VM would have got IOPS in 1:1 ratio based on shares.

Example 2:
Initial setup is same as that of Example 1.

IOPS Shares/Reservation Configuration
– Share value set on VM1 is 500 & VM2 is 2000.
-Consider max IOPS capacity of the shared datastore DS1 is 100 & we set IOPS reservation on VM1 as 50 and IOPS reservation on VM2 is NOT set.

How SIOC will behave
-In case IO contention, based on shares VM1 will get IOPS distribution as 20 & and VM2 will get 80 but if we notice bit closer IOPS reservation set on the VM1 itself is 50, what happens now? When IOPS distribution based on shares per VM is less than the IO reservation set on the VM (this is our case), IOPS distributed to the VM will be based on IOPS reservation. Hence in our case, VM1 will get 50 IOPS and VM2 will get remaining IOPS i.e. 50.

My additional observations:
-When IOPS reservation set across VMs is more than the max IOPS capacity of the shared datastore, In case of IO contention, IOPS gets distributed in the ratio of set IOPS reservation.
-If IOPS calculation for particular VM based on share is more than the IOPS limit set on the same VM, that will IOPS upto limit set. SIOC will make sure IOPS distribution can not be more than the IOPS limit set on the VM.
-We can not set IOPS reservation more than the IOPS limit.

This is how, in case of IO contention, SIOC will make sure IOPS distribution across VM is guaranteed. I hope you enjoyed reading this post. Stay tuned for my next post on how to configure SIOC and storage IO reservation from vSphere API or web client.

In order to understand SIOC in detail, please refer SIOC detailed insight