Chapter 4. Service Administration

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.

4.1. Configuring a Service

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:

  1. 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.

  2. Gather information about service resources and properties. Refer to Section 4.1.1 Gathering Service Information for information.

  3. Set up the file systems or raw devices that the service uses. Refer to Section 4.1.3 Configuring Service Disk Storage for information.

  4. 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.

  5. 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.

  6. Start the Cluster Configuration Tool and add services, specifying the information about the service resources and properties obtained in step 2.

  7. 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:

4.1.1. Gathering Service Information

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.

Service nameEach 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

Identify the members on which to run the service by associating the service with an existing failover domain.
When ordered failover is enabled, if the member on which the service is running fails, the service is automatically relocated to the next member on the ordered member list. (Order of preference is established by the sequence of member names in the failover domain list). Refer to Section 3.9 Configuring a Failover Domain for more information.

Check intervalSpecifies 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 scriptIf 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

One or more Internet protocol (IP) addresses may be assigned to a service. This IP address (sometimes called a "floating" IP address) is different from the IP address associated with the host name Ethernet interface for a member, because it is automatically relocated along with the service resources when failover occurs. If clients use this IP address to access the service, they do not know which member is running the service, and failover is transparent to the clients.
Note that cluster members must have network interface cards configured in the IP subnet of each IP address used in a service.
Netmask and broadcast addresses for each IP address can also be specified; if they are not, then the cluster uses the netmask and broadcast addresses from the network interconnect in the subnet.

Device special fileSpecify each shared disk partition used in a service.
File system and sharing options

If the service uses a file system, specify the type of file system, the mount point, and any mount options. You can specify any of the standard file system mount options as described in the mount(8) man page. It is not necessary to provide mount information for raw devices (if used in a service). ext2 and ext3 file systems are supported for a cluster.
Specify whether to enable forced unmount for a file system. Forced unmount allows the cluster service management infrastructure to unmount a file system prior to relocation or failover, even if the file system is busy. This is accomplished by terminating any applications that are accessing the file system.
You can also specify whether to export the file system via NFS set access permissions. Refer to Section 6.1 Setting Up an NFS Service for details.
Specify whether or not to make the file system accessible to SMB clients via Samba by providing a Samba share name.

Table 4-1. Service Property and Resource Information

4.1.2. Creating Service Scripts

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.

4.1.3. Configuring Service Disk Storage

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 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.

4.1.4. Verifying Application Software and Service Scripts

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.