この章では、ACSLS HA のインストールのテスト、問題の診断、およびシステムで発生する可能性がある問題のトラブルシューティングに使用できるさまざまなリソースについて説明します。
起動イベントまたはスイッチオーバーイベント中に発生するアクティビティーは、2 つのノード間で幅広く分散されます。したがって、テスト中に全体的な操作を監視するために選ばれる視点によって、イベントの発生時に展開イベントを表示するための能力が大きく左右される可能性があります。包括的なビューを設定するための手順については、ha_console.sh ユーティリティーに記載されています。
テスト中に HA 全体の動作を監視するために推奨されるダッシュボード構成には、ノードごとに 4 つのウィンドウから成る 8 つのシェルウィンドウが含まれます。
root 用のコマンドシェルは、必要に応じてさまざまなコマンドを発行するために各ノードに予約します。
システムの /var/adm/messages ファイルの末尾を表示するためのウィンドウを各ノードに設定します。
# tail -f /var/adm/messages
Solaris Cluster はすべての情報メッセージをこのログファイルに出力します。
acsls-rs リソースの start_stop log の末尾を表示するための別のウィンドウを各ノードに設定します。
# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt
acsls_agt.sh 起動スクリプトによって公開されたすべてのメッセージはここに表示されます。
acsls-rs プローブログの末尾を表示するために、各ノードの 3 番目のウィンドウを設定する必要があります。
# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/probe_log.txt
アプリケーションが起動すると、Solaris Cluster は ACSLS リソースを 1 分ごとにプローブします。数値コードが各プローブからクラスタに戻され、結果は probe_log.txt ファイルに出力されます。各プローブによって、標準的な 5 つの戻り値のいずれかがこのログに公開されて表示されます。
0 - The probe found that ACSLS is healthy and functioning normally. 1 - The probe may not have completed due to a functional error. 2 - The probe reports that ACSLS is in a transitional state. 3 - The ACSLS application has been intentionally placed offline. 201 - A condition was detected that requires fail-over action.
コード 201 に応答する場合のみ、Solaris Cluster はフェイルオーバーアクションを開始します。そのようなアクションを実行させる条件は、ACSLS クラスタの操作の章に一覧表示されています。Cluster プローブからのほかのすべての戻りコードは情報提供と見なされ、クラスタの応答アクションは実行されません。
テスト用のサンプルプローブは、コマンド行からいつでも実行できます。コマンド acsAgt probe を次のように使用します。
#/opt/ACSLSHA/util/acsAgt probe
前述のすべてのログには、Solaris Cluster から認識されているシステムビューが反映されます。$ACS_HOME/log/ ディレクトリ内の 2 つの追加のログは、ACSLS アプリケーションレベルからのビューを提供します。acsss_event.log には、アプリケーションが起動された時点から ACSLS によって検出されたすべての重要なイベントが報告されます。また、SMF によって検出された ACSLS 起動のすべての問題は acsls_start.log に記録されます。
Solaris Cluster ユーティリティーは、/usr/cluster/bin ディレクトリにあります。
ACSLS リソースグループの現在の状態を表示する場合: clrg list -v
2 つのクラスタノードの現在のステータスを表示する場合: clrg status
リソースグループのステータスを表示する場合: clrs status
ノード、定足数デバイス、およびクラスタリソースでの詳細ステータスを取得する場合: cluster status
クラスタ構成内の詳細なコンポーネントリストの場合: cluster show
リソースグループでの各 Ethernet ノードのステータスを表示する場合: clnode status -m
各ノード上のさまざまな acsls-rg リソースのステータスを表示する場合: scstat -g
ハートビートネットワークリンクの健全性を表示する場合: 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 IPMP ロジックによって自動的に再開されます。共有ディスクアレイへの中断されたデータ接続は、冗長データパスでは Solaris によって自動的に再開されます。Solaris Service Management Facility の制御下にあるサービスは、SMF によって自動的に再開されます。
実際のフェイルオーバーイベントに関するテストでは、$ACS_HOME/acslsha/pingpong_interval ファイルで定義されたプロパティー設定を確認してください。フェイルオーバーイベントを引き起こす可能性がある状態にもかかわらず、指定された pingpong_interval 内に前のフェイルオーバーイベントが発生した場合、Solaris Cluster はフェイルオーバーアクションを開始しません。
応答間隔を表示または動的に変更するには、/opt/ACSLSHA/util ディレクトリに移動して、acsAgt pingpong を実行します。
# ./acsAgt pingpong Pingpong_interval current value: 1200 seconds. desired value: [1200] 300 Pingpong_interval : 300 seconds.
次のいずれかまたはすべての手法を使用して、HA インストールの回復力を評価します。
ACSLS が操作可能な間に、アクティブノード上の各 IPMP グループから 1 つの Ethernet 接続を切断します。# scstat -i を使用してステータスをモニターします。
/var/adm/messages で反応を調べます。ACSLS の操作は、この手順によって中断されません。
Cluster Failover_mode が HARD に設定されていることを確認します。ACSLS が操作可能な間に、アクティブサーバーから共有ディスクリソースへの 1 つのファイバまたは SAS 接続を切断します。
/var/adm/messages で反応を調べます。ACSLS の操作は、この手順によって中断されません。
このテストをそれぞれの冗長 I/O 接続で繰り返します。
acsss_daemon を停止することによって ACSLS を突然終了します。pkill acsss_daemon を使用します。
svcs -l acsls を実行して、サービスログを見つけます。
acsss_daemon が停止したときのこのログの末尾を表示します。サービスが SMF によって自動的に再起動されることがわかります。acsls shutdown を使用して acsls を停止した場合、類似したアクションが確認されます。
SMF を使用して、acsls サービスを無効にします。
これは svcadm disable acsls を使用して root として行うか、acsss disable を使用してユーザー acsss として行うことができます。
SMF がこのシャットダウンイベントを管理するため、acsls サービスの再起動は試行されません。これは必要な動作です。acsls サービスは SMF の下で再起動する必要があります。root として、コマンド svcadm enable acsls を使用します。または、ユーザー acsss として、acsss-enable コマンドを使用します。
acsdb サービスを停止します。
ユーザー acsdb として、.acsls_env ファイルを探します。
$ su acsdb $ . /var/tmp/acsls/.acsls_env
ここで、次のコマンドを使用して 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 システムをモニターし、システムのフェイルオーバーイベントを必要とする致命的な状態を探します。これには、ユーザーが開始したフェイルオーバー (acsAgt nodeSwitch または clrg switch -n)、アクティブノードのシステムのリブート、システムのハング、致命的なメモリー障害、またはアクティブノードでの回復不能な I/O 通信があります。また、Solaris Cluster は、特定のアプリケーション用に設計された HA エージェントをモニターします。ACSLS HA エージェントは、次の状態でシステムのフェイルオーバーイベントをリクエストします。
アクティブノードと論理ホストの間の TCP/IP 通信が失われている。
$ACS_HOME ファイルシステムがマウントされていない。
データベースバックアップファイルシステム ($ACS_HOME/.../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) と役に立つことがあります。ACSLS クラスタ操作のモニタリングを参照してください。
クラスタのフェイルオーバーイベントを開始する単純なコマンドは、acsAgt nodeSwitch です。
# acsAgt nodeSwitch
または、同等のクラスタコマンドを使用します。
# clrg switch -n <node name> acsls_rg
このアクションによって ACSLS アプリケーションが停止し、アクティブサーバーからスタンバイシステムに処理が切り替えられます。オプション -M -e は、新しいノードで SMF サービスを有効にするようクラスタサーバーに指示します。ACSLS クラスタ操作のモニタリングを参照してください。
アクティブノードでのシステムのリブートによって、代替ノードへの HA の切り替えが即時に開始されます。
この操作は、ACSLS が新しいアクティブノードで実行されて終了します。スタンバイシステムはその新しい役割がアクティブノードであると想定するため、スタンバイノードで、/var/adm/messages ファイルの末尾を調べます。コマンド # clrg status を定期的に実行することもできます。
init 5 を使用して、アクティブサーバーノードの電源を切って、システムのフェイルオーバーを確認します。
アクティブサーバーノードと共有ディスクストレージ配列との間の両方のデータ回線を抜いて、スタンバイノードへのシステムの切り替えを確認します。
特定のライブラリがポリシーファイル ha_acs_list.txt に一覧表示されていると想定して、アクティブサーバーノードとそのライブラリとの間の両方の Ethernet 通信回線を切断します。
スタンバイノードへのシステムのフェイルオーバーを確認します。