LifeKeeper Alarming and Recovery

LifeKeeper error detection and notification is based on the event alarming mechanism, sendevent. The key concept of the sendevent mechanism is that independent applications can register to receive alarms for critical components. Neither the alarm initiation component nor the receiving application(s) need to be modified to know the existence of the other applications. Application-specific errors can trigger LifeKeeper recovery mechanisms via the sendevent facility.

This section discusses topics related to alarming including alarm classes, alarm processing and alarm directory layout and then provides a processing scenario that demonstrates the alarming concepts.

Alarm Classes

The /opt/LifeKeeper/events directory lists a set of alarm classes. These classes correspond to particular sub-components of the system that produces events (for example, filesys). For each alarm class, subdirectories contain the set of potential alarms (for example, badmount and diskfull). You can register an application to receive these alarms by placing shell scripts or programs in the appropriate directories.

LifeKeeper uses a basic alarming notification facility. With this alarming functionality, all applications registered for an event have their handling programs executed asynchronously by sendevent when the appropriate alarm occurs. With LifeKeeper present, the sendevent process first determines if the LifeKeeper resource objects can handle the class and event. If LifeKeeper finds a class/event match, it executes the appropriate recover scenario.

Defining additional scripts for the sendevent alarming functionality is optional. When you define LifeKeeper resources, LifeKeeper provides the basic alarming functionality described in the processing scenarios later in this chapter.

*Note: Local recovery for a resource instance is the attempt by an application under control of LifeKeeper to return interrupted resource services to the end-user on the same system that generated the event. Inter-server recovery allows an application to migrate to a backup system. This type of recovery is tried after local recovery fails or is not possible.

Alarm Processing

Applications or processes that detect an event which may require LifeKeeper attention can report the event by executing the sendevent program, passing the following arguments: respective error class, error name and failing instance. Refer to the sendevent(5) manual pages for required specifics and optional parameters and syntax.

Alarm Directory Layout

The /opt/LifeKeeper/events directory has two types of content:

• LifeKeeper supplied classes. LifeKeeper provides two alarm classes listed under the events directory: lifekeeper and filesys. An example of an alarm event includes diskfull. The alarm classes correspond to the strings that are passed with the -C option to the sendevent command and the alarm events correspond to the strings that are passed with the -E option. The lifekeeper alarm class is used internally by LifeKeeper for event reporting within the LifeKeeper subsystem.

• Application-specific classes. The other subdirectories in the events directory are added when specific applications require alarm class definitions. Applications register to receive these alarms by placing shell scripts or binary programs in the directories. These programs are named after the application package to which they belong.