Using ActiveDR with SQL Server

Configuring ActiveDR

The following steps must be completed using the Everpure user interface to initiate ActiveDR replication. Configuring ActiveDR for SQL Server involves the following general steps:

Create volumes at the primary site to store SQL Server user database files.
Configure SQL Server to store user database files on FlashArray volumes at the primary site. Generally, database files, log files, and TempDB files are stored on separate volumes.
Move the primary site's SQL Server user database volumes into a pod. The TempDB volume should not be moved into a pod, as it does not need to be replicated.
Create an ActiveDR replica link from the source pod to the target replication array

Configure the ActiveDR Primary Site Pod in the Everpure User Interface

To configure the primary site pod:

From the primary site's Everpure user interface, select Storage in the navigation pane, and then select the Pods tab

FIGURE 7 | The Pods tab in the Everpure user interface
Click the + icon in the Pods group to create a new pod.
In the Name field in the Create Pod dialog box, enter a name for the pod, and then click Create. The pod appears in the Pods group.
In the Pods group, select the name of the pod that was created to display the Pod management view.
In the Volumes group, click the ellipsis, and then click Move In to display the Move Volumes In dialog box.
FIGURE 8 | The Pods tab in the Everpure user interface.
Select the SQL Server database file volume and log file volume that will be moved into the pod, and then click Move. The volumes appear in the Volumes group using the naming convention, <pod name>::<volume name>.
FIGURE 9 | Displaying the volumes in a pod.

The primary site pod is now configured with the database file and log file volumes. The next step is to create a replica link to the remote site's FlashArray, which enables ActiveDR replication.

Create a Replica Link in the Everpure User Interface

From the remote site's Everpure user interface, select Protection in the navigation pane.
In the Array Connections group, click the ellipsis, and then select Get Connection Key.

FIGURE 10 | Getting a connection key on the Array tab
In the Connection Key dialog, click Copy to copy the connection key to the clipboard.
From the primary site's Everpure user interface, click Protection.
In the Array Connections group, click the ellipsis, and then select Connect Array.
In the Connect Array dialog box, enter or select the following information:
- Management Address: The IP address of the remote site's FlashArray.
- Type: Select Async Replication from the drop-down list.
- Connection Key: Paste the connection key that you copied from the remote site's Everpure user interface.
- Replication Transport: Select the transport option from the drop-down list.
- Encrypted: Select the button to toggle replication encryption on or off.
Click Connect. The secondary site array appears in the Array Connections group.
FIGURE 11 | Displaying the secondary site in the Array Connections group.
In the Pod Replica Links group, click the ellipsis, and then select Create.
FIGURE 12 | Creating a replica link.
In the Create Replica Link dialog box, select the remote site FlashArray from the Remote Array drop-down list, and then select a remote pod

Note: If a pod hasn't been created on the remote site's FlashArray, click Create Remote Pod, enter a pod name in the Name field, and then click OK.
Select Create.

Once a replica link has been created from the primary site's pod to the secondary site's pod, the primary site's pod begins a baseline replication of the volumes to the secondary site's pod. During a baseline replication operation, the primary site FlashArray replicates a full copy of the volumes to the secondary site, which depending on the size of the data, can take time. The status of the baselining progress can be monitored in the Status field in the Pod Replica Links group. When the baseline replication completes, the Status field changes from "baselining" to "replicating."

FIGURE 13 | Monitoring pod replica link statuses on the primary site's FlashArray.

In addition to monitoring the pod replica link status at the primary site, the replica link status can also be monitored in the secondary site's Everpure user interface in the Pod Replica Links group.

FIGURE 14 | Monitoring the pod replica link status on the secondary site's FlashArray

Non-Disruptive Failover Testing

Non-disruptive failover with ActiveDR allows any disaster recovery/target site to bring a pod online without interrupting the production/primary pod. During a non-disruptive test, the databases in the primary pod remain online and continue to handle transactions seamlessly. This ensures uninterrupted production operations while enabling failover testing and allowing the target database to be used for testing and development purposes.

When using this process, the primary site will still queue changes, which will be applied to the target site once the process is undone automatically, with no manual intervention required.

To perform a non-disruptive failover, the state of the environment must be as follows:

There is a functioning database residing on one or more volumes in a promoted ActiveDR pod.
There is a demoted remote pod on a separate array in the same active pod replica link.
The volumes in the demoted pod are connected to, and have been discovered by, a host with a running SQL Server instance.
The demoted volumes are offline

A non-disruptive failover consists of the following steps:

Promote the ActiveDR pod on the target array.
Set the disks to online and, if required, provide a drive letter or mount to a folder.
Attach the database to the SQL Server instance

A failback after a non-disruptive failover only requires that the pod be demoted on the target system. Replication will automatically resume from the source pod to the target.

To complete the non-disruptive failover and failback between two arrays and different SQL Server host systems:

In the Storage section on the production/primary array, click the Pods tab, and then observe the state of the Pod Replica Links in a specific pod's details, which will show as promoted.
FIGURE 15 | Displaying the state of the production/primary array pod.
In the Storage section on the target/disaster recovery array, click the Pods tab, and then observe the state of the Pod Replica Links, which will show as demoted.
FIGURE 16 | Displaying the state of the target/disaster recovery array pod.
On the target array, attach the pod's volumes to a specific host. This can be done on the Hosts tab for a specific host.
FIGURE 17 | Attaching the pod's volumes to a host
When ready to perform the failover, navigate to the specific pod in Pods under Storage on the target/disaster recovery array, click the ellipsis, and then select Promote.
FIGURE 18 | Promoting the target/disaster recovery array pod.
When the pod has been promoted, it will have a promotion status of promoted.
FIGURE 19 | The promoted pod on the target/disaster recovery array.
The disks can be set online in Windows Disk Manager.
FIGURE 20 | Bringing the disks online in Windows Disk Manager.
Once all of the disks are online, they might require drive letters or mount points to be assigned. In the example shown here, the drive letters have persisted between hosts after failover. In the event that the disks come online in a read-only state, set them to read/write prior to the next step.
FIGURE 21 | Volumes attached as drives on the target/disaster recovery SQL Server host.
The database can be attached to the instance by executing the CREATE DATABASE T-SQL command with the FOR ATTACH property and the appropriate paths to each data file.
```
CREATE DATABASE [UserDB] ON
( FILENAME = 'E:\SQL\UserDB.mdf' ),
( FILENAME = 'F:\SQL\UserDB_log.ldf' )
 FOR ATTACH
```
The failed-over user database is now available for use. Any data changes made in the database will not be replicated back to the primary pod.

Failback from a Planned Non-disruptive Failover

To rollback from a non-disruptive failover, navigate to the ActiveDR pod on the target/disaster recovery array, and then select Demote Local Pod. This will apply all changes from the production/primary instance and then set the pod as read-only.
FIGURE 22 | Demoting the local pod.
When selecting Demote Local Pod, a prompt to confirm demotion appears. Select Demote when ready
FIGURE 23 | Confirming the pod demotion.
Once the pod has been demoted, it will show as demoted in the Pod Replica Links pane.
FIGURE 24 | Displaying the pod status.

Attach the Database to the Remote Site's SQL Server Instance Using SQL Server Management Studio

In SQL Server Management Studio, connect to the remote site's SQL Server instance.
Right-click the Databases object, and then select Attach.
Select Add, and then navigate to the drive and folder that contain the database MDF file.
Select all database data and log files, and then select OK.
Select Add, and then navigate to the drive and folder that contain the log files.
Select the database LDF file, and then select OK.
Select OK to attach and bring the database online.

The remote site's SQL Server instance is now able to service application requests. Verify connectivity to the database at the remote site and that applications that use the database perform as expected. Once connectivity to the database has been verified and applications perform as expected, a failback can be performed.

Performing a Full Failover for Disaster Recovery Testing Only

This section is intended for situations where a full manual failover needs to be executed. Once ActiveDR is configured, replicated data can be used at the remote site by performing a manual failover. Note that a manual failover requires SQL Server downtime, and without careful planning and coordination, it can result in business disruption. For testing a failover, see the Non-disruptive Failover Testing section of this document.

A planned failover consists of the following general steps:

Take the primary site's SQL Server database offline.
Demote the primary site's pod.
Allow for data replication to complete.
Promote the secondary site's pod.
Bring the secondary site's database online in SQL Server at the secondary site

The Everpure user interface and various SQL Server and Windows Server tools can be used to accomplish these steps.

Take the SQL Server Database Offline in SQL Server Management Studio

In SQL Server Management Studio, connect to the SQL Server instance whose data is being replicated to the secondary site.
In Object Explorer, navigate to the database that will be taken offline.
Right-click the database, select Tasks, and then select Take Offline.
FIGURE 25 | Taking the database offline.
In the Take Database Offline dialog, verify that the database that is to be taken offline is highlighted, and then click OK. The database is taken offline.
Note: You can also use the following SQL statement in SQL Server Management Studio to take the database offline:
```
ALTER DATABASE [Database Name] OFFLINE;
```
Once the SQL Server database is taken offline, the primary site's pod can be demoted.

Demote the Pod at the Primary Site in the Everpure User Interface

Verify that the SQL Server database is offline in SQL Server Management Studio.
From the primary site's Everpure user interface, select Storage in the navigation pane, and then select the Pods tab.
Navigate to the primary site's pod, click the ellipsis, and then select Demote.
FIGURE 26 | Demoting the primary site's pod.
From the Demote dialog, select Quiesce, and then click Demote. The primary site's pod is demoted and put in a read-only state
FIGURE 27 | Confirming the pod's demotion.

Promote the Pod at the Secondary Site in the Everpure User Interface

Navigate to the secondary site's Everpure user interface, select Storage in the navigation pane, and then select the Pods tab.
Navigate to the secondary site's pod, click the ellipsis, and then select Promote.
FIGURE 28 | Promoting the secondary site's pod.
From the Promote dialog, select Promote. The secondary site's pod is promoted and put into a read/write state.
FIGURE 29 | Confirming the pod's promotion.

With the secondary site's pod promoted and in a read/write state, the volumes can be attached to the remote site's Windows Server instance.

Note: The remote site's Windows Server instance should already be attached to the target Windows instance and offline.

Bring the Disks Online Using the Windows Server Disk Management Application

From the remote site's Everpure user interface, select Storage in the navigation pane, and then select the Hosts tab.
Verify that the remote site's Windows Server environment where SQL Server is installed appears in the Hosts group.
FIGURE 30 | Verifying the SQL Server host.
On the remote site's Windows Server instance where SQL Server is installed, open the Disk Management application. The database file and log file Everpure volumes appear as offline disks.
Right-click each offline disk, and then select Online.
FIGURE 31 | Bringing the disks online in Windows Disk Manager
If the disk does not have a drive letter assigned, right-click the disk, and then select Change Drive Letter and Paths.
Assign the same drive letter as was used before the failover.
FIGURE 32 | Volumes attached as drives on the SQL Server host.
If the disks come online in a read-only state, right-click each disk, and then set them to read/write.

Attach the Database to the Remote Site's SQL Server Instance Using SQL Server Management Studio

In SQL Server Management Studio, connect to the remote site's SQL Server instance.
Right-click the Databases object, and then select Attach.
Select Add, and then navigate to the drive and folder that contain the database MDF file.
Select all database data and log files, and then select OK.
Select Add, and then navigate to the drive and folder that contain the log files.
Select the database LDF file, and then select OK.
Select OK to attach and bring the database online.

The remote site's SQL Server instance is now able to service application requests. Verify connectivity to the database at the remote site and that applications that use the database perform as expected. Once connectivity to the database has been verified and applications perform as expected, a failback can be performed.