Virtualization Requirements

When deploying Rhapsody onto a virtual machine, for example VMware vCenter Server, VirtualBox, Virtual PC, you must configure the following features of the virtual machine:

Host Cluster Settings

When clustering your hosts, follow your vendor’s recommendations for how best to configure your cluster for virtual machines running Java virtual machines (JVM).   

In a VMware vCenter environment, set the Dynamic Resource Scheduler (DRS) to fully automatic with the migration threshold to the second tick on that scale (one level removed from the most conservative setting).  This will limit the frequency at which automatic vMotion’s occur. Configure resource pools to further divide physical resources and compartmentalize them between virtual machine groups.

CPU Allocation

At least two virtual CPUs (vCPUs) must be allocated for the virtual machine running Rhapsody.  This is the minimum requirement to allow Rhapsody and the operating system to operate simultaneously.  A virtual CPU is a single core in the physical CPUs.  Therefore, only having a single vCPU could cause process queuing for OS processes and all other application running on the virtual machine.  This also places a physical resource constraint on your virtual machines because the maximum vCPUs that can be specified to a virtual machine is equal to the number of cores on the host because all allocated vCPUs need to be available to a virtual machine simultaneously for any processing to occur.  Additionally, a vCPU must be added to the virtual machine for every JVM instance (for example, every Rhapsody instance on the virtual machine).  In cases with moderate to high load, the number of vCPUs would likely need to be increased for the higher load.

Data Storage Persistence

Rhapsody's data store is saved in a file system and the Rhapsody engine should be treated as you would a database server.  It is a best practice for Rhapsody that the data store for the Rhapsody engine be allocated a dedicated disk. When Rhapsody is run on a virtual machine, the data store must be kept on disk accessed on the block level.  This can be achieved by using a physical disk attached to the virtual machine, or, in a VMware environment, a virtualized disk (VMDK). If a VMDK is used, the datastore for the virtual machine must follow the guidelines for Rhapsody data store setup. In addition, the virtual disk must use a thick provisioned disk, preferably with the eager zero option. For optimal performance, the data store should be on a fast SAN (Storage Area Network). Note that the use of NFS for the data store is not supported due to problems discovered from practise, as block level access is required. When using a VMDK it is imperative that snapshots not be used on the virtual machine for any time period longer than a maintenance window. Due to Rhapsody’s intensive disk I/O usage, snapshots can grow quickly in production causing significant performance degradation. 

Virtual Machine Memory Allocation

• The virtual machine running Rhapsody must have access to enough allocated physical RAM on the server hosting the virtual machine to satisfy the virtual machine's memory requirements. Specifically, the memory allocated to the virtual machine must not exceed the physical memory of the server.
• The virtual machine running Rhapsody must not share memory with other virtual machines on the same server.
• For optimal performance, at least 2GB of RAM must be available for the operating system of the virtual machine server.
• When calculating minimum RAM, consider other applications using memory resources.  The total allocated RAM should equal the sum of:
  • 2GB for the operating system
  • Desired RAM for the Rhapsody JVM.
  • RAM for all other running applications.
  • In order to achieve these goals, reserve memory on the virtual machine for the entire amount of allocated RAM. 
  • Reserving this amount of memory also mitigates the detrimental impact memory ballooning has on the Rhapsody engine as the virtual machine will always have the memory resources allocated to it.
  • Never set the RAM of the virtual machine equal to the entire unallocated RAM of the host server, as it needs a small amount of additional RAM for overhead of running the virtual machine.

Rhapsody Application Memory Allocation

Rhapsody must have sufficient memory for the intended message load.  In general, there must be enough memory to ensure that Rhapsody's In Use portion does not exceed 80% of the total allocation in the event of an unexpected high memory load.  Allocating too much memory is also not recommended, as it can result in Rhapsody being unresponsive for long durations due to long garbage collection cycles.  Furthermore, if the virtual machine is moved between hosts while running, using a process such as using VMware’s vMotion, the larger the amount of memory the slower that migration will be. 

When allocating memory to Rhapsody, keep in mind two other users of memory on a virtual machine: the virtual machine's operating system, and the Java process running Rhapsody.  Two gigabytes is often enough for the operating system and Java, and the rest can be allocated to the JVM that contains Rhapsody.  However, if Rhapsody's workload does not require this much memory, then allocating less to Rhapsody may result in better performance.  When allocating memory, remember to consider the memory resources of other virtual machines sharing your host server.

Time Synchronization

Ensure that your operating system on the virtual machine is configured to synchronize its clock with a NTP server or domain controller.  The time in the virtual machine can be synchronized with hosts, if supported by your hypervisor vendor.  The most benign consequence of having the time out-of-sync is that logs report time inconsistently with other servers making troubleshooting difficult or impossible to coordinate time between them.  If the time is too far out of sync from the NTP server, the virtual machine and its applications may not be able to communicate with other systems, such as cross-host encryption issues and expired request issues.