AIX v6.1 Workload Partitions (WPARs)


 

+

Search Tips   |   Advanced Search

 

Workload partitions (WPARs) offer operating-system environments that can host applications and isolate them from applications executing within other WPARs.

WPAR is a purely software partitioning solution that is provided by the operating system and has no dependencies on hardware features. AIX V6 is available for POWER4, POWER5, POWER5+, and POWER6.

The application in a WPAR thinks that it is being executed in its own dedicated AIX instance.

Workload partitions can be created within an AIX6 LPAR. An LPAR can be a full physical server not partitioned (also known as a full-system partition in POWER4 terminology).

The term global environment is introduced in the AIX terminology to refer to the part of the AIX operating system that hosts WPARs. Creating WPARs within an LPAR does not restrict the use of the hosting AIX instance. It is possible to log in to the global environment, to launch a program in the global environment, and to perform the exact same actions that are possible on any AIX instance that does not host WPARs.

WPARs can be relocated from LPAR to LPAR, whether these LPARs are hosted on the same physical server or on different physical servers.

The global environment owns all physical resources of the LPAR:

It allocates CPU and memory resources to the WPARs and provides them access to the network and storage devices.

The global environment has visibility into the WPARs. It is possible from the global environment to see (and control) the processes executing within the WPARs and to see the file systems used by the WPARs.

Most performance monitoring and tuning activities are performed from the global environment.

To most applications, the WPAR appears as a booted instance of AIX. In general, applications can run without modification in a WPAR.

Inside the WPAR, the applications:

There are two types of WPARs that can reside in a global environment:

A system WPAR is similar to a typical AIX environment. Each System WPAR has dedicated writable file systems, although it can share the global environment /usr and /opt file systems in read only mode. When a system WPAR is started, an init process is created for this WPAR, which in turns spawns other processes and daemons. For example, a system WPAR contains an inetd daemon to allow complete networking capacity, making it possible to remotely log in to a system WPAR. It also runs a cron daemon, so that execution of processes can be scheduled.

If an application or group of applications can be started with one command of the AIX command-line interface, it is a candidate to be hosted by an application WPAR. This command is passed as an argument to the wparexec command that will create an application WPAR. As soon as the passed command exits, the WPARs is terminated.

An application partition shares the file system of the global environment. It does not own any dedicated storage.

An application partition can run daemons. But application partitions will not run any of the system service daemons, such as inetd, srcmstr, and so forth. It is not possible to remotely log in to an application partition or remotely execute an action into an application WPAR.

 

Live application mobility

Both system and application WPARs are capable of being configured to support mobility, or relocation.

Distinction: In 2007, IBM System p6 and AIX V6 have two features that seem similar, but are different: WPAR mobility and live partition mobility:

The capability to move one WPAR from one LPAR to another, possibly from one physical system to another, can be executed on active partitions. In this case, the application undergoes active relocation, hot-migrated, without stopping the application. The only visible effect for a user of the application is a slightly longer response time while the application is migrating.

Workload partition mobility uses checkpoint and restart features to move WPARs. The checkpoint saves the current status of the application and then restarts it on a new system or OS instance at the previously saved state.

Partition mobility is not a replacement for a high availability solution. The premise allows for planned migrations of workloads from one system to another so that the application is uninterrupted, for example, during hardware maintenance or a firmware installation on the server. The workload does not need to be aware of the migration for the most part. But proper planning and testing are always recommended before moving anything into a production environment.

 

WPAR benefits


Improvement of service level agreements

Hardware components of an IT infrastructure might need to undergo maintenance operations requiring the component to be powered off. If an application is not part of a cluster of servers providing continuous availability, either for technical, organizational, or cost reasons, WPARs can help to reduce the application downtime. Using the live partition mobility feature, the applications that are executing on a physical server can be temporarily moved to another server without an application blackout period during the period of time required to perform the server physical maintenance operations.

Long running jobs can take advantage of the checkpoint/restart feature of WPARs. It can be used to protect them against a failure that requires restarting all computations from the beginning. The checkpoint feature can be used to regularly capture a snapshot of the application runtime environment, without having to instrument the code. In the case where the job needs to be stopped before reaching completion of the computation, the job can be resumed in the state it was when the last checkpoint was saved.

The checkpoint/restart feature can also be used to execute long lasting batch jobs on a system with limited resources. This job can be run at nighttime, be paused during the daytime, when the computer resources have to be dedicated to other applications, such as transaction handling or Web serving, and then resumed at the beginning of the next night.

WPARs can also help in an environment where an application needs to be started often, on-demand, and quickly. This might apply, for example, in test environments where resources are too scarce to keep multiple applications executing concurrently when not in use. Using WPARs, many applications can be defined on a server, but not activated. Activation of the WPARs executing each of these applications can be performed only when needed for a test.

 

Protection of existing hardware investment

Clients having many applications, each running a dedicated POWER-based server or dedicated partition and requiring only a fraction of the available processing power, can, thanks to WPAR, consolidate these applications within one LPAR. Each application can be executed within one WPAR, providing a dedicated environment isolated from the other applications environments, while all WPARs share the physical resource of one LPAR.

 

Optimization of resource usage

WPARs complement other AIX virtualization technologies such as LPARs, DLPARs, and micropartitions

Due to the static allocation of partitions in physical servers, in a typical IT environment, each server is sized with spare capacity to allow for resource consumption increase of all applications executing within this server. Thanks to the mobility feature of WPARs, the server sizing and planning can be based on the overall resources of a group of servers, rather than being performed server per server. It is possible to allocate applications to one server up to 100% of its resources. When an application grows and requires resources that can no longer be provided by the server, the application can be moved to a different server with spare capacity.

The same mobility feature, combined with the policy-based relocation functions of the WPAR Manager, allows you to size a set of servers to handle the peak load, based on the overall resource capacity of the set of servers, and not for each server. In a classical environment, each server must be able to support the peak load of all partitions hosted within that server. Thanks to the WPAR mobility, it is possible to take advantage of free resources in one physical server to offload another physical server hosting applications that require more resources than are locally available.

AIX V6 provides highly granulated control of CPU and memory resource allocation to WPARs, down to 0.01% increments. This technology is therefore suitable for server consolidation of very small workloads. This can be particularly interesting for the replacement of old servers, for which even 10% of one POWER5 or POWER6 processor (the smallest micropartition) exceeds the application needs.

The theoretical upper limit on the number of WPARs that can be executed within one LPAR is 8192.

 

Control of security and privilege command

WPARs support the specialization of admin roles and can help restrict privileges given to one person to just the scope that person needs to control, for example network, users, storage, or software maintenance.

System WPARs have their own user set, independent from the user set defined at the global environment level. An individual, who is using root within a system WPAR, only has superuser privileges for the resources visible within this WPAR. This user cannot control global environment resources, such as network adapter or physical devices, and cannot act on resources belonging to other WPARs. Many applications need the application administrator to use the root user to control the application, even if this person does not need to manage the operating system. WPARs allow you to delegate the superuser privileges to one individual and limit them to an application environment without jeopardizing the global environment.

Users defined in one system WPAR are unaware of the applications executing in the global environment or in other WPARs. They cannot see the list of users or processes outside their WPAR.

IBM AIX V6.1 provides improvement over the previous AIX 5L V5.3 for role-based control of user privileges using Role-Based Access Control (RBAC). An exhaustive description of these new features is available in AIX V6 Advanced Security Features Introduction and Configuration, SG24-7430.

 

Simplified handling of software stack

WPARs allow one to share AIX instances between multiple applications, while still running each application within its own environment, providing isolation between applications. In this case, the more applications that are consolidated within one AIX instance, the less the system administrator has to perform OS fix applications, backups, migration, and other OS maintenance tasks. This type of consolidation requires that all applications can run under the same version and maintenance level of the OS.

In addition to sharing the OS, the system administrator can use WPARs to share application code. In a traditional AIX environment, if several Apache Web servers are needed, they each need to be deployed in a dedicated server or LPAR. In a WPAR environment, it is possible to install Apache in one LPAR and then execute multiple instances of the Apache server within this LPAR, by starting multiple WPARs. Each WPAR runs its own Apache server with its own data in dedicated disk space, but shares the Apache code with all other WPARs. This type of a configuration optimizes memory utilization by eliminating duplication of code and reduces administration maintenance of the Apache code, which only needs to be updated once for all server instances.

IBM AIX V6.1 introduces a new concept in software installation and management: relocatable software packages, which are applications where the files can be installed relative to a base directory that is different from the / root directory of the AIX environment, making it possible to deploy multiple versions of the same application within one AIX instance. The system administrator can take advantage of relocatable applications by starting each version of the application in a specific WPAR, therefore providing multiple servers with different server code versions from one LPAR.

 

Simplified handling of application OS environment

WPAR configurations can be stored in human-readable specification files which can be generated by the OS from existing WPARs or can be edited, created, or modified manually, allowing sysadmins to quickly clone new application environments. These specification files can be used as input to WPAR creation commands, allowing the system administrator to automate through scripts and programs the startup and handling of multiple WPARs.

 

Business continuity: Disaster or failure recovery solution

The checkpointing feature of WPAR allows you to capture a snapshot of an executing application without having to instrument the code. The application checkpoint image is then saved to a file that can later be used to resume execution of an application. Combined with a backup of the application data, the WPAR checkpoint feature can provide an alternate disaster or failure recovery solution for applications that do not use other solutions, such as HACMP or server clusters.

 

Supporting TCM computing strategies

Using WPAR relocation features for live application mobility allows you to consolidate workloads during periods of low usage onto smaller numbers of operating server platforms. In this strategy, you still provide continuous application availability, but you do so using a smaller number of powered up servers. As you approach normal high usage periods, you can then power up additional peak demand server resources and relocate cyclical workloads back to those machines during those peak demand periods. For example, if wer data center peak workload periods are 12 hours per day, 5 days per week, peak load systems only need to be powered up approximately 35% of the time.

 

Planning


Overview

WPARs consist of two parts:

 

Networking

Using aliases decreases the number of adapters needed for communications but requires careful planning of bandwidth utilization, because several WPARs can share the same adapter.

NFS is a prerequisite to the WPAR mobility functionality. Three components are involved...

 

Workload Partition Manager

The Workload Partition Manager includes...

Components include...

The network firewalls must be configured to allow traffic to the specific ports. Default ports include 9510, 9511, 9512, and 9513.

 

Software prerequisites

Although totally isolated from each other, WPARs use the same AIX kernel instance. This means that all WPARs use the exact same level of AIX. Upgrading the environment means updating or upgrading AIX in all hosted WPAR environments. If we have an application that needs a specific version of AIX and cannot be updated, move it to a different LPAR so that it does not prevent the other WPARs from updating.

 

File system considerations

System WPARs created with the default options have shared read-only /usr and /opt file systems. This speeds up the creation, installation, and updating of WPARs and also prevents the accidental removal of system software that is shared with other WPARs. Having the read-only shared /usr and /opt file systems might not suit every application; certain applications are designed to write in the /usr or /opt file systems. One solution is to define the needed applications writable directory as a different file system and link it to the mount point that the application needs.

Another solution is for the application to not use the global environment shared /usr or /opt file systems. This solution requires extra disk space, because it duplicates the global environments /usr or /opt to the WPARs private and fully writable file systems.

Consolidating many applications within one global environment changes the way the system administrator manages file systems. Instead of managing multiple LPARs, each with a few file systems, the system administrator now manages only one LPAR with many file systems. In both cases, the overall number of file systems remains in the same order of magnitude (although using WPARs slightly reduces this number), but they are controlled within a single system.

By default, a system WPAR has four dedicated file systems...

For example, deploying 200 system WPARs in one global environment will result by default in a global environment with 800 separate file systems and 1200 mount points in the /proc pseudo-file systems. The WPAR technology provides an option to reduce this number of file systems. Instead of using the default file system creation option, the system administrator can choose to create one single file system per WPAR. This solution creates only one real file system (the root / file system) for the WPAR, and subtrees /var, /tmp, and /home are just created as subdirectories of the / file system, instead of real file systems as they usually are in AIX instances and the default system WPAR.

File systems of each system WPAR are created in the global environment directory tree and are mounted under the WPAR base directory. One base directory is defined per WPAR. The default path of the base directory is...

/wpars/partition-name

 

Global Environment considerations

WPARs have no control of hardware devices. The global environment owns all physical I/O adapters.

WPAR IP addresses are configured as aliases on one of the physical network adapters of the global environment.