Monitoring a Resource

The RGM provides for automatically starting monitors for resources. Typically, you implement monitors to run periodic fault probes on resources to detect whether the probed resources are functioning correctly. If a fault probe fails, the monitor can attempt to restart locally or request failover of the affected resource group by invoking the scha_control API function.

You can also monitor the performance of a resource and tune or report performance. Writing a resource type-specific fault monitor is completely optional. Even if you choose not to write such a fault monitor, the resource type benefits from the basic monitoring of the cluster that Sun Cluster itself does. Sun Cluster detects failures of the host hardware, gross failures of the host's operating system, and failures of a host to be able to communicate on its public networks.

When bringing a resource offline, the RGM invokes the MONITOR_STOP method to stop the resource's monitor on the local nodes before stopping the resource itself. When bringing a resource online, the RGM invokes the MONITOR_START method after the resource itself has been started.

See the Sun Cluster 3.0 Data Services Installation and Configuration Guide for information on fault monitors built into Sun supplied data services.

Resource Group Failover and Restart Control

The scha_control API function allows resource monitors to request the failover of a resource group to a different node. As one of its sanity checks, scha_control calls MONITOR_CHECK (if defined), which determines if the node on which it is run is reliable enough to master the resource group containing the resource. If MONITOR_CHECK reports back that the node is not reliable, or the method times out, the RGM looks for a different node to honor the scha_control request. If MONITOR_CHECK fails on all nodes, the failover is canceled.

Resource Properties to Support Monitors

Resource monitors, like the callback methods, need general access to resource properties. Certain system-defined resource properties are specifically for use by monitors, although the resource type implementation determines whether they are used. The monitor-related resource properties are:

• Cheap_probe_interval

• Thorough_probe_interval

• Retry_count

• Retry_interval

• Status

• Status_msg

These properties can be read with the scha_resource_get(1HA)(3HA) access command and function.

Setting Status and Status_msg

The Status and Status_msg properties are to be set by the resource monitor to reflect the monitor's view of the resource state. The API provides a function, scha_resource_setstatus, that sets these properties. See the scha_resource_setstatus(3HA) and scha_resource_setstatus(1HA) man pages for details.

---

Note -

Although scha_resource_setstatus is of particular use to a resource monitor, any program can call it.

---

Resource Group Properties to Support Monitors

Some resource group properties that a monitor might use are: Nodelist, Maximum_primaries, Desired_primaries, RG_state, Resource_list, and Global_resources_used.

Resource group properties can be read with a set of access functions. An open function (scha_resourcegroup_open(3HA)) initializes resource group access, a close function (scha_resourcegroup_close(3HA)) frees memory allocated by the access function, and operation tag values drive a variable argument function (scha_resourcegroup_get(3HA)) that returns property values in client variables that are passed as reference arguments. See Table A-3 for a list of resource group properties.

A single man page describes these three functions. You can access this man page through any of the individual functions, scha_resourcegroup_open(3HA), scha_resourcegroup_get(3HA), or scha_resourcegroup_close(3HA).

The sciptable version of this functionality is implemented with a single command, scha_resourcegroup_get(1HA).

No interface can directly change resource group properties, although control requests made using scha_control might cause the RGM to change the properties of a resource group. Resource group properties are changed by the RGM or by administrative action.

Resource Type Properties to Support Monitors

Some resource type properties, like RT_basedir and Installed_nodes, might be of use to a monitor, for example, to specify the location of the program that implements the monitor.

Resource type properties inherited by a particular resource of that type are accessible through the scha_resource_get function. An interface is also provided to access the properties of any resource type. All resource type properties are accessible.

The access interface for resource types follows the pattern of the access interface for resources and resource groups. Open and close functions provide initialization and memory management, and a variable argument function provides tag-determined access to properties.A single man page describes these three functions. You can access this man page through any of the individual functions, scha_resourcetype_open(3HA), scha_resourcetype_get(3HA), or scha_resourcetype_close(3HA). The sciptable version of this functionality is implemented with a single command, scha_resourcetype_get(1HA.