ATMCOMIO

Taking the Challenge Out of Public Cloud Disaster Recovery

Old school disaster recovery is hard. It’s also expensive. The DR paradigm that involves redundant hardware in a secondary data center has long been accepted as a necessary evil. However, in recent years, the growing availability and practicality of public cloud resources from organizations such as Amazon Web Services has created interesting dialogue in the DR arena.
It seems that maintaining an entire secondary data center full of highly complex systems (which also happen to be quite expensive) might not be the only way to protect a data center anymore. Perhaps replicating business-critical data and applications to somewhere like AWS would allow greater efficiency and flexibility in the disaster recovery strategy.
As organizations have looked at this option in the last few years, there’s been a common refrain that seems to be getting louder and stronger: “We like the idea, but it’s too hard to estimate the costs. It’s also a completely different skill set, and we’re concerned that our team couldn’t support it.” Indeed, using the public cloud as a DR target and failover location can be quite challenging.

Public Cloud DR is Hard

There are a number of different challenges associated with replicating on-premises data center contents to somewhere like AWS. Not the least of which is the fact that the AWS platform is totally different to manage than a traditional on-prem system like VMware vSphere. Making this transition would require the operations and design staff to learn how to use components on both sides (vSphere and AWS) in order to make sense of things. Is a VMware ‘datastore’ equivalent to an EBS volume, or does that map more closely to a VMDK file? There’s substantial overhead in learning all of this.
Secondly, the pricing models can be incredibly hard to use accurately. Determining the real world cost of your DR strategy in the public cloud is notoriously prone to miscalculations and often ends up costing far more than anticipated. Right-sizing – the process of determining whether virtual machine instances are allocated just enough resources – between on-premises VMs and AWS instances has also proven to be a substantial challenge. Due to various mechanisms for increased efficiency, density, and availability, the resources a virtual machine requires in a vSphere environment might be significantly different than what it takes to run it in AWS. Guessing wrong here can be quite costly.
Last, orchestrating and testing failovers between a primary data center and a public cloud based data center can be tricky at best, and could even involve data loss or downtime at worst. Again, the stark difference between on-premises and public cloud platforms makes the interaction between the two a bit of a challenge.

Enter OneCloud Recovery

There’s a light at the end of the tunnel, thanks to OneCloud Software delivering a set of tools to help administrators leverage AWS as a DR endpoint and failover site without the headaches described above. From the very first interaction, the OneCloud software begins to remove complexity and doubt about a public cloud DR strategy.
With a simple and intuitive interface, OneCloud Insight enables the automated discovery of your on-premises environment. OneCloud Insight then takes input from the user such as RPOs for selected workloads and network bandwidth specifications. It uses all the discovered and user provided information to create an accurate model of what the DR side of the equation should look like.

The OneCloud Insight interface
The OneCloud Insight interface

After the initial setup of OneCloud Recovery is complete and you’ve provided the proper access to the system on both sides, it goes to work creating a complementary AWS Virtual Private Cloud to use as a DR site. [Note that a OneCloud Insight model is not required to begin using OneCloud Recovery; this is an optional service.] This is a major component in the public cloud DR challenge eliminated; creating a VPC (or similar construct) to accurately represent your production network and systems can be a serious challenge due to the associated learning curve and/or lack of directly comparable constructs. OneCloud software uses Amazon API’s to do it all for you, correctly.
Traditional disaster recovery implementations – especially at larger scale – require a significant number of different infrastructure components. Part of the beauty of the OneCloud Recovery solution is that it’s everything you need in one solution. As an example, an enterprise DR implementation would likely include WAN accelerators at both the primary site and the DR site. With OneCloud software, this function is baked in and a separate solution isn’t required. It’s all managed from the slick UI shown below.
The OneCloud Recovery dashboard
The OneCloud Recovery dashboard

Once the system is up and running, its quite simple to configure groups of systems with different SLAs, tune the failover plan, and view statistics about your current state of protection. One of the major advantages to leveraging OneCloud over building the DR solution by hand is that almost no knowledge of AWS is ever required. This makes the solution much more approachable to the average VMware administrator or systems generalist.
Configuring Virtual Machine Groups for different RPOs and replication times
Configuring Virtual Machine Groups for different RPOs and replication times

Try It!

It’s easy enough to see how OneCloud Recovery will be able to help you. Using the form in the link below, you can sign up for a free 15-minute assessment where OneCloud Software will help you leverage the Insight tool to begin modeling your potential DR scenarios. With no risk, it can’t hurt to give it a look!
http://hubs.ly/H01RyPF0