この章では、リソースタイプを変更するために理解しておく必要がある問題を説明します。また、クラスタ管理者がリソースを更新できるようにする手段についても説明します。
この章の内容は次のとおりです。
既存のリソースタイプの新しいバージョンをインストールおよび登録する
特定のリソースタイプの複数のバージョンの登録を許可する
リソースを削除し再作成することなく、既存のリソースを新しいバージョンのリソースタイプにアップグレードする
ユーザーがアップグレードしようとするリソースタイプは「アップグレード対応」リソースタイプと呼ばれます。ユーザーが変更する既存のリソースタイプの要素には次のものがあります。
リソースタイププロパティーの属性
標準プロパティー、拡張プロパティーを含む宣言済みリソースプロパティーセット
default、 min、max、arraymin、arraymax 、tunability などのリソースプロパティーの属性
宣言済みメソッドのセット
メソッドやモニターの実装
リソースタイプ開発者は、アプリケーションコードを変更する際に必ずしもリソースタイプを変更する必要はありません。
リソースタイプ開発者は、クラスタ管理者がリソースタイプをアップグレードできるようにするツールを提供するための要件を理解する必要があります。この章では、これらのツールを設定するために知っておく必要がある事項について説明します。
リソースタイプ名の 3 つのコンポーネントは、vendor-id、 resource-type、rt-version として、RTR ファイルで指定されているプロパティーです。scrgadm コマンドにより、ピリオドとコロンの区切り文字が挿入され、リソースタイプの名前が作成されます。
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
リソースタイプ名の形式は、「リソースタイプ名の形式」で説明されています。
変更するリソースタイプがアップグレード対応であるようにするには、リソースタイプの RTR ファイルに #$upgrade ディレクティブを含めます。 #$upgrade ディレクティブのあと、サポートするリソースタイプの各旧バージョンに対して 0 個以上の #$upgrade_from ディレクティブを追加します。
#$upgrade および #$upgrade_from ディレクティブは、RTR ファイルのリソースタイププロパティー宣言と、リソース宣言のセクションの間に存在する必要があります。rt_reg(4) のマニュアルページを参照してください。
#$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
RT_version。リソースタイプにバージョンがない場合、または以前に RTR ファイルで定義したバージョン以外のバージョンに対しては、空の文字列 (“”) を指定します。
クラスタ管理者が指定の RT_version をアップグレードできる条件または時点。
#$upgrade_from ディレクティブでは次の Tunable 属性の値を使用します。
クラスタ管理者がリソースをアップグレードできる時点に対して制限がない場合に使用します。リソースは、アップグレード中完全にオンラインになることができます。
新しいリソースタイプバージョンのメソッドが次のような場合に使用します。
Update、Stop、Monitor_check、Postnet_stop メソッドが、古いリソースタイプバージョンの起動メソッド (Prenet_stop および Start) と互換性がある
Fini メソッドが、古いバージョンの Init メソッドと互換性がある
クラスタ管理者は、アップグレードの前にリソース監視プログラムのみを停止する必要があります。
新しいリソースタイプバージョンの Update、 Stop、Monitor_check、Postnet_stop メソッドが次のような場合に使用します。
古いバージョンの Init メソッドと互換性がある
古いリソースタイプバージョンの起動メソッド (Prenet_stop および Start) と互換性がない
クラスタ管理者は、アップグレードの前にリソースをオフラインにする必要があります。
WHEN_OFFLINE と同様です。ただし、クラスタ管理者はアップグレードの前にリソースを無効にする必要があります。
新しいリソースタイプバージョンの Fini メソッドが、古いバージョンの Init メソッドと互換性がない場合に使用します。クラスタ管理者はアップグレードの前に、既存のリソースグループを管理されていない状態に切り替える必要があります。
リソースタイプのバージョンが #$upgrade_from ディレクティブのリストに存在しない場合、RGM により WHEN_UNMANAGED の Tunable 属性はデフォルトでそのバージョンにされます。
既存のリソースが、新しいバージョンのリソースタイプにアップグレードされるのを防ぐために使用します。クラスタ管理者はリソースを削除し、再作成する必要があります。
RTR ファイルの内容が変更されたときにのみ、常に RTR ファイルの RT_version プロパティーを変更する必要があります。このバージョンのリソースタイプが最新バージョンであることを明確に示す、このプロパティーの値を選択します。
RTR ファイルの RT_version 文字列には次の文字を含めないでください。次の文字を含めると、リソースタイプの登録が失敗します。
スペース
タブ
スラッシュ (/)
バックスラッシュ (\)
アスタリスク (*)
疑問符 (?)
コンマ (,)
セミコロン (;)
左角括弧 ([)
右角括弧 (])
RT_version プロパティーは、Sun Cluster 3.0 ではオプションですが、Sun Cluster 3.1 以降では必須です。
次に示すように、Sun Cluster 3.0 のリソースタイプ名には、バージョン接尾辞がありません。
vendor-id.resource-type
元々 Sun Cluster 3.0 で登録されたリソースタイプは、クラスタ管理者がクラスタリングソフトウェアを Sun Cluster 3.1 以降のリリースにアップグレードしたあとも、引き続きこの構文に従う名前を持ちます。同様に、少なくとも Sun Cluster 3.1 を実行するクラスタで RTR ファイルを登録した場合でも、RTR ファイル内に #$upgrade ディレクティブがないリソースタイプには、(バージョン接尾辞のない) Sun Cluster 3.0 の形式の名前が付与されます。
クラスタ管理者は、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 と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 値が変更されたか
アップグレードによってプロパティーが追加されたか、または削除されたか
モニターコードが変更されたか
メソッドコードが変更されたか
新しいメソッド、モニターコード、またはその両方が以前のバージョンと互換性があるか
これらの点を確認しておくと、新しいリソースタイプに使用する適切なパッケージの決定に役立ちます。
リソースタイプを変更する場合、必ずしも新しいメソッドやモニターコードを作成する必要はありません。たとえば、リソースプロパティーのデフォルト値や Tunable 属性のみを変更する場合があります。この場合、メソッドコードを変更していないため、読み取り可能な RTR ファイルへの新しい有効なパス名のみが必要になります。
古いリソースタイプを再登録する必要がない場合、新しい RTR ファイルは以前のバージョンを上書きできます。再登録する必要がある場合、新しいパスに新しい RTR ファイルを配置します。
アップグレードによりプロパティーのデフォルト値または Tunable 属性が変更された場合、リソースタイプの新しいバージョンに対して Validate メソッドを使用し、既存のプロパティー属性が新しいリソースタイプに対して有効であることを確認します。有効でない場合、クラスタ管理者は既存のリソースのプロパティーを正しい値に変更できます。アップグレードによりプロパティーの min、max 、type 属性が変更された場合、クラスタ管理者がリソースタイプをアップグレードした時点で、scrgadm コマンドによりこれらの制約が自動的に検証されます。
アップグレードにより新しいプロパティーが追加された場合や古いプロパティーが削除された場合、通常、コールバックメソッドまたはモニターコードを変更する必要があります。
リソースタイプのモニターコードのみを変更した場合、パッケージのインストールではモニターのバイナリを上書きできます。
リソースタイプでメソッドコードのみを変更した場合、新しいメソッドコードが古いメソッドコードと互換性があるかどうかを判断する必要があります。この判断により、新しいメソッドコードを新しいパス名で格納する必要があるかどうか、または古いメソッドを上書きできるかどうかが決定します。
古いバージョンの Start、Prenet_stop、Init メソッドにより初期化または起動されたリソースに対して、新しい Stop、Postnet_stop、Fini メソッド (宣言されている場合) を適用できる場合は、新しいメソッドで古いメソッドを上書きできます。
プロパティーに新しいデフォルト値を適用することで、Stop、Postnet_stop、Fini などのメソッドが失敗する場合、リソースタイプのアップグレード時に、クラスタ管理者はそれに従ってリソースの状態を制限する必要があります。
Type_version プロパティーの Tunable 属性を制限することにより、クラスタ管理者が、アップグレード時のリソースの状態を制限できるようにすることができます。
パッケージの 1 つの方法としては、引き続きサポートされている以前のバージョンのリソースタイプをすべてパッケージに含めるという方法もあります。この方法では、メソッドへの古いパスを上書きまたは削除することなく、新しいパッケージのバージョンで古いバージョンのパッケージを置き換えることができます。サポートする以前のバージョンの数は、リソースタイプ開発者が決定する必要があります。
次の表に、新しいリソースタイプに使用すべきパッケージスキーマの概要を示します。
表 4–1 使用するパッケージスキーマの決定
変更のタイプ |
Tunable 属性の値 |
パッケージスキーマ |
---|---|---|
RTR ファイルのみでプロパティーを変更します。 |
ANYTIME |
新しい RTR ファイルのみを提供します。 |
メソッドを更新します。 |
ANYTIME |
古いメソッドとは異なるパスに、更新されたメソッドを配置します。 |
新しい監視プログラムをインストールします。 |
WHEN_UNMONITORED |
モニターの直前のバージョンのみを上書きします。 |
メソッドを更新します。 新しい Update および Stop メソッドと古い Start メソッドの間には互換性がありません。 |
WHEN_OFFLINE |
古いメソッドとは異なるパスに、更新されたメソッドを配置します。 |
メソッドを更新し、RTR ファイルに新しいプロパティーを追加します。新しいメソッドには新しいプロパティーが必要です。 目的は、ノード上でリソースグループがオフライン状態からオンライン状態に移行した場合に、リソースの所属リソースグループをオンラインのまま保持しながらリソースがオンラインになるのを防ぐことです。 |
WHEN_DISABLED |
以前のバージョンのメソッドを上書きします。 |
メソッドを更新し、RTR ファイルに新しいプロパティーを追加します。新しいメソッドは新しいプロパティーを必要としません。 |
ANYTIME |
以前のバージョンのメソッドを上書きします。 |
メソッドを更新します。新しい Fini メソッドと古い Init メソッドには互換性がありません。 |
WHEN_UNMANAGED |
古いメソッドとは異なるパスに、更新されたメソッドを配置します。 |
メソッドを更新します。RTR ファイルは変更されていません。 |
該当しません。RTR ファイルは変更されていません。 |
以前のバージョンのメソッドを上書きします。RTR ファイルには変更を加えていないため、リソースを登録またはアップグレードする必要はありません。 |
『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「リソースタイプの更新」では、クラスタ管理者に対するリソースタイプのアップグレード方法が説明されています。変更されるリソースタイプをクラスタ管理者がアップグレードできるようにするには、上記の手順に、この節で説明する追加情報を補足します。
通常、新しいリソースタイプを作成する場合、次の内容を含む文書を提供する必要があります。
追加、変更、または削除するプロパティーを説明する
プロパティーを新しい要件に準拠させる方法を説明する
新しいデフォルトプロパティー属性を述べる
必要に応じて、既存のリソースプロパティーを適切な値に設定できることをクラスタ管理者に通知する
次のように、ノード上でのアップグレードパッケージのインストール前に実行すべき事柄を、クラスタ管理者に説明します。
アップグレードパッケージが既存のメソッドを上書きする場合、非クラスタモードでノードを再起動するようクラスタ管理者に指示します。
アップグレードパッケージはモニターコードのみを更新し、メソッドコードを変更しない場合は、ノードをクラスタモードで実行し続けるようクラスタ管理者に通知します。また、すべてのリソースタイプの監視をオフにするようクラスタ管理者に通知します。
アップグレードパッケージは RTR ファイルのみを更新し、モニターコードを変更しない場合は、ノードをクラスタモードで実行し続けるようクラスタ管理者に通知します。また、すべてのリソースタイプの監視をオンのままにするようクラスタ管理者に通知します。
リソースを新しいバージョンのリソースタイプにアップグレードできる時点をクラスタ管理者に説明します。クラスタ管理者がリソースタイプをアップグレードできる条件は、次に示すように、RTR ファイル内のリソースの各バージョンの #$upgrade_from ディレクティブの Tunable 属性に依存します。
いつでもよい (ANYTIME)
リソースが監視されてない場合のみ (WHEN_UNMONITORED)
リソースがオフラインである場合のみ (WHEN_OFFLINE)
リソースが無効である場合のみ (WHEN_DISABLED)
リソースグループが管理されていない場合のみ (WHEN_UNMANAGED )
次の例では、#$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
バージョン |
クラスタ管理者がリソースをアップグレードできる時点 |
---|---|
1.1、1.2、1.3 |
リソースがオフラインのときのみ |
2.0 |
リソースが監視されていないときのみ |
2.1 |
任意の時点 (Anytime) |
そのほかのすべてのバージョン |
リソースグループが管理されていないときのみ |
クラスタ管理者がアップグレードを行う時点で、クラスタ管理者による既存のリソースのプロパティーの変更を要求するリソースタイプに対して行われたすべての変更を説明します。可能な変更には次のものが含まれます。
変更された既存のリソースタイププロパティーのデフォルト設定
導入されたリソースタイプの新しい拡張プロパティー
取り消されたリソースタイプの既存のプロパティー
リソースタイプに対して宣言された標準プロパティーのセットに対する変更
変更されたリソースプロパティー (min、max、arraymin、arraymax、 default、tunability など) の属性
宣言されたメソッドのセットに対する変更
変更されたメソッドまたは障害モニターの実装