Skip to main content
Pure1 Support Portal

Configuring Site Recovery Manager Tag-Based Storage Policy Discovery

Storage Policy Groups

Note! You are not REQUIRED to use Storage Policies for VMFS with SRM unless you are using the SRM stretched storage feature. If you are configuring SRM to leverage protection group-based periodic replication (from a pod or not) for VMFS datastore recovery , storage policy implementation is optional.

In Site Recovery Manager 6.1, VMware introduced the concept of Storage Policy-based discovery of datastore groups. Traditionally storage was only discovered via the SRA--the SRA would discover array pairs and then any devices that were replicated between said pairs. The limitation to this approach was that if a VM was migrated to another datastore by an administrator or via some automated process (e.g. Storage DRS) protection in SRM could break if that datastore was not replicated and specifically not replicated between that array pair. There was no way to ensure that a migration occurred to an appropriate datastore. Even if it did, if the datastore was not part of the SRM protection group the VM could not be protected.

To resolve for this, SRM now offers a new mechanism to discovery storage--tag-based storage policies. With this, SRAs still need to discover devices as replicated. This part does not change. But instead of adding datastores to an SRM protection group, you instead add a storage policy:

clipboard_e57c09b5122d51a1871ee6f8cc0bfb5fd.png

Inside of vCenter, since VMs placement and configuration is controlled via tags, VMware administrators can make sure they make correct decisions when moving virtual machines, or creating new virtual disks. If they move or create a disk that is under the VM's policy that is not on compatible storage the administrator will be warned.

clipboard_ee29f6e6ee3698b5955b55c6a820aa024.png

The process works according to the following:

  1. Configure FlashArray replication on a VMFS volume
  2. Ensure the array managers are configured to discover the replication array pair and see the discovered device
  3. Create a datastore-type tag category
  4. Tag the datastore with that tag category
  5. Create a storage policy that ensures the datastore has that tag
  6. Assign that storage policy to one or more VMs
  7. Add that storage policy to a protection group

Tag Management Strategies

The first step in configuration for tag-based protection is to create a new tag category. You can create a single category or you can create multiple categories if you prefer. It depends on how you want to manage your environment.

Tag categories and tags can be considered to be similar to key/value pairs that are just separated into two different objects--the category being the key and the tag being the value. So a category could be something like "array replication pair" and the tag could be "x20 to x70". How you decide to use tags is up to you--the main point is that in order for SRM to be able to add datastores into a protection group, they must have at least one tag which is included in at least one storage policy.

There are a few things to answer:

  • Do you want one or more categories?
  • Does that category allow one or more tags from that category on one object?
  • What should the tag value be?

How you answer these questions is up to you. There are not strict rules on how this should be done--it is purposefully flexible. Do what makes sense in your environment--but the most important part is consistency. Come up with a framework and be consistent with how you implement it.

The important thing to remember is that tags are not "intelligent". If they describe a setting (like replication interval) and someone changes the replication interval on the FlashArray for that volume, the tag may no longer be correct. So generally focus on tagging datastores so they are properly grouped and take care to enforce strict change control of replication.

One more point to note is that if your vCenter Server instances are connected via Enhanced Linked Mode, tags and tag categories are replicated across all these vCenter Server instances upon creation and you do not need to create them for each vCenter. If the vCenters are not connected via ELM, you must manually create tag categories and tags in each vCenter. Both options are supported, but linking vCenters via ELM is generally recommended.

Creating a Tag Category

To create a tag category login to the vSphere Client and choose the Tags & Custom Attributes menu item.

clipboard_e7e2519c2e9b378e8d772e89f60b21af4.png

Then choose Categories and then New.

clipboard_edeec93b478fae4b744f339e196ac5df5.png

Now specify the category characteristics:

clipboard_eff8ae656f3aded01a2c912e26545a67b.png

  • Category Name: Make the name descriptive to indicate it is for SRM protection.
  • Description: Provide additional details on what this category is.
  • Tags Per Object: This allows a given object (like a datastore) to have more than one (or only one) tag per this particular category. Either option is supported and there are no specific recommendations for this. Though having only one tag per category can make the management of this easier.
  • Associable Object Types: You can choose any number of categories, but you should at least choose either datastore or datastore and datastore cluster. If you plan on putting datastores that are under the control of SRM into a datastore cluster, it is advisable to select both options. To keep these tags used for this specific purpose (SRM protection) it is also advisable to only choose datastore and/or datastore cluster and not other object types--this will help ensure that the policy is compliant only if the VM is on a correct datastore (and not for instance moved to an incorrect datastore, but also moved to a host that happens to have that tag).

Click OK.

clipboard_ecc1256c847732a72ed1e236158e0d81a.png

Default SRM Tag Categories

There are three default tag categories that are managed by Site Recovery Manager:

  1. SRM-com.vmware.vcDr:::status: Datastores that are discovered by SRM to be replicated will be tagged with this category with the value of "replicated".
  2. SRM-com.vmware.vcDr:::protectionGroup: A datastore that has a tag in this category means that this datastore has been added to a protection group. All datastores in the same protection group will have the same tag. This tag is what prevents one datastore to be controlled by more than one SRM pair.
  3. SRM-com.vmware.vcDr:::consistencyGroup: All datastores that have been discovered by SRM as replicated will have this tag. SRM will use the consistency group advertised by the SRA (if it supports it). The FlashArray SRA does not currently advertise consistency groups. Therefore, SRM will tag each datastore with its own consistency group.

clipboard_e77b4e47ecc8ff513188027e2b54f9b4e.png

It is generally advisable to not manually alter any VMware SRM automated tags--by default SRM will repair missing or deleted tags every 50 seconds. For more information refer to the VMware KB below:

https://kb.vmware.com/s/article/2108196

Creating a Tag

To create a tag, login to the vSphere Client and click the top Menu and choose Tags & Custom Attributes.

clipboard_e344cf364b9d7b067d17b98629ede9051.png

Choose Tags and then New.

clipboard_ef5a266f00b8288e4cb4cd4e488562533.png

Enter in a name and a description. Make sure to choose a tag category you created for SRM. 

clipboard_ec720763339516bd952d56b8947aefc8f.png

In the case above, a tag was created to represent a FlashArray protection group. Though as discussed earlier, you can design your tagging for whatever fits your environment best.

Click OK.

Assigning Tags to a Datastore 

To assign a tag to a datastore, click on the Storage tab and select the desired datastore, then choose Assign in the Tags box.

clipboard_e23c19782fe02d6d51aa1407ecd18006c.png

Choose the desired tag (confirm both the tag name and category). Select the tag(s) you want to assign to the datastore. Click Assign.

clipboard_e2aeb87b44c4a22b4e95edc2e13e8222d.png

The datastore will now be tagged. 

clipboard_e63db45af43b19036123f8aba448ecd24.png

If you do not see the default SRM tags (like SRM-com.vmware.vcDr:::status) it means that the datastore has not been discovered as replicated yet by SRM. So ensure that it is replicated and the SRM array managers are properly configured.

Assigning Tags to a Datastore Cluster 

If you have configured your tag categories to be able to use datastore clusters, you can optionally also assign the tags to a datastore cluster.

To assign a tag to a datastore cluster, click on the Storage tab and right-click the desired datastore cluster, then choose Tags & Custom Attributes, then Assign Tags in the menu.

Note that you must also tag each and every datastore in the datastore cluster for the datastore cluster and its datastores to show up in policy compliance results. The datastore cluster itself does not actually have to be tagged--just the datastores. Though doing so is a best practice.

clipboard_e27ec182da8955a7136e2a00a682971a5.png

Choose the desired tag (confirm both the tag name and category). Select the tag(s) you want to assign to the datastore cluster. Click Assign.

clipboard_ecb1590ca8f355ebc684ef73de52799a7.png

You will now see the tag(s) listed on the cluster. It is important to note, that unlike a datastore, SRM will not tag the cluster with the automatic SRM tags (status, consistency group, protection group).

clipboard_eb61e6f30707ab0dadba9a11d0364c9b1.png

Creating a Tag-based Storage Policy

Note that storage policies, unlike tags, are created per-vCenter, so you must create storage policies on both the source and target vCenters. So repeat this process below for both the source and target vCenters.

To ensure a VM stays on the correct datastore (or sets of datastores) a storage policy can be assigned to the VM. The policy says that only the storage that satisfies the following requirements can be valid as acceptable storage for this VM (or a set of VMs). This allows automated (or manual) migration procedures to be able to make moves, but only to compatible storage. Migration to non-compliant storage is allowed for manual migrations, but warnings are thrown during and after the migration. VM storage policies also make sure that new virtual disks are provisioned on compliant datastores.

Storage policies can be created to look for specific tags on datastores to make sure that VMs are only on datastores that comply.

To create a tag-based policy, click on the top menu and then Policies and Profiles:

clipboard_eed1958e30c904f52729e3453535f279c.png

From there, click on VM Storage Policies, then Create VM Storage Policy:

clipboard_e40bce22e70d57d8f70f9e3f3381403c9.png

Give the policy a unique name as well as a detailed description. Ensure that you choose the correct vCenter server in the drop down. Click Next.

clipboard_e94c287af5d3459ac22fa8648b0153872.png

Select the option called Enable tag based placement rules. Click Next.

clipboard_e72b469b5f1403af0e973e5b18fa96d0f.png

Choose your desired tag category. Then click the Browse Tags button.

clipboard_e74582268e1cf66c9c8c79c7c3c46de6e.png

Select the tag(s) that you want to include in the policy. Click OK.

clipboard_e3920ff223ca231ad1dfcca3d7d42bb89.png

Add any other rules you would like in the policy and click Next.

clipboard_e7f75244829e1c52b2604a160958cd30a.png

Confirm that the datastores that you have tagged appear in the list. If they do not, confirm afterwards that the tags are correctly applied. It is okay if they are not listed right now--this compliance list is generated on demand as you tag and un-tag datastores and/or provision VMs. 

Click Next.

clipboard_ede024e0de32c173719557faad6690ed2.png

Click Finish to create the policy.

clipboard_eb86df6ebb4f0951f653698524aab8fea.png

Lastly repeat this process to create a corresponding policy on the respective vCenter server as well. When datastores are failed over they will be tagged according to the policy and the VMs will reconfigured with the target policy.

Assigning a Tag-based Storage Policy to a VM

The next step is assigning the storage policy to all of the virtual machines you want to be failed over together. All VMs added to this policy will be failed over in unison, so ensure that new VMs created later that go on these datastores receive this policy.

Right-click on your target virtual machine, choose VM Policies, then Edit VM Storage Policies.

clipboard_e720a88714c17381af0d7a6bb1dc54a71.png

In the VM storage policy drop-down, choose the desired policy.

clipboard_e261f17653f90bc13e6d39976cb2898bb.png

Do NOT choose the configure per disk--you must protect all of the virtual machine disks with the same policy when used with SRM. 

Click OK.

clipboard_e330370b10640ceb1123aa6adb7937176.png

If you have already added the storage policy to a SRM protection group, you will see the VM immediately appears in the protection group.

clipboard_e6b483abe606da906949ba9795d71fe73.png

Creating Storage Policy Mappings

Since policies are specific to a given vCenter you must also create corresponding policies on the recovery vCenter. 

One example  is a storage policy called SRM-tag-m50_1-m20_1 on the source site that looks for the tag category called srmDiscovery and a tag with the value of srm-PG-1:

clipboard_e0336527deced7a0d612ffb92f4a3cf69.png

And my datastores are tagged with that tag, and the VMs have that policy:

clipboard_eb137a64ce4822b8c11ad8d7c0d318d6b.png

On the remote vCenter, I create a policy that looks for that same tag:

clipboard_e48e7df7976e31e66917224473197edef.png

When datastores are failed over from one vCenter to the other, SRM will ensure the tags on the source copy of the datastore are re-applied to the corresponding recovery datastores. The VMs that are on those datastores that are failed over in the recovery plan will be reconfigured to have the 2nd storage policy. Since the second policy looks for those tags, the VMs will be in compliance and failover will succeed. Before that can happen you must instruct what policies on the source policy map to what policies on the target vCenter. To do so, log into SRM and enter the appropriate site pair, and expand Configure > Storage Policy Mappings and then click New.

clipboard_e9c1c25ce07234b2f3d5c62708f902ec9.png

Choose automatic or manual mappings (if the names are different like above, choose manual, if the names are the same let SRM do it for you automatically).

clipboard_e7f986e2b756f8c578518f45cc12d00bf.png

Choose the source policy and then the target policy and click Add Mappings.

clipboard_ebca3954242840c9405b11218d9b13790.png

Click Next.

clipboard_e4b8e53613cab209343712b712dae9c36.png

Select the reverse mapping to enable failback.

clipboard_e760c6fbf36735bc5ce38ee32db8d8feb.png

Click Next, then Finish to confirm.

clipboard_ee7ff433499093a84c9d3b5eaba5ebb0c.png

Using Different Tags in each vCenter

An important thing to note is that both the source and target policies must also be compatible with the datastores before failed over. In other words, the storage policy on the recovery vCenter must look for tags that are already on the source VMFS datastores before SRM has failed them over. So while the policies on each side do not need to look for the same tags--they tags that are needed on the recovery side must already be added to the source datastores prior to recovery.

So in the below case there is a policy on the source side that looks for the tag srm-PG01-vc01:

clipboard_e1803e46e048f3bf3fad77405749de0ac.png

In SRM,

That policy is mapped to a policy on the target vCenter:

clipboard_e89f4e20d2e47588240918a25c0281e1e.png

The target policy is looking for a different tag called srm-PG01-vc02:

clipboard_e4ed5e83099eaff230d1165f40405e918.png

My datastore only has the tag described in the first policy though:

clipboard_e265f47c0177d9a7949481d6aceb0cf6b.png

If you attempt to failover this datastore now with SRM, the failover will not complete successfully. Prior to recovering the VMs, SRM will run a compliance check on the recovered datastores with the corresponding mapped policy. The datastore(s) will not be in compliance as the srm-PG01-vc02 tag will not appear.

clipboard_e6b341cf5a1c7eb82e618a3c66b94a215.png

SRM will automatically copy tags over from the source datastore to the recovered datastore, so if you are using different tags on the recovery datastore than what is needed on the protected site, ensure that those tags are already on the datastore prior to failover:

clipboard_e1ddbeb777a3af2a4c62b7a0e36e3a489.png

Note that if you add a tag to a datastore and immediately attempt a test or full recovery, the recovery might still fail with a compliance error. It can take a few minutes for SRM to sync new tags on source datastores.

On the recovered datastores, all of the tags will appear:

clipboard_eef5df61254b0136bfa03ea6532fe4093.png

Which will allow for the failover to complete successfully:

clipboard_e14f4f0f8404284a73c1e1dfde4994d2a.png