Virtualized environments

OpenText™ Analytics Database supports running in any virtualized environment that conforms to the performance requirements for vioperf, vnetperf, and vcpuperf.

OpenText™ Analytics Database does not support VM Snapshot.

OpenText has tested VMware and when the underlying hardware is configured correctly, VMWare performs well. Customers have also deployed other virtualization configurations successfully. If you choose to run the database on a different virtualization configuration and you experience an issue, the support team may request you to reproduce the issue using a bare-metal environment to aid in troubleshooting. Depending on the details of the case, the Support team may also request you to enter a support ticket with your virtualization vendor.

Guidelines for hypervisor and virtual machine configuration

There are many enterprise-grade hypervisors available in the market today, most of which support Linux-based virtual machines (VMs) in support of OpenText™ Analytics Database. When selecting and configuring your virtual environment, refer to the following guidelines.

• Do not over-subscribe the physical resources (CPU, memory, and network) of the hosting hardware. Many hypervisors allow you to take advantage of scaling out solutions by over-subscribing resources, for example, deploying more virtual CPUs than are physically installed in the host hardware. However, this type of deployment has a negative performance effect on a database cluster.

• Configure the hypervisor to run low-latency, high-performance applications. This means that you should disable power-saving features and CPU frequency scaling on the hypervisor hardware because these technologies contribute to latency in the applications.

• Choose an operating system for the database VMs that is supported by OpenText™ Analytics Database and by the hypervisor you are using. For some hypervisors, different operating systems may perform better than others. It is recommended that you investigate the options with your hypervisor vendor.

• Configure attached storage for high I/O performance. A virtualized database node requires the same amount of disk I/O performance as a non-virtualized one. It is recommended to use the vioperf utility to validate the actual performance throughput on each VM.

• If you are providing storage using a shared storage device, make sure to validate disk I/O performance on the cluster as a whole to ensure that the shared resource(s) do not create a bottleneck. To achieve this validation, run the vioperf utility on all the cluster nodes simultaneously to determine the maximum disk I/O performance that can be achieved on each VM during times of heavy I/O load.

• Memory recommendations for the database running in a virtualized environment are no different than running in a non-virtualized environment. It is recommended that you allocate 8 GB of memory per virtual core. Do not over-subscribe the memory available in the hypervisor, because this creates contention for the physical resources, causes negative performance impacts, and possibly crashes the VMs.

• Networking requirements for a virtualized database cluster are the same as for a non-virtualized cluster. Each node in the cluster must be able to communicate with all the other nodes, and latency in those communications can have a negative effect on cluster performance. When you are running multiple virtual machines on a single host server, the network communication is very fast. This occurs because the network traffic is virtualized in the memory space of the hypervisor and never leaves the physical server. However, if the cluster expands beyond a single host, the physical networking of that host can become a bottleneck for the cluster. If you are deploying in a virtual environment, that environment has a robust networking infrastructure that can provide the necessary connection speeds between physical hosts. In most cases, there will be multiple 10 GBE networking connections. Use the vnetperf utility to validate actual network performance speeds between nodes in your database cluster.

• When deploying multiple database VMs per physical host, the fewer the better. The goal of virtualization is to consolidate workloads to reduce overall hardware footprints. However, running multiple database VMs on the same host can place the database cluster in a situation where a single hardware failure can take down multiple nodes in a cluster and perhaps even the cluster itself. When you virtualize a database cluster, it is recommended that you spread the VMs across as many physical hosts as possible with an ideal goal of having one database VM per physical host.

• While virtual networking can be very robust, UDP broadcast traffic that is used in the spread daemon can be unreliable in most virtual environments, especially when those environments are spread across more than one physical host. In order for the database to function effectively in a virtualized environment, use the --point-to-point flag when you execute the /opt/vertica/sbin/install_vertica script. This flag configures the spread daemons to communicate directly with one another.