WPAR in AIX 6

Introduction

WPARs are a bold new innovation, implemented within AIX 6.1. It allows administrators to virtualize their operating system, which allows for fewer operating system images on your IBM System p™ partitioned server. Prior to WPARs, you would need to create a new Logical Partition (LPAR) for each new "isolated" environment. This is no longer necessary (with AIX 6.1 only), as there are many circumstances when one can get along fine with multiple WPARs within one LPAR. Why is this important? Every LPAR requires its own operating system image and a certain number of physical resources. While you can virtualize many of these resources, there are still some physical resources that must be allocated to the system. Furthermore, you need to install patches and technology upgrades to each LPAR. Each LPAR requires its own archiving strategy and DR strategy. It also takes some time to create an LPAR; you also need to do this outside of AIX, through a Hardware Management Console (HMC) or the Integrated Virtualization Manager (IVM).

WPARs are much simpler to manage and can actually be created from the AIX command line or through SMIT. LPARs cannot. By far the biggest disadvantage of LPARs is 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 sharing 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 complement to them and allow one to further virtualize application workloads through operating system virtualization. WPARs allow for new applications to be deployed much more quickly, which is an important side-benefit. On the other side of the coin, it's important to understands the limitations of WPARs. For example, each LPAR is a single point of failure for all WPARs that are created within the LPAR. In the event of an LPAR problem (or a scheduled system outage, for that matter), all underlying WPARs will also be affected.

WPARs: How and when to use them

This section further defines the different types of workload partitions and discusses scenarios where WPARs should be used.

As discussed earlier, Workload Partitions (WPARs) are virtualized operating system environments that are created within a single AIX (only supported on AIX 6.1) image. While they may be self-contained in the sense that each WPAR has its own private execution environment with its own filesystems and network addresses, they still run inside the global environment. The global environment -- the actual LPAR -- owns all the physical resources of the logical partition. It is important to also note that the global environment can see all the processes running inside the specific WPARs.

There are two types of WPARs: system workload partitions and application workload partitions. The system WPAR is much closer to a complete version of AIX. The system WPAR has its own dedicated, completely writable filesystems along with its own inetd and cron. Application WPARs are real, lightweight versions of virtualized OS environments. They are extremely limited and can only run application processes, not system daemons such as inetd or cron. One cannot even define remote access to this environment. These are only temporarily objects; they actually disintegrate when the final process of the application partition ends, and as such, are more geared to execute processes than entire applications. Overall, WPARs have no real dependency on hardware and can even be used on POWER4 systems that do not support IBM's PowerVM (formerly known as APV). For AIX administrators, the huge advantage of WPARs is the flexibility of creating new environments without having to create and manage new AIX partitions. Let's look at some scenarios that call for the use of WPARs.

Application/workload isolation

WPARs are tailor-made for working with test and/or QA and development environments. Most larger organizations have at least three environments for their applications. These include development, test, and production. Some environments have as many as five, including demo/training and stress/integration environments. Let's use an example of a common three-tier application environment: Web, application server, and database server. In the land of the LPARs, in an environment where one has five isolated environments, you would need to create 15 LPARs. This is where the WPAR has the most value. In this environment, we would need to create just five LPARs. How is that?

In Table 1, we have five different environments, consisting of a Web server, an application server, and a database server. If we wanted to isolate our environments, the only way to do this would be through logical partitioning. That would involve architecting 15 logical partitions. Of course, we could run some of our Web, application, and database on one LPAR, but if we did that, how would we be able to really mimic our production environments (which would run on separate partitions)? In today's world of 99.9% availability, it is extremely common to give each application environment its own home. With WPARs, we can now do that, without having separate AIX images.

Table 2 illustrates how that is done. Each environment would have its own LPAR, with three WPARs created within each LPAR. Now let's imagine if we had four Web servers, two application servers, and two database servers supporting this environment. Yikes! AIX administrators supporting Fortune 500 companies know what I'm talking about. It can be a nightmare maintaining all these environments. WPARs dramatically simplify the overall work-effort involved in administrating this environment, while at the same time minimizing the expense of having to assign physical resources to logical partitions.

Playing nicely in the sandbox

In virtually every environment I've managed, my staff has begged to have sandbox environments in which to work. These environments would be used only by the systems administrators. It is here that administrators have the opportunity to install new software, test out new patches, install new technology levels, and generally be free to break the system without any effect to the business. Unfortunately, it is always the sandbox that is the first environment that must be given up when a new application needs to be deployed. With WPARs, you can quickly create an isolated environment in which to play. While my preference is to have several WPAR sandboxes within an overall LPAR sandbox, each of these owned by a different administrator, this now becomes less of a luxury than it used to be. Looking at this from another perspective, these WPARs are the training ground for new administrators to learn and practice their craft on. With WPARs, they can now be managed much more efficiently and created without having to assign dedicated devices to them.

Quickly testing an application

The application WPAR can be created in just a few seconds. What better way is there to quickly troubleshoot an application or wayward process? As these are temporary resources, they are destroyed as soon as they end, simplifying the manageability of these partitions.

WPARS: When not to use them

This section discusses situations and scenarios where you may not want to use WPARs.

Security

As stated previously, WPAR processes can be seen by the global environment from the central LPAR. If you are running a highly secure type of system, this may be a problem for you from a security standpoint. Further, the root administrator of your LPAR will now have access to your workload partition, possibly compromising the security that the application may require.

Performance

Each WPAR within LPAR is now using the same system resources of the LPAR. You need to be that much more careful when architecting your system and also when stress testing the system. For example, if you're running a performance benchmark on your pre-production system after a new build has been deployed and there are some developers working on the application server while you are testing your database, this will all be done within one LPAR sharing the same resources. Your teams will all need to understand that there will be competing resources now for the same product.

Availability

If you are in an environment where it is very difficult to bring a system down, it's important to note that when performing maintenance on an LPAR that every WPAR defined will be affected. At the same time, if there is a system panic and AIX crashes, every WPAR has now been brought down. From this standpoint, LPARs without WPARs can provide increased availability across your environment, albeit at a cost that may be prohibitive.

Production

I'm extremely conservative when it comes to production. I like to run each tier in production within its own logical partition. I do this because I like the granularity and complete OS isolation that LPARs provide, without having multiple environments (Web, applicatoin, and database) to worry about.

Physical devices

Physical devices are not supported within a WPAR. While there is a way to export devices, this can be a big problem for applications that require non-exportable devices. In this case, they would be restricted to only running in the global environment. For example, Oracle RAC is not supported using Solaris zones because of this limitation, and should not work in a WPAR environment for the very same reason.

Creating, configuring, and administering WPARs

This section creates, configures, and administers WPARs, both system and application.

System WPARs

The mkwpar command creates the WPAR, installs the filesystems, and prepares the system (see Listing 1). It also synchronizes the root section of the installed software.

Depending on the type of system you are using, this generally takes between two and four minutes. It took me two minutes and 40 seconds, installing 241 filesets on a one-CPU POWER5 processor running at 1654 MHz. To check the status of the WPAR, use the lswpar command (see Listing 2).

In this case, it is still in what is called the "defined state." We'll need to use the startwpar command to make it active (see Listing 3).

You can now see that is it is in an active state (see Listing 4)

Let's run some standard AIX commands (see Listing 5).

Your systems administrator can start and stop processes from the WPAR using the SRC or from the command line, just as they would from the global environment. As the Global (LPAR) system administrator, you will note that a WPAR has lots of filesystems. The WPAR environment is created under /wpars (see Listing 6).

Creating filesystems

Let's turn our attention back to the global environment. Let's create a filesystem through SMIT. You cannot create a f/s or volume group from the WPAR, only from the global environment (LPAR).

We need to make sure that the full path of the filesystem (including the WPAR path) is specified (see Figure 1).

Note that you also cannot increase the size of a filesystem from the WPAR, only from the global environment. You also cannot serve NFS filesystems from within the WPAR; only NFS clients are supported.

Backups

Remember, there are no physical devices in a WPAR. When backing up the WPAR environment, you need to use the savewpar command, again from the global environment.

You can restore using the restwpar command.

Users and groups

You can maintain users and groups within the WPAR, either from the command line or through SMIT. You should understand that the root user for this environment does not have access to the global environment, only to the WPAR (see LIsting 9).

Now let's turn our attention back to the global environment. You can clearly see in Listing 10 that the user was not created in the global environment, only within that specific WPAR.

WPAR manager

It's worth noting that there is a graphical tool called WPAR manager, which is Java™ based and allows for the centralized management of WPARs (see Figure 4).

To see how the process works while it is working, you will see the creation of the WPAR (see Listing 12).

When the process completes, it is gone, just as fast as it was created.