CAA (Cluster Application Availability) サブシステムは,クラスタ内のメンバやリソース (ネットワーク,アプリケーション,テープ装置,およびメディア・チェンジャなど) の状態を維持管理します。CAA は,クラスタ内のアプリケーション・リソースが必要とするリソースを監視し,メンバ上で動作しているアプリケーションが要求を満たせるようにします。
この章では,次のことについて説明します。
いつ CAA を使用するか (2.1 節)
リソース・プロファイルの作成 (2.2 節)
処理スクリプトの作成 (2.3 節)
ユーザ定義属性の作成 (2.4 節)
リソースの登録 (2.5 節)
アプリケーション・リソースの起動 (2.6 節)
アプリケーション・リソースの再配置 (2.7 節)
アプリケーション・リソースの分散 (2.8 節)
アプリケーション・リソースの停止 (2.9 節)
アプリケーション・リソースの登録抹消 (2.10 節)
CAA 状態情報の表示 (2.11 節)
グラフィカル・ユーザ・インタフェースを使った CAA の管理 (2.12 節)
CAA の学習 -- チュートリアル (2.13 節)
高可用アプリケーションの作成 -- 例 (2.14 節)
CAA は,一度に 1 つのクラスタ・メンバだけで動作するアプリケーションで使用するように設計されています。アプリケーションを実行しているクラスタ・メンバに障害が発生したか,特定の必須リソースにアクセスできない場合,CAA はアプリケーションを別のメンバに再配置,つまりフェイルオーバします。その別のメンバとは,要求されたリソースを持つメンバか,要求されたリソースを起動できるメンバのどちらかです。
マルチ・インスタンス・アプリケーションでは,アプリケーションを透過的にフェイルオーバするためには,クラスタ別名を使用する方が便利です。マルチ・インスタンス・アプリケーションは,一般的には,第 3 章で説明するように,クラスタ別名を使用することにより,クライアントに対する高可用性を実現します。ただし,CAA では,アプリケーションの簡略化した集中管理 (起動と停止) と障害の発生したインスタンスの再起動が可能になるため,CAA はマルチ・インスタンス・アプリケーションに有用です。CAA を使用すると,rc3
スクリプトを追加で作成しなくても,ブート時とシャットダウン時に,アプリケーションの自動起動およびシャットダウンを行うことができます。
クラスタ別名サブシステムと CAA の違いについては,TruCluster Server の『クラスタ管理ガイド』 を参照してください。また,マルチ・インスタンス・アプリケーションで,省略時のクラスタ別名を使って高可用性を実現する例を第 3 章で示します。
2.2 リソース・プロファイル
リソース・プロファイルには,CAA がリソースを開始して,管理,監視する方法を示す属性があります。プロファイルでは,リソースの依存関係を定義し,依存するリソースにアクセスできなくなったときに,アプリケーションをどうするかを決めます。
リソース・プロファイルには,application
,network
,tape
,および
changer
の 4 種類があります。各リソースには,リソースの属性が定義された独自のリソース・プロファイルがあります。以下の各項の例と表で,それぞれのリソース・プロファイルのタイプとそのプロファイルで使用できる属性について説明します。定義できるプロファイルの詳細な属性リストを含むリソースのタイプごとの定義についての詳細は,2.2.2 項,2.2.3 項,2.2.4 項,および2.2.5 項を参照してください。
リソース・プロファイルで指定する属性の中には,次のものがあります。
アプリケーションに必須のリソース (REQUIRED_RESOURCES
)。CAA は,必須のリソースが利用できなくなったときにアプリケーションを再配置または停止します。
アプリケーションを起動または再起動するメンバを選択するルール (PLACEMENT
)。
アプリケーションの起動時またはフェイルオーバ時に選択できるメンバのリスト (HOSTING_MEMBERS
)。このリストは,配置ポリシ (PLACEMENT
) が
favored
または
restricted
のときに使用され,優先順に並んでいます。
すべてのリソース・プロファイルはクラスタ単位のディレクトリ
/var/cluster/caa/profile
に置かれます。リソース・プロファイルのファイル名は,resource_name.cap
のような形式にします。CAA コマンドでは,リソース名 (resource_name) だけを用いて各リソースを指定します。
プロファイルの各タイプには,必須の属性とオプションの属性があります。オプションのプロファイル属性は,プロファイル内で指定しなくてもかまいません。オプションのプロファイル属性で省略時の値を持つものは,登録時に,そのタイプのテンプレートと共通のテンプレートに保存されている値とマージされます。各リソース・タイプには,TYPE_resource_type.cap
という名前で
/var/cluster/caa/template
に格納されているテンプレート・ファイルがあり,属性の省略時の値が設定されています。すべてのタイプのリソースで使用される値のための共通のテンプレート・ファイルは,/var/cluster/caa/template/TYPE_generic.cap
に格納されています。
以降の各項の例に,リソース・プロファイルの構文の例を示します。シャープ記号 (#) で始まる行はコメント行であり,リソース・プロファイルとしては処理されません。行末のバックスラッシュ (\)
は,次の行に続くことを示します。プロファイルの構文のさらに詳しい説明は,
caa
(4)2.2.1 リソース・プロファイルの作成
アプリケーションの高可用性を実現する最初のステップは,リソース・プロファイルを作成することです。次のいずれかの方法で,リソース・プロファイルを作成することができます。
caa_profile
コマンドを使用する。
SysMan (/usr/sbin/sysman caa
) にアクセスする。この方法では,スケジューリングされたアプリケーションの再分散やフェイルバックの設定はサポートされない。
既存のリソース・プロファイルを
/var/cluster/caa/profile
にコピーし,そのコピーを
emacs
,vi
,またはその他のテキスト・エディタで編集する。
これらの方法を組み合わせて使用することもできます。たとえば,caa_profile
コマンドを使用してリソース・プロファイルを作成したのち,テキスト・エディタを使用して手作業でそのプロファイルを編集することができます。
プロファイルの例がいくつか
/var/cluster/caa/examples
ディレクトリにあります。
リソース・プロファイルを作成したら,それを CAA に登録する必要があります。登録すると,リソースを管理,監視することができます。アプリケーションの登録方法については,2.5 節を参照してください。
2.2.2 アプリケーション・リソース・プロファイル
表 2-1
に,アプリケーション・プロファイルの各種属性を示します。それぞれの属性について,その属性が必須かどうかと省略時の値を示し,その属性について説明します。
表 2-1: アプリケーション・プロファイルの属性
属性 | 必須 | 省略時の値 | 説明 |
TYPE |
はい | なし | リソースのタイプ。アプリケーション・リソースでは,application
タイプを使用。 |
NAME |
はい | なし | リソースの名前。英字 a〜z,A〜Z,数字 0〜9,下線 (_),または ピリオド (.) からなる文字列。ピリオドで始まるリソース名は使用できない。 |
DESCRIPTION |
いいえ | リソースの名前 | リソースの説明 |
FAILURE_THRESHOLD |
いいえ | 0 | CAA が
FAILURE_INTERVAL
の間に検出する失敗の数。この値を超えると,CAA はリソースを利用不可としてマークし監視しなくなる。アプリケーションのチェック・スクリプトがこの回数のために失敗すると,アプリケーション・リソースは停止されてオフラインになる。値がゼロ (0) の場合は,失敗の追跡が無効になる。最大値は 20 である。 |
FAILURE_INTERVAL |
いいえ | 0 | CAA が失敗のしきい値を適用する期間。秒単位で指定。値がゼロ (0) の場合は,失敗の追跡が無効になる。 |
REQUIRED_RESOURCES |
いいえ | なし | このリソースが依存するリソース名の順序付けされたリスト。空白で区切られている。このプロファイルで必須リソースとして使うそれぞれのリソースは,CAA に登録しておかなければならない。登録しておかなければ,プロファイルの登録に失敗する。詳細は,2.2.2.1 項を参照。 |
OPTIONAL_RESOURCES |
いいえ | なし | このリソースの配置の決定時に使用する,順序付けされたオプション・リソースのリスト。空白で区切られている。オプション・リソースは 58 までリストできる。詳細は,2.2.2.3 項を参照。 |
PLACEMENT |
いいえ | balanced |
配置ポリシ (balanced ,favored ,または
restricted ) は,CAA がリソースを起動するクラスタ・メンバを選択する方法を指定する。 |
HOSTING_MEMBERS |
ときどき | なし | リソースを提供できるクラスタ・メンバのリスト。
順番に,空白で区切られてリストされている。この属性は,PLACEMENT
が
favored
または
restricted
の場合にのみ必須で,balanced
の場合には空にしなければならない。 |
RESTART_ATTEMPTS |
いいえ | 1 | CAA が,1 つのクラスタ・メンバ上でリソースを再起動しようと試みる回数。CAA は,この試行回数の後,アプリケーションを再配置しようとする。値が 1 の場合,CAA は 1 つのメンバ上で 1 回だけアプリケーションの再起動を試みる。2 回目の失敗で,アプリケーションを再配置しようとする。 |
FAILOVER_DELAY |
いいえ | 0 | CAA が,リソースを再起動しようとする前に,またはフェイルオーバを行おうとする前に待つ時間。秒単位で指定。 |
AUTO_START |
いいえ | 0 | クラスタのリブートの前にリソースが動作していたかどうかにかかわらず,リブート後に CAA が自動的にリソースを起動するかどうかを示すフラグ。0 の場合,CAA は,アプリケーション・リソースがリブート前に動作していた場合だけこのアプリケーションを起動する。1 の場合,CAA は,リブートの後に無条件にアプリケーションを起動する。 |
ACTION_SCRIPT |
はい | なし | リソースを起動,停止,およびチェックする,リソース固有のスクリプト。処理スクリプト・ファイルのフル・パスを指定する。指定しない場合は,/var/cluster/caa/script
とみなされる。開始点として,この省略時のパスで相対パスを指定してもよい。 |
ACTIVE_PLACEMENT |
いいえ | 0 | 1 に設定すると,CAA は,クラスタ・メンバが追加または再起動されるたびにアプリケーションの配置を再評価する。 |
SCRIPT_TIMEOUT |
いいえ | 60 | 処理スクリプトの実行が完了するまでにかかる時間の最大値。この時間以内に実行が完了しなければ,エラーが返される。秒単位で指定。 |
CHECK_INTERVAL |
いいえ | 60 | リソースの処理スクリプトのチェック・エントリ・ポイントを繰り返し実行する時間間隔。 秒単位で指定。 |
REBALANCE |
いいえ | なし | 最適に配置するためにアプリケーションが自動的に再評価される時間。フィールドには,t:day:hour:min
の形式で指定する必要がある。このフィールドには,再評価が発生する日時,day
には曜日 (0 〜 6),hour
には時間 (0 〜 23),min
には分 (0 〜 59) をそれぞれ指定する。毎日または毎時を指定する場合には,ワイルドカードとしてアスタリスク (*) を使用できる。 |
caa_profile
を使用して,CAA でアプリケーション・リソースを作成する例を次に示します。
# /usr/sbin/caa_profile -create clock -t application -B /usr/bin/X11/xclock \ -d "Clock Application" -r network1 -l application2 \ -a clock.scr -o ci=5,ft=2,fi=12,ra=2,bt=*:12:00
前述の例で作成されたリソース・プロファイル・ファイルの内容を次に示します。
NAME=clock TYPE=application ACTION_SCRIPT=clock.scr ACTIVE_PLACEMENT=0 AUTO_START=0 CHECK_INTERVAL=5 DESCRIPTION=Clock Application FAILOVER_DELAY=0 FAILURE_INTERVAL=12 FAILURE_THRESHOLD=2 REBALANCE=t:*:12:00 HOSTING_MEMBERS= OPTIONAL_RESOURCES=application2 PLACEMENT=balanced REQUIRED_RESOURCES=network1 RESTART_ATTEMPTS=2 SCRIPT_TIMEOUT=60
アプリケーション・リソース・プロファイルの構文の詳細は,
caa_profile
(8)caa
(4)2.2.2.1 必須リソース
CAA は,アプリケーション・リソースを提供できるクラスタ・メンバがどれかを判断するために,必須リソース・リストを,配置ポリシやホスト・メンバ・リストとともに使用します。必須リソースは,アプリケーションが動作しているかまたは起動されたメンバ上で
ONLINE
状態でなければなりません。アプリケーション・リソースのみが必須リソースを持つことができ,どのタイプのリソースでも,必須リソース・リストに定義することができます。
ホスト・メンバ上の必須リソースに障害が発生すると,CAA は,アプリケーションのフェイルオーバを開始するか,RESTART_ATTEMPTS
が 0 でない場合は現在のメンバで再起動を試みます。これにより CAA は,アプリケーション・リソースを,必須リソースが使える他のメンバへフェイルオーバさせます。適切なメンバがない場合は,アプリケーションを停止させます。後者の場合,CAA は引き続き必須リソースを監視し,適切なクラスタ・メンバ上でリソースが再び利用可能になるとアプリケーションを再起動します。
必須リソースのリストは,コマンド
caa_start
,caa_stop
,caa_relocate
を,強制 (-f) オプションを指定して実行する場合に,相互に依存しているアプリケーション・リソースのグループを,起動,停止,再配置するのにも利用できます。
2.2.2.2 アプリケーション・リソース配置ポリシ
配置ポリシでは,CAA がリソースを起動したり,障害の後にリソースを再配置したりするクラスタ・メンバを選択する方法を指定します。
注意
そのアプリケーションに関して配置を決定する際にはいつも,すべての必須リソース (アプリケーション・リソースのプロファイルにリストされている) が利用できるクラスタ・メンバだけが候補として考慮されます。
次の配置ポリシがサポートされています。
balanced
-- CAA は,現在動作しているアプリケーション・リソースが最も少ないメンバ上でのアプリケーション・リソースの起動,または再起動を優先します。オプション・リソース・リストによる配置をまず考えます。2.2.2.3 項を参照してください。次に,実行しているアプリケーション・リソースが最も少ないホストが選択されます。この基準に従っても優先するクラスタ・メンバがない場合には,メンバをランダムに選択します。
favored
-- CAA は,リソース・プロファイルの
HOSTING_MEMBERS
属性のメンバのリストを参照します。このリストにあり,必須リソースを満足するクラスタ・メンバだけが配置の候補として考慮されます。オプション・リソース・リストによる配置をまず考えます。2.2.2.3 項を参照してください。オプション・リソースに基づいてメンバが選択できない場合は,ホスト・メンバの順番により,アプリケーション・リソースを実行するメンバが決定されます。ホスト・メンバ・リストにあるメンバのいずれも利用できない場合,CAA は利用できる任意のメンバ上にアプリケーション・リソースを配置します。このメンバは,HOSTING_MEMBERS
リストに含まれているときも,含まれていないときもあります。
restricted
--
favored
とほとんど同じですが,ホスト・リストのどのメンバも利用できない場合,CAA は,アプリケーション・リソースの起動や再起動を行いません。restricted
配置ポリシを使用することによって,リストにないメンバ上でリソースが実行されないようにできます。そのメンバに,手動で再配置しても同様です。
配置ポリシの
favored
または
restricted
を使用するためには,HOSTING_MEMBERS
属性で,ホスト・メンバを指定する必要があります。配置ポリシの
balanced
を使用する場合には,HOSTING_MEMBERS
にホスト・メンバを指定してはなりません。指定した場合,リソースは無効になり,登録できません
ACTIVE_PLACEMENT
を 1 に設定した場合,クラスタ・メンバがクラスタに追加されるか再起動されるたびにアプリケーションの配置が再評価されます。このようにすると,メンバが障害から復旧したときに,クラスタ内の適切なメンバへアプリケーションを再配置することができます。
クラスタ・メンバがクラスタに再参加するとき以外に,アプリケーションを適切なメンバに再配置するには,REBALANCE
属性を使用して,配置が再評価される時刻を指定します。
2.2.2.3 配置決定の際のオプション・リソース
CAA はオプション・リソース・リストを使用して,各ホスト・メンバ上での
ONLINE
状態のオプション・リソースの数に基づいてホスト・メンバを選択します。どのメンバの
ONLINE
状態のオプション・リソースの数も同じ場合,CAA は,次のようにしてオプション・リソースの順番を決めます。
CAA は,リソース・リストの最初から順に,各メンバのオプション・リソースの状態を比較します。リスト内のリソースそれぞれに対して,あるメンバでそのリソースが
ONLINE
の場合,ONLINE
のリソースを持たないメンバは対象から外されます。リストの各リソースは,リソースを使用するメンバが 1 つになるまでこの方法で評価されます。オプション・リソースの最大個数は 58 です。
このアルゴリズムで複数の優先メンバが選択された場合,その配置ポリシに従って選択された,これらのメンバのうちの 1 つにアプリケーションが配置されます。
2.2.3 ネットワーク・リソース・プロファイル
表 2-2
では,ネットワーク・プロファイルの属性について説明します。各属性について,必須かどうかと省略時の値,および説明を示します。
表 2-2: ネットワーク・プロファイルの属性
属性 | 必須 | 省略時の値 | 説明 |
TYPE |
はい | なし | リソースのタイプ。ネットワーク・リソースのタイプは
network 。 |
NAME |
はい | なし | リソースの名前。英字 a 〜 z,A 〜 Z,数字 0 〜 9,下線 (_),またはピリオド (.) からなる文字列で指定。ピリオドで始まるリソース名は使用できない。 |
DESCRIPTION |
いいえ | なし | リソースの説明。 |
SUBNET |
はい | なし | nnn.nnn.nnn.nnn
形式のネットワーク・リソースのサブネット・アドレス (たとえば,16.140.112.0)。SUBNET
値は,IP アドレスとネットマスクの各ビットの論理積 (AND) をとった値。IP アドレスが 16.69.225.12 で,ネットマスクが 255.255.255.0 の場合,サブネット値は 16.69.225.0 となる。 |
FAILURE_THRESHOLD |
いいえ | 0 | CAA がリソースを使用不可とマークして監視しなくなる直前の,FAILURE_INTERVAL
間で検出された失敗回数。アプリケーションのチェック・スクリプトがこの回数失敗すると,アプリケーション・リソースは停止しオフラインに設定される。値がゼロ (0) の場合は,失敗の追跡が無効になる。最大値は 20 である。 |
FAILURE_INTERVAL |
いいえ | 0 | CAA が障害しきい値と比較する時間間隔 (秒単位)。値がゼロ (0) の場合は,失敗の追跡が無効になる。 |
ネットワーク・リソース・プロファイルを作成するコマンドの例を次に示します。
# /usr/sbin/caa_profile -create network1 -t network -s "16.69.244.0" \ -d "Network1"
前述のコマンドで作成されたファイル
/var/cluster/caa/profile/network1.cap
のプロファイルの内容を次に示します。
NAME=network1 TYPE=network DESCRIPTION=Network1 FAILURE_INTERVAL=0 FAILURE_THRESHOLD=0 SUBNET=16.69.244.0
ネットワーク・リソース・プロファイルの構文の詳細は,
caa_profile
(8)caa
(4)
ルーティングによって,クラスタ内のすべてのメンバは,どのメンバに接続されたネットワークにも間接的にアクセスできますが,アプリケーションによっては,ネットワークに直接接続されたメンバで動作した場合に得られる高い性能を必要とするものがあります。このため,アプリケーション・リソースでは,ネットワーク・リソースへの依存性 (オプションまたは必須) を定義します。CAA は,そのアプリケーション・リソースの配置をネットワーク・リソースの位置に基づいて最適化します。
ネットワーク・リソースを,アプリケーションのオプション・リソース (OPTIONAL_RESOURCES
) として定義した場合,そのアプリケーションは,必須リソース,配置ポリシ,およびクラスタの状態に基づいて,サブネットに直接接続されたメンバ上で起動されます。ネットワーク・アダプタが故障しても,そのアプリケーションはルーティングによって,リモートからそのサブネットにアクセスすることができます。
ネットワーク・リソースを必須リソース (REQUIRED_RESOURCES
) として定義し,ネットワーク・アダプタが故障した場合,CAA は,アプリケーションを再配置するか,または停止します。すべての適切なホスト・メンバとのネットワーク接続に失敗した場合,CAA は,アプリケーションを停止します。
2.2.4 テープ・リソース・プロファイル
表 2-3
で,テープ・プロファイルの属性について説明します。各属性について,必須かどうかと省略時の値,および説明を示します。
表 2-3: テープ・プロファイルの属性
属性 | 必須 | 省略時の値 | 説明 |
TYPE |
はい | なし | リソースのタイプ。テープ・リソースのタイプは
tape 。 |
NAME |
はい | なし | リソースの名前。英字 a 〜 z,A 〜 Z,数字 0 〜 9,下線 (_),またはピリオド (.) からなる文字列で指定。ピリオドで始まるリソース名は使用できない。 |
DESCRIPTION |
いいえ | なし | リソースの説明。 |
DEVICE_NAME |
はい | なし | テープ・リソースのデバイス名。デバイス・スペシャル・ファイルのフル・パスを使用する (たとえば,/dev/tape/tape1 )。 |
FAILURE_THRESHOLD |
いいえ | 0 | CAA がリソースを使用不可とマークして監視しなくなる直前の,FAILURE_INTERVAL
間で検出された失敗回数。アプリケーションのチェック・スクリプトがこの回数失敗すると,アプリケーション・リソースは停止しオフラインに設定される。値がゼロ (0) の場合は,失敗の追跡が無効になる。最大値は 20 である。 |
FAILURE_INTERVAL |
いいえ | 0 | CAA 障害しきい値と比較する時間間隔 (秒単位)。値がゼロ (0) の場合は,失敗の追跡が無効になる。 |
デバイス要求ディスパッチャにより,すべてのクラスタ・メンバは,どのメンバに接続されたテープ装置にも,間接的にアクセスできますが,アプリケーションによっては,テープ装置を直接接続したクラスタ・メンバ上で動作した場合に得られる高い性能を必要とするものがあります。このため,アプリケーション・リソースでは,テープ・リソースへの依存性 (オプションまたは必須) を定義できます。CAA は,そのアプリケーション・リソースの配置を,テープ・リソースの位置に基づいて最適化します。
テープ・リソース・プロファイルを作成する例を次に示します。リソース・プロファイルにテープ・リソースを定義すると,アプリケーション・リソース・プロファイルは,それを必須リソースまたはオプション・リソースとして指定することができます。
# /usr/sbin/caa_profile -create tape1 -t tape -n /dev/tape/tape1 -d "Tape Drive"
前述のコマンドで作成されたファイル
/var/cluster/caa/profile/tape1.cap
のプロファイルの内容を次に示します。
NAME=tape1 TYPE=tape DESCRIPTION=Tape Drive DEVICE_NAME=/dev/tape/tape1 FAILURE_INTERVAL=0 FAILURE_THRESHOLD=0
メディア・チェンジャ装置はテープ装置に似ていますが,複数のテープ・カートリッジにアクセスできます。
表 2-4
では,メディア・チェンジャ・プロファイルの属性について説明します。各属性について,必須かどうかと省略時の値,および説明を示します。
表 2-4: メディア・チェンジャの属性
属性 | 必須 | 省略時の値 | 説明 |
TYPE |
はい | なし | リソースのタイプ。メディア・チェンジャ・リソースのタイプは
changer 。 |
NAME |
はい | なし | リソースの名前。英字 a 〜 z,A 〜 Z,数字 0 〜 9,下線 (_),またはピリオド (.) からなる文字列で指定。ピリオドで始まるリソース名は使用できない。 |
DESCRIPTION |
いいえ | なし | リソースの説明。 |
DEVICE_NAME |
はい | なし | メディア・チェンジャ・リソースのデバイス名。
デバイス・スペシャル・ファイルのフル・パスを使用する (たとえば,/dev/changer/mc1 )。 |
FAILURE_THRESHOLD |
いいえ | 0 | CAA がリソースを使用不可とマークして監視しなくなる直前の,FAILURE_INTERVAL
間で検出された失敗回数。アプリケーションのチェック・スクリプトがこの回数失敗すると,アプリケーション・リソースは停止しオフラインに設定される。値がゼロ (0) の場合は,失敗の追跡が無効になる。最大値は 20 である。 |
FAILURE_INTERVAL |
いいえ | 0 | CAA が障害しきい値と比較する時間間隔 (秒単位)。値がゼロ (0) の場合は,失敗の追跡が無効になる。 |
デバイス要求ディスパッチャにより,すべてのクラスタ・メンバは,どのメンバに接続されたメディア・チェンジャにも,間接的にアクセスできますが,アプリケーションによっては,メディア・チェンジャに直接接続されたメンバ上で動作したときに得られる高い性能を必要とするものがあります。このため,アプリケーション・リソースでは,メディア・チェンジャ・リソースへの依存性 (オプションまたは必須) を定義できます。CAA は,そのアプリケーション・リソースの配置を,メディア・チェンジャ・リソースの位置に基づいて最適化します。
メディア・チェンジャ・リソース・プロファイルを作成する例を次に示します。メディア・チェンジャ・リソースをリソース・プロファイルで定義すると,アプリケーション・リソース・プロファイルでは,それを依存対象として指定することができます。
# /usr/sbin/caa_profile -create mchanger1 -t changer -n /dev/changer/mc1 \ -d "Media Changer Drive"
前述のコマンドで作成されたファイル
/var/cluster/caa/profile/mchanger1.cap
のプロファイルの内容を次に示します。
NAME=mchanger1 TYPE=changer DESCRIPTION=Media Changer Drive DEVICE_NAME=/dev/changer/mc1 FAILURE_INTERVAL=0 FAILURE_THRESHOLD=0
リソース・プロファイルを登録する前に,構文が正しいかどうかを検証できます。プロファイルが検証に合格しない場合には,登録できません。次のように
caa_profile
コマンドを使用して,プロファイルが正しく作成されたことを確認できます。
# /usr/sbin/caa_profile -validate resource
リソースに問題があれば,属性が正しくないというメッセージが適切に表示されます。
2.3 処理スクリプトの作成
CAA が管理,監視するアプリケーションを起動,停止,再配置するために,アプリケーション・リソースには処理スクリプトが必要です。
処理スクリプトを使って,次のことを指定することができます。
アプリケーションの開始方法
CAA は,アプリケーション・リソースを起動または再起動するために,start
エントリ・ポイントで処理スクリプトを呼び出します。この開始エントリ・ポイントでは,アプリケーションを起動するのに必要なすべてのコマンドを実行し,成功したときには 0 を返し,失敗したときには 0 以外の値を返さなければなりません。
アプリケーションの停止方法と,アプリケーションのフェイルオーバを発生させる前に行うクリーンアップ処理
CAA は,動作中のアプリケーション・リソースを停止するために,stop
エントリ・ポイントで処理スクリプトを呼び出します。UNKNOWN
状態のアプリケーション・リソースを停止するときには,呼び出しません (詳細は
caa_stop
(8)
アプリケーションが動作しているかどうかを判断する方法
CAA は,アプリケーションが動作しているかどうかを確認するために,処理スクリプトの
check
エントリ・ポイントを呼び出します。チェック・エントリ・ポイントは,CHECK_INTERVAL
秒間隔で繰り返し実行されます。このエントリでは,成功したときには 0 を返し,失敗したときには 0 以外の値を返さなければなりません。
省略時の設定では,処理スクリプトは,クラスタ単位のディレクトリ
/var/cluster/caa/script
に置かれます。処理スクリプトのファイル名は,name.scr
の形式です。
処理スクリプトを作成する最も簡単な方法は,caa_profile
コマンドでリソース・プロファイルを作成するときに,自動的に作成されるようにすることです。たとえば,次のように
-B
オプションを指定すると,作成することができます。
# caa_profile -create resource_name -t application -B application_path
caa_profile
コマンドで
-B
オプションを使用して,アプリケーションの実行形式ファイルのフル・パス名を
/usr/local/bin/httpd
のように指定します。-B
オプションを指定すると,caa_profile
コマンドは,/var/cluster/caa/script/resource_name.scr
という形式の名前の処理スクリプトを作成します。別の処理スクリプト名を指定したい場合は,-a
オプションを使います。
アプリケーションによっては,アプリケーションの環境を正しく設定するために,処理スクリプトを編集する必要があります。たとえば,xclock
のような X アプリケーションでは,処理スクリプトのコマンド行で
DISPLAY
環境変数を現在のシェルに合わせて設定する必要があります。
たとえば,次のようになります。
DISPLAY=`hostname`:0 export DISPLAY
アプリケーション・リソースには処理スクリプトが必要なため,caa_profile -create
コマンドを使用してアプリケーション・リソース・プロファイルを作成する場合は,次のいずれかの条件を満たさなければなりません。
caa_profile
にオプション
-B
application_executable_pathname
を指定して,処理スクリプトが自動的に作成されるようにします。また,-a
オプションを使って,作成される処理スクリプトの名前を指定することもできます。
省略時のディレクトリ
/var/cluster/caa/script/
に実行可能な処理スクリプトをあらかじめ作成しておかなければなりません。スクリプト名のルートは,作成するリソースと同じ名前でなければなりません。
たとえば,処理スクリプトが
/var/cluster/caa/script/up-app-1.scr
という名前の場合,リソース名は
up-app-1
でなければなりません。したがって,caa_profile
コマンドを使ったリソース・プロファイルを作成する場合,コマンド行に次のように指定します。
# caa_profile -create up-app-1 -t application
実行形式の処理スクリプトがすでにある場合,caa_profile
のオプション
-a
action_script_pathname
を,たとえば次のように指定して,CAA に処理スクリプトのある場所を知らせます。
-a /usr/users/smith/caa/scripts/app.scr
警告
処理スクリプトはセキュリティ上の理由からルートでだけ作成可能です。
2.3.1 アプリケーション・リソースの処理スクリプトを作成する際のガイドライン
アプリケーション・リソースの処理スクリプトを作成するときには,次のことに注意してください。
CAA は,アプリケーションの状態を
ONLINE
にするか
OFFLINE
にするかを,処理スクリプトからの終了コードによって判断します。処理スクリプト内のそれぞれのエントリ・ポイントでは,成功したときには終了コード 0 を返し,失敗したときには 0 以外の終了コードを返さなければなりません。
CAA は,stop
エントリ・ポイントの処理スクリプトが
SCRIPT_TIMEOUT
値 (秒数) の間に終了しないか,ゼロ以外の値を返した場合,アプリケーションの状態を
UNKNOWN
とします。UNKNOWN
状態は,起動,再配置,または停止を実行するときに発生します。アプリケーションが正常に停止した場合,またはアプリケーションを実行していない場合,stop
エントリ・ポイントの処理スクリプトが値 0 で終了するようにしてください。
デーモンは起動すると,通常はバックグラウンド・プロセスとして動作します。起動時に即座にバックグラウンドに置かれないアプリケーションについては,そのアプリケーションを起動する行の終わりにアンパサンド (&) を追加することによって,そのアプリケーションをバックグラウンドで動作するようにします。アプリケーションをこの方法で使用する場合,起動しようとすると常に正常のリターン・コードが戻ります。つまり,省略時のスクリプトには,つまらない理由による失敗 (たとえば,コマンド・パスのつづり間違い) を検出する方法がないということになります。このようなコマンドを使うときは,CAA で使う前にそのスクリプトに使うコマンドを対話的に実行して構文エラーや単純ミスを取り除くことをお勧めします。
CAA の下で実行する X Windows アプリケーションについて,次のようなことを考慮してください。
クラスタで動作し,CAA が監視しているグラフィカル・アプリケーションでは,処理スクリプト内でクライアント・システムの環境変数
DISPLAY
を設定する必要があります。
例を次に示します。
export DISPLAY=everest:0.0 /usr/bin/my_application &
クライアント・システムでは,許可する X サーバ接続のリストに,省略時のクラスタ別名を追加します。 例を次に示します。
everest#> xhost +my_cluster
caa_profile
または SysMan で作成する CAA の処理スクリプトは,PATH
環境変数を設定しません。処理スクリプトを実行するとき,PATH
は省略時の値
/sbin:/usr/sbin:/usr/bin
に設定されます。したがって,処理スクリプトで使用するパス名のほとんどは明示的に指定するか,作成された処理スクリプトを修正して
PATH
を明示的に設定するようにしなければなりません。以前のリリースで自動的に作成された処理スクリプトでは,PATH
に現在のディレクトリ (.
) が設定されています。この設定には潜在的なセキュリティ上の問題があるので,それらの処理スクリプトについては,パスから現在のディレクトリを削除してください。
処理スクリプトのテンプレートは,/var/cluster/caa/template/template.scr
にあります。これは,caa_profile
コマンドによって作成される処理スクリプトのベースとして使われるものであり,処理スクリプトの個々の要素のモデルとして使用できます。
例として,次のアプリケーション・リソースの処理スクリプトを使用することができます。これらの処理スクリプトの例は
/var/cluster/caa/script
ディレクトリにあります。
cluster_lockd.scr
dhcp.scr
named.scr
autofs.scr
また,2.14 節に示したスクリプトも,処理スクリプトのよい例となります。/var/cluster/caa/examples_unsupported
ディレクトリには,これらの例を含むスクリプトが格納されています。ここには,CAA を使用するいくつかのアプリケーションの例があります。このディレクトリにあるスクリプト
sysres_templ.scr
には,追加のシステムの性能に関連するコードがあり,システム負荷,スワップ領域使用率,使用可能なディスク・スペースを調べるのに使用できます。これらの機能をスクリプトに組み込む場合は,システムに適した値をこれらの機能に関連付けられた変数に設定します。
2.3.3 環境変数のアクセス
処理スクリプトは,多くの環境変数にアクセスすることができるので,スクリプトを変数に対応させるように作成することができます。
CAA 環境で実行する処理スクリプトがアクセスできる変数には,次のものがあります。
プロファイル属性
理由コード
ロケール情報
ユーザ定義属性
CAA 定義のリソース・プロファイルの属性は,その属性に
_CAA_
を付けることにより処理スクリプトの環境変数としてアクセスすることができます。たとえば,AUTO_START
の値は,_CAA_AUTO_START
を使用することによって得られます。
理由コードは,処理スクリプトが実行された理由を示します。環境変数
_CAA_REASON
には,次の理由コードの値のいずれかが設定されます。
user
caa_start
,caa_stop
,caa_relocate
など,ユーザが開始したコマンドによって処理スクリプトが起動された。
failure
障害状態が発生したために処理スクリプトが起動された。この値が設定される状態は,チェック・スクリプトが失敗した場合が一般的である。
dependency
依存関係にある他のリソースが障害になったために処理スクリプトが起動された。
boot
処理スクリプトが最初のクラスタ・ブートの結果として起動された (リソースはシステムの起動前に実行されていた)。
autostart
リソースが自動起動された。AUTOSTART
プロファイルの属性が 1 に設定されている場合に,最後のシャットダウンの前に,リソースがあらかじめオフラインになっているときにはクラスタのブート時にリソースは自動起動される。
system
処理スクリプトが通常の保守のためにシステムによって起動された (たとえば,チェック・スクリプトによる再配置の開始)。
unknown
スクリプトが起動されたが,その状態は内部的には認識されていない。この値が表示された場合には,クラスタとアプリケーションの状態を記録し,サポート担当に連絡する。
CAA コマンドが処理スクリプトを起動する環境のロケールは,_CAA_CLIENT_LOCALE
環境変数の情報が使用可能です。この変数には,以下のロケール情報が含まれていて,文字列の値の各情報はスペースで区切られています (LC_ALL
,LC_CTYPE
,LC_MONETARY
,LC_NUMERIC
,LC_TIME
,LC_MESSAGES
)。処理スクリプトは必要に応じて,この情報を使用して処理スクリプト環境にロケールを設定できます。
ロケールについての詳細は,
setlocale
(3)locale
(1)
処理スクリプトでの理由コードの使用例を次に示します。
if [ "$_CAA_REASON" = "user" ]; then echo "Action invoked by User"
.
.
.
fi
処理スクリプトからの出力がリダイレクトでき,caa_start
,caa_stop
,caa_relocate
の実行時にその結果を表示できます。出力の各行には,オプションでクラスタ・メンバとリソース名からなるプリフィクスを付けることができます。
省略時には,出力はリダイレクトされません。
CAA で処理スクリプトの出力をリダイレクトできるようにするには,caa_start
,caa_stop
,または
caa_relocate
を実行する環境では,以下のように環境変数
_CAA_UI_FMT
を
v
または
vs
のいずれかに設定する必要があります。
# export _CAA_UI_FMT=v # caa_start db_2 ... nodex:db_2:output text ... nodex:db_2:output text ... nodex:db_2:output text ... nodex:db_2:output text ...
修飾子
s
を使用すると,出力のプリフィクス部分のノード : リソースは表示されません。
# export _CAA_UI_FMT=vs # caa_start db_2 output text ... output text ...
アプリケーション・リソース・プロファイルでは,ユーザ定義属性を指定して拡張することができます。これらのユーザ定義属性は,リソースの処理スクリプト内で環境変数としてアクセスでき,すべてのアプリケーション・リソースに適用できます。
ユーザ定義属性は,最初に
/var/cluster/caa/template/application.tdf
にあるアプリケーション・リソース・タイプ定義ファイルで定義する必要があります。定義する必要がある値は次のとおりです。
ユーザが値を指定できる属性を定義する。この属性は,すべてのアプリケーション・リソースの処理スクリプトでアクセス可能な環境変数に変換される。
type
この属性で使用可能な値の種類を定義する。種類としては,boolean
,string
,name_list
,name_string
,positive_integer
,internet_address
,file
がある。
switch
プロファイルの値を指定するために,caa_profile
コマンドで使用するスイッチを定義する。
default
この属性をプロファイルに指定しない場合の省略時の値を定義する。
required
スイッチがプロファイルに指定されているかいないかを定義する。
ユーザ定義属性は,プロファイルだけでなく
caa_start
,caa_relocate
,caa_stop
のコマンド行にも指定することができます。コマンド行に指定された値は,プロファイルで指定された値より優先されます。詳細については,
caa_start
(8)caa_relocate
(8)caa_stop
(8)
#
で始まるタイプ定義ファイルの各行は,コメントとして解釈されます。
タイプ定義ファイルのエントリの例を次に示します。
#!========================== attribute: USR_DEBUG type: boolean switch: -o d default: 0 required: no
どのリソースにもプロファイルが必要です。リソースは CAA によって管理されるため,CAA に登録する必要があります。リソースの登録は,caa_register
コマンドで行います。たとえば,clock
アプリケーションを登録する場合,次のコマンドを実行します。
# /usr/sbin/caa_register clock
リソースを登録すると,プロファイル内の情報はバイナリの CAA レジストリに保存されます。プロファイルを変更したときには,caa_register
-u
コマンドを使ってデータベースを更新する必要があります。
詳細は,
caa_register
(8)2.6 アプリケーション・リソースの起動
CAA に登録したアプリケーションを起動するには,caa_start
コマンドを実行します。アプリケーション・リソースの名前は,アプリケーションと同じ名前でも違う名前でもかまいません。たとえば,次のようにアプリケーションを起動します。
# /usr/sbin/caa_start clock
次は,このコマンドの出力結果の例です。
Attempting to start `clock` on member `polishham` Start of `clock` on member `polishham` succeeded.
このアプリケーションは,polishham
という名前のシステムで動作しています。
このコマンドは,処理スクリプトを呼び出すたびに,処理スクリプトから返される成功したかどうかの通知を
SCRIPT_TIMEOUT
値だけ待ちます。
アプリケーション・リソースと非アプリケーション・リソースが障害しきい値を超えたために停止した場合にも,アプリケーション・リソースを起動することができ,非アプリケーション・リソースは再起動することができます (非アプリケーション・リソースの再起動については,『クラスタ管理ガイド』 を参照してください)。起動する前に,caa_register
でこのリソースを登録する必要があります。
注意
リソースを起動/停止するときには,必ず
caa_start
およびcaa_stop
,または同等の SysMan 機能を使用します。アプリケーションを起動したり停止したりするために,コマンド行を使用して手作業で行ったり,処理スクリプトを実行したりしてはなりません。CAA の管理外で,手作業による起動または停止を行うと,リソースの状態が不適切になります。
別のクラスタ・メンバで
ONLINE
状態になっている必須リソースのあるリソースを起動すると,起動に失敗します。すべての必須リソースは,リソースが起動されるメンバで
OFFLINE
状態または
ONLINE
の状態になっている必要があります。
OFFLINE
状態の必須リソースのあるリソースでは,caa_start
-f
resource_name
コマンドを使用すると,対象リソースが起動されると同時に,現在
ONLINE
状態でないすべての必須リソースも起動されます。
アプリケーション・リソースでは,caa_start
コマンドを実行することによってのみ,実際にリソースのターゲット値が
ONLINE
状態になります。ターゲット値は,CAA がリソースに設定しようとする状態を定義します。
CAA は,ターゲットに一致するように状態を変更しようとし,処理スクリプトの開始エントリ・ポイントを実行してアプリケーションを起動しようとします。アプリケーションが動作している場合は,ターゲットの状態と現在の状態が両方とも
ONLINE
状態です。ターゲットと状態のフィールドおよびそのリソースの状態の詳細は,『クラスタ管理ガイド』 を参照してください。
注意
システムがクラッシュしているクラスタ・メンバ上でアプリケーションを起動しようとすると,
caa_start
はあいまいな結果を表示します。このような場合には,処理スクリプトの開始部分は実行されますが,開始の通知がコマンド行に表示される前にそのクラスタ・メンバはクラッシュします。caa_start
は,Remote start for [resource_name] failed on member [member_name]
というエラーを表示して障害を通知します。アプリケーション・リソースは実際にはONLINE
で,別のメンバにフェイルオーバし,あたかもアプリケーションが間違ったメンバ上で起動したかのように見えます。アプリケーション・リソースを起動している間にそのクラスタ・メンバに障害が発生した場合には,そのリソースの状態を調べるため,
caa_stat
でクラスタ上のリソースの状態をチェックしてください。
詳細については,
caa_start
(8)2.7 アプリケーション・リソースの再配置
アプリケーション・リソースを再配置するには,caa_relocate
コマンドを使用します。ネットワーク,テープ,およびメディア・チェンジャは再配置できません。
アプリケーション・リソースを,利用可能なクラスタ・メンバ,または指定したクラスタ・メンバに再配置するには,caa_relocate
コマンドを使用します。たとえば,clock
アプリケーションをメンバ
provolone
に再配置するには,次のコマンドを実行します。
# /usr/sbin/caa_relocate clock -c provolone
次に,このコマンドの出力結果の例を示します。
Attempting to stop `clock` on member `polishham` Stop of `clock` on member `polishham` succeeded. Attempting to start `clock` on member `provolone` Start of `clock` on member `provolone` succeeded.
アプリケーションのリソース・プロファイルに定義されている配置ポリシを使って,clock
アプリケーションを別のメンバに再配置するには,次のコマンドを実行します。
# /usr/sbin/caa_relocate clock
次に,このコマンドの出力結果の例を示します。
Attempting to stop `clock` on member `pepicelli` Stop of `clock` on member `pepicelli` succeeded. Attempting to start `clock` on member `polishham` Start of `clock` on member `polishham` succeeded.
次に,スクリプトがゼロ以外の値を返したか,スクリプトのタイムアウトのために,アプリケーションをうまく再配置できなかった場合の,出力結果の例を示します。
Attempting to stop `clock` on member `pepicelli` Stop of `clock` on member `pepicelli` succeeded. Attempting to start `clock` on member `provolone` Start of `clock` on member `provolone` failed. No more members to consider Attempting to restart `clock` on member `pepicelli` Could not relocate resource clock.
caa_relocate
コマンドは,処理スクリプトを呼び出すたびに,処理スクリプトから返される成功したかどうかの通知を
SCRIPT_TIMEOUT
値だけ待ちます。
次の場合は,再配置しようとしても失敗します。
そのリソースに
ONLINE
状態の必須リソースがある。
特定リソースを必要とするリソースが
ONLINE
状態である。
ONLINE
状態の必須リソースを持っているか,リソースが
ONLINE
であることを必要とするリソースで,caa_relocate
-f
resource_name
コマンドを使用すると,そのリソースは再配置され,それが
ONLINE
であることを必要とするすべてのリソースは再配置されます。指定したリソースで必要とされるすべてのリソースは再配置され,それらの状態とは関係なく,起動されます。
詳細は,
caa_relocate
(8)2.8 アプリケーション・リソースの分散
アプリケーション・リソースの分散とは,クラスタ上のリソースの現在の状態とリソースの配置規則に基づいて,アプリケーション・リソースの配置を再評価することです。アプリケーションの分散は,クラスタ単位,メンバ単位,または指定したリソースで行うことができます。分散は,CAA の標準の配置決定メカニズムを使用して決定されますが,負荷を考慮しません。
caa_balance
を使用すると,アプリケーション・リソースのみを分散できます。ネットワーク,テープ,またはメディア・チェンジャのリソースを分散することはできません。
2.2.2.2 項で説明しているように,クラスタ単位で分散を行うと,クラスタ上にあるすべての
ONLINE
アプリケーション・リソースを再評価し,配置決定メカニズムにより選択されたクラスタ・メンバで実行されていないそれぞれのリソースを再配置します。
クラスタ上のすべてのアプリケーションを分散させるには,次のコマンドを入力します。
# /usr/sbin/caa_balance -all
2 つのアプリケーション
test
と
test2
だけが
ONLINE
で,balanced
配置ポリシによりメンバ
rye
上で実行されているとします。その場合,次のようなテキストが表示されます。
Attempting to stop `test` on member `rye` Stop of `test` on member `rye` succeeded. Attempting to start `test` on member `swiss` Start of `test` on member `swiss` succeeded. Resource test2 is already well placed test2 is placed optimally. No relocation is needed.
クラスタ内で 3 つ以上のアプリケーションが
ONLINE
の場合,出力にはそれぞれのアプリケーション・リソースに対してとられた処理が表示されます。
クラスタ・メンバ
rye
上で実行されているアプリケーションの配置を再評価するには,次のコマンドを入力します。
# /usr/sbin/caa_balance -s rye
2 つのアプリケーションだけが
ONLINE
で,balanced
配置ポリシのもとでメンバ
rye
上で実行されているとします。その場合,次のようなテキストが表示されます。
Attempting to stop `test` on member `rye` Stop of `test` on member `rye` succeeded. Attempting to start `test` on member `swiss` Start of `test` on member `swiss` succeeded. Resource test2 is already well placed test2 is placed optimally. No relocation is needed.
3 つ以上のアプリケーションがクラスタ・メンバ上で
ONLINE
の場合,出力にはそれぞれのアプリケーション・リソースに対してとられた処理が表示されます。
指定したアプリケーションだけを分散させるには,次のコマンドを入力します。
# /usr/sbin/caa_balance test test2
2 つのアプリケーション
test
と
test2
が
balanced
配置ポリシのもとでメンバ rye 上で実行されているとします。その場合,次のテキストが表示されます。
Attempting to stop `test` on member `rye` Stop of `test` on member `rye` succeeded. Attempting to start `test` on member `swiss` Start of `test` on member `swiss` succeeded. Resource test2 is already well placed test2 is placed optimally. No relocation is needed.
プロファイル内の時間値は,t:day:hour:min
というフォーマットで指定する必要があります。ここで,day
は曜日 (0 〜 6) を示し,hour
はその曜日の時間 (0 〜 23) を示し,min
は分 (0 〜 59) を示して,再評価が行われる時間を指定します。毎日または毎時を指定する場合には,ワイルドカードとしてアスタリスク (*) を使用できます。
たとえば,アプリケーションを毎日曜日午前 3 時に再分散する場合は,次のようになります。
REBALANCE=t:0:3:0
また,アプリケーションを毎日午前 2:30 に再分散する場合は,次のようになります。
REBALANCE=t:*:2:30
caa_profile
コマンドを使用してこれを指定すると,次のようになります。
# /usr/sbin/caa_profile -create testapp -t application -B /usr/bin/true -o bt=*:2:30
その結果,作成されるプロファイルは次のようになります。
NAME=testapp TYPE=application ACTION_SCRIPT=testapp.scr ACTIVE_PLACEMENT=0 AUTO_START=0 CHECK_INTERVAL=60 DESCRIPTION=testapp FAILOVER_DELAY=0 FAILURE_INTERVAL=0 FAILURE_THRESHOLD=0 HOSTING_MEMBERS= OPTIONAL_RESOURCES= PLACEMENT=balanced REBALANCE=t:*:2:30 REQUIRED_RESOURCES= RESTART_ATTEMPTS=1 SCRIPT_TIMEOUT=60
詳細については,
caa_balance
(8)2.9 アプリケーション・リソースの停止
クラスタ環境で動作しているアプリケーションを停止するには,caa_stop
コマンドを使用します。caa_stop
コマンドを実行すると,直ちにターゲットが
OFFLINE
に設定されます。CAA は常にリソースの状態をターゲットに一致させようとするので,CAA サブシステムはアプリケーションを停止します。停止できるリソースは,アプリケーション・リソースだけです。ネットワーク,テープ,およびメディア・チェンジャ・タイプのリソースは,停止できません。
次の例では,clock
アプリケーション・リソースを停止します。
# /usr/sbin/caa_stop clock
次は,このコマンドの出力例です。
Attempting to stop `clock` on member `polishham` Stop of `clock` on member `polishham` succeeded.
別の
ONLINE
アプリケーションに対して,そのアプリケーションが必須リソースである場合には,そのアプリケーションを停止することはできません。
他の
ONLINE
状態のリソースが必要とするリソースで
caa_stop
-f
resource_name
コマンドを使用すると,そのリソースは停止して,それを必要とする
ONLINE
状態の他のリソースも停止します。
詳細は,
caa_stop
(8)2.10 アプリケーション・リソースの登録抹消
アプリケーション・リソースの登録を抹消するには,caa_unregister
コマンドを使用します。
ONLINE
状態にあるかまたは他のリソースに必要なアプリケーションは登録を抹消できません。次の例では,clock
アプリケーションの登録を抹消します。
# /usr/sbin/caa_unregister clock
詳細は,
caa_unregister
(8)2.11 CAA の状態情報の表示
クラスタ・メンバ上のリソースに関する状態情報を表示するには,caa_stat
コマンドを使用します。
次に,clock
リソースの状態情報の表示例を示します。
# /usr/bin/caa_stat clock NAME=clock TYPE=application TARGET=ONLINE STATE=ONLINE on provolone
すべてのリソースの情報を表示するには,次のコマンドを実行します。
# /usr/bin/caa_stat NAME=clock TYPE=application TARGET=ONLINE STATE=ONLINE on provolone NAME=dhcp TYPE=application TARGET=ONLINE STATE=ONLINE on polishham NAME=named TYPE=application TARGET=ONLINE STATE=ONLINE on polishham NAME=network1 TYPE=network TARGET=ONLINE on provolone TARGET=ONLINE on polishham STATE=ONLINE on provolone STATE=ONLINE on polishham
すべてのリソースの情報を表形式で表示するには,次のコマンドを実行します。
# /usr/bin/caa_stat -t Name Type Target State Host ------------------------------------------------------------------- cluster_lockd application ONLINE ONLINE provolone dhcp application OFFLINE OFFLINE network1 network ONLINE ONLINE provolone network1 network ONLINE ONLINE polishham
リソースを再起動した回数またはリソース障害間隔内に障害が発生した回数,リソースを再起動できる回数または障害に対応できる回数,アプリケーションのターゲット状態,および通常の状態情報を表示するには,次のコマンドを実行します。
# /usr/bin/caa_stat -v NAME=cluster_lockd TYPE=application RESTART_ATTEMPTS=30 RESTART_COUNT=0 FAILURE_THRESHOLD=0 FAILURE_COUNT=0 TARGET=ONLINE STATE=ONLINE on provolone NAME=dhcp TYPE=application RESTART_ATTEMPTS=1 RESTART_COUNT=0 FAILURE_THRESHOLD=3 FAILURE_COUNT=1 TARGET=ONLINE STATE=OFFLINE NAME=network1 TYPE=network FAILURE_THRESHOLD=0 FAILURE_COUNT=0 on polishham FAILURE_COUNT=0 on polishham TARGET=ONLINE on provolone TARGET=ONLINE on polishham STATE=ONLINE on provolone STATE=OFFLINE on polishham
詳細情報を表形式で表示したい場合は,次のコマンドを実行します。
# /usr/bin/caa_stat -v -t Name Type R/RA F/FT Target State Host --------------------------------------------------------------------------- cluster_lockd application 0/30 0/0 ONLINE ONLINE provolone dhcp application 0/1 0/0 OFFLINE OFFLINE named application 0/1 0/0 OFFLINE OFFLINE network1 network 0/5 ONLINE ONLINE provolone network1 network 0/5 ONLINE ONLINE polishham
データベースに保存されているプロファイル情報を表示するには,次のコマンドを実行します。
# /usr/bin/caa_stat -p NAME=cluster_lockd TYPE=application ACTION_SCRIPT=cluster_lockd.scr ACTIVE_PLACEMENT=0 AUTO_START=1 CHECK_INTERVAL=5 DESCRIPTION=Cluster lockd/statd FAILOVER_DELAY=30 FAILURE_INTERVAL=60 FAILURE_THRESHOLD=1 REBALANCE= HOSTING_MEMBERS= OPTIONAL_RESOURCES= PLACEMENT=balanced REQUIRED_RESOURCES= RESTART_ATTEMPTS=2 SCRIPT_TIMEOUT=60
.
.
.
詳細は,『クラスタ管理ガイド』および
caa_stat
(1)2.12 グラフィカル・ユーザ・インタフェース
以降の各項では,CAA を操作するために,SysMan および SysMan Station グラフィカル・ユーザ・インタフェース (GUI) を使用する方法を説明します。
2.12.1 SysMan Menu による CAA の管理
SysMan Menu は,コマンド行に
/usr/sbin/sysman
と入力することにより,起動することができます。CAA の各種ツールにアクセスするには,[TruCluster Specific] ブランチの下の [Cluster Application Availablility (CAA) Management] を選択します。
.
.
.
+ TruCluster Specific |Cluster Application Availability (CAA) Management
[Cluster Application Availablility (CAA) Management]] タスクだけを起動する場合は,/usr/sbin/sysman caa
を使用します。
SysMan Menu のアクセス方法の詳細は,Tru64 UNIX の 『システム管理ガイド』 を参照してください。
SysMan Menu を使用して,次のことを行うことができます。
リソース・プロファイルの管理
CAA リソースの監視
リソースの登録
リソースの起動
リソースの再配置
リソースの停止
リソースの登録抹消
CAA GUI では,EVM (イベント・マネージャ) と CAA デーモンからのイベント・レポートをベースにして,グラフィカルにクラスタを管理します。
2.12.2 SysMan Station による CAA の管理と監視
SysMan Station は,クラスタの包括的情報をグラフィカルに表示します。SysMan Station では,クラスタ全体の CAA リソースの現在の状態を表示して,リソースを管理することができます。また SysMan Station では,管理ツール SysMan Menu で個々の CAA リソースを管理することができます。SysMan Station にアクセスする方法についての詳細は,Tru64 UNIX の『システム管理ガイド』 を参照してください。
SysMan Station で,CAA SysMan Menu の各種ツールにアクセスするには,次の手順に従います。
[Views] の下の,たとえば [CAA_Applications_(active)] や [CAA_Applications_(all)] などのビューのいずれかを選択します。
[Views] ウィンドウ (たとえば [CAA_Applications_(active) View] や [CAA_Applications_(all) View] など) の下のクラスタ名を選択します。
[Tools]メニューから [SysMan Menu] を選択します。[Cluster Application Availability (CAA) Management] タスクは,[TruCluster Specific] ブランチの下にあります。
SysMan Menu と SysMan Station についての詳細は,オンライン・ヘルプまたは Tru64 UNIX の『システム管理ガイド』 を参照してください。
2.13 CAA のチュートリアル
この CAA のチュートリアルでは,CAA を使ってアプリケーションの高可用性を迅速に実現するために必要な基本的な手順を紹介します。個々のコマンドについての詳細は,CAA の各種コマンドについて説明したドキュメントを読む必要があります。
前提条件 (2.13.1 項)
準備作業 (2.13.2 項)
dtcalc
の処理スクリプトの例 (2.13.3 項)
ステップ 1: アプリケーション・リソース・プロファイルの作成 (2.13.4 項)
ステップ 2: アプリケーション・リソース・プロファイルの検証 (2.13.5 項)
ステップ 3: アプリケーションの登録 (2.13.6 項)
ステップ 4: アプリケーションの起動 (2.13.7 項)
ステップ 5: アプリケーションの再配置 (2.13.8 項)
ステップ 6: アプリケーションの停止 (2.13.9 項)
ステップ 7: アプリケーションの登録抹消 (2.13.10 項)
このチュートリアルでは,サンプルのクラスタは,メンバ
provolone
,polishham
,pepicelli
を含んでいます。コマンド行で使用するメンバ名は,ご使用のクラスタのメンバ名に置き換えてください。
2.13.1 前提条件
2 メンバで構成する TruCluster Server クラスタに root ユーザとしてアクセスできる必要があります。
このチュートリアルでは,CAA を使って,Tru64 UNIX アプリケーションの
dtcalc
に高可用性を実現します。テスト・アプリケーション
/usr/dt/bin/dtcalc
があることを確認してください。
この例では,X ベースのアプリケーションを使用していますが,特にこのアプリケーションに限定する必要はありません。ただ,X ベースのアプリケーションであれば,起動,停止,および再配置の結果を即座に見ることができます。この種の高可用性アプリケーションは,あまり使用されないかもしれません。
2.13.2 準備作業
CAA を使ってグラフィカル・インタフェースを持つアプリケーションの高可用性を実現するには,ActionScript.scr
ファイルで,DISPLAY
変数を正しく設定する必要があります。DISPLAY
変数を修正したら,ファイル
ActionScript.scr
をスクリプト・ディレクトリ
/var/cluster/caa/script
にコピーします。
アプリケーションを表示したいホストで,クラスタから X アプリケーションを表示できることを確認します。アクセスを変更する必要がある場合は,アプリケーションを表示するマシンで,次のようなコマンドを実行します。
# xhost + clustername
各メンバの実際の名前がわからない場合は,システム上の
/etc/hosts
ファイルを見て確認してください。また,clu_get_info
コマンドを使って各クラスタ・メンバの情報 (ホスト名など) を得ることもできます。
次に,clu_get_info
コマンドとその実行結果の例を示します。
# clu_get_info Cluster information for cluster deli Number of members configured in this cluster = 3 memberid for this member = 3 Quorum disk = dsk10h Quorum disk votes = 1 Information on each cluster member Cluster memberid = 1 Hostname = polishham.zk4.com Cluster interconnect IP name = polishham=ics0 Member state = UP Cluster memberid = 2 Hostname = provolone.zk4.com Cluster interconnect IP name = provolone=ics0 Member state = UP Cluster memberid = 3 Hostname = pepicelli.zk4.com Cluster interconnect I name = pepicelli=ics0 Member state = UP
次に,dtcalc
のチュートリアルで使用する処理スクリプトの例を示します。
caa_profile
コマンドで作成されるもっと複雑な処理スクリプトを使用することもできます。
#!/usr/bin/ksh -p # # This action script will be used to launch dtcalc. # export DISPLAY=`hostname`:0 PATH=/sbin:/usr/sbin:/usr/bin export PATH CAATMPDIR=/tmp CMDPATH=/usr/dt/bin APPLICATION=${CMDPATH}/dtcalc CMD=`basename $APPLICATION` case $1 in 'start') [1] if [ -f $APPLICATION ]; then $APPLICATION & exit 0 else echo "Found exit1" >/dev/console exit 1 fi ;; 'stop') [2] PIDLIST=`ps ax | grep $APPLICATION | grep -v 'caa_' \ | grep -v 'grep' | awk '{print $1}'` if [ -n "$PIDLIST" ]; then kill -9 $PIDLIST exit 0 fi exit 0 ;; 'check') [3] PIDLIST=`ps ax | grep $CMDPATH | grep -v 'grep' | awk '{print $1}'` if [ -z "$PIDLIST" ]; then PIDLIST=`ps ax | grep $CMD | grep -v 'grep' | awk '{print $1}'` fi if [-n "$PIDLIST" ]; then exit 0 else echo "Error: CAA could not find $CMD." >/dev/console exit 1 fi ;; esac
起動エントリ・ポイントは,アプリケーションを起動するときに実行されます。 [例に戻る]
停止エントリ・ポイントは,アプリケーションを停止するときに実行されます。 [例に戻る]
チェック・エントリ・ポイントは,CHECK_INTERVAL
秒ごとに実行されます。
[例に戻る]
dtcalc
のリソース・プロファイルを作成するために,caa_profile
コマンドに次のオプションを指定して実行します。
# /usr/sbin/caa_profile -create dtcalc -t application -B /usr/dt/bin/dtcalc \ -d "dtcalc application" -p balanced
/var/cluster/caa/profile/
にある
dtcalc.cap
ファイルを調べると,次のような内容になっているはずです。
# cat dtcalc.cap NAME=dtcalc TYPE=application ACTION_SCRIPT=dtcalc.scr ACTIVE_PLACEMENT=0 AUTO_START=0 CHECK_INTERVAL=60 DESCRIPTION=dtcalc application FAILOVER_DELAY=0 FAILURE_INTERVAL=0 FAILURE_THRESHOLD=0 HOSTING_MEMBERS= OPTIONAL_RESOURCES= PLACEMENT=balanced REQUIRED_RESOURCES= RESTART_ATTEMPTS=1 SCRIPT_TIMEOUT=60
2.13.5 ステップ 2: アプリケーション・リソース・プロファイルの検証
リソース・プロファイルの構文を検証するために,次のコマンドを実行します。
# caa_profile -validate dtcalc
プロファイルに構文エラーがあると,caa_profile
は,プロファイルが検証をパスしなかったことを示すメッセージを表示します。
2.13.6 ステップ 3: アプリケーションの登録
アプリケーションを登録するために,次のコマンドを実行します。
# /usr/sbin/caa_register dtcalc
プロファイルを登録できない場合は,その理由を示すメッセージが表示されます。
アプリケーションが登録されたことを確認するには,次のコマンドを実行します。
# /usr/bin/caa_stat dtcalc NAME=dtcalc TYPE=application TARGET=OFFLINE STATE=OFFLINE
アプリケーションを起動するために,次のコマンドを実行します。
# /usr/bin/caa_start dtcalc
次のメッセージが表示されます。
Attempting to start `dtcalc` on member `provolone` Start of `dtcalc` on member `provolone` succeeded.
/usr/bin/caa_stat
dtcalc
コマンドを実行して,dtcalc
処理スクリプトの起動エントリ・ポイントが正しく実行され,dtcalc
が起動されたことを確認できます。
次に,例を示します。
#
/usr/bin/caa_stat dtcalc
NAME=dtcalc TYPE=application TARGET=ONLINE STATE=ONLINE on provolone
DISPLAY
変数がスクリプト内で正しく設定されていれば,dtcalc
が画面に表示されます。
2.13.8 ステップ 5: アプリケーションの再配置
アプリケーションを再配置するために,次のコマンドを実行します。
# /usr/bin/caa_relocate dtcalc -c polishham
コマンド
/usr/bin/caa_stat
を実行して,dtcalc
dtcalc
が正常に起動されたことを確認します。次に例を示します。
# /usr/bin/caa_stat dtcalc NAME=dtcalc TYPE=application TARGET=ONLINE STATE=ONLINE on polishham
STATE
属性にクラスタ・メンバがリストされます。
2.13.9 ステップ 6: アプリケーションの停止
アプリケーションを停止するために,次のコマンドを実行します。
# /usr/bin/caa_stop dtcalc
次のメッセージが表示されます。
Attempting to stop `dtcalc` on member `provolone` Stop of `dtcalc` on member `provolone` succeeded.
/usr/bin/caa_stat
コマンドを次のように実行して,dtcalc
dtcalc
処理スクリプトの停止エントリ・ポイントが正常に実行され,dtcalc
が停止することを確認します。
# /usr/bin/caa_stat dtcalc NAME=dtcalc TYPE=application TARGET=OFFLINE STATE=OFFLINE
アプリケーションの登録を抹消するために,次のコマンドを実行します。
# /usr/sbin/caa_unregister dtcalc
以降の各項では,CAA で管理する高可用性シングル・インスタンス・アプリケーションの例を示します。
2.14.1 OpenLDAP ディレクトリ・サーバ
OpenLDAP (Lightweight Directory Access Protocol) ディレクトリ・サーバは,HP によって開発された管理ツールに統合された人気の高いインターネット・ソフトウェアの集まりである,Internet Express for Tru64 UNIX 製品スイートの一部分です (Internet Express は,すべての HP Tru64 UNIX AlphaServer システムといっしょに出荷されています。Internet Express は,次の URL からも入手できます。 http://www.tru64unix.compaq.com/docs/pub_page/iass_docs.html)。 このスイート内の製品はクラスタ対応で,クラスタ内で高可用性を持つように構成可能です。
システム認証用 LDAP モジュールにより,LDAP サーバに格納されたユーザ認識情報と認証情報は以下を含め,すべてのアプリケーションで使用することができます。
ログイン認証 (rlogin
,ftp
,および
telnet
)
POP および IMAP 認証
libc
ライブラリにある
getpw*()
と
getgr*()
に対する,透過的な LDAP データベースへのアクセス
TruCluster Server 環境で高可用性の OpenLDAP ディレクトリ・サーバを作成するには,次の処理を行います。
Internet Express Installation グラフィカル・ユーザ・インタフェース (GUI) を使って Internet Express キットをインストールします。Internet Express Administration Utility とインストールする OpenLDAP のサブセットを選択します。
このインストレーション・プロシージャにより,OpenLDAP アプリケーション・リソース用に
/var/cluster/caa/profile
の中に CAA リソース・プロファイルが作成されます。
TYPE = application NAME = openldap DESCRIPTION = OpenLDAP Directory Server CHECK_INTERVAL = 60 FAILURE_THRESHOLD = 0 FAILURE_INTERVAL = 0 REQUIRED_RESOURCES = OPTIONAL_RESOURCES = HOSTING_MEMBERS = PLACEMENT = balanced RESTART_ATTEMPTS = 1 FAILOVER_DELAY = 0 AUTO_START = 0 ACTION_SCRIPT = openldap.scr
また,/var/cluster/caa/script
ディレクトリにこのリソースの処理スクリプトが作成されます。
#!/sbin/sh # # Start/stop the OpenLDAP Directory Server. # OLPIDFILE=/data/openldap/var/openldap_slapd.pid OPENLDAP_CAA=1 export OPENLDAP_CAA case "$1" in 'start') /sbin/init.d/openldap start ;; 'stop') /sbin/init.d/openldap stop ;; 'check') # return non-zero if the service is stopped if [ -f "$OLPIDFILE" ] then MYPID=`cat $OLPIDFILE` RUNNING=`/usr/bin/ps -e -p $MYPID -o command | grep slapd` fi if [ -z "$RUNNING" ] then exit 1 else exit 0 fi ;; *) echo "usage: $0 {start|stop|check}" ;; esac
次の
init.d
スクリプトは,適切な CAA コマンドを呼び出すことによってクラスタ内の OpenLDAP サービスを起動したり停止したりします。
#!/sbin/sh # # Start the OpenLDAP Directory Server daemon. # NAME="OpenLDAP Directory Server" HOME=/usr/internet/openldap OLPIDFILE=/data/openldap/var/openldap_slapd.pid MYPID= RUNNING= if [ -x /usr/sbin/clu_get_info ] && /usr/sbin/clu_get_info -q then CLUSTER="YES" fi check_running() { if [ -f "$OLPIDFILE" ] then MYPID=`cat $OLPIDFILE` RUNNING=`/usr/bin/ps -e -p $MYPID -o command | grep slapd` fi if [ ! -z "$RUNNING" ] then return 1 else return 0 fi } case "$1" in 'start') if [ "$CLUSTER" = "YES" -a "$OPENLDAP_CAA" != "1" ] then /usr/sbin/caa_start -q openldap else check_running checkres=$? if [ $checkres = 1 ] then echo "$NAME already running" else $HOME/libexec/slapd -f $HOME/etc/slapd.conf fi fi ;; 'stop') if [ "$CLUSTER" = "YES" -a "$OPENLDAP_CAA" != "1" ] then exit 1 else check_running checkres=$? if [ $checkres = 1 ] then kill -TERM $MYPID fi fi ;; *) echo "usage: $0 {start|stop}" ;; esac
さらに,/etc/clua_services
ファイルに次の行を追加します。
openldap 389/tcp in_single,out_alias
2.14.2 CAA を使ってシングル・インスタンスの高可用性 Apache HTTP サーバを作成する
フェイルオーバ機能のあるシングル・インスタンスの Apache HTTP サーバを作成するには,次の手順に従います。
Web サイト (www.apache.org
) から最新の標準 Apache 配布ソフトウェアをクラスタにダウンロードし,そのサイトの指示に従って,Apache を構築し/usr/local/apache
ディレクトリにインストールします。
次のコマンドを使って,省略時の CAA アプリケーション・リソース・プロファイルと処理スクリプトを作成します。
# caa_profile -create httpd -t application -B /usr/local/apache/bin/httpd
省略時のプロファイルに使用されているフェイルオーバ・ポリシでは,httpd
サービスを提供しているメンバがクラスタから離れると他のメンバがそのサービスを引き継ぐようになっています。また,アクティブなクラスタ・メンバであれば,どのメンバでも
httpd
サービスを提供できるようになっています。フェイルオーバ・ポリシ,配置ポリシ,およびリソースの依存関係を省略時とは別のものにしたい場合は,プロファイルを編集します。
省略時の処理スクリプトには,httpd
サービスを起動する起動エントリ・ポイントと
httpd
サービスを停止する停止エントリ・ポイントがあります。
メンバの 1 つで次のコマンドを実行して,プロファイルを CAA に登録します。
# caa_register httpd
メンバの 1 つで次のコマンドを実行して,CAA から
httpd
サービスを起動します。
# caa_start httpd
2.14.3 CAA を使ってシングル・インスタンスの Oracle8i サーバを作成する
CAA を使って,フェイルオーバ機構を持つシングル・インスタンスの Oracle8i バージョン 8.1.7 のデータベース・サーバを作成するには,次の手順に従います。
Oracle8i のドキュメントに記述されている指示に従って,Oracle8 バージョン 8.1.7 をインストールして構成します。
Oracle では,特定のカーネル属性に特定の値を設定していること,特定の UNIX グループ (dba
,
oinstall
) を作成していること,特別な環境変数を初期化していることを必要とします。
Oracle8i シングル・サーバの CAA サービスをセットアップする前に,クライアント・アプリケーションにどの方法でサービスへアクセスさせるかを決める必要があります。
これには,TruCluster Server のクラスタ別名機能を使う方法と,インタフェース (IP) 別名を使う方法があります。クラスタ別名を使う場合は,Oracle8i サーバであるクラスタ・メンバごとにクラスタ別名を作成して,各別名のルーティングおよびスケジューリング属性を個別に最適化します
(クラスタ別名の作成方法についての詳細は,
cluamgr
(8)
クラスタ別名を使用するときは,/etc/hosts
ファイルに IP アドレスとクラスタ別名の名前を追加します。
次の行を
/etc/clua_services
ファイルに追加して,Oracle8i リスナが使用するポートの特性をセットアップします。
listener 1521/tcp in_single
in_single
属性を設定すると,クラスタ別名サブシステムが,省略時のクラスタ別名宛の接続要求を別名の 1 メンバに配信するようになります。そのメンバが利用できなくなると,クラスタ別名サブシステムは,省略時のクラスタ別名の別のメンバを選択して,そのメンバがすべての要求を受け取るようにします。
サービスの定義を再ロードするために,すべてのメンバで次のコマンドを実行します。
# cluamgr -f
クライアントから出す Oracle8i サービス要求の宛先としてインタフェース・アドレスを使用する場合は,IP アドレスとクラスタ別名の名前を
/etc/hosts
に追加します。
listener.ora
と
tnsnames.ora
ファイルにある
HOST
フィールドをたとえば次のように編集して,クライアントがサービスへアクセスするときに使用する各クラスタ別名を設定します。
. . . (ADDRESS = (PROTOCOL = TCP) (HOST = alias1) (PORT = 1521)) . . .
Oracle CAA スクリプトの例が
/var/cluster/caa/examples/DataBase/oracle.scr
にあります。このスクリプトを
/var/cluster/caa/script/oracle.scr
にコピーして,電子メール・アカウント,ログ・ファイルの出力先,別名の優先順位などを環境に合わせて編集します。スクリプト内にはファイル・システムの参照を含めないでください。
スクリプトの初期テストを行います。次の例に示すように,このテストでは,最初に,CAA の外で起動エントリ・ポイントおよび停止エントリ・ポイントを実行します。
# cd /var/cluster/caa/script # ./oracle.scr start
SysMan Station を使用するかまたは次のコマンドを実行して,CAA アプリケーション・リソース・プロファイルを作成します。
# caa_profile -create oracle -t application \ -d "ORACLE Single-Instance Service" -p restricted -h "member1 member2"
Oracle CAA リソース・プロファイルが
/var/cluster/caa/examples/DataBase/oracle.cap
にあるプロファイル例のようになっていることを確認してください。
メンバの 1 つで SysMan Station を使用するかまたは次のコマンドを実行して,oracle
プロファイルを CAA に登録します。
# caa_register oracle
メンバの 1 つで SysMan Station を使用するかまたは次のコマンドを実行して,oracle
サービスを起動します。
# caa_start oracle
2.14.4 CAA を使ってシングル・インスタンスの Informix サーバを作成する
CAA を使って,フェイルオーバ機構を持つシングル・インスタンスの Informix サーバを作成するには,次の手順に従います。
Informix のドキュメントにある指示に従って,Informix をインストールして構成します。
Informix では,特定のUNIXグループ (dba
,informix
) を作成することが必要です。
Informix シングル・サーバの CAA サービスをセットアップする前に,クライアント・アプリケーションにどの方法でサービスへアクセスさせるか決める必要があります。これには,TruCluster Server 製品のクラスタ別名機能を使う方法と,インタフェース (IP) 別名を使う方法があります。クラスタ別名を使う場合は,Informix サーバであるクラスタ・メンバごとにクラスタ別名を作成して,各別名のルーティングおよびスケジューリング属性を個別に最適化します
(クラスタ別名の作成方法についての詳細は,
cluamgr
(8)
クラスタ別名を使用するときは,/etc/hosts
ファイルに IP アドレスとクラスタ別名の名前を追加します。
次の行を
/etc/clua_services
ファイルに追加して,Informix リスナが使用するポートの特性をセットアップします。
informix 8888/tcp in_single
in_single
属性を設定すると,クラスタ別名サブシステムは,クラスタ別名宛の接続要求を別名の 1 メンバに配信するようになります。そのメンバが利用できなくなると,クラスタ別名サブシステムは,クラスタ別名の別のメンバを選択して,そのメンバがすべての要求を受け取るようにします。
サービスの定義を再ロードするために,すべてのメンバで次のコマンドを実行します。
# cluamgr -f
クライアントから出す Informix サービス要求の宛先としてインタフェース・アドレスを使用する場合は,IP アドレスとクラスタ別名の名前を
/etc/hosts
に追加します。
Informix CAA スクリプトの例が
/var/cluster/caa/examples/DataBase/informix.scr
にあります。このスクリプトを
/var/cluster/caa/script/informix.scr
にコピーして,電子メール・アカウント,ログ・ファイルの出力先や別名の優先順位などを環境に合わせて編集します。スクリプト内にはファイル・システムの参照を含めないでください。
スクリプトの初期テストを行います。次の例に示すように,このテストでは,最初に,CAA の外で起動エントリ・ポイントおよび停止エントリ・ポイントを実行します。
# cd /var/cluster/caa/script # ./informix.scr start
SysMan Station を使用するかまたは次のコマンドを実行して,CAA アプリケーション・リソース・プロファイルを作成します。
# caa_profile -create informix -t application \ -d "INFORMIX Single-Instance Service" -p restricted -h "member1 member2"
Informix CAA リソース・プロファイルが
/var/cluster/caa/examples/DataBase/informix.cap
にあるプロファイル例のようになっていることを確認してください。
メンバの 1 つで SysMan Station を使用するかまたは次のコマンドを実行して,informix
プロファイルを CAA に登録します。
# caa_register informix
メンバの 1 つで SysMan Station を使用するかまたは次のコマンドを実行して,informix
サービスを起動します。
# caa_start informix