AIX > Administrator > LPAR

Now’s the Time to Consider Live Partition Mobility


Live Partition Mobility (LPM) is a powerful tool introduced with POWER6 servers in 2007. While interesting at the time, most customers didn’t have enough POWER6 servers installed to make good use of LPM. However, five years later, many data centers now have a substantial install base of POWER6 and POWER7 servers making it a good time to consider deployment of LPM. Three primary architectural models can assist you in determining how to use LPM within your business.

Live Partition Mobility Primer

LPM allows you to move an LPAR complete with running applications from one Power Systems server to another without an application outage. LPM can help you:

  • Perform scheduled hardware/firmware maintenance that requires a server outage (server evacuation) without taking applications down
  • Rearrange LPARs between servers to address requirements for more processing power or memory (workload rebalancing)
  • Assist with migration from end-of-life servers
  • Position pools of servers for internal cloud computing

It should be noted that LPM is not a high-availability or disaster-recovery solution. Its primary design goal is to keep applications up and running during scheduled maintenance events.

Architectures

The deployment and use of LPM is flexible and can be adapted to most POWER6 and POWER7 server environment. Three potential deployment models are:

  • N+1
  • Partial capacity
  • Mixed environment

Beginning your LPM design with one of these models will help you get started. In the end, you may find yourself using more than one of the models or blending their features to meet your needs. See Figure 1 to help follow along with the explanation of each deployment model.

N+1

The primary ingredient of the N+1 design is simplicity. With this model, all of the servers have identical configurations. The total workload must run on N servers and the +1 server is a spare. You can choose to mix server sizes as long as the +1 server is as big as the largest server in the pool of N servers.

When performing scheduled maintenance on one of your operational servers, use LPM to move that server’s entire collection of LPARs to the spare server. Because the spare is as large as the biggest server in the operational pool, you can be assured it will have enough CPU and memory capacity to run all of the LPARs being moved. This eliminates the need to track or monitor spare server capacity for LPM activities.

N+1 is primarily used for scheduled maintenance. Since all of the servers are the same size, it is less likely to be used for workload balancing. N+1 deployments are best suited for small servers, say 740 and below. This is due to the cost of the spare server that’s typically sitting idle. The spare capacity cannot be easily used for peak processing of running applications because it only exists on the spare server. Some also use the spare server for sandbox work.

One frequently asked question is, “How big can N be?” It can be quite large. It really depends on how often you plan to make use of the spare server. For example, if you have 20 servers plus one spare, and you only want to perform a single LPM evacuation per weekend, it would take 20 weeks to service all of the active servers. If you’re able to do an LPM evacuation every night, it would only take 20 days. After the work related to the LPM is completed, you can choose to leave the LPARs where they are (rotating spare) or move them back each time (fixed spare).

Charlie Cler supports customers in a solutions-architect role at Forsythe Technology Inc. He can be reached at ccler@forsythe.com.


comments powered by Disqus

Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters