This chapter discusses the following:
All services in SGI Cluster Manager for Linux are managed by the clusvcmgrd daemon. The clusvcmgrd daemon does the following:
Determines the cluster member where a service must run
Processes service events
Executes service scripts in a sequential manner
The service script starts, stops, or determines the status of given service. The functions within the service script take the following parameters:
The functions within the service script run application scripts in the following order:
device (including local XVM volumes) filesystem (including CXFS) nfs ip address samba user-defined application (such as DMF and TMF applications) |
user-defined application (such as DMF and TMF applications) ip address nfs samba filesystem (including CXFS) device (including local XVM volumes) |
You cannot change the order in which the application scripts are run.
The status of each application in a service is checked in a sequential manner. If the status of an application in the service fails, the status of other applications is not checked.
User application scripts are usually present in the /usr/lib/clumanager/services directory. These scripts return $FAIL (value 1) on failure and $SUCCESS (value 0) on success for each action.
To add a new application, you must write a set of scripts that are specific to the user application. The user application script must be a bash shell script and should contain a shell function with a name that is the same as the application and should take an action ( start, stop, or status) and a service ID as parameters. For example: a user application script for failing over an apache webserver could be called apache_webserver and it should have a shell function apache that takes an action and a service ID as parameters. The shell function will be called by the service script to execute appropriate action for a service.
The newly written script is configured as a user application script parameter. You must add all devices and IP addresses that the application depends on to the service. NFS export points and Samba shares can also be part of the service.
For general information about creating a service, see “Step 8: Configure the Service” in Chapter 4.
Figure 6-1 shows the GUI screen to create a service. To get to this window, select the Services tab from the Cluster Configuration window.
The following command creates a service named userapp with the newly defined user script new_application:
# sgicm-config-cluster-cmd --add_service --name=userapp \ --userscript=/usr/lib/clumanager/services/new_application \ --checkinterval=40 servicetimeout=60 |
You must copy the newly created script to the following location in all members in the cluster:
/usr/lib/clumanager/services/new_application |
To fail over an apache webserver and mySQL database as part of a service, you must do the following:
Create a directory for the service application scripts. For example:
# mkdir /usr/lib/clumanager/services/service1 |
Create a script within the directory for each application. For example, they could be named apache_webserver and mySQL:
apache_webserver should contain a shell function that takes an action and service ID as parameter. This function should perform start/stop/status operation on the apache server for service1.
mySQL should contain a shell function that performs start/stop/status operation on the mySQL database server for service1.
| Note: The directory can contain symlinks to actual scripts that are present in some other directory. |
The following is an example user application script named service_test. This example script contains a shell function test that takes an action (start, stop or status) and service ID as parameters. The shell function test can call shell functions (as in the example) to perform the actions or to execute other scripts or commands to perform the action passed as parameters.
#
# startTest serviceID
#
startTest()
{
if [ $# -ne 1 ]; then
logAndPrint $LOG_ERR "Usage: startTest serviceID"
return $FAIL
fi
typeset svcID=$1
typeset svc_name=$(getSvcName $DB $svcID)
logAndPrint $LOG_INFO "Running test start script for service $svc_name "
return $SUCCESS
}
#
# stopTest serviceID
#
stopTest()
{
if [ $# -ne 1 ]; then
logAndPrint $LOG_ERR "Usage: stopTest serviceID"
return $FAIL
fi
typeset svcID=$1
typeset svc_name=$(getSvcName $DB $svcID)
logAndPrint $LOG_INFO "Running test stop script for service $svc_name "
return $SUCCESS
}
#
# statusTest serviceID
#
statusTest()
{
if [ $# -ne 1 ]; then
logAndPrint $LOG_ERR "Usage: statusTest serviceID"
return $FAIL
fi
typeset svcID=$1
typeset svc_name=$(getSvcName $DB $svcID)
logAndPrint $LOG_INFO "Running test status script for service $svc_name "
return $SUCCESS
}
# Given an action and service ID number run that action for that service.
test()
{
if [ $# -ne 2 ]; then
logAndPrint $LOG_ERR "Usage: test [start, stop, status] serviceID"
return $FAIL
fi
typeset action=$1
typeset svcID=$2
case "$action" in
'start')
startTest $svcID
return $?
;;
'stop')
stopTest $svcID
return $?
;;
'status')
statusTest $svcID
return $?
;;
esac
} |