26.3 Understanding How a Serviceguard Package Works

     

As far as Serviceguard is concerned , a "package" constitutes all of the resources an application will require to operate in a high availability cluster. These resources include:

• An LVM volume group or VxVM disk group

  It is likely that applications will use shared data, so we need to specify where the data is located. This includes filesystem mount points if filesystems are to be used. If no shared data is used, then no LVM/VxVM entries need be listed.

• An application IP address

  Instead of contacting the application via an individual server hostname/IP address, we will allocate an IP address for the application. User client access will need to be modified to point to this new IP address. After an application failure, this IP address will be relocated to a new server. The users will experience a small interruption in service while this happens, but they need not know that the application has "moved" to a new server. If clients are located on different subnets, the application will need multiple IP addresses on each subnet.

• Application processes

  These are the processes that Serviceguard will monitor. A failure of one of these processes constitutes an application failure, which means that Serviceguard will move the application to an adoptive node. Application processes are commonly known as service processes , because each process is offering a particular and important service to the application. Service processes can be restarted if necessary. Failure of a service process renders the application to have failed. Serviceguard will move a failed application to an adoptive node. Each of the monitored processes is known by an associated SERVICE_NAME , e.g., DB_READER . The SERVICE_NAME is further defined in the actual program known as a SERVICE_CMD .

• Other resources that we deem necessary for the application to operate properly

  As we see, we can use EMS (Event Monitoring Service) resources to control the availability of an application. This could be the amount of space in a given filesystem. If this resource goes below the threshold we configure, this constitutes an application failure and Serviceguard will move the application to an adoptive node.

The configuration of the Serviceguard configuration files for a package is performed in two stages:

1. Configure a package control file.

   This file outlines the major resources for the package. This ASCII file will be compiled into the cluster binary configuration file and automatically distributed to all nodes in the cluster. The major resources listed include:

   - Package name

   - Failover/Failback behavior (more on this later)

   - List of adoptive nodes

   - Package startup and halt script (known as the package control script ):

   This is the Serviceguard package control script in item (2) below. This details the individual "services," including the actual program names . We also list LVM/VxVM IP Address details in this package control script . We call it a control script because it is this script that will be executed to control the actual startup and shutdown of the application.

   - Names of service processes (In this file, we are not defining the actual programs themselves , just a name to associate with it. Service processes are given an individual SERVICE_NAME , e.g., DB_READER . A package can have zero to 30 individual service processes .)

   - List of subnets that this application will be used on (This is not the actual IP addresses, but the network addresses. This is to inform Serviceguard which LAN cards need monitoring for this application.)

   - Any EMS resources for this application

2. Configure a package startup and halt script.

   This Serviceguard ASCII file details the actual mechanism to start and halt the application, down to the actual pathnames to find programs. To make administration easier, this file can start as well as halt the application. The actual commands to perform tasks such as activating volume groups are coded in shell functions. All we need to do is to configure, via shell variables , the various components that constitute our application. This file is not compiled into the cluster binary configuration file.

   IMPORTANT

   The package startup and halt script(s) must be distributed manually to all nodes in the cluster that will run this application, because they are not compiled into the Serviceguard application binary configuration file.

   
   

   This is a good thing. If we change the mechanics of how a package runs, e.g., change or add a volume group, we can simply update this file and redistribute it. If we change the underlying structure of the package control file, we would have to recompile and redistribute it. This would probably mean shutting down the application. The components of this file include the following:

   - Each SERVICE_NAME is further defined down to the SERVICE_CMD that details the pathname to an actual program/script.

   - IP addresses for the application are detailed.

   - LVM/VxVM shared volumes are listed.

   - Any associated filesystems mount points are listed.

   - Any additional programs we would like to run ( customer_defined_run_cmds ) before starting the application and after halting ( customer_defined_halt_cmds ) the application. This will be important, as we see later.