FlashArray ActiveCluster for Microsoft SQL Server Technology Overview

SQL Server environments rely on high-availability solutions to minimize downtime and ensure continuous access to critical data. Two primary SQL Server configurations for high availability are SQL Server Failover Cluster Instances and Always On Availability Groups, each providing unique benefits for maintaining SQL Server accessibility.

SQL Server Failover Cluster Instances use the Windows Server Failover Cluster service to provide instance-level redundancy and automatic failover within a cluster. In a SQL Server Failover Cluster Instance setup, SQL Server instances are configured with a shared storage model that connects multiple nodes, allowing operations to transfer automatically to a standby node if the primary node encounters an issue. This model reduces downtime and ensures SQL Server databases remain accessible during node failures.

ActiveCluster adds a powerful layer of storage-level high availability by addressing the singular fault domain inherent in the shared storage model used by SQL Server Failover Cluster Instances. By introducing a second FlashArray with synchronous replication, ActiveCluster enables identical copies of SQL Server database volumes to exist on separate arrays, thus mitigating the risks associated with a single storage fault domain. Storage-level redundancy and synchronous data replication with ActiveCluster ensure data consistency and seamless failover across FlashArray instances without data loss or disruption to SQL Server operations. This approach minimizes both planned and unplanned downtime, providing a robust solution for mission-critical SQL Server workloads.

Before implementing SQL Server Failover Cluster Instances with Windows Server Failover Cluster, review the following setup and installation documentation:

With ActiveCluster, data is synchronously replicated across FlashArray instances, maintaining data consistency across sites and providing an additional layer of availability for SQL Server. This configuration allows for seamless failover and recovery in the event of a failure, ensuring business continuity without data loss. By integrating at the storage layer, ActiveCluster not only enhances redundancy but also simplifies storage management for SQL Server Failover Cluster Instances, making it ideal for reducing downtime and maintaining high availability in SQL Server environments.

Always On Availability Groups provide database-level high availability and disaster recovery by maintaining replicas of user databases across multiple servers. Unlike SQL Server Failover Cluster Instances, Always On Availability Groups allow SQL Server instances in an Availability Group to be active on different replicas simultaneously, enhancing read scalability and ensuring continuous availability. However, only one replica (the primary) can be configured as read/write; additional replicas remain read-only.

An Always On Failover Cluster Instance follows a shared-storage model, where the SQL Server instance is installed on multiple hosts, but it runs on only one host at a time (in an active/passive configuration). The SQL Server instance is hosted on a primary active host, while the other hosts in the cluster remain passive. If the primary active host experiences a failure or goes offline, the Windows Server Failover Cluster service initiates a failover process, promoting one of the passive hosts to the primary active role. SQL Server then resumes operations on the newly promoted host, ensuring minimal downtime and high availability. To further enhance high availability, ActiveCluster introduces transparent failover, ensuring automatic, seamless recovery.

ActiveCluster is an advanced solution for data replication, offering a fully symmetrical, bidirectional replication capability that ensures zero recovery point objectives and zero recovery time objectives. It achieves this by replicating data synchronously and enabling automatic, seamless failover. Its design enables clustered arrays and hosts to operate in a flexible, active-active configuration within a data center setup, maintaining high availability and reliability across connected sites.

Figure 2. Pure1 and ActiveCluster architecture: Pure1 mediates between clustered FlashArray systems to provide high availability for SQL Server.

ActiveCluster stands on three pillars: Pure1 Cloud Mediator, paired active-active clustered arrays, and pods (stretched storage containers).

Figure 3. ActiveCluster components

Pure1 Cloud Mediator ensures seamless communication, while the paired arrays provide the infrastructure for bidirectional data access:

A mediator is a critical component for managing and coordinating data replication and failover between two FlashArray systems in an active-active configuration. ActiveCluster ensures synchronous replication across FlashArray systems. Pure1 Cloud Mediator ensures that if communication is lost between arrays, only one array remains active for each pod, preventing conflicts.

If the arrays lose connectivity, both temporarily halt input/output and contact the mediator. The array that reaches the mediator first continues serving its pods, while the other stops input/output to prevent a "split-brain" scenario. This process occurs within standard host input/output timeouts, ensuring applications experience only a brief pause before resuming operations, minimizing disruptions to SQL Server databases.

Failover mediation for ActiveCluster can also be facilitated by deploying an on-premises mediator, which is distributed as an Open Virtualization Format file and can be set up as a virtual machine. The failover procedures remain consistent with those previously described, regardless of whether Pure1 Cloud Mediator or an on-premises mediator is employed. More information can be found in the on-premises mediator documentation.

An on-premises mediator must adhere to certain fundamental requirements:

An array can accommodate multiple pods, and those pods can exist on a single array or span across two arrays concurrently, maintaining synchronous replication. When pods are synchronously replicated between two arrays, they are referred to as being "stretched between arrays." This innovative feature enhances the flexibility and management capabilities of ActiveCluster.

Figure 4. ActiveCluster pods

With ActiveCluster, failover is transparent, automatic, and requires no manual intervention from administrators. This ensures high availability and prevents data mismatches between arrays serving the same volume.

To maintain availability across two sites, a component called a witness (also known as a voter) is needed to manage failovers and prevent data mismatches. ActiveCluster uses Pure1 Cloud Mediator (or an on-premises failover mediator) for this purpose, making failover and site changes seamless and automatic in the event of issues, without the need for manual actions. In addition to transparent failover, ActiveCluster offers flexible deployment options for host access to optimize performance.

In ActiveCluster, hosts can be configured in two ways: uniform host access, where hosts can access both arrays, regardless of their physical locations, and non-uniform host access, where hosts interact solely with the local storage array.

A standardized storage access model is applicable wit hin environments featuring host-to-array connectivity via either Fibre Channel or Ethernet (for iSCSI), along with array-to-array Ethernet or Fibre Channel interconnectivity across two separate sites. In this deployment scenario, each host possesses access t o identical volumes through both the local and remote arrays. This solution is adept at syncing the connection of arrays even when the round-trip time latency between them reaches up to 11 milliseconds, ensuring seamless and consistent data access and management.

Figure 5. ActiveCluster uniform host access

Figure 6 provides a representation of the logical pathways connecting hosts and arrays, including the replication link connecting the two arrays, within the context of a uniform access model. In a uniform storage access model, where all hosts, regardless of their site locations, can access both arrays, it's important to note that different latency characteristics will be observed. Specifically, paths from hosts to the local array will exhibit lower latency, while paths from each local host to the remote array will demonstrate higher latency due to the geographical separation between sites. This diverse latency profile should be considered when optimizing data access and ensuring efficient data management across the environment.

For instance, if a database called "SQL Server B" writes to stretched volume A through Array A, the process might take longer compared to writing through Array B. This is because the data-write from SQL Server B has to travel the longer path between the host and Array A and then cross the replication path between Arrays A and B. It's important to be aware of these latency differences when deciding how to route data for better performance.

ActiveCluster uses a feature called SCSI Asymmetric Logical Unit Access to encourage hosts to use local paths when accessing FlashArray volumes. Array administrators can select a preferred array for a host-volume connection, making it the best choice for local hosts. Remote paths are available but might not be as fast. While both local and remote paths can be used for reading and writing, hosts prefer the fast local paths and only use the slower remote paths when there are no fast ones available. This helps data access stay quick and efficient.

For example, consider Array A as local to Host A. Setting the preferred array to Array A is important when there is a big difference in latency between a host and its local array compared to the remote array. In cases where data center or small campus setups have similar latencies for host-array communication, utilizing all paths can enhance overall performance.

ActiveCluster non-uniform host access is a deployment model where hosts connect to only one of the two FlashArray systems in an ActiveCluster setup, rather than both. Data remains synchronously replicated between arrays, but each host accesses just one array at a time. If one FlashArray becomes unavailable, hosts connected to it will need to reconnect or switch to the secondary array through either manual intervention or automated processes. This model reduces complexity and cabling, providing high availability and zero recovery point objectives without requiring direct host connections to both arrays, though it might require additional steps for failover.

Understanding the performance requirements and flow of data within ActiveCluster is crucial for optimizing SQL Server workloads. Synchronous replication with ActiveCluster ensures zero recovery point objectives by mirroring writes across FlashArray instances, providing robust data consistency and immediate failover capabilities. However, this mirrored write process can have an impact on SQL Server workload performance, especially in latency-sensitive environments.

In ActiveCluster, each write from the SQL Server host is mirrored to both FlashArray systems, ensuring identical data is maintained across arrays. This process, known as "mirrored writes," involves writing data to the primary FlashArray and immediately replicating it to the secondary array before acknowledging the write back to the host. While this approach maintains high data consistency, it also means that replication latency can impact SQL Server response times. Monitoring and managing network latency between arrays is therefore essential, as elevated latency can slow SQL Server transactions that rely on synchronous acknowledgment from both arrays.

To maximize replication performance, keep the latency between the two FlashArray systems as low as possible, ideally below five milliseconds, and not to exceed 11 milliseconds. This requires a robust network infrastructure and consistent monitoring of latency and bandwidth to ensure reliable and high-speed data transfer. Ensuring that sufficient bandwidth is available for peak workloads can prevent potential bottlenecks and performance degradation in ActiveCluster.

ActiveCluster offers built-in monitoring tools that help track replication status and performance. Regularly checking metrics such as replication lag, write latency, and array health is key to identifying potential issues before they affect SQL Server workloads. The Pure1 management platform provides a centralized view of these metrics, allowing administrators to proactively manage the replication environment and maintain optimal performance.

In an ActiveCluster environment, the flow of a write operation proceeds as follows:

Figure 6. Overview of the life of an input/output operation with ActiveCluster

This data flow ensures that every write is mirrored in real-time across both arrays, supporting the ActiveCluster promise of zero recovery point objectives and enabling fast, seamless failover when necessary.

VMware environments support two key storage technologies, both of which integrate seamlessly with ActiveCluster and offer distinct benefits for managing SQL Server virtual machines:

Integrating VMware environments with ActiveCluster for SQL Server can provide the following benefits:

For detailed steps for configuring ActiveCluster for VMware solutions, see the ActiveCluster with VMware user guide.