|Skip Navigation Links|
|Exit Print View|
|Oracle Solaris Cluster Reference Manual Oracle Solaris Cluster 4.0|
- resource type implementation for the Cluster Reconfiguration Notification Protocol (CRNP)
The SUNW.Event resource type implementation provides highly available CRNP services on Oracle Solaris Cluster. This implementation makes the notification daemon (/usr/cluster/lib/sc/cl_apid) highly available by managing it as a resource under the Oracle Solaris Cluster resource group manager (RGM). The resource group that contains the SUNW.Event resource must have a network resource configured in the same resource group. Only a single resource of type SUNW.Event should exist on a cluster.
You can run the CRNP only in the global zone.
This section describes key standard properties that control the behavior of the implementation. You use the clresource command to set these properties on a SUNW.Event resource. The r_properties(5) man page describes these resource properties in more detail.
A list of logical-hostname or shared-address network resources upon which this resource has a dependency. This list contains all network-address resources that appear in the properties Resource_dependencies, Resource_dependencies_weak, Resource_dependencies_restart, or Resource_dependencies_offline_restart.
This property is updated automatically by the RGM, based on the setting of the resource-dependencies properties. You do not set this property directly. Instead, use the Resource_dependencies property.
The empty list
A comma-separated list of port numbers on which the server is listening. The r_properties(5) man page describes Port_list in more detail.
A list of resources upon which a resource depends. This list includes any logical-hostname or shared-address network resources that are used by a resource. The default value for this property is null. You must specify this property if the application needs to bind to one or more specific addresses. If no network resource dependencies are specified, the application listens on all addresses.
Before you create the event resource, a LogicalHostname or SharedAddress resource must already be configured.
You can specify one or more resource names. Each network resource can contain one or more logical hostnames. See the clreslogicalhostname(1CL) and clressharedaddress(1CL) man pages for more information.
You can specify an alternate kind of dependency by using the Resource_dependencies_weak, Resource_dependencies_restart, or Resource_dependencies_offline_restart property instead of the Resource_dependencies property. For more information, see the r_properties(5) man page.
The empty list
The number of times that a monitor attempts to restart a resource if it fails. The r_properties(5) man page describes Retry_count in more detail.
Note - If you specify a negative value for this property, the monitor attempts to restart the resource an unlimited number of times.
The number of seconds over which to count attempts to restart a failed resource. The r_properties(5) man page describes Retry_interval in more detail.
The number of seconds between invocations of a high overhead fault probe of the resource. The r_properties(5) man page describes Thorough_probe_interval in more detail.
This section describes key extension properties that control the behavior of the implementation.
This property controls the set of clients that are allowed to register with the implementation to receive cluster reconfiguration events. The general form of this property is ipaddress/masklength, which defines a subnet from which the clients are allowed to register. For example, the setting 18.104.22.168/24 allows clients on the subnet 129.99.77 to register for events. As another example, 22.214.171.124/32 allows only the client 126.96.36.199 to register for events.
In addition, the following special keywords are recognized:
LOCAL refers to all clients that are located in directly connected subnets of the cluster.
ALL allows all clients to register.
Note - If a client matches an entry in both the Allow_hosts and the Deny_hosts property, that client is prevented from registering with the implementation.
This property controls the number of attempts made by the implementation while communicating with external clients. If a client fails to respond within Client_retry_count attempts, the client times out. The client is subsequently removed from the list of registered clients that are eligible to receive cluster reconfiguration events. The client must reregister in order to start receiving events again. The section about the Client_retry_interval property describes how often these retries are made by the implementation.
This property defines the time period (in seconds) used by the implementation while communicating with unresponsive external clients. Up to Client_retry_count attempts are made during this interval to contact the client.
The value for this property can be modified at any time.
This property is the timeout value (in seconds) that is used by the implementation while communicating with external clients. However, the implementation continues to attempt to contact the client for a tunable number of times. The sections about the Client_retry_count and Client_retry_interval properties describe the means of tuning this property.
This property controls the set of clients that are prevented from registering to receive cluster reconfiguration events. To determine access, the settings on this property take precedence over those in the Allow_hosts list. The format of this property is the same as the format that is defined in the Allow_hosts.
This property controls the maximum number of clients that can register with the implementation to receive notification of cluster events. Attempts by additional clients to register for events are rejected by the implementation. Since each client registration uses resources on the cluster, tuning this property allows users to control resource usage on the cluster by external clients.
Example 1 Creating a SUNW.Event Resource With Default Properties
This example shows how to create a failover SUNW.Event resource that is named CRNP in an existing resource group that is named events-rg. The events-rg resource group contains a LogicalHostname or SharedAddress resource, which identifies the failover hostname that is associated with the resource group.
# clresourcetype register SUNW.Event # clresource create -g events-rg -t SUNW.Event CRNP
In this example, the SUNW.Event resource that is created is named CRNP. This resource listens on port 9444 and allows all clients on directly connected subnets to register for events.
Example 2 Creating a SUNW.Event Resource With Non-Default Properties
This example shows how to create a SUNW.Event resource that is named CRNP in a resource group that is named events-rg. The CRNP resource is configured to listen on port 7000, and a specific network resource foo-1, which is already configured in the events-rg resource group. This CRNP resource allows clients on subnet 188.8.131.52 and clients on directly connected subnets to register, but disallows the client 184.108.40.206 from using the implementation.
# clresource create -g events-rg -t SUNW.Event \ -p Port_list=7000/tcp -p Network_resources_used=foo-1 \ -p Allow_hosts=LOCAL,220.127.116.11/24 \ -p Deny_hosts=18.104.22.168/32 CRNP
Directory that contains data type definitions for the CRNP protocol.
See attributes(5) for descriptions of the following attributes.