Virtualization is everywhere. I can safely say that without the hyperbole police coming to take me away, right? Just in case you haven’t had any dealings with virtual server solutions, many manufacturers have created software solutions that will allow you to create and manage virtual machines – allowing one physical server to host multiple virtual servers, each with its own OS and virtualized hardware components. Less physical hardware makes virtualization technology a great choice for Disaster Recovery (DR) operations, as physical infrastructure can be one of the largest line items in your DR budget.
Ranking up in the top slots for virtual vendors are VMware and Microsoft with their competing virtualization platforms; ESX Server and Hyper-V, respectively. While both have a ton of benefits and at least some drawbacks, we’ll avoid that discussion here. What I would like to talk about is how Double-Take Software has created a technology set called the Virtual Recovery Assistant (VRA) that can help you leverage virtualization from either vendor in either the production or DR locations – or both.
VRA is not a stand-alone product, but rather is included as a feature set in Double-Take Availability, Move and Livewire. It will also be a feature set in Double-Take Backup, due later this month. The VRA technology allows you to move server systems from any Windows platform in production (virtual or physical) into a virtual machine on either a VMware ESX Server host or a Microsoft Hyper-V host.
For failover protection with Double-Take Availability, you will create one or more virtual machine guests that will house and run the VRA Appliance, or helper, system. You’ll need one VRA helper for each instruction set of Windows you have that needs to be protected. For example, if I have four servers that are running Windows 2003 x86, five servers running Windows 2003 x64 and two servers running Windows 2008 x64, I will need a total of three VRA helpers, one for each OS variant. Each helper can natively support up to 14 protected volumes, so the total number of data and system volumes protected by each helper cannot exceed that number. As with most Double-Take Software products, we use Microsoft’s definition of a “volume” mounted to a Windows server to define how many volumes are being protected. Note that you can exclude any volumes on the production server except the system volume (typically C:). If you do have more than 14 volumes total, you can create multiple helpers to handle the load.
Once the helpers are installed with Windows, install the correct version of Double-Take Availability to complete the setup. Then install Double-Take Availability on each production server you want to protect, and optionally on one or more desktops or laptops for administrative purposes. You can manage Double-Take Availability from one or more of the servers if you prefer, but the Client Tools are provided free of charge to make remote management easier.
Once installed, the system is wizard driven. Just use the Virtual Recovery Manager instead of the usual Double-Take Management Console to perform your protection configuration. You will need to use this wizard to first declare your helper VM as a Virtual Recovery Appliance. During this process you’ll be asked to log into either vCenter, or the VM host that the helper resides on for administrative purposes.
The process for protection is relatively straight-forward. Follow the steps of the wizard to set up a protection job from one of your production (Source) servers to the appropriate helper. The wizard will ask you where it should create the virtual hard disks that will make up the replicated data set, and any disk resource that the helper’s VM host can see will be a viable choice here. Once created, the new virtual disks will be attached and mounted to the helper, ready to act as a Target system for that production server.
Replication occurs from the production system, through the helper, and onto the virtual hard disks. Other than using the helper as a Target, the process is the same as you would see between any other Double-Take Availability Source and Target server setup.
If a production server is lost, the failover progresses much differently than it would in a traditional Double-Take Availability setup. Instead of the Target either assuming the role of the production workload or (with Full Server Fail Over) becoming the production server itself, the helper will spawn a new VM guest to take over the failed server’s workload. This VM guest is configured using the settings you gave the system in the Virtual Recovery Manager wizard when you set up protection. It is created during the setup process, but is kept offline – and without any virtual disks attached – until failover is initiated. During the recovery process, the virtual disks are detached from the helper (only those for this particular protected server, of course) and are attached to the VM guest that will be used for the workload failover.
VRA will make the necessary changes to the system virtual hard disk before it is detached, so that even if you were coming from a physical machine in production, you can safely recover to an ESX or Hyper-V host in DR. Once the changes are complete and the detach/reattach operations are performed, VRA will boot up the resulting new VM guest. This brings the failed workload back up and online, now running as a VM guest on the DR VM host systems. Other than physically moving from he production server, the recovered VM will be a clone of the failed production machine. The name, SID, GUID, programs and non-hardware configuration will match what was on the original production server.
Since VRA is just a feature set of Double-Take Availability, it’s common to use the Full Server Fail Over tool set (another feature of DTA) to perform failback operations once the production hardware is either repaired or replaced. This allows you the freedom to return to the original hardware or bring in brand new hardware if desired or necessary. If preferred, a VRA helper can be established on a production VM host to allow for VRA recovery for failback purposes as well.
In addition to emergency failover operations, VRA can be very effectively used to permanently fail over to a VM guest for the purposes of migrations. As a matter of fact, the VRA components in Double-Take Move were specifically designed with this in mind, though if you own full licenses of Double-Take Availability, this functionality is available to you as part of the VRA system in that product line.
The benefit to using VRA as opposed to just failing over to VM guests you configure ahead of time is that, with VRA; you only need to provision one helper for each instruction set and/or every 14 volumes protected. That means that entire production environments may only require a few helpers, dramatically reducing the number of machines you must have running in your DR site in order to provide protection. The reduction in spinning VM’s means less management overhead, less power consumption day to day and less overall headaches – without giving up the ability to perform failovers whenever you need to. VRA will auto-provision the VM guests required as they’re needed.
VRA has been around for a few years now. As VMware and Microsoft have continued to develop and expand their virtualization offerings, Double-Take Software has continued to develop and expand VRA to take advantage of all the new features and functions. Since our clients have shown an overwhelming acceptance of the VRA technology, you can expect even more innovations as we continue to push the limits of virtualization for migrations and Business Continuity Planning.
Filed under: Business Continuity, Cloud Computing, Disaster Recovery, Double-Take Availability, Double-Take Move, Hyper-V, VMware Infrastructure, VMware vSphere, Virtualization, Workload Availability
