vsphere_static_160x300
Free Business and Tech Magazines and eBooks
Badges

vexpert_logo_100x57

gestaltitbadge

follow-me-twitter

Subscribe to me on FriendFeed

Comments / DISQUS
Feedjit.com

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

  1. Install SRM code on SRM server (SRM was installed on VC in my lab)
  2. Install SRM plugin in VI Cleint connecting to VirtualCenter and enable plugin
  3. Install SRA on SRM server

Secondary Site

  1. Install SRM code on SRM server
  2. Install SRM plugin in VI Client connecting VirtualCenter and enable plugin
  3. Install SRA on SRM server

Replication from Primary Site

  1. 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.

Related Posts

blog comments powered by Disqus
Hyper9 Cowabunga
Support VM /ETC
Support VMETC.com

Support VMETC.com

@rbrambley tweets
Advertisements
VMTN Roundtable Podcasts
Subscribe



Add to Google Reader or Homepage
Subscribe in NewsGator Online
Add to netvibes
Add to Plusmo