Implementing a Scalable Resource

A scalable resource is a resource that can be online on more than one node simultaneously. Scalable resources include data services such as Sun Cluster HA for iPlanet Web Server and HA-Apache.

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

The boolean resource property Scalable identifies a resource as scalable (TRUE) or not (FALSE). A resource whose Scalable property is TRUE is said to be in in scalable mode. A resource whose Scalable property is FALSE is said to be in failover mode.

If 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 used by this resource. This property defaults to the empty string so the cluster administrator must provide the actual list of shared addresses the scalable service uses when creating the resource.

• 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 creating the resource (unless you set tunability for Load_balancing_policy to NONE or FALSE in the RTR file). Legal values are:

  • LB_WEIGHTED - 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 (identified by the client's IP address), that connects to an IP address of a wildcard stick service, is always sent to the same cluster node regardless of the port number it is coming to.

  In case of scalable services, for those with Load_balancing_policy LB_STICKY or LB_STICKY_WILD, changing Load_balancing_weights while the service is online can cause existing client affinities to be reset. In that 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, where weight is an integer reflecting 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 of active instances. For example, 1@1,3@2 specifies that node 1 receives 1/4 of the load and node 2 receives 3/4.

• Port_list - identifies the ports on which the server 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 can run in both scalable and failover mode. To do so, declare the Scalable resource property in the data service's RTR file. You can declare it without a value (the default value is FALSE), or explicitly set its value to FALSE. By default, this resource runs in failover mode. However, the cluster administrator can make the resource run in scalable mode by changing the value of Scalable to TRUE with an administrative utility.

The cluster administrator creates a scalable resource group to contain scalable service resources. Scalable resources make use of shared address resources, which allow the multiple instances of a scalable service to appear as a single service to the client. The shared address resources upon which a scalable resource depends must reside in a separate failover resource group.

The cluster administrator uses the RG_dependencies resource group property to specify the order in which resource groups are brought online and offline on a node. This ordering is important for a scalable service because the scalable resources and the shared address resources upon which they depend are in different resource groups. A scalable data service requires that its network address (shared address) resources be configured up before it is started. Therefore, the administrator must set the RG_dependencies property to include the resource group containing the shared address resources.

The RG_mode property allows the cluster administrator to identify a resource group as failover or scalable. If RG_mode is SCALABLE, the RGM allows Maximum_primaries to have a value greater than 1, meaning the group can be mastered by multiple nodes simultaneously. The RGM does not allow a resource whose Failover property is TRUE to be instantiated in a resource group whose RG_mode is SCALABLE.

See Sun Cluster 3.0 Concepts for additional information regarding scalable resources.

Validation Checks For Scalable Services

Whenever a scalable resource is created or updated, the RGM validates various resource properties. If the properites are not configured correctly, the RGM rejects the attempted update or creation. The RGM performs the following checks:

• The Network_resources_used property must be non-empty and contain the names of existing shared address resources. Every node in the Nodelist of the resource group containing the scalable resource must appear in either the NetIfList property or AuxNodeList property of each of the named shared address resources.

• The RG_dependencies property of the resource group that contains the scalable resource must include the resource groups of all shared address resources listed in the scalable resource's Network_resources_used property.

• The Port_list property must be non-empty and contain a list of port-protocol pairs such that protocol is either tcp or udp. For example, .

  Port_list=80/tcp,40/udp