| Oracle® Fusion Middleware高可用性ガイド 11gリリース2(11.1.2) B69538-02 |
|
 前 |
 次 |
この章では、アクティブ/パッシブ・トポロジを構成して管理する方法について説明します。次の項目が含まれます。
Oracle Fusion Middlewareは、Oracle Fusion Middleware Cold Failover Cluster(コールド・フェイルオーバー・クラスタ)を使用して、すべてのコンポーネントにアクティブ/パッシブ・モデルを提供します。コールド・フェイルオーバー・クラスタ構成では、複数のアプリケーション・サーバー・インスタンスが同じアプリケーション・ワークロードを処理するように構成されますが、アクティブになるインスタンスは常に1つのみです。
2つのノードのコールド・フェイルオーバー・クラスタを使用すると、Oracle Application Server中間層コンポーネントのアクティブ/パッシブ構成の可用性を実現できます。コールド・フェイルオーバー・クラスタでは、1つのノードがアクティブになり、別のノードはスタンバイ・ノードとしてパッシブになります。アクティブ・ノードで障害が発生すると、スタンバイ・ノードがアクティブ化され、中間層コンポーネントはそのノードからクライアント・リクエストの処理を続行します。すべての中間層コンポーネントが新しいアクティブ・ノードにフェイルオーバーします。フェイルオーバー後、障害ノードでは中間層コンポーネントは実行されなくなります。
コールド・フェイルオーバー・クラスタ構成の最も一般的なプロパティは、次のとおりです。
共有記憶域: 共有記憶域は、コールド・フェイルオーバー・クラスタにおける主要プロパティです。アクティブ/パッシブ構成におけるOracle Fusion Middlewareパッシブ・インスタンスは、アクティブ・インスタンスと同じように、Oracleバイナリ、構成ファイル、ドメイン・ディレクトリおよびデータにアクセスできます。コールド・フェイルオーバー・クラスタ構成にあるすべての参加ノードでアクセス可能な記憶域にこれらのアーティファクトを配置することで、このアクセスを構成します。通常、アクティブ・ノードでは共有記憶域がマウントされて、パッシブ・ノードではアンマウント状態になりますが、ノードがアクティブになるとこの記憶域にアクセス可能になります。この共有記憶域は、両方のノードでアクセス可能な二重ポート対応ディスク・デバイスにできますし、NASやSANなどのデバイスベース記憶域にもできます。共有記憶域は通常のファイル・システム上にインストールできます。コールド・フェイルオーバー・クラスタの場合、ボリュームをマウントするノードは一度に1つのみです。
仮想ホスト名: コールド・フェイルオーバー・クラスタ・ソリューションでは、2つのノードが1つの仮想ホスト名と1つの仮想IPを共有します(仮想ホスト名と仮想IPは対応するもので、このガイドでは互換的に使用します)。ただし、この仮想IPを使用できるノードは、常に1つのアクティブ・ノードに限定されます。アクティブ・ノードで障害が発生してスタンバイ・ノードがアクティブになると、仮想IPが新しいアクティブ・ノードに移行します。この新しいアクティブ・ノードでは仮想IPによりすべてのリクエストが処理されます。仮想ホスト名により、デプロイメントの単一システム・ビューが実現されます。コールド・フェイルオーバー・クラスタのデプロイメントは、この仮想IP上でリスニングするように構成されます。たとえば、ハードウェア・クラスタの2つの物理ホスト名がnode1.mycompany.comおよびnode2.mycompany.comである場合、名前cfcvip.mycompany.comによって、このクラスタの単一のビューが提供されます。DNSでは、cfcvip.mycompany.comが仮想IPにマップされます。この仮想IPは、ノード1とノード2との間で変動します。ハードウェア・クラスタを使用すると、仮想IPのフェイルオーバーが管理されるため、どの物理ノードがアクティブでリクエストを実際に処理しているのかを中間層のクライアントでは検出されません。
ハードウェア・クラスタ: 通常、コールド・フェイルオーバー・クラスタ・デプロイメントでは、ハードウェア・クラスタを使用します。ハードウェア・クラスタでは、そのアーキテクチャにおいて共有記憶域と仮想IPが管理されます。これは、これらの共有リソースの高信頼性フェイルオーバーの役割を果たし、堅牢なアクティブ/パッシブ・ソリューションを実現します。ほとんどのコールド・フェイルオーバー・クラスタは、次のもので構成されるハードウェア・クラスタにデプロイされます。
同じサブユニット内にある2つのノード
2つのノード間における高速プライベート・インターコネクト
パブリック・ネットワーク・インタフェース: このインタフェース上でクライアント・リクエストが処理され、仮想IPが有効化されます。
2つのノードからアクセス可能な共有記憶域:これには、クォーラム・デバイスとして機能する共有記憶域と、Oracle Fusion Middlewareインストールとデータベース・インストールの共有記憶域が含まれます。
ノードとコンポーネントの障害を管理するために実行されるクラスタウェア
予定のスイッチオーバーと予定外のフェイルオーバー: コールド・フェイルオーバー・クラスタの一般的デプロイメントは、2つのノードのハードウェア・クラスタです。使用率を最大にするために、通常、これらのノードにはどちらも、実行しているデプロイメントの要素がいくつかあり、必要に応じて一方のノードが他方のノードの要素のバックアップ・ノードの役割を果たします。たとえば、あるノードでアプリケーション層(WebLogicコンテナ)が実行され、別のノードでWeb層(Oracle HTTP Server)が実行されるデプロイメントなどがあります。どちらか一方のノードをメンテナンスのために停止した場合や、どちらか一方のノードで障害が発生した場合には、停止していないノードが現在のサービスのホスト処理が継続しながら、停止したノードのサービスのホスト処理を実行します。
スタンバイ・ノードにスイッチオーバーするための高レベル手順は次のとおりです。
1次ノード上の中間層サービスを停止します(そのノードが利用可能な場合)。
現在のアクティブ・ノードからパッシブ・ノードへ仮想IPをフェイルオーバーさせます。現在のノードでそれを停止してから、パッシブ・ノードで有効化し起動します。
現在のアクティブ・ノードからパッシブ・ノードへ共有ディスクをフェイルオーバーさせます。この操作には、現在のノードから共有ディスクをアンマウントしてからパッシブ・ノードにマウントする操作が含まれます。
パッシブ・ノード上で中間層サービスを起動し、アクティブにします。
フェイルオーバー管理には、次の2つの方法があります。
クラスタ・マネージャ機能を使用した自動フェイルオーバー
クラスタ・マネージャではサービスを提供しており、これによって、サービスの状態を監視するパッケージを開発できます。サービスやノードの停止(計画停止の操作または計画外停止の操作)が検出されると、あるノードから別のノードへサービスが自動的にフェイルオーバーします。フェイルオーバー前に、所定のノード上でサービスの再起動を試みるようにパッケージを開発できます。同様に、アクティブ・ノード自体が停止した場合、クラスタウェアでノードの停止状態が検出され、指定のパッシブ・ノード上で起動を試行できます。任意のクラスタウェアを使用してこれらの操作を自動化すると、完全な自動フェイルオーバー機能を実現できます。
Oracle Fusion MiddlewareではOracle Clusterwareを使用してこの機能を実現します。Oracle Cluster Ready Servicesによるコールド・フェイルオーバー・クラスタ環境の管理の詳細は、第13章「Oracle Cluster Ready Servicesの使用」を参照してください。クラスタ・フェイルオーバーの管理には、任意の利用可能クラスタウェアを使用できます。
手動フェイルオーバー
このアプローチでは、計画スイッチオーバーの手順を手動で実行します(障害の検出およびフェイルオーバーは手動です)。この方法では、長時間サービスが使用できなくなる可能性があります。
アクティブ/パッシブ・デプロイメントの場合、通常、サービスが停止する時間は短時間です。これは、同じノード上でインスタンスを再起動するのに要する時間、またはパッシブ・ノードにインスタンスをフェイルオーバーするに要する時間になります。
アクティブ/パッシブ・トポロジ: 長所
可用性の向上
アクティブ・インスタンスに障害が発生した場合や、アクティブ・インスタンスをオフラインにする必要がある場合、いつでも同一構成のパッシブ・インスタンスで処理の引継ぎができます。この構成では、通常の単一インスタンス型デプロイメントより可用性のレベルが高くなります。また、アクティブ/パッシブ・デプロイメントは、ハードウェアの計画メンテナンス操作や計画外メンテナンス操作に対して可用性と保護機能を実現します。計画メンテナンスのためにノードを停止する必要がある場合、パッシブ・ノード上のミドルウェア・サービスを起動できます。適切な時点で元のノードへスイッチバックします。
運用コストの削減
アクティブ/パッシブ構成では、1つのプロセス・セットのみが稼働して、リクエストを処理します。アクティブ・インスタンスの管理では通常、複数のアクティブ・インスタンスの配列の管理より低コストです。
コールド・フェイルオーバー・クラスタ・トポロジの実装はそれほど難しくありません。それらのクラスタではロード・バランサが不要ですが、アクティブ/アクティブ・トポロジでは必要になるからです。
ロード・バランシング・アルゴリズム、クラスタリング、レプリケーションなどのオプションを構成する必要がないため、コールド・フェイルオーバー・クラスタ・トポロジの実装は、アクティブ/アクティブ・トポロジほど難しくありません。
アクティブ/パッシブ・トポロジでは、アクティブ/アクティブ・トポロジより正確に、1つのインスタンスのトポロジがシミュレートされます。
アプリケーションの非依存性
一部のアプリケーションは、アクティブ/アクティブ構成に適さない場合があります。このようなアプリケーションには、アプリケーションの状態への依存度が高いアプリケーションや、ローカルに格納された情報への依存度が高いアプリケーションなどあります。シングルトン・アプリケーションには、アクティブ/パッシブ・デプロイメントが適しています。アクティブ/パッシブ構成では、常に1つのインスタンスのみがリクエストを処理します。
アクティブ/パッシブ・トポロジ: 短所
アクティブ/パッシブ・トポロジは、アクティブ/アクティブ・トポロジほどスケーラビリティが高くありません。ノードをトポロジに追加して処理能力を増強することはできません。
HTTPセッションの状態およびEJBステートフル・セッションBeanからの状態情報は、レプリケートされないため、ノードが予期せずに終了すると失われます。そのような状態は、データベースまたは共有記憶域にあるファイル・システムに永続的に保持されます。ただし、これは余分なオーバーヘッドを必要とするため、単一ノードのコールド・フェイルオーバー・クラスタ・デプロイメントのパフォーマンスに影響する可能性があります。
アクティブ/パッシブ・デプロイメントでは、単一ノードのデプロイメントよりも停止時間が短縮されます。ただし、アクティブ/アクティブ・デプロイメントでは、さらに停止時間が短縮されます。
Oracle Fusion Middlewareコンポーネントには、様々な種類の、Java EEコンテナにデプロイされたコンポーネントと非Java EEコンポーネントがあります。Oracle Internet Directory、Oracle Virtual DirectoryおよびOracle Reportsはシステム・コンポーネントです。Oracle SOA SuiteやOracle WebCenterポータルは、WebLogic ServerにデプロイされるJava EEコンポーネントです。
管理コンソールとOracle Enterprise Manager Fusion Middleware ControlもWebLogicコンテナにデプロイされます。Java EEコンポーネントとシステム・コンポーネントのどちらも、コールド・フェイルオーバー・クラスタ環境にデプロイでき、同じシステム上または異なるシステム上で共存させることができます。同じシステムに配置すると、同じ仮想IPを共有して単一ユニットとしてフェイルオーバーするように構成できますし、別々の仮想IPを使用して個別にフェイルオーバーするようにも構成できます。ほとんどのOracle Fusion Middlewareデプロイメントでは、リポジトリ作成ユーティリティ(RCU)を使用して作成されたコンポーネント・メタデータ用やアプリケーション・データ用にデータベースが使用されます。多くの場合、コールド・フェイルオーバー・クラスタ中間層デプロイメントでは、同じクラスタにデプロイされたコールド・フェイルオーバー・クラスタ・データベースが使用されます。一般的なデプロイメントには、同じハードウェア・クラスタにある異なる共有ディスクと異なるVIPを使用して別々のフェイルオーバー・ユニットとして構成されたコンポーネントが2つあります。
Oracle Fusion Middlewareにおいて、アクティブ/パッシブ・トポロジを作成するには、次の手順を実行します。
単一インスタンス構成としてコンポーネントをインストールします。このインスタンスをコールド・フェイルオーバー・クラスタ・デプロイメントに変換する予定がある場合、共有ディスクを使用してインストールします。つまり、Middlewareホーム、インスタンス・ホーム(システム・コンポーネントの場合)およびドメイン・ディレクトリ(WebLogicデプロイメントの場合)を共有ディスク上に配置します。1つのユニットとしてフェイルオーバーするものはすべて、共有ディスク上に配置する必要があります。
インストール後、デプロイメントをコールド・フェイルオーバー・クラスタ・デプロイメントに変換し、仮想IP上でリスニングするように構成します。この仮想IPは現在のアクティブ・ノード上で構成します。障害が発生すると、Oracle Fusion Middlewareデプロイメントとともにパッシブ・ノードにフェイルオーバーします。
この一般的手順は、コールド・フェイルオーバー・クラスタのOracle Databaseに適用されます。たとえば、Oracle Databaseインスタンスを単一インスタンスのデプロイメントとしてインストールしてから、コールド・フェイルオーバー・クラスタ用に変換します。コールド・フェイルオーバー・クラスタのOracle Fusion Middlewareデプロイメントでは、Oracle Real Application Cluster(Oracle RAC)データベースも使用できます。
次の各項では、インストール後の構成手順について説明します。この手順によって単一インスタンスのデプロイメントをコールド・フェイルオーバー・クラスタ・デプロイメントに変換します。
この章の残りの部分では、Oracle Fusion Middlewareスイートの個別コンポーネントごとに、コールド・フェイルオーバー・クラスタを変換する方法について説明します。最初の項では、基本インフラストラクチャ・コンポーネントの手順について詳細に説明します。そしてその後続の項では、Oracle Fusion Middlewareの個別コンポーネントの手順について詳細に説明します。Oracleインスタンスやドメインなど、あらゆるデプロイメントでは、これらの複数のコンポーネントがマシンにインストールされます。インスタンスやドメインの全体を変換する手順は次のとおりです。
フェイルオーバー・ユニットに組み込むコンポーネントを決定します。
それらを同じ共有ディスク上にデプロイします。
|
注意: Oracle Fusion Middlewareコンポーネントのインストールとデプロイの詳細は、それぞれのFusion Middlewareコンポーネントのインストレーション・ガイドを参照してください。 |
このフェイルオーバー・ユニットで使用する仮想IPを決定します。通常、すべてのコンポーネントで同じ仮想IPを使用しますが、別々のIPも使用できます。ただし、すべてのコンポーネントをまとめてフェイルオーバーさせます。
個々のコンポーネントごとに変換手順を適用して、デプロイメント全体を変換します。インストールのコールド・フェイルオーバー・クラスタ変換には複数の項の手順が適用されるため、必ず次の順序で変換を実行してください。
管理サーバーまたはEnterprise Managerインスタンス(該当する場合)を変換します。
デプロイメントにあるすべての管理対象サーバーを変換します。
Oracleインスタンス(非Java EEデプロイメント)を変換します。
前述のように、コールド・フェイルオーバー・クラスタ・デプロイメントでは、2つ以上のノードがデプロイメントに含まれます。インストールはこれらのノードの1つで行われ、もう一方のノードはパッシブ・ノードです。両方のノードの要件は、次のとおりです。
各ノードはオペレーティング・システム・レベルのあらゆる面で同じである必要があります。たとえば、オペレーティング・システム、バージョンおよびパッチ・レベルが同一である必要があります。
各ノードはハードウェアの特性が同じである必要があります。それによって、通常の運用中とフェイルオーバー時のパフォーマンスが予測可能になります。通常の役割を処理できる処理能力に加えて、フェイルオーバー・シナリオに対応するために対応が必要な負荷が増大しても処理できるように、各ノードを設計することをお薦めします。停止シナリオ中におけるパフォーマンスの低下がサービス・レベル合意(SLA)で許容される場合のみ、その必要はありません。
通常の運用中とフェイルオーバー時のどちらでも同じノードに対して共有記憶域をマウントできるように、各ノードで同じマウント・ポイントが解放されている必要があります。
2つのノードのユーザーIDとグループIDが類似しており、インスタンスを所有するユーザーのユーザーIDとグループIDが両方のノードで同じである必要があります。
oraInventoryの場所が両方のノードで同じであり、インスタンスまたはドメインの所有者のアクセス・レベルが類似している必要があります。oraInst.locファイルの場所だけでなくbeahomelistファイルの場所も同じである必要があります。
指定インスタンスでは、現在アクティブになっているマシンには関係なく、同じリスニング・ポートを使用するため、コールド・フェイルオーバー・クラスタのインスタンスで使用するポートが両方のノードで解放されていることを確認します。
|
注意: 変換を開始する前に、ドメイン全体のバックアップを実行してください。また、編集前にローカル・バックアップ・ファイルを作成することをお薦めします。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。次のバックアップを作成することをお薦めします。
|
次のリストは、この章で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware(FMW)が常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle FMW Suite (SOA、WebCenter、Identity Managementなど)がインストールされている場所を指します。
ORACLE_COMMON_HOME: すべてのOracle Fusion Middlewareソフトウェア・スイートに共通するバイナリおよびライブラリ・ファイルを含むOracleホームです。特に、Oracle共通ホームには、Oracle Enterprise Manager Fusion Middleware Control(Fusion Middlewareの管理に使用される)に必要なファイルとOracle Java Required Files(JRF)が含まれています。
DOMAIN_HOME: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。
ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどのシステム・コンポーネントが1つ以上含まれています。Oracleインスタンス・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルが格納されています。
/localdisk: /localdiskは、FMWインストール(MW_HOMEまたはDOMAIN_HOME)がローカル・ディスク上にある場合のディレクトリ・ツリーのルートを表します。それはローカル・ディスクのMW_HOMEを表すために使用されます。
/shareddisk: /shareddiskは、FMWインストール(MW_HOMEまたはDOMAIN_HOME)がCFC構成のいずれかのノードによってマウントされている共有記憶域システム上にある場合に、ディレクトリ・ツリーのルートを表します。それは、共有ディスクのMW_HOMEを表すために使用されます。
これらのディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。
ORACLE_BASE: /u01/app/oracle
MW_HOME(アプリケーション層): ORACLE_BASE/product/fmw
ORACLE_COMMON_HOME: MW_HOME/oracle_common
WL_HOME: MW_HOME/wlserver_10.3
次の表は、いくつかのOracle Fusion Middlewareコンポーネントで使用されるOracleホーム、ドメイン・ホーム、およびドメイン・ディレクトリの値の例を示します。
| コンポーネント | ORACLE_HOME | DOMAIN_HOME | ドメイン・ディレクトリ |
|---|---|---|---|
|
Identity Management |
MW_HOME/idm |
IDMDomain |
MW_HOME/user_projects/domains/IDMDomain |
|
Oracle SOA |
MW_HOME/soa |
SOADomain |
MW_HOME/user_projects/domains/SOADomain |
|
WebCenter |
MW_HOME/wc |
WCDomain |
MW_HOME/user_projects/domains/WCDomain |
|
Oracle Portal |
MW_HOME/portal |
PortalDomain |
MW_HOME/user_projects/domains/PortalDomain |
|
Oracle Forms |
MW_HOME/forms |
FormsDomain |
MW_HOME/user_projects/domains/FormsDomain |
|
Oracle Reports |
MW_HOME/reports |
ReportsDomain |
MW_HOME/user_projects/domains/ReportsDomain |
|
Oracle Discoverer |
MW_HOME/disco |
DiscoDomain |
MW_HOME/user_projects/domains/DiscoDomain |
|
Web層 |
MW_HOME/web |
適用なし |
適用なし |
|
ディレクトリ層 |
MW_HOME/idm |
適用なし |
適用なし |
|
WebCenter Content |
MW_HOME/wcc |
WCCDomain |
MW_HOME/user_projects/domains/WCCDomain |
アプリケーション・ディレクトリの場所: ORACLE_BASE/admin/domain_name/appsなど
Oracleインスタンスの場所: ORACLE_BASE/admin/instance_nameなど
1つのユニットとしてフェイルオーバーするディスク上のすべてのエンティティは、同じマウント・ポイント上に配置することをお薦めします。しかし、別の共有記憶域に格納して、別のマウント・ポイントに配置することも可能です。共有記憶域のマウント・ポイントはORACLE_BASEにすることをお薦めします。ほとんどの場合、それによって、フェイルオーバー・ユニットのすべての永続ビットが同じ共有記憶域に格納されます。1つのノードに複数のコールド・フェイルオーバー・クラスタが存在する場合に、それぞれが他のクラスタと独立してフェイルオーバーすると、このようなフェイルオーバー・ユニットのそれぞれに対して異なるマウント・ポイントが存在します。
Oracle Fusion Middlewareデプロイメントは、すべての製品セットに共通する基本インフラストラクチャ・コンポーネントで構成されます。この項では、これらのコンポーネントのコールド・フェイルオーバー・クラスタ変換手順について説明します。
コールド・フェイルオーバー・クラスタ構成では、2つの管理サーバー・トロポジがサポートされています。次の各項では、これら2つのトポロジについて説明します。また、コールド・フェイルオーバー・クラスタ変換用に管理サーバーを準備するためにインストールと構成を行う手順についても説明します。
図12-1は、Oracle Cold Failover Clusterにおける最初のサポート対象トポロジを示しています。
図12-1では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。Middlewareホームとドメイン・ディレクトリは、ある時点でノード1またはノード2にマウントされている共有ディスク上にあります。Middlewareホームとドメイン・ディレクトリは両方とも、同じ共有ディスク上、またはいっしょにフェイルオーバーできる複数の共有ディスク上にあります。複数のアプリケーションまたは環境用に複数のFusion Middlewareドメインがある企業では、管理サーバーの高可用性にはこのトポロジが最適です。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。それぞれの管理サーバーでは、その仮想IPおよび一連の共有ディスクを使用して、ドメイン・サービスの高可用性を実現できます。
このトロポジのアプリケーション・サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。
Middlewareホームのインストール
このインストールには、共有ディスク上におけるOracleホーム、WebLogicホームおよびドメイン・ホームが含まれます。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。ストレージ・サブシステムにおいて複数のノードでの同時マウントが可能な場合でも、これが推奨構成になります。これは、通常の単一インスタンス型インストールとして実行されます。管理サーバー(およびEnterprise Manager)の単体インストールの詳細は、当該コンポーネントに関連する章を参照してください。各スイートの全体的な手順は次のとおりです。
For Oracle SOA、Oracle WebCenterポータルまたはOracle WebCenter Contentの場合:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
Oracle SOA、Oracle WebCenterポータルOracle WebCenter ContentのOracleホームをインストールします。
『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteインストレーション・ガイド』、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』またはOracle WebCenter Contentインストレーション・ガイドを参照してください。
構成ウィザードを起動して、管理サーバーのみのドメインを作成します。
「ドメイン・ソースの選択」画面で、次を選択します。
以下の製品をサポートするために、自動的に構成されたドメインを生成する
Enterprise ManagerとOracle JRFを選択します。
Oracle Identity Managementの場合:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
Oracle Identity Management 11gのインストーラで、ドメイン作成オプションを使用してIDMドメインをインストールおよび構成します。「コンポーネントの構成」画面で、Enterprise Manager(デフォルトで選択されています)以外のすべての選択を解除します。
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
Oracle Portal、Forms、ReportsおよびDiscovererの場合:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
Oracle Fusion Middleware 11g Portal、Forms、ReportsおよびDiscovererのインストーラで、ドメイン作成オプションを使用してクラシック・ドメインをインストールおよび構成します。「コンポーネントの構成」画面で、Enterprise Managerが選択されていることを確認します。
|
注意: この場合、製品コンポーネント用に1つ以上の管理対象サーバーがこのプロセスでインストールされます(管理サーバー単独のインストールはできません)。この管理対象サーバーは、該当コンポーネントの手順に従ってCFCに変換する必要があります。これは、管理サーバーのユニットと同じフェイルオーバー・ユニットの一部になります。 |
Oracle Business Intelligenceの場合:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
Oracle Fusion Middleware 11g Business Intelligenceインストーラで、BIシステムを新規作成するオプションを使用して、Business Intelligenceドメインのインストールと構成を実行します。
|
注意: この場合、製品コンポーネント用に1つ以上の管理対象サーバーがこのプロセスでインストールされます(管理サーバー単独のインストールはできません)。この管理対象サーバーは、該当コンポーネントの手順に従ってCFCに変換する必要があります。これは、管理サーバーのユニットと同じフェイルオーバー・ユニットの一部になります。 |
コールド・フェイルオーバー・クラスタ用の管理サーバーの構成
コールド・フェイルオーバー・クラスタ用に管理サーバーを構成する手順は次のとおりです。
rootユーザーとして次のコマンドを使用して、仮想IPをプロビジョニングします。
Linuxの場合
/sbin/ifconfig interface:index IP_Address netmask netmask /sbin/arping -q -U -c 3 -I interface IP_Address
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIPアドレスが有効化されます。
/sbin/ifconfig eth0:1 IP_Address netmask 255.255.224.0 /sbin/arping -q -U -c 3 -I eth0 IP_Address
Windowsの場合:
netsh interface ip add address interface IP Address netmask
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、"Local Area Connection"のインタフェースでIPアドレスが有効化されます。
netsh interface ip add address "Local Area connection" IP_Address 255.255.224.0
第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
仮想IP上でコンソールにアクセスして、管理サーバーの変換を検証します。
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
次の手順に従って、管理サーバーを2番目のノードに手動でフェイルオーバーさせます。
|
注意: 管理サーバーがノード・マネージャによって管理されている場合は、コールド・フェイルオーバー・クラスタのノードマネージャを有効にする必要があります。 |
管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。
Middlewareホームとドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。
記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。
rootユーザーとして次のコマンドを使用して、ノード1で仮想IPを無効化します。
Linuxの場合:
/sbin/ifconfig interface:index down
ここで、IP Addressは仮想IPです。次の例では、eth0インタフェースでIPアドレスが無効化されます。
/sbin/ifconfig eth0:1 down
Windowsの場合:
netsh interface ip delete address interface IP_Address
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、Local Area ConnectionのインタフェースでIPアドレスが有効化されます。
netsh interface ip delete address "Local Area connection" IP_Address
ステップ1と同様のコマンドを使用して、ノード2で仮想IPを有効化します。
管理サーバー・プロセスを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。
管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。
図12-2は、Oracle Cold Failover Clusterにおける2番目のサポート対象管理サーバー・トポロジを示しています。
図12-2では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。管理サーバーが使用するドメイン・ディレクトリは、共有ディスク上にあります。これは必須です。この共有ディスクは、ある時点でノード1またはノード2にマウントされます。ソフトウェアを格納するMiddlewareホーム(WebLogicホームとOracleホーム)は、共有ディスク上でなくてもかまいません。ローカル・ディスクにも配置できます。管理サーバーをノード1で実行する場合は、ソフトウェアにノード1のMiddlewareホームを使用し、ノード2で実行する場合は、ノード2のMiddlewareホームを使用します。2つのMiddlewareホームは、デプロイされた製品、Oracleホームおよびパッチに関して同じ状態に維持する必要があります。どちらの場合も、共有ドメイン・ディレクトリやドメイン・ホームで利用できる構成を使用します。これは共有されるため、フェイルオーバーの前後で同じ構成が使用されるようになります。
この共有ドメイン・ディレクトリでは、他の管理対象サーバーも実行できます。また、管理サーバー専用にも使用できます。ドメイン・ディレクトリを他の管理対象サーバーと共有する場合、管理サーバーがフェイルオーバーされるときのために、それらのフェイルオーバーに関して適切に考慮する必要があります。考慮事項の一部を次に示します。
読取りや書込みを行うために複数のノードで同時に共有記憶域をマウントできる場合は、管理サーバーのドメイン・ディレクトリを他の管理対象サーバーと共有できます。また、管理対象サーバーとは別にフェイルオーバーすることもできます。管理サーバーをフェイルオーバーして、指定ノードで独立して管理対象サーバーの実行を継続できます。これが可能な理由は、この場合、管理サーバーはVIPのフェイルオーバーのみを必要とし、共有ディスクのフェイルオーバーは必要としないためです。管理対象サーバーは、引き続きドメイン・ディレクトリやドメイン・ホームを利用できます。このような記憶域の例として、クラスタ・ファイル・システムに接続されたNASやSAN/Directなどの記憶域があります。
一度に1つのノードのみ共有記憶域をマウントできる場合、管理サーバーのドメイン・ディレクトリを管理対象サーバーと共有することは、管理サーバーがフェイルオーバーされると、同じドメイン・ディレクトリから切り離される管理対象サーバーを停止する必要があることを意味します。
このトポロジでは、ハードウェア・クラスタを使用するとフェイルオーバーの自動化に役立ちます(適切に構成されたクラスタウェアを使用した場合)。ただし、これは必須ではありません。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。各管理サーバーでそれぞれ固有の仮想IPと共有ディスク・セットを使用して、ドメイン・サービスの高可用性を実現できます。
このトポロジは、Oracle SOA SuiteおよびOracle WebCenterポータルSuiteに対してのみサポートされています。
|
注意: Oracle Identity Managementについては、コールド・フェイルオーバー・クラスタのための代替トポロジもサポートされています。詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。 |
このトロポジの管理サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。
Middlewareホームのインストール
OracleホームとWebLogicホームを含むMiddlewareホームを、ドメインにある2つのノードに個別にインストールします。管理サーバー・ドメイン・ディレクトリは共有ディスク上に作成します。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。これは、通常の単一インスタンス型インストールです。管理サーバーおよびEnterprise Managerの単体インストールの詳細は、製品スイートを参照してください。Middlewareホームをインストールする手順は次のとおりです。
Oracle SOA SuiteまたはOracle WebCenterポータルの場合:
ノード1にWebLogic Serverソフトウェアをインストールします。
ノード1にSOAまたはWebCenterのOracleホームをインストールします。
ノード2でステップ1とステップ2を繰り返します。
ノード1で構成ウィザードを起動して、管理サーバーのみのドメインを作成します。
「ドメイン・ソースの選択」画面で、次を選択します。
以下の製品をサポートするために、自動的に構成されたドメインを生成する
Enterprise ManagerとOracle JRFを選択します。
「ドメイン名と場所の指定」画面で、ドメイン名を入力し、ドメイン・ディレクトリがディレクトリと共有記憶域のマウント・ポイントに一致していることを確認します。
コールド・フェイルオーバー・クラスタ用のMiddlewareホームの構成
コールド・フェイルオーバー・クラスタ用にMiddlewareホームを構成する手順は次のとおりです。
仮想IPをプロビジョニングします。例:
Linuxの場合:
/sbin/ifconfig eth0:1 IP_Address netmask netmask /sbin/arping -q -U -c 3 -I eth0 IP_Address
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIPアドレスが有効化されます。
/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0 /sbin/arping -q -U -c 3 -I eth0 130.35.46.17
Windowsの場合:
netsh interface ip add address interface IP_Adress netmask
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、"Local Area Connection"のインタフェースでIPアドレスが有効化されます。
netsh interface ip add address "Local Area connection" 130.35.46.17 255.255.224.0
第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
管理サーバーを2番目のノードに手動でフェイルオーバーさせます。
管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。
Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。
記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。
ノード1で仮想IPを無効化します。
Linuxの場合:
/sbin/ifconfig interface:index down
次の例では、eth0インタフェースでIPアドレスが無効化されます。
/sbin/ifconfig eth0:1 down
Windowsの場合:
netsh interface ip delete address interface addr=IP Address
この場合、IP Addressは仮想IPアドレスです。次の例では、'Local Area Connection'のインタフェースでIPアドレスが有効化されます。
netsh interface ip delete address 'Local Area connection' addr=130.35.46.17
ノード2で仮想IPを有効化します。
次のコマンドを使用して、管理サーバー・プロセスを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。
管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。
共有ディスクにインストールされている管理サーバーをノード1から変換するには、この項の手順に従ってください。この手順ではコンテナを変換するため、管理コンソールとOracle Enterprise Manager Fusion Middleware Controlの両方がコールド・フェイルオーバー・クラスタ用に変換されます。それにより、このコンテナにデプロイされるOWSM-PMなどの他のコンポーネントも、コールド・フェイルオーバー・クラスタ対応になります。これらすべてのサービスのアドレスがcfcvip.mycompany.comに変換されます。インストール後、コールド・フェイルオーバー・クラスタでないインスタンスをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。
管理コンソールにログインします。
仮想ホスト用のノードを作成します。
「環境」、「マシン」の順に選択します。
「チェンジ・センター」で、「ロックして編集」、「新規」の順にクリックします。
「名前」フィールドにcfcvip.mycompany.comと入力します。
|
注意: 「リスニング・アドレス」フィールドはlocalhostに設定したままにします(CFCソリューションはこの設定に依存します)。これを仮想IPアドレスまたはその他の値に変更しないでください。 |
「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。
「次」、「終了」の順にクリックします。
「マシンのサマリー」タブで、作成したばかりのマシンの名前をクリックします。
「サーバー」タブをクリックしてから、「追加」をクリックします。
サーバー選択のドロップダウン・リストで、「AdminServer」が選択されていることを確認します。
「変更のアクティブ化」をクリックします。
cfcvip.mycompany.com上でリスニングするように管理サーバーを構成します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
管理サーバー(AdminServer)をクリックします。
リスニング・アドレスをcfcvip.mycompany.comに変更します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理サーバーを再起動します。
|
注意: 通常、管理サーバーのコールド・フェイルオーバー・クラスタへの変換はドメイン作成時に実行されることが期待されるため、ドメインにおいて他の部分への変更は行われないものと考えられます。この変更がドメイン作成後に行われ、他のコンポーネントがドメインにインストールされている場合、次の管理サーバー変換項で説明している手順に従ってください。 |
管理サーバーのクライアント側構成の変更
ドメインにある既存エンティティでは、管理サーバーとの通信に新しいアドレスを使用する必要があります。たとえば、管理対象サーバーを手動で起動する際、管理サーバーのアドレスをcfcvip.mycompany.comとして指定します。
INSTANCE_HOME/config/OPMN/opmnディレクトリにあるinstance.propertiesファイルで、次の変更を行います。
adminHost=cfcvip.mycompany.com
OPMN登録コマンドを使用して、コールド・フェイルオーバー・クラスタ管理サーバーにOracleインスタンスを登録したり再登録する場合は、opmnctlコマンドのAdminHostの場所で管理サーバーの新しい場所(cfcvip.mycompany.com)を参照します。
Oracle Enterprise Managerのクライアント側構成の変更
Enterprise Managerは管理サーバーが稼働する同じコンテナの一部であるため、管理サーバーをコールド・フェイルオーバー・クラスタに変換すると、Enterprise Managerも変換されます。ドメインの一部として構成されたEnterprise Managerエージェントが存在する場合は、それらのエージェント構成でEnterprise Managerの新しい場所を使用する必要があります。Enterprise Managerの新しい場所を構成するには、エージェントごとに次の手順を行います。
ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_asinst_ 1/sysman/configに設定します。
emd.propertiesファイルで、次の属性内のnode1.mycompany.comをcfcvip.mycompany.comに変更します。
REPOSITORY_URL
EmdWalletSrcUrl
次のコマンドを使用して、エージェントを停止してから再起動します。
cd INSTANCE_HOME/EMAGENT/emagent_dir/bin
./emctl stop agent
./emctl start agent
./emctl status agent
これによってリポジトリのURLが表示されます。このURLは新しいホストを指します。
すべてのOracle Fusion Middlewareコンポーネントは、管理対象サーバーにデプロイされます。WebLogic Serverにデプロイされたアプリケーションやコンポーネントをコールド・フェイルオーバー・クラスタに変換する際の重要な手順としては、使用する仮想IPにリスニング・アドレスを変更することがあります。この変更は、対象のコンポーネントがデプロイされている特定の管理対象サーバーに対して実行します。この変更には、管理コンソールまたはWLSTコマンドを使用できます。
次の例では、WLS_EXMPLという管理対象サーバーをコールド・フェイルオーバー・クラスタに変換する一般的手順について説明します。これらの手順は、Fusion Middlewareコンポーネントの管理対象サーバーに適用されます。
次の手順で、cfcvip.mycompany.comはコールド・フェイルオーバー・クラスタに使用する仮想IPで、WLS_EXMPLは変換対象となる管理対象サーバーです。
管理コンソールにログインします。
仮想ホストのマシンを作成します。
「環境」→「マシン」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックし「新規」をクリックします。
|
注意: 管理サーバーの変換で別のVIPを使用した場合にのみ、新しいマシンを作成します。その場合、手順gに進みます。 |
「名前」フィールドでは、cfcvip.mycompany.comと入力します。
「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。
「Next」をクリックして、「Finish」をクリックします。
ノード・マネージャを変換する場合は、次の手順を実行する必要があります。
新しく作成したマシンをクリックします。
「ノード・マネージャ」タブをクリックします。
リスニング・アドレスをcfcvip.mycompany.comに更新します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
WLS_EXMPL管理対象サーバーを停止します。
「環境」→「サーバー」を選択します。
「制御」をクリックします。
「WLS_EXMPL」を選択します。
「停止」ドロップダウン・メニューで、「ただちに強制停止」を選択します。
WLS_EXMPL管理対象サーバーを仮想ホストのマシンに関連付けます。
「環境」→「サーバー」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「構成」をクリックします。
「WLS_EXMPL」を選択します。
「マシン」では、プルダウン・メニューから新規作成マシンを選択して割り当てます。
「リスニング・アドレス」にcfcvip.mycompany.comと入力します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理対象サーバーWLS_EXMPLを起動します。
「環境」→「サーバー」を選択します。
「制御」をクリックします。
「WLS_EXMPL」を選択します。
「起動」をクリックします。
WLSTコマンドを使用してもOracle WebLogic管理対象サーバーを変換できます。
次の手順を実行する前に、変換対象となる管理対象サーバーを停止することをお薦めします。
オンライン・モード(WebLogic Server管理サーバーが稼働している状態)でWLSTコマンドラインを使用して管理対象サーバーを変換する手順は次のとおりです。
コマンドラインで次のように入力します。
WL_HOME/server/bin/setWLSEnv.sh WL_HOME/common/bin/wlst.sh
WLSTで、次のコマンドを入力します。
wls:/offline>connect(<username>,<password>,<AdminServer location>)
例:
wls:/offline>connect('WebLogic', 'welcome1', 't3://admin.mycompany.com:7001')
wls:/DomainName/serverConfig> edit()
wls:/DomainName/edit> startEdit()
wls:/DomainName/edit !> create('cfcvip.mycompany.com','Machine')
wls:/DomainName/edit !> cd('Machines/cfcvip.mycompany.com/NodeManager/cfcvip.mycompany.com')
wls:/DomainName/edit !> set('ListenAddress', 'cfcvip.mycompany.com')
wls:/DomainName/edit !>cd ('Servers')
wls:/DomainName/edit/Servers !>cd ('WLS_EXMPL')
wls:/DomainName/edit/Servers/WLS_EXMPL !>set('Machine',' cfcvip.mycompany.com ')
wls:/DomainName/edit/Servers/WLS_EXMPL !>set('ListenAddress',' cfcvip.mycompany.com ')
wls:/DomainName/edit/Servers/WLS_EXMPL !> save()
wls:/DomainName/edit/Servers/WLS_EXMPL !> activate()
wls:/DomainName/edit/Servers/WLS_EXMPL> exit()
管理対象サーバーを停止してから(停止していない場合)、再起動します。
管理対象サーバーの変換の完了後に、このサーバーに対するすべての参照で新しいリスニング・アドレスcfcvip.mycompany.comが使用されていることを確認します。Oracle HTTP Serverがこの管理対象サーバーのフロントエンドとして機能している場合、この管理対象サーバー上のアプリケーションを参照しているマウント・ポイントでmod_wls_ohs構成をすべて変更して、新しいリスニング・エンド・ポイントにルーティングします。
コールド・フェイルオーバー・クラスタ環境ではノード・マネージャを使用できます。次の構成が可能です。
仮想IP上で同様にリスニングし、コールド・フェイルオーバー・クラスタ・スタックの残りの部分とともにフェイルオーバーするノード・マネージャの使用:ASCRSベースのデプロイメントでは、コールド・フェイルオーバー・クラスタのFusion Middlewareインスタンスが稼働しているMiddlewareホームと同じMiddlewareホームにノード・マネージャが属している必要があります。このノード・マネージャはこのFusion Middlewareインスタンス専用であることが前提になります。この場合は、ローカル・ホストでリスニングするネットワーク・チャネルを別に構成することをお薦めします。他のポートでリスニングするボックス上に他のノード・マネージャを共存させることができます。詳細は、第13章「Oracle Cluster Ready Servicesの使用」を参照してください。
コールド・フェイルオーバー・クラスタ・スタックの残りの部分とともにフェイルオーバーしないノード・マネージャ。この場合、ノード・マネージャはコールド・フェイルオーバー・クラスタ用に構成されずに、コールド・フェイルオーバー・クラスタの仮想IPだけでなく、マシン上のすべてのIPをリスニングします。また、フェイルオーバー・ノードには、同様に構成されているノード・マネージャが配置され、構成済になっています。WebLogicインスタンスに関連付けられたノードは、ローカル・ホスト上のノード・マネージャと通信します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』を参照してください。
コールド・フェイルオーバー・クラスタの場合、フェイルオーバー発生時にポートが競合しないように、ポートの使用を計画することをお薦めします。
ノード・マネージャをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。
ノード・マネージャが実行されている場合は停止します。
ノード・マネージャが最初に起動された後にのみ、nodemanager.propertiesファイルは作成されます。
必要に応じて、ノード・マネージャを再起動します。
WL_HOME/common/nodemanager/ディレクトリにあるnodemanager.propertiesファイルで、ListenAddressを仮想IPに設定します。
例:
ListenAddress=cfcvip.mycompany.com
WL_HOME/server/binディレクトリにあるStartNodeManager.shファイルを使用して、ノード・マネージャを再起動します。ASCRSベースのデプロイメントの場合は、WL_HOME/server/bin/cfcStartNodemanager.shを使用してノード・マネージャを起動します。
詳細は、第13章「Oracle Cluster Ready Servicesの使用」を参照してください。
|
注意: 必要に応じて、 |
|
注意: WebLogic管理対象サーバーおよび管理サーバーでは、ホスト名の検証は特定のインストールで有効化または無効化できます。検証が有効でノード・マネージャがこれらのインスタンスを管理しているCFCインストールでは、ホスト名の検証の手順の中で仮想IPの |
Oracle Process Management and Notification Server(OPMN)は、システム・コンポーネントのプロセス管理に使用され、アプリケーション・サーバー・インスタンスの一部です。
コールド・フェイルオーバー・クラスタ環境にデフォルトのOPMN構成を維持することをお薦めします。OPMNプロセス自体のコールド・フェイルオーバー・クラスタ変換で他に必要な手順はありません。
コールド・フェイルオーバー・クラスタ用にOracleインスタンスを変換する場合に、管理サーバーに登録されているときは、次のように変更します。
管理サーバー・ドメインのDOMAIN_HOME/opmnディレクトリにあるtopology.xmlファイルで、このOracleインスタンス(コールド・フェイルオーバー・クラスタ変換の対象)のホスト名エントリをcfcvip.mycompany.comに変更します。
たとえば、Oracle HTTP Serverインスタンスをコールド・フェイルオーバー・クラスタに変換するには、topology.xmlファイルで次のように設定します。
<property name="HTTPMachine" value="cfcvip.mycompany.com"/>
インスタンス自体:
<ias-instance id="asinst " instance-home="/11gas3/MW/asinst" host="cfcvip.mycompany.com" port="6701">
INSTANCE_HOME/config/OPMN/opmnディレクトリのopmn.xmlファイルで、<physicalhostname>をcfcvip.mycompany.comに置き換えます。
</ias-component><ias-component id="ReportsServer_<physicalhostname>_asinst_2"> <process-set id="ReportsServer_<physicalhostname>_asinst_2" restart-on-death="true" numprocs="1">
INSTANCE_HOME/config/OPMN/opmnディレクトリのinstance.propertiesファイルで、adminHost=<physical hostname>をadminHost=<cfcvip.mycompany.com>に置き換えます。
すべてのコンポーネントを再起動します。
Oracle Internet DirectoryなどのOracleインスタンスをコールド・フェイルオーバー・クラスタに変換する場合は、そのOracleインスタンスの一部であるEnterprise Managerエージェントもコールド・フェイルオーバー・クラスタに変換する必要があります。
Enterprise Managerエージェントを変換する手順は次のとおりです。
次のコマンドを使用して、Enterprise Managerエージェントを停止します。
cd INSTANCE_HOME/EMAGENT/emagent_dir/bin ./emctl stop agent
ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_instance name/sysman/configに設定します。
emd.propertiesファイルで、EMD_URLurl属性のnode1.mycompany.comをcfcvip.mycompany.comに変更します。
エージェント側のtargets.xmlファイルを変更します。
cd INSTANCE_HOME/EMAGENT/emagent_dir/cp targets.xml targets.xml.org
ホストとoracle_emdに関連付けられたターゲットのみが含まれるように、targets.xmlを変更します。他のエントリはすべて削除します。例:
<Targets AGENT_TOKEN="ad4e5899e7341bfe8c36ac4459a4d569ddbf03bc">
<Target TYPE="oracle_emd" NAME=cfcvip.mycompany.com:port"/>
<Target TYPE="host" NAME=cfcvip.mycompany.com DISPLAY_NAME=cfcvip.mycompany.com/>
</Targets>
エージェントを再起動します。
cd INSTANCE_HOME/EMAGENT/emagent_dir/bin ./emctl start agent
管理サーバーのドメイン・ディレクトリにあるEnterprise Managerサーバーに対して、次の変更を行います。
使用ディレクトリをMW_HOME/user_projects/domains/domain_name/sysman/stateに設定します。
MW_HOME/user_projects/domains/domain_name/sysman/stateディレクトリにあるtargets.xmlファイルで、ホスト名をnode1.mycompany.comからcfcvip.mycompany.comに変更します。
Web層は、2つの主要コンポーネントであるOracle HTTP ServerとOracle Web Cacheで構成されます。次の2つの項では、Oracle HTTP ServerとOracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する方法について説明します。
Oracle HTTP Serverをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。
INSTANCE_HOME/config/OHS/component_name/httpd.confで、次の属性を変更します。
Listen cfcvip.mycompany.com:port #OHS_LISTEN_PORT Listen cfcvip.mycompany.com:port #OHS_PROXY_PORT ServerName cfcvip.mycompany.com
シングル・サインオンの再登録も実行します。第12.2.3.15項「シングル・サインオンの再登録(必要な場合)」を参照してください。
Oracle HTTP Serverのクライアント
コールド・フェイルオーバー・クラスタに変換したOracle HTTP ServerにOracle Web Cacheインスタンスがルーティングされる場合は、INSTANCE_HOME/config/WebCache/component_name/webcache.xmlで次の属性を変更します。
node1.mycompany.comをcfcvip.mycompany.comに変更します。このnode1.mycompany.comは、変換前のOracle HTTP Serverのアドレスです。
HOST ID="h1" NAME="cfcvip.mycompany.com" PORT="8888" LOADLIMIT="100" OSSTATE="ON"/> <HOST ID="h2" NAME="cfcvip.mycompany.com" PORT="8890" LOADLIMIT="100" OSSTATE="ON" SSLENABLED="SSL"/>
Oracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。
クラスタの両方のノードにある/etc/hostsで、物理ホスト名に別名を設定します。
これはノードのIPアドレスの別名です。Linuxの場合は/etc/hostsでこれを設定します。Windowsの場合はWindowsの場所でこれを設定します。この別名はwcprfx.mycompany.comです。たとえば、ノード1では、/etc/hostsファイル(UNIXの場合)のエントリはn.n.n.n node1 node1.mycompany.com wcprfx wcprfx.mycompany.comになります。
フェイルオーバー・ノードのノード2では、/etc/hostsファイル(UNIXの場合)のエントリはn.n.n.m node2 node2.mycompany.com wcprfx wcprfx.mycompany.comになります。
Windowsの場合は、すべてのノードにおいてC:\SystemRoot\system32\drivers\etc\hostsにあるファイルでこの変更を行います。SystemRootはWinntまたはWindowsです。
INSTANCE_HOME/config/WebCache/wc1/webcache.xmlで、次の操作を行います。
node1.mycompany.comをcfcvip.mycompany.comに変更します(node1.mycompany.comはOracle Web Cacheがインストールされている場所であり、変換前にリスニング対象となるホスト・アドレスです)。
SITE NAME="cfcvip.mycompany.com"
SSLポートと非SSLポートで仮想ホスト名のエントリをcfcvip.mycompany.comに変更します。例:
<HOST SSLENABLED="NONE" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8888"
NAME="cfcvip.mycompany.com" ID="h0"/>
<HOST SSLENABLED="SSL" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8890"
NAME="cfcvip.mycompany.com" ID="h3"/>
<VIRTUALHOSTMAP PORT="8094" NAME="cfcvip.mycompany.com">
<HOSTREF HOSTID="h3"/>
</VIRTUALHOSTMAP>
<VIRTUALHOSTMAP PORT="8090" NAME="cfcvip.mycompany.com">
<HOSTREF HOSTID="h0"/>
</VIRTUALHOSTMAP>
wcprfx.mycompany.comに基づくように、キャッシュ名エントリを変更します。wcprfx.mycompany.comは、クラスタにあるすべてのノードの/etc/hostsで作成された別名です。例:
<CACHE WCDEBUGON="NO" CAPACITY="30" VOTES="1" INSTANCENAME="asinst_1" COMPONENTNAME="wc1" ORACLEINSTANCE="ORACLE_INSTANCE_HOME" HOSTNAME="wcprfx.mycompany.com" ORACLEHOME="ORACLE_HOME" NAME=" wcprfx.mycompany.com-WebCache">
MULTIPORTセクションで、次の構成のIPADDRをANYからcfcvip.mycompany.comに変更します。
PORTTYPE="NORM" SSLENABLED="SSL" PORTTYPE="NORM" PORTTYPE="ADMINISTRATION" PORTTYPE="INVALIDATION" PORTTYPE="STATISTICS"
例:
<MULTIPORT>
<LISTEN PORTTYPE="NORM" PORT="8090"
IPADDR="cfcvip.mycompany.com"/>
<LISTEN SSLENABLED="SSL" PORTTYPE="NORM" PORT="8094"
IPADDR="cfcvip.mycompany.com">
<WALLET>ORACLE_INSTANCE/config/WebCache/wc1/keystores/
default</WALLET>
</LISTEN>
<LISTEN PORTTYPE="ADMINISTRATION" PORT="8091"
IPADDR="cfcvip.mycompany.com"/>
<LISTEN PORTTYPE="INVALIDATION" PORT="8093" IPADDR="
cfcvip.mycompany.com"/>
<LISTEN PORTTYPE="STATISTICS" PORT="8092"
IPADDR="cfcvip.mycompany.com"/>
</MULTIPORT>
コールド・フェイルオーバー・クラスタ環境では、フェイルオーバー・ノード(node2.mycompany.com)をすべての面でインストール・マシン(node1.mycompany.com)と同じにする必要があります。フェイルオーバー・ノードをインストール・ノードと同じにするには、フェイルオーバー・インスタンスで次の手順を実行します。
UNIXプラットフォームでの手順は次のとおりです。
前述のマウントおよびアンマウントの手順に従って、ノード1(インストール・ノード)からフェイルオーバー・ノード(ノード2)へMiddlewareホームをフェイルオーバーさせます。
rootとして、次の操作を行います。
ノード1にあるものと同一のoraInst.locファイルを/etcディレクトリに作成します。
ORACLE_HOMEディレクトリにあるroot.shファイルをノード2で実行します(これは、製品スイートで利用可能な場合や必要に応じて実行します)。
ORACLE_HOME/oui/bin/attachHome.shディレクトリにあるattachHomeコマンドを使用して、oraInventoryを2番目のノードで作成します。
Windowsでの手順は次のとおりです。
アプリケーション・サーバー・インスタンス(Web層、IDMインストールのOID/OVD、Oracle Portal、Form、ReportsおよびDiscoverer)の場合:
ノード2でOPMNサービスを作成するには、次のコマンドを実行します。
sc create OracleProcessManager_instance_name binPath= "ORACLE_HOME\opmn\bin\opmn.exe -S -I Instance_Home"
例:
sc create OracleProcessManager_asinst binPath= "X:\Middleware\im_oh\opmn\bin\opmn.exe -S -I X:\Middleware\asinst"
ノード1とノード2の両方で、OracleProcessManager_instance_nameサービスが手動で起動するように設定します。
sc config OracleProcessManager_instance_name start= demand
Oracle Business Intelligenceのインストールの場合:
コールド・フェイルオーバー・クラスタでOracle Business Intelligenceを使用するときには、Oracle Business Intelligenceが使用する特定のWindowsレジストリのエントリを、アクティブ・ノードとパッシブ・ノードで完全に同じにする必要があります。このレジストリのエントリをアクティブ・ノードとパッシブ・ノードで確実に同じにするには、ノード1でレジストリ・エントリをエクスポートして、そのレジストリ・エントリをノード2でインポートします(ノード1はアクティブ・ノードを表し、ノード2はパッシブ・ノードを表します)。これを実行する手順は、次のとおりです。
ノード1でのOracle Business Intelligenceレジストリ・エントリのエクスポート
次の手順を実行して、ノード1でOracle Business Intelligenceのレジストリ・エントリをエクスポートします。
ノード1で、Windowsのレジストリ・エディタを起動します。これを行うには、次のコマンドをWindowsのコマンドラインから入力します。
C:\>regedit
レジストリ・エディタで、ノードHKEY_LOCAL_MACHINE\SOFTWARE\Oracleに移動して、このノードを選択します。このノードを右クリックして、「エクスポート」を選択します。それらのエントリを、一意の名前を付けた.regファイルとして保存します。
ノードHKEY_LOCAL_MACHINE\SOFTWARE\ODBCに移動して、このノードを選択します。このノードを右クリックして、「エクスポート」を選択します。それらのエントリを、一意の名前を付けた.regファイルとして保存します。
ノードHKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Servicesに移動して、このノードを選択します。このノード内にあるOracleで始まる各ノードを、一意の名前を付けた.regファイルにエクスポートします。
ノードHKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Servicesに移動して、このノードを選択します。このノード内にあるOracleで始まる各ノードを、一意の名前を付けた.regファイルにエクスポートします。
ノードHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesに移動して、このノードを選択します。このノード内にあるOracleで始まる各ノードを、一意の名前を付けた.regファイルにエクスポートします。
作成したすべての.regファイルをノード2にコピーします。
レジストリ・エディタを終了します。
ノード2でのOracle Business Intelligenceレジストリ・エントリのインポート
次の手順を実行して、ノード1でのOracle Business Intelligenceのレジストリ・エントリをノード2にインポートします。
ノード2で、Oracle_BI1\bifoundation\install\vc80\vcredist_x86.exeをダブルクリックします。
ノード1からコピーした各.regファイルをダブルクリックします。毎回、「はい」をクリックして、ファイルの内容をレジストリにインポートします。
すべてのインストールの場合:
ノード1のシステム環境変数Pathになんらかのインスタンス固有の情報が含まれている場合、これと同じ情報をノード2の同じ変数にも設定します。また、ノード1からレジストリHKEY_LOCAL_MACHINE\SOFTWARE\Oracleをエクスポートして、それをノード2にインポートします。
ノード1からノード2にスタート・メニューをコピーするため、ノード1のC:\Document and Settings\All Users\スタート・メニュー\プログラム\<メニュー>にあるファイルをノード2にコピーしますこの操作には、Windowsバックアップ・ツールやZipユーティリティを使用できます。たとえば、Windowsバックアップ・ユーティリティを使用する場合、次のように実行します。
「アクセサリ」、「システム ツール」、「バックアップ」の順に選択して、Windowsバックアップ・ユーティリティを起動します。
C:\Document and Settings\All Users\スタート メニュー\プログラム\<メニュー>を選択します。
バックアップ・ファイルを2番目のノードにコピーします。
同じ場所(C:\Document and Settings\All Users\スタート メニュー\プログラム\)でバックアップをリストアします。
ノード・マネージャについては、WebLogic Serverの標準手順に従って、ノード・マネージャをサービスとして構成します。
ノード・マネージャをサービスとして構成するには、WL_HOME\server\bin\installNodeMgrSvc.cmdコマンドを使用します。ノード・マネージャの構成の要件は次のとおりです。
両方のノードに設定する必要があります。
両方のノードで、手動で起動するようにノード・マネージャを設定する必要があります。
ノードにノード・マネージャを構成する手順は次のとおりです。
マシンでMiddlewareホームが使用できることを確認します。
前述のコマンドを実行して、サービスをインストールします。
次のコマンドを使用して、手動で起動するようにサービスを設定します。
sc config nodemanager_service_name start= demand
この項では、Oracle製品スイートごとの考慮事項と変換手順について説明します。製品コンポーネントの詳細は、このガイドで適切なコンポーネントに関連する章を参照してください。
この項の項目は次のとおりです。
第12.2.3.3項「Oracle Directory Integration PlatformおよびOracle Directory Services Managerとそれぞれのクライアントの変換」
第12.2.3.16項「Oracle Privileged Account Managerおよびそのクライアントの変換」
この項では、Oracle Internet Directoryとそのクライアントを変換する方法について説明します。
Oracle Internet DirectoryサーバーをPS1から変換する手順は次のとおりです。
テキスト・エディタで、Oracle Internet Directoryサーバーに対して仮想IPのcfcvip.mycompany.comを設定するoidcfc.ldifというファイルを次のように作成します。
dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclhostname orclhostname: cfcvip.mycompany.com
次のコマンドを実行します。
ORACLE_HOME/bin/ldapmodify -p <oidPort> -h <oidHost> -D cn=orcladmin –w <adminPasswd> -f oidcfc.ldif
このコマンドの実行時に、OIDが稼働している必要があります。oidHostは、OIDのインストールに使用された物理ホスト名のリスニング・エンド・ポイントです。
opmnctlを使用して、Oracle Internet Directoryサーバーを停止してから再起動します。
例:
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1 ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1
OIDを管理サーバーに再登録します。
ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration -adminHost
myAdminHost -adminPort 7001 -adminUsername weblogic -componentType OID
-componentName oid1 -Host cfcvip.mycompany.com
Oracle Internet DirectoryをPS1からアップグレードするには、次を実行します。
ORACLE_HOME/opmn/bin/upgradenonj2eeapp.sh -oracleInstance ORACLE_INSTANCE
Oracle Internet Directoryクライアントを変換する手順は次のとおりです。
Oracle Internet Directoryサーバーのすべてのクライアントは、仮想IPのcfcvip.mycompany.comを使用してそのOracle Internet Directoryサーバーにアクセスします。
Oracle Internet Directoryサーバーを使用するOracle Directory Integration Platformインストールでは、仮想IPを使用してOracle Internet Directoryサーバーにアクセスする必要があります。そのための手順は次のとおりです。
テキスト・エディタで、DOMAIN_HOME/config/fmwconfig/servers/wls_ods1/applications/DIP_<version_number>/configurationディレクトリにあるdip-config.xmlファイルを開きます。
例:
MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/ wls_ods1/applications/DIP_11.1.1.2.0/configuration
次の値を入力し、LDAPアドレスを仮想IPに設定します。
OID_NODE_HOST>cfcvip.mycompany.com</OID_NODE_HOST>
Oracle Internet Directoryサーバーを管理するOracle Directory Services Managerインスタンス(第12.2.2.8.1項「Oracle HTTP Serverの変換」を参照)は、仮想IPを使用してOracle Internet Directoryサーバーに接続する必要があります。
たとえば、「Oracle Directory Services Manager」画面で、仮想サーバーを使用してOracle Internet Directoryに接続できることを次の手順で検証します。
右上隅にある「ディレクトリに接続」→「新規接続の作成」リンクを選択します。
「新規接続」画面で、次の接続情報を入力し、「接続」をクリックします。
ディレクトリ・タイプ: OID
名前: OIDHA
サーバー: cfcvip.mycompany.com
ポート: 389
SSL有効: 空白にしておきます。
ユーザー名: cn=orcladmin
パスワード: ********
開始ページ: Home(デフォルト)
この項では、Oracle Virtual Directoryとそのクライアントを変換する方法について説明します。
Oracle Virtual Directoryサーバーを変換する手順は次のとおりです。
テキスト・エディタで、ORACLE_INSTANCE/config/OVD/componentnameディレクトリにあるlisteners.os_xmlファイルを開きます。
次の値を入力し、LDAPアドレスを仮想IPに設定します。
<host>cfcvip.mycompany.com</host>
opmnctlを使用して、Oracle Virtual Directoryサーバーを再起動します。
例:
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1 ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1
Oracle Virtual Directoryのすべてのクライアントは、仮想IPのcfcvip.mycompany.comを使用して、Oracle Virtual Directoryにアクセスする必要があります。たとえば、Oracle Directory Services Managerを使用してコールド・フェイルオーバー・クラスタのOracle Virtual Directoryインスタンスを管理する場合は、Oracle Virtual Directoryインスタンスの場所としてcfcvip.mycompany.comを使用して接続を作成します。
この項では、Oracle Directory Integration Platform、Oracle Directory Services Managerおよびそれぞれのクライアントを変換する方法について説明します。
Oracle Directory Integration PlatformとOracle Directory Services Managerは管理対象サーバーにデプロイされます。CFC変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成します。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_ODS管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。
次の手順に従って、Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントを変換します。
Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントは、仮想IPのcfcvip.mycompany.comを使用してこれらのアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Directory Services Managerのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_ODS管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、Oracle HTTP ServerおよびOracle Directory Services Managerで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#Oracle Directory Services Manager
<Location /odsm>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
この項では、Oracle Identity Federationとそのクライアントを変換する方法について説明します。
Oracle Identity Federationは、管理サーバーにデプロイされるコンポーネントです。コールド・フェイルオーバー・クラスタ変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成します。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OIF管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Oracle Identity Federationコールド・フェイルオーバー・クラスタ・デプロイメントは通常、サービス・プロバイダとアイデンティティ・プロバイダに分割されるため、特定のデプロイメントに複数のWLS_OIFインスタンスが存在する場合があります。どちらのWLS_OIFインスタンスに対しても、同じコールド・フェイルオーバー・クラスタ手順を適用してください。
cfcvip.mycompany.comの仮想IP上でリスニングするように管理対象サーバーを構成した後、Oracle Enterprise Manager Fusion Middleware Controlにログインして、次の手順を実行します。
「ファーム」→「Identity and Access」→OIFに移動します。
右側のフレームで、「Oracle Identity Federation」→「管理」に移動し、次の変更を行います。
サーバー・プロパティ: ホストをcfcvip.mycompany.comに変更します。
「アイデンティティ・プロバイダ」→「共通」: providerIdをcfcvip.mycompany.comに変更します。
「サービス・プロバイダ」→「共通」: providerIdをcfcvip.mycompany.comに変更します。
データ・ストア: データ・ストアがLDAPの場合は、ユーザー・データ・ストアとフェデレーション・データ・ストアの接続URLの値をcfcvip.mycompany.comに置き換えます。
「認証エンジン」→「LDAPディレクトリ」: ConnectionURLをcfcvip.mycompany.comに設定します。
前述の変更を行った後にメタデータを生成する必要があります。
次の手順に従って、Oracle Identity Federationクライアントを変換します。
Oracle Identity Federationクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Identity Federationのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_OIF管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、Oracle HTTP ServerおよびOracle Directory Services Managerで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#Oracle Identity Federation
<Location /oif>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
Oracle Mobile and Socialサーバーを変換するには、次のサーバー･プロバイダのOracle Access Managerホストのホスト名を更新します。
OAMAuthorization
OAMAuthentication
更新を行うには、WLSTコマンドを使用するか、手動で更新を行う場合はoamconsoleを使用します。
WLSTコマンドを使用してホスト名を変更するには、次のように入力します。
updateServiceProvider('oracle.security.idaas.rest.provider.authorization.OAMS
DKAuthZServiceProvider', 'Authorization', '[]','
[{OAM_VERSION: OAM_11G},{WEBGATE_ID: accessgate-oic},
{ENCRYPTED_PASSWORD: aaaa},{DEBUG_VALUE: 0},{TRANSPORT_SECURITY: OPEN},
{OAM_SERVER_1: "cfcvip.mycompany.com:5575"},{OAM_SERVER_1_MAX_CONN: 4},
{OAM_SERVER_2: "cfcvip.mycompany.com:5575"},{OAM_SERVER_2_MAX_CONN: 4}]',
'OAMAuthorization', 'Out Of The Box Oracle Access Manager (OAM)
Authorization Service Provider')
updateServiceProviderコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のupdateServiceProviderに関する項を参照してください。
oamconsoleを使用してホスト名を変更する手順は、次のとおりです。
Oracle Access Managerコンソールにログインします。
「システム構成」を選択して、「Mobile and Social」を選択します。
「モバイル・サービス」で、「サービス・プロバイダ」を選択します。
「認証サービス・プロバイダ」の下のOAMAuthenticationおよび「認可サービス・プロバイダ」の下のOAMAuthorizationを探します。OAM_SERVER_1およびOAM_SERVER_2をcfcvip.mycompany.comに更新します。
「保存」をクリックします。
Oracle SOA Suiteは、管理対象サーバーにデプロイされるJava EEコンポーネントで構成されます。一般的な構成では、OWSM-PMアプリケーションとSOAアプリケーションのデプロイメントがあります。SOAアプリケーションは必ず、個別の管理対象サーバーにデプロイされます。多くのコールド・フェイルオーバー・クラスタ・デプロイメントでは、OWSM-PMは管理サーバーにデプロイされますが、管理対象サーバー自体(WLS_OWSMなど)やSOA管理対象サーバーにもデプロイできます。WLS_SOAコンテナには、デプロイされたBPEL、UMS、B2Bなどのアプリケーションが含まれ、さらにデプロイされたBPMコンポーネントが含まれる場合もあります。これらはJava EEコンポーネントであるため、すべての場合で、コールド・フェイルオーバー・クラスタ変換手順には、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーのWLS_OWSMおよびWLS_SOAを変換する方法の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。
また、次の手順に従って、SOAコンポーネントの管理対象サーバーを変換します。
WLS_SOA管理対象サーバーのフロントエンド・ホストをcfcvip.mycompany.comに設定します。
管理コンソールにログインします。
「環境」セクションで「サーバー」を選択します。
管理対象サーバー名を選択します。
「プロトコル」を選択してから、「HTTP」を選択します。
「フロントエンド・ホスト」フィールドで、ホスト名をcfcvip.mycompany.comとして入力します。
フロントエンド・ポートをHTTPポートに設定します。
「保存」をクリックします。
変更をアクティブ化します。
管理対象サーバーを再起動します。
Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_OWSMとWLS_SOAにデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。そのためには、SOAコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#SOA soa-infra app
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
# Worklist
<Location /integration/>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
# B2B
<Location /b2b>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
# UMS
<Location /sdpmessaging/ >
SetHandler weblogic-handler
WebLogicHost cfc.mycompany.com:port
</Location>
# UMS WS
<Location /ucs/messaging/webservice >
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com WebLogicPort port
WebLogic port
</Location>
# WSM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
# workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
# Required if SOA is being used for Oracle Image and Process Management
# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
この項では、Oracle Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定すること、および管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.mycompany.com)に指定することによって設定可能です。この場合、明確な変換手順は不要です。
Oracle Access Managerは管理対象サーバー(WLS_OAM1など)にデプロイされますが、CFC変換を行うためには、この管理対象サーバーを、仮想IPのcfcvip.mycompany.comでリスニングするように構成します。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OAM1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明のとおりです。
Oracle Access Managerコンソールは、ドメインの管理サーバーの一部としてデプロイされます。このコンソールのコールド・フェイルオーバー・クラスタ構成では、管理サーバー全体をアクティブ/パッシブで構成する必要があります。管理サーバーは、同じ仮想IPのcfcvip.mycompany.comを共有することも、個別の仮想IPと共有ディスクを使用して独立してフェイルオーバーするように構成することもできます。同じ仮想IPを使用している場合、管理サーバーとOracle Access Manager管理対象サーバーは1つのユニットとしてフェイルオーバーします。
次の手順に従って、Oracle Access Managerクライアントを変換します。
Oracle Access Managerクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Identity ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.mycompany.comを使用してアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Access Managerのフロントエンドである場合、Oracle Access Managerに関するmod_weblogic構成では、Oracle Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#Oracle Access Manager
<Location /oam>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:port
</Location>
Oracle管理サーバーの一部としてOracle Access Managerコンソールもアクティブ/パッシブに構成し、Oracle HTTP Serverがその管理サーバーのフロントエンドに配置されるように構成する場合、Webサーバー・プロキシ・プラグイン構成ファイルのWebLogicホスト構成を変更する必要があります。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#Oracle Access Manager Admin Console deployed to the Admin Server
<Location /oamconsole>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WebLogicPort 7001
</Location>
この項では、Oracle Adaptive Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.mycompany.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。
Oracle Adaptive Access Managerは管理対象サーバーにデプロイされます。両方とも単一のユニットとしてフェイルオーバーするようにデプロイされ、そのために同じ仮想IPと同じ共有記憶域を共有します。OAAM Admin管理対象サーバーおよびOAAM Server管理対象サーバーをCFC変換のために変換するには、これらの管理対象サーバーを、仮想IPのcfcvip.mycompany.comでリスニングするように構成します。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明のとおりです。
次の手順に従って、Oracle Adaptive Access Managerクライアントを変換します。
Oracle Adaptive Access Managerクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Identity Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.mycompany.comを使用してアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Adaptive Access Managerのフロントエンドである場合、Oracle Adaptive Access Managerに関するmod_weblogic構成では、Oracle Adaptive Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#Oracle Adaptive Access Manager
<Location /oaam_server>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com WebLogicPort port
</Location>
#Oracle Adaptive Access Manager Admin Console
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:port
</Location>
この項では、Oracle Identity Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.mycompany.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。
Oracle Identity Managerは、管理対象サーバーにデプロイされます。一般的なCFCデプロイメントでは、Oracle Identity Manager管理対象サーバーと、Oracle SOAおよびOracle Web Services Managerを含む別の管理対象サーバーは1つのユニットとしてフェイルオーバーするようにデプロイされ、そのために同じ仮想IPと同じ共有記憶域を共有します。この両方の管理対象サーバーをCFC変換のために変換するには、これらの管理対象サーバーを、仮想IPのcfcvip.mycompany.comでリスニングするように構成します。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明のとおりです。
Oracle Identity Managerクライアントを変換するには、次の手順を実行します。
Oracle Identity Managerクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.mycompany.comを使用してアプリケーションにアクセスする必要があります。SOAもOracle Identity Managerでフェイルオーバーするように構成されているので、Oracle Identity ManagerからSOAへの接続でも共通の仮想IPを使用する必要があります。
Oracle HTTP ServerがOracle Identity Managerのフロントエンドである場合、Oracle Identity Managerに関するmod_weblogic構成では、管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルまたはoim.confファイルを次のように編集します。
#Oracle Identity Manager
<Location /oim>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:port
WebLogicPort port
</Location>
Oracle Identity Managerでの構成変更の詳細は、Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドを参照してください。
WebCenter SuiteはJava EEコンポーネントで構成されています。一般的なWebCenter Suiteデプロイメントには4つの管理対象サーバーが含まれますが、WebCenterポータル・アプリケーションを開発すると、それより多くの追加の管理対象サーバーを含めることができます。一般的な管理対象サーバー・デプロイメントは次のとおりです。
WC_SPACES
WC_PORTLETS
WC_COLLABORATION
WC_UTILITIES
これらはJava EEコンポーネントであるため、コールド・フェイルオーバー・クラスタ変換手順では、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成します。Oracle WebCenterポータルのコールド・フェイルオーバー・クラスタ・デプロイメントでは、多くの場合、OWSM-PMをWC_PORTLETSおよびWC_SPACESコンテナにデプロイすることになります。Oracle WebCenterポータルSuite管理対象サーバーを変換する方法の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。
Oracle HTTP Serverをフロントエンドとして使用している場合は、WebCenter Suiteアプリケーションに関するmod_weblogic構成で、管理対象サーバーのアドレスのかわりとしてVIPのcfcvip.mycompany.comを指定します。これを行うには、WebCenterコンポーネントが使用するマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。
管理対象サーバーのアドレスとして仮想ホストを使用する手順は、次のとおりです。
管理対象サーバーを実行するマシンで、仮想ホストcfcvip.mycompany.comが有効になっていることを確認します。
管理対象サーバーのリスニング・アドレスがcfcvip.mycompany.comに設定されていることを確認します。
mod_wl_ohs.confファイルの、アドレスcfcvip.mycompany.comを使用します。
コールド・フェイルオーバー・クラスタ構成は、それぞれのOracle Portal、Forms、ReportsおよびDiscovererコンポーネントごとに異なります。この項では、Oracle Portal、Forms、ReportsおよびDiscovererのコールド・フェイルオーバー・クラスタ変換手順について説明します。
Oracle FormsはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Formsをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。
|
注意: この変換プロセスでは、これらのファイルの編集前にドメインを停止する必要があります。 |
WLS_FORMS管理対象サーバーを変換します。この手順の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。
Oracle Forms OPMNを変換します。この手順の詳細は、第12.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。
Enterprise Managerを変換します。この手順の詳細は、第12.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。
Oracle Forms Web層コンポーネントを変換します。この手順の詳細は、第12.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。
第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従って、シングル・サインオンを再登録します。
INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるforms.confファイルで、mod_weblogic構成を変更します。
WebLogicドメイン内の管理サーバーと管理対象サーバーだけでなくOracleインスタンスも起動して、コールド・フェイルオーバー・クラスタ・インストールを検証します。
<Location /Forms>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
DynamicServerList OFF
</Location>
Oracle ReportsはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Reportsをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。
WLS_REPORTS管理対象サーバーを変換します。この手順の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。
Oracle Reports OPMNを変換します。この手順の詳細は、第12.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。
また、次の操作を行います。
INSTANCE_HOME/config/OPMN/opmnディレクトリにあるopmn.xmlファイルで、ias-componentのReports Server名を新しい名前に変更して、新しい名前を反映させます。
例:
<ias-component id="ReportsServer_virtual_hostname_instance_name"> <process-set id="ReportsServer_virtual_hostname_instance_name" restart-on-death="true" numprocs="1"> </ias-component>
例:
<ias-component id="ReportsServer_cfcvip_asinst1"> <process-set id="ReportsServer_cfcvip_asinst1"restart-on-death="true" numprocs="1"> </ias-component>
管理サーバー・ドメイン・ホームのDOMAIN_HOME/opmn/topology.xmlで、Reportsサーバー名のすべての記述をReportsServer_physical hostname_instance_name (例: ReportsServer_node1_asinst)からReportsServer_virtual_hostname_instance_name (例: ReportsServer_cfcvip_asinst)に変更します。
Oracle Enterprise Managerを変換します。この手順の詳細は、第12.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。
Oracle Reports Web層コンポーネントを変換します。この手順の詳細は、第12.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。
シングル・サインオンを再登録します。そのためには、第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従ってください。
INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるreports_ohs.confファイルで、次を変更します。
<Location /reports>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
INSTANCE_HOME/config/ReportsServerComponentディレクトリで、次のディレクトリ名を探して、その名前を変更します。
ReportsServer_physical_hostname_instance_name (for example: ReportsServer_node1_asinst)
前述の名前を次のように変更します。
ReportsServer_VIP_instance_name (for example: ReportsServer_cfcvip_asinst)
|
注意: インスタンスの再起動後、レポート・サーバーの新しいログはすべて、ReportsServer_virtual_hostname_instance_nameに送信されます。 |
名前を変更したディレクトリで、次のファイルに記載された物理ホスト名を仮想ホスト名に置き換えます。
component-logs.xml
logging.xml
INSTANCE_HOME/EMAGENT/emagent_dir/sysman/emdディレクトリにあるtargets.xmlファイルで、次の変更を行います。
すべてのホスト名をnode1.mycompany.comからcfcvip.mycompany.comに変更します。
次の2つの要素に関して、Reports Server名をReportsServer_physical_hostname_instance_name (例: ReportsServer_node1_asinst)からReportsServer_virtual_hostname_instance_name (例: ReportsServer_cfcvip_asinst)に変更します。
Target TYPE="oracle_repserv"
Target TYPE="oracle_repapp"
INSTANCE_HOME/reportsディレクトリにあるreports_install.propertiesで、物理ホスト名を仮想ホスト名に置き換えます。
INSTANCE_HOME/reports/serverディレクトリにある次のファイルの名前を変更します。
reportsserver_physical hostname_instance name.datを、reportsserver_virtual host name_instance name.datに変更します。
ep_wls_reports_physical_hostname_instance name.datを、rep_wls_reports_virtual_hostname_instance_name.datに変更します。
DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_<version_number>/1ww3jm/configurationディレクトリ(たとえばDOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_11.1.1.3.0/1ww3jm/configurationディレクトリ)にあるrwservlet.propertiesファイルで、物理ホスト名を仮想ホスト名に置き換えます(Reports Server名のすべての記述に関する変更を含む)。
DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_<version_number>/1ww3jm/META-INFディレクトリ(たとえばDOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_11.1.1.3.0/1ww3jm/META-INFディレクトリ)にあるmbeans.xmlファイルで、物理ホスト名を仮想ホスト名に置き換えます(Reports Server名のすべての記述に関する変更を含む)。
WebLogicドメイン内の管理サーバーと管理対象サーバーだけでなくOracleインスタンスも起動して、コールド・フェイルオーバー・クラスタ・インストールを検証します。
Oracle DiscovererはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Discovererをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。
WLS_DISCO管理対象サーバーを変換します。この手順の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。
Oracle Discoverer OPMNを変換します。この手順の詳細は、第12.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。
Oracle Enterprise Managerを変換します。この手順の詳細は、第12.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。
Oracle Discoverer Web層コンポーネントを変換します。この手順の詳細は、第12.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。
シングル・サインオンを再登録します。そのためには、第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従ってください。
INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるreports_ohs.confファイルで、次を変更します。
<IfModule mod_weblogic.c><Location /discoverer>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
DynamicServerList ON
</Location>
</IfModule>
Oracle PortalはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Portalをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。
WLS_PORTAL管理対象サーバーを変換します。この手順の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。
Oracle Portal OPMNを変換します。この手順の詳細は、第12.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。
Oracle Enterprise Managerを変換します。この手順の詳細は、第12.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。
Oracle Portal Web層コンポーネントを変換します。この手順の詳細は、第12.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。
シングル・サインオンを再登録します。そのためには、第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従ってください。
INSTANCE_HOME/config/config/OHS/ohs1/moduleconfにあるportal.confファイルで、mod weblogic構成を変更して、mod weblogic構成を変更します。
# WLS routing configuration
<Location /portal>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
<Location /portalTools>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
<Location /wsrp-tools>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
<Location /richtextportlet>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
<Location /jpdk>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
<Location /portalHelp>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
<Location /portalHelp2>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
Portalレジストリをリワイヤします。
次のURLを使用して、WebLogic Server Enterprise Managerにログインします。
http://cfcvip.mycompany.com:7001/em
InValidationおよび管理者パスワードを変更します。
「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。
wc1コンポーネントをクリックします。
ページの最上部にあるドロップダウン・リストから「管理 - パスワード」を選択します。
新しい無効化パスワードの入力と確認を行ってから、「適用」をクリックします。
新しい管理者パスワードの入力と確認を行ってから、「適用」をクリックします。
左側のペインで、「Fusion Middleware」メニューを開きます。
「Classic」を選択します。
「Portal」をクリックします。
ポータル・ドメイン情報ページが表示されます。
「Portal」を右クリックして、「設定」、「ワイヤ構成」の順に選択します。
「ポータル中間層」に関して次の情報を入力します。
ホスト: Webキャッシュ・ホストのcfcvip.mycompany.comのコールド・フェイルオーバー・クラスタ仮想IP名を入力します。
ポート: 使用するWebキャッシュ・ポート(HTTPまたは非HTTP)を入力します。
SSLプロトコル: 該当する場合は、この値を入力します。
「Webキャッシュ」に関して次の情報を入力します。
ホスト: Webキャッシュ・ホストのcfcvip.mycompany.comとmysite.mycompany.comのコールド・フェイルオーバー・クラスタ仮想IP名を入力します。
無効化ポート: 9401などの無効化ポートを入力します。
無効化ユーザー名: Portal無効化のユーザー名を入力します。
無効化パスワード: このアカウントのパスワードを入力します。
「適用」をクリックし、リワイヤを開始します。
リワイヤが完了したら、「Portal」メニュー・オプションを再びクリックして、URLが次のようになっていることを確認します。
https://cfcvip.mycompany.com:WCHTTPPort/portal/pls/portal
Oracle WebLogic Serverにおけるホスト・アサーションを変更します。
Oracle HTTP ServerはWebLogicのプロキシとして機能するため、デフォルトでは、ホストやポートなどの特定のCGI変数はWebLogicに渡されません。仮想サイト名とポートを使用していることをWebLogicに認識させ、内部URLが適切に生成できるようにする手順は次のとおりです。
次のURLを使用して、管理コンソールにログインします。
http://cfcvip.mycompany.com:7001/console
ホーム・ページから「WLS_PORTAL」を選択するか、「ドメイン構造」メニューから「環境」、「クラスタ」の順に選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「プロトコル」をクリックしてから、「HTTP」を選択します。
次の値を入力します。
「フロントエンド・ホスト」: cfcvip.mycompany.com
フロントエンドHTTPポート: WCHTTPPort(8090)
フロントエンドHTTPSポート: WCHTTPSPort(8094)
これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート443に送られます。
「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックして、編集可能にします。
WLS_PORTAL管理対象サーバーを再起動します。
Oracle BAMは、管理対象サーバーにデプロイされるJava EEコンポーネントで構成されます。これらはJava EEコンポーネントであることから、コールド・フェイルオーバー・クラスタ変換手順には、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーのWLS_BAMを変換する方法の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。
Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_BAMにデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。そのためには、SOAコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
# BAM Web Application
<Location /OracleBAM >
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
カスタムADFアプリケーションを使用するデプロイメントでも、あらゆるFusion Middlewareデプロイメントと同じように、コールド・フェイルオーバー・クラスタを使用します。この場合、Oracle Application DeveloperのDVDからのインストールを使用して、ドメインを作成します。これは主にJava EEコンポーネントであるため、コールド・フェイルオーバー・クラスタ変換手順は、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーを変換する方法の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。
Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_ADF(カスタマ・アプリケーションの管理対象サーバーの名前)にデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。そのためには、SOAコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
# BAM Web Application
<Location /ADFApplicationMountPoint >
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
Oracle WebCenter Contentには、Oracle WebCenter Content: Imaging(Imaging)、Oracle WebCenter Content(WebCenter Content)、Oracle WebCenter Content: Records、Oracle WebCenter Content: Inbound Refineryなどの製品が含まれます。
Oracle WebCenter Contentをインストールする場合には、通常、次の管理対象サーバーが含まれます。
Imaging (WLS_IPM)
WebCenter Content (WLS_UCM)
Records (WLS_URM)
Inbound Refinery (WLS_IBR)
コールド・フェイルオーバー・デプロイメントでは、この章の前の項でCFCデプロイメントに推奨されているアプリケーション層およびWeb層の設定を行い、これらの管理対象サーバーに対してコールド・フェイルオーバー・クラスタ変換の手順を実行することをお薦めします。Imaging、UCM、URMおよびIBR管理対象サーバーの変換の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。
Oracle WebCenter Contentのコールド・フェイルオーバー・クラスタ・デプロイメントについては、さらに次も考慮してください。
Oracle WebCenter Contentの多くのコールド・フェイルオーバー・クラスタ・デプロイメントでは、次のようなデプロイメント・トポロジになります。
I/PMとUCMの両方ともハードウェア・クラスタの同じノードにデプロイされます。
ハードウェア・クラスタの一方のノードにI/PM、もう一方のノードにUCMというデプロイメントで、相互的なフェイルオーバーに構成されます。
I/PMサーバーがフェイルオーバーするときにアクセスする必要があるすべてのI/PM関連のファイルも、共有ディスクに配置する必要があります。これには、入力ファイルやイメージなどが含まれます。CFC構成のすべてのノードからアクセスできるように、これらは必ず共有ディスクに配置してください。入力ファイルとイメージ・ファイルは個別のボリュームを用意することをお薦めします。
JMSやTLogsなどで使用される永続ストアも、すべて共有ディスクに配置する必要があります。
Inbound Refineryに関連するすべての制限は、CFC構成において引き続き適用されます。Inbound Refineryインスタンスの構成の詳細は、Oracle Fusion Middleware変換についての管理者ガイドを参照してください。
UCMのコンテンツに関するすべてのフォルダも同様に共有ディスクに配置する必要があります。これは、UCMサーバー構成とともに1つのユニットとしてフェイルオーバーされます。これには、次のようなフォルダが含まれます。
コンテンツ・サーバー・インスタンス・フォルダ
ネイティブ・ファイル・リポジトリの場所
Webレイアウト・フォルダ
http://cfcvip.mycompany.com:port/csを使用してUCMまたはURMを構成する場合、「WebサーバーのHTTPアドレス」がWCC管理対象サーバーのフロントエンドとなるHTTPサーバーのホスト名および場所になります。HTTPサーバーの高可用性構成に応じて、これはロード・バランサのアドレス、物理ホスト、または仮想ホストになります。Oracle HTTP ServerもCFCデプロイメントに含まれる場合、上の値はOracle HTTP Serverの仮想IPに設定する必要があります。Oracle HTTP ServerがWCCサーバーと同じハードウェア・クラスタに存在する場合、これはcfcvip.mycompany.comのようになります。
UCMがコールド・フェイルオーバー・クラスタで構成され(上の例に含まれます)、I/PMがUCMに接続されている場合、UCMの仮想IPアドレスを使用することをお薦めします。http://cfcvip.mycompany.com:port/imagingを使用してこの構成を行う場合、次の手順を実行します。
左側のペインで、「接続の管理」→「Content Server接続の作成」をクリックします。
新しい接続の名前と説明を入力し、「次へ」をクリックします。
「接続設定」画面で、次を入力します。
コンテンツ・サーバー・バージョン: CS 11g
プライマリ: cfcvip.mycompany.com:4444
「次へ」をクリックします。
接続セキュリティ画面で、WebLogicユーザーに対するデフォルトの選択をそのまま受け入れ、「次へ」をクリックします。
接続の詳細を確認し、「送信」をクリックします。
また、Oracle HTTP ServerをOracle WebCenter Contentアプリケーションのフロントエンドとして使用している場合、mod_weblogic構成で、管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを使用する必要があります。そのためには、WCCコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
# Content Server
<Location /cs>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
WLCookieName IDCCS_SESSIONID
</Location>
# URM
<Location /urm>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
WLCookieName IDCURM_SESSIONID
</Location>
# IBR
<Location /ibr>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
WLCookieName IDCIBR_SESSIONID
</Location>
# IPM
<Location /imaging>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>
Oracle Business Intelligenceは、ビジネス・ユーザーに組織の全体像を提供する統合ビジネス・インテリジェンス(BI)ソリューションです。Oracle Business Intelligenceは、迅速かつ簡単に様々なデータ・ソースを統合し、データベースの情報を検索し、データベース情報を共有して、企業およびその顧客に関する情報を得るためにデータを有効に利用することを目的として設計されています。
この項では、Oracle Business Intelligence Enterprise Edition、Oracle Business Intelligence PublisherおよびOracle Real-Time Decisionsに対するアクティブ/パッシブによる高可用性構成について説明します。
この項では、Oracle Business Intelligence Enterprise Edition(Oracle BI EE)をコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
管理対象サーバーの変換
Oracle BI Enterprise Editionは管理対象サーバー(BI_SERVER1など)にデプロイされ、コールド・フェイルオーバー・クラスタ変換の手順はこの管理対象サーバーをインストール後に仮想IPのcfcvip.mycompany.comでリスニングするように構成することになります。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、BI_SERVER1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。この手順の後で、管理コンソールまたはWLSTコマンドラインを使用して、管理対象サーバーを再起動します。
Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関するすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明のとおりです。Oracle BI Enterprise Editionのコールド・フェイルオーバー・クラスタ・デプロイメントに固有の要件は、次のアーティファクトも共有ディスクに確実に存在し、フェイルオーバー・クラスタの両方のノードの同じマウント・ポイントで確実にアクセスできるということです。デフォルトのインストールで構成する場合、暗黙的にこのようになります。
BIEEプレゼンテーション・カタログ
BIEEリポジトリの公開ディレクトリ(RPD)
Oracle BI EEコンポーネントの管理対象サーバーを変換する手順は、次のとおりです。
biee-domain.xmlファイルを編集して、ホスト名をcfcvip.mycompany.comに置換します。このbiee-domain.xmlファイルは、次のディレクトリにあります。
MW_HOME/user_projects/domains/bifoundation_domain/config/fmwconfig
BI_SERVER管理対象サーバーのフロントエンド・ホストをcfcvip.mycompany.comに設定します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「環境」セクションで「サーバー」を選択します。
管理対象サーバー名を選択します。
「プロトコル」を選択してから、「HTTP」を選択します。
「フロントエンド・ホスト」フィールドで、ホスト名をcfcvip.mycompany.comとして入力します。
フロントエンド・ポートをHTTPポートに設定します。
「保存」をクリックします。
変更をアクティブ化します。
管理対象サーバーを再起動します。
システム・コンポーネントの変換
システム・コンポーネントを変換する手順は、次のとおりです。
ドメインのOracle Fusion Middlewareコンソールにログインします。
「Business Intelligence」→コア・アプリケーション→「容量管理」→「スケーラビリティ」に移動します。
Oracleインスタンス(instance1)については、「リスニング・アドレス」をcfcvip.mycompany.comに変更します。
「構成をロックして編集」をクリックして、「リスニング・アドレス」をcfcvip.mycompany.comに変更します。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
管理対象サーバーとシステム・コンポーネントの両方を再起動します(opmnctlを使用します)。
Oracle BI Enterprise Editionのクライアントの変換
Oracle BI Enterprise Editionのクライアントを変換する手順は次のとおりです。
Oracle BI Enterprise Editionのクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。
WSM-PMは同じ管理対象サーバーにデプロイされるため、WSM-PMで必要なクライアント側の構成変更も完了していることを確認してください。
BI Enterprise Edition製品スイートに含まれるその他のコンポーネントで、Oracle BI Publisherのように仮想ホスト名を使用するサービスを利用するためにOracle BI Enterprise Editionのサービスを使用するコンポーネントを構成します。
BI Publisherでは、BI Enterprise Editionのインスタンスを参照するデータ・ソースを変更するか、作成する必要があります(新規作成する場合は新しい仮想ホストを使用)。変更する手順は次のとおりです。
BI Publisherの管理コンソールに移動します。
「データソース」の下にある「JDBC接続」をクリックします。
このインスタンスのBI Enterprise Editionのデータ・ソースをすべて編集して、cfcvip.mycompany.comに接続するようにします。
BI PublisherがBIEEデプロイメントに統合されている場合は、新しい仮想アドレスでBI PublisherがPresentation Servicesを検出するように構成します。この手順の詳細は、この章のBI Publisherの項を確認してください。
Oracle HTTP ServerがOracle BI Enterprise Editionのフロントエンドである場合、テキスト・エディタを使用して、仮想IPのcfcvip.mycompany.comをOracle BI Server管理対象サーバーのアドレスとして指定するように、mod_wl_ohs.confファイルを更新します。次の例を参照してください。
# BIEE Analytics <Location /analytics> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location> <Location /analytics-ws> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location> <Location /bimiddleware> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location>
Windowsに関する特別な考慮事項
Windowsプラットフォームでコールド・フェイルオーバー・クラスタ・デプロイメントを実現する手順は、次のとおりです。
ドライブ(たとえば、E:\)で共有ディスクを使用できるようにします。
BI EEスイートをE:\上のWindowsクラスタのノード1にインストールします(ソフトウェアのみのインストール)。
Middlewareホームを削除することで、E:\からソフトウェアのみのインストールを削除します。
同じ共有ディスクをノード2にフェイルオーバーして、その共有ディスクをノード2で同じドライブ(E:\)として使用できるようにします。
BI EEスイートをE:\上のWindowsクラスタのノード2にインストールします(ソフトウェアのみのインストール)。
OUI構成ウィザードを起動して、E:\上にWLSドメインとOracleインスタンスを作成します。
ノード1:
regeditを実行します。
ノードHKEY_LOCAL_MACHINE\SOFTWARE\ORACLEを検索します。
このノードを右クリックして「エクスポート」をクリックし、ファイル名を入力します。
ノードHKEY_LOCAL_MACHINE\SOFTWARE\ODBCを検索します。
このノードを右クリックして、「エクスポート」をクリックします。ファイル名を入力します。
ノードHKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Servicesを検索します。このノード内のOracleで始まる各ノードを.regファイルにエクスポートします。
ノードHKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Servicesを検索します。このノード内のOracleで始まる各ノードを.regファイルにエクスポートします。
ノードHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesを検索します。このノード内にあるOracleで始まる各ノードを、.regファイルにエクスポートします。
エクスポートしたすべての.regファイルをノード2にコピーします。
ノード2:
Oracle_BI1\bifoundation\install\vc80\vcredist_x86.exeをダブルクリックします。
ノード1からコピーした各.regファイルをダブルクリックします。ファイルごとに、「はい」をクリックして、ファイルの内容をレジストリにインポートします。
現在のノード(ノード2)で仮想IPを有効にして、このBIスイート・インストールの変換手順(第12.2.3.13.1項「Oracle Business Intelligence Enterprise Editionおよびそのクライアントの変換」)を実行します。
この項では、Oracle Business Intelligence Publisher(Oracle BI Publisher)をコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
Oracle Business Intelligence Publisherの変換
|
注意: 管理対象サーバーをCFCに変換する前に、BIプレゼンテーション・サーバーへのBIP接続を手動で編集する必要があります。 |
Oracle BI Publisherをコールド・フェイルオーバー・クラスタ環境で機能するよう変換する手順は、次のとおりです。
http://hostname:port/xmlpserverでBI Publisherアプリケーションを開いてログインします。
BIスケジューラのJMS構成を変更します。
「管理」をクリックします。
「システム・メンテナンス」で「スケジューラ構成」をクリックします。
WeblogicのJNDI URLをt3://cfcvip.mycompany.com:9704に変更します。
「適用」をクリックします。
管理対象サーバーの変換
Oracle BI Publisherが管理対象サーバー(BI_SERVER1など)にデプロイされたら、コールド・フェイルオーバー・クラスタ変換を行う手順として、この管理対象サーバーをインストール後に仮想IPのcfcvip.mycompany.comでリスニングするように構成します。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照して、BI_SERVER1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。
次に、管理コンソールまたはWLSTコマンドラインを使用して、管理対象サーバーを再起動します。
Middlewareホームの配置に関するすべての要件およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトは、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明に適用されます。Oracle BI Publisherのコールド・フェイルオーバー・クラスタに固有の要件は、必ず次のアーティファクトが共有ディスクにも存在し、フェイルオーバー・クラスタの両方のノードから同じマウント・ポイントにアクセスできるということです。デフォルトのインストールで構成する場合、暗黙的にこのようになります。
トランザクション・ログおよびJMS永続的ストア
BI Publisher構成フォルダ
BI Publisherカタログ・リポジトリ
BI Publisher Scheduler一時ディレクトリ
BI EEの統合
BI PublisherとBI EEをまとめてデプロイすると、BI PublisherはBI EEプレゼンテーション・サービスを使用するように統合されます。この設定のBI EEデプロイメントは、通常、同一の仮想ホスト名cfcvip.mycompany.comをリスニングする、コールド・フェイルオーバー・クラスタ・デプロイメントにもなります。この場合は、BI EEの統合に関連するBI Publisher構成を変更して、この新しいアドレスでBI Publisherが確実にBI EEプレゼンテーション・サービスを検出できるようにする必要があります。そのための手順は次のとおりです。
BI PublisherアプリケーションURL http://hostname:port/xmlpserverを入力してログインします。
BIスケジューラのJMS構成を変更します。
「管理」をクリックします。
「システム・メンテナンス」で「スケジューラ構成」をクリックします。
WeblogicのJNDI URLをt3://cfcvip.mycompany.com:9704に変更します。
「適用」をクリックします。
管理サーバーのコンソールまたはコマンドラインを使用して、管理対象サーバーを再起動します。
Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関するすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明のとおりです。Oracle Business Intelligence PublisherのCFCデプロイメントについての要件は、次に示すアーティファクトも共有ディスク上に確実に存在して、それらがフェイルオーバー・クラスタの両方のノードの同じマウント・ポイントで確実に使用できることです。
トランザクション・ログおよびJMS永続的ストア
BI Publisher構成フォルダ
BI Publisherカタログ・リポジトリ
BI Publisher Scheduler一時ディレクトリ
Oracle BI Publisherクライアントの変換
Oracle BI Publisherクライアントを変換する手順は、次のとおりです。
Oracle BI Publisherクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。
WSM-PMは同じ管理対象サーバーにデプロイされるため、WSM-PMで必要なクライアント側の構成変更が同じように実行されていることを確認してください。
Oracle HTTP ServerがOracle BI Publisherのフロントエンドである場合、テキスト・エディタを使用して、次の例のように、mod_wl_ohs.confファイルを更新して仮想IPのcfcvip.mycompany.comをOracle BI Publisher管理対象サーバーのアドレスとして指定します。
# BI Publisher <Location /xmlpserver> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location> # WSM-PM <Location /wsm-pm> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 </Location>
この項では、Oracle Real-Time Decisions(Oracle RTD)をコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
Oracle RTDの変換
Oracle RTDをコールド・フェイルオーバー・クラスタ・デプロイメントに変換するには、この項の手順を実行します。
Oracle RTDは管理対象サーバー(BI_SERVER1など)にデプロイされます。コールド・フェイルオーバー・クラスタ変換の手順はこの管理対象サーバーをインストール後に仮想IPのcfcvip.mycompany.comでリスニングするように構成することになります。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、BI_SERVER1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。
Middlewareホームの配置に関するすべての要件およびフェイルオーバー可能な共有記憶域上のその他のドメイン・アーティファクトは、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明に適用されます。
Oracle RTDクライアントの変換
Oracle RTDクライアントを変換する手順は次のとおりです。
Oracle RTDクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。
WSM-PMは同じ管理対象サーバーにデプロイされるため、WSM-PMで必要なクライアント側の構成変更が同じように実行されていることを確認してください。
Oracle HTTP ServerがOracle RTDのフロントエンドである場合、テキスト・エディタを使用して、次の例のように、mod_wl_ohs.confファイルを更新して仮想IPのcfcvip.mycompany.comをOracle RTD管理対象サーバーのアドレスとして指定します。
<Location /rtis> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location> <Location /schemas> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location> <Location /ws> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location> # WSM-PM <Location /wsm-pm> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 </Location> # RTD <Location /ui> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 </Location>
この項では、Oracle BI for Microsoft Officeをコールド・フェイルオーバー・クラスタ環境で機能するように変換する手順について説明します。
Oracle BI for Microsoft Officeは管理対象サーバー(BI_Server1など)にデプロイされ、コールド・フェイルオーバー・クラスタ変換を行うには、仮想IPのcfcvip.mycompany.comでリスニングするようにこのサーバーを構成します。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、BI_SERVER1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。
Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他のドメイン・アーティファクトに関するすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明のとおりです。
|
注意: BI OfficeをCFC構成内で適切に機能させるには、 |
Oracle BI for Microsoft Officeクライアントの変換
BI Officeのすべてのクライアントの起動でcfcvip.mycompany.comを使用する必要があります。OHSがBIOFFICEのフロントエンドである場合、テキスト・エディタを使用して、仮想IPのcfcvip.mycompany.comをOracle BI for Microsoft Office管理対象サーバーのアドレスとして指定するように、mod_wl_ohs.confファイルを更新します。次の例を参照してください。
# BI Office <Location /bioffice> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com WebLogicPort port </Location> <Location /biofficeclient> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com WebLogicPort port </Location>
シングル・サインオン(SSO)の再登録は通常、Oracle Portal、Forms、ReportsおよびDiscovererにのみ適用されます。この層のOracle HTTP Server上のフロントエンド・リスニング・エンドポイントが仮想IPに変更された後で、保護されるURLを仮想IPによって構成するために、SSOの再登録が必要になります。SSOを再登録するには、SSOサーバーが配置されているIdentity Management 10.1.xインストールに対して次の手順を実行します。
ORACLE_HOME変数をSSOのORACLE_HOMEの場所に設定します。
次のパラメータを指定して、ORACLE_HOME/sso/bin/ssoreg.sh (Windowsの場合はssoreg.bat)を実行します。
-site_name cfcvip.mycompany.com:port
-mod_osso_url http://cfcvip.mycompany.com
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier
次に示す中間層ホームの場所に/tmp/osso.confファイルをコピーします。
ORACLE_INSTANCE/config/OHS/ohs1
ORACLE_HOME/opmn/bin/ディレクトリから次のコマンドを実行して、Oracle HTTP Serverを再起動します。
./opmnctl restartproc process-type=OHS
次のURLでSSOサーバーにログインします。
http://sso.mycompany.com/pls/orasso
「管理」ページ、「パートナ・アプリケーション管理」の順に選択して、node1.mycompany.comのエントリを削除します。
Oracle Privileged Account Managerを構成するコンポーネントは2つあり、Weblogicドメインに次のようにデプロイされます。
OPAMコンソール(管理サーバー上にデプロイされる)
OPAMサーバー(管理対象サーバー上にデプロイされる)
OPAMコンソールの変換は、管理サーバーの変換の一部として行われます。ただし、OPAMコンソールはOPAMサーバーのクライアントでもあるため、変換後のOPAMサーバーで動作するよう再構成する必要があります。OPAMコンソール変換の最初の手順は、OPAMサーバーの変換です。
OPAMは独自のSSL構成を持たず、WebLogicと同一のSSL構成を使用します。このため、SSLの再構成はOPAMコンソールの変換において重要な作業になります。
SSLの再構成およびOPAMコンソール変換の手順は、次のとおりです。
OPAMサーバーが使用するアイデンティティ･キーストアを更新し、サーバー証明書でサーバーのIDがVIPホスト(cfcvip.mycompany.com)であると示されるようにします。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のIDおよび信頼の構成に関する項を参照してください。
管理対象サーバーのSSL構成の変更後、OPAMコンソールはOPAMサーバーに接続できなくなります。この接続の問題は次の手順で解決します。
OPAMコンソールにOPAM_APPLICATION_CONFIGURATORロールを持つユーザーとしてログインし、OPAMコンソールのサーバー構成を更新します。詳細は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のOracle Privileged Account Managerサーバーへの接続の構成に関する項を参照してください。
Oracle Fusion Middlewareの一般的コールド・フェイルオーバー・クラスタ・デプロイメントでは、データベースもコールド・フェイルオーバー・クラスタとしてデプロイされます。この項では、単一インスタンスのOracle Databaseをコールド・フェイルオーバー・クラスタ・データベースに変換する方法について説明します。まず、この変換を実行してから、RCUを使用してデータベースをシードします。その後で、このシード済データベースを使用してFusion Middlewareをインストールします。
データベースをコールド・フェイルオーバー・クラスタ用に有効化する手順は次のとおりです。
データベース・インスタンスによって使用されるリスナー構成をlistener.oraファイルで変更します。
リスナー構成のホスト名では値として仮想ホスト名が指定されていることを確認します。さらに、リスナー・ポートを使用している他のプロセス(Oracleまたはサード・パーティ)が存在しないことも確認します。
<listener_name> =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <virtual hostname>)(PORT = port))
)
)
例:
LISTENER_CFCDB =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST cfcdbhost.mycompany.com)(PORT = 1521))
)
)
tnsnames.oraファイルを変更します。
既存のTNSサービス別名エントリを変更するか、新しいエントリを作成します。
<tns alias name> =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = <virtual hostname>)(PORT = port))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = <db service name>)
(INSTANCE_NAME = <db instance name>)
)
)
)
例:
CFCDB =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = cfcdbhost.mycompany.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = cfcdb)
(INSTANCE_NAME = cfcdb)
)
)
ローカルの.spファイルを変更して、インスタンスのlocal_listenerパラメータを更新します。
SQL*Plusを使用して、sysdbaとしてログインします。
SQL> alter system set local_listener='<tns alias name>' scope=both; )
例:
SQL> alter system set local_listener='CFCDB' scope=both;
リスナーを停止してから再起動します。
データベース・インスタンスを停止してから再起動します。
アプリケーション・サーバーのデータベース・サービスを作成します。
Oracle Application Serverで使用するデフォルト・データベース・サービスとは別に、専用のサービスを作成することをお薦めします。このサービスを作成するには、次のSQL*Plusコマンドを実行します。
SQL> execute DBMS_SERVICE.CREATE_SERVICE( '<cfc db service name>' , '<cfc db network name>' ) \
例:
SQL> execute DBMS_SERVICE.CREATE_SERVICE( 'cfcdb_asservice' , 'cfcdb_asservice' )
このサービスを開始するには、次のSQL*PLUSコマンドを実行します。
SQL> execute DBMS_SERVICE.START_SERVICE( 'cfcdb_asservice' )
インストールの必要性に応じて、このサービスに追加パラメータを設定することもできます。DBMS_SERVICEコマンドの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
UnixおよびWindowsプラットフォームのデータベース・インスタンスについて次の手順を検討してください。
Unixの場合:
前述のマウントおよびアンマウントの手順に従って、ノード1(インストール・ノード)からフェイルオーバー・ノード(ノード2)へ手動でデータベースのOracleホームをフェイルオーバーさせます。
rootとして、次の操作を行います。
ノード1にあるものと同一のoraInst.locファイルを/etcディレクトリに作成します。
ノード1にあるものと同一のoratabファイルを/etcディレクトリに作成します。
ORACLE_HOMEディレクトリにあるoracleRoot.shファイルをノード2で実行します。これは、製品スイートで利用可能な場合や必要に応じて実行します。
ORACLE_HOME/oui/bin/attachHome.shディレクトリにあるattachHomeコマンドを使用して、oraInventoryファイルを2番目のノードで作成します。
Windowsの場合:
ノード1のシステム環境変数Pathにこのデータベースに関するなんらかの情報が含まれている場合、ノード2の同じ変数にも必ずその情報を設定します。ノード1からレジストリHKEY_LOCAL_MACHINE\SOFTWARE\Oracleをエクスポートして、それをノード2にインポートします。ノード2のORA_DBAグループにもユーザーsystemが存在することを確認します。
Windowsリソース・キットのSCツールを使用して、次のサービスを作成します。
dbサービス
sc create OracleService<oracle_sid> start= demand binPath= "ORACLE_HOME\bin\ORACLE.EXE <oracle_sid>"
例:
sc create OracleServiceORCL start= auto binPath= "C:\Oracle\db\product\11.1.0\bin\ORACLE.EXE <oracle_sid>"
|
注意:
|
リスナー
sc create Oracle<home name>TNSListener start= demand binPath= "ORACLE_HOME\bin\TNSLSNR"
例:
sc create OracleINFRATNSListener start= demand binPath= "C:\Oracle\db\product\11.1.0\bin\TNSLSNR"
クラスタ・サービス
sc create OracleCSService start= auto binPath= "ORACLE_HOME\bin\ocssd.exe service"
例:
sc create OracleCSService start= auto binPath= "INFRAHOME\bin\ocssd.exe service"
データベース・コンソール
sc create OracleDBConsole<oracle_sid> start= auto binPath= "ORACLE_HOME\bin\nmesrvc service"
例:
sc create OracleDBConsoleorcl start= auto binPath= " C:\Oracle\db\product\11.1.0\bin\nmesrvc service"
ジョブ・スケジューラ
sc create OracleJobScheduler<oracle_sid> start= demand binPath= "ORACLE_HOME\bin\extjob.exe <oracle_sid>"
例:
sc create OracleJobSchedulerORCL start= auto binPath= "C:\Oracle\db\product\11.1.0\INFRAHOME\bin\extjob.exe <oracle_sid>"
|
注意:
|
Vssサービス
sc create OracleVssWriter<oracle_sid> start= demand binPath= "ORACLE_HOME\bin\OraVSSW.exe <oracle_sid>"
例:
sc create OracleJobSchedulerORCL start= auto binPath= "C:\Oracle\db\product\11.1.0\INFRAHOME\bin\ OraVSSW.exe <oracle_sid>"
|
注意:
|
この項では、コールド・フェイルオーバー・クラスタのトポロジ例について説明します。トポロジでは様々な組合せが考えられるため、ここで示すトポロジは例にすぎません。これらのトポロジを実現するには、複数の変換手順が適用されます。変換を構成する方法の詳細は、前述の各手順を参照してください。
図12-3は、Oracle WebCenterポータルのコールド・フェイルオーバー・クラスタ・デプロイメントを示しています。ドメイン内には管理サーバーとWebCenter管理対象サーバーの両方があり、1つのユニットとしてフェイルオーバーします。したがって、これらは同じ仮想IPを共有し、同じ共有ディスク上にまとめてインストールされています。このトポロジのフロントエンドとしてOracle HTTP Serverも使用できます。このトポロジ例では、別のノードに配置されています。同じノードに配置して、コールド・フェイルオーバー・クラスタ・デプロイメントの一部とすることも可能です。この例では、データベースも別のノードに配置されています。しかし、データベースも同様に、同じクラスタ上に配置して、コールド・フェイルオーバー・クラスタベースにする場合もあります(仮想IPと共有ディスクは専用のものを使用)。
図12-4は、SOAコールド・フェイルオーバー・クラスタ・デプロイメント例を示しています。この例では、SOAインスタンスのみがコールド・フェイルオーバー・クラスタとしてデプロイされ、管理サーバーは別のノードに配置されています。このトポロジ例では、データベースも別のノードに配置されています。この例では、Oracle HTTP Serverはコールド・フェイルオーバー・クラスタ・デプロイメントの一部であり、SOA管理対象サーバーと同じフェイルオーバー・ユニットの一部になります。このトポロジの重要なバリエーションの1つは、同じハードウェア・クラスタにコールド・フェイルオーバー・クラスタ管理サーバーを組み込むことです。この場合、仮想IPと共有ディスクをSOA管理対象サーバーと共有するか(管理サーバーをSOAと同じフェイルオーバー・ユニットに組み込む)、別の仮想IPと共有ディスクを使用(管理サーバーを別個にフェイルオーバーさせる)できます。同様に、マシンの処理能力に応じて、データベース・インスタンスも同じハードウェア・クラスタに配置できます。
図12-5は、Oracle Identity Managementデプロイメントを示しています。このトポロジ例では、すべてのコンポーネントが、2つのノードのハードウェア・クラスタに配置されています。Identity Managementは1つのユニットとしてフェイルオーバーし、Java EEコンポーネント(管理サーバーとWLS_ods管理対象サーバー)とシステム・コンポーネントの両方が、同じフェイルオーバー・ユニットの一部となっています。これらは同じ仮想IP(cfcvip1.mycompany.com)と共有ディスクを使用しています。データベースも同じハードウェア・クラスタに配置されています。異なる仮想IP cfcvip2.mycompany.comと、異なる共有ディスク・セットを使用しています。通常の運用中では、データベースはノード2で実行し、IDMスタックはノード1で実行します。それぞれのノードは互いにバックアップ・ノードとして機能します。
このトポロジは、ほとんどのコールド・フェイルオーバー・クラスタ・デプロイメントの推奨トポロジです。例ではIdentity Managementを使用していますが、Oracle SOA、Oracle WebCenterポータル、Oracle Portal、Forms、ReportsおよびDiscovererスイートにも有効です。推奨アーキテクチャでは、Oracle Fusion Middlewareはハードウェア・クラスタの1つのノードとして実行します。別のノードではOracle Databaseを実行します。各ノードは互いにバックアップ・ノードになります。Oracle Fusion Middlewareインスタンスとデータベース・インスタンスは、異なる共有ディスクと異なるVIPを使用し、互いに独立してフェイルオーバーします。また、このアーキテクチャでは、ハードウェア・クラスタ・リソースの使用率が最適化されます。
この項では、既存のドメインの管理サーバーをコールド・フェイルオーバー・クラスタに変換する手順について説明します。
|
注意: この項で説明するコールド・フェイルオーバー・クラスタの変換手順は、Oracle Portal、Reports、FormsおよびDiscovererではサポートされません。 |
|
注意: 管理サーバーの変換後、第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」で述べられているように、管理サーバーおよびEnterprise Managerのクライアント側の変更が必要になる場合があります。 |
前提事項
この項の手順は、次を前提としています。
すべてのFusion Middlewareコンポーネントは、nostageデプロイメントに配置されています。
起動トポロジが製品スイートのアクティブ/アクティブ・クラスタです(ノード1およびノード2)。
開始する管理サーバーはノード1です。
ノード1の管理対象サーバーと同じドメイン・ホームを共有しています。
MW_HOMEパスがノード1とノード2で同じです。
開始トポロジ
トポロジの起動を実行するには、次の項を参照してください。
Oracle SOA Suite: 第5.13項「Oracle SOAインフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」
Oracle ADF: 第6.2項「Oracle ADFの高可用性デプロイメントの構成」
Oracle WebCenterポータル: 第6.4項「WebCenterポータルの高可用性の構成」
Oracle Identity Manager: 第8章「Identity Managementコンポーネントの高可用性の構成」
これらの手順は、前提が満たされていれば、Oracle WebLogicクラスタ・インストールにデプロイされているカスタマ・アプリケーションにも適用されます。
図12-6は、管理サーバーを変換する前の開始トポロジの例を示しています。
図12-7に、コールド・フェイルオーバー・クラスタ用に管理サーバーを変換した後の可能なトポロジを示します。このトポロジは、次のような特性を持ちます。
管理サーバー・ドメイン・ホームは、ノード1とノード2の両方でマウント可能な共有ディスクに移動しますが、任意の時点では片方のみがマウントされます。
引き続き、ノード1とノード2からアクセスできる元のMiddlewareホームが使用されます。
管理サーバーのリスニング・アドレスは、仮想IPになります。
既存のドメインで管理サーバーを変換するには、次の手順を実行します。
コンポーネントの管理対象サーバーおよび管理サーバーのクラスタをシャットダウンします。
各ノードでノード・マネージャ・プロセスが稼働していれば、それをシャットダウンします。
ドメイン全体をバックアップします。
ノード1で仮想IPをプロビジョニングします。例:
Linuxの場合:
/sbin/ifconfig eth0:1 IP_Address netmask netmask /sbin/arping -q -U -c 3 -I eth0 IP_Address
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。
次の例では、Local Area ConnectionのインタフェースでIPアドレスが有効化されます。
/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0 /sbin/arping -q -U -c 3 -I eth0 130.35.46.17
Windowsの場合:
netsh interface ip add address interface IP_Address netmask
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。
次の例では、「Local Area Connection」のインタフェースでIPアドレスが有効化されます。
netsh interface ip add address "Local Area connection" 130.35.46.17 255.255.224.0
ローカルのドメイン・ホームから管理サーバーを起動します。
cd DOMAIN_HOME/bin
./startWeblogic.sh
管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
管理コンソールにログインします。
仮想ホストに備えてノードを作成します。
「環境」、「マシン」の順に選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。「新規」をクリックします。
「名前」フィールドでは、cfcvip.mycompany.comと入力します。
|
注意: 「リスニング・アドレス」フィールドはlocalhostに設定したままにします(CFCソリューションはこの設定に依存します)。これを仮想IPアドレスまたはその他の値に変更しないでください。 |
管理サーバーには、ローカルだけでなく複数のノード・マネージャと対話できるように新しい仮想ホスト・マシンが必要です。各ホストの各ノード・マネージャは、実際のIPおよびローカル・ホスト(127.0.0.1)の両方のすべてのインタフェースでリスニングします。管理サーバーは、新しい仮想ホスト・マシン定義を排他的に使用します。
localhostはアクティブなマシンの相対内部アドレスであり、管理サーバーに固定されるため、仮想ホスト・マシンはlocalhostを指す必要があります。管理サーバーをあるホストから別のホストに変更しても、同じ仮想名およびVIPが保持されます。管理サーバーはlocalhost属性と1つ目のノードを組み合せて使用し、フェイルオーバー後は2つ目のノードも使用するため、管理サーバーと関連付けられているノード・マネージャも変更されます。
適切なオペレーティング・システムを選択して、「OK」をクリックします。
作成したマシンを選択します。
「サーバー」タブをクリックしてから、「追加」をクリックします。
既存のサーバーを選択して、このマシンに関連付けます。
「サーバーの選択」ドロップダウン・リストで、「AdminServer」が選択されていることを確認します。
「終了」→「変更のアクティブ化」をクリックします。
cfcvip.mycompany.com上でリスニングするように管理サーバーを構成します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
管理サーバー(AdminServer)をクリックします。
「リスニング・アドレス」をcfcvip.mycompany.comに変更し、「保存」をクリックします。
管理コンソールから管理サーバーを停止します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」をクリックします。
その横にあるチェック・ボックスをクリックして、「Adminserver」を選択します。
「停止」プルダウン・メニューで、「ただちに強制停止」を選択して、管理サーバーをシャットダウンします。
「はい」をクリックします。
コマンドラインから、システムでVIPが有効で、管理サーバーが起動していることを確認します。
cd DOMAIN_HOME/bin
./startWeblogic.sh
仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
管理コンソールを使用して、ノード1の管理サーバーシャットダウンします。
ノード1で共有ディスクがプロビジョニングおよびマウントされていることを確認します。
ノード1でドメイン全体をパックします。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=false -domain=/localdisk/user_projects/domains/domain_name -template=cfcdomaintemplate_all.jar -template_name=cfc_domain_template_all
それを共有ディスク上に解凍します。
./unpack.sh -domain=/shareddisk/user_projects/domains/domain_name
-template=cfcdomaintemplate_all.jar
-app_dir=/shareddisk/user_projects/apps -server_start_mode=prod
製品スイート固有の変更:
Oracle Identity Management製品スイート:
config.xmlファイルをバックアップします。この例では、/shareddisk/user_projects/domains/domain_name/config/ディレクトリにあります。
WCCソケット・ホスト・フィルタを次のファイル内のVIPに変更します。
{domain}/ucm/ibr/config/config.cfg
{domain}/ucm/urm/config/config.cfg
{domain}/ucm/cs/config/config.cfg
config.xmlファイルを編集してソースパスに次の変更を行います。この例では、/shareddisk/user_projects/domains/domain_name/configにあります。
dipappで、ソースパスをORACLE_HOME/ldap/odi/dipapp/dipapps.earに変更します。
例:
<app-deployment>
<name>DIP#11.1.1.2.0</name>
<target>cluster_ods</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/ldap/odi/dipapp/dipapps.ear</source_path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</app-deployment>
ODSMアプリケーションで、ソースパスをORACLE_HOME/ldap/odsm/odsm.earに変更します。
例:
<app-deployment>
<name>odsm#11.1.1.2.0</name>
<target>cluster_ods</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/ldap/odsm/odsm.ear</source-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</app-deployment>
OIF:
次のようにして、OIF-APPのソースパスを ORACLE_HOME/fed/install/oif.earに変更します。
<app-deployment>
<name>OIF#11.1.1.2.0</name>
<target>cluster_oif</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/fed/install/oif.ear</source-path>
<security-dd-model>Advanced</security-dd-model>
<staging-mode>nostage</staging-mode>
</app-deployment>
oif-libsのソースパスをORACLE_HOME/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.earに変更します。
<library>
<name>oif-libs#11.1.1.2.0@11.1.1.2.0</name>
<target>cluster_oif</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.ear</source-path>
<security-dd-model>DDOnly</security-dd-model>
</library>
OINAV (OPAMコンソール) App:
OINAV-APPのソース･パスをORACLE_HOME/oinav/modules/oinav.earに変更します。
例:
<app-deployment>
<name>oinav_11.1.1.2.0</name>
<target>AdminServer</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/oinav/modules/oinav.ear</source-path>
<security-dd-model>DDOnly</security-dd-model>
</app-deployment>
管理サーバーを起動します。
cd /shareddisk/user_projects/domains/domain_name/bin
./startWeblogic.sh
仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
管理サーバーをシャットダウンします。
ノード1で次を実行します。
mv /localdisk/user_projects/domains/domain_name /localdisk/user_projects/domains/domain_name_old mv /localdisk/user_projects/applications/domain_name /localdisk/user_projects/applications/domain_name_old cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=/shareddisk/user_projects/domains/domain_name -template=cfcdomaintemplate_mngd.jar -template_name=cfc_domain_template_mngd ./unpack.sh -domain=/localdisk/user_projects/domains/domain_name -template=cfcdomaintemplate_mngd.jar
|
注意: これらのコマンドでは、アプリケーション・ディレクトリが |
テンプレートをノード2にコピーします。
scp ORACLE_COMMON_HOME/common/bin/cfcdomaintemplate_mngd.jar Node2:ORACLE_COMMON_HOME/common/bin
ノード2にログインして、ノード2上で解凍します。
mv /localdisk/user_projects/domains/domain_name /localdisk/user_projects/domains/domain_name_old mv /localdisk/user_projects/applications/domain_name /localdisk/user_projects/applications/domain_name_old cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=/localdisk/user_projects/domains/domain_name -template=cfcdomaintemplate_mngd.jar
|
注意: これらのコマンドでは、アプリケーション・ディレクトリが |
Oracle Identity Manager Suiteでは、次の追加手順が必要です。
DIPの場合:
ノード1で、WebLogic Serverドメイン・ディレクトリ内のアプリケーション・ディレクトリを探します。
MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applications
ノード1のアプリケーション・ディレクトリとその内容を、ノード2のドメイン・ディレクトリ内の同じ場所にコピーします。
scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers
/wls_ods1/applications
user@IDMHOST2:MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig
/servers/wls_ods2/applications
OIFの場合:
ノード1で、WebLogic Serverドメイン・ディレクトリ内のアプリケーション・ディレクトリを探します。
MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig/servers/wls_oif1/applications
ノード1のアプリケーション・ディレクトリとその内容を、ノード2のドメイン・ディレクトリ内の同じ場所にコピーします。
scp -rp MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig/servers
/wls_oif1/applications
user@IDMHOST2:MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig
/servers/wls_oif2/applications
管理サーバーを起動します。
cd /shareddisk/user_projects/domains/domain_name/bin
./startWeblogic.sh
ノード1およびノード2でノード・マネージャが使用されている場合、それを起動します。
cd WL_HOME/server/bin
./startNodeManager.sh
管理サーバー・コンソール(ノード・マネージャが使用されている場合)またはコマンドラインからノード1およびノード2上のコンポーネントの管理対象サーバーを起動します。
コンポーネント固有の機能テストを使用してデプロイメントを検証します。
管理サーバーのフェイルオーバーをテストします。
管理サーバーを2番目のノードに手動でフェイルオーバーさせます。
管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。
Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。
記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。
ノード1で仮想IPを無効化します。
Linuxの場合:
ifconfig interface:index down
次の例では、eth0インタフェースでIPアドレスが無効化されます。
ifconfig eth0:1 down
Windowsの場合:
netsh interface ip delete address interface addr=IP Address
この場合、IP Addressは仮想IPアドレスです。
次の例では、Local Area ConnectionのインタフェースでIPアドレスが有効化されます。
netsh interface ip delete address 'Local Area connection' addr=130.35.46.17
ノード2で仮想IPを有効化します。
次のコマンドを使用して、管理サーバー・プロセスを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。
管理サーバーとOracle Enterprise Manager管理コンソールの両方へのアクセスを検証します。
コンポーネント固有のテストで検証します。
検証後、管理サーバーが通常に稼働し、通常に処理を実行するノード(ノード1またはノード2)にフェイルバックします。
