3.4 Storage DRS & Storage I/O Control

3.4 Storage DRS & Storage I/O Control

Maintaining storage performance and capacity balance across a large virtual infrastructure requires automated intelligence. While regular vSphere DRS balances compute (CPU and memory) resources across ESXi hosts, Storage DRS (SDRS) and Storage I/O Control (SIOC) manage storage capacity and storage I/O queues across the storage environment.

Understanding how SDRS and SIOC operate—independently and in concert—ensures optimal performance, eliminates the "noisy neighbor" phenomenon, and prevents storage outages caused by over-utilized datastores.

---

Storage DRS (SDRS) Architecture & Datastore Clusters

Storage DRS aggregates multiple individual datastores into a single unified management entity called a Datastore Cluster (also known as a Storage Pod).

Datastore Cluster Prerequisites and Constraints

Before enabling Storage DRS, the underlying storage must satisfy strict architectural rules:

• Filesystem Homogeneity: All datastores within a Datastore Cluster must share the exact same filesystem type. Administrators cannot mix VMFS and NFS datastores in the same Datastore Cluster. Datastores of different sizes, arrays, and vendors can be combined.
• Host Connectivity: All hosts attached to the datastores must run ESXi 5.0 or later. For Storage DRS to place disks freely, the hosts that use the cluster should also see every datastore in it; a datastore that only some hosts can reach narrows the placement choices.
• Single Data Center: Datastores shared across multiple data centers cannot be included in a datastore cluster.
• Replication Consistency: Replicated datastores cannot be combined with non-replicated datastores in the same Storage DRS-enabled datastore cluster, because SDRS could move a replicated disk onto an unreplicated volume.

Version note: vSphere 8.0 Update 3 deprecated Storage DRS I/O-latency load balancing, SIOC shares and reservations in storage policies, and enabling SIOC on a datastore. They remain supported for the vSphere 8 lifecycle. Space-based balancing, datastore maintenance mode, and SIOC limits are not affected.

Automation Levels

Similar to compute DRS, Storage DRS offers two automation modes:

• Fully Automated: Storage DRS automatically executes initial virtual disk placement and automatically initiates Storage vMotion migrations when capacity or latency thresholds are breached.
• Manual: Storage DRS calculates optimal placement and rebalancing recommendations, displaying them in vCenter Server for administrator approval before execution.

---

SDRS Placement and Load Balancing Mechanics

Storage DRS operates along two distinct functional dimensions: Initial Placement and Dynamic Load Balancing.

+-----------------------------------------------------------------------------+
|                   Storage DRS (SDRS) Operational Flow                       |
+-----------------------------------------------------------------------------+
|                                                                             |
|   [ VM Provisioning / Migration ]                                           |
|                 |                                                           |
|                 v                                                           |
|   +----------------------------+                                            |
|   | SDRS Initial Placement     | ---> Evaluates Free Space, I/O Latency,    |
|   |                            |      and Active Affinity Rules             |
|   +----------------------------+                                            |
|                 |                                                           |
|                 v                                                           |
|   [ Virtual Disks Placed on Optimal Datastore ]                             |
|                                                                             |
|   -----------------------------------------------------------------------   |
|                                                                             |
|   [ Continuous Monitoring Engine ]                                          |
|                 |                                                           |
|                 +---> Space Utilization Check (Every 8 hours or threshold)  |
|                 |     - Trigger: Default > 80% or Min Free Space (e.g. 50GB)|
|                 |                                                           |
|                 +---> I/O Latency Check (90th percentile over a day)        |
|                       - Trigger: Latency exceeds threshold (Default 15ms)   |
|                 |                                                           |
|                 v                                                           |
|   +----------------------------+                                            |
|   | Storage vMotion Migration  | ---> Dynamically evacuates disks to        |
|   | (Auto or Recommendation)   |      congested datastores' cluster peers   |
|   +----------------------------+                                            |
+-----------------------------------------------------------------------------+

1. Initial Placement

When a user deploys, clones, or migrates a virtual machine to a Datastore Cluster, the Storage DRS placement engine evaluates all member datastores. It analyzes:

• Available free capacity.
• Current I/O latency trends.
• Existing affinity and anti-affinity rules. SDRS selects the optimal datastore, eliminating guesswork during provisioning.

2. Dynamic Load Balancing Triggers

Storage DRS continuously monitors member datastores and triggers automated Storage vMotion migrations based on two independent metrics:

• Space Utilization Threshold:
  • Configured either as a percentage (default: 80%) or as a minimum free space value (e.g., 50 GB).
  • SDRS evaluates space utilization on an 8-hour schedule or immediately when a threshold violation occurs. If a datastore exceeds 80% utilization, SDRS calculates candidate VMDK migrations to balance utilization across the cluster.
• I/O Latency Threshold:
  • Configured as a latency limit in milliseconds (default: 15 ms).
  • The 90th Percentile Rule: To avoid overreacting to brief spikes (such as a morning antivirus scan), SDRS collects latency data over a day and compares the 90th-percentile I/O latency with the threshold. The 90th percentile roughly marks the lower edge of the busiest period. If it exceeds the threshold (15 ms by default), SDRS treats the datastore as overloaded and recommends Storage vMotion moves off it.

---

SDRS Affinity and Anti-Affinity Rules

To ensure enterprise application performance and fault tolerance, Storage DRS provides three distinct rule types:

1. Intra-VM VMDK Affinity (Default Behavior)

• Rule: Keeps all virtual disks (.vmdk files) belonging to a specific virtual machine together on the same datastore.
• Rationale: Keeps virtual machine administration simple and avoids fragmenting a single VM's disks across multiple storage volumes.

2. Intra-VM VMDK Anti-Affinity

• Rule: Forces specific virtual disks belonging to the same virtual machine onto different datastores within the cluster.
• Enterprise Use Case: High-transaction enterprise database workloads (such as Microsoft SQL Server or Oracle Database). An administrator places the database log disk (.ldf or redo log) and the database data disk (.mdf) on separate datastores backed by different physical arrays or RAID groups. This prevents log writes from contending with random data queries.

3. Inter-VM Anti-Affinity

• Rule: Mandates that specified distinct virtual machines are placed on different datastores.
• Enterprise Use Case: Redundant application tiers, such as two Active Directory Domain Controllers, clustered web servers, or Microsoft WSFC database nodes. Inter-VM anti-affinity ensures that an outage or maintenance event on a single datastore cannot take down both redundant application instances simultaneously.

---

Storage I/O Control (SIOC)

Storage I/O Control (SIOC) provides distributed, cluster-wide Quality of Service (QoS) and queue management for shared datastores. It prevents the "noisy neighbor" problem where a low-priority virtual machine running on Host A consumes excessive storage bandwidth, starving a critical production virtual machine running on Host B.

+-----------------------------------------------------------------------------+
|                 Storage I/O Control (SIOC) Queue Throttling                 |
+-----------------------------------------------------------------------------+
|                                                                             |
|   [ Normal State: Latency < Threshold (e.g., 30ms) ]                        |
|   SIOC is DORMANT. All VMs have unconstrained HBA queue access.             |
|                                                                             |
|   -----------------------------------------------------------------------   |
|                                                                             |
|   [ Congested State: Latency > Congestion Threshold ]                       |
|   SIOC ACTIVATES cluster-wide. Throttles device queue depth by Shares:      |
|                                                                             |
|    +----------------------+                   +----------------------+      |
|    | Host A (Critical VM) |                   | Host B (Batch VM)    |      |
|    | Shares: HIGH (2000)  |                   | Shares: LOW (500)    |      |
|    +----------------------+                   +----------------------+      |
|               |                                           |                 |
|               v                                           v                 |
|       [ Large Queue Depth ]                       [ Throttled Queue ]       |
|       (Unimpeded I/O Flow)                        (Injected Queue Delay)    |
|               \                                           /                 |
|                \                                         /                  |
|                 +-------------------+-------------------+                   |
|                                     |                                       |
|                          [ Shared Storage LUN ]                             |
|                             (Queue Relieved)                                |
+-----------------------------------------------------------------------------+

How SIOC Operates

1. Dormant During Normal Operation: When a datastore experiences low latency and no contention, SIOC does nothing. Every virtual machine on every host enjoys full, unconstrained access to the storage controller queues.
2. Congestion Threshold Trigger: SIOC activates only when datastore-wide average latency exceeds a configured threshold. The threshold can be set in two ways:
   • Percentage of Peak Throughput: The threshold dynamically adjusts to the latency observed when the datastore delivers a percentage (default: 90%) of its maximum estimated throughput.
   • Manual Millisecond Limit: A static latency threshold configured by the administrator (default: 30 ms).
3. Distributed Queue Depth Throttling: When datastore latency crosses the threshold, SIOC calculates the normalized entitlement for each virtual machine based on its assigned Shares. SIOC then instructs the VMkernel on each ESXi host to dynamically throttle the HBA device queue depth for low-priority VMs, ensuring that high-priority workloads receive their fair share of storage bandwidth.

Disk Share Values & Resource Controls

When SIOC is active, I/O queue distribution is governed by virtual disk parameters:

• Shares: Define relative priority during contention.
  • High: 2000 shares per virtual disk.
  • Normal: 1000 shares per virtual disk (High receives 2x the I/O entitlement of Normal).
  • Low: 500 shares per virtual disk (Normal receives 2x the I/O entitlement of Low).
  • Custom: Explicit integer value.
• Limits: Configured in IOPS to enforce a strict ceiling on disk throughput, regardless of whether the datastore is congested.
• Reservations: Guarantees a minimum IOPS floor for mission-critical disks.

SIOC Prerequisites & Constraints

• Supported on standard VMFS and NFS datastores.
• Unsupported on Virtual Volumes (vVols) and vSAN (both platforms implement per-VM QoS natively through storage policies) and not supported for Raw Device Mappings (RDMs).
• Single vCenter Requirement: All ESXi hosts mounting the datastore must be managed by the same vCenter Server.
• No Multi-Extent Volumes: SIOC cannot be enabled on multi-extent (spanned) VMFS datastores.
• Dedicated LUN Access: If non-ESXi workloads (such as physical servers) share access to the same physical LUN, they will distort latency calculations and prevent SIOC from accurately throttling queues.

---

Comparison: Storage DRS vs. Storage I/O Control

Configuring SIOC and Datastore Cluster Options (Objectives 5.5 and 7.4.3)

Enable and Tune SIOC on a Datastore (5.5)

1. Select the datastore, then Configure > General > Datastore Capabilities > Storage I/O Control > Edit.
2. Enable SIOC, and choose the congestion threshold: a percentage of peak throughput (default 90%) or a manual latency value (default 30 ms).
3. Optionally exclude the datastore's I/O statistics from Storage DRS.
4. Set per-disk shares, limits, and reservations through VM storage policies that include a Storage I/O Control component (or, for shares and limits, in the VM's disk settings).

Datastore Cluster Options (7.4.3)

Create the cluster with New Datastore Cluster on a data center, add compatible datastores, and configure: