- Solid and reliable replication of virtual machines
- Good use of network, disk and CPU resources on ESX Server systems
- Excellent configuration options for email reports
- Requires 32-bit Windows Server 2003
- Recommended for use only with LAN connections
- Tricky process for activating a replicated VM
First launched in February and updated to version 2 in May, Double-Take for VMware Infrastructure is a new entrant to the field of virtual machine (VM) replication tools designed to work specifically with VMware Virtual Infrastructure. Unlike some competitors’ claims about their own products, Double-Take says its software is designed for LAN environments and should not be used with WAN links. The minimum installation requirements are two systems running VMware ESX Server 3.x, plus a third server running a 32-bit version of Windows Server 2003 and the VMware VirtualCenter 2.x management console.
The suite makes replicas by taking a snapshot of the VM’s disk and sending that along with the original disk to another ESX Server system. Replicas are maintained by making a new snapshot of the virtual disk and sending this snapshot to the replica after a specified time period, or once it reaches a specified size threshold. By default, update snapshots are sent once they total over 32MB or after 15 minutes, whichever occurs first.
We installed Double-Take for Virtual Infrastructure (DT for VI) on the same server as our VirtualCenter software. The first thing the installer did was ask if we wanted to check for a newer version of the software. We used this option and discovered there had been a minor update. Unfortunately we needed to acquire a new licence key in order to download the update. DT for VI needs Microsoft .NET Framework 2.0 to be installed, and will add it to your system during installation if it is not already present. Like many system management tools, DT for VI can send emails confirming what it has done and reporting errors. We were pleased to discover the ability to enter credentials, in case your mail system requires a username and password before sending mail, and a button to send a test message to confirm that the email settings work properly.
After installation, the software runs a wizard to create a new replica. The time needed to replicate a VM varies depending on the size of the original virtual disk and any subsequent snapshots that need to be sent with it.
The first VM we replicated was a small DNS server handling a few LAN clients. This VM is stored on a 4GB virtual hard disk, which is hardly ever written to during a normal day. The first wizard screen asked us for the source server and its root — or main system admin — password. We were a little concerned that we needed to supply only the root password for our VMware servers. Most people consider it inadvisable to allow the root user to log in directly to a server from a remote connection, and the default configuration of a VMware ESX 3.x server actually prevents this. Some other products log in with a non-root user and then boost their privilege to root after they are connected.
The wizard then provides a list of VMs and asks which one to replicate. Those that already have replication configured are shown in grey and cannot be selected for replication to an additional server. Having selected the destination server and supplied its root password, the next step is to tell the wizard which disk volume to use for the replica. DT for VI then checks the available space on the volume and will not authorise a replication job if there isn't enough space on the destination disk. The next screen allows some fine tuning, such as enabling data compression and adjusting the snapshot threshold size. A particularly nice touch is that you can enter a custom list of email recipients for each replication job using this screen. Replicas can also be renamed from this screen, and we like the fact that by default replicas end up with the same name as the source VM but have the word ‘Replica’ added to their name. This makes it much easier for administrators working with replicas to avoid confusing the replica with the original while booting or deleting VMs, for example.
Replication of our DNS server took just over 70 minutes, with subsequent updates taking around 9 minutes. Unfortunately our first replication job failed as soon as it started because our VMware servers were configured to prohibit the root user from remotely logging into the server. We needed to edit a configuration file on the destination VMware server to enable root access before the replication jobs would start properly. Another snag is that administrators must not make or delete snapshots of VMs for which DT for VI is maintaining replicas. Although there's no mechanism to actually prevent administrators from accidentally making such snapshots, doing so would cause unpredictable results on both source and destination VMware servers.
However, we were pleased to see that replication does not appear to run at the maximum speed of the disks or network. We like this as we have seen time-outs from services provided by VMs when the host servers are busy replicating big VMs using other products.
Unfortunately switching over to the replica uses a manual process and so requires some experience with VMware ESX Server and VirtualCenter. For example, replicas do not normally appear in the VirtualCenter hierarchy of VMs present on each server. Instead, if you want to boot a replica you must first stop DT for VI from monitoring its source VM. You then need to check the source VM is powered off or disconnected from the network to avoid conflicts. Finally, you need to register the replica VM with VirtualCenter. We would like to see this process automated for the user by a future version of DT for VI.