第 3 章 リソースタイプの更新
この章では、リソースタイプの開発者がリソースタイプの更新や移行を行うために必要な情報を提供します。
概要
システム管理者は、既存のリソースタイプの新しいバージョンをインストールおよび登録できなければなりません。これは、リソースを削除したり作成し直したりすることなく、複数のバージョンのリソースタイプを登録したり、既存のリソースを新しいバージョンのリソースタイプに移行したりする必要があるからです。リソース開発者は、リソースタイプのアップグレードや移行の要件を把握しておく必要があります。
アップグレードを念頭に置いたリソースタイプの開発を「アップグレード対応」と呼びます。
新しいバージョンのリソースタイプは、次の点で前のバージョンとは異なっている可能性があります。
-
リソースタイププロパティの属性
-
標準プロパティ、拡張プロパティを含む宣言済みリソースプロパティ
-
リソースプロパティの属性 (default、min、max、arraymin、arraymax) または tunable 属性
-
宣言済みメソッド
-
メソッドやモニターの実装
リソースタイプ開発者は、既存のリソースを新しいバージョンへ移行するタイミングを次の Tunable 属性のオプションによって特定します。制約の小さいものから順に、次のようなオプションがあります。
-
いつでもよい (ANYTIME)
-
リソースが監視されていないとき (WHEN_UNMONITORED )
-
リソースがオフラインのとき (WHEN_OFFLINE)
-
リソースが無効のとき (WHEN_DISABLED)
-
リソースグループが管理されていないとき (WHEN_UNMANAGED )
-
作成時 (AT_CREATION)
注 –
この章では、アップグレード手順の記述で常に scrgadm コマンドを使用します。これは、管理者が scrgadm コマンドしか使用できないということではありません。GUI、scsetup コマンドなども使用できます。
リソースタイプ登録ファイル
リソースタイプ名
リソースタイプ名は、RTR ファイルに指定されたプロパティ、Vendor_id、Resource_type、RT_version の 3 つで構成されます。scrgadm コマンドは、ピリオドとコロンを区切り文字として使用し、リソースタイプ名を作成します。
vendor_id.resource_type:rt_version |
Vendor_id 接頭辞では、同一名でベンダーの異なる 2 つの登録ファイルを識別できます。RT_version では、同じベースリソースタイプの複数のバージョン (アップグレード) を識別できます。重複を防ぐため、Vendor_id には、リソースタイプの作成元の会社のストックシンボルを使用することをお勧めします。
RT_version の文字列に、空白文字や、タブ、スラッシュ ( /)、バックスラッシュ (\)、アスタリスク (*)、疑問符 (?)、コンマ (,)、セミコロン (;)、左角かっこ ([)、右角かっこ (]) が含まれていると、リソースタイプの登録は失敗します。
RT_Version プロパティは、Sun Cluster 3.0 まではオプションでしたが、Sun Cluster 3.1 以降では必須です。
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、リソースの Tunable 属性の制約で構成されます。アップグレードを行う前のリソースタイプにバージョンがない場合、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 によってこれらの制約が課されます。現在のリソースタイプのバージョンがリストに表示されない場合、Tunable 属性は WHEN_UNMANAGED になります。
これらのディレクティブは、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 ファイル内には指定されません。システム管理者は、次のコマンドを使って、Type_version プロパティを編集します。
scrgadm -c -j resource -y Type_version=new_version |
このプロパティの Tunable 属性は、次の項目によって決まります。
-
現在のリソースタイプのバージョン
-
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_UNMANAGED
-
新しいリソースタイプのバージョンの Fini メソッドが古いバージョンの Init メソッドと互換しないことがわかっている場合。リソースのアップグレード前に既存のリソースグループを管理されていない状態にする必要があります。
- AT_CREATION
-
新しいリソースタイプのバージョンにアップグレードできないリソースの場合。新しいバージョンの新しいリソースしか作成できません。
Tunable 属性が AT_CREATION の場合、リソースタイプ開発者は既存のリソースを新しいタイプに移行することを禁止できます。この場合、システム管理者は、リソースを削除して作成し直す必要があります。これは、リソースのバージョンが作成時にだけ設定されるという宣言と同じことです。
リソースを別のバージョンへ移行
システム管理者がリソースの Type_version プロパティを編集すると、既存のリソースは新しいリソースタイプバージョンを取得します。これは、その他のリソースプロパティの編集時と同じ規則に従います。ただし、一部の情報が現在のバージョンではなく新しいリソースタイプから取得されるという点を除きます。
-
min、max、arraymin、arraymax、デフォルト、Tunable 属性など、すべてのプロパティのリソースプロパティ属性は、新しいリソースタイプのバージョンから取得されます。
-
Type_version プロパティに適用される Tunable 属性は、RTR ファイル内の #$upgrade_from ディレクティブと、既存のリソースのリソースタイプの RT_version プロパティから取得されます。Tunable 属性は、property_attributes(5) のマニュアルページの説明とは異なります。
-
新しいリソースタイプのバージョンの Validate メソッドが適用されます。このため、プロパティ属性は、新しいリソースタイプで有効です。既存のリソースプロパティ属性が新しいリソースタイプのバージョンの妥当性検査の条件を満たしていない場合、システム管理者は、scrgadm コマンドに、こうしたプロパティの有効な値を指定する必要があります。この手続きは、新しいリソースタイプのバージョンが、以前のバージョンでは宣言されていなかったプロパティを使用し、デフォルト値がない場合に行われます。既存のリソースが、新しいリソースタイプのバージョンでは無効なプロパティ値を持っている場合にも、この手続きが行われます。
-
古いバージョンのリソースタイプで宣言されたリソースプロパティが新しいバージョンでは宣言されないことがあります。こうしたリソースを新しいバージョンに移行すると、リソースからプロパティが削除されます。
注 –
Validate メソッドは、リソースの新しい Type_version (Validate コマンド行に渡される) だけでなく現在の Type_version も照会できます (scha_resource_get を使用)。このため、 サポートされないバージョンのアップグレードを Validate によって禁止できます。
リソースタイプのアップグレードとダウングレード
リソースタイプのアップグレードおよび移行の詳細については、『 Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「リソースタイプのアップグレード」を参照してください。
リソースタイプをアップグレードする方法
-
新しいリソースタイプのアップグレード手順の説明を読み、リソースタイプの変更とリソースの Tunable 属性の制約を確認します。
-
すべてのクラスタノードに、リソースタイプアップグレードパッケージをインストールします。
新しいリソースタイプパッケージのインストールは、段階的に行うことをお勧めします。ノードが非クラスタモードで起動している間に pkgadd を実行します。
クラスタモードのノードに新しいリソースタイプパッケージをインストールする場合は、条件に合わせて異なった方法を使用します。
-
リソースタイプパッケージのインストールによってメソッドコードが変更されず、モニターだけが更新される場合は、インストール中にそのタイプのすべてのリソース上で監視を停止する必要があります。
-
リソースタイプパッケージのインストールによってメソッドとモニターの両方のコードが変更されない場合は、ディスク上に新しい RTR ファイルが 追加されるだけなので、インストール中にリソース上での監視を停止する必要はありません。
-
-
アップグレードの RTR ファイルを参照し、scrgadm または同等のコマンドを使って新しいリソースタイプのバージョンを登録します。
RGM により、次の形式の新しいリソースタイプが作成されます。
vendor_id.resource_type:version
-
リソースタイプのアップグレードがノードのサブセットにだけインストールされる場合は、新しいリソースタイプの Installed_nodes プロパティに実際のインストール先ノードを設定する必要があります。
リソースが新しいタイプ (新しく作成された、または更新された) を取得するとき、RGM は、リソースグループ nodelist がリソースタイプの Installed_nodes リストのサブセットであることを要求します。
scrgadm -c -t resource_type -h installed_node_list
-
以前にタイプがアップグレードされ、これからそのタイプに移行する各リソースに対して、scswitch を呼び出し、そのリソース自体またはそのリソースグループを、アップグレード手順に示されている適切な状態に変更します。
-
以前にタイプがアップグレードされ、これからそのタイプに移行する各リソースを編集し、Type_version プロパティに新しいバージョンを設定します。
scrgadm -c -j resource -y Type_version=new_version
必要に応じて、同じコマンドを使って、同じリソースのその他のプロパティに適切な値を設定します。
-
手順 5 で呼び出したコマンドを逆方向に実行すると、リソースまたはリソースグループの以前の状態を回復できます。
古いバージョンのリソースタイプにダウングレードする方法
リソースをダウングレードして古いバージョンのリソースタイプにすることができます。古いリソースタイプバージョンにダウングレードする場合は、新しいリソースタイプバージョンにアップグレードする場合よりも条件が厳しくなります。まず、リソースグループの管理を解除する必要があります。アップグレードが可能なリソースタイプバージョンにしかダウングレードできないということにも注意してください。アップグレード可能なバージョンは scrgadm!)-p コマンドを使用して確認できます。アップグレード可能なバージョンの場合、接尾辞 :version が表示されます。
-
ダウングレードしたいリソースを含んでいるリソースグループをオフラインに切り替えます。
scswitch -F -g resource_group
-
ダウングレードするリソースと、そのリソースグループ内のすべてのリソースを無効にします。
scswitch -n -j resource_to_downgrade scswitch -n -j resource1 scswitch -n -j resource2 scswitch -n -j resource3 ...
注 –リソースの無効化は、依存性の高いもの (アプリケーションリソース) から開始し、もっとも依存性の低いもの (ネットワークアドレスリソース) で終了するように行なってください。
-
リソースグループを非管理状態に切り替えます。
scswitch -u -g resource_group
-
ダウングレード後のリソースタイプバージョンとする古いリソースバージョンがクラスタ内にまだ登録されているかどうか確認します。
-
登録されている場合は、次の手順に進みます。
-
登録されていない場合は、希望する旧バージョンを登録し直します。
scrgadm -a -t resource_type_name
-
-
希望する旧バージョンを Type_version に指定し、リソースをダウングレードします。
scrgadm -c -j resource_to_downgrade -y Type_version=old_version
必要に応じて、同じコマンドを使って、同じリソースのその他のプロパティに適切な値を設定します。
-
ダウングレードしたリソースを含んでいるリソースグループを管理状態にし、すべてのリソースを有効にしたあと、このグループをオンラインに切り替えます。
scswitch -Z -g resource_group
デフォルトのプロパティ値
RGM は、システム管理者によって明示的に設定されなかったためリソースの CCR (クラスタ構成リポジトリ) に格納されていないデフォルトのプロパティなど、すべてのリソースを格納します。RGM は、CCR からリソースが読み込まれるとき、欠落したリソースプロパティのデフォルト値をそのリソースタイプから取得します。リソースタイプにデフォルト値が定義されていない場合は、システム定義のデフォルト値を使用します。アップグレードされたリソースタイプは、この方法により、新しいプロパティや既存のプロパティの新しいデフォルト値を定義することができます。
リソースプロパティが変更された場合、RGM は編集コマンドで指定されたプロパティを CCR に格納します。
リソースタイプのアップグレードされたバージョンが、デフォルトのプロパティの新しいデフォルト値を宣言する場合、新しいデフォルト値は既存のリソースから継承されます。この手続きは、プロパティが作成時または無効化されている場合だけ「Tunable」と宣言されている場合でも変わりません。新しいデフォルトのアプリケーションで、Stop、 Postnet_stop、Fini などのメソッドが失敗する場合、リソースタイプの実装者は、アップグレード時のリソースの状態を適切に制限する必要があります。具体的には、Type_version プロパティの Tunable 属性を制限します。
新しいリソースタイプのバージョンの 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 と出力値を比較します。同じリソースタイプの同じバージョンを別の名前で 2 回以上登録することはできません。したがって、vers の特定の値に対して成功するのは、上記のコマンドのいずれか一方のみとなります。
アプリケーションのアップグレード
アプリケーションコードのアップグレードは、いくつかの共通点はあるものの、エージェントコードのアップグレードとは大きく異なっています。アプリケーションのアップグレードでは、リソースタイプのアップグレードが必要な場合とそうでない場合があります。
リソースタイプのアップグレード例
以下では、リソースタイプのインストールとアップグレードの例をいくつか紹介します。Tunable 属性とパッケージ情報は、リソースタイプ実装の変更に基づいて選択されています。Tunable 属性は、リソースを新しいリソースタイプに移行するときに適用されます。
すべての例は、次の条件に従うものとします。
-
リソースタイプは Solaris パッケージで配布されています。pkgadd(1M) および pkgrm(1M) のマニュアルページを参照してください。
-
リソースタイプの以前のバージョンは 1 つしかないので、新しい RTR ファイル内には #$upgrade_from ディレクティブが 1 つしかありません。
-
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
場合によっては、リソースタイプ開発者は、例で使用されているものより制限の厳しい Tunable 属性の値を指定する必要があります。Tunable 属性の値は、リソースタイプ実装の変更内容によって決定します。リソースタイプ開発者は、例で使用されている Solaris パッケージ以外のパッケージスキーマを選択することもできます。
表 3–1 リソースタイプのアップグレード例|
変更の種類 |
Tunable 属性 |
パッケージ処理 |
手続き |
|---|---|---|---|
|
プロパティの変更は、RTR ファイルのみに加えられました。 |
ANYTIME |
新しい RTR ファイルを配布するだけです。 |
新しい RTR ファイルの pkgadd をすべてのノード上で実行します。 新しいリソースタイプを登録します。 リソースを移行します。 |
|
メソッドが更新されました。 |
ANYTIME |
更新されたメソッドを古いメソッドとは異なったパスに配置します。 |
更新されたメソッドの pkgadd をすべてのノード上で実行します。 新しいリソースタイプを登録します。 リソースを移行します。 |
|
新しいモニタープログラムです。 |
WHEN_UNMONITORED |
以前のバージョンのモニターを上書きするだけです。 |
監視を無効化します。 新しい監視プログラムの pkgadd をすべてのノード上で実行します。 新しいリソースタイプを登録します。 リソースを移行します。 監視を有効化します。 |
|
メソッドが更新されました。新しい Update/ Stop メソッドと古い Start メソッドには互換性がありません。 |
WHEN_OFFLINE |
更新されたメソッドを古いメソッドとは異なったパスに配置します。 |
更新されたメソッドの pkgadd をすべてのノード上で実行します。 新しいリソースタイプを登録します。 リソースをオフラインにします。 リソースを移行します。 リソースをオンラインにします。 |
|
メソッドが更新され、RTR ファイルに新しいプロパティが追加されました。新しいメソッドには新しいプロパティが必要です。リソースの所属リソースグループをオンラインのまま保持しながらリソースがオンラインになることを防ぐ必要があります。このためには、リソースグループをノード上でオフラインの状態からオンラインの状態に変更します。 |
WHEN_DISABLED |
以前のバージョンのメソッドを上書きします。 |
リソースを無効にします。
新しいリソースタイプを登録します。 リソースを移行します。 リソースを有効にします。 |
|
メソッドが更新され、RTR ファイルに新しいプロパティが追加されました。新しいメソッドは新しいプロパティを必要としません。 |
ANYTIME |
以前のバージョンのメソッドを上書きします。 |
この手続きの間に、RGM は新しいメソッドを呼び出します。これは、まだ移行が完了しておらず、新しいプロパティが構成されていない場合でも変わりません。新しいメソッドは、新しいプロパティなしで正常に機能しなければなりません。 新しいリソースタイプを登録します。 リソースを移行します。 |
|
メソッドが更新されました。新しい Fini メソッドと古い Init メソッドには互換性がありません。 |
WHEN_UNMANAGED |
更新されたメソッドを古いメソッドとは異なったパスに配置します。 |
リソースの所属リソースグループを管理対象外にします。 更新されたメソッドの pkgadd をすべてのノード上で実行します。 リソースタイプを登録します。 リソースを移行します。 リソースの所属リソースグループを管理対象にします。 |
|
メソッドが更新されました。RTR ファイルは変更されていません。 |
該当しません。RTR ファイルは変更されていません。 |
以前のバージョンのメソッドを上書きします。 |
RTR ファイルが変更されなかったので、リソースを登録または移行する必要はありません。 |
リソースタイプパッケージのインストール要件
新しいリソースタイプをインストールするときは、次の 2 つの要件が満たされていなければなりません。
-
リソースタイプが登録されている場合、ディスク上の RTR ファイルにアクセスできなければなりません。
-
新しいタイプのリソースを作成した場合、新しいタイプの宣言済みメソッドのパス名および監視プログラムがディスク上に存在し、実行できなければなりません。リソースが使用されている間は、以前のメソッドおよび監視プログラムを定位置に確保しておく必要があります。
最適のパッケージを決定するため、リソースタイプの実装者は、次のことを考慮する必要があります。
-
RTR ファイルが変更されたか
-
プロパティのデフォルト値または tunable 属性が変更されたか
-
プロパティの min または max 値が変更されたか
-
アップグレードによってプロパティが追加されたか、または削除されたか
-
メソッドコードが変更されたか
-
モニターコードが変更されたか
-
新しいメソッドまたはモニターコードが以前のバージョンのものと互換するか
-
RTR ファイルの変更前に認識しておくべき事項
リソースタイプをアップグレードしても、新しいメソッドまたはモニターコードが呼び出されない場合がありますたとえば、リソースプロパティのデフォルト値または tunable 属性の値だけが変更される場合があります。メソッドコードは変更されないので、読み取り可能な RTR ファイルの有効なパス名を指定するだけでアップグレードをインストールできます。
古いリソースタイプを登録し直す必要がない場合、新しい RTR ファイルによって以前のバージョンのものが上書きされます。それ以外の場合、新しい RTR ファイルは新しいパス名で配置できます。
アップグレードによってプロパティのデフォルト値または tunable 属性が変更される場合、移行時に新しいバージョンの Validate メソッドで既存のプロパティ属性が新しいリソースタイプでも有効かどうかを検査できます。アップグレードによってプロパティの min、max または type 属性が変更される場合、移行時に scrgadm コマンドでこれらの制約が自動的に検査されます。
アップグレード文書には、新しいデフォルトのプロパティ値をすべて記載する必要があります。この文書では、システム管理者に、Type_version コマンドを編集するコマンドを使って、新しいリソースタイプのバージョンにプロパティをアップグレードできるように、既存のリソースプロパティの値を変更できることを通知します。
アップグレードによってプロパティが追加または削除される場合、コールバックメソッドまたはモニターコードの一部を変更しなければならないことがあります。
モニターコードの変更
更新後のリソースタイプでモニターコードだけが変更される場合、パッケージのインストールによってモニターのバイナリが上書きされます。文書には、システム管理者向けの情報として、新しいパッケージをインストールする前に監視を一時停止する指示を記述します。
メソッドコードの変更
更新後のリソースタイプでメソッドコードだけが変更される場合、新しいメソッドコードが以前のバージョンのものと互換するかどうかを確認する必要があります。これにより、新しいメソッドコードを新しいパス名で格納するか、古いメソッドを上書きするかが決定します。
新しい Stop、Postnet_stop および Fini メソッドが宣言されていて、古いバージョンの Start 、Prenet_stop または Init メソッドによって初期化または起動されたリソースに適用できる場合、新しいメソッドで古いメソッドを上書きできます。
新しいメソッドコードが以前のバージョンのものと互換しない場合、アップグレードされたリソースタイプに移行する前に、古いバージョンのメソッドを使ってリソースを停止または構成を解除する必要があります。新しいメソッドが古いメソッドを上書きする場合、リソースタイプをアップグレードする前に、そのタイプのすべてのリソースを停止 (場合によっては、さらに管理対象外に設定) しなければならないことがあります。新しいメソッドが古いものと別の場所に格納されていて、両方に同時にアクセスできる場合は、後方互換性がなくても、新しいリソースタイプのバージョンをインストールし、リソースを 1 つずつアップグレードすることができます。
新しいメソッドに後方互換性がある場合でも、その他のリソースが古いメソッドを使用し続けている間は、リソースを 1 つずつアップグレードして、新しいメソッドを使用できるようにする必要があります。また、新しいメソッドは、古いメソッドを上書きすることがないように別のディレクトリに格納する必要があります。
個々のリソースタイプのバージョンのメソッドを別々のディレクトリに格納すると、新しいバージョンで問題が発生したとき、元のリソースタイプのバージョンに切り替える手続きが簡単であるという点で有利です。
引き続きサポートされている以前のバージョンをすべてパッケージに含めるという方法もあります。この方法では、古いメソッドのパスを上書きまたは削除することなく、新しいパッケージのバージョンで古いバージョンを置き換えることができます。サポートされる以前のバージョンの数は、リソースタイプ開発者が決定します。
注 –
メソッド、または現在クラスタ内にあるノード上の pkgrm/ pkgadd メソッドの上書きはお勧めしません。RGM がディスク上のアクセス不能なメソッドを呼び出そうとすると、予測できない結果を招くことがあります。実行中のメソッドのバイナリの削除または置き換えでも、予測できない結果を招く可能性があります。
- © 2010, Oracle Corporation and/or its affiliates