ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド
11gリリース2 (11.1.2.2)
B69538-05
  目次へ移動
目次
前
前 		 次
次		  

15 Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ

この章では、アクティブ/パッシブ・トポロジを構成して管理する方法について説明します。次の項目が含まれます。

15.1 Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジの概要

Oracle Fusion Middlewareは、Oracle Fusion Middleware Cold Failover Cluster(コールド・フェイルオーバー・クラスタ)を使用して、すべてのコンポーネントにアクティブ/パッシブ・モデルを提供します。コールド・フェイルオーバー・クラスタ構成では、複数の管理対象サーバー・インスタンスが同じアプリケーション・ワークロードを処理するように構成されますが、アクティブになるインスタンスは常に1つのみです。

2つのノードのコールド・フェイルオーバー・クラスタを使用すると、中間層コンポーネントのアクティブ/パッシブ構成の可用性を実現できます。コールド・フェイルオーバー・クラスタでは、1つのノードがアクティブになり、別のノードはスタンバイ・ノードとしてパッシブになります。アクティブ・ノードで障害が発生すると、スタンバイ・ノードがアクティブ化され、中間層コンポーネントはそのノードからクライアント・リクエストの処理を続行します。すべての中間層コンポーネントが新しいアクティブ・ノードにフェイルオーバーします。フェイルオーバー後、障害ノードでは中間層コンポーネントは実行されなくなります。

コールド・フェイルオーバー・クラスタ構成の最も一般的なプロパティは、次のとおりです。

アクティブ/パッシブ・デプロイメントの場合、通常、サービスが停止する時間は短時間です。これは、同じノード上でインスタンスを再起動するのに要する時間、またはパッシブ・ノードにインスタンスをフェイルオーバーするに要する時間になります。

アクティブ/パッシブ・トポロジ: 長所

アクティブ/パッシブ・トポロジ: 短所

15.2 アクティブ/パッシブ・デプロイメントのためのOracle Fusion Middlewareの構成

Oracle Fusion Middlewareコンポーネントには、様々な種類の、Java EEコンテナにデプロイされたコンポーネントと非Java EEコンポーネントがあります。Oracle Internet Directory、Oracle Virtual DirectoryおよびOracle Reportsはシステム・コンポーネントです。Oracle SOA SuiteやOracle WebCenter Portalは、Oracle WebLogic ServerにデプロイされるJava EEコンポーネントです。

管理コンソールとOracle Enterprise Manager Fusion Middleware ControlもWebLogicコンテナにデプロイされます。Java EEコンポーネントとシステム・コンポーネントのどちらも、コールド・フェイルオーバー・クラスタ環境にデプロイでき、同じシステム上または異なるシステム上で共存させることができます。同じシステムに配置すると、同じ仮想IPを共有して単一ユニットとしてフェイルオーバーするように構成できますし、別々の仮想IPを使用して個別にフェイルオーバーするようにも構成できます。ほとんどのOracle Fusion Middlewareデプロイメントでは、リポジトリ作成ユーティリティ(RCU)を使用して作成されたコンポーネント・メタデータ用やアプリケーション・データ用にデータベースが使用されます。多くの場合、コールド・フェイルオーバー・クラスタ中間層デプロイメントでは、同じクラスタにデプロイされたコールド・フェイルオーバー・クラスタ・データベースが使用されます。一般的なデプロイメントには、同じハードウェア・クラスタにある異なる共有ディスクと異なるVIPを使用して別々のフェイルオーバー・ユニットとして構成されたコンポーネントが2つあります。

Oracle Fusion Middlewareにおいて、アクティブ/パッシブ・トポロジを作成するには、次の手順を実行します。

  1. 単一インスタンス構成としてコンポーネントをインストールします。このインスタンスをコールド・フェイルオーバー・クラスタ・デプロイメントに変換する予定がある場合、共有ディスクを使用してインストールします。つまり、Middlewareホーム、インスタンス・ホーム(システム・コンポーネントの場合)およびドメイン・ディレクトリ(WebLogicデプロイメントの場合)を共有ディスク上に配置します。1つのユニットとしてフェイルオーバーするものはすべて、共有ディスク上に配置する必要があります。

  2. インストール後、デプロイメントをコールド・フェイルオーバー・クラスタ・デプロイメントに変換し、仮想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インスタンスやドメインなど、あらゆるデプロイメントでは、これらの複数のコンポーネントがマシンにインストールされます。インスタンスやドメインの全体を変換する手順は次のとおりです。

この項の内容は次のとおりです。

15.2.1 コールド・フェイルオーバー・クラスタの要件

コールド・フェイルオーバー・クラスタのデプロイには、2つ以上のノードを使用します。これらのノードの1つにインストールを行い、もう一方のノードはパッシブ・ノードとなります。両方のノードの要件は、次のとおりです。

  • 各ノードはオペレーティング・システム・レベルのあらゆる面で同じである必要があります。たとえば、オペレーティング・システム、バージョンおよびパッチ・レベルが同一である必要があります。

  • 各ノードはハードウェアの特性が同じである必要があります。それによって、通常の運用中とフェイルオーバー時のパフォーマンスが予測可能になります。通常の役割を処理できる処理能力に加えて、フェイルオーバー・シナリオに対応するために対応が必要な負荷が増大しても処理できるように、各ノードを設計することをお薦めします。停止シナリオ中におけるパフォーマンスの低下がサービス・レベル合意(SLA)で許容される場合のみ、その必要はありません。

  • 通常の運用中とフェイルオーバー時のどちらでも同じノードに対して共有記憶域をマウントできるように、各ノードで同じマウント・ポイントが解放されている必要があります。

  • 2つのノードのユーザーIDとグループIDが類似しており、インスタンスを所有するユーザーのユーザーIDとグループIDが両方のノードで同じである必要があります。

  • oraInventoryの場所が両方のノードで同じであり、インスタンスまたはドメインの所有者のアクセス・レベルが類似している必要があります。oraInst.locファイルの場所だけでなくbeahomelistファイルの場所も同じである必要があります。

  • 指定インスタンスでは、現在アクティブになっているマシンには関係なく、同じリスニング・ポートを使用するため、コールド・フェイルオーバー・クラスタのインスタンスで使用するポートが両方のノードで解放されていることを確認します。


注意:

変換を開始する前に、ドメイン全体のバックアップを実行してください。また、ソース・ファイルの編集前にローカル・バックアップ・ファイルを作成することをお薦めします。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。次のバックアップを作成することをお薦めします。

  • すべてのドメイン・ディレクトリ

  • すべてのインスタンス・ホーム

  • データベース・リポジトリ(オプション)

  • Middlewareホーム(オプション)

15.2.2 ディレクトリおよび環境変数の用語

次のリストは、この章で使用するディレクトリと変数について説明しています。

  • ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。

  • MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware (FMW)が常駐している場所を指します。

  • WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。

  • ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、特定のOracle FMW Suite (SOAなど)がインストールされている場所を指します。

  • 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: FMWインストール(MW_HOMEまたはDOMAIN_HOME)がローカル・ディスク上にある場合のディレクトリ・ツリーのルート。それはローカル・ディスクのMW_HOMEを表すために使用されます。

  • /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

WebCenter Content

MW_HOME/wcc

WCCDomain

MW_HOME/user_projects/domains/WCCDomain

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

適用なし

適用なし

アプリケーション・ディレクトリの場所の例: ORACLE_BASE/admin/domain_name/apps

Oracleインスタンスの場所の例: ORACLE_BASE/admin/instance_name

共有記憶域のマウント・ポイントにはORACLE_BASEをお薦めします。多くの場合、この場所に、フェイルオーバー・ユニットのすべての永続ビットが同じ共有記憶域に格納されることになります。1つのノードに複数のコールド・フェイルオーバー・クラスタが存在する場合に、それぞれが独立してフェイルオーバーすると、フェイルオーバー・ユニットのそれぞれに対して異なるマウント・ポイントが存在します。

15.2.3 Oracle Fusion Middlewareインフラストラクチャ・コンポーネントの変換

Oracle Fusion Middlewareデプロイメントは、すべての製品セットに共通する基本インフラストラクチャ・コンポーネントで構成されます。この項では、これらのコンポーネントのコールド・フェイルオーバー・クラスタ変換手順について説明します。

コールド・フェイルオーバー・クラスタ構成では、2つの管理サーバー・トロポジがサポートされています。次の各項では、これら2つのトポロジについて説明します。また、コールド・フェイルオーバー・クラスタ変換用に管理サーバーを準備するためにインストールと構成を行う手順についても説明します。

この項の内容は次のとおりです。

15.2.3.1 管理サーバーのトポロジ1

図15-1は、Oracle Cold Failover Clusterにおける最初のサポート対象トポロジを示しています。

図15-1 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ1

図15-1の説明が続きます
「図15-1 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ1」の説明

図15-1では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。Middlewareホームとドメイン・ディレクトリは、ある時点でノード1またはノード2にマウントされている共有ディスク上にあります。Middlewareホームとドメイン・ディレクトリは両方とも、同じ共有ディスク上、またはいっしょにフェイルオーバーできる複数の共有ディスク上にあります。複数のアプリケーションまたは環境用に複数のFusion Middlewareドメインがある企業では、管理サーバーの高可用性にはこのトポロジが最適です。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。それぞれの管理サーバーでは、その仮想IPおよび一連の共有ディスクを使用して、ドメイン・サービスの高可用性を実現できます。

15.2.3.2 トポロジ1のインストール手順

このトロポジの管理対象サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。

Middlewareホームのインストール

このインストールには、共有ディスク上におけるOracleホーム、WebLogicホームおよびドメイン・ホームが含まれます。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。ストレージ・サブシステムにおいて複数のノードでの同時マウントが可能な場合でも、これが推奨構成になります。これは、通常の単一インスタンス型インストールとして実行されます。管理サーバー(およびEnterprise Manager)の単体インストールの詳細は、当該コンポーネントに関連する章を参照してください。各スイートの全体的な手順は次のとおりです。

管理サーバーのみ:

  1. WebLogic Serverソフトウェアをインストールします。

    『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

  2. 構成ウィザードを起動して、管理サーバーのみのドメインを作成します。

    「ドメイン・ソースの選択」画面で、次を選択します。

    • 以下の製品をサポートするために、自動的に構成されたドメインを生成する

    • 「Enterprise Manager」と「Oracle JRF」を選択します。

For Oracle SOA、Oracle WebCenter PortalまたはOracle WebCenter Contentの場合:

  1. WebLogic Serverソフトウェアをインストールします。

    『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

  2. Oracle SOA、Oracle WebCenter PortalまたはOracle WebCenter ContentのOracleホームをインストールします。

    Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』または『Oracle WebCenter Contentインストレーション・ガイド』を参照してください。

Oracle Identity Managementの場合:

  1. WebLogic Serverソフトウェアをインストールします。

    『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

  2. Oracle Identity Management 11gのインストーラで、ドメイン作成オプションを使用してIDMドメインをインストールおよび構成します。「コンポーネントの構成」画面で、Enterprise Manager(デフォルトで選択されています)以外のすべての選択を解除します。

    『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

Oracle Portal、Forms、ReportsおよびDiscovererの場合:

  1. WebLogic Serverソフトウェアをインストールします。

    『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

  2. Oracle Fusion Middleware 11g Portal、Forms、ReportsおよびDiscovererのインストーラで、ドメイン作成オプションを使用してクラシック・ドメインをインストールおよび構成します。「コンポーネントの構成」画面で、Enterprise Managerが選択されていることを確認します。


注意:

この場合、製品コンポーネント用に1つ以上の管理対象サーバーがこのプロセスでインストールされます(管理サーバー単独のインストールはできません)。この管理対象サーバーは、該当コンポーネントの手順に従ってCFCに変換する必要があります。これは、管理サーバーのユニットと同じフェイルオーバー・ユニットの一部になります。

Oracle Business Intelligenceの場合:

  1. WebLogic Serverソフトウェアをインストールします。

    『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

  2. Oracle Fusion Middleware 11g Business Intelligenceインストーラで、BIシステムを新規作成するオプションを使用して、Business Intelligenceドメインのインストールと構成を実行します。


注意:

この場合、製品コンポーネント用に1つ以上の管理対象サーバーがこのプロセスでインストールされます(管理サーバー単独のインストールはできません)。この管理対象サーバーは、該当コンポーネントの手順に従ってCFCに変換する必要があります。これは、管理サーバーのユニットと同じフェイルオーバー・ユニットの一部になります。

コールド・フェイルオーバー・クラスタ用の管理サーバーの構成

コールド・フェイルオーバー・クラスタ用に管理サーバーを構成する手順は次のとおりです。

  1. rootユーザーとして次のコマンドを使用して、仮想IPをプロビジョニングします。

    /sbin/ifconfig interface:index IP_Address netmask netmask
/sbin/arping -q -U -c 3 -I interface IP_Address

    ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIP_addressが有効化されます。

    /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

  2. 第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。

  3. 仮想IP上のコンソールにアクセスすることで、管理サーバーの変換を検証します。この仮想IPアドレスは、新規IPアドレスです。この仮想IPアドレスのみを使用することをお薦めします。

    http://cfcvip.example.com:7001/console

    http://cfcvip.example.com:7001/em

  4. 次の手順に従って、管理サーバーを2番目のノードに手動でフェイルオーバーさせます。


    注意:

    管理サーバーがノード・マネージャによって管理されている場合は、コールド・フェイルオーバー・クラスタのノードマネージャを有効にする必要があります。

    1. 管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。

    2. Middlewareホームとドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。

    3. 記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。

    4. rootユーザーとして次のコマンドを使用して、ノード1で仮想IPを無効化します。

      /sbin/ifconfig interface:index down

      次の例では、eth0インタフェースで仮想IP_Addressが無効化されます。

      /sbin/ifconfig eth0:1 down

    5. ステップ1と同じコマンドを使用して、ノード2で仮想IPを有効化します。

    6. 管理サーバー・プロセスを起動します。

      DOMAIN_HOME/bin/startWebLogic.sh

      DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。

    7. 管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。

15.2.3.3 管理サーバーのトポロジ2

図15-2は、Oracle Cold Failover Clusterにおける2番目のサポート対象管理サーバー・トポロジを示しています。

図15-2 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ2

管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ2
「図15-2 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ2」の説明

図15-2では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。管理サーバーが使用するドメイン・ディレクトリは、共有ディスク上にあります。これは必須です。この共有ディスクは、ある時点でノード1またはノード2にマウントされます。ソフトウェアを格納するMiddlewareホーム(WebLogicホームとOracleホーム)は、共有ディスク上でなくてもかまいません。ローカル・ディスクにも配置できます。管理サーバーをノード1で実行する場合は、ソフトウェアにノード1のMiddlewareホームを使用し、ノード2で実行する場合は、ノード2のMiddlewareホームを使用します。2つのMiddlewareホームは、デプロイされた製品、Oracleホームおよびパッチに関して同じ状態に維持する必要があります。どちらの場合も、共有ドメイン・ディレクトリやドメイン・ホームで利用できる構成を使用します。これは共有されるため、フェイルオーバーの前後で同じ構成が使用されるようになります。

この共有ドメイン・ディレクトリでは、他の管理対象サーバーも実行できます。また、管理サーバー専用にも使用できます。ドメイン・ディレクトリを他の管理対象サーバーと共有する場合、管理サーバーがフェイルオーバーされるときのために、それらのフェイルオーバーに関して適切に考慮する必要があります。考慮事項の一部を次に示します。

  1. 読取りや書込みを行うために複数のノードで同時に共有記憶域をマウントできる場合は、管理サーバーのドメイン・ディレクトリを他の管理対象サーバーと共有できます。また、管理対象サーバーとは別にフェイルオーバーすることもできます。管理サーバーをフェイルオーバーして、指定ノードで独立して管理対象サーバーの実行を継続できます。これが可能な理由は、この場合、管理サーバーはVIPのフェイルオーバーのみを必要とし、共有ディスクのフェイルオーバーは必要としないためです。管理対象サーバーは、引き続きドメイン・ディレクトリやドメイン・ホームを利用できます。このような記憶域の例として、クラスタ・ファイル・システムに接続されたNASやSAN/Directなどの記憶域があります。

  2. 一度に1つのノードのみ共有記憶域をマウントできる場合、管理サーバーのドメイン・ディレクトリを管理対象サーバーと共有することは、管理サーバーがフェイルオーバーされると、同じドメイン・ディレクトリから切り離される管理対象サーバーを停止する必要があることを意味します。

このトポロジでは、ハードウェア・クラスタを使用するとフェイルオーバーの自動化に役立ちます(適切に構成されたクラスタウェアを使用した場合)。ただし、これは必須ではありません。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。各管理サーバーでそれぞれ固有の仮想IPと共有ディスク・セットを使用して、ドメイン・サービスの高可用性を実現できます。

このトポロジは、Oracle SOA SuiteおよびOracle WebCenter Portal Suiteに対してのみサポートされています。


注意:

Oracle Identity Managementについては、コールド・フェイルオーバー・クラスタのための代替トポロジもサポートされています。詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

15.2.3.4 トポロジ2のインストール手順

このトロポジの管理サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。

Middlewareホームのインストール

OracleホームとWebLogicホームを含むMiddlewareホームを、ドメインにある2つのノードに個別にインストールします。管理サーバー・ドメイン・ディレクトリは共有ディスク上に作成します。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。これは、通常の単一インスタンス型インストールです。管理サーバーおよびEnterprise Managerの単体インストールの詳細は、製品スイートを参照してください。

Oracle SOA Suite、Oracle WebCenter PortalまたはOracle WebCenter ContentのMiddlewareホームをインストールする手順は次のとおりです。

  1. ノード1にOracle WebLogic Serverソフトウェアをインストールします。

  2. ノード1にSOAまたはWebCenterのOracleホームをインストールします。

  3. ノード2でステップ1とステップ2を繰り返します。

  4. ノード1で構成ウィザードを起動して、管理サーバーのみのドメインを作成します。

    「ドメイン・ソースの選択」画面で、次を選択します。

    • 以下の製品をサポートするために、自動的に構成されたドメインを生成する

    • Enterprise ManagerとOracle JRFを選択します。

  5. 「ドメイン名と場所の指定」画面で、ドメイン名を入力し、ドメイン・ディレクトリがディレクトリと共有記憶域のマウント・ポイントに一致していることを確認します。

コールド・フェイルオーバー・クラスタ用のMiddlewareホームの構成

コールド・フェイルオーバー・クラスタ用にMiddlewareホームを構成する手順は次のとおりです。

  1. 仮想IPをプロビジョニングします。例:

    /sbin/ifconfig eth0:1 IP_Address netmask netmask
/sbin/arping -q -U -c 3 -I eth0 IP_Address

    ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIP_Addressが有効化されます。

    /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

  2. 第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。

  3. 仮想IP上でコンソールにアクセスして、管理サーバーを検証します。

    http://cfcvip.example.com:7001/console

    http://cfcvip.example.com:7001/em

  4. 管理サーバーを2番目のノードに手動でフェイルオーバーさせます。

    1. 管理サーバー・プロセス、および指定されているMiddlewareホームの外部で実行されているその他のプロセスを停止します。

    2. Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。

    3. 記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。

    4. ノード1で仮想IPを無効化します。

      /sbin/ifconfig interface:index down

      次の例では、eth0インタフェースでIP_Addressが無効化されます。

      /sbin/ifconfig eth0:1 down

    5. ノード2で仮想IPを有効化します。

    6. 次のコマンドを使用して、管理サーバー・プロセスを起動します。

      DOMAIN_HOME/bin/startWebLogic.sh

      DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。

    7. 管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。

15.2.3.5 コールド・フェイルオーバー・クラスタ用の管理サーバーの変換

共有ディスクにインストールされている管理サーバーをノード1から変換するには、この項の手順に従ってください。この手順ではコンテナを変換するため、管理コンソールとOracle Enterprise Manager Fusion Middleware Controlの両方がコールド・フェイルオーバー・クラスタ用に変換されます。それにより、このコンテナにデプロイされるOWSM-PMなどの他のコンポーネントも、コールド・フェイルオーバー・クラスタ対応になります。これらすべてのサービスのアドレスがcfcvip.example.comに変換されます。インストール後、コールド・フェイルオーバー・クラスタでないインスタンスをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。

  1. 管理コンソールにログインします。

  2. 仮想ホストのマシンを作成します。

    1. 「環境」、「マシン」の順に選択します。

    2. 「チェンジ・センター」で、「ロックして編集」、「新規」の順にクリックします。

    3. 「名前」フィールドにcfcvip.example.comと入力します。

    4. 「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。

    5. 「次」、「終了」の順にクリックします。


      注意:

      「リスニング・アドレス」フィールドはlocalhostに設定したままにします(CFCソリューションはこの設定に依存します)。これを仮想IP_Addressまたはその他の値に変更しないでください。

    6. 「マシンのサマリー」タブで、作成したばかりのマシンの名前をクリックします。

    7. 「サーバー」タブをクリックしてから、「追加」をクリックします。

    8. サーバー選択のドロップダウン・リストで、「AdminServer」が選択されていることを確認します。

    9. 「終了」をクリックします。

    10. 「変更のアクティブ化」をクリックします。

  3. cfcvip.example.com上でリスニングするように管理サーバーを構成します。

    1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

    2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

    3. 管理サーバー(AdminServer)をクリックします。

    4. リスニング・アドレスをcfcvip.example.comに変更します。

    5. 「保存」をクリックします。

    6. 「変更のアクティブ化」をクリックします。

    7. 管理サーバーを再起動します。


      注意:

      通常、管理サーバーのコールド・フェイルオーバー・クラスタへの変換はドメイン作成時に実行されることが期待されるため、ドメインにおいて他の部分への変更は行われないものと考えられます。この変更がドメイン作成後に行われ、他のコンポーネントがドメインにインストールされている場合、次の管理サーバー変換項で説明している手順に従ってください。

管理サーバーのクライアント側構成の変更

ドメインにある既存エンティティでは、管理サーバーとの通信に新しいアドレスを使用する必要があります。たとえば、管理対象サーバーを手動で起動する際は、管理サーバーのアドレスをcfcvip.example.comとして指定します。

ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるinstance.propertiesファイルで、次の変更を行います。

adminHost=cfcvip.example.com

OPMN登録コマンドを使用して、コールド・フェイルオーバー・クラスタ管理サーバーにOracleインスタンスを登録したり再登録する場合は、opmnctlコマンドのAdminHostの場所で管理サーバーの新しい場所(cfcvip.example.com)を参照します。

Oracle Enterprise Managerのクライアント側構成の変更

Enterprise Managerは管理サーバーが稼働する同じコンテナの一部であるため、管理サーバーをコールド・フェイルオーバー・クラスタに変換すると、Enterprise Managerも変換されます。ドメインの一部として構成されたEnterprise Managerエージェントが存在する場合は、それらのエージェント構成でEnterprise Managerの新しい場所を使用する必要があります。Enterprise Managerの新しい場所を構成するには、エージェントごとに次の手順を行います。

  1. ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/configに設定します。

  2. emd.propertiesファイルで、次の属性内のnode1.example.comをcfcvip.example.comに変更します。

    • REPOSITORY_URL

    • emdWalletSrcUrl

  3. 次のコマンドを使用して、エージェントを停止してから再起動します。

    cd ORACLE_INSTANCE/EMAGENT/emagent_dir/bin 
./emctl stop agent 
./emctl start agent 
./emctl status agent

    これによってリポジトリのURLが表示されます。このURLは新しいホストを指します。

15.2.3.6 Oracle WebLogic管理対象サーバーの変換

すべてのOracle Fusion Middlewareコンポーネントは、管理対象サーバーにデプロイされます。Oracle WebLogic Serverにデプロイされたアプリケーションやコンポーネントをコールド・フェイルオーバー・クラスタに変換する際の重要な手順としては、使用する仮想IPにリスニング・アドレスを変更することがあります。この変更は、対象のコンポーネントがデプロイされている特定の管理対象サーバーに対して実行します。この変更には、管理コンソールまたはWLSTコマンドを使用できます。

次の例では、WLS_EXMPLという管理対象サーバーをコールド・フェイルオーバー・クラスタに変換する一般的手順について説明します。これらの手順は、Fusion Middlewareコンポーネントの管理対象サーバーに適用されます。

この項の内容は次のとおりです。

15.2.3.6.1 Fusion Middleware管理コンソールによるOracle WebLogic管理対象サーバーの変換

次の手順で、cfcvip.example.comはコールド・フェイルオーバー・クラスタに使用する仮想IPで、WLS_EXMPLは変換対象となる管理対象サーバーです。

  1. 管理コンソールにログインします。

  2. 仮想ホストのマシンを作成します。

    1. 「環境」→「マシン」を選択します。

    2. 「チェンジ・センター」で、「ロックして編集」をクリックし「新規」をクリックします。


      注意:

      管理サーバーの変換で別のVIPを使用した場合にのみ、新しいマシンを作成します。その場合、手順gに進みます。

    3. 「名前」フィールドでは、cfcvip.example.comと入力します。

    4. 「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。

    5. 「Next」をクリックして、「Finish」をクリックします。

      ノード・マネージャを変換する場合は、次の手順を実行する必要があります。

    6. 新しく作成したマシンをクリックします。

    7. 「ノード・マネージャ」タブをクリックします。

    8. リスニング・アドレスをcfcvip.example.comに更新します。

    9. 「保存」をクリックします。

    10. 「変更のアクティブ化」をクリックします。

    11. 第15.2.3.7項「ノード・マネージャの変換」の手順を完了します。

  3. WLS_EXMPL管理対象サーバーを停止します。

    1. 「環境」→「サーバー」を選択します。

    2. 「制御」をクリックします。

    3. 「WLS_EXMPL」を選択します。

    4. 「停止」ドロップダウン・メニューで、「ただちに強制停止」を選択します。

  4. WLS_EXMPL管理対象サーバーを仮想ホストのマシンに関連付けます。

    1. 「環境」→「サーバー」を選択します。

    2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

    3. 「構成」をクリックします。

    4. 「WLS_EXMPL」を選択します。

    5. 「マシン」では、プルダウン・メニューから新規作成マシンを選択して割り当てます。

    6. 「リスニング・アドレス」にcfcvip.example.comと入力します。

    7. 「保存」をクリックします。

    8. 「変更のアクティブ化」をクリックします。

  5. 管理対象サーバーWLS_EXMPLを起動します。


注意:

サーバー・インスタンスを起動および停止する方法は数種類あります。以前にサーバー・インスタンスを起動および停止した方法を使用してください。

15.2.3.6.2 WLSTコマンド行によるOracle WebLogic管理対象サーバーの変換

WLSTコマンドを使用してもOracle WebLogic管理対象サーバーを変換できます。

次の手順を実行する前に、変換対象となる管理対象サーバーを停止することをお薦めします。

オンライン・モード(WebLogic Server管理サーバーが稼働している状態)でWLSTコマンド行を使用して管理対象サーバーを変換する手順は次のとおりです。

  1. コマンド行で次のように入力します。

    WL_HOME/server/bin/setWLSEnv.sh
WL_HOME/common/bin/wlst.sh

  2. WLSTで、次のコマンドを入力します。

    wls:/offline>connect(<username>,<password>,<AdminServer location>)

    例:

    wls:/offline>connect('WebLogic', 'welcome1', 't3://cfcvip.example.com:7001')

wls:/DomainName/serverConfig> edit()
wls:/DomainName/edit> startEdit()
wls:/DomainName/edit !> create('cfcvip.example.com','Machine')
wls:/DomainName/edit !> cd('Machines/cfcvip.example.com/NodeManager/cfcvip.example.com')
wls:/DomainName/edit !> set('ListenAddress', 'cfcvip.example.com')
wls:/DomainName/edit !>cd ('Servers')
wls:/DomainName/edit/Servers !>cd ('WLS_EXMPL')
wls:/DomainName/edit/Servers/WLS_EXMPL !>set('Machine',' cfcvip.example.com ')
wls:/DomainName/edit/Servers/WLS_EXMPL !>set('ListenAddress',' cfcvip.example.com ')
wls:/DomainName/edit/Servers/WLS_EXMPL !> save()
wls:/DomainName/edit/Servers/WLS_EXMPL !> activate()
wls:/DomainName/edit/Servers/WLS_EXMPL> exit()

  3. 管理対象サーバーを停止してから(停止していない場合)、再起動します。

管理対象サーバーの変換の完了後に、このサーバーに対するすべての参照で新しいリスニング・アドレスcfcvip.example.comが使用されていることを確認します。Oracle HTTP Serverがこの管理対象サーバーのフロントエンドとして機能している場合、この管理対象サーバー上のアプリケーションを参照しているマウント・ポイントでmod_wls_ohs構成をすべて変更して、新しいリスニング・エンド・ポイントにルーティングします。

注意:

Oracle FMW SOAサーバーを既存またはデプロイされているコンポジットを使用して変換する場合は、以前のサーバーのリスニング・アドレスが表示される可能性のある場所がいくつかあります。OHSまたはLBRがサーバーのフロントエンドとなる場合、参照は、サーバーのリスニング・アドレスを反映しないため変更されません。

  • デプロイされたコンポジットには、特定のエンドポイント参照が含まれる場合があります。たとえば、特定の参照用のバインド・プロパティとして指定されたcallbackServerURLが使用される場合があります。これらの参照は、新しいサーバーのVIPに更新する必要があります。

  • Enterprise Manager内のsoa-infraアプリケーションに指定されたSOAプロパティのコンポジット・リレー。ServerURLおよびCAllBackURLがデフォルトのNull値から変更されている場合は、これらを更新する必要があります。

  • システムはサーバー・レベルで設定されたフロントエンド・アドレスを使用します。したがって、新しいVIPを反映するように更新する必要があります。

15.2.3.7 ノード・マネージャの変換

コールド・フェイルオーバー・クラスタ環境ではノード・マネージャを使用できます。コールド・フェイルオーバー・クラスタ・スタックの残りの部分とともにフェイルオーバーしないノード・マネージャ。この場合、ノード・マネージャはコールド・フェイルオーバー・クラスタ用に構成されずに、コールド・フェイルオーバー・クラスタの仮想IPだけでなく、マシン上のすべてのIPをリスニングします。また、フェイルオーバー・ノードには、同様に構成されているノード・マネージャが配置され、構成済になっています。WebLogicインスタンスに関連付けられたノードは、ローカル・ホスト上のノード・マネージャと通信します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』を参照してください。

一般的にコールド・フェイルオーバー・クラスタの場合、フェイルオーバー発生時にポートが競合しないように、ポートの使用を計画する必要があります。

ノード・マネージャをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。

  1. ノード・マネージャが実行されている場合は停止します。

    ノード・マネージャが最初に起動された後にのみ、nodemanager.propertiesファイルは作成されます。

    必要に応じて、ノード・マネージャを再起動します。

  2. WL_HOME/common/nodemanager/ディレクトリにあるnodemanager.propertiesファイルで、ListenAddressを仮想IPに設定します。

    例:

    ListenAddress=cfcvip.example.com

  3. WL_HOME/server/binディレクトリにあるstartNodeManager.shファイルを使用して、ノード・マネージャを再起動します。


    注意:

    WebLogic管理対象サーバーおよび管理サーバーでは、ホスト名の検証は特定のインストールで有効化または無効化できます。検証が有効でノード・マネージャがこれらのインスタンスを管理しているCFCインストールでは、ホスト名の検証の手順の中で仮想IPのcfcvip.example.comの証明書を使用する必要があります。

15.2.3.8 Oracle Process Management and Notification Serverの変換

Oracle Process Management and Notification Server (OPMN)は、システム・コンポーネントのプロセス管理に使用され、管理対象サーバー・インスタンスの一部です。

コールド・フェイルオーバー・クラスタ環境にデフォルトのOPMN構成を維持することをお薦めします。OPMNプロセス自体のコールド・フェイルオーバー・クラスタ変換で他に必要な手順はありません。

コールド・フェイルオーバー・クラスタ用にOracleインスタンスを変換する場合で、これが管理サーバーに登録されているときは、これらのファイルで次の変更を行います。

  1. 管理サーバー・ドメインのDOMAIN_HOME/opmnディレクトリにあるtopology.xmlファイルで、このOracleインスタンス(コールド・フェイルオーバー・クラスタ変換の対象)のホスト名エントリをcfcvip.example.comに変更します。

    たとえば、Oracle HTTP Serverインスタンスをコールド・フェイルオーバー・クラスタに変換するには、topology.xmlファイルで次のように設定します。

    <property name="HTTPMachine" value="cfcvip.example.com"/>

    インスタンス自体:

    <ias-instance id="asinst " instance-home="/11gas3/MW/asinst" host="cfcvip.example.com" port="6701">

  2. ORACLE_INSTANCE/config/OPMN/opmnディレクトリのinstance.propertiesファイルで、adminHost=<physical hostname>をadminHost=<cfcvip.example.com>に置き換えます。

  3. すべてのOPMNコンポーネントを再起動します。

15.2.3.9 OracleインスタンスのOracle Enterprise Managerの変換

Oracleインスタンスをコールド・フェイルオーバー・クラスタに変換する場合は、そのOracleインスタンスの一部であるEnterprise Managerエージェントもコールド・フェイルオーバー・クラスタに変換する必要があります。このトピックでは、エージェントおよびサーバーを変換する方法について説明します。

Enterprise Managerエージェントを変換する手順は次のとおりです。

  1. 次のコマンドを使用して、Enterprise Managerエージェントを停止します。

    cd ORACLE_INSTANCE/EMAGENT/emagent_dir/bin
./emctl stop agent

  2. ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/configに設定します。

  3. マネージドBeanを使用し、それに対する操作を設定して、物理ホスト名を仮想ホスト名に置換します。例: emoms.props:Location=AdminServer,name=emoms.properties,type=Properties,Application=em

    属性ごとにこの操作を行うには、次の手順を実行します。

    1. Enterprise Manager (http://cfcvip.example.com:7001/em)にログインします。


      注意:

      この手順では、仮想ホスト名cfcvip.example.comでリスニングするために、管理サーバーのリスニング・アドレスを変換しているものと仮定します。詳細は、第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。

    2. 「WebLogicドメイン」を展開します。

    3. ドメイン名を右クリックして、「システムMBeanブラウザ」を選択します。

    4. 検索アイコン(双眼鏡)を選択します。enoms.props:Locationを入力して、マネージドBeanを表示します。

    5. 「属性」タブを選択します。

    6. 「プロパティ」を選択します。ホスト名は、要素のリスト内にあります。例:

      +Element_ElementNumber
 key example.sysman.emSDK.svlt.ConsoleServerName 
value hostname.example.com:7001_Management_Service

 +Element_ElementNumber 
 key example.sysman.emSDK.svlt.ConsoleServerHost 
 value hostname.example.com

    7. 「操作」タブを選択してから、「SetProperty」リンクを選択します。

    8. キー名と新しい値を入力します。「起動」を選択します。

  4. emd.propertiesファイルで、EMD_URL属性のnode1.example.comをcfcvip.example.comに変更します。

  5. エージェント側のtargets.xmlファイルを変更します。

    cd ORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/emd
cp targets.xml targets.xml.org

    ホストとoracle_emdに関連付けられたターゲットのみが含まれるように、targets.xmlを変更します。他のエントリはすべて削除します。例:

    <Targets AGENT_TOKEN="ad4e5899e7341bfe8c36ac4459a4d569ddbf03bc"> 
       <Target TYPE="oracle_emd" NAME="cfcvip.example.com:port"/> 
       <Target TYPE="host" NAME="cfcvip.example.com"  DISPLAY_NAME="cfcvip.example.com/>" 
</Targets>

  6. エージェントを再起動します。

    cd ORACLE_INSTANCE/EMAGENT/emagent_dir/bin 
./emctl start agent

Enterprise Managerサーバーを変換するには、管理サーバーのドメイン・ディレクトリで、次の変更を行います。

変更を行う前に、管理サーバーを停止します。

  1. 使用ディレクトリをMW_HOME/user_projects/domains/domain_name/sysman/stateに設定します。

  2. MW_HOME/user_projects/domains/domain_name/sysman/stateディレクトリにあるtargets.xmlファイルで、ホスト名をnode1.example.comからcfcvip.example.comに変更します。

  3. 管理サーバーを再起動します。

15.2.3.10 Web層のコンポーネントとクライアントの変換

Web層は、2つの主要コンポーネントであるOracle HTTP ServerとOracle Web Cacheで構成されます。次の2つの項では、Oracle HTTP ServerとOracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する方法について説明します。

15.2.3.10.1 Oracle HTTP Serverの変換

Oracle HTTP Serverをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。

  1. ORACLE_INSTANCE/config/OHS/component_name/httpd.confで、次の属性を変更します。

    Listen cfcvip.example.com:port #OHS_LISTEN_PORT
Listen cfcvip.example.com:port #OHS_PROXY_PORT
ServerName cfcvip.example.com

  2. ORACLE_INSTANCE/config/OHS/component_name/admin.confで、次の属性を変更します。

    Listen cfcvip.example.com:port #OHS_LISTEN_PORT
Listen cfcvip.example.com:port #OHS_ADMINISTRATOR_PORT
ServerName cfcvip.example.com

  3. Oracle HTTP Serverを再起動します。

    .cd ORACLE_INSTANCE/bin
./opmnctl restartproc process-type=OHS

また、第15.2.4.7項「シングル・サインオンの再登録(必要な場合)」で説明されているシングル・サインオンの登録も実行します。

Oracle HTTP Serverのクライアント

コールド・フェイルオーバー・クラスタに変換したOracle HTTP ServerにOracle Web Cacheインスタンスがルーティングされる場合は、ORACLE_INSTANCE/config/WebCache/component_name/webcache.xmlで次の属性を変更します。

node1.example.comをcfcvip.example.comに変更します(node1.example.comは変換前のOracle HTTP Serverのアドレスです)。

<HOST ID="h1" NAME="cfcvip.example.com" PORT="8888" LOADLIMIT="100"
 OSSTATE="ON"/>
<HOST ID="h2" NAME="cfcvip.example.com" PORT="8890" LOADLIMIT="100" OSSTATE="ON"
 SSLENABLED="SSL"/>
15.2.3.10.2 Oracle Web Cacheの変換

Oracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。

  1. クラスタの両方のノードにある/etc/hostsで、物理ホスト名に別名を設定します。

    これはノードのIP_Addressの別名です。/etc/hosts内で設定します。この別名は、wcprfx.example.comです。たとえば、ノード1では、/etc/hostsファイルのエントリはn.n.n.n node1 node1.example.com wcprfx wcprfx.example.comになります。

    フェイルオーバー・ノードのノード2では、/etc/hostsファイルのエントリはn.n.n.m node2 node2.example.com wcprfx wcprfx.example.comになります。

  2. ORACLE_INSTANCE/config/WebCache/component_name/webcache.xmlで次を実行します。

    • node1.example.comをcfcvip.example.comに変更します(node1.example.comはOracle Web Cacheがインストールされている場所であり、変換前にリスニング対象となるホスト・アドレスです)。

      SITE NAME="cfcvip.example.com"

    • SSLポートと非SSLポートで仮想ホスト名のエントリをcfcvip.example.comに変更します。例:

      <HOST SSLENABLED="NONE" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8888"
NAME="cfcvip.example.com" ID="h0"/>
<HOST SSLENABLED="SSL" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8890"
NAME="cfcvip.example.com" ID="h3"/>
<VIRTUALHOSTMAP PORT="8094" NAME="cfcvip.example.com">
   <HOSTREF HOSTID="h3"/>
</VIRTUALHOSTMAP>
<VIRTUALHOSTMAP PORT="8090" NAME="cfcvip.example.com">
   <HOSTREF HOSTID="h0"/>
</VIRTUALHOSTMAP>

    • wcprfx.example.comに基づくように、キャッシュ名エントリを変更します(wcprfx.example.comは、クラスタにあるすべてのノードの/etc/hostsで作成された別名です)。例:

      <CACHE WCDEBUGON="NO" CAPACITY="30" VOTES="1" INSTANCENAME="asinst_1"
COMPONENTNAME="wc1" ORACLEINSTANCE="ORACLE_INSTANCE"
HOSTNAME="wcprfx.example.com" ORACLEHOME="ORACLE_HOME"
NAME="wcprfx.example.com-WebCache">

    • MULTIPORTセクションで、次の構成のIPADDRをANYからcfcvip.example.comに変更します。

      PORTTYPE="NORM"
SSLENABLED="SSL" PORTTYPE="NORM"
PORTTYPE="ADMINISTRATION"
PORTTYPE="INVALIDATION"
PORTTYPE="STATISTICS"

      例:

      <MULTIPORT>
   <LISTEN PORTTYPE="NORM" PORT="8090"
IPADDR="cfcvip.example.com"/>
   <LISTEN SSLENABLED="SSL" PORTTYPE="NORM" PORT="8094"
IPADDR="cfcvip.example.com">
       <WALLET>ORACLE_INSTANCE/config/WebCache/wc1/keystores/
default</WALLET>
   </LISTEN>
   <LISTEN PORTTYPE="ADMINISTRATION" PORT="8091"
IPADDR="cfcvip.example.com"/>
   <LISTEN PORTTYPE="INVALIDATION" PORT="8093" IPADDR="
cfcvip.example.com"/>
   <LISTEN PORTTYPE="STATISTICS" PORT="8092"
IPADDR="cfcvip.example.com"/>
</MULTIPORT>

  3. Oracle Web Cacheを再起動します。

    cd ORACLE_INSTANCE/bin
./opmnctl restartproc process-type=WebCache

15.2.4 Oracle Fusion Middlewareコンポーネントの変換

この項では、次のFusion Middlewareコンポーネントについて説明します。

製品コンポーネントの詳細は、このガイドで適切なコンポーネントに関連する章を参照してください。

15.2.4.1 Oracle Virtual Directoryおよびそのクライアントの変換

この項では、Oracle Virtual Directoryとそのクライアントを変換する方法について説明します。次の項目が含まれます。

15.2.4.1.1 Oracle Virtual Directoryの変換

Oracle Virtual Directoryサーバーを変換する手順は次のとおりです。

  1. テキスト・エディタで、ORACLE_INSTANCE/config/OVD/componentnameディレクトリにあるlisteners.os_xmlファイルを開きます。

  2. 次の値を入力し、LDAPアドレスを仮想IPに設定します。

    <host>cfcvip.example.com</host>

  3. opmnctlを使用して、Oracle Virtual Directoryサーバーを再起動します。

    例:

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1
15.2.4.1.2 キーストアの新しい鍵の生成

管理者は、(自己署名またはCAによって署名された)仮想ホスト名を使用して新規鍵ペアを生成し、この証明書をOVDリスナー構成で関連付ける必要があります。この証明書は、EMAgentによって信頼される必要があり、これに対して信頼できる証明書としてEMAgentのcwallet.ssoにインポートする必要があります。

詳細は、第8.3.5.2項「WLSTを使用したキーストアの新しい鍵の生成」を参照してください。

管理ゲートウェイ・リスナーまたはLDAP SSLエンドポイント・リスナーで異なるキーストアを選択するか、キーストアの証明書を変更する場合は、Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに証明書をインポートする必要があります。証明書をインポートしない場合、Oracle Enterprise Manager Fusion Middleware ControlはOracle Virtual Directoryに接続してパフォーマンス・メトリックを取得することができません。

Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに証明書をインポートする手順:

  1. 次のコマンドを実行して、Oracle Virtual Directoryサーバーの証明書をエクスポートします。

    ORACLE_HOME/jdk/jre/bin/keytool -exportcert \
-keystore OVD_KEYSTORE_FILE -storepass PASSWORD \
-alias OVD_SERVER_CERT_ALIAS -rfc \
-file OVD_SERVER_CERT_FILE

  2. 次のコマンドを実行して、Oracle Virtual Directoryサーバーの証明書を、Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに追加します。

    ORACLE_COMMON_HOME/bin/orapki wallet add -wallet \
$ORACLE_INSTANCE/EMAGENT/EMAGENT/sysman/config/monwallet \
-trusted_cert -cert OVD_SERVER_CERT_FILE -pwd WALLET_PASSWORD
15.2.4.1.3 Oracle Virtual Directoryクライアントの変換

Oracle Virtual Directoryのすべてのクライアントは、仮想IPのcfcvip.example.comを使用して、Oracle Virtual Directoryにアクセスする必要があります。たとえば、Oracle Directory Services Managerを使用してコールド・フェイルオーバー・クラスタのOracle Virtual Directoryインスタンスを管理する場合は、Oracle Virtual Directoryインスタンスの場所としてcfcvip.example.comを使用して接続を作成します。

15.2.4.2 Oracle Directory Integration PlatformおよびOracle Directory Services Managerとそれぞれのクライアントの変換

この項では、Oracle Directory Integration Platform、Oracle Directory Services Managerおよびそれぞれのクライアントを変換する方法について説明します。

15.2.4.2.1 Oracle Directory Integration PlatformとOracle Directory Services Managerの変換

Oracle Directory Integration PlatformとOracle Directory Services Managerは管理対象サーバーにデプロイされます。CFC変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_ODS管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。

15.2.4.2.2 Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントの変換

次の手順に従って、Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントを変換します。

  1. Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントは、仮想IPのcfcvip.example.comを使用してこれらのアプリケーションにアクセスする必要があります。

  2. Oracle HTTP ServerがOracle Directory Services Managerのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_ODS管理対象サーバーのアドレスとして仮想IPのcfcvip.example.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.example.com
    WebLogic port
</Location>

15.2.4.3 Oracle Identity Federationおよびそのクライアントの変換

この項では、Oracle Identity Federationとそのクライアントを変換する方法について説明します。

15.2.4.3.1 Oracle Identity Federationの変換

Oracle Identity Federationは、管理サーバーにデプロイされるコンポーネントです。コールド・フェイルオーバー・クラスタ変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OIF管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。Oracle Identity Federationコールド・フェイルオーバー・クラスタ・デプロイメントは通常、サービス・プロバイダとアイデンティティ・プロバイダに分割されるため、特定のデプロイメントに複数のWLS_OIFインスタンスが存在する場合があります。どちらのWLS_OIFインスタンスに対しても、同じコールド・フェイルオーバー・クラスタ手順を適用してください。

cfcvip.example.comの仮想IP上でリスニングするように管理対象サーバーを構成した後、Oracle Enterprise Manager Fusion Middleware Controlにログインして、次の手順を実行します。

  1. 「ファーム」→「Identity and Access」→OIFに移動します。

  2. 右側のフレームで、「Oracle Identity Federation」→「管理」に移動し、次の変更を行います。

    1. サーバー・プロパティ: ホストをcfcvip.example.comに変更します。

    2. 「アイデンティティ・プロバイダ」→「共通」: providerIdをcfcvip.example.comに変更します。

    3. 「サービス・プロバイダ」→「共通」: providerIdをcfcvip.example.comに変更します。

    4. データ・ストア: データ・ストアがLDAPの場合は、ユーザー・データ・ストアとフェデレーション・データ・ストアの接続URLの値をcfcvip.example.comに置き換えます。

    5. 「認証エンジン」→「LDAPディレクトリ」: ConnectionURLをcfcvip.example.comに設定します。

  3. メタデータを生成するため、管理対象サーバーを再起動します。

15.2.4.3.2 Oracle Identity Federationクライアントの変換

次の手順に従って、Oracle Identity Federationクライアントを変換します。

  1. Oracle Identity Federationクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。

  2. Oracle HTTP ServerがOracle Identity Federationのフロントエンドである場合、Oracle Identity FederationのWebLogic構成で、WLS_OIF管理対象サーバーのアドレスとして仮想IP cfcvip.example.comを指定する必要があります。そのためには、Oracle HTTP ServerおよびOracle Identity Federationで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、oif.confファイルを次のように編集します。

    #Oracle Identity Federation
<Location /oif>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogic port
</Location>

15.2.4.4 Oracle Access Managerおよびそのクライアントの変換

この項では、Oracle Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定すること、および管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.example.com)に指定することによって設定可能です。この場合、明確な変換手順は不要です。

15.2.4.4.1 Oracle Access Managerの変換

Oracle Access Managerは管理対象サーバー(WLS_OAM1など)にデプロイされ、CFC変換を行うためには、この管理対象サーバーを、仮想IPのcfcvip.example.comでリスニングするように構成します。第15.2.3.6,項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OAM1管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第15.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

Oracle Access Managerコンソールは、ドメインの管理サーバーの一部としてデプロイされます。このコンソールのコールド・フェイルオーバー・クラスタ構成では、管理サーバー全体をアクティブ/パッシブで構成する必要があります。管理サーバーは、同じ仮想IPのcfcvip.example.comを共有することも、個別の仮想IPと共有ディスクを使用して独立してフェイルオーバーするように構成することもできます。同じ仮想IPを使用している場合、管理サーバーとOracle Access Manager管理対象サーバーは1つのユニットとしてフェイルオーバーします。

15.2.4.4.2 Oracle Access Managerクライアントの変換

次の手順に従って、Oracle Access Managerクライアントを変換します。

  1. Oracle Access Managerクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Identity ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.example.comを使用してアプリケーションにアクセスする必要があります。

  2. Oracle HTTP ServerがOracle Access Managerのフロントエンドである場合、Oracle Access Managerに関するmod_weblogic構成では、Oracle Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.example.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

    #Oracle Access Manager
<Location /oam>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com:port
</Location>

  3. 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>

15.2.4.5 Oracle Adaptive Access Managerおよびそのクライアントの変換

この項では、Oracle Adaptive Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.example.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。

15.2.4.5.1 Oracle Adaptive Access Managerの変換

Oracle Adaptive Access Managerは管理対象サーバーにデプロイされます。両方とも単一のユニットとしてフェイルオーバーするようにデプロイされ、そのために同じ仮想IPと同じ共有記憶域を共有します。OAAM Admin管理対象サーバーおよびOAAM Server管理対象サーバーをCFC変換のために変換するには、これらの管理対象サーバーを、仮想IPのcfcvip.example.comでリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第15.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

15.2.4.5.2 Oracle Adaptive Access Managerクライアントの変換

次の手順に従って、Oracle Adaptive Access Managerクライアントを変換します。

  1. Oracle Adaptive Access Managerクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Identity Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.example.comを使用してアプリケーションにアクセスする必要があります。

  2. Oracle HTTP ServerがOracle Adaptive Access Managerのフロントエンドである場合、Oracle Adaptive Access Managerに関するmod_weblogic構成では、Oracle Adaptive Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.example.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

    #Oracle Adaptive Access Manager
<Location /oaam_server>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com WebLogicPort port
</Location>

#Oracle Adaptive Access Manager Admin Console
<Location /oaam_admin>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com:port
</Location>

15.2.4.6 Oracle Identity Managerおよびそのクライアントの変換

この項では、Oracle Identity Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.example.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。

15.2.4.6.1 Oracle Identity Managerの変換

Oracle Identity Managerは、管理対象サーバーにデプロイされます。一般的なCFCデプロイメントでは、Oracle Identity Manager管理対象サーバーと、Oracle SOAおよびOracle Web Services Managerを含む別の管理対象サーバーは1つのユニットとしてフェイルオーバーするようにデプロイされ、そのために同じ仮想IPと同じ共有記憶域を共有します。この両方の管理対象サーバーをCFC変換のために変換するには、これらの管理対象サーバーを、仮想IPのcfcvip.example.comでリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第15.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

15.2.4.6.2 Oracle Identity Managerクライアントの変換

次の手順に従って、Oracle Identity Managerクライアントを変換します。

  1. Oracle Identity Managerクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.example.comを使用してアプリケーションにアクセスする必要があります。SOAもOracle Identity Managerでフェイルオーバーするように構成されているので、Oracle Identity ManagerからSOAへの接続でも共通の仮想IPを使用する必要があります。

  2. Oracle HTTP ServerがOracle Identity Managerのフロントエンドである場合、Oracle Identity Managerに関するmod_weblogic構成では、管理対象サーバーのアドレスとして仮想IPのcfcvip.example.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルまたはoim.confファイルを次のように編集します。

    #Oracle Identity Manager
<Location /oim>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com:port
    WebLogicPort port
</Location>

    Oracle Identity Managerでの構成変更の詳細は、Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドを参照してください。

15.2.4.7 シングル・サインオンの再登録(必要な場合)

シングル・サインオン(SSO)の再登録は通常、Oracle Portal、Forms、ReportsおよびDiscovererにのみ適用されます。この層のOracle HTTP Server上のフロントエンド・リスニング・エンドポイントが仮想IPに変更された後で、保護されるURLを仮想IPによって構成するために、SSOの再登録が必要になります。


注意:

11gでは、再登録ではなく新しいVIPを使用してWebGateを作成する必要があります。

SSOを再登録するには、SSOサーバーが配置されているIdentity Management 10.1.xインストールに対して次の手順を実行します。

  1. ORACLE_HOME変数をSSOのORACLE_HOMEの場所に設定します。

  2. 次のパラメータを指定して、ORACLE_HOME/sso/bin/ssoreg.shを実行します。

    -site_name cfcvip.example.com:port
-mod_osso_url http://cfcvip.example.com 
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier

  3. 次に示す中間層ホームの場所に/tmp/osso.confファイルをコピーします。

    ORACLE_INSTANCE/config/OHS/ohs1

  4. 次のコマンドをORACLE_INSTANCE/binディレクトリから実行して、Oracle HTTP Serverを再起動します。

    ./opmnctl restartproc process-type=OHS

  5. 次のURLでSSOサーバーにログインします。

    http://sso.example.com/pls/orasso

  6. 「管理」ページの「パートナ・アプリケーション管理」で、node1.example.comのエントリを削除します。

15.2.5 Fusion Middlewareフェイルオーバーの追加のアクション

コールド・フェイルオーバー・クラスタ環境では、フェイルオーバー・ノード(node2.example.com)をすべての面でインストール・マシン(node1.example.com)と同じにする必要があります。フェイルオーバー・ノードをインストール・ノードと同じにするには、フェイルオーバー・インスタンスで次の手順を実行します。

UNIXプラットフォームでの手順は次のとおりです。

  1. 前述のマウントおよびアンマウントの手順に従って、ノード1(インストール・ノード)からフェイルオーバー・ノード(ノード2)へMiddlewareホームをフェイルオーバーさせます。

  2. rootとして、次の操作を行います。

    • ノード1にあるものと同一のoraInst.locファイルを/etcディレクトリに作成します。

    • ORACLE_HOMEディレクトリにあるroot.shファイルをノード2で実行します(これは、製品スイートで利用可能な場合や必要に応じて実行します)。

  3. ORACLE_HOME/oui/bin/attachHome.shディレクトリにあるattachHomeコマンドを使用して、oraInventoryを2番目のノードで作成します。

15.2.6 Oracle Databaseの変換

Oracle Fusion Middlewareの一般的コールド・フェイルオーバー・クラスタ・デプロイメントでは、データベースもコールド・フェイルオーバー・クラスタとしてデプロイされます。この項では、単一インスタンスのOracle Databaseをコールド・フェイルオーバー・クラスタ・データベースに変換する方法について説明します。まず、この変換を実行してから、RCUを使用してデータベースをシードします。その後で、このシード済データベースを使用してFusion Middlewareをインストールします。

データベースをコールド・フェイルオーバー・クラスタ用に有効化する手順は次のとおりです。

  1. データベース・インスタンスによって使用されるリスナー構成を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.example.com)(PORT = 1521))
   )
 )

  2. 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.example.com)(PORT = 1521))
   )
   (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = cfcdb)
      (INSTANCE_NAME = cfcdb)
   )
 )

  3. ローカルの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;

  4. リスナーを停止してから再起動します。

  5. データベース・インスタンスを停止してから再起動します。

  6. アプリケーション・サーバーのデータベース・サービスを作成します。

    デフォルト・データベース・サービスとは別の、専用のサービスをお薦めします。このサービスを作成するには、次の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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

15.2.6.1 データベース・インスタンスの考慮事項

Unixプラットフォームのデータベース・インスタンスについて次の手順を検討してください。

  1. 前述のマウントおよびアンマウントの手順に従って、ノード1(インストール・ノード)からフェイルオーバー・ノード(ノード2)へ手動でデータベースのOracleホームをフェイルオーバーします。

  2. rootとして、次の操作を行います。

    • ノード1にあるものと同一のoraInst.locファイルを/etcディレクトリに作成します。

    • ノード1にあるものと同一のoratabファイルを/etcディレクトリに作成します。

    • ORACLE_HOMEディレクトリにあるoracleRoot.shファイルをノード2で実行します。これは、製品スイートで利用可能な場合や必要に応じて実行します。

  3. ORACLE_HOME/oui/bin/attachHome.shディレクトリにあるattachHomeコマンドを使用して、oraInventoryファイルを2番目のノードで作成します。

15.3 Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジ例

この項では、コールド・フェイルオーバー・クラスタのトポロジ例について説明します。トポロジでは様々な組合せが考えられるため、ここで示すトポロジは例にすぎません。これらのトポロジを実現するには、複数の変換手順が適用されます。変換を構成する方法の詳細は、前述の各手順を参照してください。

この項の内容は次のとおりです。

15.3.1 トポロジ例1

図15-3は、Oracle WebCenter Portalのコールド・フェイルオーバー・クラスタ・デプロイメントを示しています。ドメイン内には管理サーバーとWebCenter管理対象サーバーの両方があり、1つのユニットとしてフェイルオーバーします。したがって、これらは同じ仮想IPを共有し、同じ共有ディスク上にまとめてインストールされています。このトポロジのフロントエンドとしてOracle HTTP Serverも使用できます。このトポロジ例では、別のノードに配置されています。同じノードに配置して、コールド・フェイルオーバー・クラスタ・デプロイメントの一部とすることも可能です。この例では、データベースも別のノードに配置されています。しかし、データベースも同様に、同じクラスタ上に配置して、コールド・フェイルオーバー・クラスタベースにする場合もあります(仮想IPと共有ディスクは専用のものを使用)。

図15-3 コールド・フェイルオーバー・クラスタのトポロジ例1

図15-3の説明が続きます
「図15-3 コールド・フェイルオーバー・クラスタのトポロジ例1」の説明

15.3.2 トポロジ例2

図15-4は、SOAコールド・フェイルオーバー・クラスタ・デプロイメント例を示しています。この例では、SOAインスタンスのみがコールド・フェイルオーバー・クラスタとしてデプロイされ、管理サーバーは別のノードに配置されています。このトポロジ例では、データベースも別のノードに配置されています。この例では、Oracle HTTP Serverはコールド・フェイルオーバー・クラスタ・デプロイメントの一部であり、SOA管理対象サーバーと同じフェイルオーバー・ユニットの一部になります。このトポロジの重要なバリエーションの1つは、同じハードウェア・クラスタにコールド・フェイルオーバー・クラスタ管理サーバーを組み込むことです。この場合、仮想IPと共有ディスクをSOA管理対象サーバーと共有するか(管理サーバーをSOAと同じフェイルオーバー・ユニットに組み込む)、別の仮想IPと共有ディスクを使用(管理サーバーを別個にフェイルオーバーさせる)できます。同様に、マシンの処理能力に応じて、データベース・インスタンスも同じハードウェア・クラスタに配置できます。

図15-4 コールド・フェイルオーバー・クラスタのトポロジ例2

図15-4の説明が続きます
「図15-4 コールド・フェイルオーバー・クラスタのトポロジ例2」の説明

15.3.3 トポロジ例3

図15-5は、Oracle Identity Managementデプロイメントを示しています。このトポロジ例では、すべてのコンポーネントが、2つのノードのハードウェア・クラスタに配置されています。Identity Managementは1つのユニットとしてフェイルオーバーし、Java EEコンポーネント(管理サーバーとWLS_ods管理対象サーバー)とシステム・コンポーネントの両方が、同じフェイルオーバー・ユニットの一部となっています。これらは同じ仮想IP (cfcvip1.example.com)と共有ディスクを使用しています。データベースも同じハードウェア・クラスタに配置されています。異なる仮想IP cfcvip2.example.comと、異なる共有ディスク・セットを使用しています。通常の運用中では、データベースはノード2で実行し、IDMスタックはノード1で実行します。それぞれのノードは互いにバックアップ・ノードとして機能します。

このトポロジは、ほとんどのコールド・フェイルオーバー・クラスタ・デプロイメントの推奨トポロジです。例ではIdentity Managementを使用していますが、Oracle SOA、Oracle WebCenter Portal、Oracle Portal、Forms、ReportsおよびDiscovererスイートにも有効です。推奨アーキテクチャでは、Oracle Fusion Middlewareはハードウェア・クラスタの1つのノードとして実行します。別のノードではOracle Databaseを実行します。各ノードは互いにバックアップ・ノードになります。Oracle Fusion Middlewareインスタンスとデータベース・インスタンスは、異なる共有ディスクと異なるVIPを使用し、互いに独立してフェイルオーバーします。また、このアーキテクチャでは、ハードウェア・クラスタ・リソースの使用率が最適化されます。

図15-5 コールド・フェイルオーバー・クラスタのトポロジ例3

コールド・フェイルオーバー・クラスタのトポロジ例3
「図15-5 コールド・フェイルオーバー・クラスタのトポロジ例3」の説明

15.4 コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換

この項では、既存のドメインの管理サーバーをコールド・フェイルオーバー・クラスタに変換する手順について説明します。


注意:

管理サーバーの変換後、第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」で述べられているように、管理サーバーおよびEnterprise Managerのクライアント側の変更が必要になる場合があります。

前提事項

この項の手順は、次を前提としています。

これらの手順は、前提が満たされていれば、Oracle WebLogicクラスタ・インストールにデプロイされているカスタマ・アプリケーションにも適用されます。

開始トポロジ

図15-6は、管理サーバーを変換する前の開始トポロジの例を示しています。

図15-6 コールド・フェイルオーバー・クラスタの開始トポロジ例

コールド・フェイルオーバー・クラスタのトポロジ例1
「図15-6 コールド・フェイルオーバー・クラスタの開始トポロジ例」の説明

15.4.1 変換後トポロジ

図15-7に、コールド・フェイルオーバー・クラスタ用に管理サーバーを変換した後の可能なトポロジを示します。このトポロジは、次のような特性を持ちます。

  • 管理サーバー・ドメイン・ホームは、ノード1とノード2の両方でマウント可能な共有ディスクに移動しますが、任意の時点では片方のみがマウントされます。

  • 引き続き、ノード1とノード2からアクセスできる元のMiddlewareホームが使用されます。

  • 管理サーバーのリスニング・アドレスは、仮想IPになります。

図15-7 変換後の可能なトポロジ

コールド・フェイルオーバー・クラスタのトポロジ例1
「図15-7 変換後の可能なトポロジ」の説明

15.4.2 コールド・フェイルオーバー・クラスタ変換の手順

既存のドメインで管理サーバーを変換するには、次の手順を実行します。

  1. コンポーネントの管理対象サーバーおよび管理サーバーのクラスタをシャットダウンします。

  2. 各ノードでノード・マネージャ・プロセスが稼働していれば、それをシャットダウンします。

  3. ドメイン全体をバックアップします。

  4. ノード1で仮想IPをプロビジョニングします。例:

    /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_Addressが有効化されます。

    /sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0
/sbin/arping -q -U -c 3 -I eth0 IP_Address

    ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。

    次の例では、Local Area ConnectionのインタフェースでIP_Addressが有効化されます。

    netsh interface ip add address "Local Area connection" IP_Address netmask

  5. ローカルのドメイン・ホームから管理サーバーを起動します。

    cd DOMAIN_HOME/bin
./startWeblogic.sh

  6. 管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。

    管理コンソールにログインします。

    仮想ホストのマシンを作成します。

    1. 「環境」、「マシン」の順に選択します。

    2. 「チェンジ・センター」で、「ロックして編集」をクリックします。「新規」をクリックします。

    3. 「名前」フィールドにcfcvip.example.comと入力します。


      注意:

      「リスニング・アドレス」フィールドはlocalhostに設定したままにします(CFCソリューションはこの設定に依存します)。これを仮想IP_Addressまたはその他の値に変更しないでください。

      管理サーバーには、ローカルだけでなく複数のノード・マネージャと対話できるように新しい仮想ホスト・マシンが必要です。各ホストの各ノード・マネージャは、実際のIPおよびローカル・ホスト(127.0.0.1)の両方のすべてのインタフェースでリスニングします。管理サーバーは、新しい仮想ホスト・マシン定義を排他的に使用します。

      localhostはすべてのアクティブなマシンの相対内部アドレスであり、管理サーバーに固定されるため、仮想ホスト・マシンはlocalhostを指す必要があります。管理サーバーをあるホストから別のホストに変更しても、同じ仮想名およびVIPが保持されます。管理サーバーはlocalhost属性と1つ目のノードを組み合せて使用し、フェイルオーバー後は2つ目のノードも使用するため、管理サーバーと関連付けられているノード・マネージャも変更されます。図xを参照してください。

    4. 適切なオペレーティング・システムを選択して、「OK」をクリックします。

    5. 作成したマシンを選択します。

    6. 「サーバー」タブをクリックしてから、「追加」をクリックします。

    7. 既存のサーバーを選択して、このマシンに関連付けます。

    8. 「サーバーの選択」ドロップダウン・リストで、「AdminServer」が選択されていることを確認します。

    9. 「終了」→「変更のアクティブ化」をクリックします。

    cfcvip.example.com上でリスニングするように管理サーバーを構成します。

    1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

    2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

    3. 管理サーバー(AdminServer)をクリックします。

    4. 「リスニング・アドレス」をcfcvip.example.comに変更し、「保存」をクリックします。

    管理コンソールから管理サーバーを停止します。

    1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

    2. 「制御」をクリックします。

    3. その横にあるチェック・ボックスをクリックして、「Adminserver」を選択します。

    4. 「停止」プルダウン・メニューで、「ただちに強制停止」を選択して、管理サーバーをシャットダウンします。

    5. 「はい」をクリックします。

    コマンド行から、システムでVIPが有効で、管理サーバーが起動していることを確認します。

    cd DOMAIN_HOME/bin
./startWeblogic.sh

  7. 仮想IP上でコンソールにアクセスして、管理サーバーを検証します。

    • http://cfcvip.example.com:7001/console

    • http://cfcvip.example.com:7001/em

  8. 管理コンソールを使用して、ノード1の管理サーバーシャットダウンします。

  9. ノード1で共有ディスクがプロビジョニングおよびマウントされていることを確認します。

  10. ノード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

  11. それを共有ディスク上に解凍します。

    ./unpack.sh -domain=/shareddisk/user_projects/domains/domain_name
-template=cfcdomaintemplate_all.jar 
-app_dir=/shareddisk/user_projects/apps -server_start_mode=prod

  12. 製品スイート固有の変更:

    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>

  13. 管理サーバーを起動します。

    cd /shareddisk/user_projects/domains/domain_name/bin
./startWeblogic.sh

  14. 仮想IP上でコンソールにアクセスして、管理サーバーを検証します。

    • http://cfcvip.example.com:7001/console

    • http://cfcvip.example.com:7001/em

  15. 管理サーバーをシャットダウンします。

  16. ノード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

    注意:

    これらのコマンドでは、アプリケーション・ディレクトリがuser_projectsの下に存在すると想定しています。

  17. テンプレートをノード2にコピーします。

    scp ORACLE_COMMON_HOME/common/bin/cfcdomaintemplate_mngd.jar
Node2:ORACLE_COMMON_HOME/common/bin

  18. ノード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

    注意:

    これらのコマンドでは、アプリケーション・ディレクトリがuser_projectsの下に存在すると想定しています。

  19. Oracle Identity Manager Suiteでは、次の追加手順が必要です。

    DIPの場合:

    1. ノード1で、Oracle WebLogic Serverドメイン・ディレクトリ内のアプリケーション・ディレクトリを探します。

      MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applications

    2. ノード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. ノード1で、Oracle WebLogic Serverドメイン・ディレクトリ内のアプリケーション・ディレクトリを探します。

      MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig/servers/wls_oif1/applications

    2. ノード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

  20. 管理サーバーを起動します。

    cd /shareddisk/user_projects/domains/domain_name/bin
./startWeblogic.sh

  21. ノード1およびノード2でノード・マネージャが使用されている場合、それを起動します。

    cd WL_HOME/server/bin
./startNodeManager.sh

  22. 管理サーバー・コンソール(ノード・マネージャが使用されている場合)またはコマンド行からノード1およびノード2上のコンポーネントの管理対象サーバーを起動します。

  23. コンポーネント固有の機能テストを使用してデプロイメントを検証します。

  24. 管理サーバーのフェイルオーバーをテストします。

    管理サーバーを2番目のノードに手動でフェイルオーバーさせます。

    1. 管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。

    2. Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。

    3. 記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。

    4. ノード1で仮想IPを無効化します。

      ifconfig interface:index down

      次の例では、eth0インタフェースでIP_Addressが無効化されます。

      ifconfig eth0:1 down

      netsh interface ip delete address interface addr=IP_Address

      この場合、IP_Addressは仮想IP_Addressです。

      次の例では、IP_AddressはインタフェースLocal Area Connection上で有効になります。

      netsh interface ip delete address 'Local Area connection' addr=130.35.46.17

    5. ノード2で仮想IPを有効化します。

    6. 次のコマンドを使用して、管理サーバー・プロセスを起動します。

      DOMAIN_HOME/bin/startWebLogic.sh

      DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。

    管理サーバーとOracle Enterprise Manager管理コンソールの両方へのアクセスを検証します。

    コンポーネント固有のテストで検証します。

  25. 検証後、管理サーバーが通常に稼働し、通常に処理を実行するノード(ノード1またはノード2)にフェイルバックします。

  前
前 		 次
次
  目次へ移動
目次