Virtualization is the process of creating and using virtual, rather than physical, machines to run software and solutions. Normally many virtual machines run on one or multiple physical host machines, attached to a specialized storage system. In many scenarios, such systems offer performance on par with or even better than “bare-metal” systems. Such systems make management much easier, reducing the size and cost of the hardware footprint significantly. For example, applications running on different physical machines installed 4-5 years ago, running on the latest hardware available at the time, can today be migrated to virtual machines running on the same host and based on the latest hardware available today. At the same time, thanks to Moore’s Law, they can profit from speedup.
Jedox measurements showed up to 60% less performance when running Jedox on VM vs. running on the same bare-metal host. This is a general issue, not limited to Jedox products (see BizTalk Server Performance), which highly depends on the performance of the underlying host and storage system as well type and configuration of the hypervisor involved.
Virtual machine sizing
In general, Jedox software can be run in virtualized production and non-production environments. Virtualized Jedox is sized the same as non-virtualized Jedox deployments. In other words, for sizing the virtual machine (VM), the CPU/memory ratio as used for native, non-virtual sizing is taken into account to ensure locality of memory access on the underlying hardware resources. However, the following constraints have to be met:
- Support is limited to scale-up scenarios only. Jedox database scale-out installations are not supported. The maximum resource size (CPUs, memory, etc.) of a virtual Jedox instance is hence limited by the maximum size supported by the hypervisor per virtual machine and the application-specific core-to-memory ratios.
- Each Jedox instance/virtual machine needs to be sized according to the existing Jedox sizing guidelines and corresponding hypervisor vendor recommendations. CPU and memory over-provisioning must not be used.
Further constraints may apply to the various use cases and hypervisors. More information on sizing for the Jedox Platform can be found in Jedox Hardware Requirements.
To avoid memory overcommitting, the memory resource allocation upon virtual machine startup should always be enabled. Also, keep in mind that the underlying hypervisor also requires some resources (CPU/memory) to operate, and these resources must not be dedicated to one of the Jedox VMs.
Since Jedox is an in-memory data platform, the memory requirements of a Jedox system need to be calculated based on capacity sizing as well. These figures are determined by the customer. It is important to note that a vCPU is not exactly equivalent to a full physical core, because it is mapped to a logical execution thread. When hyper-threading is enabled, a physical core has two execution threads. This means, two vCPUs are needed to use both threads. However, the additional thread created by enabling hyper-threading does not double the performance of the core. It has been determined that enabling hyper-threading usually increases overall Jedox system performance by approximately 20%.
Operating mixed VM landscapes
Additional non-performance-critical, non-Jedox VMs may run on the same hypervisor/host, so long as the following constraints are met:
- There must be no memory or CPU over-provisioning configured between VMs.
- Resources sized for dedicated use by Jedox must not be utilized by other VMs.
- VMs running Jedox must be configured with HW resource scheduling priority.
Other settings to be considered
- Settings specific to underlying hardware and hypervisor (e.g. specialized support for virtualization in BIOS)
- Power-saving settings, both in host and guest OS, render the best performance when set to high performance
- AV scanner options for both host and guest OS may slow down performance
- Remote desktop/console access to the guest machine may slow down performance
- The screen saver on the guest machine should be turned off
- Live migration, although transparent for Jedox, should be done outside peak hours
See related document Scaling Jedox.