Freeing Node Resources by Offloading Noncritical Resource Groups
Note –
The use of strong negative affinities between resource groups provides a simpler method for offloading noncritical resource groups. For more information, see Distributing Online Resource Groups Among Cluster Nodes.
Prioritized Service Management (RGOffload) allows your cluster to automatically free a node's resources for critical data services. RGOffload is used when the startup of a critical failover data service requires a Non-Critical, scalable or failover data service to be brought offline. RGOffload is used to offload resource groups containing noncritical data services.
Note –
The critical data service must be a failover data service. The data service to be offloaded can be a failover or scalable data service.
How to Set Up an RGOffload Resource
-
Become superuser on a cluster member.
-
Determine whether the RGOffload resource type is registered.
The following command prints a list of resource types.
# scrgadm -p|egrep SUNW.RGOffload
-
If needed, register the resource type
.
# scrgadm -a -t SUNW.RGOffload
-
Set the Desired_primaries to zero in each resource group to be offloaded by the RGOffload resource.
# scrgadm -c -g offload-rg -y Desired_primaries=0
-
Add the RGOffload resource to the critical failover resource group and set the extension properties.
Do not place a resource group on more than one resource's rg_to_offload list. Placing a resource group on multiple rg_to_offload lists may cause the resource group to be taken offline and brought back online repeatedly.
See Configuring RGOffload Extension Properties for extension property descriptions.
# scrgadm -aj rgoffload-resource \ -t SUNW.RGOffload -g critical-rg \ -x rg_to_offload=offload-rg-1, offload-rg-2, ... \ -x continue_to_offload=TRUE \ -x max_offload_retry=15
Note –Extension properties other than rg_to_offload are shown with default values here. rg_to_offload is a comma-separated list of resource groups that are not dependent on each other. This list cannot include the resource group to which the RGOffload resource is being added.
-
Enable the RGOffload resource.
# scswitch -ej rgoffload-resource
-
Set the dependency of the critical failover resource on the RGOffload resource.
# scrgadm -c -j critical-resource \ -y Resource_dependencies=rgoffload-resource
Resource_dependencies_weak may also be used. Using Resource_dependencies_weak on the RGOffload resource type will allow the critical failover resource to start up even if errors are encountered during offload of offload-rg.
-
Bring the resource group to be offloaded online.
# scswitch -z -g offload-rg, offload-rg-2, ... -h [nodelist]
The resource group remains online on all nodes where the critical resource group is offline. The fault monitor prevents the resource group from running on the node where the critical resource group is online.
Because Desired_primaries for resource groups to be offloaded is set to 0 (see Step 4), the “-Z” option will not bring these resource groups online.
-
If the critical failover resource group is not online, bring it online.
# scswitch -Z -g critical-rg
SPARC: Example – Configuring an RGOffload Resource
This example describes how to configure an RGOffload resource (rgofl), the critical resource group that contains the RGOffload resource (oracle_rg), and scalable resource groups that are offloaded when the critical resource group comes online (IWS-SC, IWS-SC-2). The critical resource in this example is oracle-server-rs.
In this example, oracle_rg, IWS-SC, and IWS-SC-2 can be mastered on any node of cluster “triped”, phys-triped-1, phys-triped-2, phys-triped-3.
[Determine whether the SUNW.RGOffload resource type is registered.] # scrgadm -p|egrep SUNW.RGOffload [If needed, register the resource type.] # scrgadm -a -t SUNW.RGOffload [Set the Desired_primaries to zero in each resource group to be offloaded by the RGOffload resource.] # scrgadm -c -g IWS-SC-2 -y Desired_primaries=0 # scrgadm -c -g IWS-SC -y Desired_primaries=0 [Add the RGOffload resource to the critical resource group and set the extension properties.] # scrgadm -aj rgofl -t SUNW.RGOffload -g oracle_rg \ -x rg_to_offload=IWS-SC,IWS-SC-2 -x continue_to_offload=TRUE \ -x max_offload_retry=15 [Enable the RGOffload resource.] # scswitch -ej rgofl [Set the dependency of the critical failover resource to the RGOffload resource.] # scrgadm -c -j oracle-server-rs -y Resource_dependencies=rgofl [Bring the resource groups to be offloaded online on all nodes.] # scswitch -z -g IWS-SC,IWS-SC-2 -h phys-triped-1,phys-triped-2,phys-triped-3 [If the critical failover resource group is not online, bring it online.] # scswitch -Z -g oracle_rg |
Configuring RGOffload Extension Properties
Typically, you use the command line scrgadm -x parameter=value to configure extension properties when you create the RGOffload resource. See Appendix A, Standard Properties for details on all of the Sun Cluster standard properties.
Table 2–3 describes extension properties that you can configure for RGOffload. The Tunable entries indicate when you can update the property.
Table 2–3 RGOffload Extension Properties|
Name/Data Type |
Default |
|---|---|
|
rg_to_offload (string) |
A comma-separated list of resource groups that need to be offloaded on a node when a critical failover resource group starts up on that node. This list should not contain resource groups that depend upon each other. This property has no default and must be set.
RGOffload does not check for dependency loops in the list of resource groups set in the rg_to_offload extension property. For example, if resource group RG-B depends in some way on RG-A, then both RG-A and RG-B should not be included in rg_to_offload.
Default: None Tunable: Any time |
|
continue_to_offload (Boolean) |
A Boolean to indicate whether to continue offloading the remaining resource groups in the rg_to_offload list after an error in offloading a resource group occurs.
This property is only used by the START method.
Default: True Tunable: Any time |
|
max_offload_retry (integer) |
The number of attempts to offload a resource group during startup in case of failures due to cluster or resource group reconfiguration. There is an interval of 10 seconds between successive retries.
Set the max_offload_retry so that
(the number of resource groups to be offloaded * max_offload_retry * 10 seconds)
is less than the Start_timeout for the RGOffload resource. If this number is close to or more than the Start_timeout number, the START method of RGOffload resource may time out before maximum offload attempts are completed.
This property is only used by the START method.
Default: 15 Tunable: Any time |
Fault Monitor
The Fault Monitor probe for RGOffload resource is used to keep resource groups specified in the rg_to_offload extension property offline on the node mastering the critical resource. During each probe cycle, Fault Monitor verifies that resource groups to be offloaded (offload-rg) are offline on the node mastering the critical resource. If the offload-rg is online on the node mastering the critical resource, the Fault Monitor attempts to start offload-rg on nodes other than the node mastering the critical resource, thereby bringing offload-rg offline on the node mastering the critical resource.
Because desired_primaries for offload-rg is set to 0, offloaded resource groups are not restarted on nodes that become available later. Therefore, the RGOffload Fault Monitor attempts to start up offload-rg on as many primaries as possible, until maximum_primaries limit is reached, while keeping offload-rg offline on the node mastering the critical resource.
RGOffload attempts to start up all offloaded resource groups unless they are in the MAINTENANCE or UNMANAGED state. To place a resource group in an UNMANAGED state, use the scswitch command.
# scswitch -u -g resourcegroup |
The Fault Monitor probe cycle is invoked after every Thorough_probe_interval.
- © 2010, Oracle Corporation and/or its affiliates