The immediate loss of revenue from a data center outage or unplanned downtime is tangible and an easier amount to quantify.  We have built a Downtime Cost Calculator that helps you perform quick, back-of-the-napkin calculations to determine the hourly cost of downtime based on:

• Annual Revenue
• Retail Promotion
• Employee Productivity

We have also made it extremely easy to access directly from your smartphone by going to: rackspace.com/dt-calc

Our aim is to provide you with a simple and quick calculator, but we do understand that there are also several other less tangible aspects to consider such as negative impact to brand reputation, customer loyalty (defection to competitors) and SLA-related punitive damages to name a few.

If you happen to be at EMC World in Las Vegas, be sure to drop by our breakout session at 4 p.m. PST on Monday, May 6.  We’ll discuss the cost of downtime and how you can make your systems and apps more resilient.  Also, be sure to drop by our booth (No. 527) and try your luck at our interactive “Unlock the Cloud” touchscreen game for a chance to win a fabulous prize.

Calculating Downtime Costs
Monday, May 6
4:00 p.m. to 5:00 p.m. PST
Room: Murano 3205*

Rackspace offers a broad portfolio of resiliency solutions that can help protect and recover your important apps when disaster strikes. Visit rackspace.com/disaster-recovery-planning to learn about how our DR specialists can help remove the burden related to architecting, deploying and testing complex recovery solutions.

*Please note that the room is subject to change and you should check the EMC World Mobile Application when arriving onsite – just to confirm.

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

You’re Free to Test, But Testing Isn’t Free
Remember my first blog installment? I defined failover as 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. Testing failover and the subsequent failback can be challenging, especially for SMBs. It requires time, resources and a ton of planning.

It also involves risk. With a full failover/failback test, you’re putting your production workloads on the line. What happens if the failover, well, fails? Or if the failback doesn’t bring up your primary production environment as expected? This uncertainty is precisely why extensive planning must happen.

There’s a substantial cost related to every time you perform a full failover test including: the time it takes to plan, the personnel resources who are on hand to manage the failover and failback and any charges from the service provider for performing the full test.

Testing…1, 2, 3?
How often should you fully test the failover? Unfortunately, the answer is, it depends. Testing is needed at an interval that makes sense for your company and your budget. Your production environment is in flux – data is changing and growing, new code is being pushed for apps, operating systems are being patched, hypervisors and VMs are being added, bandwidth requirements are increasing, etc. As part of any sound DR strategy, it is recommended that you execute the failover runbook as part of a real-world test of the failover process.

While there is no substitute for a real-world test between data centers, there is a way to supplement this occasional drill with more frequent snapshot-based tests. You can quickly and affordably simulate how your replicated production VMs would respond if they were restarted in a different DC.

Some replication software or managed services offer the ability to create a snapshot of the critical VMs being replicated provided that you have enough extra storage space in the redundant infrastructure. This test only occurs in the secondary DC and doesn’t involve your production environment; thereby removing the risk and extensive planning required for a full failover test.

Take a look at the graphic below. It represents a snapshot-based failover test of the replicated VM 2. You’ll notice that the replication process continues uninterrupted, and the replicated VM 2 remains powered off. In Data Center 2, a snapshot of the offline VM is created, then powered on, tested and finally deleted. This test is quick, easy and doesn’t require planning or an IT team on hand. This test is contained in a sandbox environment and doesn’t affect your production VMs or even the replication process.

Although SMBs should still perform a full DC-to-DC failover and failback test, snapshot-based test can be done quickly and often. When major changes are replicated to the VMs in the secondary DC, an SMB can do a quick check to see if their critical apps will start up and run properly. More importantly, it can be done with no cost, minimal team distraction and zero risk to the production environment.

Quick recap…

• A full failover/failback test is challenging for an SMB
  • Requires time, resources and tons of planning
  • Puts the production environment at risk of becoming unavailable

• Testing still needs to happen because the production environment is changing/growing
  • SMBs can supplement full failover tests with more frequent snapshot-based tests
  • Snapshot-based failover tests remove risk to production, require very little time and team resources
  • It’s a cost-effective way to test major changes to critical replicated VMs

Want to learn more about VM replication and resiliency, and how to overcome these hurdles? Check out this presentation on SlideShare: VM Replication Is Your Lifeline When Disaster Strikes.

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

Complexity Question:  I can probably do it, but do I want to?
There are a couple different ways of looking at complexity from the perspective of the IT manager.  The first consideration is whether or not you have the expertise to architect, deploy and manage a replication tool that can be fairly complex.

Your IT department probably has the expertise to determine the reference architecture, how to implement the design, and also set up the monitoring and failover testing that’s required to help manage the replication process.  The second consideration, and perhaps bigger question, is do you have the resources to dedicate towards making this happen, and even if you do, is this the most beneficial use of your headcount?

I mentioned in the first installment of this series that IT budgets are already stretched thin.  Not only are budgets limited, but the expectations are to do more with less.  A study from Gartner (Amplifying the Enterprise: 2012 CIO Agenda) indicated the No. 1 priority for CIOs in 2011 and 2012 to be “increasing enterprise growth.”

I believe that this priority applies to SMBs just the same as it would to large enterprises.  The Gartner study mentioned above discusses what it means “to re-imagine IT.”  In other words, how can IT use its resources and headcount to better serve the company by helping acquire new customers and drive innovation – as opposed to just “keeping the lights on.”

I would argue that even though your team probably has the expertise to implement a VM resiliency solution, those resources are best used to help grow the company.  The SMB would be better served if you outsourced the heavy lifting to a managed hosting provider.  Not only do many of these service providers have VMware Certified Professionals (VCP), but they have already done a wide range of resiliency implementations for hundreds of customers just like you.

A managed hosting provider can help you architect and deploy the resiliency solution that best fits your risk requirements.  They will deploy the infrastructure in industry-leading data centers and have staff dedicated to monitoring your VM replication process around-the-clock.

Achieving geographic redundancy by hosting your business-critical VMs with a managed service provider will free up your team to focus on value-adding initiatives like the following:  building systems that have near real-time access to business data in order to deliver trending and reporting info that can be used to improve your customers’ experience.

When the “Scheisse” Hits the Fan
Pardon my German, but I’m going to go out on a limb here and say that your worst day at the office would probably be when unplanned downtime strikes.  Remember, it’s not a question of if an outage will happen, but when.  Being able to leverage an extension of your own IT team is like a lighthouse that will help guide your ship safely back to harbor during a torrential storm.

When evaluating various service providers, be sure to understand the levels of responsibility that fall on you, and the responsibilities owned by the hosting provider.  At the very least, a managed hosting provider should be able to assist you with the failover process in order to make sure this goes off without a hitch.

When it comes to affordable resiliency solutions, you’re usually responsible for executing your own disaster recovery (DR) plan.  This is the comprehensive strategy that encompasses processes, policies, people and technology.  As part of the DR plan, you should have a failover runbook that will cover the process once a major disruption occurs.

You should prepare for an outage by training your team for this inevitable event, testing your failover process often and communicating the next steps with all of the appropriate stakeholders and leadership.  Once a disruption occurs, you would press the “failover button,” so to speak, and initiate the process; this is when the support team from the managed hosting provider springs into action.

The responsibilities then shift to the service provider who assists you with the failover process.  As part of the managed-level of service, the provider is usually responsible for the replication tool, hypervisor layer, guest-OS layer, and also the dedicated hardware, network and the data centers.  This level of control coupled with monitoring tools, expert staff and 24/7 access will all help you get through – as Jack Bauer would say – “the longest day of your life” and bring back your critical apps as quickly as possible.

Quick recap…

• Just because you have the expertise, doesn’t mean you should do it
  • Outsource the heavy lifting to a managed hosting provider
  • Free up your resources so your team can  leverage technology to enhance the customer experience and support revenue growth
• When evaluating service providers, be aware of the levels of responsibility
  • Create a comprehensive DR plan that includes a failover runbook
  • Train your team, test the failover process often and communicate next steps with leadership and stakeholders so you’ll be ready to push the “failover button” when the Scheisse hits the fan

In the final installment, I’ll discuss the third challenge for SMBs – testing the failover process.

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.

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

Rackspace now offers VM Replication to Rackspace Managed Virtualization (VMware^®) customers in the U.S. VM Replication allows you to easily replicate selected VMs across Rackspace data centers. It’s a cost-effective resiliency tool that provides geographic redundancy and helps protect and recover VMs when disaster strikes.

Our VM Replication offering was developed with real customer replication needs in mind. We worked with customer Virtual, Inc., a leading association management specialist. Virtual was seeking a simple and affordable, host-based replication solution for their client’s fully virtualized environment, and decided that VM Replication was a good fit. Virtual engaged with Rackspace and served as a beta tester.

“I felt that Rackspace listened carefully to our feedback and even anticipated how we intended to use and implement the solution,” said Russell Kuhl, Vice President of Technology at Virtual. “We provided input that helped Rackspace develop a product that solves real-world replication scenarios. In turn, we’re very satisfied to have VM Replication as part of our customer’s broader disaster recovery plan, and the peace of mind that we can count on Rackspace to provide the reliable support we’ve come to expect, delivered with a personalized touch.”

Feel free to contact us if you want to learn more about how VM Replication fits into your DR strategy.