- ✓Fast, reliable backups of virtual machines (VMs)
- ✓No need to switch off VMs while making backups or replicas
- ✓Integrates with VMware Consolidated Backup software for better backup/restore jobs
- ✓Integrates with VMware VirtualCenter for better usability
- ✓Excellent view of server CPU, disk, RAM and network utilisation
- ✓Easy to maintain replica VMs on secondary servers
- ✓Can be installed on a Windows XP workstation; no requirement for Windows Server platform
- ✓Billback option could be used for inter-department charges
- ✕Some VM settings needed adjusting for successful backup/restore
- ✕Poor granularity in the billback option leaves room for improvement
- ✕We found a bug that will be addressed in forthcoming updates
Combining comprehensive backup, monitoring and virtual machine (VM) replication tools for VMware’s Virtual Infrastructure 3, Vizioncore esxEssentials provides the main utilities needed to manage VMs in a datacentre environment. Priced at £509 (ex. VAT) with one year's support, or £649 with three years' support, the esxEssentials pack costs less than buying the individual applications separately. The suite was originally launched last summer, and has recently been updated with new versions of esxRanger and esxCharter.
We tested the suite in our VI3 and VirtualCenter 2.0 datacentre by installing the software onto a desktop PC running Windows XP SP2. As the backup tools can also be configured to use VMware’s Consolidated Backup, we installed a second copy of the esxRanger Pro backup suite on our lab VCB server, which also runs our VMware VirtualCenter 2.0 management console and Windows Server 2003. Although we experienced a few hitches during installation and operation of the Vizioncore software, by and large we were very impressed by the facilities on offer.
esxRanger Professional 3.1
We found the esxRanger Professional backup suite particularly valuable. The suite comes as two main components: a graphical user interface (GUI) enables users to define and run backup and restore jobs from a conventional Windows point-and-click environment. However, the GUI does not run the jobs — it merely creates a command line for esxRanger Pro’s command line interpreter (CLI), which takes commands and actually runs the jobs. This two-tier architecture means that system administrators can define and test backup jobs using the GUI and then use the Windows scheduler to automatically run the jobs when they have been tested and are known to work properly.
esxRanger Pro has three operating modes. In the most basic mode, it connects directly with various ESX Server systems. Although this mode is simple and works well, the main drawback is that you can select one or all of the VMs on a particular server, but you can’t select a subgroup of VMs to be handled by a single job. In the second mode, esxRanger Pro connects to VirtualCenter rather than the individual servers. VMs can be organised into folders with VirtualCenter, and esxRanger Pro can select such a folder and backup all its VMs in a single job.
In the above two modes, the esxRanger Pro CLI issues tasks to an ESX Server, which actually does all the hard work of running the backup or restore jobs. For example, to make a backup the server would need to snapshot the VM’s disk and RAM, read those files from disk, compress the data and send the compressed data to a storage device — probably via a LAN connection. All this work places a relatively high load on one of the ESX Server’s CPUs (in our tests we often recorded about 70 percent CPU utilisation on one of our server’s two 3GHz Xeon processors while running esxRanger Pro jobs).
However, companies running VMware’s Consolidated Backup (VCB) can download and install a free plugin for esxRanger Pro that integrates with VCB to offload much of the overhead from the server CPU. Using the VCB plugin, the esxRanger Pro CLI issues a few commands to the server to take the snapshots. The CLI then uses VCB to copy those files directly from the storage area network (SAN) to the VCB server’s hard disk without using the ESX Server’s CPU for the transfer. In our test using the VCB option, backups took about twice as long to complete but had almost no effect the server’s CPU performance. However, our VCB server has only a single CPU and 32-bit PCI slots. We would expect VCB backups to be quicker if we tested with a higher-specification VCB server.
Unfortunately we encountered a few installation hitches with esxEssentials on our XP system. All three Vizioncore programs repeatedly failed to install if we used the option to install the software for all users, but succeeded if we installed for only a named user. Another problem affected esxRanger Pro’s backups of a VM stored on a SAN volume that had the same name as the directory in which the VM was stored. In our tests this VM consistently failed to restore properly. However, when we moved the VM to a different SAN volume and made a new backup, the restore process worked perfectly. Vizioncore is investigating this problem and we expect it to be addressed in a future release.
Overall, however, we are impressed with esxRanger Pro. In fact, we have been using various versions of esxRanger for over a year and have found it to be a reliable and easy way to backup VMs. In particular, we like the fact that it's not necessary to shut down or even quiesce the VM operating system while making backups. We also like the fact that esxRanger Pro now maintains a simple database of backup jobs and archive file locations, making it easy to find the files for a particular VM without needing to hunt through a directory listing of obscurely named archive files.
We tested the suite by backing up nine VMs from one server and 12 from another server. We completed the test by restoring the VMs to a specific server using a different name for the restored VM. However, three of our VMs would not restore properly at first. We needed to adjust the VM configuration settings to successfully backup and restore two of these problem systems. After about two weeks of dialogue with Vizioncore, we were still unable to restore one VM. The company says that it's working on an update that should address the problem. The bottom line is that, as with all backup suites, it’s important to test your backups to ensure they will actually restore if needed.
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.
Even companies that don’t use VMs will occasionally face questions from users about the performance of their server systems. Adding more storage or RAM could boost performance, but it’s often difficult to predict which will have the most impact for the least outlay, especially in a virtualised server environment. esxCharter is designed to easily answer such questions for administrators running VI3. The suite uses the Simple Network Management Protocol (SNMP) to gather resource utilisation metrics from the ESX Servers.
The main esxCharter display is split into the typical three-way hierarchy, with a list of servers in a box on the top left. Below this are a few summary displays showing aggregated data about the VMware Console OS and other major subsystems. Finally, the right-hand panel provides the detailed view and is the one that most people will use most of the time.
By default, esxCharter displays four line graphs showing overall CPU, RAM, disk and network utilisation. By comparing data between our two servers it was easy to see that the performance of one of our servers was seriously restricted by using only local storage. For example, we could see that the maximum disk throughput on our SAN-connected server was around 50MB per second, while the server without SAN storage could manage only about 3MB per second. However, we could also see that unless a backup or restore job was running, both servers had enough disk bandwidth to satisfy the users. This was particularly useful data, as one user had asked to increase the disk storage on one VM by about 30 percent. Data from esxCharter suggested this could be done without affecting the performance of other VMs.
From the main display we could also drill down to look at the data for a specific VM's CPU, RAM, disk and network utilisation. Other options provide data on the throughput of particular SCSI adapters, LUNs (Logical Unit Numbers) and VMware file systems (VMFS). Similarly data is available for the server’s physical network interface cards (NICs) and for the virtual NICs used by the VMs.
But perhaps the most interesting feature of esxCharter is the billback module. We needed to configure the module with information about the cost of server resources such as SAN ports, network interfaces, software licences and so on. esxCharter can then produce reports allocating billback costs for each VM or group of VMs.
Our experiments with this module suggest there's still room for improvement. For example, companies will need to research the cost of their hardware and software, and may find the billback reports a little simplistic. For example, on one of our servers the Console OS seems to be responsible for much of the work done by the server, and therefore is billed for about £600 out of some £1,800 total for that server. It turns out the Console OS was indeed very busy, but most of its work was done making backups of one particular VM. Thus we would prefer the Console OS work itself to be billed back to VMs where possible. Such granularity is not currently available. However, billback is something many firms would want to test now with a view to using it once the software matures.
The base price for esxEssentials covers one ESX Server CPU. Additional CPUs for esxCharter or esxRanger Professional cost £169 and £279 respectively. Licences for esxReplicator are charged per VM, with additional ones priced at £279 per VM.