ヘッダーをスキップ
Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド
12c (12.1.3)
E59392-01
  目次へ移動
目次

前
 
次
 

2 Oracle Fusion Middlewareコンポーネントに関する推奨事項

この章では、様々なOracle製品スイート内のOracle Fusion Middlewareコンポーネントの障害保護の要件について説明し、これらのコンポーネントの同期化に関する推奨事項も示します。前に説明したとおり、ストレージ・レプリケーションを使用して中間層のコンテンツを同期化し、Oracle Data Guardを使用してOracle Fusion Middleware障害時リカバリ・トポロジに含まれているOracle Database・リポジトリまたはカスタム・アプリケーション・データベース内のデータを同期化します。

この章では、次の項目について説明します。


注意:

Oracleインベントリ、beahomelistファイル、oratabファイル、oraInst.locファイルなどの特定のアーティファクトは、すべてのOracle製品デプロイメント間で共通です。これらのアーティファクトが異なっていることはほとんどなく、通常のストレージ・レプリケーションおよび同期化アクティビティの一部とする必要はありません。Oracleインベントリ、beahomelistファイル、oratabファイルおよびoraInst.locファイルはマシンのローカル・ディスクに配置することをお薦めします。これらのアーティファクトは、作成時およびパッチ・アップデートの適用時に手動で更新する必要があります。環境で必要な場合は、これらのアーティファクトを共有記憶域に配置することも可能です。Oracleインベントリの管理方法の詳細は、付録Aを参照してください。


2.1 Oracle WebLogic Serverに関する推奨事項

Oracle WebLogic Serverは、エンタープライズ対応のスケーラブルなEnterprise Edition(Java EE)アプリケーション・サーバーです。Oracle WebLogic Serverインフラストラクチャは、様々なタイプの分散アプリケーションのデプロイメントをサポートしており、サービス指向アーキテクチャ(SOA)に基づいてアプリケーションを構築するための理想的な基盤となります。

Oracle WebLogic Serverの共通アーティファクトと考慮事項

コンポーネント固有の推奨事項に加えて、次のアーティファクトと考慮事項がすべてのWebLogic Serverコンポーネントに適用されます。

ファイル・システム上のアーティファクト

Oracleホーム: Oracleホームは、WebLogic Serverバイナリ・ファイルを含むWebLogicホームから構成されます。

ドメイン・ホーム: ドメイン・ホームには、WebLogicドメインの構成データおよびアプリケーションが含まれます。

ネットワーク・アーティファクト

Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。

環境でサーバー全体の移行を構成する必要がある場合、サーバー全体の移行で構成されている管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。障害時リカバリ操作後にリスニング・アドレスを手動で更新しなくても済むようにするには、ホスト名をプライマリ・サイトとスタンバイ・サイトの両方で解決できるようにしてください。

本番サイトとスタンバイ・サイトの両方で、WebLogic Serverアプリケーションへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。

この項の残りの部分では、次のOracle WebLogic Serverコンポーネントの障害時リカバリに関する推奨事項を示します。

2.1.1 Oracle WebLogic Server Java Message Service (JMS)およびTransaction Logs (T-Logs)の推奨事項

この項では、様々なOracle WebLogic Server JMSおよびT-Logアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

ファイルベースの永続ストア: JMSおよびT-Logのファイル・ストアの場所(ファイルベースの永続ストアを使用する場合)。

データベース内のアーティファクト

JMSメッセージを含むスキーマ(データベースベースの永続ストアを使用する場合)。このスキーマには、JDBC LLRオプションを利用するWebLogicアプリケーションのロギング・ラスト・リソース(LLR)トランザクション・ログ・レコードが含まれます。

サーバー全体の自動移行が構成されている場合、必要なリース表はデータベース内にあります。

特別な考慮事項

  • システムのリストア・ポイントよりも後にエンキューされていた未処理のメッセージは失われます。システムのリストア・ポイントよりも前にエンキューされており、その後デキューされて確認応答またはコミット(処理)されたメッセージについては、メッセージの複製が作成されます。

  • 永続ストアがJMS専用のカスタム・ストアである場合は、ストア全体を削除できます。

  • システムの様々な部分を様々な時点でリストアすると、データに不整合が生じる可能性があります。メッセージ・ストア、トランザクション・ログまたはアプリケーション・データベースが別々に同期化されると、このような状況が発生することがあります。たとえば、存在しないデータベース行をメッセージが参照する場合(またはその逆)などです。これにより、重複メッセージに加えて未処理のメッセージが削除されることがあります。

  • ストアがJMS専用でない場合は、Oracle WebLogic Server JMSメッセージ管理ツールを使用します。このツールを使用して、管理コンソール、MBeanおよびWebLogic Scripting Tool(WLST)からインポート、エクスポート、移動および削除の各操作を行うことができます。

  • アプリケーションがキューとトピックの両方を使用する場合は、必ずキューとトピックの両方のサブスクリプションを処理してください。

同期に関する推奨事項

  • JMSデータの重要性が高い場合には、同期レプリケーションを使用して、トランザクション・ログ・データとJMSデータをリアル・タイムで同期化します。同期レプリケーションを使用するとパフォーマンスに影響する場合があります。

  • 各層間でのデータの整合性が重要な場合は、データベース層とアプリケーション層が同時にレプリケートされていることを確認します。こうすると、異なる層をまったく同じ時点でリカバリできるようにするために役立ちます。

  • データベース・ベースの永続ストアを使用している場合は、Oracle Data Guardを使用して、プライマリ・サイトとスタンバイ・サイトをレプリケートします。

  • ブロックレベルのスナップショット機能をサポートしていないストレージ・デバイスを使用している場合は、JMSサーバーを停止して、一貫性バックアップを作成します。これにより、コピー操作の実行中に永続ストアへの書込みが行われないようになります。クラスタ環境では、一度に1台のサーバーを停止して、バックアップし、再起動します。WLSTを使用してこれらの操作を実行するスクリプトを作成することもできます。

リカバリに関する推奨事項

WLSドメイン内の管理サーバーおよび管理対象サーバーの永続ストアを含むデータベース・スキーマを直近の時点にリカバリします。

また、重複メッセージを回避するために、リカバリに関する次の推奨事項を使用します。

重複メッセージの回避

リカバリの前に次の手順を実行して、永続ストアのリカバリ後にJMSキュー内のメッセージをフィルタリングし、重複メッセージの処理を回避します。


注意:

メッセージを排出および破棄する前に、保存の必要なデータがメッセージに含まれていないことを確認してください。リカバリしたメッセージには、処理済の重複メッセージに加えて、重要なアプリケーション・データが含まれる未処理のメッセージが含まれている可能性があります。


  1. Oracle WebLogic Server管理コンソールにログインします。

  2. リカバリの前に、起動時に生成、挿入および消費操作を一時停止するようにJMSサーバーを構成します。これにより、古いメッセージを破棄する前に、新しいメッセージが宛先に生成または挿入されたり、宛先から消費されたりしないことが保証されます。その手順は次のとおりです。

    1. サービス」→「メッセージング」→「JMSサーバー」を開きます。

    2. 「JMSサーバーのサマリー」ページで、メッセージの休止を構成するJMSサーバーをクリックします。

    3. 「構成: 全般」ページで「詳細」をクリックして、メッセージの休止オプションを定義します。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択します。

    4. 保存」をクリックします。

    5. 前述の変更をアクティブ化するには、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。

リカバリ後に実行する手順は次のとおりです。

  1. 永続ストアのリカバリ後に、管理対象サーバーを起動します。

  2. 次の手順を実行して、失効したメッセージをJMS宛先から排出します。

    1. サービス」→「メッセージング」→「JMSモジュール」を開きます。

    2. JMSモジュールを選択して、宛先を選択します。

    3. 「監視」を選択して、「メッセージの表示」をクリックします。

    4. すべて削除」をクリックします。

手順2にリストされている指示に従って操作を再開します。

2.1.2 Oracle Platform Security Servicesに関する推奨事項

この項では、様々なOracle Platform Security Servicesアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle Platform Security Servicesにはデータベース依存性がないため、適用されません。

同期に関する推奨事項

構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項および『Oracle Data Guard概要および管理』フィジカル・スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。

リカバリに関する推奨事項

WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーをリカバリします。

2.2 Oracle SOA Suiteに関する推奨事項

Oracle SOA Suiteは、Oracle Fusion Middlewareのミドルウェア・コンポーネントです。Oracle SOA Suiteにより、SOAコンポジット・アプリケーションを設計、デプロイおよび管理するサービス・インフラストラクチャ・コンポーネントの完全なセットが提供されます。Oracle SOA Suiteでは、サービスの作成、管理、および複数のテクノロジ・コンポーネントと結合するSOAコンポジット・アプリケーションへの編成が可能です。

SOAコンポジット・アプリケーションは、次のものから構成されています。


注意:

Oracle SOA Suiteリリース12c (12.1.3)では、soa-infraおよびサービス・エンジン構成ファイルは、ドメイン構成の一部としてローカルまたは共有のストレージ・ファイルに格納されていました。

Oracle SOA Suite 11gR1 (11.1.1.2)以降、これらのファイルは、メタデータ・リポジトリに移動されています。そのため、soa-infraおよびサービス・エンジン構成変更は、クラスタ全体に即座に伝播されるようになりました。

Oracle SOA Suite 11g R1 (11.1.1.3)では、Oracle Business Process Management (BPM) SuiteをOracle SOA Suiteインストール上にデプロイできます。

Oracle SOA Suiteの障害時リカバリに関する推奨事項では、Oracle SOA Suite 12c R1 (12.1.3)を使用しているものと想定しています。


Oracle SOA Suiteアーティファクトは、メタデータ・リポジトリだけでなく、ローカルまたは共有のファイル・システムに格納されます。コンポジット・アーティファクトはメタデータ・リポジトリに格納され、バイナリ・ファイルおよびドメイン関連の構成ファイルはローカルまたは共有のファイル・システムに格納されます。

すべてのOracle SOA Suiteコンポーネントで共通のアーティファクトおよび考慮事項

コンポーネント固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle SOA Suiteコンポーネントに適用されます。

ファイル・システム上のアーティファクト

Oracleホーム: Oracleホームは、WebLogic Serverバイナリ・ファイルが格納されるWebLogicホームとOracle SOA Suiteバイナリ・ファイルが格納されるOracleホームから構成されます。

Oracle Commonホーム: これは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホームです。

ドメイン・ホーム: ドメイン・ホームには、SOAドメインの構成データおよびSOAコンポジットが含まれます。

ネットワーク・アーティファクト

Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。IPアドレスを仮想ホスト名に更新する手順については、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

本番サイトとスタンバイ・サイトの両方で、Oracle SOA Suiteコンポーネントへのアクセスに必要なロード・バランサの仮想ホストを構成する必要があります。

データベース内のアーティファクト

Oracle SOA Suiteスキーマ、サービス・インフラストラクチャとサービス・エンジンの構成、およびコンポジット定義は、Oracle SOA Suiteのデータベースとメタデータ・リポジトリに格納されます。

同期に関する推奨事項

ドメイン関連の構成の変更、コンポジットのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項および『Oracle Data Guard概要および管理』フィジカル・スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。

リカバリに関する推奨事項

データベースを直近の時点にリカバリして、最新のコンポジット定義および進行中のインスタンスがリストアされるようにする必要があります。

進行中のインスタンスで処理が続行されるようにするには、コンポジット定義が一致している必要があります。このため、メタデータ・リポジトリ(コンポジット定義が格納されている場所)とOracle SOA Suiteデータベース(プロセス・ステータスが維持される場所)は、同じ時点にリカバリされる必要があります。

再デプロイされたコンポジットでは、データベース・リカバリにより、デハイドレーションされた進行中のプロセスと、対応するそれらの定義間の一貫性が確保されます。これは、デハイドレーションされたインスタンスが格納されているデータベース・リポジトリにプロセス定義が格納されているためです。

この項では、次のOracle SOA Suiteコンポーネントの障害時リカバリに関する推奨事項を示します。

2.2.1 Oracle SOA Service Infrastructureに関する推奨事項

Oracle SOAサービス・インフラストラクチャは、Oracle SOA Suiteを実行するための基礎となるサービスを提供するJava EEアプリケーションです。このJava EEアプリケーションは、Oracle SOA Suiteがインストールされると、自動的にデプロイされるランタイム・エンジンです。コンポジット(サービス・コンポーネント・アーキテクチャ内の基本アーティファクト)をOracle SOA Infrastructureにデプロイすると、コンポジットの実行に必要なサービスが提供されます。Oracle SOA Infrastructureは、コンポジット用のデプロイメント、接続およびスレッド管理サービスを提供します。これらのサービスにより、コンポジットのライフサイクルと実行時操作が維持されます。

この項では、様々なOracle SOA Service Infrastructureアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

コンポジット定義と構成ファイルは、MDSリポジトリに格納されます。コンポジット・インスタンス・ステータスの永続性は、Oracle SOA Service Infrastructureデータベース内に格納されます。

同期に関する推奨事項

ドメイン関連の構成の変更、コンポジットのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

データベースを直近の時点にリカバリして、最新のコンポジット定義および進行中のインスタンスがリストアされるようにする必要があります。

2.2.2 Oracle BPEL Process Managerに関する推奨事項

Oracle BPEL Processエンジンは、BPELプロセスの実行を可能にする、Oracle SOA Service Infrastructure内で実行されるサービス・エンジンです。BPELプロセスは、一連の独立したサービスをエンドツーエンドのプロセス・フローに組み込み、エンドツーエンドのBPELプロセス・フローへの同期および非同期サービスを開発するための標準を提供します。それは、長時間実行される非同期プロセスのプロセス編成および格納を可能にします。

この項では、様々なOracle BPEL Process Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

プロセス定義と構成ファイルは、MDSリポジトリに格納されます。BPELプロセス・ステータスの永続性は、Oracle SOA Suiteデータベース内に格納されます。

同期に関する推奨事項

ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

データベースを直近の時点にリカバリして、最新のプロセス定義および進行中のインスタンスがリストアされるようにする必要があります。Oracle BPEL Process Managerの冪等プロセスを使用すると、障害時リカバリ操作の実行後にクリーンアップする必要がないため、これを使用することをお薦めします。冪等以外のOracle BPEL Process Managerプロセスを使用する場合は、障害時リカバリ操作の実行後に、デハイドレーション・ストアからプロセスをクリーンアップする必要があります(特に、プロセスが進行中の場合)。

2.2.3 Oracle Mediatorに関する推奨事項

Oracle Mediatorは、Oracle SOA Service Infrastructure内のサービス・エンジンです。Oracle Mediatorは、様々なプロバイダとサービスやイベントのコンシューマの間を仲介するフレームワークを提供します。Mediatorサービス・エンジンは、SOA Service Infrastructure Java EEアプリケーションとともに実行されます。

この項では、様々なOracle Mediatorアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Mediatorサービス・エンジンは、パラレル・ルーティング・ルールの非同期ルーティング用にメッセージをデータベースに格納します。Mediatorコンポーネント・インスタンス・ステータスおよび監査の詳細もデータベース内に格納されます。

メタデータ・リポジトリには、コンポジット定義の一部としてMediatorコンポーネント定義が格納されます。


注意:

順次ルーティング・ルールはメッセージをデータベースに実行の一部として永続化しません。


同期に関する推奨事項

ドメイン関連の構成の変更およびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

管理サーバー、およびsoa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。

2.2.4 Oracle Human Workflowに関する推奨事項

Oracle Human Workflowは、人間による対話型プロセスの実行を可能にする、Oracle SOA Service Infrastructure内で実行されるサービス・エンジンです。ヒューマン・ワークフローは、プロセス内またはプロセス外で承認、拒否、再割当てアクションなどの人間による対話型のアクションをサポートします。Human Workflowサービスは、人間がビジネス・プロセスに関する様々な操作を実行できるようにするためのいくつかのサービスで構成されています。

この項では、様々なOracle Human Workflowアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

ヒューマン・ワークフロー・インスタンス・データおよび他のワークリスト・データ(休暇ルール、グループ・ルール、フィールド・マッピング、ビュー定義など)は、データベース内に格納されます。

メタデータ・リポジトリは、SOAコンポジットによって使用される共有のヒューマン・ワークフロー・サービス定義およびスキーマの格納に使用されます。

同期に関する推奨事項

ドメイン関連の構成の変更およびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。Oracle Human Workflowエンジンは、Oracle User Messaging Serviceを使用して通知を送信および取得します。Oracle User Messaging Serviceの詳細は、第2.2.7項を参照してください。

2.2.5 Oracle B2Bに関する推奨事項

Oracle B2Bは、SOAコンポジット・アプリケーションを外部サービス、アプリケーションおよびテクノロジに接続します。Oracle B2Bは、業界に認められたB2B標準をサポートしているマルチプロトコル・ゲートウェイを提供します。Oracle B2Bは、Oracle SOA Suiteを、電子データ交換(EDI)、ebXML、HL7、RosettaNetなどのビジネス・プロトコル標準で拡張します。Oracle B2Bは、SOA Service Infrastructure内のバインディング・コンポーネントとして実装されます。

この項では、様々なOracle B2Bアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

JMSストア: ファイルベースのJMS永続ストアを含むボリューム。表2-1に、Oracle B2Bによって内部的に使用されるJMSキューおよびトピックを示します。

表2-1 Oracle B2Bによって使用されるJMSキューおよびトピック

JMSアーティファクト名 タイプ JNDI名

dist_B2BEventQueue_auto

分散キュー

jms/b2b/B2BEventQueue

dist_B2B_IN_QUEUE_auto

分散キュー

jms/b2b/B2B_IN_QUEUE

dist_B2B_OUT_QUEUE_auto

分散キュー

jms/b2b/B2B_OUT_QUEUE

dist_B2BBroadcastTopic_auto

分散トピック

jms/b2b/B2BBroadcastTopic


データベース内のアーティファクト

Oracle B2Bメッセージおよびメッセージ・ステータスの永続性は、パートナ、ドキュメントおよびチャネル定義とともに、Oracle SOA Suiteデータベース内に格納されます。メタデータ・リポジトリは、Oracle B2Bメタデータの格納に使用されます。

特別な考慮事項

これらのアダプタを使用する場合は、スタンバイ・サイトで外部FTPサーバーおよび電子メール・サーバーが使用可能である必要があります。

同期に関する推奨事項

Oracle B2B JMSキューの同期とリカバリの詳細は、第2.1.1項を参照してください。

ドメイン関連の構成の変更およびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。Oracle B2Bは、JMSキューおよびSOAランタイム・データベース内に状態情報を格納するので、データベースおよび管理対象サーバーのリカバリにより、アプリケーションが正常に実行されるようになります。

2.2.6 Oracle Web Services Managerに関する推奨事項

Oracle Web Services Manager(Oracle WSM)は、組織全体でWebサービスを一貫して管理および保護するポリシー・フレームワークを提供します。これは、セキュリティ、Web Services Reliable Messaging (WSRM)、Message Transmission Optimization Mechanism (MTOM)およびアドレッシング・ポリシーを含むWebサービス・ポリシーを構築、強制、実行および監視する機能を提供します。Oracle Web Services Managerは、ポリシー・マネージャおよびエージェントから構成されています。

ポリシー・マネージャは、MDSリポジトリから、事前定義されたポリシーとカスタム・ポリシーを含め、セキュリティおよび管理ポリシーの読取りおよび書込みを行います。ポリシー・マネージャは、ステートレスJava EEアプリケーションです。ステートレス・セッションBeanによって、その機能が公開されます。ポリシー・マネージャはデータをキャッシュしませんが、基礎となるMDSインフラストラクチャはデータをキャッシュします。

エージェントは、ポリシーの適用と実行、および実行時統計の収集を行います。エージェントは、すべてのOracle Fusion Middleware管理対象サーバー上で使用可能であり、保護対象のアプリケーションと同じサーバー上に構成されます。エージェントは、ポリシー・アクセス・ポイント(PAP)とポリシー・インターセプタの2つから構成されています。

この項では、様々なOracle Web Services Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

MDSリポジトリは、ポリシーの格納に使用されます。

同期に関する推奨事項

ドメイン関連の構成の変更およびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化します。

リカバリに関する推奨事項

soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。すべてのポリシーはMDSリポジトリ内に格納されるので、データベースおよび管理対象サーバーのリカバリにより、アプリケーションが正常に実行されるようになります。

2.2.7 Oracle User Messaging Serviceに関する推奨事項

Oracle User Messaging Service(UMS)は、ユーザーとデプロイ済アプリケーションの間での双方向通信を可能にします。電子メール、IM、SMS、テキストから音声に変換したメッセージなど、様々なチャネルに対応しています。Oracle User Messaging Serviceは、Oracle BPEL Process Manager、Oracle Human Workflow、Oracle Business Activity Monitoring (BAM)、Oracle WebCenter PortalなどのOracle Fusion Middlewareコンポーネントに統合されます。通常、これは、Oracle UserでOracle SOAサービス・インフラストラクチャとともにデプロイされます。Oracle User Messaging Serviceは、UMSサーバー、UMSドライバおよびUMSクライアント・アプリケーションで構成されています。

この項では、様々なOracle User Messaging Serviceアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

JMSストア: ファイルベースのJMS永続ストアを含むボリューム。表2-2に、Oracle User Messaging Serviceによって内部的に使用されるJMSリソースを示します。

表2-2 Oracle User Messaging Serviceによって使用されるJMSリソース

JMSアーティファクト名 タイプ JNDI名

OraSDPMAppDefRcvQ1_auto

分散キュー

OraSDPM/Queues/OraSDPMAppDefRcvQ1

OraSDPMDriverDefSndQ1_auto

分散キュー

OraSDPM/Queues/OraSDPMDriverDefSndQ1

OraSDPMEngineCmdQ_auto

分散キュー

OraSDPM/Queues/OraSDPMEngineCmdQ

OraSDPMEngineRcvQ1_auto

分散キュー

OraSDPM/Queues/OraSDPMEngineRcvQ1

OraSDPMEngineSndQ1_auto

分散キュー

OraSDPM/Queues/OraSDPMEngineSndQ1

OraSDPMWSRcvQ1_auto

分散キュー

OraSDPM/Queues/OraSDPMWSRcvQ1


データベース内のアーティファクト

Oracle User Messaging Serviceは、外部データベース・リポジトリを使用してメッセージおよび構成の状態を維持管理します。

特別な考慮事項

Oracle User Messaging Serviceは、JMSを使用して、メッセージング・アプリケーション間にメッセージを配信します。デフォルトでは、ファイルベースの永続性JMSストアを使用するように構成されているので、それらのファイルが配置されているストレージ・デバイスに依存します。

同期に関する推奨事項

構成の変更、追加のOracle User Messaging Serviceドライバのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

usermessagingserverアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。Oracle User Messaging Serviceは、外部データベース・リポジトリ内にメッセージおよび構成の状態を保持し、JMSキュー内にメッセージを保持するので、データベースおよび管理対象サーバーのリカバリにより、アプリケーションが問題なく機能するようになります。JMSデータの同期化に関する推奨事項は、第2.1.1項内の「同期化に関する推奨事項」を参照してください。

2.2.8 Oracle Java EE Connector Architecture (JCA)アダプタに関する考慮事項

Oracle JCA Adaptersは、Service Infrastructureが異なるプロトコルを使用してエンドポイントと通信できるようにするJCAバインディング・コンポーネントです。Oracle JCA Adaptersは、Oracle SOA Service Infrastructureの一部としてではなく、JCAリソース(RAR)の一部としてデプロイされます。

Oracle JCA Adaptersには、次のような幅広いカテゴリのものがあります。

  • Oracleテクノロジ・アダプタ

  • レガシー・アダプタ

  • パッケージ化されたアプリケーションのアダプタ

  • Oracleアプリケーション用のOracleアダプタ

Oracle JCA Adaptersのタイプの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

この項では、様々なOracle JCA Adapterアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

特定のアダプタは、ローカルまたは共有のストレージ・ファイルを使用します。例:

  • ファイルベースの永続ストアとともにWebLogic JMSを使用するJMSアダプタ: フェイルオーバー後に処理を再開するには、永続ストアがスタンバイ・サイトと同期化される必要があります。

  • FileアダプタまたはFTPアダプタのいずれかからのインバウンドおよびアウトバウンド・ファイル: フェイルオーバー後に処理を再開するには、関連ファイルがスタンバイ・サイトと同期化される必要があります。

アダプタ構成は、ear JCAリソース(RAR)のweblogic-ra.xmllデプロイメント・ディスクリプタ内に保持されます。各weblogic-ra.xmlファイルの場所は、ファイルの作成時に管理者によって決定されており、スタンバイ・サイトにレプリケートされる必要があります。

データベース内のアーティファクト

アダプタ・アーティファクトは、コンポジット・プロジェクトの一部として設計時に生成されます。これらのアーティファクトは、残りのコンポジット定義とともにメタデータ・リポジトリに格納されます。

同期に関する推奨事項

ドメイン関連の構成の変更(つまり、アダプタ構成の変更)後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化します。

リカバリに関する推奨事項

JCAアダプタを実行している管理対象サーバーおよび管理サーバーとともに、データベースを直近の時点にリカバリする必要があります。

2.2.9 Oracle Business Activity Monitoringに関する推奨事項

Oracle Business Activity Monitoring(BAM)は、エンタープライズ内のビジネス・サービスおよびプロセスを監視するためのツールを提供します。これにより、市場の指標を実際のビジネス・プロセスと相関させることや、ビジネス・プロセスをすばやく変更したり、ビジネス環境の変化に応じて修正を加えたりすることが可能になります。Oracle BAMは、ダッシュボード(リアルタイムのデータ流入を表示し、特定の状況でアラートを送信するためのルールを定義する場所)の作成に必要なツールとランタイム・サービスを提供します。

この項では、様々なOracle BAMアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

データベース内のアーティファクト

Oracle BAMデータおよびレポート・メタデータは、Oracle BAMスキーマを含むOracle BAMデータベース内に格納されます。

同期に関する推奨事項

ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data Guardが、Oracle BAMスキーマとメタデータ・リポジトリを含むOracle SOA Suiteデータベース用に構成されている必要があります。

ストレージ上でアプリケーション層の同期が開始される場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。

リカバリに関する推奨事項

Oracle BAMを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。

2.2.10 Oracle Business Process Managementに関する推奨事項

Oracle Business Process Management(BPM) Suiteは、ビジネス・プロセスを中心にしたビジネス・アプリケーションを開発、管理および使用するための統合環境を提供します。それは、設計時および実装からランタイムおよびアプリケーション管理まで、アプリケーション開発ライフサイクルの全ステージをシームレスに統合します。

Oracle BPM SuiteはOracle SOA Suiteの上位レイヤーになり、次を含む製品コンポーネントの多くを共有しています。

  • Oracle Business Rules

  • Oracle Human Workflow

  • 統合のためのOracleアダプタ・フレームワーク

  • SOAコンポジット・アーキテクチャ

この項では、様々なOracle BPMアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。

ファイル・システム上のアーティファクト

BPM JMS永続ストア(BPMJMSFileStore_auto): ファイルベースのJMS永続ストア。フェイルオーバー後に処理を再開するには、永続ストアがスタンバイ・サイトと同期化される必要があります。

データベース内のアーティファクト

プロセス定義、デプロイ済アプリケーションおよび構成ファイルは、Oracle Metadata Services (MDS)リポジトリに格納されます。Oracle BPMでは、プロセス・アナリストとプロセス開発者の間でプロジェクトとプロジェクト・テンプレートを共有するために、別のMDSパーティションも使用します。

同期に関する推奨事項

ドメイン関連の構成の変更およびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。

Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。

ストレージ上でアプリケーション層の同期化が開始されると、スタンバイ・データベースも同じ時点まで更新されます。スナップショット・スタンバイ・データベースが使用される場合は、これをお薦めします。

リカバリに関する推奨事項

soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。