Private Cloud
Recovery organization
Suggest changes
PDFs
Disaster Recovery Orchestration
This section discusses successful failover of applications in a crisis or in a planned migration. It first looks at protecting complex multitier applications, and then simpler applications. You can build disaster recovery plans that are slow or fast, so this section provides examples of the highest-performing plans.
Multitier Applications
-
From the Failover page, select the Plans tab.
-
On the far right is an +Add Failover Group button.
In this example, we called this plan Multi-tier. We will use the network mapping in the bottom left to change the virtual switch that is in use on production to the one in use on DR.
The previous screenshot shows how you can choose the network switch in production and then in DR, use the Map button to select them, and then use Save. You can have more than one mapping if necessary.
-
To select the VMs to protect, click Add Failover Group.
Because this plan will protect multitier applications, the first group will be for databases.
Notice how this example enables Wait for VMware Tools. This setting is important, because it helps make sure that the applications are running. We used the Add VM button to add VMs that are databases. We didn’t enable Unregister Source VMs, because it will slow down the failover. We now use the Add Failover button to protect the applications.
-
Do the same thing for web servers. When that is done, the screen resembles the following example.
The important part of this plan is to get all the databases working; then the applications start, find the databases, and start working. Then the web servers start, and the applications are complete and working. This approach is the fastest way to set up this sort of recovery.
-
Click Save before you continue.
Simple or Mass Applications to Fail Over
The order in which the VMs start is important, so that they work; that is what the previous section accomplished. Now we will fail over a set of VMs for which order is unimportant.
Let’s create a new failover plan, with one failover group that has several VMs. We still need to do the network mapping.
Notice that there are several VMs in this plan. They will also start at different times, but that is OK because they are not related to each other.
Planned Migration
Planned migration is similar to a disaster recovery failover, but because it is not a disaster recovery situation, it can be handled slightly differently. It is still good to practice the planned migration, but you can add something to your failover group: You can unregister the VM from the source. That takes a little more time, but in a planned migration that is not a bad thing.
A planned migration is usually a move to a new domain controller. Sometimes it is also used if destructive weather is approaching but has not yet arrived.
Plan of Plans
With a plan of plans, you can trigger one plan and it will take care of all the failover plans.
The Plans tab contains a Plan of Plans section. You can use the +Add Sub-Plan to start a plan and add other plans to it.
In this example, the plan of plans is called Master Plan, and we added the two plans to it. Now when we execute a failover, or test failover, we will have the option for the Master Plan too.
This approach is good because it is best to test your application failovers in their own plan. Each plan is much easier to troubleshoot and fix, and when it is working well, you add it to your master plan.