Configuring the service group for the application


Configuring the service group for the application
Prev	Installing the application	Next

The following diagrams illustrates different examples of resource dependencies. In one case the WPAR root is set up on local storage. In the other, WPAR root is set up on shared storage.

Figure: WPAR root on local disks (with direct mount file system)

Figure: WPAR root on local disks (file system mounted from inside WPAR)

Figure: WPAR root on shared storage (with namefs file system)

Modifying the service group configuration

Perform the following procedure to modify a service group's configuration.

To add a service group or modify the service group configuration

Run the hawparsetup.pl command to set up the WPAR configuration.

# /opt/VRTSvcs/bin/hawparsetup.pl servicegroup_name WPARres_name \
WPAR_name password systems

*servicegroup_name*	Name of the application service group.
*WPARres_name*	Name of the resource configured to monitor the WPAR.
*WPAR_name*	Name of the WPAR.
*password*	Password to be assigned to VCS or Security (Veritas Product Authentication Service) user created by the command.
*systems*	List of systems on which the service group will be configured. Use this option only when creating the service group.

The command adds a resource of type WPAR to the application service group. It also creates a user account with group administrative privileges to enable WPAR to global communication.

If the application service group does not exist, the command creates a service group.

Modify the resource dependencies to reflect your WPAR configuration. See the resource dependency diagrams for more information.
Save the service group configuration and bring the service group online.

About configuring failovers

An application can be failed over from an LPAR to a WPAR running on a different LPAR. You can configure VCS to fail over from a physical system to a virtual system and vice versa. A physical to virtual failover gives an N + N architecture in an N + 1 environment. For example, several physical servers with applications can fail over to containers on another physical server. On AIX, a container is a WPAR.

In this configuration, you have two LPARs. One node runs AIX 7.1 (sysA) and another node that runs AIX 6.1 (sysB). The node that runs AIX 6.1 has WPARs configured.

Figure: An application service group that can fail over onto a WPAR

In the main.cf configuration file, define the container name, type of container, and whether it is enabled or not. The following is an example of the ContainerInfo lines in the main.cf file:

ContainerInfo@sysA = {Name = W1, Type = WPAR, Enabled = 2}

ContainerInfo@sysB = {Name = W1, Type = WPAR, Enabled = 1}

On sysA, you set the value of Enabled to 2 to ignore WPARs so that the application runs on the physical system. When an application running on sysA fails over to sysB, the application runs inside the WPAR after the failover because Enabled is set to 1 on sysB. The application can likewise fail over to sysA from sysB.

IMF must be disabled on the node where Enabled is set to 2 (sysA in this example). To disable IMF, set the mode to 0.

On a Workload Partition (WPAR) where the WPAR is ignored to run the application on the physical system, you can disable the IMF for the WPARs.

To disable IMF monitoring

Set the Mode key of IMF attribute to 0:

# hares -override <wpar_res> IMF
# hares -local <wpar_res> IMF
# hares -modify <wpar_res> IMF Mode 0 MonitorFreq 5 RegisterRetryLimit 3 \
-sys sysA