Chapter 4 Resource Management API Reference

This chapter provides a reference to the access functions and callback methods that make up the Resource Management API (RMAPI). It lists and briefly describes each function and method. However, the definitive reference for these functions and methods is the RMAPI man pages.

The information in this chapter includes:

• RMAPI Access Methods – in the form of shell script commands and C functions

  • scha_resource_get(1HA), scha_resource_close(3HA), scha_resource_get(3HA), scha_resource_open(3HA)

  • scha_resource_setstatus(1HA), scha_resource_setstatus(3HA)

  • scha_resourcetype_get(1HA), scha_resourcetype_close(3HA), scha_resourcetype_get(3HA), scha_resourcetype_open(3HA)

  • scha_resourcegroup_get(1HA), scha_resourcegroup_get(3HA), scha_resourcegroup_close(3HA), scha_resourcegroup_open(3HA)

  • scha_control(1HA), scha_control(3HA)

  • scha_cluster_get(1HA), scha_cluster_close(3HA), scha_cluster_get(3HA), scha_cluster_open(3HA)

  • scha_cluster_getlogfacility(3HA)

  • scha_cluster_getnodename(3HA)

  • scha_strerror(3HA)

• RMAPI Callback Methods – described in the rt_callbacks(1HA) man page.

  • Start

  • Stop

  • Init

  • Fini

  • Boot

  • Prenet_start

  • Postnet_stop

  • Monitor_start

  • Monitor_stop

  • Monitor_check

  • Update

  • ValidateS

RMAPI Access Methods

The API provides functions to access resource, resource type, and resource group properties, and other cluster information. These functions are provided both in the form of shell commands and C functions, enabling resource type providers to implement control programs as shell scripts or as C programs.

RMAPI Shell Commands

Shell commands are to be used in shell script implementations of the callback methods for resource types representing services controlled by the cluster's RGM. You can use these commands to:

• Access information about resources, resource types, resource groups, and clusters

• Use with a monitor to set the Status and Status_msg properties of a resource

• Request the restart or relocation of a resource group

Although this section provides brief descriptions of the shell commands, the individual man pages in the section 1HA provide the definitive reference for the shell commands. Each command has a man page of the same name unless otherwise noted.

RMAPI Resource Commands

You can access information about a resource or set the Status and Status_msg properties of a resource with these commands.

scha_resource_get

Accesses information about a resource or resource type under the control of the RGM. It provides the same information as the scha_resource_get() function.

scha_resource_setstatus

Sets the Status and Status_msg properties of a resource under the control of the RGM. It is used by the resource's monitor to indicate the resource's state as perceived by the monitor. It provides the same functionality as the scha_resource_setstatus() C function.

---

Note –

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

---

Resource Type Command

This command accesses information about a resource type registered with the RGM.

scha_resourcetype_get

This command provides the same functionality as the scha_resourcetype_get() C function.

Resource Group Commands

You can access information about or restart a resource group with these commands.

scha_resourcegroup_get

Accesses information about a resource group under the control of the RGM. This command provides the same functionality as the scha_resourcetype_get() C function.

scha_control

Requests the restart of a resource group under the control of the RGM or its relocation to a different node. This command provides the same functionality as the scha_control() C function.

Cluster Command

This command accesses information about a cluster, such as node names, IDs, and states, the cluster name, resource groups, and so on.

scha_cluster_get

This command provides the same information as the scha_cluster_get() C function.

C Functions

C functions are to be used in C program implementations of the callback methods for resource types representing services controlled by the cluster's RGM. You can use these functions to do the following:

• Access information about resources, resource types, resource groups, and clusters

• Use with a monitor to set the Status and Status_msg properties of a resource

• Request the restart or relocation of a resource group

• Convert an error code to an appropriate error message

Although this section provides brief descriptions of the C functions, the individual (3HA) man pages provide the definitive reference for the C functions. Each function has a man page of the same name unless otherwise noted. See the scha_calls(3HA) man page for information on the output arguments and return codes of the C functions.

Resource Functions

These functions access information about a resource managed by the RGM or indicate the state of the resource as perceived by the monitor.

scha_resource_open(), scha_resource_get(), and scha_resource_close()

Together these functions access information on a resource managed by the RGM. The scha_resource_open() function initializes access to a resource and returns a handle for scha_resource_get(), which accesses the resource information. The scha_resource_close() function invalidates the handle and frees memory allocated for scha_resource_get() return values.

A resource can change, through cluster reconfiguration or administrative action, after scha_resource_open() returns the resource's handle, in which case the information scha_resource_get() obtains through the handle could be inaccurate. In cases of cluster reconfiguration or administrative action on a resource, the RGM returns the scha_err_seqid error code to scha_resource_get() to indicate information about the resource might have changed. This is a non-fatal error message; the function returns successfully. You can choose to ignore the message and accept the returned information, or you can close the current handle and open a new handle to access information about the resource.

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

scha_resource_setstatus()

Sets the Status and Status_msg properties of a resource under the control of the RGM. The resource's monitor uses this function to indicate the resource's state.

---

Note –

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

---

Resource Type Functions

Together these functions access information about a resource type registered with the RGM.

scha_resourcetype_open(), scha_resourcetype_get(), scha_resourcetype_close()

The scha_resourcetype_open() function initializes access to a resource and returns a handle for scha_resourcetype_get(), which accesses the resource type information. The scha_resourcetype_close() function invalidates the handle and frees memory allocated for scha_resourcetype_get() return values.

A resource type can change, through cluster reconfiguration or administrative action, after scha_resourcetype_open() returns the resource type's handle, in which case the information scha_resourcetype_get() obtains through the handle could be inaccurate. In cases of cluster reconfiguration or administrative action on a resource type, the RGM returns the scha_err_seqid error code to scha_resourcetype_get() to indicate information about the resource type might have changed. This is a non-fatal error message; the function returns successfully. You can choose to ignore the message and accept the returned information, or you can close the current handle and open a new handle to access information about the resource type.

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

Resource Group Functions

You can access information about or restart a resource group with these functions.

scha_resourcegroup_open(3HA), scha_resourcegroup_get(3HA), and scha_resourcegroup_close(3HA)

Together these functions access information on a resource group managed by the RGM. The scha_resourcegroup_open() function initializes access to a resource group and returns a handle for scha_resourcegroup_get(), which accesses the resource group information. The scha_resourcegroup_close() function invalidates the handle and frees memory allocated for scha_resourcegroup_get() return values.

A resource group can change, through cluster reconfiguration or administrative action, after scha_resourcegroup_open() returns the resource group's handle, in which case the information scha_resourcegroup_get() obtains through the handle could be inaccurate. In cases of cluster reconfiguration or administrative action on a resource group, the RGM returns the scha_err_seqid error code to scha_resourcegroup_get() to indicate information about the resource group might have changed. This is a non-fatal error message; the function returns successfully. You can choose to ignore the message and accept the returned information, or you can close the current handle and open a new handle to access information about the resource group.

scha_control(3HA)

Requests the restart of a resource group under the control of the RGM or its relocation to a different node.

Cluster Functions

These functions access or return information about a cluster.

scha_cluster_open(3HA), scha_cluster_get(3HA), scha_cluster_close(3HA)

Together these functions access information about a cluster, such as node names, IDs, and states, cluster name, resource groups, and so on.

A cluster can change—through reconfiguration or administrative action—after scha_cluster_open() returns the cluster's handle, in which case the information scha_cluster_get() obtains through the handle could be inaccurate. In cases of reconfiguration or administrative action on a cluster, the RGM returns the scha_err_seqid error code to scha_cluster_get() to indicate information about the cluster might have changed. This is a non-fatal error message; the function returns successfully. You can choose to ignore the message and accept the returned information, or you can close the current handle and open a new handle to access information about the cluster.

scha_cluster_getlogfacility(3HA)

Returns the number of the system log facility being used as the cluster log. Uses the returned value with the Solaris syslog() function to record events and status messages to the cluster log.

scha_cluster_getnodename(3HA)

Returns the name of the cluster node on which the function is called.

Utility Function

This function converts an error code to an error message.

scha_strerror(3HA)

Translates an error code—returned by one of the scha_ functions—to the appropriate error message. Use this function with logger to log messages to the system log (syslog).

RMAPI Callback Methods

Callback methods are the key elements provided by the API for implementing a resource type. Callback methods enable the RGM to control resources in the cluster in the event of a change in cluster membership, such as a node boot or crash.

The callback methods are executed by the RGM with root permissions because the client programs control HA services on the cluster system. Install and administer these methods with restrictive file ownership and permissions. Specifically, give them a privileged owner, such as bin or root, and do not make them writable.

This section describes callback method arguments and exit codes and lists and describes callback methods in the following categories:

• Control and initialization methods

• Administrative support methods

• Net-relative methods

• Monitor control methods

Although this section provides brief descriptions of the callback methods, including the point at which the method is invoked and the expected effect on the resource, the rt_callbacks(1HA) man page is the definitive reference for the callback methods.

Method Arguments

The RGM invokes callback methods as follows:

method -R resource-name -T type-name -G group-name

The method is the path name of the program that is registered as the Start, Stop, or other callback. The callback methods of a resource type are declared in its registration file.

All callback method arguments are passed as flagged values, with -R indicating the name of the resource instance, -T indicating the type of the resource, and -G indicating the group into which the resource is configured. Use the arguments with access functions to retrieve information about the resource.

The Validate method is called with additional arguments (the property values of the resource and resource group on which it is called).

See scha_calls(3HA) for more information.

Exit Codes

All callback methods have the same exit codes defined to specify the effect of the method invocation on the resource state. The scha_calls(3HA) man page describes all these exit codes. The exit codes are:

• 0 – Method succeeded

• Any nonzero value – Method failed

The RGM also handles abnormal failures of callback method execution, such as time outs and core dumps.

Method implementations must output failure information using syslog on each node. Output written to stdout or stderr is not guaranteed to be delivered to the user (though it currently is displayed on the console of the local node).

Control and Initialization Callback Methods

The primary control and initialization callback methods start and stop a resource. Other methods execute initialization and termination code on a resource.

Start

This required method is invoked on a cluster node when the resource group containing the resource is brought online on that node. This method activates the resource on that node.

A Start method should not exit until the resource it activates has been started and is available on the local node. Therefore, before exiting, the Start method should poll the resource to determine that it has started. In addition, you should set a sufficiently long time-out value for this method. For example, certain resources, such as database daemons, take more time to start, and thus require that the method have a longer timeout value.

The way in which the RGM responds to failure of the Start method depends on the setting of the Failover_mode property.

The START_TIMEOUT property in the resource type registration file sets the time-out value for a resource's Start method.

Stop

This required method is invoked on a cluster node when the resource group containing the resource is brought offline on that node. This method deactivates the resource if it is active.

A Stop method should not exit until the resource it controls has completely stopped all its activity on the local node and has closed all file descriptors. Otherwise, because the RGM assumes the resource has stopped, when in fact it is still active, data corruption can result. The safest way to avoid data corruption is to terminate all processes on the local node related to the resource.

Before exiting, the Stop method should poll the resource to determine that it has stopped. In addition, you should set a sufficiently long time-out value for this method. For example, certain resources, such as database daemons, take more time to stop, and thus require that the method have a longer time-out value.

The way in which the RGM responds to failure of the Stop method depends on the setting of the Failover_mode property (see Table A–2).

The STOP_TIMEOUT property in the resource type registration file sets the time-out value for a resource's Stop method.

Init

This optional method is invoked to perform a one-time initialization of the resource when the resource becomes managed—either when the resource group it is in is switched from an unmanaged to a managed state, or when the resource is created in a resource group that is already managed. The method is called on nodes determined by the Init_nodes resource property.

Fini

This optional method is invoked to clean up after the resource when the resource becomes unmanaged—either when the resource group it is in is switched to an unmanaged state or when the resource is deleted from a managed resource group. The method is called on nodes determined by the Init_nodes resource property.

Boot

This optional method, similar to Init, is invoked to initialize the resource on nodes that join the cluster after the resource group containing the resource has already been put under the management of the RGM. The method is invoked on nodes determined by the Init_nodes resource property. The Boot method is called when the node joins or rejoins the cluster as the result of being booted or rebooted.

Failure of the Init, Fini, or Boot methods causes the syslog() function to generate an error message but does not otherwise affect RGM management of the resource.

Administrative Support Methods

Administrative actions on resources include setting and changing resource properties. The Validate and Update callback methods enable a resource type implementation to hook into these administrative actions.

Validate

This optional method is called when a resource is created and when administrative action updates the properties of the resource or its containing resource group. This method is called on the set of cluster nodes indicated by the Init_nodes property of the resource's type. Validate is called before the creation or update is applied, and a failure exit code from the method on any node causes the creation or update to be canceled.

Validate is called only when resource or resource group properties are changed through administrative action, not when the RGM sets properties, or when a monitor sets the resource properties Status and Status_msg.

Update

This optional method is called to notify a running resource that properties have been changed. Update is invoked after an administration action succeeds in setting properties of a resource or its group. This method is called on nodes where the resource is online. The method uses the API access functions to read property values that might affect an active resource and adjust the running resource accordingly.

Failure of the Update method causes the syslog() function to generate an error message but does not otherwise affect RGM management of the resource.

Net-Relative Callback Methods

Services that use network address resources might require that start or stop steps be done in a certain order relative to the network address configuration. The following optional callback methods, Prenet_start and Postnet_stop, enable a resource type implementation to do special startup and shutdown actions before and after a related network address is configured or unconfigured.

Prenet_start

This optional method is called to do special startup actions before network addresses in the same resource group are configured.

Postnet_stop

This optional method is called to do special shutdown actions after network addresses in the same resource group are configured down.

Monitor Control Callback Methods

A resource type implementation optionally can include a program to monitor the performance of a resource, report on its status, or take action on resource failure. The Monitor_start, Monitor_stop, and Monitor_check methods support the implementation of a resource monitor in a resource type implementation.

Monitor_start

This optional method is called to start a monitor for the resource after the resource is started.

Monitor_stop

This optional method is called to stop a resource's monitor before the resource is stopped.

Monitor_check

This optional method is called to assess the reliability of a node before a resource group is relocated to the node. The Monitor_check method must be implemented so that it does not conflict with the concurrent running of another method.