Launched on September 4th, vReplicator 2.1 is the latest version of Vizioncore’s virtual machine replication suite. Previously called esxReplicator 2.0, the update is a good choice for firms that want to create and maintain replicas of their virtual machines (VMs) that are ready to run on secondary servers just in case something goes wrong with the original.The change of name indicates that a future upgrade may support other virtual server environments, possibly such as the open-source Xen hypervisor or Microsoft Virtual Server or Hyper-V.
New features in vReplicator 2.1 are focussed on improving manageability and ease of use. For example, reporting gets a shot in the arm as the suite now uses a Microsoft SQL database to keep track of replication jobs. Rather than searching through text based log files, administrators can now easily view a list of jobs, and can drill down into the list to get more details.
Another valuable improvement is the addition of buttons on the main graphical user interface to test and perform failovers from the original servers to their replicas. Given that many firms use this type of replication tool as part of their disaster recovery or server backup plans, the addition of buttons to test whether the replicas actually work as intended is an extremely important addition.
We were also pleased to see improvements in the way updates are scheduled. Previously updates could be scheduled to occur after a predefined delay – perhaps so that an update is sent 60 minutes after the last update was completed. This meant that was almost impossible to predict at what time an update might occur. A new feature in 2.1 enables updates to be scheduled so they occur at regular intervals, regardless of how long each update takes to complete. This guarantees that updates occur at predictable times.
vReplicator runs on Windows XP SP2 and Windows Server 2003. It also requires two or more servers running VMware ESX Server 3.x to act as the source and destination servers for the replication jobs. We tested the suite on a server running Windows 2003 Small Business Edition.
Installation was straightforward, but with an installation package of some 63.3MB, the suite took the best part of 30 minutes to add to our server. Like other Vizioncore software, vReplicator requires Microsoft dot-Net Framework version 2.0. As this was already present on our server a restart after installation was not necessary. We were also asked to choose between using an existing Microsoft SQL database and installing a copy of the free Microsoft SQL Express that is included in the Vizioncore package. We took the MS SQL Express option, which accounted for much of the time needed to install the suite.
During installation the suite gathered some information about our environment from the previous version that was installed on our system. Notable on this list of inherited information was a list of existing replication jobs from the old installation. We were also asked for details of a mail sever that vReplicator could use to email reports on how each replication job was processed. Compared to some products with similar email facilities, vReplicator seemed a little basic. For example, it does not support email user authentication or SSL encryption.
However, in our tests we were instantly 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. In our case, initially it seemed there was a problem with the Linux user credentials for our ESX Server systems. Having deleted the references to our ESX Servers and recreated them using only root user credentials our replication jobs ran without hiccup.
In terms of usability, perhaps the biggest improvement is the addition of buttons to test replicas by performing a dummy or real failover. We used the Test Failover button to see if our replica would pass muster. Initially the test failed because we had not paused the replication job. Having paused the job and activated the test function, vReplicator reported that it was disabling the network interfaces on the replica before it booted the replica. The test function then waited for us to log into the replica server to ensure it was working correctly. The next step is to press the “Resume” button on the vReplicator console, which switched off the replica and left the master VM untouched. This type of test is much more difficult using competing products we tested in the past, where administrators needed to use VMware software to register the replica VM on the secondary server, then manually disconnect its virtual network cards and boot the server. Even so, we think it would be better if replication jobs were automatically paused when the Test button is pressed.
Similarly, the new Failover button in vReplicator makes it much easier for system administrators to perform a planned failover from master to replica. Having paused our replication job and pressed the Failover button, we were asked if we wanted to perform a final synchronisation of the replica. Obviously in a real disaster recovery operation a final synchronisation would not be possible, but as we were making a planned failover we took the opportunity to perform this update. As these updates can take some time we were pleased to see a complementary button to stop the failover from continuing. However, we were a little surprised to see that the by the time it had finished, both the original and the replica VMs were powered off. This seems counter-intuitive and we had expected the replica to be powered on by vReplicator as part of the failover process.
We were less impressed by the suite’s performance. We found the initial replication of a VM took much the same amount of time as with the previous version of the suite – about 43 minutes to replicate a VM that had a 4GB virtual hard disk. Subsequent updates to our replica were a little quicker, requiring only about 23 minutes. However, this still seems rather a long time, indicating that too much data is being sent over the network during this process.
Some other products use VMware’s ESX Server software to make a snapshot of the master VM’s disk. The VMware hypervisor then stores any changes to the master disk in a separate update file and replicas are updated simply by merging that snapshot update file with the replica. Unfortunately, as with previous versions of the vReplicator, the Vizioncore approach appears to send the VM’s entire hard disk to the secondary server simply to see if anything had changed on the master since the last replication. We also noticed during our tests that our server monitoring suite reported time-outs from several VMs running on the secondary server while it was creating or updating replicas. Although these problems may not occur if we had a more powerful replica server, we did not experience such time-outs while testing a competitor’s product in our Lab.
Of course, while these times provide a guide, the actual time needed to replicate a VM would vary enormously depending on the datacentre environment, such as the SAN and LAN infrastructure and the performance of the various servers. In our case, our primary ESX Server was a twin CPU Intel Xeon based server attached to a 2Gbit/sec SAN, 1000BaseT LAN and a RAID array that could handle about 50MB/second. Our secondary server was rather less well endowed. It had only a single CPU and one SCSI disk.