| Oracle Fusion Middlewareリリース・ノート 11gリリース1（11.1.1） for Microsoft Windows x64 B55938-01 |
|
 戻る |
 次へ |
この章では、Oracle Fusion Middlewareの高可用性とエンタープライズ・デプロイメントに関連する問題について説明します。内容は次のとおりです。
この項では、一般的な問題および回避方法について説明します。内容は次のとおりです。
クラスタ内のOracle Portal、Oracle Forms、Oracle ReportsおよびOracle Discovererで管理対象サーバーにpackおよびunpackコマンドを使用する場合、必ず第1ノードから第2ノードにアプリケーションをコピーしてください（これらは外部にステージングされたアプリケーションであるためです）。packおよびunpackコマンドの使用方法の詳細は、『Oracle WebLogic Server Creating Templates and Domains Using the Pack and Unpack Commands』を参照してください。
Oracle Fusion Middlewareでは、管理対象サーバーのクラスタに対するOracle HTTP Serverルーティングに関して、mod_wls_ohsのみがサポートされ、mod_wlはサポートされません。
Oracle Fusion Middlewareの高可用性デプロイメントでは、『Oracle Fusion Middleware高可用性ガイド』およびOracle Fusion Middlewareのエンタープライズ・デプロイメント・ガイドに記載されている構成手順のみを使用することを強くお薦めします。
この項では、構成に関する問題およびその回避方法について説明します。内容は次のとおりです。
クラスタ環境では、ノードが別のコンピュータ上にある場合、その2番目のノードにXEngineはインストールされません。これは、（2番目のノードで自動的に実行されない）構成ウィザードを実行した場合にのみXEngineの抽出が行われるためです。この問題を回避するには、XEngineの抽出を手動で実行します。XEngineの抽出後、サーバーを再起動する必要があります。
クラスタ環境では、各ノードは、インバウンド再試行用にメモリー内に独自のHasmapを維持します。jca.retry.countプロパティは、インバウンド再試行機能で3と指定されます。ただし、ノードごとに3回試行されます。結果として、クラスタ環境に2つのノードがある場合、合計再試行回数は6になります。
クラスタ内のすべてのマシンは、同じタイムゾーンに存在する必要があります。WANクラスタは、Oracle Fusion Middlewareの高可用性ではサポートされません。同じタイムゾーンのマシンであっても、コマンドラインで起動されると問題が発生する可能性があります。サーバーの起動には、ノード・マネージャを使用することをお薦めします。
JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している状態で、予期しないマシン障害の後にOracle WebLogic Serverが再起動しない場合、次のエラーがサーバー・ログ・ファイルに記録されている可能性があります。
<MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent
store "_WLS_server_soa1" could not be deployed:
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_SOA1000000.DAT"
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_SOA1000000.DAT"
at weblogic.store.io.file.Heap.open(Heap.java:168)
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:88)
トランザクション・ログまたはJMS永続ストア・ディレクトリがNFSを使用してマウントされている場合、予期しないマシン障害が発生すると、WebLogic Serverの再起動またはサーバー移行全体が失敗する可能性があります。WebLogic Serverは、同じWebLogic Serverの2つのインスタンスが偶然起動した場合にデータ破損が発生しないように、JMSデータおよびトランザクション・ログの格納に使用しているファイルに対するロックを保持します。NFSプロトコルはステートレスであり、ストレージ・デバイスはマシン障害を認識できないため、ロックを解放しません。このため、予期しないマシン障害とそれに続く再起動の後に、WebLogic Serverが以前ロックされたファイルに対するロックを取得しようとしても、失敗する可能性があります。ストレージ・デバイスでNFSにマウントされたディレクトリに格納されているファイルのロックに関する追加情報は、使用しているストレージ・ベンダーのドキュメントを参照してください。
次のいずれかの解決策を使用してログとデータファイルのロックを解除してください。
解決策1
手動でログおよびJMSデータファイルのロックを解除し、サーバーを起動します。これを行うには、ロックされた永続ストア・ファイルのコピーを作成して、後続の操作にそのコピーを使用します。ロックされた永続ストア・ファイルのコピーを作成するには、ファイル名を変更してから、そのファイルをコピーして元の名前に戻します。次の手順例では、トランザクション・ログが/shared/tlogsディレクトリに格納されており、JMSデータが/shared/jmsディレクトリに格納されていると仮定します。
cd /shared/tlogs mv _WLS_SOA_SERVER1000000.DAT _WLS_SOA_SERVER1000000.DAT.old cp _WLS_SOA_SERVER1000000.DAT.old _WLS_SOA_SERVER1000000.DAT cd /shared/jms mv SOAJMSFILESTORE_AUTO_1000000.DAT SOAJMSFILESTORE_AUTO_1000000.DAT.old cp SOAJMSFILESTORE_AUTO_1000000.DAT.old SOAJMSFILESTORE_AUTO_1000000.DAT mv UMSJMSFILESTORE_AUTO_1000000.DAT UMSJMSFILESTORE_AUTO_1000000.DAT.old cp UMSJMSFILESTORE_AUTO_1000000.DAT.old UMSJMSFILESTORE_AUTO_1000000.DAT
この解決策では、WebLogicのファイル・ロック・メカニズムにより、同じサーバーの複数のインスタンスが偶然起動した場合に発生する可能性のあるデータ破損からの保護が引き続き提供されます。ただし、サーバーは、予期しないマシン障害の後に手動で再起動する必要があります。ファイル・ストアでは、大量のデータを格納する場合、連続した番号が付けられた複数の.DATファイルが作成されます。この場合、必要に応じてすべてのファイルをコピーし、その名前を変更する必要があります。
解決策2
ネイティブI/Oのwlfileio2ドライバを無効化して、WebLogicのファイル・ロックを無効にします。次の手順例では、ドライバの共有オブジェクトをバックアップの場所に移動することで、事実上ドライバを削除しています。
cd WL_HOME/server/native/platform/cpu_arch mv libwlfileio2.so /shared/backup
この解決策では、WebLogicのロック機能が無効化されるため、自動的なサーバーの再起動とフェイルオーバーに成功します。ただし、この場合、パフォーマンスが低下する可能性があります。この解決策を使用する場合は、慎重に行ってください。データベース表を使用した追加のロック・メカニズムを適用し、同じWebLogic Serverの複数のインスタンスが自動的に再起動しないように、必ずデータベースに基づいたリース・オプションを構成してください。人為的エラーを回避し、任意の時点でサーバーのただ1つのインスタンスを手動で起動するため、追加の手続き型の予防措置を実施する必要があります。同様に、特別な予防措置を実行して、同じディレクトリを参照する同じ名前の1つのストアを複数のドメインが保持しないようにする必要があります。
高可用性のPortal実装では、通常、ロード・バランサを通じてリクエストをループバックするようにParallel Page Engineを構成する必要があります。Portalループバック用にロード・バランサを構成する場合、ロード・バランサがポート変換を使用して構成されていないことを確認してください。次に例を示します。
正しい構成: ロード・バランサがリクエストをポート7777でリスニングし、Web Cacheポート7777に転送。
間違った構成: ロード・バランサがリクエストをポート8888でリスニングし、Web Cacheポート7777に転送。
一部の環境では、コンポーネントが再起動またはフェイルオーバーされた直後に、そのコンポーネントの間違ったステータスがOracle WebLogic Fusion Middleware Controlに表示されることがあります。
スケール・アウトされたクラスタ環境で、大量のBPELインスタンスがデータベースに蓄積されると、データベースのパフォーマンスが低下し、MANY THREADS STUCK FOR 600+ SECONDSというエラーが生成されます。
このエラーを回避するには、データベースから古いBPELインスタンスを削除してください。
XA以外の環境では、ローカル・トランザクションにおいて、メッセージがインバウンド・アダプタからエンドポイントまでただ1回のみ配信されることがMQSeriesアダプタにより保証されません。この場合、インバウンド・メッセージがエンドポイントにパブリッシュされ、トランザクションがコミットされる前にSOAサーバーが停止すると、インバウンド・メッセージはロールバックされ、同じメッセージが再度デキューされてエンドポイントにパブリッシュされます。これにより、アウトバウンド・キューに余分なメッセージが作成されます。
XA環境では、MQメッセージは失われませんが、一貫性のない状態であるためキュー・マネージャによって保留されます。保留メッセージを取得するには、キュー・マネージャを再起動します。
Oracle Human Workflowがトランザクションをコミットすると、制御は即座にBPELに戻され、BPELでほぼ同時にそのトランザクションがコミットされます。この間にOracle RACインスタンスが停止すると、フェイルオーバーでメッセージ送信が再試行され、重複タスクが発生する可能性があります。重複タスクは、2つの形式で出現する可能性があります。つまり、ワークリスト・アプリケーションに重複タスクが出現するか、またはリカバリ不可能なBPELインスタンスが作成されます。このBPELインスタンスは、BPELリカバリに出現します。該当タスクはすでに完了しているため、このBPELインスタンスはコンシューマとしてリカバリできません。
次の情報は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の第10章「トポロジの管理」に記載されています。
管理サーバー・ノードの計画的な停止（管理サーバー・マシンの再起動または停止）を実行する場合、管理サーバー自体が停止する前にOSのNFSサービスが無効になる可能性があります。これにより、OSレベルでのサービスの構成によっては、管理サーバーのドメイン・ディレクトリでファイルの欠落が検出され、他のノードのドメイン・ディレクトリでそれらの削除が行われる可能性があります。その結果、フレームワークでdomain_dir/fmwconfig/のファイルの一部が削除される可能性があります。この動作は、通常、マシン障害、停電、マシン・クラッシュなどの計画外の停止時間には発生しません。この動作を回避するには、再起動を実行する前に管理サーバーを停止します。別の方法としては、管理サーバー・プロセスより後にNFSサービスが無効化されるように、適切なOS構成を使用してサービスの優先順位を設定します。サービスの順序に対応するために必要な構成の詳細は、使用しているOSの管理ドキュメントを参照してください。
クラスタ構成に次のものが含まれる場合:
クラスタ通信用のユニキャスト・メッセージング機能
異なる物理マシン上で稼働する複数のクラスタ・サーバー
クラスタの各サーバーに指定されたリスニング・アドレスなし
必ず次のことを実行してください。
各クラスタ・サーバーのクラスタ・ブロードキャスト・プロトコル用にカスタム・ネットワーク・チャネルを定義します。チャネルの名前は、サーバーごとに同じである必要があります。
リスニング・アドレスおよびポートを、サーバーが稼働しているマシンのIPまたはポートのいずれかに設定します。
クラスタ用のユニキャスト・ブロードキャスト・チャネルの名前を、新しく定義したカスタム・チャネルに設定します。このチャネルは、アウトバウンド対応である必要があります。
SOA B2B TCP/IPプロトコルでは、高可用性フェイルオーバーはサポートされません。このことは、主にHL7 over MLLPを使用したデプロイメントに影響します。クラスタ環境のインバウンド通信では、すべてのB2Bサーバーがアクティブであり、インバウンド・トラフィックに公開されたアドレスは、ロード・バランサの仮想サーバーです。また、アクティブな管理対象サーバーが使用できなくなる停止時間には、永続TCP/IP接続が失われ、クライアントは接続を再確立する必要があります。
Oracle HTTP ServerからWLS_SOAサーバーで公開されているコンポジットのエンドポイントに対するリクエストのルーティングは、WLS_SOAサーバーのステータスが「実行中」になると即座に開始されます。SOAインフラ・アプリケーションは、WLS_SOAサーバーが実行中であるかどうかにかかわらず、使用できない可能性があります。また、コンポジット・デプロイメントおよびクラスタ間の同期は、WLS_SOAサーバーの起動後、少し時間がかかる場合があります。このため、起動されるサーバーで必要なコンポジットがまだ使用できない状態で、Oracle HTTP Serverは、（ノードでのフェイルオーバー、サーバー移行または単純な再起動の後に）SOAインフラのコンテキストURLにルーティングを開始する可能性があります。エンドポイントの起動時に404 HTTPエラー・コードが発生することを防ぐため、クライアントに適切な再試行コードを含めることをお薦めします。コンポジットの完全な同期が完了すれば、エラーは停止します。
この項では、ドキュメントの訂正箇所を示します。内容は次のとおりです。
この項には、『Oracle Fusion Middleware高可用性ガイド』の訂正箇所が含まれます。
Oracle Fusion Middleware 11gドキュメント・セットの複数のマニュアルには、Oracle Fusion Middlewareシステムの要件、前提条件、仕様および動作保証情報に関する情報が含まれます。
Oracle Fusion Middlewareシステムの要件、前提条件、仕様および動作保証情報に関する最新情報は、Oracle Technology Networkの次のドキュメントを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。
Oracle Fusion Middlewareの動作保証情報は、次のURLを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。
『Oracle Fusion Middleware高可用性ガイド』のシステム・クロックの同期に関する項には、高可用性のSOAデプロイメントで各クラスタ・ノードのシステム・クロックを同期することをお薦めすると記載されています。
クラスタでのシステム・クロックの同期は、推奨事項ではなく、必須要件です。
Oracle Access Managerのコンポーネントでは、Oracle Access Protocol（OAP）およびOracle Identity Protocol（OIP）という独自仕様のプロトコルを使用して相互に通信します。
Oracle Access Protocol（OAP）により、ユーザーの認証および認可時にアクセス・システム・コンポーネント（Policy Manager、Access Manager、WebGateなど）間で通信を実行できます。このプロトコルは、以前はNetPoint Access Protocol（NAP）またはCOREid Access Protocolと呼ばれていました。
Oracle Identity Protocol（OIP）は、アイデンティティ・システム・コンポーネント（Identity ServerやWebPassなど）とWebサーバー間の通信を制御します。このプロトコルは、以前はNetPoint Identity Protocol（NIP）またはCOREid Identity Protocolと呼ばれていました。
『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management』のアプリケーション層の理解に関する項には、NAP（Network Access Protocol）ポートに関する記載が含まれますが、正しくはOracle Access Protocol（OAP）ポートに関する内容になります。また、この項にはNIP（Network Identity Protocol）ポートに関する記載も含まれますが、正しくはOracle Identity Protocol（OIP）ポートに関する内容になります。
『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management』のWeb層の理解に関する項には、Network Access Protocol（NAP）に関する記載が含まれますが、正しくはOracle Access Protocol（OAP）に関する内容になります。
『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management』のOracle Identity Managementのエンタープライズ・デプロイメント・トポロジに関する表には、NAPプロトコルに関する記載が2つ含まれますが、正しくはOAPプロトコルに関する内容になります。この表には、NIPプロトコルに関する記載も2つ含まれますが、正しくはOIPプロトコルに関する内容になります。
『Oracle Fusion Middleware高可用性ガイド』のWLS_REPORTSおよびWLS_REPORTS1の再起動に関する項の前に、Oracle Reportsサーバー・クラスタを作成するための次の手順が欠落しています。
データベース・レポート・キューでReportsクラスタを作成することで、すべてのReportsサーバーを同じキューにリンクできます。この手順のメリットは、サーバーに予備の容量がある場合に、キュー内で次のレポートを取得および実行することで、負荷を分散できることです。また、いずれかのクラスタ・メンバーが使用できなくなったときに、別のReportsサーバーがその状態を検出し、障害サーバーが処理していたレポートを実行できます。
Reportsクラスタを作成するには、APPHOST1とAPPHOST2の両方のrwservlet.propertiesファイルにクラスタ・エントリを追加します。
クラスタAPPHOST1
DOMAIN_HOME/user_projects/domains/ReportsDomain/servers/WLS_REPORTS/stage/reports/reports/configurationディレクトリに存在するrwservlet.propertiesファイルを編集します。
次の行を追加します。
<cluster clustername="cluster_reports" clusternodes="rep_wls_reports1_APPHOST2_reports2"/>
|
注意: clusternodesの値は、APPHOST2に存在するrwservlet.propertiesファイルの<server>タグに記載されている値です。 |
|
注意: clusternodesパラメータには、ローカルのReportsサーバーを除くクラスタ内のすべてのReportsサーバーが（カンマ区切りで）リストされている必要があります。 |
クラスタAPPHOST2
DOMAIN_HOME/user_projects/domains/ReportsDomain/servers/WLS_REPORTS1/stage/reports/reports/configurationディレクトリに存在するrwservlet.propertiesファイルを編集します。
次の行を追加します。
<cluster clustername="cluster_reports" clusternodes="rep_wls_reports_APPHOST1_reports1"/>
|
注意: clusternodesの値は、APPHOST1に存在するrwservlet.propertiesファイルの<server>タグに記載されている値です。 |
|
注意: clusternodesパラメータには、ローカルのReportsサーバーを除くクラスタ内のすべてのReportsサーバーが（カンマ区切りで）リストされている必要があります。 |
この項には、Oracle Fusion Middlewareのエンタープライズ・デプロイメント・ガイドの訂正箇所が含まれます。
『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の第2章「データベースおよび環境の事前構成」には、次の情報が欠落しています。
クォーツ
Oracle SOA Suiteでは、クォーツを使用してデータベースのジョブおよびスケジュールを管理します。クォーツ・ジョブをクラスタ内の異なるOracle SOAノードで実行するには、クラスタ・ノードのシステム・クロックを同期させる必要があります。
『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のSOAエンタープライズ・デプロイメント・トポロジに対するコンポジットおよびアーティファクトのデプロイに関する項には、次の情報が欠落しています。
SOA Fusion Order Demoをデプロイする場合、FODのREADMEファイルに記載されたデプロイ手順に加え、次の追加手順が必要となります。
earファイルが各ノードにコピーされるように、Webアプリケーションのbuild.xmlファイルに含まれるnostageプロパティをfalseに変更します。FOD_dir\CreditCardAuthorization\binおよびFOD_dir\OrderApprovalHumanTask\binディレクトリに存在するCreditCardAuthorizationおよびOrderApprvalHumanTask build.xmlファイルを編集し、次のフィールドを変更します。
<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>
デプロイメントがSOAクラスタを対象とし、個々のサーバーを対象としないようにWebアプリケーションのターゲットを変更します。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アーティファクトがEDG 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')
次のように変更します。
# lookup the SOAJMSModule - it's a system resource
jmsSOASystemResource = lookup("SOAJMSModuleUDDs","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('SOAJMSSubDM')
.
topicbean = jmsResource.lookupTopic('DemoSupplierTopic')
if topicbean is None:
print "Creating DemoSupplierTopic jms topic"
demoJMSTopic =
jmsResource.createDistributedTopic("DemoSupplierTopic")
demoJMSTopic.setJNDIName('jms/DemoSupplierTopic')
demoJMSTopic.setSubDeploymentName('SOAJMSSubDM')
『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の第10章「トポロジの管理」には、次の情報が欠落しています。
EDGトポロジでSOAおよびBAMコンポーネントに適用される構成変更:
クラスタ環境でOracle SOA Suiteを使用している場合、あるノードでOracle Enterprise Managerにより構成プロパティを変更する場合、その変更はすべてのノードで行う必要があります。構成プロパティは、Oracle Enterprise Managerの「SOAインフラストラクチャ」メニューの次のオプションを通じて設定します。
「管理」→「システムMBeanブラウザ」→「SOA管理」→任意のプロパティ選択での「サービスと参照」→「プロパティ」タブ。
また、BAM EDGトポロジでBAM Serverの構成を変更する場合、次のことを考慮してください。
サーバー移行が使用されるため、BAM Serverは異なるノードのドメイン・ディレクトリに移動されます。フェイルオーバー・ノードでBAM Serverの構成を事前に作成しておく必要があります。BAM Serverの構成ファイルは、次のディレクトリにあります。
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/servers/<servername>/tmp/_WL_user/oracle-bam_11.1.1 /*/APP-INF/classes/config/
*は、デプロイ中にOracle WebLogic Serverによってランダムに生成される3682yqなどのディレクトリ名を表します。
フェイルオーバーに備えてファイルを作成するため、強制的にサーバー移行を実行し、ソース・ノードからファイルをコピーできます。たとえば、BAMの場合、次のようになります。
BAMHOST1でWLS_BAM1のドライバを構成します。
強制的にWLS_BAM1をBAMHOST2にフェイルオーバーします。フェイルオーバー・ノードのBAM Serverのディレクトリ構造を確認します。
cd ORACLE_BASE/admin/<domain_name>/mserver/
<domain_name>/servers/<servername>/tmp/_WL_user/oracle-bam_11.1.1
/*/APP-INF/classes/config/
*は、デプロイ中にOracle WebLogic Serverによってランダムに生成される3682yqなどのディレクトリ名を表します。
BAM Serverの構成ファイルを次のようにBAMHOST1からBAMHOST2にリモート・コピーします。
BAMHOST1> scp
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>
/servers/<servername>/tmp
/_WL_user/oracle-bam_11.1.1/*/APP-INF/classes/config/* oracle@BAMHOST2:
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/servers/<servername>/tmp
/_WL_user/oracle-bam_11.1.1/*/APP-INF/classes/config/
『Oracle Fusion Middleware高可用性ガイド』の第6章「Oracle ADFおよびWebCenterアプリケーションの高可用性の構成」には、ディスカッション・フォーラムをマルチキャストからユニキャストに変換する手順が欠落しています。
ディスカッション・フォーラムをマルチキャストからユニキャストに変換するには、次の手順を実行します。
手順1: Oracle Coherence構成ファイルのシステム・プロパティの有効化
デフォルトのOracle Coherence設定を上書きするため、コヒーレンス.xmlファイルの関連システム・プロパティを設定します。ディスカッション・フォーラム用にtangosol-coherence-override.xmlファイルを編集します。このファイルは、ディスカッション・フォーラムとともにデプロイされるcoherence.jarの一部です。このファイルを次のように変更します。
WLS_Servicesデプロイメント・ディレクトリのcoherence.jarからtangosol-coherence-override.xmlファイルを抽出します（jar xvf coherence.jar）。
ファイルのcluster-config要素内に次の行を追加します。
<unicast-listener>
<well-known-addresses>
<socket-address id="1">
<address system-property="tangosol.coherence.wka1"></address>
<port system-property="tangosol.coherence.wka1.port">8088</port>
</socket-address>
<socket-address id="2">
<address system-property="tangosol.coherence.wka2"></address>
<port system-property="tangosol.coherence.wka2.port">8088</port>
</socket-address>
....etc....
<socket-address id="9">
<address system-property="tangosol.coherence.wka9"></address>
<port system-property="tangosol.coherence.wka9.port">8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
jarファイルを作成してサーバーを再起動します（jar cvf coherence.jar *）。
手順2: 起動パラメータの追加
関連する起動パラメータを追加するには、次の手順を実行します。
Oracle WebLogic Server管理コンソールで、「サーバー」→WLS_Services1→「構成」→「サーバーの起動」を選択します。
「引数」ボックスで、次の引数を追加します。
-Dtangosol.coherence.wka1=Host1 -Dtangosol.coherence.wka2=Host2 -Dtangosol.coherence.localhost=Host1 -Dtangosol.coherence.wka1.port=8088 -Dtangosol.coherence.wka2.port=8088
Host1は、WLS_Services1が実行されている場所です。
WLS_Services2で、Host1をHost2に、Host2をHost1に置き換えて手順1と2を繰り返します。
WLS_Servicesサーバーを再起動します。
手順3: 変更の確認
変更を確認するには、次の手順を実行します。
ディスカッション・フォーラム管理パネルにログインします。
左側のペインの「キャッシュ設定」を選択します。
画面の一番下で、「クラスタリング」が「有効」に設定されていることを確認します。
クラスタのすべてのメンバーに対して手順1〜3を繰り返します。
サーバーがクラスタに参加すると、画面の一番上に表示されます。
