26.9 Creating and Updating an ASCII Package Control Script ( cmmakepkg “s ) This is the file that details the individual components of our application: volumes , filesystems, IP addresses, and processes. The command to create the template is cmmakepkg “s . In our example, we create the control script clockwatch .cntl . Once created, we update the template with the necessary details. Below is output from that process:
root@hpeos001[clockwatch] # cmmakepkg -s clockwatch.cntl Package control script is created. This file must be edited before it can be used.
I was going to list the entire clockwatch.cntl in a similar way as I listed the configuration file clockwatch.conf . In this instance, the vast majority of clockwatch.cntl is not for us to configure ”the code that actually activates volume groups, mounts filesystems, and adds IP addresses. I will list the sections that detail the configuration parameters we need to configure. (NOTE: In relation to disk/volume groups, I have listed ONLY the LVM commands. There are similar commands for VERTIAS VxVM disk groups. As we see, the defaults are suitable for most situations.)
# VGCHANGE="vgchange -a e -q n" # VGCHANGE="vgchange -a e -q n -s" # VGCHANGE="vgchange -a y" VGCHANGE="vgchange -a e" # Default
This section lists the default option for vgchange . Using exclusive mode activation is a good idea (unless we are activating a volume group in shared read-write access for all nodes: see option “a s and “S y . Shared access is normally used only in very specialized situations).
# The volume group activation method is defined above. The filesystems # associated with these volume groups are specified below. # #VG[0]=""
Here, we list each volume group on a separate line. We need to ensure that the array index is increased each time.
#LV[0]=""; FS[0]=""; FS_MOUNT_OPT[0]=""; FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]="" #FS_TYPE[0]="" #
Here, we list the entries for individual filesystems ”one line for each individual filesystem. In my version of Serviceguard (version A.11.14), there are a couple of parameters in the control file that you may not see in earlier versions:
CONCURRENT_VGCHANGE_OPERATIONS=1 CONCURRENT_FSCK_OPERATIONS=1 CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS=1
There are supporting comments explaining the meaning and operation of each parameter. Here is an accompanying comment from the same control file:
# Example: If a package uses 50 JFS filesystems, pkg01aa through pkg01bx, # which are mounted on the 50 logical volumes lvol1..lvol50 for read and write # operation, you may enter the following: # # CONCURRENT_DISKGROUP_OPERATIONS=50 # CONCURRENT_FSCK_OPERATIONS=50 # CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS=50
As you can see from these comments, these parameters may be useful when we have a large configuration. I leave it to you to configure them as you see fit.
# IP/Subnet address pairs for each IP address you want to add to a subnet # interface card. Must be set in pairs, even for IP addresses on the same # subnet. # #IP[0]="" #SUBNET[0]=""
Here we list the IP address(es) and associated subnet addresses for our package. These are the IP address(es) our clients will now use to contact the application, regardless which node is actually running the application.
# Note: No environmental variables will be passed to the command, this # includes the PATH variable. Absolute path names are required for the # service command definition. Default shell is /usr/bin/sh. # #SERVICE_NAME[0]="" #SERVICE_CMD[0]="" #SERVICE_RESTART[0]=""
This is where we need to start being very careful. In this section, we are now relating the SERVICE_NAME s we configured in the configuration file ( clockwatch.conf ) to actual scripts/programs that Serviceguard will execute. You will notice that we have a SERVICE_RESTART option for each service process. The choice to configure and use SERVICE_RESTART is highly application dependent. In lots of situations, you will leave this blank because, if the service process fails, it means we have experienced a critical failure and Serviceguard should move the package to an adoptive node. In other situations, you may wish to restart a particular program a couple of times ( -r 2 ) in case it was a minor problem that caused the process to die unexpectedly. If it still fails after the prescribed number of restarts, then Serviceguard will fail the application and move it to an adoptive node. The third option is for Serviceguard to restart the program indefinitely ( -R ). In this situation, it would be a complete node failure that would cause the package to move to an adoptive node. Setting up a Quorum Server is one such situation where we restart the qs daemon if it accidentally dies. We would move the Quorum Server service to an adoptive node only if the original node fails.
function customer_defined_run_cmds { # ADD customer defined run commands. : # do nothing instruction, because a function must contain some command. test_return 51 }
customer_defined_run_cmds is where any additional command will be run before the service processes are started. In our case, this is where we actually start our application. The service processes are simply the application monitoring script(s).
function customer_defined_halt_cmds { # ADD customer defined halt commands. : # do nothing instruction, because a function must contain some command. test_return 52 }
This is where we run any commands after the service processes have terminated . The test_return function used in both the customer_defined_run_cmds and customer_defined_halt_cmds are simply functions to allow the control file to output an appropriate error if the commands you supply fail in some way. I now list the lines that I have updated for my application:
VG[0]="/dev/vg01"
Volume group name (s):
LV[0]="/dev/vg01/db"; FS[0]="/clockwatch/logs"; FS_MOUNT_OPT[0]="-o rw"; FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]="" FS_TYPE[0]="vxfs" LV[1]="/dev/vg01/progs"; FS[1]="/clockwatch/bin"; FS_MOUNT_OPT[1]="-o rw"; FS_UM OUNT_OPT[1]=""; FS_FSCK_OPT[1]="" FS_TYPE[1]="vxfs
Filesystems to be mounted:
IP[0]="192.168.0.220" SUBNET[0]="192.168.0.0"
IP address for the application:
SERVICE_NAME[0]="clock_mon" SERVICE_CMD[0]="/etc/cmcluster/clockwatch/CLOCKWATCH.sh monitor" SERVICE_RESTART[0]=""
This is the only service process I will configure. If you remember, this will monitor all the processes for my application. I do not want to restart this process because it should fail only if the application fails.
function customer_defined_run_cmds { # ADD customer defined run commands. /etc/cmcluster/clockwatch/CLOCKWATCH.sh start test_return 51 }
This is where I start my application. Remember the requirements for service processes. Because my startup routine spawns child processes, I couldn't use it as a service process, hence the application monitoring script.
function customer_defined_halt_cmds { # ADD customer defined halt commands. /etc/cmcluster/clockwatch/CLOCKWATCH.sh stop test_return 52 }
Finally, this is where I shut down my application. As you can see, it is a relatively straightforward process. The hard work was taken care of when we spent time understanding the workings of our application. I have talked to many administrators who think they know how their application works, only to find out they don't when it comes to configuring their applications into a Serviceguard cluster. Without that knowledge, we would have spent many hours " tinkering " with this file trying to "mould" the application into Serviceguard. In many instances, it is due to the definition of the SERVICE_CMD s. Many administrators ask the question, "How many SREVICE_CMD s should I have?" Obviously, there is no easy answer to that. The answer I would give is actually another question, "How many critical components of your application do you want Serviceguard to manage?" Remember, if a SERVICE_CMD cannot be restarted, Serviceguard will deem the entire application to have failed and move the application to an adoptive node. We are now ready to manually distribute this control script to all relevant nodes in the cluster. | 