この章では、Oracle Application Serverの高可用性ソリューションにおける様々な高可用性構成および機能のベスト・プラクティスについて説明します。この章の内容は次のとおりです。
OracleAS Cluster(Identity Management)に参加しているインスタンスには、一貫性があり標準化された構成を使用します。OracleAS Single Sign-On側からは、クラスタ内のインスタンスはすべて、単一のサービスを提供する単一のエンティティに見えます。構成を更新する際にエラーを回避するヒントは次のとおりです。
OracleAS Cluster(Identity Management)内のIdentity Managementインスタンスには、同じOracleホーム・パスを使用します。
Identity Managementインスタンスには同じインスタンス名を使用します。インストーラによってホスト名に接頭辞が付けられるため、アプリケーション・サーバー・インスタンスは一意になります。
HTTPリスニング・サーバーは、Oracle Application Server Single Sign-On/Oracle Delegated Administration Servicesのホストごとに別々のポートをリスニングすることもできますが、同じポートを使用することをお薦めします。
Application Server Controlなど、他のすべてのコンポーネントとサービスにも同じポートを使用することをお薦めします。これを実現するには、すべてのインストールでstaticports.ini
を使用します。
OracleAS Cluster(Identity Management)のインストール時にOracleAS Clusterの構成ページで指定するクラスタ名では、大文字と小文字が区別されます。インストール中は、構成エラーを回避するために、常にすべて大文字を使用するか、すべて小文字を使用することをお薦めします。
関連項目:
|
この項は次のトピックで構成されています。
ロード・バランサは、多くの異なるサービスへのエントリ・ポイントです。これらのサービスで冗長性を実現することとは別に、ロード・バランサ自体の可用性を高くする必要があります。ロード・バランサに障害が発生した場合に自動的にフェイルオーバーするように構成可能なロード・バランサを使用してください。
ほとんどのロード・バランサ製品では一般的に、監視によってサービスの障害は検出されません。このような製品では、接続はアイドルのままになり、リクエストはハングします。
実装の詳細
サービスを監視して、障害が発生した場合はすべてのトラフィックをただちに他のノードにフェイルオーバーするように、ロード・バランサが構成されていることを確認してください。
この項は次のトピックで構成されています。
第6.3.1項「OracleAS Cold Failover Cluster(中間層)用に共有Oracleホーム・インストールを使用して管理を簡略化する」
第6.3.3項「OracleAS Cold Failover Clusterにディスク冗長性を使用してOracleホームの障害を回避する」
第6.3.4項「ポートの割当てを標準化し、OracleAS Cold Failover Clusterインスタンスにポートを事前に割り当てて障害を回避する」
OracleAS Cold Failover Clusterを複数のOracleホーム構成にインストールする場合、J2EEアプリケーションのデプロイも含めて、管理上の変更をすべて2回以上適用する必要があります。共有でないドライブが使用可能なものも含めて、すべてのインストール・タイプに共有ドライブを使用することをお薦めします。
OracleAS Cold Failover Clusterインストールでは、インストーラが共有場所のoraInventory
ディレクトリをポイントするよう指定されている場合を除き、ローカル・ファイル・システム内のoraInventory
ディレクトリが更新されます。OracleAS Cold Failover Clusterインストールに使用しなかったハードウェア・クラスタ内のノードから追加のソフトウェアをインストールすると、コールド・フェイルオーバー・クラスタのインストールは検出されません。Oracle Universal Installerを使用して、OracleAS Cold Failover ClusterのOracleホームを非インストール・ノード上のoraInventory
ディレクトリにアタッチします。
実装の詳細
OracleホームをoraInventory
ディレクトリに関連付けてアタッチするには、次のコマンドを使用します。
./runInstaller -silent -attachHome -invPtrLoc <oraInst.loc location> ORACLE_HOME="ORACLE_HOME_LOCATION" ORACLE_HOME_NAME="ORACLE_HOME_NAME" CLUSTER_NODES="{}" LOCAL_NODE="node_name"
関連項目: Oracle Application Serverのインストレーション・ガイドの第8章「高可用性環境へのインストール: OracleAS Cold Failover Cluster」 |
すべてのアプリケーション・デプロイと最大数のJMSメッセージを保持して、OracleAS PortalとOracle Identity Managementのデータを必要に応じて保持するよう、ディスクのサイズを変更します。なんらかのディスク冗長性を使用して、OracleAS Cold Failover Clusterで使用されるすべてのバイナリ、データおよびメタデータを保護することが重要です。自動ストレージ管理(ASM)を使用して、ASMを使用する他のデータベースと共存している場合は、コールド・フェイルオーバー・クラスタ全体をクラスタ化ASMにアップグレードします。
アクティブ・インスタンスがパッシブ・ノードにフェイルオーバーしたときにポートが使用できない場合、Oracle Application Serverは起動できません。アクティブ/パッシブ・インストールで使用したポートを記録し、staticports.ini
を使用してその他のOracle Application Serverインスタンスをインストールし、該当するポートを未使用にします。
すでに他のアプリケーションを実行しているマシンにパッシブ・ノードを実装する場合は、OracleAS Cold Failover Clusterのポートを構成する際に、既存のコンポーネントと競合しないようにしてください。
パッシブ・ノードで新しいインストールやアプリケーションのデプロイを実行する場合は、新しいコンポーネントのポートがパッシブ・インスタンスと競合しないようにします。パッシブ・コンポーネントに割り当てられたポートは、オペレーティング・システムには空きポートに見える場合がよくあります。
関連項目: Oracle Application Serverのインストレーション・ガイドの第8章「高可用性環境へのインストール: OracleAS Cold Failover Cluster」 |
この項は次のトピックで構成されています。
無効なOracleソフトウェア(無効なOracle DatabaseまたはOracle Application Serverのインストール)をすべて、oraInventory
ディレクトリから削除します。この作業は、Oracle Universal Installerを使用して実行できます。たとえば、あるインスタンスをインストールし、後にOracleホームを削除することによって手動で削除するとします。このインスタンスの情報を、Inventory.xml
ファイルから手動で削除します。そうしないと、OracleAS Guardではインスタンス化と同期化の操作が失敗する場合があります。
プライマリ・サイトとスタンバイ・サイトでは、同じOracleAS Guardポートを使用してください。そうしないと、本番サイトのピアとスタンバイ・サイトのピアとの間における通信を有効にするように、dsa.conf
ファイルを手動で編集する必要があります。
OracleAS Guardではホスト名が対称型である必要があるため、プライマリとスタンバイ両方の環境のシェルが、同じホスト名およびプロンプトで表示される場合があります。本番サイトでの実行が推奨された操作を、誤ってスタンバイ・シェルで実行することがあります。この間違いによって、エラーや矛盾した構成変更が発生します。正しいサイトで操作が行われるように、標準的な決まった方法でコマンド・シェルをラベル付けおよび配置してください。
set trace on all
コマンドを使用すると、OracleAS Guardの動作を非常に詳細にトレースできます。デフォルトでは、トレース・レベルはoff
に設定されています。OracleAS Guardの問題に対処するときは、このタイプのロギングを使用します。
実装の詳細
OracleAS Guardのプロンプトから、次のように入力します。
set trace on | off <traceflags>
関連項目: 『Oracle Application Server高可用性ガイド』の第12章「OracleAS Guard asgctlコマンドライン・リファレンス」 |
この項は次のトピックで構成されています。
Application Server Controlを使用すると、簡単で便利な方法でOracle Application Server Backup and Recovery Toolを構成して、バックアップとリカバリの操作を何度でも実行できます。OracleAS Backup and Recovery Toolの操作ログ・ファイルは、Application Server Controlを使用して表示できます。このインタフェースは、コマンドラインよりエラーが発生しにくくなっています。
実装の詳細
関連項目: 『Oracle Application Server管理者ガイド』の第19.2.4項「Application Server Controlコンソールを使用したOracle Application Serverインスタンスのバックアップの実行」 |
インスタンス・レベルのバックアップには、構成とリポジトリのバックアップが含まれます。リポジトリは、データベース・ベースまたはファイル・ベースのいずれかにできます。この機能を使用すると、構成バックアップとリポジトリ・バックアップとの間で一貫性が確保されます。構成とリポジトリを別々にバックアップするかわりに、できるだけこのオプションを使用してください。
実装の詳細
関連項目: 使用可能なインスタンス・レベルのバックアップ・オプションの詳細は、『Oracle Application Server管理者ガイド』の第19章「バックアップ計画と手順」を参照してください。 |
OracleAS Backup and Recovery Toolを使用すると、ホスト破損のシナリオからのリカバリができます。インストール実行後に、Oracleホーム、OraInventory
ディレクトリ、レジストリ・エントリ、インスタンス・バックアップなどが含まれるイメージ・バックアップを必ず実行してください。この情報を使用して、ホスト破損からリカバリすることができます。
実装の詳細
イメージ・バックアップを作成するには、次のコマンドを使用します。
UNIXの場合:
bkp_restore.sh -m node_backup -o image_backup -P <archive path>
Windowsの場合:
bkp_restore.bat -m node_backup -o image_backup -P <archive path>
関連項目: 『Oracle Application Server管理者ガイド』の第18.6項「OracleAS Backup and Recovery Toolの使用方法のまとめ」および第19章「バックアップ計画と手順」 |
OracleAS Backup and Recovery Toolを使用すると、構成ファイルとデータベースの両方の増分バックアップができます。この場合、変更されたデータのみがバックアップされます。冗長なデータを毎回バックアップしない場合や、バックアップのサイズを小さくする場合に、このオプションを選択してください。
関連項目: 『Oracle Application Server管理者ガイド』の第18.6項「OracleAS Backup and Recovery Toolの使用方法のまとめ」および第19章「バックアップ計画と手順」 |