Can you remember how disaster recovery (DR) used to be achieved for companies before virtualisation technologies were available?
For a company's server estate, it normally meant deploying an expensive identical redundant physical server at a DR site with a 'hot standby' 1:1 mapping of server hardware. Typically the server needed to be the same brand, model, configuration (CPU and RAM), firmware version, operating system version and patch level.
Most of the time the servers and applications in the DR site also required access to physical storage arrays and tape backup/restore facilities. In the event of a disaster, the storage data and server apps would need to be quickly recovered using notoriously unreliable data tapes, disk-based backup, or via real-time replication.
Of course in the 'physical' world the reality was that DR was rarely invoked, required many complex procedures, took a long time to plan and complete and had huge capex and opex costs associated for manpower, hardware and facilities.
So, what's the best way to take advantage of virtualisation technology for DR?
Most organisations have now made use of hypervisors, such as VMware vSphere or Microsoft Hyper-V, which enable a single physical server to run multiple virtual servers on top of the hypervisor. Hypervisors can eliminate hardware compatibility problems, VMs run on virtual hardware that is emulated by the hypervisor and there are no hardware compatibility issues caused by differences in the underlying physical hardware.
From a disaster recovery perspective, a hypervisor platform deployed at a primary site can site can easily be expanded and built upon with a subset of the virtualisation infrastructure components deployed at a secondary site. When deploying the virtualisation platform at both the primary site and the secondary sites, organisations can use different physical hardware without having to deal with compatibility issues. This portability means the heavy burden of a 1:1 physical server mapping between the production and DR sites is eradicated.
Organisations are then able to replicate virtual machines using storage replication or in-built virtualisation replication to the hypervisor platform at the secondary DR site. Replication will provide a mirror copy of the virtual machines from the primary site to the secondary DR site, allowing the second site to take over in a DR scenario.
The actual failover of virtual machines from the primary to the secondary site in the event of a disaster can be a manual, semi-automated or fully-automated process based on vendor and operation toolsets which use scripting and orchestration. Failover testing and recovery can also be further enhanced using bolt on automation products like VMware Site Recovery Manager (SRM), which can build complex recovery plans that can test or invoke DR failover and failback at the push of a button.
In short, the main advantage of using a virtualised platform for disaster recovery is the portability of virtual machines being decoupled from the underlying hardware, which allows for a far more flexible DR capability to be realised, reducing costs, providing increased flexibility, and ensuring recovery point objectives (RPO) and recovery time objectives (RTOs) can be met when compared to traditional DR methods. If organisations have not already done so, they should review their current DR methodologies, procedures and capabilities to understand how they can leverage their investment in virtualisation technologies to provide cost effective, flexible DR platforms.
Del Lunn is a principal consultant at GlassHouse Technologies.