WebSphere Application Server for z/OS, Version 6.1   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化

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

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

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

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

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 つのサーバーは、ハートビートを交換します。 システム過負荷が起こっている間、ハートビート操作はタイムアウトとなり、サーバー障害が発生しているように見え ます。 ネットワーク分割後、各サーバーは別個のネットワーク内に置かれ、サーバー間でハートビートをやりとりでき なくなり、 サーバー障害が発生しているように見えます。




関連概念
トランザクション高可用性のデプロイメントに関する考慮事項
関連タスク
トランザクション・プロパティーの、ピア・リカバリー用の構成
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 9:12:22 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/cjta_hacons_log.html