Oracle Application Serverインストレーション・ガイド 10g (10.1.4.0.1) for Microsoft Windows B31479-02 |
|
この章では、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を設定し、この環境を少し変更できます。詳細は、10.2.4項「本番サイトでOracleAS Cold Failover Clusterを使用する場合」を参照してください。
これらのサポートされているトポロジでは、OracleAS Disaster Recoveryソリューションとして構成された本番およびスタンバイ・トポロジ内のすべてのシステムのOracleホームに、OracleAS Guardがインストールされます。
OracleAS GuardはOracleAS Companion CD 2に収録されており、スタンドアロン・インストール・キットとしてインストールできます。このスタンドアロン・キットをインストールするタイミングについては、10.4項「OracleホームへのOracleAS 10g (10.1.2.0.2)のOracleAS Guardスタンドアロン・インストール」を参照してください。
図10-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
ファイルを作成します。このファイルで各コンポーネントのポート番号を指定できます。詳細は、2.4.4項「カスタムのポート番号の使用(「静的ポート」機能)」を参照してください。
サイト間でデータを同期化するときにデータを編集してホスト名を修正する必要がないように、本番サイトおよびスタンバイ・サイトの対応するノードの名前は同じである必要があります。
インフラストラクチャを実行するノードの場合、仮想名を設定します。これを行うには、C:¥Windows¥system32¥drivers¥etc¥hosts
ファイルにノードの別名を指定します。
たとえば、本番サイトのインフラストラクチャ・ノードでは、hosts
ファイル内の次の行は別名をasinfra
に設定します。
138.1.2.111 prodinfra asinfra
スタンバイ・サイトでは、次の行はノードの別名をasinfra
に設定します。
213.2.2.110 standbyinfra asinfra
本番サイトおよびスタンバイ・サイトにOracleAS Infrastructureをインストールする場合は、「仮想ホストの指定」画面でこの別名(asinfra
)を指定します。構成データには、インフラストラクチャ・ノード用のこの別名が含まれます。
中間層を実行するノードの場合、中間層のインストール時にインストーラによって「仮想ホストの指定」画面が表示されないため、インフラストラクチャ・ノードの場合のように別名を指定できません。中間層のインストールでは、インストーラによってgethostname()関数がコールされ、自動的にホスト名が確認されます。本番サイトの各中間層ノードに対して、スタンバイ・サイトの対応するノードが同じホスト名を戻すようにする必要があります。
これを行うには、ローカルまたは内部のホスト名を設定します。このホスト名はパブリックまたは外部のホスト名と同じである必要はありません。スタンバイ・サイトのノードの名前を本番サイトの対応するノードの名前にあわせて変更するか、本番サイトとスタンバイ・サイトの両方のノードの名前が同じになるように変更できます。どちらの方法を使用するかは、ノード上で実行されている他のアプリケーション、およびノード名の変更によってこれらのアプリケーションが影響を受けるかどうかによって決定します。
_CLUSTER_NETWORK_NAME_
に、新しいローカルの完全修飾名(asmid1.oracle.com
など)を指定します。方法1: 本番サイトとスタンバイ・サイトに異なる内部DNSサーバーを設定します。この構成によって、各サイト(本番またはスタンバイ)のノードがサイト内でホスト名を解決できるようになります。内部DNSサーバーの上には、企業、つまり外部のDNSサーバーがあります。内部DNSサーバーは、信頼できないリクエストは外部DNSサーバーへ転送します。外部DNSサーバーは、内部DNSサーバーの存在を知りません。詳細は、図10-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
インフラストラクチャ・ノードの場合、仮想名または別名を使用します。
中間層ノードの場合、ノード名(環境変数_CLUSTER_NETWORK_NAME_
内の値)を使用します。
次の例では、新しいゾーンのドメイン名として「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
表10-1 内部DNSサーバーを指すようにDNSリゾルバを構成する方法
スタンバイ・サイトのノードに対しても同じ手順を実行します。ただし、スタンバイ・サイト用の内部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: 両サイトの各ノードのC:¥Windows¥system32¥drivers¥etc¥hosts
ファイルを編集します。この方法にはDNSサーバーの構成は含まれませんが、OracleAS Disaster Recovery環境内の各ノードのhosts
ファイルをメンテナンスする必要があります。たとえば、IPアドレスが変更されたら、すべてのノード上のファイルを更新し、ノードを再起動する必要があります。
方法2の詳細
C:¥Windows¥system32¥drivers¥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
hosts
ファイルが最初に読み取られるようにします。hosts
ファイルに目的のホスト名のエントリが含まれていない場合、ノードはDNSを介してホスト名を解決します。これを行うには、hosts
ファイルにエントリを追加した後でnbtstat -R
コマンドを実行し、キャッシュされた情報の消去および名前表の再ロードを実行します。詳細は、システム管理者に問い合せてください。
変更を行い、ノードを再起動した後で、次のコマンドを実行して、ノードがホスト名を適切に解決することを確認します。
hostname
コマンドを実行します。これによって、内部ホスト名が戻されます。たとえば、prodmid1およびstandbymid1上でこのコマンドを実行すると、「asmid1」が戻されます。
C:¥> hostname asmid1
C:> ping prodinfra ping the production infrastructure node Pinging prodinfra [138.1.2.111] with 32 bytes of data: Reply from 138.1.2.111: bytes=32 time<1ms TTL=128 C:> ping asinfra ping the production infrastructure node Pinging prodinfra [138.1.2.111] with 32 bytes of data: Reply from 138.1.2.111: bytes=32 time<1ms TTL=128 C:> ping asmid2 ping the second production midtier node Pinging asmid2 [138.1.2.444] with 32 bytes of data: Reply from 138.1.2.444: bytes=32 time<1ms TTL=128 C:> ping prodmid2 ping the second production midtier node Pinging asmid2 [138.1.2.444] with 32 bytes of data: Reply from 138.1.2.444: bytes=32 time<1ms TTL=128 C:> ping standbymid1 ping the first standby midtier node Pinging asmid2 [213.2.2.330] with 32 bytes of data: Reply from 213.2.2.330: bytes=32 time<1ms TTL=128
OracleAS Disaster Recoveryシステムの本番サイトでOracleAS Infrastructureを設定し、OracleAS Cold Failover Cluster構成で実行できます。この場合、1つのハードウェア・クラスタに2つのノードがあり、OracleAS Infrastructureを共有ディスクにインストールします。詳細は、第8章「高可用性環境へのインストール: 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
OracleAS Disaster Recovery環境でOracleAS Cold Failover Clusterを設定する場合は、OracleAS Metadata RepositoryをOracle Fail Safeグループに追加するときにパスワード・ファイルを作成する必要があります。
8.10.2項「OracleAS Metadata Repositoryの高可用性設定」の手順cで、「はい、パスワード・ファイルを作成します(推奨)」を選択します。
「ユーザー名」で、SYS
と入力します。
「パスワード」と確認のために「パスワードの確認」にも、SYSユーザーに設定するパスワードを入力します。
次のようにしてOracle Application Serverをインストールします。
注意: すべてのインストールに対して、staticports.iniを使用してコンポーネントのポート番号を指定します。詳細は、10.2.2項「staticports.iniファイルの設定」を参照してください。 |
インストール手順は、OracleAS Cold Failover Clusterの手順の場合と同様です。表示される一連の画面については、8.3項「OracleAS Cold Failover Cluster(Infrastructure)構成のインストール」を参照してください。次の点に注意してください。
Oracle Application Server 10g (10.1.4.0.1)と互換性のある任意の中間層タイプをインストールできます。詳細は、Oracle Application Serverのアップグレードおよび互換性ガイドを参照してください。
中間層をインストールするには、対象のリリースのOracle Application Serverのインストレーション・ガイドを参照してください。
次の点に注意してください。
OracleAS 10g (10.1.2.0.2)のOracleAS Guardスタンドアロン・インストールは、Companion CDのDisk 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スタンドアロン・インストール・キットを実行するには、次のディレクトリ・パスから実行します。
Windowsシステムの場合:
¥Disk2¥asg¥install¥setup.exe
実行するインストールの種類を選択します。一般のインストールには、「標準」を選択します。OracleAS Guardの旧リリースから現行リリースへアップグレードする場合は、「カスタムまたは再インストール」を選択します。
ias_admin
アカウントのパスワードを入力し、インストールを続行します。
OracleAS Guardリリース10.1.2.0.0を使用してすでにOracleAS Disaster Recovery環境が設定されている場合は、環境にOracleAS Guardのパッチを適用して、新しい機能および10.1項「OracleAS Disaster Recovery: 概要」に示したトポロジのサポートを利用できます。OracleAS Disaster Recovery環境にパッチを適用する基本的な手順は、次のとおりです。
Windowsシステムの場合:
<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環境で以前と同じ設定を使用できます。
Windowsシステムの場合:
<ORACLE_HOME>¥dsa¥dsa.conf
Windowsシステムの場合:
<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 © 2007 Oracle Corporation. All Rights Reserved. |
|