SQL Server 2025 on Dell PowerMax with Failover Cluster Instance
Executive summary
Executive summary
Overview
Revision history
Audience
Terminology
We value your feedback
Product overview
Product overview
PowerMax
Unisphere for PowerMax
Solutions Enabler
Windows Server and Failover Cluster
Microsoft SQL Server
Solution overview
Solution overview
System architecture
The logical architecture, as shown in the following figure, uses a three-node WSFC with shared storage over FC. Each node accesses the shared storage, which enables SQL Server to fail over between nodes to minimize service disruption and reduce downtime.
As a recommended best practice, database files are distributed across multiple LUNs to distribute the I/O and together with Windows MPIO, achieve high throughput from the storage system. Three storage groups are provisioned on the PowerMax system for the database data files, log file, and the system and tempdb. This separation improves performance, enables I/O type isolation, and allows SnapVX‑based backup and restore of database files without overwriting log files. For more information, see SQL Server database layout.
The data storage group consists of four volumes, while the log and the system/tempdb storage groups each contain a single volume, all of which are mapped to three Windows compute hosts using a masking view. In this test environment, the array is configured with four FC front‑end ports providing four active paths per volume for redundancy and fault tolerance, whereas production environments typically use a higher number of connected ports.
Each database host runs Windows Server 2025 and uses Windows MPIO to present the storage LUNs as a single logical disk while leveraging multiple paths for resiliency and fault tolerance. MPIO improves availability and balances I/O across available paths during normal operation and fault conditions.
SQL Server failover cluster deployment
SQL Server failover cluster deployment
Windows Server Failover Cluster
All the services that are required for deploying the failover cluster, including DNS, AD, and NTP servers, are hosted on a separate host. These services do not share any resources with the hosts where the SQL Server database workload is running.
The following figure shows the cluster that is built from the three nodes:
WSFC requires a quorum to maintain cluster availability and avoid split‑brain conditions; in this design the quorum is provided by a shared disk witness that is hosted on a dedicated WSFC_Witness storage group on PowerMax. This disk witness acts as a tiebreaker, enabling the cluster to make consistent and reliable failover decisions.
All storage required for the WSFC deployment, including the quorum witness drive and the SQL Server database volumes, is provisioned and managed through Unisphere for PowerMax. To grant the WSFC cluster nodes access to the storage, Unisphere uses masking views to map and share the volumes.
One of the important steps in a WSFC deployment is selecting the preferred owners for the clustered role to explicitly define which nodes can host the workload during a failure. Properly configuring these preferred owners is critical, as an incomplete or incorrect selection can prevent a successful failover.
As shown in the preceding figure, all three cluster nodes are selected as preferred owners for the SQL Server FCI. This configuration allows WSFC to fail over the SQL Server FCI role to any available node, ensuring resiliency during node failures or maintenance events.
SQL Server FCI deployment
This solution incorporates SQL Server FCI to leverage its inherent high availability, fault tolerance, and seamless failover capabilities for database workloads. The following essential cluster components are required to build a highly available SQL Server (FCI):
- Dedicated Cluster Network: A dedicated network isolates cluster communication and ensures reliable heartbeat monitoring between the nodes.
- Virtual IP (VIP): A specifically assigned VIP provides consistent client connectivity regardless of which cluster node currently hosts the active database instance.
- Storage Dependencies: SQL Server FCI depends heavily on storage resources for a successful failover. These dependencies are defined using the WSFCM and dictate the exact order in which the system brings resources online during startup or failover operations.
The following figure shows the active SQL Server FCI. The role, named "SQLInstance1," is currently online and relies on its associated cluster resources to maintain high availability and coordinate failover. When a node failure occurs, WSFC automatically transitions the SQL Server role and all dependent resources to a healthy node.
The preceding figure illustrates "SQLInstance1" and its explicit dependency on six storage volumes. The cluster must verify and bring all six storage volumes online before the SQL Server role can successfully start.
SQL Server database layout
General guidelines for database layout design
When designing the database layout, apply the following general guidelines:
- Volume Count and I/O Concurrency: For high-IOPS workloads, spread data files across multiple storage volumes to maximize I/O concurrency.
- I/O Isolation: Provision dedicated and separate volumes for the transaction log and the
system/tempdbfiles (in larger deployments, the system andtempdbfiles can be placed on separate volumes). This isolation prevents the mixing of random data access patterns with sequential log access patterns, resulting in efficient I/O distribution. It also allows use of the PowerMax SnapVX feature to create T-SQL based backups where the database files can be restored without overwriting the transaction log. - Capacity Planning and Future Growth: Storage sizing requires establishing a standardized building block, such as 2 TB or 5 TB volumes. When a database grows and requires additional capacity, administrators can add new volumes that match the size and count of the existing deployment to maintain an even I/O distribution. For example, if a deployment starts with four 10 TB devices, future expansions should use an additional four 10 TB devices. Alternatively, administrators can provision initial volumes that are sized for near-term to medium-term requirements and dynamically expand those existing volumes as data grows. Both methods are effective, allowing storage teams to choose the expansion strategy that best aligns with their infrastructure management practices.
- File System Formatting: Format all SQL Server database volumes on PowerMax storage with the NTFS file system using a 128 KB allocation unit size. This exact size matches the PowerMax track size, which improves storage data reduction efficiency, ensures proper alignment for Microsoft ODX operations, and delivers optimal integration between the database and the storage platform.
Based on the preceding guidance, this solution database is configured with a specific capacity layout optimized for a 300 GB dataset, as illustrated in the following figure:
This layout spreads the data files equally across four separate 300 GB data volumes (Drives E, F, G, and H). A 600 GB volume (Drive I) is used for log file and a 100 GB volume (Drive D) is used for SQL Server system and tempdb files. To support the I/O demands of this configuration, the deployment uses two host initiators for each volume, connected to two storage targets, for a total of four paths per volume.
The following table specifies the volume size and file system for a 300 GB SQL Server database:
| Drive letter | Volume size (GB) | File system | Allocation size | Purpose |
| D | 100 | NTFS | 128 K | SQL server System and TempDB files |
| E | 300 | NTFS | 128 K | Data file 1 |
| F | 300 | NTFS | 128 K | Data file 2 |
| G | 300 | NTFS | 128 K | Data file 3 |
| H | 300 | NTFS | 128 K | Data file 4 |
| I | 600 | NTFS | 128 K | Log files |
Scaling the SQL Server FCI deployment
When organizations deploy large‑scale SQL Server environments to support multiple applications, a multi-FCI environment allows administrators to consolidate these applications onto a shared infrastructure rather than dedicating a separate physical cluster node for each application. For this solution, deploying a multi-FCI environment enabled effective stress testing of both SQL Server workloads and the PowerMax storage platform. This section demonstrates how to deploy multiple independent SQL Server Failover Cluster Instances (FCIs) within the WSFC environment.
To provide an example, the solution uses three independent SQL Server FCIs. Each FCI operates with its own active and passive nodes. Deploying multiple FCIs does not require separate SQL Server software installations or clusters. Instead, as shown in the following example, multiple named instances are configured across the same cluster nodes:
The preceding image illustrates a three-node WSFC setup and outlines the active-passive configuration of each SQL Server FCI.
Each SQL Server FCI in the WSFC setup uses its own dedicated shared storage for data, log, system, and tempdb files, allowing for better scale, performance, and resource isolation. For ease of storage management, the volumes for each FCI are configured in their own dedicated storage group. Storage groups provide logical grouping of volumes, enabling administrators to easily provision, map, and manage storage resources (such as service levels, capacity forecast, performance monitoring, replications, and more) for clustered SQL Server workloads.
In this configuration, node 1 hosts the active SQL Server instance for FCI 1, node 2 hosts the active instance for FCI 2, and node 3 hosts the active instance for FCI 3. Because the WSFC includes all three nodes, the other two nodes automatically serve as passive standby for each FCI. If an active node experiences a failure, the affected FCI and its resources seamlessly fail over to any of the remaining available nodes in the cluster.
Performance Validation Tests
Performance Validation Tests
Test validation
HammerDB tool is used to run the OLTP workload tests against multiple SQL Server FCI deployments. The SQL Server FCI databases are first populated with a data set of 1,556 warehouses, resulting in approximately 150 GB per database instance. Multiple test runs are then conducted, each lasting 30 minutes. In each test run, 30 virtual users are used.
The primary objective of this test is to evaluate the available lab configuration in a multi-FCI environment. The dataset is large enough not to fit in either host or storage cache, allowing the SQL Server workload to push more IOPS, while operating under a storage latency of less than 1 millisecond. As described in the System Architecture section, the lab setup used the Least Queue Depth (LQD) Windows multipath policy to optimize path selection and balance I/O across the available storage paths for the benchmark runs.
Note: For all tests, the SQL Server buffer cache was set to only 4 GB for each SQL Server instance from a total of 128 GB available memory on each SQL Server host. This was done to limit database caching and allow more storage IOPS.
A dedicated load-generation VM was provisioned with the Windows Server 2025 operating system to launch the HammerDB tool, which connected to the database over the network and generated transactions. This HammerDB VM was hosted on a separate host and did not use any storage or compute resources from the SQL Server hosts.
In this solution, a VM launches three clients of HammerDB software, each connects to an individual SQL Server FCI active node. As illustrated in the image above, HammerDB client 1 connects to the active node of SQL Server Instance 1 on FCI 1, client 2 connects to the active node of SQL Server instance 2 on FCI 2, and so on As a result, each SQL Server FCI generates an OLTP workload on its respective SQL Server database instance, driving IOPS to its dedicated storage groups.
The team conducted multiple tests using different virtual user counts and finalized 30 virtual users. The ‘think-time’ option is not used by the HammerDB clients, so each of these virtual users is running transactions as fast as possible, and the transactions are allowed to run against all warehouses, ensuring that the virtual users exercise the full dataset. With this lab configuration and virtual user count, this design delivers the optimal database performance while maintaining sub‑millisecond storage latency.
Test results
The performance test results demonstrate the ability of PowerMax to scale IOPS while maintaining sub‑millisecond latency as the SQL Server workload scales. All SQL Server database volumes that are used for this test are configured with the Diamond service level.
The workload is generated using HammerDB and is scaled incrementally. In the first scenario, a single HammerDB client generates an OLTP workload to one SQL Server FCI, using 30 virtual users across all 1,556 warehouses. In the next phase, two HammerDB clients simultaneously generate identical workloads against two separate SQL Server FCI’s, again using 30 virtual users per instance and the same warehouse configuration. In the final scenario, three HammerDB clients run concurrently against three separate SQL Server FCIs, each with 30 virtual users across all warehouses.
As shown in the following figure, increasing the number of active database workloads results in incremental TPM and IOPS scaling, while consistently maintaining sub-millisecond read and write latency.
During the simultaneous run of three SQL Server FCIs, the overall resource utilization of the one node-pair PowerMax 2500 lab configuration was high. While this specific lab setup was fully utilized by the test, larger-scale workloads can be easily accommodated by scaling out with additional PowerMax node-pairs or using the larger scale PowerMax 8500 system.
Note: These results do not represent the maximum performance capabilities of PowerMax. They reflect observations from the specific lab-based testing environment and are provided to illustrate best practice validation and configuration behavior.
Best practices
Best practices
Windows Server and SQL Server 2025
PowerMax best practices
HammerDB best practices
PowerMax service levels and SQL Server
PowerMax service levels and SQL Server
Service levels overview
PowerMax storage systems are often used to consolidate multiple databases and applications on a single storage system. To manage performance effectively and align it with business priorities, PowerMax uses service levels (SLs) to control I/O latency and resource allocation for storage groups (SGs). Service levels provide a structured way to prioritize workloads and ensure consistent performance for critical applications.
Common use cases for service levels include restricting noisy‑neighbor workloads (Tier 2 Application), prioritizing production databases over development and test systems, and supporting service provider or chargeback models where different applications or tenants require tiered performance.
By default, the PowerMax system assigns newly created storage groups to the Diamond service level. This service level delivers the best performance. Each service level has a defined performance range (and expected average response time). If it cannot maintain this performance range, it will cause service levels with lower priority to slow down (as shown in the following figure).
How service levels work
When using service levels, you can assign higher service levels (such as Diamond, Platinum, or Gold) to mission‑critical applications so that they receive priority over Tier‑2 applications that are assigned to lower service levels (such as Silver, Bronze, or Optimized).
The following figure shows the service level order and the performance offerings that are associated with each level:
PowerMax enforces service level priorities by managing I/O latency between storage groups. If a higher-priority storage group cannot meet its expected performance, latency may increase for lower-priority storage groups, so that mission-critical workloads continue to perform as expected. For example, Diamond storage groups can impact Platinum storage groups, which can in turn affect Gold storage groups, and so on. Any storage group assigned a non‑optimized service level can influence optimized storage groups, ensuring that higher‑priority applications take precedence when resources are constrained.
Single database workloads with service levels
The following figure demonstrates how PowerMax service levels influence the performance of a single SQL Server database workload. Throughout this test, the HammerDB workload remained unchanged, ensuring a continuous load. The only variable that was introduced was the service level change to the user database storage group (AB_Instance3_SQL_data) after every 30-minute interval.
At the Bronze service level, the database experienced an average latency of approximately 5 ms and around 14,000 IOPS. When the service level was increased to Silver, latency dropped to 2 ms, and IOPS increased by more than 50 percent to approximately 34,000. Assigning the Gold service level further reduced latency to about 0.42 ms and increased throughput to 127,000 IOPS. Both Platinum and Diamond service levels delivered similar results, maintaining latency near 0.15 ms and achieving approximately 218,000 IOPS.
Service level changes take effect immediately because they are enforced at the PowerMaxOS software layer. These results also show that service level settings influence both read and write latency, directly affecting overall SQL Server database performance.
Conclusion
Conclusion
Appendix A: Additional PowerMax features enhancing Windows and SQL Server deployments
Appendix A: Additional PowerMax features enhancing Windows and SQL Server deployments
PowerMax compression and deduplication
Data reduction example
This is a common enterprise example in which a host-based data copy doubles the logical consumed storage capacity (the original data, and its exact copy), yet PowerMax deduplication prevents such unnecessary storage overhead. The example illustrates a cold backup of a production database, which is used to create a development, test, or quality‑assurance environment copies that resemble the production database. In many organizations, these backup files are large and can consume significant storage capacity, especially when multiple copies are used to create non‑production environments. In the example, a cold backup of the HammerDB database from the earlier performance tests is created, representing a production backup.
A Windows host‑based file copy is used to copy the backup files from one NTFS‑formatted volume to others, all provisioned from the PowerMax system with a 128 KB allocation unit size. One copy target volume has data reduction enabled while the other does not. When the data copy occurs, alignment with the PowerMax 128 KB track size allows the storage deduplication feature to recognize the identical data blocks without having to physically consume that storage capacity again, significantly reducing overall storage consumption.
In this scenario, the cold backup data resides on the source volume Source_Vol (I:) , which is a PowerMax LUN without data reduction enabled. This volume contains the full set of HammerDB data and log files that are associated with the user database, totaling approximately 1.45 TB of stored data.
The target volume, Target_Vol (J:), is a newly provisioned PowerMax LUN with data reduction enabled and represents the SQL Server instance supporting a development or QA database environment.
Before performing the copy operation, storage metrics were verified using the SE CLI. At this stage, the SRP reported 9,591 GB of used capacity, while the target volume showed 0 GB of effective used capacity. Because the target volume was empty, no data reduction ratio (DRR) is applicable at this point.
symcfg list -srp -detail -gb
STORAGE RESOURCE POOLS
Symmetrix ID : 000120002165
C A P A C I T Y
-------------------------------- --- --------------------------------------------
Flag Physical Physical Physical Provisioned
Name DRR (GB) Used(GB) Free(GB) (GB)
-------------------------------- --- ---------- ---------- ---------- -----------
SRP_1 FXO 100509.4 9591.2 90918.2 88249.1
---------- ---------- ---------- -----------
Total 100509.4 9591.2 90918.2 88249.1
symcfg -sid 2165 list -sg_compression -all
-------------------------------- --- --------------------------------------------
Flags Number Effective Physical Estimated
Storage Group Name C Devices Used(GB) Used(GB) Ratio
-------------------------------- --- --------------------------------------------
Target_DRR_Volume x 1 0.0 0.0 26.9:1
The backup data and log folders are copied at the host level from
Source Vol
(I:)Target Vol (J:) using Windows Explorer. After the copy operation is completed, storage metrics are verified again using the SE CLI.
symcfg list -srp -detail -gb
STORAGE RESOURCE POOLS
Symmetrix ID : 000120002165
C A P A C I T Y
-------------------------------- --- --------------------------------------------
Flg Physical Physical Physical Provisioned
Name DRR (GB) Used(GB) Free(GB) (GB)
-------------------------------- --- ---------- ---------- ---------- -----------
SRP_1 FXO 100509.4 9728.4 90781.0 88249.2
---------- ---------- ---------- -----------
Total 100509.4 9728.4 90781.0 88249.2
symcfg -sid 2165 list -sg_compression -all
----------------------------------------------------------------------
Flags Number Effective Physical Estimated
Storage Group Name C Devices Used (GB) Used(GB) Ratio
----------------------------------------------------------------------
Source_DRR_Voume . 1 685.7 685.7 1.0:1
Target_DRR_Volume X 1 685.7 137.9 4.9:1
After the copy operation, the SRP used capacity increased by approximately 137 GB. The target volume reported 685 GB of effective used capacity while consuming only 137 GB of physical capacity, resulting in a data reduction ratio (DRR) of approximately 4.9:1. This difference highlights the effectiveness of PowerMax deduplication, where identical data blocks are stored only once, significantly reducing the physical storage required on the target volume.
As shown in the preceding output, complete data reduction was not immediately achieved because Activity-Based Reduction (ABR) kept data extents uncompressed due to the copy operation being the hottest activity in the test storage system.
Also, Dell best practice is to use snapshots or clones for the most efficient time and capacity savings when the DBAs still require a host-based copy. This approach still allows storage capacity optimization benefits without proportionally increasing storage consumption.
Windows ODX feature
ODX copy example
In this example, two NTFS volumes, X: and Y:, are provisioned from separate PowerMax LUNs and formatted with a 128 KB allocation unit size. The source volume (X:) contains an SQL Server backup file of approximately 700 GB, while the target volume (Y:) is empty.
Copy test with ODX disabled
With ODX disabled, the backup file is copied from the X: to the Y: volume using a multithreaded robocopy operation.
C:\ > Set-ItemProperty -Path 'hklm:\system\currentcontrolset\control\filesystem' -Name 'FilterSupportedFeaturesMode' 1
Robocopy /MIR /MT X:\ Y:\
------------------------------------------------------------------------------
100% New File 676.5 g X:\oltp_backup
------------------------------------------------------------------------------
Total Copied Skipped Mismatch FAILED Extras
Dirs : 4 3 4 0 0 0
Files : 2 1 1 0 0 0
Bytes : 676.530 g 676.530 g 129 0 0 0
Times : 0:25:31 0:06:22 0:00:00 0:06:22
Speed : 1,897,487,642 Bytes/sec.
Speed : 108,575.117 MegaBytes/min.
When ODX is disabled, the copy operation relies entirely on host‑based reads and writes. In this test, copying the 700 GB file took approximately six minutes, with a transfer rate of about 1.8 GB/s.
During the operation, the host experienced a noticeable increase in CPU utilization and disk activity, indicating that Windows processed the data movement through the host I/O stack rather than offloading it to the storage system. This behavior highlights the additional host overhead that is associated with traditional copy mechanisms when ODX is not in use.
Copy test with ODX enabled
With ODX enabled, the backup file is copied from the X: to the Y: volume using the same multithreaded robocopy operation.
C:\ > Set-ItemProperty -Path 'hklm:\system\currentcontrolset\control\filesystem' -Name 'FilterSupportedFeaturesMode' 0
Robocopy /MIR /MT X:\ Y:\
------------------------------------------------------------------------------
100% New File 676.5 g X:\oltp_backup
------------------------------------------------------------------------------
Total Copied Skipped Mismatch FAILED Extras
Dirs : 4 3 4 0 0 0
Files : 2 1 1 0 0 0
Bytes : 676.530 g 676.530 g 129 0 0 0
Times : 0:00:16 0:00:04 0:00:00 0:00:04
Speed : 181,287,494,149 Bytes/sec.
Speed : 10,373,354.000 MegaBytes/min.
With ODX enabled, the same 700 GB file copy completed in approximately four seconds, with a transfer rate of 181 GB/s.
During the copy operation, CPU utilization remained low and disk activity was minimal, indicating that Windows did not perform the copy through host‑based read and write operations, but instead relied on the underlying storage system to handle the data movement, as shown in the preceding figure.
This example highlights the practical value of the ODX feature for managing multiple databases restore requests. With ODX enabled, DBAs can efficiently copy cold database backups, such as physical data and log files, from a source backup volume to multiple target SQL Server volumes without incurring host‑based copy overhead. After the copy operation completes, the databases can be quickly attached to the appropriate SQL Server instances, avoiding the need for time‑consuming restore operations.