The Blog is Back!and I Made a Change!
Learn more featured post
May, 2010

If I Have VPLEX, Do I Need Site Recovery Manager?

As I’m flying back to North Carolina from my one whole day at EMC World I was thinking a bit about the announcements that EMC has made this week.  VPLEX is a very interesting product and I was going over possible use cases in my head. If money was no object, or if you needed VPLEX anyway, where does that leave VMware’s Site Recovery Manager?

With SRM you can do DR testing and failover, but with VPLEX and active/active data centers you can do seamless vMotions to another site. Should an unscheduled outage happen and given a geo-aware vSphere cluster couldn’t you almost just rely on the cluster handling it like a normal HA event?  Of course this assumes you have the capacity in the cluster, but you’d need that for SRM as well.  Do you need to do a formal DR test if you can just hot-move your systems over at will without disruption?  Understanding that you would need to test any non-virutalized systems, but it would greatly reduce the number.  You would need to test rebuilding a system from backup since VPLEX doesn’t offer any type of journal roll-back right now, but for standard failover it should work fine.

I realize that many people won’t have the resources or budget for a full VPLEX enabled environment but for those that do it may be an interesting option. In a lot of scenarios I’d also assume organizations would want an asynchronous replication capable VPLEX offering for longer distances and out-of-region recovery.  But, to me, this  yet again adds more reasons to virtualize all the applications that you can.  Virtualizing the tier 1 apps reduces your DR plan by a large amount with SRM and this would make it even simpler.

But it’s something to consider.

7 thoughts on “If I Have VPLEX, Do I Need Site Recovery Manager?”

  1. Jason – thanks for the post, and the thoughts. For what it’s worth, an SRA for VPLEX is committed, so there’s an answer 🙂

    While VPLEX enables distance vMotion, SRM is the “site”/over distance version of VM HA. In otherwords – vMotion is all about “everything is up, and move”, and VM HA/SRM is all about “uh oh, something happened, workflow the process of restarting”.

    With a VPLEX SRA, you would be able to do both with just one replica.

    There are caveats we’re still working through.
    – SRM expects two vCenter instances. you can vMotion between clusters, but not between two different vCenter instances.
    – VM HA behavior is missing the degree of sophistication to make stetched clusters a good idea, but that’s not intrinsic. Working on that one with VMware.

    Good thinking though!

  2. Hello,

    This is a nice post and the exact question came to my mind, when I started to digest the VPLEX staff.

    Are there any plans to have volume journal roll-back in VPLEX as it is now in the RPA?

    Anybody willing to compare the major features or pointing out major differences between EMC VPLEX and Falconstor NSS Gateway? OK, I see at least one – VPLEX has its unique cache coherency directory (distributed cache), but is it a real benefit?


  3. This post is very old and some may misinterpret the content, want to add a bit of clarification and update.

    A lot has changed since May 2010, both from an EMC VPLEX perspective as well as a VMware perspective. Many restrictions and concerns for implementation of VPLEX-Metro have been mitigated. Some of the issues mentioned such as HA behavior and sophistication such as split brain handling of VMware have had huge improvements and the decision to use SRM vs VPLEX-Metro must be consider on a case by case basis. Some use cases are a good fit for SRM some are not depending on what you are attempting to accomplish. Same can be said for VPLEX and any other technology on the market. No one solution meets every and all needs.
    EMC has large population of customers that have chosen to implement VPLEX-Metro to both allow greater IT agility as well as increase availability. In fact VPLEX-Metro is the highest % of deployments and these are typically VMware stretched clusters and in these absence of an SRA was not factor.

    Also keep in mind, SRM is not without its failings. We have many successful implementations, but we also hear the complaints and compatibility issues like SRM cohabitating with other VMware provided solutions without introducing complexities in operations. I point this out not to knock SRM or VMware as I love the solutions and have been a long term advocate. The point, just because a tool works well in one use case does not mean it works well for all. Understand the use case, pick the right solution that meets the priorities you have.

Leave a Reply

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