この章では,CAA (Cluster Application Availability) サブシステムによる高可用性アプリケーションの管理について取り上げ,次の項目について説明します。
リソースの状態の調査 (8.1 節)
リソースの可用性計測レポート(8.2 節)
アプリケーションの再配置 (8.3 節)
アプリケーション・リソースの起動と停止 (8.4 節)
アプリケーションの平衡 (8.5 節)
アプリケーション・リソースの登録と登録取り消し (8.6 節)
ネットワーク,テープ,メディア・チェンジャ・リソースの管理 (8.7 節)
SysMan を使用した CAA の管理 (8.8 節)
起動時およびシャットダウン時の CAA サブシステムに関する考慮事項の理解 (8.9 節)
CAA デーモン
caad
の管理 (8.10 節)
EVM による CAA のイベントの表示 (8.11 節)
イベントを使用したトラブルシューティング (8.12 節)
コマンド行メッセージを使用したトラブルシューティング (8.13 節)
CAA サブシステムによるアプリケーションのセットアップについての詳細は,TruCluster Server 『クラスタ高可用性アプリケーション・ガイド』を参照してください。CAA サブシステムについての概説は,TruCluster Server 『クラスタ概要』を参照してください。
CAA サブシステムの制御下で動作する高可用性アプリケーションであれば,その管理は自動的に行われます。ただし,高可用性アプリケーションの管理を手動で行うことが必要な場合もあります。その場合には,たとえば次のような状況が発生します。
クラスタ・メンバのシャットダウンまたはリブート
シャットダウンするメンバ上でどの高可用性アプリケーションが動作しているかを調べ (caa_stat
を使用),そのメンバ上のアプリケーションを手動で再配置できます (caa_relocate
を使用)。
負荷分散
クラスタのさまざまなメンバ上の負荷の変化に応じて,負荷が軽めのメンバにアプリケーションを手動で再配置します (caa_stat
と
caa_relocate
を使用)。caa_balance
を実行してアプリケーションの配置をチェックして,優先度の高い別のクラスタ・メンバが利用可能な場合に限り,再配置します。
新規アプリケーション・リソースのプロファイルの作成
未登録,未起動のアプリケーション・リソースのプロファイルを作成します (caa_register
と
caa_start
を使用)。
既存アプリケーション・リソースのプロファイルの更新
アプリケーション・リソースを更新し,更新を有効にします (caa_register
-u
を使用)。
既存アプリケーション・リソースの廃止
廃止予定のアプリケーション・リソースを停止し,登録を取り消します (caa_stop
と
caa_unregister
を使用)。
アプリケーション・リソースを使っての作業では,リソースの名前がそのリソースに関連付けられたアプリケーションの実際の名前と必ずしも一致するわけではありません。アプリケーション・リソースの名前は,リソース・プロファイルのルート名と一致します。たとえば,cluster_lockd
という名前のアプリケーション・リソースがあるとすると,このリソースのプロファイルは
/var/cluster/caa/profile/cluster_lockd.cap
です。このリソースに関連付けられたアプリケーションは
rpc.lockd
と
rpc.statd
です。
このようにアプリケーション・リソースの名前とそのリソースに関連付けられたアプリケーションの名前が異なる場合があるので,アプリケーション名を使って,クラスタ内で動作するプロセスのリスト内でリソースを検索しても見つからない場合があります。CAA サブシステムを使ってアプリケーションを管理するときは,リソース名を使用しなければなりません。
8.1 リソースの状態の調査
登録済みのリソースは,次の 3 つのうちのいずれかの状態になります。
ONLINE
アプリケーション・リソースの場合,そのリソースに関連付けられたアプリケーションは正常に動作しています。
ネットワーク,テープ,またはメディア・チェンジャ・リソースの場合,そのリソースに関連付けられたデバイスは使用可能であり,正常に機能しています。
そのアプリケーション・リソースは動作していません。そのリソースは,既に登録されていますが
caa_start
によって起動されなかったか,caa_stop
によって早期に正常に停止された可能性があります。ネットワーク,テープ,またはメディア・チェンジャ・リソースの場合,そのリソースに関連付けられたデバイスが正常に機能していません。さらに,プロファイル内の
FAILURE_THRESHOLD
の値よりも多くの回数のエラーがそのリソースに発生した場合も,この状態になります。
UNKNOWN
CAA はそのアプリケーションが実行中であるか,リソースの処理スクリプトの停止エントリ・ポイントの実行の失敗によるか,判断できません。この状態は,アプリケーション・リソースにのみ適用されます。リソースの処理スクリプトにある停止エントリ・ポイントを調べて,失敗 (0 以外の値が返される) の原因を調べます。
CAA は常に,アプリケーション・リソースの状態をそのターゲット状態に一致させようとします。ターゲット状態は,caa_start
を使用すると
ONLINE
に設定され,caa_stop
を使用すると
OFFLINE
に設定されます。ターゲット状態が,アプリケーション・リソースの状態と等しくない場合は,CAA によりアプリケーションを起動または停止している途中か,アプリケーションの実行または起動に失敗したかのいずれかです。非アプリケーション・リソースのターゲット状態が常に
OFFLINE
の場合,そのリソースは障害しきい値内で何度も障害が発生しています。詳細については,8.7 節を参照してください。
ターゲット・フィールドと状態フィールドの情報から,リソースの状態を判断することができます。その 2 つのフィールドの組み合わせの意味は表 8-1
(アプリケーション),表 8-2
(ネットワーク),表 8-3
(テープ,メディア・チェンジャ) に示されています。両方とも
ONLINE
でないリソースの状態とターゲットの組み合わせがある場合,すべてのリソースは
OFFLINE
の状態になります。
表 8-1: アプリケーション・リソースのターゲットと状態の組み合わせ
ターゲット | 状態 | 説明 |
ONLINE |
ONLINE | アプリケーションが正常に開始した。 |
ONLINE | OFFLINE | 起動コマンドが発行されたが,処理スクリプトの起動エントリ・ポイントの実行がまだ完了していない。 |
必要なリソースの障害のため,アプリケーションが停止した。 | ||
新クラスタ・メンバの開始または追加のため,アプリケーションが有効な配置状態で,再配置中である。 | ||
明示的再配置またはクラスタ・メンバの障害のため,アプリケーションが再配置中である。 | ||
アプリケーションを開始する適切なメンバが使用できない。 | ||
OFFLINE | ONLINE | 停止コマンドが発行されたが,処理スクリプトの停止エントリ・ポイントの実行がまだ完了していない。 |
OFFLINE | OFFLINE | アプリケーションがまだ起動されていない。 |
障害のしきい値に到達したため,アプリケーションが停止した。 | ||
アプリケーションが正常に停止した。 | ||
ONLINE | UNKNOWN | 処理スクリプトの停止エントリ・ポイントが障害を返した。 |
OFFLINE | UNKNOWN | 状態が UNKNOWN のアプリケーションでアプリケーション停止コマンドが発行された。処理スクリプトの停止エントリ・ポイントはまだ障害を返す。アプリケーション状態を OFFLINE に設定するには,caa_stop
-f
を使用する。 |
表 8-2: ネットワーク・リソースのターゲットと状態の組み合わせ
ターゲット | 状態 | 説明 |
ONLINE |
ONLINE | ネットワークが正常に機能している。 |
ONLINE | OFFLINE | クラスタ・メンバはネットワークへの直接的な接続を持たない。 |
OFFLINE | ONLINE | 障害のしきい値に到達したため,ネットワーク・カードの障害と想定され,CAA で監視されなくなる。 |
OFFLINE | OFFLINE | ネットワークとマシンとの直接接続が不可である。 |
障害のしきい値に到達したため,ネットワーク・カードの障害と想定され,CAA で監視されなくなる。 |
表 8-3: テープ,メディア・チェンジャ・リソースのターゲットと状態の組み合わせ
ターゲット | 状態 | 説明 |
ONLINE |
ONLINE | テープまたはメディア・チェンジャはマシンと直接的に接続され,正常に機能している。 |
ONLINE | OFFLINE | リソースに関連したテープ装置またはメディア・チェンジャがイベント・マネージャ (EVM) イベントを送信し,正常に動作しなくなる。リソースには障害があると考えられる。 |
OFFLINE | ONLINE | 障害のしきい値に到達したため,テープ装置またはメディア・チェンジャの障害と想定され,CAA で監視されなくなる。 |
OFFLINE | OFFLINE | テープ装置またはメディア・チェンジャがクラスタ・メンバへ直接接続できない。 |
リソースの状態を調べるには,次のように
caa_stat
コマンドを入力します。
# caa_stat resource_name
このコマンドのリターン値は次のとおりです。
NAME
リソース・プロファイルの
NAME
フィールドに指定されたリソース名が表示されます。
TYPE
リソースの種類 (application
,tape
,changer
,または
network
) が表示されます。
TARGET
アプリケーション・リソースの場合は,状態の
ONLINE
または
OFFLINE
が表示されます。CAA はアプリケーションをその状態にしようとします。その他の種類のリソースの場合は,そのリソースに関連付けられたデバイスの障害回数が障害しきい値より高くない限り,ターゲットは常に
ONLINE
になります。高い場合,TARGET
は
OFFLINE
になります。
STATE
アプリケーション・リソースの場合は,ONLINE
または
OFFLINE
が表示されます。リソースがオンラインのときは,現在稼働中のクラスタ・メンバの名前も表示されます。処理スクリプトの停止エントリ・ポイントで障害が返された場合,アプリケーションの状態は
UNKNOWN
にもなります。アプリケーション・リソースは,正常に停止するまで,アクティブになれません。その他の種類のリソースの場合は,クラスタのメンバごとに
ONLINE
または
OFFLINE
の状態が表示されます。
このコマンドの実行例は次のとおりです。
# caa_stat clock NAME=clock TYPE=application TARGET=ONLINE STATE=ONLINE on provolone
スクリプトを使ってリソースがオンラインかどうかを調べるには,
caa_stat
コマンドに
-r
オプションを使用します。たとえば,次のように記述します。
# caa_stat resource_name -r ; echo $?
リソースが
ONLINE
状態の場合は,値 0 (ゼロ) が返ります。
スクリプトを使ってアプリケーション・リソースが登録済みかどうかを調べるには,caa_stat
コマンドに
-g
オプションを使用します。たとえば,次のように記述します。
# caa_stat resource_name -g ; echo $?
リソースが登録済みの場合は,値 0 (ゼロ) が返ります。
8.1.2 特定のクラスタ・メンバ上のすべてのリソースの調査
caa_stat
-c
cluster_member
コマンドは,cluster_member
上のすべてのリソースの状態を返します。このコマンドの実行例は次のとおりです。
# caa_stat -c polishham NAME=dhcp TYPE=application TARGET=ONLINE STATE=ONLINE on polishham NAME=named TYPE=application TARGET=ONLINE STATE=ONLINE on polishham NAME=xclock TYPE=application TARGET=ONLINE STATE=ONLINE on polishham
このコマンドが役立つのは,クラスタのメンバをシャットダウンする前に,どのアプリケーションをフェイルオーバまたは手動再配置の対象にするか調べるときです。
8.1.3 すべてのクラスタ・メンバ上のすべてのリソースの調査
caa_stat
コマンドは,すべてのクラスタ・メンバ上のすべてのリソースの状態を返します。このコマンドの実行例は次のとおりです。
# caa_stat NAME=dhcp TYPE=application TARGET=ONLINE STATE=ONLINE on polishham NAME=xclock TYPE=application TARGET=ONLINE STATE=ONLINE on provolone NAME=named TYPE=application TARGET=OFFLINE STATE=OFFLINE NAME=ln0 TYPE=network TARGET=ONLINE on provolone TARGET=ONLINE on polishham TARGET=ONLINE on peppicelli STATE=OFFLINE on provolone STATE=ONLINE on polishham STATE=ONLINE on peppicelli
オプション -t を使用すると,表形式で情報が表示されます。たとえば,次のように表示されます。
# caa_stat -t Name Type Target State Host --------------------------------------------------------- cluster_lockd application ONLINE ONLINE provolone dhcp application OFFLINE OFFLINE named application OFFLINE OFFLINE ln0 network ONLINE ONLINE provolone ln0 network ONLINE OFFLINE polishham
caa_stat
-v
コマンドは,すべてのクラスタ・メンバ上のすべてのリソースの状態とともに,それらのリソースの障害回数と再起動回数も返します。このコマンドの実行例は次のとおりです。
# caa_stat -v NAME=cluster_lockd TYPE=application RESTART_COUNT=0 RESTART_ATTEMPTS=30 REBALANCE= FAILURE_COUNT=0 FAILURE_THRESHOLD=0 TARGET=ONLINE STATE=ONLINE on provolone NAME=dhcp TYPE=application RESTART_COUNT=0 RESTART_ATTEMPTS=1 REBALANCE= FAILURE_COUNT=1 FAILURE_THRESHOLD=3 TARGET=ONLINE STATE=OFFLINE NAME=ln0 TYPE=network FAILURE_THRESHOLD=5 FAILURE_COUNT=1 on provolone FAILURE_COUNT=0 on polishham TARGET=ONLINE on provolone TARGET=OFFLINE on polishham STATE=ONLINE on provolone STATE=OFFLINE on polishham
-t オプションを使用すると,情報が表形式で表示されます。このコマンドの実行例は次のとおりです。
# caa_stat -v -t Name Type R/RA F/FT Target State Host Rebalance ------------------------------------------------------------------------------------- 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 ln0 network 0/5 ONLINE ONLINE provolone ln0 network 1/5 ONLINE OFFLINE polishham
この情報によって,頻繁に障害が発生しているリソースや何度も再起動されたリソースを簡単に特定できます。
8.2 リソースの可用性計測レポート
CAA は最初に起動されてからの各アプリケーション・リソースの履歴を保持しています。caa_report
コマンドは,ONLINE
状態にあり,現在登録されているすべてのアプリケーション・リソースの
ONLINE
状態であった時間の割合をまとめたレポートを出力します。このデータは,CAA 関連の Event Management イベントを分析した結果です。
アプリケーションの稼働履歴を追跡するファイルは,毎日,AM 3 時 に自動的に更新されます。この時間に
caa_report
コマンドがルートで実行されます。この定期的なマージを行う時間と頻度の変更は,/var/cluster/caa/clustercron/caa_report.clustercronData
で定義された
crontab
フォーマットを変更します。
このコマンドは,アプリケーションの開始時刻と,アプリケーションが
ONLINE
状態であった時間 (総時間に対する割合) を示します。
出力例は次のとおりです。
#/usr/bin/caa_report Application Availability Report for rubble Applications starting/ending uptime --------------------------------------------------------------- autofs NEVER STARTED 0.00 % cluster_lockd Fri Jul 27 11:00:48 2001 99.80 % Thu Oct 4 12:31:14 2001 clustercron Fri Jul 27 11:01:08 2001 100.00 % Thu Oct 4 12:31:14 2001 dmiller1 Tue Sep 25 13:57:51 2001 12.51 % Thu Oct 4 12:31:14 2001
指定された時間に実行されていないすべてのアプリケーションを対象外にできます。次に例を示します。
#/usr/bin/caa_report -o Application Availability Report for rubble Applications starting/ending uptime --------------------------------------------------------------- cluster_lockd Fri Jul 27 11:00:48 2001 99.80 % Thu Oct 4 12:31:14 2001 clustercron Fri Jul 27 11:01:08 2001 100.00 % Thu Oct 4 12:31:14 2001 dmiller1 Tue Sep 25 13:57:51 2001 12.51 % Thu Oct 4 12:31:14 2001
開始時刻と終了時刻を指定して,その範囲で稼働時間の割合を測定をすることができます。開始時刻と終了時刻は,
date
(1)
次のルールに従って時刻を指定します。
終了時刻は開始時刻より後にしなければならない。
開始時刻が指定されていない場合,アプリケーションが起動された最も早い時刻を使用する。
終了時刻が指定されていない場合,現時点の時刻を使用する。
終了時刻が現時点より以降に指定されている場合,現時点の時刻を使用する。
指定された開始時刻以前にアプリケーションが実行されていない場合,アプリケーションが起動された最初の時刻を使用する。
指定された開始時刻以前にアプリケーションが実行されていたが,指定開始時刻ではダウンしている場合,指定された開始時刻を使用する。
出力では,分析に使用された実時間を表示する。
開始時刻と終了時刻の指定例は,次のとおりです。
#/usr/bin/caa_report -b 12/03/01 -e 12/04/01 Application Availability Report for rubble Applications starting/ending uptime --------------------------------------------------------------- autofs NEVER STARTED 0.00 % cluster_lockd Wed Oct 3 00:00:00 2001 100.00 % Thu Oct 4 00:00:00 2001 clustercron Wed Oct 3 00:00:00 2001 100.00 % Thu Oct 4 00:00:00 2001 dmiller1 Wed Oct 3 00:00:00 2001 92.54 % Thu Oct 4 00:00:00 2001
クラスタ・メンバ間でのアプリケーションの再配置では次のような状況が考えられます。
クラスタの 1 つのメンバ上のすべてのアプリケーションを別のメンバに再配置する (8.3.1 項)
クラスタの 1 つのメンバ上の特定のアプリケーションを別のメンバに再配置する (8.3.2 項)
依存関係にあるアプリケーションを別のメンバに再配置する (8.3.3 項)
アプリケーションを再配置するには,caa_relocate
コマンドを使用します。アプリケーションを再配置すると必ず,システムから再配置を追跡するメッセージが返されます。たとえば,次のようなメッセージが返されます。
Attempting to stop `cluster_lockd` on member `provolone` Stop of `cluster_lockd` on member `provolone` succeeded. Attempting to start `cluster_lockd` on member `pepicelli` Start of `cluster_lockd` on member `pepicelli` succeeded.
以降の各項で,アプリケーションの再配置についてより詳しく説明します。
8.3.1 クラスタ・メンバ上のすべてのアプリケーションの手動再配置
クラスタの 1 つのメンバをシャットダウンすると,そのメンバ上で動作する CAA 制御下のアプリケーションはすべて,各アプリケーションの配置ポリシに従って,自動的に再配置されます。ただし次の理由から,メンバのシャットダウン前にそのメンバ上のすべてのアプリケーションの手動再配置が必要な場合があります。
複数のメンバをシャットダウンする場合は,即時シャットダウンするメンバにアプリケーションが自動的に再配置されないようにする必要があるため。
メンバに問題または障害が発生している場合は,そのメンバ上で動作するアプリケーション・リソースに対する性能劣化を最小にする必要があるため。
作業環境の崩壊を最小限にして,クラスタ・メンバ上で保守を行う場合。
member1
上のすべてのアプリケーションを
member2
に再配置するには,次のコマンドを入力します。
# caa_relocate -s member1 -c member2
member1
上のすべてのアプリケーションを各アプリケーションの配置ポリシに従って再配置するには,次のコマンドを入力します。
# caa_relocate -s member1
caa_stat
コマンドを使って,すべてのアプリケーション・リソースが正常に再配置されたことを確認します。
8.3.2 特定のアプリケーションの手動再配置
次の理由から,特定のクラスタ・メンバへの特定のアプリケーションの手動再配置が必要な場合があります。
特定のアプリケーションを現在実行中のクラスタ・メンバに過負荷がかかっているので,負荷が小さい別のメンバ上でそのアプリケーションを実行する必要があるため。
クラスタのメンバをシャットダウンしようとしているが,再配置ポリシによって選択されない可能性があるメンバ上で,特定のアプリケーションを実行する必要があるため。
member2
に特定のアプリケーションを再配置するには,次のコマンドを入力します。
# caa_relocate resource_name -c member2
caa_stat
コマンドを使って,アプリケーション・リソースが正常に再配置されたことを確認します。
8.3.3 依存関係にあるアプリケーションの手動再配置
相互依存するアプリケーションのグループの再配置が必要な場合があります。リソース・プロファイル内で
REQUIRED_RESOURCE
フィールドに最低 1 つの他のアプリケーション・リソースが列挙指定されている場合,このプロファイルを持つアプリケーション・リソースは,列挙された他のアプリケーション・リソースと依存関係にあります。他のアプリケーション・リソースと依存関係にあるアプリケーション・リソースを再配置する場合は,caa_relocate
コマンドに
-f
オプションを使って手動再配置を行わなければなりません。
手動再配置を行うと,CAA デーモンは,指定されたアプリケーション・リソースおよびそれと依存関係にあるアプリケーション・リソースをすべて再配置します。つまり,指定されたアプリケーション・リソースとともに,指定されたリソースが依存するリソースも,指定されたリソースに依存する
ONLINE
状態のリソースも再配置されます。依存関係が間接的な場合もあります。つまり,1 つのリソースが中間の 1 つ以上のリソースを介して別のリソースに依存している場合です。
特定のアプリケーション・リソースおよびそれと依存関係にあるアプリケーション・リソースを
member2
に再配置するには,次のコマンドを入力します。
# caa_relocate resource_name -f -c member2
caa_stat
コマンドを使って,アプリケーション・リソースが正常に再配置されたことを確認します。
8.4 アプリケーション・リソースの起動と停止
以降の各項で,CAA アプリケーション・リソースの起動および停止方法について説明します。
注意
CAA が管理するアプリケーション・リソースの起動には
caa_start
,停止にはcaa_stop
,または SysMan の同等のものを必ず使用してください。CAA に登録した後は,絶対に手動でアプリケーションを起動,停止しないでください。
アプリケーション・リソースを起動するには,起動するリソースの名前を後ろに指定して
caa_start
コマンドを実行します。アプリケーション・リソースを起動する前に,caa_register
を使ってそのリソースを登録しておく必要があります。
caa_start
コマンドの実行後すぐにターゲットには
ONLINE
が設定されます。CAA のサブシステムがアプリケーションを起動し,状態をターゲットと同じものにします。リソースに関連するアプリケーションは,ターゲット状態が
ONLINE
に設定され,CAA サブシステムはこれらを起動しようとします。
リソースの再配置ポリシによって選択されるクラスタ・メンバ上で,clock
というアプリケーション・リソースを起動するには,次のコマンドを入力します。
# /usr/sbin/caa_start clock
たとえば,このコマンドの出力は次のようになります。
Attempting to start `clock` on member `polishham` Start of `clock` on member `polishham` succeeded.
このコマンドは,リソースの処理スクリプトが呼び出されるたびに,SCRIPT_TIMEOUT
の値に達するまで,そのスクリプトから成功または失敗の通知が来るのを待ちます。
クラスタの特定のメンバ上で
clock
というアプリケーション・リソースを起動するには (ただしそのメンバが再配置ポリシによって許可されることが前提),次のコマンドを入力します。
# /usr/sbin/caa_start clock -c member_name
指定したメンバが使用可能でない場合,そのリソースは起動されません。
指定したリソースと依存関係にあるリソースが,指定したメンバ上で使用可能でなく,起動できない場合,caa_start
の実行は失敗し,依存関係の問題でアプリケーション・リソースが起動できなかったというメッセージが表示されます。
指定したリソースおよびそれと依存関係にあるリソースをすべて強制的に起動または同じメンバへ再配置するには,次のコマンドを使用します。
# /usr/sbin/caa_start -f clock
注意
システム・クラッシュが起こったクラスタ・メンバでアプリケーションを起動しようとする場合,caa_start は中間結果を表示することができます。このシナリオでは,処理スクリプトの起動セクションが実行されますが,クラスタ・メンバは,コマンド行に開始の通知が表示される前にクラッシュします。
caa_start
コマンドは,Remote start for [resource_name] failed on member [member_name].
というエラーを表示して,失敗状態を返します。アプリケーション・リソースは実際にはONLINE
で,別のメンバへのフェイルオーバは,アプリケーションが間違ったメンバ上で起動されたかのように見えます。そのメンバ上でアプリケーション・リソースの起動中にクラスタ・メンバが失敗した場合は,
caa_stat
でクラスタ上のリソースの状態をチェックして,そのリソースの状態を判断する必要があります。
詳細は,
caa_start
(8)8.4.2 アプリケーション・リソースの停止
アプリケーション・リソースを停止するには,停止するアプリケーション・リソースの名前を後ろに指定して
caa_stop
コマンドを使用します。前述したように,kill
コマンドやその他の方法を使って,CAA 制御下のアプリケーション・リソースを停止しないでください。
caa_stop
コマンドの実行後すぐにターゲットには
OFFLINE
が設定されます。CAA のサブシステムがアプリケーションを停止し,状態をターゲットと同じにします。
たとえば,clock
というアプリケーション・リソースを停止するには,次のコマンドを使用します。
# /usr/sbin/caa_stop clock
指定したリソースと依存関係にある他のアプリケーション・リソースがある場合,このコマンドではそのアプリケーションは停止されません。代わりに,依存関係の問題でアプリケーション・リソースが停止できなかったというメッセージが表示されます。指定したリソースおよびそれと依存関係にあるリソースをすべて強制停止するには,次のコマンドを入力します。
# /usr/sbin/caa_stop -f clock
詳細は,
caa_stop
(8)8.4.3 複数インスタンスが作成されないアプリケーション・リソース
複数または 1 つのメンバ上で同じアプリケーション・リソースに対して複数のコマンド
start
または
stop
(あるいはその両方) を同時に実行した場合,そのリソースにどのコマンドが反映されるかわかりません。ただし,start
コマンドを複数回実行しても,アプリケーション・リソースのインスタンスは複数作成されません。
8.4.4 caa_stop を使用した UNKNOWN 状態のリセット
アプリケーション・リソースの状態が
UNKNOWN
に設定されている場合は,最初に
caa_stop
を実行してください。このコマンドでリソースが
OFFLINE
にリセットされない場合は,caa_stop
-f
コマンドを使用してください。このコマンドは,停止スクリプトで返されるあらゆるエラーを無視して,リソースを
OFFLINE
に設定し,アプリケーション・リソースを利用するすべてのアプリケーションを同様に
OFFLINE
に設定します。
アプリケーション・リソースを再起動する前に,処理スクリプトの停止エントリ・ポイントで確実にアプリケーションが正常に停止し,0 が返されるかどうかを確認してください。また,アプリケーションが現在実行されていない場合も,0 が返されることを確認してください。
8.5 アプリケーション・リソースの分散
アプリケーション・リソースの分散では,クラスタ上のリソースの現在の状態とリソースの配置ルールとに基づいてアプリケーション・リソースの配置を再評価します。アプリケーションの分散は,クラスタ単位として,メンバ単位として,または指定されたリソースで行われます。分散は,CAA 標準の配置決定メカニズムを使用し,負荷を考慮しないで決定されます。
アプリケーションの分散は,最も好ましいメンバに配置するか (favored
または
restricted
の配置ポリシを使用する場合),または,より平等に,実行する CAA アプリケーション・リソースの数をクラスタ・メンバに割り当てます (balanced
配置ポリシを使用する場合)。
あるクラスタ・メンバから別のクラスタ・メンバへのアプリケーションの再配置は,次の方法で行います。
クラスタのすべてのアプリケーションを分散する (8.5.1 項)
クラスタ・メンバのすべてのアプリケーションを分散する (8.5.2 項)
指定されたアプリケーションを分散する (8.5.3 項)
指定されたアプリケーションを特定の時刻で分散する (8.5.4 項)
caa_balance
コマンドは,アプリケーション・リソースだけに使用できます。ネットワーク,テープ,またはメディア・チェンジャ・リソースを分散することはできません。
クラスタ単位での分散では,クラスタ上のすべての
ONLINE
状態のアプリケーション・リソースを再評価し,配置決定メカニズムによって選択されたクラスタ・メンバ上で動作していない場合,そのリソースを再配置します。
詳細は
caa_balance
(8) を参照してください。
以降の各項で,アプリケーションの分散について詳しく説明します。
8.5.1 クラスタのすべてのアプリケーションを分散する
クラスタのすべてのアプリケーションを分散するには,次のコマンドを使用します。
# /usr/sbin/caa_balance -all
アプリケーション test と test2 は,ONLINE
状態のただ 2 つのアプリケーションで,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.
ONLINE
状態のアプリケーションがクラスタにより多く存在する場合には,各アプリケーション・リソースで行う動作を反映して,出力も多くなります。
8.5.2 クラスタ・メンバのすべてのアプリケーションを分散する
クラスタ・メンバの rye で実行されるアプリケーションの配置を再評価するには,次のコマンドを使用します。
# /usr/sbin/caa_balance -s rye
アプリケーション test と test2 は,ONLINE
状態のただ 2 つのアプリケーションで,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.
ONLINE
状態のアプリケーションがクラスタにより多く存在する場合には,各アプリケーション・リソースで行う動作を反映して,出力も多くなります。
8.5.3 指定されたアプリケーションを分散する
指定されたアプリケーションを分散するには,次のコマンドを使用します。
# /usr/sbin/caa_balance test test2
アプリケーション 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.
単一アプリケーションを特定の時刻で分散するには,プロファイルに
REBALANCE
属性を設定します。この機能は,決まった時刻でアプリケーションをフェイルバックさせるのに役立ちます。アプリケーション・リソースに対して
REBALANCE
属性に特定の時刻を設定すると,そのアプリケーションはその時刻で最適なメンバに再配置されます。Active Placement 属性を使用しても,最適なメンバにフェイルバックされますが,フェイルバックが発生するのは,favored 配置ポリシで指定されたメンバがクラスタに再び加わったときだけです。これは,アプリケーションの可用性を妨げたくない期間中に再配置を発生させることもあります。Active Placement 属性の代わりに
REBALANCE
属性を使用すると,指定した時刻にアプリケーションが優先メンバにフェイルバックするだけです。
t:day:hour:min
という形式で,プロファイルに時刻の値を指定する必要があります。ここで
day
は曜日 (0-6 で,日曜日が 0),hour
は時間 (0-23),min
は分 (0-59) で,この指定された時間で再評価が行われます。アスタリスクは,毎日,毎時間,毎分を指定するためにワイルドカードとして使用できます。
REBALANCE
属性は
clustercron
リソースを使用します。このリソースは,クラスタ単位の
cron
の CAA 固有の実装であり,次の URL からアクセスできる Best Practice ドキュメントの『Using cron in a TruCluster Server Cluster』に説明があります。
http://www.tru64unix.compaq.com/docs/best_practices/BP_CRON/TITLE.HTM.
この固有の実装は,再分散のスケジュールのために CAA により内部的に使用され,その他の用途にはサポートされていません。
REBALANCE
属性の設定の方法の例は 『クラスタ高可用性アプリケーション・ガイド』 を参照してください。
8.6 アプリケーション・リソースの登録と登録取り消し
CAA がリソースを管理するには,そのリソースを CAA サブシステムに登録しておく必要があります。この登録作業はリソースごとに一度行うだけで済みます。
アプリケーション・リソースを登録するには,/var/cluster/caa/profile
ディレクトリ内にそのリソースのプロファイルが必要です。リソース・プロファイルの作成手順については,TruCluster Server 『クラスタ高可用性アプリケーション・ガイド』を参照してください。
クラスタ内のどのリソースが登録済みかを調べるには,次のように
caa_stat
コマンドを使用します。
# /usr/sbin/caa_stat
アプリケーション・リソースを登録するには,次のように
caa_register
コマンドを使用します。
# caa_register resource_name
たとえば,dtcalc
というアプリケーション・リソースを登録するには,次のコマンドを入力します。
# /usr/sbin/caa_stat dtcalc
登録するアプリケーション・リソースのプロファイルの
REQUIRED_RESOURCES
属性に,そのリソースと依存関係にあるリソースが列挙定義されている場合,この属性の列挙されたすべてのリソースをまず登録しなければなりません。
詳細については,
caa_register
(8)8.6.2 リソースの登録取り消し
アプリケーション・リソースの登録を取り消して CAA サブシステムによる監視対象から削除することが必要な場合があります。アプリケーション・リソースの登録を取り消すには,まず最初に停止させ,リソースの状態を
OFFLINE
に変更する必要があります。アプリケーションの停止方法については,8.4.2 項を参照してください。
アプリケーション・リソースの登録を取り消すには,caa_unregister
コマンドを使用します。たとえば,dtcalc
というリソースの登録を取り消すには,次のコマンドを入力します。
# /usr/sbin/caa_unregister dtcalc
詳細は,
caa_unregister
(8)
SysMan Menu によるリソースの登録と登録取り消しについては,SysMan のオンライン・ヘルプを参照してください。
8.6.3 登録の更新
アプリケーション・リソースのプロファイルを変更した場合は,その登録を更新しなければならないことがあります。リソース・プロファイルについての詳細は,『クラスタ高可用性アプリケーション・ガイド』 を参照してください。
リソースの登録を更新するには,caa_register
-u
コマンドを使用します。たとえば,dtcalc
というリソースを更新するには,次のように入力します。
# /usr/sbin/caa_register -u dtcalc
注意
caa_register -u
コマンドと SysMan Menu を使用すれば,ONLINE
状態のリソースのプロファイルにあるREQUIRED_RESOURCES
フィールドを更新して,OFFLINE
状態にあるリソースの名前を追加することができます。ただし,REQUIRED_RESOURCES
フィールドを更新してOFFLINE
状態にあるアプリケーションを追加 すると,システムがプロファイルと同期しなくなることがあります。このような更新を実行する場合は,手動で必要なリソースを起動するか,更新したリソースを停止しなければなりません。同じように,プロファイルにある
HOSTING_MEMBERS
リストの値を変更すると,その後の再配置と起動に影響します。ONLINE
状態のアプリケーション・リソースのプロファイルにあるHOSTING_MEMBERS
リストを更新して配置ポリシを restricted にする場合は,そのリストに登録されているいずれかのクラスタ・メンバでそのアプリケーションが実行中であることを確認してください。資格のあるどのメンバでもそのアプリケーションが実行されていないときは,caa_register -u
を実行した後,そのアプリケーションに対してcaa_relocate
を実行します。
8.7 ネットワーク,テープ,およびメディア・チェンジャ・リソース
アプリケーション・リソースのみ
caa_stop
を使用して停止できます。ただし,非アプリケーション・リソースで,障害発生間隔の範囲でリソース障害しきい値を上回る障害が発生した場合は,caa_start
を使用して該当するリソースを再起動できます。非アプリケーション・リソースを起動すると,その
TARGET
値が
ONLINE
にリセットされます。これにより,このリソースに依存するアプリケーションはすべて起動されます。
ネットワーク,テープ,およびメディア・チェンジャ・リソースでは,ハードウェアの問題が原因で何度も障害が発生するおそれがあります。このようになった場合は,障害の発生するクラスタ・メンバで CAA がそのデバイスを使用できないようにして,可能であれば,アプリケーション・リソースを再配置または停止してください。障害発生間隔の範囲で障害しきい値を上回ると,デバイスのリソースが使用できなくなります。リソースが使用できなくなった場合は,特定のクラスタ・メンバ上のリソースの
TARGET
状態が,caa_stat
resource_name
で示したように,OFFLINE
に設定されます。
たとえば,以下のようになります。
# /usr/sbin/caa_stat network1
NAME=network1 TYPE=network TARGET=OFFLINE on provolone TARGET=ONLINE on polishham STATE=ONLINE on provolone STATE=ONLINE on polishham
ネットワーク,テープ,またはチェンジャ・リソースの
TARGET
状態が,障害発生間隔の範囲で障害回数が障害しきい値を上回ったために
OFFLINE
に設定された場合は,該当するリソースを利用するすべてのリソースの
STATE
が
OFFLINE
になります。ただし,TARGET
は
ONLINE
のままです。このような依存関係にあるアプリケーションは,リソースが
ONLINE
になっている別のマシンに再配置されます。このリソースを
ONLINE
にしているクラスタ・メンバが存在しない場合,アプリケーションは,現在のメンバ上のリソースの
STATE
と
TARGET
が
ONLINE
になるまで,OFFLINE
のままです。
非アプリケーション・リソースの
TARGET
状態を
ONLINE
にリセットするには,caa_start
(すべてのメンバの場合) コマンドまたは
caa_start
-c
cluster_member
コマンド (特定のメンバの場合) を使用します。処理が終わると,障害回数もゼロ (0) にリセットされます。
STATE
の値が
ONLINE
になっている可能性があっても,障害回数が障害しきい値を上回ったために
TARGET
の値が
OFFLINE
に設定されている場合,リソースは,CAA によって
OFFLINE
であるかのように処理されます。
注意
テープまたはメディア・チェンジャ・リソースが,クラスタの稼働中にデバイスが取り外された後や物理的な障害が発生した後にクラスタに再接続される場合,デバイスの再接続はクラスタで自動的には検出されません。したがって,
drdmgr -a DRD_CHECK_PATH
device_name コマンドを実行する必要があります。
この節では,SysMan のツールを使用して CAA を管理する方法を説明します。SysMan の起動の一般的説明とクラスタでの使用方法については,第 2 章を参照してください。
8.8.1 SysMan Menu での CAA 管理
SysMan Menu から [Cluster Application Availability (CAA) Management] へのブランチは,図 8-1で示すように,[TruCluster Specific] という見出しの下にあります。[CAA Management] ダイアログ・ボックスを開くには,メニューの [Cluster Application Availability (CAA) Management] を選択し,[Select] ボタンをクリックするか,その文字列をダブルクリックします。
図 8-1: SysMan Menu の CAA へのブランチ
8.8.1.1 [CAA Management] ダイアログ・ボックス
[CAA Management] ダイアログ・ボックス (図 8-2) では,アプリケーションの起動,停止,再配置などを実行できます。アプリケーションを起動,再配置する場合,ダイアログ・ボックスにアプリケーションの配置についての問い合わせが出力されます。
また,[Setup] ダイアログ・ボックスを開いて,リソースの作成,変更,登録,登録取り消しなどを実行できます。
図 8-2: [CAA Management] ダイアログ・ボックス
[Start] ダイアログ・ボックス (図 8-3) では,アプリケーション・リソースを配置ポリシに従って配置するか,明示的に別のメンバ上に置くかを選択できます。
アプリケーションを明示的にメンバ上に配置できるのは,ホスト・メンバ・リストで許可されている場合のみです。配置ポリシが
restricted
で,ホスト・メンバ・リストに含まれないメンバ上にアプリケーションを配置しようとする場合,起動は失敗します。
図 8-3: [Start] ダイアログ・ボックス
プロファイルの追加,変更,登録,登録取り消しでは,図 8-4
に示す [Setup] ダイアログ・ボックスを使用します。このダイアログ・ボックスは,[CAA Management] ダイアログ・ボックスの [Setup...] ボタンから表示できます。SysMan Menu でリソースを設定する方法についての詳細は,オンライン・ヘルプを参照してください。
図 8-4: [Setup] ダイアログ・ボックス
8.8.2 SysMan Station での CAA 管理
SysMan Station を使用して CAA リソースを管理することができます。図 8-5 に SysMan Station の CAA_Applications_(active) ビューを示します。図 8-6 に SysMan Station の CAA_Applications_(all) ビューを示します。ウィンドウの上端にある [View] メニューを使用して,これらのビューのいずれかを選択します。クラスタ・アイコンまたはクラスタ・メンバ・アイコンを選択すると,CAA 固有の作業を含む [Tools] メニューの下のすべての SysMan Menu が使用可能になります。
アプリケーション・リソースのアイコンは,リソースの状態を示します。これら 2 つの図では,App1
と
App2
が現在オフラインで,cluster_lockd
がオンラインになっています。
図 8-5: SysMan Station の CAA_Applications_(active) ビュー
図 8-6: SysMan Station の CAA_Applications_(all) ビュー
8.8.2.1 SysMan Station でのアプリケーションの起動
CAA_Applications_(active) ビュー (図 8-5) または CAA_Applications_(all) ビュー (図 8-6) のいずれかでアプリケーションを起動するには,[Tools] メニューでマウスの右ボタンをクリックして,[CAA Management ==> Start Application] を選択します。
8.8.2.2 SysMan Station でのリソース設定
SysMan Station を使用してリソースを設定するには,クラスタ・アイコンかクラスタ・メンバ・アイコンのどちらかを選択します。マウスの右ボタンをクリックするか,[Tool] メニューをクリックして,[CAA Management ==> CAA Setup
] を選択します。図 8-7
を参照してください。その後の手順は SysMan Menu の手順と同じで,オンライン・ヘルプの「使い方」の項で説明しています。
図 8-7: SysMan Station の [CAA Setup] 画面
8.9 起動時およびシャットダウン時の CAA に関する考慮事項
CAA デーモンは,データベースから全リソースの情報を読み取る必要があります。そのため,多数のリソースが登録されている場合は,そのクラスタ・メンバはブートするのに時間がかかる場合があります。
CAA は,メンバのブート時に次のようなメッセージを表示する場合があります。
Cannot communicate with the CAA daemon.
このメッセージの前に次のようなメッセージが表示されるときもあります。
Error: could not start up CAA Applications Cannot communicate with the CAA daemon.
これらのメッセージは,TrueCluster Server ライセンスを登録していなかったことを示しています。メンバのブートが終了したら,次のコマンドを入力します。
# lmf list
TCS-UA ライセンスが動作していない場合は,『クラスタ・インストレーション・ガイド』に記述されている方法によって登録してから,次のように CAA デーモン (caad
) を起動します。
#/usr/sbin/caad
クラスタのシャットダウン時,CAA デーモンは各アプリケーション・リソースが
ONLINE
であるか
OFFLINE
であるかを記録します。クラスタの再起動時に,ONLINE
だったアプリケーションは再起動され,OFFLINE
だったアプリケーションは再起動されません。UNKNOWN
だったアプリケーションは中断状態とみなされます。クラスタの再起動によって解決されるような問題でアプリケーションが停止している場合は,caa_start
コマンドを使って,それらのアプリケーションを起動します。AUTO_START
が 1 に設定されているアプリケーションは,クラスタが再編成されたときに起動されます。
クラスタのメンバをシャットダウンする前にアプリケーションの配置を行う場合は,アプリケーション・リソースの状態を調べ,シャットダウンするメンバ上のあらゆるアプリケーションを別のメンバに再配置します。アプリケーションを再配置する方法は,8.3 節にリストされています。
8.10 CAA デーモンの管理
CAA デーモン (caad
) の管理は,通常,自動的に行われます。CAA デーモンは,クラスタのあらゆるメンバ上で,ブート時に起動され,シャットダウン時に停止されます。ただし,このデーモンに問題が発生した場合は,作業が必要になります。
コマンド
caa_stat
,caa_start
,caa_stop
,または
caa_relocate
を実行したときに,「Cannot communicate with the CAA daemon!」というメッセージが表示された場合,caad
デーモンはおそらく動作していません。CAA デーモンでエラーが発生した場合には,Essential Services Monitor デーモンが CAA デーモンの再起動を試みます。数秒たってから,CAA コマンドの実行を試みます。成功した場合には,デーモンが再起動され,CAA のすべての機能が正常に動作しています。デーモンが動作しているかどうかを手動で調べるには,8.10.1 項を参照してください。
8.10.1 ローカルの CAA デーモンの状態の確認
ローカルの CAA デーモンの状態を確認するには,次のコマンドを実行します。
# ps ax | grep -v grep | grep caad
caad
が動作している場合,たとえば次のような出力が表示されます。
545317 ?? S 0:00.38 caad
何も表示されない場合は,caad
が実行されていません。
クラスタの別のメンバにログインし,ps ax |grep -v grep | grep caad
コマンドを実行することによって,他の
caad
デーモンの状態も確認できます。
マシン上で
caad
デーモンが動作していない場合,そのマシン上で起動されたアプリケーション・リソースは CAA で管理されなくなります。caa_stop
を使ってアプリケーションを停止することはできません。8.10.2 項の説明に従って
caad
デーモンを再起動すると,そのマシン上のリソースは CAA サブシステムによって完全に管理されるようになります。
8.10.2 CAA デーモンの再起動
caad
デーモンがクラスタの 1 つのメンバ上で強制終了されても,そのメンバ上のすべてのアプリケーション・リソースは動作し続けますが,それらのリソースは CAA サブシステムを使って一時的に管理できなくなります。Essential Services Monitor デーモン
esmd
は自動的に
caad
を再起動し,管理機能が元に戻ります。Essential Services Monitor デーモンが caad デーモンを再起動できない場合には,syslog
に高い優先度のイベントをポストします。詳細は
esmd
(8)
/usr/sbin/caad
コマンドを手動で入力することによって,このデーモンの再起動を試みることができます。
caad
デーモンを再起動するために起動スクリプト
/sbin/init.d/clu_caa
を使用しないでください。このスクリプトは,クラスタ・メンバをブートするときに,caad
デーモンを起動するためにだけ使用します。
8.10.3 CAA デーモンのメッセージのモニタ
リソースの状態変化に関する情報を見るには,CAA デーモンによって EVM にポストされたイベントを表示します。EVM のメッセージについての詳細は,8.11 節を参照してください。
8.11 EVM による CAA のイベントの表示
CAA デーモンは,EVM (イベント・マネージャ) にイベントをポストします。これらのイベントは,CAA サブシステムで発生したエラーの解決に役立つ場合があります。
注意
いくつかの CAA 動作は,syslog を介して
/var/cluster/members/{member}/adm/syslog.dated/[date]/daemon.log
にログが取られます。daemon.log
と EVM の両方の情報を取得するのが問題を判別するのに有益です。EVM はクラスタ全体の情報の単一ソースであるという利点があり,daemon.log
情報は各メンバ固有です。daemon.log
のみに存在する情報がいくつかあります。
SysMan Station を使用するか,コマンド行から EVM のコマンドを使用することによって,EVM にポストされたイベントにアクセスできます。SysMan Station の使用方法についての詳細は,Tru64 UNIX 『システム管理ガイド』を参照してください。特定のタスクの実行方法についての詳細は,オンライン・ヘルプを参照してください。
CAA デーモンが生成する多くのイベントは,EVM の構成ファイル
/usr/share/evm/templates/clu/caa/caa.evt
に定義されています。これらのイベントにはすべて
sys.unix.clu.caa.*
という形式の名前が付きます。
CAA デーモンが生成する一部のイベントには,sys.unix.syslog.daemon
という名前が付きます。ただし,他のデーモンによってポストされるイベントにもこの名前が付きます。したがって,EVM によって表示されるのは CAA のイベントだけではありません。
EVM Event Management System
からの情報の取得についての詳細は,
EVM
(5)evmget
(1)evmshow
(1)8.11.1 CAA のイベントの表示
EVM にポストされた CAA のイベントを表示するには,次のコマンドを入力します。
# evmget -f "[name *.caa.*]" | evmshow CAA cluster_lockd was registered CAA cluster_lockd is transitioning from state ONLINE to state OFFLINE CAA resource sbtest action script /var/cluster/caa/script/foo.scr (start): success CAA Test2002_Scale6 was registered CAA Test2002_Scale6 was unregistered
EVM の詳細なイベント情報を取得するには,オプション -d を次のように指定します。
# evmget -f "[name *.caa.*]" | evmshow -d | more ============================ EVM Log event =========================== EVM event name: sys.unix.clu.caa.app.registered This event is posted by the Cluster Application Availability subsystem (CAA) when a new application has been registered. ====================================================================== Formatted Message: CAA a was registered Event Data Items: Event Name : sys.unix.clu.caa.app.registered Cluster Event : True Priority : 300 PID : 1109815 PPID : 1103504 Event Id : 4578 Member Id : 2 Timestamp : 18-Apr-2001 16:56:17 Cluster IP address: 16.69.225.123 Host Name : provolone.zk4.dec.com Cluster Name : deli User Name : root Format : CAA $application was registered Reference : cat:evmexp_caa.cat Variable Items: application (STRING) = "a" ======================================================================
テンプレート・スクリプト
/var/cluster/caa/template/template.scr
は,CAA がアプリケーションを起動,停止,チェックするときにイベントがポストされるスクリプトを生成するように変更されました。caa_profile
または SysMan で新たに作成された処理スクリプトはどれでも,EVM へイベントをポストするようになります。これらのイベントのみを表示するには,次のコマンドを入力します。
# evmget -f "[name sys.unix.clu.caa.action_script]" | evmshow -t "@timestamp @@"
CAA のイベントは SysMan Station を使っても表示できます。そのためには,SysMan Station Monitor Window の [Status Light or Label Box for Applications] をクリックします。
他のデーモンと同様に
caad
デーモンによってログに記録されたその他のイベントを表示するには,次のコマンドを入力します。
# evmget -f "[name sys.unix.syslog.daemon]" | \ evmshow -t "@timestamp @@"
CAA のイベントにタイム・スタンプを付けてコンソール上で監視するには,次のコマンドを入力します。
# evmwatch -f "[name *.caa.*]" | evmshow "@timestamp @@"
CAA のイベントが EVM にポストされると,このコマンドの実行元の端末上にそれらのイベントが表示されます。たとえば,次のようなメッセージが表示されます。
CAA cluster_lockd was registered CAA cluster_lockd is transitioning from state ONLINE to state OFFLINE CAA Test2002_Scale6 was registered CAA Test2002_Scale6 was unregistered CAA xclock is transitioning from state ONLINE to state OFFLINE CAA xclock had an error, and is no longer running CAA cluster_lockd is transitioning from state ONLINE to state OFFLINE CAA cluster_lockd started on member polishham
syslog
機能を用いて,CAA デーモンとその他のデーモンがログをとったその他のイベントを表示するには,次のコマンドを入力します。
# evmwatch -f "[name sys.unix.syslog.daemon]" | evmshow | grep CAA
この節で示すエラー・メッセージは,次のコマンドを入力して,CAA デーモンからのイベントを示すときに表示される可能性があります。
# evmget -f "[name sys.unix.syslog.daemon]" | evmshow | grep CAA
時間切れの処理スクリプト
CAAD[564686]: RTD #0: Action Script \ /var/cluster/caa/script/[script_name].scr(start) timed out! (timeout=60)
最初に,/var/cluster/caa/script/[script_name].scr start
を実行して,処理スクリプトでアプリケーションが正しく起動されるかどうかを確認してください。処理スクリプトが正しく動作してエラーなしに正常に戻っても,SCRIPT_TIMEOUT
の値より時間がかかる場合は,SCRIPT_TIMEOUT
の値を増やしてください。スクリプトで実行されたアプリケーションの終了に時間がかかる場合は,スクリプト内のアプリケーションを起動する行にアンパサンド (&
) を追加して,スクリプト内のタスクをバックグラウンドで実行してください。ただし,この処理はコマンドが常に 0 の状態を返し,CAA はささいな理由 (たとえば,コマンド・パスのスペルの誤り) によるコマンドの失敗を検出できません。
処理スクリプトの停止エントリ・ポイントでのリターン値 0 以外
CAAD[524894]: `foo` on member `provolone` has experienced an unrecoverable failure.
このメッセージは,停止エントリ・ポイントが 0 以外の値を返すときに出力されます。リソースは
UNKNOWN
状態になります。アプリケーションを停止するためには,0 を返すように停止処理スクリプトを修正して
caa_stop
または
caa_stop
-f
を実行する必要があります。いずれにしても,停止処理スクリプトが 0 を返すように修正してから,アプリケーション・リソースを再起動してください。
ネットワーク障害
CAAD[524764]: `tu0` has gone offline on member `skiing`
ネットワーク・リソース
tu0
のこのようなメッセージは,ネットワークが停止したことを示します。ネットワーク・カードが正しく接続されているかどうかを確認してください。必要であれば,カードを交換してください。
CAA デーモンの起動を妨げるロック
CAAD[526369]: CAAD exiting; Another caad may be running, could not obtain \ lock file /var/cluster/caa/locks/.lock-provolone.dec.com
これと同様のメッセージは,2 つ目の
caad
を起動しようとしたときに表示されます。8.10.1 項で説明したように
caad
が実行されているかどうかを確認してください。このデーモンが実行されていない場合は,メッセージでリストされているロック・ファイルを削除して,8.10.2 項で説明したように
caad
を再起動してください。
8.13 コマンド行メッセージのトラブルシューティング
以下のようなメッセージは,ユーザが登録しようとしたリソースのプロファイルを CAA で検出できないことを示しています。
Cannot access the resource profile file_name
たとえば,clock
のプロファイルがない場合は,clock
を登録しようとしても失敗して,次のようになります。
# caa_register clock Cannot access the resource profile '/var/cluster/caa/profile/clock.cap'.
リソース・プロファイルの場所が正しくないか,プロファイルがありません。プロファイルが,メッセージ中に示された場所に存在するかどうかを確認してください。