Live Application Mobility in AIX 6.1

WPARs, LPARs, and Live Application Mobility

Among other benefits, WPARs allow you to deploy applications more quickly and requires far fewer dedicated hardware resources. In fact, unlike a logical partition (LPAR), no physical resources are actually required to build a WPAR. As most system administrators have come to realize, the biggest disadvantage of LPARs are maintaining multiple images, which goes along with possibly over-committing expensive hardware resources, such as CPU and RAM. In other words, while partitioning helps you consolidate and virtualize hardware within a single box, operating system virtualization through WPAR technology goes one step further and allows for an even more granular approach of resource management. It does this by allowing for the sharing of OS images and is clearly the most efficient use of CPU, RAM, and I/O resources.

Rather than a replacement for LPARs, WPARs are a compliment to them and allow one to further virtualize application workloads through operating system virtualization. WPARs also work very well with Role-Based Access Control (RBAC), which is another important innovation in AIX 6.1. So what does this have to do with Live Application Mobility?

Live Application Mobility allows you to relocate running WPARs from one LPAR to another. While Sun may have a similar concept with its zone-based strategy, it does not provide for a hot migration of running applications. Of all the UNIX®-based systems, only the IBM AIX OS has this important innovation. The way it works is that it uses features such as checkpointing to move the actual running partitions. The checkpoint saves and validates the status of the current application and then starts its back up on the other LPAR in this saved state. Do you still need High Availability solutions such as HACMP if you will be using this feature? Absolutely. It's important to make the distinction that Live Application Mobility provides for increased availability during scheduled outages, not unscheduled outages. One needs to actively use WPAR manager or the command line interface to initiate the movement of the WPARs; it is not automatic. Live Application Mobility is actually an optional feature that is enabled within the WPAR manager component. What's the difference between partition mobility and Live Application Mobility? Partition mobility is a feature of Power6™ that allows you to migrate entire AIX or Linux® LPARs from one physical server to another. It does not require AIX 6.1 or WPARs. This feature helps when scheduling downtime for entire frames.

If you need to take an entire managed system off-line, you can move its partitions to another server. It also allows you to balance workloads and resources by allowing you to move LPARs to different physical servers. Live Application Mobility is an innovation of AIX 6.1 alone and is a component of its WPAR strategy, allowing you to move workloads rather than entire partitions. The actual target WPARs can be a different server, though it doesn't have to be. It is more flexible, as you can use it on environments where you have a mixed physical architecture: Power5 and Power6. It moves applications away from systems that require scheduled downtime for maintenance. It can also be used to improve performance by moving workloads from stressed out servers to less overtaxed ones. Further, it can help provide energy savings by moving the workload around in such a way as to allow a physical server to literally sleep during non-peak periods. The table below shows some basic differences between Live Application Mobility and Partition Mobility.

Live Application Mobility -- Configuration challenges

This section looks at how to configure Live Application Mobility.

There are two ways to configure Live Application Mobility. The first is by using the WPAR manager (part of the IBM System Director family) and the second is using the command line. IBM strongly suggests you use the WPAR manager, and having used both, I would say it's simpler and much more powerful to use the manager. Furthermore, it performs certain compatibility tests between both the source and global environments, which are just not provided from the command line. IBM goes as far as to say: "Using the WPAR manager is therefore the only recommended way to perform a WPAR relocation". That was enough for me not to even consider demonstrating moving WPARs around using the command line; however, if you are so inclined to experiment, the command line tools include the following commands:

• chkptwpar -- This is the command that creates a snapshot of all the tasks in a WPAR.

• killwpar -- This command kills all tasks belonging to a paused WPAR.

• restartwpar -- This command creates the workload partition from the checkpointable state.

• resumewpar -- This command resumes execution of a paused or frozen WPAR.

The WPAR manager uses a browser-based interface that allows for the management of the WPARs from literally any platform. It is designed to manage WPARs and provides the enablement that allows one to use Live Application Mobility. It is also a licensed product, which means it costs money. It includes a centralized database consisting of DB2® with an agent that needs to be installed on each computer. This is very helpful because you do not need to log into the LPAR itself to actually create, configure, and enable Live Application Mobility. It also provides for policy-based mobility, which can significantly reduce your overall workload.

When planning for Live Application Mobility, it's important to start out by defining your reason behind relocating the WPARs. And once you understand the why behind your decision to relocate the WPARs, you'll also need to take into account the workloads on both the source and target system. It's one thing to use Live Application Mobility as a tool that will allow you to move an application off of an LPAR whose physical server needs maintenance for a couple of hours; it's another issue entirely to use this to improve application performance. When using it for the latter purpose, you'll need to search for frames that have better CPU and memory resources than the source systems. If your goal for using Live Application Mobility is energy management and using it as a server consolidation tool, then resource utilization is not as important.

WPAR manager and Live Application Mobility demo

This section shows how to install WPAR manager and relocate a running WPAR.

First, install the WPAR manager. There are two parts to the process:

1. Installation of the WPAR manager

2. Installation of the agent

The agent goes on every system that will be managed by the WPAR manager, while the WPAR manager and centralized database is installed on only one system. Start by installing the filesets for the WPAR manager (see Listing 1).

When the filesets are installed, you need to configure the database: # /opt/IBM/WPAR/manager/db/bin/DBInstall.sh -dbinstallerdir /db2 -dbpassword my_password.

When this is completed, you'll need to configure the database connection between the WPAR Manager and the database, and to define the WPAR Agent registration password. While there are three supported modes to run the WPAR manager configurator, we used the console mode -- the non-GUI version -- for our install. We found this to be the simplest method to use.

The final piece is installing and configuring the agent, which must be done on each partition that you want managed by the WPAR manager: # installp -acqgYXd <MOUNT_POINT> wparmgt.agent.

When the filesets are installed, this command will configure the agent for you: # /opt/IBM/WPAR/agent/bin/configure-agent -yourhostmachine.

When completed, we're ready to point our browser to the IP address where WPAR manager is configured. I was able to use this from a VNC client after configuring VNServer on the host console or from a standard Firefox browser, even from a PC running Windows®. The latter will work only if you are on the same network as the WPAR manager.

Now, let's return to the WPAR manager. Regardless of where you create your WPAR, you can relocate your partitions from here as well (see Figure 4).