As physical servers provision additional resources for additional VMs, the need to optimize hardware usage becomes greater in order to maximize server performance. The following set of best-practice suggestions should help you with ensuring that the optimal configuration is achieved and maintained.
Documenting the server's goals not only helps system architects and administrators focus their planning on a finite list, but provides a document that can be referenced for new teams or members using this server in the future. Even if the usage patterns are not constant, maintaining a living document provides value by maintaining the team's agreement of how the server is being used. Using the IBM System Planning Tool (SPT) should make this step fairly trivial. Further SPT details can be found in the Miscellaneous section under References at the end of this document.
To get the best-performing hypervisor, have the system installed with the latest release of the firmware for the machine being used. If a Hardware Management Console (HMC) is set up, you can use its maintenance functionality to perform the updates for you.
Further details for firmware updates can be found in the Firmware Update Procedure section under References at the end of this document.
If the HMC is not being used to update the server, an alternate method would be to manually download the patches through the IBM support site, which also provides patches and updates for other components like the HMC or SPT.
After understanding what the server will be used for, the planned hosts need to be resourced appropriately to carry out that purpose in the most effective way. This does not just refer to the quantity of the resources (for example, 32 compared to 16 processors, 256 GB compared to 128 GB RAM), but also to the manner in which they are to be virtualized: shared processing, dedicated processing, dedicated-donate processing, active memory sharing, active memory deduplication, Virtual I/O Server (VIOS) deployments etc.
Further documentation for virtualization best practices can be found online. Refer to the Virtualization section under References.
The processor-memory and processor-processor affinities are important factors for system performance. The fewer the Multi-Chip Modules (MCMs) and Central Electronic Complex (CEC) enclosures the LPAR resources are spread across, the better it will perform. The hypervisor computes the best, most-aligned, resource assignments to a starting LPAR based on the current resource pool that exists. It also remembers the resource allocations it computes for an LPAR from its first startup. Therefore, it is vital that the processor and memory resource pool is made as large as possible to produce the best affinities. After, it is equally vital that the most processor- and memory-critical LPARs are activated first, to ensure they get the best chance for being assigned the most optimal resource alignments.
In the strictest sense, this is only needed when the hypervisor has no allocation for the server LPARs. That is, the startup order of a server is important only if there are LPARs that have never been activated or started, or LPARs whose resource allocations were cleared (for example, using
chhwres). For example, if a system administrator is shutting down the running LPARs, power cycling the server, and starting those same LPARs, the startup order does not matter: the hypervisor has the information that it needs to optimize the LPAR resource allocations during server startup time. However, it might be easier to start the LPARs in order of importance anyway, so that one does not need to track
chhwres or LPAR creation events.
The minor tradeoff to this practice is a somewhat unintuitive startup order, where the VIOS instances are powered on last. This implies that while the most important LPARs are started first, they will not actually be operational — spinning with the platform firmware code,
AA060011 — until the VIOS is up and running.