In my opinion, one of the main drivers for this rapid level of growth is the fact that it is ‘as a service’ and not the complex and expensive ‘create your own’ environment that it used to be. As a result, this has made DRaaS much more accessible to the SMB market, as well as enterprise customers. But, as the list of DRaaS solutions grows along with adoption rates, it's important for customers to carefully consider how their choice of cloud provider should be influenced by their existing infrastructure. This will help to avoid technical challenges down the road.
The concept of Disaster Recovery
Before I delve into the key considerations for customers when choosing a DR solution, I should, for the sake of the uninitiated amongst us, explain what DR is. It literally means to recover from a disaster, and so encompasses the time and labour required to be up and running again after a data loss or downtime. DR depends on the solution that is chosen to protect the business against data loss. It is not simply about the time during which systems and employees cannot work. It is also about the amount of data lost when having to fall back on a previous version of that data. Businesses should always ask themselves: “how much would an hour of downtime cost?” And, moreover, “is it possible to remember and reproduce the work that employees, or systems did in the last few hours?”
When choosing a DR solution, what are the considerations?
In the past, customers would usually have resorted to building out a secondary data centre complete with a suitably sized stack of infrastructure to support their key production servers in the event of a DR undertaking. They could either build with new infrastructure, or eke out a few more years from older servers and networking equipment. Often, they would even buy similar storage technology that would support replication.
More recently, software-based replication technologies have enabled a more heterogeneous set up, but still requiring a significant investment in the secondary data centre, and, not forgetting the power and cooling required in the secondary DC, coupled with the ongoing maintenance of the hardware, all of which increases the overall cost and management task of the DR strategy.
Even recent announcements such as VMware Cloud on AWS, are effectively managed co-location offerings, involving a large financial commitment to physical servers and storage which will be running 24/7.
So, should customers be looking to develop their own DR solutions, or would it be easier and more cost-effective to buy a service offering?
Enter DRaaS.
Now, customers need only pay for the storage associated with their virtual machines being replicated and protected, and only pay for CPU and RAM when there is a DR test or real failover.
Choosing the right DR provider for you
When determining the right DR provider for you, I would always recommend undertaking a disaster recovery requirements checklist and regardless of whether you are choosing an in-house or DRaaS solution. This checklist should include the following points:
Performance
· Does the DR solution offer continuous replication?
· Which RTO and RPO does the solution offer?
· DRaaS – Does the Cloud Service Provider offer a reliable and fast networking solution, and does the DRaaS solution offer networking efficiencies like compression?
Support of your systems
· Is the DR solution storage agnostic?
· How scalable is the solution (up and also down in a DRaaS environment)?
· DRaaS – Does it offer securely isolated data streams for business critical applications and compliance?
Functionality
· Is it a complete off-site protection solution, offering both DR and archival (backup) storage?
· Is it suited for both hardware and logical failures?
· Does it offer sufficient failover and failback functionality?
Compliance
· Can it be tested easily and are testing reports available?
· DRaaS – Are there any licence issues or other investments upfront?
· DRaaS – Where is the data being kept? Does the service provider comply with EU regulations?
Let’s take VMware customers as an example. What are the benefits for VMware on-premises customers to working with a VMware-based DRaaS service provider?
Clearly, one of the main benefits is that the VMs will not need to be converted to a different hypervisor platform such as Hyper-V, KVM or Xen. This can cause problems as VMware tools will need to be removed (deleting any drivers) and the equivalent tools installed for the new hypervisor. Network Interface Controllers (NICs) will be deleted and new ones will need to be configured. This results in significantly longer on-boarding times as well as ongoing DR management challenges; these factors increase the overall TCO of the DRaaS solution.
In the case of the hyperscale cloud providers, there is also the need to align VM configuration to the nearest instance of CPU, RAM and storage that those providers support. If you have several virtual disks, this may mean that you need more CPU and RAM in order to allow more disks (the number of disks is usually a function of the number of CPU cores). Again, this can significantly drive up the cost of your DRaaS solution.
In some hyperscale cloud providers, the performance of the virtual disks is limited to a certain number of IOPS. For typical VMware VM implementations, with a C: drive and a data disk or two, this can result in very slow performance.
Over the past few years, iland has developed a highly functional web-based console, that gives DRaaS customers the same VMware functionality that they used to on-premises. This allows them to launch remote consoles, reconfigure VMs, see detailed performance data, take snapshots while running in DR and, importantly, perform test failovers in addition to other functions.
For VMware customers, leveraging a VMware-based cloud provider for Disaster Recovery as a Service delivers rapid on-boarding, cost-effectiveness, ease of ongoing management and a more flexible and reliable solution to protect your business.
