Tag Archives: SRA

Data Centre Migration Strategies – Part 1 – Overview

Posted on by
1

After a recent twitter discussion, I felt a Data Centre migration strategies would be a good blog series to help people understand what the options are, along with the Pros and Cons of each strategy.

This guide is not intended to be a step by step on how to set-up each of these solutions, but a guide to assist you making the best decision for your environment when considering a data centre migration.

So what’s are some of the options when migrating virtual machines from one data centre to another?

1. Lift and Shift

Summary: Shut-down your environment and Physically relocate all the required equipment to the new location.

2. VMware Site Recovery Manager (SRM)

Summary: Using SRM with either Storage Replication Adapters (SRAs) or vSphere Replication (VR) to perform both test and planned migration/s between the data centres.

3. vSphere Metro Storage Cluster (vMSC)

Summary: Using an existing vMSC or by setting up a new vMSC for the migration, vMotion virtual machines between the sites.

4. Stretched vSphere Cluster / Storage vMotion

Summary: Present your storage at one or both sites to ESXi hosts at one or both sites and use vMotion and Storage vMotion to move workloads between sites.

5. Backup & Restore

Summary: Take a full backup of your virtual machines, transport the backup data to a new data centre (physically or by data replication) and restore the backup onto the new environment.

6. Vendor Specific Solutions

Summary: There are countless vendor specific solutions which range from Storage layer, to Application layer and everything in between.

7. Data Replication and re-register VMs into vCenter (or ESXi) inventory

Summary: The poor man’s SRM solution. Setup data replication at the storage layer and manually or via scripts re-register VMs into the inventory of vCenter or ESXi for sites with no vCenter.

Each of the above topics will be discussed in detail over the coming weeks so stay tuned, and if you work for a vendor with a specific solution you would like featured please leave a comment and I will get back to you.

Example Architectural Decision – Site Recovery Manager Deployment Location

Posted on by
2

Problem Statement

To ensure Production vSphere environment/s can meet/exceed the required RTOs in the event of a declared site failure and easily perform scheduled DR testing, VMware Site Recovery Manager will be used to automated the failover to the secondary site.

What is the most suitable way to deploy Site Recovery Manager to ensure the environment can be maintained with minimal risk/complexity?

Requirements

1. Meet/Exceed RTO requirements
2. Ensure solution is fully supported

Assumptions

1. vCenter is considered a Tier 1 application
2. vSphere 5.1
3. SRM 5.1
4. A single Windows instance hosts vCenter, SSO and Inventory services and is protected by vCenter Heartbeat

Constraints

1. SRM is not protected by vCenter Heartbeat

Motivation

1. Reduce the complexity for BAU maintenance

Architectural Decision

Install Site Recovery Manager on a dedicated Windows 2008 instance

Justification

1. When installing / upgrading /  patching  SRM including Storage Replication Adapters (SRAs) this may require a reboot or troubleshooting which may impact the production vCenter, including SSO and inventory services.

2. Having SRM separate to vCenter ensures the fail over is not unnecessarily delayed in the event of a disaster due to contention with vCenter on the same VM

3. SRM and vCenter work together in the event of an outage, as such they are less complimentary workloads

4. If hosted on vCenter, SRM will then be subject to the same change windows and be impacted during any maintenance performed for applications running on the same OS instance

5. The SRM application has different availability requirements than vCenter, as such if SRM was combined with vCenter, SRM (having a lower availability requirement than vCenter) would have to be treated with the same change management / care as vCenter which would complicate BAU maintenance

6. The SRM service (business) has different maintenance requirements to vCenter, as such they are not suited to be placed on the same VM

7. Having SRM on a dedicated VM aligns with the scaling out recommendation for virtual workloads

8. Having additional components on the same OS increases complexity and may reduce the availability of vCenter

Alternatives

1. Place SRM on the vCenter server

Implications

1. One (1) additional Windows 2008 R2 licenses will be required

2. One (1) additional Windows instance will need to be maintained in BAU

I would like to Thank James Wirth VCDX#83 (@jimmywally81) for his contribution to this example architectural decision.

Related Articles

1. VMware Site Recovery Manager, Physical or Virtual machine?

2. Swap file location for SRM protected VMs

CloudXClogo