Skip Navigation Links
Exit Print View
| Oracle Solaris Cluster Data Services Planning and Administration Guide Oracle Solaris Cluster 4.1

Search Scope:

- This Document
- Entire Library

## Upgrading a Resource Type

Upgrading a resource type enables you to use new features that are introduced in the new version of the resource type. A new version of a resource type might differ from a previous version in the following ways.

- Default settings of resource type properties might change.

- New extension properties of the resource type might be introduced.

- Existing extension properties of the resource type might be withdrawn.

- The set of standard properties that are declared for the resource type might change.

- The attributes of resource properties such as `min`, `max`, `arraymin`, `arraymax`, `default`, and `tunability` might change.

- The set of declared methods might differ.

- The implementation of methods or the fault monitor might change.

Upgrading a resource type involves the tasks that are explained in the following sections:

1. How to Install and Register an Upgrade of a Resource Type

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

## How to Install and Register an Upgrade of a Resource Type

The instructions that follow explain how to use the `clresource` command to perform this task. However, you are not restricted to using the `clresource` command for this task. Instead of the `clresource` command, you can use the Resource Group option of the `clsetup` command to perform this task. See `clsetup`(1CL) for more information.

Before You Begin

Consult the documentation for the resource type to determine what you must do before installing the upgrade package on a node. One action from the following list will be required:

- You must reboot the node in noncluster mode.

- You may leave the node running in cluster mode, but you must turn off monitoring of all instances of the resource type.

- You may leave the node running in cluster mode and leave monitoring turned on for all instances of the resource type.

If you must reboot the node in noncluster mode, prevent a loss of service by performing a rolling upgrade. In a rolling upgrade, you install the package on each node individually while leaving the remaining nodes running in cluster mode.

1. On a cluster member, assume the `root` role that provides `solaris.cluster.modify` RBAC authorization.
2. Install the package for the resource type upgrade on all cluster nodes where instances of the resource type are to be brought online.
3. Register the new version of the resource type.

   To ensure that the correct version of the resource type is registered, you must specify the following information:

   - The resource type name

   - The resource type registration (RTR) file that defines the resource type

       # clresourcetype register -f path-to-new-rtr-file resource-type-name

   The format of the resource type name is as follows:

       vendor-id.base-rt-name:rt-version

   For an explanation of this format, see Format of Resource Type Names.

4. Display the newly registered resource type.

       # clresourcetype show resource-type-name

5. If necessary, set the `Installed_nodes` property to the nodes where the package for the resource type upgrade is installed.

   You must perform this step if the package for the resource type upgrade is not installed on all cluster nodes.

   The `nodelist` property of all resource groups that contain instances of the resource type must be a subset of the `Installed_nodes` property of the resource type.

       # clresourcetype set -n installed-node-list resource-type

   `-n` installed-node-list

     Specifies the names of nodes on which this resource type is installed.

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

The instructions that follow explain how to use the `clresource` command to perform this task. However, you are not restricted to using the `clresource` command for this task. Instead of the `clresource` command, you can use the Resource Group option of the `clsetup` command to perform this task. See `clsetup`(1CL) for more information.

Before You Begin

Consult the instructions for upgrading the resource type to determine when you can migrate resources to a new version of the resource type.

- Any time

- Only when the resource is unmonitored

- Only when the resource is offline

- Only when the resource is disabled

- Only when the resource group is unmanaged

The instructions might state that you cannot upgrade your existing version of the resource. If you cannot migrate the resource, consider the following alternatives:

- Deleting the resource and replacing it with a new resource of the upgraded version

- Leaving the resource at the old version of the resource type

1. On a cluster member, assume the `root` role that provides `solaris.cluster.modify` RBAC authorization.
2. 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.
   - If you can migrate the resource at any time, no action is required.
   - If you can migrate the resource only when the resource is unmonitored, type the following command:

         # clresource unmonitor resource

   - If you can migrate the resource only when the resource is offline, type the following command:

         # clresource disable resource

     Note - If other resources depend on the resource that you are migrating, this step fails. In this situation, consult the error message that is printed to determine the names of the dependent resources. Then repeat this step, specifying a comma-separated list that contains the resource that you are migrating and any dependent resources.

   - If you can migrate the resource only when the resource is disabled, type the following command:

         # clresource disable resource

     Note - If other resources depend on the resource that you are migrating, this step fails. In this situation, consult the error message that is printed to determine the names of the dependent resources. Then repeat this step, specifying a comma-separated list that contains the resource that you are migrating and any dependent resources.

   - If you can migrate the resource only when the resource group is unmanaged, type the following commands:

         # clresource disable -g resource-group +
         # clresourcegroup offline resource-group
         # clresourcegroup unmanage resource-group

     The replaceable items in these commands are as follows:

     resource-group

       Specifies the resource group that is to be unmanaged

3. For each resource of the resource type that is to be migrated, change the `Type_version` property to the new version.

   If necessary, set other properties of the same resource to appropriate values in the same command. To set these properties, specify the `-p` option in the command.

   To determine whether you are required to set other properties, consult the instructions for upgrading the resource type. You might be required to set other properties for the following reasons:

   - An extension property has been introduced in the new version of the resource type.

   - The default value of an existing property has been changed in the new version of the resource type.

       # clresource set -p Type_version=new-version \
       [-p extension-property=new-value] [-p standard-property=new-value] resource

   Note - If the existing version of the resource type does not support upgrades to the new version, this step fails.

4. Restore the previous state of the resource or resource group by reversing the command that you typed in Step 2.
   - If you can migrate the resource at any time, no action is required.

     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 lists the correct resource type version.

   - If you can migrate the resource only when the resource is unmonitored, type the following command:

         # clresource monitor resource

   - If you can migrate the resource only when the resource is offline, type the following command:

         # clresource enable resource

     Note - If you disabled in Step 2 other resources that depend on the resource that you are migrating, enable the dependent resources also.

   - If you can migrate the resource only when the resource is disabled, type the following command:

         # clresource enable resource

     Note - If you disabled in Step 2 other resources that depend on the resource that you are migrating, enable the dependent resources also.

   - If you can migrate the resource only when the resource group is unmanaged, type the following commands:

         # clresource enable -g resource-group +
         # clresourcegroup manage resource-group
         # clresourcegroup online resource-group

Example 2-2 Migrating a Resource That Can Be Migrated Only When Offline

This example shows the migration of a resource that can be migrated only when the resource is offline. The new resource type package contains methods that are located in new paths. Because the methods are not overwritten during the installation, the resource does not need to be disabled until after the upgraded resource type is installed.

The characteristics of the resource in this example are as follows:

- The new resource type version is 2.0.

- The resource name is `myresource`.

- The resource type name is `myrt`.

- The new RTR file is in `/opt/XYZmyrt/etc/XYZ.myrt`.

- No dependencies on the resource that is to be migrated exist.

- The resource that is to be migrated can be taken offline while leaving the containing resource group online.

This example assumes that the upgrade package is already installed on all cluster nodes according to the supplier's directions.

    # clresourcetype register -f /opt/XYZmyrt/etc/XYZ.myrt myrt
    # clresource disable myresource
    # clresource set -p Type_version=2.0 myresource
    # clresource enable myresource

Example 2-3 Migrating a Resource That Can Be Migrated Only When Unmonitored

This example shows the migration of a resource that can be migrated only when the resource is unmonitored. The new resource type package contains only the monitor and RTR file. Because the monitor is overwritten during installation, monitoring of the resource must be disabled before the upgrade package is installed.

The characteristics of the resource in this example are as follows:

- The new resource type version is 2.0.

- The resource name is `myresource`.

- The resource type name is `myrt`.

- The new RTR file is in `/opt/XYZmyrt/etc/XYZ.myrt`.

The following operations are performed in this example.

1. Before the upgrade package is installed, the following command is run to disable monitoring of the resource:

       # clresource unmonitor  myresource

2. The upgrade package is installed on all cluster nodes according to the supplier's directions.

3. To register the new version of the resource type, the following command is run:

       # clresourcetype register -f /opt/XYZmyrt/etc/XYZ.myrt myrt

4. To change the `Type_version` property to the new version, the following command is run:

       # clresource set -p Type_version=2.0 myresource

5. To enable monitoring of the resource after its migration, the following command is run:

       # clresource monitor myresource

## How to Unregister Older Unused Versions of the Resource Type

If you have migrated all existing resources to the newest version of the resource type and have no further need for the older version of that resource type, unregister the older versions.

1. On a cluster member, assume the `root` role that provides `solaris.cluster.modify` RBAC authorization.
2. Retrieve a list of the registered resource type versions and unregister the version you no longer wish to use.

       # clresourcetype list | grep myrt

       XYZ.myrt:1.0
       XYZ.myrt:2.0

       # clresourcetype unregister XYZ.myrt:1.0

3. If the resource type has the `RT_system` property set to `TRUE`, you must set it to `FALSE` before you can remove the resource type.

   If the following text appears after you run `clresourcetype unregister` from Step 2, you must set the property to `TRUE` by typing the commands that appear below the output below.

       clrt: (C944871) Operation not allowed on system rescue type <XYZ.myrt:1.0>

       # clresourcetype set -p RT_system=FALSE XYZ.myrt:1.0

       # clresourcetype unregister XYZ.myrt:1.0

   By default, the `RT_system` property by default is set to `TRUE` on the pre-installed resource types `LogicalHostname` and `SharedAddress`. If you have upgraded to a newer version of one of these pre-installed resource types, you will have to set `RT_system` to `FALSE` before unregistering the older version. In this example, all of the existing `LogicalHostname` resources have been migrated to version 4.0 of `LogicalHostname`.

       # clresourcetype list

       ...
       SUNW.LogicalHostname.3
       SUNW.LogicalHostname:4
       ...

       # clresourcetype set -p RT_system=FALSE SUNW.LogicalHostname:3

       # clresourcetype unregister SUNW.LogicalHostname:3

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