Skip Navigation Links
Exit Print View
| Oracle Solaris Cluster Reference Manual Oracle Solaris Cluster 4.1

Search Scope:

- This Document
- Entire Library

### r_properties

- resource properties

## Description

The following information describes the resource properties that are defined by Oracle Solaris Cluster software. These descriptions have been developed for data service developers. For more information about a particular data service, see the man page for that data service.

Note - A resource must have the Scalable resource property set to TRUE before it can use the network load balancing features of Oracle Solaris Cluster software. Scalable resources can use the `Affinity_timeout`, `Generic_affinity`, `Load_balancing_policy`, `Load_balancing_weights`, `Conn_threshold`, `Round_robin`, `Port_list`, `UDP_affinity`, and `Weak_affinity` properties.

Some resource types can run on multiple nodes without using network load balancing. The `Scalable` property for such a resource is set to `False`, and such a resource does not use the preceding additional properties.

### Resource Property Values

Required

  The cluster administrator must specify a value when creating a resource with an administrative utility.

Optional

  If the cluster administrator does not specify a value when creating a resource group, the system supplies a default value.

Conditional

  The Resource Group Manager (RGM) creates the property only if the property is declared in the Resource Type Registration (RTR) file. Otherwise, the property does not exist and is not available to the cluster administrator. 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 cluster administrator can edit all tunable properties by using the following command:

    # clresource set -p property=new-value resource

### Resource Properties and Descriptions

Note - Property names, such as `Affinity_timeout` and `Cheap_probe_interval`, are not case sensitive. You can use any combination of uppercase and lowercase letters when you specify property names.

`Affinity_timeout` (`integer`)

  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.

  If you set this property to `-1`, all connections are sent to the same node. If you set this property to `0`, all open connections are sent to the same node. If you set this property to n, for n number of seconds after the last connection has closed, all new connections are sent to the same node as the last connection.

  In all cases, if the server node leaves the cluster as a result of a failure, a new server node is selected.

  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` (the default value).

  This property is used only for scalable services.

  Category

    Conditional/Optional

  Default

    0

  Tunable

    Any time

`Application_user` (`string`)

  A Solaris user name to be used for execution of application programs related to the resource.

  Application programs that are executed by resource methods or monitors might execute as root or as a non-root user (the "application user"), depending on how the particular agent is implemented. The `application_user` resource property does not exist for all resource types; only those resource types that declare this property allow it to be set.

  A resource type that declares the `application_user` resource property is typically an agent that uses the `scha_check_app_user`(1HA) interface to perform additional checks on the executable file ownership and permissions of application programs. If the application program executable is not owned by root but is to be executed by root, or if the executable has group or world write permissions, an insecurity exists. In this case, if the `resource_security` property is set to `SECURE`, execution of the application program fails at run time and an error is returned. If `resource_security` has any other setting, the application program is allowed to execute with a warning message.

  A resource type that declares the `application_user` property sets the user ID for execution of application programs according to the setting of the `resource_security` cluster property. If `resource_security` is set to `COMPATIBILITY`, the setting of the `application_user` resource property is ignored and the application user will be the effective user ID of the caller (usually root). This behavior is compatible with previous releases of Oracle Solaris Cluster.

  If `resource_security` is set to `OVERRIDE`, the `application_user` property is ignored and the application user will be the owner of the application program executable file.

  If `resource_security` is set to `SECURE` or `WARN`, the application user will be the value of the `application_user` resource property; however, if `application_user` is unset or empty, the application user will be the owner of the application program executable file.

  If the `Tunable` attribute is not specified in the RTR file, the tunability of the property is `When_disabled`.

  Category

    Conditional/Optional

  Default

    The empty string

  Tunable

    When disabled

`Cheap_probe_interval` (`integer`)

  The number of seconds between invocations of a quick fault probe of the resource. This property is only created by the RGM and available to the cluster administrator 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 resource-type file, the `Tunable` value for the property is `When_disabled`.

  Category

    Conditional

  Default

    See above

  Tunable

    When disabled

`CheckActivePortInstances`(`boolean`)

  Determines whether a node participates in the scalable service, and receives client requests from the load balancer, when not all ports that are specified in the `Port_list` property have an active listening process. This property is only applicable to scalable services.

  Supported values include:

  - `FALSE` (default) – A node participates in the scalable service when at least one of its ports has an active listening process.

  - `TRUE` – A node participates in the scalable service only when all ports have an active listening process.

  Category

    Conditional/Optional

  Default

    False

  Tunable

    When disabled

`Conn_threshold (integer)`

  Maximum number of active connections or clients supported when `Round_robin` load distribution is enabled. TCP connections are considered active if the connection endpoint remains alive on the server node. UDP sessions are considered active if there is traffic flow within the UDP session active timeout window setting (see the `udp_session_timeout` cluster property).

  Category

    Optional

  Default

    10000

  Tunable

    WHEN_DISABLED

`Round_robin (boolean)`

  Assigns incoming requests to specific server nodes in a round-robin fashion taking into account the relative `load_balancing_weight`s value assigned to each node. Requests are assigned on a connection basis for resources with a non-sticky `load_balancing_policy` setting; otherwise, requests are assigned on a per-client IP address basis.

  `Round_Robin` should be enabled for resources that require deterministic load distribution of incoming requests where a small number of connections or clients are expected.

  A resource property, `Conn_threshold`, and a cluster property, `udp_session_timeout`, support the Round Robin scheme and can optionally be configured 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.

  Category

    Optional

  Default

    FALSE

  Tunable

    WHEN_DISABLED

Extension properties

  You declare resource-type properties in the RTR file. The RTR file defines the initial configuration of a data service when the cluster administrator registers the data service with Oracle Solaris Cluster software.

  For information about the individual attributes that you can set for extension properties, see the `property_attributes`(5) man page.

  You can specify that a cluster administrator can set an extension property on a per-node basis or for the entire cluster. However, you cannot specify (in the RTR file) that the cluster administrator can do the same for a system-defined property. System-defined properties implicitly can apply to all nodes or to particular nodes. Whether system-defined properties apply to all or particular nodes depends on the particular definition of the system-defined property.

  Category

    Conditional

  Default

    No default

  Tunable

    Depends on the particular property

`Failover_mode` (`enum`)

  Modifies the recovery actions that the RGM takes when a resource fails to start or 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.

    `NONE` indicates that the RGM is not to take any recovery action when one of the previously mentioned 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. However, if the resource group is being quiesced by the `clresourcegroup quiesce` subcommand, the node will not be rebooted even if the `Failover_mode` is `HARD` and a stop method fails. In this case, the resource will instead move to a STOP_FAILED state.

  `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 give overs that are initiated by the resource monitor.

    `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 give overs 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 data service is not failed over or 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 if 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`, if 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` 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`, if 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`, if 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 `scha_control()` 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 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`, if 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 to restart the resource or resource group or to fail over the group fail.

  Category

    Optional

  Default

    `NONE`

  Tunable

    Any time

`Global_zone_override` (`boolean`)

  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.

  Setting the `Global_zone_override` property to `FALSE` forces the resource methods to execute in the non-global zone 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`.

  Note - 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 you then set the `Global_zone_override` property to `TRUE` and the resource is switched offline, the stopping methods are executed in the global zone. Your method code must handle this possibility. If your method code does not handle this possibility, you must set the `Tunable` attribute to `When_disabled` or `At_creation` instead.

  Category

    Conditional/Optional

  Default

    `TRUE`

  Tunable

    At creation

`Load_balancing_policy` (`string`)

  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`. The set of ports is known at the time the application resources are configured. A given client (identified by the client's IP address) of the scalable service is always sent to the same node of the cluster.

  - `Lb_sticky_wild`. The port numbers are not known in advance but are dynamically assigned. A given client (identified by the 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 that IP address is coming.

  Category

    Conditional/Optional

  Default

    `Lb_weighted`

  Tunable

    At creation

`Load_balancing_weights` (`string_array`)

  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 distributed to the specified node. The fraction of load 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 1/4 of the load and node 2 receives 3/4. The empty string (“”), the default, sets a uniform distribution. Any node that is not assigned an explicit weight receives a default weight of 1. You can specify weight 0 to assign no load to a node.

  If the `Tunable` attribute is not specified in the resource-type file, the `Tunable` value for the property is `Anytime`. Changing this property revises the distribution for new connections only.

  Category

    Conditional/Optional

  Default

    Null

  Tunable

    Any time

`method_timeout` for each callback method (`integer`)

  A time lapse, in seconds, after which the RGM concludes that an invocation of the method has failed.

  Note - You cannot specify a maximum value for a method timeout (using the `Max` attribute). Likewise, you cannot specify a minimum value of zero (`Min=0`).

  Category

    Conditional/Optional

  Default

    3,600 (one hour) if the method itself is declared in the RTR file

  Tunable

    Any time

`Monitored_switch` (`enum`)

  You cannot directly set this property. Rather, it is set to `Enabled` or to `Disabled` by the RGM, either on a particular node or for the entire cluster. The RGM does so if the cluster administrator enables or disables the monitor with an administrative utility, either on a particular node or for the entire cluster. If disabled, the `Monitor_start` method is not called on the resource until monitoring is enabled again. If the resource does not have a monitor callback method, this property evaluates to `Disabled`.

  Category

    Query-only

  Default

    Enabled, if the resource type has monitoring methods, disabled otherwise

  Tunable

    See the description

`Network_resources_used` (`string_array`)

  A list of logical-hostname or shared-address resources on 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`.

  The RGM automatically creates this property if the `Scalable` property is declared in the RTR file. If the `Scalable` property is not declared in the RTR file, `Network_resources_used` is unavailable unless it is explicitly declared in the RTR file.

  If you do not assign a value to the `Network_resources_used` property, its value is updated automatically by the RGM, based on the setting of the resource-dependencies properties. You do not need to set this property directly. Instead, set the `Resource_dependencies`, `Resource_dependencies_offline_restart`, `Resource_dependencies_restart`, or `Resource_dependencies_weak` property. If per-node dependencies are specified, the derived value of the `Network_resources_used` property includes only those dependencies which are in effect on the local node. The value might differ on each node.

  To maintain compatibility with earlier releases of Oracle Solaris Cluster software, you can still set the value of the `Network_resources_used` property directly. If you set the value of the `Network_resources_used` property directly, the value of the `Network_resources_used` property is no longer derived from the settings of the resource-dependencies properties. If you add a resource name to the `Network_resources_used` property, the resource name is automatically added to the `Resource_dependencies` property as well. The only way to remove that dependency is to remove it from the `Network_resources_used` property. If you are not sure whether a network-resource dependency was originally added to the `Resource_dependencies` property or to the `Network_resources_used` property, remove the dependency from both properties. For example, the following command removes a dependency of resource `r1` upon network resource `r2`, regardless of whether the dependency was added to the `Network_resources_used` or `Resource_dependencies` property:

      # clresource set -p Network_resources_used-=r2 -p Resource_dependencies-=r2 r1

  For simplicity, avoid setting a value for the `Network_resources_used` property. Set only the resource dependency properties, and treat the `Network_resources_used` property as a read-only property.

  Category

    Conditional/Optional

  Default

    The empty list

  Tunable

    Any time

`Num_resource_restarts` on each cluster node (`integer`)

  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` command with the `RESOURCE_RESTART` argument

  - The `scha_control()` 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 give over 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.

  Category

    Query-only

  Default

    No default

  Tunable

    See description

`Num_rg_restarts` on each cluster node (`integer`)

  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` command with the `RESTART` argument

  - The `scha_control()` 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.

  Category

    Query-only

  Default

    No default

  Tunable

    See description

`On_off_switch` (`enum`)

  You cannot directly set this property. Rather, it is set to `Enabled` or to `Disabled` by the RGM, either on a particular node or for the entire cluster. The RGM does so if the cluster administrator enables or disables the resource with an administrative utility, either on a particular node or for the entire cluster. If disabled, a resource has no callbacks invoked until it is enabled again.

  Category

    Query-only

  Default

    Disabled

  Tunable

    See description

`Outgoing_Connection`(`boolean`)

  Specifies whether the scalable service uses the virtual network address (see `Network_resources_used` property) in initiating outgoing requests to servers outside the cluster. The load balancer ensures that any incoming replies are forwarded to the initiating node.

  Note - Only one node of the cluster can initiate requests to a given server at a time.

  This property is only applicable to scalable services with `Generic_Affinity` set to `TRUE` and`Load_balancing_policy` set to `LB_STICKY_WILD`. Supported values include:

  - `FALSE` (default) – The scalable service does not initiate outgoing requests to external servers by using the virtual network address that is specified in the `Network_resources_used` property.

  - `TRUE` – The scalable service initiates outgoing requests to external servers by using the virtual network address that is specified in the `Network_resources_used` property. The load balancer forwards incoming replies to the initiating node.

  Category

    Conditional/Optional

  Default

    False

  Tunable

    At creation

`Port_list` (`string_array`)

  A comma-separated 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`.

  Possible protocols that you can specify include:

  - `tcp`, for only TCP IPv4

  - `tcp6`, for both TCP IPv4 and TCP IPv6

  - `udp`, for only UDP IPv4

  - `udp6`, for both UDP IPv4 and UDP IPv6

  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 use with Oracle Solaris Cluster HA for Apache is described in the Oracle Solaris Cluster Data Service for Apache Guide.

  Category

    Conditional/Required

  Default

    No default

  Tunable

    Any time

`R_description` (`string`)

  A brief description of the resource.

  Category

    Optional

  Default

    The empty string

  Tunable

    Any time

`Resource_dependencies` (`string_array`)

  A list of resources in the same group or in different groups upon which this resource has a strong dependency. 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.

  By default in a resource group, application resources have an implicit strong resource dependency on network address resources.`Implicit_network_dependencies` in the `rg_properties`(5) man page 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 ({ }) or at-sign (@), to the resource name when you specify this property.

  `{ANY_NODE}`

    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.

  `{FROM_RG_AFFINITIES}`

    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}`.

  `{LOCAL_NODE}`

    Limits the specified dependency to a per-node basis. The behavior of the dependent is affected by the depended-on resource only on the same node. The dependent resource waits for the depended-on resource to start on the same node. The situation is similar for stopping and restarting.

    If the `{LOCAL_NODE}` dependent resource is in a failover (that is, single-mastered) resource group, and if the `{LOCAL_NODE}` dependency is unsatisfied on one node, the resource group might fail over to a different node on which the `{LOCAL_NODE}` dependency is satisfied, rather than remaining in the `Pending_online_blocked` state on the node where the dependency is unsatisfied.

  @nodename

    Specifies a `{LOCAL_NODE}` dependency which is limited to a particular node and has no effect on other nodes. This allows a resource to have different dependencies on each node of the cluster. The `nodename` is a node name or node ID.

    For example, the following list indicates a dependency on resource `res1` on node `node1` and a dependency on resource `res2` on node `node2`:

        res1@node1,res2@node2

    If the same dependency is applicable on multiple nodes, repeat the resource name with each node name. For example:

        myres@node1,myres@node2,myres@node3,...

  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.

  The `scha_resource_get`(1HA), `scha_resource_get`(3HA), and `scds_property_functions`(3HA) man pages document alternate query forms to obtain the dependency list with qualifiers or without qualifiers.

  Category

    Optional

  Default

    The empty list

  Tunable

    Any time

`Resource_dependencies_offline_restart` (`string_array`)

  A list of resources in the same group 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 ({ }) or at-sign (@), to the resource name when you specify this property.

  `{ANY_NODE}`

    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.

  `{FROM_RG_AFFINITIES}`

    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}`.

  `{LOCAL_NODE}`

    Limits the specified dependency to a per-node basis. The behavior of the dependent is affected by the depended-on resource only on the same node. The dependent resource waits for the depended-on resource to start on the same node. The situation is similar for stopping and restarting.

    If the `{LOCAL_NODE}` dependent resource is in a failover (that is, single-mastered) resource group, and if the `{LOCAL_NODE}` dependency is unsatisfied on one node, the resource group might fail over to a different node on which the `{LOCAL_NODE}` dependency is satisfied, rather than remaining in the `Pending_online_blocked` state on the node where the dependency is unsatisfied.

  @nodename

    Specifies a `{LOCAL_NODE}` dependency which is limited to a particular node and has no effect on other nodes. This allows a resource to have different dependencies on each node of the cluster. The `nodename` is a node name or node ID.

    For example, the following list indicates a dependency on resource `res1` on node `node1` and a dependency on resource `res2` on node `node2`:

        res1@node1,res2@node2

    If the same dependency is applicable on multiple nodes, repeat the resource name with each node name. For example:

        myres@node1,myres@node2,myres@node3,...

  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.

  The `scha_resource_get`(1HA), `scha_resource_get`(3HA), and `scds_property_functions`(3HA) man pages document alternate query forms to obtain the dependency list with qualifiers or without qualifiers.

  Category

    Optional

  Default

    The empty list

  Tunable

    Any time

`Resource_dependencies_restart` (`string_array`)

  A list of resources in the same group or in different groups upon which this resource has an restart dependency.

  This property works just as `Resource_dependencies` does, except that, if any resource in the restart dependency list is restarted, this resource is restarted. The restart of this resource occurs after the resource in the list comes back online.

  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_restart` 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 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.

  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 ({ }) or at-sign (@), to the resource name when you specify this property.

  `{LOCAL_NODE}`

    Limits the specified dependency to a per-node basis. The behavior of the dependent is affected by the depended-on resource only on the same node. The dependent resource waits for the depended-on resource to start on the same node. The situation is similar for stopping and restarting.

    If the `{LOCAL_NODE}` dependent resource is in a failover (that is, single-mastered) resource group, and if the `{LOCAL_NODE}` dependency is unsatisfied on one node, the resource group might fail over to a different node on which the `{LOCAL_NODE}` dependency is satisfied, rather than remaining in the `Pending_online_blocked` state on the node where the dependency is unsatisfied.

  `{ANY_NODE}`

    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.

  @nodename

    Specifies a `{LOCAL_NODE}` dependency which is limited to a particular node and has no effect on other nodes. This allows a resource to have different dependencies on each node of the cluster. The `nodename` is a node name or node ID.

    For example, the following list indicates a dependency on resource `res1` on node `node1` and a dependency on resource `res2` on node `node2`:

        res1@node1,res2@node2

    If the same dependency is applicable on multiple nodes, repeat the resource name with each node name. For example:

        myres@node1,myres@node2,myres@node3,...

  `{FROM_RG_AFFINITIES}`

    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.

  The `scha_resource_get`(1HA), `scha_resource_get`(3HA), and `scds_property_functions`(3HA) man pages document alternate query forms to obtain the dependency list with qualifiers or without qualifiers.

  Category

    Optional

  Default

    The empty list

  Tunable

    Any time

`Resource_dependencies_weak` (`string_array`)

  A list of resources in the same group or in different groups upon which this resource has a weak dependency. A weak dependency determines the order of method calls within the group. The RGM calls the `Start` methods of the resources in this list before the `Start` method of this resource. The RGM calls the `Stop` methods of this resource before the `Stop` methods of those in the list. The resource can still start if those in the list fail to start or remain offline.

  If this resource and a resource in its `Resource_dependencies_weak` list start concurrently, the RGM waits until the resource in the list starts before the RGM starts this resource. If the resource in the list does not start (for example, if the resource group for the resource in the list remains offline or the resource in the list is in a `Start_failed` state), this resource starts. This resource's resource group might enter a `Pending_online_blocked` state temporarily as resources in the this resource's `Resource_dependencies_weak` list start. When all resources in the list have started or failed to start, this resource starts and its group reenters the `Pending_online` 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.

  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 ({ }) or at-sign (@), to the resource name when you specify this property.

  `{LOCAL_NODE}`

    Limits the specified dependency to a per-node basis. The behavior of the dependent is affected by the depended-on resource only on the same node. The dependent resource waits for the depended-on resource to start on the same node. The situation is similar for stopping and restarting.

    If the `{LOCAL_NODE}` dependent resource is in a failover (that is, single-mastered) resource group, and if the `{LOCAL_NODE}` dependency is unsatisfied on one node, the resource group might fail over to a different node on which the `{LOCAL_NODE}` dependency is satisfied, rather than remaining in the `Pending_online_blocked` state on the node where the dependency is unsatisfied.

  `{ANY_NODE}`

    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.

  @nodename

    Specifies a `{LOCAL_NODE}` dependency which is limited to a particular node and has no effect on other nodes. This allows a resource to have different dependencies on each node of the cluster. The `nodename` is a node name or node ID.

    For example, the following list indicates a dependency on resource `res1` on node `node1` and a dependency on resource `res2` on node `node2`:

        res1@node1,res2@node2

    If the same dependency is applicable on multiple nodes, repeat the resource name with each node name. For example:

        myres@node1,myres@node2,myres@node3,...

  `{FROM_RG_AFFINITIES}`

    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.

  The `scha_resource_get`(1HA), `scha_resource_get`(3HA), and `scds_property_functions`(3HA) man pages document alternate query forms to obtain the dependency list with qualifiers or without qualifiers.

  Category

    Optional

  Default

    The empty list

  Tunable

    Any time

`Resource_name` (`string`)

  The name of the resource instance. Must be unique within the cluster configuration and cannot be changed after a resource has been created.

  Category

    Required

  Default

    No default

  Tunable

    Never

`Resource_project_name` (`string`)

  The Oracle Solaris project name (see `projects`(1)) associated with the resource. Use this property to apply Solaris resource management features such as CPU shares and resource pools to cluster data services. When the RGM brings resources online, it launches the related processes under this project name. If this property is not specified, the project name will be 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 Oracle Solaris 11.1 Administration: Oracle Solaris Zones, Oracle Solaris 10 Zones, and Resource Management).

  Note - Changes to this property take affect the next time the resource is started.

  Category

    Optional

  Default

    Null

  Tunable

    Any time

  Valid value

    Any valid Oracle Solaris project name, or null

`Resource_state` on each cluster node (`enum`)

  The RGM-determined state of the resource on each cluster node. Possible states include: `Online`, `Offline`, `Start_failed`, `Stop_failed`, `Monitor_failed`, `Online_not_monitored`, `Starting`, and `Stopping`.

  `Online`

    The starting methods (`Prenet_start`, `Start`, and `Monitor_start`) have executed successfully on the resource on this node.

  `Offline`

    The resource has not yet started for the first time on this node, or the stopping methods (`Monitor_stop`, `Stop`, and `Postnet_stop`, as applicable to the particular resource) have executed successfully on the resource on this node.

  `Start_failed`

    A `Prenet_start` or `Start` method failed on the resource on this node. `Start_failed` means that the method exited with a nonzero exit status or timed out. The service that is represented by the resource might or might not actually have started on this node.

  `Stop_failed`

    A `Monitor_stop`, `Stop`, or `Postnet_stop` method failed on the resource on this node. `Stop_failed` means that the method exited with a nonzero exit status or timed out. The service that is represented by the resource might or might not actually have stopped on this node.

    When a resource enters this state, the resource-group state becomes `Error_stop_failed` and requires you to intervene. `Error_stop_failed` is described in more detail in the `rg_properties`(5) man page.

  `Monitor_failed`

    The resource successfully executed its `Prenet_start` or `Start` methods (as applicable to the specific resource type). However, the resources' `Monitor_start` method exited with a nonzero exit status or timed out. The resource monitor might or might not actually have started on this node.

  `Online_not_monitored`

    The resource successfully executed its `Prenet_start` or `Start` methods (as applicable to the specific resource type). The `Monitor_start` method has not yet been executed on the resource. A resource that is unmonitored (that is, for which there is no `Monitor_start` method, or for which monitoring has been disabled) remains in this state when the resource group goes to `Online` state.

  `Starting`

    The resource is running the `Prenet_start` or `Start` method in an attempt to go online.

  `Stopping`

    The resource is running the `Start` or `Postnet_stop` method in an attempt to go offline.

  You cannot configure this property.

  Category

    Query-only

  Default

    No default

  Tunable

    Never

`Retry_count` (`integer`)

  The number of times 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 do one of the following:

  - Allow the resource group to remain on the current primary, 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 resource-type file, the `Tunable` value for the property is `When_disabled`.

  If you specify a negative value for this property, the monitor attempts to restart the resource an unlimited number of times.

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

  Category

    Conditional

  Default

    See above

  Tunable

    When disabled

`Retry_interval` (`integer`)

  The number of seconds in 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 made 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 resource-type file, the `Tunable` value for the property is `When_disabled`.

  Note - If the `Retry_interval` property is not declared, the call to `scha_resource_get (num_*_restarts)` fails with exit 13 (`SCHA_ERR_RT`).

  Category

    Conditional

  Default

    See above

  Tunable

    When disabled

`Scalable` (`boolean`)

  Indicates whether the resource is scalable, that is, whether the resource uses the networking load balancing features of Oracle Solaris Cluster software.

  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 is not permitted to 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, if you want, because these properties can be useful in a non-scalable service as well as in a scalable service.

  You use the `Scalable` resource property in combination with the `Failover` resource-type property, as follows:

  `Failover` | `Scalable` | Description
  --- | --- | ---
  `True` | `True` | Do not specify this illogical combination.
  `True` | `False` | Specify this combination for a failover service.
  `False` | `True` | Specify this combination for a scalable service that uses a `SharedAddress` resource for network load balancing.The Oracle Solaris Cluster Concepts Guide describes `SharedAddress` in more detail.
  `False` | `False` | Use this combination to configure a multi-master service that does not use network load balancing.

  The description for the `Failover` resource-type property in the `rt_properties`(5) man page contains additional information.

  Category

    Optional

  Default

    See above

  Tunable

    At creation

`Status` on each cluster node (`enum`)

  Set by the resource monitor. Possible values are: `Online`, `Degraded`, `Faulted`, `Unknown`, and `Offline`. The RGM sets the value to `Online` when the resource is started, if it is not already set by the `Start` (or `Prenet_start`) method. The RGM sets the value to `Offline` when the resource is stopped, if it is not already set by the `Stop` (or `Postnet_stop`) method.

  Category

    Query-only

  Default

    No default

  Tunable

    Only by using the `scha_resource_setstatus` command

`Status_msg` on each cluster node (`string`)

  Set by the resource monitor at the same time as the `Status` property. The RGM sets it to the empty string when the resource is brought `Offline`, if it was not already set by the `Stop` (or `Postnet_stop`) method.

  Category

    Query-only

  Default

    No default

  Tunable

    Only by using the `scha_resource_setstatus`

`Thorough_probe_interval` (`integer`)

  The number of seconds between invocations of a high-overhead fault probe of the resource. This property is created by the RGM and 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 resource-type file, the `Tunable` value for the property is `When_disabled`.

  Category

    Conditional

  Default

    No default

  Tunable

    When disabled

`Type` (`string`)

  An instance's resource type.

  Category

    Required

  Default

    No default

  Tunable

    Never

`Type_version` (`string`)

  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 may appear as a suffix of the resource-type name. When a resource is edited, the `Type_version` may be changed to a new value.

  Category

    See above

  Default

    None

  Tunable

    Tunability is derived from the following:

    - The current version of the resource type.

    - The `#$upgrade_from` directive in the resource-type registration file (see the `rt_reg`(4) man page).

`UDP_affinity` (`boolean`)

  If true, all UDP traffic from a given client is sent 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` (the default value).

  This property is only used for scalable services.

  Category

    Conditional/Optional

  Default

    False

  Tunable

    When disabled

`Weak_affinity` (`boolean`)

  If true, enable the weak form of the client affinity. This allows connections from a given client to be sent to the same server node except when a server listener starts (for example, due to a fault monitor restart, a resource failover or switchover, or a node rejoining a cluster after failing) or when `load_balancing_weights` for the scalable resource changes due to an administration 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.

  Category

    Conditional/Optional

  Default

    False

  Tunable

    When disabled

## See Also

`projects`(1), `clresource`(1CL), `clresourcegroup`(1CL), `clresourcetype`(1CL), `scha_control`(1HA), `scha_resource_get`(1HA), `scha_resource_setstatus`(1HA), `scha_control`(3HA), `scha_resource_get`(3HA), `scds_property_functions`(3HA), `rt_reg`(4), `property_attributes`(5), `rg_properties`(5), `rt_properties`(5)

Oracle Solaris Cluster Concepts Guide, Oracle Solaris 11.1 Administration: Oracle Solaris Zones, Oracle Solaris 10 Zones, and Resource Management.

Copyright © 2000, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |