vSphere 5.1 game-changer has big impact on disaster recovery
- select the contributor at the end of the page -
What is disaster recovery (DR)?
Business continuity is critical to all organizations and a properly developed disaster recovery plan may determine the ability of a business to continue after a disaster strikes.
A disaster recovery plan is an attempt to make a list of possible disasters and being as prepared as possible to deal with them. A disaster usually implies a major event that affects the whole business from a specific site, thus forcing the business to relocate many of its critical operations to another site. Our role as IT professionals is to envision such scenarios and their impact on the computer/server room or the data center.
Of course, the possibilities for disasters are endless, and even the most creative imagination cannot consider every possible scenario. Also, guarding against every disaster costs money, so you create a business continuity plan based on your budget, the probability of the disaster and the impact on the business.
A plan may be as simple as shipping backups offline to be able to restore them somewhere else or as expensive as replicating everything in the active site to another DR site. Often, a plan is a combo of many methods.
How virtualization changed disaster recovery
In the past, a disaster recovery site included a number of servers almost identical to the production servers in specs and capabilities. Those physical servers may spend their useful life unused, waiting for a disaster that hopefully won't happen. Moreover, expensive storage-based replication was, in many cases, the only option available to reproduce changes written on the production systems on the DR site. Storage replication often needed an identical expensive storage from the same vendor.
Just how expensive? My employer paid $1 million for production storage, DR storage and the necessary licenses for about five years ago. We were told that the blade servers, the fabric switches, the fiber-to-IP transceivers, the fiber SAN and everything else needed to be from the same vendor to insure stability.
Cost and vendor lock-in were not the only concerns I had with this solution: The whole idea was based on a run-book of tasks that administrators have to perform manually if a disaster strikes. The plan was not easily testable and the only chance we had to test it was for the relocation of our data center to a new headquarters. After months of preparation, it took more than 24 hours of continuous work to get everything up and running again. If it had been a real disaster that might have required a substitute administrator to follow the run-book, it would have taken even longer.
Transforming servers into virtual machines detaches the operating system and any applications running on it from the underlying hardware, thus enabling it to run on servers that can be different in specs, configuration and/or vendor. VMware Site Recovery Manager (SRM) adds to that a fully automated run-book that provides non-disruptive testing.
Storage-based replication used to be a requirement for SRM. That changed during VMworld 2011, when VMware introduced hypervisor-based replication as part of SRM 5.0. This meant a huge cut in costs for organizations planning to build a disaster recovery plan. vSphere Replication allows the use of dissimilar storages, saving on the storage licensing costs and even letting you use local disks to hosts VM replicas. In addition to cutting costs, vSphere Replication is all about flexibility. For example, you can protect VMs individually, as opposed to protecting the entire VMFS datastore.
So what is new in vSphere Replication 5.1?
The most significant difference in 5.1 is that vSphere Replication is available at no extra charge and comes as part of the vSphere platform, whereas in 5.0 it came only with an SRM license. This makes disaster recovery more affordable to even SMB customers who are using the vSphere Essentials Plus.
As with all new features in vSphere 5.1, vSphere Replication is only managed using the web client. The new vSphere Replication is an easy-to-deploy virtual appliance that uses its own internal database. Each deployed vSphere Replication Appliance can be used to configure and manage replications for up to 500 virtual machines. By using its built-in database, VMware has greatly simplified the deployment of vSphere Replication.
To save bandwidth, it replicates only changed blocks and can even be configured per disk. For example, you can put your OS swap on a separate disk and exclude that from replication, as it will be useless anyway for a recovered VM. Moreover, vSphere Replication does not care if your primary disks are thin or thick, and it is independent of snapshots.
To save time and bandwidth, vSphere Replication can use a seed VM. For example, you can export the primary VM to external media then import it on the secondary site to be used as target for replication. Changes are tracked and the target VM is brought in sync with the primary, using as little bandwidth as possible to replicate only the differences since the VM was exported. Even if moving an exported VM is not easy, you may use a freshly installed VM of the same OS as a seed to save from replicating common OS files.
The new vSphere Replication has greatly improved integration with Microsoft's Volume Shadow Copy Services (VSS) to ensure application consistency when replicating VMs. This is especially important for applications like SQL and Exchange. vSphere Replication does not only request OS quiescence, it also asks the VMware tools to flush any application or database writes before taking a consistent replica.
Are there any downsides to vSphere Replication 5.1?
One of the most notable limitations of vSphere Replication is that it has a minimum recovery point objective (RPO) of 15 minutes and a maximum of 24 hours. A lot can happen in 15 minutes and for some businesses, the data lost in that amount of time is simply unacceptable. Those businesses may still need to rely on storage or application synchronous replication. Synchronous replication means that any write operation is not confirmed to the front-end application until the data is written to both the primary and secondary sites, ensuring that if a disaster happens, there is no loss of data.
Another significant limitation is that vSphere Replication only replicates turned-on VMs. This means that you cannot use it to replicate templates across sites and you cannot replicate a collection of ISO files in a datastore.
Like many other vSphere features, vSphere Replication is not supported with VMware Fault Tolerance. It is also not supported with linked clones or with Physical RDM. However, you might be surprised to learn that vSphere Replication is not supported with Storage vMotion and Storage DRS.
vSphere Replication implementation
At this point, I am sure you are eager to test vSphere Replication and learn about the common implementation scenarios. In an article next week, I will explain in detail how to integrate vSphere Replication in a single vCenter environment and across sites that are managed by different vCenters. So stay tuned!
Ready to test your skills in VMware? See how they stack up with this assessment from Smarterer. Start this VMware test now.
