Chapter 6. Creating a New Highly Available Application

This chapter discusses the following:

The clusvcmgrd Daemon

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

The service script starts, stops, or determines the status of given service. The functions within the service script take the following parameters:

  • An action, which can be one of start, stop, or status

  • A service ID which is a number that identifies the service (the ID is automatically determined and is not user-configurable)

The functions within the service script run application scripts in the following order:

  • start order:

    device (including local XVM volumes)
    filesystem (including CXFS)
    nfs
    ip address
    samba
    user-defined application (such as DMF and TMF applications)

  • stop order:

    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.

Adding a Service

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.

Figure 6-1. Creating a Service

Creating a Service

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

Example of Failing Over Multiple User Applications

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.


Sample User Application Script

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
}