A major benefit of using an ActiveCluster stretched storage solution is simplicity. This section walks you through aspects of configuring and managing ActiveCluster to harness that simplicity for your SQL Server workloads.
Before setting up ActiveCluster with SQL Server Failover Cluster Instances, it's important to review the FlashArray user guide, in addition to ActiveCluster, SQL Server, and Windows Server best practices documentation:
Pre-workflow
Before beginning, define the storage to be used for ActiveCluster. Figure 1 showcases the volumes in the FlashArray graphical user interface.
For Windows systems, in Disk Management, check your selected volumes are listed as available and healthy.
For the SQL Server UserDB volume, check the health of the database health and that the data file locations are as expected.
Creating a Synchronous Connection
To set up ActiveCluster, start by creating a synchronous connection with another FlashArray. It's worth mentioning that you can use either of the FlashArray systems intended for ActiveCluster to connect to the other—both work equally well for the task.
To start this process, navigate to the Array tab in the Protection view of the graphical user interface, as shown in Figure 4.
For ActiveCluster to work, a Fibre Channel or TCP/IP connection must exist between the two FlashArray systems involved in replication. To establish this connection, obtain the connection key from the other FlashArray by using the graphical user interface.
To retrieve the connection key, click the vertical ellipsis in the right-hand corner of Array Connections, and then select Get Connection Key.
The Connection Key dialog will display. Copy the key, and then return to the source array.
On the corresponding FlashArray, utilize the connection key and the management IP address of the target array to establish a synchronization replication relationship. The provided example uses Ethernet as the replication transport, but it is equally feasible to employ Fibre Channel if preferred.
To connect the arrays, navigate to the Arrays tab within the Protection view, identify the Array Connections section, and then click the + to add a new array connection (as shown in Figure 7).
In the Connect Array dialog, enter the Management Address and Connection Key of the target array, and then select Sync Replication as the Type, adjusting any other parameters as required. Click Connect when complete.
To confirm that the arrays are successfully connected, review each array's status in the Array Connections pane.
Managing a Pod
ActiveCluster replicates storage objects like volumes, snapshots, and schedules within consistency groups, referred to as pods. Each array can accommodate multiple pods, with each pod acting as an independent namespace for the objects it houses. An array administrator has the capability to stretch (replicate) a pod across two arrays, enhancing data redundancy and availability. An entire pod is synchronously replicated, ensuring everything in it stays consistent. If replication is interrupted, the first array to contact the mediator takes control of the entire pod.
All volumes that pertain to a single user database need to be in the same pod; it is also recommended to put related volumes in the same pod. This is useful for volumes with similar needs or when you want them to be consistent. It also makes administration easier. For volumes with different requirements, use separate pods to keep things organized.
If pre-existing database volumes are present, create the pod on the array to which it is localized.
The following steps showcase how to create a pod.
-
From the primary site's Everpure user interface, select Storage in the navigation pane, and then select the Pods tab. Click the + icon in the Pods group to create a new pod.
Figure 10. The Pods tab in the Storage view -
In the Name field in the Create Pod dialog box, enter a name for the pod, and then click Create. The new pod will appear in the list.
Figure 11. The Create Pod dialog
Before stretching a pod (enabling synchronous replication to another array), it's possible to move existing volumes into it. The following steps showcase how to add volumes to an existing pod.
-
Select the pod created in Figure 12 from the list of pods.
Figure 12. The Pods list -
In the pod details view, click the ellipsis in the Volumes pane, and then select Move In to move existing volumes into the pod.
Figure 13. The Volumes pane in the Pods console
-
Existing volumes can be moved into the pod if the pod is not in a stretched state. When a volume is moved into a pod, it is renamed by adding the pod name followed by two colons as a prefix to its original name. This naming convention helps maintain clarity and organization within the pod.
Figure 14. The existing pod with no volumes in the Move Volumes In dialog -
Select the SQL Server database volumes to add to the existing pod, and then click Move.
Figure 15. The existing pod with volumes selected in it in the Move Volumes In dialog
-
To create a new volume in a pod (whether stretched or unstretched), open the Pods screen, and then click the + symbol in the Volumes pane to create a new volume.
Figure 16. View of all pods
Expanding a pod initiates the replication of volumes added to that pod and conducts the initial baseline copy of these volumes from the source to the target array. Once this baseline process is finished, the pod achieves high availability on both arrays, ensuring data redundancy and accessibility. To stretch a pod, follow these steps:
-
Navigate to the ActiveCluster tab in the Protection view in the FlashArray graphical user interface. From the ActiveCluster Pods section, click the + to stretch an existing pod.
Figure 17. ActiveCluster pod -
To stretch a pod, enter the Local Pod name and Remote Array name in the Stretch Pod dialog box, and then click Stretch.
Figure 18. The Stretch Pod dialog with Local Pod name and Remote Array name enteredNote: While both stretched pods and protection groups are used to manage and replicate groups of storage objects, there are key differences. Protection groups are typically associated with asynchronous replication and are used to manage the recovery of groups of volumes, ensuring data consistency during disaster recovery scenarios. On the other hand, stretched pods in ActiveCluster are designed specifically for synchronous replication, ensuring that all objects in the pod remain perfectly in sync across arrays. This ensures that any failover event maintains data availability and consistency with no data loss, making stretched pods ideal for active-active, high-availability configurations.
When stretching a pod, a baseline is performed where data is replicated to the target array.
Once this baseline is complete, the status of the target array will change from resyncing to online.
-
Using the pod status view, check the status details of the arrays for a pod.
Figure 19. View of the status of a single pod with the target array resyncing -
When the pod shows that both arrays have the online status, they are available and protected by both arrays.
Figure 20. View of a single pod with ActiveCluster array status online
Configuring Windows Server Hosts
FlashArray provides support for both iSCSI and Fibre Channel host connections, and these options are fully compatible with ActiveCluster. To facilitate storage provisioning to a host, an array administrator is required to create a corresponding host object. Additionally, administrators have the flexibility to group hosts with shared storage provisioning needs, such as SQL Server hosts, into host groups. This management feature streamlines storage management and allocation.
-
Create site A hosts on a FlashArray.
-
Present FlashArray storage volumes to each site A host.
-
Create a site A host group.
-
Associate all site A hosts to the newly created host group.
-
Connect site A FlashArray storage volumes.
Figure 22. View of SQL Server database volumes on a single site (A) -
In Windows Server, ensure storage array volumes are connected at each node located at site A.
-
Online FlashArray storage volumes only at the site A primary node where SQL Server will be active.
-
Ensure that the non-primary node volumes are not online (Figure 23).
Figure 23. The Windows Server Disk Management consoleNote: Online volumes only at the site A primary active node. On site A, only the primary active node initializes, formats, and assigns drive letters and labels to the storage volumes listed in the preceding steps. -
Stretch the site A FlashArray storage to the site B FlashArray storage.
Note: Hosts cannot be connected to the volumes on the secondary array until the stretch is complete and the pod is online at both the primary and the secondary arrays. -
Verify that pod status is listed as online and the baseline stretch is completed.
-
Create site B hosts on a FlashArray.
-
Present FlashArray storage volumes to each site B host.
-
Create the site B host group.
-
Associate all site B hosts to the newly created host group.
-
Connect the site B FlashArray storage volumes.
-
In Windows Server, ensure the storage array volumes are connected at each node located at site B.
-
Create a site B host group located on the site A FlashArray.
-
Associate site B hosts to the new host group created at the site A FlashArray.
-
Connect SQL Server cluster FlashArray volumes according to the host group created at the site A FlashArray.
Figure 24. View of all SQL Server database volumes at the second site (B)
The default behavior is that all paths from a FlashArray to a host will be actively used by the SQL Server primary active node— even ones from the secondary FlashArray.
FlashArray offers an option to intelligently tell the SQL Server primary active node which FlashArray should optimally service input/output in the event the SQL Server primary active node can see paths to both FlashArray systems for a given device. This is a FlashArray host object setting called "Preferred Arrays."
In a situation where the FlashArray systems are in geographically different data centers, it is important to set the preferred array for a host on both FlashArray systems. For each host, log in to the FlashArray web interface for the array that is local to that host. Once logged in, select t he Storage console and Hosts tab, and then choose the host to be configured. In the Details submenu, click the vertical ellipsis, and then select the Add Preferred Arrays option.
Half of the writes (assuming both FlashArray systems offer an equal number of paths for each device) sent from a host in site A will be sent to the FlashArray in site B. Using preferred arrays mitigates unnecessary latency by ensuring hosts prioritize writing to the local FlashArray. Without preferred arrays, writes from a host in site A may be sent directly to the remote FlashArray in site B. Since writes must be acknowledged at both sites, this can cause data to traverse the wide-area network twice—first from the host to the remote FlashArray and then back to the local FlashArray—introducing significant latency. Preferred arrays ensure writes are sent to the local FlashArray first, which then forwards them to the remote FlashArray, reducing traversal to a single pass and optimizing performance.
Half of the reads (assuming both FlashArrays offer an equal number of paths for each device) sent from a host in site A will be sent to the FlashArray in site B. However, under normal circumstances, all reads can be serviced locally by either array without traversing the wide-area network. This extra, unnecessary read traffic simply uses up network bandwidth.
Best practice: For every host that has access to both FlashArray systems hosting an ActiveCluster volume, set the preferred FlashArray for the host on both FlashArray systems. Ensure on FlashArray A that it is preferred for host A and ensure on FlashArray B that FlashArray A is preferred for host A. Doing this on both FlashArray systems allows a host to automatically know which paths are optimized and which are not.
To simplify the provisioning of storage for a cluster, host objects that correspond to the cluster's nodes can be grouped together on a host, known as a host group. This approach simplifies the management of storage resources for the entire cluster, enhancing efficiency and organization.
The Critical Importance of Proper Multipath I/O (MPIO) Configuration at the Host Level
In an ActiveCluster environment, Multipath I/O (MPIO) is essential for ensuring high availability and optimal performance of SQL Server instances. MPIO allows the host to maintain multiple redundant paths to both arrays, enabling continuous access to storage even if one or more paths fail.
MPIO matters for three principal reasons:
-
Redundancy: MPIO provides fault tolerance by ensuring that if one network path fails (due to a network issue, hardware failure, or site failure), the SQL Server instance can continue accessing the storage volumes using alternate paths. Without MPIO configured correctly, a single path failure could lead to a complete loss of storage connectivity.
-
Load balancing: Properly configured MPIO can balance input/output traffic across multiple paths, ensuring that SQL Server efficiently uses available bandwidth. This minimizes latency and optimizes throughput, particularly in high-demand environments.
-
Seamless failover: During failover scenarios, such as when switching to the secondary array in ActiveCluster, MPIO ensures that SQL Server can seamlessly transition its input/output operations to the available paths without interruption. Ensuring that MPIO is correctly configured across both arrays and hosts is critical to maintaining seamless operations.
The key considerations for MPIO configuration include:
-
Driver installation: Ensure that the appropriate MPIO drivers are installed on all SQL Server hosts and that they are compatible with your storage arrays.
-
Path validation: Regularly test and validate all paths to the storage arrays to ensure that each path is functional and that there are no misconfigurations.
-
Load balancing policies: Implement optimal load balancing policies (such as round robin or least queue depth) based on the environment to maximize performance.
-
Regular monitoring: Continuously monitor the status of MPIO paths to ensure there are no issues, such as pat h failures or imbalanced traffic, that could degrade performance.