トランザクションの高可用性

トランザクション・サービスの高可用性によって、クラスターの任意のサーバーは、同じクラスターの他のサーバーのトランザクション作業をリカバリーできます。この機能は WebSphere® Application Server の高可用性 (HA) 戦略全体の一部を形成します。

[z/OS]この機能は、ピアの再始動およびリカバリーのサポートに追加されたものです。これによりシスプレックス内のピア・システムで再始動を行うことができるようになります。

トランザクションのリカバリーを提供する重要な部分として、トランザクション・サービスはアクティブなトランザクション作業に関する情報をトランザクション・リカバリー・ログ に記録します。トランザクション・リカバリー・ログは、情報をパーシスタント形式で保管します。すなわち、サーバー障害時に処理中のトランザクション作業はすべて、サーバーが再始動すると解決されます。 このアクティビティーはトランザクション・リカバリー処理 として知られています。未解決のトランザクションの完了に加えて、この処理でも、関連するリソース・マネージャーに保留されているロックを解除することができます。

ピア・リカバリー処理

アプリケーション・サーバーの再始動時に実行される標準のリカバリー処理は、記録されたトランザクション情報をサーバーが取り出して処理し、トランザクション作業をリカバリーし、未確定のトランザクションを完了するためのものです。トランザクション作業が完了するのは (したがって、トランザクションが保持していたデータベース・ロックが解放されるのは)、サーバーが正常に再始動し、そのトランザクション・ログが処理された後です。 サーバーがリカバリーするのが遅かったり、または手操作による介入が必要な場合、 トランザクション作業は完了できず、関連データベースへのアクセスは中断します。

トランザクション作業および関連付けられているデータベースに対するこのような中断を最小限にするために、WebSphere Application Server は、トランザクション・ピア・リカバリー という高可用性戦略を提供しています。

ピア・リカバリーはサーバー・クラスター内で提供されます。ピア・サーバー (他のクラスター・メンバー) は、ピアがトランザクションのワークロードの管理を続けている間、障害を起こしたサーバーのリカバリー・ログを処理することができます。障害を起こしたサーバーが再始動するのを待ったり、障害を起こしたサーバーをリカバリーするためだけに新規アプリケーション・サーバーを始動する必要はありません。

図 1. ピア・リカバリー
サーバー・クラスターのピア・リカバリー。障害を起こしたサーバー 2 およびサーバー 3 のためにリカバリー処理を開始する前後のサーバー 1 を示しています。

ピア・リカバリー処理は、障害を起こしたサーバーの再始動と論理的に同等 ですが、ピア・サーバー内の障害を起こしたサーバーの完全な再始動を構成しません。 ピア・リカバリー処理では、未解決の作業を完了する機会が与えられますが、リカバリー処理以外の新規の作業を開始することはできません。障害が発生したサーバーに対しては、転送処理はできません。

ピア・リカバリーによって、高可用性要件が個々のサーバーからサーバー・クラスターに移動しています。 クラスターの管理システムは、このような障害の後に、残りのサーバーに新規作業をディスパッチします。唯一の相違点は、システム全体のスループットが低下する可能性が潜んでいることです。サーバーに障害が発生した場合、必要なことは、障害が発生したサーバーでアクティブだった作業を完了し、要求を代わりのサーバーに転送することだけです。

デフォルトでは、クラスター構成でトランザクション・ログ・リカバリーのフェイルオーバーを使用可能にしてクラスター・メンバーを再始動するまで、ピア・リカバリーは使用不可です。 トランザクション・ログ・リカバリーを使用可能にすると、WebSphere Application Server は、トランザクション・ピア・リカバリーを開始するためのスタイルとして、自動と手動の 2 つをサポートします。デプロイメントに基づき、どちらのスタイルがより適切であるかを判断し、適切な高可用性ポリシーを構成して、そのスタイルを指定します。この高可用性ポリシーは、これらのトピックでは、トランザクション・サービスのポリシー と呼ばれています。
自動ピア・リカバリー
このスタイルが、ピア・リカバリー開始のデフォルトです。アプリケーション・サーバーに障害が起こると、それに代わってピア・リカバリー処理を実行するサーバーを WebSphere Application Server が自動的に選択し、障害の起こったサーバーが再始動したときにリカバリーをそのサーバーに戻します。このモデルを使用するには、トランザクション・ログ・リカバリーを使用可能にし、クラスター・メンバーごとにリカバリー・ログのロケーションを構成します。
手動ピア・リカバリー
ピア・リカバリーのこのスタイルは、明示的に構成する必要があります。アプリケーション・サーバーに障害が起こると、管理コンソールを使用して、そのサーバーに代わってリカバリー処理を実行するサーバーを選択します。

HA 環境では、トランザクション・ログの他に補正ログも構成する必要があります。 クラスター内の各サーバーについて、補正サービス設定を使用して固有の補正ログ・ロケーションを構成し、すべてのクラスター・メンバーがこれらの補正ログにアクセスできることを確認します。

ピア・リカバリーの例

以下の図には、 単一サーバーに障害が発生した場合に起こるピア・リカバリー処理を示しています。図 2 には、WebSphere Application Server クラスターで稼働している 3 つの安定サーバーを示します。 ワークロードは、これらのサーバー間でバランスが取られ、これにより各サーバーの代わりに、バックエンド・データベースによってロックが保持されます。

図 2. サーバー・クラスター稼働中、サーバー障害の直前
この図は、サーバー障害前のサーバー・クラスターについて説明しています。

図 3 は、サーバー 1 に障害が発生して、データベースからロックが消去されずに残ってしまった後のシステムの状態を示しています。 サーバー 2 および 3 は、それぞれの既存のトランザクションを実行して 完了させ、バックエンド・データベースに存在する既存のロックを解放する ことができますが、サーバー 1 の代わりにロックが依然として保持されてい るため、それ以上のアクセスは低下する可能性があります。実際は、サー バー 2 および 3 は、適切に構成されたロックの細分度を想定す れば、あるレベルのアクセスは依然として可能ですが、この例では、サーバー 2 および 3 は、ロックされたレコードにアクセスしようとすると、ブロックされることを想定しています。

図 3. サーバー 1 は障害が発生しています。 サーバー 2 および 3 は結果としてブロックされます。
この図では、サーバー 1 の障害の結果として、サーバー 2 および 3 がブロックされるところを示しています。

図 4 は、サーバー 3 の中で稼働しているサーバー 1 に対するピア・リカバリー処理を示しています。リカバリー処理のトランザクション・サービスの部分では、サーバー 1 によって保管されている情報が取り出され、その情報を使用して、未確定トランザクションが完了します。 この図では、一部のロックをサーバー 1 の代わりにデータベースが保留しているため、ピア・リカバリー処理は部分的に完了します。

図 4. サーバー 3 で開始されたピア・リカバリー処理
この図では、サーバー 3 におけるピア・リカバリー処理を示しています。

図 5 は、ピア・リカバリー処理が完了したときのサーバー・クラスターの状態を示しています。 システムは 2 つのサーバーのみを持つ安定状態で、このサーバー間でワークロードのバランスを取ることができます。サーバー 1 は再始動可能で、実行する必要のある、それ自体のリカバリー処理はありません。

図 5. サーバー 2 およびサーバー 3 の 2 つのサーバーだけで再度安定したサーバー・クラスター
この図では、サーバー 2 および 3 によるサーバー・クラスターの安定を示しています。

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



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