10gリリース2（10.1.2）for Solaris Operating System（SPARC）
B15826-04
 目次 |
 索引 |
| Oracle Application Server インストレーション・ガイド 10gリリース2（10.1.2）for Solaris Operating System（SPARC） B15826-04 |
|
この章では、OracleAS Disaster Recovery構成にOracle Application Serverをインストールする方法について説明します。OracleAS Disaster Recoveryは、Oracle Application Serverでサポートされている高可用性環境の1つです。
この章の内容は次のとおりです。
使用している環境に2つの物理的に分離したサイトが必要な場合は、OracleAS Disaster Recovery環境を使用します。1つは本番サイトであり、もう1つはスタンバイ・サイトです。本番サイトがアクティブの間、スタンバイ・サイトはパッシブです。本番サイトが停止すると、スタンバイ・サイトがアクティブになります。
OracleAS Disaster Recoveryでは、本番およびスタンバイ・サイトでInfrastructureおよび中間層の構成に使用できる、多数の基本トポロジをサポートしています。OracleAS Disaster Recoveryがサポートする基本トポロジは次のとおりです。
対称トポロジでは、スタンバイ・サイトの各ノードは本番サイトのノードに対応しています。この中には、OracleAS Infrastructureおよび中間層の両方を実行しているノードも含まれます。非対称トポロジのスタンバイ・サイトに必要なインスタンスの数は、本番サイトよりも少なく、スイッチオーバーまたはフェイルオーバー操作時のサイトの運用に最低限必要な数です。
OracleAS Cold Failover Cluster環境の本番サイトにOracleAS Infrastructureを設定し、この環境を少し変更できます。詳細は、第13.2.4項「本番サイトでOracleAS Cold Failover Clusterを使用する場合」を参照してください。
これらのサポートされているトポロジでは、OracleAS Disaster Recoveryソリューションとして構成された本番およびスタンバイ・トポロジ内のすべてのシステムのOracleホームに、OracleAS Guardがインストールされます。
OracleAS Guardは、OracleAS Companion CD 2に入っており、スタンドアロン・インストール・キットとしてインストールできます。このスタンドアロン・キットのインストールのタイミングについては、第13.4項「OracleホームへのOracleAS 10g（10.1.2.0.2）のOracleAS Guardスタンドアロン・インストール」を参照してください。
図13-1に、対称型のOracleAS Disaster Recovery環境の例を示します。各サイトには、中間層を実行するノードが2つとOracleAS Infrastructureを実行するノードが1つあります。
OracleAS Disaster Recoveryを機能させるには、フェイルオーバーが即座に実行されるように本番サイトとスタンバイ・サイトのデータを同期化する必要があります。本番サイトで行った構成の変更は、スタンバイ・サイトにも反映させる必要があります。
2つのタイプのデータを同期化する必要があります。同期化の方法は、データのタイプによって異なります。
Oracle Data Guard、およびバックアップおよびリカバリ・スクリプトの使用方法の詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
OracleAS Disaster Recovery環境内にOracle Application Serverをインストールする前に、次の手順を実行する必要があります。
次の条件についてノードが同じであることを確認します。
同じコンポーネントでは、本番サイトでもスタンバイ・サイトでも同じポート番号を使用する必要があります。たとえば、Oracle HTTP Serverが本番サイトでポート80を使用している場合は、スタンバイ・サイトでもポート80を使用する必要があります。これを確実にするためには、インストール時に使用するstaticports.iniファイルを作成します。このファイルで各コンポーネントのポート番号を指定できます。詳細は、第4.6.3項「カスタムのポート番号の使用（「静的ポート」機能）」を参照してください。
サイト間でデータを同期化するときにデータを編集してホスト名を修正する必要がないように、本番サイトおよびスタンバイ・サイトの対応するノードの名前は同じである必要があります。
インフラストラクチャを実行するノードの場合、仮想名を設定します。これを行うには、/etc/hostsファイルにノードの別名を指定します。
たとえば、本番サイトのインフラストラクチャ・ノードでは、hostsファイル内の次の行は別名をasinfraに設定します。
138.1.2.111 prodinfra asinfra
スタンバイ・サイトでは、次の行はノードの別名をasinfraに設定します。
213.2.2.110 standbyinfra asinfra
本番サイトおよびスタンバイ・サイトにOracleAS Infrastructureをインストールする場合は、「仮想ホストの指定」画面でこの別名（asinfra）を指定します。構成データには、インフラストラクチャ・ノード用のこの別名が含まれます。
中間層を実行するノードの場合、中間層のインストール時にインストーラによって「仮想ホストの指定」画面が表示されないため、インフラストラクチャ・ノードの場合のように別名を指定できません。中間層のインストールでは、インストーラによってgethostname()関数がコールされ、自動的にホスト名が確認されます。本番サイトの各中間層ノードに対して、スタンバイ・サイトの対応するノードが同じホスト名を戻すようにする必要があります。
これを行うには、ローカルまたは内部のホスト名を設定します。このホスト名はパブリックまたは外部のホスト名と同じである必要はありません。スタンバイ・サイトのノードの名前を本番サイトの対応するノードの名前にあわせて変更するか、本番サイトとスタンバイ・サイトの両方のノードの名前が同じになるように変更できます。どちらの方法を使用するかは、ノード上で実行されている他のアプリケーション、およびノード名の変更によってこれらのアプリケーションが影響を受けるかどうかによって決定します。
/etc/nodenameファイルを編集して新しいローカルの完全修飾名を指定します。次に、名前をiasmid1.oracle.comに設定する例を示します。（図13-1の例では、この名前を使用しています。）
iasmid1.oracle.com
方法1: 本番サイトとスタンバイ・サイトに異なる内部DNSサーバーを設定します。この構成によって、各サイト（本番またはスタンバイ）のノードがサイト内でホスト名を解決できるようになります。内部DNSサーバーの上には、企業、つまり外部のDNSサーバーがあります。内部DNSサーバーは、信頼できないリクエストは外部DNSサーバーへ転送します。外部DNSサーバーは、内部DNSサーバーの存在を知りません。詳細は、図13-2を参照してください。
方法1の詳細
prodmid1.us.oracle.com IN A 138.1.2.333 prodmid2.us.oracle.com IN A 138.1.2.444 prodinf.us.oracle.com IN A 138.1.2.111 standbymid1.us.oracle.com IN A 213.2.2.330 standbymid2.us.oracle.com IN A 213.2.2.331 standbyinf.us.oracle.com IN A 213.2.2.110
インフラストラクチャ・ノードの場合、仮想名または別名を使用します。
中間層ノードの場合、ノード名（/etc/nodename内の値）を使用します。
次の例では、新しいゾーンのドメイン名として「asha」を使用します。
asmid1.asha IN A 138.1.2.333 asmid2.asha IN A 138.1.2.444 asinfra.asha IN A 138.1.2.111
スタンバイ・サイトに対しても同じことを行います。本番サイトに使用したドメイン名を使用します。
asmid1.asha IN A 213.2.2.330 asmid1.asha IN A 213.2.2.331 asinfra.asha IN A 213.2.2.110
本番サイトの各ノードの/etc/resolv.confファイル内で、既存のネーム・サーバーのIPアドレスを、本番サイトの内部DNSサーバーのIPアドレスに変更します。
スタンバイ・サイトのノードに対しても同じ手順を実行します。ただし、スタンバイ・サイト用の内部DNSサーバーのIPアドレスを使用します。
次の例では、「remote_infra」エントリはスタンバイ・サイトのインフラストラクチャ・ノードを示します。この名前は、スイッチオーバーが発生した場合にTNSエントリを変更しなくてもよいように、本番サイトとスタンバイ・サイトの両方のTNSエントリで使用されます。
本番サイトでは、DNSエントリは次のようになります。
asmid1.asha IN A 138.1.2.333 asmid2.asha IN A 138.1.2.444 asinfra.asha IN A 138.1.2.111 remote_infra.asha IN A 213.2.2.110
スタンバイ・サイトでは、DNSエントリは次のようになります。
asmid1.asha IN A 213.2.2.330 asmid2.asha IN A 213.2.2.331 asinfra.asha IN A 213.2.2.110 remote_infra.asha IN A 138.1.2.111
方法2: 両サイトの各ノードの/etc/hostsファイルを編集します。この方法には、DNSサーバーの構成は含まれませんが、OracleAS Disaster Recovery環境内の各ノードのhostsファイルをメンテナンスする必要があります。たとえば、IPアドレスが変更されたら、すべてのノード上のファイルを更新し、ノードを再起動する必要があります。
方法2の詳細
/etc/hostsファイルに次の行を含めます。IPアドレスは、本番サイトのノードで解決します。127.0.0.1 localhost 138.1.2.333 asmid1.oracle.com asmid1 138.1.2.444 asmid2.oracle.com asmid2 138.1.2.111 asinfra.oracle.com asinfra
hostsファイルに次の行を含めます。IPアドレスは、スタンバイ・サイトのノードで解決します。127.0.0.1 localhost 213.2.2.330 asmid1.oracle.com asmid1 213.2.2.331 asmid2.oracle.com asmid2 213.2.2.110 asinfra.oracle.com asinfra
/etc/nsswitch.confファイルの「hosts:」行の最初の項目が、「files」になるようにします。
hosts: files nis dns
このエントリでは、名前解決の順序を指定します。別の方法が最初に表示されている場合は、ノードは他の方法を使用してホスト名を解決します。
変更を行い、ノードを再起動した後で、次のコマンドを実行して、ノードがホスト名を適切に解決することを確認します。
hostnameコマンドを実行します。これによって、内部ホスト名が戻されます。たとえば、prodmid1およびstandbymid1上でこのコマンドを実行すると、「asmid1」が戻されます。
prompt> hostname asmid1
-sオプションを指定するとノードのIPアドレスが表示されます）。
prompt> ping -s prodinfra ping the production infrastructure node PING prodinfra: 56 data byes 64 bytes from prodinfra.oracle.com (138.1.2.111): icmp_seq=0. time=0. ms ^C prompt> ping -s iasinfra ping the production infrastructure node PING iasinfra: 56 data byes 64 bytes from iasinfra.oracle.com (138.1.2.111): icmp_seq=0. time=0. ms ^C prompt> ping -s iasmid2 ping the second production midtier node PING iasmid2: 56 data byes 64 bytes from iasmid2.oracle.com (138.1.2.444): icmp_seq=0. time=0. ms ^C prompt> ping -s prodmid2 ping the second production midtier node PING prodmid2: 56 data byes 64 bytes from prodmid2.oracle.com (138.1.2.444): icmp_seq=0. time=0. ms ^C prompt> ping -s standbymid1 ping the first standby midtier node PING standbymid1: 56 data byes 64 bytes from standbymid1.oracle.com (213.2.2.330): icmp_seq=0. time=0. ms ^C
OracleAS Disaster Recoveryシステムの本番サイトでOracleAS Infrastructureを設定し、OracleAS Cold Failover Cluster構成で実行できます。この場合、1つのハードウェア・クラスタに2つのノードがあり、OracleAS Infrastructureを共有ディスクにインストールします。詳細は、第11章「高可用性環境へのインストール: OracleAS Cold Failover Cluster」を参照してください。
この環境でOracleAS Cold Failover Clusterを設定するには、本番サイト上のasinfra.ashaに対して（物理IPアドレスのかわりに）仮想IPアドレスを使用します。次の例では、138.1.2.120が仮想IPアドレスであると仮定します。
asmid1.asha IN A 138.1.2.333 asmid2.asha IN A 138.1.2.444 asinfra.asha IN A 138.1.2.120 this is a virtual IP address remote_infra.asha IN A 213.2.2.110
スタンバイ・サイトでは、asinfra.ashaには引き続き物理IPアドレスを使用しますが、remote_infra.ashaには仮想IPアドレスを使用します。
asmid1.asha IN A 213.2.2.330 asmid2.asha IN A 213.2.2.331 asinfra.asha IN A 213.2.2.110 physical IP address remote_infra.asha IN A 138.1.2.120 virtual IP address
次のようにしてOracle Application Serverをインストールします。
|
注意 すべてのインストールに対して、staticports.iniを使用してコンポーネントのポート番号を指定します。詳細は、第13.2.2項「staticports.iniファイルの設定」を参照してください。 |
OracleAS InfrastructureのOracle Identity ManagementおよびOracleAS Metadata Repositoryコンポーネントを同じノードにインストールする必要があります。コンポーネントを複数のノードに分散することはできません。
インストール手順は、OracleAS Cold Failover Clusterの場合の手順と同様です。表示される一連の画面については、第11.3項「OracleAS Cold Failover Cluster（Infrastructure）構成のインストール」を参照してください。次の点に注意してください。
任意の中間層タイプをインストールできます。
J2EE and Web Cacheのインストールについては、第7.9項「Database-Based Farm RepositoryへのJ2EE and Web Cacheのインストール（Oracle Identity Management Accessを使用する場合）」を参照してください。
Portal and WirelessまたはBusiness Intelligence and Formsのインストールについては、第7.13項「Portal and WirelessまたはBusiness Intelligence and Formsのインストール」を参照してください。
次の点に注意してください。
OracleAS 10g（10.1.2.0.2）では、OracleAS Guardのスタンドアロン・インストールは、OracleAS Companion CD 2に収録されています。OracleAS Guardのスタンドアロン・インストールは、次の環境にインストールできます。
OracleAS Guardがアップグレード・インストールされた場合は、dsa.conf構成ファイルのコピーを作成して、現在のOracleAS Guard環境の設定を保存します。OracleAS 10g（10.1.2.0.2）のOracleAS Guardスタンドアロン・インストール・キットを実行後、保存しておいたdsa.conf構成ファイルをリストアして、アップグレードされたOracleAS Guard環境で以前と同じ設定を使用できます。
OracleAS 10g（10.1.2.0.2）のOracleAS Guardスタンドアロン・インストール・キットを実行するには、次のディレクトリ・パスから実行します。
UNIXシステムの場合:
/Disk2/asg/install/runInstaller
実行するインストールの種類を選択します。一般のインストールには、「標準」を選択します。OracleAS Guardの旧リリースから現行リリースへアップグレードする場合は、「カスタムまたは再インストール」を選択します。
ias_adminアカウントのパスワードを入力し、インストールを続行します。
OracleAS Guardリリース10.1.2.0.0を使用してすでにOracleAS Disaster Recovery環境が設定されている場合は、環境にOracleAS Guardのパッチを適用して、新しい機能および第13.1項「OracleAS Disaster Recovery: 概要」で説明したトポロジのサポートを利用できます。OracleAS Disaster Recovery環境にパッチを適用する基本的な手順は、次のとおりです。
UNIXシステムの場合:
<ORACLE_HOME>/opmn/bin/opmnctl stopall
同じシステムに複数のOracleホームが存在する場合は、構成ファイルでOracleAS Guardサーバーごとに異なるポートが構成されていることを確認します。
ここではOracleAS Guardをアップグレード・インストールするので、dsa.conf構成ファイルのコピーを作成して、現在のOracleAS Guard環境の設定を保存します。OracleAS 10g（10.1.2.0.2）のOracleAS Guardスタンドアロン・インストール・キットを実行後、保存しておいたdsa.conf構成ファイルをリストアして、アップグレードされたOracleAS Guard環境で以前と同じ設定を使用できます。
UNIXシステムの場合:
<ORACLE_HOME>/dsa/dsa.conf
UNIXシステムの場合:
<ORACLE_HOME>/opmn/bin/opmnctl startall <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA
Oracle Data Guardの設定やOracleAS Metadata Repositoryデータベースの構成などの、OracleAS Disaster Recovery環境の管理方法については、『Oracle Application Server高可用性ガイド』を参照してください。
|
 Copyright © 2005, Oracle. All Rights Reserved. |
|