Configuring a Service

After setting up disk storage and installing applications to be managed by the cluster, you can config- ure services to manage these applications and resources by using theCluster 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.2Creating Service Scriptsfor information.

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

3. Set up the file systems or raw devices that the service uses. Refer to Section 4.1.3Configuring Service Disk Storagefor 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.4Verifying Application Software and Service Scripts for upgrade instructions.

5. If upgrading from an existing cluster, back up the/etc/cluster.conffile. Refer to Section 3.2Installation Notes for Red Hat Enterprise Linux 2.1 Usersfor upgrade instructions. 6. Start theCluster Configuration Tooland 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: • Section 5.1Setting Up an Oracle Service

• Section 5.3Setting Up a MySQL Service • Section 6.1Setting Up an NFS Service • Section 6.6Setting Up a Samba Service • Chapter 7Setting Up Apache HTTP Server

4.1.1. Gathering Service Information

Before configuring a service, gather all available information about the service resources and proper- ties. 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 theCluster Configuration Toolare described in Table 4-1.

60 Chapter 4. Service Administration

Property Description Service

name Each service must have a unique name. A service name can consist of one to 63characters and must consist of a combination of letters (either uppercase or lowercase), integers, underscores, periods, and dashes (hyphens). A service name mustbegin with a letter or an underscore.

Failover

domain Identify the members on which to run the service by associating the service with anexisting 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.9Configuring a Failover Domainfor more information.

Check

interval Specifies the frequency (in seconds) that the member checks the health of theapplication 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 thestatusclause 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.2Creating Service Scriptsfor 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 file Specify 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.1Setting Up an NFS Servicefor details.

Specify whether or not to make the file system accessible to SMB clients via Samba by providing a Samba share name.

Chapter 4. Service Administration 61

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 infras- tructure. Consequently, when running theCluster Configuration Toolto configure NFS and Samba services, leave theUser Scriptfield 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 Vinitscripts. This convention dictates that the scripts have astart,stop, andstatusclause. These scripts should return an exit status of0upon 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 theFailedstate. Administrators must then start theCluster Status Tool, highlight the failed service, and clickDisablebefore 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 thestatusclause of the service script. To enable service monitoring, specify a nonzero value in theCheck Intervalfield when specifying service properties with theCluster 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 stubstatusclause should be present which returns success.

The operations performed within the status clause of an application can be tailored to best meet the ap- plication’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.1Setting Up an Oracle Service, Section 5.3Setting Up a MySQL Service, Chapter 7Setting 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.4Configuring Shared Disk Storagefor 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 de- vices that are to be bound each time the member boots. Refer to Section 3.5Editing therawdevices Filefor 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 followingservice disk storage recommendations:

• For optimal performance, use a 4 KB block size when creating file systems. Note that some of the mkfsfile system build utilities default to a 1 KB block size, which can cause longfscktimes. • To facilitate quicker failover times, it is recommended that the ext3 file system be used. Refer to

62 Chapter 4. Service Administration

• For large file systems, use thenocheckoption to bypass code that checks all the block groups on the partition. Specifying thenocheckoption 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 mem- bers, and verify that it can be used to start and stop the application. Refer to Section 4.1.2Creating Service Scriptsfor more information.