Sun Cluster Data Services Planning and Administration Guide for Solaris OS

Upgrading a Resource Type

As newer versions of resource types are released, you will want to install and register the upgraded resource type. You may also want to upgrade your existing resources to the newer resource type versions. This section provides the following procedures for installing and registering an upgraded resource type and for upgrading an existing resource to a new resource type version.

How to Install and Register an Upgrade of a Resource Type

This procedure can also be performed using the Resource Group option of scsetup. For information on scsetup, see the scsetup(1M) man page.

Install the resource type upgrade package on all cluster nodes.

Note –
If the resource type package is not installed on all of the nodes, then an additional step will be required (Step 3).

The upgrade documentation will indicate whether it is necessary to boot a node in non-cluster mode to install the resource type upgrade package. To avoid down time, add the new package in a rolling upgrade fashion on one node at a time, while the node is booted in non-cluster mode and the other nodes are in cluster mode.

Register the new resource type version.
scrgadm -a -t resource_type -f path_to_new_RTR_file
The new resource type will have a name in the following format.
vendor_id.rtname:version
Use scrgadm -p or scrgadm -pv (verbose) to display the newly registered resource type.

If the new resource type is not installed on all of the nodes, set the Installed_nodes property to the nodes on which it is actually installed.
# scrgadm -c -t resource_type -h installed_node_list

A new version of a resource type may differ from a previous version in the following ways.

The settings of the resource type properties may change.
The set of declared resource properties, including standard and extension properties, may change.
The attributes of resource properties, such as default, min, max, arraymin, arraymax, or tunability may change.
The set of declared methods may differ.
The implementation of methods and/or monitor may change.

How to Migrate Existing Resources to a New Version of the Resource Type

This procedure can also be performed using the Resource Group option of scsetup. For information on scsetup, see the scsetup(1M) man page.

The existing resource type version and the changes in the new version determine how to migrate to the new version type. The resource type upgrade documentation will tell you whether the migration can occur. If a migration is not supported, consider deleting the resource and replacing it with a new resource of the upgraded version or leaving the resource at the old version of the resource type.

When you migrate the existing resource, the following values may change.

Default property values

If an upgraded version of the resource type declares a new default value for a defaulted property, the new default value will be inherited by existing resources.

The new resource type version's VALIDATE method checks to make sure that existing property settings are appropriate. If the settings are not appropriate, edit the properties of the existing resource to appropriate values. To edit the properties, see Step 3 .

Resource type name

The RTR file contains the following properties that are used to form the fully qualified name of the resource type.

Vendor_id
Resource_type
RT_Version

When you register the upgraded version of the resource type, its name will be stored as vendor_id.rtname:version. A resource that has been migrated to a new version will have a new Type property, composed of the properties listed above.

Resource type_version property

The standard resource property Type_version stores the RT_Version property of a resource's type. The Type_Version property does not appear in the RTR file. Edit the Type_Version property using the following command.

scrgadm -c -j resource -y Type_version=new_version

Before migrating an existing resource to a new version of the resource type, read the upgrade documentation accompanying the new resource type to determine whether the migration can take place.

The documentation will specify when the migration must take place.
- Any time
- When the resource is unmonitored
- When the resource is offline
- When the resource is disabled
- When the resource group is unmanaged
Note –
After migrating a resource that can be migrated at any time, the resource probe might not display the correct resource type version. In this situation, disable and re-enable the resource's fault monitor to ensure that the resource probe displays the correct resource type version.

If the migration is not supported, you must delete the resource and replace it with a new resource of the upgraded version, or leave the resource at the old version of the resource type.

For each resource of the resource type that is to be migrated, change the state of the resource or its resource group to the appropriate state as dictated by the upgrade documentation.

For example, if the resource needs to be unmonitored
scswitch -M -n -j resource
If the resource needs to be offline
scswitch -n -j resource
If the resource needs to be disabled
scswitch -n -j resource
If the resource group needs to be unmanaged
scsswitch -n -j resource-group scswitch -F -g resource_group scswitch -u -g resource_group

For each resource of the resource type that is to be migrated, edit the resource, changing its Type_version property to the new version.
scrgadm -c -j resource -y Type_version=new_version \ -x extension_property=new_value -y extension_property=new_value
If necessary, edit other properties of the same resource to appropriate values in the same command by adding additional -x or -y options on the command line.

Restore the previous state of the resource or resource group by reversing the command typed in Step 2.

For example, to make the resource monitored again
scswitch -M -e -j resource
To re-enable the resource
scswitch -e -j resource
To make the resource group managed and online
scswitch -o -g resource_group scswitch -Z -g resource_group

Example 1 – Migrating an Existing Resource to a New Resource Type Version

This example shows the migration of an existing resource to a new resource type version. Note that the new resource type package contains methods located in new paths. Because the methods will not be overwritten during the installation, the resource does not need to be disabled until after the upgraded resource type is installed.

This examples assumes the following.

New resource type version is 2.0
Tunability from previous version is “when_offline”
Resource name is “myresource”
Resource type name is “myrt”
New RTR file is in /opt/XYZmyrt/etc/XYZ.myrt
There are no dependencies on the resource to be migrated
The resource to be migrated can be taken offline while leaving the containing resource group online

(Install the new package on all nodes according to vendor's directions.)
# scrgadm -a -t myrt -f /opt/XYZmyrt/etc/XYZ.myrt
# scswitch -n -j myresource
# scrgadm -c -j myresource -y Type_version=2.0
# scswitch -e -j myresource

Example 2 – Migrating an Existing Resource to a New Resource Type Version

This example shows the migration of an existing resource to a new resource type version. Note that the new resource type package contains only the monitor and RTR file. Because the monitor will be overwritten during installation, the resource must be disabled before the upgraded resource type is installed.

This example assumes the following.

New resource type version is 2.0
Tunability from previous version is “when_unmonitored”
Resource name is “myresource”
Resource type name is “myrt”
New RTR file is in /opt/XYZmyrt/etc/XYZ.myrt

# scswitch -M -n -j myresource
(Install the new package according to vendor's directions.)
# scrgadm -a -t myrt -f /opt/XYZmyrt/etc/XYZ.myrt
# scrgadm -c -j myresource -y Type_version=2.0
# scswitch -M -e -j myresourcee