Home > Blogs > VMware Consulting Blog


BCDR: Some Things to Consider When Upgrading Your VMware Disaster Recovery Solution

Julienne_PhamBy Julienne Pham

Once upon a time, you protected your VMs with VMware Site Recovery Manager, and now you are wondering how to upgrade your DR solution with minimum impact on the environment. Is it as seamless as you think?

During my days in Global Support and working on customer Business Continuity/Disaster Recovery (BCDR) projects, I found it intriguing how vSphere components can put barriers in an upgrade path. Indeed, one of the first things I learned was that timing and the update sequence of my DR infrastructure was crucial to keep everything running, and with as little disruption as possible.

Here If we look more closely, this is a typical VMware Site Recovery Manager setup:

JPham_SRM 6x

And in a pyramid model, we have something like this:

JPham_SRM Pyramid

Example of a protected site

So, where do we start our upgrade?

Upgrade and maintain the foundation

You begin with the hardware. Then, the vSphere version you are upgrading to. You’ll see a lot of new features available, along with bug fixes, so your hardware and firmware might need some adjustments to support new features and enhancements. It is important at a minimum to check the compatibility of the hardware and software you are upgrading to.

In a DR scenario, it is important to check storage replication compliance

This is where you ensure your data replicates according to your RPO.

If you are using vSphere Replication or Storage Array Replication, you should check the upgrade path and the dependency with vSphere and SRM.

  • As an example, VR cannot be upgraded directly from 5.8 to 6.1
  • You might need to update the Storage Replication Adaptor too.
  • You can probably find other examples of things that won’t work, or find work-arounds you’ll need.
  • You can find some useful information in the VMware Compatibility Guide

Architecture change

If you are looking to upgrade from vSphere 5.5 to 6.1, for example, you should check if you need to migrate from a simple SSO install to an external one for more flexibility, as you might not be able to change in the future. As VMware SRM is dependent on the health of vCenter, you might be better off looking first into upgrading this component as a prerequisite.

Before you start you might want to check out the informative blog, “vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 1.”

The sites are interdependent

Once the foundation path is planned out, you have to think about how to minimize business impact.

Remember that if your protected site workload is down, you can always trigger a DR scenario, so it is in your best interest to keep the secondary site management layer fully functional and upgrade VMware SRM and vCenter at the last resort.

VMware upgrade path compatibility

Some might assume that you can upgrade from one version to another without compatibility issues coming up. Well, to avoid surprises, I recommend looking into our compatibility matrix, and validate the different product version upgrade paths.

For example, the upgrade of SRM 5.8 to 6.1 is not supported. So, what implications might be related to vCenter and SRM compatibility during the upgrade?

JPham_Upgrade Path Sequence

Back up, back up, back up

The standard consideration is to run backups before every upgrade. A snapshot VM might not be enough in certain situations if you are in different upgrade stages at different sites. You need to carefully plan and synchronise all different database instances for VMware Site Recovery Manager and vCenter—at both sites and eventually vSphere Replication databases.

I hope this addresses some of the common questions and concerns that might come up when you are thinking of upgrading SRM. Planning and timing are key for a successful upgrade. Many components are interdependent, and you need to consider them carefully to avoid an asynchronous environment with little control over outcomes. Good luck!


Julienne Pham is a Technical Solution Architect for the Professional Services Engineering team. She is specialised on SRM and core storage. Her focus is on VIO and BCDR space.

3 thoughts on “BCDR: Some Things to Consider When Upgrading Your VMware Disaster Recovery Solution

  1. Mike Burkhart

    I would add a few things here:
    “As an example, VR cannot be upgraded directly from 5.8 to 6.1” – yes you can; the article linked later ( https://kb.vmware.com/kb/2136677 ) shows support for upgrading vR 5.8.x to 6.1
    SRM cannot be upgraded from 5.8.x to 6.1; VR is a different story.

    “If you are looking to upgrade from vSphere 5.5 to 6.1” – currently there is no 6.1 for vSphere; latest release is 6.0U2

    Also – embedded SSO in 5.5/5.1 was fairly simple install, and desirable for a “hassle-free” deployment; Once upgraded to 6.0, these become embedded PSC’s, and these potentially break SRM 6.1’s ability to reference the local site. Embedded PSC’s are “not recommended” but not explicitly unsupported as of writing, so I would warn off customers of this type of architecture. Also – moving to an external PSC, pre Update 2, is a terrible pain. Custom SSL Certs make it doubly so. Just my $0.02

    Great article, thanks for writing!

    Reply
  2. Rahul

    Great article, I have really enjoyed your article. Currently we are working on upgradation of SRM and we are trying to apply best practices for this upgradation so that we can get minimum impact on our environment .I will definitely apply these points at the time of SRM upgradation. Thank you for sharing these important points .All the points are really very important. Its really helpful. You did a great job . You have cleared my all the doubts in this article. Thanks once again for sharing.

    Reply
  3. Daniel Gachara

    Hey Awesome information right here, i would definitely motivate myself and my I.T counterparts to have in mind the points when Upgrading their SMRs

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*