Editors' Rating
Published: 21 Aug 2007
esxReplicator 2.0
Offering the promise of replicating VMs to other ESX Server systems, esxReplicator 2.0 could be used as the basis of a disaster recovery or business continuity plan. As such it arguably provides the most value for money of all the components of the esxEssentials package.
We used the esxReplicator GUI to define a replication task by selecting the source VM from a list in the middle of the screen and then clicking on a link to 'Assign a new job'. This caused a dialogue box to appear asking when and how frequently the job should run, and who should be emailed with details of how the job was processed. The next steps were to select the target server and file system.
Unfortunately we found that this process required a lot of network bandwidth. For example, we made a replica of a Windows Server 2003 system that was configured with a 30GB hard disk and 4GB of RAM, which took around 2 hours to replicate via a 1000Base-T LAN. Interestingly, this is much longer than the 40 minutes or so needed by esxRanger Pro to make a backup of the same VM. It took 25 minutes to replicate a VM configured with a 128MB of RAM and a 4GB virtual hard disk. Once the initial replica has been made, esxReplicator synchronises the replica by sending only information that has changed since the last replication. However, replicate synchronisation was still a slow process because changes are analysed by comparing files on the source and destination servers. Thus we rarely noticed a significant increase in the speed of replica synchronisation passes compared to the time needed to create the initial replica. A new option that uses VMware’s snapshot capability to maintain replicas is being introduced in version 2.1, which is due at the end of August. This should dramatically reduce the time needed to synchronise replicas.
Although Vizioncore says that esxReplicator can be used to maintain off-site replicas, the speed of your WAN connection may make this an extremely slow process. Companies wanting to maintain replicas via slow WAN links should make a backup of the VM and send the backup media to the remote site, where it can be restored; esxReplicator can then continue the replication by sending the only new or changed information to the remote site.
We were also disappointed at the way replicas were updated in our tests. For example, replication jobs failed if the target VM was running. Similarly, the previous replica is left in an unusable state while the new one is sent.
Replication also placed a high CPU load on the source ESX Server system during our tests. We noted 97 percent CPU utilisation on one of our 3GHz Xeon CPUs at the start of a replication job. This figure occasionally dropped to about 70 percent while the disk transfer phase of the replication was happening. These shortcomings aside, esxReplicator could form part of a server backup or disaster recovery plan.
Previous
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
