Skip to main content
Pure Technical Services

SRM User Guide: Stretched Storage (ActiveCluster) SRM Workflows

Currently viewing public documentation. Please login to access the full scope of documentation.

 

Overview of Stretched Storage in SRM

VMware Site Recovery Manager supports two main modes of array-based replication:

  • Active/Passive: SRM coordinates with underlying array-based replication to create a copies of datastores or RDMs on the remote site. VMs are shut down and restarted on the target site. The Recovery Point Objective is not guaranteed to be zero. SRM attempts to synchronize any changes during a failover, but in the case of a site loss of the source it may not be possible. Recovery Time Objective is always non-zero, and the length depends on how much data needs to be synchronized and how large of a recovery occurs.
  • Active/Active: SRM coordinates migrating VMs between vCenter environment. This implementation requires synchronous replication (all data is always in both sites) as well as active-active replication (the data is available in both sites at the same time). SRM will attempt to vMotion VMs to the remote vCenter if possible and if not will restart them on the second site otherwise. Recovery Point Objective is always zero, and Recovery Time Objective may be zero (generally in a migration or disaster avoidance scenario) or non-zero in certain disaster recovery events.

For Pure Storage, this means the use of ActiveCluster. ActiveCluster is enabled when a volume is placed in a pod and that pod is stretched to a second array. Any volume in a stretched pod is now both synchronously replicated and available in an active/active state (both FlashArrays can simultaneously service reads and writes for those volumes).

The 3.1 release of the Pure Storage SRA also supports recovery from a stretched pod to a third FlashArray. This does not leverage the stretched storage support in SRM as the recovery is an active/passive replication scenario. For details on that behavior see the following section:

Pod-based Periodic Replication SRM Workflow Behavior

Example Environment

For the purpose of this document, the following example environment will be used:

Two volumes in a stretched pod called srmPod:

clipboard_e501e0f4feeae4cc4302fa44a89518105.png

The pod is stretched over two physical arrays, flasharray-m50-1 and flasharray-m50-2. On each of these volumes is a VMFS datastore (it should be noted that RDM as not supported by SRM for usage with stretched storage), named srmDS-01-stretched and srmDS-02-stretched

clipboard_e730bd00bd349f80e9db6f7b3a31e923f.png

Both datastores are tagged so that the VMs hosted on them can be given a correct storage policy for protection in SRM. For stretched storage, only storage-policy-based discovery is supported, for details, refer to the section Configuring Site Recovery Manager Tag-Based Storage Policy Discovery.

clipboard_e0dddca1e5cd2001cd3d351d71b75e19b.png

The VMs have a tag-based policy applied that ensure they stay on these datastores:

clipboard_e8d4fd94a33e6649ec5ba0518513cf341.png

These two datastores then are in compliance with this policy:

clipboard_e072c7ec5ca63fe02b14f8c63e116578f.png

The datastores are presented to both vCenters:

clipboard_ee9ff92d60d489a5383ef6ffc6a306dd3.png

They are presented via paths to the FlashArray flasharray-m50-1 on vCenter-01 and through flasharray-m50-2 on vCenter-02.

The datastores (and storage policy called SRM-tag-m50_1-m50_2) is added to an SRM protection group called srmpg-01-stretched:

clipboard_e2b26dacb7810aff1d572157e4f846928.png

Therefore protecting all of the VMs on those datastores (and any ones that get added to that policy). 

clipboard_ec4ad55eb401060ea424b80faa7d1b9cd.png

Note that for each datastore there will be one consistency group reported. So if there are two datastores, there will be two consistency groups and so on. This is because the FlashArray SRA does not advertise consistency groups back up to SRM so SRM puts each datastore in its own group. This provides the greatest flexbility of failover when it comes to granularity, but this also means it is not supported to have any VM span more than one datastore. Each VM must be on only one datastore to be protected by SRM and stretched storage.

Lastly, the storage policy assigned to the VMs on vCenter-01 is called SRM-tag-m50_1-m50_2 which maps to SRM-tag-m50_2-m50_on vCenter-02 and that mapping is configured in SRM:

clipboard_eef328802951bdbb3d6ea9d47fcee428e.png When the VMs are recovered in vCenter-01 they will have the mapped policy applied.

Test Recovery

A test recovery is a slightly different concept with the SRM stretched storage feature, as the workflow from a migration/storage operation is not quite the same.

A recovery (more on this in a bit) is either:

  • Cross vCenter vMotion
  • Register and Power-on of VMs on target vCenter

In both cases there is no copy of the datastore--the VMs are recovered on the exact datastores they are on in the source vCenter. This of course makes it impossible to really test the entire work flow. Instead the SRM test recovery is focused on VM recovery order, reconfiguration, placement, connectivity, relationships, and of course any scripts/customizations you might have in the recovery plan.

If you plan on leverage the Cross vCenter vMotion feature, you should attempt this process manually with a VM configured like the protected VM (stretched volume) as described in the next section as well as the official SRM test recovery process.

Testing Cross vCenter vMotion

For specific requirements for this feature, refer to the following VMware KB.

Right-click on a test VM and choose Migrate:

clipboard_ee92bfee3388673b20b4e10638cb9a234.png

Choose "Change compute resource only" and click Next:

clipboard_e79c7528f6da8943929f62d7920c23ad9.png

Then choose a destination host or cluster:

clipboard_e1855ffdaed31508330fe36ec58c9edab.png

It is important to pay attention to the Compatibility box. If there is a prerequisite missing it will be listed there. If there are no errors or warning, click Next. If there are warnings, check the VMware KB linked above for requirements. Common reasons are no vMotion vmkernel port on the target hosts, incorrect network names, incompatible CPUs, or a VM resource that is not present in the target site.

Complete the wizard and verify a successful vMotion.

clipboard_e3a3da23be7e4b602bb2bfd8261485bb4.png

Lastly, verify the networking is correct for the target VM. Perform the vMotion in the opposite direction to confirm backwards compatibility. 

If the VM you tested is part of the SRM recover plan, it is important to remember to re-apply the storage policy to it when you vMotion it back. The vMotion process does not preserve the policies across vCenters.

clipboard_e8a275574df941d7cae6dd4626ca33dc9.png

 Testing the SRM Recovery Plan

To test the recovery plan, click Test on the plan in SRM:

clipboard_ea740becb4840b8d6b194ff588a6813f4.png

Unlike with active/passive storage the "Replicate recent changes to the recovery site" does not have any effect with stretched storage as the data is always in sync. Though if this recovery plan has SRM protection groups in it that do include datastores protected via asynchronous replication it is applicable. For a purely stretched recovery plan though, it does not need to be selected (though it does not harm being enabled).

clipboard_e8ecb15350cbd14a24daedc7b27f94235.png

The test recovery process will create a copy of all of the volumes in the recovery plan with a prefix of the pod name and a suffix of "-puresra-testFailover":

clipboard_e6dcfea649094f1751509231c3d43e0cf.png

The datastores will be mounted and resignatured with the prefix of "snap-XXXXXXXX-" in the name. This can be automatically in the SRM advanced settings discussed here Site Recovery Manager Advanced Options.

clipboard_ebbb4e80becbbbaa9786c307b26258175.png

Verify the recovery plan result:

clipboard_e021f4dbcc5bf1397f0ef38df4cd081dc.png

When done, click Cleanup in SRM:

clipboard_e2ed6b937e58e7653fc4276a8808972cf.png

The VMs and corresponding datastores will be removed and the volumes will be destroyed and eradicated on the FlashArray:

clipboard_e0927363b1abcb078467b9cc86111b20d.png

Recovery

A recovery operation will attempt a vMotion if applicable of the virtual machines in the stretched protection group/recovery plan.

To verify a VM is eligible for vMotion, click on the SRM protection group and then the Virtual Machines tab. The VM will have Yes in the vMotion Eligible column.

clipboard_ec325e33a4d571ea90cb707ab42504ba7.png

You can disable/override vMotion for a given VM in the recovery plan, click on the VM and choose Configure Recovery.

clipboard_eebe58d3e33d38dcc0c31ceb48bf40849.png

Deselect the Use vMotion for planned migration box if you prefer SRM not attempt to vMotion that VM.

clipboard_e4b58bfeef81b47569c91898ce5ae7bc0.png

To start a recovery, click Run:

clipboard_e3379c48da9a900004ca153ab51e0ca3c.png

When you initiate the recovery wizard, you have one more option to disable vMotion for all VMs in the plan if you choose. Default is to attempt it for all eligible VMs.

clipboard_e8f0d99a19c74e84df04682c909f26a07.png


If you choose to vMotion:

It is highly advisable to pre-connect the datastores on the target ESXi hosts prior to recovery or the recovery plan will hang until you connect and mount the datastores manually.

SRM will (if enabled) attempt to vMotion all applicable VMs. For all others, it will unregister them on the source vCenter, and then register and power them on within the target vCenter according to SRM resource mappings.

clipboard_e918db7fcef19a5af9597ed9ade59b912.png

If the datastores are not presented prior to recovery and vMotion is enabled, the recovery plan will hang on the step Prepare stretched storage for VM migration at the protected site waiting for the storage as it will not be able to vMotion the VMs.

clipboard_e111650553f01cc29e828b4adef15be10.png

You can manually connect the datastores during the recovery and rescan the hosts to allow the process to progress. The ideal option though is to connect them prior to recovery.

If you choose not to vMotion:

If you deselect vMotion during the recovery, or disable it for all VMs, or simply do not have an environment that supports cross-vCenter vMotion, you do not have to have to volumes preconnected to the target ESXi hosts. In this case the SRA will connect them for you automatically during the Configure recovery site storage step:

clipboard_e40109e537d108697dd3eed7292a1cd64.png

If the datastores are not present and vMotion is enabled, the recovery plan will hang on the step Prepare stretched storage for VM migration at the protected site waiting for the storage as it will not be able to vMotion the VMs.

clipboard_e111650553f01cc29e828b4adef15be10.png

The datastores are not automatically attached until a later step in the recovery plan. If the datastores are not connected (and you prefer to have the SRA connected them as needed), you must disable vMotion attempts for the respective VMs, or the entire recovery plan. To ensure that vMotion is not attempted for an entire plan, deselect the option when starting the recovery:

clipboard_ebb86923574057a56a1440b1b6ccb1f8b.png


Note that there is no operation on the FlashArray for the entire recovery. Verify the recovery:

clipboard_e0240041c329e92c2d2788045243de56f.png

Note that unlike an active/passive SRM recovery, the datastores remain mounted on the source vCenter:

clipboard_e166418a578635c79f7dece642ba66677.png

Reprotect

The reprotect operation also does not interact with the storage--it just reverses the SRM protection group and recovery plan. To reprotect, click Reprotect in SRM:

clipboard_e6ba1cdf0e1f2b66360eba7ca9123e147.png

Confirm the operation in the wizard and click Finish.

clipboard_e241db2c3ffaac3f3c0ae72e0f839e417.png

Failback

An SRM failback is identical in everyway to an original recovery for stretched storage. Ensure the proper resource mappings exist and the datastores are mounted in the target site to enable vMotion (if desired). Run the recovery plan normally to failback to the original vCenter.