The following sections describe how to display, enable, disable, modify, relocate, and delete a service, and how to handle services that fail to start. Examples of setting up specific types of services are provided.
After setting up disk storage and installing applications to be managed by the cluster, you can configure services to manage these applications and resources by using the Cluster Configuration Tool.
To configure a service, follow these steps:
If applicable, create a script to start, stop, and check the status of the application used in the service. Refer to Section 4.1.2 Creating Service Scripts for information.
Gather information about service resources and properties. Refer to Section 4.1.1 Gathering Service Information for information.
Set up the file systems or raw devices that the service uses. Refer to Section 4.1.3 Configuring Service Disk Storage for information.
Ensure that the application software can run on each member (in either the associated failover domain, if used, or in the cluster) and that the service script, if any, can start and stop the service application. Refer to Section 4.1.4 Verifying Application Software and Service Scripts for upgrade instructions.
If upgrading from an existing cluster, back up the /etc/cluster.conf file. Refer to Section 3.2 Installation Notes for Red Hat Enterprise Linux 2.1 Users for upgrade instructions.
Start the Cluster Configuration Tool and add services, specifying the information about the service resources and properties obtained in step 2.
Save your configuration. Saving the settings on one cluster member propogates to other cluster members automatically.
For more information about adding a cluster service, refer to the following:
Before configuring a service, gather all available information about the service resources and properties. In some cases, it is possible to specify multiple resources for a service (for example, multiple IP addresses and disk devices).
The service properties and resources that you can specify using the Cluster Configuration Tool are described in Table 4-1.
| Property | Description | ||||
|---|---|---|---|---|---|
| Service name | Each service must have a unique name. A service name can consist of one to 63 characters and must consist of a combination of letters (either uppercase or lowercase), integers, underscores, periods, and dashes (hyphens). A service name must begin with a letter or an underscore. | ||||
| Failover domain |
| ||||
| Check interval | Specifies the frequency (in seconds) that the member checks the health of the application associated with the service. For example, when you specify a nonzero check interval for an NFS or Samba service, Red Hat Cluster Manager verifies that the necessary NFS or Samba daemons are running. For other types of services, Red Hat Cluster Manager checks the return status after calling the status clause of the application service script. By default, check interval is 0, indicating that service monitoring is disabled. | ||||
| User script | If applicable, specify the full path name for the script that is used to start and stop the service. Refer to Section 4.1.2 Creating Service Scripts for more information. | ||||
| IP address |
| ||||
| Device special file | Specify each shared disk partition used in a service. | ||||
| File system and sharing options |
|
Table 4-1. Service Property and Resource Information
The cluster infrastructure starts and stops specified applications by running service-specific scripts. For both NFS and Samba services, the associated scripts are built into the cluster services infrastructure. Consequently, when running the Cluster Configuration Tool to configure NFS and Samba services, leave the User Script field blank. For other application types it is necessary to designate a service script. For example, when configuring a database application, specify the fully-qualified pathname of the corresponding database start script.
The format of the service scripts conforms to the conventions followed by the System V init scripts. This convention dictates that the scripts have a start, stop, and status clause. These scripts should return an exit status of 0 upon successful completion.
When a service fails to start on one cluster member, Red Hat Cluster Manager will attempt to start the service on other cluster members. If the other cluster members fail to start the service, Red Hat Cluster Manager attempts to stop the service on all members. If it fails to stop the service for any reason, the cluster infrastructure will place the service in the Failed state. Administrators must then start the Cluster Status Tool, highlight the failed service, and click Disable before they can enable the service.
In addition to performing the stop and start functions, the script is also used for monitoring the status of an application service. This is performed by calling the status clause of the service script. To enable service monitoring, specify a nonzero value in the Check Interval field when specifying service properties with the Cluster Configuration Tool. If a nonzero exit is returned by a status check request to the service script, then the cluster infrastructure first attempts to restart the application on the member it was previously running on. Status functions do not have to be fully implemented in service scripts. If no real monitoring is performed by the script, then a stub status clause should be present which returns success.
The operations performed within the status clause of an application can be tailored to best meet the application's needs as well as site-specific parameters. For example, a simple status check for a database would consist of verifying that the database process is still running. A more comprehensive check would consist of a database table query.
The /usr/share/cluster/doc/services/examples/ directory contains a template that can be used to create service scripts, in addition to examples of scripts. Refer to Section 5.1 Setting Up an Oracle Service, Section 5.3 Setting Up a MySQL Service, Chapter 7 Setting Up Apache HTTP Server, for sample scripts.
Prior to creating a service, set up the shared file systems and raw devices that the service is to use. Refer to Section 2.4.4 Configuring Shared Disk Storage for more information.
If employing raw devices in a cluster service, it is possible to use the /etc/sysconfig/rawdevices file to bind the devices at boot time. Edit the file and specify the raw character devices and block devices that are to be bound each time the member boots. Refer to Section 3.5 Editing the rawdevices File for more information.
Note that software RAID and host-based RAID cannot be used for shared disk storage. Only certified SCSI adapter-based RAID cards can be used for shared disk storage.
You should adhere to the following service disk storage recommendations:
For optimal performance, use a 4 KB block size when creating file systems. Note that some of the mkfs file system build utilities default to a 1 KB block size, which can cause long fsck times.
To facilitate quicker failover times, it is recommended that the ext3 file system be used. Refer to Section 2.4.4.6 Creating File Systems for more information.
For large file systems, use the nocheck option to bypass code that checks all the block groups on the partition. Specifying the nocheck option can significantly decrease the time required to mount a large file system.
Prior to setting up a service, install any applications that are used in the service on each member in the cluster (or each member in the failover domain, if used). After installing the application on these members, verify that the application runs and can access shared disk storage. To prevent data corruption, do not run the application simultaneously on more than one member.
If using a script to start and stop the service application, install and test the script on all cluster members, and verify that it can be used to start and stop the application. Refer to Section 4.1.2 Creating Service Scripts for more information.