With previous SRM versions your options for controlling start sequence of individual VMs boiled down to choosing whether to put the individual VMs into High, Medium or Low priority groups. High priority VMs started sequentially, Medium and Low priority VMs started in parallel.
This meant that in order to stage startup of VMs what most of our customers would do is more or less leave everything in "Medium" and then control sequencing by interleaving multiple recovery plans.
This meant you had to carefully manage your recovery plans and the sequence with which they were run. You might have had an RP for 'base infrastructure services' another RP for 'base databases' another for each tier of a 3-tier architecture, and so forth, and then manage running them in the appropriate sequence.
Now we have a slightly different way of manipulating startups. We have 6 priority groups within a recovery plan. The VMs in each priority group will all start in parallel with each other, meaning we've in essence doubled the number of priorities that can be set for VMs within a recovery plan.
But beyond that we want to be able to control the sequence for starting VMs *within* a priority group as well, and that's where the new feature of "Dependencies" comes into play. With SRM 5 you can set as a property of the VM itself another VM or a number of VMs that must be started and running before the VM on which you're working will start.
In essence we can now have a single recovery plan, with 6 groups of VMs within it, with individual dependencies for each VM set within the priority group to control start sequence.
So what, Ken? Well the great part about this is that we can now reduce the number of recovery plans needed to control start sequence. We can take those old RPs and in essence turn them into priority groups within a single recovery plan, and then from there set mandatory start ordering within each priority group!
So from an ease of management perspective, this is brilliant, and everyone should be quite pleased by this. But what's the catch?
Well there's no real catch per se, but one thing you *will* need to be aware of is that the RTO, Recovery Time Objective, may be impacted if instead of doing things in parallel you start setting dependencies and start ordering for all your VMs.
If your recovery time with 10 VMs starting in parallel is 5 minutes, adding a single dependency into that may add another, say, 2 minutes while one VM waits for its 'parent' to complete booting. If every VM has a dependency set on one or two mandatory VMs it's probably not a big deal. If every VM is dependent on another VM in essence you've set them back to sequential boot sequence, and your 5 minute RTO may have to be adjusted to 25 minutes or so!
The point is that dependencies are amazing and give you a lot more control over how and when VMs start, and allow you to redesign your recovery plans, but be cautious with them. If a dramatically quick RTO is your chief objective you may be better served by either putting non-dependent groups of VMs into more priority groups or even by returning to the old model of interleaving sets of recovery plans!
