Generic Data Service Overview

A generic data service (GDS) is a mechanism for making simple applications highly available or scalable by plugging them into the Sun Cluster's Resource Group Management framework. This mechanism does not require the coding of an agent which is the typical approach for making an application highly available or scalable.

The Generic Data Service (GDS) is a single, precompiled data service that you can use to make various applications highly available or scalable. In this approach, the precompiled data service and its components, the callback method implementations and the RTR file, are not subject to change.

The GDS model is especially attractive to people who develop custom HA solutions. With the GDS model, developers are able to separate the user modifiable components from the unchangeable ones and thus are able to better diagnose problems on a customer site.

Precompiled Resource Type

The generic data service resource type, SUNW.gds, is included in the SUNWscgds package. The scinstall utility installs this package on the cluster during cluster installation. The SUNWscgds package includes the following files:

# pkgchk -v SUNWscgds 

/opt/SUNWscgds
/opt/SUNWscgds/bin
/opt/SUNWscgds/bin/gds_monitor_check
/opt/SUNWscgds/bin/gds_monitor_start
/opt/SUNWscgds/bin/gds_monitor_stop
/opt/SUNWscgds/bin/gds_probe
/opt/SUNWscgds/bin/gds_svc_start 
/opt/SUNWscgds/bin/gds_svc_stop
/opt/SUNWscgds/bin/gds_update
/opt/SUNWscgds/bin/gds_validate 
/opt/SUNWscgds/etc
/opt/SUNWscgds/etc/SUNW.gds

Methods of Creating a Service Using GDS

There are 2 methods of creating a service that uses GDS:

• GDS using the command line interface

• GDS using the SunPlex Agent Builder

GDS and the Command Line Interface

This method utilizes the precompiled data service code in SUNWscgds but requires that the developer use the command line interface (scrgadm and scswitch) to enter the parameters required to create and configure the resource.

GDS and the SunPlex Agent Builder

Use the SunPlex Agent Builder and select GDS to generate the driving scripts which rely on the precompiled code being available in SUNWscgds. The user input is used to generate a set of driving scripts that configure resources for the given application.

How to Select Which Method to Use to Create a GDS

As shown in the procedures "Command Line Interface to Create a Highly Available Service Using GDS" and "Command Line Interface to Create a Scalable Service Using GDS", a significant amount of typing is required to issue the appropriate scrgadm commands.

Using GDS with SunPlex Agent Builder simplifies the process since the precompiled binaries are used and there is significant less typing of input information.

Mandatory Inputs

The start command launches the application. It should be a UNIX command complete with its arguments that is acceptable by pmfadm. For network aware (or client-server) applications, the command to launch the application may contain the hostname (or IP address) it's going to listen on. In this case, the user has to configure the LogicalHostname or SharedAddress resources separately. The GDS start method launches the application under the control of Process Monitoring Facility (PMF) using the start command.

Optional Inputs

The optional inputs to GDS include the following:

• Stop command

• Probe command

• Timeout for start method

• Timeout for stop method

• Timeout for fault monitor probe

• Child monitor level (only with GDS using command line interface)

Stop Command

The stop command is supposed to stop the application and not return until the application has been completely stopped. It should be a UNIX command complete with its arguments that is acceptable by hatimerun.

If the stop command is provided, the GDS stop method launches the stop command with 80% of the timeout. Regardless of the outcome of launching the stop command, the GDS stop method still sends SIGKILL with 15% of the stop timeout. The remaining 5% of the time is assumed to have been used by the house keeping overhead.

If the stop command is omitted, the GDS tries to stop the application using signals. GDS first sends SIGTERM with 80% of the stop timeout. If the SIGTERM fails to stop the application, GDS then sends SIGKILL with 15% of the stop timeout. The remaining 5% of the time is assumed to have been used by the house keeping overhead.

Probe Command

The probe command checks the health of the given application. It should be a UNIX command complete with its arguments that is acceptable by hatimerun. The exit status of the probe command is used to determine the severity of the failure of the application. This exit status, called probe status, must be an integer between 0 (for success) and 100 (for complete failure). The probe status is used with in the GDS probing algorithm to take the decision of restarting the application locally, versus failing it over to another node.

If the probe command is omitted and the application uses network, GDS provides its own simple probe. This alternative probe simply connects to the application on the given hostname and port number. If the connect succeeds, it disconnects immediately. If both connect and disconnect succeed, the application is deemed to be running healthily.

The probe provided with GDS is only intended to be a simple substitute for the fully functioning application specific probe.

Start Method Timeout

The default timeout for the start method is 300 seconds.

Stop Method Timeout

The default timeout for the stop method is 300 seconds.

Fault Monitor Probe Timeout

The default timeout for the fault monitor probe is 30 seconds.

Child Monitor Level

This option provides more control over what level of processes get monitored through PMF. It denotes the level up to which the forked children processes have to be monitored. This is the -C argument to the pmfadm command. See the pfmadm(1M) man page for more details.

This option can only be specified using the command line interface. This option cannot be specified if you are using the SunPlex Agent Builder.