| Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド 11g リリース1 (11.1.1.7) B61432-07 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド 11g リリース1 (11.1.1.7) B61432-07 |
|
前 |
次 |
この章では、クラスタ環境に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ドメイン・シングルトン・マーカー・アプリケーション |
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ドメイン・シングルトン・マーカー・アプリケーション(domainsingletonmarker.ear)は、クラスタ内の1台の管理対象サーバーでシングルトン・サービスとして実行されます。データの収集は、ドメインの各管理対象サーバーで実行されます。ALSBドメイン・シングルトン・マーカー・アプリケーションは、ドメインのすべての管理対象サーバーからデータを収集し、集約します。集約されたデータは処理され、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はHTTPトランスポートを使用し、ビジネス・サービスに対してスティッキー・セッションまたはセッション・アフィニティをサポートします。つまり、あるセッションのすべてのリクエストがそのセッションの最初のリクエストを処理したサーバーへ転送されます。ビジネス・サービスに対してHTTPトランスポート・プロパーティでセッション・アフィニティを構成できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトランスポート構成に関する項を参照してください。
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章「クラスタ・デプロイメントの構成」を参照してください。
