自動と手動のトランザクション・ピア・リカバリーのいずれかを選択する方法

ファイル・システムのタイプは、 使用するトランザクション・ピア・リカバリーの種類を決定する際の主な要素です。 ファイル・システムが異なれば振る舞いも異なり、 特にファイル・ロックの振る舞いは、自動と手動のピア・リカバリーのいずれかを選択する場合に重要です。

WebSphere® Application Server の高可用性 (HA) サポートでは、ハートビート・メカニズムを使用して、サーバーがまだ稼働しているかどうかを判別します。 サーバーは、ハートビート要求に対する応答が停止したときに、障害が発生していると判断されます。 システム過負荷とネットワーク分割 (このトピックで説明されています) などの一部のシナリオでは、 サーバーが依然として稼働中であっても、サーバーのハートビートへの応答が停止することがあります。 WebSphere Application Server は、ファイル・ロックのテクノロジーを使用して、 こうしたイベントによってトランザクション・リカバリー・ログへの並行アクセスが発生しないようにします。 これは、複数のサーバーがリカバリー・ログにアクセスすることで、データ保全性が失われる可能性があるためです。

しかし、すべてのファイル・システムに、必要なファイル・ロックのセマンティクスが提供されているわけではあ りません。具体的には、サーバー障害時にファイル・ロックが解除されることについてです。 例えば、Network File System バージョン 4 (NFSv4) ではこの解除の振る舞いが行われますが、 Network File System バージョン 3 (NFSv3) では行われません。

WebSphere Application Server のファイル・システム・ロッキング・プロトコル・テストを実行することによって、共有ファイル・システムが、トランザクション・ログのフェイルオーバーをサポートできるかどうかをテストできます。 テストを実行するには、http://www-01.ibm.com/support/docview.wss?uid=swg24010222を参照してください。

NFSv4 は、ホストの障害時に、ホストに代わって保留されているロックを解除します。 ピア・リカバリーは自動的に行われるので、障害が発生しているハードウェアの再始動は不要です。 したがって、このバージョンの NFS は、自動ピア・リカバリーでの使用により適しています。

NFSv3 は、障害のあるホストが再始動するまで、ホストに代わってファイル・ロックを保留します。 このコンテキストでは、ホストとは、ロックを要求したアプリケーション・サーバーを実行する物理マシンであり、 アプリケーション・サーバーの再始動ではなく、 ホストの再始動により、最終的にロックの解除が引き起こされます。

NFSv3 でのファイル・ロックを説明するために、クラスター・メンバーの障害時の振る舞いについて考えてみます。
  1. サーバー H は、ホスト H 上で稼働し、 独自のリカバリー・ログ・ファイルの排他的ファイル・ロックを保留しています。
  2. サーバー P は、ホスト P 上で稼働し、 独自のリカバリー・ログ・ファイルの排他的ファイル・ロックを保留しています。
  3. ホスト H に障害が起こり、サーバー H にそれが波及します。 ファイル・サーバー上の NFS ロック・マネージャーは、 サーバー H に代わって、サーバー H に付与されたロックを保留します。
  4. WebSphere Application Server は、ピア・リカバリー・イベントを、サーバー H の代わりにサーバー P で起動します。
  5. サーバー P は、このピア・リカバリー・ログの排他的ファイル・ロックを得ようとしますが、 サーバー H の代わりに保留されているため、それができません。 ピア・リカバリー処理はブロックされます。
  6. 不特定の時刻に、ホスト H が再始動します。 ホスト H の代わりに保留されているロックは、解除されます。
  7. サーバー P でのピア・リカバリー処理は、ブロックされておらず、ピア・リカバリーの実行に必要な排他的ファイル・ロックが付与されています。
  8. ピア・リカバリーは、サーバー H に代わってサーバー P で行われます。
  9. サーバー H が再始動します。
  10. サーバー P でピア・リカバリーがまだ進行中の場合、リカバリーは停止されます。
  11. サーバー P は、リカバリー・ログの排他ロックを解除し、リカバリー・ログの所有権をサーバー H に戻します。
  12. サーバー H は、排他ロックを取得し、これで標準のトランザクション・ロギングを実行できるようになります。

この振る舞いのため、NFSv3 では自動ピア・リカバリーを使用するために、ファイル・ロックを使用不可にする必要があります。 ファイル・ロックを使用不可にすると、リカバリー・ログへの並行アクセスが行われる可能性があります。 したがって、まず、システムでシステムの過負荷とネットワーク分割が発生しないようにする 必要があります。 あるいは、手動のピア・リカバリーを構成することもできます。この場合、障害が発生しているサーバーに限定してピア・リカバリー処理を手動で起動し、並行アクセスを回避します。

システム過負荷
システム過負荷は、マシンの負荷が極めて大きくなり、 それによって応答時間が極端に悪化し、要求がタイムアウトし始めたときに発生します。 そのような過負荷には、次のようないくつかの潜在的な原因があります。
  • サーバーの能力が低下し、ワークロードを処理できません。
  • サーバーが一時的に大量の要求を受け取りました。
  • 使用可能な物理メモリーが不足しています。 結果として、オペレーティング・システムのページングが過度にビジーになり、 アプリケーション・サーバーに必要な CPU 時間がなくなります。
ネットワーク分割
ネットワーク分割は、ネットワーク内の通信障害によって、 独立した 2 つの小さなネットワークに分割され、互いに接続できなくなった場合に起こります。
図 1. システム過負荷とネットワーク分割という明らかなサーバー障害後のハートビートと比較した、正常に稼働しているシステムのハートビートシステム過負荷とネットワーク分割という明らかなサーバー障害後のハートビートと比較した、正常に稼働しているシステムのハートビート

正常に稼働中、ネットワーク上の 2 つのサーバーは、ハートビートを交換します。 システム過負荷が起こっている間、ハートビート操作はタイムアウトとなり、サーバー障害が発生しているように見え ます。 ネットワーク分割を行うと、各サーバーは別個のネットワーク内に置かれ、 ハートビートをやりとりできなくなるため、 サーバー障害が発生しているように見えます。


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



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