Srm on The IT Hollow

VMware Site Recovery Manager 6.1 Announced

Mon, 31 Aug 2015 17:00:52 +0000

VMware announced Site Recovery Manager version 6.1 this week at VMworld in San Francisco California. Several new features were unveiled for VMware’s flagship Disaster Recovery product.

Storage Profile Protection Groups

Remember back in the old days (prior to today), when deploying a new virtual machine we had to ensure the datastore we were putting the virtual machine on was replicated? Not only that, but if this new VM was part of a group of similar VMs that needed to fail over together, we needed to make sure it was in the same protection group? Well VMware decided this was a cumbersome process and added “Storage Profile Protection Groups”.

SRM Troubleshooting

Tue, 27 Jan 2015 14:56:41 +0000

Unfortunately, not all software is perfect and from time to time I’ve run into issues with SRM as well. This post is a list of items I often see during SRM deployments and some information to troubleshoot issues.

Log File Locations

SRM Logs: c:programDataVMwareVMware vCenter Site Recovery ManagerLogs

Installation logs: %USERPROFILE%Application DataVMwareVMware Site Recovery ManagerLogs

Storage Replication Adapater Logs: This depends on the SRA Vendor, but try program filesSRANAME to start with

SRM 5.8 now with Automation!

Mon, 19 Jan 2015 14:15:24 +0000

SRM version 5.8 now is now extensible with vRealize Orchestrator (formerly vCenter Orchestrator). This new functionality was expected since the vRealize Suite is all about automation and disaster recovery certainly needs to be taken into consideration.

One pain point I’ve seen with SRM has been the ongoing administration of protection groups. Every time a virtual machine is deployed to a protected datastore, the VM also has to be configured for protection. This usually only consists of right clicking the virtual machine and choosing “configure protection” but is also another thing that administrators have too keep track of.

SRM 5.5 to 5.8 Upgrade

Wed, 14 Jan 2015 13:14:32 +0000

If you’ve got SRM 5.5 installed and you want to get the new SRM 5.8 code into your environment, don’t worry. The upgrade process is pretty easy to manage. The important thing to note is the upgrade order and of course your compatibility matrix. Remember that you need vCenter 5.5 U2 or higher to get SRM 5.8 working.

Upgrade Order

Ensure your vCenter Server and Web Client are on 5.5 U2 or higher in the protected site. If not, upgrade them!
Upgrade vSphere Replication on the protected site to 5.8 if you’re using one.
Upgrade SRM on the protected site to 5.8
Upgrade your SRA on the protected site if you’re using one.
Ensure your vCenter Server and Web Client are on 5.5 U2 or higher in the recovery site. If not, upgrade them!
Upgrade vSphere Replication on the recovery site to 5.8 if you’re using one.
Upgrade SRM on the recovery site.
Upgrade your SRA on the recovery site if you’re using one.
Verify the conneciton between your sites is valid, protection groups still exist and recovery plans are in tact.
Upgrade ESXi servers on the recovery site
Upgrade ESXi servers on the protected site
Upgrade VMware Tools.

Install

Run the installer on the SRM servers. The installer should detect that SRM is already installed an that an upgrade will be performed.

SRM 5.8 Customizing Your Recovery Plan

Thu, 08 Jan 2015 14:19:46 +0000

A customized recovery plan means the difference between hoursdays of reconfiguration of your environment in the event of a failure. VMware SRM allows for lots of opportunity to customize your recovery plans with scripts and modifications along the way to ease the management of your disaster recovery plans.

Run Scripts from SRM Server

If we open any given recovery plan we can click on a step we’d like to modify and then right-click to “Add Step…”

SRM 5.8 Alarms

Wed, 07 Jan 2015 04:46:33 +0000

Setting up some alerting is a good idea once you’ve setup your disaster recovery solution. Let’s face it once you’ve tested your DR solution, you might not look at it again until your next test, which in some cases is yearly!

To setup alarms for SRM in version 5.8 navigate to the vCenter object and click the Manage tab. From there click the Alarm Definitions sub-tab. Click the add (green plus sign) to add a new alarm.

SRM 5.8 Guide

Mon, 05 Jan 2015 15:00:29 +0000

This is a Site Recovery Manager 5.8 Guide to help understand the design, installation, operation and architecture of setting up VMware SRM 5.8

SRM 5.8 Architecture

SRM 5.8 Installation

SRM 5.8 Upgrade from SRM 5.5

SRM 5.8 Site Setup

SRM 5.8 Array Based Replication

SRM 5.8 Protection Groups

SRM 5.8 Recovery Plan

SRM 5.8 IP Customization

SRM 5.8 Customizing your Recovery Plan

SRM 5.8 Test Recovery

SRM 5.8 Failover Recovery

SRM 5.8 with Automation

SRM 5.8 Alarms

SRM 5.8 Troubleshooting

Official Documentation Links

Site Recovery Manager 5.8 Documentation Center

Site Recovery Manager 5.8 Compatibility Matrix

Site Recovery Manager 5.8 Release Notes

Site Recovery Manager 5.8 vCO Plug-in Download

Site Recovery Manager 5.8 Download

Site Recovery Manager 5.8 Storage Replication Adapters

Additional Resources

If you want some great resources to continue learning VMware Site Recovery Manager, I suggest checking out these resources:

SRM 5.8 Test Recovery

Mon, 05 Jan 2015 12:08:45 +0000

“Your disaster recovery plan is only as good as it’s last test.”

“If you haven’t tested your DR plan, then you don’t have a DR plan.”

These are all statements I’ve heard in the industry from CIOs and directors, and lucky for us VMware Site Recovery Manager has a test functionality built in for us to leverage without fear of affecting our production workloads.

Run a Test

Open up one of your recovery plans and click the monitor tab. Here you’ll have several buttons to choose from as well as seeing the list of recovery steps. To run a “Test” recovery click the green arrow button.

SRM 5.8 Failover

Mon, 05 Jan 2015 12:08:42 +0000

A terrible thing has happened and it’s time to failover your datacenter to your disaster recovery site. Well, maybe you’re just migrating your datacenter to a new one, but this is always a bit of a tense situation. Luckily we’ve had the opportunity to test the failovers many, many times before so we can be confident in our process.

Go to the Recovery Plan and click the monitor tab. Click the “BIG RED BUTTON” (yeah, it’s not that big, but it has big consequences).

SRM 5.8 IP Customization

Mon, 05 Jan 2015 12:07:15 +0000

Some companies have built out their disaster recovery site with a stretched layer 2 network or even a disjoint layer 2 network that shares the same IP addresses with their production sites. This is great because VMs don’t need to change IP Addresses if there is a failover event. This post goes over what options we have if you need to change IP Addresses during your failover.

Network mappings

SRM 5.8 has a wonderful new way to manage IP Addresses between datacenters. Prior to SRM 5.8 each VM needed to be manually updated with a new IP Address or done in bulk with a CSV template (show later in this post) if you had to re-IP your VMs. Now with SRM 5.8 we can do a network mapping to make our lives much easier. This is one of the best new features of SRM 5.8 in my opinion.

SRM 5.8 Recovery Plan

Mon, 05 Jan 2015 12:06:52 +0000

A recovery plan is the orchestration piece of Site Recovery Manager and likely the main reason for purchasing the product. All of the setup that’s been done prior to creating the recovery plans is necessary but the recovery plan is where magic happens.

When we go to the Recovery Plans menu in Site Recovery, we’ll see the option to click the notepad with the “+” sign on it to create a new recovery plan.

SRM 5.8 Protection Groups

Mon, 05 Jan 2015 12:05:58 +0000

SRM Sites and resource mappings are all done. It’s time to create some Protection Groups for our new VMware Site Recovery Manager deployment.

A protection group is a collection of virtual machines that should be failed over together. For instance, you may want all of your Microsoft Exchange servers to fail over together, or you may want a Web, App, Database Tier to all failover at the same time. It is also possible that your main goal for SRM is to protect you in the event of a catastrophic loss of your datacenter and you’re concerned with every VM. It still a good idea to create multiple protection groups so that you can fail over certain apps in the event of an unforeseen issue. Think about it, if your mail servers crashed but the rest of your datacenter is fine, would it make sense to just fail over the mail servers, or the entire datacenter? Just failing over the mail servers would make sense if they are in their own protection group.

SRM 5.8 Array Based Replication

Mon, 05 Jan 2015 12:04:36 +0000

If you plan to use Array Based Replication for your SRM implementation, you’ll need to install and configure your Storage Replication Adapter on your SRM Servers. The SRA is used for SRM to communicate with the array to do things like snapshots, and mounting of datastores.

Pair the Arrays

Once your SRAs have been installed in both your sites and you’ve gotten the arrays replicating, you’ll want to pair the arrays in SRM so that they can be used for protection Groups. Open the “Array Based Replication” tab in the “Site Recovery” menu of the web client. Click the Add button.

SRM 5.8 Site Setup

Mon, 05 Jan 2015 12:02:32 +0000

In the previous post we installed VMware Site Recovery Manger and now we need to do our Site Setup.

If you notice, now that SRM has been installed, the vSphere Web Client now has a Site Recovery menu in it. (If it doesn’t, log out and back in)

From here, we can go into the new SRM menus.

Site Pairing

Once you’ve gotten to the SRM Menus, we’ll want to click on Sites to configure our Sites.

SRM 5.8 Installation

Mon, 05 Jan 2015 12:01:14 +0000

SRM Installation Prerequisites

Database Prerequisites

Before you are able to install SRM, you’ll need a database to store configuration files. Create a database on your SQL Server to house the configuration information. Note: You’ll need a database server in both the protected site and recovery site; one for each SRM Server.

Pre-create the SQL Database and assign your SRM Service account AT LEAST the ADMINISTER BULK OPERATIONS, CONNECT, AND CREATE TABLE permissions.
Ensure the SRM database schema has the same name as the database user account.
The SRM database service account should be the database owner of the SRM database
The SRM database schema should be the default schema of the SRM database user.
On your SRM Servers, install the SQL Server native client for your version of SQL Server.

Create an ODBC connection to the SRM database on your SRM Servers. Select the SQL Native Client appropriate for your database server.

SRM 5.8 Architecture

Mon, 05 Jan 2015 12:00:31 +0000

VMware Site Recovery Manager consists of several different pieces that all have to fit together, let alone the fact that you are working with two different physical locations.

The following components will all need to be configured for a successful SRM implementation:

2 or more sites
2 or more Single Sign On Servers
2 or more vCenter Servers 5.5
2 or more SRM Servers
Storage – Either storage arrays with replication, or 2 or more Virtual Replication Appliances
Networks

It’s worth noting that SSO, vCenter, and SRM could all be installed on the same machine, but you’ll need this many instances of these components.

VMware Site Recovery Manager 5.5 Guide

Mon, 04 Nov 2013 14:02:37 +0000

This is a Site Recovery Manager 5.5 Guide to help understand the design, installation, operation and architecture of setting up VMware SRM 5.5

SRM 5.5 Architecture SRM 5.5 Installation SRM 5.5 Site Configuration SRM 5.5 VM Replication Configuration

SRM 5.5 Array Replication Configuration

SRM 5.5 Virtual Appliance Replication SRM 5.5 Protection Groups SRM 5.5 Recovery Plans SRM 5.5 Bulk IP Customizations SRM 5.5 Test Recovery SRM 5.5 Recovery SRM Gotchas

Official Documentation Links

SRM 5.5 Release Notes SRM 5.5 Compatibility Matrix SRM 5.5 Documentation Center SRM Port Numbers SRM Product Page

Are you Prepared for Disaster?

Mon, 11 Feb 2013 14:10:58 +0000

Disaster Recovery has never been easier to manage than it is right now. Virtualization has given engineers a tremendous tool to allow us to almost effortlessly move workloads between datacenters. Now that we’re virtualizing workloads, we’re now capable of standing up exact copies of our servers in two offices and have them up and running in very short RTOs.

In the past year we’ve seen two major storms hit the East Coast causing severe power outages as well as making commutes difficult or impossible for users to get to work. Thanks to the cloud we have many more mobile users than we used to and even if they’re not considered mobile, their servers may not be located in their office. Cloud presents some great options for disaster recovery that should be taken advantage of, no matter what your geographic location. If you’re in a SMB and you don’t have a DR plan, GET ONE NOW!

Lowering Disaster Recovery Costs with Site Recovery Manager

Fri, 22 Jun 2012 14:04:40 +0000

Setting up a disaster recovery site can be a costly endeavor. VMware Site Recovery Manager has made disaster recovery much simpler, but it’s still expensive to get a DR site up and going. Rack space, power, cooling, bandwidth, storage and compute can all add up pretty quickly, not to mention that hopefully you’ll never have to use this equipment.

Replication Bandwidth

Bandwidth could be very expensive depending on how much data needs to be replicated. Consider some of these techniques to make the best use of your bandwidth.

Poor Man's SRM Lab (Whitebox)

Thu, 03 May 2012 12:32:17 +0000

I really wanted to test out some VMware Site Recovery Manager scenarios and realized that buying SANs, servers and networking equipment was quite expensive. I also didn’t have a lot of space in my house that was available for running all of this equipment. After completing my VCP5 I was given a copy of VMware Workstation 8 and thought that I might be able to build a nested virtual environment, where the ESXi hosts themselves were virtualized inside of workstation. (Don’t worry, virtualizing a virtual host doesn’t warp time or space, it’s safe.)

VMware Replication Setup for Site Recovery Manager

Tue, 24 Apr 2012 12:21:22 +0000

Recently, I wrote a blog post about how to setup and configure VMware Site Recovery Manager for vSphere 5.0. This setup included using array based storage replication to transfer data and it ignored the new VMware replication engine that is included with Site Recovery Manager 5.0. This post is intended to cover the setup and configuration of the vSphere replication.

If you’re not familiar with it, the vSphere Replication Management Server handles individual replication of powered on virtual machines, to a secondary site. This is a free vSphere appliance with the purchase of VMware Site Recovery Manager 5.0. Traditionally, vSphere required that the storage providers were replicating the virtual machine data for SRM to work, but that has all changed with 5.0. Now VMware can do the replication for you.

VMware Site Recovery Manager Basic Setup

Fri, 20 Apr 2012 17:23:49 +0000

Finally, the idea of running a Disaster Recovery test is manageable. VMware Site Recovery Manager combined with vSphere has made it possible to test a failover to a warm site without worrying that the DR test itself will cause an outage.

Setting up Site Recovery Manager and performing a site failover sounds like a daunting task, but VMware has made this very simple, assuming you are familiar with vSphere already. If you already have a virtual environment setup at both your production site and a secondary site, SRM is pretty simple to get started with but allows for almost any DR Plan you can think of to be run.

Exchange Split Brain ... On Purpose?

Mon, 27 Feb 2012 00:42:40 +0000

I was recently tasked with performing a company wide disaster recovery test. The test had the normal goals with a standard recovery time objective, and recover point objectives. Unfortunately, the test needed to be performed during the middle of a production day, and not affect production. Under normal circumstances we could assume that our production servers were disabled or destroyed in some manner and we could power up our DR servers and continue the business. During this test however we needed to make sure that both networks could run at the same time.