第 4 章 リソースタイプの変更

この章では、リソースタイプを変更するために理解しておく必要がある問題を説明します。また、クラスタ管理者がリソースを更新できるようにする手段についても説明します。

この章の内容は次のとおりです。

• 「リソースタイプの変更の概要」

• 「リソースタイプ登録ファイルの内容の設定」

• 「クラスタ管理者がアップグレードする際の処理」

• 「リソースタイプモニターコードの実装」

• 「インストール要件とパッケージの決定」

• 「変更されたリソースタイプに提供すべき文書」

リソースタイプの変更の概要

クラスタ管理者は、次の作業を実行できる必要があります。

• 既存のリソースタイプの新しいバージョンをインストールおよび登録する

• 特定のリソースタイプの複数のバージョンの登録を許可する

• リソースを削除し再作成することなく、既存のリソースを新しいバージョンのリソースタイプにアップグレードする

ユーザーがアップグレードしようとするリソースタイプは「アップグレード対応」リソースタイプと呼ばれます。

ユーザーが変更する既存のリソースタイプの要素には次のものがあります。

• リソースタイププロパティーの属性

• 標準プロパティー、拡張プロパティーを含む宣言済みリソースプロパティーセット

• default、 min、max、arraymin、arraymax 、tunability などのリソースプロパティーの属性

• 宣言済みメソッドのセット

• メソッドやモニターの実装

リソースタイプ開発者は、アプリケーションコードを変更する際に必ずしもリソースタイプを変更する必要はありません。

リソースタイプ開発者は、クラスタ管理者がリソースタイプをアップグレードできるようにするツールを提供するための要件を理解する必要があります。この章では、これらのツールを設定するために知っておく必要がある事項について説明します。

リソースタイプ登録ファイルの内容の設定

ここでは、リソースタイプ登録ファイルの設定方法について説明します。

この章の内容は次のとおりです。

• 「リソースタイプ名」

• 「#$upgrade および #$upgrade_from ディレクティブの指定」

• 「RTR ファイルでの RT_version の変更」

• 「以前のバージョンの Sun Cluster のリソースタイプ名」

リソースタイプ名

リソースタイプ名の 3 つのコンポーネントは、vendor-id、resource-type、rt-version として、RTR ファイルで指定されているプロパティーです。clresourcetype(1CL) コマンドは、ピリオドとコロンの区切り文字を挿入して次のリソースタイプの名前を作成します。

vendor-id.resource-type:rt-version

vendor-id 接頭辞は、異なる会社が提供する同じ名前の 2 つの登録ファイルを区別する役目を果たします。vendor-id が一意であることを保証するためには、リソースタイプを作成した時点の会社の株式の略号を使用します。 rt-version は、同じベースリソースタイプの複数の登録バージョン (アップグレード) を識別します。

次のコマンドを入力することで、完全修飾リソースタイプ名を取得できます。

# scha_resource_get -O Type -R resource-name -G resource-group-name

Sun Cluster 3.1 以前に登録されたリソースタイプ名は、引き続き次の構文を使用します。

vendor-id.resource-type

リソースタイプ名の形式は、「リソースタイプ名の形式」で説明されています。

#$upgrade および #$upgrade_from ディレクティブの指定

変更するリソースタイプがアップグレード対応であるようにするには、リソースタイプの RTR ファイルに #$upgrade ディレクティブを含めます。 #$upgrade ディレクティブのあと、サポートするリソースタイプの各旧バージョンに対して 0 個以上の #$upgrade_from ディレクティブを追加します。

#$upgrade および #$upgrade_from ディレクティブは、RTR ファイルのリソースタイププロパティー宣言と、リソース宣言のセクションの間に存在する必要があります。詳細は、rt_reg(4) のマニュアルページを参照してください。

例 4–1 RTR ファイルの #$upgrade_from ディレクティブ

#$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

#$upgrade_from ディレクティブの形式は次のとおりです。

#$upgrade_from version tunability

version

RT_version。リソースタイプにバージョンがない場合、または以前に RTR ファイルで定義したバージョン以外のバージョンに対しては、空の文字列 (“”) を指定します。

tunability

クラスタ管理者が指定の RT_version をアップグレードできる条件または時点。

#$upgrade_from ディレクティブでは次の Tunable 属性の値を使用します。

ANYTIME

クラスタ管理者がリソースをアップグレードできる時点に対して制限がない場合に使用します。リソースは、アップグレード中完全にオンラインになることができます。

WHEN_UNMONITORED

新しいリソースタイプバージョンのメソッドが次のような場合に使用します。

• Update、Stop、Monitor_check、Postnet_stop メソッドが、古いリソースタイプバージョンの起動メソッド (Prenet_stop および Start) と互換性がある

• Fini メソッドが、古いバージョンの Init メソッドと互換性がある

クラスタ管理者は、アップグレードの前にリソース監視プログラムのみを停止する必要があります。

WHEN_OFFLINE

新しいリソースタイプバージョンの Update、 Stop、Monitor_check、Postnet_stop メソッドが次のような場合に使用します。

• 古いバージョンの Init メソッドと互換性がある

• 古いリソースタイプバージョンの起動メソッド (Prenet_stop および Start) と互換性がない

クラスタ管理者は、アップグレードの前にリソースをオフラインにする必要があります。

WHEN_DISABLED

WHEN_OFFLINE と同様です。ただし、クラスタ管理者はアップグレードの前にリソースを無効にする必要があります。

WHEN_UNMANAGED

新しいリソースタイプバージョンの Fini メソッドが、古いバージョンの Init メソッドと互換性がない場合に使用します。クラスタ管理者はアップグレードの前に、既存のリソースグループを管理されていない状態に切り替える必要があります。

リソースタイプのバージョンが #$upgrade_from ディレクティブのリストに存在しない場合、RGM により WHEN_UNMANAGED の Tunable 属性はデフォルトでそのバージョンにされます。

AT_CREATION

既存のリソースが、新しいバージョンのリソースタイプにアップグレードされるのを防ぐために使用します。クラスタ管理者はリソースを削除し、再作成する必要があります。

RTR ファイルでの RT_version の変更

RTR ファイルの内容が変更されても、そのたびに RTR ファイルの RT_version プロパティーを変更するだけで済みます。このバージョンのリソースタイプが最新バージョンであることを明確に示す、このプロパティーの値を選択します。

RTR ファイルの RT_version 文字列には次の文字を含めないでください。次の文字を含めると、リソースタイプの登録が失敗します。

• スペース

• タブ

• スラッシュ (/)

• 逆スラッシュ (\)

• アスタリスク (*)

• 疑問符 (?)

• コンマ (,)

• セミコロン (;)

• 左角括弧 ([)

• 右角括弧 (])

RT_version プロパティは、Sun Cluster 3.0 まではオプションですが、Sun Cluster 3.1 以降のリリースでは必須です。

以前のバージョンの Sun Cluster のリソースタイプ名

次に示すように、Sun Cluster 3.0 のリソースタイプ名には、バージョン接尾辞がありません。

vendor-id.resource-type

Sun Cluster 3.0 で登録したリソースタイプの名前については、Sun Cluster 3.1 および Sun Cluster 3.2 でもこの構文が保たれます。RTR ファイルを、#$upgrade が省略された Sun Cluster 3.1 または Sun Cluster 3.2 で登録した場合でも、リソースタイプ名はこの構文に従います。

クラスタ管理者は、Sun Cluster 3.0 では、#$upgrade ディレクティブや #$upgrade_from ディレクティブを使った RTR ファイルの登録は可能ですが、Sun Cluster 3.0 では、既存のリソースの新しいリソースタイプへのアップグレードはサポートされません。

クラスタ管理者がアップグレードする際の処理

リソースタイプをアップグレードする時点でクラスタ管理者が行わなければならない処理、およびシステムにより行われる処理を次に示します。

• 既存のリソースプロパティー属性が新しいリソースタイプのバージョンの妥当性検査の条件を満たしていない場合、クラスタ管理者は有効な値を指定する必要があります。

  クラスタ管理者は、次の条件のもとで有効な値を提供する必要があります。

  • リソースタイプの新しいバージョンが、以前のバージョンでは宣言されていなかったプロパティーを使用し、デフォルト値がない場合。

  • 既存のリソースが、新しいバージョンでは値が宣言されていないか無効であるプロパティーを使用している場合。リソースタイプの新しいバージョンでは宣言されていない宣言済みプロパティーは、リソースから削除されます。

• サポートされていないバージョンのリソースタイプからアップグレードを試みると失敗します。

• アップグレード後、リソースは、新しいバージョンのリソースタイプから、すべてのプロパティーのリソースプロパティー属性を継承します。

• RTR ファイルでリソースタイプのデフォルト値を変更すると、既存のリソースにより新しいデフォルト値が継承されます。プロパティーが AT_CREATION または WHEN_DISABLED のみで tunable に宣言されている場合であっても、新しいデフォルト値は継承されます。クラスタ管理者が作成する同じタイプのプロパティーも、このデフォルト値を継承します。ただし、クラスタ管理者がプロパティーに新しいデフォルト値を指定する場合、RTR ファイルで指定されているデフォルト値よりも、新しいデフォルト値が優先されます。

Sun Cluster 3.0 で作成されたリソースは、それ以降のバージョンの Sun Cluster にアップグレードされたときに、リソースタイプから新しいデフォルトリソースプロパティー属性を継承しません。この制限は、Sun Cluster 3.0 クラスタからアップグレードされた Sun Cluster 3.1 クラスタのみに適用されます。クラスタ管理者は、プロパティーに値を指定し、デフォルトよりも優先させることによって、この制限に対処できます。

リソースタイプモニターコードの実装

クラスタ管理者は Sun Cluster 3,0 のアップグレード対応のリソースタイプを登録できます。ただし、Sun Cluster ではバージョン接尾辞の付かないリソースタイプ名が記録されます。このリソースタイプのモニターコードを Sun Cluster 3.0 および Sun Cluster 3.1 で正しく実行するためには、そのモニターコードで次の命名規則の両方を処理できるようにする必要があります。

vendor-id.resource-type:rt-version
vendor-id.resource-type

リソースタイプ名の形式は、「リソースタイプ名の形式」で説明されています。

クラスタ管理者は、2 つの異なる名前の下で、同じバージョンのリソースタイプを 2 回登録することはできません。モニターコードが正しい名前を判断できるようにするには、モニターコードで次のコマンドを呼び出します。

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

続いて、出力値と vers を比較します。vers の特定の値に対して、これらのコマンドのいずれか 1 つのみが成功します。

インストール要件とパッケージの決定

リソースタイプパッケージのインストール要件とパッケージを決定する際には、次の 2 つの要件を考慮します。

• 新しいリソースタイプが登録されている場合、ディスク上の RTR ファイルにアクセスできなければなりません。

• 新しいタイプのリソースを作成した場合、新しいタイプのすべての宣言済みメソッドのパス名および監視プログラムがディスク上に存在し、実行可能でなければなりません。リソースが使用されている間は、以前のメソッドおよび監視プログラムを定位置に確保しておく必要があります。

使用すべき適切なパッケージを決定するには、次の点を考慮する必要があります。

• RTR ファイルが変更されたか

• プロパティーのデフォルト値または tunable 属性が変更されたか

• プロパティーの min または max 値が変更されたか

• アップグレードによってプロパティーが追加されたか、または削除されたか

• モニターコードが変更されたか

• メソッドコードが変更されたか

• 新しいメソッド、モニターコード、またはその両方が以前のバージョンと互換性があるか

これらの点を確認しておくと、新しいリソースタイプに使用する適切なパッケージの決定に役立ちます。

RTR ファイルを変更する前に

リソースタイプを変更する場合、必ずしも新しいメソッドやモニターコードを作成する必要はありません。たとえば、リソースプロパティーのデフォルト値や Tunable 属性のみを変更する場合があります。この場合、メソッドコードを変更していないため、読み取り可能な RTR ファイルへの新しい有効なパス名のみが必要になります。

古いリソースタイプを再登録する必要がない場合、新しい RTR ファイルは以前のバージョンを上書きできます。再登録する必要がある場合、新しいパスに新しい RTR ファイルを配置します。

アップグレードによりプロパティーのデフォルト値または Tunable 属性が変更された場合、リソースタイプの新しいバージョンに対して Validate メソッドを使用し、既存のプロパティー属性が新しいリソースタイプに対して有効であることを確認します。有効でない場合、クラスタ管理者は既存のリソースのプロパティーを正しい値に変更できます。アップグレードによりプロパティーの min、max、または type 属性が変更された場合、クラスタ管理者がリソースタイプをアップグレードするときに、clresourcetype(1CL) コマンドによってこれらの制約の有効性が自動的に確認されます。

アップグレードにより新しいプロパティーが追加された場合や古いプロパティーが削除された場合、通常、コールバックメソッドまたはモニターコードを変更する必要があります。

モニターコードの変更

リソースタイプのモニターコードのみを変更した場合、パッケージのインストールではモニターのバイナリを上書きできます。

メソッドコードの変更

リソースタイプでメソッドコードのみを変更した場合、新しいメソッドコードが古いメソッドコードと互換性があるかどうかを判断する必要があります。この判断により、新しいメソッドコードを新しいパス名で格納する必要があるかどうか、または古いメソッドを上書きできるかどうかが決定します。

古いバージョンの Start、Prenet_stop、Init メソッドにより初期化または起動されたリソースに対して、新しい Stop、Postnet_stop、Fini メソッド (宣言されている場合) を適用できる場合は、新しいメソッドで古いメソッドを上書きできます。

プロパティーに新しいデフォルト値を適用することで、Stop、Postnet_stop、Fini などのメソッドが失敗する場合、リソースタイプのアップグレード時に、クラスタ管理者はそれに従ってリソースの状態を制限する必要があります。

Type_version プロパティーの Tunable 属性を制限することにより、クラスタ管理者が、アップグレード時のリソースの状態を制限できるようにすることができます。

パッケージの 1 つの方法としては、引き続きサポートされている以前のバージョンのリソースタイプをすべてパッケージに含めるという方法もあります。この方法では、メソッドへの古いパスを上書きまたは削除することなく、新しいパッケージのバージョンで古いバージョンのパッケージを置き換えることができます。サポートする以前のバージョンの数は、リソースタイプ開発者が決定する必要があります。

使用するパッケージスキーマの決定

次の表に、新しいリソースタイプに使用すべきパッケージスキーマの概要を示します。

変更されたリソースタイプに提供すべき文書

『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「リソースタイプの更新」では、クラスタ管理者に対するリソースタイプのアップグレード方法が説明されています。変更されるリソースタイプをクラスタ管理者がアップグレードできるようにするには、上記の手順に、この節で説明する追加情報を補足します。

通常、新しいリソースタイプを作成する場合、次の内容を含む文書を提供する必要があります。

• 追加、変更、または削除するプロパティーを説明する

• プロパティーを新しい要件に準拠させる方法を説明する

• リソースに対する Tunable 属性の制約を記載する

• 新しいデフォルトプロパティー属性を述べる

• 必要に応じて、既存のリソースプロパティーを適切な値に設定できることをクラスタ管理者に通知する

アップグレードのインストール前に実行すべき事柄に関する情報

次のように、ノード上でのアップグレードパッケージのインストール前に実行すべき事柄を、クラスタ管理者に説明します。

• アップグレードパッケージが既存のメソッドを上書きする場合、非クラスタモードでノードを再起動するようクラスタ管理者に指示します。

• アップグレードパッケージはモニターコードのみを更新し、メソッドコードを変更しない場合は、ノードをクラスタモードで実行し続けるようクラスタ管理者に通知します。また、すべてのリソースタイプの監視をオフにするようクラスタ管理者に通知します。

• アップグレードパッケージは RTR ファイルのみを更新し、モニターコードを変更しない場合は、ノードをクラスタモードで実行し続けるようクラスタ管理者に通知します。また、すべてのリソースタイプの監視をオンのままにするようクラスタ管理者に通知します。

リソースをアップグレードする時点に関する情報

リソースを新しいバージョンのリソースタイプにアップグレードできる時点をクラスタ管理者に説明します。

クラスタ管理者がリソースタイプをアップグレードできる条件は、次に示すように、RTR ファイル内のリソースの各バージョンの #$upgrade_from ディレクティブの Tunable 属性に依存します。

• いつでもよい (ANYTIME)

• リソースが監視されてない場合のみ (WHEN_UNMONITORED)

• リソースがオフラインである場合のみ (WHEN_OFFLINE)

• リソースが無効である場合のみ (WHEN_DISABLED)

• リソースグループが管理されていない場合のみ (WHEN_UNMANAGED )

例 4–2 クラスタ管理者がアップグレードできる時点を #$upgrade_from が定義する方法

次の例では、#$upgrade_from ディレクティブの Tunable 属性が、クラスタ管理者がリソースを新しいバージョンのリソースタイプにアップグレードできる条件にどのように影響するかを示します。

#$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

リソースプロパティーに対する変更に関する情報

クラスタ管理者がアップグレードを行う時点で、クラスタ管理者による既存のリソースのプロパティーの変更を要求するリソースタイプに対して行われたすべての変更を説明します。

可能な変更には次のものが含まれます。

• 変更された既存のリソースタイププロパティーのデフォルト設定

• 導入されたリソースタイプの新しい拡張プロパティー

• 取り消されたリソースタイプの既存のプロパティー

• リソースタイプに対して宣言された標準プロパティーのセットに対する変更

• 変更されたリソースプロパティー (min、max、arraymin、arraymax、 default、tunability など) の属性

• 宣言されたメソッドのセットに対する変更

• 変更されたメソッドまたは障害モニターの実装