例外条件からのメッセージング・エンジンのリカバリー

サービス統合では、メッセージング・エンジンの再始動を必要としない例外条件、メッセージング・エンジンの自動再始動を必要とする例外条件、明示的なヘルス・モニターによって検出され、HAManager によって処理される例外条件、およびユーザー介入が必要な例外条件が発生する可能性があります。

稼働状態でのメッセージング・エンジンのリカバリー

メッセージング・エンジンは、メッセージング・エンジンの再始動またはフェイルオーバーを必要とせずに特定の例外条件を処理できます。例外条件は自動的に修正され、エラーの内容を説明してユーザーがとるべき処置を提案する項目がシステム・エラー・ログに追加されます。 メッセージング・エンジンは稼働し続け、処理対象のメッセージに指定 されているサービス品質を保証します。

メッセージング・エンジンの自動再始動によるリカバリー (ローカル例外)

メッセージング・エンジンは、現行サーバー上または代替サーバー上 でメッセージング・エンジンを自動再始動することで、ローカル例外からリカバリーできます。例えば 、メッセージング・エンジンが そのデータ・ストアに接続できない場合、メッセージング・エンジンが稼働しているサーバー でデータ・ストアへの接続を作成できないが、同じクラスター内の別のサーバーでは作成できることが考えられます。高可用性の構成、つまりフェイルオーバーが使用可能になっている構成の場合、HAManager は現行サーバーのメッセージング・エンジンを停止して使用不可にし、新しいサーバーにメッセージング・エンジンをフェイルオーバーします。 使用不可になったメッセージング・エンジンは、30 秒後に自動的に使用可能になります。

明示的なヘルス・モニターによって検出された例外からのリカバリー

メッセージング・エンジンでは、スレッド・スピン (スレッドがループでトラップ状態になり、有効な 作業を実行できなくなった状態) やデッドロック (2 つのスレッドが互いをブロックし合っている状態) などの例外は検出できませんが、明示的なヘルス・モニターでは可能です。HAManager にってそのようなモニター作業を行うことができ 、メッセージング・エンジンの正常性を 定期的にテストすることができます。データ・ストアを使用しているメッセージング・エンジンが正常に実行できないことを HAManager が検出すると、HAManager はそのメッセージング・エンジンを停止して使用不可にします。メッセージング・エンジンがファイル・ストアを使用している場合は、HAManager は、メッセージング・エンジンをホストしているサーバーをシャットダウンします。サーバーがクラスター内にある場合 、メッセージング・エンジンのポリシーによってフェイルオーバーが使用可能に設定されていれば、メッセージング・エンジンは HAManager によって代替サーバー上で再始動されます。メッセージング・エンジンがデータ・ストアを使用している場合は、使用不可になったメッセージング・エンジンは、30 秒後に自動的に使用可能になります。

ユーザー介入を必要とするリカバリー (グローバル例外)

メッセージング・エンジンは、メッセージング・エンジンを再始動またはフェイルオーバーすることで、グローバル例外からリカバリーすることはできません。例えば 、メッセージング・エンジンのデータ・ ストアが破損した場合、メッセージング・エンジンを 他のサーバー上で稼働しても問題は解決できません。同じ問題が発生するためです。この状況でメッセージング・エンジンが フェイルオーバーされた場合、どのサーバー上でも稼働できないため 、メッセージング・エンジンは 次々にフェイルオーバーされます。サーバーがメッセージング・エンジンの実行を試みたときにシャットダウンされると、クラスターに不要な混乱が発生します。そのような状況を回避するために、グローバル例外が起きた場合 、メッセージング・エンジンはエラーを ログに記録してメッセージ処理を停止しますが、フェイルオーバーされません。メッセージング・エンジンの再始動は、ユーザー がグローバル例外条件を修正してサーバーを再始動するまで実行できません。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjt0004_
ファイル名:cjt0004_.html