Torbz - Fotolia
Virtual disaster recovery is without a doubt a great boon to the disaster recovery as-a-service world. When providers manage and control disaster recovery expenses, customers know what their approximate spend is and can budget appropriately. However, when the disaster recovery setup is created in an ad hoc manner, it can get expensive very quickly.
When a virtual disaster recovery as a service (DRaaS) infrastructure is first set up, it's new to not just the consumers and end users but the administrator as well. This is where most providers make their first mistake regarding disaster recovery setup costs. Often a proof-of-concept DR setup or limited rollout fails to appropriately take into account the chargeback for the true cost of the service.
During the initial disaster recovery setup, those involved tend to be more concerned with performance, proof of concept and utility over price, which is not a good way to look at such a critical item. Once a customer has a bill for the initial trial phase, they expect that cost to be consistent. Customers love consistency from service providers.
Be mindful of resources
After a provider successfully works out its virtual disaster recovery setup, often the people who put the system in place and test it are not the same people who determine the pricing and costs. What many admins forget is that during the initial setup, the items that are put under virtual DR are the low-hanging fruit and do not consume a "normal" amount of resources.
To give an example, a web server or basic application server will not consume vast amounts of resources as the rate of change is relatively modest. However, if someone creates a new, complex virtual machine (VM) for a database server, the rate of change can potentially be astronomical.
If every changed block must be replicated across the WAN, it can create unexpected resource issues in terms of DR bandwidth, as well as the DR production side having the resources to cope. The more blocks an organization needs to replicate, the more memory and CPU it requires to keep up to date and store these changes before they are shipped across the WAN.
It also affects DR setup in a different way. The more disk blocks that change, the bigger the journal history that tracks all the changes needs to be. One example is an instance where the journal size becomes greater than the size of the protected production VM.
Don't forget testing costs
It isn't just the technical aspects of a disaster recovery setup that can cause issues. Obviously, the organization needs to test DR periodically to make sure that it works as expected. If the provider needs to pay for out-of-hours DR tests, it is key to figure out the cost of the administrators performing the failover and build it into the overall setup cost model.
The following are three steps a DRaaS provider can follow to accurately figure out the total costs of virtual disaster recovery setup:
- Ensure any DR agreement is not a flat rate agreement. Someone must pay for the resources used. You want it to be the customer, not you, the provider. This includes not only the data that makes up the VMs, but also the journals and point-in-time copies.
- You must track and compress all changing data sent across the WAN, with acknowledgment of receipt. This ties up RAM and if the administrator suddenly has to double the RAM on all the replication appliances to handle massive rates of change, it gets very expensive.
- Lastly, work out a cost model for both real and test DR events. Make it clear what is included, what is not included and the cost. That way, both customer and provider understand the cost of scheduling failovers.
Providers need to work out and test disaster recovery cost before it is deployed to customers. The team providing the service needs to ensure that they understand the costs that can be incurred when a VM doesn't fit the expected limits of the model.
When it comes to disaster recovery setup costs, it should not be one size fits all. Factor in size, rate of change, bandwidth costs for those rates of change and the resources that will be required to support the DR setup.