この章では、可用性の高いトポロジに関連した問題について説明します。この章の内容は次のとおりです。
第4.2項「OracleAS Disaster Recovery: Real Application Clustersデータベースをサポート」
第4.3項「LinuxシステムのOracleAS Guardスタンドアロン・キットに、ファイルlibcxa.so.3がない」
複数のOracleホームがあるノードでdiscover topology
コマンドを実行し、そのOracleホームの1つがなんらかの理由で無効な場合(つまり、そのOracleホームがOracle Universal Installerに表示されない場合)、discover topology
コマンドによって次のような警告が表示されます。
ASGCTL> discover topology oidpass=welcome1 Discovering topology on host "hasun1" with IP address "123.45.67.89" hasun1:7890 Connecting to the OID server on host "hasun12vip1.mydomain.com" using SSL port "636" and username "orcladmin" Getting the list of databases from OID Gathering database information for SID "orcl" from host "hasun12vip1.mydomain.com" Getting the list of instances from OID Gathering instance information for "immr.hasun12vip1.mydomain.com" from host "hasun12vip1.mydomain.com" Gathering instance information for "asmid.haqadr01.mydomain.com" from host "haqadr01.mydomain.com" ********** WARNING ********** hasun1: -->ASG_IAS-15779: Error getting instance information for instance "asmid.haqadr01.mydomain.com" from host "haqadr01.mydomain.com". This instance will be excluded from the topology.xml file drmt: -->ASG_IAS-15632: The home that contains instance "asmid.haqadr01.mydomain.com" could not be found drmt: -->ASG_DUF-4950: An error occurred on host "drmt" with IP "130.35.45.23" and port "7890" ******** END WARNING ******** The topology has been discovered. A topology.xml file has been written to each home in the topology.
この問題に対処するには、oraInventory
ディレクトリにあるInventory.xml
ファイルから無効なOracleホームのエントリを削除してから、discover topology
コマンドを再実行します。
『Oracle Application Server高可用性ガイド』の表1-3には、OracleAS Disaster Recoveryはアクティブ/アクティブ・トポロジのOracleAS Infrastructureをサポートしないと記述されていますが、これは間違っています。OracleAS Disaster Recoveryは、アクティブ/パッシブ・トポロジだけでなく、アクティブ/アクティブ・トポロジのOracleAS Infrastructureもサポートします。アクティブ/アクティブ・トポロジのOracleAS Infrastructureでは、OracleAS Metadata RepositoryはReal Application Clustersデータベース上で稼動します。
次に、最新の表1-3を示します(太字は更新箇所を表す)。
表4-1 サービス・レベル要件とアーキテクチャの選択
ビジネス要件 | 選択するアーキテクチャ | |||
---|---|---|---|---|
ローカル高可用性 | スケーラビリティ | 障害時リカバリ | インスタンスの冗長性 | 障害時リカバリ |
N |
N |
N |
基本 |
N |
Y |
N |
N |
アクティブ/パッシブ |
N |
N |
Y |
N |
アクティブ/アクティブ |
N |
N |
N |
Y |
基本 |
Y |
Y |
Y |
N |
アクティブ/アクティブ |
N |
Y |
N |
Y |
アクティブ/パッシブ |
Y |
N |
Y |
Y |
アクティブ/アクティブ(中間層) 基本(Infrastructure) |
Y |
Y |
Y |
Y |
アクティブ/アクティブ(中間層) アクティブ/パッシブおよびアクティブ/アクティブ(Infrastructure) |
Y |
注意: OracleAS Disaster Recoveryは、基本、アクティブ/パッシブおよびアクティブ/アクティブのInfrastructureアーキテクチャをサポートしています。基本、アクティブ/パッシブまたはアクティブ/アクティブ・アーキテクチャのスケーラビリティを向上させるには、高性能のCPUやメモリーの追加によってInfrastructureハードウェアの処理能力を上げてください。 |
LinuxシステムにOracleAS Guardスタンドアロン・キットをインストールし、asgctlのasgctl.sh startup
コマンドを使用してOracleAS Guardサーバーを起動すると、他のエラー情報とともに次のDufExceptionが返されます。
oracle.duf.DufException: oracle.duf.DufException
トレースを有効にしている場合は、duf_client.log
ファイルに次のエラー・メッセージが含まれ、トレース出力の下部に埋め込まれた状態になっています。
. . . java.lang.UnsatisfiedLinkError: /private/mydb/product/10.1.0/asg/dsa/lib/libOsUtils.so: libcxa.so.3: cannot open shared object file: No such file or directory . . .
OracleAS Guardリリース10.1.2.0.2のスタンドアロン・キットを使用している場合、この問題を回避するには、OracleAS Guardのクライアントまたはサーバーを起動する前に、<ORACLE_HOME>/lib
にあるOracle Application ServerのOracleホームから<ORACLE_HOME>/dsa/lib
にあるスタンドアロンOracleAS Guardのホームに、libcxa.so.3
ファイルをコピーします。
このlibcxa.so.3
ファイルのコピー操作は、OracleAS Guardリリース10.1.2.0.2のスタンドアロン・キットをインストールしたすべてのシステムで実行する必要があります。
『Oracle Application Server高可用性ガイド』の第13章「OracleAS Disaster Recovery」の第13.10項「実行時操作 -- OracleAS Guardのスイッチオーバーおよびフェイルオーバー操作」には、次のように記述されています。「サイト・スイッチオーバーは、本番サイトの計画停止の際に実行されます。スイッチオーバー時には、本番サイトとスタンバイ・サイトの両方が使用可能である必要があります。」
「使用可能」とは、次のコンポーネントが起動されて実行中である必要があるという意味です。
リスナー
DSA
データベース
『Oracle Application Server高可用性ガイド』の第13章「OracleAS Disaster Recovery」の第13.8項「OracleAS Guard操作: スタンバイ・システムへの1つ以上の本番インスタンスのスタンバイ・サイト・クローニング」には、次の記述を入れる必要があります。
OracleAS Guardは、Identity Managementのみ、同じ場所にあるIdentity ManagementおよびMetadata Repository、独自のMetadata RepositoryなどのInfrastructureインストールのクローニングはサポートしません。
10gリリース2(10.1.2)以降、『Oracle Application Server高可用性ガイド』の「サポートされているトポロジ」では、Identity Managementの分散構成(Oracle Internet DirectoryおよびDirectory Integration Platformが1つのホスト上にあり、Oracle Single Sign-OnおよびDelegated Administration Servicesがもう1つのホスト上にある)が、Oracle Application Server Disaster Recoveryのサポート対象トポロジであるかどうか記載されていません。
同様に、10gリリース2(10.1.2.3)の『Oracle Application Server Disaster Recovery Guide』のサポートされているトポロジに関する項でも、Identity Managementの分散構成がOracle Application Server Disaster Recoveryのサポート対象トポロジであるかどうかの記載がありません。
Identity Managementの分散構成は、サポートされているOracle Application Server Disaster Recoveryトポロジです。
10gリリース2(10.1.2.3)の『Oracle Application Server Disaster Recovery Guide』には、Oracle Application Server Guardの構成およびその他の関連情報に関する項で、Oracle Application Server Guardのclone_unpack_cmd
パラメータに関する記載に誤りがあります。
Oracle Application Server Guardのclone_unpack_cmd
パラメータに関する正しい説明は次のようになりますので、10gリリース2(10.1.2.3)の『Oracle Application Server Disaster Recovery Guide』で該当する記載を読み替えてください。
clone_unpack_cmd
- このオプション・パラメータは、クローン・インスタンスまたはクローン・トポロジの操作時に作成されたjarファイルを解凍する際、Oracle Application Server Guardでtarコマンドを使用するよう指定します。たとえば、UNIXプラットフォーム上のOracle Application Server Guardは、デフォルトで、which tar
コマンドによって返されるtarのバージョンを使用してクローン・インスタンスおよびクローン・トポロジのjarファイルを解凍します。clone_unpack_cmdパラメータを使用すれば、Oracle Application Server Guardがこれらのjarファイルの解凍に使用する別のバージョンのtarおよびtarコマンド・パラメータを指定できます。
値: クローニング操作時に作成されたjarファイルの解凍に使用する、文字列、tarコマンドおよびパラメータ。次に例を示します。
clone_unpack_cmd = /sys/prod/software/tar -xpf
『Oracle Application Server高可用性ガイド』の第5.6項「OracleAS Integration B2B」に次の記載があります。
「この層は、Oracle HTTP ServerとOC4Jトランスポート・サーブレット・インスタンスで構成されています。サーブレットは、OC4Jコンテナにデプロイされ、そのコンテナの高可用性プロパティを利用できます。これは、OracleAS Clusters(OC4J)にグループ化され、一貫した構成のためにDCMによって同期化できます。OC4Jインスタンスはmod_oc4jによってロード・バランシングされます。」
次の点に注意してください。
トランスポート・サーブレットはB2Bサーバーとは異なります。
DCMを使用してトランスポート・サーブレットの構成を複数のOC4Jインスタンス間で一貫させることはできますが、DCMを使用してB2Bサーバーをクラスタリングすることはできません。B2BサーバーはJavaアプリケーションのようにOC4Jの外部で実行されるため、DCMでは制御されません。