|
|
クラスタ化された Oracle Service Bus ドメインは高可用性を備えています。高可用性デプロイメントには、ハードウェアやネットワークに障害が発生したときの回復処理が備えられており、障害発生時に制御をバックアップ コンポーネントに移行させることができます。
以下の節では、Oracle Service Bus デプロイメントのクラスタ化と高可用性について説明します。
高可用性を提供するクラスタでは、サービス障害からの回復が可能です。WebLogic Server では、レプリケートされた HTTP セッション ステート、クラスタ化されたオブジェクト、およびクラスタ化環境のサーバに固定されたサービスのフェイルオーバがサポートされます。WebLogic Server でこのようなフェイルオーバを処理する方法については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでの通信」を参照してください。
一般的な Oracle Service Bus 環境で使用できる基本コンポーネントは次のとおりです。
| 注意 : | 各種の JDBC ドライバに関連する可用性とパフォーマンスの注意点については、『WebLogic Server Administration Console オンライン ヘルプ』の「JDBC のコンフィグレーション」にある「データベース接続のコンフィグレーション」を参照してください。 |
クラスタ システムのネットワーク トポロジのプランニングについての詳細説明は、この節で扱う内容の範囲を越えています。Oracle Service Bus コンフィグレーションで、ロード バランサ、ファイアウォール、Web サーバについて、1 つまたは複数の WebLogic Server クラスタを構成することにより、着信ロード バランシング機能とフェイルオーバ機能を十分に活用する方法は、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタ アーキテクチャ」を参照してください。発信ロード バランシングのコンフィグレーションについては、『Oracle Service Bus Console の使い方』の「ビジネス サービス」にある「ビジネス サービスの追加」の「ビジネス サービスを追加するには - 転送コンフィグレーション」を参照してください。
次の図は、HTTP ロード バランサ、高可用性データベースとマルチポート ファイル システムを含むクラスタの概略を示しています。
デフォルトの Oracle Service Bus ドメイン コンフィグレーションでは、モニタとアラートの目的で収集されたメトリックを JMS の永続性用のファイル ストアに格納します。上記のコンフィグレーションは、パフォーマンスを最適化するために管理対象サーバ間で共有可能な、高可用性を備えたマルチポート ディスクに依存します。通常、JMS ファイル ストアは JDBC ストアよりもパフォーマンスが高くなります。
JMS ファイル ストアのコンフィグレーションについては、『WebLogic Server 環境のコンフィグレーション』の「WebLogic 永続ストアの使い方」を参照してください。
ソフトウェアまたはハードウェアの問題により、サーバに障害が発生することがあります。以下の節では、障害が起こったときに自動的に発生するプロセスと、手動で行わなければならない手順について説明します。
ソフトウェアの障害が発生すると、Node Manager は WebLogic Server を再起動します (再起動するようにコンフィグレーションされている場合)。Node Manager の詳細については、『サーバの起動と停止の管理』の「ノード マネージャを使用したサーバの制御」を参照してください。セキュア インストールの回復処理を準備する方法については、『サーバの起動と停止の管理』の「サーバ障害の回避とサーバ障害からの回復」にある「障害回復のためのディレクトリとファイルのバックアップ」を参照してください。
ハードウェアの障害が発生すると、物理マシンの修理が必要になり、長期間使用できなくなることがあります。ハードウェアの障害時には、以下のイベントが発生します。
Oracle Service Bus では、WebLogic Server のサーバ移行機能を利用して、システム間での管理対象サーバのフェイルオーバを透過的に行うことができます。WebLogic Server のサーバ移行の詳細については、WebLogic Server ドキュメントの次のトピックを参照してください。
JMS メッセージ レポート プロバイダの Message Reporting Purger は、クラスタ内の単一の管理対象サーバにデプロイされます (「Oracle Service Bus デプロイメントのリソース」を参照)。
Message Reporting Purger アプリケーションをホストする管理対象サーバで障害が発生した場合は、通常の運用を再開するために、Message Reporting Purger とそれに関連するキュー (wli.reporting.purge.queue) のために別の管理対象サーバを選択する必要があります。
障害が発生した管理対象サーバで保留されているパージ要求は、自動的には移行されません。これらは手動で移行する必要があります。または、Message Reporting Purger アプリケーションとそのキューを別の管理対象サーバに割り当てて、パージ要求を再び送信します。
WebLogic Server の高可用性機能に加え、Oracle Service Bus には、Oracle Service Bus ソリューションの実装とコンフィグレーション単位での障害回復処理の機能があります。以下の節では、Oracle Service Bus の障害と回復処理に関する次のトピックについて説明します。
Oracle Service Bus では、外部サーバおよびサービスが障害により再起動されたとき、それらへの再接続が透過的に行われます。接続が使用できない間に Oracle Service Bus から送り先にメッセージが送信されると、サーバ コンソールに 1 つまたは複数の実行時エラー メッセージが表示されることがあります。
以下の種類のサーバおよびサービスで透過的な再接続を行うことができます。
Oracle Service Bus Console はモニタ機能も備えており、サービスの状態を表示したり、サービスの障害に応答する SLA とアラートのシステムを構築することができます。詳細については、『Oracle Service Bus Console の使い方』の「モニタ」を参照してください。
プロダクション環境のほとんどのビジネス サービスは、ロード バランシングと高可用性を目的として複数の EIS インスタンスを指すようにコンフィグレーションされます。EIS インスタンスの障害が長引くか、ビジネス サービスが障害のある単一の EIS インスタンスを指すことが予期される場合、ビジネス サービスのコンフィグレーションを再設定し、代替のオペレーション可能な EIS インスタンスを指定できます。この変更は動的に行うことができます。
Oracle Service Bus Console を使用したビジネス サービスのエンドポイント URI の変更については、『Oracle Service Bus Console の使い方』の「ビジネス サービス」にある「ビジネス サービスの表示と変更」を参照してください。
ファイル、FTP、および電子メールは、ポーラー ベースの転送です。これらのプロトコルはトランザクション非対応であるため、信頼性の向上と高可用性の実現のために、追加の JMS ベースのフレームワークが作成され、これらの転送で障害からの回復が行えるようになりました。これらの転送では、JMS·フレームワークを使用して、メッセージの処理が少なくとも·1·回は実行されることを保証します。ただし、処理が実行されても、サーバがクラッシュしたり、トランザクションが完了する前にサーバが再起動された場合は、同じファイルを再度処理できます。処理が再度実行される回数は、ドメインのポーラー転送に設定されている再配信制限によって異なります。
ターゲット (ファイルおよび FTP 転送の場合はディレクトリ、電子メール転送の場合はサーバ アカウント) からの新しいメッセージは、ポーリングまたはパイプライン処理時に、ダウンロード (ステージ) ディレクトリにコピーされます。
| 注意 : | FTP 転送の場合、ファイル名は、リモート ディレクトリで <名前>.stage に変更されます。ファイルは、パイプライン処理時のみ、ステージ ディレクトリにコピーされます。 |
ファイルおよび FTP 転送の場合、ターゲット ディレクトリのそれぞれの新しいファイル応じて JMS タスクが作成されます。電子メール転送の場合、電子メール メッセージはダウンロード ディレクトリのファイルに格納され、これらの各ファイルに応じて JMS タスクが作成されます。
これらの JMS タスク メッセージは、Oracle Service Bus ドメインの作成時にこれらの転送用に事前にコンフィグレーションされる JMS キューに格納されます。
Oracle Service Bus ドメインに対してコンフィグレーションされるポーラー転送固有の JMS キューを以下に示します。
ドメイン全体のメッセージ駆動型 Bean (MDB) が JMS タスクを受信します。MDB はメッセージを受信すると、XA トランザクションのパイプラインを呼び出します。パイプラインでの例外またはサーバのクラッシュによってパイプラインでメッセージ処理が失敗した場合、XA トランザクションも失敗し、メッセージは再度 JMS キューに格納されます。このメッセージは、キューに設定された再配信制限のパラメータに基づいて、MDB に再配信されます。デフォルトでは、再配信制限は 1 (メッセージは 1 回送信され、1 回再試行される) に設定されています。メッセージが正常に配信されずに再配信制限に達した場合、メッセージはエラー ディレクトリに移されます。この制限は、WebLogic Server Console から変更できます。詳細については、『Administration Console オンライン ヘルプ』の「JMS トピック : コンフィグレーション : 配信の失敗」を参照してください。
| 注意 : | 単一の Oracle Service Bus ドメインの転送の場合、再配信制限は、ドメイン全体でグローバルです。たとえば、1 つのドメイン内で、ある FTP プロキシで再配信制限を 2 に設定し、別の FTP プロキシで再配信制限を 5 に設定することはできません。 |
クラスタでは、これらのそれぞれのポーラー ベースの転送に関連付けられている JMS キューは、分散キューです (各管理対象サーバは、分散キューのメンバーであるローカル JMS キューを持っています)。転送用の JMS キューはドメイン全体をサポートします。タスク メッセージは、分散キューに入れられ、管理対象サーバの基底のローカル キューに渡されます。管理対象サーバにデプロイされている MDB がメッセージを取得し、実際のメッセージ処理のために、トランザクションのパイプラインを呼び出します。
JMS キューは、クラスタ ドメイン内の分散キューであるため、WebLogic Server の分散キュー機能を利用することで高可用性が実現します。すべての管理対象サーバがメッセージのポーリングを行うのではなく、クラスタ内のいずれかの管理対象サーバのみにメッセージのポーリングのジョブが割り当てられます。プロキシ サービスのコンフィグレーション時に、いずれかの管理対象サーバが新しいファイルまたは電子メール メッセージをポーリングするようにコンフィグレーションされます。詳細については、『Oracle Service Bus Console の使い方』の「プロキシ サービス」にあるプロキシ サービスの追加を参照してください。
ポーラー サーバは新しいメッセージをポーリングし、個々のポーラー転送に関連付けられた共通分散キューに置きます。このキューから、メッセージが管理対象サーバのローカル キューに渡されます。管理対象サーバは、これらのローカル キューを介して、すべてのサーバにデプロイされている MDB を使用してメッセージを受信します。
| 注意 : | これらのそれぞれのポーラー ベースの転送用に、すべての管理対象サーバにローカル キューを持つ共通分散キューがあります。 |
分散キューがローカル キューにメッセージを配信した後で管理対象サーバがクラッシュした場合は、手動で移行する必要があります。詳細については、「サーバの移行」を参照してください。
クラスタが作成されるときに、すべての管理対象サーバにローカル キュー メンバーを持つ共通分散キューが作成されます。ただし、既存のクラスタに新しい管理対象サーバが追加されるときは、これらのローカル キューは自動的には作成されません。ローカル キューを手動で作成し、共通分散キューの一部にする必要があります。
| 注意 : | 分散キューの JNDI 名は、wlsb.internal.transport.task.queue.file (ファイル転送の場合)、wlsb.internal.transport.task.queue.ftp (FTP 転送の場合) および wlsb.internal.transport.task.queue.email (電子メール転送の場合) です。 |
分散 JMS キューを使用すると、分散キューに関連付けられているロード バランシング アルゴリズムに基づいて、メッセージが管理対象サーバに分散されます。デフォルトでは、JMS フレームワークでは、ラウンドロビン ロード バランシングを使用します。WebLogic Server Console で JMS モジュールを使用してアルゴリズムを変更できます。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「JMS のロード バランシング」を参照してください。管理対象サーバのいずれかで障害が発生した場合、残りのメッセージは、他のアクティブな管理対象サーバのいずれかによって処理されます。
| 注意 : | ポーラー サーバは常に動作している必要があります。ポーラー サーバに障害が発生した場合、メッセージ処理も停止します。 |
|