VRO Plan Recovery Steps Examples

[mjm599]

Hi All,

Are there any Orchestration plan "VM Steps" Examples? So this is the step where you detail what to complete and in which order. As a starter this may be:

- Shutdown source VM
- Process CDP Replica VM to sync final changes
- Check VM Heartbeat
- VM Power Options (Power on Replica VM)

However would the above be the best order? These will be CDP Replicas, so the RE-IP Detail will be configured on the VBR Server in CDP Policy/Job, so looks like no need to add any RE-IP Detail/step to the Orchestration plan and steps above?

So the above would be the "Failover" steps to follow. How would 'failback' work? is that a separate Plan you configure?

Thanks,

[Alec King]

Hi,

A VRO CDP Replica plan performs many of the required steps automatically.

When failover is run, VRO will not automatically shut down the source VM - use the VM Power Actions step if you wish to do that (e.g. as part of a planned failover).
VBR will perform re-IP if it is configured as part of the CDP policy.
As a CDP policy runs continuously, there is no need to trigger any additional replica processing after powering off the VM - just failover.
The replica will automatically be powered ON after failover processing.
Check VM Heartbeat is a separate step, which is automatically added for each VM when creating a CDP replica plan in VRO. Heartbeat will be checked on the replica after failover processing.

You can also choose to add other steps, such as Ping VM Network, which will attempt to ping all network adapters on the failed-over VM.
All built-in steps are documented in the User Guide Appendix A. And of course you can add your own custom script steps.

VRO also understands the current plan status - so if you have already run the plan, your plan status is "failover complete". If you run the plan again, it will automatically offer to perform failback. And so on. You can work with the same plan to failover, failback, failover again etc.

You can see details in the User Guide on Running and Scheduling CDP Replica Plans

Hope that helps!

[mjm599]

Hi Alec,

Thanks for the reply. So with a basic plan, we can simply add the first step as "Shutdown Source VM" (In Production Site) then second step as "Check VM Heartbeat" (On replica in DR Site). Then when we failover, those steps will be followed. For the failback of that plan, would Veeam then reverse CDP Replica direction, power on the original VM in the production site as that plan would only detail "Shutdown Source VM"?

For a more complex requirement, whereby we have VMs with in-guest iSCSI, we would need to add custom scripts, so thats easy enough however in terms of the ordering would this seem correct?

- Edit plan to access pre and post options
- add pre plan step to power off source VM
- add pre plan step to run custom script (Custom script to break SnapMirror and complete netapp config)
------------- Believe this is the stage when CDP will run to failover the VM and RE-IP etc-------------------------------
- add post plan step to run custom script (to remap iSCSI Targets inside Windows VMs)
- add post plan step to restart VM to complete all changes and ensure applications can access new iSCSI Volume data etc

[Alec King]

Hi mjm599

Yes, your plan is valid -
Pre-plan steps - break snapmirror and mount volume on failover site and other netapp configuration.
For each VM -
First step for each VM would be "Shutdown Source VM", you can add that manually when creating the plan (this will ensure it gets added to any new VMs which are added to the CDP replica policy later)
Second step should be Process Replica VM, this is a step VRO adds automatically when creating the plan. This is a 'smart' step which will know when it should perform failover, failback, and so on, depending on the plan state.
Third step is by default Check Heartbeat.
Then you can add any other steps you want to process for each VM.

Regarding the VMs with in-guest iSCSI, you could configure all the iSCSI connections for all VMs in one post-plan step (you can pass in the names of all VMs to your script, this is a built-in VRO parameter)
Alternatively, it might be easier to run a script inside each VM, which could reconfigure the iSCSI connections and also perform the reboot. By choosing the script step 'Execute Location' as in-guest, your script will run inside the VM. That could be your Fourth step above, after checking the heartbeat.

There are numerous ways to achieve your goal, you can choose based on your requirements. Any other questions let us know!

[mjm599]

Hi Alec, thats all really helpful, thank you.

Do you see any issue combining requirements into a single plan?

For example, say we have 30 workloads to protect with VRO and CDP replications, of which 10 need RE-IP Configuration, 10 do not need to be RE-IP and 10 need the in-guest iSCSI configuration with custom script and NetApp etc.

Would you see any issue having all that config in one Plan? I'm mainly referring to the custom script part. i know there will be parameters in the script to detail which VMs the custom script aligns to however wondering if having that script in as a step may have any impact on the other VMs that don't have any in-guest iSCSI or need any mention of that in the plan?

Thanks,

[Alec King]

You are very welcome!

I see no technical issues in combining this in a single plan - ultimately it depends on some other details whether that's the optimal way for your case.

For example, should the VMs be recovered in a sequence? Or all in parallel? If all at once in parallel then a single group in a single plan is probably the optimal way to manage that.
However you seem to have 3 groups of VMs which will be recovered differently, it might make sense to have 3 groups in one plan if you want that to happen in a sequence. You can also mix sequential and parallel groups in the same plan. It might make sense to have three separate plans, this for example allows you to test those VM groups independently. (And you can chain plans together in an execution sequence too, so there really are a lot of options!)

Regarding the script, it could work in either of the suggested ways - either running the script inside every guest, or running a script in post-plan on the VBR or VRO server.

Option 1 - run the script inside guest OS
You can manage the iSCSI script step manually for the desired VMs in the plan, and just omit it for VMs that don't use iSCSI.
Or you can run the step for every VM, but the script can make a simple check so no changes will be attempted on the wrong VMs (e.g. is the iSCSI service set to automatic or not? if not, then exit)

Option 2 - run the script on VBR or VRO server with a list of VMs
You will have to maintain the list of VMs manually (e.g pass in a comma-separated list), however provided the VRO/VBR server has required remote access to the guest OSes, it will work fine. And this method doesn't touch any VMs which don't need iSCSI reconfiguration.

So, there's no technical reason that you can't perform all the actions you've specified within a single plan with a single group of VMs. However splitting these VMs into groups or even separate plans might also give advantages.
VRO gives you the flexibility to choose what's best for the recovery scenarios you anticipate.

Hope that helps!