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