VM Replication & Resiliency: Three Common Hurdles For SMBs Part 1: Cost

Geographic redundancy is not just for big enterprises.  Small and medium-sized businesses (SMBs) can take advantage of it to protect their critical apps and keep downtime to a minimum.  How, you ask?  Well, if you’re running the apps on VMware virtualization, then VM replication technology and expert managed hosting are a good place to start.

In this three-part blog series, I’ll cover the following common challenges that IT managers face when considering a resiliency solution.

Top 3 Challenges:

  1.  Cost
  2. Complexity
  3. Failover Testing

Conquer Cost
In a 2012 Gartner Research report, Gartner interviewed hundreds of their clients and found that “affordability” was one of the three core criteria used to evaluate solutions that provide “IT resilience.”[1]  Given that IT budgets are already stretched thin, it’s no surprise that cost is top of mind when reviewing a resiliency tool.

Here are some reasons why replication can be expensive:

  • You pay for the same expensive device on both ends (like SAN to SAN in traditional storage replication)
  • VMs on both sides are powered on all the time so you pay for both source and target
  • You can’t pick only the ones that you want to replicate, leading to unnecessary costs, etc.

There are several ways of replicating a virtualized environment between two disparately located data centers (DCs).  Two common ways are host-based, and guest-based replication.

Guest-Based Solutions
With guest-based replication, it would be like owning two homes: a main house that you live in 50 weeks out of the year, and your vacation home that you visit for two weeks in the summer.  In the guest-based scenario, the lights in your summer home would be turned on all the time.  Whether you’re vacationing there or not, you would have to pay for the electricity cost of the summer home, on top of the electric bill for your main home.

Guest-based replication occurs at the VM layer and utilizes each VM to control its own replication process.  A VM in the primary DC would replicate the data changes to its active counterpart in the target DC.  The replicated VMs on the target site must be powered on because they help manage the backup process.  You end up paying licensing fees for both the source and target VMs.

Host-Based Solutions
Keeping with the summer house analogy from before, having heterogeneous infrastructure in the two data centers would be like owning a large four-bed home with an attached two-car garage, and a summer house that’s a one-bed beach bungalow located in Cabo San Lucas.  You leave the three kids at the house with grandma when you go on vacation, so you don’t need the extra space and storage for a whole family.  Downsizing to a thatched hut is a perfect fit.

Host-based replication is controlled by a virtual appliance (VA) that runs at the hypervisor layer in both the primary and secondary DCs.  In host-based replication, you can handpick just the important VMs that you would like protected.  The VA replicates these active VMs to the secondary DC where they’re stored in an inactive state.

In other words, the replicated VMs in the target site remain powered down, meaning you do not pay for them during active replication. You only pay for the target VM when a failover is initiated.  Failover is the process of switching to the backup infrastructure in the secondary DC after a major disruption causes the apps in the primary data center to become unavailable.

Infrastructure Costs
In addition to the replication method, you should also consider the costs that are related to the additional infrastructure needed for geographic redundancy.

As I mentioned before, with host-based replication, the critical VMs that reside in the target DC are powered off.  This is important because it enables you to take advantage of the idle capacity in the secondary DC by using it for other purposes like a test or dev environment.  Finding other uses can help justify the additional cost of redundant infrastructure.

If you only replicate the most critical VMs and not the entire environment, then you probably don’t need to reproduce the exact hardware setup that you use for production.  The infrastructure in the target DC could have a smaller footprint than the source DC – fewer servers, less cost.

Another option that you could consider is using less powerful servers and storage in the secondary data center.  Target infrastructure could be designed to use less expensive equipment so that the backup VMs would run with degraded performance for a short time until you failback to the primary DC.  Depending on your needs, a temporary performance degradation may be acceptable.

Quick recap…

  • Host-based replication is economical for SMBs
    • Pay only for source VMs until failover
    • Replicate just the critical VMs, not all of them
  • Infrastructure considerations in target DC:
    • Repurpose to help justify added cost (e.g. dev sandbox)
    • Pare down server and storage performance to save money
    • Downsize footprint to accommodate only the critical VMs

In the next installment, I’ll review how SMBs can overcome the complexity of architecting, deploying and monitoring a sophisticated resiliency solution.

Want to learn more about VM replication and resiliency, and how to overcome these hurdles? Check out the recording of this webinar: VM Replication Is Your Lifeline When Disaster Strikes.

[1] John P. Morency, Kevin Knox, “New Evaluation Criteria and Provider Capabilities Are Changing Disaster Recovery Sourcing,” Published by Gartner, Inc., 2 March 2012, p. 3

Brent is a Product Manager for the VMware Cloud Practice. Prior to product management, he owned solution marketing across the Rackspace Managed Private Cloud portfolio. A Racker since 2012, Brent has more than 15 years in software, cloud and managed IT services focusing on product lifecycle management, product strategy and roadmap, implementation of agile principles, go-to-market strategy, content marketing and sales/partner enablement. He hails from Southern California, but currently lives in Austin. While working for DreamHost in Los Angeles, Brent founded the OpenStack LA user group. On weekends, you might find him on a stand up paddle board floating down Lady Bird Lake, or riding his mountain bike down the trail. You can follow his cloudy interests on Twitter @BrentScotten.


Please enter your comment!
Please enter your name here