Search This Blog

SRM implementation with vSphere Replication

It has been way too long since my last post and I figured I would update what has been happening.

Project - SRM implementation with vSphere Replication

I had an opportunity to implement an VMware Site Recovery Manager implementation for a Disaster Recovery initiative at the company I am working at.

The main thing to understand is the SRM itself is not the Disaster Recovery tool itself, it is the workflow engine for the fail over and fail back. The process for the fail over NEEDS to be fleshed out before this tool is installed. So perform the fail over manually before SRM is installed and document this, even if this is conceptually.

The disparate storage back-end from the main office to the alternate site made array based replication not ideal (licensing cost didn't help either) so vSphere replication was chosen as the replication mechanism.

Design

The design for SRM is fairly simple and the implementation requirements are also fairly straightforward:

Have two sites with ESXi hosts

Have two vCenters (same edition is critical)

Have a methodology for your SQL installation

SQL server installed on the same Windows machine as the application

SQL server installed in a central instance

Have a good network connection between the sites

Ideally have a segregated network for Replication Traffic and SRM Management (not critical but good to have)

As we were wanting to do the replication of our Messaging (Exchange 2007) environment IP addressing was ideal to remain the same, so thinking about IP spanning across sites was also considered. This was the dangerous consideration as determined by Cisco, citing numerous examples of spanning tree issues causing major outages. So other factors entered into the consideration of how this was to be designed.

The basics of the SRM implementation

SRM needs to talk to the Site vCenter, plain and simple. The two vCenters shouldn't be in linked mode to so to produce less errors in case of a site failure. So I determined for the second site, since this is a simple straight forward install the vCenter Appliance would be enough and would be quicker to install.

Download the vCenter appliance OVF

Get a static IP for the appliance

Install the OVF

Do initial setup using the built in Database

Connect ESXi Hosts to the vCenter

The infrastructure is setup for the receiving / recovery site.

Create a Windows Server that the SQL server will reside on

Install SQL server (it can not be SQL express)

If there is a policy to put the application server on the same windows box as the SQL server, install SRM on the same VMguest.

During the install there is a section to install vSphere Replication, make sure to install the component for this whether or not you will use it as it will provide functionality in the future.

Connect it to the vCenter and SRM will be available at the VIClient (not the Web Client)

Once the vCenter is connected a "vSphere Plug-in" will be available, install it and go to the "solution"

vSphere Replication

This one wasn't intuitive to begin with but after you figure it out, it is quite simple, in fact too simple and does need some additional components to track and monitor the connection.

The appliance is the piece that performs the replication, it contains the Replication Manager and Replication Server. Addition replication Servers can provides additional redundancy for the replication and isn't needed for small installs or few VMs to replicate.

Deploy the VR appliance (link on the Getting Started tab)

The "Reconfigure" link opens a web browser and the link to the admin page of the VRA

Configure, and register.

To initiate the replication,

Open the inventory tab and select the VM to be replicated.

Right click and select vSphere Replication

This sets up the replication to the configuration settings desired.

That's it, other than the Protection Groups and the Recovery plans. Remember Protection Groups are the bundle of VMs to replicate / protect and the Recovery plan is the order to be recovered. Once it is determined the application to be protected, initiate smaller protection groups and larger recovery plans.

I hope this helps those that are working through this. Drop a comment if for questions, or comments.

Ever wanted a way to ping an entire subnet and don't have access to a tool to do it? Well this one liner allows that.

The For at the beginning says the variable $i is equal to one, the semicolon separates it from the amount of times the loop is run 1..254 and then the $i++ increments the loop by 1. (You can specify every 5th IP if you want)

The next section runs the windows builtin ping.exe command (make sure you include the .EXE extension) with the switch -n (which means number of times) and then in brackets you are specifying the IP to ping. The where statement at the end is looking for a match of "bytes=32" default output for a successful ping.

I was working with VMware Update Manager and was running a scan on the entire VMguest infrastructure. Well the Update Manager service hung. I am not going to say anything more about that. :)

So I went to the UM server and attempted to restart the service. It sat in stop pending for quite awhile so I decided to kill the process. hmmm how do I do that? I was going to use powershell but the only cmdlet's available are to get- and stop- and restart-. All in the same token as going through the GUI.

Tasklist.exe /SVC
This displays all of the services running and their PID

Taskkill.exe /PID <PID #> /T
This terminates the service and child processes.

This killed the Update Scan on the VIclient and allowed me to restart the service.