How to configure Protector

Protector users who require SRM functionality must protect their datastores using block storage replication (TrueCopy, Universal Replicator or Global-Active Device) dataflows, the policies for which select LDEVs corresponding to datastores to be replicated. The current implementation does not support the automatic creation of SRM objects such as protection groups.

Note: It is recommended that the policy explicitly specifies LDEVs or Host Groups where the datastores reside. While it is possible to specify datastores indirectly, using a VMware classification, this method has limitations because SRM invalidates object IDs during failover.

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 a Batch 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:

Table. SRM Configurations
Setup	Capabilities	Pros/Cons	Reference
On both sides of DR replication, a local: Batch ShadowImage Batch Refreshed Thin Image Continuous Refreshed Thin Image	Non-disruptive test-failover in either direction	+ Does not disrupt the DR protection - Requires storage and pool space	Figure 1 OR Figure 2
On one side of DR replication, a local: Batch ShadowImage Batch Refreshed Thin Image Continuous Refreshed Thin Image	Non-disruptive test-failover in a single direction (side with replication)	+ Does not disrupt the DR protection + Requires less storage and pool space than above - Only performs test-failover in a single direction	Figure 4
No Local Replications.	None. All test-failover requests will fail.	+ Does not use any storage and pool space - No test-failover capabilities	Figure 3
SRA Configured to allow disruptive test-failover.	A test-failover performed by splitting the main DR replication.	+ Most similar to a real failover + Does not use any storage and pool space - This will suspend the DR protection unit test-failover is cleaned up - Not supported for Global-Active Device replications	All Figures supported. This configuration is discussed in Section How to configure SRM

Figure. Dataflow with support for non-destructive test-failover (using batch replications)

Figure. Dataflow with support for non-destructive test-failover (using continuous replications)

Figure. Dataflow without support for non-destructive test-failover

Figure. Dataflow with support for non-destructive test-failover on recovery site

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 a Protector-SRA user.

Tip: A built-in Default VMware SRM ACP and associated role is provided for this purpose. This ACP can be cloned and associated with a more specific resource group if required.
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 Hypervisor > VMware > Browse for resources > Virtual Machines and Templates classification in conjunction with a Hypervisor > VMware 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 Hypervisor > VMware > Specify resource by name or wildcard > Virtual Machines and Templates classification in conjunction with a Hypervisor > VMware node.
  CAUTION:
  - Use of Protector's Hypervisor > VMware > Datastores 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 vCenter
  Note: 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 screen

Figure. S-VOL with Secondary Host Groups configured

Figure. Remote Test Failover Volume with Secondary Host Groups configured

Figure. Local Test Failover Volume with Secondary Host Groups configured