| Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B55899-03 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B55899-03 |
|
前 |
次 |
この章では、トポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップなどがあります。
この章の項目は次のとおりです。
SOAコンポジットをSOAエンタープライズ・デプロイメント・トポロジにデプロイする場合、LBRアドレス(soa.mycompany.com)にではなく、特定のサーバーのアドレスにデプロイします。LBRアドレスにデプロイするには、デプロイヤ・ノードから外部のLBRアドレスへの直接接続が必要になることがあり、その接続のために、システムのファイアウォールで追加ポートを開く必要が生じる場合があります。
B2Bの場合、アグリーメントのデプロイおよびメタデータのパージとインポートは、コマンドライン・ユーティリティではなく、B2BコンソールのGUIから実行してください。コマンドライン・ユーティリティを使用してこれらの操作を実行すると、B2Bシステムで不整合やエラーが発生することがあります。
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アーティファクトがEDG 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コンポジットが機能しなくなることがあります。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管理者ガイドの』の第8章「SOAコンポジット・アプリケーションの管理」を参照してください。正しく消去するには、提供されているスクリプトを常に使用します。composite_dn表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。
UMSドライバの構成情報は、SOAやBAMのクラスタに自動的には伝播されません。したがって、ユーザーが次の作業を行う必要があります。
UMSドライバの構成情報を、そのドライバを使用するEDGトポロジ内のすべてのサーバーに適用します。
サーバーの移行機能を使用すると、サーバーは別のノードのドメイン・ディレクトリに移動します。UMSドライバ構成は、フェイルオーバー・ノード内であらかじめ作成しておく必要があります。UMSドライバ構成ファイルの場所は次のとおりです。
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/servers/<server_name>/tmp/_WL_user/<ums_driver_name>/*/configuration/driverconfig.xml
(「*」はデプロイメント時にランダムに生成されるディレクトリ名、たとえば「3682yq」を表します)。
フェイルオーバーに備えてファイルを作成するには、強制的にサーバー移行を実行してファイルをソース・ノードからコピーしてください。たとえば、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で確認してください。
エンタープライズ・トポロジは、スケールアウトまたはスケールアップできます。トポロジのスケールアップとは、1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することです。トポロジのスケールアウトとは、新しいノードに新しい管理対象サーバーを追加することです。
この項の項目は次のとおりです。
トポロジをスケールアップするには、管理対象サーバーを実行しているノードがすでに存在していることと、その管理対象サーバーがSOAコンポーネントまたはWSM-PMを実行するように構成されていることが必要です。このノードには、共有記憶域内にWebLogic ServerホームとOracle Fusion Middleware SOAホームが存在します。このような既存のインストール(WebLogic Serverホーム、Oracle Fusion Middlewareホーム、ドメイン・ディレクトリなど)を使用して、新しい管理対象サーバーをWLS_SOAおよびWLS_WSMという名前で作成します。WLSまたはSOAのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
|
注意: BAMサーバーはアクティブ/パッシブ構成で動作するため、BAMサーバーの管理対象サーバーをスケーリングすることはできません。BAM Webアプリケーション・サーバーのスケーリングは可能です。第7.6項「WLS_BAM2からのBAMサーバー・システムのターゲット指定の解除」で説明するターゲット指定解除を行う必要があります。ここで説明するJMS構成作業は不要です。 |
Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。クローニング元の管理対象サーバーとして選択できるのは、新しい管理対象サーバーを実行するノード上にすでに存在しているサーバーです。
管理対象サーバーのクローンを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
「ロックして編集」をクリックして、クローニングする管理対象サーバー(たとえばWLS_SOA1)を選択します。
「クローンの作成」をクリックします。
新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。ここでは、WLS_SOA1が実行されていたノード1に新しいサーバーを追加するとします。
以降の手順は、新しいサーバーをSOAHOST1に追加する場合を想定しています。このホストではすでにWLS_SOA1が実行されています。
リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを指定します。推奨されているとおりにサーバー移行を使用する場合、サーバーを別のノードに移動できるようにVIP(浮動IPとも呼ばれる)を指定します。このVIPは、実行されている管理対象サーバーとは別のものを使用してください。
WLS_WSMサーバーの場合は、第4.17項「Oracle WSMでのJava Object Cacheの構成」で説明されているように、Java Object Cacheの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。同じ検出ポートは、同じノード内の複数のWSM-PMサーバーに使用できます。第4.17項で説明されている手順をWSM-PMサーバーごとに繰り返して、サーバー・リストを更新します。
SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。
|
注意: この手順は、WSM_PM管理対象サーバーをスケールアップする場合は不要です。WLS_SOA管理対象サーバーの場合にのみ実行してください。BAM Webアプリケーション・システムをスケールアップする場合も、この手順は不要です。 |
SOA、UMSおよび(適用可能な場合)BPM用のJMSサーバーを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリ・パスは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、JMS永続ストアのディレクトリとして指定します。
ORACLE_BASE/admin/<domain_name>/cluster_name/jms/SOAJMSFileStore_N
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 |
SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMS JMSサーバー用の新しい永続ストアを作成し(UMS JMSサーバーの作成方法は後述します)、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリ・パスは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、JMS永続ストアのディレクトリとして指定します。
ORACLE_BASE/admin/<domain_name>/cluster_name/jms/UMSJMSFileStore_N
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 |
|
注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。 |
UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、次のように共有記憶域上のディレクトリにする必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。SOAJMSFileStore_Nを新しいBPM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
BPMシステムの場合のみ: BPM用の新しいJMSサーバー(たとえばBPMJMSServer_N)を作成します。このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。
SOA、UMSおよび(適用可能な場合)BPM JMSモジュールのサブデプロイメント・ターゲットを更新し、作成した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を追加します)。保存してアクティブ化をクリックします。
新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順については、第5.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。
|
注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。
|
新しいサーバー用の永続ストアを構成します。これは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、他のノードから見える場所にする必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAN管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しい管理対象サーバー用のサーバー移行を構成します。
|
注意: これはスケールアップ操作であるため、ノードにノード・マネージャが存在していること、およびサーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済であることが必要です。新しいSOA管理対象サーバー用の浮動IPも、すでに存在している必要があります。 |
Oracle WebLogic Server管理コンソールを使用してサーバー移行を構成する手順は次のとおりです。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で、移行を構成するサーバーの名前(ハイパーリンクとして表示される)をクリックします。選択したサーバーの「設定」ページが表示されます。
「移行」サブタブをクリックします。
「移行の構成」セクションで、移行に参加するサーバーを「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、SOAHOST1(すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。
|
注意: 移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第4.7項「SOAHOST1での管理サーバーの起動」の手順を使用します。
次のように新しいサーバーを含むようにクラスタ・アドレスを更新します。
管理コンソールで、「環境」→「クラスタ」を選択します。
「SOA_Cluster」サーバーをクリックします。
SOA_Clusterの設定画面が表示されます。
「ロックして編集」をクリックします。
「クラスタ・アドレス」フィールドに新しいサーバーのアドレスとポートを入力します。たとえば、SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOST1VHN1 :8001と入力します。
変更を保存してアクティブ化します。
この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。
WLS_SOAn管理対象サーバーを停止します。
停止するには、run kill -9 <pid>を管理対象サーバーのPIDに対して実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを実行します。
ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルでは再起動されないことを示すメッセージが、ログに記録されます。
トポロジをスケールアウトするには、SOAまたはWSM-PMを構成した新しい管理対象サーバーを新しいノードに追加します。
この項の手順を実行する前に、次の要件が満たされていることを確認してください。
前提条件
SOAまたはWSM-PMを構成した管理対象サーバーが、トポロジ内の既存のノードで実行されている必要があります。
新しいノードから、WebLogic ServerおよびSOAの既存のホーム・ディレクトリにアクセスできる必要があります (新しいWLS_SOAまたはWLS_WSM管理対象サーバーを作成する場合、共有記憶域内の既存のインストールを使用します。WebLogic ServerやSOAのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpackとunpackを実行してドメイン構成をブートストラップする必要はあります)。
ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておくことをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールをアタッチするには、ORACLE_HOME/oui/bin/attachHome.shを使用します。ミドルウェア・ホーム・リストでWL_HOMEを追加または削除するには、<user_home>/bea/beahomelistファイルを編集します。次の手順を参照してください。
トポロジをスケールアウトする手順は次のとおりです。
新しいノード上に、既存のミドルウェア・ホーム(SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチするには、次のコマンドを実行します。
SOAHOSTn>cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
ミドルウェア・ホーム・リストを更新するには、$HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集します)、MW_HOMEをこのファイルに追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。
マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのIPをマッピングします。
Use the Oracle WebLogic Server Administration Console to clone WLS_SOA1/WLS_WSM1 into a new managed server. Name it WLS_SOAn/WLS_WSM-PMn, where n is a number. Assign it to the new machine created above.
|
注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。
このサーバーでサーバー移行を実行する場合(推奨)、ここでサーバーのVIP(浮動IPとも呼ばれる)を指定します。このVIPは、既存の管理対象サーバーとは別のものを使用してください。
WLS_WSMサーバーの場合は、第4.17項「Oracle WSMでのJava Object Cacheの構成」で説明されているように、Java Object Cacheの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。
SOA用、BPM用および(適用可能な場合)UMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。
|
注意: この手順は、WSM_PM管理対象サーバーをスケールアウトする場合は不要です。WLS_SOA管理対象サーバーの場合にのみ実行してください。BAM Webアプリケーション・システムをスケールアップする場合も、この手順は不要です。 |
SOA用およびUMS用のJMSサーバーを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述します)、SOAJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリ・パスは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、JMS永続ストアのディレクトリとして指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_N
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 |
SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMSJMSServer用の新しい永続ストアを作成し、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリ・パスは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、JMS永続ストアのディレクトリとして指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore _N
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 |
|
注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。 |
UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、次のように共有記憶域上のディレクトリにする必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。SOAJMSFileStore_Nを新しいBPM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
BPMシステムの場合のみ: BPM用の新しいJMSサーバー(たとえばBPMJMSServer_N)を作成します。このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したSOA JMSサーバーを追加します。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModuleUDDs」をクリックします(表の「名前」列にハイパーリンクとして表示される)。SOAJMSModuleUDDsの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSSubDMサブデプロイメントが表示されます。
|
注意: このサブデプロイメント・モジュールは、最初の2つのサーバー(WLS_SOA1およびWLS_SOA2)のJMS構成を共通分散宛先(UDD)スクリプト(soa-createUDD.py)によって更新した結果作成されたものです。このスクリプトは、EDGトポロジの初期設定に必要です。 |
このサブデプロイメントをクリックします。SOA用の新しいJMSサーバーSOAJMSServer_Nを、このサブデプロイメントに追加します。「保存」をクリックします。
UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。
SOA、UMSおよび(適用可能な場合)BPM JMSモジュールのサブデプロイメント・ターゲットを更新し、作成した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を追加します)。保存してアクティブ化をクリックします。
次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
SOAHOST1で次のコマンドを実行し、テンプレート・ファイルをSOAHOSTnにコピーします。
SOAHOST1> 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を構成します。手順については、第5.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。
|
注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。
|
新しいサーバー用の永続ストアを構成します。これは、第2.3項「共有記憶域と推奨ディレクトリ構造」で推奨されているとおり、他のノードから見える場所にする必要があります。
管理コンソールから、「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が実行されていることを確認します。
LBR上(https://soa.mycompany.com/soa-infra)のアプリケーションにアクセスします。アプリケーションが機能している必要があります。
|
注意: トポロジ内のHTTP Serverは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverのmod_wl_ohs.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングは、WebLogicClusterディレクティブにリストされているサーバーが最低1つは起動している場合のみ実行されます。 |
新しい管理対象サーバー用のサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいSOA管理対象サーバー用の浮動IPも、新しいノードにすでに存在します。 |
Oracle WebLogic Server管理コンソールにログインし、次の手順に従ってサーバー移行を構成します。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
表の「名前」列で、移行を構成するサーバー(ハイパーリンクとして表示される)を選択します。そのサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。
|
注意: マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要な容量計画をあらかじめ行ってください。 |
「サーバーの自動移行を有効化」を選択します。これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第4.7項「SOAHOST1での管理サーバーの起動」の手順を使用します。
次のように、新しいサーバーを含むようクラスタ・アドレスを更新します。
管理コンソールで、「環境」および「クラスタ」を選択します。
「SOA_Cluster」サーバーをクリックします。
SOA_Clusterの設定画面が表示されます。
「ロックして編集」をクリックします。
「クラスタ・アドレス」フィールドに新しいサーバーのアドレスとポートを入力します。たとえば、SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8001と入力します。
変更を保存してアクティブ化します。
この新しいサーバー用のサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。
管理対象サーバーWLS_SOAnのPIDに対してkill -9 <pid>を実行して、このサーバーを急に停止します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを実行します。
ノード・マネージャのコンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルで再び再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
表10-1は、11gのSOAエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。
表10-1 11gのSOAエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
ORACLEホーム(DB) |
CUSTDBHOST1およびCUSTDBHOST |
ユーザー定義 |
データ層 |
|
MWホーム(OHS) |
WEBHOST1およびWEBHOST2 |
|
Web層 |
|
MWホーム(SOAホームも含む) |
SOAHOST1およびSOAHOST2 |
SOAホームはMW_HOMEのサブディレクトリになります: |
アプリケーション層 |
|
インストール関連ファイル |
OraInventory、 |
該当せず |
表10-2は、11gのSOAエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。
表10-2 11gのSOAエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
ドメイン・ホーム |
SOAHOST1およびSOAHOST2 |
|
アプリケーション層 |
|
アプリケーション・アーティファクト(EARおよびWARファイル) |
SOAHOST1およびSOAHOST2 |
アプリケーション・アーティファクトの場所を調べるには、管理コンソールですべてのデプロイメントを表示する |
アプリケーション層 |
|
OHSインスタンス・ホーム |
WEBHOST1およびWEBHOST2 |
ORACLE_BASE/admin/<instance_name> |
Web層 |
|
Oracle RACデータベース |
CUSTDBHOST1およびCUSTDBHOST2 |
ユーザー定義 |
データ層 |
Oracle Fusion Middlewareのコンポーネントのバックアップとリカバリの詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。
|
注意: ORACLE_HOMEのバックアップは、B2B設定の一部であるXEngine構成が変更されたときに実行する必要があります。対象のファイルは、ORACLE_HOME/soa/thirdparty/edifecs/XEngineにあります。ORACLE_HOMEをバックアップするには、次のコマンドを実行してください。
SOAHOST1> tar -cvpf fmwhomeback.tar MW_HOME
|
この項の項目は次のとおりです。
第10.7.2項「soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する」
第10.7.4項「デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)」
第10.7.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) ...
解決方法: クラスタ内の最初のSOAサーバーの起動が失敗したためにポリシー移行が未完になります。正常に移行するには、次のようにsystem-jazn-data.xmlファイル内の<jazn-policy>要素を編集してbpm-services.jarに権限を付与します。
<grant>
<grantee>
<codesource>
<url>file:${oracle.home}/soa/modules/oracle.soa.workflow_11.1.1/bpm-
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.>
解決方法: ノードの障害発生後にノードを復旧させるときに、ドメイン・ディレクトリに共有記憶域が使用されている場合、ロック・クリーンアップの失敗が原因で、管理サーバーのログにこのエラーが記録されることがあります。このエラーを解決するには、ファイルORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/servers/AdminServer/data/ldap/ldapfiles/ EmbeddedLDAP.lokを削除します。
問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。
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サーバーの移行を試行した後でも、このサーバーが使用するVIPがフェイルオーバー・ノード内で有効化されていません(フェイルオーバー・ノードでifconfigを実行しても、どのインタフェースのVIPも報告されません)。コマンド「sudo ifconfig $INTERFACE $ADDRESS $NETMASK」を実行しても、そのIPはフェイルオーバー・ノード内で有効化されません。
解決方法: sudo実行時にパスワード入力を要求するような権限と構成を設定しないでください。パスワード入力を要求しなくてもsudoが動作するようにsudoが構成されていることを、システム管理者に確認してください。
問題: サーバー移行は正常に実行されますが(SOA/BAMサーバーがフェイルオーバー・ノード内で再起動されます)、<仮想ホスト名>:8001/soa-infra URLにWebブラウザからアクセスできません。元のホストではすでにサーバーが強制終了(kill)されており、フェイルオーバー・ノードのノード・マネージャでは、VIPが移行済でサーバーが起動していることが報告されます。SOAサーバーが使用するVIPに対して、クライアントのノード(ブラウザが使用されているノード)からpingを実行しても応答がありません。
解決方法: arpingコマンドがノード・マネージャによって実行されてARPキャッシュが更新されましたが、この更新が適切にブロードキャストされていません。この場合、そのノードが外部ノードからは到達不能になります。nodemanager.propertiesファイルにMACBroadcastを追加するか、次のように手動でarpingを実行してください。
/sbin/arping -b -q -c 3 -A -I $INTERFACE $ADDRESS > $NullDevice 2>&1
$INTERFACEは、VIPが有効化されているネットワーク・インタフェース、$ADDRESSはVIPアドレスです。
問題: 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およびLBRを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。
解決方法: この問題は、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、管理コンソールがその変更を反映しようとすると発生します。変更内容によっては、管理サーバーのリスニング・アドレスにリダイレクトすることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、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を実行します)。通信が有効になったら、(同じドメイン・ディレクトリで他のサーバーが正常に稼働している場合に)新しいノードに対してドメインのpackとunpackを再度実行するか、OARCLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/nodemanager/ディレクトリを削除してサーバーを再起動します。
この項の項目は次のとおりです。
EDG本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters(RAC)の場合、データベース接続はOracle RACのVIPとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。そのように構成できない場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルの*SQLNET.EXPIRE_TIME=n*パラメータを設定してください。nは分単位の数値です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定してください。
Oracle Fusion Middleware監査フレームワークは、Oracle Fusion Middleware 11gで追加された新しいサービスであり、ミドルウェア製品ファミリの集中監査フレームワークです。このフレームワークでは、Oracle Platform Security Services(OPSS)やOracle Web Servicesなどのプラットフォーム・コンポーネントに対して監査サービスが提供されます。また、Oracle固有のJavaEEコンポーネントをはじめ、様々なJavaEEアプリケーションのフレームワークとしても機能します。また、このようなJavaEEアプリケーションで、アプリケーション固有の監査イベントを作成できます。ミドルウェアのOracleコンポーネントのうちJavaEE以外のもの、たとえばCやJavaSEのコンポーネントについても、JavaEEアプリケーションと同様、エンドツーエンドのフレームワーク構造を実現します。
図10-1は、Oracle Fusion Middleware監査フレームワーク・アーキテクチャの概要図です。
Oracle Fusion Middleware監査フレームワークを構成する主なコンポーネントは次のとおりです。
Oracle Fusion Middleware監査フレームワークに統合される監査対応コンポーネント用のAPIです。実行時にアプリケーションからこのAPIを呼び出すと、アプリケーション・コード内で発生した特定のイベントに関する必要な情報の監査を行うことができます。監査対象のイベントのコンテキストを示すために、イベントの詳細情報、たとえばユーザー名や属性を、このAPIを通してアプリケーション側で指定できます。
Oracle Fusion Middleware監査フレームワークには、汎用イベントがあらかじめ用意されており、アプリケーション監査イベントを簡単にマッピングできるようになっています。この汎用イベントとは、認証などの一般的なイベントです。このフレームワークでは、アプリケーション側でアプリケーション固有イベントも定義できます。
このイベント定義および構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成の更新は、Enterprise Manager(UI)およびWLST(コマンドライン・ツール)から実行できます。
バスストップとは、監査リポジトリにプッシュされる前の監査データが格納されるローカル・ファイルです。データベース・リポジトリが1つも構成されていない場合は、このバスストップ・ファイルをファイルベースの監査リポジトリとして使用できます。バスストップ・ファイルは単純なテキスト・ファイルであり、特定の監査イベントの検索も簡単に実行できます。データベース・リポジトリがある場合、バスストップはコンポーネントと監査リポジトリの間の中間ファイルになります。ローカル・ファイルは、構成したアップロード間隔に基づいて、定期的に監査リポジトリにアップロードされます。
その名のとおり、監査ローダーの機能は、監査バスストップのファイルを監査リポジトリにロードすることです。プラットフォームおよびJavaEEアプリケーションの監査の場合、JavaEEコンテナ起動時に監査ローダーも起動されます。システム・コンポーネントの場合、監査ローダーは定期的に生成されるプロセスになります。
監査リポジトリに格納されるのは、事前定義されたOracle Fusion Middleware監査フレームワークのスキーマです。これは、リポジトリ作成ユーティリティ(RCU)によって作成されます。構成が完了すると、すべての監査ローダーがリポジトリを認識し、そのリポジトリに定期的にデータをアップロードするようになります。監査データは監査リポジトリ内に蓄積されるため、時間とともに増加します。監査リポジトリには、他のアプリケーションが使用している運用データベースではなく、監査専用のスタンドアロンのRDBMSを使用するのが理想的です。高可用性構成の場合は、Oracle Real Application Clusters(RAC)データベースを監査データ・ストアとして使用することをお薦めします。
Oracle Business Intelligence Publisher
監査リポジトリ内のデータは、Oracle Business Intelligence Publisherの事前定義済レポートとして公開されます。このレポートでは、監査データを様々な条件に基づいてドリルダウンできます。例:
ユーザー名
時間範囲
アプリケーション・タイプ
実行コンテキスト識別子(ECID)
Oracle Fusion Middleware監査フレームワークの初歩的な情報は、Oracle Fusion Middlewareセキュリティ・ガイドの「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。
Oracle Fusion Middleware監査フレームワークのリポジトリの設定方法の詳細は、Oracle Fusion Middlewareセキュリティ・ガイドの監査の構成および管理に関する章を参照してください。
EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成は含まれません。バスストップ・ファイルへの監査データの出力、および監査ローダーの構成は、製品をインストールした後に実行できるようになります。最大の懸念事項は、監査データが格納される監査データベース・リポジトリです。監査データはサイズが大きく、過去のデータが蓄積されていくため、他のミドルウェア・コンポーネントの運用ストアとは別に、専用のデータベースを用意することを強くお薦めします。
