Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > Configuring VMware SRM protection groups
When using SRDF, there are two types of protection groups that can be configured in SRM: datastore groups for SRDF/S and SRDF/A replication and storage policies specifically for SRDF/Metro (when the R2 is used) in SRM 8.4 and earlier.
A datastore group is a logical grouping of devices and is the smallest unit of storage that can be failed over or tested independently. There are several rules that control how datastore groups are calculated:
Protection groups can include one or more datastore groups and are one type of building blocks of recovery plans (which are discussed in the next section). Protection groups include the datastores groups which are to be failed over simultaneously. As such, failover is absolute—either the entire protection group fails over or none of it.
A storage policy defines storage policy information through rule-sets that describes storage requirements for virtual machines and storage capabilities of storage providers. Storage policies are used to manage the association between virtual machines and datastores. When used in conjunction with SRM, storage policies use tag-based rule-sets. The tag is then assigned to the datastores which are replicated with SRDF/Metro. Finally the VMs are associated with the newly created storage policy.
Note: The SRDF SRA requires that users create device/composite (consistency) groups prior to configuring protection groups that utilize datastore groups except for MetroDR configurations.
Protection groups can be created by selecting the shield in the Protection Groups section highlighted in Figure 49. This process can be initiated from either SRM server.
Note: Protection groups that are comprised of datastore groups should have underlying device/composite (consistency) groups on the appropriate Solutions Enabler installations. Datastore groups should have the identical devices in it that are in the consistency group—no more, no less. If a datastore group contains more devices than the consistency group it is based on, this usually means that one or more virtual machines on a datastore in that consistency groups spans to devices outside of the consistency group. In other words a virtual machine has a RDM, VMDK or a mounted ISO on a device or datastore not in the consistency group. If this occurs either move the VMDK, RDM or ISO to a device in the consistency group and re-discover or remove the offending object or virtual machine.
At this point the “Create Protection Group” wizard will appear. The wizard consists solely of choosing the target SRM server and what datastore group(s) or storage policy/policies will be in the protection group and a name for the group. The wizard is shown in Figure 50. Note there is the option to create a Recovery Plan within the protection group wizard, negating the requirement to run the recovery plan wizard if desired.
Note: If using MetroDR and both array pairs for the R1 and R2 are enabled, be sure to choose the R1 pair in step 2 of the wizard.
It should be noted that while the process can be initiated from either SRM server, datastore groups will only appear for the SRM server that has access to the R1 devices in that group. So if no datastore groups appear in the create protection group wizard it is likely that the incorrect SRM server was previously selected in the wizard.
VMware vCenter Site Recovery Manager (SRM) provides extensive functionality to configure flexible disaster recovery plans. Detailed information on the creation and configuration of these plans are beyond the scope of this paper but as the creation of a recovery plan is associated directly with a protection group, the wizard will walk the user through it. Readers should consult VMware documentation available on the VMware website for further details. To explain the functionality provided by SRDF SRA during the testing and execution of the recovery plans, sample protection groups and recovery plans were created for the environments used in this paper.
VMware SRM offers a wide variety of advanced options and settings that can be altered by the SRM administrator. The vast majority of these options are well beyond the scope of this book but this section will briefly discuss a few key settings involved in storage configuration and behavior of SRM.
If these settings are changed from the default it is recommended to make the change on both the protected and recovery SRM servers to maintain configuration consistency between the two environments. Changes of an option on one SRM server does not propagate to the other SRM server therefore the onus is on the user to do so.
Below are descriptions and recommendations for a list of six of the most common storage-related advanced SRM settings:
Note: During a recovery or test recovery the Auto-Resignature Mode set to Enabled, SRM automatically sets LVM.enableResignature to 1 if the flag is not already set in order to resignature snapshot volumes and mount them on ESXi hosts. The flag is NOT reset to 0. Setting the LVM.enableResignature flag on ESXi hosts is a host-wide operation and, if set, all snapshot LUNs that can be resignatured are resignatured during the subsequent host rescan. If snapshot volumes unrelated to SRM are currently forcefully mounted to ESXi hosts on the recovery site, these LUNs are resignatured as part of a host rescan. Accordingly, all of the virtual machines on these volumes will become inaccessible and will require re-registration. To prevent outages, ensure that no forcefully-mounted snapshot LUNs are visible to ESXi hosts on the recovery site or set Auto-Resignature mode to disabled. For more information refer to VMware KB article 2010051.
This option is targeted for environments that have multi-extent datastores with multiple copies of them presented to the recovery environment. Resignaturing in these situations can be complex and the functionality introduced by enabling this option eliminates the possibility of errors in regard to the resignaturing process. Dell’s recommendation is to leave this option enabled.
It is important to note that SRM will only detach detected snapshots of the devices to be recovered in the recovery plan. Unmounted, unresolved devices unrelated to the recovery plan (not in the recovery plan or snapshots of devices in it) will not be detached/re-attached. This option affects both recovery and test recovery operations.
Figure 51 shows the location of the advanced options editor.