障害時リカバリとは、自然災害またはそれ以外の災害によるサイトの壊滅的な障害からシス テムを回復することを指します。これら壊滅的な障害の例として、地震、竜巻、洪水、火事 などがあります。さらに、システムの計画停止の管理方法も障害時リカバリに含まれます。
障害時リカバリを必要とするほとんどの状況において、障害の解決には個々のハードウェア やサブコンポーネントのレプリケーションだけでなく、サイト全体を対象としたレプリケー ションを行う必要があります。これは、Oracle Application Server Disaster Recovery
（OracleAS Disaster Recovery）ソリューションについても同様です。
この章では、OracleAS Disaster Recoveryソリューション、その環境の構成およびセット アップ方法、およびソリューションの高可用性の向上を目的とした管理方法について説明し ます。ここでは、本番用およびスタンバイ用の2つのサイト内のOracleAS Middle Tierおよ
びInfrastructure層の両方を対象にします。スタンバイ・サイトは本番サイトと同じように
構成されます。通常の運用では、本番サイトがリクエストを積極的に処理します。スタンバ イ・サイトは、本番サイトがホスティングするアプリケーションおよびコンテンツをミラー 化するために維持されています。
これらのサイトは、Oracle Application Server Backup and Recovery Tool（ファイル・シス テム上の構成ファイル用）およびOracle Data Guard（Infrastructureデータベース用）によ り同期化されます。次の表に、OracleAS Disaster Recoveryの実行計画を要約します。
表表表
表6-1 OracleAS Disaster Recoveryの実行計画の概要の実行計画の概要の実行計画の概要の実行計画の概要 対象
対象対象
対象 ツールツールツールツール 目的目的目的目的
中間層構成ファイル Backup and Recovery Tool 本番サイトの中間層ノードにある
OracleAS構成ファイルをバックアッ
プして、スタンバイ・サイトの中間 層ノードで構成ファイルをリストア します。
これらリカバリの実行計画に加えて、両サイトの構成およびインストールについても説明し ます。これらのタスクでは、中間層ノードをネーミングする2つの異なる方法、さらにはサ イト間およびサイト内でホスト名を解決する2つの方法について説明します。
OracleAS Disaster Recoveryでは、スタンバイ・サイトに切り替えることで、サービスを中
断することなく本番サイトを計画停止できます。計画外停止は、スタンバイ・サイトにフェ イルオーバーすることで管理されます。スイッチオーバーおよびフェイルオーバーの手順に ついてもこの章で説明します。
この章は、次の主要な項で構成されています。
■ Oracle Application Server 10g Disaster Recoveryソリューション
■ OracleAS Disaster Recovery環境のセットアップ
■ Oracle Application Server 10gソフトウェアのインストール
■ ベースライン・インストールとスタンバイ・サイトの同期化
■ 本番サイトのバックアップ
■ スタンバイ・サイトへのリストア
■ スケジューリングした停止
■ 計画外停止
■ ワイド・エリアDNSの操作 Infrastructure構成
ファイル
Backup and Recovery Tool 本番サイトのInfrastructureノードに
あるOracleAS構成ファイルをバック
アップして、スタンバイ・サイトの Infrastructureノードで構成ファイル をリストアします。
Infrastructureデータ ベース
Oracle Data Guard 本番サイトのInfrastructureデータ ベースにあるアーカイブ・ログをス タンバイ・サイトのInfrastructure データベースへ転送します。ログは すぐには適用されないことに注意し てください。
表 表表
表6-1 OracleAS Disaster Recoveryの実行計画の概要（続き）の実行計画の概要（続き）の実行計画の概要（続き）の実行計画の概要（続き）
対象 対象対象
対象 ツールツールツールツール 目的目的目的目的
Oracle Application Server 10g Disaster Recoveryソリューション
Oracle Application Server 10g Disaster Recovery ソリューション ソリューション ソリューション ソリューション
Oracle Application Server Disaster Recoveryソリューションは、プライマリ（本番/アク ティブ）とセカンダリ（スタンバイ）という、同一の構成を持つ2つのサイトからなりま す。両方のサイトには、同数の中間層ノードとInfrastructureノードがインストールされ、
同数で同種のコンポーネントがインストールされます。つまり、両サイトのインストールで 中間層およびInfrastructureは同じです。これらのサイトは通常、地理的に分散されます。
その場合、Wide Area Network経由でつながっています。
この項では、ソリューション全体のレイアウト、関連する主要なコンポーネントおよびそれ らのコンポーネントの構成について説明します。この項の内容は次のとおりです。
■ 用語
■ 要件
■ トポロジ
用語 用語 用語 用語
OracleAS Disaster Recoveryソリューションについて、その内容と詳細を説明する前に、こ
の章で説明する概念を正しく理解するために、この章で使用されるいくつかの用語の定義を 明確にしておく必要があります。
■ 物理ホスト名物理ホスト名物理ホスト名物理ホスト名
この章の説明では、物理ホスト名と論理ホスト名という2つの用語が異なる意味で使用 されます。物理ホスト名は、現行マシンの内部名を表すために使用されます。UNIXで は、コマンドhostnameにより返される名前です。
物理ホスト名は、現行マシンにインストールされているOracle Application Server 10g コンポーネントにより、ローカル・ホストを参照する名前として使用されます。物理ホ スト名は、これらのコンポーネントのインストール時に、インストーラにより現行マシ ンから取得され、ディスク上のOracle Application Server 10g構成メタデータに格納さ れます。
■ 論理ホスト名論理ホスト名論理ホスト名論理ホスト名
論理ホスト名は、/etc/hostsファイル（UNIXの場合）、
C:¥WINDOWS¥system32¥drivers¥etc¥hostsファイル（Windowsの場合）または DNS解決のいずれかで指定される、IPアドレスに割り当てられる名前です。この名前 は、ホストが接続しているネットワークで参照可能です。多くの場合、論理ホスト名と 物理ホスト名は同じものを指します。ただし、 ソリュー
注意注意注意
注意: 後述の用語定義は、特にOracleAS Disaster Recoveryに当てはま ります。これ以外のコンテキストでは、定義が異なる場合があります。
Oracle Application Server 10g Disaster Recoveryソリューション
■ 仮想ホスト名仮想ホスト名仮想ホスト名仮想ホスト名
仮想ホスト名は、OracleASインストーラの「High Availability Addressingの指定」画 面で指定されたInfrastructureホストの名前を表すために使用されます。仮想ホスト名 は、中間層コンポーネントおよびInfrastructureコンポーネントがInfrastructureへのア クセスに使用する名前です。Infrastructureが単一ノードのインストールであるか、ま
たはOracleAS Cold Failover Clusterソリューションの一部であるかどうかは関係あり
ません。この章では、仮想ホスト名がInfrastructureホストにのみ適用されます。
要件 要件 要件 要件
OracleAS Disaster Recoveryソリューションの実装を計画どおり動作させるには、次の要件
を順守する必要があります。
■ スタンバイ・サイトの各ホストでは、次の項目を本番サイトの同等のホストと同じにす る必要があります。
■ 中間層ホストの場合は、物理ホスト名。
■ Infrastructureの仮想ホスト名。仮想ホスト名は、インストーラにより表示される
「High Availability Addressingの指定」画面で指定できます。
■ ハードウェア・プラットフォーム。
■ オペレーティング・システムのリリースとパッチ・レベル。
■ Oracle Application Serverのすべてのインストールで、Oracle Application Server 10gの インストレーション・ガイドに記載されている要件を順守する必要があります。
■ Oracle Application Serverソフトウェアは、本番サイトの各ホストとスタンバイ・サイ
トの同等のホストで、同一のディレクトリ・パスにインストールします。
■ Oracle Application Serverをインストールしたユーザーのユーザー名とパスワードが本
番サイトのホストとスタンバイ・サイトの同等のホストで、同じである必要がありま す。
■ 特定のノードにOracle Application ServerをインストールしたユーザーのユーザーID番 号。
■ 特定のノードにOracle Application Serverをインストールしたユーザーのグループ名。
■ 特定のノードにOracle Application ServerをインストールしたユーザーのグループID番 号。
Oracle Application Server 10g Disaster Recoveryソリューション
■ 中間層: 「J2EE and Web Cache」、「Portal and Wireless」および「Business Intelligence and Forms」。
■ Infrastructure: Metadata RepositoryおよびIdentity Management（OracleAS
Disaster Recoveryソリューションの両サイトでは、「Infrastructure」インストー
ル・タイプを使用して、これらをインストールする必要があります）。
トポロジ トポロジ トポロジ トポロジ
図6-1に、OracleAS Disaster Recoveryソリューションのトポロジを示します。
図図図
図6-1 Oracle Application Server 10gのサイト間の障害時リカバリ・ソリューション（中間層のサイト間の障害時リカバリ・ソリューション（中間層のサイト間の障害時リカバリ・ソリューション（中間層のサイト間の障害時リカバリ・ソリューション（中間層 ノードが
ノードがノードが
ノードが1つの場合は、ロード・バランサ機器はオプション）つの場合は、ロード・バランサ機器はオプション）つの場合は、ロード・バランサ機器はオプション）つの場合は、ロード・バランサ機器はオプション）
Oracle Application Server 10g Disaster Recoveryソリューション
OracleAS Disaster Recoveryソリューションの構成および運用手順では、本番サイトにおけ
る、任意の数の中間層インストールがサポートされます。スタンバイ・サイトには、同じ数 の中間層インストールを配置する必要があります。本番サイトとスタンバイ・サイトでは、
中間層を相互にミラー化します。
Infrastructureの場合は、本番サイトとスタンバイ・サイトで同じ数のインストールが必要
とされません。たとえば、本番サイトにはOracle Application Server Cold Failover Cluster ソリューションを配置し、スタンバイ・サイトには、1つのノードにInfrastructureインス トールを配置できます。このように、OracleAS Cold Failover Clusterを使用して本番サイト のInfrastructureをホストの障害から保護します。OracleAS Cold Failover Clusterの詳細は、
第3章の「Oracle Application Server Cold Failover Cluster」を参照してください。
OracleAS Disaster Recoveryソリューションの重要な特徴は、次のとおりです。
■ 中間層インストールは、本番サイトとスタンバイ・サイト間で同じです。つまり、本番 サイトの中間層の各インストールは、スタンバイ・サイトにまったく同等のインストー ルを持ちます。中間層ノードは複数にすることをお薦めします。これにより、それぞれ のサイトの中間層インストールの各セットを冗長にできるためです。中間層インストー ルが複数のマシンにあるため、そのサイトでの障害および停止はクライアントにとって 透過的になります。
■ OracleAS Disaster Recoveryソリューションのサイト構成は同一にする必要があります。
これは、プロセスおよび処理手順を両サイトで同一にすることで、運用タスクの実行お よび維持が容易になるためです。また同一のサイト構成は、Oracle Application Server 10gコンポーネント構成ファイルのサイト間での同期化を手動で行う際にエラーを防ぎ ます。
■ 障害が原因で本番サイトが使用不能になったときは、妥当な時間内に、スタンバイ・サ イトが運用可能になります。クライアント・リクエストは、本番として運用されている サイトに必ずルーティングされます。サイトの停止に伴うフェイルオーバーまたはス イッチオーバー処理が実行された後、クライアント・リクエストは運用を引き継いだ別 のサイトへとルーティングされます。新しい本番サイトが提供するサービスの質は、停 止前に元の本番サイトが提供していたサービスと同じになります。
■ サイトは、アクティブ/パッシブ構成でセットアップされます。アクティブ/パッシ ブ・セットアップは、本番として使用される1つのプライマリ・サイトと最初はパッシ ブ（スタンバイ）になっている1つのセカンダリ・サイトで構成されます。セカンダ リ・サイトは、フェイルオーバーまたはスイッチオーバーが実行された後にのみアク ティブになります。両サイトには対称性があるため、フェイルオーバーまたはスイッチ オーバー後は、元のスタンバイ・サイトを新しい本番サイトとしてアクティブな状態に 維持できます。修復またはアップグレードが終わると、元の本番サイトは新しいスタン