SQL Server AG Resiliency on AVS with Everpure Cloud Dedicated

Overview

This article describes recommended settings for running SQL Server Availability Groups (AG) on Azure VMware Solution (AVS) using VMFS datastores backed by Everpure Cloud Dedicated for Azure (EC Dedicated). The guidance is based on resiliency testing with injected storage latency on EC Dedicated VMFS datastores and is intended to reduce I/O related errors and unnecessary SQL AG or Windows Server Failover Clustering (WSFC) instability during transient storage issues.

Applies to

Test Context

In the underlying tests:

• Two Windows Server VMs were configured in a SQL AG and WSFC cluster, with a third VM providing a witness.

• SQL data and log volumes were VMware virtual disks on EC Dedicated VMFS datastores.

• EC Dedicated operated using Azure resiliency tunables.

• Windows DiskTimeOutValue for SQL data/log disks was evaluated at 60 seconds (default) and 240 seconds.

• Storage outages were simulated by injecting 50 seconds of additional latency for 1 minute and, in separate tests, for 4 minutes, with values chosen below the internal “sick” timeout so EC Dedicated itself did not intentionally fail over.

Short‑duration outages (50 seconds over 1 minute) were tolerated well in all runs. Longer outages (50 seconds over 4 minutes) increased I/O retries and CPU/interrupt load and, in some cases, led to AG lease timeouts and WSFC recovery actions when the guest stack was under sustained I/O pressure.

Recommended Configuration

Resiliency in this environment is driven by both EC Dedicated’s handling of transient latency and Windows’ response to delayed I/O on SQL volumes.

EC Dedicated in the tests was running with resiliency tunables, the recommendations below assume that this configuration is in place.

On the Windows guest side, it is recommended that DiskTimeOutValue = 240 seconds be configured for volumes that reside on EC Dedicated VMFS datastores. With the default 60 second timeout, tests observed more frequent disk‑level error events during injected latency, reflecting I/O timeouts and retry storms on those volumes. After increasing DiskTimeOutValue to 240 seconds for the data and log disks, disk timeout events were significantly reduced or eliminated across runs, while the VMs continued to recover from short‑to‑moderate slowdowns without immediately surfacing I/O timeout errors in the guest.

This longer timeout does not alter EC Dedicated behavior; it simply allows Windows and SQL Server more time to complete I/O when EC Dedicated experiences a brief latency spike.

For SQL AG and WSFC, the tests used a configuration aligned with Microsoft best practices for AG and clustering. No special cluster policy changes were required beyond those recommendations. Customers should continue to design AG topology, quorum model, listener configuration, and failover behavior according to Microsoft guidance and their own SLAs.

The cluster watcher / witness plays an important role in this design. The watcher can be:

• A Local Disk Witness

• A File Share Witness

• Azure Public Cloud Witness

provided it is reachable from the AG nodes and meets Microsoft’s requirements for WSFC quorum. Hosting the witness on independent storage helps ensure that quorum is not directly affected by the same latency events that may impact the SQL data volumes.

Operational Considerations

When SQL Server VMs, including their operating system and SQL volumes, run entirely on EC Dedicated VMFS datastores:

• Short, transient latency events are handled more gracefully when EC Dedicated is operated with the appropriate resiliency tunables and DiskTimeOutValue on SQL data/log volumes is set to 240 seconds. Under these conditions, testing showed that AG and WSFC remained stable for the short‑duration outages considered.

• Longer or repeated latency episodes can still produce extended I/O retries, elevated CPU and interrupt activity, AG lease timeouts, and WSFC recovery actions, consistent with documented WSFC behavior under sustained storage stalls.

In practice, this means that the combination of:

• EC Dedicated being operated with Azure resiliency tunables by Everpure,

• a 240‑second DiskTimeOutValue on volumes on EC Dedicated VMFS, and

• a resiliently hosted cluster watcher/witness

reduces the likelihood that short storage slowdowns will result in disk errors or unnecessary SQL AG failovers. At the same time, standard SQL AG and WSFC high‑availability design remains the primary protection against longer or more severe infrastructure events.

Summary

For SQL Server AG on AVS with VMFS datastores backed by Everpure Cloud Dedicated for Azure:

• EC Dedicated should be operated with the Azure resiliency tunables applied. These are part of the 6.10.3 release. Find out more in the Release Notes or Resiliency Tunables KB.

• Windows should be configured so that DiskTimeOutValue = 240 seconds is used for volumes on EC Dedicated VMFS, to reduce disk timeout events and I/O retry storms during transient latency.

• SQL AG and WSFC should follow Microsoft best practices, with storage tuned as described to minimize storage‑driven instability.

• In line with Microsoft guidance, the WSFC cluster witness should be configured as a Cloud Witness, so that quorum is not directly affected by temporary storage I/O delays on the SQL data volumes.

These measures were observed in testing to help SQL AG workloads on AVS remain resilient to short‑term latency events on EC Dedicated VMFS datastores.