Vizioncore esxEssentials

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.

esxCharter 2.0
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.