11 クラスタのロギング、診断、およびテスト

この章では、ACSLS-HA のインストールのテスト、問題の診断、およびシステムで発生する可能性がある問題のトラブルシューティングに使用できるさまざまなリソースについて説明します。

Solaris Cluster のロギング

フェイルオーバーイベント中の Solaris Cluster メッセージは、/var/adm/messages ファイルに書き込まれます。このファイルには、Cluster 機能に関するメッセージ、および ACSLS のエラーメッセージと情報メッセージがあります。アクティブノードのみがクラスタメッセージを /var/adm/messages ファイルに書き込みます。

Solaris Cluster は、60 秒ごとに 1 回プローブを使用して ACSLS のヘルスをモニターします。このプローブアクティビティーのログはここで確認できます。

/var/cluster/logs/DS/acsls-rg/acsls-rs/probe_log.txt

同じディレクトリには、フェイルオーバーシーケンスが発生した場合にすべての開始イベントと停止イベントが記録されるファイルがあります。

/var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt

ACSLS イベントログ

ACSLS イベントログは $ACS_HOME/log/acsss_event.log です。このログには、ACSLS ソフトウェアの観点からの開始イベントと停止イベントに関するメッセージが含まれています。ログは、ライブラリリソースの動作状態に対する変更を報告し、ACSLS ソフトウェアによって検出されたすべてのエラーを記録します。acsss_event.log は、acsss_config option-2 で定義されたパラメータから自動的に管理およびアーカイブされます。

Cluster のモニタリングユーティリティー

Solaris Cluster ユーティリティーは、/usr/cluster/bin ディレクトリにあります。

ACSLS リソースグループの現在の状態を表示する場合: clrg list -v
2 つのクラスタノードの現在のステータスを表示する場合: clrg status
リソースグループのステータスを表示する場合: clrs status
ノード、定足数デバイス、およびクラスタリソースでの詳細ステータスを取得する場合: cluster status
クラスタ構成内の詳細なコンポーネントリストの場合: cluster show
リソースグループでの各 Ethernet ノードのステータスを表示する場合: clnode status -m
リソースグループのステータスを表示する場合: scstat -g
デバイスグループのステータスを表示する場合: scstat -D
ハートビートネットワークリンクのヘルスを表示する場合: scstat -D または clintr status
IPMP ステータスを表示する場合: scstat -i
ノードステータスを表示する場合: scstat -n
定足数構成とステータスを表示する場合: scstat -q または clq status
タイムアウト値を含む詳細なクラスタリソースを表示する場合: clresource show -v

回復およびフェイルオーバーのテスト

このセクションでは、回復およびフェイルオーバーのテストの状態、モニタリング、およびテストについて説明します。

回復状態

システムのフェイルオーバーイベントを必要とせずに回復できる、致命的なシステム状態は多数存在します。たとえば、IPMP では、各グループ内の 1 つの Ethernet 接続が何らかの理由で失敗することがありますが、通信は代替のパスを通じて途切れずに再開するはずです。

共有ディスク配列は、各サーバー上の 2 つの別個のポートを使用してサーバーに接続するべきです。1 つのパスが中断された場合、ディスク I/O 操作は、代替のパスを通じて中断することなく再開するはずです。

ACSLS は、Solaris Service Management Facility (SMF) によってモニターされるいくつかのソフトウェア「サービス」で構成されます。ユーザー acsss は、コマンド acsss status を使用してそれぞれの acsss サービスを一覧表示できます。これらのサービスには、PostgreSQL データベース、WebLogic Web アプリケーションサーバー、および ACSLS アプリケーションソフトウェアがあります。特定のサービスが Solaris システムで失敗した場合、システムのフェイルオーバーを必要とせずに、SMF はそのサービスを自動的にリブートするはずです。

acsls サービス自体は、親の acsss_daemon によってモニターされる多数の子プロセスで構成されます。ACSLS サブプロセスを一覧表示するには、(ユーザー acsss として) コマンド psacs を使用します。何らかの理由でいずれかの子プロセスが異常終了した場合、親は即時にその子をリブートして、通常の操作を復元するはずです。

回復のモニタリング

システムリソース (ディスク I/O や Ethernet 接続など) の回復を確認するために最適な場所は、システムログ /var/adm/messages です。

SMF は、モニターするソフトウェアサービスごとに特定のログを保持します。このログには、起動、再起動、およびシャットダウンイベントが表示されます。サービスログへのフルパスを取得するには、コマンド svcs -l service-name を実行します。ACSLS サービスは、acsss コマンド $ acsss status を使用して一覧表示できます。サブプロセスは、コマンド $ acsss p-status を使用して一覧表示できます。

ACSLS サブプロセスの回復を表示するには、acsss_event.log ($ACS_HOME/ACSSS/log/acsss_event.log) をモニターできます。このログには、ACSLS サブプロセスに関するすべての回復イベントが表示されます。

回復テスト

冗長なネットワーク接続は、Solaris マルチパス IP ロジック (IPMP) によって自動的にリブートされるはずです。共有ディスク配列への中断されたデータ接続は、冗長データパスでは Solaris によって自動的にリブートされるはずです。Solaris Service Management Facility の制御下にあるサービスは、SMF によって自動的にリブートされるはずです。

実際のフェイルオーバーイベントに関するテストでは、$ACS_HOME/acslsha/pingpong_interval ファイルで定義されたプロパティー設定を確認してください。フェイルオーバーイベントを引き起こす可能性がある状態にもかかわらず、指定された pingpong_interval 内に前のフェイルオーバーイベントが発生した場合、Solaris Cluster はフェイルオーバーアクションを開始しません。"フェイルオーバーの Pingpong_interval の設定."を参照してください

現在の Pingpong_interval 設定を確認するには、クラスタコマンドを使用します。

clrg show -p Pingpong_interval

この動作の推奨される検証方法には、次のものが含まれることがあります。

ACSLS が操作可能な間に、アクティブノード上の IPMP グループから 1 つの Ethernet 接続を切断します。# scstat -i を使用してステータスをモニターします。

/var/adm/messages で反応を調べます。ACSLS の操作は、この手順によって中断されないはずです。
ACSLS が操作可能な間に、アクティブサーバーから共有ディスクリソースへの 1 つのファイバまたは SAS 接続を切断します。

/var/adm/messages で反応を調べます。ACSLS の操作は、この手順によって中断されないはずです。

このテストをそれぞれの冗長 I/O 接続で繰り返します。
acsss_daemon を停止して、ACSLS を突然停止します。

svcs -l acsls を実行して、サービスログを見つけます。

acsss_daemon の停止時に、このログの末尾を確認します。サービスが SMF によって自動的にリブートされることがわかるはずです。acsls shutdown を使用して acsls を停止した場合、類似したアクションが確認されるはずです。
SMF を使用して、acsls サービスを無効にします。

これは、svcadm disable acsls を使用して root として行うか、acsss disable を使用してユーザー acsss として行うことができます。

SMF がこのシャットダウンイベントを管理するため、acsls サービスのリブートは試行されません。これは必要な動作です。$ acsss enable または # svcadm enable acsls を使用して、SMF で acsls サービスをリブートする必要があります。
acsdb サービスを停止します。

ユーザー acsdb として、次のコマンドを使用して PostgreSQL データベースを突然無効にします。
```
pg_ctl stop \
     -D $installDir/acsdb/ACSDB1.0/data \
     -m immediate
```
このアクションによってデータベースが停止し、acsls プロセスも停止します。svcs -l acsdb を実行して、acsdb サービスログを見つけます。

データベースの停止時に、acsdb サービスログと acsls サービスログの両方の末尾を確認します。acsdb サービスが停止すると、acsls サービスも停止することがわかるはずです。両方のサービスが、SMF によって自動的にリブートされるはずです。
ACSLS が操作可能な間に、ユーザー acsss として psacs を実行して、acsss_daemon の下で実行されているサブプロセスのリストを取得します。

これらのサブプロセスの 1 つを停止します。acsss_event.log を調べて、サブプロセスがリブートされて回復手順が起動されることを確認します。

フェイルオーバー状態

Solaris Cluster ソフトウェアは Solaris システムをモニターし、システムのフェイルオーバーイベントを必要とする致命的な状態を探します。これには、ユーザーが開始したフェイルオーバー (clrg switch)、アクティブノードのシステムのリブート、システムのハング、致命的なメモリー障害、またはアクティブノードでの復元不能な I/O 通信があります。また、Solaris Cluster は、特定のアプリケーション用に設計された HA エージェントをモニターします。ACSLS HA エージェントは、次の状態でシステムのフェイルオーバーイベントを要求します。

アクティブノードと論理ホストの間の TCP/IP 通信が失われます。
$ACS_HOME ファイルシステムがマウントされていません。
/export/backup ファイルシステムがマウントされていません。
ファイル $ACS_HOME/acslsha/ha_acs_list.txt に一覧表示されていて、必要な状態はオンラインであり、通常であれば switch lmu は不可能であるか失敗する、ACS への通信が失われます。

フェイルオーバーのモニタリング

コマンド # clrg status を使用して、ときどきそれぞれのノードのフェイルオーバーステータスをモニターできます。

または、start_stop_log の末尾を調べて、フェイルオーバーアクティビティーをモニターできます。

# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt

診断フェイルオーバー操作の実行時に、両方のノードで /var/adm/messages ファイルを表示する (tail -f) と役に立つことがあります。

フェイルオーバーのテスト

Cluster フェイルオーバーをテストするために指示されている方法では、clrg switch コマンドを使用します。
```
# clrg switch -M -e -n <standby node name> acsls-rg
```
このアクションによって ACSLS アプリケーションが停止し、アクティブサーバーからスタンバイシステムに処理が切り替えられます。オプション -M -e は、新しいノードで SMF サービスを有効にするようクラスタサーバーに指示します。/var/adm/messages ファイルの末尾を確認することで、各ノードでこの一連のイベントを調べます。start-stop ログの末尾を表示します。
```
# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt
```
コマンド # clrg status を定期的に実行します。
アクティブノードでのシステムのリブートによって、代替ノードへの HA の切り替えが即時に開始されるはずです。

この操作は、ACSLS が新しいアクティブノードで実行されて終了するはずです。スタンバイシステムはその新しい役割がアクティブノードであると想定するため、スタンバイノードで、/var/adm/messages ファイルの末尾を調べます。コマンド # clrg status を定期的に実行することもできます。
init 5 を使用して、アクティブサーバーノードの電源を切って、システムのフェイルオーバーを確認します。
アクティブサーバーノードと共有ディスクストレージ配列との間の両方のデータ回線を抜いて、スタンバイノードへのシステムの切り替えを確認します。
特定のライブラリがポリシーファイル ha_acs_list.txt に一覧表示されていると想定して、アクティブサーバーノードとそのライブラリとの間の両方の Ethernet 通信回線を切断します。

スタンバイノードへのシステムのフェイルオーバーを確認します。

追加のテスト

ミラー化されたブートドライブがホットプラグ可能である場合、ブートドライブの 1 つを無効にして、システムが完全に操作可能なままであることを確認できます。1 つのブートドライブを無効にして、システムをリブートし、代替のブートドライブからノードが起動することを確認します。2 つの各ノード上のブートドライブごとにこのアクションを繰り返します。

アクティブノードから 1 つの電源を外しても、システムは代替の電源で完全に操作可能なままになるはずです。