Storage Policy Groups
It is not REQUIRED to use Storage Policies for VMFS with SRM unless you are using the SRM stretched storage feature. If configuring SRM to leverage protection group-based periodic replication (from a pod or not) for VMFS datastore recovery, the 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. Instead of adding datastores to an SRM protection group, a storage policy can be added:
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.
The process is:
- Configure FlashArray replication on a VMFS volume
- Ensure the array managers are configured to discover the replication array pair and see the discovered device
- Create a datastore-type tag category
- Tag the datastore with that tag category
- Create a storage policy that ensures the datastore has that tag
- Assign that storage policy to one or more VMs
- 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 the administrator decide to use tags is up to the administrator- 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:
- How many categories should there be- one or more?
- 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 the administrator. There are not strict rules on how this should be done; it is purposefully flexible. Do what makes sense in the environment. The most important part is consistency. Come up with a framework and be consistent with how it is implimented.
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 software for that volume, the tag may no longer be correct. 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 there is no need to create them for each vCenter. If the vCenters are not connected via ELM, there must be manually be created 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.
Then choose Categories and then New.
Now specify the category characteristics:
- 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. Having only one tag per category can make the management of this easier.
- Associable Object Types: Choose any number of categories, but there should at least be either datastore or datastore and datastore cluster. If the plan is to put 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).
Default SRM Tag Categories
There are three default tag categories that are managed by Site Recovery Manager:
- 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".
- 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.
- 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.
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 this VMware KB.
Creating a Tag
To create a tag, login to the vSphere Client and click the top Menu and choose Tags & Custom Attributes.
Choose Tags and then New.
Enter in a name and a description. Make sure to choose a tag category you created for SRM.
In the case above, a tag was created to represent a FlashArray protection group. As discussed earlier, tagging can be designed for specific environmental considerations.
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.
Choose the desired tag (confirm both the tag name and category). Select the tag(s) that should be assigned to the datastore. Click Assign.
The datastore will now be tagged.
If the default SRM tags are not visible (like SRM-com.vmware.vcDr:::status), it means that the datastore has not been discovered as replicated yet by SRM. Ensure that it is replicated and the SRM array managers are properly configured.
Assigning Tags to a Datastore Cluster
If the tag categories have been configured to be able to use datastore clusters, tags can optionally be assigned 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 the administrator 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. Doing so is a best practice.
Choose the desired tag (confirm both the tag name and category). Select the tag(s) appropriate to assign to the datastore cluster. Click Assign.
Now the tag(s) listed on the cluster are visible. Unlike a datastore, SRM will not tag the cluster with the automatic SRM tags (status, consistency group, protection group).
Creating a Tag-based Storage Policy
Note that storage policies, unlike tags, are created per-vCenter, so storage policies must be created on both the source and target vCenters. 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:
From there, click on VM Storage Policies, then Create VM Storage Policy:
Give the policy a unique name as well as a detailed description. Ensure that the correct vCenter server is chosen in the drop down. Click Next.
Select the option called Enable tag based placement rules. Click Next.
Choose the desired tag category. Then click the Browse Tags button.
Select the tag(s) that need to be include in the policy. Click OK.
Add any other rules desired in the policy and click Next.
Confirm that the datastores that were 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 the datastores are tagged and un-tagged and/or VMs are provisioned.
Click Finish to create the policy.
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 that need 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 the target virtual machine, choose VM Policies, then Edit VM Storage Policies.
In the VM storage policy drop-down, choose the desired policy.
Do NOT choose the configure per disk- all of the virtual machine disks must be protected with the same policy when used with SRM.
If the storage policy has already been added to a SRM protection group, you will see the VM immediately appears in the protection group.
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:
The datastores are tagged with that tag, and the VMs have that policy:
On the remote vCenter, a policy is created that looks for that same tag:
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 second 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.
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).
Choose the source policy and then the target policy and click Add Mappings.
Select the reverse mapping to enable failback.
Click Next, then Finish to confirm.
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, the tags that are needed on the recovery side must already be added to the source datastores prior to recovery.
In the below case there is a policy on the source side that looks for the tag srm-PG01-vc01:
In SRM that policy is mapped to a policy on the target vCenter:
The target policy is looking for a different tag called srm-PG01-vc02:
The datastore only has the tag described in the first policy though:
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.
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:
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:
Which will allow for the failover to complete successfully: