vSphere contains a handful of storage-related performance techniques to ensure that VM performance is maximized and optimal across the vSphere environment. Storage IO Control and Storage DRS are proving to be quite effective and increasingly popular in vSphere implementations; however, with storage vendors providing auto-tiering functionality in their products, some of the functions from vSphere can negatively interact with auto-tiering functions on the array. Let's take a quick look at the technologies in play, how they interact and how to deal with them in a manner that ensures performance is optimal—and that no one is stepping on anyone else's feet.
What is Storage IO Control (SIOC)?
With vSphere 4.1, VMware introduced a storage prioritization technique to help ensure top priority VMs and storage latency sensitive VMs were able to get storage performance while the storage system was under contention. This approach is called Storage IO Control (lovingly referred to as SIOC going forward).
SIOC monitors the latency of IO operations on a datastore on each ESXi host. When a defined average threshold has been exceeded, SIOC kicks in and starts prioritizing the amount of storage throughput available to VMs. VMs that have been configured with higher shares and/or allowed IOPS (configured similarly to traditional resource shares) receive more queue slots. Conversely, VMs with lower shares and/or allowed IOPS receive fewer queue slots.
The great thing about SIOC is that it is datastore specific, as opposed to being host specific. In the real world, any number of VMs can be running on multiple hosts and sharing the same datastores. If SIOC were purely host based, only the host-level metrics would be available for evaluation. A single VM on another ESXi host could severely degrade the shared datastore, and the other ESXi hosts would not be able to react properly. However, since SIOC can operate across ESXi hosts, all ESXi hosts on the datastore respect the SIOC determinations.
What is Storage DRS?
The concept of Distributed Resource Scheduling (DRS) has been around for quite some time. At a very high level, DRS allows hosts to be aggregated into a DRS enabled cluster. Via vCenter, the cluster is able to analyze performance of the hosts to ensure workloads are evenly distributed between the hosts. In the event there is an imbalance (i.e., one host has more CPU utilization than another), DRS takes action to migrate workloads (read: VMs) around so that all hosts are equally utilizing resources. Consider this basic example: in a cluster of 4 ESXi hosts, DRS would work to ensure each host is running 25% of the workloads, versus a single host running 100% and the remaining 3 sitting idle.
In addition to spreading the workload love between hosts, DRS is able to initially place workloads when VMs are powered on, and handle adherence to affinity/anti-affinity rules that exist.
Storage DRS, quite logically, operates very similar to traditional DRS.
With Storage DRS, datastores with similar IO profiles are grouped together into datastore clusters. Storage DRS can monitor various statistics (notably latency and capacity) and use those statistics to determine the load on a datastore. Based on the results, Storage DRS can proactively initiate a Storage vMotion function (migrate a VM's VMDKs from one datastore to another) to another datastore in the datastore cluster. Theoretically, since the datastores in the datastore cluster have similar IO profiles, the VMs operating should not notice a change in performance, post Storage vMotion operation.
Like traditional DRS, Storage DRS can be used to initially place VM disks when created and ensure storage affinity/anti-affinity rules are adhered to.
What is Auto-Tiering?
The auto-tiering function is becoming very popular in storage environments, especially with the advent of SSD-based storage devices. Auto-tiering acts as a bridge between various tiers of storage aggregates and disk technologies. Rather than create disk aggregates of like-disk technologies (SATA, FC, SAS, SSD, etc.) and relegating VMs to the aggregate based on IO need, the storage array analyzes the data in a number of ways (most active, predictive and so on) and dynamically moves the data between tiers (most active in the highest-performing tier and least active in the lowest-performing tier).
One of the emerging implementations of auto-tiering involves using a number of SSDs as the highest tier and SATA as the low tier. SATA provides the bulk data storage, while SSDs provide a massive amount of performance. Quite the nice combination!
Do they ‘play nice’ with each other?
SIOC, Storage DRS, and auto-tiering are all designed to improve the storage experience for applications. While they all mean well, when combined together, these technologies can create some significant performance degradation. Specifically, when the Storage DRS functionality utilizes the IO Metric function, which moves VMs between datastores based on observed IO latency.
Join us next week for part two, when we’ll discuss the relationship between auto-tiering and sDRS, and how best to deal with it.
Unique control with VM-level actions for infrastructure functions including snapshots, replication and QoS make protection and performance certain in production, and accelerate test and development cycles.