Generally, all resources are unique but some resources may have common attributes. Oracle Clusterware uses resource types to organize these similar resources. Benefits that resource types provide are:
Manage only necessary resource attributes
Manage all resources based on the resource type
Every resource that you register in Oracle Clusterware must have a certain resource type. In addition to the resource types included in Oracle Clusterware, you can define custom resource types using the Oracle Clusterware Control (CRSCTL) utility. The included resource types are:
Local resource: Instances of local resources—type name is local_resource—run on each server of the cluster (the default) or you can limit them to run on servers belonging to a particular server category. When a server joins the cluster, Oracle Clusterware automatically extends local resources to have instances tied to the new server. When a server leaves the cluster, Oracle Clusterware automatically sheds the instances of local resources that ran on the departing server. Instances of local resources are pinned to their servers; they do not fail over from one server to another.
Cluster resource: Cluster-aware resource types—type name is cluster_resource—are aware of the cluster environment and are subject to cardinality and cross-server switchover and failover.
Generic application: You can use this resource type—type name is generic_application—to protect any generic applications without requiring additional scripts. High availability for an application is achieved by defining a resource with the generic_application resource type and providing the values for key attributes of the resource. The generic_application resource type is derived from the cluster_resource resource type and, therefore, all resources of the generic_application resource type are cluster-aware resources. Attributes include:
START_PROGRAM: A complete path to the executable that starts the application, with all appropriate arguments. The executable must exist on every server where Oracle Grid Infrastructure is configured to run the application. This attribute is required. For example:
/opt/my_app –start
The executable must also ensure that the application starts and return an exit status value of zero (0) to indicate that the application started successfully and is online. If the executable fails to start the application, then the executable exits with a non-zero status code.
STOP_PROGRAM: A complete path to the executable that stops the application, with all appropriate arguments. The executable must exist on every server where Oracle Grid Infrastructure is configured to run the application. If you do not specify this attribute value, then Oracle Clusterware uses an operating system-equivalent of the kill command. For example:
/opt/my_app –stop
The executable must also ensure that the application stops and return an exit status value of zero (0) to indicate that the application stopped successfully. If the executable fails to stop the application, then the executable exits with a non-zero status code and Oracle Clusterware initiates a clean of the resource.
CLEAN_PROGRAM: A complete path to the executable that cleans the program, with all appropriate arguments. The executable must exist on every server where Oracle Grid Infrastructure is configured to run the application. If you do not specify a value for this attribute, then Oracle Clusterware uses an operating system-equivalent of the kill -9 command. For example:
/opt/my_app –clean
Note:
The difference between STOP_PROGRAM and CLEAN_PROGRAM is that CLEAN_PROGRAM is a forced stop that stops an application ungracefully, and must always be able to stop an application or the application becomes unmanageable.
PID_FILES: A comma-delimited list of complete paths to files that will be written by the application and contain a process ID (PID) to monitor. Failure of a single process is treated as a complete resource failure. For example:
/opt/app.pid
Note:
The files that you specify in the PID_FILES attribute are read immediately after the START action completes and monitoring commences for the PIDs listed in the files.
EXECUTABLE_NAMES: A comma-delimited list of names of executables that is created when the application starts and the state of these executables is subsequently monitored. Failure of a single executable is treated as a complete resource failure. For example:
my_app
Note:
You need specify only the complete name of the executables. This attribute does not accept the path of the executable or wild cards. The PIDs matching the executable names are cached immediately after the START action completes.
CHECK_PROGRAMS: A list of complete paths to the executable that determines the state of the application. Reporting a non-running state by any of the applications is treated as a failure of the entire resource. For example:
/opt/my_app –check
ENVIRONMENT_FILE: A complete path to the file containing environment variables to source when starting the application. The file must be a text file containing name=value pairs, one per line. For example:
/opt/my_app.env
ENVIRONMENT_VARS: A comma-delimited list of name=value pairs to be included into the environment when starting an application. For example:
USE_FILES=No, AUTO_START=Yes
SEND_OUTPUT_ALWAYS: This attribute is responsible for sending the application output that is sent to STDOUT, which is then displayed. A value of 0 does not display any application output unless an action fails. When an action fails, whatever application output that has been saved by the agent is displayed. Any value greater than 0 displays every application output. The default value is 0. For example:
SEND_OUTPUT_ALWAYS=1
Note:
If you do not specify the STOP_PROGRAM, CHECK_PROGRAMS, and CLEAN_PROGRAM attributes, then you must specify either PID_FILES or EXECUTABLE_NAMES, or Oracle Clusterware will not allow you to register a resource of this type.
If you specify all the attributes, then the following rules apply:
When stopping a resource, if you specified STOP_PROGRAM, then Oracle Clusterware calls STOP_PROGRAM. Otherwise, Oracle Clusterware uses an operating system-equivalent of the kill -9 command on the PID obtained from either the PID_FILES or the EXECUTABLE_NAMES attribute.
When you need to establish the current state of an application, if you specified CHECK_PROGRAMS, then Oracle Clusterware calls CHECK_PROGRAMS. Otherwise, Oracle Clusterware uses an operating system-equivalent of the ps -p command with the PID obtained from either the PID_FILES or EXECUTABLE_NAMES attribute.
When cleaning a resource, if you specified CLEAN_PROGRAM, then Oracle Clusterware calls CLEAN_PROGRAM. Otherwise, Oracle Clusterware uses an operating system-equivalent of the kill -9 command on the PID obtained from either the PID_FILES or the EXECUTABLE_NAMES attribute.
See Also:
"crsctl add resource" for more information about and examples of using CRSCTL to add resources
"Resource States" for more information about resource state
"Creating Resources that Use the generic_application Resource Type"