Editors' Rating
Published: 21 Aug 2007
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.
Previous
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
