SIOC is considered to be one of the finest addition to the VMware feature stack. In this blog we will discuss about SIOC and its impact on Disk usage.
Before discussing about SIOC, we should understand the relevance of VM based 'Disk Shares' in VMware. The disk share concept is simple and much alike Memory and CPU shares. When there is a resource constraint, the host will throttle the disk usage of VMs by adjusting its Disk Queue Depth based on its share values. If all the VMs have the same Disk Share, the control over disk will be shared among all VMs. If the share value of a VM is high, it gets precedence over other VMs.
Simple and effective right...then why should VMware introduce a new feature called Storage I/O Control - SIOC.
The answer is simple, 'Disk Share' calculates the share value of VMs in a particular host whereas the relevance of SIOC comes in a cluster.
SIOC is configured for a particular datastore and will be disabled by default. Once enabled, SIOC gets active based on the value of the datastore latency. The current latency of datastore will be stored in the file called iormstat.sf which is hidden in the datastore. The default threshold value of latency is set to 30ms which is of course configurable. The threshold value can be changed based on the underlying storage technology. For eg: <20 and="" for="" ms="" nbsp="" sata.="" span="" ssd="">SIOC requires VMware Enterprise Plus license.
A datastore-wide disk scheduler (PARDA control algorithm) runs on each host sharing that datastore. This scheduler will be triggering 'Latency computation' and 'Window Size Computation' algorithms. 'Latency Computation' is used to detect if SIOC needs to throttle queues to ensure each VM gets its fair share. 'Window Size Computation' is used to calculate what this queue depth should be for your host. Once the queue depth is calculated by PARDA, the 'Local Host Scheduler' will take on from there. By default the queue depth is 32 and will be adjusted to a value calculated by PARDA which will be always higher than 4.
VMware recommends that this feature should be enabled for better VM performance. It is not at all advisable to leave a datastore unconfigured with SIOC, when other datastores in the same physical array is configured with SIOC.
Pictorial representation of SIOC scenario
Suppose we have 3 VMs with equal disk shares of 1000 each. 2 VMs are in one ESXi and the 3rd VM in another ESXi. When SIOC is disabled, even though all VMs are configured with equal shares, the VM in the 2nd ESXi will enjoy more disk shares during resource constraint.
With SIOC enabled, VMs across hosts enjoys a fair share.
Before discussing about SIOC, we should understand the relevance of VM based 'Disk Shares' in VMware. The disk share concept is simple and much alike Memory and CPU shares. When there is a resource constraint, the host will throttle the disk usage of VMs by adjusting its Disk Queue Depth based on its share values. If all the VMs have the same Disk Share, the control over disk will be shared among all VMs. If the share value of a VM is high, it gets precedence over other VMs.
Simple and effective right...then why should VMware introduce a new feature called Storage I/O Control - SIOC.
The answer is simple, 'Disk Share' calculates the share value of VMs in a particular host whereas the relevance of SIOC comes in a cluster.
SIOC is configured for a particular datastore and will be disabled by default. Once enabled, SIOC gets active based on the value of the datastore latency. The current latency of datastore will be stored in the file called iormstat.sf which is hidden in the datastore. The default threshold value of latency is set to 30ms which is of course configurable. The threshold value can be changed based on the underlying storage technology. For eg: <20 and="" for="" ms="" nbsp="" sata.="" span="" ssd="">SIOC requires VMware Enterprise Plus license.
A datastore-wide disk scheduler (PARDA control algorithm) runs on each host sharing that datastore. This scheduler will be triggering 'Latency computation' and 'Window Size Computation' algorithms. 'Latency Computation' is used to detect if SIOC needs to throttle queues to ensure each VM gets its fair share. 'Window Size Computation' is used to calculate what this queue depth should be for your host. Once the queue depth is calculated by PARDA, the 'Local Host Scheduler' will take on from there. By default the queue depth is 32 and will be adjusted to a value calculated by PARDA which will be always higher than 4.
VMware recommends that this feature should be enabled for better VM performance. It is not at all advisable to leave a datastore unconfigured with SIOC, when other datastores in the same physical array is configured with SIOC.
Pictorial representation of SIOC scenario
Suppose we have 3 VMs with equal disk shares of 1000 each. 2 VMs are in one ESXi and the 3rd VM in another ESXi. When SIOC is disabled, even though all VMs are configured with equal shares, the VM in the 2nd ESXi will enjoy more disk shares during resource constraint.
No comments:
Post a Comment