Improve Memory Utilization With the PowerVM AMS Feature

Enter your search terms Submit search form The PowerVM feature, Active Memory Sharing (AMS), helps Power Systems address peak memory demands and improve overall memory utilization at the server level. Based on a concept similar to the shared processor pool, AMS starts with a pool of physical memory and then shares it among a group of LPARs. Each LPAR has a desired memory setting that specifies the amount of memory it’s permitted to use. The aggregate of the desired memory settings is permitted to exceed the physical size of the pool, which overcommits the physical memory pool from a design perspective. The main idea is to move memory to and from LPARs to satisfy their requirements. Similar to the way AIX operates, if the demand for memory exceeds the physical memory available, paging devices on the virtual I/O server (VIOS) become active. Memory sharing has different operational dynamics than processor sharing. With processor sharing, the processor state for an idle LPAR can be quickly saved, freeing it for another LPAR to use. However, the give and take of memory between LPARs isn’t as fluid as processor sharing with the shared processor pool. AMS is included with PowerVM Enterprise Edition and can be implemented on POWER6 and POWER7 servers. It’s supported with AIX V6.1 or higher and IBMi V6.1. Implementing AMS Finding situations to implement AMS can be somewhat challenging, primarily because: For most applications, you want to avoid page-in activity. If systems begin moving memory pages back into physical memory, the application is likely to suffer a noticeable degradation in performance. Many applications aren’t well behaved and don’t free up unused memory blocks. This results in a situation where memory is allocated to an LPAR, but might not be in active use. AIX (or IBMi) and the hypervisor must work together to determine which memory blocks should be paged out to the VIOS paging device. Here are two use cases that address these challenges. They’re good candidates for AMS because the shared memory pool LPARs are predominantly “quiet,” just waiting to ramp up to run production workloads. AMS provides a fast, automated method to move physical memory to the LPARs in need. AMS for High Availability Clusters Use of AMS can simplify the configuration and operation of PowerHA high-availability clusters, especially those with a large number of servers being clustered to a single recovery server. For example, you might have a PowerHA cluster with eight active servers and one hot standby server. Each active server has one 32GB production LPAR with a corresponding cluster partner LPAR on the standby server. The cluster partner LPARs only require 2GB of memory while in standby mode and 32GB of memory when a failover is active. It’s assumed that the standby server will be configured to support just one failover at a time. Without AMS, a typical design would assign 2GB of memory to each of the recovery LPARs with 30GB of unallocated memory available for an active failover. Total memory required on the standby server would be 46GB [(8 x 2GB) + 30GB = 46GB]. During a cluster failover for one production LPAR, an additional 30GB of memory would need to move to its cluster partner on the standby server. This could be accomplished with a scripted or manual dynamic LPAR (DLPAR) operation at the Hardware Management Console (HMC). Implementing AMS on the standby server, however, can simplify and automate this process. With AMS, a 48GB shared memory pool would be configured. Each cluster partner LPAR would be set up to have access to 32GB of memory from the pool. During a failover event, the corresponding cluster partner LPAR would automatically make use of up to 30GB of additional physical memory from the pool. There should be no delay in acquiring this memory because it doesn’t need to freed from the other LPARs. After the production workload has been shifted back to the production server, the additional 30GB of memory is no longer needed on the cluster partner. To prevent that 30GB from remaining with this LPAR, it could be shutdown and reactivated. The LPAR would reboot and resume operation with just the 2GB of memory required to sustain standby operations. This would leave 30 GB of unallocated memory in the shared memory pool, ready for use by any cluster partner LPAR. AMS and Disaster Recovery Using AMS as part of a disaster recovery (DR) architecture has a similar theme. Assume you have a collection of DR recovery LPARs with minimal workload under normal operation. This time, a DR event causes an AMS-based recovery LPAR to make use of additional memory. When the DR event occurs, the workload on the corresponding recovery LPAR increases, and memory is automatically shifted to that LPAR from the shared memory pool. Using AMS for DR would work best if the collection of recovery LPARs on a single server was composed of a mix from several physical production locations or at least, different physical servers. If all recovery LPARs on a single server were to become active at the same time, an overcommit situation would likely result in undesired paging. Another option would be to configure development and test LPARs along with the recovery LPARs at the DR site. The recovery, development and test LPARs would share a single shared memory pool. During a large-scale DR event, the development and test LPARs could be shutdown. This would automatically free up memory in the pool for use by the recovery LPARs. Potential Savings With some creative thinking, you may find a good use for AMS in your Power Systems environment. This will position you to take advantage of the flexibility and potential cost savings available with AMS.