Live Partition Mobility

Edit online

You can use Live Partition Mobility (LPM) to migrate partitions that are running the AIX® operating system. You can also migrate applications from one physical server to another without disrupting the infrastructure services.

The migration operation maintains complete system transactional integrity. The migration transfers the entire system environment, including the processor state, memory, attached virtual devices, and connected users.

LPM provides the facility for no required downtime for planned hardware maintenance. However, LPM does not offer the same for software maintenance or unplanned downtime. You can use PowerHA® SystemMirror® within a partition that is capable of being moved with LPM. This does not mean that PowerHA SystemMirror uses LPM in anyway, and it is treated as another application within the partition.

For PowerHA SystemMirror clusters configured to use heartbeating and application monitoring with short checking intervals, you must complete testing to validate that the period of suspension during LPM does not cause unwanted cluster events. You can greatly minimize the chance of unwanted cluster events by stopping cluster services with the Unmanage Resource Group option in SMIT on the node in the cluster that LPM is going to be performed on. You do not want to interfere with any applications during the LPM process. While the cluster is in an unmanaged state, PowerHA SystemMirror does not monitor any applications. Therefore, you must monitor the applications during the LPM process. If an LPAR failure occurs during the LPM process, you can start the workload on a standby node.

PowerHA SystemMirror automates some of the LPM steps by registering a script with the LPM framework.

PowerHA SystemMirror listens to LPM events and automates steps in PowerHA SystemMirror to handle the LPAR freeze that might occur during the LPM process. As part of the automation, PowerHA SystemMirror provides a few variables that can be changed based on the requirements for your environment.

You can also set LPM_POLICY to UNMANAGED state which will stop the cluster services in UNMANAGED state before LPM operation, and restart the cluster services after LPM operation. While restarting the cluster services, the application monitors are run to check whether any applications need to be restarted. A failure or disruption might occur if the application monitor is not configured for application monitoring or if the application monitor script disrupts the cluster services. To avoid failure or disruption after LPM operation, you can use the SKIP_EVENT_PROCESSING_MANAGE_MODE tunable.

Note: You do not have to take any actions or change any application monitor or application controller scripts after LPM operation.

If you use the SKIP_EVENT_PROCESSING_MANAGE_MODE tunable, any cluster resource processing is ignored after cluster services are restarted. After LPM operation, the entire partition and all cluster resources are restarted and are set automatically to the previous state. However, if you use the SKIP_EVENT_PROCESSING_MANAGE_MODE tunable and if you manually change the configuration of the cluster resources when the cluster services are in the UNMANAGED state, you must manually restore the cluster resources to its previous state. PowerHA SystemMirror does not determine automatically the state of the cluster service and set the state of the cluster service to the previous state before you use the Unmanaged resource groups option. For more information, see Starting cluster services on a node with a resource group in the UNMANAGED state.