| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1.7.0) B55899-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1.7.0) B55899-09 |
|
前 |
次 |
この章では、トポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップなどがあります。
この章の項目は次のとおりです。
SOAエンタープライズ・デプロイメントを構成したら、この章の情報を使用してトポロジを管理します。
SOAアプリケーションは、様々なコンポーネントで構成されるコンポジットとしてデプロイされます。SOAコンポジット・アプリケーションには次が含まれます。
ルーティングのためのOracle Mediator、オーケストレーションのためのBPELプロセス、オーケストレーションのためのBAMNプロセス(Oracle BAM Suiteがインストールされている場合)、ワークフロー承認のためのヒューマン・タスク、SOAコンポジット・アプリケーションにJavaインタフェースを統合するためのSpring、ビジネス・ルールを使用するためのデシジョン・サービスなどのサービス・コンポーネント。
外部のサービス、アプリケーションおよびテクノロジに対してSOAコンポジット・アプリケーションを接続するバインディング・コンポーネント(サービスと参照)
これらのコンポーネントが、1つのSOAコンポジット・アプリケーションに組み込まれています。この章では、SOAコンポジット・アプリケーションのデプロイのヒントを示します。
SOAコンポジット・アプリケーションの監視の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAコンポジット・アプリケーションの監視に関する項を参照してください。
SOAコンポジット・アプリケーションの管理の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAコンポジット・アプリケーションの監視に関する項を参照してください。
スケール・アップやスケール・アウトなどの方法で、トポロジの拡張が必要になることがあります。スケール・アップとスケール・アウトの違いおよびこれらのタスクの実行方法の詳細は、第16.5項「トポロジのスケールアップ(管理対象サーバーを既存ノードに追加)」および第16.6項「トポロジのスケールアウト(管理対象サーバーを新しいノードに追加)」を参照してください。
構成の変更前後にはトポロジをバックアップします。構成変更後の問題発生に対応するためバックアップしておく必要のあるディレクトリとファイルについては、第16.8項「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」で説明します。
この章では、トポロジの構成後に発生する可能性のある既知の問題の解決方法も示します。
この項では、SOAエンタープライズ・デプロイメントにコンポジットおよびアーティファクトをデプロイする際のヒントを示します。コンポジットのデプロイ方法の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAコンポジット・アプリケーションのデプロイに関する章を参照してください。
特定のサーバー・アドレスへのコンポジットのデプロイ
SOAコンポジットをSOAエンタープライズ・デプロイメント・トポロジにデプロイする場合、ロード・バランサ・アドレス(soa.mycompany.com)にではなく、特定のサーバーのアドレスにデプロイします。ロード・バランサ・アドレスにデプロイするには、デプロイヤ・ノードから外部のロード・バランサ・アドレスへの直接接続が必要になることがあり、その接続のために、システムのファイアウォールで追加ポートを開く必要が生じる場合があります。
B2Bコンソールを使用したアグリーメントのデプロイおよびメタデータのパージとインポート
B2Bの場合、アグリーメントのデプロイおよびメタデータのパージとインポートは、B2BコンソールのGUIから実行してください。コマンド行ユーティリティは使用しません。コマンド行ユーティリティを使用してこれらの操作を実行すると、B2Bシステムで不整合やエラーが発生することがあります。
FODデプロイメントに関するその他の指示
SOA Fusion Order Demoをデプロイする場合は、FODのREADMEファイルで指定されたデプロイ手順を実行した後、次の追加手順を実行します。
earファイルが各ノードにコピーされるように、Webアプリケーションのbuild.xmlファイルのnostageプロパティをfalseに変更します。FOD_dir\CreditCardAuthorization\binおよびFOD_dir\OrderApprovalHumanTask\binのディレクトリにあるbuild.xmlファイルのCreditCardAuthorizationおよびOrderApprvalHumanTaskを編集して次のフィールドを変更します。
<target name="deploy-application">
<wldeploy action="deploy" name="${war.name}"
source="${deploy.ear.source}" library="false"
nostage="false"
user="${wls.user}" password="${wls.password}"
verbose="false" adminurl="${wls.url}"
remote="true" upload="true"
targets="${server.targets}" />
</target>
これを次のように変更します。
<target name="deploy-application">
<wldeploy action="deploy" name="${war.name}"
source="${deploy.ear.source}" library="false"
nostage="true"
user="${wls.user}" password="${wls.password}"
verbose="false" adminurl="${wls.url}"
remote="true" upload="true"
targets="${server.targets}" />
</target>
Webアプリケーションのターゲットを変更して、デプロイが個別のサーバーでなくSOAクラスタにターゲット設定されるようにします。FOD_Dir/binディレクトリにあるFODのbuild.propertiesファイルを編集して、次のフィールドを変更します。
# wls target server (for shiphome set to server_soa, for ADRS use AdminServer) server.targets=SOA_Cluster (the SOA cluster name in your SOA EDG)
JMSシード・テンプレートを変更し、通常の宛先でなく共通分散宛先を使用して、JMSアーティファクトがエンタープライズ・デプロイメントJMSモジュールにターゲット設定するようにします。FOD_DIR\bin\templatesディレクトリにあるcreateJMSResources.seedファイルを編集して、次のフィールドを変更します。
# lookup the SOAJMSModule - it's a system resource
jmsSOASystemResource = lookup("SOAJMSModule","JMSSystemResource")
jmsResource = jmsSOASystemResource.getJMSResource()
cfbean = jmsResource.lookupConnectionFactory('DemoSupplierTopicCF')
if cfbean is None:
print "Creating DemoSupplierTopicCF connection factory"
demoConnectionFactory =
jmsResource.createConnectionFactory('DemoSupplierTopicCF')
demoConnectionFactory.setJNDIName('jms/DemoSupplierTopicCF')
demoConnectionFactory.setSubDeploymentName('SOASubDeployment')
.
topicbean = jmsResource.lookupTopic('DemoSupplierTopic')
if topicbean is None:
print "Creating DemoSupplierTopic jms topic"
demoJMSTopic = jmsResource.createTopic("DemoSupplierTopic")
demoJMSTopic.setJNDIName('jms/DemoSupplierTopic')
demoJMSTopic.setSubDeploymentName('SOASubDeployment')
これを次のように変更します。
jmsSOASystemResource = lookup("SOAJMSModule","JMSSystemResource")
jmsResource = jmsSOASystemResource.getJMSResource()
topicbean=jmsResource.lookupTopic('DemoSupplierTopic_UDD')
if topicbean is None:
print "Creating DemoSupplierTopicC jms topic"
#create a udd - so clustering is automatically working and done
demoJMSTopic = jmsResource.createUniformDistributedTopic("DemoSupplierTopic_UDD")
demoJMSTopic.setJNDIName('@jms.topic.jndi@')
#Replace the subdeployment name with the one that appears in the WLS AdminConsole as listed for the SOAJMSModule
demoJMSTopic.setSubDeploymentName()
else: print "Found DemoSupplierTopic_UDD topic – noop"
すべてのコンポジットがデータベースを頻繁に使用するわけではありませんが、CUBE_INSTANCEおよびMEDIATOR_INSTANCEスキーマにはかなりの量のデータがサービス・エンジンによって生成されます。データベース領域が不足すると、SOAコンポジットが機能しなくなることがあります。
SOAインフラストラクチャ・データベースでスペースを管理する手順は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlコンソール(のダッシュボードなど)でOracle.fabric.common.FabricInvocationExceptionなどの汎用エラーがないか確認します。
SOAサーバーのログで次のようなエラーを検索します。
Error Code: 1691 ... ORA-01691: unable to extend lob segment SOAINFRA.SYS_LOB0000108469C00017$$ by 128 in tablespace SOAINFRA
これらのメッセージは、通常、データ・ファイルの追加や既存のファイルへの領域の追加を必要とする、データベースの領域の問題を示します。SOAデータベース管理者は、領域を追加する際、拡張ポリシーや使用するパラメータを決定する必要があります。
古いコンポジット・インスタンスをパージしてSOAインフラストラクチャ・データベースのサイズを縮小します。このタイプの操作に、Oracle Enterprise Manager Fusion Middleware Controlを使用することはお薦めしません。操作でトランザクション・タイム・アウトが高い確率で発生します。リポジトリ作成ユーティリティには、インスタンスのパージ用に提供されているパッケージがあります。例:
DECLARE
FILTER INSTANCE_FILTER := INSTANCE_FILTER();
MAX_INSTANCES NUMBER;
DELETED_INSTANCES NUMBER;
PURGE_PARTITIONED_DATA BOOLEAN := TRUE;
BEGIN
.
FILTER.COMPOSITE_PARTITION_NAME:='default';
FILTER.COMPOSITE_NAME := 'FlatStructure';
FILTER.COMPOSITE_REVISION := '10.0';
FILTER.STATE := fabric. STATE_UNKNOWN;
FILTER.MIN_CREATED_DATE := to_timestamp('2010-09-07','YYYY-MM-DD');
FILTER.MAX_CREATED_DATE := to_timestamp('2010-09-08','YYYY-MM-DD');
MAX_INSTANCES := 1000;
.
DELETED_INSTANCES := FABRIC.DELETE_COMPOSITE_INSTANCES(
FILTER => FILTER,
MAX_INSTANCES => MAX_INSTANCES,
PURGE_PARTITIONED_DATA => PURGE_PARTITIONED_DATA
);
これによって2010-09-07から2010-09-08の間に作成されたFlatStructureコンポジット(バージョン10)の「UNKNOWN」状態の最初の1000インスタンスが削除されます。提供されるSQLパッケージに含まれている可能性のある操作の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のSOAコンポジット・アプリケーションの管理に関する項を参照してください。正しく消去するには、提供されているスクリプトを常に使用します。composite_dn表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。
UMSドライバの構成情報は、SOAやBAMのクラスタに自動的には伝播されません。UMSドライバの構成をクラスタに伝播する手順は次のとおりです。
UMSドライバの構成を、そのドライバを使用するエンタープライズ・デプロイメント・トポロジ内のすべてのサーバーに適用します。
サーバー移行を使用する場合、サーバーは別のノードのドメイン・ディレクトリに移動します。フェイルオーバー・ノード内でUMSドライバ構成をあらかじめ作成しておきます。UMSドライバの構成ファイルは、次のディレクトリにあります。
ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml
*は、デプロイ中にOracle WebLogic Serverによってランダムに生成されるディレクトリ名を表します。たとえば、3682yqなどです。
フェイルオーバーに備え、強制的にサーバー移行を実行しファイルをソース・ノードからコピーする方法でUMSドライバ構成ファイルを作成します。
たとえば、BAM用のファイルを作成する手順は次のとおりです。
WLS_BAM1のドライバをBAMHOST1内で構成します。
BAMHOST2へのWLS_BAM1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内でUMSドライバ構成用の次のディレクトリ構造を確認します。
cd ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/
(「*」はデプロイメント時にランダムに生成されるディレクトリ名、たとえば「3682yq」を表します)。
ドライバ構成ファイルをBAMHOST1からBAMHOST2にリモート・コピーします。
BAMHOST1> scp ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml
oracle@BAMHOST2:ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/
これらの変更を有効にするため、ドライバを再起動します。
ドライバを再起動する手順は次のとおりです。
Oracle WebLogic管理コンソールにログインします。
ナビゲーション・ツリーの環境ノードを開きます。
「デプロイメント」をクリックします。
ドライバを選択します。
「停止」→「作業完了時」をクリックし、操作を確認します。
ドライバの状態が「準備完了」に変化するまで待ちます(必要に応じて、管理コンソール・ページを更新します)。
再度ドライバを選択し、「起動」→「すべてのリクエストを処理」をクリックして操作を確認します。
ドライバのプロパティが保持されていることを、Oracle Enterprise Manager Fusion Middleware Controlで確認します。
トポロジをスケールアップするときには、Fusion Middlewareコンポーネントを使用して構成されている管理対象サーバーまたはWSM-PMを含む管理対象サーバーを実行するノードがすでに存在します。このノードには、共有記憶域内にWebLogic ServerホームとOracle Fusion Middleware SOAホームが存在します。このような既存のインストール(WebLogic Serverホーム、Oracle Fusion Middlewareホーム、ドメイン・ディレクトリなど)を使用して、新しい管理対象サーバーをWLS_SOAおよびWLS_WSMという名前で作成します。WLSまたはSOAのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
サーバー移行を使用してサーバーのスケール・アップを行う場合は、必要となる容量およびリソース割当てについて計画します。例として、次のシナリオについて考えてみます。
サーバー1がノード1上にあり、このサーバーはノード2上のサーバー2を使用するクラスタ内サーバー移行を使用します。
スケールアップ操作によって、ノード1のクラスタにサーバー3が追加されます。これもサーバー移行を使用します。
このシナリオでは、ノード1またはノード2のいずれかですべてのサーバー(サーバー1、サーバー2、サーバー3および管理サーバー)が実行される恐れがあります。つまり、サーバー移行を使用するすべてのサーバーが1つのノード上(サーバー移行候補マシンの構成で定義される)で実行される最悪のケースに対応できるように、各ノードを十分なリソースで設計する必要があるということです。
|
注意: スケール・アップの手順は、WSM管理対象サーバーにのみ適用されます。 |
SOAトポロジをスケール・アップする手順は次のとおりです。
Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。クローニング元の管理対象サーバーとして選択できるのは、新しい管理対象サーバーを実行するノード上にすでに存在しているサーバーです。
管理対象サーバーのクローンを作成するには:
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
「ロックして編集」をクリックして、クローニングする管理対象サーバー(たとえばWLS_SOA1)を選択します。
「クローンの作成」をクリックします。
新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。ここでは、WLS_SOA1が実行されていたノード1に新しいサーバーを追加します。
以降の手順は、新しいサーバーをSOAHOST1に追加します。このホストではすでにWLS_SOA1が実行されています。
リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを指定します。推奨されているとおりにサーバー移行を使用する場合、サーバーを別のノードに移動できるように仮想IP(浮動IPとも呼ばれる)を指定します。仮想IPは、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。
WLS_WSMサーバーの場合は、第8.6項「Oracle WSMでのJava Object Cacheの構成」で説明されているように、Java Object Cacheの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。同じノード内にある複数のWLS_WSMサーバーが同一の検出ポートを使用できます。第8.6項で説明されている手順をWLS_WSMサーバーごとに繰り返して、サーバー・リストを更新します。
SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。
|
注意: WLS_WSM管理対象サーバーまたはBAM Webアプリケーション・システムをスケール・アップする場合は、新しい管理対象サーバー上でSOAおよびUMSのJMSサーバーを作成する必要はありません。この手順は、WLS_SOA管理対象サーバーをスケール・アップする場合にのみ必要です。 |
SOAおよびUMS用のJMSサーバーを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMS JMSサーバー用の新しい永続ストアを作成し(UMS JMSサーバーの作成方法は後述します)、UMSJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。
SOAおよびUMSのSubDeploymentターゲットを更新して、先ほど作成したJMSサーバーを含めます。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA用: SOAJMSModuleおよびUMS用: UMSSYtemResource)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。
|
注意: このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXXまたはUMSJMSServerXXXXXXのフォームのランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。 |
このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。
新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順については、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。
|
注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。 Dtangosol.coherence.localhost=SOAHOST1VHNn |
管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic
「保存してアクティブ化」をクリックします。
新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAN管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しい管理対象サーバー用のサーバー移行を構成します。Oracle WebLogic Server管理コンソールを使用してサーバー移行を構成する手順は次のとおりです。
|
注意: これはスケールアップ操作であるため、ノードにノード・マネージャが存在していること、およびサーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済であることが必要です。新しいSOA管理対象サーバー用の浮動IPも、すでに存在している必要があります。 |
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で、移行を構成するサーバーの名前(ハイパーリンクとして表示される)をクリックします。選択したサーバーの「設定」ページが表示されます。
「移行」サブタブをクリックします。
「移行の構成」セクションで、移行に参加するサーバーを「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、SOAHOST1(すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。
|
注意: 移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。 |
「サーバーの自動移行を有効化」オプションを選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。
次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。
管理コンソールで、「環境」、「クラスタ」の順に選択します。
「SOA_Cluster」サーバーをクリックします。
SOA_Clusterの設定画面が表示されます。
「ロックして編集」をクリックします。
「クラスタ・アドレス」フィールドに新しいサーバーのアドレスとポートを入力します。例: SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOST1VHN1:8001
変更を保存してアクティブ化します。
この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。
次のコマンドを使用して、WLS_SOAn管理対象サーバーを停止します。
kill -9 pid
ノードのPID (プロセスID)は次のコマンドで特定できます。
ps -ef | grep WLS_SOAn
ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
SOAトポロジをスケール・アップする手順は次のとおりです。
Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。クローニング元の管理対象サーバーとして選択できるのは、新しい管理対象サーバーを実行するノード上にすでに存在しているサーバーです。
管理対象サーバーのクローンを作成するには:
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
「ロックして編集」をクリックして、クローニングする管理対象サーバー(たとえばWLS_SOA1)を選択します。
「クローンの作成」をクリックします。
新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。ここでは、WLS_SOA1が実行されていたノード1に新しいサーバーを追加します。
以降の手順は、新しいサーバーをSOAHOST1に追加します。このホストではすでにWLS_SOA1が実行されています。
リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを指定します。推奨されているとおりにサーバー移行を使用する場合、サーバーを別のノードに移動できるように仮想IP(浮動IPとも呼ばれる)を指定します。仮想IPは、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。
SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。
SOA、UMSおよびBAM用のJMSサーバーを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMS JMSサーバー用の新しい永続ストアを作成し(UMS JMSサーバーの作成方法は後述します)、UMSJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいBAMJMSServerの新しい永続ストアを作成します(たとえば、BAMJMSFileStore_N)。このストアのパスを指定します。第4.3項「各種ディレクトリの推奨場所について」で推奨されているとおり、ディレクトリは共有記憶域上にある必要があります。例:
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: SOAJMSFileStore_Nを新しいBAM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
BAMの新しいJMSサーバーを作成します(たとえば、BAMJMSServer_N)。このJMSServerにはBAMJMSFileStore_Nを使用します。BAMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。
SOA、UMSおよびBAM JMSモジュールのSubDeploymentターゲットを更新して、先ほど作成したJMSサーバーを含めます。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BAM: BAMJMSMOdule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。
|
注意: このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBAMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。 |
このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。「保存してアクティブ化」をクリックします。
新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順については、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。
|
注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。 Dtangosol.coherence.localhost=SOAHOST1VHNn |
管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1
「保存してアクティブ化」をクリックします。
新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAN管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しい管理対象サーバー用のサーバー移行を構成します。Oracle WebLogic Server管理コンソールを使用してサーバー移行を構成する手順は次のとおりです。
|
注意: これはスケールアップ操作であるため、ノードにノード・マネージャが存在していること、およびサーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済であることが必要です。新しいSOA管理対象サーバー用の浮動IPも、すでに存在している必要があります。 |
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で、移行を構成するサーバーの名前(ハイパーリンクとして表示される)をクリックします。選択したサーバーの「設定」ページが表示されます。
「移行」サブタブをクリックします。
「移行の構成」セクションで、移行に参加するサーバーを「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、SOAHOST1(すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。
|
注意: 移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。 |
「サーバーの自動移行を有効化」オプションを選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。
次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。
管理コンソールで、「環境」、「クラスタ」の順に選択します。
「SOA_Cluster」サーバーをクリックします。
SOA_Clusterの設定画面が表示されます。
「ロックして編集」をクリックします。
「クラスタ・アドレス」フィールドに新しいサーバーのアドレスとポートを入力します。例:
SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOST1VHN1 :8001
変更を保存してアクティブ化します。
この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。
管理対象サーバーのPIDで次のコマンドを使用して、WLS_SOAn管理対象サーバーを停止します。
kill -9 pid
ノードのPIDは次のコマンドで特定できます。
ps -ef | grep WLS_SOAn
ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
BAMサーバーはアクティブ/パッシブ・モードで動作するため、BAMサーバーの管理対象サーバーをスケーリングできません。しかし、BAM Webアプリケーション・サーバーのスケーリングは可能です。
BAM Webアプリケーション・サーバーのスケーリング方法は2つあります。
BAM Webアプリケーション・サーバーのみを実行している管理対象サーバーをクローニングします。
BAMサーバーとBAM Webアプリケーション・サーバーの両方を実行している管理対象サーバーをクローニングし、第12.6項「WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除」の説明のとおり、ターゲット設定からBAMサーバー・システムを外します。
BAM Webアプリケーション・サーバーをスケールアップするには、第16.5.1項「Oracle SOAのスケールアップ手順」の「手順5 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します」以外の手順を実行します。
1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することで、Oracle Service Busサーバーをスケールアップできます。
前提条件
Oracle Service Busサーバーをスケールアップする前に、次の前提条件を確認してください。
クラスタで、Oracle Service Busコンポーネントを使用して構成されている管理対象サーバーを実行しています。
ノードには、既存の管理対象サーバーのミドルウェア・ホーム、Oracleホーム(SOAとOracle Service Bus)およびドメイン・ディレクトリが含まれています。
クローンのソースとなる管理対象サーバーが、新しい管理対象サーバーを実行するノードにすでに存在しています。
新しいWLS_OSBサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。SOAまたはOracle Service Busのバイナリを新しい場所にインストールしたり、packやunpackを実行したりする必要はありません。
Oracle Service Busサーバーをスケールアップする手順は次のとおりです。
管理コンソールを使用し、WLS_OSBnのクローンを新しい管理対象サーバーにします。
「環境」→「サーバー」を選択します。
クローンを作成する管理対象サーバー(WLS_OSB1など)を選択します。
「クローン」を選択します。
新しい管理対象サーバーにWLS_OSBnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
以降の手順は、新しいサーバーをSOAHOST1に追加します。すでにWLS_OSB1が実行されています。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。
このサーバーに対して推奨されているサーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。この仮想ホスト名は、Oracle Service Bus/SOAドメイン(同じドメインまたは別のドメイン)によって使用されているノードで実行されている他の管理対象サーバーで使用されているものとは異なっている必要があります。
管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列で、更新するリスニング・アドレスを持つ管理対象サーバーを選択します。
その管理対象サーバーの「設定」ページが表示されます。
「リスニング・アドレス」を「SOAHOST1VHNn」に設定し、「保存」をクリックします。
管理対象サーバーを再起動して変更を有効にします。
次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。
管理コンソールで、「環境」、「クラスタ」の順に選択します。
「OSB_Cluster」サーバーをクリックします。
OSB_Clusterの「設定」画面が表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:
SOAHOST1VHN2:8011,SOAHOST2VHN2:8011,SOAHOST1VHNn:8011
Oracle Service BusにJMSリクエスト/レスポンス機能を使用するビジネス・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順を実行します。
「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。
プロジェクト・エクスプローラで、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索し、選択します。
このタイプのビジネス・サービスは、「サービスのタイプ」としてメッセージング・サービスが表示されます。
「詳細の表示」ページの下部にある「編集」をクリックします。
エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。
ビジネス・サービスの編集 - サマリー・ページで「保存」をクリックします。
JMSリクエスト/レスポンスを使用する他のビジネス・サービスについて、それぞれ前の手順を繰り返します。
「チェンジ・センター」で、「アクティブ化」をクリックしてセッションを作成します。
管理対象サーバーを再起動します。
管理サーバーを再起動します。
これで、ビジネス・サービスは、拡張されたドメインで操作できるように構成されています。
|
注意: JMS MessageID相関スキームを使用するビジネス・サービスの場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加します。キューとトピック宛先の構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。 |
Oracle Service Busにクラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順を実行します。
「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。
プロジェクト・エクスプローラで、クラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスを検索し、選択します。
「詳細の表示」ページの下部にある「編集」をクリックします。
エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。
「プロキシ・サービスの編集 - サマリー」ページで「保存」をクリックします。
クラスタ・アドレスを含むJMSエンドポイントを使用する他のプロキシ・サービスについて、それぞれ前の手順を繰り返します。
「チェンジ・センター」で、「アクティブ化」をクリックします。
管理対象サーバーを再起動します。
これで、プロキシ・サービスは、拡張されたドメインで操作できるように構成されています。
新しいサーバーのOracle Service Busの結果キャッシュのCoherence構成を更新する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンク)をクリックします。
選択したサーバーの「設定」ページが表示されます。
「サーバーの起動」タブをクリックします。
WLS_OSBnについて(改行を入れずに1行で)次のように入力します。
-DOSB.coherence.localhost=SOAHOST1vhnn -DOSB.coherence.localport=7890 -DOSB.coherence.wka1=SOAHOST1vhn2 -DOSB.coherence.wka1.port=7890 -DOSB.coherence.wka2=SOAHOST2vhn2 -DOSB.coherence.wka1.port=7890
|
注意: この構成では、WLS_OSBnの起動時に、サーバーWLS_OSB1とWLS_OSB2が実行している必要があります(このガイドの残りの手順で使用しているように仮想ホスト名SOAHOST1VHNおよびSOAHOST2VHNをリスニング)。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたCoherenceクラスタに、指定されたWKAアドレスを使用して参加します。また、3つのサーバーすべてを再起動する場合、WLS_OSB1とWLS_OSB2が起動されてからWLS_OSBnが起動されることを確認します。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたクラスタに参加します。サーバーの起動順序が重要でない場合は、WLS_OSB1とWLS_OSB2のWKAとしてWLS_OSBnのホストとポートを追加し、さらにWLS_OSBnのWKAとしてWLS_OSBnを追加します。 |
変更を保存してアクティブ化します。
Oracle Service Busサーバーを再起動して、変更内容を反映します。
管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1
「保存してアクティブ化」をクリックします。
新しい管理対象サーバーにOracle Service Busのレポート作成/内部宛先のJMSサーバーと永続ストアを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、OSB_rep_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶領域のディレクトリである必要があります。例:
ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/
ストアを新しいクローン済サーバー(WLS_OSBn)にターゲット設定します。
Oracle Service Busの新しいJMSサーバーを作成します(たとえば、OSB_rep_JMSServer_N)。このJMSサーバーに対して、OSB_rep_JMSFileStore_Nを使用します。OSB_rep_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。
新たに作成されたOSB JMSサーバーが含まれるように、"jmsResources" Oracle Service Bus JMSモジュールのSubDeploymentターゲットを更新します。
「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。
「jmsResources」をクリックします(表の「名前」列内のハイパーリンク)。jmsResourcesの「設定」ページが表示されます。
「サブデプロイメント」タブをクリックします。jmsresourcesのサブデプロイメント・モジュールが表示されます。
|
注意: 宛先のこのサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OSB1とWLS_OSB2)のJMS構成から生成されたwlsbJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「wlsbJMSServerXXXXXX」をクリックし、新しいOSB_rep_JMSServer_nサーバーが含まれるようにターゲットを更新します。
新しい管理対象サーバーにOSB JAX-RPCのJMSサーバー、永続ストアおよび宛先を作成します。
|
注意: WebLogic JAX-RPC Webサービスの高度な拡張機能では、通常の(非分散)宛先を使用して、ローカルに処理するサービス・リクエストがローカル・メンバーにのみエンキューされることを保証します。 |
Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、Wsee_rpc_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。
OSB JAX-RPCの新しいJMSサーバーを作成します(たとえば、OSB_rpc_JMSServer_N)。このJMSサーバーに対して、Wsee_rpc_JMSFileStore_Nを使用します。OSB_rpc_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。
「サービス」ノード、「メッセージング」ノードを開き、WseeJMSModule OSB JMSモジュールを宛先および新しく作成したOSB JMSサーバーで更新します。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「WseeJmsModule」をクリックします(表の「名前」列内のハイパーリンク)。WseeJmsModuleの「設定」ページが表示されます。ステップdからvを実行して、この手順を完了します。
「チェンジ・センター」で、「ロックして編集」をクリックし、「新規」をクリックします。
「DefaultCallbackQueue-WseeJmsServer_auto_n」を選択し、「次へ」をクリックします。
「新しいサブデプロイメントの作成」をクリックします。
デフォルトの名前を受け入れて「OK」をクリックします。
ターゲットとして「OSB_rpc_JMSServer_n」を選択し、「終了」をクリックします。
宛先のローカルJNDI名を更新します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「WseeJmsModuleの設定」ページで、「DefaultCallbackQueue-WseeJmsServer_auto_n」宛先をクリックします。
「一般構成」タブで、「詳細」をクリックします。
ローカルJNDI名をweblogic.wsee.DefaultCallbackQueueに更新します。
DefaultQueue-WseeJmsServer_auto_nキューに対して、JNDI名としてweblogic.wsee.DefaultQueue-WseeJmsServer_auto_nを、ローカルJNDI名としてweblogic.wsee.DefaultQueueを使用して、ステップdからhを繰り返します。
新しいSAFエージェントを作成し、そのターゲットを新しく追加した管理対象サーバーに設定します。
Oracle WebLogic Server管理コンソールで、「サービス」、「メッセージング」、「ストア・アンド・フォワード・エージェント」を展開します。
新しいSAFエージェントReliableWseeSAFAgent_auto_Nを追加します。
永続ストアWsee_rpc_JMSFileStore_N (OSB JAX-RPC用に作成された永続ストア)を選択します。
SAFエージェントのターゲットを新しい管理対象サーバーに設定し、変更をアクティブにします。
新しいサーバーのTX永続ストアを、他のノードから参照可能な場所に構成します。
管理コンソールから、「Server_name」を選択し、「サービス」タブを選択します。
「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバー用のホスト名検証を無効にします。WLS_OSBn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておきます。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローンの元となったソース・サーバーでホスト名検証がすでに無効化されている場合、これらの手順は不要です(ホスト名検証の設定はクローニングされたサーバーに伝播されているため)。
ホスト名検証を無効化するには:
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_OSBn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブ、「詳細」を順にクリックします。
「ホスト名の検証」を「なし」に設定し、「保存」をクリックします。
新しいノードでノード・マネージャがまだ起動されていない場合はそれを起動します。ノード・マネージャを起動するには、次のように、すでに存在しているノードの共有記憶域にあるインストールを使用します。
SOAHOSTN> WL_HOME/server/bin/startNodeManager
管理コンソールから、新しい管理対象サーバーを起動してテストします。
クラスタ内の既存の管理対象サーバーを停止します。
新たに作成した管理対象サーバーWLS_OSBnが起動していることを確認します。
次のURLを使用して、新しく作成した管理対象サーバー上のアプリケーションにアクセスします。
http://vip:port/sbinspection.wsil
新しい管理対象サーバーに対してサーバー移行を構成します。
|
注意: これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。新しいOracle Service Bus管理対象サーバー用の浮動IPがすでに存在している必要があります。 |
サーバー移行を構成する手順は次のとおりです。
管理コンソールにログインします。
左側のペインで「環境」を開き、「サーバー」を選択します。
移行を構成する新しい管理対象サーバーの名前を選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可するマシンを選択して、右向き矢印をクリックします。
ノードの既存のサーバーと同じ移行ターゲットを選択します。
たとえば、SOAHOST1(すでにWLS_OSB1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_OSB2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。
移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。
「サーバーの自動移行を有効化」オプションを選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。
管理対象サーバーのPID (プロセスID)で次のコマンドを実行して、WLS_OSBn管理対象サーバーを停止します。
kill -9 pid
ノードのPIDは次のコマンドで特定できます。
ps -ef | grep WLS_OSBn
|
注意: Windowsの場合は、
taskkill /f /pid pid
pidは、管理対象サーバーのプロセスIDを表します。 WLS_OSBn管理対象サーバーのプロセスIDを確認するには、次のコマンドを実行します。
MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v
|
ノード・マネージャのコンソールに、WLS_OSBnの浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_OSBnの2回目の再起動を試行するのを待ちます。
ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャでサーバーを再起動したら、再び停止します。
サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
|
注意: サーバーの移行後、そのサーバーを元のノードにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。 |
トポロジをスケールアウトするには、SOAまたはWSM-PMを構成した新しい管理対象サーバーを新しいノードに追加します。
この項の手順を実行する前に、次の要件が満たされていることを確認してください。
前提条件
SOAまたはWSM-PMを構成した管理対象サーバーが、トポロジ内の既存のノードで実行されている必要があります。
新しいノードが、WebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerやSOAのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpackとunpackを実行してドメイン構成をブートストラップする必要はあります。)
ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておきます。ノード内のoraInventoryを更新し、これに共有記憶域のインストールをアタッチするには、次の場所でattachHome.shスクリプトを使用します。
ORACLE_HOME/oui/bin/
ミドルウェア・ホーム・リストを更新してWL_HOMEを追加または削除するには、次のディレクトリにあるbeahomelistファイルを編集します。
MW_HOME/bea
|
注意: スケール・アウトの手順は、WSM管理対象サーバーにのみ適用されます。 |
トポロジをスケール・アウトするには:
新しいノード上に、既存のミドルウェア・ホーム(SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチするには、次のコマンドを実行します。
SOAHOSTn>cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
ミドルウェア・ホーム・リストを更新するには、beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集します)、MW_HOMEをこのファイルに追加します。beahomelistファイルは、次のディレクトリにあります。
MW_HOME/bea
Oracle WebLogic管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。
マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのIPをマッピングします。
Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。この管理対象サーバーには、WLS_SOAnまたはWLS_WSMnという名前を付けます(nは番号です)。これを、作成した新しいマシンに割り当てます。
|
注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。
このサーバーでサーバー移行を実行する場合(推奨)は、ここでサーバーの仮想IP(浮動IPとも呼ばれる)を指定します。この仮想IPは、既存の管理対象サーバーとは別のものを使用してください。
WLS_WSMサーバーの場合は、第8.6項「Oracle WSMでのJava Object Cacheの構成」で説明されているように、Java Object Cacheの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。
SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。
|
注意: WSM_WSM管理対象サーバーまたはBAM Webアプリケーション・システムをスケール・アップする場合は、新しい管理対象サーバー上でSOAおよびUMSのJMSサーバーを作成する必要はありません。この手順は、WLS_SOA管理対象サーバーをスケール・アップする場合にのみ必要です。 |
SOA用およびUMS用のJMSサーバーを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms/
SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMSJMSServer用の新しい永続ストアを作成し、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」でJMS永続ストアのディレクトリとして推奨されているパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
SOA、UMSおよびBPM JMSモジュール用のSubDeploymentターゲットを更新し、新しく作成したJMSサーバーを含めます(該当する場合)。この操作を実行するには、「サービス」ノードを開き、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BPM: BPMJMSModule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。
|
注意: このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。 |
このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。「保存してアクティブ化」をクリックします。
UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。
SOAおよびUMS JMSモジュール(適用可能な場合)のサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA用: SOAJMSModuleおよびUMS用: UMSSYtemResource)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。
|
注意: このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXXまたはUMSJMSServerXXXXXXのフォームのランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。 |
このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。
次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
SOAHOST1で次のコマンドを実行し、テンプレート・ファイルをSOAHOSTnにコピーします。
scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_COMMON_HOME/common/bin
次のように、SOAHOSTnでunpackコマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。
SOAHOSTN> cd ORACLE_COMMON_HOME/common/bin
SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name /mserver/domain_name/ -template=soadomaintemplateScale.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
|
注意: このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。 |
新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順については、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。
|
注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。 Dtangosol.coherence.localhost=SOAHOST1VHNn |
管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1
「保存してアクティブ化」をクリックします。
新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAn管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用してから、次のように新しいノードのホスト名をパラメータとして渡します。
SOAHOSTN> WL_HOME/server/bin/startNodeManager
Oracle WebLogic Server管理コンソールで、新しい管理対象サーバーを起動してテストします。
新たに作成した管理対象サーバー、WLS_SOAnが実行されていることを確認します。
次のURLを使用して、ロード・バランサ上のアプリケーションにアクセスします。
https://soa.mycompany.com/soa-infra
アプリケーションが機能している必要があります。
|
注意: トポロジ内のHTTP Serverは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。クラスタ内のすべてのサーバーをOracle HTTP Serverの |
新しい管理対象サーバー用のサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいSOA管理対象サーバー用の浮動IPも、新しいノードにすでに存在します。 |
Oracle WebLogic Server管理コンソールにログインし、サーバー移行を構成します。
サーバー移行を構成する手順は次のとおりです。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
表の「名前」列で、移行を構成するサーバー(ハイパーリンクとして表示される)を選択します。そのサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。
|
注意: マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。 |
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。
次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。
管理コンソールで、「環境」、「クラスタ」の順に選択します。
「SOA_Cluster」サーバーをクリックします。
SOA_Clusterの設定画面が表示されます。
「ロックして編集」をクリックします。
「クラスタ・アドレス」フィールドに新しいサーバーのアドレスとポートを入力します。たとえば、SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8001と入力します。
変更を保存してアクティブ化します。
この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。
WLS_SOAn管理対象サーバーに対して次のコマンドを実行して、このサーバーをすぐに停止します。
kill -9 pid
ノードのPID (プロセスID)は次のコマンドで特定できます。
ps -ef | grep WLS_SOAn
ノード・マネージャのコンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。
トポロジをスケール・アウトするには:
新しいノード上に、既存のミドルウェア・ホーム(SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチするには、次のコマンドを実行します。
SOAHOSTn>cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
ミドルウェア・ホーム・リストを更新するには、beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集します)、MW_HOMEをこのファイルに追加します。beahomelistファイルは、次のディレクトリにあります。
MW_HOME/bea
Oracle WebLogic管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。
マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのIPをマッピングします。
Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。このサーバーにWLS_SOAnという名前を付けます(nは番号です)。これを、作成した新しいマシンに割り当てます。
|
注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。
このサーバーでサーバー移行を実行する場合(推奨)は、ここでサーバーの仮想IP(浮動IPとも呼ばれる)を指定します。この仮想IPは、既存の管理対象サーバーとは別のものを使用してください。
SOA、BAM(適用可能な場合)およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。
SOA用およびUMS用のJMSサーバーを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms/
SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMSJMSServer用の新しい永続ストアを作成し、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」でJMS永続ストアのディレクトリとして推奨されているパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいBAMJMSServerの新しい永続ストアを作成します(たとえば、BAMJMSFileStore_N)。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: SOAJMSFileStore_Nを新しいBAM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
BAMの新しいJMSサーバーを作成します(たとえば、BAMJMSServer_N)。このJMSServerにはBAMJMSFileStore_Nを使用します。BAMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したSOA JMSサーバーを追加します。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列にハイパーリンクとして表示)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSSubDMサブデプロイメントが表示されます。
|
注意: このサブデプロイメント・モジュールは、最初の2つのサーバー(WLS_SOA1およびWLS_SOA2)のJMS構成を共通分散宛先(UDD)スクリプト(soa-createUDD.py)によって更新した結果作成されたものです。このスクリプトは、エンタープライズ・デプロイメント・トポロジの初期設定に必要です。 |
このサブデプロイメントをクリックします。SOA用の新しいJMSサーバーSOAJMSServer_Nを、このサブデプロイメントに追加します。「保存」をクリックします。
UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。
SOA、UMSおよびBAM JMSモジュール(適用可能な場合)のサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BAM: BAMJMSMOdule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。
|
注意: このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBAMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。 |
このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。
次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
SOAHOST1で次のコマンドを実行し、テンプレート・ファイルをSOAHOSTnにコピーします。
scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_COMMON_HOME/common/bin
次のように、SOAHOSTnでunpackコマンドを実行して、管理対象サーバーのドメイン・ディレクトリにテンプレートを解凍します。
SOAHOSTN> cd ORACLE_COMMON_HOME/common/bin
SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name /mserver/domain_name/ -template=soadomaintemplateScale.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
|
注意: このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。 |
新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順については、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。
|
注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。 Dtangosol.coherence.localhost=SOAHOST1VHNn |
管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1
「保存してアクティブ化」をクリックします。
新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAn管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用してから、次のように新しいノードのホスト名をパラメータとして渡します。
SOAHOSTN> WL_HOME/server/bin/startNodeManager
Oracle WebLogic Server管理コンソールで、新しい管理対象サーバーを起動してテストします。
新たに作成した管理対象サーバー、WLS_SOAnが実行されていることを確認します。
次のURLを使用して、ロード・バランサ上のアプリケーションにアクセスします。
https://soa.mycompany.com/soa-infra
アプリケーションが機能している必要があります。
|
注意: トポロジ内のHTTP Serverは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。クラスタ内のすべてのサーバーをOracle HTTP Serverの |
新しい管理対象サーバー用のサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいSOA管理対象サーバー用の浮動IPも、新しいノードにすでに存在します。 |
Oracle WebLogic Server管理コンソールにログインし、サーバー移行を構成します。
サーバー移行を構成する手順は次のとおりです。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
表の「名前」列で、移行を構成するサーバー(ハイパーリンクとして表示される)を選択します。そのサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。
|
注意: マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。 |
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。
次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。
管理コンソールで、「環境」、「クラスタ」の順に選択します。
「SOA_Cluster」サーバーをクリックします。
SOA_Clusterの設定画面が表示されます。
「ロックして編集」をクリックします。
「クラスタ・アドレス」フィールドに新しいサーバーのアドレスとポートを入力します。例:
SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8001
変更を保存してアクティブ化します。
この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。
WLS_SOAn管理対象サーバーに対して次のコマンドを実行して、このサーバーをすぐに停止します。
kill -9 pid
ノードのPID (プロセスID)は次のコマンドで特定できます。
ps -ef | grep WLS_SOAn
ノード・マネージャのコンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。
BAMサーバーはアクティブ/パッシブ・モードで動作するため、BAMサーバーの管理対象サーバーをスケーリングできません。しかし、BAM Webアプリケーション・サーバーのスケーリングは可能です。
BAM Webアプリケーション・サーバーのスケーリング方法は2つあります。
BAM Webアプリケーション・サーバーのみを実行している管理対象サーバーをクローニングします。
BAMサーバーとBAM Webアプリケーション・サーバーの両方を実行している管理対象サーバーをクローニングし、第12.6項「WLS_BAM2からのBAMサーバー・システムのターゲット設定の解除」の説明のとおり、ターゲット設定からBAMサーバー・システムを外します。
BAM Webアプリケーション・サーバーをスケールアウトするには、第16.6.1項「Oracle SOAのスケールアウト手順」の「手順11 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します」以外の手順を実行します。
トポロジのスケール・アウトでは、Oracle Service Busで構成された新しい管理対象サーバーを新しいノードに追加します。
前提条件
Oracle Service Busトポロジをスケール・アウトする前に、次の前提条件を満たしていることを確認します。
Oracle Service Busで構成された管理対象サーバーを実行しているノードがトポロジ内に存在しています。
新しいノードは、WebLogic ServerとOracle Service Busインストールの既存のホーム・ディレクトリに必要に応じてアクセスできます。新しいWLS_OSB管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用してください。この場合、WebLogic ServerまたはOracle Service Busバイナリを新しい場所すべてにインストールする必要はありませんが、同じドメインの他のサーバーを含んでいるマシン(SOAサーバー)にOracle Service Busサーバーをスケールアウトする場合を除いて、packおよびunpackコマンドを実行して、新しいノードでドメイン構成をブートストラップする必要があります。
共有記憶域に既存のインストールがない場合は、WebLogic Server、SOAおよびOracle Service Busを新しいノードにインストールします。
ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておきます。ノード内のoraInventoryを更新し、これに共有記憶域のインストールをアタッチするには、次のディレクトリにあるattachHome.shファイルを使用します。
ORACLE_HOME/oui/bin/
ミドルウェア・ホーム・リストを更新してWL_HOMEを追加または削除するには、次のディレクトリにあるbeahomelistファイルを編集します。
MW_HOME/bea
トポロジをスケール・アウトするには:
新しいノードで、既存のミドルウェア・ホームをマウントします。これにはOracle Service BusとSOA (ホームを共有している場合)のインストールおよびドメイン・ディレクトリが含まれている必要があります。新しいノードが、ドメイン内の他のノードと同様に、このディレクトリにアクセスできることを確認します。
次のコマンドを使用して、共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチします。
SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/ SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
ミドルウェア・ホーム・リストを更新するには、次のディレクトリにbeahomelistファイルを作成します(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集します)。
MW_HOME/bea/
ORACLE_BASE/product/fmwをリストに追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。
マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのIPをマッピングします。
Oracle WebLogic Server管理コンソールを使用し、WLS_OSB1のクローンを作成して新しい管理対象サーバーにします。これにWLS_OSBnという名前を付けます(nは新しいマシンに割り当てる番号です)。
|
注意: これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加します。 |
リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。このサーバーに対して推奨されているサーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。この仮想ホスト名は、OSB/SOAドメイン(同じドメインまたは別のドメイン)によって使用されているノードで実行されている他の管理対象サーバーで使用されているものとは異なっている必要があります。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。
その管理対象サーバーの「設定」ページが表示されます。
「リスニング・アドレス」を「SOAHOSTnVHN1」に設定し、「保存」をクリックします。
変更を保存してアクティブ化します。
管理対象サーバーを再起動します。
次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。
管理コンソールで「環境」、「クラスタ」を順に選択します。
「OSB_Cluster」サーバーをクリックします。
OSB_Clusterの「設定」画面が表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:
SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8011
新しい管理対象サーバーにOracle Service Busのレポート作成/内部宛先のJMSサーバーと永続ストアを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、OSB_rep_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 ORACLE_BASE/admin/domain_name/cluster_name/jms/OSB_rep_JMSFileStore _N |
Oracle Service Busの新しいJMSサーバーを作成します(たとえば、OSB_rep_JMSServer_N)。このJMSサーバーに対して、OSB_rep_JMSFileStore_Nを使用します。OSB_rep_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。
新たに作成されたOracle Service Bus JMSサーバーが含まれるように、jmsresources Oracle Service Bus JMSモジュールのSubDeploymentターゲットを更新します。
「サービス」ノードを開いてから、「メッセージング」ノードを開きます。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。
「jmsresources」をクリックします(表の「名前」列内のハイパーリンク)。jmsResourcesの「設定」ページが表示されます。
「サブデプロイメント」タブを開きます。jmsresourcesのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュールの名前は、 サブデプロイメント「wlsbJMSServerXXXXXX」をクリックし、新しいOSB_rep_JMSServer_Nサーバーが含まれるようにターゲットを更新します。 |
新しい管理対象サーバーにOSB JAX-RPCのJMSサーバー、永続ストアおよび宛先を作成します。
|
注意: WebLogic JAX-RPC Webサービスの高度な拡張機能では、通常の(非分散)宛先を使用して、ローカルに処理するサービス・リクエストがローカル・メンバーにのみエンキューされることを保証します。 |
Oracle WebLogic Server管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、Wsee_rpc_JMSFileStore_Nなどの名前を付けます。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/Wsee_rpc_JMSFileStore_N |
Oracle Service Bus JAX-RPCの新しいJMSサーバーを作成します(たとえば、OSB_rpc_JMSServer_N)。このJMSサーバーに対して、Wsee_rpc_JMSFileStore_Nを使用します。OSB_rpc_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。
WseeJMSModule Oracle Service Bus JMSモジュールを、宛先および新しく作成したOracle Service Bus JMSサーバーで更新します。
「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。
「WseeJmsModule」をクリックします(表の「名前」列内のハイパーリンク)。WseeJmsModuleの「設定」ページが表示されます。
ステップdからjを実行して、この手順を完了します。
「チェンジ・センター」で、「ロックして編集」をクリックし、「新規」をクリックします。
「キュー」を選択し、「次へ」をクリックします。
キューの名前としてDefaultCallbackQueue-WseeJmsServer_auto_nと入力します。
JNDI名として「weblogic.wsee.DefaultCallbackQueue-WseeJmsServer_auto_n」と入力し、「次へ」をクリックします。
「新しいサブデプロイメントの作成」をクリックします。
デフォルトの名前を受け入れて「OK」をクリックします。
ターゲットとして「OSB_rpc_JMSServer_n」を選択し、「終了」をクリックします。
変更をアクティブ化します。
宛先のローカルJNDI名を更新します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
WseeJmsModuleの「設定」ページで、「DefaultCallbackQueue-WseeJmsServer_auto_n」宛先をクリックします。
「一般構成」タブで、「詳細」をクリックします。
ローカルJNDI名をweblogic.wsee.DefaultCallbackQueueに更新します。
新しいSAFエージェントを作成し、そのターゲットを新しく追加した管理対象サーバーに設定します。
Oracle WebLogic Server管理コンソールで、「サービス」→「メッセージング」→「ストア・アンド・フォワード・エージェント」を展開して、新しいSAFエージェント「ReliableWseeSAFAgent_auto_N」を追加します。
永続ストアWsee_rpc_JMSFileStore_N (Oracle Service Bus JAX-RPC用に作成された永続ストア)を選択します。SAFエージェントのターゲットを新しい管理対象サーバーに設定し、変更をアクティブにします。
Oracle Service BusにJMSリクエスト/レスポンス機能を使用するビジネス・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順を実行します。
「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。
プロジェクト・エクスプローラで、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索し、選択します。
このタイプのビジネス・サービスは、「サービスのタイプ」としてメッセージング・サービスが表示されます。
「詳細の表示」ページの下部にある「編集」をクリックします。
エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。
「ビジネス・サービスの編集 - サマリー」ページで「保存」をクリックします。
JMSリクエスト/レスポンスを使用する他のビジネス・サービスについて、それぞれ前の手順を繰り返します。
「チェンジ・センター」で、「アクティブ化」をクリックします。
管理対象サーバーを再起動します。
管理サーバーを再起動します。
これで、ビジネス・サービスは、拡張されたドメインで操作できるように構成されています。
|
注意: JMS MessageID相関スキームを使用するビジネス・サービスの場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加します。キューとトピック宛先の構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。 |
Oracle Service Busにクラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順を実行します。
「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。
プロジェクト・エクスプローラで、クラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスを検索し、選択します。
「詳細の表示」ページの下部にある「編集」をクリックします。
エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。
「プロキシ・サービスの編集 - サマリー」ページで「保存」をクリックします。
クラスタ・アドレスを含むJMSエンドポイントを使用する他のプロキシ・サービスについて、それぞれ前の手順を繰り返します。
「チェンジ・センター」で、「アクティブ化」をクリックします。
管理対象サーバーを再起動します。
これで、プロキシ・サービスは、拡張されたドメインで操作できるように構成されています。
新しいサーバーのOracle Service Busの結果キャッシュのCoherence構成を更新する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンク)をクリックします。
選択したサーバーの「設定」ページが表示されます。
「サーバーの起動」タブをクリックします。
「詳細」をクリックします。
WLS_OSBnについて(改行を入れずに1行で)次のように入力します。
-DOSB.coherence.localhost=SOAHOSTnvhn1 -DOSB.coherence.localport=7890 -DOSB.coherence.wka1=SOAHOST1vhn1 -DOSB.coherence.wka1.port=7890 -DOSB.coherence.wka2=SOAHOST2vhn1 -DOSB.coherence.wka1.port=7890
|
注意: 前述の構成は、WLS_OSBnの起動時に、サーバーWLS_OSB1とWLS_OSB2が実行されてます。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたCoherenceクラスタに、指定されたWKAアドレスを使用して参加します。また、3つのサーバーすべてを起動する場合、WLS_OSB1とWLS_OSB2が起動されてからWLS_OSBnが起動されることを確認します。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたクラスタに参加できます。サーバーの起動順序を考慮する必要のない構成の場合は、WLS_OSB1とWLS_OSB2のWKAとしてWLS_OSBnのホストとポートを追加し、さらにWLS_OSBnのWKAとしてWLS_OSBnを追加します。 |
変更を保存してアクティブ化します
Oracle Service Busサーバーを再起動します。
管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1
「保存してアクティブ化」をクリックします。
次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをSOAHOSTnにコピーします。
scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ORACLE_BASE/product/fmw/soa/common/bin
次のように、unpackコマンドをSOAHOSTNで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
cd ORACLE_BASE/product/fmw/soa/common/bin ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar
|
注意: このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。 |
共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所に新しいサーバーのTX永続ストアを構成します
管理コンソールからサーバー名を選択して、「サービス」タブを選択します。
「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバー用のホスト名検証を無効にします。
WLS_OSBn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておきます。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローンの元となったソース・サーバーでホスト名検証がすでに無効化されている場合、この手順は省略してかまいません(ホスト名検証の設定はクローニングされたサーバーに伝播されているため)。
ホスト名検証を無効化するには:
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_OSBn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定し、「保存」をクリックします。
すでに存在しているノードの共有記憶域にあるインストールを使用して、新しいノード上のノード・マネージャを起動します。新しいノードのホスト名をパラメータとして渡します。
SOAHOSTN> WL_HOME/server/bin/startNodeManager new_node_ip
Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーをすべて停止します。
新たに作成した管理対象サーバーWLS_OSBnが実行されていることを確認します。新たに作成した管理対象サーバー上のアプリケーションにアクセスします。
http://vip:port/sbinspection.wsil
アプリケーションが機能している必要があります。
新しい管理対象サーバー用のサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャおよびネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいOracle Service Bus管理対象サーバー用の浮動IPも、新しいノードにすでに存在します。 |
サーバー移行を構成する手順は次のとおりです。
管理コンソールにログインします。
左側のペインで「環境」を開き、「サーバー」を選択します。
移行を構成する対象となるサーバー(ハイパーリンクとして表示)を表の「名前」列から選択します。
このサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行先にするマシンを選択して、右向き矢印をクリックします。
たとえば、SOAHOST1(すでにWLS_OSB1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_OSB2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。
|
注意: マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。 |
「サーバーの自動移行を有効化」オプションを選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。
管理対象サーバーのPID (プロセスID)で次のコマンドを実行して、WLS_OSBn管理対象サーバーをすぐに停止します。
kill -9 pid
ノードのPIDは次のコマンドで特定できます。
ps -ef | grep WLS_OSBn
|
注意: Windowsの場合は、
taskkill /f /pid pid
pidは、管理対象サーバーのプロセスIDを表します。 WLS_OSBn管理対象サーバーのプロセスIDは次のコマンドで特定できます。
MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v
|
ノード・マネージャ・コンソールに、WLS_OSBnの浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_OSBnの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャでサーバーを再起動したら、再び停止します。
サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
|
注意: サーバーが移行された後に、それを元のノードまたはマシンにフェイルバックさせるには、Oracle WebLogic管理コンソールから管理対象サーバーを停止して、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。 |
ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。次に、SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。
前提条件:
管理サーバーを、任意のアドレスではなくADMINVHN上でリスニングするように構成します。第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順14を参照してください。
これらの手順では、2つのノードがそれぞれ別々のドメイン・ディレクトリを使用していることおよびこれらのディレクトリがローカル記憶域または別のボリュームにある共有記憶域に配置されていることを想定しています。
管理サーバーはSOAHOST1からSOAHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。
SOAHOST1: 100.200.140.165
SOAHOST2: 100.200.140.205
ADMINVHN : 100.200.140.206。これは管理サーバーを実行している場所の仮想IPであり、ethX:Yに割り当てられており、SOAHOST1とSOAHOST2からアクセスできます。
SOAHOST1での管理サーバーの実行場所であるドメイン・ディレクトリは共有記憶域にあり、SOAHOST2からもマウントされています。
第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」の説明のとおり、Oracle WebLogic ServerおよびOracle Fusion MiddlewareコンポーネントはSOAHOST2にインストールされています(つまり、SOAHOST1に存在するORACLE_HOMEおよびMW_HOMEのパスをSOAHOST2でも使用できます)。
この項には次のトピックが含まれます:
次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーしたうえで、同じWebLogic Serverマシン(これは物理マシンではなく論理マシンです)を引き続きその管理サーバーで使用する方法を示しています。
管理サーバーを別ノードにフェイルオーバーする手順は次のとおりです。
管理サーバーを停止します。
IPを第2ノードに移行します。
SOAHOST1上で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。
/sbin/ifconfig ethX:Y down
次のコマンドをSOAHOST2上で実行します。
/sbin/ifconfig <interface:index> IP_Address netmask <netmask>
例:
/sbin/ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0
|
注意: 使用するネットマスクとインタフェースは、SOAHOST2で使用可能なネットワーク構成と一致している必要があります。 |
次の例のようにarpingを使用してルーティング表を更新します。
/sbin/arping -q -U -c 3 -I eth0 10.0.0.1
SOAHOST2上の管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して起動します。
次の方法でSOAHOST2上の管理サーバーにアクセスできることをテストします。
次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN:7001/console
次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。
http://ADMINVHN:7001/em
|
注意: 管理サーバーでは、フェイルオーバーにノード・マネージャを使用しません。手動でフェイルオーバーした後、サーバーの管理コンソールの「現在のマシン」フィールドに表示されるマシン名は、フェイルオーバー・マシン「SOAHOST2」でなく、「SOAHOST1」になります。ノード・マネージャでは管理サーバーを監視しないので、「現在のマシン」フィールドに表示されるマシン名は関係ないため、無視してかまいません。 |
第8.7.5項「Oracle HTTP Serverを介したアクセスの検証」と同じ手順を実行します。この目的は、SOAHOST2で実行している管理サーバーにもアクセスできることを確認することです。
この手順では、管理サーバーをフェイルバックできることを確認します。フェイルバックとは、SOAHOST2で実行している管理サーバーを停止し、ADMINVHNをSOAHOST1ノードに戻して、SOAHOST1で再び管理サーバーを実行することです。
ADMINVHNをSOAHOST1に戻す手順は次のとおりです。
管理サーバーが起動されていないことを確認します。
次のコマンドをSOAHOST2上で実行します。
/sbin/ifconfig ethZ:N down
次のコマンドをSOAHOST1上で実行します。
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
|
注意: 使用するネットマスクとインタフェースは、SOAHOST1で使用可能なネットワーク構成と一致している必要があります。 |
arpingを使用してルーティング表を更新します。次のコマンドをSOAHOST1から実行します。
/sbin/arping -q -U -c 3 -I ethZ 100.200.140.206
第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して、SOAHOST1上の管理サーバーを再度起動します。
cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin ./startWebLogic.sh
次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。
http://ADMINVHN:7001/console
次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。
http://ADMINVHN:7001/em
環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。
表16-1は、11gのSOAエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。
表16-1 11gのSOAエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
ORACLEホーム(DB) |
CUSTDBHOST1およびCUSTDBHOST |
ユーザー定義 |
データ層 |
|
MWホーム(OHS) |
WEBHOST1およびWEBHOST2 |
ORACLE_HOME/fmw
|
Web層 |
|
MWホーム(SOAホームも含む) |
SOAHOST1およびSOAHOST2 |
MW_HOME
SOAホームはMW_HOMEのサブディレクトリになります
ORACLE_HOME
|
アプリケーション層 |
|
インストール関連ファイル |
OraInventory MW_HOME/bea/beahomelist, oraInst.loc, oratab |
なし |
表16-2は、11gのSOAエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。
表16-2 11gのSOAエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
ドメイン・ホーム |
SOAHOST1およびSOAHOST2 |
ORACLE_BASE/admin/domain_name/ mserver/domain_name |
アプリケーション層 |
|
アプリケーション・アーティファクト(EARおよびWARファイル) |
SOAHOST1およびSOAHOST2 |
アプリケーション・アーティファクトの場所を調べるには、管理コンソールですべてのデプロイメントを表示する |
アプリケーション層 |
|
OHSインスタンス・ホーム |
WEBHOST1およびWEBHOST2 |
ORACLE_BASE/admin/instance_name |
Web層 |
|
Oracle RACデータベース |
CUSTDBHOST1およびCUSTDBHOST2 |
ユーザー定義 |
データ層 |
|
注意: ORACLE_HOMEのバックアップは、B2B設定の一部であるXEngine構成が変更されたときに実行する必要があります。これらのファイルは、次のディレクトリにあります。
ORACLE_HOME/soa/thirdparty/edifecs/XEngine
ORACLE_HOMEをバックアップするには、次のコマンドを使用します。
tar -cvpf fmwhomeback.tar MW_HOME
|
エンタープライズ・デプロイメントの本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters (RAC)の場合、データベース接続はOracle RACの仮想IPとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。このような構成が不可能である場合は、次のディレクトリにあるsqlnet.oraファイル内の*SQLNET.EXPIRE_TIME=n*パラメータを設定します。
ORACLE_HOME/network/admin
nは分単位の時間です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。
この項では、BPELやメディエータなどのサービス・エンジンの失敗したインスタンスの有無を調べてリカバリする方法について説明します。
|
注意: この手順でSQL文を実行するときは、データベースに |
リカバリ可能インスタンスの有無を調べるには、データベース内で次のSQL文を実行します。
// Find recoverable activities SQL> select * from work_item where state = 1 and execution_type != 1; // Find recoverable invoke messages SQL> select * from dlv_message where dlv_type = 1 and state = 0; // Find recoverable callback messages SQL> select * from dlv_message where dlv_type = 2 and (state = 0 or state = 1);
失敗したBPELインスタンスをリカバリするには:
Enterprise Managerで、「Farm_<domain_name>」を選択し、「SOA」を展開し、「soa-infra (server_soa)」を右クリックして、「サービス・エンジン」→「BPEL」→「リカバリ」を選択します。
失敗したメディエータ・コンポジットをリカバリするには:
Enterprise Managerで、「Farm_<domain_name>」を選択し、「SOA」を展開し、「soa-infra (server_soa)」を右クリックして、「サービス・エンジン」→「メディエータ」→「フォルト」を選択します。
拒否メッセージの有無を調べるには:
SQL> select * from rejected_message
インスタンス・トラッキング表のデータを調べるには、次のSQL問合せを実行します。
SQL> select ID, STATE from COMPOSITE_INSTANCE where CREATED_TIME > datetime
datetimeには、問合せを絞り込むための日時を指定します。例:
'04-NOV-09 03.20.52.902000000 PM'
アダプタからのデータは、まずCOMPOSITE_INSTANCE表に入力されます。
アダプタからのデータがアダプタBCに公開されると、STATEが0のエントリ1個がCOMPOSITE_INSTANCE表に挿入されます。そのメッセージの処理が完了すると、STATEは1になります。エラーの場合は、STATE >= 2になります。
Webサービスに対するDoS攻撃や再帰的ノード攻撃を防ぐための構成は、SCABindingProperties.xmlおよびoracle-webservices.xmlで行います。
SCABindingProperties.xmlの構成
DoS攻撃や再帰的ノード攻撃を防ぐには、エンベロープ・サイズおよびネスト制限を例16-1のようにSCABBindingProperties.xmlで設定します。
例16-1 SCABBindingProperties.xmlでのエンベロープ・サイズとネスト制限の構成
<bindingType type="ws">
<serviceBinding>
<bindingProperty>
<name>request-envelope-max-kilobytes</name>
<type>xs:integer</type>
<defaultValue>-1</defaultValue>
</bindingProperty>
<bindingProperty>
<name>request-envelope-nest-level</name>
<type>xs:integer</type>
<defaultValue>-1</defaultValue>
</bindingProperty>
</serviceBinding>
oracle-webservices.xmlの構成
スタンドアロンのWebサービスについては、エンベロープ・サイズとネスト制限をoracle-webservices.xmlで構成します。例:
<request-envelope-limits kilobytes="4" nest-level="6" />
|
注意: エンベロープ・サイズとネスト制限の値が極端に大きい場合や、値がまったく設定されていない場合は、DoS攻撃を受けるおそれがあります。 |
BAMによる、Oracle RACフェイルオーバー後の処理中トランザクションの再試行回数を変更するには、MaxDBNodeFailoverRetries設定をデフォルトの5回から別の値に変更します。ただし、UseDBFailoverおよびMaxDBNodeFailoverRetriesの設定はデフォルトのままにしておくことをお薦めします。BAMのOracle RACフェイルオーバー再試行サポートを無効化するには、UseDBFailoverをfalseに設定します。(この設定のデフォルト値はtrueです。)これらの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のOracle BAM構成プロパティ・リファレンスの項を参照してください。
SOAクラスタ内のSOAインフラストラクチャ・アプリケーションまたはリソース・アダプタを再デプロイするときは、デプロイメント・プランとアプリケーション・ビットに、クラスタ内の全サーバーからアクセスできる必要があります。SOAのアプリケーションおよびリソース・アダプタは、nostageデプロイメント・モードを使用してインストールされます。nostageデプロイメント・モードを選択した場合、管理サーバーはアーカイブ・ファイルをソースの場所からコピーしないため、各サーバーが同じデプロイメント・プランにアクセスできるようにしておく必要があります。デプロイメント・プランおよびアプリケーションに次の場所を使用します。
ORACLE_BASE/admin/domain_name/cluster_name/dp
第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているとおり、このディレクトリはエンタープライズ・デプロイメント・トポロジ内のすべてのノードからアクセスできる場所である必要があります。
この項では、SOAエンタープライズ・デプロイメントで発生する可能性のある問題を示し、その解決方法を提案します。
この項の項目は次のとおりです。
第16.14.2項「soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する」
第16.14.4項「デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)」
第16.14.15項「OAMに対する変更をアクティブ化した後でユーザーが管理コンソールのホーム・ページにリダイレクトされる」
問題: BAMアプリケーションにアクセスするとHTTP 404エラー「見つかりません」が発生します。BAMスキーマを含むデータベース・インスタンスを起動する前に、BAMサーバーを起動したことが、このエラーの原因である可能性があります。
解決方法: データベースがすでに起動していることを確認してから、BAMインスタンスを停止して再起動します。
問題: ロード・バランサのアドレスを使用してsoa-infraアプリケーションにアクセスしようとしたときに、404メッセージ「ページが見つかりません」がWebブラウザに表示されます。このエラーは断続的に発生し、WLS管理コンソールではSOAサーバーが「実行中」と表示されます。
解決方法: SOA管理対象サーバーが実行中であるように見えても、そのサーバー内のアプリケーションの状態が「アクティブ」ではなく、「管理」や「準備完了」である場合があります。SOAサーバーが実行中でも、soa-infraアプリケーションが使用不可になることもあります。管理コンソールの「デプロイメント」ページで、soa-infraアプリケーションの状態を調べてください。状態は「アクティブ」になっている必要があります。SOA Serverの出力ログにsoa-infraアプリケーション関連のエラーがないことを確認し、管理コンソールの「デプロイメント」ページでsoa-infraアプリケーションを起動してください。
問題: ドキュメント定義XSDをOracle B2Bから取得しようとするときにエラーが発生します。B2Bはクラスタ内に存在しており、ロード・バランサ経由でアクセスします。B2Bコンソールには、次のようにレポートされます。
An error occured while loading the document definitions. java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.
解決方法: Oracle B2Bが存在するOracle WebLogicクラスタのフロントエンドにあるHTTPホストおよびポートを設定します。SOAクラスタに対してフロントエンド・アドレスを設定します。
WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。
左ペインの「ドメイン構造」ウィンドウの「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
「WLS_SOA」クラスタを選択します。
「HTTP」を選択します。
次の値を設定し、「保存」をクリックします。
フロントエンド・ホスト: soa.mycompany.com
フロントエンドHTTPSポート: 443
フロントエンドHTTPポート: 80
変更を有効にするために、管理コンソールの「チェンジ・センター」セクションの「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。
問題: デプロイメントのCoherence構成に対する変更を適用した後、soa-infraアプリケーションの起動に失敗します。SOAサーバーの出力ログには、次のように報告されます。
Cluster communication initialization failed. If you are using multicast, Please make sure multicast is enabled on your network and that there is no interference on the address in use. Please see the documentation for more details.
解決方法:
SOAコンポジットのクラスタ・デプロイメントに対してユニキャストではなくマルチキャストを使用する場合、前述のようなメッセージが表示されることがあります。その原因は、soa-infraアプリケーションの起動時(つまり、SOAが実行される管理対象サーバーの起動時)にマルチキャスト競合が発生したためです。このメッセージは、Oracle Coherenceがランタイム例外をスローしたときに生成されるもので、例外自体の詳細情報も含まれています。このようなメッセージが表示された場合、ネットワークのマルチキャスト構成を確認してください。マルチキャスト・アドレスに対してpingを実行できることを確認します。さらに、ネットワーク内の別の名前のクラスタが同じマルチキャスト・アドレスを使用しているかどうかを調べてください。このようなクラスタがあると、競合が発生してsoa-infraを起動できなくなることがあります。ネットワークでマルチキャストが有効化されていない場合、ユニキャストを使用するようにデプロイメント・フレームワークを変更してください。その方法については、『Oracle Coherence開発者ガイド』を参照してください。
ユニキャスト用の既知アドレス・リストをサーバー起動パラメータ内に入力するときは、ノードのローカル・ホストおよびクラスタ化されたサーバー用のアドレスが正しいことを確認してください。エラー・メッセージの例を次に示します。
oracle.integration.platform.blocks.deploy.CompositeDeploymentCoordinatorMessages errorUnableToStartCoherence
このようなエラーがサーバーの出力ログにある場合、正しく解決されていないアドレスがあります。
問題: ノード・マネージャのプロパティをstartScriptEnabled=trueに設定する前にSOAサーバーを管理コンソールから起動しようとすると、失敗します。このプロパティを設定した後、サーバーが起動しません。SOAサーバーの出力ログには、次のように報告されます。
SEVERE: <.> Unable to Encrypt data Unable to Encrypt data. Check installation/post-installation steps for errors. Check for errors during SOA server startup. ORABPEL-35010 . Unable to Encrypt data. Unable to Encrypt data. Check installation/post-installation steps for errors. Check for errors during SOA server startup. . at oracle.bpel.services.common.util.EncryptionService.encrypt(EncryptionService.java:56) ...
解決方法: system-jazn-data.xmlファイル内の<jazn-policy>要素を編集してBAM-services.jarに権限を付与します。
<grant>
<grantee>
<codesource>
<url>file:${oracle.home}/soa/modules/oracle.soa.workflow_11.1.1/BAM-
services.jar</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>java.security.AllPermission</class>
</permission>
</permissions>
</grant>
問題: SOA、WSMまたはBAMサーバーの起動に失敗します。新しい管理対象サーバー・タイプ用にドメインが拡張されているか(たとえば、BAM用にSOAを拡張)、システムがスケールアップされています(同じタイプのサーバーを追加)です。SOA/BAMまたはWSMサーバーの出力ログに、次のように報告されます。
<Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "SOADataSource-rac0": Listener refused the connection with the following error: ORA-12516, TNS:listener could not find available handler with matching protocol stack >
解決方法: データベース内のプロセス数を確認し、それにあわせて調整します。SYSユーザーとして、SHOW PARAMETERコマンドを発行します。
SQL> SHOW PARAMETER processes
次のコマンドを使用して初期化パラメータを設定します。
SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE
データベースを再起動します。
|
注意: パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイル、サーバー・パラメータ・ファイルおよびパラメータ値の変更方法の詳細は、Oracle Database管理者ガイドを参照してください。 |
問題: 管理サーバーに障害が発生して別のノードへの手動フェイルオーバーを実行した後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。
<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/soadomain/aserver/soadomain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>
解決方法: 次のディレクトリからEmbeddedLDAP.lokファイルを削除します。
ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/data/ldap/ldapfiles/
.
問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。
An error occurred during activation of changes, please see the log for details. [Management:141190]The commit phase of the configuration update failed with an exception: In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean
解決方法: 構成を変更しようとしていたサーバーの起動構成の一部であるユーザー名/パスワードの情報を管理コンソールで指定するか、<password-encrypted></password-encrypted>エントリをconfig.xmlファイルから削除してください(管理サーバーの再起動が必要)。
問題: ローカルのノード・マネージャによる再起動試行回数が最大数に達した後で、フェイルオーバー・ノードのノード・マネージャが再起動を試行しますが、サーバーは起動しません。ノード・マネージャの出力情報には、サーバーがフェイルオーバーしたことが報告されます。ノード・マネージャがSOAサーバーの移行を試行した後でも、このサーバーが使用する仮想IPがフェイルオーバー・ノード内で有効化されていません(フェイルオーバー・ノードでif configを実行しても、どのインタフェースの仮想IPも報告されません)。コマンド「sudo ifconfig $INTERFACE $ADDRESS $NETMASK」を実行しても、そのIPはフェイルオーバー・ノード内で有効化されません。
解決方法: sudo実行時にパスワード入力を要求するような権限と構成を設定しないでください。パスワード入力を要求しなくてもsudoが動作するようにsudoが構成されていることを、システム管理者に確認してください。
問題: サーバー移行は正常に実行されますが(SOA/BAMサーバーがフェイルオーバー・ノード内で再起動されます)、<仮想ホスト名>:8001/soa-infra URLにWebブラウザからアクセスできません。元のホストではすでにサーバーが強制終了されており、フェイルオーバー・ノードのノード・マネージャでは、仮想IPが移行済でサーバーが起動していることが報告されます。SOAサーバーが使用する仮想IPに対して、クライアントのノード(ブラウザが使用されているノード)からpingを実行しても応答がありません。
解決方法: nodemanager.propertiesファイルを更新してMACBroadcastを追加するか、次のように手動でarpingを実行してください。
/sbin/arping -b -q -c 3 -A -I $INTERFACE $ADDRESS > $NullDevice 2>&1
$INTERFACEは、仮想IPが有効化されているネットワーク・インタフェース、$ADDRESSは仮想IPアドレスです。
問題: WLS_SOAは正常に起動し、しばらくの間機能しますが、Oracleファイル・アダプタまたはOracle FTPアダプタを使用するアプリケーションの実行後に応答しなくなります。サーバーのログ・ファイルには、次のように報告されます。
<Error> <Server> <BEA-002606> <Unable to create a server socket for listening on channel "Default". The address X.X.X.X might be incorrect or another process is using port 8001: @ java.net.SocketException: Too many open files.>
解決方法: コンポジットでOracleファイルおよびFTPアダプタを使用している場合は(これらのアダプタは大量の同時メッセージを処理するように設計されている)、オペレーティング・システムのオープン・ファイル・パラメータの数値を大きくしてください。たとえば、Linuxのオープン・ファイル・パラメータの値を8192に設定するには、ulimit -n 8192コマンドを使用します。この値は、予想されるシステム負荷に基づいて調整する必要があります。
問題: 新しいアグリーメントのデプロイメントまたは新しいメタデータのパージ/インポートに失敗し、SWLS_SOAサーバーの出力ログに「[java] MDS-02202: Content of the metadata object」(デプロイメント)、「postTransfer: MDS-00521: error while reading document...」(パージ/インポート)と報告されます。
解決方法: この問題は、操作におけるタイミングとロード・バランシングのメカニズムが原因で発生します。例外が発生する可能性は非常に低いため、操作を再試行すれば概して成功します。クリーンアップなどの追加の手順は必要ありません。
問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しました。しかし、そのURLの1つに誤記がありました。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。
解決方法: 同じapp_domain名を指定してOAM構成ツールを実行したときは、既存ポリシーへの新しいURLの追加のみが行われます。特定のURLを削除するには、OAMのポリシー・マネージャ・コンソールを使用してください。OAMのアクセス管理サイトにログオンして、「ポリシー・ドメイン」をクリックし、作成済のポリシー・ドメイン(SOA_EDG)をクリックし、「リソース」タブで誤ったURLを削除します。
問題: Oracle WebLogic管理コンソールにアクセスするためにOHSおよびロード・バランサを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。
解決方法: この問題は、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、管理コンソールがその変更を反映しようとすると発生します。変更内容によっては、管理サーバーのリスニング・アドレスにリダイレクトすることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。再度ログインする必要はありません。次のURLを更新し、管理コンソールのホーム・ページに直接アクセスします。
soa.mycompany.com/console/console.portal
|
注意: この項で説明する変更の追跡を無効にしている場合、この問題は発生しません。 |
問題: OAMを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻りません)。
解決方法: これは、OAM SSOが構成済のときに発生する現象で、管理サーバーによってリダイレクトが実行された結果です。このリダイレクトにかかわらず、アクティブ化は完了します。必要であれば、ユーザーは手動で目的のコンテキスト・メニューに戻ることができます。
問題: Java Object Cacheを使用する管理対象サーバー(OWSMやWebCenter Spaces管理対象サーバーなど)を起動しようとすると失敗します。ログには次のようなエラーが記録されます。
J2EE JOC-058 distributed cache initialization failure J2EE JOC-043 base exception: J2EE JOC-803 unexpected EOF during read.
解決方法: JOCが取得しようとしているポートを別のプロセスが使用しています。そのプロセスを停止するか、このクラスタのJOCを再構成して、推奨されるポート範囲内で別のポートを使用するようにします。
SOAサーバーまたはBAMサーバーを初めて起動するときに失敗して、config.xmlの解析の失敗が報告されます。
問題: ノード・マネージャを使用して初めてサーバーを起動したときに、起動に失敗します。サーバーの出力ログには、次のようなメッセージが記録されます。
<Critical> <WebLogicServer> <eicfdcn35> <wls_server1> <main> <<WLS Kernel>> <> <> <1263329692528> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.
管理対象サーバーは、初回はMSI(管理対象サーバー独立)モードで起動しようとします。ただし、サーバーは初回起動時には適切な構成を取得できません。管理対象サーバーは、初回起動時には管理サーバーと通信できるようになっている必要があります。
解決方法: 管理サーバーのリスニング・アドレスと管理対象サーバーのリスニング・アドレスの間で通信が有効になっていることを確認します(管理対象サーバーのノードから管理サーバーのリスニング・アドレスに対してpingを実行し、管理サーバーのリスニング・アドレスおよびポートに対してtelnetを実行します)。通信が有効になったら、ドメインの圧縮と新しいドメインへの解凍を再度行うか、(一方のサーバーが同じドメイン・ディレクトリで正常に実行されている場合は)次のディレクトリを削除してサーバーを再起動します。
OARCLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/nodemanager
SOAクラスタのデフォルトのMDS変更通知メカニズムでは、デフォルトの30秒間隔で更新が伝播されます。B2Bアグリーメントのデリバリ・チャネルの場合または変更が頻繁に行われる場合など、それよりも早く構成変更を伝播する必要がある場合は、Javaオブジェクト・キャッシュ(JOC)を使用します。次のディレクトリにあるconfigure-joc.pyスクリプトを使用して分散Javaオブジェクト・キャッシュを構成します。
MW_HOME/oracle_common/bin
このPythonスクリプトを使用して管理対象サーバーにJOCを構成すると、B2Bデリバリ・チャネルに加えられた変更がすぐに通知されます。スクリプトはWLSTオンライン・モードで実行されます。管理サーバーが稼働している必要があります。
Oracle製品にJOCポートを構成する場合は、9988から9998のポートを使用します。
|
注意: WLSTコマンドまたは |
Oracle SOA Suiteサーバーの分散Javaオブジェクト・キャッシュを構成する手順は次のとおりです。
次のディレクトリの、コマンド行Oracle WebLogic Scripting Toolのwlst.shを使用して、管理サーバーに接続します。
MW_HOME/oracle_common/common/bin
wlst.shを使用して接続する手順は次のとおりです。
$ connect()
プロンプトが表示されたら、Oracle WebLogic管理サーバーのユーザー名とパスワードを入力します。
WLSTを使用して管理サーバーに接続したら、execfileコマンドを使用してスクリプトを起動します。例:
wls:/mydomain/serverConfig>execfile('MW_HOME/oracle_common/bin/configure-joc.py')
特定のクラスタのすべての管理対象サーバー用のJOCを構成します。
クラスタ名を指定するかどうかを尋ねるスクリプト・プロンプトが表示されたらyを入力します。プロンプトに従ってクラスタ名および検出ポートを指定します。これによって、指定したクラスタの管理対象サーバーがすべて検出され、JOCが構成されます。検出ポートは、そのクラスタのJOC構成全体で共通になります。
For Oracle Web Services Manager: Do you want to specify a cluster name (y/n) <y> Enter Cluster Name : SOA_Cluster Enter Discover Port : 9992
高可用性環境のためのconfigure-joc.pyの例を次に示します。
execfile('MW_HOME/oracle_common/bin/configure-joc.py')
.
Enter Hostnames (eg host1,host2) : SOAHOST1VHN1,SOAHOST2VHN1
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : SOA_Cluster
.
Enter Discover Port : 9992
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n
このスクリプトは、次のJOC構成にも使用できます。
指定された管理対象サーバーすべてのJOCを構成します。
クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたらnを入力し、プロンプトが表示されたら管理対象サーバーと検出ポートを指定します。例:
Do you want to specify a cluster name (y/n) <y>n Enter Managed Server and Discover Port (WLS_WSM1:9998, WLS_WSM1:9998) : WLS_WSM1:9992,WLS_WSM2:9992
一部の管理対象サーバーでJOC構成を除外します。
このスクリプトにより、JOC構成「DistributeMode」を「false」に設定する管理対象サーバーのリストを指定できます。JOC構成から除外するサーバーがあるかどうかを尋ねるプロンプトが表示されたら'y'を入力し、プロンプトが表示されたら除外する管理対象サーバー名を入力します。例:
Do you want to exclude any server(s) from JOC configuration (y/n) <n>y Exclude Managed Server List (eg Server1,Server2) : WLS_WSM1,WLS_WSM3
すべての管理対象サーバーに対して分散モードを無効にします。
このスクリプトでは、指定されたクラスタのすべての管理対象サーバーに対する分散を無効にできます。スクリプトにより分散モードに対するプロンプトが表示されたら、「false」を指定します。デフォルトでは、分散モードは「true」に設定されています。
B2BサーバーのVHNをリスニング・アドレスとして使用するようjavacahce.xmlファイルを編集します。
問題のサーバーのjavacache.xmlファイルを編集します。このファイルは、次のディレクトリに格納されています。
DOMAIN_HOME/aserver/soaedg_domain/config/fmwconfig/servers/server_name
次のようにlisten-addressフィールドを追加します。
...
<packet-distributor enable-router="false" startable="true" dedicated-coordinator="false">
<listener-address host="SOAHOST1VHN1" port="9992" />
<listener-address host="SOAHOST1VHN1" port="9992" />
<distributor-location host=" SOAHOST1VHN1" port="9992" ssl="true"/>
</packet-distributor>
...
CacheWatcherユーティリティを使用し、JOCの構成を確認します。『Oracle Fusion Middleware高可用性ガイド』を参照してください。
『Oracle Fusion Middleware高可用性ガイド』で説明しているように、Oracle WebLogic管理コンソールで「HAパワー・ツール」タブを使用してJavaオブジェクト・キャッシュ(JOC)を構成できます。
問題: 同じノードに複数のSOAクラスタが存在する場合にsoa-infraの起動に失敗します。サーバーの.outファイルに次のようなメッセージが表示されます。
<Error> <Coherence> <BEA-000000> <Oracle Coherence GE 3.6.0.4 <Error> (thread=Cluster, member=1): This senior Member(…) appears to have been disconnected from another senior Member…stopping cluster service.>
解決方法: Coherenceメンバーは再起動したときに、localport設定で構成されたポートへのバインドを試みます。このポートが使用できない場合は、ポート番号を2つずつ増やしてそのポートへの接続を試みます。複数のSOAクラスタがCoherence用に同じ範囲のポートを使用していると、メンバーが異なるWKAのクラスタに参加する可能性があり、この不一致によりsoa-infraアプリケーションが起動しなくなることがあります。この問題を解決するには、いくつかの方法があります。
クラスタ・ポートを2ずつ増やす方法ではなく、各クラスタにポート範囲を設定します。たとえば、クラスタ1は8000から8090、クラスタ2は8091から8180のように設定します。これは、このガイドの表3-4で推奨しているモデルが暗黙的に示すもので、各Coherenceクラスタにはそれぞれ別の範囲を使用する必要があります。
自動調整を無効化し、メンバーに構成されているlocalhostアドレスを使用するように設定します。これは、システム・プロパティ"tangosol.coherence.localport.adjust"で設定します(例: -Dtangosol.coherence.localport.adjust=false)。
各クラスタに一意のクラスタ名を構成します。これは、システム・プロパティtangosol.coherence.clusterを使用して行います。例:
-Dtangosol.coherence.cluster=SOA_Cluster1
これらのオプションの詳細は、次のURLにあるCoherenceクラスタの構成に関するドキュメントを参照してください。
http://download.oracle.com/docs/cd/E24290_01/coh.371/e22837/cluster_setup.htm
問題: サーバー移行のためwlsifconfigを実行すると、次の警告が表示されます。
sudo: sorry, you must have a tty to run sudo
解決方法: WebLogicユーザー('oracle')がバックグラウンドでsudoを実行できません。この問題を解決するには、次の行を/etc/sudoersに追加します。
Defaults:oracle !requiretty
詳細は、第14.5項「wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定」を参照してください。
問題: 次のトランザクション・タイムアウト・エラーがログに表示されます。
Internal Exception: java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start() failed on resource 'SOADataSource_soaedg_domain': XAER_NOTA : The XID is not valid
解決方法: トランザクション・タイムアウト設定をチェックし、JTAトランザクション・タイムアウトがDataSource XAトランザクション・タイムアウトより小さく、DataSource XAトランザクション・タイムアウトが(データベースの) distributed_lock_timeoutより小さいことを確認します。
ボックス構成が行われていない場合、SOAデータソースでは、XAタイムアウトがいかなる値にも設定されません。WebLogic Server管理コンソールで、「XAトランザクション・タイムアウトの設定」構成パラメータが選択解除されています。この場合、データソースでは、30に設定されているドメイン・レベルのJTAタイムアウトを使用します。また、データベースに対するdistributed_lock_timeoutのデフォルト値は60です。結果として、トランザクションがこのような値より短い耐用期間を持つことが予想されるシステムでは、SOAの構成が正常に機能します。特定の操作にかかると予想されるトランザクション時間に応じて、これらの値を調整してください。
問題: 複雑なルールを編集してSOAクラスタに保存すると、レプリケーション・メッセージの最大サイズを超えたことをレポートするエラー・メッセージが、サーバーの出力ファイルに表示されることがあります。例:
<rws3211539-v2.company.com> <WLS_SOA1> <ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'> <<WLS Kernel>> <> <> <1326464549135> <BEA-000403> <IOException occurred on socket: Socket[addr=/10.10.10.10,port=48290,localport=8001] weblogic.socket.MaxMessageSizeExceededException: Incoming message of size: '10000080' bytes exceeds the configured maximum of: '10000000' bytes for protocol: 't3'. weblogic.socket.MaxMessageSizeExceededException: Incoming message of size: '10000080' bytes exceeds the configured maximum of: '10000000' bytes for protocol: 't3'
解決方法: このエラーは、HTTPセッションで配置されクラスタに複製された、シリアル化されたルールのサイズが大きいために発生します。使用するルールのサイズに応じて、最大メッセージ・サイズを増やしてください。
最大メッセージ・サイズを増やす手順は次のとおりです。
WebLogic管理コンソールにログインします。
「サーバー」、「Server_name」、「プロトコル」、「全般」の順に選択します。
必要に応じて「最大メッセージ・サイズ」フィールドを変更します。
問題: サーバー移行用に構成され、リースにOracle RACデータベースを使用しているサーバーが、自身をシャットダウンし、次のようなメッセージが表示されます。
<Error> <Cluster> <BEA-000150> <Server failed to get a connection to the database in the past 60 seconds for lease renewal. Server will shut itself down.> <Critical> <Health> <BEA-310006> <Critical Subsystem ServerMigration has failed. Setting server state to FAILED. Reason: ServerXXX failed to renew lease in the database> <Critical> <WebLogicServer> <BEA-000385><Server health failed. Reason: health of critical service 'ServerMigration'failed> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED>
このようなメッセージが表示されるにもかかわらず、リース用のデータ・ソースは正常に動作し、接続テストも正常に実行されます。
解決方法: 様々なRAC DBインスタンスのクロックが同期していることを確認します。
