Changing the RT_Version in an RTR file
Change the RT_Version string in an RTR file whenever the contents of the RTR file changes. The value of this property must make it obvious which is the newer version of the resource type and which is the older. There is no need to change the RT_Version string if there are no changes to the RTR file.
Resource Type Names in Earlier Versions of Sun Cluster
Resource type names in Sun Cluster 3.0 did not contain the version suffix:
vendor_id.resource_name |
A resource type that was originally registered under Sun Cluster 3.0 continues to have a name of this form even after you upgrade the clustering software to Sun Cluster 3.1. Similarly, a resource type whose RTR file is missing the #$upgrade directive is given a Sun Cluster 3.0 format name, without the version suffix, if the RTR file is registered on a cluster running Sun Cluster 3.1 software.
You can register RTR files with the #$upgrade or #$upgrade_from directive in Sun Cluster 3.0, but, migrating existing resources to new resource types in Sun Cluster 3.0 is not supported.
Resource Type_version Property
The standard resource property Type_version stores the RT_Version property of a resource's type. This property does not appear in the RTR file. The system administrator edits this property value by using the following command:
scrgadm -c -j resource -y Type_version=new_version |
This property's tunability is derived from:
The current version of the resource type
The #$upgrade_from directives in the RTR file
Use the following tunability values in the #$upgrade_from directives:
- Anytime
If there are no restrictions on when the resource can be upgraded. The resource can be fully online.
- When_unmonitored
If the new resource type version's Update, Stop, Monitor_check, and Postnet_stop methods are known to be compatible with older resource type version's starting methods (Prenet_stop and Start), and if the new resource type version's Fini method is known to be compatible with the Init method of older versions. This scenario requires only that the resource monitor program be stopped before the upgrade
- When_offline
If the new resource type version's Update, Stop, Monitor_check, or Postnet_stop methods are known not to be compatible with older resource type version's starting methods (Prenet_stop and Start) but are known to be compatible with the Init method of older versions, the resource must be offline when the type upgrade is applied to it.
- When_disabled
Similar to When_offline. However, this tunability value imposes the stronger condition that the resource be disabled.
- When_unmanaged
If the new resource type version's Fini method is not compatible with the Init method of older versions. This tunability value requires the existing resource group to be switched to the unmanaged state before you can upgrade the resource.
- At_creation
If resources cannot be upgraded to the new resource type version. Only new resources of the new version can be created.
The tunability of At_creation means that the resource type developer can prohibit the migration of an existing resource to the new type. In this case, the system administrator must delete and recreate the resource. This is equivalent to declaring that the resource's version can only be set at creation time.
Migrating a Resource to a Different Version
An existing resource takes on the new resource type version when the system administrator edits the Type_version property of the resource. This follows the same conventions that are used to edit other resource properties, except that some information will be derived or taken from the new resource type version instead of the current version:
Resource property attributes for all properties such as min, max, arraymin, arraymax, default, and tunability are taken from the new resource type version
The tunability applicable to the Type_version property is taken from the #$upgrade_from directives in the RTR file and the RT_version property of the resource type of the existing resource. This tunability is unlike the tunability described in property_attributes(5).
The Validate method for the new resource type version will be applied. This ensures that the property attributes are valid for the new resource type. If the existing resource property attributes do not satisfy the validation conditions of the new resource type version, the system administrator has to provide valid values for such properties on the scrgadm command line. This can occur if the newer resource type version starts to use a property that was not declared in the earlier version and which does not have a default. It might also occur if the existing resource already has a property which was assigned a value that is invalid for the newer resource type version.
Resource properties that were declared in an older version of the resource type can be undeclared in the newer version. When the resource is migrated to the newer version, the property will be deleted from the resource.
Note - The Validate method can query the current Type_version of the resource (using scha_resource_get) as well as the new Type_version (which is passed on the Validate command line). Therefore, Validate can rule out upgrades from unsupported versions.
Upgrading and Downgrading a Resource Type
The section "Upgrading a Resource Type" in Sun Cluster 3.1 Data Service Planning and Administration Guide contains additional information about upgrading or migrating a resource type.
How to Upgrade a Resource Type
Read the upgrade documentation for the new resource type to find out the resource type changes and resource tunability constraints.
Install the resource type upgrade package on all cluster nodes.
The recommended practice for installing new resource type packages is in a rolling upgrade fashion: the pkgadd occurs while the node is booted in non-cluster mode.
There are scenarios in which it would be possible to install new resource type packages on a node in cluster mode:
If resource type package installation leaves the method code unchanged and only updates the monitor, then it is necessary to stop monitoring on all resources of that type during the installation.
If resource type package installation leaves both the method and monitor code unchanged then it is not necessary to stop monitoring on the resource during the installation, because the installation is only putting a new RTR file on the disk.
Register the new resource type version using the scrgadm (or equivalent) command, referencing the RTR file of the upgrade.
The RGM creates a new resource type whose name is of the form
vendor_id.resource_type:version
If the resource type upgrade is installed on only a subset of the nodes, you must set the Installed_nodes property of the new resource type to the nodes on which it is actually installed.
When a resource takes on the new type (either by being newly created or updated), the RGM requires that the resource group nodelist be a subset of the Installed_nodes list of the resource type.
scrgadm -c -t resource_type -h installed_node_list
For each resource of the preupgraded type that is to be migrated to the upgraded type, invoke scswitch to change the state of the resource or its resource group to the appropriate state as dictated by the upgrade documentation.
For each resource of the preupgraded type that is to be migrated to the upgraded type, edit the resource, changing its Type_version property to the new version.
scrgadm -c -j resource -y Type_version=new_version
If necessary, edit other properties of the same resource to appropriate values in the same command.
Restore the previous state of the resource or resource group by reversing the command invoked in Step 5.
How to Downgrade a Resource to an Older Version of Its Resource Type
You can downgrade a resource to an older version of its resource type. The conditions under which you can downgrade a resource to an older version of the resource type are more restrictive than when you upgrade to a newer version of the resource type. You must first unmanage the resource group. In addition, you can only downgrade a resource to an upgrade-enabled version of the resource type. You can identify upgrade-enabled versions by using the scrgadm -p command. In the output, upgrade-enabled versions contain the suffix :version.
Switch the resource group that contains the resource you want to downgrade offline.
scswitch -F -g resource_group
Disable the resource that you want to downgrade and all resources in the resource group.
scswitch -n -j resource_to_downgrade scswitch -n -j resource1 scswitch -n -j resource2 scswitch -n -j resource3 ...
Note - Disable resources in order of dependency, starting with the most dependent (application resources) and ending with the least dependent (network address resources).
Unmanage the resource group.
scswitch -u -g resource_group
Is the old version of the resource type to which you want to downgrade still registered in the cluster?
If yes, go to the next step.
If no, re-register the old version that you want.
scrgadm -a -t resource_type_name
Downgrade the resource by specifying the old version that you want for Type_version.
scrgadm -c -j resource_to_downgrade -y Type_version=old_version
If necessary, edit other properties of the same resource to appropriate values in the same command.
Bring the resource group that contains the resource that you downgraded to a managed state, enable all the resources, and switch the group online.
scswitch -Z -g resource_group