|
|
以下の節では、Oracle WebLogic Integration (WLI) をクラスタ化環境でコンフィグレーションおよびデプロイする方法について説明します。内容は以下のとおりです。
アプリケーションのデプロイの詳細については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。
クラスタ化によって、WLI をサーバのグループで実行でき、そのグループを単体ユニットとして管理できます。クラスタ環境では、複数のマシンが負荷を分担します。WLI にはロード バランシング機能があるので、リソース要求はすべてのマシンに均等に分散されます。WLI デプロイメントは、クラスタ化とロード バランシングを使用してノード間にワークロードを分散させることにより、スケーラビリティを向上できます。クラスタ化により、単一サーバよりもスケーラビリティの高いデプロイメント プラットフォームを構築できます。
WLI クラスタのドメインは、1 台の管理サーバと、1 つまたは複数の管理対象サーバで構成されます。WLI ドメインの管理対象サーバはクラスタにまとめることができます。WLI のクラスタ対応リソースをコンフィグレーションする場合、通常はそのリソースのデプロイ対象とするクラスタを指名します。クラスタをリソース デプロイメントの対象として指定すると、管理対象サーバをクラスタに追加することによって能力を動的に増大できるという利点が得られます。
| 注意 : | WLI ドメインは複数のクラスタをサポートすることができます。ただし、WLI のシステム リソースおよびアプリケーションは、複数のクラスタで構成されるドメイン内の 1 つの WLI クラスタを対象とする必要があります。 |
ここでは、クラスタ環境で WLI をコンフィグレーションする場合に必要な情報について説明します。WLI でサポートしているクラスタ化についての予備的な情報も含まれていますが、主に、クラスタ化環境で WLI をコンフィグレーションする手順を説明します。
読み進む前に、以下の Oracle WebLogic Server マニュアルの節の内容を確認し、クラスタ化について十分に理解しておくことをお勧めします。
以下の節では、クラスタ デプロイメントの設計に必要な情報について説明します。
クラスタ化されたドメインに合わせてアーキテクチャを設計する前に、Oracle WebLogic Server クラスタがどのように運用されるかを知っておく必要があります。
ドメインとクラスタの作成は、Configuration Wizard を使用して基本および拡張ドメイン テンプレートからドメインを生成することにより、簡単に実行できます。ユーザのクエリに対する応答を基に、Configuration Wizard によって、ドメイン、サーバ、エンタープライズ アプリケーションなどが、コンフィグレーション済みの適切なコンポーネントおよび資産を含めて生成されます。さまざまなドメインに使用可能なテンプレートの詳細については、「ドメイン テンプレート リファレンス」を参照してください。
Configuration Wizard で作成するドメインには、WLI のシステム コンポーネントとアプリケーションを含むデプロイ対象が 1 つだけ存在している必要があります。この対象は、wli-config.properties で weblogic.wli.WliClusterName の値を設定することによって指定できます。weblogic.wli.WliClusterName の値を指定しない場合は、デフォルトにより、WLI の対象は最初の WLI クラスタになります。wli-config.properties ファイルの詳細については、「wli-config.properties コンフィグレーション ファイル」を参照してください。
サーバには管理対象サーバと管理サーバがあります。管理サービスを実行している Oracle WebLogic Server は管理サーバと呼ばれ、Oracle WebLogic Server Administration Console のホストとなります。複数の Oracle WebLogic Server が稼働しているドメインでは、そのうち 1 つのみが管理サーバで、他のサーバは管理対象サーバと呼ばれます。各管理対象サーバは、起動時に管理サーバからコンフィグレーションを取得します。
Oracle WebLogic クラスタの詳細については、Oracle WebLogic Server ドキュメントの『クラスタの使用』を参照してください。このドキュメントでは、推奨される基本、多層、およびプロキシ アーキテクチャの詳細について説明されています。Oracle WebLogic クラスタ設計のセキュリティに関する考慮事項については、『クラスタの使用』の「クラスタ アーキテクチャ」に記載されている「クラスタ アーキテクチャのセキュリティ オプション」を参照してください。
Oracle WebLogic Integration ドメインにあるすべての管理対象サーバは、Oracle WebLogic Integration クラスタの一部である必要があります。管理対象サーバはスタンドアロンにはなれません。
Oracle WebLogic Server の管理ドメインがクラスタ ドメインとは別のものである場合 (Oracle WebLogic Server クラスタが別の管理ドメインに属するノードを持つ場合) もありますが、WLI デプロイメントの場合は、クラスタ ドメインが管理ドメインおよびセキュリティ ドメインとなるように設計する必要があります。
クラスタ化されたドメインの各サーバに対して、そのドメイン内のサーバの機能を定義するさまざまな属性をコンフィグレーションできます。これらの属性は、Configuration Wizard で WLI ドメインを作成すると、自動的にコンフィグレーションされます。また、Oracle WebLogic Server Administration Console の [サーバ] ノードを使用して手動でコンフィグレーションすることもできます。
| 注意 : | WLI アプリケーションはクラスタ全体にデプロイする必要があります。つまり、クラスタ内の一部の管理対象サーバにのみデプロイすることはできません。 |
WLI デプロイメントのコンフィグレーション可能なリソースの一覧については、「Oracle WebLogic Integration デプロイメントのリソース」を参照してください。ここでは、クラスタ化された WLI ドメインの各リソースのデフォルト ターゲットについて説明し、Oracle WebLogic Server Administration Console での各リソースへの移動方法を示しています。
この節では、以下の WLI 追加デプロイメントでのコンフィグレーション要件に関するトピックを取り上げます。
システムによるメッセージ処理が開始される前にすべての WLI アプリケーション コンポーネントをデプロイすることが大切です。これを確実に行うために、WLI をデプロイするときには TwoPhase 属性を指定します。サンプルの config.xml ファイルからの次の抜粋は、WLI の 2 段階デプロイメントを指定する Application 要素を示しています。
<Domain Name="MyCluster">
...
<Application Name="WebLogic Integration" Path="WL_HOME/lib"
TwoPhase="true">
...
Trading Partner Integration のコンポーネントは、クラスタに均一にデプロイする必要があります。冗長化されていない箇所をなくすために、Trading Partner Integration のリソースを各管理対象サーバへまったく同じようにコンフィグレーションします。
Trading Partner Integration をクラスタにコンフィグレーションする場合、以下の点に留意する必要があります。
クラスタのコンフィグレーションを変更できるのは (たとえば、クラスタへの新しいノードの追加や Trading Partner Integration コンフィグレーションの変更など)、その管理サーバがアクティブな場合のみです。
あるクラスタの管理サーバが使用できなくなると、デプロイ要求やアンデプロイ要求は中断されますが、管理対象サーバは要求の処理を続行します。管理対象サーバは、必要なコンフィグレーション ファイル (msi-config.xml および SerializedSystemIni.dat) およびオプションの boot.properties が各管理対象サーバのルート ディレクトリに存在する限り、既存のコンフィグレーションを使用して起動および再起動することができます。
管理サーバなしで起動する管理対象サーバは、管理対象サーバ独立 (MSI) モードで稼働します。MSI モードの詳細については、『サーバの起動と停止の管理』の「管理対象サーバ独立モード」を参照してください。
WLI アプリケーションをクラスタ化する目的の 1 つは、スケーラビリティの実現です。クラスタをスケーラブルなものにするには、各サーバを十分に活用する必要があります。ロード バランシングにより、クラスタ内のすべてのサーバ間で負荷が均等に分散され、各サーバがそれぞれ最大能力で動作できるようになります。以下の節では、さまざまな機能分野についての、WLI クラスタでのロード バランシングについて説明します。
詳細については、『クラスタの使用』の「クラスタでのロード バランシング」を参照してください。
Web サービス (SOAP over HTTP または XML over HTTP) と Oracle WebLogic Trading Partner Integration プロトコルでは、HTTP ロード バランシングを使用できます。外部ロード バランシングは、WebLogic HttpClusterServlet、WebServer プラグイン、またはハードウェア ルータによって実現できます。
Oracle WebLogic Server は、HTTP セッション ステートおよびクラスタ オブジェクトのロード バランシングをサポートしています。詳細については、『クラスタの使用』の「クラスタでの通信」を参照してください。
WLI または WLI アプリケーションで使用されるほとんどの JMS キューは、分散送り先としてコンフィグレーションされます。この例外は、1 台の管理対象サーバを送り先としている JMS キューです。
JMS ロード バランシングの詳細については、「WebLogic JMS のチューニング」の分散送り先のチューニングに関する説明を参照してください。
WLI ソリューションに同期クライアントと非同期ビジネス プロセスとの通信が含まれる場合、weblogic.jws.jms.QueueConnectionFactory のサーバ アフィニティを有効にする必要があります。これがデフォルトの設定です。
| 警告 : | 同期クライアントと非同期ビジネス プロセスとの通信機能を持つソリューションのサーバ アフィニティを無効にして JMS ロード バランシングを試行した場合の動作は予測できません。 |
RDBMS イベント ジェネレータには専用の JMS 接続ファクトリ (wli.internal.egrdbms.XAQueueConnectionFactory) があります。この接続ファクトリのロード バランシングはデフォルトで有効になっています。RDBMS イベントのロード バランシングを無効にするには、wli.internal.egrdbms.XAQueueConnectionFactory のロード バランシングを無効にし、サーバ アフィニティを有効にする必要があります。
Oracle Workshop for WebLogic アプリケーションから EAR ファイルを作成したら、アプリケーションをプロダクション環境にデプロイします。プロセス アプリケーションは、Web サービス アプリケーションと同じ手順でデプロイできます。
WLI アプリケーションをクラスタにデプロイする場合、以下の点に留意する必要があります。
wlw-manifest.xml のキューを JMS 分散キューとしてコンフィグレーションすることが推奨される。 wlw-manifest.xml で参照している会話状態要素ごとにデータベース テーブルを作成する必要がある。
アプリケーション デプロイメントの概要については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。
WLI のイベント ジェネレータ (電子メール、ファイル、HTTP、JMS、MQSeries、RDBMS、タイマー) は、Oracle WebLogic Integration Administration Console を使用してデプロイできます。Oracle WebLogic Integration Administration Console を使用してイベント ジェネレータをデプロイする方法については、『WebLogic Integration Administration Console の使用』の「イベント ジェネレータ」に記載されている「イベント ジェネレータの作成およびデプロイメント」を参照してください。
イベント ジェネレータを WebLogic Scripting Tool (WLST) でデプロイすることもできます。以下の 3 つの WLST スクリプトは、イベント ジェネレータを作成、デプロイ、およびコンフィグレーションする方法を示しています。
WLST スクリプトの次の抜粋は、JMS イベント ジェネレータの作成方法を示しています。
import com.bea.wli.mbconnector.jms as eggen
…
eggen.JmsConnGenerator.main([
"-inName", “myEgName”,
"-outfile", “mydomain/myEgName.jar",
"-destJNDIName", “myQueueName”,])
イベント ジェネレータを作成したら、次の例のようなスクリプトで適切なターゲットにデプロイできます。
wlst.deploy( "WLIJmsEG_myEgName”, “mydomain/myEgName.jar", myServer )
デプロイしたイベント ジェネレータのプロパティをコンフィグレーションするには、以下の例のようなスクリプトを使用します。
import com.bea.wli.management.configuration as wlicfg
…
# Must have wli.jar in classpath
egCfgMBean = wlst.getTarget("JMSEventGenerators/JMSEventGenerators")
egMBean = egCfgMBean.newJMSEventGenConfigurationMBean( “myEgName”)
cData = jarray.zeros( 1, wlicfg.JMSEventGenChannelConfiguration )
cData[0] = wlicfg.JMSEventGenChannelConfiguration()
cData[0].setChannel( “myChannel” )
cData[0].setComment("Default channel")
egMBean.setChannels(cData);
以下の節では、イベント ジェネレータの補足情報について説明します。
電子メール、ファイル、タイマーの各イベント ジェネレータでは、クラスタを対象にしないでください。これらのジェネレータは、特定のイベント ジェネレータ (たとえば、電子メール イベント ジェネレータの wli.internal.egmail.queue) に関連付けられたキューによって移行可能なサーバを含んだ管理対象サーバ上でアクティブになります。
以下の節では、JMS イベント ジェネレータをデプロイするときに考慮する必要がある対象指定とエラー処理の問題について説明します。
次の表で示すように、JMS イベント ジェネレータは、JMS イベント ジェネレータの送り先 JNDI 名に応じて対象に割り当てる必要があります。
JMS イベント ジェネレータに明示的なエラー処理メカニズムはありません。エラー処理は、JMS イベント ジェネレータ キューをエラー キューに関連付けることによって提供されます。
| 注意 : | JMS エラー キューの [再配信の制限] に、環境に応じた実際的なメッセージ数を設定することが重要です。デフォルトでは、JMS キューのエラー メッセージおよび警告の再配信回数は無制限です。 |
| 注意 : | メッセージの [再配信の制限] を設定する方法の詳細については、Oracle WebLogic Server Administration Console オンライン ヘルプの「JMS テンプレート : コンフィグレーション : 再配信」を参照してください。 |
MQSeries イベント ジェネレータは、WebSphere MQ キューのメッセージをポーリングし、メッセージ (メタデータとしての MQMD ヘッダとメッセージのペイロード) をメッセージ ブローカ チャネルにパブリッシュします。コンテンツのフィルタ処理、およびその他の処理条件は、イベント ジェネレータのチャネル ルールで指定します。
HTTP イベント ジェネレータは、HTTP リクエストを受け取り、内容のタイプを調べ、メッセージをメッセージ ブローカ チャネルにパブリッシュするサーブレットです。
RDBMS イベント ジェネレータは、データベース テーブルをポーリングして、追加、削除、または更新された行を確認し、結果をメッセージ ブローカ チャネルにパブリッシュします。また、このイベント ジェネレータを使用すると、データベース テーブルにカスタム クエリを実行し、メッセージ ブローカ チャネルに結果をパブリッシュすることもできます。
クラスタに RDBMS イベント ジェネレータをデプロイする場合、各 RDBMS イベント ジェネレータの JMS キューの [再配信遅延のオーバライド] の値を 20000 (20 秒)、[再配信の制限] の値を -1 (制限なし) に手動で設定する必要があります。クラスタのイベントを生成する前に、これらの再配信の設定をコンフィグレーションする必要があります。
| 警告 : | [再配信遅延のオーバライド] と [再配信の制限] の値をデフォルトのままにしておくと、エラーが発生したときに、ただちに 2 回の再配信が試行されます。2 回目の再配信が失敗すると、メッセージは破棄されます。 |
クラスタ内の RDBMS イベント ジェネレータの JMS キューに再配送の設定をコンフィグレーションするには、次の手順を実行します。
Oracle WebLogic Server Administration Console (必要な場合は管理サーバ) を起動する手順については、「コンソールの起動」を参照してください。
dist_wli.internal.egrdbms.queue_auto_1 ～ n) に対して [再配信] タブを選択し、次の値を入力します。
単一サーバ デプロイメントでは、[再配信遅延のオーバライド] の値を 20000 (20 秒) に設定する必要があります。単一サーバ デプロイメントで [再配信遅延のオーバライド] の値をコンフィグレーションするには、次の手順を実行します。
Oracle WebLogic Server Administration Console (必要な場合は管理サーバ) を起動する手順については、「コンソールの起動」を参照してください。
20000 を入力します。
単一サーバ デプロイメントでは、[再配信の制限] の設定を手動でコンフィグレーションする必要はありません。単一サーバ デプロイメントの [再配信の制限] は、デフォルトで適切な値に設定されています。
  
|