第 3 章 升级资源类型

本章介绍升级资源类型和迁移资源时应了解的事项。

• 概述

• 资源类型登记文件

• 资源的 Type_version 特性

• 将资源迁移到其它版本

• 升级和降级资源类型

• 缺省特性值

• 资源类型开发者文档

• 资源类型名称和资源类型监视器实现

• 应用程序升级

• 资源类型升级实例

• 资源类型软件包的安装要求

概述

系统管理员需要具备相应的能力，以便可以安装和登记现有资源的新版本，允许登记给定资源类型的多个版本，以及将现有资源迁移到资源类型的新版本，而无需删除和重新创建资源。 资源开发者需要了解进行资源类型升级和资源迁移的要求。

资源类型在开发时考虑到升级问题称为升级支持。

资源类型的新版本与以前版本的不同之处可能有以下几个方面：

• 资源类型特性的属性可能发生更改

• 已声明的资源特性（包括标准特性和扩展特性）的设置可能发生更改

• 资源特性的属性（例如 default、min、max、arraymin、arraymax 或可调性）可能发生更改

• 已声明方法的设置可能产生不同

• 方法或监视器的实现可能发生更改。

资源类型开发者可以从以下可调性选项中进行选择，确定何时可以将现有资源迁移到新版本中。 这些选项按限制性的高低（从低到高）列出：

• 随时 (Anytime)

• 当资源不受监视时 (When_unmonitored)

• 当资源处于脱机状态时 (When_offline)

• 当资源处于禁止状态时 (When_disabled)

• 当资源组处于不受管理状态时 (When_unmanaged)

• 在创建时 (At_creation)

在本章中，介绍如何进行升级时使用的是 scrgadm 命令。 管理员并不仅限于使用 scrgadm 命令，也可以使用 GUI 或 scsetup 命令进行升级。

资源类型登记文件

资源类型名称

资源类型名称的三个组成部分是在 RTR 文件中指定为 Vendor_id、Resource_type 和 RT_version 的特性。 scrgadm 命令用来插入句点和冒号分界符以创建资源类型的名称：

vendor_id.resource_type:rt_version

Vendor_id 前缀用来区分不同供应商提供的两个名称相同的登记文件。 RT_version 用来区分同一基本资源类型的多个登记版本（升级）。 为了确保 Vendor_id 的唯一性，建议使用创建该资源类型的公司的股票标志。

如果 RT_version 字符串包含空格、制表符、正斜杠 (/)、反斜杠 (\)、星号 (*)、问号 (? )、逗号 (,)、分号 (;)、左方括号 ([) 或右方括号 (]) 字符，资源类型的登记将失败。

从 Sun Cluster 3.1 开始，RT_Version 特性（在 Sun Cluster 3.0 中为可选特性）已成为必需的特性。

以下命令将返回全限定名称：

scha_resource_get -O Type -R resource_name -G resource_group_name

在 Sun Cluster 3.1 以前的版本中登记的资源类型名称继续采用以下语法：

vendor_id.resource_type

指令

支持升级的资源类型的 RTR 文件必须包含 #$upgrade 指令，后面跟有零或多个采用以下格式的指令：

#$upgrade_from version tunability

upgrade_from 指令由字符串 #$upgrade_from 组成，其后跟有 RT_Version，再后面跟有对该资源的可调性约束。 如果从中执行升级操作的资源类型不具有任何版本，则将 RT_Version 指定为空字符串，如下面最后一个示例所示：

#$upgrade_from   "1.1"   when_offline 
#$upgrade_from   "1.2"   when_offline
#$upgrade_from   "1.3"   when_offline
#$upgrade_from   "2.0"   when_unmonitored
#$upgrade_from   "2.1"   anytime
#$upgrade_from   ""      when_unmanaged

当系统管理员尝试更改资源的 Type_version 时，RGM 将对资源执行这些约束。 如果该资源类型的当前版本未出现在列表中，RGM 将强制执行可调性 When_unmanaged。

这些指令必须显示在 RTR 文件中的资源类型特性声明部分和 RTR 文件中的资源声明部分之间。 请参阅 rt_reg( 4)。

更改 RTR 文件中的 RT_Version

每当更改 RTR 文件的内容之后，都需要更改 RTR 文件中的 RT_Version 字符串。 此特性的值必须明确表明哪一个是该资源类型的新版本，哪一个是旧版本。 如果未更改 RTR 文件，则无需更改 RT_Version 字符串。

Sun Cluster 早期版本中的资源类型名称

Sun Cluster 3.0 中的资源类型名称不包含版本后缀：

vendor_id.resource_name

原来在 Sun Cluster 3.0 中登记的资源类型将继续使用采用此格式的名称（即使是在您将群集软件升级为 Sun Cluster 3.1 或更高版本之后）。 同样地，如果 RTR 文件是在运行 Sun Cluster 3.1 或更高版本软件的群集上进行登记的，则其 RTR 文件中缺少 #$upgrade 指令的资源类型将被指定为 Sun Cluster 3.0 格式的名称，不包含版本后缀。

在 Sun Cluster 3.0 中，您可以登记包含 #$upgrade 或 #$upgrade_from 的 RTR 文件，但是不支持将现有资源迁移到新资源类型。

资源的 Type_version 特性

标准资源特性 Type_version 用来存储资源类型的 RT_Version 特性。 此特性未出现在 RTR 文件中。 系统管理员可以使用以下命令编辑此特性值：

scrgadm -c -j resource -y Type_version=new_version

此特性的可调性继承自：

• 资源类型的当前版本

• RTR 文件中的 #$upgrade_from 指令

在 #$upgrade_from 指令中使用以下可调性值：

Anytime

适用于对于何时升级资源没有限制的情况。 该资源可以始终处于联机状态。

When_unmonitored

适用于新资源类型版本的 Update、Stop、Monitor_check 和 Postnet_stop 方法与旧资源类型版本的启动方法（Prenet_stop 和 Start）兼容且新资源类型版本的 Fini 方法与旧资源类型版本的 Init 方法兼容的情况。 此方案仅要求在升级之前停止资源监视器程序

When_offline

如果新资源类型版本的 Update、Stop、Monitor_check 或 Postnet_stop 方法与旧资源类型版本的启动方法（Prenet_stop 和 Start）不兼容，但是与旧版本的 Init 方法兼容，则对资源进行类型升级时，该资源必须脱机。

When_disabled

与 When_offline 类似。 但是，该可调性值会强加更严格的禁用资源的条件。

When_unmanaged

适用于新资源类型版本的 Fini 方法与旧版本的 Init 方法不兼容的情况。 此可调性值要求您必须将现有资源组切换到不受管理的状态才能升级该资源。

At_creation

适用于无法将资源升级到新资源类型版本的情况。 仅能创建新版本的新资源。

At_creation 可调性表明资源类型开发者可以禁止将现有资源迁移到新类型。 在这种情况下，系统管理员必须删除并重新创建该资源。 这等同于声明该资源版本仅可以在创建时进行设置。

将资源迁移到其它版本

在系统管理员编辑资源的 Type_version 特性后，现有资源将采用新版本。 遵循用来编辑其它资源特性的同一惯例，不同的是要从新资源类型版本中（而不是当前版本）继承或获取一些信息：

• 所有特性的资源特性属性，例如 min、max、arraymin、arraymax、缺省值和可调性是从新资源类型版本中获取的。

• 适用于 Type_version 特性的可调性是从现有资源的资源类型的 RTR 文件中的 #$upgrade_from 指令和 RT_version 特性获取的。 此可调性与 property_attributes(5) 中介绍的可调性不同。

• 将应用新资源类型版本的 Validate 方法。 这可以确保特性属性对新资源类型有效。 如果现有资源特性属性不能满足新资源类型版本的验证条件，系统管理员必须在 scrgadm 命令行中为这样的特性提供有效值。 如果新资源类型版本开始使用未在早期版本中声明且不具有缺省值的特性，可能会发生这样的情况。 如果现有资源的某个特性被分配了对新资源类型版本来说无效的值，则也可能发生这种情况。

• 已在旧版本中声明的资源特性在新版本中可能未进行声明。 当资源迁移到新版本后，该特性将从该资源中删除。

Validate 方法可以查询资源的当前 Type_version（使用 scha_resource_get）和新的 Type_version（传送到了 Validate 命令行）。 因此，Validate 可以取消从不支持的版本进行升级。

升级和降级资源类型

有关升级或迁移资源类型的其它信息，请参阅《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》中的“升级资源类型”一节。

如何升级资源类型

1. 请阅读新资源类型的升级文档，找出资源类型更改和资源可调性约束。

2. 在所有群集节点上安装资源类型升级软件包。

   建议按照轮询升级方式安装新的资源类型软件包： 在非群集模式下引导节点时，将出现 pkgadd。

   以下是在处于群集模式下的节点上安装新资源类型软件包时可能出现的情况：

   • 如果安装资源类型软件包时不更改方法代码并且仅更新监视器，则必须在安装过程中停止监视该类型的所有资源。

   • 如果安装资源类型软件包时既不更改方法也不更改监视器代码，则不需要在安装过程中停止监视该资源，因为安装操作仅在磁盘上放置一个新的 RTR 文件。

3. 使用 scrgadm（或等效）命令登记新资源类型版本，并引用升级版本的 RTR 文件。

   RGM 将创建新资源类型，其名称格式为

   vendor_id.resource_type:version

4. 如果资源类型升级版本仅安装在节点的子集上，则您必须将新资源类型的 Installed_nodes 特性设置为实际进行安装的节点。

   当资源采用新类型时（无论是通过重新创建还是更新），RGM 要求资源组的 nodelist 为该资源类型的 Installed_nodes 列表的子集。

   scrgadm -c -t resource_type -h installed_node_list

5. 对于预备升级类型（即计划迁移到升级类型的类型）的每一个资源，请调用 scswitch 将该资源及其资源组的状态更改为升级文档中指示的相应状态。

6. 对于预备升级类型（即计划迁移到升级类型的类型）的每一个资源，请编辑该资源并将其 Type_version 特性更改为新的版本。

   scrgadm -c -j resource -y Type_version=new_version

   如果需要，请使用同一命令将同一资源的其它特性编辑为适当的值。

7. 通过使用与步骤 5中所调用命令相反的命令来恢复资源或资源组原来的状态。

如何将资源降级到其资源类型的早期版本

您可以将资源降级为其资源类型的早期版本。 将资源降级为资源类型的早期版本比升级到资源类型的更新版本所需的条件更受限制。 首先必须使资源组不受管理。 此外，只能将资源降级到资源类型的可升级版本。 您可以使用 scrgadm -p 命令标识可升级版本。 在输出中，可升级版本包含后缀 :version。

1. 将包含要降级资源的资源组切换为脱机状态。

   scswitch -F -g resource_group

2. 禁用要降级的资源以及资源组中的所有资源。

   scswitch -n -j resource_to_downgrade scswitch -n -j resource1 scswitch -n -j resource2 scswitch -n -j resource3 ...

   ---

   注意：

   按相关性的顺序禁用资源，从相关性最强的资源（应用程序资源）开始，到相关性最弱的资源（网络地址资源）结束。

   ---

3. 使资源组不受管理。

   scswitch -u -g resource_group

4. 您要降级到的旧版本的资源类型是否仍注册在群集中？

   • 如果是，请转到下一步。

   • 如果否，请重新注册所需的旧版本。

     scrgadm -a -t resource_type_name

5. 通过为 Type_version 指定所需的旧版本来降级资源。

   scrgadm -c -j resource_to_downgrade -y Type_version=old_version

   如果需要，请使用同一命令将同一资源的其它特性编辑为适当的值。

6. 使包含已降级资源的资源组转为受管理状态，启用所有资源并将组切换为联机状态。

   scswitch -Z -g resource_group

缺省特性值

RGM 将存储所有资源，这样系统管理员未明确设置的特性（和具有缺省值的特性）将不存储在 CCR（群集配置系统信息库）中的资源项中。 如果是从 CCR 读入资源，RGM 将从资源类型中获得缺少的资源特性的缺省值（如果未在该处定义，则使用系统定义的缺省特性值）。 正是这个存储特性的方法允许升级后的资源类型定义新特性或为现有特性定义新的缺省值。

编辑资源特性时，RGM 将通过编辑命令指定的特性存储在 CCR 中。

如果资源类型的升级版本声明了缺省特性的新缺省值，则新缺省值被现有资源继承，即使该特性被声明为可变的 At_creation 或 When_disabled。 如果使用新的缺省值导致方法（例如 Stop、Postnet_stop 或 Fini）失败，资源类型实现器必须相应地在升级该资源时限制其状态。 限制 Type_version 特性的可调性即可实现此目的。

新资源类型版本的 Validate 方法可用于进行检查，以确保现有特性属性适用。 如果不适用，系统管理员可以通过编辑 Type_version 特性使用的同一命令来编辑现有资源的特性，使其具有适当的值，以将该资源升级为新资源类型版本。

在将 Sun Cluster 3.0 中创建的资源迁移到更高版本时，它们不会从该资源类型中继承新的缺省特性值，因为它们的缺省特性存储在 CCR 中。

资源类型开发者文档

资源类型开发者必须随新资源一起提供包含以下信息的文档：

• 介绍所有特性的添加、更改或删除操作

• 介绍如何使特性符合新的要求

• 说明对资源的可调性约束

• 说明所有新的缺省特性属性

• 通知系统管理员可以使用编辑 Type_version 特性时使用的同一命令来编辑现有资源类型，使其具有适当的值，以将该资源升级到新资源类型版本

资源类型名称和资源类型监视器实现

虽然您可以在 Sun Cluster 3.0 中登记支持升级的资源类型，但是在 CCR 中记录的资源类型名称不包含版本后缀。 要在 Sun Cluster 3.0 和 Sun Cluster 3.1（及更高版本）中正确运行，该资源类型的监视器必须可以处理以下两种命名惯例：

vendor_id.resource_name:version
vendor_id.resource_name

通过运行与以下代码等效的代码，监视器可以确定要使用的适当名称：

scha_resourcetype_get -O RT_VERSION -T VEND.myrt
scha_resourcetype_get -O RT_VERSION -T VEND.myrt:vers

然后比较包含 vers 的输出值。 对于 vers 的某一特定值，只有一个命令会成功，因为不可能使用两个不同名称将资源类型的同一版本登记两次。

应用程序升级

虽然有些方面相似，但是应用程序代码的升级与代理程序代码的升级还是存在不同之处。 应用程序升级可能伴有资源类型升级，也可能不伴有资源类型升级。

资源类型升级实例

这些实例说明了几种不同资源类型的安装和升级方案。 已经根据对资源类型实现进行的更改类型选择了可调性和封装信息。 可调性适用于将资源迁移到新资源类型的迁移。

所有实例均假设：

• 资源类型来自 Solaris 软件包。 请参阅 pkgadd(1M) 和 pkgrm(1M)。

• 新的 RTR 文件中只有一个 #$upgrade_from 指令（由于只有一个以前版本的资源类型）

• 如果从磁盘删除方法时 RGM 要调用这些方法，则安装过程不会删除或覆写这些方法

• 新方法与旧方法兼容（除非另外说明）

• 在安装或迁移之前使用正确的 scswitch (1M) 命令或等效命令将资源和资源组转换到所需状态。 以下实例说明了如何将资源组转换到不受管理状态：

  scswitch -M -n -j resource scswitch -n -j resource scswitch -F -g resource_group scswitch -u -g resource_group

• 使用此命令登记资源类型：

  scrgadm -a -t resource_type -f path_to_RTR_file

• 使用此命令迁移资源：

  scrgadm -c -j resource -y Type_version=version \ -y property=value \ -x property=value ...

• 迁移之后，将使用相应的 scswitch (1M) 命令或等效命令将资源和资源组恢复成以前的状态：

  scswitch -M -e -j resource scswitch -e -j resource scswitch -o -g resource_group scswitch -Z -g resource_group

资源类型开发者可能需要指定比这些实例中所用可调性值的限定性更强的值。 可调性值取决于对资源类型实现进行的确切更改。 此外，资源类型开发者可以选择使用不同的封装机制来代替这些实例中所用的 Solaris 封装。

资源类型软件包的安装要求

以下是与新资源类型软件包安装相关的两个要求：

• 登记新资源类型时，其 RTR 文件必须可以在磁盘上存取

• 创建新类型的资源时，新资源类型的所有已声明方法路径名和监视器程序必须位于磁盘上并且可执行。 只要正在使用该资源，就必须在原来位置保留旧的方法和监视器程序。

  为了确定最合适的封装机制，资源类型实现器必须考虑以下几个方面：

  • 是否更改 RTR 文件？

  • 是否更改特性的缺省值或可调性？

  • 是否更改特性的 min 或 max 值？

  • 升级过程中是否添加或删除特性？

  • 是否更改方法代码？

  • 是否更改监视器代码？

  • 新的方法或监视器代码与以前版本是否兼容？

您在更改 RTR 文件之前需了解的信息

一些资源类型升级并不涉及新的方法或监视器代码。 例如，资源类型升级可能仅更改资源特性的缺省值或可调性。 既然不会更改方法代码，则对安装升级软件包仅有一项要求，即要具有指向可读 RTR 文件的有效路径名称。

如果无需登记旧的资源类型，新的 RTR 文件可以覆写以前版本。 否则，可以将新的 RTR 文件放置在新的路径名下。

如果升级过程中更改了特性的缺省值或可调性，则新版本的 Validate 方法可以在迁移时检验现有特性属性对新资源类型是否有效。 如果升级过程中更改了特性的 min、max 或 type 属性，scrgadm 命令将在迁移时自动验证这些约束。

升级文档必须说明所有新的缺省特性属性。 该文档必须告知系统管理员使用与编辑 Type_version 特性时使用的同一命令编辑各个值，使其具有适当的值，以将资源升级到新的资源类型版本。

如果升级过程中添加或删除了特性，则可能需要更改某些回叫方法或监视器代码。

更改监视器代码

如果已更新的资源类型中仅更改了监视器代码，软件包安装可以覆写监视器二进制文件。 文档必须通知系统管理员在安装新软件包之前暂停监视。

更改方法代码

如果已更新的资源类型中仅更改了方法代码，那么确定新的方法代码是否与以前版本兼容就变得十分重要。 这样可以确定是否必须将新方法代码存储在新路径名下或旧的方法是否可以被覆写。

如果新的 Stop、Postnet_stop 和 Fini 方法（如果已声明）可以应用到通过 Start 、Prenet_stop 或 Init 方法的旧版本初始化或启动的资源，那么就能够用新方法覆写旧方法。

如果新方法代码与以前版本不兼容，则必须使用该方法的旧版本停止或取消配置资源才能迁移到已升级的资源类型。 如果新方法要覆写旧方法，那么在升级资源类型之前，它可能会要求关闭（也许还要取消管理）该类型的所有资源。 如果新方法与旧方法存储在不同的位置（可以同时存取），则即使没有向下兼容性，也可以安装新的资源类型版本并逐个升级这些资源。

如果新方法可以向下兼容，则可能要求每次将一个资源升级为使用新方法，而其它资源继续使用旧的方法。 仍然需要将新方法存储在单独的目录中，而不覆写旧的方法。

将方法的每一个资源类型版本都存储在单独的目录中的优点是当新版本出现问题时可以很容易地转换回旧的资源类型版本。

一种封装方法是包含所有在软件包中仍然支持的早期版本。 这样做允许新的软件包版本替换旧的版本，而不覆写或删除旧的方法路径。 由资源类型开发者决定可以支持多少个以前版本。

建议不要在当前处于群集中的节点上覆写方法或对方法执行 pkgrm/pkgadd。 如果方法在磁盘上不可存取时，则 RGM 调用该方法时可能会导致意外的结果。 删除或替换正在运行的方法的二进制文件也可能会导致意外的结果。