Skip Navigation Links | |
Exit Print View | |
![]() |
Oracle Solaris Cluster Data Services Planning and Administration Guide |
1. Planning for Oracle Solaris Cluster Data Services
2. Administering Data Service Resources
This section describes the resource properties that are defined by the Oracle Solaris Cluster software.
The property values are categorized as follows:
Required. The cluster administrator must specify a value when he or she creates a resource with an administrative utility.
Optional. If the cluster administrator does not specify a value when he or she creates a resource group, the system supplies a default value.
Conditional. The RGM creates the property only if the property is declared in the RTR file. Otherwise, the property does not exist and is not available to cluster administrators. A conditional property that is declared in the RTR file is optional or required, depending on whether a default value is specified in the RTR file. For details, see the description of each conditional property.
Query-only. Cannot be set directly by an administrative tool.
The Tunable attribute, which is described in Resource Property Attributes, lists whether and when you can update resource properties, as follows:
Never
Any time
When the resource is added to a cluster
When the resource is disabled
Property names are shown first, followed by a description.
Length of time in seconds during which connections from a given client IP address for any service in the resource are sent to the same server node.
This property is relevant only when Load_balancing_policy is either Lb_sticky or Lb_sticky_wild. In addition, Weak_affinity must be set to FALSE.
This property is used only for scalable services.
Optional
No default
ANYTIME
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
The number of seconds between invocations of a quick fault probe of the resource. This property is created by the RGM and is available to the cluster administrator only if it is declared in the RTR file. This property is optional if a default value is specified in the RTR file.
If the Tunable attribute is not specified in the RTR file, the Tunable value for the property is WHEN_DISABLED.
Conditional
No default
WHEN_DISABLED
Controls the number of connections after which the clean-up thread will be started. The clean-up thread cleans all TCP connections which have not completed the three-way TCP handshake. No new connections are accepted until the number of connections drops below Conn_threshold.
This property only applies to resources with the Round_robin policy enabled. No existing resource type registration (RTR) files need to be upgraded to use the Conn_threshold property.
Optional
100
WHEN_DISABLED
Extension properties as declared in the RTR file of the resource's type. The implementation of the resource type defines these properties. Resource Property Attributes contains information about the individual attributes that you can set for extension properties.
Conditional
No default
Depends on the specific property
Modifies the recovery actions that the RGM takes when a resource fails to start or to stop successfully, or when a resource monitor finds a resource to be unhealthy and consequently requests a restart or failover.
NONE, SOFT, or HARD (method failures)
These settings affect only failover behavior when a start or stop method (Prenet_start, Start, Monitor_stop, Stop, Postnet_stop) fails. The RESTART_ONLY and LOG_ONLY settings can also affect whether the resource monitor can initiate the execution of the scha_control command or the scha_control() function. See the scha_control(1HA) and the scha_control(3HA) man pages. NONE indicates that the RGM is not to take any recovery action when one of the previously listed start or stop methods fails. SOFT or HARD indicates that if a Start or Prenet_start method fails, the RGM is to relocate the resource's group to a different node. For Start or Prenet_start failures, SOFT and HARD are the same.
For failure of a stop method (Monitor_stop, Stop, or Postnet_stop), SOFT is the same as NONE. If Failover_mode is set to HARD when one of these stop methods fails, the RGM reboots the node to force the resource group offline. The RGM might then attempt to start the group on another node.
RESTART_ONLY or LOG_ONLY
Unlike NONE, SOFT, and HARD, which affect failover behavior when a start or stop method fails, RESTART_ONLY and LOG_ONLY affect all failover behavior. Failover behavior includes monitor-initiated (scha_control) restarts of resources and resource groups, and giveovers that are initiated by the resource monitor (scha_control). RESTART_ONLY indicates that the monitor can run scha_control to restart a resource or a resource group. The RGM allows Retry_count restarts within Retry_interval. If Retry_count is exceeded, no further restarts are permitted.
Note - A negative value of Retry_count, which is permitted by some but not all resource types, specifies an unlimited number of resource restarts. A more dependable way to specify unlimited restarts is to do the following:
Set Retry_interval to a small value such as 1 or 0.
Set Retry_count to a large value such as 1000.
If the resource type does not declare the Retry_count and Retry_interval properties, an unlimited number of resource restarts is permitted.
If Failover_mode is set to LOG_ONLY, no resource restarts or giveovers are permitted. Setting Failover_mode to LOG_ONLY is the same as setting Failover_mode to RESTART_ONLY with Retry_count set to zero.
RESTART_ONLY or LOG_ONLY (method failures)
If a Prenet_start, Start, Monitor_stop, Stop, or Postnet_stop method fails, RESTART_ONLY and LOG_ONLY are the same as NONE. That is, the node is neither failed over nor rebooted.
Effect of Failover_mode settings on a data service
The effect that each setting for Failover_mode has on a data service depends on whether the data service is monitored or unmonitored and whether it is based on the Data Services Development Library (DSDL).
A data service is monitored if it implements a Monitor_start method and monitoring of the resource is enabled. The RGM starts a resource monitor by executing the Monitor_start method after starting the resource itself. The resource monitor probes the health of the resource. If the probes fail, the resource monitor might request a restart or a failover by calling the scha_control() function. For DSDL-based resources, probes might reveal partial failure (degradation) or a complete failure of the data service. Repeated partial failures accumulate to a complete failure.
A data service is unmonitored if it does not provide a Monitor_start method or monitoring of the resource has been disabled.
DSDL-based data services include those that are developed with Agent Builder, through the GDS, or by using the DSDL directly. Some data services, HA Oracle for example, were developed without using the DSDL.
NONE, SOFT, or HARD (probe failures)
If you set Failover_mode to NONE, SOFT, or HARD and the data service is a monitored DSDL-based service, and if the probe fails completely, the monitor calls the scha_control() function to request a restart of the resource. If probes continue to fail, the resource is restarted up to a maximum of Retry_count number of times within Retry_interval. If the probes fail again after the Retry_count number of restarts is reached, the monitor requests a failover of the resource's group to another node.
If you set Failover_mode to NONE, SOFT, or HARD and the data service is an unmonitored DSDL-based service, the only failure that is detected is the death of the resource's process tree. If the resource's process tree dies, the resource is restarted.
If the data service is a not a DSDL-based service, the restart or failover behavior depends on how the resource monitor is coded. For example, the Oracle resource monitor recovers by restarting the resource or the resource group, or by failing over the resource group.
RESTART_ONLY (probe failures)
If you set Failover_mode to RESTART_ONLY and the data service is a monitored DSDL-based service, and if the probe fails completely, the resource is restarted Retry_count times within Retry_interval. However, if Retry_count is exceeded, the resource monitor exits, sets the resource status to FAULTED, and generates the status message “Application faulted, but not restarted. Probe quitting.” At this point, although monitoring is still enabled, the resource is effectively unmonitored until it is repaired and restarted by the cluster administrator.
If you set Failover_mode to RESTART_ONLY and the data service is an unmonitored DSDL-based service, and if the process tree dies, the resource is not restarted.
If a monitored data service is not DSDL-based, the recovery behavior depends on how the resource monitor is coded. If you set Failover_mode to RESTART_ONLY, the resource or resource group can be restarted by a call to the scha_control() function Retry_count times within Retry_interval. If the resource monitor exceeds Retry_count, the attempt to restart fails. If the monitor calls the scha_control() function to request a failover, that request fails as well.
LOG_ONLY (probe failures)
If you set Failover_mode to LOG_ONLY for any data service, all scha_control() requests either to restart the resource or resource group or to fail over the group are precluded. If the data service is DSDL-based, a message is logged when a probe completely fails, but the resource is not restarted. If a probe fails completely more than Retry_count times within Retry_interval, the resource monitor exits, sets the resource status to FAULTED, and generates the status message “Application faulted, but not restarted. Probe quitting.” At this point, although monitoring is still enabled, the resource is effectively unmonitored until it is repaired and restarted by the cluster administrator.
If you set Failover_mode to LOG_ONLY and the data service is an unmonitored DSDL-based service, and if the process tree dies, a message is logged but the resource is not restarted.
If a monitored data service is not DSDL-based, the recovery behavior depends on how the resource monitor is coded. If you set Failover_mode to LOG_ONLY, all scha_control() requests either to restart the resource or resource group or to fail over the group fail.
Optional
NONE
ANYTIME
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
Provides IP affinity to the client, independent of the protocol. When enabled, all packets from the client to the scalable service follow the first packet from the client, irrespective of the protocol that is used by the connection. This property is relevant only when Load_balancing_policy is either Lb_sticky or Lb_sticky_wild. In addition, UDP_Affinity and Weak_Affinity must be set to FALSE. Affinity_Timeout must have a value greater than 50.
No existing resource type registration (RTR) files need to be upgraded to use this property.
Optional
FALSE
WHEN_DISABLED
This property is allowed only for resource types that set the Global_zone=TRUE property in the RTR file. The setting of the Global_zone_override property overrides the value of the resource type property Global_zone for the particular resource. See the rt_properties(5) man page for more information.
When the Global_zone property is set to TRUE the resource methods always execute in the global-cluster voting node.
Setting the Global_zone_override property to FALSE forces the resource methods to execute on a non-global zone, that is, either a zone-cluster node or a global-cluster non-voting node in which the resource group is configured, rather than always executing in the global zone as they usually would when the Global_zone property is set to TRUE.
This property is optional if a default value is specified in the RTR file.
If the Tunable attribute is not specified in the RTR file, the Tunable value for the property is AT_CREATION. You can set the Tunable attribute in the RTR file to AT_CREATION, WHEN_DISABLED, or ANYTIME.
Use caution when you set the Tunable attribute to Anytime in the RTR file. Changes to the Global_zone_override property take effect immediately, even if the resource is online. For example, suppose that the Global_zone_override tunability is set to ANYTIME and the Global_zone_override property is currently set to FALSE on a resource that is configured in a non-global zone. When the resource is switched online, the starting methods are executed in the non-global zone. If the Global_zone_override property is then set to TRUE and the resource is switched offline, the stopping methods are executed in the global zone. Your method code must be able to handle this possibility. If it cannot, then you must set the Tunable attribute to WHEN_DISABLED or AT_CREATION instead.
Conditional or Optional
TRUE
AT_CREATION
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
Provides for IPsec session failover. Once a client has negotiated a Security Association (SA) with a node, that SA can fail over to another node with the client. This decreases the service downtime incurred as a result of the failure of the original node.
To use IPsec_session_failover, the Generic_Affinity property must be set to TRUE, and the Load_balancing_policy property must be set to Lb_sticky_wild. In addition:
As security sensitive information, including session keys, are transmitted over the interconnect, IPsec must be configured for the interconnect before it is configured for any scalable services. To configure IPsec for the interconnect, follow general Oracle Solaris IPsec configuration procedures and enter the IP addresses for the interconnect in the relevant configuration files. Follow the related Oracle Solaris Cluster procedures for configuring IPsec with scalable services.
The IDLE time has to be specified for the IPsec SA. This corresponds to the p2_idletime_secs parameter in the /etc/inet/ike/config file. Any SAs that transition to IDLE state will have their replay values checkpointed after 2 minutes (by default).
Session failover for SAs not in IDLE state are not supported. Such SAs have replay values that change continuously and are not checkpointed.
5. External servers and clients must support Dead Peer Detection (RFC 3706) to take advantage of the transparent session failover of IDLE SAs.
Internet Key Exchange (IKE) must be used for key negotiation to allow for automatic replication of keying and session state across cluster nodes. To configure monitoring of IKE:
The IKE port 500/udp must be added to the Port_list property
The CheckActivePortInstances property must be set to TRUE
No existing resource type registration (RTR) files need to be upgraded to use the IPsec_session_failover property.
Conditional or Optional
FALSE
AT_CREATION
A string that defines the load-balancing policy in use. This property is used only for scalable services. The RGM automatically creates this property if the Scalable property is declared in the RTR file. Load_balancing_policy can take the following values:
Lb_weighted (the default). The load is distributed among various nodes according to the weights set in the Load_balancing_weights property.
Lb_sticky. A given client (identified by the client IP address) of the scalable service is always sent to the same node of the cluster.
Lb_sticky_wild. A given client's IP address that connects to an IP address of a wildcard sticky service is always sent to the same cluster node, regardless of the port number to which the IP address is coming.
Conditional or Optional
Lb_weighted
AT_CREATION
For scalable resources only. The RGM automatically creates this property if the Scalable property is declared in the RTR file. The format is weight@node,weight@node, where weight is an integer that reflects the relative portion of load that is distributed to the specified node. The fraction of load that is distributed to a node is the weight for this node, divided by the sum of all weights. For example, 1@1,3@2 specifies that node 1 receives one-fourth of the load and node 2 receives three-fourths of the load. The empty string (“”), the default, sets a uniform distribution. Any node that is not assigned an explicit weight receives a default weight of 1.
If the Tunable attribute is not specified in the RTR file, the Tunable value for the property is ANYTIME. Changing this property revises the distribution for new connections only.
Conditional or Optional
The empty string (“”)
ANYTIME
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
Set to Enabled or Disabled by the RGM if the cluster administrator enables or disables the monitor with an administrative utility. If Disabled, monitoring on the resource is stopped, although the resource itself remains online. The Monitor_start method is not called until monitoring is re-enabled. If the resource does not have a monitor callback method, this property does not exist.
Query-only
No default
NONE
A list of logical-hostname or shared-address network resources on which the 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.
The RGM automatically creates this property if the Scalable property is declared in the RTR file. If Scalable is not declared in the RTR file, Network_resources_used is unavailable unless it is explicitly declared in the RTR file.
This property is updated automatically by the RGM, based on the setting of the resource-dependencies properties. You do not need to set this property directly. However, if you add a resource name to this property, the resource name is automatically added to the Resource_dependencies property. In addition, if you delete a resource name from this property, the resource name is automatically deleted from any resource-dependencies property in which the resource also appears.
Conditional or Optional
The empty list
ANYTIME
The number of restart requests that have occurred on this resource within the past n seconds, where n is the value of the Retry_interval property.
A restart request is any of the following calls:
The scha_control(1HA) command with the RESOURCE_RESTART argument.
The scha_control(3HA) function with the SCHA_RESOURCE_RESTART argument.
The scha_control command with the RESOURCE_IS_RESTARTED argument.
The scha_control() function with the SCHA_RESOURCE_IS_RESTARTED argument.
The RGM resets the restart counter to zero for a given resource on a given node whenever that resource executes one of the following:
The scha_control command with the GIVEOVER argument.
The scha_control() function with the SCHA_GIVEOVER argument.
The counter is reset whether the giveover attempt succeeds or fails.
If a resource type does not declare the Retry_interval property, the Num_resource_restarts property is not available for resources of that type.
Query-only
No default
See description
The number of resource group restart requests that have occurred for this resource within the past n seconds, where n is the value of the Retry_interval property.
A resource group restart request is either of the following calls:
The scha_control(1HA) command with the RESTART argument.
The scha_control(3HA) function with the SCHA_RESTART argument.
If a resource type does not declare the Retry_interval property, the Num_rg_restarts property is not available for resources of that type.
Query-only
No default
See description
Set to Enabled or Disabled by the RGM if the cluster administrator enables or disables the resource with an administrative utility. If disabled, a resource is brought offline and has no callbacks run until it is re-enabled.
Query-only
No default
NONE
Allows a scalable service to initiate requests to a server outside the cluster and to use the virtual IP address of the scalable service as the source IP address of those requests.
To use Outgoing_Connection, the Generic_Affinity property must be set to TRUE, and the Load_balancing_policy property must be set to Lb_sticky_wild.
No existing resource type registration (RTR) files need to be upgraded to use the Outgoing_Connection property.
Conditional or Optional
FALSE
AT_CREATION
A list of port numbers on which the server is listening. Appended to each port number is a slash (/) followed by the protocol that is being used by that port, for example, Port_list=80/tcp or Port_list=80/tcp6,40/udp6.
You can specify the following protocol values:
tcp, for TCP IPv4
tcp6, for TCP IPv6
udp, for UDP IPv4
udp6, for UDP IPv6
sctp, for SCTP
If the Scalable property is declared in the RTR file, the RGM automatically creates Port_list. Otherwise, this property is unavailable unless it is explicitly declared in the RTR file.
Setting up this property for Apache is described in the Oracle Solaris Cluster Data Service for Apache Guide. The Network_resources_used property accepts multiple shared-address resources. If the protocol is SCTP, the clrs command checks that the network resources used belong to the same resource group such that they are hosted on the same node. In SCTP, a single association can use multiple shared addresses. This requirement ensures that the global interface (GIF) node is same for all shared-address resources that are specified. Otherwise, SCTP is managed the same as TCP or UDP services.
Conditional or Required
No default
ANYTIME
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
A brief description of the resource.
Optional
The empty string
ANYTIME
A list of resources on which the resource has a strong dependency. A strong dependency determines the order of method calls.
A resource with resource dependencies, referred to as the dependent resource, cannot be started if any resource in the list, referred to as the depended-on resource, is not online. If the dependent resource and one of the depended-on resources in the list start at the same time, the RGM waits to start the dependent resource until the depended-on resource in the list starts. If the depended-on resource does not start, the dependent resource remains offline. The depended-on resource might not start because the resource group for the depended-on resource in the list remains offline or is in a Start_failed state. If the dependent resource remains offline because of a dependency on a depended-on resource in a different resource group that fails to start or is disabled or offline, the dependent resource's group enters a Pending_online_blocked state. If the dependent resource has a dependency on a depended-on resource in the same resource group that fails to start or is disabled or offline, the resource group does not enter a Pending_online_blocked state.
By default in a resource group, application resources have an implicit strong resource dependency on network address resources. Implicit_network_dependencies in Resource Group Properties contains more information.
Within a resource group, Prenet_start methods are run in dependency order before Start methods. Postnet_stop methods are run in dependency order after Stop methods. In different resource groups, the dependent resource waits for the depended-on resource to finish Prenet_start and Start before it runs Prenet_start. The depended-on resource waits for the dependent resource to finish Stop and Postnet_stop before it runs Stop.
To specify the scope of a dependency, append the following qualifiers, including the braces ({}), to the resource name when you specify this property.
Limits the specified dependency to a per-host basis. The behavior of the dependent is affected by the depended-on resource only on the same host. The dependent resource waits for the depended-on resource to start on the same host. The situation is similar for stopping and restarting.
Extends the specified dependency to any node. The behavior of the dependent is affected by the depended-on resource on any node. The dependent resource waits for the depended-on resource to start on any primary node before it starts itself. The situation is similar for stopping and restarting.
Specifies that the scope of the resource dependency is derived from the RG_affinities relationship of the resource groups to which the resources belong. If the dependent resource's group has a positive affinity for the depended-on resource's resource group, and they are starting or stopping on the same node, the dependency is {LOCAL_NODE}. If no such positive affinity exists, or if the groups are starting on different nodes, the dependency is {ANY_NODE}.
Resource dependencies between two resources that are located in the same resource group are always {LOCAL_NODE}.
If you do not specify a qualifier, FROM_RG_AFFINITIES is used by default.
Optional
The empty list
ANYTIME
A list of resources in the same or in different groups upon which this resource has an offline-restart dependency.
This property works just as Resource_dependencies does, except that, if any resource in the offline-restart dependency list is stopped, this resource is stopped. If that resource in the offline-restart dependency list is subsequently restarted, this resource is restarted.
This resource cannot be started if the start of any resource in the list fails. If this resource and one of the resources in the list start at the same time, the RGM waits until the resource in the list starts before the RGM starts this resource. If the resource in this resource's Resource_dependencies list does not start (for example, if the resource group for the resource in the list remains offline or if the resource in the list is in a Start_failed state), this resource also remains offline. If this resource remains offline because of a dependency on a resource in a different resource group that fails to start, this resource's group enters a Pending_online_blocked state.
If this resource is brought offline at the same time as those in the list, this resource stops before those in the list. However, if this resource remains online or fails to stop, a resource in the list stops anyway.
If a fault occurs on a “depended-on” resource on a node, and the resource cannot recover, the RGM brings that resource on that node offline. The RGM also brings all of the depended-on resource's offline-restart dependents offline by triggering a restart on them. When the cluster administrator resolves the fault and re-enables the depended-on resource, the RGM brings the depended-on resource's offline-restart dependents back online as well.
To specify the scope of a dependency, append the following qualifiers, including the braces ({ }), to the resource name when you specify this property.
Limits the specified dependency to a per-host basis. The behavior of the dependent is affected by the depended-on resource only on the same host. The dependent resource waits for the depended-on resource to start on the same host. The situation is similar for stopping and restarting.
Extends the specified dependency to any node. The behavior of the dependent is affected by the depended-on resource on any node. The dependent resource waits for the depended-on resource to start on any primary node before it starts itself. The situation is similar for stopping and restarting.
Specifies that the scope of the resource dependency is derived from the RG_affinities relationship of the resource groups to which the resources belong. If the dependent resource's group has a positive affinity for the depended-on resource's resource group, and they are starting or stopping on the same node, the dependency is {LOCAL_NODE}. If no such positive affinity exists, or if the groups are starting on different nodes, the dependency is {ANY_NODE}.
Resource dependencies between two resources that are located in the same resource group are always {LOCAL_NODE}.
If you do not specify a qualifier, FROM_RG_AFFINITIES is used by default.
Optional
The empty list
ANYTIME
A list of resources on which the resource has a restart dependency. A restart dependency determines the order of method calls.
This property works as Resource_dependencies does, with one addition. If any resource in the restart dependency list, referred to as a depended-on resource, is restarted, the resource with resource dependencies, referred to as the dependent resource, is restarted. After the depended-on resource in the list comes back online, the RGM stops and restarts the dependent resource. This restart behavior occurs when the resource groups that contain the dependent and depended-on resources remain online.
A resource with resource dependencies, referred to as the dependent resource, cannot be started if any resource in the list, referred to as the depended-on resource, is not online. If the dependent resource and one of the depended-on resources in the list start at the same time, the RGM waits to start the dependent resource until the depended-on resource in the list starts. If the depended-on resource does not start, the dependent resource remains offline. The depended-on resource might not start because the resource group for the depended-on resource in the list remains offline or is in a Start_failed state. If the dependent resource remains offline because of a dependency on a depended-on resource in a different resource group that fails to start or is disabled or offline, the dependent resource's group enters a Pending_online_blocked state. If the dependent resource has a dependency on a depended-on resource in the same resource group that fails to start or is disabled or offline, the resource group does not enter a Pending_online_blocked state.
To specify the scope of a dependency, append the following qualifiers, including the braces ({}), to the resource name when you specify this property.
Limits the specified dependency to a per-host basis. The behavior of the dependent is affected by the depended-on resource only on the same host. The dependent resource waits for the depended-on resource to start on the same host. The situation is similar for stopping and restarting.
Extends the specified dependency to any node. The behavior of the dependent is affected by the depended-on resource on any node. The dependent resource waits for the depended-on resource to start on any primary node before it starts itself. The situation is similar for stopping and restarting.
Specifies that the scope of the resource dependency is derived from the RG_affinities relationship of the resource groups to which the resources belong. If the dependent resource's group has a positive affinity for the depended-on resource's resource group, and they are starting or stopping on the same node, the dependency is {LOCAL_NODE}. If no such positive affinity exists, or if the groups are starting on different nodes, the dependency is {ANY_NODE}.
Resource dependencies between two resources that are located in the same resource group are always {LOCAL_NODE}.
If you do not specify a qualifier, FROM_RG_AFFINITIES is used by default.
Optional
The empty list
ANYTIME
A list of resources on which the resource has a weak dependency. A weak dependency determines the order of method calls.
The RGM calls the Start methods of the resources in this list, referred to as the depended-on resources, before the Start method of the resource with resource dependencies, referred to as the dependent resource. The RGM calls the Stop methods of the dependent resource before the Stop methods of the depended-on resources. The dependent resource can still start if the depended-on resources fail to start or remain offline.
If the dependent resource and a depended-on resource in its Resource_dependencies_weak list start concurrently, the RGM waits to start the dependent resource until the depended-on resource in the list starts. If the depended-on resource in the list does not start, for example, if the resource group for the depended-on resource in the list remains offline or the depended-on resource in the list is in a Start_failed state, the dependent resource starts. The dependent resource's resource group might enter a Pending_online_blocked state temporarily as resources in the dependent resource's Resource_dependencies_weak list start. When all depended-on resources in the list have started or failed to start, the dependent resource starts and its group reenters the Pending_online state.
Within a resource group, Prenet_start methods are run in dependency order before Start methods. Postnet_stop methods are run in dependency order after Stop methods. In different resource groups, the dependent resource waits for the depended-on resource to finish Prenet_start and Start before it runs Prenet_start. The depended-on resource waits for the dependent resource to finish Stop and Postnet_stop before it runs Stop.
To specify the scope of a dependency, append the following qualifiers, including the braces ({}), to the resource name when you specify this property.
Limits the specified dependency to a per-host basis. The behavior of the dependent is affected by the depended-on resource only on the same host. The dependent resource waits for the depended-on resource to start on the same host. The situation is similar for stopping and restarting.
Extends the specified dependency to any node. The behavior of the dependent is affected by the depended-on resource on any node. The dependent resource waits for the depended-on resource to start on any primary node before it starts itself. The situation is similar for stopping and restarting.
Specifies that the scope of the resource dependency is derived from the RG_affinities relationship of the resource groups to which the resources belong. If the dependent resource's group has a positive affinity for the depended-on resource's resource group, and they are starting or stopping on the same node, the dependency is {LOCAL_NODE}. If no such positive affinity exists, or if the groups are starting on different nodes, the dependency is {ANY_NODE}.
Resource dependencies between two resources that are located in the same resource group are always LOCAL_NODE.
If you do not specify a qualifier, FROM_RG_AFFINITIES is used by default.
Optional
The empty list
ANYTIME
The name of the resource instance. This name must be unique within the cluster configuration and cannot be changed after a resource has been created.
Required
No default
NONE
The Oracle Solaris project name that is associated with the resource. Use this property to apply Oracle Solaris resource management features, such as CPU shares and resource pools, to cluster data services. When the RGM brings resources online, it starts the related processes under this project name. If this property is not specified, the project name is taken from the RG_project_name property of the resource group that contains the resource (see the rg_properties(5) man page). If neither property is specified, the RGM uses the predefined project name default. The specified project name must exist in the projects database(see the projects(1) man page and System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones).
Note - Changes to this property take effect the next time that the resource is started.
Optional
Null
ANYTIME
The RGM-determined state of the resource on each cluster node. Possible states are Online, Offline, Start_failed, Stop_failed, Monitor_failed, Online_not_monitored, Starting, and Stopping.
You cannot configure this property.
Query-only
No default
NONE
The number of times that a monitor attempts to restart a resource if it fails.
If the Retry_count is exceeded, depending on the particular data service and the setting of the Failover_mode property, the monitor might perform one of the following actions:
Allow the resource group to remain on the current primary node, even though the resource is in a faulted state
Request a failover of the resource group onto a different node
This property is created by the RGM and is made available to the cluster administrator only if this property is declared in the RTR file. This property is optional if a default value is specified in the RTR file.
If the Tunable attribute is not specified in the RTR file, the Tunable value for the property is WHEN_DISABLED.
Note - If you specify a negative value for this property, the monitor attempts to restart the resource an unlimited number of times.
However, some resource types do not allow you to set Retry_count to a negative value. A more dependable way to specify unlimited restarts is to do the following:
Set Retry_interval to a small value such as 1 or 0.
Set Retry_count to a large value such as 1000.
Conditional
See above
WHEN_DISABLED
The number of seconds over which to count attempts to restart a failed resource. The resource monitor uses this property in conjunction with Retry_count. This property is created by the RGM and is available to the cluster administrator only if it is declared in the RTR file. This property is optional if a default value is specified in the RTR file.
If the Tunable attribute is not specified in the RTR file, the Tunable value for the property is WHEN_DISABLED.
Conditional
No default (see above)
WHEN_DISABLED
Assigns incoming connections to one specific node of all those running a service, in a predetermined order based on the weights and utilization of the node. The Round Robin load-balancing scheme permits the deterministic assignment of connections to nodes. When Round Robin load-balancing is implemented, the Global Interface (GIF) node directs each incoming connection for a service to a specific node running that service, based on nodes' assigned weights and whether the service is sticky.
A new resource property, Conn_threshold, and a new cluster property, udp_session_timeout, support the Round Robin scheme, and may optionally be configured by the user if the Round_robin resource property is set for a service. .
No existing resource type registration (RTR) files need to be upgraded to use the Round_robin property.
Optional
FALSE
WHEN_DISABLED
Indicates whether the resource is scalable, that is, whether the resource uses the networking load-balancing features of the Oracle Solaris Cluster software.
Note - You can configure a scalable resource group (which uses network load-balancing) to run in a global-cluster non-voting node. However, you can run such a scalable resource group in only one node per Oracle Solaris host.
If this property is declared in the RTR file, the RGM automatically creates the following scalable service properties for resources of that type: Affinity_timeout, Load_balancing_policy, Load_balancing_weights, Network_resources_used, Port_list, UDP_affinity, and Weak_affinity. These properties have their default values unless they are explicitly declared in the RTR file. The default for Scalable, when it is declared in the RTR file, is TRUE.
If this property is declared in the RTR file, it cannot be assigned a Tunable attribute other than AT_CREATION.
If this property is not declared in the RTR file, the resource is not scalable, you cannot tune this property, and no scalable service properties are set by the RGM. However, you can explicitly declare the Network_resources_used and Port_list properties in the RTR file. These properties can be useful in a nonscalable service as well as in a scalable service.
Using this resource property in combination with the Failover resource type property is described in more detail in the r_properties(5) man page.
Optional
No default
AT_CREATION
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
Set by the resource monitor with the scha_resource_setstatus command or the scha_resource_setstatus() or scha_resource_setstatus_zone() functions. Possible values are OK, DEGRADED, FAULTED, UNKNOWN, and OFFLINE. When a resource is brought online or offline, the RGM automatically sets the Status value if the Status value is not set by the resource's monitor or methods.
Query-only
No default
NONE
Set by the resource monitor at the same time as the Status property. When a resource is brought online or offline, the RGM automatically resets this property to the empty string if this property is not set by the resource's methods.
Query-only
No default
NONE
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
The number of seconds between invocations of a high-overhead fault probe of the resource. This property is created by the RGM and is available to the cluster administrator only if it is declared in the RTR file. This property is optional if a default value is specified in the RTR file.
If the Tunable attribute is not specified in the RTR file, the Tunable value for the property is WHEN_DISABLED.
Conditional
No default
WHEN_DISABLED
The resource type of which this resource is an instance.
Required
No default
NONE
Specifies which version of the resource type is currently associated with this resource. The RGM automatically creates this property, which cannot be declared in the RTR file. The value of this property is equal to the RT_version property of the resource's type. When a resource is created, the Type_version property is not specified explicitly, though it might appear as a suffix of the resource type name. When a resource is edited, the Type_version property can be changed to a new value.
The tunability of this property is derived from the following sources:
The current version of the resource type
The #$upgrade_from directive in the RTR file
See description
No default
See description
If this property is set to TRUE, sends all UDP traffic from a given client to the same server node that currently handles all TCP traffic for the client.
This property is relevant only when Load_balancing_policy is either Lb_sticky or Lb_sticky_wild. In addition, Weak_affinity must be set to FALSE.
This property is only used for scalable services.
Optional
No default
WHEN_DISABLED
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
A time lapse, in seconds, after which the RGM concludes that an invocation of this method has failed. For a given resource type, timeout properties are defined only for those methods that are declared in the RTR file.
Conditional or Optional
3600 (one hour), if the method itself is declared in the RTR file
ANYTIME
If this property is set to TRUE, this property enables the weak form of the client affinity.
The weak form of the client affinity allows connections from a given client to be sent to the same server node except when the following conditions occur:
A server listener starts in response to, for example, a fault monitor's restarting, a resource's failing over or switching over, or a node's rejoining a cluster after failing
Load_balancing_weights for the scalable resource changes because the cluster administrator performed an administrative action
Weak affinity provides a low-overhead alternative to the default form, both in terms of memory consumption and processor cycles.
This property is relevant only when Load_balancing_policy is either Lb_sticky or Lb_sticky_wild.
This property is only used for scalable services.
Optional
No default
WHEN_DISABLED