Skip Navigation Links
Exit Print View
| Oracle Solaris Cluster Data Services Developer's Guide Oracle Solaris Cluster 4.1

Search Scope:

- This Document
- Entire Library

## Implementing a Scalable Resource

A scalable resource can be online on more than one node simultaneously. Scalable resources include data services such as Oracle Solaris Cluster HA for Oracle GlassFish Server and Oracle Solaris Cluster HA for Apache.

The RGM provides a number of properties that support the implementation of a scalable resource.

Set the Boolean `Failover` resource type property to `FALSE`, to allow the resource to be configured in a resource group that can be online on more than one node at a time.

The `Scalable` resource property determines if the resource uses the cluster shared address facility. Set this property to `TRUE` because a scalable service uses a shared address resource to make the multiple instances of the scalable service appear as a single service to the client.

The `RG_mode` property enables the cluster administrator to identify a resource group as failover or scalable. If `RG_mode` is `SCALABLE`, the RGM allows `Maximum_primaries` to be assigned a value greater than 1. The resource group can be mastered by multiple nodes simultaneously. The RGM allows a resource whose `Failover` property is `FALSE` to be instantiated in a resource group whose `RG_mode` is `SCALABLE`.

The cluster administrator creates a scalable resource group to contain scalable service resources and a separate failover resource group to contain the shared address resources upon which the scalable resource depends.

The resource group that contains the scalable service resource has an implicit dependency on the resource group that contains the shared address resource. This dependency ensures that the network address is brought up before the scalable data service is started. The cluster administrator need not set any explicit dependency for this.

When you declare the `Scalable` property in the RTR file for a resource, the RGM automatically creates the following set of scalable properties for the resource.

`Network_resources_used`

  Identifies the 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.

`Load_balancing_policy`

  Specifies the load-balancing policy for the resource. You can explicitly set the policy in the RTR file (or allow the default `LB_WEIGHTED`). In either case, the cluster administrator can change the value when he or she creates the resource (unless you set `Tunable` for `Load_balancing_policy` to `NONE` or `FALSE` in the RTR file). These are the legal values that you can use:

  `LB_WEIGHTED`

    The load is distributed among various nodes according to the weights that are 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 (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 it is coming.

  For a scalable service with a `Load_balancing_policy` of `LB_STICKY` or `LB_STICKY_WILD`, changing `Load_balancing_weights` while the service is online can cause existing client affinities to be reset. In this case, a different node might service a subsequent client request, even if the client had been previously serviced by another node in the cluster.

  Similarly, starting a new instance of the service on a cluster might reset existing client affinities.

`Load_balancing_weights`

  Specifies the load to be sent to each node. The format is `weight@node,weight@node`. 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 of active instances. 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.

`Port_list`

  Identifies the ports on which the application is listening. This property defaults to the empty string. You can provide a list of ports in the RTR file. Otherwise, the cluster administrator must provide the actual list of ports when creating the resource.

You can create a data service that the cluster administrator can configure to be either scalable or failover. To do so, declare both the `Failover` resource type property and the `Scalable` resource property as `FALSE` in the data service's RTR file. Specify the `Scalable` property to be tunable at creation.

The `Failover` property value `FALSE` allows the resource to be configured in a scalable resource group. The cluster administrator can enable shared addresses by changing the value of `Scalable` to `TRUE` when he or she creates the resource, to create a scalable service.

On the other hand, even though `Failover` is set to `FALSE`, the cluster administrator can configure the resource in a failover resource group to implement a failover service. The cluster administrator does not change the value of `Scalable`, which is `FALSE`. To support this scenario, you should provide a check in the `Validate` method on the `Scalable` property. If `Scalable` is `FALSE`, verify that the resource is configured into a failover resource group.

The Oracle Solaris Cluster Concepts Guide contains additional information about scalable resources.

### Validation Checks for Scalable Services

Whenever you create or update a resource with the scalable property set to `TRUE`, the RGM validates various resource properties. If you do not configure the properties correctly, the RGM rejects the attempted update or creation.

The RGM performs the following checks:

- The scalable resource must declare a resource dependency on one or more existing shared address resources.

  Every node in the `Nodelist` for the resource group that contains the scalable resource must appear in the `NetIfList` property of the `SharedAddress` resource.

  The `Nodelist` of the scalable resource group must be a subset of, or the same as, the combination, or union, of the following two node lists:

  - The `Nodelist` for the resource group that contains the `SharedAddress` resource.

  - The `Nodelist` that is listed in the `AuxNodeList` property for the `SharedAddress` resource.

  Note - If you include all nodes in the node list for the scalable resource's resource group in the node list for the shared address' resource group, you do not need to set the `AuxNodeList` property.

- The `Port_list` property must not be empty and must contain a list of port-protocol pairs. You must append a slash (`/`) to each port number, followed by the protocol that is being used by that port. For example:

      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

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