SRM provides a test failover feature to ensure that VMs can be brought up on either site. The test failover data can be provided in a non-disruptive form by creating an Refreshed ShadowImage/Thin Image or Continous Thin Image replication. Unless specifically required, it is recommended to use a Continuous Thin Image for best user experience. To support the test failover feature, one of the following configurations can be used:
| Setup | Capabilities | Pros/Cons | Reference |
|---|---|---|---|
|
Local ‘Refreshed Thin Image’ / ‘ ShadowImage’ / ‘Continuous Refreshed Thin Image’ replication on both sides. |
Non-disruptive test-failover in either direction |
|
OR |
|
Local ‘Refreshed Thin Image’ / ‘ ShadowImage’ / ‘Continuous Refreshed Thin Image’ replication on single sides. |
Non-disruptive test-failover in a single direction (side with replication) |
|
Figure 4 |
|
No Local Replications. |
None. All test-failover requests will fail. |
|
Figure 3 |
|
SRA Configured to allow disruptive test-failover. |
A test-failover performed by splitting the main DR replication. |
|
All Figures supported. This configuration is discussed in Section How to configure SRM |
In the example above, Jurassic is the storage array where production vCenter datastores reside. Chesil is the storage array at the backup site. A TrueCopy replication protects the production datastores. For all the dataflows shown SRA can be configured to allow disruptive test-failover, which will split the main DR replication (TrueCopy in these examples) unless it is a Global-Active Device replication. This configuration is discussed in Section How to configure SRM
-
In Protector,
create and activate the SRM dataflows that define the protection of your
VM(s).
Each SRM data flow:
- MUST identify a datastore(s), or LDEV(s) that contains a datastore(s).
- The following is the recommended approach: LDEV ID using a Physical >Hitachi Block classification in conjunction with a Host > Hitachi BlockHost (the Storage > Hitachi Logical Block Device or Storage > Hitachi Block Device node is also allowed but is ultimately being deprecated).
- or VM ID using a classification in conjunction with a node.
- This method will only work if the SRM placeholder datastore is on the same block storage device as the protected VM(s).
- or VM Name using a classification in conjunction with a node.
CAUTION:- Use of Protector's classification is not supported because SRM unregisters datastores during fail-over and thus their IDs are subject to change.
- Use of any Protector classification type that relies on Object IDs is only supported if the SRM placeholder datastore is on the same block storage device. SRM unregisters and re-registers items in vCenter as it moves them. This process does not preserve the Object ID, thus the policy may not reliably backup the selected items once they are moved.
- Use of any Protector classification type that relies on Tags is not supported because SRM removes tags from objects when it moves them, thus the policy may not reliably backup the selected items once they are moved.
Note: The SRA can use the Protector UserTag feature to identify replications that are relevant to SRM. This tag can either be the default "SRM_REPLICATION", or a custom user defined tag that is also specified when setting up the SRA Array Pair Manager. In order to use this method, the tag should be added to the required Policy operations.Using UserTags in this way enables the Dataflow to have extra replications that are not relevant to SRM. It also enables different SRM instances or Array Pair Managers to filter different replications presented by the same master.
- If using the Protector UserTag based mechanism the Dataflow, where the userTag can be the default 'SRM_REPLICATION' or a custom user defined tag.
- MUST continuously replicate the datastore(s) or LDEV(s) using TrueCopy, Universal Replicator or Global-Active Device to the remote storage array. This operation must have the UserTag
- MAY define exactly one batch or continuous Refreshed Thin Image or batch ShadowImage replication of the datastore(s) or LDEV(s) at the local and/or remote site to support SRM non-disruptive recovery plan testing in both the fail- over and/or fail-back direction. These operations must have the UserTag
- MAY, if required for other purposes, have any additional operations assigned to the local and/or remote LDEVs as long as they do NOT have the UserTag
- If using the schema-based mechanism the Dataflow
- MUST continuously replicate the datastore(s) or LDEV(s) using TrueCopy, Universal Replicator, or Global-Active Device to the remote storage array.
- MAY define exactly one batch or continuous Refreshed Thin Image or batch ShadowImage replication of the datastore(s) or LDEV(s) at the local and/or remote site to support SRM non-disruptive recovery plan testing in both the fail- over and/or fail-back direction.
- MAY, if required for other purposes, have additional TI snapshot operations assigned to the local and/or remote LDEVs. No other operations can be assigned.
- MUST define the hostgroup(s) for the destination side (SVol) to be exposed on
the destination vCenterNote: When configuring TrueCopy on the data flow, setting On Destination Write Failure to Ignore (i.e. Fence Level: Never) in the Replication Configuration Wizard will not guarantee data consistency of VMs between the sites. Additional work may therefore be required to recover applications after failover.CAUTION:The continuous TC, UR or GAD replication must be left in the active, forward state, and only be paused or swapped by SRM. SRM will throw an error if the replications under its management are not in the expected state when performing fail-over or fail-back.
Note: The Protector Adapter will only identify SRM data flows that conform to this schema and data flows that use a Policy whose operations have the default or custom userTag. It will list them as Discovered Devices when configuring Array Pairs in the Site Recovery UI. The SRA Option ‘OnlyTaggedReplications=true’ can be used to only show data flows where the Policy operation uses the ‘SRM_REPLICATION’ tag.For custom tags (e.g. 'CUSTOM_TAG'), use the option 'OnlyTaggedReplications=CUSTOM_TAG
Setting Host Groups
When setting up the Dataflow the host groups for the remote copies, S-VOL and any testFailover copies must also be configured.
This is done as part of configuring the replication.
Figure. Replication Configuration screenFigure. S-VOL with Secondary Host Groups configuredFigure. Remote Test Failover Volume with Secondary Host Groups configuredFigure. Local Test Failover Volume with Secondary Host Groups configured - MUST identify a datastore(s), or LDEV(s) that contains a datastore(s).