26.4 Establishing Whether You Can Utilize a Serviceguard Toolkit

     

A Serviceguard Toolkit is designed to make setting up a package a quick, easy, and straightforward process. The Toolkits cover most of the common RDBMS systems available as well as products such as NFS and a range of Netscape products. A product known as the Enterprise Cluster Master Toolkit (B5139DA) lists a large proportion of the available toolkits. As more applications become more common, Hewlett-Packard will make such toolkits available. Keep an eye on http://docs.hp.com/ha for the most recent Toolkits. Here is a list of the Toolkits found at the time of this writing:

Table 26-2. List of Current Serviceguard Toolkits

Internet Server or Database Name

Internet Server or Database Version (as shown in swlist output)

Toolkit Version ("what" string)

FastTrack Server

B.03.01.05

B.01.07

Enterprise Server

Netscape version 3.6

B.01.09

B.02.00.13

Enterprise Server Pro

B.03.05.04

B.01.07

Proxy Server

B.03.05.04

B.01.07

Directory Server

B.03.01.03

B.01.07

Messaging Server

B.03.05.04

B.01.07

Collabra Server

B.03.05.01

B.01.07

Calendar Server

B.03.05.02

B.01.07

Informix

All versions up to 9.30

B.01.08

XPS 8.31

B.01.07

DB2

7.1

B.01.07

Oracle

7.3.x, 8.0.x, 8.1.x

B.01.07

9i

B.01.08

Oracle Standby Database

8.1.x

B.01.03

Sybase

12.0

B.01.09

Progress

9.1.A

 

Another product, B5140BA, is known as the Serviceguard NFS Toolkit. NFS, databases, and Netscape cannot be started as service processes ; therefore, they require an application monitoring script . The primary value of the toolkits is the inclusion of an application monitoring script for each application. This eliminates the need for you to code a monitoring script from scratch. The monitoring scripts included with the toolkits require minor modifications to customize the script for your application.

The Enterprise Cluster Master Toolkit is intended to contain all future scripts for ease of ordering.

This toolkit is already loaded onto the machine when you install the HP-UX 11i Mission Critical Operating Environment.

We can then set up a SERVICE_NAME that relates to a SERVICE_CMD detailing the name of the application monitoring script . We also run the script in the customer_defined_run_cmds and customer_defined_halt_cmds with a command line argument specifying the start or stop . The value of the Toolkit is that the hard work of writing a script, which details all of the application processes for our application, has been taken care of for us. When using a Toolkit, I will study the supplied script to ensure that it supports the version of the application I am using. If not, I may have to get the most up-to-date version of the Toolkit from my HP supplier or Technical Account Manager (if I have one).

We will look at using a toolkit in Chapter 27, "Managing a Serviceguard Cluster," when we add additional packages to our cluster configuration. If our application was written in-house or is not listed above, the setup of a Serviceguard package is a little bit more involved. We need to configure our own package control script and write our own application monitoring scripts . The need for an application monitoring script will become obvious when we look at a "typical" application.

26.4.1 A "typical" application

We are going to discuss a "typical" application. As far as Serviceguard is concerned , we need to fully understand our application in order to set up our package control file and startup script. If we think about a "typical" application, its startup and running characteristics may look something like this:

  • Run a startup script. This will start a number of daemon processes.

  • The startup script dies, leaving the daemons running.

  • The application daemons spawn child processes to undertake certain tasks . When a particular task is complete, the child process will die.

  • Run a shutdown script to kill the application daemons.

The essence of a Serviceguard package is the persistence of processes. Serviceguard needs to monitor the application daemon processes. As we will see, this poses a problem for the setup of our application startup script.

In our Serviceguard application startup script, we supply a single or multiple service processes ( SERVICE_CMD ). These are the programs/scripts that Serviceguard will run to start the application, and Serviceguard will consequently monitor them. Here are some rules for a service process:

  • A Service Process must :

    - Be defined in the package configuration file via a SERVICE_NAME

    - Be invoked from within the control script

    - Always be present in order for the package to be considered healthy

  • A Service Process must not :

    - Be a process that is spawned and respawned as requests come in

    - Be a process that only the application can invoke ( i.e. Oracle daemons)

This is the crux of our "typical" application. The SERVICE_CMD we supply to Serviceguard would normally be our own, real application startup script that initiates all the necessary daemons. If we use that as a SERVICE_CMD , Serviceguard will run it to start our application, but being a startup script, it will run the necessary daemons and then die. Because our SERVICE_CMD has died, Serviceguard will deem our application to have died. This constitutes an application failure, and the application will be shut down and relocated to an adoptive node. There is a solution to this. The SERVICE_CMD we specify to Serviceguard must not be the application startup script but an application monitoring script that we need to write ourselves . This will monitor all our application processes, go to sleep for about 10 seconds, and then wake up and test for all our application processes. It will do this repeatedly until it detects that a critical application process has died (or is not responding; we can program the script to be as intelligent as we like), at which time the application monitoring process dies. Serviceguard detects that the SERVICE_CMD has died and, hence, the application must be dead; this constitutes an application failure and Serviceguard will correctly start the process of moving this application to an adoptive node. One question often asked is, "How does the actual application get started?" This is taken care of in the Serviceguard startup script in a function called customer_defined_run_cmds . This is where we supply our real application startup routines. These will be executed before the SERVICE_CMD s; hence, the application gets started up and then the monitoring script begins. In a similar way, we shut down our application via specifying our own application shutdown script in the function customer_defined_run_cmds , which will be executed after the SERVICE_CMD s are shut down. Figure 26-1 shows you a diagram of basically how it works.

Figure 26-1. Application package monitoring.

graphics/26fig01.jpg


The first package I will set up is such a "typical" application. It is a simple example of a program that operates like a daemon; the main program spawns the necessary child processes and then itself dies. We will need to write our own application monitoring script to monitor the application daemons. Serviceguard will then monitor the application monitoring script. Our testing will include the following:

  • Kill the application daemons.

    The monitor should detect this and then fail. Causing Serviceguard to move the package to an adoptive node.

  • Kill the application monitor.

    Serviceguard should detect this and shut down the application and move it to an adoptive node.

There are some examples of an application not following this "typical" pattern. You need to be absolutely sure that the SERVICE_CMD that Serviceguard will run is a program that meets the criteria for a service process listed above. Setting up a Quorum Server to be an application package is one such example.

Let's continue the process of configuring an application package. The next step in our "cookbook" is to set up and understand the workings of any in-house applications. Once we know how our applications behave, we can then configure the Serviceguard package configuration and control scripts. Here goes.



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net