SQL Server can be configured as an Always On Failover Cluster Instance, an Always On Availability Group, or Standalone. While ActiveDR can be implemented with many SQL Server configurations, the two most common use cases are replicating the entire VM and replicating just the user data. Stretching a SQL Always On Availability Group and using ActiveDR is not supported since you would be replicating the data at both the storage and application layers simultaneously. Replicating a VM is more complicated, since the networking configuration is stored inside the VM. If the network is not stretched, user orchestration is required to change the networking subnet or VLAN. This can be as simple as a script, or more complex if the network must be changed before the application starts. In most cases, an Always On Availability Group will be better served by using replication at the SQL layer, rather than at the storage layer. Adding a node to the cluster at the DR site, then an asynchronous copy of the database on that node, is the simplest configuration.
The user data means non-system database and transaction log files. This is similar to . Once you have a snapshot of Pure Volumes that contain databases and transaction logs, you can copy them to new volumes, or overwrite existing volumes. ActiveDR is similar. When you promote a demoted copy, replication finishes, or in the event that the original promoted side is unavailable, the most recent point in time, crash-consistent version of the volume will become writable at the DR site.
Standalone & Always On Failover Cluster Instance
Make sure that all of the non-system databases are placed on volumes that are in the same Pod. Volumes which contain system databases and TempDB should not be placed in the Pod.
Always On Availability Group
An Availability Group is a special case since it can have many synchronous and asynchronous copies of the databases in the Availability Group on nodes throughout the cluster. It is more common to stretch the Availability Group to a SQL Server in the DR site, using an asynchronous copy of the Availability Group. Should your use case require the storage to handle the replication it is more efficient to place only one copy of the databases of the Availability Group in a Pod to be replicated and the SQL instance in the DR site cannot be part of the production SQL Availability Group cluster.