PowerHA SystemMirror support for running a resource group in an AIX WPAR
When a WPAR-enabled resource group is brought online, all
its associated resources are activated within the corresponding WPAR.
The WPAR-enabled resource group is associated with a WPAR based on
their common name. If a resource group called test_resource_group is
WPAR-enabled, then it is associated with a WPAR with the name test_resource_group.
When a resource group is made WPAR-enabled, all the user-defined scripts (such as application start, stop, and monitoring scripts) must be accessible within the WPAR, at the paths that are specified in the PowerHA® SystemMirror® configuration.
Support for mixed-type nodes
A WPAR-enabled resource group can consist of some nodes that are not WPAR capable. To use the WPAR functions, you do not need to upgrade all their nodes of the resource group to the latest version of the AIX® operating system.
When a WPAR-enabled resource group comes online on a WPAR-incapable node, it behaves as if the WPAR property for the resource group was not set. You must ensure that all the user-defined scripts are accessible at the same path that was previously specified in the PowerHA SystemMirror configuration.
Enable/disable WPAR property of a resource group
If the WPAR property of a resource group is changed by using DARE (when the resource group is online), then the WPAR property takes effect only when the resource group is brought online the next time.
Resource assignment to a WPAR-enabled resource group
PowerHA SystemMirror automatically assigns and unassigns resources to a WPAR as the corresponding WPAR-enabled resources comes online or goes offline. You must not assign any PowerHA SystemMirror resources to a WPAR.
Restrictions for running a resource group in a WPAR
PowerHA SystemMirror has the following restrictions for WPAR support:
- Only the following resource types are supported to run in a WPAR: Service Label, Application Controllers, and File Systems.
- Every resource group that is to be run in a WPAR should have at least one service address that is associated with it.
- PowerHA SystemMirror Smart Assist scripts are not supported for a WPAR enabled resource group. Thus, any application controller or application monitoring script that uses the PowerHA SystemMirror Smart Assist scripts cannot be configured as a part of a WPAR enabled resource group.
- For all applications that are associated with a WPAR-enabled resource
group, you must ensure that the application start, stop, and other
user-defined scripts (such as application monitoring scripts), are
accessible within the WPAR. Note: The PowerHA SystemMirror configuration verification is not checking for the access permissions for the application scripts that are a part of a WPAR-enabled resource group.
- When a resource group is enabled to use WPAR, PowerHA SystemMirror manages the WPAR by using the resource group management function during cluster events. You must not manage this WPAR as you would a stand-alone WPAR. For example, you must not log in to the WPAR and stop it, and you must not stop the WPAR from the global environment. PowerHA SystemMirror does not monitor the operational state of the WPAR. If you manage the WPAR outside of PowerHA SystemMirror it might cause the WPAR enabled resource group to go into the Error state.
- Process application monitoring is not supported for WPAR-enabled resource groups.
- For every WPAR-capable node that is a part of a WPAR-enabled resource
group and contains a WPAR for a WPAR-enabled resource group, at least
one of the service labels (of the WPAR-enabled resource group) must
be accessible from the corresponding global WPAR. Note: When a WPAR-enabled resource group is brought online on a WPAR capable node, PowerHA SystemMirror (which runs in the global WPAR), automatically sets up rsh access to the corresponding WPAR to manage various resources associated with the resource group.