Oracle® Fusion Middleware Oracle Service Busデプロイメント・ガイド 11g リリース(11.1.1.3) B61432-01 |
|
前 |
次 |
以下の項では、Oracle Service Busをクラスタリング環境で構成およびデプロイする方法を説明します。内容は以下のとおりです。
クラスタリングによって、Oracle Service Busをサーバーのグループで実行でき、そのグループを単体ユニットとして管理できます。クラスタ環境では、複数のマシンが負荷を分担します。Oracle Service Busにはロード・バランシング機能があるので、リソース・リクエストはすべてのマシンに均等に分散されます。Oracle Service Busデプロイメントは、クラスタリングとロード・バランシングを使用してノードに負荷を分散させることにより、スケーラビリティを向上できます。クラスタリングにより、単一サーバーよりもスケーラビリティの高いデプロイメント・プラットフォームを構築できます。
Oracle WebLogic Serverクラスタのドメインは、1台の管理サーバーと、1つまたは複数の管理対象サーバーで構成されます。Oracle Service Busドメインの管理対象サーバーを1つのクラスタにまとめることができます。Oracle Service Busのクラスタリング可能リソースを構成する場合、通常はそのリソースのデプロイ対象とするクラスタを指名します。クラスタをリソース・デプロイメントの対象として指定すると、管理対象サーバーをクラスタに追加することによって能力を動的に増大できるという利点が得られます。
注意: Oracle Service Busドメインでは単一のクラスタをサポートできます。ドメイン内のすべての管理対象サーバーがそのクラスタに属する必要があります。 |
ここでは、クラスタ環境でOracle Service Busを構成する場合に必要な情報について説明します。Oracle WebLogic Serverでサポートしているクラスタリングについての予備的な情報も含まれていますが、主に、クラスタ環境でOracle Service Busを構成する手順を説明します。
読み進む前に、以下のOracle WebLogic Serverドキュメントの項の内容を確認し、クラスタリングについて十分に理解しておくことをお薦めします。
『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』
『Oracle Fusion Middleware Oracle WebLogic Serverのサーバー環境設定』
以下の項では、クラスタ・デプロイメントの設計に必要な情報について説明します。
クラスタリングされたドメインに合わせてアーキテクチャを設計する前に、Oracle WebLogic Serverクラスタがどのように運用されるかを知っておく必要があります。
ドメインおよびクラスタの作成は、Oracle Fusion Middleware構成ウィザードを使用して基本および拡張ドメイン・テンプレートからドメインを生成することにより、簡単に実行できます。ユーザー問合せに対するレスポンスを基に、構成ウィザードによって、ドメイン、サーバ、エンタープライズ・アプリケーションが、構成済の適切なコンポーネントおよび資産を含めて生成されます。Oracle Fusion Middleware構成ウィザードを使用したOracle Service Busドメインの作成については、『Oracle Fusion Middleware Oracle Service Busインストレーション・ガイド』を参照してください。
サーバーには管理対象サーバーと管理サーバーがあります。管理サービスを実行しているOracle WebLogic Serverは管理サーバーと呼ばれ、Oracle WebLogic Server管理コンソールのホストとなります。複数のOracle WebLogic Serverが稼働しているドメインでは、そのうち1つのみが管理サーバーで、他のサーバーは管理対象サーバーと呼ばれます。各管理対象サーバーは、起動時に管理サーバーから構成を取得します。
注意: 管理サーバーなしで起動する管理対象サーバーは、管理対象サーバー独立(MSI)モードで稼働します。MSIモードの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』の管理対象サーバー独立モードに関する項を参照してください。 |
管理サーバーのSSLポート、HTTPクリア・テキスト・ポート、またはそれら両方のポートを有効にできます。セキュア・インストールでは、HTTPクリア・テキスト・ポートを無効にできます。ただし、Oracle Service BusをUDDIレジストリ(Oracle Service Registryなど)と組み合せて使用する場合は、サーバーのHTTPクリア・テキスト・ポートを有効にする必要があります。
WebLogicクラスタの一般情報については、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』を参照してください。このドキュメントでは、推奨される基本、多層、およびプロキシ・アーキテクチャの詳細について説明されています。WebLogicクラスタ設計のセキュリティに関する考慮事項については、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』のクラスタ・アーキテクチャのセキュリティ・オプションに関する項を参照してください。
クラスタリングされたドメインの各サーバーに対して、そのドメイン内のサーバーの機能を定義する様々な属性を構成できます。これらの属性は、Oracle Fusion Middleware構成ウィザードでOracle Service Busドメインを作成すると、自動的に構成されます。また上級ユーザーの場合は、Oracle WebLogic Server管理コンソールの「サーバー」ノードを使用して手動で構成することもできます。
Oracle Service Busデプロイメントの構成可能なリソースの一覧については、付録B「Oracle Service Busデプロイメントのリソース」を参照してください。ここでは、クラスタリングされたOracle Service Busドメインの各リソースのデフォルトのターゲット指定について説明し、Oracle WebLogic Server管理コンソールの各リソースへの移動方法を示しています。
Oracle Service Busで使用されるほとんどのリソースはクラスタ内に均一にデプロイされますが、正しく動作させるには単一の管理対象サーバーに固定する必要があるリソースがあります。以下の表に、これらのコンポーネント、そのターゲット指定の方法、および詳細情報へのリンクを示します。
表3-1 Oracle Service Busのシングルトン・リソース
リソース | ターゲット指定方法および指定先 | 詳細については、以下を参照 |
---|---|---|
プロキシ・サービスのファイル、FTP、および電子メール・ポーラー |
Oracle Service Busコンソールを使用してプロキシ・サービス定義に手動で指定します。ポーラーはすべての管理対象サーバーにデプロイされるが、特定のプロキシ・サービスには1台の管理対象サーバーにあるポーラーがポーリングします。 |
『Oracle Fusion Middleware Oracle Service Busインストレーション・ガイド』 |
ALSB Domain Singleton Marker Application |
Oracle Fusion Middleware構成ウィザードでターゲット指定する |
『Oracle Fusion Middleware Oracle Service Busインストレーション・ガイド』 |
SLAマネージャ |
Oracle Fusion Middleware構成ウィザードでターゲット指定する |
『Oracle Fusion Middleware Oracle Service Busインストレーション・ガイド』 |
各管理対象サーバーのOracle Service Bus JMSサーバー wlsbJMSServer_auto_1-n |
Oracle Fusion Middleware構成ウィザードで自動的にターゲット指定される |
『Oracle Fusion Middleware Oracle Service Busインストレーション・ガイド』 |
ALSB Domain Singleton Marker Application (domainsingletonmarker.ear)は、クラスタ内の1台の管理対象サーバーでシングルトン・サービスとして実行されます。データの収集は、ドメインの各管理対象サーバーで実行されます。ALSB Domain Singleton Marker Applicationは、ドメインのすべての管理対象サーバーからデータを収集し、集約します。集約されたデータは処理され、Oracle Service Bus構成ごとに分類されます。
Oracle Service Bus構成には、システム・パフォーマンスのサービス・レベル合意(SLA)を定義するルールを含めることができます。アラート・マネージャではルールを格納し、集約されたクラスタ・データについてルールを評価します。ルールがtrue
と評価された場合、アラート・マネージャではルールに関連付けられているアクションに従って、電子メール・メッセージの送信、JMSキューへのメッセージのポスト、またはメッセージのロギングを行います。
これらの機能の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のモニターに関する項を参照してください。
セッションのアクティブ化処理中に管理対象サーバーがダウンした場合、そのサーバーには、アクティブ化による構成の変更は反映されません。また、セッションのアクティブ化についてのタスクのステータスは、部分的にアクティブ化されましたとして示され、すべての管理対象サーバーでアクティブ化処理が完了しなかったことを示します。管理対象サーバーを再起動すると、管理対象サーバーは、管理サーバーから入手可能な情報と同期し、アクティブ化されていないすべての変更内容が管理対象サーバーでアクティブ化されます。セッションのアクティブ化の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。
クラスタの再構成(クラスタへの新しいノードの追加やビジネス・サービス構成の変更など)を行うことができるのは、その管理サーバーがアクティブな場合だけです。
あるクラスタの管理サーバーが使用できなくなると、デプロイ・リクエストやアンデプロイ・リクエストは中断されますが、管理対象サーバーはリクエストの処理を続行します。各管理対象サーバーは、必要な構成ファイル(msi-config.xml
、SerializedSystemIni.dat
およびオプションのboot.properties
)がその管理対象サーバーのルート・ディレクトリに存在するかぎり、既存の構成を使用して起動および再起動できます。
Oracle Service Busアプリケーションをクラスタリングする目的の1つは、スケーラビリティの実現です。クラスタをスケーラブルなものにするには、各サーバーを十分に活用する必要があります。ロード・バランシングにより、クラスタ内のすべてのサーバー間で負荷が均等に分散され、各サーバーがそれぞれ最大能力で動作できるようになります。以下の項では、Oracle Service Busクラスタのインバウンド・メッセージ処理のロード・バランシングについて説明します。
インバウンド・メッセージのロード・バランシングについては、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』の「クラスタでのロード・バランシング」を参照してください。ビジネス・サービスのロード・バランシングの構成については、 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトランスポート構成に関する項を参照してください。
Webサービス(SOAPまたはXML over HTTP)では HTTPロード・バランシングを使用できます。外部ロード・バランシングは、WebLogic HttpClusterServlet、WebServerプラグインまたはハードウェア・ルーターによって実現できます。ロード・バランシングを含むクラスタ・トポロジの概要については、図5-1を参照してください。Oracle WebLogic ServerはHTTPセッション・ステートおよびクラスタ・オブジェクトのロード・バランシングをサポートしています。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』のクラスタでの通信に関する項を参照してください。
Oracle Service Busで使用されるほとんどのJMSキューは分散宛先として構成されています。例外は、単一の管理対象サーバーに割り当てられているJMSキューです。
JMSロード・バランシングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のJMSサーバーおよび宛先のメッセージのフロー制御に関する項を参照してください。
メッセージドリブンBeanは、JMS宛先からのメッセージを消費します。多くのメッセージドリブンBeanが、Oracle Service Busの各宛先にデプロイされます。
複数の物理宛先を1つの分散宛先グループのメンバーとして構成できるため、WebLogic JMSを実装にきわめて高い可用性がもたらされます。具体的には、管理者がクラスタ内の各ノードに対して、各分散宛先に物理宛先を1つ構成する必要があります。クラスタ内のノードに障害が発生して、そのノードの物理宛先が使用できなくなった場合、分散宛先のメンバーとして構成された他の物理宛先が、JMSのプロデューサとコンシューマにサービスを提供することができます(この方法で、Oracle Fusion Middleware構成ウィザードはクラスタのドメインを生成します)。
メッセージドリブンBeanは、分散宛先からのメッセージを消費します。分散宛先には、Oracle WebLogic Serverのインスタンスごとに1つの物理宛先が含まれます。分散キューの各メッセージ・プロデューサは、それぞれ1つの物理宛先にバインドされています。メッセージドリブンBeanは、デプロイ先のサーバー内の物理宛先にバインドされています(サーバー親和性)。
詳細は、第5章「Oracle Service Busの高可用性について」を参照してください。
構成をデプロイするには、Oracle Service Busコンソールからエクスポートされた1つまたは複数のJARファイルの内容をインポートします。クラスタ環境にOracle Service Bus構成をデプロイするときは、非クラスタ・デプロイメントと同じ手順に従います。デプロイメント手順については、2.4項「ステップ4. Oracle Service Bus構成のデプロイ」を参照してください。
本番クラスタ環境へのOracle Service Bus構成のデプロイメントを準備するときは、非クラスタのテスト環境またはステージング環境の場合より多くのシステム管理タスクが必要になります。本番クラスタ・デプロイメントで必要な手順の詳細は、第4章「クラスタ・デプロイメントの構成」を参照してください。