Skip to Content

Using Live Partition Mobility with SAP Instances

Live Partition Mobility (LPM) allows you to migrate a running SAP instance from one physical server to another without disrupting users or running processes. The migration transfers the entire LPAR (logical partition) state, including processor context, memory, connected users, running batch jobs etc.

 

Pre-requisites:-

In order to use LPM, there are several pre-requisites which must be met. Obviously, you need a couple of IBM P6 machines with Virtual I/O Servers (VIOS) enabled. For more accurate technical details, please refer to the following paper from my favourite UNIX guy. 

LPM How to guide 

As far as your SAP instances are concerned, nothing special needs to be done. Everything is handled at the Hardware/Operating System level. LPM works for both single or dual stack SAP instances. 

 

Two types of LPM:-

The LPM process can be performed either with a running SAP instance (Active Migration), but works equally as well with a shut down SAP instance on a powered down LPAR (Inactive Migration). 

 

The AusPost test:-

Obviously you would try LPM during a quiet time on the SAP instance, but these days, there is no such time in my landscape. So for the test, we dynamically reduced (using Power VM technology) the CPU and Memory allocation on the SAP SCM2007 (dual stack) LPAR from 2vpu/8gb RAM to 1vpu/2gb RAM – this would ensure the SAP instance would work the LPAR very hard. I then ran a large SGEN and several brconnect operations.

 

When I looked at ST06n, we were hammering the system (>90% CPU and RAM utilisation) and we had some swapping – the perfect scenario for a hard core test.  

Figure 1 – Hammering the LPAR

I then make the phone call to my favourite UNIX guy, and ask him to LPM me from the P570 frame to the P595 frame. He starts the process while I check the machine serial number in ST06n, the SM21 system log, the SAP O/S Collector log, the ST04n Oracle log and the UNIX syslog. I keep refreshing ST06n until I notice the machine name change in less than 5 minutes.

All SM50 processes keep running, no one is logged off and my ssh session to UNIX maintains connection. 

Figure 2 – Running ST06n to see machine Serial Number before LPM 

Figure 3 – Running ST06n to see machine Serial Number after LPM 

During and after the migration, the SAP instance continues to run normally. Even the SAP license was working (as long as you don’t reboot the instance). We continue to run on the P595 frame for an hour until we decide to LPM back to the original P570 frame. Same process, no outage or disruption and the whole operation is completed in less than 5 minutes. 

 

The AusPost value proposition for LPM:-

LPM is the latest weapon AusPost is using on the road to continuous availability. LPM will help to:-

  • Reduce planned down time by dynamically moving running SAP instances from one server to another.
  • React to increased workloads over month end by moving non essential SAP instances from heavily loaded servers to less used servers – leaving spare capacity for critical month end workload.
  • Develop an energy reduction program which allows easy consolidation of SAP workloads and subsequent powering down of unused servers over weekends.

 

SAP support for LPM:-

Service Marketplace note – 1102760 

More reading on LPM:-

LPM Redbook

 

My exclusion clause:-

It may not be fully supported by all RDBMS vendors yet, however this BLOG represents AusPost experiences…

Lastly, don’t try this at home without a switched on Unix guy.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Matthew Harding
    Great real world production proof of something I’ve only heard or read about – You should present this at Tech Ed partnering with IBM to prove that outages are slowly becoming a thing of the past (except for upgrades and patches of course)…

    Cheers,
    Matt

    (0) 

Leave a Reply