Launched on 4 September, vReplicator 2.1 is the successor to Vizioncore’s esxReplicator 2.0 virtual machine (VM) replication suite. The update is a good choice for datacentres needing to create and maintain replicas of VMs that can be run on secondary servers in case something goes wrong with the original.

The change of name indicates that a future upgrade may support other virtual server environments, such as the open-source Xen hypervisor, or Microsoft’s forthcoming Virtual Server.

New features in vReplicator 2.1 focus on improving reporting and ease of use. For example, the suite now uses a Microsoft SQL database to keep track of replication jobs. Rather than searching through text-based log files, administrators can easily view a list of jobs and drill down into the list to get more information.

Another improvement is the ability to test and perform failovers from the original servers to their replicas, a feature currently missing from competing products. Making sure the replicas actually work as intended is extremely important for the validation of datacentre backup and disaster recovery strategies.

We were also pleased to see improved scheduling of updates. A new feature in 2.1 enables updates to be timed so they occur at regular intervals, regardless of how long each update takes to complete.

VReplicator runs on Windows XP SP2 and Windows Server 2003, and requires two or more servers running VMware ESX Server 3.x to act as the source and destination servers for the replication jobs. Our primary ESX Server was a twin CPU Intel Xeon-based server attached to a 2Gbit/s SAN, 1000BaseT LAN and a Raid array that could handle about 50MB/s. Our secondary server had a single CPU and one SCSI disk

Installing the suite on the server running Windows 2003 Small Business Edition took the best part of 30 minutes, though installing the Microsoft SQL Express included in the Vizioncore package rather than using an existing datab ase accounted for much of the time. Like other Vizioncore software, vReplicator also requires Microsoft .Net Framework version 2.0.

During installation the suite gathered some information about our environment from the previous version, including a list of existing replication jobs. We were also asked for details of a mail server that vReplicator could use to email reports on how each replication job was processed.

Compared with some products with similar email facilities, vReplicator seemed a little basic. For example, it does not support email user authentication or SSL-style encryption.

We were impressed by the new reporting facilities, which made it particularly easy to see how various replication jobs had progressed. Previous versions of the product produced unreadable log files that needed to be sent to Vizioncore support for analysis.
Though initially it seemed there was a problem with the Linux user credentials for our ESX Server systems, deleting the references to our ESX Servers and recreating them using only root user credentials meant our replication jobs ran without hiccup.

The addition of buttons on the main interface that enable administrators to test replicas by performing a dummy or real failover is the biggest usability improvement.
When we used the “Test Failover” button to see if our replica would pass muster, the test initially failed because we had not paused the replication job. Once it was paused the test restarted, vReplicator reported that it was disabling the network interfaces on the replica before it booted it. The test function then waited for us to log into the replica server to ensure it was working correctly. Pressing the “Resume” button on the vReplicator console then switched off the replica but left the master VM untouched.
Doing this type of test with competing products would require administrators to use VMware software to register the replica VM on the secondary server, then manually disconnect its virtual network cards and boot the server.

Similarly, the new “Failover” button in vReplicator makes it much easier for system administrators to perform a planned failover from master to replica.
On pressing the button, the administrator is asked whether that want to perform a final synchronisation of the replica. Though this would not be possible in a real disaster recovery operation, it does provide the opportunity to perform one last update in a planned failover (a complementary button stops the failover from continuing if it takes too long).

We were surprised to see that by the time our test had finished, both the original and the replica VMs were powered off, which seems counter-intuitive as we had expected the replica to be powered on by vReplicator as part of the failover process.

The suite’s performance is less impressive. Our initial VM replication was not much quicker than it would have been using esxReplicator 2.0 ­ 43 minutes for a VM with a 4GB virtual hard disk. Subsequent updates to our replica were a little quicker, requiring only 23 minutes, suggesting the process still sends too much data over the network.

Vizioncore appears to send the VM’s entire hard disk to the secondary server simply to see if anything has changed on the master since the last replication. In contrast, other products use VMware’s ESX Server software to store changes made to the master VM snapshot in a separate file that is then merged with the replica.

During tests, our server monitoring suite also reported time-outs from several VMs running on the secondary server while it was creating or updating replicas. Though other products we tested did not suffer from this problem, it is important to remember that the actual time needed to replicate a VM will vary enormously depending on both the specification of the server and the resident SAN and LAN infrastructure.