Now that all of the prerequisites are complete, it is time to start creating protection groups and recovery plans.
This is part 3 of this series, the earlier parts were:
- Site Recovery Manager and ActiveCluster Part I: Pre-SRM Configuration
- Site Recovery Manager and ActiveCluster Part II: Configuring SRM
In SRM, there are two main management objects. Protection groups and recovery plans.
Protection groups are a selection of VMs (or datastores) that will always be failed over in unison. A VM or datastore can only be in one protection group.
A recovery plan includes one or more protection groups. A recovery plan indicates VM boot order, scripts or custom steps, IP changes and other time-of-failover configurations. A protection group can be in one or more recovery plans.
Creating a protection group
To create a protection group (I will refer to as PGs from now on), click on the Protection Group tab and then the NEW button.
Give your new PG a name and description and then a direction–if the VMs are currently on a certain vCenter, choose that one as the source.
Now choose storage policies. Active-Active storage is only supported in SRM with storage policy protection groups (SPPGs).
Choose your storage policy, mine is called srm-420-405-ActiveCluster.
On the next screen I am going to choose “Do not add to a recovery plan” but feel free to do that if you want. I will do it later in this post though.
Click Next then Finish.
To look at your protection group, click on the Protection Groups tab and then your new protection group. Verify that all of the VMs you want to be in the group are there. If some are missing, you likely have forgotten to apply the storage policy to it (or it has been mistakenly removed).
One column under the VM listing that is of interest is the “vMotion Eligible”. In order for this to be “yes” the following requirements exist:
- The PG must be a storage policy one
- The VM must be on stretched storage (like ActiveCluster)
- The VM must be powered-on
Why does this matter? Well in a stretched storage environment, SRM has the ability to actually vMotion the VMs on that type of storage from one vCenter to the other–therefore eliminating any downtime for those VMs during failover. This is a major benefit of SRM stretched storage support. More on this in an upcoming blog post.
Beyond looking at things, there is no much to DO in the PG, the work is all in the recovery plan. So let’s create one and see what’s available.
Creating a Recovery Plan
The next step is to create a recovery plan (which I will call RP from now on). Click on recovery plans and then the NEW button.
Give the RP a name and description and then choose the same direction as your PG.
Then choose the radio button for Storage policy protection groups and choose the PG(s) you want to add.
If you want to override network mappings for test failovers you can configure that here, otherwise click Next and then Finish. You can always change that later.
Now that the RP is created, click on it to view and/or edit it.
I am not going to go into everything in recovery plans here, but I will mention one thing. If my VMs is vMotion eligible, can I change that?
Yes! In the recovery plan. If you click on the Virtual Machines tab, you will see your VMs. Click on one and then choose the configure recovery button up top.
There is an option in here to override vMotion attempts. If you signal (during a failover) that SRM should attempt vMotion, it will try to vMotion all eligible VMs. If there are VMs that you do not want to be vMotioned, even though they are eligible, you can go in here to make them not eligible.
Deselecting the vMotion option will force the VM to always just be powered down, unregistered and then registered and booted up on the other vCenter instead of vMotioned.
That’s it for part III. In the next posts, I will do a FAQ and also walk through the recovery process and test recovery process.
3 Replies to “Site Recovery Manager and ActiveCluster Part III: Creating Protection Groups and Recovery Plans”
There’s a question that confusing me for a long time.
If customer have stretched storage deployed, why not just deploy vMSC instead, which could also protect VMs via vMotion to other healthy nodes if node/site failure.
What’s the benefit to deploy SRM stretch compared with vMSC?
Thank you very much!
Here is a good doc from VMware that I find helpful in explaining this https://storagehub.vmware.com/t/site-recovery-manager-3/stretched-clusters-vmware-site-recovery-manager/
Hello Cody and readers,
Can you tell if You maybe tried to protect SRM and vCenter VMs using the storage policies? Does it work? I know, from tests I done, that with the “old” protection method (async replication) this won’t work since SRM and vCenter on both sites has to be online but with ActiveCluster and SPPG, in theory, it should work right? since “all” SRM does is a Cross-vCenter vMotion. Can you somehow test this? Do you think it should be possible to protect ALL the VMs on VMware?