VMware's Site Recovery Manager (SRM) can make the disaster recovery (DR) of all your virtual guest operating systems much easier. Among its many benefits are reduced recovery time of systems; improved success of DR recovery; prioritization of DR resources based on business needs; the ability to test DR recovery and audit trail of those tests; and, indirectly, through the storage arrays features, replication of virtual machine (VM) data to a recovery site. But it requires that you have all the right pieces in place. In this tip, I'll discuss how SRM works.
VMware SRM is a package that plans your VMware Virtual Infrastructure (VI) recovery in the event of a disaster at your primary, or protected, data center. The recovery plan for your VI is stored in Virtual Center and contains the exact order that your virtual guests need to be brought up in, as well as the exact recovery steps to get the protected site running again at the recovery site. Additionally, SRM manages the synchronization of your Virtual Center data (guest VM configurations) between the primary and backup site. Finally, SRM provides role-based access control, audit trails and the ability to export your recovery plan.
Synchronization of the Virtual Center configuration enables the synchronization of all VM guest configurations, such as the VM guest networking, CPU, RAM and hierarchical organization of VMs in VC. In this way, SRM is able to provide the following benefits:
- Automatic failover of VMs, as defined in the SRM disaster recovery plan
- Changes of IP addressing to provide for failover and export of a DNS script to update DNS
- Prioritization of VM startup based on available resources
- Ability to test DR recovery using SRM
In the graphic below, you can see how SRM is an add-on that appears inside your VMware Infrastructure client. From there, you can create, test and audit the recovery of your entire VMware Infrastructure.
SRM, however, is not a silver bullet. You still need an SRM-supported storage system. In fact, you will need two of them – one SRM supported storage system on each side of the connection. Many of you who use VMware ESX Server in the enterprise and have redundant data centers already have at least two SAN storage systems. But these requirements can be a resource strain on those who don't have the means to run out and buy a couple of SAN storage systems. Still, it is important to understand what SRM can do, what is needed and where SRM is going in the future.
To make SRM work, you will need a few other things. This is a complex solution with huge benefits, so it is likely that these aren't all things that you will have lying around:
- Virtual Center license at both the primary (protected) and recovery sites
- ESX Server licenses at both sites
- Database for SRM data at both sites
- Two SAN storage arrays (already mentioned) with block level replication – both of which must be supported by SRM. Note that 3PAR, Dell, EMC, FalconStor, Hitachi Data Systems, HP, IBM, LeftHand Networks and NetApp have all either announced that they will support SRM or have already released their SRM solution (see the links below for a few of those vendors).
- Site Recovery Agent (SRA) software that is compatible with SRM
Where can I find more news about VMware SRM?
For a product description of SRM, you can visit VMware's website. You can also find a VMware SRM technical presentation and expert advice about features of VMware Site Recovery Manager. Additionally, blogger Rich Brambly has a good SRM description on the VMTN blog. Lastly, make sure to check out Dell's video on scripting elements with VMware SRM.
About the author: David Davis (CCIE #9369, VCP, CWNA, MCSE, CISSP, Linux+, CEH) is the
Director of Infrastructure at Train Signal,
Inc. He has written hundreds of articles and six video training courses – including the Train Signal VMware ESX Server video training series. His websites are Happy Router.com and VMwareVideos.com.
This was first published in June 2008