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