Chapter 1 Resource Management API Overview

This book provides guidelines for creating a highly available (HA) data service for a software application such as Oracle, iPlanet^TM Web Server, DNS, and so on, using the Resource Management API (RMAPI). As such, this book is targeted at data service developers. This book uses the second person pronoun, "you", throughout to address data service developers .

This chapter provides an overview of the concepts you need to understand in order to use the API.

The following information is in this chapter.

• "What Is Sun Cluster?"

• "Resource Management Object Model"

• " Resource Group Manager"

• "Resource Group Manager Administrative Interface"

• "Callback Methods"

• "Access Methods"

What Is Sun Cluster?

The Sun Cluster 3.0 system enables applications to be run and administered as highly available and scalable resources (data services). The cluster facility known as the Resource Group Manager, or RGM, provides the mechanism for high availability. The elements that form the programming interface to this facility include the following.

• A set of callback methods the RGM uses to control an application on the cluster

• API commands and functions that callback methods can use to access information about the elements in the cluster

• Process management facilities for monitoring and restarting processes on the cluster

The RGM runs as a daemon on each cluster node and automatically starts and stops resources on selected nodes according to pre-configured policies. The RGM makes a resource highly available in the event of a node failure or reboot by stopping the resource on the affected node and starting it on another. The RGM also automatically starts and stops resource-specific monitors that can detect resource failures and relocate failing resources onto another node or can monitor other aspects of resource performance.

The RGM supports both failover resources, which can be online on at most one node at a time, and scalable resources, which can be online on multiple nodes simultaneously.

Resource Management Object Model

This section and its subsections introduce some fundamental terminology and explain how the different elements of the API are put together to create a highly available application.

The RGM and its associated API handle three major kinds of interrelated objects: resource types, resources, and resource groups. One way to introduce these objects is by means of an example, such as the following.

A developer could implement a resource type, ha-oracle, which makes an existing Oracle DBMS application highly available. An end user might define separate databases for marketing, engineering, and finance, each of which would be a resource of type ha-oracle. The cluster administrator could place these resources in separate resource groups so they could run on different nodes and fail over independently. Likewise, a developer could create a second resource type, ha-calendar, to implement a highly available calendar server that requires an Oracle database. The cluster administrator could place the resource for the finance calendar into the same resource group as the finance database resource so that both resources would run on the same node and fail over together.

Resource Types

A resource type consists of a software application to be run on the cluster, control programs used as callback methods by the RGM to manage the application as a cluster resource, and a set of properties that form part of the static configuration of a cluster. The RGM uses resource type properties to manage resources of a particular type.

In addition to a software application, a resource type can represent other system resources such as network addresses.

The resource type developer specifies the properties for the resource type and sets their values in a resource type registration (RTR) file. The resource type registration file follows a well-defined format described in "Setting Resource and Resource Type Properties" and in the rt_reg(4) man page. See also "Defining the Resource Type Registration File" for a description of a sample resource type registration file.

Table A-1 provides a list of the resource type properties.

The cluster administrator installs the resource type implementation and underlying application on a cluster and registers it using administrative commands. The registration procedure enters into the cluster configuration the information from the resource type registration file. The Sun Cluster 3.0 Data Services Installation and Configuration Guide describes the procedure for registering a data service.

Resources

A resource inherits the properties and values of its resource type. In addition, a developer can declare resource properties in the resource type registration file. See Table A-2 for a list of resource properties.

The cluster administrator can change the values of certain properties depending on how they were specified in the resource type registration (RTR) file. For example, property definitions can specify a range of allowable values and specify when the property is tunable, for example, at creation, anytime, or never. Within these specifications, the cluster administrator can make changes to properties using administration commands.

The cluster administrator can create many resources of the same type, each resource having its own name and set of property values, so that more than one instance of the underlying application can run on the cluster. Each instantiation requires a unique name within the cluster.

Resource Groups

Each resource must be configured in a resource group. The RGM brings all resources in a group online and offline together on the same node. When the RGM brings a resource group online or offline, it invokes callback methods on the individual resources in the group.

The nodes on which a resource group is currently online are called its primaries or primary nodes. A resource group is mastered by each of its primaries. Each resource group has an associated Nodelist property, set by the cluster administrator, which identifies all potential primaries or masters of the resource group.

A resource group also has a set of properties. These properties include configuration properties that can be set by the cluster administrator and dynamic properties, set by the RGM, that reflect the active state of the resource group.

The RGM defines two types of resource groups, failover and scalable. A failover resource group can be online on one node only at any time while a scalable resource group can be online on multiple nodes simultaneously. The RGM provides a set of properties to support the creation of each type of resource group. See "Implementing a Failover Resource" and "Implementing a Scalable Resource" for details on these properties.

See Table A-3 for a list of resource group properties.

Resource Group Manager

The Resource Group Manager (RGM) is implemented as a daemon, rgmd, that runs on each member node of the cluster. All of the rgmd processes communicate with each other and act together as a single cluster-wide facility.

The RGM supports the following functions:

• Whenever a node boots or crashes, the RGM attempts to maintain availability of all managed resource groups by automatically bringing them online on appropriate masters.

• If a particular resource fails, its monitor program can request that the resource group be restarted on the same master or switched to a new master.

• The cluster administrator can issue an administrative command to request one of the following actions:

  • Change mastery of a resource group

  • Enable or disable a particular resource within a resource group

  • Create, delete, or modify a resource, a resource group, or a resource type

Whenever the RGM activates configuration changes, it coordinates its actions across all member nodes of the cluster. This kind of activity is known as a reconfiguration. To effect a state change on an individual resource, the RGM invokes a resource-type specific callback method on that resource. Callback methods are described in "Callback Methods".

Resource Group Manager Administrative Interface

The Sun Cluster 3.0 commands for administering RGM objects are scrgadm(1M), scswitch(1M), and scstat(1M)-g.

The scrgadm(1M) command allows viewing, creating, configuring and deleting the resource type, resource group, and resource objects used by the RGM. The command is part of the administrative interface for the cluster, and is not to be used in the same programming context as the application interface described in the rest of this chapter. However, scrgadm(1M) is the tool for constructing the cluster configuration in which the API operates. Understanding the administrative interface sets the context for understanding the application interface. Refer to the scrgadm(1M) man page for details on the administrative tasks that can be performed by the command.

The scswitch(1M) command switches resource groups online and offline on specified nodes and enables or disables a resource or its monitor. See the scswitch(1M) man page for details on the administrative tasks that the command can perform.

The scstat(1M)-g command shows the current dynamic state of all resource groups and resources.

Callback Methods

You use the Resource Management API (RMAPI) to implement a resource type. The key elements of a resource type are the callback methods, programs invoked by the RGM to control resources on the cluster. The API defines the arguments and return value of the callback methods.

The only required callback methods for a resource type are a start method, START or PRENET_START, and a stop method, STOP or POSTNET_STOP.

The RMAPI provides callback methods in the following categories:

• Control and initialization methods

  • START and STOP start and stop resources in a group that is being brought online or offline.

  • INIT, FINI, BOOT execute initialization and termination code on resources.

• Administrative support methods

  • VALIDATE verifies properties set by administrative action.

  • UPDATE updates the property settings of an online resource.

• Net-relative methods

  • PRENET_START and POSTNET_STOP do special startup or shutdown actions before network addresses in the same resource group are configured up or after they are configured down.

• Monitor control methods

  • MONITOR_START and MONITOR_STOP start or stop the monitor for a resource.

  • MONITOR_CHECK assesses the reliability of a node before a resource group is moved to the node.

See Chapter 4, Resource Management API Reference and the rt_callbacks(1HA) man page for more information on the callback methods. Also see Chapter 5, Sample Application for examples of how the callback methods are used.

Access Methods

To support implementation of callback methods, the API provides an interface to the RGM in the form of methods to access resource properties and other cluster information. The access methods are provided both in the form of shell commands and in the form of C functions.

The API provides commands and functions to do the following:

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

• Set the Status and Status_msg properties of a resource

• Request the restart or relocation of a resource group

See Chapter 4, Resource Management API Reference for more information on the access methods. Also see Chapter 5, Sample Application for examples of how the access methods are used.