VMware Site Recovery Manager Overview
One of the hands on labs I attended at VMware Partner Exchange was the Site Recovery Manager (SRM) lab. In the lab I was able to get a good understanding of the technical details of how the yet to be released product is configured. The lab then walked us through the fail over process and workflow. This post is a high level summary of what I learned. This post is not intended to be a detailed how to, but instead just a logical overview about what it will take to set up SRM.
SRM requirements:
- VirtualCenter licensed and running at both the primary and secondary sites.
- ESX hosts licensed and running at both the primary and secondary sites.
- Backend database for SRM at both the primary and secondary site.
- Shared storage capable of, and licensed for, block level replication (SAN based) at both the primary and secondary sites.
- Site Recovery Agent (SRA) installer provided by the SAN manufacturer.
Note: if your SAN manufacturer does not create a SRA you can not use SRM. There is not an official SRA manufacturer list at this time. The instructors in my lab indicated most all major SAN manufacturers are working on developing SRAs, but the list will not be official until product release. My lab used a LeftHand Networks SRA.
Preparation for SRM:
LUNs
Organize your LUNs / volumes for SRM because you will probably not need all of your VMs to be replicated. For example, your VC server, Update Manager server, and SRM server (if they are VMs) should not be replicated. If other similar infrastructure server VMs should not be replicated then move these VMs out of the LUNs / Volumes containing the VMs that will be replicated. Move all of your non critical VMs to their own LUNs. The idea is to reduce replicated traffic as much as possible by syncing only select LUNs containing your critical VMs. Obviously, this will be a significant project for some organizations by itself. Leverage storage vmotion to minimize VM downtown during this process as much as possible.
Database
I was told the database requirements are exactly the same as VirtualCenter. Since the product has not been fully user tested yet, my instructors indicated there are no solid best practices yet for SRM database design. In other words, can SRM be installed on VC? Can Update Manager and SRM be installed on the same server? Should all of these servers be VMs or physical servers? Personally, considering VirtualCenter, SRM, Guided Consolidation, and Update Manager all require a database, I am of the opinion it will make the most sense to use ODBC connections to a stand alone database server. If I am going to make all of these servers VMs then I would make a separate server for each as well. Be sure to include this design in the LUN preparations!
Lab and Configuration overview:
Primary Site
- Install SRM code on SRM server (SRM was installed on VC in my lab)
- Install SRM plugin in VI Cleint connecting to VirtualCenter and enable plugin
- Install SRA on SRM server
Secondary Site
- Install SRM code on SRM server
- Install SRM plugin in VI Client connecting VirtualCenter and enable plugin
- Install SRA on SRM server
Replication from Primary Site
- Use SRM plugin to configure and verify replication to secondary site
Test fail over and work flow using the SRM plugin from the primary site
When the lab materials are released to the public I will post a copy here on vmetc.com. I do not have them as of this writing.
on May 12th, 2008 at 2:33 pm
[…] VMware Site Recovery Manager Overview […]
on June 7th, 2008 at 9:18 am
[…] With the help of a storage vendor provided SRM Agent, VirtualCenter with the SRM plug-in is able to coordinate the ESX snapshots with the SAN snapshots in order to provide site replication. Wouldn’t it be cool if a future version of SRM or a “sister” application was […]