Description
1.1 Storage
1.2 Memory
1.3 Networking
2.1 Virtual CPUs
2.2 Memory
2.3 Disk
2.4 Network
2.5 Disable unneeded hardware
2.6 Snapshots
2.2 MySQL
Configuring ESXi
The range of hardware that ESXi will run on is more limited than you might expect. Before purchasing any hardware, you should consult the hardware compatibility list located at http://www.vmware.com/resources/compatibility/search.php . For testing or experimentation, you might find hardware that's not on the list will work, but naturally only hardware that is on the VMware hardware compatibility list should be used in a production environment.
The BIOS of the machine should be up to date. All virtualization features such as VT-x should be enabled in the BIOS. For best performance, power-saving features should be disabled. Unused hardware features, such as parallel ports, should be disabled. The settings chosen in the BIOS screens can have a substantial effect on the performance of the machine. If your hardware does not perform to your expectations, be sure to consult the vendor documentation or support services for information on the optimal configuration of your hardware.
The storage technology used can be any of the usual choices – local, NAS, or SAN, but care should be taken to not overburden storage with too many VMs. Ediscovery Platform (eDP) is very IO-intensive and performance will suffer substantially, especially during processing, if the storage system can not meet the demand. Local storage on a fast RAID array can be just as fast as a FC SAN, but to make use of the advanced fault tolerance features of ESXi, you'll need to use NAS or SAN. To compare disk performance between a known hardware configuration and a VM environment, you can use the IOMeter storage benchmark tool from http://www.iometer.org/. Comparing the results of this tool on a physical hardware and a VM will give you a good idea of the performance you can expect from a eDP installation, provided you follow the suggestions about memory and CPU allocation given below.
The minimum RAM necessary to effectively run eDP processing node is 16 gigabytes. Keep in mind when deciding how much RAM your (physical) machine needs that ESXi needs some additional memory for its own purposes. For a 16 GB VM with 8 vCPUs, this will be about 169 MB of memory for ESXi 5. See this link in VMware's ESXi and vCenter Server 5 Documentation for more information.
Ideally, the machine should have at least two physical NICs. One should be dedicated to the service console and ESXi infrastructure. If possible, dedicate a NIC to each VM that needs to access different physical machines.
For best performance, all of the eDP nodes in a cluster should use the same virtual switch.
Configuring the VM
There are a couple important things to keep in mind when configuring vCPU allocations for your VM: First, is the fact that if you allocate n vCPUs to a virtual machine, then that VM can receive a time slice if there are CPU cores idle/available on the host machine at given point in time. For example, if you have a host machine with 24 cores, and you create a set of VMs with 8 vCPUs allocated, then at most 3 VMs will be able to simultaneously run. The VM will only receive a time slice if the hypervisor can dedicate 8 cores This is true even if the VMs are not making use of all of those cores. And so over-allocating vCPUs negatively impacts performance of the VM by reducing the likelihood that the VM will receive a timeslice.
Secondly, In practice, the hypervisor requires significant processing time to maintain the virtualization environment, in particular to perform IO virtualization tasks. So, in the previous scenario, often only 2 VMs will be able to run simultaneously.
Care should be taken to avoid allocating more cores to eDP VMs on a single host than physically exist on the host if those VMs will be processing simultaneously. Naturally, the best performance will be realized when CPU resources are dedicated to the eDP VM but this limits flexibility of the system.
It doesn't matter if you configure a single CPU with multiple cores, or multiple CPUs with fewer cores. There may be some theoretical performance difference, but it's unlikely there will be any in practice. The configuration option is there for the benefit of people running software that is licensed per-CPU (so you can configure a single CPU, but with 4 or 6 cores or more).
When allocating memory to your virtual machines, it's possible to allocate more memory collectively than exists physically in the machine. This is called memory overcommitment. If at no point do the VMs use all of their allocated memory at the same time, this can work well. However, if multiple VMs simultaneously do need to use all their allocated RAM, performance will be very poor as data in RAM is forced out into the Windows page file (if using the VMware balloon driver) or into the ESXi swap file. Since eDP is tuned to use as much memory as is available, it's important that the eDP VM have its full memory allotment available. For best performance, eDP VMs should have all of its memory reserved and locked. This is particularly important if multiple eDP VMs on a given host will be processing concurrently, otherwise disk thrashing will occur.
If memory is nevertheless over-committed, the VWware swap file and Windows page file should preferably be located on a different storage device from the VM virtual disks in order to minimize the performance impact.
A C drive of 60 GB and D drive of 100 GB should be created for the VM. By far, the heaviest IO load will be on the D drive, so if the host environment has storage of differing performance levels, the D drive should be on the faster subsystem.
The drives should be thick-provisioned to avoid fragmentation. Eager-zeroing the drive will likely not have a large impact, but you might as well do that too.
As mentioned above, for best performance, in order to improve locality of reference, swap files should be located on separate devices – both the esxi swap file and the windows page file.
The VWware paravirtual storage driver doesn't seem to offer significant performance gains over the default LSI Logic SAS driver if the host machine is not heavily CPU loaded and local storage is used. VMware reports considerable performance improvement with regards to CPU usage. Also, there are reports of considerable performance gains when storage located on a SAN. Guidance should be sought from your hardware vendor.
In our tests, the VMXNET3 paravirtual network driver offer no performance gain when the host machine is not heavily CPU loaded. VMware technical reports claim that considerable improvements can be had in some usages, particularly with regard to CPU usage. Once again, seek guidance from your hardware vendor.
Disable USB controllers, serial/parallel ports, CD-ROM drive, sound cards. This eliminates the need for the hypervisor to emulate these unused devices when the operating system polls them for their status.
Snapshots have a negative impact on performance. Avoid keeping them longer than necessary.
MySQL
The database host should be within the same hypervisor and virtual switch if possible.
MySQL probably doesn't need many vCPUs, but this needs to be explored. Maybe start with 1 or 2 and increase if the database seems to be a bottleneck.
A paper on the VWware site, but written by Sun, recommends using the paravirtual vmxnet driver.
Was this content helpful?
Translated Content
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.