Defining the Resource Type Registration File

The resource type registration (RTR) file in this example defines the static configuration of the DNS resource type. Resources of this type inherit the properties that are defined in the RTR file.

The information in the RTR file is read by the Resource Group Manager (RGM) when the cluster administrator registers the HA-DNS data service. By convention, you place the RTR file in the /opt/cluster/lib/rgm/rtreg/ directory. Note that the package installer places the RTR file that Agent Builder creates in this directory as well.

Overview of the RTR File

The RTR file follows a well-defined format. Resource type properties are defined first in the file, system-defined resource properties are defined next, and extension properties are defined last. See the rt_reg(4) man page and Setting Resource and Resource Type Propertiesfor more information.

The following sections describe the specific properties in the sample RTR file. These sections provide listings of different parts of the file. For a complete listing of the contents of the sample RTR file, see Resource Type Registration File Listing.

Resource Type Properties in the Sample RTR File

The sample RTR file begins with comments followed by resource type properties that define the HA-DNS configuration, as shown in the following listing. The example assumes that previous versions of the resource type exist, so #$upgrade directives are included. See Specifying the #$upgrade and #$upgrade_from Directives for more information.

#
# Copyright (c) 1998, 2011, Oracle and/or its affiliates.
# All rights reserved.
#
# Registration information for Domain Name Service (DNS)
#

#pragma ident   “@(#)ORCL.sample   1.3   00/05/24”

Resource_type = “sample”;
Vendor_id = ORCL;
RT_description = “Domain Name Service on Oracle Solaris Cluster”;

RT_version =”3”; 
API_version = 2;    
Failover = TRUE;

RT_basedir=/opt/ORCLsample/bin;
Pkglist = ORCLsample;

Start         =   dns_svc_start;
Stop          =   dns_svc_stop;

Validate      =   dns_validate;
Update        =   dns_update;

Monitor_start =   dns_monitor_start;
Monitor_stop  =   dns_monitor_stop;
Monitor_check =   dns_monitor_check;

#$upgrade 
#$upgrade_from "1" when_disabled 
#$upgrade_from "2" anytime

The following information describes these properties:

• You can specify the resource type name by the Resource_type property alone (sample) or by using the vendor-id as a prefix, followed by a period (.), followed by the resource type property (ORCL.sample).

  If you specify vendor-id, use the stock exchange symbol of the company that is defining the resource type. The resource type name must be unique in the cluster.

• The RT_version property identifies the version of the sample data service as specified by the vendor.

• The API_version property identifies the Oracle Solaris Cluster version. For example, API_version = 11 indicates that the data service can be registered on any version of Oracle Solaris Cluster starting with 3.3, assuming that the application is compatible with that version of Oracle Solaris Cluster software. However, API_version = 11 also indicates that the data service cannot be registered on any version of Oracle Solaris Cluster that was released before 3.3. This property is described in more detail in the rt_properties(5) man page.

• Failover = TRUE indicates that the data service cannot run in a resource group that can be online on multiple nodes at the same time.

• RT_basedir points to /opt/ORCLsample/bin as the directory path to complete relative paths, such as callback method paths.

• Start, Stop, and Validate provide the paths to the respective callback method programs that are run by the RGM. These paths are relative to the directory that is specified by RT_basedir.

• Pkglist identifies ORCLsample as the package that contains the sample data service installation.

Resource type properties that are not specified in this RTR file, such as Single_instance, Init_nodes, and Installed_nodes, are set to their default values. Resource Type Properties contains a complete list of the resource type properties, including their default values.

The cluster administrator cannot change the values for resource type properties in the RTR file.

Resource Properties in the Sample RTR File

By convention, you declare resource properties after the resource type properties in the RTR file. Resource properties include system-defined properties that are provided by the Oracle Solaris Cluster software and extension properties that you define. For either type, you can specify a number of property attributes that are supplied by the Oracle Solaris Cluster software, such as minimum, maximum, and default values.

System-Defined Properties in the RTR File

The following listing shows the system-defined properties in a sample RTR file.

# A list of bracketed resource property declarations follows the
# resource type declarations. The property-name declaration must be
# the first attribute after the open curly bracket of each entry.

# The <method>_timeout properties set the value in seconds after which
# the RGM concludes invocation of the method has failed.

# The MIN value for all method timeouts is set to 60 seconds. This
# prevents administrators from setting shorter timeouts, which do not
# improve switchover/failover performance, and can lead to undesired
# RGM actions (false failovers, node reboot, or moving the resource group
# to ERROR_STOP_FAILED state, requiring operator intervention). Setting
# too-short method timeouts leads to a *decrease* in overall availability
# of the data service.
{
   PROPERTY = Start_timeout; 
   MIN=60; 
   DEFAULT=300;
}

{
   PROPERTY = Stop_timeout; 
   MIN=60; 
   DEFAULT=300;
}
{
   PROPERTY = Validate_timeout;
   MIN=60;
   DEFAULT=300;
}
{
   PROPERTY = Update_timeout;
   MIN=60;
   DEFAULT=300;
}
{
   PROPERTY = Monitor_Start_timeout;
   MIN=60;
   DEFAULT=300;
}
{
   PROPERTY = Monitor_Stop_timeout;
   MIN=60;
   DEFAULT=300;
}
{
   PROPERTY = Thorough_Probe_Interval;
   MIN=1;
   MAX=3600;
   DEFAULT=60;
   TUNABLE = ANYTIME;
}

# The number of retries to be done within a certain period before concluding 
# that the application cannot be successfully started on this node.
{
   PROPERTY = Retry_count;
   MIN=0;
   MAX=10;
   DEFAULT=2;
   TUNABLE = ANYTIME; 
}

# Set Retry_interval as a multiple of 60 since it is converted from seconds
# to minutes, rounding up. For example, a value of 50 (seconds)
# is converted to 1 minute. Use this property to time the number of 
# retries (Retry_count).
{
   PROPERTY = Retry_interval;
   MIN=60;
   MAX=3600;
   DEFAULT=300;
   TUNABLE = ANYTIME;
}

{
   PROPERTY = Network_resources_used;
   TUNABLE = AT_CREATION;
   DEFAULT = ““;
}

Although the Oracle Solaris Cluster software provides the system-defined properties, you can set different default values by using resource property attributes. See Resource Property Attributes for a complete list of attributes that are available to you to apply to resource properties.

Note the following points about the system-defined resource properties in the sample RTR file:

• Oracle Solaris Cluster provides a minimum value (1 second) and a default value (3600 seconds, or one hour) for all timeouts. The sample RTR file changes the minimum timeout to 60 seconds and the default value to 300 seconds. A cluster administrator can accept this default value or change the value of the timeout to another value, 60 or greater. Oracle Solaris Cluster has no maximum allowed value.

• The TUNABLE attribute for the properties Thorough_probe_interval, Retry_count, and Retry_interval, are set to ANYTIME. These settings indicate that the cluster administrator can change the value of these properties, even when the data service is running. These properties are used by the fault monitor implemented by the sample data service. The sample data service implements an Update method to stop and restart the fault monitor when these or other resource properties are changed by administrative action. See How the Update Method Works.

• Resource properties are classified as follows:

  • Required. The cluster administrator must specify a value when creating a resource.

  • Optional. If the cluster administrator does not specify a value, the system supplies a default value.

  • Conditional. The RGM creates the property only if it is declared in the RTR file.

  The fault monitor of the sample data service makes use of the Thorough_probe_interval, Retry_count, Retry_interval, and Network_resources_used conditional properties, so you need to declare them in the RTR file. See the r_properties(5) man page or Resource Properties for information about how properties are classified.

Extension Properties in the RTR File

At the end of the sample RTR file are extension properties, as shown in this listing.

# Extension Properties

# The cluster administrator must set the value of this property to point to the
# directory that contains the configuration files used by the application.
# For this application, DNS, specify the path of the DNS configuration file on
# PXFS (typically named.conf).
{
   PROPERTY = Confdir;
   EXTENSION;
   STRING;
   TUNABLE = AT_CREATION;
   DESCRIPTION = “The Configuration Directory Path”;
}

# Time out value in seconds before declaring the probe as failed.
{
   PROPERTY = Probe_timeout;
   EXTENSION;
   INT;
   DEFAULT = 120;
   TUNABLE = ANYTIME;
   DESCRIPTION = “Time out value for the probe (seconds)”;
}

The sample RTR file defines two extension properties, Confdir and Probe_timeout. The Confdir property specifies the path to the DNS configuration directory. This directory contains the in.named file, which DNS requires to operate successfully. The sample data service's Start and Validate methods use this property to verify that the configuration directory and the in.named file are accessible before starting DNS.

When the data service is configured, the Validate method verifies that the new directory is accessible.

The sample data service's PROBE method is not an Oracle Solaris Cluster callback method but a user-defined method. Therefore, Oracle Solaris Cluster does not provide a Probe_timeout property for it. You need to define an extension property in the RTR file to enable a cluster administrator to configure a Probe_timeout value.