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