VMC DRaaS

I see disaster recovery as one of the best use cases for VMware Cloud on AWS and there is a good reason for it. Typically, the main requirement is to have a degree of geographic separation between the production and DR sites. That means a different datacenter and which automatically means that a lot of time and resources are consumed and capital is locked in order to create and maintain a reliable disaster recovery site.

For example, you have to:

  • Find a well-connected and reliable data centre
  • Procure all the servers, switches, firewalls, load-balancers etc.
  • Pay for utilities and connectivity to the primary data centre

to mention a few and then we’re all well-familiar with the procurement processes, delivery lead times and installation woes etc.

VMware Cloud on AWS = Cost-Effective DR

Companies need to take the TCO (Total Cost of Ownership) of such commitment into account when looking at the best DR platform for them and that’s where VMware Cloud on AWS shines. When all costs are taken into account, placing your DR environment into VMware Cloud on AWS makes a lot of sense.

Even better, there’s a good opportunity to cut the number of active hosts in the DR environment as compared to a traditional DR site. That’s because typically a safe number of hosts are procured for a traditional DR site so that they can take the load of the production site when required; even if they’re not consumed properly in normal operation.

A VMware Cloud on AWS based DR site allows the constant footprint to be reduced to the bare minimum as hosts can be added on-demand within minutes when required. That results in efficient sizing and in turn, cost savings that simply won’t be possible in a traditional DR scenario. Until recently, the one concern was the delay between the addition of hosts when scaling up the cluster.

At Cloud Field Day 7, it was revealed that rapid host addition is being introduced to VMware Cloud on AWS which will allow Elastic DRS to add up to 4 hosts at a time. I am yet to test it but it should go a long way in alleviating those scaling up concerns.

Still Expensive?

Is it possible to reduce the cost of this kind of disaster recovery site even further? The challenge that companies typically face is that a VMware Cloud on AWS deployment is rigid in its configuration and more specifically, storage. When lots of large VMs require DR protection, more hosts are required to replicate all that storage. Adding hosts for just storage – and not compute or memory – makes the solution more expensive than it needs to be.

A few vendors have unique solutions to get around that challenge. Rackspace is one of them and can make high-performance and flexible NetApp storage available to a VMware Cloud on AWS deployment, which complements that existing storage. What that allows is to reduce a DR environment down to 3 hosts, which is enough to run a “Pilot Light” environment. All the extra storage requirement is fulfilled by the external NetApp storage.

All this means that the DR deployment only needs 3 hosts in normal operation so the cost remains low. When the disaster scenario occurs, the environment can be scaled-up to rapidly suit the workload at the time. Once the event is over, data synchronisation and failback are done and the cluster is scaled-back down to 3 hosts again. The hosts added for the duration of the DR event are charged at “On-Demand” rates but it’s so much more economical than having those hosts permanently.

Conclusion

Building your DR environment on a VMware Cloud on AWS platform has the potential for significant cost savings, especially when you take the external storage option I mentioned above into account. Not only that but there are operational and lifecycle management benefits as well.

Hope this post goes some way in giving you a different perspective on how a cost-effective DR environment can be achieved by utilising VMware Cloud on AWS as the platform.

Disclaimer: I work for Rackspace and am the SME for the VMware Cloud on AWS DR solution with NetApp External Storage mentioned in this post.