Oracle® Fusion Middleware

ディザスタ・リカバリ・ガイド

12c (12.1.3)

E59392-01(原本部品番号:E52348-02)

2014年7月

このドキュメントでは、Oracle Fusion Middleware製品の障害時リカバリ・ソリューションについて説明します。

Oracle Fusion Middlewareディザスタ・リカバリ・ガイド、12c (12.1.3)

E59392-01

Copyright © 2013, 2014 Oracle and/or its affiliates. All rights reserved.

原本著者: Rekha Kamath

原本協力者: Susan Kornberg、Fermin Castro Alonso、Satheesh Amilineni、Ashwani Raj、Mukesh Tailor、Allwarappan Sundararaj

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 Oracle Fusion Middleware障害時リカバリの概要

- 1.1 障害時リカバリの概要

- 1.1.1 問題の説明と一般的なソリューション

- 1.1.2 用語

- 1.2 Oracle Fusion Middlewareコンポーネントの障害時リカバリの設定

- 1.2.1 Oracle Fusion Middleware障害時リカバリ・アーキテクチャの概要

- 1.2.2 このドキュメントに記述されているコンポーネント

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

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

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

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

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

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

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

- 2.2.3 Oracle Mediatorに関する推奨事項

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

- 2.2.5 Oracle B2Bに関する推奨事項

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

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

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

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

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

3 設計上の考慮事項

- 3.1 ネットワークに関する考慮事項

- 3.1.1 ホスト名の計画

- 3.1.1.1 Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

- 3.1.1.1.1 ホスト名の解決

- 3.1.1.1.2 ローカルでのホスト名の解決

- 3.1.1.1.3 個別のDNSサーバーを使用したホスト名の解決

- 3.1.1.1.4 グローバルDNSサーバーを使用したホスト名の解決

- 3.1.1.1.5 ホスト名解決のテスト

- 3.1.2 仮想IPおよび仮想ホスト名に関する考慮事項

- 3.1.3 ロード・バランサに関する考慮事項

- 3.1.4 仮想サーバーに関する考慮事項

- 3.1.5 外部クライアントの考慮事項

- 3.1.6 ワイド・エリアDNSの操作

- 3.1.6.1 グローバル・ロード・バランサの使用

- 3.1.6.2 DNS名の手動変更

- 3.2 ストレージに関する考慮事項

- 3.2.1 Oracle Fusion Middlewareのアーティファクト

- 3.2.2 OracleホームとOracleインベントリ

- 3.2.3 ストレージ・レプリケーション

- 3.2.4 ファイルベースの永続ストア

- 3.3 データベースに関する考慮事項

- 3.3.1 データベースのTNSNAMES.ORAエントリの作成

- 3.3.2 Oracle Data Guardを使用した手動によるデータベースの強制同期

- 3.3.3 データベース・ホスト名の別名の設定

- 3.4 開始ポイント

- 3.4.1 既存のサイトを基にした設計

- 3.4.1.1 共有ストレージへの既存の本番サイトの移行

- 3.4.2 新しいサイトの設計

- 3.5 トポロジに関する考慮事項

- 3.5.1 対称トポロジの設計に関する考慮事項

- 3.5.2 非対称トポロジの設計に関する考慮事項

4 障害時リカバリ・サイトの設定と管理

- 4.1 サイトの設定

- 4.1.1 ディレクトリ構造とボリューム設計

- 4.1.1.1 Oracle SOA Suiteのディレクトリ構造に関する推奨事項

- 4.1.1.1.1 Oracle SOA Suiteのボリューム設計

- 4.1.1.1.2 Oracle SOA Suiteのコンシステンシー・グループに関する推奨事項

- 4.1.2 ストレージ・レプリケーション

- 4.1.3 データベース

- 4.1.3.1 Oracle Database 11.2または12.1 MAA環境のインストールおよび構成

- 4.1.3.1.1 前提条件

- 4.1.3.1.2 Oracle Data Guard環境の説明

- 4.1.3.1.3 プライマリ・データベースの複製の手順

- 4.1.3.1.4 スタンバイ・データベースのRAC構成の完了の手順

- 4.1.3.1.5 Data Guard Broker構成の作成

- 4.1.3.1.6 Data Guard Broker構成の検証

- 4.1.3.1.7 データベースのスイッチオーバーおよびスイッチバックのテスト

- 4.2 本番サイトの作成

- 4.2.1 Oracle SOA Suiteトポロジの本番サイトの作成

- 4.2.2 Oracle Fusion Middleware SOAアクティブ-パッシブ・デプロイメントのデータ・ソースの構成

- 4.3 スタンバイ・サイトの作成

- 4.3.1 スタンバイ・サイトの作成

- 4.3.1.1 中間層のホストの設定

- 4.3.2 スタンバイ・サイトの自己署名証明書およびキーストアの更新

- 4.3.2.1 自己署名証明書の生成

- 4.3.2.2 IDキーストアの作成

- 4.3.2.3 信頼キーストアの作成

- 4.3.3 スタンバイ・サイトの設定の検証

- 4.4 非対称スタンバイ・サイトの作成

- 4.4.1 非対称スタンバイ・サイトの作成

- 4.4.1.1 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイトの作成

- 4.4.2 非対称スタンバイ・サイトの設定の検証

- 4.5 サイトの操作および管理の実行

- 4.5.1 サイトの同期

- 4.5.2 スイッチオーバーの実行

- 4.5.3 スイッチバックの実行

- 4.5.4 フェイルオーバーの実行

- 4.5.5 スタンバイ・サイトの定期テストの実行

- 4.5.6 テストでのpeer-to-peerファイル・コピーの使用

- 4.5.6.1 Oracle Fusion Middleware障害時リカバリ・トポロジでのrsyncとOracle Data Guardの使用

- 4.5.6.1.1 Oracle Fusion Middleware中間層コンポーネントでのrsyncの使用

- 4.5.6.1.2 フェイルオーバー操作およびスイッチオーバー操作の実行

- 4.6 障害時リカバリのためのOracle Site Guardの使用

- 4.7 Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用

5 障害時リカバリのトラブルシューティング

- 5.1 Oracle Fusion Middleware障害時リカバリ・トポロジのトラブルシューティング

- 5.1.1 本番サイトおよびスタンバイ・サイトのホスト名解決の確認

- 5.1.2 障害時リカバリ・トポロジでのコンポーネントの問題の解決

- 5.1.3 共有ストレージにデプロイされたコンポーネントの問題の解決

- 5.2 追加情報

A Oracleインベントリの管理

- A.1 Oracleインベントリの更新

- A.2 Windowsレジストリの更新

はじめに

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

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このドキュメントは、管理者や開発者など、ストレージ・レプリケーション・テクノロジを使用して、Oracle Fusion Middleware障害時リカバリ・ソリューションをデプロイおよび管理することを役割としている方を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleカスタマは、My Oracle Supportから電子サポートにアクセスできます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middlewareのドキュメント・セットにある次のドキュメントを参照してください。

- Oracle Fusion Middleware高可用性ガイド

- Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware管理者ガイド

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 Oracle Fusion Middleware障害時リカバリの概要

この章では、Oracle Fusion Middleware障害時リカバリについて紹介します。

内容は次のとおりです。

- 第1.1項「障害時リカバリの概要」

- 第1.2項「Oracle Fusion Middlewareコンポーネントの障害時リカバリの設定」

1.1 障害時リカバリの概要

この項では、Oracle Fusion Middlewareの障害時リカバリの概要について説明します。

内容は次のとおりです。

- 問題の説明と一般的なソリューション

- 用語

1.1.1 問題の説明と一般的なソリューション

いかなるOracle Fusion Middlewareエンタープライズ・デプロイメントにおいても、Oracleの最大可用性アーキテクチャの実現が重要な要件の1つとなります。Oracle Fusion Middlewareには、広範囲にわたる高可用性機能が組み込まれています。この高可用性機能には、プロセス停止の検出と再起動、サーバー・クラスタリング、サーバー移行、クラスタウェアの統合、GridLink、ロード・バランシング、フェイルオーバー、バックアップとリカバリ、ローリング・アップグレード、ローリング構成変更などが含まれており、計画外の停止からエンタープライズ・デプロイメントを保護し、計画済の停止を最小限に抑えます。

また、エンタープライズ・デプロイメントは、予測不可能な障害や天災から保護する必要があります。保護するためのソリューションとして、本番サイトとは別の場所にスタンバイ・サイトを設定する方法があります。スタンバイ・サイトは本番サイトと比較して、サービスやリソースの数が同じか下回る場合があります。アプリケーション・データ、メタデータ、構成データおよびセキュリティ・データが、定期的にスタンバイ・サイトにレプリケートされます。通常の場合、スタンバイ・サイトはパッシブ・モードであり、本番サイトが使用できないときに起動されます。このデプロイメント・モデルは、アクティブ・パッシブ・モデルと呼ばれることがあります。通常、このモデルは、2つのサイトがWAN経由で接続されていて、ネットワーク待機時間の関係で2つのサイトにまたがるクラスタリングができない場合に採用されます。

ホット・プラグ可能性は、Oracle Fusion Middlewareの中核となる戦略の一つであり、重要な機能の一つでもあります。異機種が混在する企業向けに構築されたOracle Fusion Middlewareは、モジュール形式のコンポーネント・ソフトウェアで構成されており、それらのソフトウェアは、一般的な各種プラットフォーム上で稼働し、他のソフトウェア・ベンダーのミドルウェア・テクノロジやビジネス・アプリケーションと相互運用されます。たとえば、Oracle Fusion Middlewareの製品およびテクノロジ(ADF、Oracle BPEL Process Manager、Oracle Enterprise Service Bus、Oracle Web Services Manager、Adapters、Oracle Access Manager、Oracle Identity Manager、Rules、Oracle TopLink、Oracle Business Intelligence Publisherなど)は、Oracle WebLogic Serverコンテナで稼働することに加えて、IBM WebsphereやJBossなど、Oracle以外のコンテナでも稼働できます。

Oracle Fusion Middleware障害時リカバリ・ソリューションは、Oracle Fusion Middlewareの中間層コンポーネントの障害保護にストレージ・レプリケーション・テクノロジを使用しています。このソリューションでは、ホット・プラグ可能なデプロイメントがサポートされており、サード・パーティ・ベンダーの推奨するソリューションと互換性があります。

Oracle Fusion Middlewareに含まれるOracle Databaseの障害保護は、Oracle Data Guardによって実現されます。

このドキュメントでは、エンタープライズ・デプロイメント向けにOracle Fusion Middleware障害時リカバリ・ソリューションをLinuxとUNIXのオペレーティング・システムにデプロイして、ストレージ・レプリケーション・テクノロジとOracle Data Guardテクノロジを利用する方法について説明します。

1.1.2 用語

この項では、障害時リカバリに関して次の用語を定義します。

- 非対称トポロジ
Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層の構成に相違があります。たとえば、スタンバイ・サイトのほうが本番サイトより、ホストやインスタンスの数が少ないというようなケースが考えられます。第4.4項では、非対称トポロジの作成方法を説明します。

- 障害
許容できないダメージまたは損失を引き起こす、突然かつ計画外の致命的なイベント。この障害というイベントが発生すると、許容しがたいほどの期間にわたって、重大な機能、プロセスまたはサービスを提供する機会が損なわれるので、組織はそのリカバリ計画を実行します。

- 障害時リカバリ
本番サイトにおいて、天災による停止や計画外の停止を予防する機能。別の場所に設置したスタンバイ・サイトにアプリケーションやデータをレプリケートするためのリカバリ戦略を使用します。

- ホスト名別名
このガイドでは、「ホスト名別名」という用語と「物理ホスト名」という用語を区別しています。

ホスト名別名とは、実際のネットワーク名を指定する以外に、システムにアクセスするための代替手段です。通常は、システムのネットワーク名と同じIPアドレスに変換されます。これは、DNSのような名前解決システムで定義することも、各システムのローカル・ホスト・ファイルでローカルに定義することもできます。1つのシステムに対して複数のホスト名別名を定義できます。

この項で後述する「物理ホスト名」の定義も参照してください。

- 物理ホスト名
物理ホスト名とは、gethostname()コールまたはhostnameコマンドで返されるシステムのホスト名です。通常の場合、物理ホスト名は、クライアントがシステムにアクセスするために使用するネットワーク名でもあります。この場合、DNS(または使用中の任意の名前解決メカニズム)でこの名前にIPアドレスが関連付けられます。関連付けられたIPは、システムへのネットワーク・インタフェースのいずれか1つで有効化できます。

1つのシステムには通常、物理ホスト名が1つ設定されています。また、ネットワーク・インタフェースで有効化されているIPアドレスに対応して、クライアントがネットワークを介してアクセスするために使用するネットワーク名を、追加で1つ以上設定することもできます。さらに、各ネットワーク名は、1つ以上のホスト名別名に置き換えることもできます。

この項で前述した「ホスト名別名」の定義も参照してください。

- 仮想ホスト名
仮想ホスト名はネットワーク・アドレスを指定可能なホスト名で、ロード・バランサまたはハードウェア・クラスタを通じて、1つ以上の物理マシンにマップされます。ロード・バランサの場合、このマニュアルでは「仮想サーバー名」の名前は「仮想ホスト名」と同じ意味で使用されます。複数のサーバーのセットを代表する仮想ホスト名をロード・バランサに付与でき、クライアントは仮想ホスト名を使用して、間接的にマシンと通信します。ハードウェア・クラスタの仮想ホスト名は、クラスタの仮想IPに割り当てられるネットワーク・ホスト名です。クラスタにある特定ノードにクラスタの仮想IPが永続的に付与されないため、仮想ホスト名も特定ノードに永続的に付与されません。

注意:

このドキュメントで「仮想ホスト名」という用語を使用する場合、それが仮想IPアドレスに関連付けられることを前提とします。IPアドレスが必要とされたり使用される場合、明示的に言及します。

- 仮想IP
一般的に、仮想IPはハードウェア・クラスタやロード・バランサに割り当てることができます。クラスタにおいて単一のシステム・ビューをネットワーク・クライアントに対して実現するために、クラスタのメンバーであるサーバー・グループに対して仮想IPはエントリ・ポイントのIPアドレスとして機能します。仮想IPは、サーバーのロード・バランサまたはハードウェア・クラスタに割り当てることができます。

ハードウェア・クラスタではクラスタの仮想IPが使用され、外部の世界に対してクラスタ(スタンドアロンのマシンにも設定可能)へのエントリ・ポイントを実現します。ハードウェア・クラスタのソフトウェアにより、クラスタにある2台の物理ノード間においてこのIPアドレスの変更が管理されますが、クライアントはこのIPアドレスに接続します。その際、このIPアドレスが現在アクティブである物理ノードを判別する必要はありません。2台のノードによる標準的ハードウェア・クラスタ構成では、各マシンには固有の物理IPアドレスと物理ホスト名が付与されながら、数個のクラスタIPアドレスを付与することもできます。これらのクラスタIPアドレスは、2台のノードにおいて切り替わります。クラスタIPアドレスを現在所有しているノードは、そのアドレスでアクティブになります。

また、ロード・バランサも一連のサーバーのエントリ・ポイントとして仮想IPを使用します。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーには割り当てられませんが、サーバーとクライアントとの間においてプロキシとして動作するロード・バランサに割り当てられます。

- 本番サイトの設定
このマニュアルに記述した手順を使用して本番サイトを作成するには、物理ホスト名およびホスト名別名を計画して作成し、共有ストレージ上でOracle Fusion Middlewareインスタンスのインストール先とするOracleホーム・ディレクトリに対するマウント・ポイントおよびシンボリック・リンク(該当する場合)をホスト上に作成し、バイナリ・ファイルとインスタンスをインストールして、アプリケーションをデプロイする必要があります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項を参照してください。

- サイトのフェイルオーバー
(本番サイトに障害が発生したことなどが原因で)本番サイトが突然使用できなくなった後で、現在のスタンバイ・サイトを新しい本番サイトにするプロセス。このドキュメントでは、サイトのフェイルオーバーを指す用語として「フェイルオーバー」も使用します。

- サイトのスイッチバック
現在の本番サイトおよび現在のスタンバイ・サイトをそれらの元の役割に戻すプロセス。スイッチバックは、スイッチオーバー処理の完了後に行う計画済の操作です。スイッチバックを行うと、各サイトの元のロールがリストアされます。具体的には、現在のスタンバイ・サイトが本番サイトになり、現在の本番サイトがスタンバイ・サイトになります。このドキュメントでは、サイトのスイッチバックを指す用語として「スイッチバック」も使用します。

- サイトのスイッチオーバー
本番サイトとスタンバイ・サイトの役割を逆転するプロセス。スイッチオーバーは、定期的な検証のために行う、または現在の本番サイトで計画メンテナンスを実行するための計画済の操作です。スイッチオーバー中に、現在のスタンバイ・サイトが新しい本番サイトになり、現在の本番サイトが新しいスタンバイ・サイトになります。このドキュメントでは、サイトのスイッチオーバーを指す用語として「スイッチオーバー」も使用します。

- サイトの同期
本番サイトに行った変更をスタンバイ・サイトに適用するプロセス。たとえば、本番サイトで新しいアプリケーションがデプロイされたら、同期化を実行して、同じアプリケーションがスタンバイ・サイトでもデプロイされるようにする必要があります。

- スタンバイ・サイトの設定
スタンバイ・サイトの作成のプロセス。このマニュアルに記述した手順を使用して本番サイトを作成するには、物理ホスト名およびホスト名別名を計画して作成し、スタンバイ共有ストレージ上のOracleホーム・ディレクトリに対するマウント・ポイントおよびシンボリック・リンク(該当する場合)を作成する必要があります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項を参照してください。

- 対称トポロジ
Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層の構成は完全に一致します。対称トポロジでは、本番サイトとスタンバイ・サイトで同じ数のホスト、ロード・バランサ、インスタンスおよびアプリケーションを使用します。また、両方のサイトで同じポートが使用されます。システムはまったく同じように構成され、アプリケーションは同じデータにアクセスします。このガイドでは、エンタープライズ構成用に、Oracle Fusion Middleware障害時リカバリで対称トポロジを設定する方法について説明します。

- トポロジ
Oracle Fusion Middleware障害時リカバリ・ソリューションを構成する、本番サイトとスタンバイ・サイトのハードウェアおよびソフトウェアのコンポーネント。

- ターゲット
ターゲットは、エンタープライズ内のインフラストラクチャおよびビジネス・コンポーネントを表すコアEnterprise Managerエンティティです。ビジネスが効率的に機能するには、これらのコンポーネントを監視および管理する必要があります。例: Oracle Fusion MiddlewareファームまたはOracle Database。

- システム
システムとは、相互に機能することでアプリケーションをホスティングする、一連のターゲット(ホスト、データベース、アプリケーション・サーバーなど)を指します。Enterprise Managerでアプリケーションを監視するには、最初に、アプリケーションが動作するターゲットであるデータベース、リスナー、アプリケーション・サーバーおよびホストで構成されるシステムを作成します。

- サイト
サイトは、アプリケーションのグループを実行するのに必要なデータセンターにある、一連の様々なターゲットを指します。サイトは、たとえば、Oracle Fusion Middlewareインスタンス、データベース、ストレージなどがあります。データセンターは、Oracle Site Guardによって複数のサイトを定義することができ、各データセンターにおけるスイッチオーバーやフェイルオーバーなどの操作は、独立して管理されます。

1.2 Oracle Fusion Middlewareコンポーネントの障害時リカバリの設定

この項では、Oracle Fusion Middlewareの一般的なエンタープライズ・デプロイメント向けに、障害時リカバリ・ソリューションを設定する作業について紹介します。

内容は次のとおりです。

- Oracle Fusion Middleware障害時リカバリ・アーキテクチャの概要

- このドキュメントに記述されているコンポーネント

1.2.1 Oracle Fusion Middleware障害時リカバリ・アーキテクチャの概要

この項では、Oracle Fusion Middlewareコンポーネントのデプロイメント・アーキテクチャについて説明します。

Oracle Fusion Middlewareコンポーネントおよびアプリケーションの製品バイナリ・ファイルと構成は、中間層のOracleホーム・ディレクトリにデプロイされます。また、製品のほとんどで、メタデータとランタイム・データもデータベース・リポジトリに格納されます。そのため、Oracle Fusion Middleware障害時リカバリ・ソリューションによって、データベースに格納されている中間層ファイル・システム・データは、本番サイトとスタンバイ・サイトで同期がとられています。

Oracle Fusion Middleware障害時リカバリ・ソリューションでは、Oracle Fusion Middlewareデータおよびデータベース・コンテンツのデータ保護を提供するための次の方法をサポートします。

- Oracle Fusion Middleware製品バイナリ・ファイル、構成ファイルおよびメタデータ・ファイル
ストレージ・レプリケーション・テクノロジを使用します。

- データベースの内容
OracleデータベースにはOracle Data Guard(サード・パーティのデータベースにはベンダー推奨のソリューション)を使用します。

図1-1に、Oracle Fusion Middleware障害時リカバリ・トポロジの概要を示します。

図1-1 Oracle Fusion Middleware障害時リカバリ・トポロジにおける本番サイトとスタンバイ・サイト

図1-1に示したソリューションの重要な側面をいくつか、次に示します。

- このソリューションにはサイトが2つあります。現在の本番サイトは稼働中かつアクティブであり、2番目のサイトはスタンバイ・サイトとして動作し、パッシブ・モードになっています。

- 各サイト上のホストには、そのサイトの共有ストレージ・システムにアクセスするためのマウント・ポイントが定義されています。

- どちらのサイトでも、Oracle Fusion Middlewareコンポーネントはサイトの共有記憶域システムにデプロイされます。そのため、ミドルウェア・コンポーネントの製品バイナリ・ファイルや構成データなど、すべてのOracleホーム・ディレクトリを本番サイトの共有ストレージ上のボリュームに作成し、共有ストレージ上のOracleホーム・ディレクトリにコンポーネントをインストールする必要があります。図1-1では、Oracle Fusion Middlewareホストの各クラスタに対して、別々のボリュームが共有ストレージに作成されています(各サイトの共有ストレージ・システムで、Web、アプリケーション、セキュリティの各ボリュームが、それぞれWebクラスタ、アプリケーション・クラスタおよびセキュリティ・クラスタ用として作成されています)。

- 本番サイトの共有ストレージにマウント・ポイントを作成する必要があります。本番サイトの共有ストレージに作成したマウント・ポイントを使用して、本番サイトのOracle Fusion MiddlewareソフトウェアをOracleホーム・ディレクトリにインストールします。本番サイトの共有ストレージ上のOracleホーム・ディレクトリに対するシンボリック・リンクを、本番サイトのホストに設定する必要もあります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項を参照してください。

- スタンバイ・サイトの共有ストレージにマウント・ポイントを作成する必要があります。スタンバイ・サイトの共有ストレージ上のOracleホーム・ディレクトリに対するシンボリック・リンクを、スタンバイ・サイト・ホストに設定する必要もあります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項を参照してください。マウント・ポイントおよびシンボリック・リンクは、スタンバイ・サイト・ホスト用と本番サイト・ホスト用で同一である必要があります。

- 本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージに、中間層のファイル・システムなどのデータをコピーするには、ストレージ・レプリケーション・テクノロジを使用します。

- ストレージ・レプリケーションが有効化されると、アプリケーションのデプロイメント、構成、メタデータ、データおよび製品バイナリ情報が、本番サイトからスタンバイ・サイトにレプリケートされます。

- スタンバイ・サイト・ホストでは、Oracleソフトウェアのインストールを実行する必要はいっさいありません。製品サイトの記憶域がスタンバイ・サイトの記憶域にレプリケートされると、同等のOracleホーム・ディレクトリおよびデータが、スタンバイ・サイトの記憶域に書き込まれます。

- 指定した間隔で増分レプリケーションが行われるようにスケジュールを作成します。中間層の構成を頻繁に変更しない本番デプロイメントには、この間隔として1日に1回をお薦めします。また、本番サイトで中間層の構成を変更するたびに(本番サイトに新しいアプリケーションをデプロイした場合など)、手動による同期化を実施する必要があります。一部のOracle Fusion Middlewareコンポーネントでは、ファイル・システム上にデータが生成されるため、リカバリ・ポイントの目標に応じて、より頻繁なレプリケーションが必要になる場合があります。Oracle Fusion Middlewareコンポーネントの障害時リカバリの詳細な推奨事項については、第2章を参照してください。

- 手動による同期化を実施する前に、サイトのスナップショットを取得して、現時点の状態を取得しておく必要があります。これにより、スナップショットがスタンバイ・サイトの記憶域にレプリケートされるようになります。また必要に応じて、このスナップショットを使用して、スタンバイ・サイトを前の同期状態にロールバックすることもできます。レプリケーションに失敗した場合は、レプリケーションが前回成功した(スナップショットが作成された)ポイントにリカバリできます。

- Oracle Fusion Middlewareリポジトリやカスタム・アプリケーション・データベースなど、すべてのOracle Databaseリポジトリをレプリケートするには、Oracle Data Guardを使用します。Oracle Data Guardを使用してOracle Databaseで障害保護を実現する方法の詳細は、第3.3項を参照してください。

- Oracle Fusion Middleware障害時リカバリ・トポロジにサード・パーティのデータベースが含まれる場合、それらのデータベースにはベンダーが推奨するソリューションを使用してください。

- ユーザー・リクエストは最初に、本番サイトにルーティングされます。

- 本番サイトに障害または計画外の停止が発生した場合には、次の手順を実行して、トポロジ内でスタンバイ・サイトが本番のロールを引き継げるようにします。

1. 本番サイトからスタンバイ・サイトへのレプリケーションを停止します(障害発生時には、その障害によりレプリケーションがすでに停止している可能性があります)。

2. Oracle Data Guardを使用して、Oracle Databaseのフェイルオーバーまたはスイッチオーバーを実行します。

3. スタンバイ・サイトでサービスとアプリケーションを起動します。

4. グローバルなロード・バランサを使用して、ユーザー・リクエストをスタンバイ・サイトに再ルーティングします。この時点では、スタンバイ・サイトが本番のロールを引き継いでいます。

1.2.2 このドキュメントに記述されているコンポーネント

Oracle Fusion Middleware障害時リカバリ・ソリューションがサポートしている各種Oracle製品群のコンポーネントには、次のようなものがあります。

- Oracle WebLogic Server
Oracle WebLogic Serverコンポーネント向けの障害時リカバリに関する推奨事項については、第2.1項を参照してください。

- Oracle SOA Suiteのコンポーネント:

- Oracle SOA Service Infrastructure

- Oracle BPEL Process Manager

- Oracle Mediator

- Oracle Human Workflow

- Oracle B2B

- Oracle Web Services Manager

- Oracle User Messaging Service

- Oracle JCA Adapters

- Oracle Business Activity Monitoring

- Oracle Business Process Management

Oracle SOA Suiteコンポーネント向けの障害時リカバリに関する推奨事項については、第2.2項を参照してください。

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

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

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

- 第2.1項「Oracle WebLogic Serverに関する推奨事項」

- 第2.2項「Oracle SOA Suiteに関する推奨事項」

注意:

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コンポーネントの障害時リカバリに関する推奨事項を示します。

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

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

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コンポジット・アプリケーションは、次のものから構成されています。

- サービス・コンポーネント: サービス・コンポーネントとは、SOAコンポジット・アプリケーションの基本となるビルディング・ブロックです。サービス・コンポーネントにより、SOAコンポジット・アプリケーション全体のビジネス・ロジックの一部が実装されます。サービス・コンポーネントの例としては、Oracle BPEL Process Manager、Oracle Mediator、Oracle Human Workflow、Oracle Business Rulesなどがあります。

- バインディング・コンポーネント: バインディング・コンポーネントは、SOAコンポジット・アプリケーションを外部サービス、アプリケーションおよびテクノロジに接続します。バインディング・コンポーネントは、次の2つのグループから構成されています。

- サービス: SOAコンポジット・アプリケーションへのエントリ・ポイントを外部に提供します。サービスのWSDLファイルによって、そのサービスの機能が外部のアプリケーションに通知されます。サービスのバインディングでは、SOAコンポジット・サービスをどのように呼び出すことができるか(例: SOAP経由で)が定義されます。

- 参照: SOAコンポジット・アプリケーションから外部のサービスにメッセージを送信できます(たとえば、パートナ・リンクがBPELプロセスに対して提供するものと同じ機能であっても、より高度な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コンポーネントの障害時リカバリに関する推奨事項を示します。

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

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

- Oracle Mediatorに関する推奨事項

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

- Oracle B2Bに関する推奨事項

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

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

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

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

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

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

3 設計上の考慮事項

この章では、エンタープライズ・デプロイメントにおけるOracle Fusion Middleware障害時リカバリ・ソリューションに関する設計上の考慮事項について説明します。

含まれる内容は、次のとおりです。

- 第3.1項「ネットワークに関する考慮事項」

- 第3.2項「ストレージに関する考慮事項」

- 第3.3項「データベースに関する考慮事項」

- 第3.4項「開始ポイント」

- 第3.5項「トポロジに関する考慮事項」

注意:

- スイッチオーバーやフェイルオーバーなどの障害時リカバリ操作は、Oracle Site Guardを使用して自動化できます。製品の詳細は、Oracle Site Guard管理者ガイドを参照してください。

- エンタープライズ・デプロイメントでのOracle SOA Suiteコンポーネントのインストールおよび構成に関する情報は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

- エラーに関する更新情報は、Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureリリース・ノートを参照してください。

この章では、LinuxおよびUNIXオペレーティング・システムでOracle Fusion Middleware 12c障害時リカバリの本番サイトとスタンバイ・サイトを設定する際の詳細な手順を説明します。エンタープライズ・デプロイメントのOracle Fusion Middleware 12c障害時リカバリ・ソリューションを設定する方法の例では、主に、Oracle SOA Suiteエンタープライズ・デプロイメント(図3-1を参照)を使用します。Oracle SOA Suiteエンタープライズ・トポロジの障害時リカバリを設定する方法を理解したら、この章に記載されているその他の12cエンタープライズ・デプロイメントに関する情報を参照して、それらのデプロイメントの障害時リカバリを設定することもできます。

注意:

この章では、本番サイトとスタンバイ・サイトの両方で、図3-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用するOracle Fusion Middleware 12c障害時リカバリの対称トポロジについて説明します。図3-1は、一方のサイトのみのデプロイメントを示しています。この図では、デプロイメントの詳細をわかりやすくするために、両方のサイトのデプロイメントを1つの図に示していません。

障害時リカバリの対称型の本番サイトとスタンバイ・サイトを1つの図に示したものについては、図1-1を参照してください。

図3-1 Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトで使用するデプロイメント

図3-1は、Oracle SOA、Business Process Management (BPM)およびOracle Service Busエンタープライズ・デプロイメント・トポロジのダイアグラムを示しています。Oracle SOA Suiteエンタープライズ・デプロイメントのインストールおよび構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

設計するOracle Fusion Middleware障害時リカバリ・トポロジは、本番サイトとスタンバイ・サイトで次の点について対称である必要があります。

- ディレクトリ名およびパス
本番サイトのホストに存在するすべてのファイルが、スタンバイ・サイトのピア・ホストの同一ディレクトリおよびパスに存在する必要があります。

つまり、Oracleホームの名前とディレクトリ・パスが本番サイトとスタンバイ・サイトで同じである必要があります。

- ポート番号
ポート番号は、リスナーによってリクエストのルーティングに使用されます。ポート番号は構成に保存され、本番サイトのホストとスタンバイ・サイトのピア・ホストで同じである必要があります。

第3.4.1項では、本番サイトとスタンバイ・サイトのホスト間におけるポートの競合を確認する方法について説明しています。

- セキュリティ
本番サイトとスタンバイ・サイトの両方に同じユーザー・アカウントが必要です。また、本番サイトとスタンバイ・サイトで、ファイル・システム、SSLおよびシングル・サインオンを同様に構成する必要があります。たとえば、本番サイトでSSLを使用している場合、スタンバイ・サイトでも、本番サイトとまったく同様に構成したSSLを使用する必要があります。

- ロード・バランサと仮想サーバー名
本番サイトについては、仮想サーバー名を使用してフロントエンド・ロード・バランサを設定する必要があります。スタンバイ・サイトについては、同じ仮想サーバー名を使用して同一のフロントエンド・ロード・バランサを設定する必要があります。

- ソフトウェア
本番サイトとスタンバイ・サイトで同じバージョンのソフトウェアを使用する必要があります。また、両方のサイトでオペレーティング・システムのパッチ・レベルが同じである必要があります。さらに、本番サイトとスタンバイ・サイトの両方にOracleまたはサード・パーティ・ソフトウェアのパッチを適用する必要があります。

3.1 ネットワークに関する考慮事項

この項では、ネットワークに関する次の考慮事項について説明します。

- ホスト名の計画

- 仮想IPおよび仮想ホスト名に関する考慮事項

- ロード・バランサに関する考慮事項

- 仮想サーバーに関する考慮事項

- 外部クライアントの考慮事項

- ワイド・エリアDNSの操作

3.1.1 ホスト名の計画

障害時リカバリ・トポロジでは、本番サイトのホスト名がスタンバイ・サイトの対応するピア・システムのIPアドレスに解決可能である必要があります。そのため、本番サイトとスタンバイ・サイトのホスト名を計画することが重要です。プライマリ・サイトからスタンバイ・サイトへのフェイルオーバー後に、スタンバイ・サイトの中間層ホストのホスト名別名がアクティブになります。スタンバイ・サイトの別名を設定する場合、スタンバイ・サイトのホストのホスト名を再構成する必要はありません。

物理ホスト名の別名は、ホスト名の解決に単一のグローバルDNSサーバーを使用する場合にのみ作成する必要があります。

この項では、本番サイトとスタンバイ・サイトでOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、物理ホスト名およびホスト名別名を計画する方法を説明します。ホスト名の例として、図3-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。この項に記載されているホスト名の例は、障害時リカバリの対称サイトを設定することを前提としています(つまり、本番サイトとスタンバイ・サイトのホスト数は同じです)。本番サイトとスタンバイ・サイトの各ホストに他方のサイトのピア・ホストがあります。ピア・ホストは、他方のサイトの対応するホストと同じポートを使用するなど、同様に構成されます。

各コンポーネントを構成する際には、コンポーネントでIPベースの構成を使用する必要がある場合を除き、IPベースの構成ではなく、ホスト名ベースの構成を使用してください。たとえば、Oracle Fusion Middlewareコンポーネントのリスニング・アドレスを特定のIPアドレス(172.16.10.255など)に構成する場合は、172.16.10.2555に解決されるホスト名SOAHOST1.EXAMPLE.COMを使用します。

この後の項では、次のエンタープライズ・デプロイメントの障害時リカバリの本番サイトとスタンバイ・サイトでホスト名を設定する方法を説明します。

注意:

このガイドで示されている例では、最初の本番サイトのホストのIPアドレスは172.16.x.xという形式で、最初のスタンバイ・サイトのホストのIPアドレスは172.16.x.xという形式です。

3.1.1.1 Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

表3-9に、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(EDG)のデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図3-1を参照してください。

表3-1 SOA Suiteの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス

物理ホスト名脚注1

ホスト名別名

172.16.2.111

WEBHOST1

なし

172.16.2.112

WEBHOST2

なし

172.16.2.113

SOAHOST1

なし

172.16.2.114

SOAHOST2

なし

脚注 1 物理ホスト名の定義の詳細は、第3.1.1.1.3項および第3.1.1.1.4項を参照してください。

図3-2には、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、ホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.1.3項を参照してください。

図3-2 Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用する物理ホスト名

管理サーバー、Oracle Identity Manager管理対象サーバーおよびSOA管理対象サーバーには、各サイトでのプロビジョニング用に浮動IPアドレスが必要です(表3-2)。浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想ホスト名でプロビジョニングしてください。

表3-2 浮動IPアドレス

物理ホスト名

仮想ホスト名

浮動IP

AdminServer

ADMINVHN

172.16.2.134

OIMHOST1

OIMVHN1

172.16.2.135

OIMHOST2

OIMVHN2

172.16.2.136

SOAHOST1

SOAVHN1

172.16.2.137

SOAHOST2

SOAVHN2

172.16.2.138

注意:

詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

3.1.1.1.1 ホスト名の解決

ホスト名の解決は、通信のためにホスト名を適切なIPアドレスに解決するプロセスです。ホスト名の解決は、次のいずれかの方法で構成できます。

- ローカルでのホスト名の解決
ローカルでのホスト名の解決では、各ホストの/etc/hostsファイルで指定したホスト名とIPアドレスのマッピングが使用されます。

/etc/hostsファイルを使用してローカルでホスト名のファイル解決を実装する方法の詳細は、第3.1.1.1.2項を参照してください。

- DNSを使用したホスト名の解決
DNSサーバーは、IPネットワークでDNSによる名前解決を提供する専用サーバーまたはサービスです。

DNSサーバーのホスト名解決を実装する2つの方法の詳細は、第3.1.1.1.3項および第3.1.1.1.4項を参照してください。

Oracle Fusion Middleware障害時リカバリ・トポロジのデプロイメントを計画する際には、トポロジで使用するホスト名解決の方法を決定する必要があります。ほとんどのサイト管理者は、ホスト名を管理する際にこれらの解決方法を優先順位に従って組み合せて使用しています。

各サイトのOracle Fusion Middlewareホストと共有ストレージ・システムは、相互に通信できる必要があります。

ホスト名解決の優先順位

特定のホストで使用するホスト名の解決方法を決定するには、ホストの/etc/nsswitch.confファイルでhostsパラメータの値を検索します。

ホストでローカルにホスト名を解決する場合は、例3-1に示されているように、filesエントリをhostsパラメータの最初のエントリにします。filesがhostsパラメータの最初のエントリである場合、ホストの/etc/hostsファイル内のエントリがホスト名の解決で最初に使用されます。

例3-1 ローカルでのホスト名解決を使用する場合の指定

hosts:   files   dns   nis

ホストでDNSを使用してホスト名を解決する場合は、例3-2に示されているように、dnsエントリをhostsパラメータの最初のエントリにします。dnsがhostsパラメータの最初のエントリである場合、DNSサーバーのエントリがホスト名の解決に最初に使用されます。

例3-2 DNSによるホスト名解決を使用する場合の指定

hosts:   dns    files   nis

わかりやすくすると同時に整合性を保つために、サイト(本番サイトまたはスタンバイ・サイト)内のすべてのホストで同じホスト名解決方法(ローカルでのホスト名の解決か、個別のDNSサーバーまたはグローバルDNSサーバーを使用したホスト名の解決)を使用することをお薦めします。

次の項に記載されている推奨事項は全般的な推奨事項です。企業で使用しているホスト名解決の標準に合わせて調整できます。

3.1.1.1.2 ローカルでのホスト名の解決

ローカルでのホスト名の解決では、ホストの/etc/hostsファイルで定義したホスト名とIPのマッピングが使用されます。障害時リカバリ・トポロジでこの方法を使用してホスト名を解決する場合、次のガイドラインが適用されます。

1. 本番サイトとスタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

hosts:   files   dns   nis

2. 本番サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされている必要があります。保守を簡潔かつ容易にするために、本番サイトのすべてのホストで同じエントリを提供することをお薦めします。例3-3に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hostsファイルを示します。

例3-3 本番サイト・ホストの/etc/hostsファイル・エントリの作成

174.0.0.1      localhost.localdomain    localhost
172.16.2.111    WEBHOST1.EXAMPLE.COM    WEBHOST1
172.16.2.112    WEBHOST2.EXAMPLE.COM    WEBHOST2
172.16.2.113    SOAHOST1.EXAMPLE.COM    SOAHOST1
172.16.2.114    SOAHOST2.EXAMPLE.COM    SOAHOST2

3. スタンバイ・サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされているとともに、本番サイトの対応するピアの物理ホスト名がホスト名別名として定義されている必要があります。保守を簡潔かつ容易にするために、スタンバイ・サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-4に、SOAエンタープライズ・デプロイメント・トポロジのスタンバイ・サイトの/etc/hostsファイルを示します。

例3-4 スタンバイ・サイト・ホストの/etc/hostsファイル・エントリの作成

176.0.0.1      localhost.localdomain    localhost
172.26.2.111    STBYWEB1.EXAMPLE.COM    WEBHOST1
172.26.2.112    STBYWEB2.EXAMPLE.COM    WEBHOST2
172.26.2.113    STBYSOA1.EXAMPLE.COM    SOAHOST1
172.26.2.114    STBYSOA2.EXAMPLE.COM    SOAHOST2

4. /etc/hostファイル・エントリを使用してホスト名解決を設定したら、pingコマンドを使用してホスト名解決をテストします。例3-3に示されている静的IPアドレス指定と/etc/hostsファイル・エントリを使用して構成したシステムの場合、本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.16.2.111)が返され、ホスト名が完全修飾されていることがわかります。

5. 同様に、例3-4に示されている静的IPアドレス指定と/etc/hostsファイル・エントリを使用して構成したシステムの場合、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.26.2.111)が返され、WEBHOST1という名前がそのIPアドレスと関連付けられていることがわかります。

3.1.1.1.3 個別のDNSサーバーを使用したホスト名の解決

このマニュアルでは、本番サイトとスタンバイ・サイトに独自のDNSサーバーがある障害時リカバリ・トポロジを表す場合に「個別のDNSサーバー」という用語を使用します。障害時リカバリ・トポロジで個別のDNSサーバーを使用してホスト名を解決する場合、次のガイドラインが適用されます。

1. 本番サイトとスタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

hosts:   dns   files   nis

2. 本番サイトとスタンバイ・サイトのDNSサーバーが相互を認識してはいけません。独自のサイト内で使用されるホスト名のエントリはそれぞれのDNSサーバーで構成されている必要があります。

3. 本番サイトのDNSサーバーのエントリで、物理ホスト名がIPアドレスにマップされている必要があります。例3-5に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトで使用するDNSサーバー・エントリを示します。

例3-5 個別のDNSサーバー構成における本番サイト・ホストのDNSエントリ

WEBHOST1.EXAMPLE.COM    IN    A    172.16.2.111
WEBHOST2.EXAMPLE.COM    IN    A    172.16.2.112
SOAHOST1.EXAMPLE.COM    IN    A    172.16.2.113
SOAHOST2.EXAMPLE.COM    IN    A    172.16.2.114

4. スタンバイ・サイトのDNSサーバーのエントリで、本番サイトの物理ホスト名がIPアドレスにマップされている必要があります。例3-6に、SOAエンタープライズ・デプロイメント・トポロジのスタンバイ・サイトで使用するDNSサーバー・エントリを示します。

例3-6 個別のDNSサーバー構成におけるスタンバイ・サイト・ホストのDNSエントリ

WEBHOST1.EXAMPLE.COM    IN    A    172.26.2.111
WEBHOST2.EXAMPLE.COM    IN    A    172.26.2.112
SOAHOST1.EXAMPLE.COM    IN    A    172.26.2.113
SOAHOST2.EXAMPLE.COM    IN    A    172.26.2.114

5. 本番サイトまたはスタンバイ・サイトのいずれのホストについても、/etc/hostsファイルにエントリがないことを確認します。

6. pingコマンドを使用してホスト名解決のテストを行います。例3-5に示されている本番サイトのDNSエントリで構成したシステムの場合、本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.16.2.111)が返され、ホスト名が完全修飾されていることがわかります。

7. 同様に、例3-6に示されているスタンバイ・サイトのDNSエントリで構成したシステムの場合、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.26.2.111)が返され、ホスト名が完全修飾されていることがわかります。

3.1.1.1.4 グローバルDNSサーバーを使用したホスト名の解決

このマニュアルでは、本番サイトとスタンバイ・サイト両方に対して1つのDNSサーバーを使用する障害時リカバリ・トポロジを表す場合に「グローバルDNSサーバー」という用語を使用します。障害時リカバリ・トポロジでグローバルDNSサーバーを使用してホスト名を解決する場合、次のガイドラインが適用されます。

1. グローバルDNSサーバーを使用する場合は、簡潔にするために、ローカルでのホスト名解決とDNSによるホスト名解決を組み合せて使用します。

2. この例では、本番サイトでDNSによるホスト名解決を使用し、スタンバイ・サイトではローカルでのホスト名解決を使用することを前提とします。

3. グローバルDNSサーバーに、本番サイトとスタンバイ・サイト両方のホストのエントリがある必要があります。例3-7に、SOAエンタープライズ・デプロイメント・トポロジのエントリを示します。

例3-7 グローバルDNSサーバー構成を使用する場合の本番サイト・ホストおよびスタンバイ・サイト・ホストのDNSエントリ

WEBHOST1.EXAMPLE.COM    IN    A    172.16.2.111
WEBHOST2.EXAMPLE.COM    IN    A    172.16.2.112
SOAHOST1.EXAMPLE.COM    IN    A    172.16.2.113
SOAHOST2.EXAMPLE.COM    IN    A    172.16.2.114
STBYWEB1.EXAMPLE.COM    IN    A    172.26.2.111
STBYWEB2.EXAMPLE.COM    IN    A    172.26.2.112
STBYSOA1.EXAMPLE.COM    IN    A    172.26.2.113
STBYSOA2.EXAMPLE.COM    IN    A    172.26.2.114

4. 本番サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

hosts:   dns   files   nis

5. スタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

hosts:   files   dns   nis

6. スタンバイ・サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされているとともに、本番サイトの対応するピアの物理ホスト名がホスト名別名として定義されている必要があります。保守を簡潔かつ容易にするために、スタンバイ・サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-8に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hostsファイルを示します。

例3-8 グローバルDNSサーバー構成を使用する場合のスタンバイ・サイトの/etc/hostsファイル・エントリ

176.0.0.1      localhost.localdomain    localhost
172.26.2.111    STBYWEB1.EXAMPLE.COM    WEBHOST1
172.26.2.112    STBYWEB2.EXAMPLE.COM    WEBHOST2
172.26.2.113    STBYSOA1.EXAMPLE.COM    SOAHOST1
172.26.2.114    STBYSOA2.EXAMPLE.COM    SOAHOST2

7. pingコマンドを使用してホスト名解決のテストを行います。本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.16.2.111)が返され、ホスト名が完全修飾されていることがわかります。

8. 同様に、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.26.2.111)が返され、ホスト名が完全修飾されていることがわかります。

3.1.1.1.5 ホスト名解決のテスト

ホスト名が適切に割り当てられていることを検証します。そのためには、本番サイトの各ホストに接続し、pingコマンドを使用して、ホストが本番サイトの他のホストを特定できることを確認します。

続いて、スタンバイ・サイトの各ホストに接続し、pingコマンドを使用して、ホストがスタンバイ・サイトの他のホストを特定できることを確認します。

3.1.2 仮想IPおよび仮想ホスト名に関する考慮事項

Oracle WebLogic管理サーバーをホストしているマシンに障害が発生した際に、リクエストの処理が続行されるようOracle WebLogic管理サーバーを有効にするには、仮想IPアドレスおよび仮想ホスト名が必要です。仮想IPアドレスを使用すると、ドメインの管理サーバーによってサーバー移行が行われます。仮想サーバーは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。

障害時リカバリ・トポロジでは、本番サイトの仮想IPホスト名がスタンバイ・サイトの対応するピア・システムのIPアドレスに解決可能である必要があります。そのため、本番サイトとスタンバイ・サイトのホスト名を計画することが重要です。プライマリ・サイトからスタンバイ・サイトへのフェイルオーバー後に、スタンバイ・サイトの中間層ホストのホスト名別名がアクティブになります。スタンバイ・サイトの別名を設定する場合、スタンバイ・サイトのホストのホスト名を再構成する必要はありません。

この項では、本番サイトとスタンバイ・サイトでOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、仮想IPホスト名およびホスト名別名を計画する方法を説明します。これは、単一の企業DNSを使用している場合に必要です。

ホスト名の例として、図3-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。この項に記載されているホスト名の例は、障害時リカバリの対称サイトを設定することを前提としています(つまり、本番サイトとスタンバイ・サイトのホスト数は同じです)。本番サイトとスタンバイ・サイトの各ホストに他方のサイトのピア・ホストがあります。ピア・ホストは、他方のサイトの対応するホストと同じポートを使用するなど、同様に構成されます。

この後のサブセクションでは、次のエンタープライズ・デプロイメントの障害時リカバリの本番サイトとスタンバイ・サイトで仮想IPアドレスおよびホスト名を設定する方法を説明します。

Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

表3-3に、Oracle SOA Suite EDGデプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図3-1を参照してください。

表3-3 SOA Suiteの本番サイト・ホストの仮想IPアドレスと仮想ホスト名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

172.16.2.115

ADMINVHN

なし

172.16.2.116

SOAVHN1

なし

172.16.2.117

SOAVHN2

なし

脚注 1 物理ホスト名の定義の詳細は、第3.1.1.1.3項および第3.1.1.1.4項を参照してください。

表3-4に、Oracle SOA Suite EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。図3-2には、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。図3-2に示されているOracle SOA Suiteのスタンバイ・サイト・ホストについては、表3-4に示されているホスト名別名を定義する必要があります。

注意:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ仮想IPアドレスおよび仮想ホスト名を使用できるため、ホスト名別名を定義する必要はありません。

個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.1.3項を参照してください。

表3-4 SOA Suiteのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス

仮想ホスト名脚注 1

ホスト名別名

172.26.2.115

STBYADMINVHN

ADMINVHN

172.26.2.116

STBYSOAVHN1

SOAVHN1

172.26.2.117

STBYSOAVHN2

SOAVHN2

脚注 1 物理ホスト名の定義の詳細は、第3.1.1.1.3項および第3.1.1.1.4項を参照してください。

3.1.3 ロード・バランサに関する考慮事項

Oracle Fusion Middlewareコンポーネントを高可用性トポロジでデプロイする場合には、ハードウェア・ロード・バランサが必要です。次の機能を備えたハードウェア・ロード・バランサをお薦めします。

- 仮想ホスト名を介した実サーバー・プールへのトラフィックのロード・バランシング機能: クライアントは、仮想ホスト名を使用して(実ホスト名を使用するかわりに)、サービスにアクセスします。これによって、ロード・バランサはプール内のサーバーにリクエストの負荷を分散できます。

- ポート変換の構成。

- ポート(HTTPおよびHTTPS)の監視。

- 仮想サーバーとポートの構成: 外部ロード・バランサで仮想サーバー名およびポートを構成する機能。仮想サーバー名とポートは、次の要件を満たす必要があります。

- ロード・バランサでは、複数の仮想サーバーの構成が可能である必要があります。各仮想サーバーについては、複数のポート上のトラフィック管理を構成できることが必要です。たとえば、Oracle Internet Directoryクラスタの場合、ロード・バランサでは、LDAPおよびLDAPSトラフィックの仮想サーバーとポートを構成する必要があります。

- 仮想サーバー名がIPアドレスと関連付けられており、DNSの一部である必要があります。クライアントは、仮想サーバー名を使用してロード・バランサにアクセスできる必要があります。

- ノードの障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。

- リソースの監視、ポートの監視およびプロセスの障害の検出: ロード・バランサは、通知などの方法を使用してサービスやノードの障害を検出し、障害が発生したノードへのOracle Net以外のトラフィックの送信を停止できる必要があります。ロード・バランサで障害を自動的に検出できる場合は、その機能を使用してください。

- フォルト・トレラント・モード: ロード・バランサをフォルト・トレラント・モードで構成することを強くお薦めします。

- トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようにロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。この構成は、クライアント・システムにおけるTCP/IPの設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。

- スティッキーなルーティング機能: CookieやURLに基づいてコンポーネントへのスティッキーな接続を維持する機能。

- SSLアクセラレーション: この機能は推奨されますが、必須ではありません。

- Oracle Access Managerを使用したIdentity Managementの構成については、TCP接続タイムアウトの数値を大きくして、ディレクトリ層でロード・バランサに仮想サーバーを構成します。この値は、Oracle Access Managerとディレクトリ層の間でトラフィックがない場合に、その予想される最大時間より大きい必要があります。

- クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。

3.1.4 仮想サーバーに関する考慮事項

様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらは、実際のホストおよびポートに対して適切に構成し、サービスが継続されるようにする必要があります。また、可用性を確保するために、実際のホストおよびポートを監視して、サービスが停止した場合はできるだけ早く、それらのホストやポートへのトラフィックが停止されるようにロード・バランサを構成する必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

外部トラフィックと内部トラフィックを処理する場合は、ロード・バランサを2つ使用することをお薦めします。このようなトポロジでは、一方のロード・バランサを外部HTTPトラフィック用に設定し、もう一方のロード・バランサを内部LDAPトラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なDMZ間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。

ロード・バランサに定義された一部の仮想サーバーは、コンポーネント間の通信に使用されます。これらの仮想サーバーは内部トラフィック用に使用され、企業の内部DNSに定義されます。ホスト名の解決に単一のグローバルDNSサーバーを使用する場合は、これらの仮想サーバーに別名を作成することを強くお薦めします。

個別のDNSサーバーを使用してホスト名を解決する場合は、別名を作成する必要はありません。

各種Oracle Fusion Middleware製品に必要な仮想サーバーを表3-5から表3-6に示します。

表3-5 Oracle SOA Suiteの本番サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

別名

Oracle SOA

外部

soa.example.com

なし

Oracle SOA

内部

soainternal.example.com

なし

管理コンソール

内部

admin.example.com

なし

表3-6 Oracle SOA Suiteのスタンバイ・サイトの仮想サーバー

コンポーネント

アクセス

仮想サーバー名

仮想サーバー名別名

Oracle SOA

外部

soa.example.com

なし

Oracle SOA

内部

stbysoainternal.example.com

soainternal.example.com

管理コンソール

内部

admin.example.com

なし

3.1.5 外部クライアントの考慮事項

トポロジで直接使用されている(つまり、JMXクライアントやRMIクライアントの場合のようにフロントエンド・ロード・バランサを使用していない)サーバーにアクセスするシステムは、異なるOracle WebLogic Serverインスタンスで使用されるリスニング・アドレスを認識する必要があります。適切なホスト名解決をクライアントに提供して、サーバーでリスニング・アドレスとして使用されるホスト名別名が正しく解決されるようにする必要があります。これは、Oracle JDeveloperデプロイメントにも適用されます。デプロイメントを成功させるには、Oracle Jdeveloperをホストしているクライアントが、SOAHOSTxおよびSOAVHNx別名を適切なIPアドレスにマップする必要があります。

3.1.6 ワイド・エリアDNSの操作

サイトのスイッチオーバーまたはフェイルオーバーを実行した場合、クライアント・リクエストは本番ロールを引き継ぐ新しいサイトに透過的にリダイレクトされる必要があります。本番サイトのエントリ・ポイントにクライアント・リクエストを送信するには、DNS解決を使用します。このリダイレクションを実現するには、本番サイトへのリクエストを解決するワイド・エリアDNSをスタンバイ・サイトにスイッチオーバーする必要があります。DNSスイッチオーバーを実行するには、グローバル・ロード・バランサを使用するか、DNS名を手動で変更します。

注意:

ハードウェア・ロード・バランサは、各サイトのフロントエンドとして機能することを前提とします。サポートされているロード・バランサについては、次のWebサイトを参照してください。

http://support.oracle.com

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

- グローバル・ロード・バランサの使用

- DNS名の手動変更

3.1.6.1 グローバル・ロード・バランサの使用

グローバル・ロード・バランサを本番サイトとスタンバイ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。さらに、このロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。

通常の操作時には、本番サイトのロード・バランサの名前とIPのマッピングを使用してグローバル・ロード・バランサを構成できます。DNSスイッチオーバーが必要な場合は、グローバル・ロード・バランサのこのマッピングを変更して、スタンバイ・サイトのロード・バランサのIPにマップします。これにより、本番ロールを引き継いだスタンバイ・サイトにリクエストが送信されるようになります。

DNSスイッチオーバーを使用するこの方法は、サイトのスイッチオーバーおよびフェイルオーバーとして機能します。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です。

3.1.6.2 DNS名の手動変更

DNSスイッチオーバーを使用するこの方法では、当初は本番サイトのロード・バランサのIPアドレスにマップされていた名前とIPのマッピングを手動で変更する必要があります。マッピングはスタンバイ・サイトのロード・バランサのIPアドレスにマップするように変更します。スイッチオーバーを実行する手順は次のとおりです。

1. 本番サイトのロード・バランサ・マッピングの現在の存続時間(TTL)値を書き留めます。このマッピングはDNSキャッシュ内にあり、TTLが経過するまでそこに保持されます。例として、TTLが3600秒であるとします。

2. TTL値を短い間隔(60秒など)に変更します。

3. 元のTTLの間隔が1回経過するまで待ちます。これは、ステップ1で書き留めた元のTTL値である3600秒です。

4. スタンバイ・サイトがリクエストを受信するようにスイッチオーバーされていることを確認します。

5. スタンバイ・サイトのロード・バランサを解決するようにDNSマッピングを変更します。通常の操作に適したTTL値(3600秒など)を指定してください。

DNSスイッチオーバーを使用するこの方法は、スイッチオーバー操作またはフェイルオーバー操作として機能します。ステップ2で設定するTTL値は、その時間内にクライアント・リクエストを十分に処理できないような値にする必要があります。TTLを変更する場合、実質的には、アドレス解決のキャッシュ・セマンティックを長い時間から短い時間に変更することになります。キャッシュ時間が短くなるため、DNSリクエストが増加する可能性があります。

3.2 ストレージに関する考慮事項

この項では、エンタープライズ・デプロイメントの障害時リカバリ・ソリューションで使用するストレージを設計する際の推奨事項について説明します。

3.2.1 Oracle Fusion Middlewareのアーティファクト

通常、特定の環境内のOracle Fusion Middlewareコンポーネントは相互に依存するため、トポロジ内のコンポーネントが同期されていることが重要です。これは、ボリュームとコンシステンシー・グループを設計する際の重要な考慮事項です。アーティファクトの中には静的なものもあれば、動的なものもあります。

静的アーティファクト

静的アーティファクトは、頻繁には変更されないファイルやディレクトリです。次のようなものがあります。

- ホーム: Oracleホームは通常、OracleホームとOracle WebLogic Serverホームで構成されます。

- Oracleインベントリ: これには、/etcディレクトリにある、oraInst.locおよびoratabファイルが含まれます。

- BEAホームの一覧: UNIXの場合、user_home/bea/beahomelistにあります。

動的またはランタイム・アーティファクト

動的またはランタイム・アーティファクトは、頻繁に変更されるファイルです。ランタイム・アーティファクトには、次のものが含まれています。

- ドメイン・ホーム: 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリ。

- Oracleインスタンス: Oracleインスタンスのホーム・ディレクトリ。

- .earファイルや.warファイルなどのアプリケーション・アーティファクト。

- MDSリポジトリなどのデータベース・アーティファクト。

- Oracle Fusion Middlewareで使用されるデータベース・メタデータ・リポジトリ。

- JMSプロバイダやトランザクション・ログなどの永続ストア。

- デプロイメント・プラン: ファイル・アダプタやJMSアダプタなどのテクノロジ・アダプタの更新に使用されます。これらは、アーティファクトがデプロイされるクラスタ内のすべてのノードにアクセスできる場所に保存する必要があります。

3.2.2 OracleホームとOracleインベントリ

Oracle Fusion Middlewareでは、1つのバイナリ・インストールから複数の管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリ・ファイルをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。

OracleホームまたはWebLogicホームが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとOracleホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。

ノードでインベントリ・ファイルを更新して、これに共有ストレージのインストールを関連付けるには、ORACLE_HOME/oui/bin/attachHome.shを使用します。

Oracleホームの一覧を更新してWebLogicホームを追加または削除するには、user_home/bea/beahomelistファイルを編集します。これは、このトポロジに示されているものに加えてインストールしたノードで必要になります。

3.2.3 ストレージ・レプリケーション

この項では、共有ストレージにボリュームを作成する際のガイドラインを説明します。ストレージ・デバイスで使用可能なストレージ・レプリケーション・テクノロジの機能によっては、層内の各ノードでマウント・ポイント、ディレクトリおよびシンボリック・リンクを作成する必要がある場合があります。

ストレージ・デバイスのストレージ・レプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証される場合:

- その層で実行されるサーバーごとにボリュームを1つずつ作成します。たとえば、アプリケーション層では、WebLogicの管理サーバー用にボリュームを1つと管理対象サーバー用に別のボリュームを作成できます。

- 各層に対して、その層のボリュームをメンバーとするコンシステンシー・グループを1つ作成します。

- 2つのシステムによってボリュームが同時にマウントされる場合、ストレージ・サブシステムによっては、クラスタ・ファイル・システムが必要になることがあります。ただし、異なるシステム上のOracleプロセスが1つのファイルまたはディレクトリ・ツリーに同時にアクセスするという既知のケースはありません。NFSはクラスタ・ファイル・システムなので、NFSで接続されたストレージを使用している場合、クラスタ・ファイル・システム・ソフトウェアを追加する必要はありません。

ストレージ・デバイスのストレージ・レプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合:

- 各層にボリュームを1つずつ作成します。たとえば、アプリケーション層用のボリューム、Web層用のボリュームというように作成できます。

- その層の各ノード用に別個のディレクトリを作成します。たとえば、アプリケーション層のボリュームの下にSOAHOST1用のディレクトリを作成し、Web層のボリュームの下にWEBHOST1用のディレクトリを作成できます。

- ボリューム上のそのディレクトリに対するマウント・ポイント・ディレクトリを各ノードに作成します。

- マウント・ポイント・ディレクトリへのシンボリック・リンクを作成します。これにより、層内のノード間で同じディレクトリ構造を使用できるようになります。

- 2つのシステムによってボリュームが同時にマウントされる場合、ストレージ・サブシステムによっては、クラスタ・ファイル・システムが必要になることがあります。ただし、異なるシステム上のOracleプロセスが1つのファイルまたはディレクトリ・ツリーに同時にアクセスするという既知のケースはありません。NFSはクラスタ・ファイル・システムなので、NFSで接続されたストレージを使用している場合、クラスタ・ファイル・システム・ソフトウェアを追加する必要はありません。

注意:

障害時リカバリ・サイトの共有ストレージを設定する前に、『Oracle Fusion Middlewareリリース・ノート』の高可用性に関する章を参照して、高可用性環境で共有ストレージをベースとしたデプロイメントに関する既知の問題を確認してください。

Oracle Fusion Middlewareのリリース・ノートは次のURLにあります。

http://www.oracle.com/technology/documentation/middleware.html

3.2.4 ファイルベースの永続ストア

WebLogic Serverアプリケーション・サーバーは通常、高可用性を確保するためにクラスタ化されています。Oracle SOA Suiteトポロジのローカル・サイトの高可用性については、Java Message Service(JMS)およびトランザクション・ログ(TLog)にファイルベースの永続ストアを使用します。このファイルベースの永続ストアは、クラスタのすべてのメンバーがアクセス可能な共有ストレージに配置する必要があります。

ストレージ領域ネットワーク(SAN)ストレージ・システムでは、Oracle Clustered File System (OCFS2)など、ホストベースのクラスタまたは共有ファイル・システム・テクノロジを使用する必要があります。OCFS2は、対称型の共有ディスク・クラスタ・ファイル・システムです。これを使用すると、各ノードでメタデータとデータの両方をSANに対して直接読み書きできます。

NASストレージ・システムを使用している場合、クラスタ・ファイル・システムを追加する必要はありません。

3.3 データベースに関する考慮事項

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジで使用するOracle Databaseの設定に関する推奨事項と考慮事項を説明します。

- 使用するトポロジの要件に応じて、本番サイトとスタンバイ・サイトの両方にOracle Real Application Cluster (Oracle RAC)データベースを作成することをお薦めします。

- メタデータ・リポジトリを実行するデータベースについては、障害時保護テクノロジとしてOracle Data Guardをお薦めします。Oracle Active Data GuardまたはOracle GoldenGateを使用することもできます。

注意:

Oracle GoldenGateは、アクティブ-パッシブ構成でのみ使用できます。

詳細については、次の情報を参照してください。

- Oracle Active Data Guard:

http://www.oracle.com/in/products/database/options/active-data-guard/index.html

- Oracle GoldenGate:

http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html

- 使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定する必要があります。Oracle Data Guard構成を設定する前に、こうした情報が正しく特定されていることを確認してください。
詳細は、『Oracle Data Guard概念および管理』、および関連事項として次のURLにあるOracleの最大可用性アーキテクチャに関する情報を参照してください。

http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm

- 同期REDO転送によってレスポンス時間やスループットに影響が生じる可能性があるため、必ず十分な帯域幅を備えた、待機時間の少ないネットワークを構成してください。

- スタンバイ・サイトのデータベースのLOG_ARCHIVE_DEST_nパラメータにSYNCまたはASYNC属性を指定しておく必要があります。属性を指定しなかった場合は、デフォルトでASYNCに設定されます。

- スタンバイ・サイトのデータベースは、管理リカバリ・モードである必要があります。これによって、スタンバイ・サイトのデータベースは常にメディア・リカバリの状態になります。管理リカバリ・モードを使用すると、フェイルオーバー時間を短縮できます。

- 本番サイトとスタンバイ・サイトのtnsnames.oraファイルに、本番サイトとスタンバイ・サイト両方のデータベースをエントリしておく必要があります。

- Oracle Data Guardでは、中間層の同期が実行される場合はいつでも、必ず手動によるデータベース同期を実行することをお薦めします。これは特に、メタデータ・リポジトリに構成データを格納するコンポーネントにとって重要です。

- 本番サイトとスタンバイ・サイトの両方でデータベース・ホスト名の別名を設定することを強くお薦めします。これによって、シームレスなスイッチオーバー、スイッチバックおよびフェイルオーバーが実現します。

- どちらかのサイトのデータベースの1つがOracle RACデータベースである場合、ピア・サイトの単一のインスタンス・データベースにinstance_nameの値と同じ値がある必要があります。

注意:

- 中間層のORACLE_HOME、home、ORACLE_INSTANCE、DOMAIN_HOMEの値は同一である必要があります。

- データベース層のDB_NAME、INSTANCE_NAME、Listen PortおよびORACLE_SIDの値は同一である必要があります。

- WLSデータソースの操作を回避するには、アプリケーション・データソースで指定されたSERVICE_NAMEが同一である必要があります。ただし、各データベースは、追加のサービスを定義できます。

3.3.1 データベースのTNSNAMES.ORAエントリの作成

Oracle Data Guardでは本番データベースとスタンバイ・データベースが同期されるため、本番データベースとスタンバイ・データベースが相互を参照できる必要があります。

Oracle Data Guardでは、tnsnames.oraファイル・エントリを使用して、本番データベースとスタンバイ・データベースにリクエストを送信します。そのため、本番データベースとスタンバイ・データベースのエントリをtnsnames.oraファイルに作成する必要があります。Oracle Data Guardでtnsnames.oraファイルを使用する方法の詳細は、Oracle Databaseのドキュメント・セットにある『Oracle Data Guard概念および管理』を参照してください。

3.3.2 Oracle Data Guardを使用した手動によるデータベースの強制同期

中間層の構成データをOracle Database・リポジトリに格納するOracle Fusion Middlewareコンポーネントについては、中間層の同期が実行された場合は必ず、Oracle Data Guardを使用して、データベースを手動で強制的に同期してください。alter system archive log allというSQL文を使用して、ログを切り替えます。これにより、本番サイトとスタンバイ・サイトのデータベースの同期が強制的に行われます。

例3-9に、本番サイトのデータベースとスタンバイ・サイトのデータベースを強制的に同期する場合に使用するSQL文を示します。

例3-9 手動によるOracle Data Guardデータベースの強制同期

ALTER SYSTEM ARCHIVE LOG ALL;

3.3.3 データベース・ホスト名の別名の設定

必要に応じて、本番サイトとスタンバイ・サイトのデータベースにデータベース・ホスト名の別名を設定できます。この別名は、DNSまたはデータベース・インスタンスを実行する各ノードの/etc/hostsファイルで定義する必要があります。

障害時リカバリ環境では、アクティブに接続を受け取るサイトが本番サイトになります。フェイルオーバー操作またはスイッチオーバー操作が正常に完了すると、スタンバイ・サイトが新しい本番サイトになります。

この項の例では、custdbhost1およびstbycustdbhost1という名前のデータベース・ホストの別名を定義します。表3-7に、別名を定義する前のデータベース・ホスト名とデータベース接続文字列を示します。

表3-7 データベース・ホスト名と接続文字列

サイト

データベース・ホスト名

データベース接続文字列

本番

custdbhost1.example.com

custdbhost1.example.com:1521:orcl

スタンバイ

stbycustdbhost1.example.com

stbycustdbhost1.example.com:1521:orcl

この例では、本番サイトのすべてのデータベース接続文字列にcustdbhost1.example.com:1521:orclという形式を使用します。フェイルオーバー操作またはスイッチオーバー操作の後、この接続文字列をstbycustdbhost1.example.com:1521:orclに変更する必要があります。ただし、表3-8に示されているように、データベース・ホスト名にproddb1という別名を作成することで、接続文字列を手動で変更しなくて済むようにすることができます。これにより、シームレスなフェイルオーバーとスイッチオーバーが実現します。

表3-8 データベース・ホストの別名の指定

サイト

データベース・ホスト名

別名

データベース接続文字列

本番

custdbhost1.example.com

proddb1.example.com

proddb1.example.com:1521:orcl

スタンバイ

stbycustdbhost1.example.com

proddb1.example.com

proddb1.example.com:1521:orcl

この例では、本番サイトのデータベース・ホスト名とスタンバイ・サイトのデータベース・ホスト名にproddb1.example.comという別名を作成します。また、本番サイトとスタンバイ・サイトの接続文字列にproddb1.example.com:1521:orclという形式を使用できます。フェイルオーバー操作およびスイッチオーバー操作の際、接続文字列を変更する必要がないため、シームレスなフェイルオーバーとスイッチオーバーが実現します。

/etc/hostsファイル・エントリで別名を指定する際の形式は次のとおりです。

IP    ALIAS_WITH_DOMAIN ALIAS    HOST_NAME_WITH_DOMAIN HOST_NAME

この例では、本番サイトのホストcustdbhost1とスタンバイ・サイトのホストstbycustdbhost1にproddb1というデータベース・ホスト名の別名を作成します。hostsファイル・エントリでは、ALIAS_WITH_DOMAINパラメータでデータベース・ホスト名の完全修飾された別名を、ALIASパラメータでデータベース・ホスト名の短い別名を、HOST_NAME_WITH_DOMAINパラメータで完全修飾されたホスト名を、HOST_NAMEパラメータで短いホスト名を指定する必要があります。

そのため、本番サイトの/etc/hostsファイルで、ホストcustdbhost1のエントリは次のようになることを確認してください。

152.68.196.213 proddb1.example.com proddb1 custdbhost1.example.com custdbhost1

また、スタンバイ・サイトの/etc/hostsファイルで、ホストstbycustdbhost1のエントリは次のようになることを確認してください。

140.87.25.40   proddb1.example.com proddb1 stbycustdbhost1.example.com stbycustdbhost1

3.4 開始ポイント

スタンバイ・サイトを設定する前に、管理者はプロジェクトの開始ポイントを評価する必要があります。通常、Oracle Fusion Middleware障害時リカバリ・トポロジを設計する際の開始ポイントは次のいずれかです。

- 本番サイトがすでに作成されており、スタンバイ・サイトが計画および作成中です。
既存の本番サイトがある場合にOracle Fusion Middleware障害時リカバリのスタンバイ・サイトを設計する方法については、第3.4.1項「既存のサイトを基にした設計」を参照してください。

- 既存の本番サイトもスタンバイ・サイトもありません。両方とも設計して作成する必要があります。
既存の本番サイトもスタンバイ・サイトもない場合にOracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく設計する方法については、第3.4.2項「新しいサイトの設計」を参照してください。

- 一部のホストやコンポーネントが現在の本番サイトに存在するものの、そのサイトまたはスタンバイ・サイトに新しいホストやコンポーネントを追加して、適切に機能するOracle Fusion Middleware障害時リカバリ・トポロジを設定する必要があります。
この章に記載されている関連情報を参考にして、Oracle Fusion Middleware障害時リカバリ・トポロジを設計および実装してください。

3.4.1 既存のサイトを基にした設計

管理者の開始ポイントが既存の本番サイトである場合、本番サイトの構成データおよびOracleバイナリ・ファイルがファイル・システムにすでに存在します。また、ホスト名、ポートおよびユーザー・アカウントもすでに定義されています。本番サイトが存在する場合、管理者は次の方法を選択できます。

- 対称スタンバイ・サイトを設計します。第3.5.1項「対称トポロジの設計に関する考慮事項」を参照してください。

- 非対称スタンバイ・サイトを設計します。第3.5.2項「非対称トポロジの設計に関する考慮事項」を参照してください。

- 本番サイトが共有ストレージにない場合、本番サイトを共有ストレージに移行し、対称スタンバイ・サイトまたは非対称スタンバイ・サイトを作成します。第3.4.1.1項「共有ストレージへの既存の本番サイトの移行」を参照してください。

3.4.1.1 共有ストレージへの既存の本番サイトの移行

Oracle Fusion Middleware障害時リカバリ・ソリューションでは、共有ストレージを使用して、Oracle Fusion Middlewareの中間層構成の障害時保護に使用するストレージ・レプリケーションを実装します。本番サイトがすでに作成されている場合、サイトを構成するOracle Fusion MiddlewareインスタンスのOracleホーム・ディレクトリが共有ストレージに配置されていない可能性があります。その場合、Oracle Fusion Middleware障害時リカバリ・ソリューションを実装するには、それらのホームをすべて共有ストレージに移行する必要があります。

ローカル・ディスクから共有ストレージに本番サイトを移行する際のガイドラインは次のとおりです。

- 実行するバックアップはすべて、オフライン・バックアップである必要があります。詳細は、『Oracle Fusion Middleware管理者ガイド』のバックアップのタイプに関する説明および推奨されるバックアップ計画に関する説明を参照してください。

- ルート・ユーザーとしてバックアップを実行する必要があり、その権限を保持している必要があります。『Oracle Fusion Middleware管理者ガイド』のバックアップ計画の概要に関する説明を参照してください。

- これは1回のみの操作であるため、ドメイン全体をリカバリする必要があります。

- 共有ストレージのディレクトリ構造は、第4.1.1項の説明に従って設定する必要があります。

- Oracle SOA Suiteについては、『Oracle Fusion Middleware管理者ガイド』のバックアップおよびリカバリの概要に関する項を参照してください。

- Web層については、『Oracle Fusion Middleware管理者ガイド』のバックアップおよびリカバリの概要に関する項を参照してください。

3.4.2 新しいサイトの設計

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジの新しい本番サイトを実装する際の考え方を紹介します。ここでは、ホスト名を事前に計画し、ホスト名別名と物理ホスト名を解決するようにホストを構成して、これらの名前に基づいて構成をスタンバイ・サイトにコピーするようにストレージ・レプリケーションを設定することによって、本番サイトを計画および設定する方法について説明します。本番サイトを設計する際には、スタンバイ・サイトについても計画する必要があります。対称スタンバイ・サイトまたは非対称スタンバイ・サイトのいずれかを選択できます。

既存の本番サイトを使用せずに新しい本番サイトを設計する場合は、Oracle Universal Installerを使用して本番サイトにソフトウェアをインストールし、ホスト名別名やソフトウェア・パスなどのパラメータが両方のサイトで同じになるように慎重に設計する必要があります。

Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく作成する場合、次のような選択肢があります。

- 本番サイトとスタンバイ・サイトの各ホストが目的のホスト名別名および物理ホスト名を使用するように、Oracle Fusion Middleware障害時リカバリ・ソリューションを設計できます。ホスト名の計画の詳細は、第3.1.1項を参照してください。

- 独自の本番サイトを設計して作成する場合、各Fusion MiddlewareインストールのOracleホーム名およびOracleホーム・ディレクトリを選択できます。
サイトを最初から設計して作成する方が、この章で説明した設計要件に合せて既存のサイトを変更するよりも簡単です。

- 本番サイトのホストのOracle Fusion Middlewareインストールに、スタンバイ・サイトのホストで使用するポートと競合しないポートを割り当てることができます。
既存の本番サイトとスタンバイ・サイト間におけるポートの競合を確認して解決するよりも、この方が簡単です。

3.5 トポロジに関する考慮事項

この項には次のトピックが含まれます:

- 対称トポロジの設計に関する考慮事項

- 非対称トポロジの設計に関する考慮事項

3.5.1 対称トポロジの設計に関する考慮事項

対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層がまったく同じように構成されます。対称トポロジでは、本番サイトとスタンバイ・サイトで同じ数のホスト、ロード・バランサ、インスタンスおよびアプリケーションを使用します。また、両方のサイトで同じポートが使用されます。システムはまったく同じように構成され、アプリケーションは同じデータにアクセスします。このマニュアルでは、エンタープライズ構成用に、Oracle Fusion Middleware障害時リカバリで対称トポロジを設定する方法について説明します。

3.5.2 非対称トポロジの設計に関する考慮事項

非対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層の構成に相違があります。非対称トポロジでは、スタンバイ・サイトで使用するハードウェアの数が少ない場合があります(本番サイトには4つのホストと4つのOracle Fusion Middlewareインスタンスがあるのに対して、スタンバイ・サイトには2つのホストと4つのOracle Fusion Middlewareインスタンスがある場合など)。または、別の非対称トポロジでは、スタンバイ・サイトで使用するOracle Fusion Middlewareインスタンスの数が少ない場合があります(本番サイトには4つのOracle Fusion Middlewareインスタンスがあるのに対して、スタンバイ・サイトには2つのOracle Fusion Middlewareインスタンスがある場合など)。別の非対称トポロジでは、データベースのための異なる構成が含まれている場合があります(本番サイトでOracle Real Application Clusters (Oracle RAC)データベースを、スタンバイ・サイトで単一のインスタンス・データベースを使用する場合など)。

4 障害時リカバリ・サイトの設定と管理

この章では、Oracle SOA Suiteのエンタープライズ・デプロイメント・トポロジを使用して、本番サイトおよびスタンバイ・サイトの設定に必要な手順を説明します。

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

- 第4.1項「サイトの設定」

- 第4.2項「本番サイトの作成」

- 第4.3項「スタンバイ・サイトの作成」

- 第4.4項「非対称スタンバイ・サイトの作成」

- 第4.5項「サイトの操作および管理の実行」

- 第4.6項「障害時リカバリのためのOracle Site Guardの使用」

- 第4.7項「Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用」

注意:

スイッチオーバーやフェイルオーバーなどの障害時リカバリ操作は、Oracle Site Guardを使用して自動化できます。詳細は、Oracle Site Guard管理者ガイドを参照してください。

4.1 サイトの設定

この項では、サイトを設定する手順を説明します。

次のトピックが含まれます:

- ディレクトリ構造とボリューム設計

- ストレージ・レプリケーション

- データベース

本番サイトの作成を開始する前に、次の手順を実行します。

- 第3.1.1項で説明されているように、中間層ホストのホスト名別名を設定します。

- 本番サイトの共有ストレージに必要なボリュームを作成します。第4.1.1項を参照してください。

- 使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定します。
詳細は、『Oracle Data Guard概念および管理』、および関連事項として次のURLにある最大可用性アーキテクチャに関する情報を参照してください。

http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm

4.1.1 ディレクトリ構造とボリューム設計

次の項では、お薦めするディレクトリ構造について詳しく説明します。エンド・ユーザーは他のディレクトリ・レイアウトを選択してもかまいませんが、ここで採用されているモデルを使用すると、コンポーネントが最適に分離され、構成における対称性が保たれるとともに、バックアップと障害時リカバリが容易になり、最大限の可用性が実現されます。

次の一覧では、ディレクトリとディレクトリ環境変数について説明します。

- ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを表します。

- Oracle_Home: この関連ディレクトリ・パスは、Oracle Fusion Middlewareが存在する場所を指します。

- WL_HOME: この環境変数と関連ディレクトリ・パスには、Oracle WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。

- ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、製品スイート(Oracle SOA Suite、Oracle WebCenter Portal、Oracle Identity Managementなど)がインストールされている場所を表します。

- DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogic Domain情報(構成アーティファクト)が保存されている場所を表します。各種のWebLogic Serverは、同じノード内にある場合でも異なるドメイン・ディレクトリを使用できます。

- ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなど、1つ以上のシステム・コンポーネントが格納されます。Oracleインスタンスのディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されます。

詳細は、「Oracle SOA Suiteのディレクトリ構造に関する推奨事項」を参照してください。

4.1.1.1 Oracle SOA Suiteのディレクトリ構造に関する推奨事項

Oracle Fusion Middleware 12cでは、1つのバイナリ・インストールから複数のSOA管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリ・ファイルをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのOracleホーム(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがある)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムへの配置もサポートされていますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-1は、Oracle SOA Suiteのディレクトリ構造のレイアウトを示しています。

図4-1 SOAのディレクトリ構造

このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

4.1.1.1.1 Oracle SOA Suiteのボリューム設計

図4-2および図4-3は、Oracle SOA Suiteのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle SOA Suiteトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

図4-2 Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジのダイアグラム

図4-3 Oracle SOA SuiteおよびOracle Service Busエンタープライズ・デプロイメント参照用トポロジのダイアグラム

このOracle SOA Suiteトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。

- 製品の冗長バイナリ・ファイルを格納する2つのOracleホーム用にボリュームを2つプロビジョニングします(表4-1のVOLFMW1およびVOLFMW2)。

- 管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-1のVOLADMIN)。

- 管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-1のVOLSOA1およびVOLSOA2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。

- JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-1のVOLDATA)。ドメイン全体で1つのボリュームが、ドメインのすべてのノードでマウントされます。

- Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-1のVOLWEB1およびVOLWEB2)。

- Oracle HTTP ServerのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-1のVOLWEBINST1およびVOLWEBINST2)。

表4-1に、図4-2および図4-3に示されているOracle SOA Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。

表4-1 Oracle SOA Suiteのボリューム設計に関する推奨事項

層

ボリューム名

マウントされるホスト

マウント・ポイント

コメント

Web

VOLWEB1

WEBHOST1

/u01/oracle/products/fmwnnnn/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEB2

WEBHOST2

/u01/oracle/products/fmwnnnn/web

Oracle HTTP Serverインストール用のボリューム

Web

VOLWEBINST1

WEBHOST1

/u01/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLWEBINST2

WEBHOST2

/u01/oracle/admin/ohs_instance

Oracle HTTP Serverインスタンス用のボリューム

Web

VOLSTATIC1脚注 1

WEBHOST1

/u01/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

Web

VOLSTATIC2脚注 2

WEBHOST2

/u01/oracle/admin/ohs_instance/config/static

静的HTMLコンテンツ用のボリューム

アプリケーション

VOLFMW1

SOAHOST1

/u01/oracle/products/fmwnnnn/

WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム

アプリケーション

VOLFMW2

SOAHOST2

/u01/oracle/products/fmwnnnn/

WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム

アプリケーション

VOLADMIN

SOAHOST1

/u01/oracle/admin/soaDomain/admin

管理サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLSOA1

SOAHOST1

/u01/oracle/admin/soaDomain/mng1

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLSOA2

SOAHOST2

/u01/oracle/admin/soaDomain/mng2

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLDATA

SOAHOST1、SOAHOST2

/u01/oracle/config/soaDomain/soaCluster/jms

/u01/oracle/config/soaDomain/soaCluster/tlogs

トランザクション・ログおよびJMSデータ用のボリューム

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.1.2 Oracle SOA Suiteのコンシステンシー・グループに関する推奨事項

Oracle SOA Suiteトポロジについては、次のコンシステンシー・グループをお薦めします。

- 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2のDOMAINGROUP)。

- JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2のDATAGROUP)。

- Oracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2のFMWHOMEGROUP)。

- Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2のWEBHOMEGROUP)。

- Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-2のWEBINSTANCEGROUP)。

表4-2に、図4-2に示されているOracle SOA Suiteトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-2 Oracle SOA Suiteのコンシステンシー・グループ

層

グループ名

メンバー

コメント

アプリケーション

DOMAINGROUP

VOLADMIN

VOLSOA1

VOLSOA2

管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ

アプリケーション

DATAGROUP

VOLDATA

JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ

アプリケーション

FMWHOMEGROUP

VOLFMW1

VOLFMW2

Oracleホーム用のコンシステンシー・グループ

Web

WEBHOMEGROUP

VOLWEB1

VOLWEB2

Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ

Web

WEBINSTANCEGROUP

VOLWEBINST1

VOLWEBINST2

VOLSTATIC1脚注 1

VOLSTATIC2脚注 2

Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.2 ストレージ・レプリケーション

Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定するには、次の手順を実行します。

- スタンバイ・サイトで、本番サイトのピア・ホストに使用されている物理ホスト名と同じホスト名別名が作成されていることを確認します。

- スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。

- スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンクを作成します(スタンバイ・サイトでシンボリック・リンクを設定する必要があるのは、本番サイトでシンボリック・リンクを設定した場合のみです)。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項を参照してください。

- 本番サイトにインストールしたものと同じOracle Fusion Middlewareインスタンスをスタンバイ・サイトにインストールする必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているOracleソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。

- 本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、本番サイトとスタンバイ・サイトの共有ストレージ間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。

- スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。

- Oracle Fusion Middleware障害時リカバリの本番サイトに含まれているデータベースの障害保護機能がOracle Data Guardによって提供されていることを確認します。Oracle Databaseの障害保護にストレージ・レプリケーション・テクノロジは使用しないでください。

- スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。

- 本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行することを強くお薦めします。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。

4.1.3 データベース

この項では、Oracle Database 11.2または12.1 MAA環境をOracle SOA Suiteエンタープライズ・デプロイメントにインストールおよび構成する方法について説明します。

Oracle Fusion Middleware障害時リカバリ・トポロジで使用されるOracleデータベースの設定に関する推奨事項と考慮事項は、第3.3項を参照してください。

4.1.3.1 Oracle Database 11.2または12.1 MAA環境のインストールおよび構成

Oracle Maximum Availability Architecture (MAA)は、計画停止の停止時間を短縮し、計画外停止を防止、検出およびリカバリするOracleの包括的なアーキテクチャです。

Real Application Clusters (RAC)およびData Guardは、プライマリ・サイトにRACデータベースが含まれ、セカンダリ・サイトにRAC物理スタンバイ・データベースが含まれるデータベースMAAソリューションの基礎を提供します。

この項には次のトピックが含まれます:

- 前提条件

- Oracle Data Guard環境の説明

- プライマリ・データベースの複製の手順

- スタンバイ・データベースのRAC構成の完了の手順

- Data Guard Broker構成の作成

- Data Guard Broker構成の検証

- データベースのスイッチオーバーおよびスイッチバックのテスト

ヒント:

また、この項のタスクの多くはOracle Enterprise Manager Cloud Control (Cloud Control)を使用して実行することもできます。

Cloud Controlを使用したデータベースの設定および管理は、ダウンタイムの制御および障害時リカバリ操作の簡略化に役立ちます。

Enterprise Manager Cloud Control 12cのインストールの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

Cloud Controlを使用したOracle Data Guardの設定の詳細は、Oracle Enterprise Manager Cloud Control 12cによるOracle Data Guardの設定および管理を参照してください。

4.1.3.1.1 前提条件

次の前提条件が満たされていることを確認してください。

- スタンバイ・サイトのOracle RACクラスタおよび自動ストレージ管理(ASM)インスタンスが作成済です。

- スタンバイ・サイトおよび本番サイトのOracle RACデータベースでフラッシュ・リカバリ領域を使用しています。

- Oracle RACデータベースがarchivelogモードで実行されています。

- スタンバイ・サイトのデータベース・ホストにOracleソフトウェアがすでにインストールされています。

- 共有ORACLE_HOME構成では、TNS_ADMINディレクトリはローカルの非共有ディレクトリである必要があります。

4.1.3.1.2 Oracle Data Guard環境の説明

この項で示す例には、表4-3で説明する環境変数が含まれています。

表4-3 プライマリおよびスタンバイ・データベースで使用される変数

変数

プライマリ・データベース

スタンバイ・データベース

データベース名

soa

soa

SOAデータベースのホスト名

soadc1.dbhost1、soadc1.dbhost2

soadc2.dbhost1、soadc2.dbhost2

データベースの一意の名前

psoa

ssoa

インスタンス名

soa1、soa2

soa1、soa2

サービス名

psoa、ssoa

psoa、ssoa

4.1.3.1.3 プライマリ・データベースの複製の手順

次の手順に従って、Oracle Data Guardの設定用のプライマリ・データベースを準備します。

注意:

Oracle Data Guardの設定の前提条件の詳細は、『Oracle Data Guard Broker』の前提条件に関する項を参照してください。

1. プライマリ・データベースで強制ロギングを使用可能にします。

SQL> alter database force logging;
SQL> select name, log_mode, force_logging from v$database;
NAME LOG_MODE FOR
---------- ---------------- -------
PSOA ARCHIVELOG YES

2. スタンバイ・ノード1で、例4-1に示すように、スタンバイ・データベースの静的SIDエントリを提供し、プライマリ(soa1)と同じORACLE_SIDの値を持つリスナー(たとえば、LISTENER_DUPLICATE)を作成し、起動します。

listener.oraファイルへの次のパスを提供します。

GRID_HOME/network/admin/listener.ora

例4-1 静的SIDを持つリスナーを作成および起動するスクリプト

LISTENER_duplicate =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = soadc2.dbhost1)
(PORT = 1521)(IP = FIRST))))

SID_LIST_LISTENER_duplicate =
(SID_LIST =
(SID_DESC =
(SID_NAME = soa1)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)))

3. 次のコマンドを実行して、リスナーを起動および検証します。

lsnrctl start listener_duplicate
lsnrctl status listener_duplicate

4. スタンバイ・ノード2で、例4-2に示すように、スタンバイ・データベースの静的SIDエントリを提供し、プライマリ(soa2)と同じORACLE_SIDの値を持つリスナー(たとえば、LISTENER_DUPLICATE)を作成し、起動します。
listener.oraファイルへの次のパスを提供します。

GRID_HOME/network/admin/listener.ora

例4-2 静的SIDを持つリスナーを作成および起動するスクリプト

LISTENER_duplicate =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = soadc2.dbhost2)
(PORT = 1521)(IP = FIRST))))

SID_LIST_LISTENER_duplicate =
(SID_LIST =
(SID_DESC =
(SID_NAME = soa2)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)))

注意:

リスナーはクラスタ・レベルで構成され、すべてのノードがリスナーのポートおよび環境設定を継承します。したがって、TNS_ADMINディレクトリ・パスはすべてのノードで同じ値を持ちます。

共有ORACLE_HOME構成では、TNS_ADMINディレクトリはローカルの非共有ディレクトリである必要があります。これらのネットワーク・ファイルはIFILESとして含まれます。

次の手順を実行して、それぞれインスタンスSOA1およびSOA2を持つSOADC1.DBHOST1およびSOADC1.DBHOST2の2ノード・クラスタに共有ORACLE_HOMEのTNS_ADMINを設定します。

1. 各ノードにローカル・ネットワーク・ディレクトリを作成します。たとえば、/local_network_dir/network_adminなどです。

2. 各ノードの場所/local_network_dir/network_adminにローカルlistener.oraファイルを作成します。

3. ローカルlistener.oraファイルに、LISTENER_duplicateパラメータの値を追加します。

4. 共通listener.oraファイルのGRID_HOME/network/adminに、IFILEパラメータ値を次のように追加します。

IFILE=/local_network_dir/network_admin/listener.ora

5. 次のコマンドを実行して、リスナーを起動および検証します。

lsnrctl start listener_duplicate
lsnrctl status listener_duplicate

6. プライマリ・ノードのデータベース・ホームに、手順2で作成したリスナーに接続するためのOracle Net別名を作成します。例4-3を参照してください。

例4-3 Oracle Net別名を作成するスクリプト

dup =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = soadc2.dbhost1)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = soa1)))

7. REDOトランスポート用のOracleパスワード・ファイル認証を構成します。次の要件を満たすことを確認します。

- remote_login_passwordfileをEXCLUSIVEに設定します。

SQL> show parameter
remote_login_passwordfile
NAME TYPE VALUE
--------------------------------- -------------- --------------------------------
remote_login_passwordfile string EXCLUSIVE

- プライマリおよびスタンバイ・データベースにバイト単位で同一のパスワード・ファイルがあることを確認します。

8. スタンバイ・ホストのORACLE_HOME/dbsディレクトリで、次のパラメータを使用してpfile、initsoa1.oraを作成します。

db_name=soa
db_unique_name=ssoa
sga_target=5g

9. すべてのスタンバイ・ホストにsoaデータベースの監査ディレクトリを作成します。

mkdir -p /u01/app/oracle/admin/soa/adump

10. スタンバイ・ホスト上のssoaデータベースにアクセスするために、Oracle Net別名をすべてのプライマリ・ホストに作成します。
すべてのホストにpsoa and ssoa用のOracle Net別名があることを確認します。作成するすべての別名は、ノードVIPではなくスキャン・リスナーを参照する必要があります。また、local_listener変数がプライマリ・ホストの別名に設定されている場合は、スタンバイ・サイトに、プライマリ・ホスト上のローカル・リスナーを指す変数の詳細を入力します。例4-4と例4-5を参照してください。

例4-4 プライマリ・ノード1 (SOADC1.DBHOST1)のサンプルtnsnames.oraファイル

psoa =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL= TCP)
(HOST=prmy-scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = psoa)
)
)

ssoa =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby-scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ssoa)
)
)

psoa_local_listener =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=prmy1-vip)(PORT = 1521))
)
)

注意:

- プライマリ・ノード2 (SOADC1.DBHOST2)では、次のように、プライマリ・ノード2のVIPを指すようにpsoa_local_listenerのHOST値を更新します。

psoa_local_listener =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=prmy2-vip)(PORT = 1521))
)
)

- 共有Oracleホームを使用している場合は、2つのノードのVIPをlocal_listenerパラメータに追加します。
例:

psoa_local_listener =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=prmy1-vip)(PORT = 1521))
(ADDRESS=(PROTOCOL = TCP)
(HOST=prmy2-vip)(PORT = 1521))
)
)

例4-5 スタンバイ・ノード1 (SOADC2.DBHOST1)のサンプルtnsnames.oraファイル

psoa =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL= TCP)(HOST=prmy-scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = psoa)
)
)

ssoa =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby-scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ssoa)
)
)

ssoa_local_listener =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby1-vip)(PORT = 1521))
)
)

注意:

- スタンバイ・ノード2 (SOADC2.DBHOST2)では、次のように、スタンバイ・ノード2のVIPを指すようにssoa_local_listenerのHOST値を更新します。

ssoa_local_listener = (ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby2-vip)(PORT = 1521))
)
)

- 共有Oracleホームを使用している場合は、2つのノードのVIPをlocal_listenerパラメータに追加します。
例:

ssoa_local_listener =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby1-vip)(PORT = 1521))
(ADDRESS=(PROTOCOL = TCP)
(HOST=stby2-vip)(PORT = 1521))
)
)

11. スタンバイ・ホストで、ORACLE_SIDをプライマリ・データベースと同じ値(ORACLE_SID=soa1)に設定し、スタンバイPFILEを使用してスタンバイ・データベースでstartup nomountコマンドを実行します。

12. プライマリ・ホストでパラメータcluster_interconnectsが設定されている場合は、これを無効にします。

SQL> alter system reset cluster_interconnects scope=spfile sid='soa1';
SQL> alter system reset cluster_interconnects scope=spfile sid='soa2';

13. プライマリ・ホストで、Recovery Manager (RMAN)スクリプトを実行して、コマンドduplicate target database for standby from active databaseを使用してプライマリ・データベースを複製します。

注意:

このコマンドは、環境によって異なります。コマンドの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータベースの複製に関する項を参照してください。

例4-6を参照して、異なるディスクグループ名を持つ2つのシステム間での複製方法を理解します。

例4-6 異なるディスクグループ名を持つ2つのシステム間でのデータの複製

rman <<EOF
connect target sys/password;
connect auxiliary sys/password@dup;
run {
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate channel prmy3 type disk;
allocate channel prmy4 type disk;
allocate auxiliary channel stby type disk;
duplicate target database for standby from active database
spfile
parameter_value_convert '+DATA_prmy','+DATA_stby','+RECO_prmy','+RECO_stby'
set db_file_name_convert '+DATA_prmy','+DATA_stby'
set db_unique_name='ssoa'
set db_create_online_log_dest_1='+DATA_stby'
set db_create_file_dest='+DATA_stby'
set db_recovery_file_dest='+RECO_stby'
set log_file_name_convert '+DATA_prmy','+DATA_stby','+RECO_prmy','+RECO_stby'
set control_files='+DATA_stby/ssoa/standby.ctl'
set local_listener='ssoa_local_listener'
set remote_listener='stby-scan:1521';
} EOF

例4-7を参照して、同じディスクグループ名+DATAを持つ2つのシステム間での複製方法を理解します。

例4-7 同じディスクグループ名+DATAを持つ2つのシステム間でのデータの複製

rman <<EOF
connect target sys/password;
connect auxiliary sys/password@dup;
run {
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate channel prmy3 type disk;
allocate channel prmy4 type disk;
allocate auxiliary channel stby type disk;

duplicate target database for standby from active database
spfile
set db_unique_name='ssoa'
set control_files='+DATA/ssoa/standby.ctl'
set local_listener='ssoa_local_listener'
set remote_listener='stby-scan:1521';
}
EOF

14. 手順12で説明するように、プライマリ・ホストでパラメータcluster_interconnectsを無効にした場合は、spfileで元の値に戻す必要があります。

15. (オプション) 手順2で作成したリスナーを停止し、削除します。

4.1.3.1.4 スタンバイ・データベースのRAC構成の完了の手順

スタンバイ・データベースでRAC構成を完了するには、第4.1.3.1.3項の手順を実行します。さらに、次の手順を実行します。

1. 一時パラメータ・ファイルを作成します。

SQL> create pfile='/tmp/p.ora' from spfile;

2. スタンバイ・データベースの+DATA_stbyにSPFILEを作成します。

SQL> create spfile='+DATA_stby/ssoa/spfilessoa.ora' from pfile='/tmp/p.ora';

3. すべてのスタンバイ・ホストにinitsoan.oraファイルを作成します。ファイルは、手順2で作成したSPFILEの場所を指す必要があります。

4. スタンバイ・システムで、マウント状態のインスタンスを再起動します。

startup mount

5. 次のようにRACデータベースをCRSに登録します。

srvctl add database -d ssoa –o /u01/app/oracle/product/11.2.0/db_1
srvctl add instance -d ssoa -i soa1 -n soadc2.dbhost1
srvctl add instance -d ssoa -i soa2 -n soadc2.dbhost2
srvctl modify database –d ssoa –r physical_standby

6. オンラインREDOログと同じサイズのスタンバイREDOログをプライマリ・データベースとスタンバイ・データベースに作成します。
例4-8に示すように、同じ数に1つ加えた追加のREDOログを各スレッドで使用することをお薦めします。

例4-8 サンプルREDOログ

SQL> alter database add standby logfile thread 1
group 9 size 500M,
group 10 size 500M,
group 11 size 500M;

SQL> alter database add standby logfile thread 2
group 12 size 500M,
group 13 size 500M,
group 14 size 500M;

4.1.3.1.5 Data Guard Broker構成の作成

この項では、Data Guard構成の作成の基本的な手順について説明します。

Data Guard Brokerの詳細は、『Oracle Data Guard Broker』ガイドを参照してください。

Data Guard Broker構成を作成するには、次の手順を実行します。

1. 静的SIDの値を、構成のすべてのホストのグリッド・インフラストラクチャ・ホームにあるローカル・ノード・ファイルlistener.oraに追加します。

LISTENER_SCAN2=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN2))))
LISTENER_SCAN3=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN3))))
LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER))))

LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1))))
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1=ON
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = psoa_DGMGRL)
(SID_NAME = soa1)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)))
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN3=ON

注意:

- 各ホストのパラメータGLOBAL_DBNAMEおよびSID_NAMEに適切な値を入力します。

- IFILEが共有ORACLE_HOMEに使用されている場合は、IFILEで指定した対応するローカルlistener.oraファイルを変更します。

2. プライマリ・サイトとスタンバイ・サイトのリスナーをバウンスして、ファイルに対する変更を適用します。

srvctl stop listener
srvctl start listener

3. Data Guard Brokerメタデータ・ファイルを構成し、プライマリ・サイトとスタンバイ・サイトでブローカを次のように有効化します。
プライマリ・サイト

SQL> alter system set dg_broker_config_file1='+DATA_prmy/psoa/dr1.dat' scope=both;
SQL> alter system set dg_broker_config_file2='+DATA_prmy/psoa/dr2.dat' scope=both;
SQL> alter system set dg_broker_start=true scope=both;

スタンバイ・サイト

SQL> alter system set dg_broker_config_file1='+DATA_stby/ssoa/dr1.dat' scope=both;
SQL> alter system set dg_broker_config_file2='+DATA_stby/ssoa/dr2.dat' scope=both;
SQL> alter system set dg_broker_start=true scope=both;

4. プライマリ・ホストでdgmgrlにアクセスし、構成を作成します。例4-9を参照してください。

例4-9 dgmgrlへのアクセスによるプライマリ・ホストのData Guard Broker構成の作成

dgmgrl sys/password

DGMGRL> create configuration 'dg_config' as
primary database is 'psoa'
connect identifier is psoa;

Configuration "dg_config" created with primary database "psoa"

DGMGRL> add database 'ssoa' as
connect identifier is ssoa;

Database "ssoa" added

DGMGRL> enable configuration;

Enabled.

4.1.3.1.6 Data Guard Broker構成の検証

次の手順を実行して、Data Guard Broker構成が正常に作成されたことを確認します。

1. V$ARCHIVED_LOGビューへの問合せを実行して、アーカイブされたREDOログ内の既存のファイルを特定することで、Oracle Data Guardの構成を確認します。例:

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME
2> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME NEXT_TIME
---------- ------------------ ------------------
8 11-JUL-13 17:50:45 11-JUL-13 17:50:53
9 11-JUL-1317:50:53 11-JUL-1317:50:58
10 11-JUL-13 17:50:58 11-JUL-13 17:51:03

3 rows selected

2. プライマリ・データベースで、次のSQL文を発行してログ切替えを強制し、現在のオンラインREDOログ・ファイル・グループをアーカイブします。

SQL> alter system archive log current;

3. スタンバイ・データベースでV$ARCHIVED_LOGビューへの問合せを実行して、REDOデータがスタンバイ・データベースで受信およびアーカイブされていることを確認します。

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME
2> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME NEXT_TIME
---------- ------------------ ------------------
8 11-JUL-13 17:50:45 11-JUL-13 17:50:53
9 11-JUL-1317:50:53 11-JUL-1317:50:58
10 11-JUL-13 17:50:58 11-JUL-13 17:51:03
11 11-JUL-13 17:51:03 11-JUL-1318:34:11

4 rows selected

4. show configurationコマンドを使用して、スタンバイ・サイトに構成が正常に作成されたことを確認します。例4-10を参照してください。

例4-10 Data Guard Broker構成の検証

DGMGRL> show configuration;

Configuration - dg_config

Protection Mode: MaxPerformance
Databases:
psoa- Primary database
ssoa- Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

4.1.3.1.7 データベースのスイッチオーバーおよびスイッチバックのテスト

この項には次のトピックが含まれます:

- Oracle Data Guard Brokerを使用したスイッチオーバー操作の実行

- SQL*Plusを使用したスイッチオーバー操作の実行

Oracle Data Guard Brokerを使用したスイッチオーバー操作の実行

Oracle Data Guard Brokerを使用してスイッチオーバー操作を実行するには、次のタスクを完了します。

1. 4.1.3.1.5「Data Guard Broker構成の作成」の手順を使用して作成したOracle Data Guard Broker構成を検証します。
構成を検証するには、次のコマンドを実行します。

DGMGRL> show configuration;

Configuration - dg_config

Protection Mode: MaxPerformance
Databases:
psoa- Primary database
ssoa- Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

2. SWITCHOVERコマンドを実行して、プライマリおよびスタンバイ・データベースのロールをスワップします。例4-11では、Data Guard Brokerが、古いプライマリ・データベースの停止および再起動を、スイッチオーバー操作の一部として自動的に実行する方法を示します。

例4-11

DGMGRL> switchover to 'ssoa';
Performing switchover NOW, please wait...
New primary database "ssoa" is opening...
Operation requires shutdown of instance "psoa1" on database "psoa"
Shutting down instance "psoa1"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "psoa1" on database "psoa"
Starting instance "psoa1"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "ssoa"

3. スイッチオーバーの完了後、SHOW CONFIGURATIONコマンドを使用して、スイッチオーバー操作が正常終了したかどうかを検証します。

DGMGRL> show configuration;
Configuration - dg_config
Protection Mode: MaxPerformance
Databases:
ssoa- Primary database
psoa- Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

SQL*Plusを使用したスイッチオーバー操作の実行

次の操作を実行して、新しく作成したフィジカル・スタンバイ・データベースとプライマリOracle RACデータベース間でデータベースを正しくスイッチオーバーまたはスイッチバックします。

1. プライマリ・サイトのOracle RACデータベース(PSOA)の、1つを除くすべてのインスタンスを停止します。たとえば、本番サイトのSOADC1.DBHOST1で次のコマンドを実行します。

srvctl stop instance -d psoa -i soa2

2. 現在のプライマリ・データベースでフィジカル・スタンバイへのロール移行を開始します。たとえば、本番サイトのSOADC1.DBHOST1で次のコマンドを実行します。

SQL > ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

3. プライマリ・インスタンスを停止し、プライマリ・インスタンスをマウントします。たとえば、本番サイトのSOADC1.DBHOST1で次のコマンドを実行します。

SQL > shutdown immediate
SQL > startup mount

4. これで、両方のデータベースがフィジカル・スタンバイ・モードになりました。
インスタンスにログインして続行します。

5. 両方のデータベースがフィジカル・スタンバイ・モードであることを確認するには、両方のデータベースで次のSQL問合せを実行します。

SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PHYSICAL_STANDBY

6. フィジカル・スタンバイ・データベース・ロールをプライマリ・ロールに切り替えます。たとえば、スタンバイ・サイトのSOADC2.DBHOST1で次のコマンドを実行します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

7. これで、フィジカル・スタンバイ・データベースが新しいプライマリ・データベースになりました。

8. 新しいプライマリ・データベースを停止し、srvctlを使用して両方のRACノードを起動します。たとえば、新しいプライマリ・サイトSOADC2.DBHOST1で次のコマンドを実行します。

srvctl start database -d ssoa

9. 新しいフィジカル・スタンバイ・データベース(元のプライマリ)で、データベースの管理リカバリを開始します。たとえば、プライマリ・サイトのSOADC1.DBHOST1で次のコマンドを実行します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

10. 新しいフィジカル・スタンバイ・データベースへのREDOデータの送信を開始します。たとえば、新しいプライマリ・サイトSOADC2.DBHOST1で次のコマンドを実行します。

SQL> ALTER SYSTEM SWITCH LOGFILE;

11. V$ARCHIVED_LOGビューへの問合せを実行して、新しいフィジカル・スタンバイ・データベースでアーカイブ・ログ・ファイルが受信されているかどうかを確認します。

12. スイッチバック操作を実行します。スイッチバックは、スイッチオーバー操作の後にデータベースのロールを元の状態に戻す操作です。

注意:

Oracle Data Guard Brokerのスイッチオーバーおよびフェイルオーバー操作の詳細は、『Oracle Data Guard Broker』のスイッチオーバーおよびフェイルオーバー操作に関する項を参照してください。

4.2 本番サイトの作成

この項では、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジに本番サイトを作成する手順を示します。

内容は次のとおりです。

- Oracle SOA Suiteトポロジの本番サイトの作成

- Oracle Fusion Middleware SOAアクティブ-パッシブ・デプロイメントのデータ・ソースの構成

本番サイトの作成を開始する前に、次の事前準備を行ってください。

- 第3.1.1項で説明されているように、中間層ホストのホスト名別名を設定します。

- 本番サイトの共有ストレージに必要なボリュームを作成します。第4.1.1項を参照してください。

- 使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定します。
詳細は、『Oracle Data Guard概念および管理』、および関連事項として次のURLにある最大可用性アーキテクチャに関する情報を参照してください。

http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm

4.2.1 Oracle SOA Suiteトポロジの本番サイトの作成

本番サイトは、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。次のタスクを実行して、本番サイトをインストールして構成します。

タスク1   ボリュームおよびコンシステンシー・グループの作成

第4.1.1.1.1項「Oracle SOA Suiteのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

タスク2   物理ホスト名および別名ホスト名の設定

本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

タスク3   Oracle SOA Suiteのインストールおよび構成

『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従って、Oracle SOA Suiteをインストールおよび構成します。ただし、次の点が異なります。

1. 共有ストレージ・デバイス上に作成したボリュームにOracle SOA Suiteコンポーネントをインストールします。

2. 物理および仮想ホスト名の別名を使用して、本番およびスタンバイ・サイトを設定します。

3. JMSストアおよびトランザクション・ログ用に各サイトで別個のボリュームを作成します。

4. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーおよび管理対象サーバーのホスト名検証をオフにする詳細な手順は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

5. ホスト名の検証をオフにしない場合は、第4.3.2項に記載されている手順に従って、ノード・マネージャの通信を構成します。

6. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.2 Oracle Fusion Middleware SOAアクティブ-パッシブ・デプロイメントのデータ・ソースの構成

Oracle Fusion Middleware SOA Suiteで使用されるデータ・ソースを構成して、プライマリ・データベースのフェイルオーバーまたはスイッチオーバーがある場合に接続のフェイルオーバーを自動化します。次のデータ・ソースを正しく構成して、このフェイルオーバーを自動化する必要があります。

- EDNDataSource

- EDNLocalTxDataSource

- mds-owsm

- mds-soa

- OraSDPMDataSource

- SOADataSource

- SOALocalTxDataSource

また、フェイルオーバーを自動化するには、データベースを使用した永続ストアおよびサーバー移行に使用するリース・データ・ソースを構成する必要があります。GridLinkデータ・ソースを変更する必要があります。

- ONS構成を更新して、本番およびスタンバイ両方のサイトONSを含めます。
ONSアドレスのリスト内のアイテムは、カンマで区切る必要があります。

例:

prmy-scan:6200,stby-scan:6200

「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

接続が成功したときに表示される通知の一例を次に示します。

Connect test for prmy-scan:6200 succeeded.

- JDBC URLを更新して、両方のサイトに適切なサービスを含めます。
データベースがData Guardを使用するOracle Fusion Middleware SOAアクティブ/パッシブ構成のSOAデータ・ソースのサンプルJDBC URLを次に示します。

jdbc:oracle:thin:@
(DESCRIPTION_LIST =
(LOAD_BALANCE = off)
(FAILOVER = on)
(DESCRIPTION =
(CONNECT_TIMEOUT = 10)
(TRANSPORT_CONNECT_TIMEOUT = 3)
(RETRY_COUNT = 3)
(ADDRESS_LIST =
(LOAD_BALANCE = on)
(ADDRESS =
(PROTOCOL = TCP)(HOST = prmy-scan)(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE_NAME =soaedg.example.com)
)
)
(DESCRIPTION =
(CONNECT_TIMEOUT =10)
(TRANSPORT_CONNECT_TIMEOUT = 3)
(RETRY_COUNT = 3)
(ADDRESS_LIST =
(LOAD_BALANCE = on)
(ADDRESS =
(PROTOCOL =TCP)(HOST = stby-scan)(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE_NAME = soaedg.example.com))

)

)

「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。

接続が成功したときに表示される通知の一例を次に示します。

Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))) succeeded.

4.3 スタンバイ・サイトの作成

この項では、スタンバイ・サイトを作成する手順を説明します。Oracle SOAエンタープライズ・デプロイメント・トポロジを例として使用します。

次のトピックが含まれます:

- スタンバイ・サイトの作成

- スタンバイ・サイトの自己署名証明書およびキーストアの更新

- スタンバイ・サイトの設定の検証

4.3.1 スタンバイ・サイトの作成

スタンバイ・サイトの作成を開始する前に、次の事前準備を行ってください。

- スタンバイ・サイトで、第3.1.1項の手順に従って、ホスト名別名および物理ホスト名を正しく設定します。
スタンバイ・サイトの各ホストに、本番サイトのピア・ホストの物理ホスト名と同じホスト名別名が設定されていることを確認してください。

- スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。

- スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、第3.2.3項を参照してください。

4.3.1.1 中間層のホストの設定

スタンバイ・サイトの中間層ホストでは、Oracle Fusion MiddlewareやOracle WebLogic Serverソフトウェアのインストールや構成を行う必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。

スタンバイ・サイトの中間層ホストを設定する手順は、次のとおりです。

1. 本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、ストレージ・デバイス間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。

2. 本番サイトの共有ストレージをスタンバイ・サイトの共有ストレージと同期します。これによって、本番サイトからスタンバイ・サイトに初期のベースライン・スナップショットが転送されます。

3. スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。

4. ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。

4.3.2 スタンバイ・サイトの自己署名証明書およびキーストアの更新

管理サーバーのホスト名検証を有効にする場合は、スタンバイ・サイトの証明書で適切な信頼ストアとキー・ストアも更新する必要があります。証明書は、スタンバイ・サイトのノード専用に作成する必要があります。

ノードの証明書の作成の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の中間層とハードウェア・ロード・バランサ間のSSL通信の有効化に関する項を参照してください。

このセクションでは、次のトピックについて説明します。

- 自己署名証明書の生成

- IDキーストアの作成

- 信頼キーストアの作成

これらの項の例では、図4-2に示されているOracle SOA Suiteエンタープライズ・トポロジに対してタスクを実行する方法を紹介します。

注意:

- 図4-2に示されているOracle SOA Suiteエンタープライズ・トポロジを障害時リカバリ・トポロジの本番サイトとして設定する場合は、図4-2に示されているホスト名のかわりに、表3-1に示されている物理ホスト名を本番サイトのホストに使用する必要があります。

- この項の手順は、Oracle WebLogic Serverがインストールされているアプリケーション層ホストで実行する必要があります。

4.3.2.1 自己署名証明書の生成

次の手順に従って、自己署名証明書を生成します。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。
Bourneシェルで次のコマンドを実行します。

. setWLSEnv.sh

CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

2. 証明書用のユーザー定義ディレクトリを作成します。

mkdir home/user_projects/domains/SOADomain/certs

3. ディレクトリをユーザー定義ディレクトリに変更します。

cd home/user_projects/domains/SOADomain/certs

4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、ノード内のサーバーによって使用される物理ホスト名と仮想ホスト名の両方に対応する証明書を作成します。

java utils.CertGen key_passphrase cert_file_name key_file_name [export|domestic] [hostname]

例:

java utils.CertGen password soadc1host1_cert soahost1_key domestic soahost1
java utils.CertGen password soadc1host2_cert soahost2_key domestic soahost2

4.3.2.2 IDキーストアの作成

次の手順に従って、utils.ImportPrivateKeyユーティリティを使用してIDキーストアを作成します。

1. 次の構文を使用して、証明書および秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

java utils.ImportPrivateKey keystore_file keystore_password certificate_alias_to_use private_key_passphrase certificate_file private_key_file keystore_type

注意:

keystore_typeのデフォルト値はjksです。

例:

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity1 password
ASERVER_HOME/certs/SOAHOST1.example.com_cert.pem
ASERVER_HOME/certs/SOAHOST1.example.com_key.pem

2. プライマリおよびスタンバイ・サイトのすべてのホストについて手順1を繰り返します。

4.3.2.3 信頼キーストアの作成

次の手順に従って、信頼キーストアを作成します。

1. 新しい信頼キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。
標準のJava信頼キーストアを直接変更することはお薦めしません。

WL_HOME/server/libディレクトリにある標準のJavaキーストアのCA証明書を、証明書のあるディレクトリにコピーします。

例:

cp $WL_HOME/server/lib/cacerts
$home/user_projects/domains/SOADomain/certs/appTrustKeyStore.jks

2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。
デフォルト・パスワードを変更することをお薦めします。それには、keytoolユーティリティを使用します。

構文は次のとおりです。

keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass
OriginalPassword

たとえば、次のコマンドを入力します。

keytool -storepasswd -new password -keystore home//user_projects/domains/SOADomain/certs/appTrustKeyStore.jks -storepass
changeit

3. このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用され、WL_HOME/server/libディレクトリに存在しています。このCA証明書は、keytoolユーティリティを使用してappTrustKeyStoreにインポートする必要があります。
構文は次のとおりです。

keytool -import -v -noprompt -trustcacerts -alias AliasName -file
CA_file_location -keystore key_store_location -storepass key_store_password

たとえば、次のコマンドを入力します。

keytool -import -v -noprompt -trustcacerts -alias clientCACert -file
$WL_HOME/server/lib/CertGenCA.der -keystore appTrust.jks -storepass password

4.3.3 スタンバイ・サイトの設定の検証

次の手順を実行することで、スタンバイ・サイトを検証します。

1. 本番サイトで実行中のプロセスを停止します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

2. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

3. スイッチバック操作を実行します。スイッチバックは、スイッチオーバー操作の後にデータベースのロールを元の状態に戻す操作です。

4. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

5. ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。

4.4 非対称スタンバイ・サイトの作成

この項の手順では、Oracle Fusion Middleware障害時リカバリの非対称トポロジを設定する方法を説明します。

非対称トポロジは、本番サイトとスタンバイ・サイトの層で異なる障害時リカバリ構成です。Oracle Fusion Middleware障害時リカバリのほとんどの非対称トポロジでは、スタンバイ・サイトのリソースの数が本番サイトより少なくなっています。

この項を読む前に必ず、このマニュアルで前述した対称トポロジの設定に関する概念と情報に目を通し、理解しておいてください。対称トポロジの設定に関する概念の多くは、非対称トポロジを設定する際にも有効です。

次の項では、非対称トポロジを作成する基本手順について説明します。

- 非対称スタンバイ・サイトの作成

- 非対称スタンバイ・サイトの設定の検証

4.4.1 非対称スタンバイ・サイトの作成

この項では、Oracle Fusion Middleware障害時リカバリのあらゆるタイプの非対称トポロジを作成する際の大まかな手順を説明します。本番サイトは、図4-2に示されているOracle SOA Suiteのエンタープライズ・デプロイメントです。スタンバイ・サイトは本番サイトと異なるものになります。

非対称トポロジを作成する手順は次のとおりです。

1. 本番サイトとスタンバイ・サイトを設計します。スタンバイ・サイトが本番ロールを引き継いだときに許容されるパフォーマンスを確保できるように、スタンバイ・サイトで必要となるリソースを特定してください。

注意:

スタンバイ・サイト・インスタンスのポートでは、本番サイトのピア・インスタンスと同じポート番号を使用する必要があります。そのため、スタンバイ・サイトで必要となるすべてのポート番号が使用可能である(スタンバイ・サイトで使用中でない)ことを確認してください。

2. 次の操作を実行して、Oracle Fusion Middleware障害時リカバリの本番サイトを作成します。

1. 本番サイトの共有ストレージ・システムで、本番サイト用にインストールするOracle Fusion Middlewareインスタンスのボリュームを作成します。詳細は、第4.1.1項を参照してください。

2. 本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、第3.2.3項を参照してください。

ボリューム設計の詳細は、第4.1.1.1.1項を参照してください。

3. 本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、第3.2.3項を参照してください。

Oracle中央インベントリ・ディレクトリの詳細は、第3.2.2項を参照してください。

4. 本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle HTTP Serverインスタンスに対して、静的HTMLページ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します(該当する場合)。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、第3.2.3項を参照してください。

5. 本番サイトの共有ストレージ・システムのボリュームに、本番サイト用のOracle Fusion Middlewareインスタンスをインストールします。詳細は、第4.2.1項を参照してください。

3. スタンバイ・サイトの共有ストレージ・システムでも、本番サイトの共有ストレージ・システムでOracle Fusion Middlewareインスタンスに対して作成したのと同じボリュームを、同じファイル権限とディレクトリ権限で作成します。この手順は重要です。これにより、後からストレージ・レプリケーションを使用してスタンバイ・サイト用にOracle Fusion Middlewareのピア・インスタンスのインストールを作成できるようになり、Oracle Universal Installerを使用したインストールが不要になるからです。

注意:

ストレージ・レプリケーションを構成する際には、本番サイトの共有ストレージ・システムで設定したすべてのボリュームがスタンバイ・サイトの共有ストレージ・システム上の同じボリュームにレプリケートされるようにしてください。

本番サイトの一部のインスタンスやホストがスタンバイ・サイトに存在しない場合でも、本番サイトのOracle Fusion Middlewareインスタンスに対して設定したすべてのボリュームでストレージ・レプリケーションを構成する必要があります。

4. 共有ストレージ・ベンダーが規定しているその他の必要な構成を実行して、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にします。本番サイトの共有ストレージ・システムのボリュームをスタンバイ・サイトの共有ストレージ・システムに非同期でコピーするように、ストレージ・レプリケーションを構成してください。

5. 本番サイトの共有ストレージ・システムの初期のベースライン・スナップショット・コピーを作成して、本番サイトとスタンバイ・サイトの共有ストレージ・システム間のレプリケーションを設定します。初期のベースライン・スナップショット・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリュームのすべてのディレクトリの内容が本番サイトのボリュームのディレクトリと同じであることを検証します。初期のスナップショットを作成する方法、および本番サイトとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にする方法の詳細は、共有ストレージ・ベンダーのドキュメントを参照してください。

6. ベースライン・スナップショットを作成したら、スタンバイ・サイトのホストでOracle Fusion Middlewareインスタンスについて次の手順を実行します。

1. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。

2. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、第3.2.3項を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。

3. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。

4. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、第3.2.3項を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。

5. スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。

6. スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。

前述の手順が完了すると、本番サイトのOracle Fusion Middlewareインスタンスのインストールがスタンバイ・サイトにレプリケートされます。スタンバイ・サイトは、次のすべての項目に該当する状態となります。

- Oracle Fusion Middlewareインスタンスは、本番サイトと同じボリューム上の同じOracleホーム・ディレクトリにインストールされています。また、ホストでは、Oracleホーム・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項を参照してください。

- Oracle中央インベントリ・ディレクトリは、本番サイトと同じボリューム上の同じディレクトリにあります。また、ホストでは、Oracle中央インベントリ・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項を参照してください。

- Oracle HTTP Serverの静的HTMLページ・ディレクトリは、本番サイトと同じボリューム上の同じディレクトリにあります。また、ホストでは、Oracle HTTP Serverの静的HTMLページ・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項を参照してください。

- スタンバイ・サイトのOracle Fusion Middlewareインスタンスには、本番サイトの同じインスタンスに使用されているものと同じポートが使用されています。

4.4.1.1 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイトの作成

この項では、ホストおよびOracle Fusion Middlewareインスタンスの数が本番サイトより少ない非対称スタンバイ・サイトを作成する方法を説明します。

このOracle Fusion Middleware障害時リカバリ・トポロジの本番サイトは、図4-2に示されているOracle SOA Suiteのエンタープライズ・デプロイメントです。この本番サイトとその共有ストレージ・システムのボリュームを設定する方法、および必要なマウント・ポイントを作成する方法は、第4.1項から第4.1.1項に記載されています。

図4-4に、図4-2に示されている本番サイトの非対称スタンバイ・サイトを示します。

図4-4 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイト

図4-4に示されているOracle SOA Suiteの非対称スタンバイ・サイトのホストおよびインスタンスの数は、図4-2に示されているOracle SOA Suiteの本番サイトより少なくなっています。

図4-2の本番サイトには、ホストWEBHOST2およびSOAHOST2とこれらのホスト上のインスタンスが存在しますが、図4-4の非対称スタンバイ・サイトには、これらのホストとそのインスタンスが存在しません。そのため、スタンバイ・サイトのホストおよびインスタンスの数は、本番サイトより少なくなっています。

この非対称スタンバイ・サイトには、本番ロールを引き継いだときに適切なパフォーマンスを提供できるように、十分なリソースを確保することが重要です。

第4.4.1項に記載されている手順に従って、この非対称スタンバイ・サイトを設定すれば、スタンバイ・サイトは本番ロールを引き継ぐように適切に構成されます。

非対称スタンバイ・サイトを正しく設定するには、本番サイトの共有ストレージで作成したものと同じボリュームおよびコンシステンシー・グループをスタンバイ・サイトの共有ストレージで作成します。たとえば、Oracle SOA Suiteデプロイメントについて、表4-1のボリューム設計に関する推奨事項と表4-2のコンシステンシー・グループに関する推奨事項を使用して、本番サイトの共有ストレージを設定したとします。その場合、本番サイトの共有ストレージに使用したものと同じボリューム設計に関する推奨事項とコンシステンシー・グループに関する推奨事項を使用して、非対称スタンバイ・サイトの共有ストレージを設定します。

非対称スタンバイ・サイトでは、本番サイトに存在する一部のホストがスタンバイ・サイトに存在しません。たとえば、図4-4に示されているOracle SOA Suiteの非対称スタンバイ・サイトでは、WEBHOST2とSOAHOST2が存在しないため、スタンバイ・サイトの共有ストレージ・ボリュームに対してこれらのホスト上にマウント・ポイントを作成することはできず、作成する必要はありません。

4.4.2 非対称スタンバイ・サイトの設定の検証

次の手順を実行することで、スタンバイ・サイトを検証します。

1. 本番サイトで実行中のプロセスを停止します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

2. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

3. Oracle Data Guardを使用して、データベースをスイッチオーバーします。

4. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これらには、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

5. ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。

4.5 サイトの操作および管理の実行

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジで実行する操作および管理について説明します。

次のセクションがあります。

- サイトの同期

- スイッチオーバーの実行

- スイッチバックの実行

- フェイルオーバーの実行

- スタンバイ・サイトの定期テストの実行

- テストでのpeer-to-peerファイル・コピーの使用

4.5.1 サイトの同期

スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。

本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行する必要があります。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。

Oracle Fusion Middleware障害時リカバリ・トポロジでのデータベースの同期は、Oracle Data Guardによって管理されます。

4.5.2 スイッチオーバーの実行

本番サイトを停止し(保守を行う場合など)、現在のスタンバイ・サイトを新しい本番サイトにする場合は、スタンバイ・サイトが本番ロールを引き継ぐように、スイッチオーバー操作を実行する必要があります。

スイッチオーバー操作を実行する手順は、次のとおりです。

1. 本番サイトで実行中のプロセスを停止します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

2. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

3. 中間層のアーティファクトがある共有ストレージ・ボリュームをアンマウントし、現在の本番サイトで、新しい本番サイトとなる現在のスタンバイ・サイト上の対応するボリュームをマウントします。

4. Oracle Data Guardを使用して、データベースをスイッチオーバーします。

5. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

6. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがスタンバイ・サイトにルーティングされるようにします。

7. ブラウザ・クライアントを使用してスイッチオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。
これで、元のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトが新しいスタンバイ・サイトになりました。

8. 2つのサイト間のレプリケーションを再確立します。ただし、スナップショット・コピーが逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。

前述の手順が完了すると、元のスタンバイ・サイトが新しい本番サイトになります。これで、元の本番サイトで保守を実行できるようになります。予定していたタスクを元の本番サイトで実行した後、将来、そのサイトを本番サイトまたはスタンバイ・サイトとして使用できます。

元の本番サイトを新しい本番サイトとして使用するには、第4.5.3項に記載されているスイッチバック手順を実行してください。

4.5.3 スイッチバックの実行

スイッチオーバー操作を実行した後、スイッチバック操作を実行して、現在の本番サイトと現在のスタンバイ・サイトをスイッチオーバー操作前のロールに戻すことができます。

スイッチバック操作を実行する手順は、次のとおりです。

1. 現在の本番サイトで実行中のプロセスを停止します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

2. 現在の本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

3. 中間層のアーティファクトがある共有ストレージ・ボリュームをアンマウントし、現在の本番サイトで、新しい本番サイトとなる現在のスタンバイ・サイト上の対応するボリュームをマウントします。

4. Oracle Data Guardを使用して、データベースをスイッチバックします。

5. 新しい本番サイトのホストで、すべてのプロセスを手動で開始します。これらには、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

6. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストが新しい本番サイトにルーティングされるようにします。

7. ブラウザ・クライアントを使用してスイッチバック後のテストを実行し、リクエストが解決されて新しい本番サイトにリダイレクトされていることを確認します。
これで、元のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトが新しいスタンバイ・サイトになりました。

8. 2つのサイト間のレプリケーションを再確立します。ただし、スナップショット・コピーが逆方向に(新しい本番サイトから新しいスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。

4.5.4 フェイルオーバーの実行

本番サイトが予期せず使用できなくなった場合、スタンバイ・サイトが本番ロールを引き継ぐように、フェイルオーバー操作を実行する必要があります。

フェイルオーバー操作を実行する手順は、次のとおりです。

1. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

2. 新しい本番サイトとなる現在のスタンバイ・サイトで、中間層のアーティファクトがある共有ストレージ・ボリュームをマウントします。

3. スタンバイ・サイトから、Oracle Data Guardを使用して、データベースをフェイルオーバーします。

4. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これらには、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

5. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがスタンバイ・サイトにルーティングされるようにします。

6. ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されて本番サイトにリダイレクトされていることを確認します。
これで、スタンバイ・サイトが新しい本番サイトになりました。元の本番サイトが使用できなくなった原因を調べることができます。

7. 元の本番サイトを現在のスタンバイ・サイトとして使用するには、2つのサイト間のレプリケーションを再確立する必要があります。ただし、スナップショット・コピーが逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。

元の本番サイトを新しい本番サイトとして使用するには、第4.5.3項に記載されているスイッチバック手順を実行してください。

4.5.5 スタンバイ・サイトの定期テストの実行

このマニュアルでは、Oracle Fusion Middlewareの本番サイトとスタンバイ・サイトの障害時リカバリを設定する方法を説明します。Oracle Fusion Middleware障害時リカバリの通常の構成は、次のようになっています。

- ストレージ・レプリケーションを使用して、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージにOracle Fusion Middlewareの中間層のファイル・システムおよびデータをコピーします。通常の操作時には、本番サイトはアクティブで、スタンバイ・サイトはパッシブです。本番サイトがアクティブな場合、スタンバイ・サイトはパッシブで、スタンバイ・サイトの共有ストレージは読取り専用モードです。スタンバイ・サイトの共有ストレージに対して行われる書込み操作は、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージへのストレージ・レプリケーション操作のみです。

- Oracle Data Guardを使用して、本番サイトのOracle Databaseのデータベース・データをスタンバイ・サイトのスタンバイ・データベースにコピーします。デフォルトでは、本番サイトのデータベースはアクティブで、スタンバイ・サイトのスタンバイ・データベースはパッシブです。スタンバイ・サイトがスタンバイ・ロールの間(パッシブである間)、スタンバイ・サイトのスタンバイ・データベースは管理リカバリ・モードです。本番サイトがアクティブな場合、スタンバイ・データベースに対して行われる書込み操作は、Oracle Data Guardによって実行されるデータベースの同期操作のみです。

- 本番サイトが使用できなくなったときには、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。現在の本番サイトが予期せず使用できなくなった場合は、フェイルオーバー操作(第4.5.4項を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。また、現在の本番サイトを意図的に停止する場合は(予定した保守の場合など)、スイッチオーバー操作(第4.5.2項を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。

通常の方法でスタンバイ・サイトをテストする場合は、現在の本番サイトを停止し、スイッチオーバー操作を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。ただし、企業では、現在の本番サイトを停止してスイッチオーバー操作を実行することなく、障害時リカバリのスタンバイ・サイトの定期テストを実行することもできます。

スタンバイ・サイトをテストする代替方法では、スタンバイ・サイトの読取り専用共有ストレージのクローンを作成し、クローニングされたスタンバイ・サイト共有ストレージをテストで使用します。この代替テスト方法を使用する手順は、次のとおりです。

1. 共有ストレージ・ベンダーが提供しているクローニング・テクノロジを使用して、スタンバイ・サイトの共有ストレージでスタンバイ・サイトの読取り専用ボリュームのクローンを作成します。クローニングされたスタンバイ・サイトのボリュームが書込み可能であることを確認します。スタンバイ・サイトを1回のみテストする場合、これは1回かぎりのクローン操作にできます。ただし、スタンバイ・サイトを定期的にテストする場合は、スタンバイ・サイトの読取り専用ボリュームの、スタンバイ・サイトの読取り/書込みクローン・ボリュームへの定期的クローニングを設定できます。

2. スタンバイ・サイトのデータベースのバックアップを実行し、本番サイトとスタンバイ・サイトのデータベース間のOracle Data Guardレプリケーションを変更します。

- 10.2以降のデータベースについては、次の手順に従って、スナップショット・スタンバイ・データベースを確立します。

1. フラッシュ・リカバリ領域がない場合は、設定します。

2. REDO Applyを取り消します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE CANCEL;

3. 保証付きリストア・ポイントを作成します。

SQL> CREATE RESTORE POINT standbytest
GUARANTEE FLASHBACK DATABASE;

4. プライマリ(本番)サイトで現在のログをアーカイブします。

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

5. アクティブ化するスタンバイ・サイト接続先を遅延させます。

SQL> ALTER SYSTEM SET
LOG_ARCHIVE_DEST_STATE_2=DEFER;

6. ターゲット・スタンバイ・データベースをアクティブ化します。

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

7. データベースが読取り専用で開いている場合、Forceオプションを指定してデータベースをマウントします。

SQL> STARTUP MOUNT FORCE;

8. 保護モードを下げて、データベースを開きます。

SQL> ALTER DATABASE SET STANDBY DATABASE TO
MAXIMIZE PERFORMANCE;
SQL> ALTER DATABASE OPEN;

3. Oracle Data Guardのデータベース・リカバリ手順に従って、スタンバイ・データベースをオンラインにします。

4. スタンバイ・サイトのコンピュータで、次の手順に従って、スタンバイ・サイトのクローニングされた読取り/書込み共有ストレージ・ボリュームを指すようにmountコマンドを変更します。

1. 読取り専用の共有ストレージ・ボリュームをアンマウントします。

2. クローニングされた読取り/書込みボリュームを同じマウント・ポイントでマウントします。

5. スタンバイ・サイトをテストする前に、ホスト名が本番サイトのコンピュータではなくスタンバイ・サイトのコンピュータを指すように、テストの実行に使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、スタンバイ・サイトのロード・バランサの仮想IPを指すように/etc/hostsファイルを変更します。

6. スタンバイ・サイトのテストを実行します。

スタンバイ・サイトのテストが完了したら、次の手順に従って、元の本番サイトを本番サイトとして再度使用します。

1. スタンバイ・サイトの読取り専用共有ストレージ上のボリュームを指すようにスタンバイ・サイト・コンピュータのmountコマンドを変更します。つまり、mountコマンドを、テストを実行する前の状態にリセットします。

1. クローニングされた共有ストレージの読取り/書込みボリュームをアンマウントします。

2. 読取り専用の共有ストレージ・ボリュームをマウントします。

これで、mountコマンドがスタンバイ・サイトのテストを実行する前の状態にリセットされました。

2. 本番サイトのデータベースとスタンバイ・サイトのスタンバイ・データベース間のレプリケーションを実行するように、Oracle Data Guardを構成します。この構成を実行すると、スタンバイ・データベースは再度、管理リカバリ・モードに設定されます。

- Oracle Database 10.2以降については、次の手順に従います。

1. アクティブ化したデータベースをフィジカル・スタンバイ・データベースに戻します。

SQL> STARTUP MOUNT FORCE;
SQL> FLASHBACK DATABASE TO POINT standbytest;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> STARTUP MOUNT FORCE;

2. 管理リカバリを再開します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE USING CURRENT LOGFILE DISCONNECT;

3. スタンバイ接続先を再度有効にし、ログを切り替えます。

SQL> ALTER SYSTEM SET
LOG ARCHIVE DEST STATE 2=ENABLE;

- Oracle Database 12cについては、『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースの管理に関する項に記載されている手順に従って、レプリケーションを再度設定します。

3. 元の本番サイトを再度使用する前に、ホスト名がスタンバイ・サイトのコンピュータではなく本番サイトのコンピュータを指すように、本番サイトへのアクセスに使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、本番サイトのロード・バランサの仮想IPを指すように/etc/hostsファイルを変更します。

4.5.6 テストでのpeer-to-peerファイル・コピーの使用

Oracle Fusion Middleware中間層コンポーネントの障害保護および障害時リカバリにストレージ・レプリケーション・テクノロジを使用するかわりに、テスト環境でpeer-to-peerファイル・コピー・メカニズムを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトのホストからスタンバイ・サイトのピア・ホストに中間層のファイル・システム・データをレプリケートできます。peer-to-peerファイル・コピー・メカニズムの例として、rsync (UNIXシステムのオープン・ソース・ユーティリティ)があります。

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジでストレージ・レプリケーションのかわりにrsyncを使用する方法を説明します。対称トポロジのコンテキストにおけるrsyncについて説明します。この項でrsyncについて記載されている情報は、他のpeer-to-peerファイル・コピー・メカニズムにも適用されます。

この項の情報を読む前に、このマニュアルの他の部分を読み、Oracle Fusion Middleware Disaster Recoveryトポロジでのストレージ・レプリケーションおよびOracle Data Guardの使用方法に精通してください。Oracle Fusion Middlewareコンポーネントの障害保護および障害時リカバリでのストレージ・レプリケーションとrsyncの使用には、多くの類似点があります。

注意:

ストレージ・レプリケーション・テクノロジのかわりにrsyncを使用して、本番サイトからスタンバイ・サイトに中間層のファイル・システム・データをレプリケートできます。ただし、rsyncを使用した場合、次のようなストレージ・レプリケーションの便利な機能を使用することはできません。

- ストレージ・レプリケーションでは、本番サイトで前のスナップショットが作成された時点まで変更をロールバックできます。
rsyncでは、レプリケートされた本番サイトのデータによってスタンバイ・サイトのデータが上書きされるため、レプリケーションをロールバックすることはできません。

- ストレージ・レプリケーションでは、共有ストレージ・システムで各ホスト・クラスタについて設定したボリュームによって、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間でそのホスト・クラスタのデータの整合性が保証されます。
rsyncでは、データの整合性は保証されません。

ストレージ・レプリケーションと比較すると、このような短所があるため、実際の本番環境では、障害時リカバリにrsyncを使用することはできません。

4.5.6.1 Oracle Fusion Middleware障害時リカバリ・トポロジでのrsyncとOracle Data Guardの使用

次の項では、rsyncとOracle Data Guardを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの障害保護および障害時リカバリを実現するときに適用する基本原則について説明します。

- Oracle Fusion Middleware中間層コンポーネントでのrsyncの使用

- フェイルオーバー操作およびスイッチオーバー操作の実行

注意:

Oracleデータベース用のOracle Data Guardの設定方法は、第3.3項を参照してください。

4.5.6.1.1 Oracle Fusion Middleware中間層コンポーネントでのrsyncの使用

rsyncを使用してOracle Fusion Middleware中間層コンポーネントの障害保護および障害時リカバリを実現する手順は、次のとおりです。

1. 本番サイトのホストからスタンバイ・サイトのピア・ホストへのファイルのレプリケーションが有効になるように、rsyncを設定します。rsyncをインストールおよび設定する手順、および構文と使用方法の詳細は、rsyncのマニュアル・ページを参照してください。rsyncに関する情報は、http://rsync.samba.orgで入手できます。

2. 1つ以上のOracle Fusion Middlewareコンポーネントがインストールされている本番サイトの各ホストについて、次のディレクトリおよびファイルを、スタンバイ・サイトのピア・ホスト上の同じディレクトリおよびファイルにコピーするように、rsyncを設定します。

- Oracleホーム・ディレクトリおよびサブディレクトリと、それらのディレクトリ内のすべてのファイル

- ホストのOracle中央インベントリ・ディレクトリおよびファイル(Oracle Fusion Middlewareインストール用のOracle Universal Installerエントリを含む)

- ホスト上のOracle HTTP Serverインストール用のOracle Fusion Middlewareの静的HTMLページ・ディレクトリ(該当する場合)

- Oracle Formsによってホスト上に作成された.fmbおよび.fmxデプロイメント・アーティファクト・ファイルと、Oracle Reportsによってホスト上に作成された.rdfデプロイメント・アーティファクト・ファイル(該当する場合)

注意:

rsyncをルートとして実行してください。ユーザーにパスワードの入力を求めるプロンプトを表示せずにrsyncが機能するようにするには、SSHによってパスワードの入力を求めるプロンプトが表示されないように、本番サイトのホストとスタンバイ・サイトのホスト間にSSHキーを設定します。

3. 前の手順でrsyncを設定した本番サイトのホストについて、cronジョブなどのスケジュール済ジョブを設定します。これらのスケジュール済ジョブを使用すると、rsyncによって、本番サイトのホストからスタンバイ・サイトのホストへのこれらのファイルのレプリケーションを定期的に自動実行できます。Oracle Fusion Middlewareの構成がそれほど頻繁に変更されない本番サイトについては、1日1回の間隔をお薦めします。

4. 本番サイトのホストでOracle Fusion Middlewareの中間層の構成が変更された場合(新しいアプリケーションがデプロイされた場合など)は必ず、rsyncを使用して、スタンバイ・サイトのピア・ホストとそのホストの手動同期を実行する必要があります。

5. 本番サイトのホスト上にあるOracle Fusion Middlewareの中間層インスタンスを、rsyncを使用して手動でスタンバイ・サイトのピア・ホストと同期させた場合は、関連する本番サイトのOracle Fusion Middlewareインスタンスのデータベース・リポジトリも、Oracle Data Guardを使用して手動で強制的にスタンバイ・サイトと同期させる必要があります。Oracle Data Guardを使用してOracle Databaseを手動で強制的に同期させる方法の詳細は、第3.3.2項を参照してください。

4.5.6.1.2 フェイルオーバー操作およびスイッチオーバー操作の実行

rsyncを使用している場合、本番サイトからスタンバイ・サイトへのフェイルオーバーまたはスイッチオーバーを実行する手順は次のとおりです。

1. 本番サイトで実行中のプロセスを停止します(該当する場合)。

2. 本番サイトのホストとスタンバイ・サイトのピア・ホスト間のrsyncジョブを停止します。

3. Oracle Data Guardを使用して、本番サイトのデータベースをスタンバイ・サイトにフェイルオーバーします。

4. スタンバイ・サイトで、Oracle Fusion Middlewareサーバー・インスタンスのプロセスを手動で開始します。

5. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストをスタンバイ・サイトにルーティングします。

6. ブラウザ・クライアントを使用してフェイルオーバー後またはスイッチオーバー後のテストを実行し、スタンバイ・サイト(現在の本番サイト)でリクエストが解決されていることを確認します。
これで、スタンバイ・サイトが新しい本番サイトになり、本番サイトが新しいスタンバイ・サイトになりました。

7. 2つのサイト間のrsyncレプリケーションを再確立します。ただし、逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)レプリケートされるようにレプリケーションを構成してください。

元の本番サイトを新しい本番サイトとして使用するには、前述の手順をもう一度実行します。ただし、元の方向で(元の本番サイトから元のスタンバイ・サイトへ)レプリケートされるようにrsyncレプリケーションを構成してください。

4.6 障害時リカバリのためのOracle Site Guardの使用

Oracle Site Guardは、主に、2つの障害回復サイト間のスイッチオーバーおよびフェイルオーバーを編成します。これには、次の機能があります。

- 企業データの高可用性、データ保護および障害時リカバリを保証します。

- スイッチオーバーやフェイルオーバーなどのOracle Site Guard操作を実行します。プライマリ・サイトが計画停止または計画外停止のため使用不可となった場合、スイッチオーバーまたはフェイルオーバー・プロセスはOracle Site Guardを使用して開始する必要があります。

Oracle Site Guardの使用方法の詳細は、Oracle Site Guard管理者ガイドを参照してください。

4.7 Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用

この項では、12c Oracle Fusion Middlewareパッチ・セットを適用して、Oracle Fusion Middleware障害時リカバリ・サイトに含まれるOracleホームをアップグレードする方法を説明します。

この項の一覧では、Oracle Fusion Middleware障害時リカバリの本番サイトでパッチ・セットを適用して、Oracle Fusion Middleware 12cホームをアップグレードする手順について説明します。

次の手順は、パッチを適用するOracle Fusion MiddlewareインスタンスのOracle中央インベントリが本番サイトの共有ストレージに配置されていて、パッチが適用されたインスタンスのOracle中央インベントリをスタンバイ・サイトにレプリケートできるようになっていることを前提としています。

Oracle Fusion Middleware 12cのパッチ・バージョンをアップグレードする手順は、次のとおりです。

1. 開始時の状態が保持されるように、本番サイトのバックアップを実行します。

2. パッチ・セットを適用して、本番サイトのインスタンスをアップグレードします。

3. パッチ・セットを適用したら、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージを手動で強制的に同期させます。これによって、本番サイトのパッチが適用されたインスタンスとOracle中央インベントリがスタンバイ・サイトの共有ストレージにレプリケートされます。

4. パッチ・セットを適用したら、Oracle Data Guardを使用して、本番サイトとスタンバイ・サイトのOracle Databaseを手動で強制的に同期させます。Oracle Fusion Middlewareの一部のパッチ・セットでは、リポジトリが更新される場合があるため、この手順を必ず実行して、本番サイトのデータベースの変更をスタンバイ・サイトのデータベースに同期させます。

5. これでアップグレードは完了です。障害時リカバリ・トポロジで処理を再開できます。

注意:

パッチは、Oracle Fusion Middleware 12c障害時リカバリ・トポロジの本番サイトでのみ適用する必要があります。Oracle Fusion MiddlewareインスタンスまたはOracle中央インベントリのパッチの場合、本番サイトの共有ストレージがスタンバイ・サイトの共有ストレージにレプリケートされるときに、パッチがコピーされます。本番サイトでパッチをインストールした場合は、同期操作を実行する必要があります。

同様に、本番サイトのデータベースのパッチをインストールした場合、同期を実行すると、Oracle Data Guardによってスタンバイ・サイトのスタンバイ・データベースにパッチがコピーされます。

5 障害時リカバリのトラブルシューティング

この章では、障害時リカバリ・トポロジにおいてOracle Fusion Middlewareをデプロイおよび管理するときに一般的に遭遇する可能性がある状況、およびそうした状況に対処するための手順について説明します。この章の内容は次のとおりです。

- 第5.1項「Oracle Fusion Middleware障害時リカバリ・トポロジのトラブルシューティング」

- 第5.2項「追加情報」

5.1 Oracle Fusion Middleware障害時リカバリ・トポロジのトラブルシューティング

この項では、Oracle Fusion Middleware構成時に一般的に遭遇する可能性がある状況と構成の実行手順について説明します。内容は次のとおりです。

- 本番サイトおよびスタンバイ・サイトのホスト名解決の確認

- 障害時リカバリ・トポロジでのコンポーネントの問題の解決

- 共有ストレージにデプロイされたコンポーネントの問題の解決

5.1.1 本番サイトおよびスタンバイ・サイトのホスト名解決の確認

障害時リカバリ・トポロジで発生する問題の多くは、ホスト名解決が本番サイトおよびスタンバイ・サイトに対して正しく設定されていないことが原因です。

第3.1.1.1.5項のホスト名検証手順を実行して、ホスト名解決が正しく設定されていることを確認してください。

5.1.2 障害時リカバリ・トポロジでのコンポーネントの問題の解決

障害時リカバリ・トポロジのコンポーネントで発生する可能性のある問題の中には、障害時リカバリの問題ではなく、コンポーネント自体に関するものがあります。

障害時リカバリ・トポロジで使用されているOracle Fusion Middlewareコンポーネントで問題が発生した場合、そのコンポーネントの『Oracle Fusion Middleware高可用性ガイド』のトラブルシューティングに関する項を参照して、発生した問題について記述されているかどうか確認します。

同様に、ご使用の障害時リカバリ・トポロジが、次のマニュアルで説明されている1つ以上のエンタープライズ・デプロイメントに基づいており、問題が発生した場合には、そのマニュアルのトラブルシューティングに関する項を参照して、発生した問題について記述されているかどうか確認します。

- Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド

5.1.3 共有ストレージにデプロイされたコンポーネントの問題の解決

障害時リカバリ・トポロジのコンポーネントで発生する可能性のある問題の中には、障害時リカバリの問題ではなく、共有ストレージへのコンポーネントのデプロイに関するものがあります。

第5.1.2項に示したマニュアルに記載されている共有ストレージに関する問題の中に、該当するものがない場合は、『Oracle Fusion Middlewareリリース・ノート』の共有ストレージの問題に関する説明を参照してください(次のOracle Technology Networkで参照可能)。

http://www.oracle.com/technology/documentation/middleware.html

5.2 追加情報

次のMy Oracle Supportでより多くのソリューションを知ることができます。

http://support.oracle.com

問題の解決方法が見つからない場合は、サービス・リクエストを記録してください。

Oracle Technology Networkで提供されている『Oracle Fusion Middlewareリリース・ノート』も参照できます。

http://www.oracle.com/technology/documentation/middleware.html

A Oracleインベントリの管理

この付録では、本番サイトおよびスタンバイ・サイトでの、Oracle Fusion Middleware障害時リカバリ・トポロジにおけるOracleインベントリの管理方法について説明します。

この章の内容は次のとおりです。

- 第A.1項「Oracleインベントリの更新」

- 第A.2項「Windowsレジストリの更新」

A.1 Oracleインベントリの更新

本番サイトのホストでOracleインベントリを更新するときには(新しいOracleソフトウェアのインストール、既存のOracleソフトウェアへのOracleパッチ・セットまたはパッチの適用など)、スタンバイ・サイトのピア・ホストでも同じようにソフトウェアを更新する必要があります。そのためには、次のスクリプトを実行してスタンバイ・サイトのピア・ホストでOracleインベントリを更新する必要があります。

ORACLE_HOME/oui/bin/attachHome.sh

また、beahomelistファイルを更新して、Oracleホームの場所を編集する必要があります。次のファイルを編集して、Oracleホーム情報を更新します。

user_home/bea/beahomelist

(Windows) C:\bea\beahomelist

A.2 Windowsレジストリの更新

本番サイトのWindowsホストでOracleインベントリを更新するときは(新しいOracleソフトウェアのインストール、既存のOracleソフトウェアへのOracleパッチ・セットまたはパッチの適用など)、本番サイトのホストで次のWindowsレジストリ・キーをエクスポートし、これをスタンバイ・サイトのピア・ホストにインポートすることによって、同じソフトウェア更新をスタンバイ・サイトのピア・ホストでも実行する必要があります。

HKEY_LOCAL_MACHINE\Software\oracle

また、システム・コンポーネント(Oracle Web Cacheなど)を変更する場合、次のWindowsレジストリ・キーを本番サイトのホストにエクスポートし、これをスタンバイ・サイトのピア・ホストにインポートする必要があります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

以前エクスポートしたキーをインポートするには、次のコマンドを使用します。

regedit /I FileName

例:

regedit /I C:\oracleregistry.reg

レジストリ・エディタを使用して、キーをインポートすることもできます。詳細は、レジストリ・エディタのヘルプを参照してください。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。