10gリリース3（10.1.3.1.0）
B31835-01
 目次 |
 索引 |
| Oracle Application Server 高可用性ガイド 10gリリース3（10.1.3.1.0） B31835-01 |
|
この章では、Oracle SOA Suiteの高可用性ソリューションについて説明します。Oracle SOA Suiteは、サービス指向アーキテクチャ・システムのデプロイおよび管理に使用する一連のコンポーネントです。
この章では、次のOracle SOA Suiteコンポーネントの高可用性について説明します。
高可用性トポロジにOracle SOA Suiteコンポーネントをインストールするには、次の2つの手順を実行する必要があります。
Oracle SOA Suiteは、メインのOracle Application Server CD-ROMからインストールしないでください。
拡張インストール・オプションを必ず選択してください。Oracle SOA Suiteコンポーネントが自動インストールされる基本インストール・オプションは使用しないでください。このオプションでは、インストールするコンポーネントを選択できません。基本インストール・オプションは、非高可用性トポロジを構築する場合にのみ使用します。
必要なOracle SOA Suiteコンポーネントのインストールには、それぞれのコンポーネントCD-ROM（たとえば、Oracle BPEL Process Manager CD-ROMやOracle Enterprise Service Bus CD-ROM）を使用します。これによって、目的のコンポーネントのみをインストールできます。Oracle Enterprise Service Busの高可用性トポロジでは、ESBリポジトリ・サーバーとESBランタイム・サーバーを異なるOracleホームにインストールする必要があるため、これはOracle Enterprise Service Busの場合に特に重要です。
この項では、Oracle BPEL Process Managerの高可用性について説明します。この項の項目は次のとおりです。
BPEL（ビジネス・プロセス実行言語）はXMLベースの言語であり、これを使用すると別個のサービスを1つのエンドツーエンド・プロセス・フローにアセンブルできます。Oracle BPEL Process Managerには、BPELビジネス・プロセスの設計、配置および管理を行うためのフレームワークが用意されています。
Oracle BPEL Process ManagerはJ2EEアプリケーションの1つであり、様々なアプリケーション・サーバーで実行できます。これはステートレス・アプリケーションですが、データベースを「デハイドレーション・ストア」として使用して、プロセスの状態に関する情報を格納します。
Oracle BPEL Process Managerの詳細は、『Oracle BPEL Process Manager管理者ガイド』および『Oracle BPEL Process Manager開発者ガイド』を参照してください。
Oracle BPEL Process Managerのアーキテクチャもステートレスなため、高可用性の実現が簡単になります。図5-1に、Real Application Clustersデータベースをデハイドレーション・ストアとして使用した、アクティブ/アクティブ・トポロジでのOracle BPEL Process Managerを示します。
アクティブ/アクティブ・トポロジには、次のような特性があります。
soapServerUrlおよびsoapCallbackUrlプロパティをロード・バランサのURLに設定します。
jndiProviderURL = "ormi://localhost/Service"
かわりに次のように指定します。
jndiProviderURL = "opmn:ormi://host1:port1:oc4j/Service, opmn:ormi://host2:port2:oc4j/Service"
これによって、JVMレベルの高可用性を実現できます。1つのOC4Jインスタンスに対して複数のJVMプロセスを実行している場合、OPMNでは、使用可能なJVMの数に基づいて独立したJNDIオブジェクトにリクエストをルーティングできます。
アクティブ/アクティブ・トポロジにBPELプロセスをデプロイする手順は次のとおりです。
この項では、SOAP/WSDLまたはOracle BPEL Process Manager Java APIを使用してBPELプロセスを起動する場合に必要な変更について説明します。
SOAP/WSDLを使用する場合は、ノードのホスト名ではなく、ロード・バランサの仮想サーバー名を使用する必要があります。
Oracle BPEL Process Manager Java APIを使用する場合は、アクティブ/アクティブ・トポロジで各ノードのホスト名をリストします。前述のjndiProviderURLの例を参照してください。
高可用性を実現するには、Real Application Clustersデータベースなどの高可用性データベースでデハイドレーション・ストアを実行する必要があります。Real Application Clustersデータベースを使用すると、すべてのコンポーネントで高可用性を実現できます。
デハイドレーション・ストアにReal Application Clustersデータベースを使用する場合、構成に対し、次の変更を行う必要があります。
data-sources.xmlファイルを変更します。
jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS_LIST=(LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=tcp)(HOST=hostname1)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=hostname2)(PORT=1521)) ) (CONNECT_DATA=(SERVICE_NAME=orcl)) )
hostname1およびhostname2は、Real Application Clustersデータベースを実行するノードの名前を指定します。
orclは、データベースのサービス名を指定します。
アドレスおよびロード・バランサのオプションは両方ともADDRESS_LIST要素内にあります。
また、Real Application Clustersデータベースに対する高速接続フェイルオーバーを有効化できます。構成手順は、『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』の第3.2項「APPHOST1およびAPPHOST2でのRACデータベースに対する高速接続フェイルオーバーの構成」を参照してください。
マシンが異なるサブネットにある環境でアクティブ/アクティブ・トポロジを実行する場合は、トポロジを実行する前に、次の手順に従ってORACLE_HOME¥bpel¥system¥config¥jgroups-protocol.xmlファイルに変更を加える必要があります。
jgroups-protocol.xmlファイルの最初の<config>セクションをコメント・アウトします。例5-1の(2)を参照してください。
jgroups-protocol.xmlファイルの2番目の<config>セクションをコメント解除します。例5-1の(3)を参照してください。
<!-- ************ JGroups Protocol Stack Configuration ************** --> <!-- generated by XmlConfigurator on Mon Apr 26 11:15:41 PDT 2004 --> <!-- input file: default.old.xml --> <!-- (2) Comment out this <config> section. --> <config> <UDP mcast_send_buf_size="32000" mcast_port="45788" ucast_recv_buf_size="64000" mcast_addr="228.8.15.24" bind_to_all_interfaces="true" loopback="true" mcast_recv_buf_size="64000" max_bundle_size="48000" max_bundle_timeout="30" use_incoming_packet_handler="false" use_outgoing_packet_handler="false" ucast_send_buf_size="32000" ip_ttl="32" enable_bundling="false"/> <PING timeout="2000" num_initial_members="3"/> <MERGE2 max_interval="10000" min_interval="5000"/> <FD timeout="2000" max_tries="3" shun="true"/> <VERIFY_SUSPECT timeout="1500"/> <pbcast.NAKACK max_xmit_size="8192" use_mcast_xmit="false" gc_lag="50" retransmit_timeout="600,1200,2400,4800"/> <UNICAST timeout="1200,2400,3600"/> <!-- - desired_avg_gossip: periodically sends STABLE messages around. 0 disables this - max_bytes: max number of bytes received from anyone until a STABLE message is sent. Use either this or desired_avg_gossip, but not both ! 0 disables it. - stability_delay: range (number of milliseconds) that we wait until sending a STABILITY message. This prevents STABILITY multicast storms. If max_bytes is used, this should be set to a low value (> 0 though !). --> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="20000" max_bytes="0"/> <FRAG frag_size="8192" down_thread="false" up_thread="false"/> <VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" /> <pbcast.GMS print_local_addr="true" join_timeout="3000" join_retry_timeout="2000" shun="true"/> </config> <!-- (2) end of <config> section to comment out --> <!-- For cluster across subnet, please use the following tcp config and - change the initial_hosts instead of the above, the initial_hosts that are going to be participating in the cluster. --> <!-- (3) Uncomment this <config> section <config> <TCP start_port="7900" loopback="true" send_buf_size="32000" recv_buf_size="64000"/> <!-- (4) Replace "hostA" and "hostB" with hostnames in your topology. --> <TCPPING timeout="3000" initial_hosts="hostA[7900],hostB[7900]" port_range="3" num_initial_members="3"/> <FD timeout="2000" max_tries="4"/> <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/> <pbcast.NAKACK gc_lag="100" retransmit_timeout="600,1200,2400,4800"/> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="20000" down_thread="false" max_bytes="0" up_thread="false"/> <VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" /> <pbcast.GMS print_local_addr="true" join_timeout="5000" join_retry_timeout="2000" shun="true"/> </config> --> <!-- (3) end of config section to comment out -->
Oracle BPEL Process Managerは、OracleAS Cold Failover Cluster、つまりアクティブ/パッシブなトポロジでも動作できます。アクティブ/パッシブ・トポロジは、ハードウェア・クラスタ内の2つのノード、共有記憶域、および仮想ホスト名と仮想IPアドレスで構成されます。共有記憶域にファイルをインストールして、ハードウェア・クラスタ内のどちらかのノードからこれらのファイルにアクセスできるようにします。クライアントは、仮想ホスト名を使用して、ハードウェア・クラスタ内のアクティブ・ノードにアクセスします。そのアクティブ・ノードが使用不可になった場合は、フェイルオーバー・イベントが発生し、パッシブ・ノードがかわりにプロセスを実行します。
Oracle BPEL Process ManagerをOracle Application Serverアダプタとともに使用して、Oracle BPEL Process Managerプロセスを外部リソースと統合します。これらのアダプタは、J2CA（J2EE Connector Architecture）に基づいています。
この項では、可用性の高い方法でOracle BPEL Process Managerをアダプタとともに実行する方法について説明します。この項の項目は次のとおりです。
表5-1に示すように、Oracle Application ServerのJ2CAベースのアダプタは、Oracle Application Serverを様々な外部リソースと統合します。
アダプタの詳細は、『Oracle Application Server Adapter概要』を参照してください。
同時実行性のサポートとは、複数のアダプタ・サービスがデータ破損を起こすことなく同時に同じリソースにアクセスできることです。同時実行性のサポートを、トランザクションのサポートと考えることができます。例として、データベース・アダプタの複数のアダプタ・サービスからデータベース内の同じ表に同時にアクセスできることが挙げられます。
アダプタは同時実行性をサポートするものとサポートしないものに分けられます。
表5-2に示すように、同時実行性のサポートまたは非サポートによって、アダプタの高可用性オプションが影響を受けます。
| アダプタ・タイプ | 高可用性オプション |
|---|---|
|
同時実行性のサポート |
|
|
同時実行性の非サポート（ファイルおよびFTPアダプタ） |
すべての高可用性オプションについて、すべてのノードにアダプタがインストールされていることが前提となっています。ただし、高可用性オプションによっては、1つのノードでのみOracle BPEL Process Managerを実行するものがあります。
このトポロジは、同時実行性をサポートするアダプタに使用できます。
図5-1に、アクティブ/アクティブ・トポロジを示します。このトポロジでは、1つ以上のノードの前面にロード・バランサを配置します。各ノードで、Oracle BPEL Process Managerおよびビジネス・プロセスを配置して実行します。これは、すべてのノードですべてのコンポーネントを使用できるため、高可用性の点で理想のモデルといえます。
同時実行性をサポートしないアダプタをアクティブ/アクティブ・トポロジに配置すると、外部データソースのデータが破損するおそれがあります（同時に同じファイルの読取りと書込みを行うなど）。
この変更済バージョンのアクティブ/アクティブ・トポロジは、次の相違点を除いて完全なアクティブ/アクティブ・トポロジと同様です。
最初のノードのアダプタ・サービスのみが受信リクエストを取得します。
このトポロジは、次のアダプタに使用できます。
図5-2に、変更済アクティブ/アクティブ・トポロジを示します。
アクティブ化エージェントを使用しているノードに障害が発生した場合は、次の手順を実行する必要があります。
アクティブ化エージェントを無効にするには、bpel.xmlファイルのactivationAgent要素をコメント・アウトします。次の例では、無効にするアクティブ化エージェントが含まれるコメント行を示します。
<activationAgents> <!-- start comment <activationAgent className="oracle.tip.adapter.fw.agent.jca.JCAActivationAgent" partnerLink="InboundPL"> <property name="InputFileDir">C:/ora_home/integration/bpm/samples/tutorials/ 121.FileAdapter/ComplexStructure/InputDir/</property> <property name="portType">Read_ptt</property> </activationAgent> end comment --> </activationAgents>
このトポロジは、すべてのアダプタに使用できます。アクティブ/パッシブ・トポロジは、OracleAS Cold Failover Clusterトポロジとも呼ばれます。
アクティブ/パッシブ・トポロジ（図5-3を参照）では、ハードウェア・クラスタに2つのノードがあります。そのうちの1つはアクティブ・ノード、もう1つはパッシブ・ノードです。共有記憶域もあり、これにOracleホーム・ディレクトリをインストールします。共有記憶域はアクティブ・ノードにのみマウントされます。
ハードウェア・クラスタのアクティブ・ノードは、仮想ホスト名およびIPに関連付けられています。クライアントは、仮想ホスト名を使用して、クラスタ内のアクティブ・ノードにアクセスします。
実行時に、アクティブ・ノードはプロセスを実行します。仮想ホスト名はアクティブ・ノードを指し示します。アクティブ・ノードが使用不可になると、フェイルオーバー・イベントが発生します。パッシブ・ノードが新しいアクティブ・ノードになり、プロセスを実行します。
次の相違点を除いて単一ノード配置の場合と同じように、Oracle BPEL Process Managerをインストールして管理します。
この項では、Oracle Enterprise Service Busの高可用性について説明します。この項の項目は次のとおりです。
Oracle Enterprise Service Busは、SOAとイベントドリブン・アーキテクチャ（EDA）を使用するサービスのための基盤です。Oracle Enterprise Service Busを使用することで、エンタープライズの内側および外側の両方にある複数のエンドポイント間でデータを移動できます。Oracle Enterprise Service Busでは、異なるアプリケーション間でのビジネス・ドキュメント（XMLメッセージなど）の接続、変換およびルーティングに、オープン・スタンダードが使用されます。これにより、既存のアプリケーションへの影響を最小限に抑えながら、ビジネス・データの監視と管理が可能になります。
Oracle Enterprise Service Busは、高い可用性を必要とする次の2つの主要なコンポーネントで構成されます。
Oracle Enterprise Service Busには、管理タスクに使用できるWebベースのコンソールも用意されています。
Oracle Enterprise Service Busの詳細は、次のドキュメントを参照してください。
Oracle Enterprise Service Busを可用性の高い環境で実行するには、図5-4に示すようなアクティブ/アクティブ・トポロジで実行する必要があります。通常のアクティブ/アクティブ・トポロジと同様、トポロジ内のすべてのノードがアクティブとなるため、各アクティブ・ノードへのリクエストの分散にロード・バランサが必要です。
この図は、4つのノードからなるアクティブ/アクティブ・トポロジを示しています。状況によっては、さらに多数のノードを配置できますが、次の注意事項を確実に理解して構成する必要があります。
|
注意3 アクティブ/アクティブ・トポロジでは、同時実行性をサポートしないアダプタ（ファイル・アダプタとFTPアダプタ)を実行できません。これは、外部リソース（これらのアダプタの場合はファイル・システム）が同時実行アクセスをサポートしないためです。 詳細は、第5.2.4.2項「同時実行性のサポート」を参照してください。 |
このトポロジの構築手順の詳細は、『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』の第3章「mySOACompanyのWeb層とアプリケーション層のインストールと構成」を参照してください。この章には、インストールの手順とインストール後の手順（構成手順）が説明されています。
（『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』の第3章「mySOACompanyのWeb層とアプリケーション層のインストールと構成」に説明されている）インストール後の手順の1つに、ESBランタイム・サーバー用のESBクラスタの名前変更があります。名前変更の理由は、このESBクラスタにESBランタイム・サーバー・インスタンスのみが含まれることを確実にすることです。このESBクラスタには、ESBリポジトリ・サーバー・インスタンスを含めることはできません。
これを検証するには、テキスト・エディタでORACLE_HOME¥integration¥esb¥config¥esb_config.iniファイルを表示します。ESBランタイム・サーバーおよびESBリポジトリ・サーバーを実行するすべてのOracleホームに対して、この手順を実行します。
すべてのESBランタイム・サーバー・インスタンスが同じESBクラスタ名を使用すること、およびESBリポジトリ・サーバー・インスタンスが異なるESBクラスタ名を使用することを確認します。クラスタ名は、ファイル内のcluster_nameパラメータで指定されます。次に、例を示します。
# Cluster name cluster_name=ESBcluster1
（『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』の第3章「mySOACompanyのWeb層とアプリケーション層のインストールと構成」に説明されている）インストール後の手順の1つに、仮想ホスト名および仮想ポート（ロード・バランサに構成されるホスト名とポート）のORAESBスキーマへの登録があります。これらの値は、次のコマンドを実行して検証できます。
ant export-params -DDB_URL=jdbc:oracle:thin:@//dbhost:1521/ORCL -DDB_USER=oraesb -DDB_PASSWORD=oraesbpassword
dbhost: ORAESBスキーマを持つデータベースを実行するマシンを指定します。
1521: データベース・リスナーがリスニングするポートを指定します。
ORCL: データベースのサービス名を指定します。
oraesbpassword: ORAESBスキーマのパスワードを指定します。
値が正しくない場合は、手順を再実行して、正しい値を登録します。
高可用性環境を構築するには、Real Application ClustersデータベースにORAESBスキーマをインストールする必要があります。Oracle Enterprise Service Busのインストール時の指示に従って、Real Application Clustersデータベース内のすべてのノードを入力する必要があります。
OC4JインスタンスはOC4Jクラスタとしてクラスタ化できますが、必須ではありません。
クライアントは、ロード・バランサに構成された仮想ホスト名およびポートを使用して、Oracle Enterprise Service Busサービスにアクセスします。
Oracle Enterprise Service Busコンソールにアクセスするには、物理ホスト名を使用します。
ESBアプリケーションをOracle Enterprise Service Busに登録するときは、アクティブ/アクティブ・トポロジ内のすべてのESBランタイム・サーバーに登録する必要があります。
J2CAベースのOracle Application Serverアダプタは、Oracle Enterprise Service Busにも使用できます。これらのアダプタの高可用性トポロジは、第5.2.4項「アダプタとのOracle BPEL Process Managerの使用」を参照してください。
この項では、高可用性環境でのOracle Business Activity Monitoringの実行について説明します。この項の項目は次のとおりです。
Oracle Business Activity Monitoringは、様々なソースから情報をリアルタイムに収集し、フィルタ、変換処理を行って、操作メトリックやキー・パフォーマンス・インジケータに対する影響を分析します。Oracle Business Activity Monitoringは、このデータを対話型のダッシュボードにリアルタイムに表示できると同時に、アラートを送信できます。
高可用性環境でOracle Business Activity Monitoringを実行するには、そのすべてのコンポーネントを高可用性対応にする必要があります。
Active Data Cacheの高可用性を実現するには、ハードウェア・クラスタ内のノードにインストールします。また、Real Application Clustersデータベースにデータを格納するようActive Data Cacheを構成します。
Active Data Cacheのフェイルオーバー: ハードウェア・クラスタ内のノードに障害が発生した場合は、ハードウェア・クラスタ内のもう一方のノードが処理を引き継ぎます。Active Data Cacheとアクティブ・ノードの状態は、クラスタ・サービスによって監視されます。アクティブ・ノードまたはActive Data Cacheサービスに障害が発生した場合は、クラスタ・サービスによって、クラスタ内のもう一方のノードのActive Data Cacheが起動されます。
クラスタ・サービスは、Active Data Cacheの実行状態だけでなく、デッドロックの発生も監視します。
Enterprise Linkの高可用性を実現するには、2つまたはそれ以上のノードにインストールします。インストールするのは、アクティブ/アクティブ構成のノードです。
Enterprise Linkのフェイルオーバー: Enterprise Linkを実行するノードに障害が発生しても、残りのアクティブ・ノードが実行を継続しています。
Plan Monitorの高可用性を実現するには、2つまたはそれ以上のノードにインストールします。インストールするのは、アクティブ/アクティブ構成のノードです。
Plan Monitorのフェイルオーバー: Plan Monitorを実行するノードに障害が発生した場合は、残りのアクティブ・ノードが、障害発生ノードによって監視されていたプランを監視できます。
Webアプリケーションの高可用性を実現するには、2つまたはそれ以上のノードにインストールし、その前面にロード・バランサを配置します。ロード・バランサは、任意のノードにリクエストを転送できます。
Webアプリケーションのフェイルオーバー: Webアプリケーションを実行するノードに障害が発生した場合は、ロード・バランサによって、そのノードへのリクエストの転送が停止されます。ロード・バランサは、残りのアクティブ・ノードにリクエストを転送します。
Report Cacheの高可用性を実現するには、ハードウェア・クラスタ内のノードにインストールします。また、Real Application Clustersデータベースにデータを格納するようReport Cacheを構成します。
Report Cacheのフェイルオーバー: ハードウェア・クラスタ内のノードに障害が発生した場合は、ハードウェア・クラスタ内のもう一方のノードが処理を引き継ぎます。Report Cacheとアクティブ・ノードの状態は、クラスタ・サービスによって監視されます。アクティブ・ノードまたはReport Cacheサービスに障害が発生した場合は、クラスタ・サービスによって、クラスタ内のもう一方のノードのReport Cacheが起動されます。
フェイルオーバーが実行されている間（Microsoft Cluster Serverによって、スタンバイ・ノードのReport Cacheが起動されている間）、Oracle BAMのリアルタイム・ダッシュボードおよびレポートには、リアルタイムなデータを表示できないことに注意してください。フェイルオーバーにかかる時間はシステムに依存します。
Event Engineの高可用性を実現するには、ハードウェア・クラスタ内のノードにインストールします。また、Real Application Clustersデータベースにデータを格納するようEvent Engineを構成します。
Event Engineのフェイルオーバー: ハードウェア・クラスタ内のノードに障害が発生した場合は、ハードウェア・クラスタ内のもう一方のノードが処理を引き継ぎます。Event Engineとアクティブ・ノードの状態は、クラスタ・サービスによって監視されます。アクティブ・ノードまたはEvent Engineサービスに障害が発生した場合は、クラスタ・サービスによって、クラスタ内のもう一方のノードのEvent Engineが起動されます。
図5-5に、Oracle Business Activity Monitoringの高可用性トポロジを示します。
高可用性環境でOracle Business Activity Monitoringを実行するには、次のアイテムが必要です。
ハードウェア・クラスタには、Microsoft Cluster Server（MSCS）の実行と、仮想ホスト名およびIPアドレスの構成が必要です。クラスタ内のノードの一方はアクティブで、他方はパッシブです。1つのノード（アクティブ・ノード）のみが、常にリクエストを処理します。アクティブ・ノードに障害が発生した場合は、フェイルオーバー・イベントが生じ、パッシブ・ノードがアクティブ・ノードになります。
クラスタ内のノードは、ストレージ・デバイスを共有します。アクティブ・ノードのみが、共有記憶域にアクセスできます。
この項では、図5-5のトポロジを構築する目的でOracle Business Activity Monitoringコンポーネントをインストールする際の重要なポイントについて説明します。各コンポーネントは、任意の順序でインストールできます。
Oracle Business Activity Monitoringのインストーラおよび要件の詳細は、『Oracle Business Activity Monitoringインストレーション・ガイド』を参照してください。
この項の項目は次のとおりです。
Active Data Cache、Event EngineおよびReport Cacheは、ハードウェア・クラスタ内のノードにインストールします。これらのコンポーネントをインストールするときは、次の点に注意してください。
C:¥OracleBAM、ログ・ディレクトリはC:¥OracleBAM¥Logsなど）。
nodeA.oracle.com:1521^nodeB.oracle.com:1521^nodeC.oracle.com:1521
ノード名は^文字で区切ります。
Webアプリケーションは、ロード・バランサの背後にあるノードにインストールします。Webアプリケーションをインストールするときは、次の点に注意してください。
Enterprise Linkをインストールするときは、次の点に注意してください。
Oracle Business Activity Monitoringコンポーネントのインストールが完了したら、次の手順を実行してMSCSを構成します。
cluster.exe restype "Oracle BAM Active Data Cache" /create /dll:"C:¥OracleBAM¥ADCClusterResourceType.dll"
C:¥OracleBAMは、Oracle Business Activity Monitoringをインストールしたディレクトリを表します。
このコマンドは、1つのノードでのみ実行する必要があります。実行結果は、クラスタ内のすべてのノードに反映されます。
「次へ」をクリックします。
「次へ」をクリックします。
「次へ」をクリックします。
Webガーデンは、複数のワーカー・プロセスで構成されます。WebアプリケーションにWebガーデンを設定するには、次の手順を実行します。
「Application Pools」が表示されない場合は、「IIS 5.0 プロセス分離モードで WWW サービスを実行する」オプションが選択解除されていることを確認します。このオプションは、「Web サイト」→「プロパティ」→「サービス」タブにあります。
Webガーデンの詳細は、次のページを参照してください。http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/659f2e2c-a58b-4770-833b-df96cabe569e.mspx?mfr=true
アクティブ/アクティブ構成の複数のノードでEnterprise LinkとPlan Monitorの複数のインスタンスを実行する場合は、Oracle Business Activity Monitoring Architectを使用して、Enterprise LinkとPlan Monitorの各インスタンスに特定のプランを割り当てる必要があります。
構成手順の詳細は、『Oracle Business Activity Monitoringインストレーション・ガイド』の第3.7項「複数のPlan Monitorのインストール」を参照してください。
Oracle Business Activity Monitoring Architectの実行方法の詳細は、『Oracle Business Activity Monitoring Architectユーザーズ・ガイド』を参照してください。
高可用性トポロジでOracle Business Activity Monitoringを実行するときは、次の各項で説明する既知の問題に注意してください。
Active Data Cacheを実行するハードウェア・クラスタ内のノードに障害が発生し、フェイルオーバー・イベントが正常に完了したとき（つまり、別ノードのActive Data Cacheが起動されたとき）、Enterprise Linkがキューおよびログのメッセージを処理しません。一方、フェイルオーバー・イベントの完了後も、プランは引き続き実行されます。
また、Enterprise Linkに次のエラーが表示される場合があります。
You are unable to connect to the Oracle BAM services. Contact your system administrator if the error persists. [ErrorSource="ActiveDataCache", ErrorID="ADCServerConnectionError"] No connection could be made because the target machine actively refused it [Error Source="mscolib"]
Enterprise Linkにエラーが表示される場合は、プランに対してメッセージ整合機能（保証されたメッセージング機能とも呼ばれる）を使用していることを確認します。メッセージ整合機能を有効化すると、エラーは表示されなくなります。この機能を有効化する手順は、第5.4.8項「メッセージ整合の設定」を参照してください。
メッセージ処理を再開するには、次の順序でコンポーネントを再起動する必要があります。
Active Data Cacheを実行するハードウェア・クラスタ内のノードに障害が発生し、フェイルオーバー・イベントが正常に完了したとき（つまり、別ノードのActive Data Cacheが起動されたとき）、Active Viewerでチャートをドリルダウンするなどのアクションを実行すると、「Oracle BAMサービスに接続できません。」というエラーが表示されます。Active Viewerは、ノード障害およびフェイルオーバー・イベントが発生する前のハードウェア・クラスタに接続されています。
Active Viewerでレポートを再度開いて表示します。
Real Application Clustersデータベース内のノードに障害が発生すると、次のエラーが表示されます。
An error has occurred in the ADC storage system. ORA-01089: immediate shutdown in progress - no operations are permitted [ErrorSource="ActiveDataCache", ErrorID="ADCStorageException"]
このエラーは、Enterprise Link、Plan Monitor、Active Data Cacheなどの個々のコンポーネントで生じる可能性があります。
また、ノードの障害によって、その時点で実行中のプランも停止されます。
現時点では、この問題の回避策はありません。ノードのフェイルオーバー後に、ログをチェックして、すべてのデータが揃っていることと、失われたデータがないことを確認する必要があります。
Plan MonitorがActive Data CacheまたはDFSへの接続を失った場合（ネットワーク接続が失われたなどの理由で）、イベント・ログにメッセージが書き込まれ、処理が一時停止されます。このメッセージは次のようになります。
2006-03-10 10:46:32,808 [2472] ERROR - PlanMonitor Plan Monitoring processing suspended. Service must be restarted. [ErrorSource="PlanMonitor", ErrorID="PlanMonitor.BackgroundFatal"] An error has occurred in the ADC storage system. ORA-03113: end-of-file on communication channel [ErrorSource="ActiveDataCache", ErrorID="ADCStorageException"]
Plan Monitorの停止と再起動を手動で行う必要があります。
Plan MonitorがEnterprise Linkへの接続を失った場合、自動的に再接続されません。
Plan Monitorを再起動してください。
ハードウェア・クラスタのスタンバイ・ノードでicommand.exeを実行すると、次のようなエラーが表示されます。
> ICommand.exe cmd=import file=sla_adherence_stage.xml Oracle BAM Command Utility 10g Release 3 (10.1.3.1.0) [Build 3 5 5777 0, ADC Version 1003.0] Copyright (c) 2002, 2006 Oracle. All rights reserved. Error while processing command "import". [ErrorSource="ICommandEngine", ErrorID="ICommandEngine.Error"] You are unable to connect to the Oracle BAM services. Contact your system administrator if the error persists. [ErrorSource="ActiveDataCache", ErrorID="ADCServerConnectionError"] Requested Service not found [ErrorSource="System.Runtime.Remoting"]
アクティブ・ノードでicommand.exeを実行します。
Microsoft Cluster Serverがアクティブ・ノードからスタンバイ・ノードへのフェイルオーバーを実行している間に、アラートに指定されたルールまたは条件が満たされた場合、アラートが起動されないことがあります。
フェイルオーバーの完了後に、起動対象のアラートがすべて起動されていることを検証します。起動されていない場合は、手動で起動できます。
このリリースのOracle Business Activity Monitoringでは、高速接続フェイルオーバーはサポートされません。
メッセージ整合は、障害の発生時にメッセージの再処理を可能にする機能です。プランにメッセージ整合を設定するには、次の各項の手順を実行します。
メッセージ整合は、障害の発生時、具体的には第5.4.7.1項「クラスタ・ノードの障害発生時にEnterprise Linkでエラーが発生する」に説明されている障害の発生時に、メッセージの再処理を可能にする機能です。メッセージの再処理がどのような場合に行われるかを理解するには、イベントの発生順序を知っておく必要があります。
メッセージはキューから読み取られ、メッセージ・ログ・データ・オブジェクトに記録されます。各メッセージには独自のIDがあり、Active Data Cacheに対して行われる各トランザクションのMessage Tracker変換によって使用されます。
メッセージがメッセージ・ログ・データ・オブジェクトに記録される前に障害が発生した場合、メッセージはキューから削除されていません。この場合、メッセージはまだ処理されていないため、メッセージの再処理は必要ありません。
メッセージがメッセージ・ログ・データ・オブジェクトに記録されキューから削除された後に障害が発生した場合、プランによる処理が未完了のメッセージは再処理が必要です。
「Oracle BAM Enterprise Message Receiver」ダイアログ（図5-13）で、次のオプションを選択します。
サブプランを作成し、それに各レコードの反復処理を設定します。
図5-14に、メッセージ・レシーバからサブプランのトップ・コネクタへのコネクタを示します。
サブプラン上の反復アイコンを右クリックして、ポップアップ・メニュー（図5-15）から「Iteration」を選択します。
「Iteration」ダイアログで、「Iterate for each record」を選択します（図5-16）。
反復設定したサブプラン内の各メッセージまたは各行がプランによってトランザクションとして処理されるように、「Include in Global Transaction」オプションを選択します（図5-17）。
このオプションは、次の各ダイアログにあります。
グローバル・トランザクションには名前を指定する必要があります。この名前は、サブプラン内のすべてのトランザクションで同じにする必要があります。
「Oracle BAM Message Tracker」ダイアログで、「Include in Global Transaction」オプションを選択し、変換に使用した名前と同じ名前を入力します（図5-18）。
図5-19に、反復サブプラン内に表示された変換を示します。
Oracle Service Registryは、WebサービスのUDDI（Universal Description, Discovery and Integration）レジストリです。クライアントはOracle Service Registryに問い合せることで、Webサービスの場所を特定できます。また、クライアントは、Webサービスをレジストリに登録できます。
Oracle Service Registryの詳細は、アプリケーションに付属する製品ドキュメントを参照してください。
Oracle Business Rulesは実行可能なコンポーネントではありません。つまり、プロセスまたはサービスとして実行されません。Oracle Business Rulesは、アプリケーションが使用可能なライブラリです。Oracle Business Rulesを使用するアプリケーションがある場合、Oracle Business Rulesの高可用性は、アプリケーションがデプロイされている環境の高可用性に依存します。Oracle Business Rulesは、アクティブ/アクティブまたはアクティブ/パッシブの高可用性環境で動作できます。
Oracle Business Rulesの詳細は、『Oracle Business Rulesユーザーズ・ガイド』を参照してください。
この項の項目は次のとおりです。
本番環境では、ファイル・リポジトリではなく、WebDAVベースのリポジトリを使用する必要があります。WebDAVリポジトリは、ファイル・リポジトリよりも安全です。ファイル・リポジトリは、開発環境でのみ使用してください。
Rule AuthorにWebDAVリポジトリを指定する前に、リポジトリの作成が完了している必要があります（Rule Authorではリポジトリを作成できません)。リポジトリは、Oracle HTTP Serverと同じファイル・システム上にある必要があります。Oracle HTTP Serverは、ORADAV（mod_oradav）モジュールを介してWebDAVをサポートします。
次に、Rule AuthorでリポジトリへのURLを入力するときは、完全修飾の物理ホスト名（Oracle HTTP Serverを実行するホスト）を使用します。
実行時には、リポジトリへのURLパスも指定する必要があります。すべてのノードがリポジトリへのアクセスに使用可能なURLを入力します。
Oracle Business Rules自体はデータベースを使用しません。ただし、Oracle XML DBに組み込まれているWebDAVサポートを利用して、Oracle XML DBにWebDAVリポジトリを構成できます。
Rule Authorは、ルールの作成と変更に使用できるブラウザベースのツールです。これはJ2EEアプリケーションのため、複数のインスタンスにデプロイ可能ですが、次の点に注意する必要があります。
Oracle Web Services Managerの高可用性に関する説明は、『Oracle Web Services Managerデプロイメント・ガイド』のクラスタ環境でのOracle WSMの構成に関する項を参照してください。
|
 Copyright © 2006, Oracle. All Rights Reserved. |
|
