Finally, we have arrived to a point where we can run the Recovery. SRM migrates all the VMs in the recovery plan to the recovery site. SRM attempts to shutdown the VMs at the Protected Site. Not everyone in the organization are allowed to run recovery as it alters the entire environment in many cases and reversing things is time consuming and needs effort. Continue reading
It is important to clean up after testing the recovery plan; failing to clean up the recovery plan bars us to test or run the recovery plan again. Cleanup does the following things.
- Powers off the recovered VMs
- Replaces recovered VMs with place holder VMs and preservs the configuration information.
- Cleansup the replicated storage snapshots that the recovered VMs used during the test.
Now that we have the recovery plan configured according to our needs, its time we test the recovery plan. When you test a recovery plan, SRM uses the test network to test the VMs in the plan and also no VMs on the Protected Site are powered off unlike when the actual recovery plan is run. Remember that, if a recovery plan requires to suspend or power off any VM on the recovery site, testing the recovery plan also suspends the VMs and no other changes are made to the production environment during the test recovery. Continue reading
Creating a Recovery Plan is a very good thing but how do make it work the way we want it to? Well, every Recovery Plan has to be configured for the fact that, virtual machines depend on other machines in many ways, for example, the DB server has to powered on first for the app server and web server to connect to it and in some cases, we want to run some start-up scripts so that the machine can become available to users. All such things have to be fed to the recovery plan. So let’s see how that is done. Continue reading
We have come a long way in settings up things and working on SRM related stuff. We have almost reached the last steps in enabling a Disaster Recovery Solution for VMs. Now that we have Protection Groups created and verified all the required VMs are being replicated as expected, our next step would be to create a Recovery Plan so that the Protection Groups can be made use of. A Recovery Plan controls every step of the recovery process, including the order in which the VMs have to be powered on, networks to be used, and other stuff related to virtual machines to be protected. Continue reading
As discussed in our previous post, Protection Groups are a collection of virtual machines that are protected together. Protection Groups can be created based on the type of replication they have ie whether it is Array Based or vSphere Replication or Storage Policy Based. A Recovery Plan can include Protection Groups from Array Based Replication or vSphere Based Replication but a Storage Policy Based Protection Group cannot be included in the same Recovery Plan as Array or vSphere Replication Protection Group. Continue reading
Mapping is important for the SRM to work correctly as it specifies how VM resources at Protected Site are to be mapped to the resources at the Recovery Site. During the recovery, SRM uses the resources specified in the mapping at the recovery site to start the virtual machines. Bi-directional protection is also possible in the SRM and for this reverse mapping has to be configured. Continue reading