test

Sun Cluster 3.0 Data Services Developers' Guide

Chapter 2 Using the Resource Management API

This chapter provides detailed information about using the Resource Management API to implement a resource type.

The following information is in this chapter.

Setting Resource and Resource Type Properties

Sun Cluster provides resource type properties that you can use to define the static configuration of a data service. Resource type properties can specify the type of the resource, its version, the version of the API, and so on, as well as specify paths to each of the callback methods. Table A-1 lists all the resource type properties.

You declare the resource type properties in the resource type registration (RTR) file. The RTR file defines the initial configuration of the data service at the time the cluster administrator registers the data service with Sun Cluster. With the exception of Installed_nodes, the cluster administrator cannot configure resource type properties.

Note -

Table A-1, which describes the resource type properties, specifies whether each property is optional, required, or conditional. You do not have to declare optional properties in the RTR file because the system supplies a default value if you omit them. This table also lists the default value for each optional property. If you do not declare a required property in the RTR file, registration of the data service fails.If you do not declare a conditional property in the RTR file, the RGM does not create the property and it is not available to the cluster administrator.

The following example shows resource type property entries in an RTR file.


# Registration information for example resource type
Resource_type = example_RT; 
Vendor_id = SUNW;
Pkglist = SUNWxxx;
RT_Basedir = /opt/SUNWxxx;
START			=	bin/service_start;
STOP			=	bin/service_stop;
Tip -

You must declare the Resource_type property as the first entry in the RTR file. Otherwise, registration of the resource type will fail.

Sun Cluster also provides resource properties, such as Failover_mode, Thorough_probe_interval, and method timeouts, that define the static configuration of the resource. Dynamic resource properties such as Resource_state and Status reflect the active state of a managed resource. In addition to the resource properties, a resource inherits the properties of its resource type. Table A-2 describes the resource properties.

As with resource type properties, you declare resource properties in the RTR file. For resource properties provided by Sun Cluster, so-called system-defined properties, you can change specific attributes in the RTR file. For example, Sun Cluster provides method timeout properties for each of the callback methods, and specifies default values. In the RTR file, you can specify different default values.

You can also define new resource properties in the RTR file--so-called extension properties--using a set of property attributes provided by Sun Cluster. Table A-4 lists the attributes for changing and defining resource properties.

By convention, resource property declarations follow the resource type declarations in the RTR file. Entries begin with an open curly bracket and end with a closed curly bracket. The following example shows resource declarations in a sample RTR file.

...

 

# Resource property declarations appear as a list of bracketed 

# entries after the resource-type declarations. The property  

# name declaration must be the first attribute after the open 

# curly bracket of a resource property entry. 

# 

# Set minimum and default for method timeouts. 

{ 

Property = Start_timeout;  

MIN=60;  

DEFAULT=300; 

} 

{ 

Property = Stop_timeout;  

MIN=60;  

DEFAULT=300; 

} 

# An extension property that can be set at resource creation 

 

{  

Property = Log_level; 

Extension; 

enum {OFF, TERSE, VERBOSE}; 

DEFAULT = TERSE; 

TUNABLE = AT_CREATION; 

DESCRIPTION = "Controls the detail of message logging"; 

} 

Start_timeout and Stop_timeout are system-defined resource properties. Sun Cluster provides a minimum value (1 second) and a default value (3600 seconds) for all timeouts. This sample RTR file changes these values to 60 seconds minimum and 300 seconds default. The cluster administrator can accept the default value or change the value of the timeout to 60 seconds or greater.

Note -

You must declare conditional system-defined resource properties in the resource type registration file for them to be available for resources of that type. That is, properties that are not declared cannot be set or queried.

The final point about resource properties is that the cluster administrator can configure them under certain conditions. The following table shows the TUNABLE attribute that determines when and if an administrator can configure a resource property.

NONE or FALSE

Never 

TRUE or ANYTIME

Anytime 

AT_CREATION

When the data service is added to a cluster 

WHEN_DISABLED

When the data service is disabled 

You can use other attributes to put limits on the configurability of a property. For example, the Min and Max attributes allow you to set ranges for integer properties. See Table A-4 for a complete list of resource property attributes.

Using Callback Methods

This section provides some information that pertains to using the callback methods in general.

Accessing Resource and Resource Group Property Information

The callback methods that enable the RGM to control activation of cluster resources might require access to the properties of that resource. The API provides both shell commands and C functions that you can use in callback methods to access the system-defined and extension properties of resources.

You cannot use the property mechanism to store dynamic state information for a data service because no API functions are available for setting resource properties (other than the function for setting Status and Status_msg). Rather, you should store dynamic state information in global files.

Note -

The cluster administrator can set certain resource properties using the scrgadm(1M) command or through an available graphical administrative interface.

The C function for resource property access has a variable argument interface. The API defines string-valued tags that indicate an operation and determine the interpretation of the variable argument list. The "get" access function works in conjunction with "open" and "close" functions that do initialization, finalization, and memory management.

You use three functions together for resource property access:

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

A command version of scha_resource_get is provided for use in shell scripts. The command takes as flagged arguments an operation tag, the resource name, and its group name. Additional unflagged arguments might be available for some operation tags. The scha_resource_get(1HA) man page provides details on this access command.

Idempotency for Methods

In general, the RGM does not call a method more than once in succession on the same resource with the same arguments. However, if a START method fails, the RGM could call a STOP method on a resource even though the resource was never started. Likewise, a resource daemon could die of its own accord and the RGM might still invoke its STOP method on it. The same scenarios apply to the MONITOR_START and MONITOR_STOP methods.

For these reasons, you must build idempotency into your STOP and MONITOR_STOP methods, which means that repeated calls of STOP or MONITOR_STOP on the same resource with the same parameters achieve the same results as a single call.

One implication of idempotency is that STOP and MONITOR_STOP should return 0 (success) even if the resource or monitor is already stopped and no work is to done.

Note -

The INIT, FINI, BOOT, and UPDATE methods must also be idempotent. A START method need not be idempotent.

Controlling an Application

Callback methods enable the RGM to take control of the underlying resource (application) whenever nodes are in the process of joining or leaving the cluster.

Starting and Stopping a Resource

A resource type implementation requires, at a minimum, a START method and a STOP method. The RGM calls a resource type's method functions or programs at appropriate times and on the appropriate nodes for bringing resource groups offline and online. For example, after the crash of a cluster node, the RGM moves any resource groups mastered by that node onto a new node. You must implement a START method to provide the RGM with a way of restarting each resource on the surviving host node.

A START method must not return until the resource has been started and is available on the local node. Be certain that resource types requiring a long initialization period have sufficiently long timeouts set on their START methods (set default and minimum values for the Start_timeout property in the resource type registration file).

You must implement a STOP method for situations in which the RGM takes a resource group offline. For example, suppose a resource group is taken offline on Node1 and back online on Node2. While taking the resource group offline, the RGM calls the STOP method on resources in the group to stop all activity on Node1. After the STOP methods for all resources have completed on Node1, the RGM brings the resource group back online on Node2.

A STOP method must not return until the resource has completely stopped all its activity on the local node and has completely shut down. The safest implementation of a STOP method would terminate all processes on the local node related to the resource. Resource types requiring a long time to shut down should have sufficiently long timeouts set on their STOP methods. Set the Stop_timeout property in the resource type registration file.

Failure or timeout of a STOP method causes the resource group to enter an error state that requires operator intervention. To avoid this state, the STOP and MONITOR_STOP method implementations should attempt to recover from all possible error conditions. Ideally, these methods should exit with 0 (success) error status, having successfully stopped all activity of the resource and its monitor on the local node.

Initializing and Terminating a Resource

Three optional methods, INIT, FINI, and BOOT, allow the RGM to execute initialization and termination code on a resource. The RGM invokes the INIT method 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 it is created in a resource group that is already managed.

The RGM invokes the FINI method 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 it is deleted from a managed resource group. The clean up must be idempotent, that is, if the clean up has already been done, FINI exits 0 (success).

The RGM invokes the BOOT method on nodes that have newly joined the cluster, that is, have been booted or rebooted.

The BOOT method normally performs the same initialization as INIT. This initialization must be idempotent, that is, if the resource has already been initialized on the local node, BOOT and INIT exit 0 (success).

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:

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.

Adding Message Logging to a Resource

If you want to record status messages in the same log file as other cluster messages, use the convenience function scha_cluster_getlogfacility to retrieve the facility number being used to log cluster messages.

Use this facility number with the regular Solaris syslog function to write messages to the cluster log. You can also access the cluster log facility information through the generic scha_cluster_get(1HA)(3HA) interface.

Providing Process Management

Process management facilities are provided with the Resource Management API to implement resource monitors and resource control callbacks. See the man pages for details on each of these commands and programs.

Providing Administrative Support for a Resource

Administrative actions on resources include setting and changing resource properties. The API defines the VALIDATE and UPDATE callback methods so you can hook into these administrative actions.

The RGM calls the optional VALIDATE method when a resource is created and when administrative action updates the properties of the resource or its containing group. The RGM passes the property values for the resource and its resource group to the VALIDATE method. The RGM calls VALIDATE on the set of cluster nodes indicated by the Init_nodes property of the resource's type. The RGM calls VALIDATE 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.

The RGM calls VALIDATE only when resource or 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.

The RGM calls the optional UPDATE method to notify a running resource that properties have been changed. The RGM invokes UPDATE after an administrative action succeeds in setting properties of a resource or its group. The RGM calls this method on nodes where the resource is online. This method can use the API access functions to read property values that might affect an active resource and adjust the running resource accordingly.

Implementing a Failover Resource

A failover resource group contains network addresses such as the built in resource types logical hostname and shared address, and failover resources such as the data service application resources for a failover data service. The network address resources, along with their dependent data service resources move between cluster nodes when data services fail over or are switched over. The RGM provides a number of properties that support implementation of a failover resource.

The boolean resource type property, Failover, if set to TRUE, restricts the resource from being configured in a resource group that can be online on more than one node at a time. This property defaults to FALSE, so you must declare it as TRUE in the RTR file for a failover resource.

The RG_mode resource group property allows the cluster administrator to identify a resource group as failover or scalable. If RG_mode is FAILOVER, the RGM sets the Maximum_primaries property of the group to 1 and restricts the resource group to being mastered by a single node. The RGM does not allow a resource whose Failover property is TRUE to be instantiated in a resource group whose RG_mode is SCALABLE.

The Implicit_network_dependencies resource group property specifies that the RGM should enforce implicit strong dependencies of non-network-address resources on all network-address resources within the group. This means that the non-network address (data service) resources in the group will not have their START methods called until the network addresses in the group are configured up. Network-address resources include the logical hostname and shared address resource types. This property defaults to TRUE.

Implementing a Scalable Resource

A scalable resource is a resource that can be online on more than one node simultaneously. Scalable resources include data services such as Sun Cluster HA for iPlanet Web Server and HA-Apache.

The RGM provides a number of properties that support implementation of a scalable resource.

The boolean resource property Scalable identifies a resource as scalable (TRUE) or not (FALSE). A resource whose Scalable property is TRUE is said to be in in scalable mode. A resource whose Scalable property is FALSE is said to be in failover mode.

If you declare the Scalable property in the RTR file for a resource, the RGM automatically creates the following set of scalable properties for the resource:

You can create a data service that can run in both scalable and failover mode. To do so, declare the Scalable resource property in the data service's RTR file. You can declare it without a value (the default value is FALSE), or explicitly set its value to FALSE. By default, this resource runs in failover mode. However, the cluster administrator can make the resource run in scalable mode by changing the value of Scalable to TRUE with an administrative utility.

The cluster administrator creates a scalable resource group to contain scalable service resources. Scalable resources make use of shared address resources, which allow the multiple instances of a scalable service to appear as a single service to the client. The shared address resources upon which a scalable resource depends must reside in a separate failover resource group.

The cluster administrator uses the RG_dependencies resource group property to specify the order in which resource groups are brought online and offline on a node. This ordering is important for a scalable service because the scalable resources and the shared address resources upon which they depend are in different resource groups. A scalable data service requires that its network address (shared address) resources be configured up before it is started. Therefore, the administrator must set the RG_dependencies property to include the resource group containing the shared address resources.

The RG_mode property allows the cluster administrator to identify a resource group as failover or scalable. If RG_mode is SCALABLE, the RGM allows Maximum_primaries to have a value greater than 1, meaning the group can be mastered by multiple nodes simultaneously. The RGM does not allow a resource whose Failover property is TRUE to be instantiated in a resource group whose RG_mode is SCALABLE.

See Sun Cluster 3.0 Concepts for additional information regarding scalable resources.

Validation Checks For Scalable Services

Whenever a scalable resource is created or updated, the RGM validates various resource properties. If the properites are not configured correctly, the RGM rejects the attempted update or creation. The RGM performs the following checks:

Writing and Testing Data Services

This section provides some information about writing and testing data services.

Setting Up the Development Environment for Writing a Data Service

Before beginning data service development, you must have installed the Sun Cluster development package (SUNWscdev) to have access to the Sun Cluster header and library files. Although this package is already installed on all cluster nodes, typically, you do development on a separate, non-cluster development machine, not on a cluster node. In this typical case, you must use pkgadd(1M) to install the SUNWscdev package on your development machine.

When compiling and linking your code, you must set particular options to identify the header and library files. When you have finished development (on a non-cluster node) you can transfer the completed data service to a cluster for running and testing.

Note -

Be certain you are using a development version of Solaris.

Use the procedures in this section to:

How to Set Up the Development Environment

This procedure describes how to install the SUNWscdev package and set the compiler and linker options for data service development.

  1. Change directory to the appropriate CD-ROM directory. 


    cd appropriate_CD-ROM_directory

  2. Install the SUNWscdev package in the current directory.


    pkgadd -d . SUNWscdev

  3. In the makefile, specify compiler and linker options to identify the include and library files for your data service code.

    Specify the -I option to identify the Sun Cluster header files, the -L option to identify the static library files, and the -R option to identify the dynamic library files.


    # Makefile for sample data service
... 

-I /usr/cluster/include

-L /usr/cluster/lib

-R /usr/cluster/lib
...

How to Transfer a Data Service to a Cluster

When you have completed development of a data service on a development machine, you must transfer it to a cluster for testing. To reduce the chance of error, the best way to accomplish this transfer is to package together the data service code and the RTR file and then install the package on all nodes of the cluster.

Note -

Whether you use pkgadd or some other way to install the data service, you must put it on all cluster nodes.

Deciding on the START and STOP Methods to Use

This section provides some tips about when to use the START and STOP methods versus using the PRENET_START and POSTNET_STOP methods. You must have in-depth knowledge of both the client and the data service's client-server networking protocol to decide which methods are appropriate.

Services that use network address resources might require that start or stop steps be done in a certain order relative to the Logical_hostname address configuration. The optional callback methods PRENET_START and POSTNET_STOP allow a resource type implementation to do special start-up and shutdown actions before and after network addresses in the same resource group are configured up or configured down.

The RGM calls methods that plumb (but do not configure up) the network addresses before calling the data service's PRENET_START method. The RGM calls methods that unplumb the network addresses after calling the data service's POSTNET_STOP methods. The sequence is as follows when the RGM takes a resource group online.

  1. Plumb network addresses.

  2. Call data service's PRENET_START methods (if any).

  3. Configure network addresses up.

  4. Call data service's START methods (if any).

The reverse happens when the RGM takes a resource group offline:

  1. Call data service's STOP methods (if any).

  2. Configure network addresses down.

  3. Call data service's POSTNET_STOP methods (if any).

  4. Unplumb network addresses.

When deciding whether to use the START, STOP, PRENET_START, or POSTNET_STOP methods, first consider the server side. When bringing online a resource group containing both data service application resources and network address resources, the RGM calls methods to configure up the network addresses before it calls the data service resource START methods. Therefore, if a data service requires network addresses to be configured up at the time it starts, use the START method to start the data service.

Likewise, when bringing offline a resource group that contains both data service resources and network address resources, the RGM calls methods to configure down the network addresses after it calls the data service resource STOP methods. Therefore, if a data service requires network addresses to be configured up at the time it stops, use the STOP method to stop the data service.

For example, to start or stop a data service, you might have to invoke the data service's administrative utilities or libraries. Sometimes, the data service has administrative utilities or libraries that use a client-server networking interface to perform the administration. That is, an administrative utility makes a call to the server daemon, so the network address might need to be up to use the administrative utility or library. Use the START and STOP methods in this scenario.

If the data service requires that the network addresses be configured down at the time it starts and stops, use the PRENET_START and POSTNET_STOP methods to start and stop the data service. Consider whether your client software will respond differently depending on whether the network address or the data service comes online first after a cluster reconfiguration, scha_control giveover, or scswitch switchover. For example, the client implementation might do minimal retries, giving up soon after determining that the data service port is not available.

If the data service does not require the network address to be configured up when it starts, start it before the network interface is configured up. This ensures that the data service is able to respond immediately to client requests as soon as the network address has been configured up, and clients are less likely to stop retrying. In this scenario, use the PRENET_START method rather than the START method to start the data service.

If you use the POSTNET_STOP method, the data service resource is still up at the point the network address is configured to be down. Only after the network address is configured down is the POSTNET_STOP method invoked. As a result, the data service's TCP or UDP service port, or its RPC program number, always appears to be available to clients on the network, except when the network address also is not responding.

The decision to use the START and STOP methods versus the PRENET_START and POSTNET_STOP methods, or to use both, must take the requirements and behavior of both the server and client into account.

Using Keep-Alives

On the server side, using TCP keep-alives protects the server from wasting system resources for a down (or network-partitioned) client. If those resources are not cleaned up (in a server that stays up long enough), eventually the wasted resources grow without bound as clients crash and reboot.

If the client-server communication uses a TCP stream, then both the client and the server should enable the TCP keep-alive mechanism. This provision applies even in the non-HA, single-server case.

Other connection-oriented protocols might also have a keep-alive mechanism.

On the client side, using TCP keep-alives enables the client to be notified when a network address resource has failed over or switched over from one physical host to another. That transfer of the network address resource breaks the TCP connection. However, unless the client has enabled the keep-alive, it would not necessarily learn of the connection break if the connection happens to be quiescent at the time.

For example, consider the case in which the client is waiting for a response from the server to a long-running request. In this scenario, the client's request message has already arrived at the server and has been acknowledged at the TCP layer, so the client's TCP module has no need to keep retransmitting it. The client application is now blocked, waiting for a response to the request.

Where possible, in addition to using the TCP keep-alive mechanism, the client application also must perform its own periodic keep-alive at its level, because the TCP keep-alive mechanism is not perfect in all possible boundary cases. Using an application-level keep-alive typically requires that the client-server protocol supports a null operation or at least an efficient read-only operation such as a status operation.

Testing HA Data Services

This section provides suggestions about how to test a data service implementation in the HA environment. The test cases are suggestions and are not exhaustive. You need access to a test-bed Sun Cluster configuration so the testing work does not impact production machines.

Test that your HA data service behaves properly in all cases where a resource group is moved between physical hosts. These cases include system crashes and the use of the scswitch(1M) command. Test that client machines continue to get service after these events.

Test the idempotency of the methods. For example, replace each method temporarily with a short shell script that calls the original method two or more times.

Coordinating Dependencies Between Resources

Sometimes one client-server data service makes requests on another client-server data service while fulfilling a request for a client. Informally, a data service A depends on a data service B if, for A to provide its service, B must provide its service. Sun Cluster provides for this requirement by permitting resource dependencies to be configured within a resource group. The dependencies affect the order in which Sun Cluster starts and stops data services. See the scrgadm(1M) man page for details.

If resources of your resource type depend on resources of another type, you need to instruct the user to configure the resources and resource groups appropriately, or provide scripts or tools to correctly configure them. If the dependent resource must run on the same node as the depended-on resource, then both resources must be configured in the same resource group.

Decide whether to use explicit resource dependencies, or to omit them and poll for the availability of the other data service(s) in your HA data service's own code. In the case that the dependent and depended-on resource can run on different nodes, configure them into separate resource groups. In this case, polling is required because it is not possible to configure resource dependencies across groups.

Some data services store no data directly themselves, but instead depend on another back-end data service to store all their data. Such a data service translates all read and update requests into calls on the back-end data service. For example, consider a hypothetical client-server appointment calendar service that keeps all of its data in an SQL database such as Oracle. The appointment calendar service has its own client-server network protocol. For example, it might have defined its protocol using an RPC specification language, such as ONC(TM) RPC.

In the Sun Cluster environment, you can use HA-ORACLE to make the back-end Oracle database highly available. Then you can write simple methods for starting and stopping the appointment calendar daemon. Your end user registers the appointment calendar resource type with Sun Cluster.

If the appointment calendar application must run on the same node as the Oracle database, then the end user configures the appointment calendar resource in the same resource group as the HA-ORACLE resource, and makes the appointment calendar resource dependent on the HA-ORACLE resource. This dependency is specified using the Resource_dependencies property tag in scrgadm(1M).

If the HA-ORACLE resource is able to run on a different node than the appointment calendar resource, the end user configures them into two separate resource groups. The end user might configure a resource group dependency of the calendar resource group on the Oracle resource group. However resource group dependencies are only effective when both resource groups are being started or stopped on the same node at the same time. Therefore, the calendar data service daemon, after it has been started, might poll waiting for the Oracle database to become available. The calendar resource type's START method usually would just return success in this case, because if the START method blocked indefinitely it would put its resource group into a busy state, which would prevent any further state changes (such as edits, failovers, or switchovers) on the group. However, if the calendar resource's START method timed-out or exited non-zero, it might cause the resource group to ping-pong between two or more nodes while the Oracle database remained unavailable.