How to size Domino and Sametime systems for full production loads on VMware ESX Server
Your Lotus Domino-based servers are implemented on VMware ESX server and you need to size your systems to meet the requirements of your production-grade workload. How do you size your systems to support Lotus Notes and Sametime users on virtualized servers Domino-based servers?
Resolving the problem
VMware ESX Server is a software-based virtualization product that allows a means to divide a portion of a physical server to one or more "virtual machines" (VMs), each loading a separate operating system (usually Windows or Linux) as well any applications, such as Lotus Domino or Sametime, installed within each guest operating system.
VMware ESX Server software makes it possible to place multiple virtual machines on the same physical server, and it is possible to over-commit those finite physical resources. For example, one can allocate more processor (CPU) or memory (RAM) to the guest virtual machines than what is physically present on the server hardware. Each VM has its own setting for how much CPU and RAM to take from the physical hardware, therefore it is essential to be aware of all the system resources consumed by every virtual machine installed in your VMware ESX server. Any over-commitment of system resources must be resolved in order to minimize unacceptable performance in production-grade workloads.
A note about test workload tools and networking
Test and simulation tools, such as Domino Server.Load, exist to generate an artificial load on the server in order to simulate how the system might behave under real life workloads. Be aware that these tools do not exactly simulate the behavior of a real user with a real client. This difference is particularly evident when all clients temporarily get disconnected, for example due to a network-related issue, and then re-connect. In production environments, all clients throughout the enterprise would attempt to reconnect simultaneously after the network issue has been resolved, flooding the server with client requests all at the same time. This common scenario is not easily simulated using test workload tools.
In a simulated environment, the load is generally provided by a few workload test machines that simulate thousands of users. The ramp-up time for the thousands of users from a single workload simulation machine is measured in several minutes, not a few seconds, as is likely to occur under the true to life scenario.
When configuring a production environment under VMware ESX Server, one must budget sufficient resources--network bandwidth included--to handle a burst of activity caused by external conditions and not just a full load under ideal or simulated conditions. Physical network cards must support the combined demands of all virtual machines installed on that hardware. In simple terms, if 5 VMs share the same network interface and each VM generates between 180-400 megabits of traffic, in theory all of this traffic could be accommodated on a single gigabit link. To maximize performance in production environments, isolate and protect each VM from the burst of demand of others: consider additional network interface cards, preferably one network interface per virtual machine.
**Note** While a VMware ESX environment with over-committed resources may work in a test environment or with a limited load, this configuration is not recommended nor supported in production environments.
Hard disk performance
Disk is the slowest component of any computing environment. In the past, each operating system or server used to possess its own set of dedicated hard disks. Today, virtualization tools encourage the sharing of hard disks, and therefore, can greatly increase this disk performance bottleneck if not configured optimally.
A Storage Area Network, or SAN, is another technology that shares storage space for use by several separate computing systems and can introduce its disk performance choke points of its own. Even on a SAN, because it is possible to put multiple virtual disks per LUN (logical unit number), it is important to verify that the disk is not a bottleneck for Domino performance.
When a SAN is used in conjunction with VMware ESX server, it is vitally important that the disk back-end is fast enough to support concurrent activity from all virtual machines.
To achieve the best performance:
- Create a single virtual disk per LUN (assign all available space on the LUN to a single virtual disk)
- Utilize a separate LUN and Virtual Disk for the operating system, page file, application executable code
- Utilize a separate LUN for the Domino data files
- Utilize a separate LUN for Domino transaction logs
**Note** Running multiple Domino servers or other disk intensive applications from local storage is not recommended and should be avoided to obtain acceptable performance. The recommendation is to consider a sized storage area network.
Memory (RAM) requirements
To build a responsive Domino and Sametime server production environment on VMware ESX, each VM should have the same amount of RAM and number of virtual CPUs as recommended by the IBM Techline or IBM publications such as IBM Redbooks.
For example, if 2 cores and 4 GB of memory are recommended for a supporting a given number of concurrent users on a physical server, then a minimum of 2 CPUs and 4096 MB of RAM should be allocated to the virtual machine and exist on the physical hardware.
Limiting the RAM allocated to the virtual machine (by way of Virtual Machine Properties -> Resources -> Memory) to a value lower than the amount of RAM assigned to the VM requirements is not supported. This under allocation of physical resources can introduce serious performance issues with Domino that are very difficult to analyze and troubleshoot.
For all Domino-based products running In VMware ESX Server, enable the memory limit to be "Unlimited". This checkbox is found in Virtual Machine Properties -> Resources -> Memory. The "Unlimited" checkbox appears toward the bottom of the panel.
If the "unlimited" option is not enabled, the guest operating system will not utilize the memory allocation set in the other part of the VMware ESX Server interface where memory usage is configured. This is a frequently misunderstood aspect of the ESX Server product.
Virtual Machine Properties -> Hardware -> Memory
Controls how much memory the virtual machine can "see" from the host hardware.
Controls how much memory the virtual machine and all applications can utilize from the amount allocated in Virtual Machine Properties -> Hardware -> Memory.
**Note** Only VMware ESX Server (not VMware Workstation) has two locations where memory settings are configured.
The VMware ESX console itself consumes a portion of the processing power of cpu0. Therefore, running a two virtual cpu virtual machine on a 2-core system or a four virtual cpu virtual machine on a 4-core system is not recommended nor supported.
Virtualization is not merely saving hardware by placing multiple services on a single physical machine. Virtualization requires a carefully designed environment, a clear understanding of how system resources are utilized, sufficient bandwidth and a contingency plan such that future upgrades and tuning are made possible for future changes. These considerations are particularly important for mission critical and resource intensive applications like Lotus Domino-based servers.
In general you should make sure that your VMware ESX Server, SAN, HBA, Fiber Switch and network cards can support the combined load of all virtual machines, when external factors cause a burst of user load onto the system.
Virtualized servers require the same or a higher level of performance than that normally available in a physical server environment. VMware ESX does not reinvent the laws of physics: CPUs and GHz, available RAM, network speed, disk subsystem speed and latency do not disappear. VMware ESX server will not provide an adequate environment for running Lotus products in a production-grade workload if sufficient resources are not allocated to each of the virtual machines.
For more information on how to tune VMware ESX for best performance see the VMware whitepaper "Performance Tuning Best Practices for ESX Server 3".
|Organizational Productivity- Portals & Collaboration||IBM Sametime||Crash and Performance||Linux, Windows|