WebLogic Platform アプリケーションのデプロイメント

対象環境について

アプリケーション プロモーション プロセスは、アプリケーションの設計だけでなく、アプリケーションを実行する対象環境のハードウェアおよびソフトウェアの特性によっても影響を受けます。これらの特性には、アプリケーションをホストする、またはアプリケーションと頻繁に対話するマシン、マシンのオペレーティング システム、ネットワーク、データベース、クラスタ、ロード バランサなどが含まれます。

この章では、WebLogic Platform アプリケーションをデプロイする 4 つの異なる環境、各環境の特性が各環境のドメインのコンフィグレーション方法に及ぼす影響に関する考慮事項、および各環境へのデプロイメント前のアプリケーション ファイルの変更方法について説明します。また、セキュリティ、高可用性、およびデータベース使用に関する特定の考慮事項についても説明します。

この章の内容は以下のとおりです。

• 一般的なデプロイメント環境
• WebLogic Platform ドメインのコンフィグレーションに関する考慮事項
• WebLogic Platform ドメインの例

この章の内容は概念的なものであり、概要レベルにとどまります。WebLogic Platform ドメインのシステムレベルのリソース、サービス、およびアプリケーションの割り当てやデプロイメントに関する詳細については、「デプロイメント対象のリファレンス」を参照してください。

 

---

一般的なデプロイメント環境

WebLogic ドメインに基づく基本的なデプロイメント環境には通常、以下の表に示されたコンポーネントが含まれます。この表にはコンポーネントを表す図が示されており、これらの図はこの章全体で使用されています。

表 2-1 基本的なアプリケーション デプロイメント環境のコンポーネント

コンポーネント	説明
ドメイン	デプロイメントされたリソースを管理する基本的な組織単位。ドメインは、1 つまたは複数の WebLogic Server インスタンス、および論理的に関連し 1 つの単位としてまとめて管理されるリソースとサーバで構成される。
マシン	マシンにインストールされ、WebLogic Server インスタンスが実行される WebLogic ソフトウェア、アプリケーション、データベースおよび RDBMS、環境で使用されるその他のソフトウェアをホストする。
管理サーバ	各ドメインの WebLogic Server の 1 つのインスタンスは管理サーバとして機能するため、すべてのサーバ インスタンスを一元的に管理できる。
管理対象サーバ	ドメインのアプリケーション コンポーネントとリソースをホストする。マシンは複数の管理対象サーバをホストできる。
ノード マネージャ	リモートの WebLogic Server インスタンスの起動、停止、およびモニタを可能にする、WebLogic Server に付属する Java プログラム。この機能を有効にするには、ドメイン内の物理的な各マシン上でノード マネージャを実行する。
クラスタ	スケーラビリティおよび信頼性を向上させるために同時に実行されている複数のサーバ インスタンスから構成される。クラスタはクライアントからは単一の WebLogic Server インスタンスのように見える。クラスタを構成するサーバ インスタンスは同じマシン上で実行することも、複数のマシンに分散配置することもできる。 注意 : 管理サーバはクラスタのメンバーになれない。
データベース	アプリケーションおよびシステム データをホストする。WebLogic Platform は、PointBase、Oracle、Microsoft SQL Server、DB2、Sybase などの一般的な RDBMS システムをサポートする。RDBMS との対話は WebLogic JDBC を介して行うことができる。
ロード バランサ/プロキシ	クライアントの接続リクエストを分散し、クラスタ全体に対してロード バランシングおよびフェイルオーバを提供し、ローカル エリア ネットワーク アドレスを外部ユーザから隠すことによりセキュリティを確保する。ロード バランサ/プロキシは、以下のいずれかの方法により実装できる。 WebLogic Server のインスタンス (HttpClusterServlet を使用) WebLogic Server プロキシ プラグインによりコンフィグレーションが行われた WebLogic Platform によってサポートされる Web サーバ ハードウェア ロード バランサ

 

図 2-1 は、管理対象サーバとクラスタを含む一般的な WebLogic Server ドメインの例を示しています。

図 2-1 管理対象サーバとクラスタを含む一般的な WebLogic ドメイン

 

WebLogic Server ドメインの詳細については、以下の URL にある『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server ドメインの概要」を参照してください。

http://edocs.beasys.co.jp/e-docs/wls/docs81/adminguide/overview_domain.html

以降の節では、WebLogic Platform ドメインのコンフィグレーションに関する一部の考慮事項と要件について説明します。

 

---

WebLogic Platform ドメインのコンフィグレーションに関する考慮事項

WebLogic Platform アプリケーションのドメインをコンフィグレーションするときにドメインに少なくとも 1 つのクラスタが含まれる場合は、以下の考慮事項に注意してください。

• ドメインを作成するために使用するドメイン コンフィグレーション テンプレート (コンフィグレーション ウィザードや WebLogic Scripting Tool (WLST) Offline を使用して作成) によって、ドメインで実行するサーバの構造が決まる。つまり、ドメインのすべてのサーバは、このテンプレートで指定されたコンポーネントを含むようにコンフィグレーションされます。たとえば、WebLogic Integration ドメインを作成した場合、ドメインの各サーバでは WebLogic Portal リソースではなく WebLogic Integration リソースがコンフィグレーションされます。これとは逆に、WebLogic Platform ドメインの各サーバでは、すべての WebLogic Platform コンポーネントを実行するために必要なリソースがコンフィグレーションされます。
• プロダクション環境用にコンフィグレーションされたドメインには、少なくとも 1 つのクラスタを使用する。クラスタは、プロダクション用アプリケーションに通常必要とされる高可用性、ロード バランシング、およびフェイルオーバの機能を提供します。
• WebLogic Portal アプリケーションや Administration Portal ツールは通常、クラスタと管理サーバの両方を対象とする。これは、WebLogic Portal の非常に強力な機能を有効にするために必要です。この機能により、更新や他のカスタマイズがドメイン内の各サーバ インスタンスに動的に伝播されます。
• WebLogic Integration アプリケーションはクラスタを対象とし、WebLogic Integration Administration Console は管理サーバを対象とする。
• ドメインには、複数の WebLogic Integration クラスタを含めることができない。つまり、WebLogic Integration アプリケーションとそのアプリケーションに必要なシステムレベルのリソースは、複数のクラスタを対象とすることができません (この制限により、あるクラスタで WebLogic Integration アプリケーションを実行し、別のクラスタで WebLogic Portal アプリケーションを実行するようにコンフィグレーションされたマルチ クラスタ ドメインを作成することが複雑になります (「マルチ クラスタ Platform ドメインの例」を参照))。
• WebLogic Platform ドメインには、リレーショナル データベース管理システム (RDBMS) が必要である。
• RDBMS は、WebLogic Workshop 実行時フレームワークや、システムおよびアプリケーション レベルの WebLogic Portal リソースと WebLogic Integration リソースに必要である。
• システムレベルの RDBMS 処理を行うために、一連の JDBC リソース (接続プール、データ ソース、トランザクション データ ソースなど) が WebLogic Platform コンポーネントによって必要とされる。これらのリソースの詳細については、「リソースのコンフィグレーションと割り当てに関する考慮事項」を参照してください。
• WebLogic Platform ドメイン内の各 WebLogic Server インスタンスでは、JMS サーバがコンフィグレーションされる。JMS サーバは、アプリケーションと、JMS を使用するシステムレベルのリソースの両方に必要なすべての送り先、接続ファクトリ、メッセージ ストア、キーなどを管理します。

また、WebLogic Workshop で作成し、Web サービスに非同期要求を行う Web アプリケーション プロジェクト (WebLogic Integration および WebLogic Portal 用のものを含む) には、デフォルトで非同期キューと非同期エラー キューが作成されます。このキューに対して、アプリケーションをデプロイメントする各対象サーバ上に、対応する JMS キューのペアを作成する必要があります。対象ドメインがクラスタ化されている場合は、これらのキューを分散キューとしてコンフィグレーションする必要があります。詳細については、「WebLogic Workshop ランタイムで必要なアプリケーション リソースの追加」を参照してください。

• クラスタには、ロード バランシングのために少なくとも 3 つの管理対象サーバが必要である。1 つの管理対象サーバで障害が発生した場合は、残りの 2 つの管理対象サーバ間でロード バランシングが維持されます。

 

---

WebLogic Platform ドメインの例

この節では、以下の 4 つのドメイン環境での WebLogic Platform アプリケーションのコンフィグレーションに関する考慮事項について説明します。

• 開発ドメインの例
• 単一クラスタ Platform ドメインの例
• マルチドメインの例
• マルチ クラスタ Platform ドメインの例

これらの例を示す目的は以下の 2 つです。

プロモーション プロセスでステージとして使用できる WebLogic Platform コンフィグレーションを説明する。
このドキュメントでこれ以降に説明するデプロイメント タスクとコンフィグレーション タスクの範囲を説明する。

これらの例は、WebLogic Platform で可能なコンフィグレーションの種類が制限されることを意味しません。これ以外にも使用できるコンフィグレーションが存在します。ただし、WebLogic Platform を初めて使用する場合は、これらの例を使用すると役に立ちます。

以降の節で示された図では、マシンで実行されているアプリケーションの種類が、最低限の構成の WebLogic Platform 製品がそのマシンにインストールされていることを示しています。たとえば、WebLogic Portal アプリケーションをホストするマシンには、WebLogic Portal、WebLogic Workshop、および WebLogic Server がインストールされている必要があります。ただし、マシンで実行されているアプリケーションの種類は、これらの製品のみがインストールされていることを示しません。たとえば、WebLogic Portal アプリケーションは、WebLogic Integration を含むすべての WebLogic Platform 製品がインストールされているマシンで実行できます。

開発ドメインの例

WebLogic Workshop を使用する一般的な開発環境は、以下の図に示されたように単一サーバ ドメインから構成されます。

図 2-2 単一サーバ開発ドメインの例

 

例で示されたコンポーネント

図 2 - 2 で示された開発環境には、以下の特徴があります。

• データベースを含むドメイン全体が 1 つのマシン上にある。
• WebLogic Platform のシステムレベルのコンポーネントで必要なデータベースを管理する RDBMS が、デフォルトの単独ユーザ PointBase RDBMS である場合がある。または、WebLogic Platform によってサポートされたプロダクション対応の RDBMS である場合がある。開発時に、プロダクション システムで使用されるのと同じ RDBMS を使用することをお勧めします (ただし、必須ではありません)。WebLogic Platform には、あるデータベースと RDBMS から別のデータベースと RDBMS に簡単に移行できるスクリプトが用意されています。このスクリプトには、あるデータベースからデータベース スキーマを抽出し別のデータベースに挿入することができるスクリプトも含まれます。
• この例のドメインには、この図で PlatApp として示されている単一の WebLogic Platform アプリケーションをホストする単一サーバが含まれる。「WebLogic Platform アプリケーションについて」に記載されているように、WebLogic Platform アプリケーションには、WebLogic Platform のすべてのコンポーネントが組み込まれます。
• また、サーバは、WebLogic Platform の以下のすべての管理コンポーネントをホストする。
• WebLogic Server ドメイン管理コンポーネント (WLS Console として示されています)。
• WebLogic Portal のシステムレベルの Web アプリケーションおよび EJB (Portal Console として示されています)。これらのコンポーネントには、WebLogic Administration Portal と Datasync Web アプリケーションが含まれます。
• WebLogic Integration Administration Console およびその他の管理コンポーネント (WLI Console として示されています)。これらのコンポーネントには、EJB、Web アプリケーション、起動クラス/停止クラス、コンフィグレーション キュー、およびトピックが含まれます。
• WebLogic Platform ドメイン JMS および JDBC リソース。

このコンフィグレーションに関する考慮事項

このコンフィグレーションは基本的な WebLogic Platform ドメイン コンフィグレーションであり、通常、アプリケーション開発に使用されます。サーバ管理が簡略化され、すべてのアプリケーションレベル リソースとシステムレベル リソースが自動的にコンフィグレーションされて、1 つのサーバに置かれます。開発にこのコンフィグレーションを使用する際の考慮事項は以下のとおりです。

• このドメインは、コンフィグレーション ウィザードでエクスプレス モードを使用して作成する。これは、ドメインを作成する最も簡単かつ迅速な方法であり、開発環境に理想的です。エクスプレス モードでは、コンフィグレーション テンプレートのデフォルト設定が使用されます。このモードでは、ドメインの作成中にテンプレートの設定 (サーバのポート番号など) を変更することができないことに注意してください。
• このドメインのサーバでは、WebLogic Platform でサポートされている全種類 (つまり WebLogic Server、WebLogic Workshop、WebLogic Integration、および WebLogic Portal) のアプリケーションを実行するために必要なすべてのリソースがコンフィグレーションされる。
• このドメインは、開発モードで実行するようにコンフィグレーションされる。開発モードは、以下の点でプロダクション モードと異なります。
• デモ セキュリティ証明書の使用が有効である。
• WebLogic Server インスタンスがアプリケーションを自動的にデプロイメントおよび更新する。
• デフォルトで、制限された数のシステムレベルのリソースを使用できる。

開発モードで作成されたドメインでのリソースのコンフィグレーション方法に関する詳細については、以下の URL にある『コンフィグレーション ウィザードの使い方』の「新規 WebLogic ドメインの作成」の「コンフィグレーションの起動モードの相違点」を参照してください。

http://edocs.beasys.co.jp/e-docs/platform/docs81/confgwiz/newdom.html

• すべてのセキュリティ データが WebLogic 組み込み LDAP サーバに格納される。ドメインのアクセスはデフォルトで信頼されています。
• このコンフィグレーションは、プロダクション環境には推奨されない。すべてのシステムおよびアプリケーション コンポーネントが 1 つのマシンに存在するため、マシンに障害が発生するとシステム全体に障害が発生します。

単一クラスタ Platform ドメインの例

単一クラスタ WebLogic Platform ドメイン環境を以下の図に示します。

図 2-3 単一クラスタ Platform ドメインの例

 

例で示されたコンポーネント

図 2-3 で示されたプロダクション環境には、以下の特徴があります。

• このコンフィグレーションのドメインは、Basic WebLogic Platform Domain テンプレートに基づく。
• このドメインは、4 つの管理対象サーバから構成される単一クラスタを持つ。
• 2 つの管理対象サーバが最初のマシンに割り当てられ、残りの 2 つの管理対象サーバが 2 つ目のマシンに割り当てられる。
• クラスタ内の各マシンには、WebLogic Platform がインストールされている。また、各マシンにはノード マネージャがコンフィグレーションされている。
• 各管理対象サーバ インスタンスは、以下の 3 つのアプリケーションをホストする。
• WebLogic Portal アプリケーション (PortApp として示されています)
• WebLogic Integration アプリケーション (IntApp として示されています)
• WebLogic Platform アプリケーション (PlatApp として示されています)

これらの各アプリケーションは、EAR ファイルとしてデプロイされます。つまり、各アプリケーションは、個別のデプロイメント ユニットとして存在します。

• また、各管理対象サーバ インスタンスは、WebLogic Administration Portal、WebLogic Portal 管理ツール、および Datasync Web アプリケーションもホストする。これらのシステムレベルのリソースの集合は、Portal Console と示されます。
• 管理サーバは 3 つ目のマシンに割り当てられ、以下のものをホストする。
• WebLogic Server ドメイン管理インフラストラクチャ。WebLogic Server Administration Console が含まれ、WLS Console として示されています。
• WebLogic Administration Portal、WebLogic Portal 管理ツール、および Datasync Web アプリケーション。Portal Console として示されています。
• WebLogic Integration Administration Console、他の WebLogic Integration 管理 EJB と Web アプリケーション、起動/停止クラス、およびコンフィグレーション キューとトピック。WLI Console として示されています。
• また、WebLogic Portal アプリケーションは、通常管理サーバにデプロイされ、PortApp として示されているが、クライアント リクエストを処理するためではなく、ドメイン全体に WebLogic Portal データを伝播するために使用される。
• ロード バランサ/プロキシ サーバは、クライアント リクエストをクラスタ内の利用可能なサーバに振り分ける。このコンポーネントを使用することは、クラスタにデプロイされているアプリケーションへのクライアント リクエストを処理するために必要ですが、プロダクション システムでの利用に対しても重要です。
• クラスタのアプリケーションには、ロード バランサ/プロキシがホストされているマシンの IP アドレスによって外部的にアクセスする。したがって、クライアント アプリケーションはアプリケーションがホストされている特定のマシンのアドレスを直接公開しません。これはセキュリティの観点から非常に望ましいことです。
• ロード バランサ/プロキシを使用すると、管理サーバへの外部からのアクセスを防ぐことができるため、セキュリティが向上する。
• バランサ/プロキシにより、クライアント セッション情報インメモリ レプリケーションを使用できる。これは可用性の観点から非常に望ましいことです。サーバがホストされているマシンに障害が発生した場合は、実行されている他のサーバ インスタンスでクライアント セッションを再確立できます。
• 管理対象サーバにホストされているアプリケーションにクライアントがアクセスする方法に影響を与えずに、管理対象サーバをクラスタに追加できる。
• RDBMS はスタンドアロン マシンにホストされる。

このコンフィグレーションに関する考慮事項

ドメインに複数のマシンとサーバを組み込むことにより、プロダクション システムで必要な WebLogic Platform の可用性機能と信頼性機能を有効にすることができます。たとえば、クラスタをコンフィグレーションすることにより、複数のサーバで類似機能を実行できます。クラスタのどのサーバでも、特定のクライアントからのリクエストを処理できます。また、クラスタでは、ロード バランシングがサーバ間に自動的に設定されます。

このコンフィグレーションに関する以下の考慮事項に注意してください。

• このドメインは、コンフィグレーション ウィザードまたは WebLogic Scripting Tool (WLST) Offline のいずれかを使用して作成できる。この例のようなドメインを作成する場合は、コンフィグレーション ウィザードでエクスプレス モードを使用できません。代わりに、カスタム モードを使用して、このコンフィグレーションに必要なクラスタと他のリソースをコンフィグレーションする必要があります。

WLST Offline を使用して単一クラスタ プロダクション ドメインを作成する例については、「例 : WLST Offline を使用して、単一クラスタ Platform ドメインをコンフィグレーションする方法」を参照してください。

• この単一ドメイン コンフィグレーションは、プロダクション環境の WebLogic Platform アプリケーションに対する最も単純なコンフィグレーションである。WebLogic Workshop でコントロールを使用すると、アプリケーション開発と、アプリケーション内リクエストおよび応答を簡略化できます。ポータル、ビジネス プロセスを同じ EAR ファイルに格納すると、デプロイメントが簡略化されます。また、WebLogic Platform の複数の個別コンポーネントには、単一クラスタ環境の設計および開発のベスト プラクティスを示す同じアプリケーションが含まれます。

ただし、このコンフィグレーションでは、WebLogic Integration Web アプリケーションと EJB がクラスタを対象とし、WebLogic Portal EJB と Administration Portal が管理サーバとクラスタの両方を対象とするように、個々のアプリケーション モジュールを対象とする必要があります。

WebLogic Platform アプリケーションでのアプリケーション モジュールの割り当てに関する考慮事項については、「アプリケーションの割り当て」を参照してください。

• 管理サーバではクライアント アプリケーション リクエストを処理しない。したがって、通常、アプリケーションはクラスタのみを対象とする必要があります。この結果、管理サーバは、ドメインにデプロイされたアプリケーションのクライアントに外部的に公開されません。この例外は、WebLogic Portal アプリケーションです (以下で説明)。

また、管理サーバは、WebLogic Platform アプリケーションをサポートするために常に実行されている必要があります。

• WebLogic Portal アプリケーションは管理サーバとクラスタにデプロイされ、ポータル アプリケーションのカスタマイズと他の動的な更新がドメイン全体におけるアプリケーションのデプロイされたすべてのインスタンスに伝播される。ただし、ロード バランサ/プロキシを介して外部クライアントからアクセスできるのは、クラスタにデプロイされたアプリケーションのインスタンスだけです。

WebLogic Portal アプリケーションのファイルには、以下のような複数のシステムレベルの EJB、JAR ファイル、Web アプリケーション、および Web サービスが含まれています。

• WebLogic Administration Portal
• Datasync Web アプリケーション
• コンテンツ管理
• パーソナライゼーション
• パイプライン サービスまたはコマース サービス (インストールされている場合)

これらのコンポーネントは、アプリケーションの作成時に WebLogic Workshop IDE によってアプリケーション プロジェクト ディレクトリ ツリーに自動的にコピーされます。通常、EAR ファイルはドメイン内のすべてのサーバにデプロイします。ただし、クラスタのみを WebLogic Portal アプリケーションの対象としたり、管理サーバのみを Administration Portal および他の管理コンポーネントの対象としたりすることができます。

• 「WebLogic Platform ドメインのコンフィグレーションに関する考慮事項」に記載されているように、WebLogic Workshop で作成し、Web サービスに非同期要求を行う Web アプリケーション プロジェクトには、非同期キューと非同期エラー キューが作成される。このキューに対して、クラスタ上の対応する分散 JMS キューのペアを作成する必要があります。これらのキューの名前は、WebLogic Workshop で各 EAR ファイルと共に提供される wlw-manifest.xml ファイルに指定されます。これらの分散キューの作成については、「WebLogic Workshop ランタイムで必要なアプリケーション リソースの追加」を参照してください。
• プロダクション環境では、ドメインに WebLogic Platform でサポートされたエンタープライズレベルの RDBMS によって管理されているデータベースをコンフィグレーションする必要がある。このデータベースは、WebLogic Platform またはそのいずれかのコンポーネントがインストールされているマシンには存在しません。

対象環境に対してデータベースをコンフィグレーションするには、以下を含む複数の手順を実行する必要があります。

• データベースを作成および準備する。
• WebLogic Integration および WebLogic Portal データベース スキーマをプロモートする。

データベースのコンフィグレーションについては、「プロダクション データベースのコンフィグレーション」を参照してください。この章では、WLST を使用して WebLogic Portal および WebLogic Integration データベース スキーマをロードする例を示します。

• セキュリティに関する考慮事項を以下に示す。
• プロダクション環境で、管理対象サーバをホストするマシンとは別のマシンに管理サーバを常に置くことにより、潜在的な攻撃からドメイン インフラストラクチャを保護し、クラスタに管理サーバを含めない。前述したように、管理サーバをアプリケーションの対象にしないでください (記載されているとおり、WebLogic Portal アプリケーションを除く)。
• デフォルトでは、ユーザおよびグループ情報は、組み込み LDAP サーバに格納される。これは、開発、システム統合、テスト、および他のプロダクション前のドメイン環境に最適です。WebLogic Security Service を使用すると、アプリケーションやセキュリティ プロバイダのコンフィグレーションを含むドメイン リソースに設定されたポリシーなどのセキュリティ情報を、あるデプロイメント環境から簡単にエクスポートし、別のデプロイメント環境に簡単にインポートできます。詳細については、「対象データベースへの組み込み LDAP セキュリティ データのプロモート」を参照してください。

ただし、企業内のプロダクション環境では、ユーザおよびグループ情報は通常、企業が使用する LDAP サーバに格納されます。したがって、アプリケーションをプロダクション環境にプロモートするときに、セキュリティ プロバイダに外部 LDAP サーバをコンフィグレーションすることが重要になります。外部 LDAP サーバの使用については、『WebLogic Platform 8.1 のセキュリティ』の「ユーザ情報のための外部データ ストアの使用」を参照してください。

• ドメイン作成時に、JMS が JDBC ストアを使用するようにコンフィグレーションされている場合は、JMS などの WebLogic Server サブシステムに対して動的にテーブルが作成される。管理者には、必要に応じてテーブルを更新できる、データベースに対するアクセス権が付与されている必要があります。したがって、ドメインのコンフィグレーション時には、適切なデータベース アクセス権が付与されるようにしてください。
• WebLogic Platform が複数の認証プロバイダの使用をサポートすることに注意する。WebLogic Server での複数の認証プロバイダのコンフィグレーションについては、『WebLogic Security の管理』の「セキュリティ プロバイダのコンフィグレーション」を参照してください。WebLogic Administration Portal における複数の認証プロバイダの管理については、「WebLogic Portal で複数の認証プロバイダを使用する」を参照してください。WebLogic Portal アプリケーション開発における複数の認証プロバイダの使用については、「WebLogic Portal で複数の認証プロバイダを使用する」を参照してください。
• プロダクション ドメインのコンフィグレーション時に、管理対象サーバにデプロイされたアプリケーションが SSL ベースのリクエストのみを受け取るように各管理対象サーバで SSL をコンフィグレーションできる。ただし、環境によっては、デフォルトで管理対象サーバ全体に対して SSL を有効にするために必要なオーバヘッドを節約するために、管理対象サーバ全体に対してではなくロード バランサで SSL を有効にするか、アプリケーション レベルで SSL を有効にする方が望ましいことがあります。

アプリケーションが SSL ベースのリクエストのみを受け取るように、または認証されたユーザのみがアクセスできるようにアプリケーションのデプロイメント記述子を変更する方法については、「アプリケーション セキュリティの準備」を参照してください。

• ロード バランサ/プロキシを使用する場合はセッション レプリケーションについて考慮する。ロード バランサ/プロキシのコンフィグレーションについては、「ロード バランサと Web プロキシ サーバの使用」を参照してください。

非クラスタ化された環境からクラスタ化された環境にアプリケーションをプロモートする場合は、他のアプリケーションへのアクセスについて考慮する必要があります。クライアントは、他のアプリケーションに直接アクセスする代わりに、バランサ/プロキシを介してアクセスする必要があります。アプリケーション ファイルを変更してロード バランサを介するアクセスを有効にする方法については、「アプリケーション間の通信の有効化」を参照してください。

マルチドメインの例

疎結合のマルチドメイン プロダクション環境を以下の図に示します。

図 2-4 マルチドメインの例

 

例で示されたコンポーネント

図 2-4 で示されているプロダクション システムには以下の特徴があります。

• WebLogic Portal ドメインが Basic WebLogic Portal Domain テンプレートに基づいて作成される。このドメインには以下のものが含まれます。
• 2 つのマシンにホストされているクラスタ
• 2 つの管理対象サーバをホストするクラスタ内の各マシン
• 1 つの WebLogic Portal アプリケーションをホストする各管理対象サーバ
• WebLogic Portal アプリケーション、Administration Portal、Datasync Web アプリケーション、WebLogic Portal システム EJB、および Web サービスをホストする管理サーバ

各管理対象サーバと管理サーバは、複数の WebLogic Portal アプリケーションをホストできます。管理サーバは、1 つの WebLogic Portal アプリケーションのみをホストするように制約されていません。

• WebLogic Integration ドメインが Basic WebLogic Integration Domain テンプレートに基づいて作成される。このドメインには以下のものが含まれます。
• 2 つのマシンにホストされているクラスタ
• 2 つの管理対象サーバをホストするクラスタ内の各マシン
• 1 つの WebLogic Integration アプリケーションをホストする各管理対象サーバ
• WebLogic Integration 管理 Web アプリケーション、WebLogic Integration システム EJB、および他のシステム コンポーネントをホストする管理サーバ
• 各クラスタは、リクエストを処理するロード バランサ/プロキシを持つ。
• データベースは両方のドメインによって共有される。

このコンフィグレーションに関する考慮事項

マルチドメイン プロダクション システムに関する考慮事項は以下のとおりです。

• WebLogic Portal ドメインが WebLogic Integration ドメインのアプリケーションおよびリソースに対するアクセス ポイントとして使用される場合に、このコンフィグレーションが適切である。この疎結合のコンフィグレーションにより、以下のように個々のアプリケーションの規模を必要に応じて調整できます。
• ポータルの規模は、WebLogic Integration アプリケーションの要件に関係なく幅広く調整できる。たとえば、アプリケーションがデプロイされる小規模マシンの数を増やすことによってパフォーマンスを最適化できます。
• WebLogic Integration アプリケーションに、少ない数の強力なマシンが必要となる。

WLST Offline を使用してこのドメインを作成する例については、「例 : WLST Offline を使用して、マルチドメイン環境をコンフィグレーションする方法」を参照してください。

コンフィグレーション ウィザードをサイレント モードで使用してこのドメインを作成する例については、「例 : サイレント モードでコンフィグレーション ウィザードを使用して、マルチドメイン環境をコンフィグレーションする方法」を参照してください。

• このコンフィグレーションによってアプリケーション タイプがより明確に区別されるようになり、開発タスク、コンフィグレーション タスク、およびデプロイメント タスクが簡素化される。ただし、アプリケーションが異なるドメインにデプロイされるため、WebLogic Portal と WebLogic Integration コンポーネント間の対話が複雑になります。たとえば、ビジネス プロセスを呼び出すために JPD プロキシまたは Web サービス インタフェースを使用する必要があります。
• 「このコンフィグレーションに関する考慮事項」の単一クラスタの例で示されているセキュリティに関する考慮事項は、マルチドメインの例にも適用される。プロダクション環境では、両方のドメインで中央 LDAP サーバのユーザ情報がコンフィグレーションされている必要があります。ただし、ユーザ情報がいずれかのドメインの組み込み LDAP サーバに維持されている場合は、ドメイン間での ID の伝播と資格情報の受け渡しがより複雑になります。
• WebLogic Portal と WebLogic Integration はデータベース スキーマを共有しないため、1 つのデータベースを問題なく共有できる。
• ドメイン間の通信に関する考慮事項を以下に示す。
• 2 つのドメイン間の RMI トラフィックに対して信頼を有効にする必要がある。
• アプリケーションが Web サービスを使用している場合に双方向 SSL を有効にすることを考慮する。
• メッセージング ブリッジまたは外部 JMS サーバなどを介する非同期通信のために JMS を使用する。
• ドメイン コンフィグレーションおよびアプリケーション デプロイメントが簡素化される。ただし、各ドメインは個別に管理する必要がある。

マルチ クラスタ Platform ドメインの例

WebLogic Integration および WebLogic Portal アプリケーションが同じドメインの異なるクラスタにデプロイされるマルチ クラスタ ドメインを作成できます。このコンフィグレーションを以下の図に示します。

図 2-5 マルチ クラスタ Platform ドメインの例

 

例で示されたコンポーネント

図 2-5 で示されているプロダクション システムには以下の特徴があります。

• 2 つのクラスタがドメインでコンフィグレーションされている。一方は WebLogic Integration アプリケーションを対象としたクラスタであり、もう一方は WebLogic Portal アプリケーションを対象としたクラスタです。
• 各クラスタは 2 つのマシンから構成される。各マシンにはノード マネージャがコンフィグレーションされています。
• クラスタ内の各マシンが 2 つの管理対象サーバをホストする。
• 各クラスタの各管理対象サーバが 1 つのアプリケーションをホストする。
• この例で示されているドメインは、カスタム WebLogic Platform ドメインである。ドメインには 1 つの WebLogic Integration クラスタしか含めることができないため、このドメイン内のすべての管理対象サーバが同じというわけではありません。ポータル クラスタ内の管理対象サーバには、WebLogic Integration アプリケーションを実行するために必要なリソースがコンフィグレーションされていません。
• このドメインでは、1 つのマシンが管理サーバをホストしている。管理サーバは以下のものを対象にしています。
• WebLogic Server ドメイン管理インフラストラクチャ
• WebLogic Portal アプリケーション、Administration Portal、Datasync Web アプリケーション、WebLogic Portal システム EJB、および Web サービス
• WebLogic Integration 管理 EJB、Web アプリケーション、起動クラス/停止クラス、コンフィグレーション キュー、およびトピック

コンフィグレーションに関する考慮事項

マルチ クラスタ ドメインのコンフィグレーションに関する考慮事項は以下のとおりです。

• 「マルチドメインの例」に記載されているように、WebLogic Integration クラスタを WebLogic Portal クラスタから切り離すと、各アプリケーションの規模を個別に調整できる。
• 単一ドメイン コンフィグレーションでは以下のことが可能である。
• アプリケーションとリソースの一元的な管理
• アプリケーション間のメッセージの簡素化。「マルチドメインの例」に記載されているように、メッセージング ブリッジまたは外部 JMS サーバは必要ありません。
• このコンフィグレーションの利点は以下のとおりである。
• WebLogic Portal アプリケーション クラスタを統合して、WebLogic Integration アプリケーションとは関係なくアプリケーション クラスタの規模を調整できる。これにより、他のアプリケーションが利用できなくなった場合や断続的にしか利用できない場合に 1 つのアプリケーションが稼働し続けるため、ロード バランシングや信頼性が向上します。
• アプリケーションとアプリケーションをサポートする WebLogic Platform リソースのサイズは小さいので、管理対象サーバをホストするマシンはそれほど大量にメモリを必要としない。このため、各サーバが実行する機能を細かく調整できます。
• WebLogic Integration アプリケーションを含むマルチクラスタ ドメインの作成は複雑であるが、複数の方法で実行できる。このコンフィグレーションを作成する例については、「例 : WLST Offline を使用して、マルチ クラスタ Platform ドメインをコンフィグレーションする方法」を参照してください。WLST Offline を使用して自動化できる手順もありますが、一部の手順は手動で実行する必要があります。この例で使用された手順の概要を以下に示します。
WLST Offline では、ドメインは Basic WebLogic Platform Domain テンプレートを使用して作成されます。
WebLogic Integration 用と WebLogic Portal 用の 2 つのクラスタがコンフィグレーションされます。
4 つのマシンがコンフィグレーションされます。2 つは WebLogic Integration クラスタに割り当てられ、残りの 2 つは WebLogic Portal クラスタに割り当てられます。
JMS JDBC ストアは、WebLogic Portal クラスタ用にコンフィグレーションされます。
システム リソースと、各クラスタの WebLogic サービスの対象が手動で再割り当てされます。WebLogic Portal リソースは WebLogic Integration クラスタから割り当て解除され、WebLogic Integration リソースは WebLogic Portal クラスタから割り当て解除されます。
アプリケーションの対象が修正されます。最初に、すべてのアプリケーションが、管理サーバ、WebLogic Integration クラスタで割り当てられた最初の管理対象サーバ、および両方のクラスタから割り当て解除される。次に、各アプリケーションが正しい対象に割り当てられます。
WebLogic Portal クラスタの JMS リソースを作成するために、ドメイン config.xml ファイルが手動で修正されます。
• 前述した単一ドメインとマルチドメインのコンフィグレーション例で説明したように、wlw-manifest.xml ファイルの内容に基づいてリソースを作成する必要がある。ただし、各クラスタで作成するリソース同士を区別する必要があります。
• このコンフィグレーションでは、各クラスタにロード バランサ/プロキシが必要である。
• 前述した 2 つのコンフィグレーション例で説明したセキュリティに関する考慮事項は、マルチ クラスタのコンフィグレーションに適用される。ユーザ情報は、組み込み LDAP サーバまたは外部 LDAP サーバに格納できます。両方のクラスタではドメインのセキュリティ コンフィグレーションを簡単に使用できます。
• クラスタ間の通信は、信頼性のある JMS 転送、MQ Series (メッセージング ブリッジが必要な場合)、コントロールからの呼び出しなどのメッセージングを介して実装される。このコンフィグレーションでは、アプリケーションと、システムレベルの JMS および JDBC リソースを正確に対象とする必要があります。アプリケーションが Web サービスを使用している場合は、双方向 SSL を有効にすることを考慮してください。