WebSphere Enterprise Service Bus バージョン 6.2.0 オペレーティング・システム: AIX、HP-UX、i5/OS、Linux、Solaris、Windows


トランザクションのプロパティーとソリューション・リカバリー

WebSphere® ESB は WebSphere Application Server をベースとしているため、ビジネス・トランザクションを実行するトランザクション・モデル をサポートしています。

WebSphere ESB はこのトランザクション・モデルに基づいて構築されており、疎結合の SOA アプリケーションおよび BPM アプリケーションを提供します。

これは、技術的に 2 つの事柄を意味します。

  1. WebSphere ESB は、トランザクション・アプリケーション実行パターンを実現するためにデータベース・システムおよびメッセージング・システムに依存しています。
  2. トランザクションは、メッセージング・システムおよびデータベース・システムにおいて重要な役割を担っています。

    トランザクションは、ACID プロパティーに対応しています。トランザクションは、原子性、一貫性、独立性、および耐久性を持つときに、 ACID 準拠と見なされます。

    WebSphere ESB ではデータベース・システムおよびメッセージング・システムを使用して、「疎結合された」パターンを実現します。WebSphere ESB はデータベースを更新してメッセージを送信します。データベースの更新およびメッセージの処理は同じトランザクションでコミットされます。

    「疎結合」パターンの別の特徴は、メッセージング・システムからメッセージを取り出して、データベースを更新することです。 この処理中に障害が発生すると、イベントはあたかも未読であったかのようにメッセージ・キューに戻ります。WebSphere ESB には再試行メカニズムが存在し、5 回試行した後でイベントは Failed Event Manager に渡されます。「疎結合」という句は、すべての処理が 1 つの大きなトランザクション内で発生しなくてもよいことを表しています。

システム障害イベントでのデータ損失の回避

利用可能なリソース・マネージャーを適切に調整および構成しておけば、システムのある部分に障害があってもデータは失われません。ロールバックおよびリカバリーのメカニズムなどのトランザクションの保全性は、障害が発生してもデータが失われないようにする、WebSphere のキー・コンポーネントです。

WebSphere のロールバックおよびリカバリー・メカニズムを機能させるには、リソース・マネージャー (データベースおよびメッセージング) を正しくセットアップする必要があります。例えば、データベースのロック・タイムアウトを適切に設定し、サーバーのリカバリー時に、ロック状態になることなく、データベースでコミットまたはロールバックのどちらかを完了できるようにする必要があります。

WebSphere ESB は、WebSphere Application Server の機能を拡張する機能を追加することで、予期しない障害からデータを回復する完全なソリューションを提供します。

リカバリー機能の使用可能化の概要

WebSphere ESB のコア・リカバリー・モデルの基本は作業単位です。システムは、システム操作中に発生する障害を、実行される単一の作業単位に注目して処理および回復できるため、中断することなくサービスを提供できます。このタイプのリカバリーは、一連の再試行メカニズムとエラー・キューによって行われます。アプリケーション設計の一部に、システム・エラーをアプリケーション・エラーと区別する機能を組み込んでください。システム・エラーは、呼び出し側コンポーネントをサポートするインフラストラクチャーに戻されます。そこでは、追加のシステム・レベル・リカバリーが試みられたり、より一般的なビジネス例外への変換が行われたりします。自動的に実行されるさまざまな再試行メカニズムを構成できます。また WebSphere ESB では、必要な場合に人間の詳細な介入を可能にする一連のコンソールおよび対応するプログラミング・インターフェースが提供されています。これらの機能およびこれらが扱う障害の多くは、この作業を実行するサーバーが新しい要求の処理を継続している間も活用できます。

使用不可サーバー - 概要

障害によって、高い可用性を持つ WebSphere クラスター内の 1 つまたは複数のサーバーが使用不可になった場合、システム内の追加のリカバリー機能が以下のように呼び出されます。
  1. インバウンド処理を経路指定して障害システムから引き離す

    これは、基盤となる WebSphere Application Server のワークロード管理機能を使用して実行されます。この機能は、プロトコル、トポロジー、および構成によって異なります。

  2. 管理者がアクションを開始する

    システムは、全体としてアクティブで使用可能な状態を続けますが、管理者はリカバリー操作を実行できます。

    管理者のアクションの目的は、基本的な優先順位を決定し、停止しているサーバーを再始動することです。この再始動によってトランザクション・ログが再生され、ほとんどのサーバー・ダウンの状況がクリーンアップされるはずです。

    完全リカバリーを管理するには、WebSphere ESB で提供されているエラー処理メカニズムを使用することが必要な場合があります。

使用不可クラスター - 概要

サーバー・クラスター全体が使用できないか、または応答しない場合、より複雑な一連のリカバリー・アクションが必要です。例えば、データベースなどの共用リソースが利用できない場合は、クラスター内のどのサーバーでも一様に処理の完了が難しくなります。

共用リソース・リカバリーを処理する手順は、障害が発生している共用リソースによって決まります。さまざまな WebSphere の技法を適用して、全体的なダウン時間を最小化し、停止した処理を再開することができます。

壊滅的な障害 - 概要

壊滅的な状況では、マシン全体が利用できないか、またはサーバーがリカバリー可能ではありません。 このような事例では、WebSphere の拡張機能を使用して、サーバー障害のリカバリーを同じクラスター内の別のサーバー上で実行することができます。この機能では、ログを共用するためのネットワーク接続されたストレージまたはその他のメカニズムを用意するという前提条件を満たすことで、この種類のリカバリーも可能になります。同じクラスターの別のメンバーによる障害サーバーのリカバリーの詳細については、ピア・リカバリーを参照してください。


concept 概念トピック

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


タイムスタンプ・アイコン 最終更新: 2010/07/05


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/crec_trnsactional.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
このインフォメーション・センターでは Eclipse テクノロジーが採用されています (http://www.eclipse.org)。