10gリリース5（10.2.0.5.0）
B53907-01
 目次 |
 索引 |
| Oracle Enterprise Manager アドバンスト構成 10gリリース5（10.2.0.5.0） B53907-01 |
|
アクティブおよびパッシブ環境（またはコールド・フェイルオーバー・クラスタ（CFC））環境は、高可用性ソリューションの1つで、アプリケーションは一度に1つのノードで動作することができます。これらの環境では、一般に、クラスタのソフトウェアの組合せによって論理ホスト名とIPアドレスが提供され、相互接続されたホストおよびストレージのシステムが情報を共有して、アプリケーションの高可用性のための手段を提供します。
この章では次の項について説明します。
この項では、データベース管理者に、Enterprise Manager Database Controlによるコールド・フェイルオーバー・クラスタ環境でのOracle Databaseリリース10gの構成に関する情報を提供します。
クラスタ内の異なるホストへのフェイルオーバー後にDatabase Controlがデータベース・インスタンスを提供するには、次の条件が満たされている必要があります。
次の項目は、構成とインストールについて、作業を開始する前に考慮すべき点です。
invPtrLocを使用して、ソフトウェアがインストールされている必要があります。
仮想ホスト名および仮想IPアドレスのエイリアスは、クラスタウェアにそれを自動設定させることにより、またはOracleサービスのインストールおよび起動の前に手動で設定することにより、設定することができます。仮想ホスト名は、静的であり、ネットワーク上で常に解決可能である必要があります。設定に参加するすべてのノードは、仮想IPアドレスを同じホスト名に解決する必要があります。nslookupコマンドやtracerouteコマンドのような標準TCPツールは、検証に使用できます。
共有記憶域は、使用中のクラスタウェアで管理できます。または、サポートされている任意の共有ファイル・システム・ボリュームを使用できます。最も一般的な共有ファイル・システムは、NFSです。また、Oracle Cluster File Systemソフトウェアを使用することもできます。
一部のバージョンのオペレーティング・システムでは、Oracleデータベースのリリース10gリリース2をインストールする前に、特定のオペレーティング・システム・パッチを適用する必要があります。また、インストールを実行する際に、十分な使用可能カーネル・リソースがある必要があります。
インストーラを起動する前に、必ず、特定の環境変数を確認してください。次の変数はそれぞれ、クラスタに参加するすべてのマシンで、ソフトウェアをインストールするために使用しているアカウントについて同じ設定である必要があります。
ソフトウェア所有者のユーザーおよびグループは、クラスタのすべてのノードで定義が同一である必要があります。このことは、次のコマンドを使用して確認できます。
$ id -a uid=1234(oracle) gid=5678(dba) groups=5678(dba)
インベントリ・ファイルが共有記憶域にあることを確認するには、次の手順に従います。
cd <shared oracle home> mkdir oraInventory
インストーラを起動するには、インベントリ・ロケーション・ファイルのoraInst.locを指して、仮想グループのホスト名を指定します。次の例のdebugパラメータはオプションです。
$ export ORACLE_HOSTNAME=lxdb.acme.com $ runInstaller -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_ HOSTNAME=lxdb.acme.com -debug
Windows環境の場合、Oracleソフトウェアに必要なサービスおよびキーをコピーするには追加の手順が必要です。
Windowsの場合、フェイルオーバー・ホストでNTサービスを作成する必要があります。Enterprise Managerリリース10.2.0.5の管理エージェントの場合、次のコマンドを使用できます。
emctl create service [-user <username>] [-pwd <password>] -name <servicename>
フェイルオーバー後に、このコマンドをフェイルオーバー・ホスト上で1回実行する必要があります。
サービスは、次の順に起動する必要があります。
サービスが起動しない場合は、次のようにします。
lsnrctl start
dbstart
emctl start dbconsole
サービスを手動で停止またはシャットダウンするには、次の手順に従います。
emctl stop dbconsole
lsnrctl stop
dbshut
Grid Controlリポジトリが別のホストにフェイルオーバーできるように、次の条件を満たしている必要があります。
インストールおよび構成に関する次の要件に注意する必要があります。
インストールにNFSマウント・ボリュームを使用する場合は、I/Oの問題が発生しないように、mountコマンドでrsizeおよびwsizeの値を指定してください。My Oracle Supportノート279393.1「Linux.NetApp: RHEL/SUSE Setup Recommendations for NetApp Filer Storage」を参照してください。
例:
grid-repo.acme.com:/u01/app/share1 /u01/app/share1 nfs
rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0
仮想ホスト名および仮想IPアドレスは、クラスタウェアにそれを設定させることにより、またはOracleサービスのインストールおよび起動の前に手動で設定することにより、設定することができます。仮想ホスト名は、静的であり、ネットワーク上で常に解決可能である必要があります。設定に参加するすべてのノードは、仮想IPアドレスを同じホスト名に解決する必要があります。nslookupやtracerouteのような標準TCPツールは、ホスト名の検証に使用できます。検証は、次のようなコマンドを使用して実行します。
nslookup <virtual hostname>
このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。
nslookup <virtual IP>
このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。
クラスタの各ノードでこれらのコマンドを実行し、正しい情報が返されることを確認してみてください。
一部のオペレーティング・システムのバージョンでは、10gリリース2をインストールする前に、特定のパッチを適用する必要があります。10gリリース2ソフトウェアをインストールして使用するユーザーは、十分な使用可能カーネル・リソースがある必要があります。詳細は、オペレーティング・システムのインストレーション・ガイドを参照してください。
インストーラを起動する前に、必ず、特定の環境変数を確認してください。それらの各変数には、クラスタに属するすべてのマシンに該当ソフトウェアをインストールするアカウントで、等しい値を設定する必要があります。
この変数の設定は、インストールの前に解除する必要があります。
PERL5LIBのような変数も、正しくないPERLライブラリを不注意に選択しないように、設定を解除する必要があります。
たとえば、LIBPATH、LD_LIBRARY_PATH、SHLIB_PATHなどです。同じシステム・ライブラリが存在する必要があります。
ソフトウェア所有者のユーザーおよびグループは、クラスタのすべてのノードで定義が同一である必要があります。次のidコマンドを使用して検証することができます。
$ id -a
uid=550(oracle) gid=50(oinstall) groups=501(dba)
インベントリの設定は、次の手順で実行します。
cd <shared oracle home>
mkdir oraInventory
vi oraInst.loc
Oracleインベントリ・ディレクトリへのパス情報を入力し、ソフトウェア所有者のグループをoinstallユーザーとして指定します。
例:
inventory_loc=/app/oracle/product/10.2/oraInventory
inst_group=oinstall
次の手順に従って、ソフトウェアをインストールします。
$ export ORACLE_HOSTNAME=grid-repo.acme.com $ runInstaller -invPtrLoc /app/oracle/share1/oraInst.loc
ORACLE_HOSTNAME=grid-repo.acme.com
/oradbnas/app/oracle/product/oradb10203 using Host1
/oradbnas/oradata
Windows環境の場合、Oracleソフトウェアに必要なサービスおよびキーをコピーするには追加の手順が必要です。
Windowsの場合、フェイルオーバー・ホストでNTサービスを作成する必要があります。Enterprise Managerリリース10.2.0.5の管理エージェントの場合、次のコマンドを使用できます。
emctl create service [-user <username>] [-pwd <password>] -name <servicename>
フェイルオーバー後に、このコマンドをフェイルオーバー・ホスト上で1回実行する必要があります。
サービスは、次の正しい順序で起動してください。
フェイルオーバーの場合は、次の手順を実行します。
lsnrctl start。同じフェイルオーバー・グループの一部である場合）を起動します。
dbstart。同じフェイルオーバー・グループの一部である場合）を起動します。
これで、浮動ホスト名を利用するCFC環境内でGrid Control管理リポジトリをデプロイできるようになりました。
CFC環境でのOMS中間層のデプロイについては、4.3項「仮想ホスト名を使用した高可用性フェイルオーバーのためのアクティブ/パッシブ環境におけるGrid Control OMSの構成方法」を参照してください。
この項では、コールド・フェイルオーバー・クラスタ（CFC）環境でEnterprise Manager 10g Grid Controlの構成を実行するGrid Control管理者のために、その操作の概要を説明します。
Grid Controlが他のホストにフェイルオーバーできるためには、次の条件を満たす必要があります。
クラスタ・メンバーの物理ホスト名を仮想ホスト名で上書きするには、ソフトウェアが、ORACLE_HOSTNAMEパラメータを使用してインストールされている必要があります。インベントリ・ポインタについては、共有インベントリの場所へのパスが含まれている共有インベントリ・ロケーション・ファイルを指すように、コマンドライン・パラメータの-invPtrLocを使用して、ソフトウェアがインストールされている必要があります。
インストールにNFSマウント・ボリュームを使用する場合は、I/Oの問題が発生しないように、mountコマンドでrsizeおよびwsizeの値を指定してください。
次に例を示します。
oms.acme.com:/u01/app/share1 /u01/app/
share1 nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,
timeo=600 0 0
仮想ホスト名および仮想IPアドレスは、クラスタウェアにそれを設定させることにより、またはOracleサービスのインストールおよび起動の前に手動で設定することにより、設定することができます。仮想ホスト名は、静的であり、ネットワーク上で常に解決可能である必要があります。設定に参加するすべてのノードは、仮想IPアドレスを同じホスト名に解決する必要があります。nslookupやtracerouteのような標準TCPツールは、ホスト名の検証に使用できます。検証は、次のコマンドを使用して実行します。
nslookup <virtual hostname>
このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。
nslookup <virtual IP>
このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。
クラスタの各ノードでこれらのコマンドを実行し、正しい情報が返されることを確認してみてください。
使用中のクラスタウェアによって管理する記憶域を設定するか、任意の共有ファイル・システム（FS）ボリューム（ただし、OCFS V1のようなサポートされていないタイプは除く）を使用することができます。最も一般的な共有ファイル・システムは、NFSです。
一部のオペレーティング・システムのバージョンでは、10gR2をインストールする前に、特定のパッチを適用する必要があります。10gリリース2ソフトウェアをインストールして使用するユーザーは、十分な使用可能カーネル・リソースがある必要があります。詳細は、オペレーティング・システムのインストレーション・ガイドを参照してください。
インストーラを起動する前に、必ず、特定の環境変数を確認してください。それらの各変数には、クラスタに属するすべてのマシンに該当ソフトウェアをインストールするアカウントで、等しい値を設定する必要があります。
タイムゾーン設定。この変数の設定は、インストールの前に解除する必要があります。
PERL5LIBのような変数は、不適切なPERLライブラリ・セットへの関連付けを防止するために、設定を解除する必要があります。
ソフトウェア所有者のユーザーおよびグループは、クラスタのすべてのノードで定義が同一である必要があります。次のidコマンドを使用して検証することができます。
$ id -a
uid=550(oracle) gid=50(oinstall) groups=501(dba)
次の手順を実行し、共有インベントリを設定します。
$ cd <shared oracle home>
$ mkdir oraInventory
次の手順に従って、ソフトウェアをインストールします。
$ export ORACLE_HOSTNAME=lxdb.acme.com $ runInstaller -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.acme.com -debug
hostname <unqualified name of virtual host>を実行して、ホスト名を変更できない場合は、OMSコンフィギュレーション・アシスタントが
emctl config emkeyで失敗したときにインストーラを中断し、次のコマンドを実行してインストールを完了します。
OMS_HOME>/bin/emctl config emkey -repos -force
OMS_HOME>/bin/emctl secure oms
OMS_HOME>/bin/emctl secure lock
OMS_HOME>/perl/bin/perl $OMSHOME/sysman/install/precompilejsp.pl <OMS_HOME>/j2ee/OC4J_EM/
config/global-web-application.xmlGrid Control 10.2.0.1を使用している場合、この手順を実行します。10.2.0.4または10.2.0.5パッチセットを適用する前にGrid Controlをインストールする必要があります。
OMS_HOME>/bin/emctl config agent updateTZ
OMS_HOME>/opmn/bin/opmnctl stopall
OMS_HOME>/opmn/bin/opmnctl startall
AGENT_HOME>/bin/agentca -f
Windows環境の場合、Oracleソフトウェアに必要なサービスおよびキーをコピーするには追加の手順が必要です。
Windowsの場合、フェイルオーバー・ホストでNTサービスを作成する必要があります。Enterprise Managerリリース10.2.0.5の管理エージェントの場合、次のコマンドを使用できます。
emctl create service [-user <username>] [-pwd <password>]
-name <servicename>
フェイルオーバー後に、このコマンドをフェイルオーバー・ホスト上で1回実行する必要があります。
サービスは、次の正しい順序で起動してください。正しい順序は次のようになります。
フェイルオーバーの場合は、次の手順を実行します。
lsnrctl startを使用して、TNSリスナー（同じフェイルオーバー・グループの一部である場合）を起動します。
dbstartを使用して、データベース（同じフェイルオーバー・グループの一部である場合）を起動します。
opmnctl startallを使用して、Grid Controlを起動します。
これで、浮動ホスト名を利用するCFC環境内でGrid ControlのOMS中間層コンポーネントをデプロイできるようになりました。
CFC環境でのリポジトリ・データベースのデプロイについては、4.2項「アクティブ/パッシブ高可用性環境でのGrid Controlリポジトリの構成」を参照してください。
この項では、コールド・フェイルオーバー・クラスタ（CFC）・ターゲットを既存の管理エージェントから別の管理エージェントに再配置するGrid Control管理者のために、その操作の概要を説明します。これらのターゲットは複数のノードで実行することもできますが、CFC環境ではアクティブ・ノードでのみ実行します。
CFC環境では、一般に、クラスタ・ソフトウェアの組合せによって仮想ホスト名とIPアドレスが提供され、相互接続されたホストおよびストレージのシステムが情報を共有して、アプリケーションの高可用性を実現します。仮想ホスト名およびIPのフェイルオーバーの自動化とともに、Enterprise Managerターゲットの再配置、およびパッシブ・ノードでのアプリケーションの再起動を行うには、Oracle Enterprise Managerコマンドライン・インタフェース（EM CLI）と（Oracle Databaseリリース10gまたは11gを実行している）Oracleクラスタウェアまたはサード・パーティのクラスタ・ソフトウェアを使用する必要があります。Oracleのパートナ・ベンダー数社は、この領域のクラスタウェア・ソリューションを提供しています。
Enterprise Managerコマンドライン・インタフェース（EM CLI）を使用すると、様々なオペレーティング・システムに対応したテキスト・ベースのコンソール（端末セッション）からEnterprise Manager Grid Control機能にアクセスできます。EM CLIを使用して、Enterprise Manager Grid Controlコンソール・ベースの操作を実行できます。これには、ターゲット、ジョブ、グループ、ブラックアウト、通知およびアラートの監視や管理などの操作があります。詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。
Oracle Enterprise Manager 10gリリース10.2.0.5以降では、クラスタ内の各ノードで実行されている単一のOracle Management Agentが、アクティブ/パッシブ高可用性を実現するために構成されているターゲットを監視できます。パッシブ・ノードへのフェイルオーバーの場合、Enterprise Managerは一連のEMCLIコマンドを使用して、障害が発生したノード上の管理エージェントから、新しくアクティブ化されたノード上の別の管理エージェントへHA監視ターゲットを移動できます。このため、CFCクラスタの各物理ノードで必要な管理エージェントは1つのみです。
使用するアプリケーションがアクティブ/パッシブ環境で実行されている場合、アクティブ・ノードで障害が発生すると、クラスタウェアは、パッシブ・ノード上のアプリケーションを起動します。このようなタイプの構成でEnterprise Managerがターゲットの監視を継続できるようにするには、既存の管理エージェントに追加の構成が必要です。
次の項では、新規アクティブ・ノードでターゲットを自動化および再起動するために環境を整える方法について説明します。フェイルオーバーとフォールバックの手順についても説明します。
次の項では、Oracle Management Serviceプロセスと通信する既存の管理エージェントを使用してCFC構成をサポートするようEnterprise Managerを構成する方法について説明します。
次のようにアクティブ/パッシブ環境を準備します。
次の項では、OMSプロセスと通信する既存の管理エージェントを使用してCFC構成をサポートするようEnterprise Managerを構成する方法について説明します。後述の例は、1つのフェイルオーバー・グループを持つ2ノード・クラスタの構成に基づいています。CFCアクティブ/パッシブ環境で実行されているターゲットの詳細は、My Oracle Supportノート406014.1を参照してください。
ターゲットの再配置を設定および構成するには、Oracle Enterprise Managerコマンドライン・インタフェース（EM CLI）を使用します。EM CLIおよび管理プラグインの詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』および『Oracle Enterprise Manager拡張ガイド』を参照してください。
クラスタ内の各ノード上のローカル・ディスク・ボリュームに管理エージェントをインストールします。インストールした後、管理エージェントはGrid Controlコンソールに表示されます。
アクティブ/パッシブ・ターゲットが構成された後、Grid Controlコンソール内の管理エージェントの検出画面を使用してターゲット（データベース、リスナー、アプリケーション・サーバーなど）を追加します。新規ターゲットを現在ホストしているノードであるアクティブ・ノードで、検出を実行します。
ノードのフェイルオーバー後にターゲットの再配置を短時間で行うには、ターゲットのフェイルオーバーを自動的に開始するために必要なコマンドを含むスクリプトを使用して、次の手順を構成します。通常、クラスタ・ソフトウェアには、Enterprise Manager内のターゲットを再配置するためのスクリプトを自動的に実行できるメカニズムが採用されています。また、サンプル・スクリプトの詳細は、4.4.6項「スクリプト例」も参照してください。
ターゲットが実行されているアクティブ・ノード上で、仮想IP上で実行されているターゲット・サービスを停止します。
仮想IPおよび共有記憶域で動作するすべてのアプリケーションを停止します。
新規アクティブ・ノード上の管理エージェントにターゲットを再配置するには、フェイルオーバー操作後に再配置する必要があるターゲット・タイプ（リスナー、アプリケーション・サーバーなど）ごとにEM CLI RELOCATE TARGETコマンドを発行します。次に例を示します。
emcli relocate_targets -src_agent=<node 1>:3872 -dest_agent=<node 2>:3872 -target_name=<database_name> -target_type=oracle_database -copy_from_src -force=yes
この例では、ポート3872が管理エージェントのデフォルト・ポートです。使用している構成に適したポート番号を確認するには、この管理エージェントのemd.propertiesファイル内のEMD_URLパラメータの値を使用します。
注意:フェイルオーバー・イベント時には、ソース・エージェントは実行されません。ただし、RELOCATE操作を実行するためにソース管理エージェントを実行する必要はありません。EM CLIがOMSクライアントとして、管理リポジトリに対してRELOCATE操作を直接実行します。
HAターゲットを元のアクティブ・ノードまたは他の任意のクラスタ・メンバー・ノードに戻すには、次のようにします。
再配置操作中にフェイルオーバー（またはスイッチオーバー）されるターゲット・タイプごとに同じコマンドを発行します。たとえば、同じEM CLIコマンドを発行し、リスナーやアプリケーション・サーバーなどを再配置します。表4-1に、ターゲットを再配置するために使用するEM CLIパラメータを示します。
次の項では、スクリプト例を示します。
#! /bin/ksh #get the status of the targets emcli get_targets - targets="db1:oracle_database;listener_db1:oracle_listener" -noheader if [[ $? != 0 ]]; then exit 1; fi # blackout the targets to stop false errors. This blackout is set to expire in 30 minutes emcli create_blackout -name="relocating active passive test targets" - add_targets="db1:oracle_database;listener_db1:oracle_listener" - reason="testing failover" - schedule="frequency:once;duration:0:30" if [[ $? != 0 ]]; then exit 1; fi # stop the listener target. Have to go out to a OS script to use the 'lsnrctl set current_listener' function emcli execute_hostcmd -cmd="/bin/ksh" -osscript="FILE" - input_file="FILE:/scratch/oraha/cfc_test/listener_stop.ksh" - credential_set_name="HostCredsNormal" - targets="host1.us.oracle.com:host" if [[ $? != 0 ]]; then exit 1; fi # now, stop the database emcli execute_sql -sql="shutdown abort" - targets="db1:oracle_database" - credential_set_name="DBCredsSYSDBA" if [[ $? != 0 ]]; then exit 1; fi # relocate the targets to the new host emcli relocate_targets - src_agent=host1.us.oracle.com:3872 - dest_agent=host2.us.oracle.com:3872 - target_name=db1 -target_type=oracle_database - copy_from_src -force=yes - changed_param=MachineName:host1vip.us.oracle.com if [[ $? != 0 ]]; then exit 1; fi emcli relocate_targets - src_agent=host1.us.oracle.com:3872 - dest_agent=host2.us.oracle.com:3872 - target_name=listener_db1 -target_type=oracle_listener - copy_from_src -force=yes - changed_param=MachineName:host1vip.us.oracle.com if [[ $? != 0 ]]; then exit 1; fi # Now, restart database and listener on the new host emcli execute_hostcmd -cmd="/bin/ksh" -osscript="FILE" - input_file="FILE:/scratch/oraha/cfc_test/listener_start.ksh" - credential_set_name="HostCredsNormal" - targets="host2.us.oracle.com:host" if [[ $? != 0 ]]; then exit 1; fi emcli execute_sql -sql="startup" - targets="db1:oracle_database" - credential_set_name="DBCredsSYSDBA" if [[ $? != 0 ]]; then exit 1; fi # Time to end the blackout and let the targets become visible emcli stop_blackout -name="relocating active passive test targets" if [[ $? != 0 ]]; then exit 1; fi # and finally, recheck the status of the targets emcli get_targets - targets="db1:oracle_database;listener_db1:oracle_listener" -noheader if [[ $? != 0 ]]; then exit 1; fi
#!/bin/ksh export ORACLE_HOME=/oradbshare/app/oracle/product/11.1.0/db export PATH=$ORACLE_HOME/bin:$PATH lsnrctl << EOF set current_listener listener_db1 start exit EOF
#!/bin/ksh export ORACLE_HOME=/oradbshare/app/oracle/product/11.1.0/db export PATH=$ORACLE_HOME/bin:$PATH lsnrctl << EOF set current_listener listener_db1 stop exit EOF
コールド・フェイルオーバー・クラスタ環境では、1つのホストがアクティブ・ノード（アプリケーションが動作中）とみなされ、共有記憶域に保存されているデータにアクセスします。
2つ目のノードはスタンバイ・ノードとみなされ、障害発生時に、現在プライマリ・ノードで提供されているアプリケーションを動作させることができます。クラスタ・ソフトウェアは、論理ホスト名とIPアドレスを示すように構成されます。このアドレスにより、アプリケーション実行用の、アクティブ・ノードまたはスタンバイ・ノードのいずれにも固定されない一般位置が指定されます。
アクティブ・ノードで障害が発生すると、アプリケーションがハードウェア障害またはクラスタ・ソフトウェアによって停止されます。停止されたアプリケーションは、同じ論理ホスト名およびIPアドレスを使用してパッシブ・ノードで再起動されるので、わずかな中断時間で動作を再開できます。仮想ホスト名およびIPのフェイルオーバーの自動化と、パッシブ・ノードでのアプリケーションの起動には、サード・パーティのクラスタ・ソフトウェアが必要です。Oracleのパートナ・ベンダー数社は、この領域の高可用性ソリューションを提供しています。
Enterprise Managerは、Oracle Management Serviceプロセスと通信する追加の管理エージェントを使用してこの形式のコールド・フェイルオーバー・クラスタをサポートするように構成できます。
使用するアプリケーションがアクティブおよびパッシブ環境で実行されている場合、アクティブ・データベースが停止すると、クラスタウェアは、パッシブまたはスタンバイのデータベース・インスタンスを起動します。このような状況でもEnterprise Managerがアプリケーション・インスタンスの監視を継続できるようにするには、既存の管理エージェントに追加の構成が必要です。
この環境に対する追加の構成の手順には、次が含まれます。
つまり、この構成では、3つの管理エージェント（ハードウェア・ノードごとに1つとクラスタ・ソフトウェアが生成するIPアドレス用に1つ）がインストールされます。理論的には、クラスタ・ソフトウェアが、複数の高可用性環境をサポートするために複数の仮想IPアドレスの生成をサポートする場合、ここで概要を示すソリューションは、その環境をサポートするために拡張される必要があります。
次の表に、CFC環境の管理エージェントの構成に必要な手順を示します。
各クラスタ・ベンダーは、スイッチオーバーまたはフェイルオーバーを異なる方法で実行するために必要な手順のラッパーを構築するプロセスを実装します。その手順自体は一般的なものであり、次のとおりです。
管理エージェントを最初に停止し、他のアプリケーションが起動した後に管理エージェントを再起動することにより、Enterprise Managerが不適切なターゲット・ダウン・アラートをトリガーすることを防止できます。この順序で操作しないと、スイッチオーバーまたはフェイルオーバー時にアラートが発生します。
論理的には、アクティブ・ホストで2つの管理エージェント・プロセスが動作することによるパフォーマンスの低下が想定されますが、テストでは、そのようなパフォーマンスの低下は見られませんでした。管理エージェントがこのドキュメントで説明されているように構成されている場合は、物理ホストIPを監視する管理エージェントが保持する監視対象ターゲットは2つのみです。このため、追加のオーバーヘッドは、2つの管理エージェント・プロセス自体と、それらが管理エージェントおよびオペレーティング・システムを監視するために発行するコマンドのみです。テストでは、CPU使用率1〜2%のオーバーヘッドの発生が確認されました。
全体として、コールド・フェイルオーバー環境をサポートするためのEnterprise Managerの構成には、次の手順があります。
|
 Copyright © 2003, 2009 Oracle Corporation. All Rights Reserved. |
|