10g リリース2（10.1.2）
B15817-04
 目次 |
 索引 |
| Oracle Application Server 高可用性ガイド 10g リリース2（10.1.2） B15817-04 |
|
障害時リカバリとは、自然災害またはそれ以外の災害によるサイトの壊滅的な障害からシステムを回復することを指します。これら壊滅的な障害の例として、地震、竜巻、洪水、火事などがあります。さらに、システムの計画停止の管理方法も障害時リカバリに含まれます。障害時リカバリを必要とするほとんどの状況において、障害の解決には個々のハードウェアやサブコンポーネントのレプリケーションだけでなく、サイト全体を対象としたレプリケーションを行う必要があります。これは、Oracle Application Server Disaster Recovery（OracleAS Disaster Recovery）ソリューションについても同様です。
この章では、OracleAS Disaster Recoveryソリューション、その環境の構成および設定方法、およびソリューションの高可用性の向上を目的とした管理方法について説明します。ここでは、本番用およびスタンバイ用の2つのサイト内のOracleAS中間層およびInfrastructure層の両方を対象にします。スタンバイ・サイトは本番サイトと同じように、また対称的あるいは非対称的に構成されます。通常の運用では、本番サイトがリクエストを積極的に処理します。スタンバイ・サイトは、本番サイトがホスティングするアプリケーションおよびコンテンツを完全にミラー化した状態またはそれに近い状態で維持されます。
これらのサイトは、Oracle Application Server Guardを使用して管理します。Oracle Application Server Guardには、各種の管理タスク（これらの管理コマンドの詳細は、第14章「OracleAS Guard asgctlコマンドライン・リファレンス」を参照）がカプセル化されたコマンドライン・ユーティリティ（asgctl）が用意されています。OracleAS Disaster Recoveryソリューションでは、サイト全体で使用できるシステム・サービスの中でも特に次のサービスを活用します。背後では、OracleAS Guardによってトポロジ内に分散されたBackup and Recovery Tool（ファイル・システムの構成ファイルの管理）とOracle Data Guard（OracleAS Infrastructureデータベースの管理）が自動的に使用されます。表13-1に、OracleAS Disaster Recoveryの実行計画と、このOracleソフトウェアが背後で使用される方法を要約します。
OracleAS 10gリリース2（10.1.2.0.2）以降、OracleAS Disaster Recoveryソリューションの説明に使用する概念をわかりやすくするために、本番サイトまたはスタンバイ・サイトのすべてのファームを示すのに「トポロジ」という用語を使用するようになりました。用語「トポロジ」の意味するものは、以前は、OracleAS 10gリリース2（10.1.2.0.0）のOracleAS Disaster Recoveryソリューションのドキュメントでの記述のように「ファーム」という用語で表されていました。「トポロジ」という用語は、本番サイトの同じOracle Internet Directoryを共有するすべてのインスタンスを示します。discover topologyコマンドは、Oracle Internet Directoryに問合せを行い、インスタンスのリストを調べ、本番トポロジを記述するトポロジXMLファイルを生成します。discover topology within farmコマンドは、Oracle Internet Directoryを使用できない場合に使用され、OracleAS GuardによってOPMNが使用されてファーム内のトポロジが検出されます。
これらリカバリの実行計画に加えて、両サイトの構成およびインストールについても説明します。これらのタスクでは、中間層ノードをネーミングする2つの異なる方法、さらにはサイト間およびサイト内でホスト名を解決する2つの方法について説明します。
OracleAS Disaster Recoveryでは、OracleAS Guardスイッチオーバー操作を使用してスタンバイ・サイトに切り替えることで、サービスを中断することなく本番サイトを計画停止できます。計画外停止は、OracleAS Guardフェイルオーバー操作を使用してスタンバイ・サイトにフェイルオーバーすることで管理できます。スイッチオーバーおよびフェイルオーバーの手順についてはこの章の第13.10項「実行時操作 -- OracleAS Guardのスイッチオーバーおよびフェイルオーバー操作」で説明します。
この章は、次の項で構成されています。
Identity Management（IM）Infrastructureを地理的に分散配置するレプリケーション方法は、アクティブ/アクティブ構成の例になりますが、Oracle Internet Directory（OID）、OracleAS Metadata Repository（MR）およびOracleAS Single Sign-On（SSO）がレプリケーション構成で設定され、異なる地域に分散配置されるOracleAS Disaster Recoveryソリューションと特徴が似ています。OracleAS Single Sign-Onの各サイトでは、そのローカル・サイトに配置されたそれ自体のOracle Internet DirectoryとOracleAS Metadata Repositoryが使用され、アクティブ/アクティブ構成となります。このように類似していることには、2つの目的があります。1つは、データベース障害が1つのサイトで検出された場合、ユーザー・リクエストが地理的に最も近い領域にルーティングされるようにOracle Internet DirectoryおよびOracleAS Single Sign-Onサーバーを再構成することです。もう1つは、OracleAS Single Sign-On中間層の障害が検出された場合に、トラフィックがリモート中間層にルーティングされるようにネットワークを再構成することです。しかし、このソリューションでは、Infrastructureデータベース内のOracleAS Portal、OracleAS WirelessおよびDistributed Configuration Management（DCM）スキーマの同期化が行われません。これは、これらのいずれでも、Oracle Internet DirectoryとOracleAS Single Sign-Onの情報に使用するレプリカ・モデルがサポートされていないためです。地理的に分散されたIdentity Management Infrastructureの詳細は、『Oracle Identity Management概要および配置プランニング・ガイド』を参照してください。
Oracle Application Server Disaster Recoveryソリューションは、プライマリ（本番/アクティブ）とセカンダリ（スタンバイ）という構成を持つ2つのサイトからなります。両方のサイトには、同数の中間層と同数のOracleAS Infrastructureノード、および同数で同種のコンポーネントがインストールされている場合もされていない場合もあります。つまり、両サイトのインストールで、中間層およびOracleAS Infrastructureが同じ場合（対称トポロジ）も同じでない場合（非対称トポロジ）もあります。これらのサイトは通常、地理的に分散されます。その場合、Wide Area Network経由でつながっています。
Oracle Application Server Disaster Recoveryソリューションで重要な点は次のとおりです。
この項では、ソリューション全体のレイアウト、関連する主要なコンポーネントおよびそれらのコンポーネントの構成について説明します。この項の内容は次のとおりです。
OracleAS Disaster Recoveryソリューションの実装を計画どおり動作させるには、次の要件を満たしている必要があります。
すでにシステムをインストールしている場合は、スタンバイ・サイトの中間層システムの物理名を変更し、OracleAS Infrastructureの物理ホスト名に仮想ホスト名を作成するだけです（次の項目を参照）。物理ホスト名と仮想ホスト名を変更する手順は、第13.2.1項「ホスト名の計画と割当て」を参照してください。
注意
OracleAS Guardは、Oracle Application Server 10gリリース1（9.0.4）と10gリリース2（10.1.2.0.0および10.1.2.0.2）をサポートします。トポロジ内にOracleホームまたはOracle Application Serverインスタンスがあるすべてのシステムに、10gリリース2（10.1.2.0.2）のOracleAS Companion CD 2にあるOracleAS Guardキットをインストールする必要があります。詳細は、Oracle Application Serverのインストレーション・ガイドのOracleAS Disaster Recoveryのインストール情報を参照してください。
OracleAS Guardは、アップグレード・シナリオの中で発生する可能性があるOracleAS 10gリリース1（9.0.4）とOracleAS 10gリリース2（10.1.2）以降のリリースの混在環境をサポートします。この場合、スタンバイ・サイトで中間層はOracleAS 10gリリース2（10.1.2）Oracleホームにアップグレードしたが、Infrastructureは依然としてOracleAS 10g（9.0.4）Infrastructureであることがあります。このリリース混在環境は、本番サイトの中間層OracleホームのOracleAS Disaster Recoveryの同等のホームが同じリリースであるOracleAS 10gリリース2（10.1.2）にアップグレードされ、かつ、そのInfrastructureが依然としてOracleAS 10gリリース1（9.0.4）Infrastructureのままであるかぎり動作します。つまり、トポロジ内のすべてのOracleホームの同等の中間層が、スタンバイ・サイトと本番サイトの両方で完全に一致するリリース番号である必要があります。また、Infrastructureもスタンバイ・サイトと本番サイトの両方でリリース番号が完全に一致する必要があり、Oracle AS Guardも両方のサイトで同じバージョンである必要があります。ただし、アップグレードに基づいた要件として、Infrastructureは中間層よりも前のリリースにすることができます。それは、この状況がアップグレード・シナリオの中で発生するためです。
OracleAS Disaster Recoveryでは、本番サイトとスタンバイ・サイトのInfrastructureと中間層の構成についていくつかの基本トポロジがサポートされています。OracleAS Disaster Recoveryでサポートされている基本トポロジは次のとおりです。
OracleAS Disaster Recovery（10.1.2.0.1）の場合、サポートされていたのは、OracleAS Disaster Recoveryの対称トポロジ環境だけでした。このOracleAS Disaster Recovery環境には、2つの主要な要件があります。
図13-1は、プライマリ・サイトにCold Failover Clusterがある、対称トポロジを持つOracleAS Disaster Recoveryソリューションの例を示しています。これは、Oracle Application Serverの視点から見ると、両方のサイトに2つのOracleAS中間層と1つのInfrastructureが含まれているため、対称トポロジとみなされます。
OracleAS Disaster Recoveryソリューションの構成および運用手順では、本番サイトにおける、任意の数の中間層インストールがサポートされます。スタンバイ・サイトには、同じ数の中間層インストールを配置する必要があります。本番サイトとスタンバイ・サイトでは、中間層を相互にミラー化します。
OracleAS Infrastructureの場合は、本番サイトとスタンバイ・サイトで同じ数のインストールが必要とされません（名前またはインスタンスは同一である必要があります）。たとえば、図13-1に示すように、本番サイトにはOracleAS Cold Failover Cluster（Infrastructure）ソリューションを配置し、スタンバイ・サイトには、1つのノードにOracleAS Infrastructureインストールを配置できます。このように、OracleAS Cold Failover Clusterを使用して本番サイトのOracleAS Infrastructureをホストの障害から保護します。また、このソリューションでは仮想ホスト名を利用して、ハードウェアの冗長性を実現できます。OracleAS Cold Failover Clusterの詳細は、第6.2.2項「アクティブ/パッシブ型の高可用性トポロジ」の項を参照してください。
OracleAS Disaster Recoveryソリューションは、様々な単一サイトのOracle Application Serverアーキテクチャを拡張したものです。たとえば、単一サイトのアーキテクチャには、OracleAS Cold Failover Cluster（Infrastructure）と、アクティブ/アクティブ構成のOracle Application Server中間層アーキテクチャを組み合せたものがあります。どのような単一サイト・アーキテクチャがサポートされているかについての最新情報は、Oracle Technology Network（OTN）のWebサイトで最新の動作要件を確認してください。
http://www.oracle.com/technology/products/ias/hi_av/index.html
OracleAS Disaster Recoveryソリューションの重要な特徴は、次のとおりです。
OracleAS Disaster Recovery（10.1.2.0.2）以降、サポート対象となる非対称トポロジには、次の単純な非対称スタンバイ・トポロジも含まれています。
図13-2は、4つの中間層インスタンスと1つのInfrastructure（Oracle Identity ManagementとOracleAS Metadata Repositoryが同じ場所にある）で構成された本番サイトを示しています。この例では、中間層1に配置されたサービスとアプリケーションは、中間層2を含むようにスケール変更されます。さらに、中間層3に配置されたサービスとアプリケーションは、中間層4を含むようにスケール変更されます。障害時リカバリのための本番サイトより少ない数のリソースの要件を満たすために、スタンバイ・サイトでのスケール変更は必要ありません。したがって、本番中間層1と2に配置されたサービスは、スタンバイ・サイトの障害時リカバリの同等の中間層1によって満たされ、このスタンバイ・サイトの中間層1は本番中間層1と同期化されます。同様に、本番中間層3と4に配置されたサービスは、スタンバイ・サイトの障害時リカバリの同等の中間層3によって満たされ、このスタンバイ・サイトの中間層3は本番中間層3と同期化されます。
図13-3は、4つの中間層インスタンスで構成された本番サイトを示しています。そのうちの2つの中間層（1と2）と本番のInfrastructureサービスが同じ場所にあり、残りの2つの中間層（3と4）がスタンバイ・サイトにリモート配置されています。スタンバイ・サイトは、Infrastructureサービスに対してのみ障害時リカバリの機能を提供するために使用されます。この構成では、中間層リソースは、アクティブ/アクティブ・モデルで、技術的には1つの本番トポロジとして構成されます。
通常の状態では、アプリケーション・リクエストに対して中間層1〜4がサービスを提供できます。このモデルでは、中間層3と4に配置されたサービスとアプリケーションは、このトポロジに関連する待機時間、ファイアウォールおよびネットワークの問題に対応できると想定されます。障害時リカバリの運用では、維持する必要があるのはInfrastructureサービスのみです。中間層インスタンスの配置とメンテナンスは、通常の本番サイトの管理によって行われます。
一般的に、非対称トポロジのサポートとは、OracleAS Disaster Recoveryのスタンバイ・サイトでは、リソースの数が本番サイトより少なく（または少ない可能性があり）、縮小したOracleホームを維持し、最小レベルのサービス機能が保証されることを意味します。
このトポロジ（図13-4）は、2つのOracleAS Metadata Repositoryを持つ1つのOracleAS Infrastructureと複数の中間層で構成されています。1つのOracleAS Metadata RepositoryはOracle Identity Managementコンポーネント（Oracle Internet DirectoryやOracleAS Single Sign-Onなど）によって使用されます。すべての中間層および拡張されたときにこのトポロジに追加される中間層は、Oracle Identity Managementサービスに、このOracleAS Metadata Repositoryを使用します。もう1つのOracleAS Metadata Repositoryは、OracleAS PortalおよびOracleAS Wireless中間層コンポーネントによって製品メタデータのために使用されます。2つのメタデータ・リポジトリを持つこの配置は2つのDCM本番ファームといえます。
OracleAS Disaster Recoveryのスタンバイ構成は、第13.1.3.1項「対称トポロジ - Oracle Identity ManagementとOracleAS Metadata Repositoryが同じ場所にあるInfrastructureによる本番サイトの完全なミラー」の説明のように対称トポロジとして設定すること（2つのDCMスタンバイ・ファームの構成が必要）も、第13.1.3.2項「非対称トポロジ - Oracle Identity ManagementとOracleAS Metadata Repositoryが同じ場所にあるInfrastructureによる単純な非対称のスタンバイ・トポロジ」の説明のように単純な非対称トポロジとして設定すること（最低1つのDCMスタンバイ・ファームの構成が必要なサービスを保証）もできます。
第13.1.3.1項「対称トポロジ - Oracle Identity ManagementとOracleAS Metadata Repositoryが同じ場所にあるInfrastructureによる本番サイトの完全なミラー」、第13.1.3.2項「非対称トポロジ - Oracle Identity ManagementとOracleAS Metadata Repositoryが同じ場所にあるInfrastructureによる単純な非対称のスタンバイ・トポロジ」および第13.1.3.3項「OracleAS PortalのOracleAS Metadata Repositoryは別の場所にあり、Oracle Identity ManagementとOracleAS Metadata Repository Infrastructureは同じ場所にある（部門別トポロジ）」のトポロジは、Oracle Identity ManagementとOracleAS Metadata Repositoryが同じ場所にあるInstructureによるデフォルトのデータベース・リポジトリの配置を示しています。第13.1.3.3項「OracleAS PortalのOracleAS Metadata Repositoryは別の場所にあり、Oracle Identity ManagementとOracleAS Metadata Repository Infrastructureは同じ場所にある（部門別トポロジ）」は、OracleAS Metadata Repositoryが別の場所にあるトポロジを示しています。
アプリケーションOracleAS Metadata Repositoryが分散し、Oracle Identity ManagementとOracleAS Metadata Repository Infrastructureが同じ場所にないトポロジでは、Oracle Identity Management Infrastructureと1つのOracleAS Metadata Repository Infrastructureは別々のホストにインストールされ、他のOracleAS Metadata Repositoryは異なるホストに、それぞれのアプリケーションと常駐するようにインストールされます。したがって、1つのOracleAS Metadata Repositoryは、1つのデフォルトInfrastructureインストールを使用した配置の結果であり、1つ以上のOracleAS Metadata Repositoryは、OracleASユーザーが、管理またはポリシー、あるいはその両方の理由のために、OracleAS Metadata Repository Creation Assistantなどのツールを使用して1つ以上のアプリケーションOracleAS Metadata Repositoryをアプリケーション・データを持つ1つ以上のシステムにインストールした結果である可能性があります。
図13-5は、Oracle Identity ManagementとOracleAS Metadata Repositoryが同じ場所にあるInfrastructureで、OracleAS Metadata Repositoryが分散しているOracleAS Disaster Recoveryソリューションの例を示しています。
OracleAS Disaster Recoveryソリューション用にOracleASソフトウェアをインストールする前に、システム・レベルで必要な構成やオプションの構成を行います。これらの構成を実行するタスクには、次のものがあります。
この項では、非対称トポロジで、これらのタスクの実行に必要な手順について説明します。同じ手順は、単純な非対称スタンバイ・サイトにも適用できます。また、OracleAS Metadata Repositoryが分散されているかどうかに関係なく、Oracle Identity ManagementとOracleAS Metadata Repositoryが同じ場所にないトポロジにも適用できます。
物理ホスト名およびネットワーク・ホスト名の設定手順を実行する前に、OracleAS Disaster Recoveryソリューション全体で使用する物理ホスト名およびネットワーク・ホスト名を計画します。ホスト名の計画および割当てにおける全体的なアプローチでは、次の目標を達成する必要があります。
たとえば、本番サイトの中間層コンポーネントが同じサイト内のホストへのアクセスに名前asmid1を使用するのであれば、スタンバイ・サイトの同じコンポーネントはこの同じ名前を使用して、スタンバイ・サイト内にあるasmid1と同等のホストにアクセスする必要があります。同様に、本番サイトのOracleAS Infrastructureの仮想ホスト名にinfraという名前を使用する場合は、スタンバイ・サイトのOracleAS Infrastructureの物理ホスト名にもinfraという仮想ホスト名を使用する必要があります。
本番サイトとスタンバイ・サイトの物理ホスト名は両サイト間で統一する必要がありますが、物理ホスト名を解決した後の適切なホストは異なっていてもかまいません。ホスト名解決は、第13.2.2項「ホスト名解決の構成」で説明します。
注意
図13-6は、ホスト名の計画と割当てのプロセスを示しています。
図13-6では、本番サイトに2つの中間層ノードがあります。OracleAS Infrastructureは単一ノードまたはOracleAS Cold Failover Clusterソリューション（単一ノードの OracleAS Infrastructureと同様、1つの仮想ホスト名と仮想IPで表される）にすることができます。 2つのサイトの一般名は、中間層ノードの物理ホスト名とOracleAS Infrastructureの仮想ホスト名です。表13-2は、例における物理、ネットワークおよび仮想ホスト名を示しています。
| 物理ホスト名 | 仮想ホスト名 | ネットワーク・ホスト名 |
|---|---|---|
asmid1 |
- |
prodmid1, standbymid1 |
asmid2 |
- |
prodmid2, standbymid2 |
- 1 |
infra |
prodinfra, standbyinfra |
|
1
この例では、物理ホスト名はネットワーク・ホスト名になります。そのため、このネットワーク・ホスト名を、asgctlコマンドの<host>、<host-name>または<standby_topology_host>パラメータ引数に使用します。 |
本番サイトに非OracleASアプリケーションを実行しているホストがあり、そのホストでOracleASを共同ホスティングする場合、このホストの物理ホスト名を変更すると、非OracleASアプリケーションが使用不能になることがあります。このようなケースでは、本番サイトのホスト名はそのままにして、スタンバイ・サイトの物理ホスト名を本番サイトと同じホスト名に変更します。その後で、非OracleASアプリケーションをスタンバイ・ホストにもインストールすることで、このホストは非OracleASアプリケーションに対するスタンバイの役割も果たせます。
第1.2.1項「用語」の説明にあるように、OracleAS Disaster Recoveryソリューションでの物理ホスト名、ネットワーク・ホスト名および仮想ホスト名の用途は他のアプリケーションとは異なります。また、これらの設定方法も異なります。次の項では、3つのタイプのホスト名の設定方法について説明します。
本番サイトとスタンバイ・サイトの両方の各ホストで、中間層ホストの物理ホスト名を変更する必要があります。
Solarisで、ホストの物理ホスト名を変更する手順は次のとおりです。
prompt> hostname
viなどのテキスト・エディタを使用して、/etc/nodenameの名前を、計画した物理ホスト名に編集します。
Windowsで、ホストの物理ホスト名を変更する手順は次のとおりです。
_CLUSTER_NETWORK_NAME_"を入力します。
OracleAS Disaster Recoveryソリューションで使用されるネットワーク・ホスト名は、ドメイン・ネーム・システム（DNS）に定義されます。これらのホスト名はソリューションで使用するネットワークで参照可能で、DNSにより、DNSシステムで割り当てられたIPアドレスを使用して適切なホストへと解決されます。そのため、ネットワーク・ホスト名と対応するIPアドレスを、DNSシステムに追加する必要があります。
図13-6の例では、本番サイトとスタンバイ・サイトを有するネットワーク全体を管理するDNSシステムに、次のエントリを追加する必要があります。
prodmid1.oracle.com IN A 123.1.2.333 prodmid2.oracle.com IN A 123.1.2.334 prodinfra.oracle.com IN A 123.1.2.111 standbymid1.oracle.com IN A 213.2.2.443 standbymid2.oracle.com IN A 213.2.2.444 standbyinfra.oracle.com IN A 213.2.2.210
第1.2.1項「用語」の項で定義したように、仮想ホスト名はOracleAS Infrastructureにのみ適用されます。仮想ホスト名は、OracleAS Infrastructureのインストール時に指定します。「OracleAS Infrastructure」インストール・タイプを実行すると、「仮想ホストの指定」という画面が表示され、インストール中のOracleAS Infrastructureの仮想ホスト名を入力するテキストボックスが表示されます。詳細は、Oracle Application Serverのインストレーション・ガイドを参照してください。
図13-6の例の場合は、本番サイトのOracleAS Infrastructureのインストール時に「仮想ホストの指定」画面が表示されたら、仮想ホスト名infraを入力します。スタンバイ・サイトのOracleAS Infrastructureのインストール時にも、同じ仮想ホスト名を入力します。
OracleAS Disaster Recoveryソリューションでは、第13.2.1項「ホスト名の計画と割当て」で計画して割り当てたホスト名の解決に、次の2つのいずれかのホスト名解決方法を構成できます。それらのコンポーネントには次のものがあります。
UNIXでは、ファイル/etc/nsswitch.confのhostsパラメータを使用して、名前解決の方法の順序を指定できます。次に、hostsエントリの例を示します。
hosts: files dns nis
この文では、ローカル・ホスト名ファイル解決がDNS解決およびNIS（Network Information Service）解決よりも優先されています。ホスト名のIPアドレスへの解決が必要になったら、/etc/hostsファイル（UNIXの場合）またはC:¥WINDOWS¥system32¥drivers¥etc¥hostsファイルが最初に参照されます。ローカル・ホスト名ファイル解決でホスト名を解決できなかったときは、DNSが使用されます（NIS解決は、OracleAS Disaster Recoveryソリューションでは使用されません）。ファイル/etc/nsswitch.confを使用した名前解決の詳細は、UNIXシステムのドキュメントを参照してください。
ホスト名解決のこの方法は、必要なホスト名とそのIPアドレスの対応付けが記載されたローカル・ホストネーミング・ファイルに依存します。UNIXでは、このファイルは/etc/hostsです。Windowsでは、このファイルはC:¥WINDOWS¥system32¥drivers¥etc¥hostsです。
UNIXでOracleAS Disaster Recoveryソリューションのホスト名解決にローカル・ホストネーミング・ファイルを使用するには、本番サイトとスタンバイ・サイト両方の中間層およびOracleAS Infrastructureの各ホストで、次の手順を実行します。
viなどのテキスト・エディタを使用して、/etc/nsswitch.confファイルを編集します。hosts:パラメータで、ホスト名解決の第一の選択肢としてfilesを指定します。
/etc/hostsファイルを編集します。
ホスト・ファイルにエントリを追加する場合は、計画したホスト名をホスト・ファイルの2番目の列に指定してください。そうしないと、asgctlの
注意
verify topology with <host>の操作に失敗し、本番トポロジがスタンバイ・トポロジと対称ではないというエラー・メッセージが表示されます。この種の問題のトラブルシューティングと解決方法は、付録A「高可用性のトラブルシューティング」を参照してください。
たとえば、本番サイト内にある中間層ノードの/etc/hostsファイルを編集している場合は、現行ホストのエントリをリストの最初にして、本番サイト内のすべての中間層ノードの物理ホスト名とそのIPアドレスを入力します（短縮されたホスト名に加えて、完全修飾されたホスト名も含める必要があります。表13-3を参照）。
たとえば、スタンバイ・サイト内にある中間層ノードの/etc/hostsファイルを編集している場合は、スタンバイ・サイト内のOracleAS Infrastructureホストの仮想ホスト名（完全修飾名と短縮名の両方）とそのIPアドレスを入力します。
図13-6の例のasmid1ホストの場合は、次のコマンドを続けて使用します。
ping asmid1
返されたIPアドレスは123.1.2.333のはずです。
ping asmid2
返されたIPアドレスは123.1.2.334のはずです。
ping infra
返されたIPアドレスは123.1.2.111のはずです。
Windowsでは、ホスト名解決の順序を指定する方法は、Windowsのバージョンによって異なります。適切な手順については、ご使用のバージョンのWindowsのドキュメントを参照してください。
表13-3に、図13-6の例における、各本番ノードの/etc/hostsファイルのエントリを示します。これには、各UNIXホストで必須のエントリが含まれています。WindowsのC:¥WINDOWS¥system32¥drivers¥etc¥hostsファイルでも、必要なエントリは同様です。
/etc/hostsファイルにあるネットワーク・ホスト名と仮想ホスト名のエントリ
DNSホスト名解決を使用するようOracleAS Disaster Recoveryソリューションを設定するには、企業全体のDNSサーバーに加えて、サイト固有のDNSサーバーを本番サイトとスタンバイ・サイトに設定する必要があります（企業ネットワークには、冗長性を実現するために複数のDNSサーバーがあるのが一般的です）。図13-7に、この設定の概要を示します。
図13-7のトポロジが機能するには、次のことが要件または前提となります。
/etc/hostsファイルに、本番とスタンバイの両方のサイトのどのホストについても、物理ホスト名、ネットワーク・ホスト名または仮想ホスト名のエントリがないこと。Windowsでは、この要件はファイルC:¥WINDOWS¥system32¥drivers¥etc¥hostsに適用されます。
DNS解決を使用するOracleAS Disaster Recoveryソリューションを設定する手順は次のとおりです。
prodmid1.oracle.com IN A 123.1.2.333 prodmid2.oracle.com IN A 123.1.2.334 prodinfra.oracle.com IN A 123.1.2.111 standbymid1.oracle.com IN A 213.2.2.443 standbymid2.oracle.com IN A 213.2.2.444 standbyinfra.oracle.com IN A 213.2.2.210
oracleasを使用します。上位レベルの企業ドメイン名はoracle.comです。
図13-6の例のエントリは、次のようになります。
本番サイトのDNSサーバーの場合:
asmid1.oracleas IN A 123.1.2.333 asmid2.oracleas IN A 123.1.2.334 infra.oracleas IN A 123.1.2.111
スタンバイ・サイトのDNSサーバーの場合:
asmid1.oracleas IN A 213.2.2.443 asmid2.oracleas IN A 213.2.2.444 infra.oracleas IN A 213.2.2.210
|
注意
これらのサイトいずれかで、OracleAS InfrastructureにOracleAS Cold Failover Clusterソリューションを使用する場合は、クラスタの仮想ホスト名と仮想IPアドレスを入力します。たとえば、前の手順では |
OracleAS Guardは、Oracle Data Guardテクノロジの使用を自動化して、本番とスタンバイのOracleAS Infrastructureデータベースを同期化するため、本番OracleAS InfrastructureはスタンバイOracleAS Infrastructureを参照できる必要があり、その逆も同様です。
これを機能させるには、本番サイトのDNSサーバーに、スタンバイOracleAS InfrastructureホストのIPアドレスを、本番サイトに対して一意のホスト名とともに入力する必要があります。同様に、スタンバイ・サイトのDNSサーバーに、本番OracleAS InfrastructureホストのIPアドレスを、同じホスト名を使用して入力する必要があります。これらのDNSエントリが必要なのは、Oracle Data Guardでは、本番およびスタンバイOracleAS Infrastructureへのリクエストの転送にTNS名が使用されるためです。したがって、tnsnames.oraファイルにも適切なエントリを作成する必要があります。また、OracleAS Guardのasgctlコマンドライン・コマンドにも、ネットワーク・ホスト名を使用する必要があります。
図13-6の例では、リモートOracleAS Infrastructure用に選択した名前がremoteinfraであるとすると、本番サイトのDNSサーバーのエントリは次のようになります。
asmid1.oracleas IN A 123.1.2.333 asmid2.oracleas IN A 123.1.2.334 infra.oracleas IN A 123.1.2.111 remoteinfra.oracleas IN A 213.2.2.210
同様に、スタンバイ・サイトのDNSサーバーのエントリは次のようになります。
asmid1.oracleas IN A 213.2.2.443 asmid2.oracleas IN A 213.2.2.444 infra.oracleas IN A 213.2.2.210 remoteinfra.oracleas IN A 123.1.2.111
この項では、OracleAS Disaster Recoveryソリューションをインストールする手順の概要を示します。これらの手順は、第13.1.3項「サポートされているトポロジ」に示したトポロジに適用できます。第13.2項「OracleAS Disaster Recovery環境の準備」の手順に従ってソリューション環境を設定したら、この項でインストール・プロセスの概要をお読みください。その後に、Oracle Application Serverのインストレーション・ガイドの詳細な手順に従って、ソリューションをインストールします。
OracleAS Disaster Recoveryソリューションをインストールするための全般的な手順は次のとおりです。
インストールを実行するときは、次の点が重要です。
asmid1ホストは、本番サイトのasmid1ホストと同じポートを使用する必要があります。静的ポート定義ファイルを使用します（この項の前述の注意と次の点を参照）。
staticports.iniファイルへのフル・パスを指定します。
この項では、OracleAS Guardとそのコマンドライン・インタフェースであるasgctlの概要について説明します。この概要についてすでに理解している場合は、第13.5項「データベースの認証」に進んでください。この項の項目は次のとおりです。
asgctlコマンドライン・ユーティリティによって、OracleAS Disaster Recoveryの設定および管理に関する複雑で長い手順が大幅に簡素化されました。このユーティリティは、クライアント・コンポーネントとサーバー・コンポーネントで構成される分散ソリューションを提供します。クライアント・コンポーネント（OracleAS Guardクライアント）は、トポロジ上のシステムにインストールできます。サーバー・コンポーネント（OracleAS Guardサーバー）は、デフォルトでは、OracleAS Disaster Recovery環境を構成するプライマリおよびスタンバイOracleホームをホスティングするシステムにインストールされます。
OracleAS Guardクライアントは、すべてのOracleASインストール・タイプでインストールされます。OracleAS Guardクライアントは、OracleAS Guardサーバーとの接続の確立と維持を試みます。
OracleAS Guardクライアントには、asgctlコマンドライン・インタフェース（CLI）が用意されており（第14章「OracleAS Guard asgctlコマンドライン・リファレンス」を参照）、第13.4.4項「asgctl操作」で説明する管理タスクを実行する一連のコマンドが含まれています。
OracleAS Guardサーバーは、分散サーバーとして（デフォルトでインストールされ）、OracleAS Disaster Recovery構成のすべてのシステムで実行されます。OracleAS Guardクライアントは、OracleAS Disaster Recovery構成とネットワーク接続されている1つのシステムのOracleAS Guardサーバーとアクティブな接続を維持します。この調整サーバーは、必要に応じて、OracleAS Disaster Recovery構成内の他のシステムのOracleAS Guardサーバーと通信し、スタンバイ・サイトのクローニング、インスタンス化、同期化、検証、スイッチオーバーおよびフェイルオーバー操作の処理を実行します。OracleAS Guardサーバーは、OracleAS Guardクライアントから直接発行されたasgctlコマンドを実行したり、ネットワーク内の別のOracleAS GuardサーバーからOracleAS Guardクライアントにかわって発行されたコマンドをそのクライアントのセッション中に実行します。操作を実行する手順は、本番トポロジとスタンバイ・トポロジ両方のすべてのシステムで実行されます。ほとんどの操作手順は、OracleAS Disaster Recovery構成にあるこれらのシステムのOracleAS Guardサーバーで、必要に応じて並列または順番に実行されます。
asgctlコマンドを使用した主なasgctl操作は、次のいずれかの操作のカテゴリに分類されます。
フェイルオーバー操作の前にスタンバイ・トポロジで新しいOracleAS Infrastructureデータベースを識別します（set new primary databaseコマンド）。
特定のホストに対して、OracleAS GuardクライアントからOracleAS Guardサーバーへの接続、およびOracleAS Guardサーバー間の接続を認証するための資格証明を設定します（set asg credentialsコマンド）。例は、set asg credentialsコマンドを参照してください。詳細は、第13.14.1.1項「asgctl資格証明の設定」を参照してください。
OracleAS Guardがトポロジを検出する場合（discover topologyコマンド）、Oracle Internet Directoryに問い合せて、その本番サイトのインスタンス情報を取得するためにOracle Internet Directory認証資格証明（Oracle Internet Directoryパスワード）を提供する必要があります。
コマンドdiscover topology within farmは、Oracle Internet Directoryを使用できない特別な場合に、本番サイトにあるOPMNを使用してトポロジを検出します。
using policy <file>パラメータで指定し、インスタンス別にこれらの各asgctlコマンドに許可される実行操作のドメインを定義します。XMLポリシー・ファイルの各インスタンスのリストのエントリは、本番とスタンバイのピア組合せと、正常な操作のための成功要件を定義する特定の属性を論理的に結び付けます。たとえば、前述の操作の1つを実行するときに、対称トポロジの1つのノードを省くことができます。ポリシー・ファイルを使用して、無視するノードを指定します。詳細は、第13.7項「いくつかのasgctlコマンドでのポリシー・ファイルのダンプとポリシー・ファイルの使用」を参照してください。
表13-4は、asgctlのクローン、インスタンス化、同期、フェイルオーバーおよびスイッチオーバー操作の前と後のOracleAS Disaster Recovery本番サイト環境とスタンバイ・サイト環境を示しています。
一般的なOracle Application Serverサイトには、複数のファームがあります。OracleAS Guardサーバーとそのias-component DSAプロセスは、障害時リカバリ・サイトのコンテキストでのみ必要であるため、デフォルトではOPMNによって起動されません。この項で後述するように、このias-component DSAプロセスをすべてのOracleホームで起動する必要があります。このコンポーネントのステータスをチェックし、コンポーネントが実行中であるかどうかを調べるには、トポロジ内の各システムで次のopmnctlコマンドを実行します。
UNIXシステムの場合:
> <ORACLE HOME>/opmn/bin/opmnctl status
Windowsシステムの場合:
> <ORACLE HOME>¥opmn¥bin¥opmnctl status
本番サイトのOracleAS GuardクライアントとOPMNは、スタンバイ・サイトのOracleAS Guardサービスを起動できないため、OracleAS Guardはスタンバイ・トポロジのInfrastructureノードでopmnctlを使用して直接起動する必要があります。ノードに接続し、UNIXシステム上で次のOPMNコマンドを実行します。
> <ORACLE HOME>/opmn/bin/opmnctl startproc ias-component=DSA
Windowsシステムでは、次のOPMNコマンドを発行してOracleAS Guardを起動します（OracleホームがドライブC:にある場合）。
C:¥<ORACLE HOME>¥opmn¥bin¥opmnctl startproc ias-component=DSA
OracleAS Guardサーバーを起動した後、そのサーバーは一時サーバーではなくなり、スタンバイ・トポロジ内の他のOracleAS Guardサーバーが一時サーバーになります。この構成によって、トポロジ間の通信が実現されます。
OracleAS 10gリリース2（10.1.2）の場合、OracleAS Guardは、Oracle Application Server Cold Failover Clusterとシングル・インスタンスのデフォルトのOracleAS Infrastructure構成だけでなく、第13.1.3項「サポートされているトポロジ」に示すトポロジもサポートします。
デフォルトでは、OracleAS Guardと、OracleAS Guardのコマンドライン・ユーティリティであるasgctlは、次のデフォルトの構成情報ですべてのインストール・タイプにインストールされます。
<ORACLE_HOME>¥dsa¥docディレクトリにあるOracleAS Guardのreadme.txtファイルを参照してください。
<ORACLE_HOME>/dsa/binディレクトリに、Windowsシステムの場合は、<ORACLE_HOME>¥dsa¥binディレクトリにインストールされます。
port=7890として設定されます。システムに2番目のOracleホームがインストールされている場合、この2番目のOracleホームは異なるOracleAS Guardポート番号を持つ必要があります。通常、そのポート番号はport=7891などのように1ずつ増加します。
ポート番号を変更する必要がある場合は（ポート番号は、マシン上の各Oracleホームの各OracleAS Guardサーバーに対して一意である必要があり、インストール時に自動的に割り当てられます）、その値を
注意
<ORACLE_HOME>/dsa/dsa.confファイルで変更することができます。変更したら、OracleAS Guardサーバーを停止してから（<ORACLE_HOME>/opmn/bin/opmnctl stopproc ias-component=DSA）、OracleAS Guardサーバーを再起動し（<ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA）変更内容を有効にします。詳細は、第13.4.5項「OracleAS GuardとOPMNとの統合」を参照してください。
exec_timeout_secs=60）。
OracleAS GuardクライアントがOracleAS Guardサーバーに接続し、本番トポロジ内または本番トポロジとスタンバイ・トポロジの両方で管理操作を実行するセッションを開始する場合は、次のようないくつかのレベルの認証が必要です。
OracleAS Guard管理セッションをインスタンス化する場合、OracleAS GuardクライアントとOracleAS Guardサーバーとの間の接続を確立した後、set primary databaseコマンドを使用してプライマリ・トポロジのすべてのOracleAS Infrastructureデータベースを識別する必要があります。Infrastructureの認証は、本番トポロジまたは本番トポロジとスタンバイ・トポロジの両方に関連する操作を開始する前に実行する必要があります。
別の形式のInfrastructureの認証は、フェイルオーバー操作の一部として実行されます。このシナリオでは、本番サイトは停止しており、スタンバイ・サイトにフェイルオーバーしてこのサイトを新しい本番サイトとする必要があります。最初に、フェイルオーバー操作を実行する前にset new primary databaseコマンドを使用してスタンバイ・トポロジの新しいOracleAS Infrastructureデータベースを識別します。詳細は、第13.10.1.2項「計画外停止」を参照してください。
デフォルトでは、これらは、Oracle Application Serverのインストール中に作成され、connect asgコマンドで使用されたOracle Application Serverアカウント（ias_admin/password）でのインスタンス・レベルの認証に使用されるものと同じ認証資格証明です。これらの同じ資格証明は、管理操作を実行する場合に本番トポロジとスタンバイ・トポロジのOracleAS GuardサーバーにOracleAS Guardクライアントが接続するときに使用されます。
特定のOracleAS Guardサーバーに対して異なる資格証明を使用したり、プライマリ・トポロジで使用する資格証明とは異なる一般的なセットの資格証明をスタンバイ・トポロジに設定する必要がある場合があります。OracleAS Guardサーバーに対して資格証明を設定するには、set asg credentialsコマンドと1つ以上のそのパラメータ・オプションを使用し、資格証明を適用するホスト名またはトポロジを新しいセットの資格証明（ユーザー名/パスワード）とともに指定します。
あるトポロジに資格証明を設定した場合、その資格証明はトポロジ全体に継承されます。トポロジ上の個別のホストに資格証明を設定した場合、そのホストの資格証明が、トポロジに設定されたデフォルトの資格証明よりも優先されます。ホスト・システムまたはトポロジ全体にデフォルトの接続資格証明とは異なる資格証明を設定すると、OracleAS Guard管理セッションを開始するたびに、本番トポロジ内または本番トポロジとスタンバイ・トポロジの両方のすべてのOracleAS Guardサーバーに関係する操作を実行する前に、ホスト・システムまたはトポロジのデフォルト接続情報とは異なるすべての資格証明を指定する必要があります。指定しない場合、操作は認証エラーのために失敗します。例は「connect asg」を参照してください。
discover topologyコマンドでは、Oracle Internet Directoryに問い合せて、その本番サイトのインスタンス情報を取得するためにOracle Internet Directory認証資格証明（Oracle Internet Directoryパスワード）を提供する必要があります。詳細およびdiscover topologyコマンドは、後述のセクションを参照してください。
discover topologyコマンドは、Oracle Internet Directoryに問い合せることによって、本番サイトの同じOracle Internet Directoryを共有する、トポロジ内のすべてのインスタンスを検出します。トポロジのすべてのインスタンスを記述するトポロジXMLファイルが作成され、トポロジ内のすべてのOracleホームに配布されます。このトポロジ・ファイルは、すべてのOracleAS Guard操作で使用されます。
トポロジXMLファイルを内部的に作成するために、OracleAS Disaster Recovery環境を最初に設定するとき、discover topologyコマンドを実行する必要があります。したがって、本番サイトに別のOracleホームを配置した場合や、スイッチオーバーまたはフェイルオーバー操作によって本番サイトからスタンバイ・サイトに役割を変更した場合は、常にトポロジの検出操作を実行する必要があります。詳細は、「discover topology」コマンドを参照してください。
トポロジを記述する情報を調べるには、dump topologyコマンドを実行する必要があります。詳細は、「dump topology」コマンドを参照してください。
プライマリ・トポロジが実行中であり、その構成が有効であることを確認するには、verify topologyコマンドを実行する必要があります。さらに、with hostパラメータを指定した場合、検証操作によって、ローカル・ホスト・システムがメンバーとなっているプライマリ・トポロジと、スタンバイ・トポロジが比較され、それらが相互に一致しており、OracleAS Disaster Recoveryの要件を満たしていることが確認されます。詳細は、第13.11.1項「トポロジの検証」および「verify topology」コマンドを参照してください。
dump topologyとverify topologyコマンドの両方で、ポリシー・ファイルを使用する場合は、ダンプおよび検証それぞれのポリシー・ファイル（dump_policy.xmlおよびverify_policy.xml）を編集して使用します。このファイルを各コマンドのusing policy <file>パラメータで指定し、それによって指定されたインスタンスのみをダンプまたは検証します。詳細は、第13.7項「いくつかのasgctlコマンドでのポリシー・ファイルのダンプとポリシー・ファイルの使用」を参照してください。
OracleAS Disaster Recoveryは、第13.1.3項「サポートされているトポロジ」に説明するように各種アプリケーション・サーバー・トポロジのサポートを提供しています。このサポートの一部として、一連のXMLフォーマットのポリシー・ファイルが、dump policiesコマンドを実行するOracleAS Guardクライアントにローカルに維持され、インスタンス別に、各asgctlコマンド（dump topology、verify topology、clone topology、failover、instantiate topology、switchover topologyおよびsync topology）に許可される実行操作のドメインが記録されます。
これらのasgctlコマンドに使用されているデフォルト・ポリシーを調べるには、asgctlプロンプトで次のコマンドを入力します。
ASGCTL> dump policies Generating default policy for this operation Creating policy files on local host in directory "/private1/OraHome2/asr1012/dsa/conf/" ASGCTL>
各XMLポリシー・ファイルの各インスタンスのリストのエントリは、デフォルトでは、本番とスタンバイのピア組合せと、各コマンドの正常な操作のための成功要件を定義する特定の属性を論理的に結び付けます。この方法によって、サポートされているトポロジでこれらの各OracleAS Guard操作を正常に使用する方法を柔軟に規定できます。詳細は、第13.1.3項「サポートされているトポロジ」を参照してください。
各XMLフォーマットのポリシー・ファイルを調べた後、それぞれのポリシー・ファイルを編集し、特定のasgctlコマンドのパラメータ構文using policy <file>にそれを使用することによって、使用するポリシー・ファイルの名前を指定できます。このようにして、この章ですでに説明したOracleAS Guardの操作ごとに、インスタンス別の成功要件の属性値を定義する特定の障害時リカバリ・ポリシーを使用できます。
成功要件の属性値は、次のいずれかです。[optional | mandatory | ignore | group <MinSucceeded=<number>>]それぞれの値の意味は次のとおりです。
Optional: そのインスタンスに障害がある場合、他のインスタンスの処理を続行します。
Mandatory: このインスタンスにエラーが発生した場合、操作全体が失敗することを意味します。
Ignore: インスタンスが操作の一部ではないことを意味します。
Group <MinSucceeded=<number>: Oracleインスタンスのグループを結合することを意味し、指定された数のグループ・メンバーが正常に処理された場合、操作は成功します。指定された数よりも正常に処理されたグループ・メンバーの数が少ない場合、操作は失敗します。
各属性値は、そのピア・グループの成功要件を決定し、asgctl操作に障害が発生した場合に参照され、OracleAS Guardの操作を続行するかどうかが決定されます。たとえば、成功要件が必須であると指定された場合、OracleAS Guardの特定の操作は、本番とスタンバイのピア組合せに指定されたインスタンスに対して正常に実行される必要があります。正常に実行されなかった場合は、OracleAS Guardのその操作が中止され、実行はその開始時点までロールバックされ、エラー・メッセージが返されます。
たとえば、フェイルオーバー操作の非対称トポロジに使用されている次のXMLポリシー・ファイルでは、このasgctl操作がinfraインスタンスには必須であり、portal_1インスタンスおよびportal_2インスタンスにはオプションであり、portal_3インスタンスには無視でき、3つのインスタンスBI_1、BI_2およびBI_3のグループのうち、少なくともいずれか2つに対しては正常に実行される必要があると指定しています。
<policy> <instanceList successRequirement="Mandatory"> <instance>infra</instance> </instanceList > <instanceList successRequirement="Optional"> <instance>portal_1</instance> <instance>portal_2</instance> </instanceList > <instanceList successRequirement="Ignore"> <instance>portal_3</instance> </instanceList > <instanceList successRequirement="Group" minSucceed="2"> <instance>BI_1</instance> <instance>BI_2</instance> <instance>BI_3</instance> </instanceList > </policy>
スタンバイ・サイト・クローニングとは、1つの本番インスタンスを1つのスタンバイ・システムにクローンするか（clone instanceコマンド）、2つ以上の本番インスタンスを複数のスタンバイ・システムにクローンする（clone topologyコマンド）プロセスです。
clone instanceコマンドを使用して、既存の本番インスタンス・ソースから新しいスタンバイ・インスタンス・ターゲットを作成します。
この操作を実行するためにOracleAS Guardが使用する基礎となるテクノロジの1つとして、ホストの破損に対するOracleASバックアップおよびリストア機能があります。前提条件のリストなどの詳細は、『Oracle Application Server管理者ガイド』の「ホストの破損の自動リカバリ」を参照してください。この機能は、ターゲット・マシンが新しく作成されたOracle環境であることを想定しています。これは、それがOracleソフトウェア・レジストリを上書きするためです。さらに、基礎となる操作のいくつかには、UNIX環境の場合はroot、およびWindowsの場合はAdministratorといった高い権限が必要です。Windowsでは、ユーザーは、クライアントとOracleAS GuardサーバーがAdministrator権限によって起動されていることを確認する必要があります。
クローンには次の2つのフェーズがあります。最初のフェーズは、Oracleホームを作成し、それをシステム環境内に登録することです。2番目のフェーズは、OracleAS Guardインスタンス化操作を実行し、それをOracleAS Disaster Recovery環境にリンクし、Oracleホームをそれに対応する本番ホームと論理的に一致させることです。
様々なインスタンスでの一連のインスタンスのクローン操作は、1つのトポロジのクローン操作と同等です。
clone topologyコマンドは、1つのグループのシステム全体にインスタンスのクローン操作を実行します。クローン操作は、データベースを含まないすべてのOracleASホームで実行され、ポリシー・ファイルを使用してフィルタできます。データベースを含むOracleASホームの場合、トポロジのクローン操作によって、操作のインスタンス化フェーズが実行され、スタンバイ・サイトでのOracleホームの作成をスキップできます。この操作は、ポリシー・ファイルを使用することによってトポロジのサブセットに実行できます。
OracleAS Disaster Recoveryのサイトの設定を計画する際には、次の3つの方法論を認識する必要があります。
各操作では、新しくインストールしたOracleホームを既存のサイトに統合したり、それらを本番サイトのスタンバイ・サイトに結合するための様々な方法が必要です。
OracleAS 10gリリース2（10.1.2.0.2）より前は、これがOracleAS Guardがサポートする唯一のタイプのサイトでした。OracleAS Disaster Recovery構成は、デフォルトのInfrastructureおよびOracleAS中間層のインストール・タイプに対してのみサポートされていました。このタイプの構成では、すべてのOracleASホームはOracleインストーラを使用して作成されました。OracleAS Guardのインスタンス化コマンドによって、本番およびスタンバイのOracleホームと基礎となっているスタンバイOracleデータベース・リポジトリとの間の関係が作成されます。
OracleASサイトでOracleAS Disaster Recoveryが有効化された後、本番OracleホームとスタンバイOracleホームとの間の関係が作成されます。OracleAS 10gリリース2（10.1.2.0.2）の場合、新しいしインスタンスをサイトに追加する唯一の方法は、スタンバイの関係を壊し、Oracle Installerを使用して本番サイトで新しいインスタンスを追加し、Oracle Installerを使用してその新しいインスタンスをスタンバイ・サイトに追加し、スタンバイ・サイトを再作成することでした。OracleAS 10gリリース2（10.1.2.0.2）では、clone instanceコマンドを使用してインスタンスをスタンバイ・サイトに追加できます。
たとえば、中間層のサービスを増やすために新しい中間層が必要な場合、新しいインスタンスを本番サイトにインストールします。この操作によって、そのインスタンスのOracleASホームが作成され、OracleASリポジトリ内に必要な関係が確立されます。
OracleAS 10gリリース2（10.1.2.0.2）のOracleAS Guardの非対称トポロジ・サポートでは、このOracleホームは、このサイトのOracleAS Disaster Recoveryソリューションについては無視することもできます。このインスタンスをスタンバイ・サイトに追加する場合は、clone topologyコマンドでスタンバイ・ターゲット・ホストにOracleAS Oracleホームを作成し、このインスタンスに対する本番とスタンバイの関係を確立します。このコマンドを発行する前に、OracleAS Guardのスタンドアロン・キットをターゲット・ホストにインストールして起動し（詳細は、Oracle Application Serverのインストレーション・ガイドのOracleAS Disaster Recoveryのインストール情報を参照）、サイトのトポロジ検出操作を実行して、本番トポロジの新しいインスタンスを検出する必要があります。
OracleASは、既存のデータベースにMetadata Repositoryスキーマを作成する機能をサポートしています。OracleAS Guardでは、これらのデータベースが認識および管理され、Metadata Repository構成データがサイトの残りの分散構成データと同期化されますが、スタンバイ・リポジトリも本番とスタンバイの関係も作成されません。この環境は、トポロジのクローン操作を使用してサポートします。
clone topologyコマンドを利用するには、最初にスタンドアロンOracleAS Guardサーバーを各スタンバイ・ホストにインストールして起動します。さらに、スタンドアロンOracleAS Guardのインストールによって作成されたOracleホームにOracleASのバックアップおよびリストア・ユーティリティをインストールします。前提条件のリストなどの詳細は、『Oracle Application Server管理者ガイド』の「ホストの破損の自動リカバリ」を参照してください。clone topologyコマンドによって、スタンバイ・サイトに中間層インスタンスOracleホームと構成情報が作成されます。Infrastructureインスタンスの場合は、暗黙的インスタンス化操作を実行して、OracleAS Disaster Recovery環境を初期化します。スタンバイ・ホストでは独立したOracleASのインストールがすでに実行されていると想定します。トポロジのクローニング操作は、プロファイル・ファイルを使用して、非対称トポロジのインスタンスをフィルタで除外できます。
クローン操作は、次のような状況で便利です。
これらのクローン操作を実行する手順は、次の項で説明します。
例として、1つの本番インスタンスをスタンバイ・ホスト・システムに追加するとします。インスタンスのクローン操作を使用すると、Oracleインスタンスをスタンバイ中間層システムにインストールしてからインスタンス化操作を実行するという作業を行わずに済みます。
クローニングする本番インスタンスは、スタンバイ・システムに存在してはなりません。
スタンバイ・サイト・システムにインスタンスのクローン操作を実行するための前提条件は次のとおりです。
sc.exe）をスタンバイ・システムにインストールする必要があります。
クローニングの基本手順は、次のクローニング前、クローニング中およびクローニング後の各手順から構成されています。
本番サイトとスタンバイ・サイトの各インスタンスで、次の手順を実行します。
UNIX システムの場合:
> <ORACLE HOME>/opmn/bin/opmnctl stopproc ias-component=DSA
Windowsシステムの場合:
C:¥<ORACLE HOME>¥opmn¥bin¥opmnctl stopproc ias-component=DSA
<ORACLE_HOME>/dsa/binのdsaServer.shをすべてのユーザーが実行できることを確認します。実行できない場合は、現在の実行権限を書き留めてから、次のコマンドを実行して実行権限を変更します。
chmod +x dsaServer.sh chmod u+x asgexec
>On UNIX systems from the <ORACLE_HOME>/dsa/bin directory > asgctl.sh startup On Windows systems fom the <ORACLE_HOME>¥dsa¥bin directory C:¥> asgctl startup
本番サイトのインスタンスで、次の手順を実行します。
> asgctl.sh Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg prodinfra ias_admin/adminpwd Successfully connected to prodinfra:7890 ASGCTL> set primary database sys/testpwd@asdb Checking connection to database asdb ASGCTL> clone instance portal_2 to asmid2 Generating default policy for this operation . . . ASGCTL> disconnect ASGCTL> exit >
本番サイトとスタンバイ・サイトのインスタンスで、次の手順を実行します。
>On UNIX systems from the <ORACLE_HOME>/dsa/bin directory > asgctl.sh shutdown On Windows systems fom the <ORACLE_HOME>¥dsa¥bin directory C:¥> asgctl shutdown
dsaServer.shの実行権限を、クローニング前の手順4で書き留めた権限に戻します。
UNIXシステムの場合:
> <ORACLE HOME>/opmn/bin/opmnctl startproc ias-component=DSA
Windowsシステムの場合:
C:¥<ORACLE HOME>¥opmn¥bin¥opmnctl startproc ias-component=DSA
最後の手順で、インスタンスのクローニング操作が完了し、操作を開始する前の状態にシステムが戻ります。この時点でasgctlを起動し、本番システムに接続し、トポロジを検出し、検証操作を実行して、本番トポロジとスタンバイ・トポロジが有効で、予期したとおりに両方のトポロジが一致しているかどうかを調べます。
例として、2つ以上の本番インスタンスをスタンバイ中間層ホスト・システムに追加するとします。トポロジのクローン操作を使用すると、Oracleインスタンスをスタンバイ中間層システムにインストールしてからインスタンス化操作を実行するという作業を行わずに済みます。
トポロジのクローン操作の一部として、本番インスタンスがクローンされ、OracleAS Metadata Repositoryがインスタンス化されます。ただし、OracleAS Metadata Repository Creation Assistantを使用して作成されたOracleAS Metadata Repository構成の場合、インスタンス化操作は実行されません。
クローニングする本番インスタンスは、スタンバイ・システムに存在してはなりません。
ポリシー・ファイルを使用する場合、クローン・ポリシー・ファイル（clone_policy.xml）を編集して使用します。このファイルをclone topologyコマンドのusing policy <file>パラメータで指定し、それによって指定されたインスタンスに対してのみスタンバイ・トポロジをクローンします。詳細は、第13.7項「いくつかのasgctlコマンドでのポリシー・ファイルのダンプとポリシー・ファイルの使用」を参照してください。
スタンバイ・サイト・システムにトポロジのクローン操作を実行するための前提条件は次のとおりです。
sc.exe）を各スタンバイ・システムにインストールする必要があります。
クローニングの基本手順は、次のクローニング前、クローニング中およびクローニング後の各手順から構成されています。
本番サイトとスタンバイ・サイトの各インスタンスで、次の手順を実行します。
UNIXシステムの場合:
> <ORACLE HOME>/opmn/bin/opmnctl stopproc ias-component=DSA
Windowsシステムの場合:
C:¥<ORACLE HOME>¥opmn¥bin¥opmnctl stopproc ias-component=DSA
<ORACLE_HOME>/dsa/binのdsaServer.shをすべてのユーザーが実行できることを確認します。実行できない場合は、現在の実行権限を書き留めてから、次のコマンドを実行して実行権限を変更します。
chmod +x dsaServer.sh chmod u+x asgexec
>On UNIX systems from the <ORACLE_HOME>/dsa/bin directory > asgctl.sh startup On Windows systems fom the <ORACLE_HOME>¥dsa¥bin directory C:¥> asgctl startup
本番サイトのインスタンスで、次の手順を実行します。
> asgctl.sh Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg prodinfra ias_admin/adminpwd Successfully connected to prodinfra:7890 ASGCTL> set primary database sys/testpwd@asdb Checking connection to database asdb ASGCTL> # Command to use if you are using a policy file where <file> # is the full path and file spec of the clone policy file. ASGCTL> clone topology to standbyinfra using policy <file> Generating default policy for this operation . . . ASGCTL> disconnect ASGCTL> exit >
本番サイトとスタンバイ・サイトの各インスタンスで、次の手順を実行します。
>On UNIX systems from the <ORACLE_HOME>/dsa/bin directory > asgctl.sh shutdown On Windows systems fom the <ORACLE_HOME>¥dsa¥bin directory C:¥> asgctl shutdown
dsaServer.shの実行権限を、クローニング前の手順4で書き留めた権限に戻します。
UNIXシステムの場合:
> <ORACLE HOME>/opmn/bin/opmnctl startproc ias-component=DSA
Windowsシステムの場合:
C:¥<ORACLE HOME>¥opmn¥bin¥opmnctl startproc ias-component=DSA
最後の手順で、トポロジのクローニング操作が完了し、操作を開始する前の状態にシステムが戻ります。この時点でasgctlを起動し、本番システムに接続し、トポロジを検出し、検証操作を実行して、本番トポロジとスタンバイ・トポロジが有効で、予期したとおりに両方のトポロジが一致しているかどうかを調べます。
次の条件を満たしている場合、Oracle Application Server Guardを使用して、スタンバイのインスタンス化とスタンバイの同期化を実行できます。
次の項目では、スタンバイのインスタンス化とスタンバイの同期化について説明します。
OracleAS Guardコマンドラインasgctlユーティリティのリファレンス情報は、第14章「OracleAS Guard asgctlコマンドライン・リファレンス」を参照してください。
スタンバイのインスタンス化操作では、スタンバイ・サイトで論理的な本番サイトのミラー化を設定し、維持するためのいくつかの操作を実行します。OracleAS Guardは、障害時リカバリの機能を実現するために、本番サイトとスタンバイ・サイト間での分散操作の調整に使用されます。設定操作は次のとおりです。
instantiate_policy.xml）を編集して使用します。このファイルをinstantiate topologyコマンドのusing policy <file>パラメータで指定し、それによって指定されたインスタンスに対してのみスタンバイ・トポロジをインスタンス化します。詳細は、第13.7項「いくつかのasgctlコマンドでのポリシー・ファイルのダンプとポリシー・ファイルの使用」を参照してください。
スタンバイのインスタンス化操作を実行する手順では、次の例を使用します。この例では、OracleAS Guardクライアントを起動して、discover topologyコマンドを実行してトポロジ・ファイルを作成してあると想定しています。
CFC環境にOracleAS Disaster Recovery構成があり、インスタンス化操作を実行しようとしている場合は、第14.2.1.1項「CFC環境でインスタンス化およびフェイルオーバー操作を実行するときの特別な考慮事項」を参照してください。
ASGCTL > connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
ASGCTL> set primary database sys/testpwd@asdb
verify_policy.xml）およびインスタンス化ポリシー・ファイル（instantiate_policy.xml）を編集して使用し、ファイル内に各インスタンスの成功要件の属性を指定します。詳細は、第13.7項「いくつかのasgctlコマンドでのポリシー・ファイルのダンプとポリシー・ファイルの使用」を参照してください。
ASGCTL> dump policies Generating default policy for this operation Creating policy files on local host in directory "/private1/OraHome2/asr1012/dsa/conf/"
standbyinfraが使用されています。
ASGCTL> verify topology with standbyinfra
standbyinfraが使用されています。このコマンドは、すべてのOracleホームがOracleインストーラ・ソフトウェアを使用してインストールされていると想定しています。using policy <file>パラメータを指定します。ここで<file>は、instantiate_policy.xmlファイルのパスとファイルの指定を表します。
ASGCTL> instantiate topology to standbyinfra using policy <file>
asgctl instantiate topologyコマンドを使用して、スタンバイのインスタンス化を実行するたびに、同期化操作も実行されます。したがって、インスタンス化操作の後、すぐに別の同期化操作を実行する必要はありません。インスタンス化操作の後に一定期間経過した場合は、プライマリ・サイトとスタンバイ・サイトが一致していることを確認します。その後、トポロジの同期化操作を実行し、プライマリ・サイトで行われたすべての変更がセカンダリ・サイトに適用されるようにします。
OracleAS Guardの同期化操作は、スタンバイ・サイトとプライマリ・サイトを同期化し、2つのサイトを論理的に一致させます。この操作は、次のような状況の場合に必要になります。
完全な同期化を指定することも増分の同期化を指定することもできます。デフォルトでは、増分の同期化が実行されます。これは最も高いパフォーマンスを提供します。ただし、次の3つの状況では、完全な同期化を指定する必要があります。
同期化操作の際に検証操作が実行されて、必要なOracleAS Disaster Recovery環境が維持されていることが確認されます。また、OracleASトポロジに新しいOracleASインスタンスをインストールした場合は、OracleAS Guardによってこれらのインストールが検出されます。
ポリシー・ファイルを使用する場合、同期化ポリシー・ファイル（sync_policy.xml）を編集して使用します。このファイルをsync topologyコマンドのusing policy <file>パラメータで指定し、それによって指定されたインスタンスに対してのみスタンバイ・トポロジを同期化します。詳細は、第13.7項「いくつかのasgctlコマンドでのポリシー・ファイルのダンプとポリシー・ファイルの使用」を参照してください。
次の例では、OracleAS Guardクライアントを起動して、discover topologyコマンドを実行してトポロジ・ファイルを作成してあると想定しています。
スタンバイの同期化を実行する手順は次のとおりです。
ASGCTL > connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
ASGCTL> set primary database sys/testpwd@asdb
ASGCTL> sync topology to standbyinfra
実行時操作には、スケジューリングした停止と計画外停止を含む停止の操作（第13.10.1項「停止」を参照）、asgctlコマンドライン・ユーティリティを使用した実行中のOracleAS Guard操作を監視する操作およびトラブルシューティング（第13.11項「OracleAS Guard操作の監視とトラブルシューティング」を参照）があります。
停止には、スケジューリングした停止と計画外停止の2つのカテゴリがあります。
次のサブセクションではこれらの停止について説明します。
スケジューリングした停止とは、計画停止のことです。この停止は、ビジネス・アプリケーションをサポートするテクノロジ・インフラストラクチャの定期的なメンテナンスのために必要で、この間に、ハードウェアのメンテナンスや修復とアップグレード、ソフトウェアのメンテナンスとパッチ適用、アプリケーションの変更とパッチ適用、およびシステムのパフォーマンスと管理機能強化を目的とした変更などのタスクが実行されます。スケジューリングした停止は、本番サイトまたはスタンバイ・サイトのどちらでも実行できます。次に、本番サイトまたはスタンバイ・サイトに影響を与えるスケジューリングした停止について説明します。
現行の本番環境があるサイト全体が使用できなくなります。サイトレベルのメンテナンスの例には、スケジューリングした停電、サイトのメンテナンス、定期的に計画されたスイッチオーバー操作などがあります。
これは、ハードウェア・メンテナンスのためにスケジューリングした、OracleAS Cold Failover Clusterの停止時間です。この停止時間は、ハードウェア・クラスタ全体に影響を与えます。クラスタレベルのメンテナンスの例には、クラスタ・インターコネクトの修復、クラスタ管理ソフトウェアのアップグレードなどがあります。
スケジューリングした停止では、次の項で説明するサイト・スイッチオーバー操作を実行する必要があります。
サイト・スイッチオーバーは、本番サイトの計画停止の際に実行されます。スイッチオーバー時には、本番サイトとスタンバイ・サイトの両方が使用可能である必要があります。データベースREDOログは、中間層およびOracleAS Infrastructureインストールの構成ファイルのバックアップおよびリストアと同時に適用されます。
サイト・スイッチオーバー時は、DNS情報が長時間キャッシュされないように配慮する必要があります。そのため、サイトのDNS情報の変更、具体的にはTime-To-Live（TTL）値の変更が必要です。手順は、第13.12.2項「DNS名の手動変更」を参照してください。
ポリシー・ファイルを使用する場合、スイッチオーバー・ポリシー・ファイル（switchover_policy.xml）を編集して使用します。このファイルをswitchover topologyコマンドのusing policy <file>パラメータで指定し、それによって指定されたインスタンスに対してのみスタンバイ・トポロジにスイッチオーバーします。詳細は、第13.7項「いくつかのasgctlコマンドでのポリシー・ファイルのダンプとポリシー・ファイルの使用」を参照してください。この例では、ポリシー・ファイルの使用例は示しません。
CFC環境にOracleAS Disaster Recovery構成があり、スイッチオーバー操作を計画している場合は、第14.2.1.3項「CFC環境でスイッチオーバー操作を実行するときの特別な考慮事項」を参照してください。
本番サイトからスタンバイ・サイトにスイッチオーバーする手順は次のとおりです。
prodinfra: -->ASG_DGA-13051: Error performing a physical standby switchover. prodinfra: -->ASG_DGA-13052: The primary database is not in the proper state to perform a switchover. State is "SESSIONS ACTIVE"
UNIXシステムの場合、次のようにしてApplication Server Controlを停止し（iasconsole）、emagentプロセスを停止します。
> <ORACLE_HOME>/bin/emctl stop iasconsole
UNIXシステムの場合、emagentプロセスが実行されていないかをチェックするために、次のコマンドを入力します。
> ps -ef | grep emagent
UNIXシステムの場合、iasconsoleの停止操作の後でemagentプロセスが依然として実行されている場合は、前のpsコマンドで示したようにプロセスID（PID）を取得し、次のようにしてemagentプロセスを停止します。
> kill -9 <emagent-pid>
Windowsシステムの場合、「サービス」コントロール パネルを開きます。OracleAS10gASControlサービスを見つけて、このサービスを停止します。
asgctl.shは<ORACLE_HOME>/dsa/binにあり、Windowsシステムでは、asgctl.batは<ORACLE_HOME>¥dsa¥binにあります。
> asgctl.sh Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg prodinfra ias_admin/<adminpwd>
using policy <file>パラメータを指定します。<file>は、switchover_policy.xmlファイルのパスとファイルの指定を表します。
ASGCTL> switchover topology to standbyinfra
ASGCTL> disconnect ASGCTL>
この項では、スイッチオーバー操作に関する次のような特別な考慮事項について説明します。
switchover_policy.xmlポリシー・ファイルを編集してノードをIgnoreに設定するだけでなく、このノードで実行中のすべてのプロセスを停止する必要があります。たとえば、プライマリ・サイトで実行されている2つのOracle Identity Managementインスタンスがim.machineA.us.oracle.comとim.machineB.us.oracle.comであり、もう1つのノード（im.machineB.us.oracle.com）がスイッチオーバー・サイトで無視される場合、スイッチオーバー操作が正常に実行されるためには、システム管理者はそのノード（im.machineB.us.oracle.com）上で実行されているすべてのプロセスを停止することも必要です。
本番サイトに影響を与える計画外停止は、そのサイトが使用不能になり、本番サイトがリストアされて妥当な期間内にサービスを提供する可能性がない場合に発生します。これには、火事、洪水、地震、停電などの本番サイトでのサイトレベルの停止があります。
計画外停止が発生した場合は、本番サイトからスタンバイ・サイトへのフェイルオーバー操作の実行が保証されます。
サイト・フェイルオーバー操作は、本番サイトの計画外停止の際に実行されます。フェイルオーバー操作では、構成データとInfrastructureデータを、一貫性のあった時点までリストアする必要があります。OracleAS Guardでは、最後にsync操作を行った時点から、一貫性のある方法でサイトのサービスが開始されます。フェイルオーバー操作によって、最後の同期化の時点までリストアされます。
ポリシー・ファイルを使用する場合、フェイルオーバー・ポリシー・ファイル（failover_policy.xml）を編集して使用します。このファイルをfailoverコマンドのusing policy <file>パラメータで指定し、それによって指定されたインスタンスのみがスタンバイ・トポロジにフェイルオーバーされるようにします。詳細は、第13.7項「いくつかのasgctlコマンドでのポリシー・ファイルのダンプとポリシー・ファイルの使用」を参照してください。
CFC環境にOracleAS Disaster Recovery構成があり、フェイルオーバー操作を実行しようとしている場合は、第14.2.1.1項「CFC環境でインスタンス化およびフェイルオーバー操作を実行するときの特別な考慮事項」を参照してください。
本番サイトからスタンバイ・サイトにフェイルオーバーする手順は次のとおりです。
ASGCTL> connect asg standbyinfra ias_admin/<adminpwd> Successfully connected to stanfbyinfra:7890
ASGCTL> set new primary database sys/testpwd@asdb
ASGCTL> failover
ASGCTL> discover topology oidpassword=oidpwd
OracleAS Disaster Recoveryソリューションを設定し、スタンバイ・トポロジをインスタンス化し、スタンバイ・トポロジを同期化したら、OracleAS Guardクライアントのコマンドライン・ユーティリティのasgctlを使用して、OracleAS Guard調整サーバーからasgctl操作の監視およびトラブルシューティング・タスクを実行するコマンドを発行できます。通常のOracleAS Guardの監視またはトラブルシューティング・セッションでは、次のようなタスクを実行します。
OracleAS Guardクライアントからasgctlコマンドを発行すると、OracleAS Guard調整サーバーにリクエストが送られます。OracleAS Guard調整サーバーはこのリクエストを本番トポロジとスタンバイ・トポロジのOracleAS Guardサーバーに転送します。その後、ステータス・メッセージがOracleAS Guardクライアントに返され、特定のタスクに問題が発生した場合はエラー・メッセージも返されます。エラー・メッセージの詳細は、第13.11.7項「エラー・メッセージ」を参照してください。
プライマリ・トポロジが実行状態にあり、構成が有効であることを確認するには、asgctlプロンプトで次のasgctlコマンドを入力します。
ASGCTL> connect asg ias_admin/iastest2
Successfully connected to prodinfra:7890
ASGCTL> discover topology oidpassword=oidpwd
ASGCTL> verify topology
Generating default policy for this operation
prodinfra:7890
HA directory exists for instance asr1012.infra.us.oracle.com
asmid2:7890
HA directory exists for instance asmid2.asmid2.us.oracle.com
asmid1:7890
HA directory exists for instance asmid1.asmid1.us.oracle.com
ASGCTL>
ポリシー・ファイルを使用する場合は、検証ポリシー・ファイル（verify_policy.xml）を編集して使用し、ファイル内に各インスタンスの成功要件の属性を指定します。verifyコマンドにusing policy <file>パラメータを指定します。ここで<file>は、verify_policy.xmlファイルのパスとファイルの指定を表します。詳細は、第13.7項「いくつかのasgctlコマンドでのポリシー・ファイルのダンプとポリシー・ファイルの使用」を参照してください。
ローカル・ホストがメンバーであるプライマリ・トポロジとスタンバイ・トポロジを比較して、両方のトポロジが一致していること、および両方のトポロジがOracleAS Disaster Recoveryの要件を満たしていることを確認するには、asgctlプロンプトで次のasgctlコマンドを入力して、スタンバイ・ホスト・システムの名前を指定します。
ASGCTL> dump policies Generating default policy for this operation Creating policy files on local host in directory "/private1/OraHome2/asr1012/dsa/conf/"
ASGCTL> verify topology with standbyinfra
Generating default policy for this operation
prodinfra:7890
HA directory exists for instance asr1012.infra.us.oracle.com
asmid2:7890
HA directory exists for instance asmid2.asmid2.us.oracle.com
asmid1:7890
HA directory exists for instance asmid1.asmid1.us.oracle.com
standbyinfra:7890
HA directory exists for instance asr1012.infra.us.oracle.com
asmid2:7890
HA directory exists for instance asmid2.asmid2.us.oracle.com
asmid1:7890
HA directory exists for instance asmid1.asmid1.us.oracle.com
prodinfra:7890
Verifying that the topology is symmetrical in both primary and standby configuration
ASGCTL>
# Command to use if you want to use a policy file # verify topology with standbyinfra using policy <file>
OracleAS Guardクライアントが接続しているトポロジのすべてのノードで、現在実行されているすべての操作のステータスを表示するには、asgctlプロンプトで次のasgctlコマンドを入力します。
ASGCTL> show operation ************************************* OPERATION: 19 Status: running Elapsed Time: 0 days, 0 hours, 0 minutes, 28 secs TASK: syncFarm TASK: backupFarm TASK: fileCopyRemote TASK: fileCopyRemote TASK: restoreFarm TASK: fileCopyLocal
完了した操作（現行セッションでOracleAS Guardクライアントが接続されているトポロジのノード上で実行されていない操作）のみを表示するには、asgctlプロンプトで次のasgctlコマンドを入力します。
ASGCTL> show operation history ************************************* OPERATION: 7 Status: success Elapsed Time: 0 days, 0 hours, 0 minutes, 0 secs TASK: getTopology TASK: getInstance ************************************* OPERATION: 16 Status: success Elapsed Time: 0 days, 0 hours, 0 minutes, 0 secs TASK: getTopology TASK: getInstance ************************************* OPERATION: 19 Status: success Elapsed Time: 0 days, 0 hours, 1 minutes, 55 secs TASK: syncFarm TASK: backupFarm TASK: fileCopyRemote TASK: fileCopyRemote TASK: restoreFarm TASK: fileCopyLocall
サーバーで実行されている特定の操作を停止するには、asgctlプロンプトで次のasgctlコマンドを入力し、停止する操作番号を指定します。停止する操作番号は、asgctl show operation fullコマンドを入力すると表示されます。
ASGCTL> show operation full ************************************* OPERATION: 19 Status: running Elapsed Time: 0 days, 0 hours, 0 minutes, 28 secs Status: running . . . ASGCTL> stop operation 19
特定のイベントにトレース・フラグを設定し、出力をasgctlログ・ファイルに記録するには、asgctlプロンプトで次のasgctlコマンドを入力し、onキーワードを指定して、有効にするトレース・フラグを入力します。この場合、トレース・フラグDBは、Oracle Database環境の処理に関するトレース情報が表示されることを示します。有効にすることができるその他のトレース・フラグの詳細は、「set trace」コマンドを参照してください。設定できるすべてのトレース・フラグの一覧も、「set trace」コマンドを参照してください。
ASGCTL> set trace on db
ローカル・ホストが接続されているトポロジに関する詳細情報を書き込むには、asgctlプロンプトで次のasgctlコマンドを入力し、出力される情報を書き込むファイルのパスと名前を指定します。この出力では、dump topologyコマンドを実行した場合と同じ結果が表示されますが、この場合はファイルに書き込まれるので、将来参照するために保存しておくことが可能です。
ASGCTL> dump topology to c:¥dump_mid_1.txt
OracleAS Disaster Recoveryソリューションの実行時に表示されるエラー・メッセージは、付録C「OracleAS Guardエラー・メッセージ」に分類して説明しています。
クライアント・リクエストが本番サイトのエントリ・ポイントに送信されるようにするには、DNS解決を使用します。サイトのスイッチオーバーまたはフェイルオーバーが実行される際には、クライアント・リクエストが本番の役割を果たす新しいサイトに透過的にリダイレクトされる必要があります。このリダイレクションを可能にするには、本番サイトへのリクエストを解決するワイド・エリアDNSをスタンバイ・サイトにスイッチオーバーする必要があります。DNSスイッチオーバーは、ワイド・エリア・ロード・バランサを使用するか手動でDNS名を変更することによって行えます。
次のサブセクションではDNSスイッチオーバー操作について説明します。
ワイド・エリア・ロード・バランサ（グローバル・トラフィック・マネージャ）が本番サイトとスタンバイ・サイトの前面に配置されているときは、両サイトに対して、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。さらに、このロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。
通常の運用時は、本番サイトのロード・バランサの名前とIPの対応付けにより、ワイド・エリア・ロード・バランサを構成できます。DNSスイッチオーバーが必要な際には、ワイド・エリア・ロード・バランサのこの対応付けが変更され、スタンバイ・サイトのロード・バランサのIPに対応付けられます。これにより、本番の役割を引き継いだスタンバイ・サイトにリクエストが転送されるようになります。
DNSスイッチオーバーのこの方法は、サイトのスイッチオーバーとフェイルオーバーの両方に対応できます。ワイド・エリア・ロード・バランサを使用する利点の1つは、名前とIPの新しい対応付けがすぐに有効になるという点です。不利な点は、ワイド・エリア・ロード・バランサへの追加投資が必要になることです。
DNSスイッチオーバーのこの方法には、元は本番サイトのロード・バランサのIPアドレスに対応付けられていた名前とIPの対応付けを手動で変更することが関係しています。この対応付けを変更して、スタンバイ・サイトのロード・バランサのIPアドレスに対応付けます。スイッチオーバーを実行する手順は次のとおりです。
DNSスイッチオーバーのこの方法は、計画的なサイトのスイッチオーバー操作にのみ対応できます。手順2のTTL値は、クライアント・リクエストを処理しきれない時間に設定する必要があります。TTLの変更とは、実質的にはアドレス解決時間を短縮させるためにキャッシュ・セマンティックを変更することを表しているからです。そのため、キャッシュ時間が短縮されたことにより、DNSリクエストが増加する可能性があります。
この項は、次のサブセクションで構成されています。
asgctlを使用した一般的なOracleAS Guardセッションには、次のようなタスクがあります。これらのタスクについては、次のサブセクションで説明します。
asgctlコマンドライン・インタフェースがサポートされている利点の1つは、これらのasgctlコマンドを、第13.13.1.4項「asgctlスクリプトの作成と実行」の説明に従って適切な順序でスクリプトに入力し、第13.13.2項「OracleAS Guard asgctlスクリプトの定期的なスケジュール」および第13.13.3項「Enterprise Manager Job Systemを使用したOracleAS Guardジョブの実行」に従ってスクリプトとして実行できることです。
特定のコマンドのヘルプを表示するには、asgctlプロンプトにasgctlコマンドを入力し、ヘルプ情報を表示するコマンド名を指定します。また、すべてのコマンドのヘルプを表示するには、asgctlプロンプトで次のasgctlコマンドを入力します。
ASGCTL> help
connect asg [<host>] [ias_admin/<password>]
disconnect
exit
quit
clone topology to <standby_topology_host> [using policy <file>]
clone instance <instance> to <standby_topology_host>
discover topology [oidhost=<host>] [oidsslport=<sslport>] [oiduser=<user>] oidpassword=<pass>
discover topology within farm
dump farm [to <file>] (Deprecated)
dump topology [to <file>] [using policy <file>]
dump policies
failover [using policy <file>]
help [<command>]
instantiate farm to <standby_farm_host> (Deprecated)
instantiate topology to <standby_topology_host> [using policy <file>]
set asg credentials <host> ias_admin/<password> [for topology]
set asg credentials <host> ias_admin/<password> [for farm] (Deprecated)
set primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
set new primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
set noprompt
set trace on|off <traceflags>
sync farm to <standby_farm_host> [full | incr[emental]] (Deprecated)
sync topology to <standby_topology_host> [full | incr[emental]] [using policy <file>]
startup
startup farm (Deprecated)
startup topology
shutdown [local]
shutdown farm (Deprecated)
shutdown topology
show op[eration] [full] [[his]tory]
show env
stop op[eration] <op#>
switchover farm to <standby_farm_host> (Deprecated)
switchover topology to <standby_topology_host> [using policy <file>]
verify farm [with <host>](Deprecated)
verify topology [with <host>] [using policy <file>]
ASGCTL>
プライマリ・トポロジのOracleAS Infrastructureデータベースを指定するには、asgctlプロンプトで次のasgctlコマンドを入力し、OracleAS Infrastructureデータベースにアクセスするsysdba権限があるデータベース・アカウントのユーザー名とパスワード、およびOracleAS InfrastructureデータベースのTNSサービス名を指定します。
ASGCTL> set primary database sys/testpwd@asdb Checking connection to database asdb ASGCTL>
スタンバイ・サイトの場合も、プライマリ・データベースで指定する値と同じ値を使用します。これは、プライマリとスタンバイのOracleAS Infrastructureデータベースのサービス名とパスワードを同じにする必要があるためです。プライマリ・データベースは、インスタンス化、同期化、スイッチオーバーまたはフェイルオーバー操作を実行する前に設定する必要があります。
トポロジにOracleAS Metadata Repositoryが複数ある場合は、set primary databaseコマンドを使用して、それぞれを認証する必要があります。
トポロジXMLファイルを内部的に作成するために、OracleAS Disaster Recovery環境を最初に設定するとき、discover topologyコマンドを実行する必要があります。したがって、本番サイトに別のOracleホームを配置した場合や、スイッチオーバーまたはフェイルオーバー操作によって本番サイトからスタンバイ・サイトに役割を変更した場合は、常にトポロジの検出操作を実行する必要があります。discover topologyコマンドは、Oracle Internet Directoryに、本番サイトの同じOracle Internet Directoryを共有する、トポロジ内のすべてのインスタンスについて問い合せます。asgctlプロンプトで次のasgctlコマンドを入力し、トポロジを検出します。
ASGCTL> discover topology oidpassword=oidpwd Discovering topology on host "infra" with IP address "123.1.2.111" prodinfra:7890 Connecting to the OID server on host "infra.us.oracle.com" using SSL port "636" and username "orcladmin" Getting the list of databases from OID Gathering database information for SID "asdb" from host "infra.us.oracle.com" Getting the list of instances from OID Gathering instance information for "asr1012.infra.us.oracle.com" from host "infra.us.oracle.com" Gathering instance information for "asmid1.asmid1.us.oracle.com" from host "asmid1.us.oracle.com" Gathering instance information for "asmid2.asmid2.us.oracle.com" from host "asmid2.us.oracle.com" The topology has been discovered. A topology.xml file has been written to each home in the topology. ASGCTL>
本番トポロジが本番サイトのOracleAS Guardに認識された後、後続のコマンドのいずれかを実行し、スタンバイ・サイトに関連する後続のasgctl操作を実行できます。詳細は、discover topologyを参照してください。
一連のasgctlコマンド名と引数を含むスクリプトを作成するには、適当なエディタを開いて、実行する操作に応じた正しい順序でasgctlコマンドを入力します。スクリプト・ファイルを保存し、asgctlを起動するときに次のようにスクリプトを実行します。
> ASGCTL @myasgctlscript.txt
一連のasgctlコマンドを指定したスクリプトの例は、「set echo」コマンドを参照してください。
asgctlスクリプトのコマンドの実行に使用するために、後ですべての対話型プロンプトが無視される非プロンプト状態を設定できます。詳細は、asgctlの「set noprompt」コマンドを参照してください。
定期的なトポロジの同期化操作を実行してスタンバイ・トポロジとプライマリ・トポロジの同期化を維持するなど、OracleAS Guard操作を定期的に実行するために、OracleAS Guardのasgctlスクリプトの定期的な実行を自動化できます。
UNIXシステムの場合は、cronジョブを設定してasgctlスクリプトを実行できます。asgctlスクリプトを/etcの下の適切なサブディレクトリ、cron.hourly、cron.daily、cron.weeklyまたはcron.monthlyにコピーします。スクリプトのコピー先に選択したディレクトリの名前に応じて、スクリプトは時間、日、週または月単位で実行されます。または、crontabを編集して、asgctlスクリプトを実行する時間を指定したエントリを作成することもできます。詳細は、cronおよびcrontabに関するマニュアルのページを参照してください。
Windowsシステムの場合は、「コントロール パネル」のタスク・スケジューラまたはスケジュールされたタスクを使用して、asgctlスクリプトを毎日、毎週、または毎月実行したり、特定の時間に実行したりできます。また、様々なオプションの付いたサード・パーティ製のスケジューラ・ソフトウェアを購入して、asgctlスクリプトを実行する時間や頻度を設定することもできます。詳細は、Windowsオペレーティング・システムのヘルプを参照してください。
Enterprise Manager Job Systemを使用して、asgctlスクリプトを特定の時間間隔または特定の日時（あるいはその両方）に実行するように自動化したり、さらに別のカスタム設定に設定したりすることができます。その場合は、Enterprise Managerの「ジョブ・アクティビティ」ページにアクセスして、asgctlスクリプトを実行するユーザー自身のホスト・コマンド・ジョブ、つまりジョブ・タスクを作成します。ジョブ・タスク（スクリプト）はasgctlを起動し、指定された順序に従ってasgctlコマンドを実行します。OracleAS Guardジョブを作成したら、EMジョブ・ライブラリに保存します。このライブラリは、頻繁に使用されるジョブのリポジトリであり、ここで、カスタム設定と選択した時間に従ってジョブが実行されます。詳細は、Enterprise Managerのオンライン・ヘルプ、および『Oracle Enterprise Manager概要』を参照してください。
この項では、OracleAS Metadata Repository Creation Assistantを使用して作成した複数のOracleAS Metadata RepositoryとOracleAS Metadata Repositoryの特別な考慮事項について説明します。
デフォルトでは、asgctl connectコマンドで指定した資格証明は、OracleAS Guardサーバーが他のOracleAS Guardサーバーに接続する際に必ず使用されます。しかし、次のような使い方が必要になる場合もあります。
ホスト・システムの資格証明がasgctl connectコマンドで使用されているものと異なる場合は、OracleAS Guardサーバーが構成内の各ホスト・システムに接続できるように、OracleAS Guard資格証明を設定する必要があります。
同じトポロジに属する、すべてのホスト・システムに異なる資格証明を設定するには、asgctlプロンプトに次のasgctlコマンドを入力します。資格証明が適用されるホスト・システムのノード名、Oracle Application Serverのインストール時に作成したias_adminアカウント名とias_adminアカウントのパスワード、およびキーワードのfor topologyを指定します。これらの設定は、現行セッションに有効です。
ASGCTL> set asg credentials standbyinfra ias_admin/<iasadminpwd> for topology
キーワードのfor topologyを指定した場合は、資格証明は、指定したシステムと同じトポロジに属するすべてのホスト・システムに設定されます。キーワードを指定しない場合、資格証明は指定したホスト・システムにのみ適用されます。
set asg credentialsコマンドは、トポロジ内の特定のサーバーに異なる資格証明を適用する場合にも使用できます。前述の例では、スタンバイ・トポロジ内のすべてのノードに同じ資格証明を適用し、プライマリ・トポロジに使用する資格証明とは異なる資格証明を設定しました。次のコマンドでは、スタンバイ・トポロジ内の特定のノードであるstandbyinfraノードに、資格証明を設定します。
ASGCTL> set asg credentials standbyinfra ias_admin/<iasadminpwd>
つまり、あるトポロジに資格証明を設定した場合、この資格証明はトポロジ全体に継承されます。トポロジ上の個別のホストに資格証明を設定した場合、（そのホストの）資格証明が、トポロジに設定されたデフォルトの資格証明よりも優先されます。
また、Oracle Internet DirectoryとOracleAS Metadata Repositoryが同じ場所にあって、PortalのOracleAS Metadata Repositoryが別の場所にあるような、複数のInfrastructureが存在するトポロジでは、OracleAS Guardでインスタンス化、同期化、スイッチオーバー、フェイルオーバーなどの重要な操作を実行する前に、各システムの資格証明をInfrastructureが存在するノードで設定する必要があります。例は、set asg credentialsを参照してください。
プライマリ・トポロジ内のOracleAS Infrastructureデータベースを指定するには、asgctlプロンプトに次のasgctlコマンドを入力します。プライマリ・トポロジ内のOracleAS Infrastructureデータベースにアクセスするsysdba権限のあるデータベース・アカウントのユーザー名とパスワードを指定し、OracleAS InfrastructureデータベースのTNSサービス名を指定します。
ASGCTL> set primary database sys/testpwd@asdb Checking connection to database asdb ASGCTL>
スタンバイ・サイトの場合も、プライマリ・データベースで指定する値と同じ値を使用します。これは、プライマリとスタンバイのOracleAS Infrastructureデータベースのサービス名とパスワードが必ず同じであるためです。
本番サイトまたはスタンバイ・サイトに複数のOracleAS Metadata Repositoryインスタンスがインストールされており、インスタンス化、同期化、スイッチオーバーまたはフェイルオーバー操作を実行する場合、それらの操作を実行する前に、各OracleAS Metadata Repositoryインスタンスに対してset primary databaseコマンドを実行することによって、OracleAS Metadata Repositoryインスタンスすべてを識別する必要があります。例は、set asg credentialsを参照してください。
OracleAS Guardは、デフォルトのポート（port）番号である7890を使用します。たとえば、port=7890として設定されます。システムに追加のOracleホームがインストールされている場合、各Oracleホームは一意のOracleAS Guardポート番号を持つ必要があります。その番号は、通常はport=7891などのように1ずつ増加します。詳細は、第13.4.6項「サポートされるOracleAS Disaster Recovery構成」を参照してください。
次の項目は、OracleAS Metadata Repository Creation Assistantを使用して作成したOracleAS Metadata Repository構成の特別な考慮事項です。これらのメタデータ・リポジトリ・データベースは、ユーザー・データを含むスキーマとともにOracleホームにインストールされます。この理由により、OracleAS Disaster Recoveryに関するいくつかの特別な考慮事項があります。
次の項では、OracleAS Disaster Recovery環境のいくつかの追加の特別な考慮事項について説明します。
サイトにOracleAS Disaster Recoveryを設定する際に注意する必要がある特別な考慮事項は次のとおりです。
どちらの場合も、Oracle Internet Directoryに格納されているインスタンス名は、本番サイトのインストールが実行された元のホスト名で構成されます。OracleAS Disaster Recoveryサイトに対称トポロジがある場合、OracleAS Disaster Recoveryのスタンバイ・ピアは、本番サイトと同じようにインストールする必要があり、OracleAS Guard 10gリリース2（10.2.0.2）のインスタンスのクローニング操作またはトポロジのクローニング操作の場合、操作は構成をミラー化するように実行する必要があります。
スタンバイが非対称トポロジで、本番サイトの物理ホストがスタンバイ・サイトに存在しない場合、ポリシー・ファイル機能を使用して、そのインスタンス名をトポロジからフィルタで除外する必要があります（詳細は第13.7項「いくつかのasgctlコマンドでのポリシー・ファイルのダンプとポリシー・ファイルの使用」を参照）。トポロジの検出操作を実行するホストのホスト・ファイルは、元のホスト名を、クローンされた新しいホスト・システムの対応するIPに対応付けしている必要があります。
OracleAS Guard操作で、スタンバイ・サイトの構成ファイルが、プライマリ・サイトのバックアップ操作によって本番サイトの構成ファイルと同期化され、スタンバイ・サイトにリストアされます。
非対称トポロジの場合、スタンバイ・サイトは本番サイトよりノードの数が少なく、ons.conf構成ファイルのノード名リストは、本番サイトのノード名リストと異なります。したがって、ons.conf構成ファイルは、ファイルのバックアップ・リストから除外し、スタンバイ・サイトにリストアされないようにします。除外しない場合、ons.conf構成ファイルにリストされているノードは、本番サイトのノード・リストを反映し、スタンバイ・サイトの実際のノード・リストは反映しなくなります。これによって、存在しないノードにOPMNがpingを実行し続けるという非効率が発生します。
さらに、非対称トポロジの場合、Oracleホームのdsa.conf構成ファイルには、スタンバイ・サイトとは異なる特別な設定が本番サイトに含まれていることもあります。たとえば、inventory_locationパラメータ設定は、スタンバイ・サイトとプライマリ・サイトでは異なることがあります。この場合、dsa.conf構成ファイルも、ファイルのバックアップ・リストから除外し、スタンバイ・サイトにリストアされないようにします。除外しない場合、この例では、スイッチオーバーまたはフェイルオーバー操作の後のOraInventoryの場所はスタンバイ・サイトでは正しくありません。
どちらの場合も、次のようにバックアップおよびリストアの除外ファイルを変更し、これらのどちらの構成ファイルも、ファイルのバックアップ・リストから除外し、どちらもスタンバイ・サイトにリストアされないようにします。
# Exclude Files # - Add additional files to this list that you want to be ignored # - during the configuration file backup/restore c:¥oracle¥ias1012¥opmn¥conf¥ons.conf c:¥oracle¥ias1012¥dsa¥dsa.conf
dsa.confファイルで設定されたディレクティブが、現在、本番サイトとして動作しているサイトで必要な場合は、同期化にdsa.confファイルも含め、スイッチオーバーまたはフェイルオーバー後の手順を追加して、物理サイト固有のディレクティブを編集したほうがよいこともあります。
いくつかの追加の特別な考慮事項の詳細は、第14.2項「OracleAS Guardコマンドの一部に特有の情報」を参照してください。
|
 Copyright © 2005, 2007 Oracle. All Rights Reserved. |
|