ヘッダーをスキップ
Oracle Fusion Middleware高可用性ガイド
11gリリース1（11.1.1）
B55898-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

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

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

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

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

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

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

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

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

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

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

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

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

Oracle Fusion Middlewareにおいて、アクティブ/パッシブ・トポロジを作成するための推奨手順は次のとおりです。

この一般的手順は、コールド・フェイルオーバー・クラスタのOracleデータベースに適用されます。たとえば、Oracleデータベース・インスタンスを単一インスタンスのデプロイメントとしてインストールしてから、コールド・フェイルオーバー・クラスタ用に変換します。コールド・フェイルオーバー・クラスタのOracle Fusion Middlewareデプロイメントでは、Oracle Real Application Cluster（RAC）データベースも使用できます。

次の各項では、インストール後の構成手順について説明します。この手順によって単一インスタンスのデプロイメントをコールド・フェイルオーバー・クラスタ・デプロイメントに変換します。

この章の残りの部分では、Oracle Fusion Middlewareスイートの個別コンポーネントごとに、コールド・フェイルオーバー・クラスタを変換する方法について説明します。最初の項では、基本インフラストラクチャ・コンポーネントの手順について詳細に説明します。そしてその後続の項では、Oracle Fusion Middlewareの個別コンポーネントの手順について詳細に説明します。Oracleインスタンスやドメインなど、あらゆるデプロイメントでは、これらの複数のコンポーネントが指定マシンにインストールされます。インスタンスやドメインの全体を変換する手順は次のとおりです。

10.2.1 コールド・フェイルオーバー・クラスタの一般的要件

前述のように、コールド・フェイルオーバー・クラスタ・デプロイメントでは、2つ以上のノードがデプロイメントに含まれます。これらのノードのいずれか1つで、インストールが行われます。別のノードはパッシブ・ノードです。これら2つのノードにおける要件は次のとおりです。

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

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

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

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

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

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


注意:

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

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

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

  • 必要に応じて、データベース・リポジトリとMiddlewareホーム

  • 次のすべての項で、ファイルを変更する前にローカル・バックアップ・コピーを必ず作成してから、ファイルを編集するようにしてください。

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

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

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

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

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

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

  • DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報（構成アーティファクト）が格納されている場所を指します。

  • ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどのシステム・コンポーネントが1つ以上含まれています。Oracleインスタンス・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルが格納されています。

これらのディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。

  • ORACLE_BASE: /u01/app/oracle

  • MW_HOME（アプリケーション層）: ORACLE_BASE/product/fmw

  • WLS_HOME: MW_HOME/wlserver_10.3

コンポーネント 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


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

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

1つのユニットとしてフェイルオーバーするディスク上のすべてのエンティティは、同じマウント・ポイント上に配置することをお薦めします。しかし、別の共有記憶域に格納して、別のマウント・ポイントに配置することも可能です。共有記憶域のマウント・ポイントはORACLE_BASEにすることをお薦めします。ほとんどの場合、それによって、フェイルオーバー・ユニットのすべての永続ビットが同じ共有記憶域に格納されます。1つのノードに複数のコールド・フェイルオーバー・クラスタが存在する場合に、それぞれが他のクラスタと独立してフェイルオーバーすると、このようなフェイルオーバー・ユニットのそれぞれに対して異なるマウント・ポイントが存在します。

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

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

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

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

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

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

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

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

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

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

Middlewareホームのインストール

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

Oracle SOAまたはOracle WebCenterの場合:

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

    『Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server』を参照してください。

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

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

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

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

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

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

Oracle Identity Managementの場合:

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

    『Oracle Fusion Middleware Installation Guide for 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ソフトウェアをインストールします。

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


注意:

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

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

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

  1. 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アドレスが有効化されます。

    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

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

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

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

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

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

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

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

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

    4. 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" 130.35.46.17

    5. 手順1と同様のコマンドを使用して、ノード2で仮想IPを有効化します。

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

      DOMAIN_HOME/bin/startWebLogic.sh

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

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

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

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

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

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

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

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

このトポロジは、Oracle SOA SuiteとOracle WebCenter Suiteのみでサポートされています。


注意:

Oracle Identity Managementでは、コールド・フェイルオーバー・クラスタの代替トポロジもサポートされています。詳細は、『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management』を参照してください。

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

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

Middlewareホームのインストール

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

Oracle SOA SuiteまたはOracle WebCenterの場合:

  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をプロビジョニングします。次に例を示します。

    Linuxの場合

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

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

    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

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

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

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

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

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

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

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

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

    4. ノード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
DOMAIN_HOME/bin/startWebLogic.sh

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

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

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

      DOMAIN_HOME/bin/startWebLogic.sh

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

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

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

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

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

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

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

    2. 「ロックして編集」をクリックします。

    3. 「新規」をクリックします。

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

    5. 適切なオペレーティング・システムを選択します。

    6. 「OK」をクリックします。

    7. 「サーバー」タブをクリックします。

    8. 「追加」をクリックします。

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

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

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

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

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

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

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

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

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

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

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


      注意:

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

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

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

INSTANCE_HOME/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の新しい場所を構成するには、エージェントごとに次の手順を行います。

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

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

    • REPOSITORY_URL

    • EmdWalletSrcUrl

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

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

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

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

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

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

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

この手順を実行するには、WebLogic Server管理コンソールが稼働していることが必要です。次の例で、cfcvip.mycompany.comはコールド・フェイルオーバー・クラスタに使用する仮想IPで、WLS_EXMPLは変換対象となる管理対象サーバーです。

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

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

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

    2. 「ロックして編集」をクリックします。

    3. 「新規」をクリックします。

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

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

    6. 「OK」をクリックします。

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

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

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

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

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

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

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

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

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

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

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

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

    2. 「ロックして編集」をクリックします。

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

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

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

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

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

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

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

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

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

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

    4. 「起動」をクリックします。

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

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

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

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

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

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

  2. 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構成をすべて変更して、新しいリスニング・エンドポイントにルーティングする必要があります。

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

コールド・フェイルオーバー・クラスタ環境ではノード・マネージャを使用できます。次の構成が可能です。

  • 仮想IP上で同様にリスニングし、コールド・フェイルオーバー・クラスタ・スタックの残りの部分とともにフェイルオーバーするノード・マネージャの使用:ASCRSベースのデプロイメントでは、コールド・フェイルオーバー・クラスタのFusion Middlewareインスタンスが稼働しているMiddlewareホームと同じMiddlewareホームにノード･マネージャが属している必要があります。このノード・マネージャはこのFusion Middlewareインスタンス専用であることが前提になります。この場合は、ローカル・ホストでリスニングするネットワーク・チャネルを別に構成することをお薦めします。他のポートでリスニングするボックス上に他のノード・マネージャを共存させることができます。詳細は、第11章「Oracle Cluster Ready Servicesの使用」を参照してください。

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

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

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

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

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

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

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

    次に例を示します。

    ListenAddress=cfcvip.mycompany.com

  3. WLS_HOME/server/binディレクトリにあるStartNodeManager.shファイルを使用して、ノード・マネージャを再起動します。ASCRSベースのデプロイメントの場合は、WLS_HOME/server/bin/cfcStartNodemanager.shを使用してノード・マネージャを起動します。

    詳細は、第11章「Oracle Cluster Ready Servicesの使用」を参照してください。


    注意:

    必要に応じて、startNodeManager.shスクリプトのかわりにcfcStartNodemanager.shスクリプトのみを使用して、ノード・マネージャを起動します。

10.2.2.6 Oracle Process Management and Notification Serverの変換

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="/11gr1as3/MW/asinst" host="cfcvip.mycompany.com" port="6701">

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

Oracle Internet Directory、Oracle Virtual Directory、Web層コンポーネント、Oracle Portal、Forms、ReportsおよびDiscovererコンポーネントなどのOracleインスタンスをコールド・フェイルオーバー・クラスタに変換する場合は、そのOracleインスタンスの一部であるEnterprise Managerエージェントもコールド・フェイルオーバー･クラスタに変換する必要があります。

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

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

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

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

  3. emd.propertiesファイルで、emd_url属性のnode1.mycompany.comをcfcvip.mycompany.comに変更します。

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

    cd INSTANCE_HOME/EMAGENT/emagent_dir/sysman/emd
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>

  5. エージェントを停止してから再起動します。

    cd INSTANCE_HOME/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.mycompany.comからcfcvip.mycompany.comに変更します。

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

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

10.2.2.8.1 Oracle HTTP Serverの変換

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

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"/>
10.2.2.8.2 Oracle Web Cacheの変換

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

  1. クラスタの両方のノードにある/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です。

  2. INSTANCE_HOME/config/WebCache/wc1/webcache.xmlで、次の操作を行います。

    • node.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="/mnt1/ Oracle/Middleware/asinst_1"
 HOSTNAME="wcprfx.mycompany.com" ORACLEHOME="/mnt1/ Oracle/Middleware/as
_1" 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="stbdd01-vip.us.oracle.com"/>
            <LISTEN SSLENABLED="SSL" PORTTYPE="NORM" PORT="8094"
 IPADDR="cfcvip.mycompany.com">
              <WALLET>/mnt1/Oracle/Middleware/asinst_
1/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>

10.2.2.9 インスタンス固有の考慮事項

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

10.2.2.9.1 UNIXプラットフォーム

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

  1. ノード1（インストール・ノード）からフェイルオーバー・ノード（ノード2）へMiddlewareホームをフェイルオーバーさせます。この操作は、前述のマウント/アンマウント手順に従って手動で実行する必要があります。

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

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

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

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

10.2.2.9.2 Windowsプラットフォーム

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

ASインスタンス（Web層、IDMインストールのOID/OVD、Oracle Portal、Form、ReportsおよびDiscoverer）の場合:

  1. マシン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"

  2. マシン1とマシン2の両方で、OracleProcessManager_instance_nameサービスが手動で起動するように設定します。

    sc config OracleProcessManager_instance_name start= demand

すべてのインストールの場合:

マシン1からマシン2にスタート・メニューをコピーするため、マシン1のC:\Document and Settings\All Users\スタート メニュー\プログラム\<メニュー>にあるファイルをマシン2にコピーします。この操作には、Windowsバックアップ・ツールやZipユーティリティを使用できます。たとえば、Windowsバックアップ・ユーティリティを使用する場合、次のように実行します。

  1. 「アクセサリ」、「システム ツール」、「バックアップ」の順に選択して、Windowsバックアップ・ユーティリティを起動します。

  2. C:\Document and Settings\All Users\スタート メニュー\プログラム\<メニュー>を選択します。

  3. バックアップ・ファイルを2番目のノードにコピーします。

  4. 同じ場所（C:\Document and Settings\All Users\スタート メニュー\プログラム\）でバックアップをリストアします。

ノード・マネージャについては、WebLogic Serverの標準手順に従って、ノード・マネージャをサービスとして構成します。

ノード・マネージャをサービスとして構成するには、WL_HOME\server\bin\installNodeMgrSvc.cmdコマンドを使用します。ノード・マネージャの構成の要件は次のとおりです。

  • 両方のマシンで設定する必要があります。

  • 両方のノードで、手動で起動するようにノード・マネージャを設定する必要があります。

マシンでノード・マネージャを構成する手順は次のとおりです。

  1. マシンでMiddlewareホームが使用できることを確認します。

  2. 前述のコマンドを実行して、サービスをインストールします。

  3. 次のコマンドを使用して、手動で起動するようにサービスを設定します。

    sc config nodemanager_service_name start= demand

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

この項では、Oracle製品スイートごとの考慮事項と変換手順について説明します。製品コンポーネントの詳細は、このガイドで適切なコンポーネントに関連する章を参照してください。

10.2.3.1 Oracle Internet Directoryおよびそのクライアントの変換

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

10.2.3.1.1 Oracle Internet Directoryの変換

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

  1. テキスト・エディタで、Oracle Internet Directoryサーバーに対して仮想IPのcfcvip.mycompany.comを設定するoidcfc.ldifというファイルを次のように作成します。

    dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclhostname
orclhostname: cfcvip.mycompany.com

  2. 次のコマンドを実行します。

    ORACLE_HOME/bin/ldapmodify -p <oidPort> -h <oidHost> -D cn=orcladmin –w
<adminPasswd> -f oidcfc.ldif

    このコマンドを実行する際、OIDが稼働している必要があります。前述のコマンドで使用されているOidHostは、OIDのインストールに使用された物理ホスト名のリスニング・エンド・ポイントです。

  3. opmnctlを使用して、Oracle Internet Directoryサーバーを停止してから再起動します。

    次に例を示します。

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1

  4. OIDを管理サーバーに再登録します。

    ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration -adminHost
 myAdminHost -adminPort 7001 -adminUsername weblogic -componentType OID
 -componentName oid1 -Host cfcvip.mycompany.com
10.2.3.1.2 Oracle Internet Directoryクライアントの変換

Oracle Internet Directoryクライアントを変換する手順は次のとおりです。

  1. Oracle Internet Directoryサーバーのすべてのクライアントは、仮想IPのcfcvip.mycompany.comを使用してそのOracle Internet Directoryサーバーにアクセスします。

  2. Oracle Internet Directoryサーバーを使用するOracle Directory Integration Platformインストールでは、仮想IPを使用してOracle Internet Directoryサーバーにアクセスする必要があります。そのための手順は次のとおりです。

    1. テキスト・エディタで、DOMAIN_HOME/servers/wls_ods1/stage/DIP/11.1.1.1.0/DIP/configurationディレクトリにあるdip-config.xmlファイルを開きます。

      次に例を示します。

      MW_HOME/user_projects/domains/IDMDomain/servers/wls_ods1/stage/DIP/
11.1.1.1.0/DIP/configuration/dip-config.xml

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

      OID_NODE_HOST>cfcvip.mycompany.com</OID_NODE_HOST>

  3. Oracle Internet Directoryサーバーを管理するOracle Directory Services Managerインスタンス（第10.2.2.8.1項「Oracle HTTP Serverの変換」を参照）は、仮想IPを使用してOracle Internet Directoryサーバーに接続する必要があります。

    たとえば、「Oracle Directory Services Manager」画面で、仮想サーバーを使用してOracle Internet Directoryに接続できることを次の手順で検証します。

    1. 右上にある「ディレクトリに接続」→「新規接続の作成」リンクを選択します。

    2. 「新規接続」画面で、次の接続情報を入力し、「接続」をクリックします。

      • ディレクトリ・タイプ: OID

      • 名前: OIDHA

      • サーバー: cfcvip.mycompany.com

      • ポート: 389

      • SSL有効: 空白にしておきます。

      • ユーザー名: cn=orcladmin

      • パスワード: ********

      • 開始ページ: Home（デフォルト）

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

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

10.2.3.2.1 Oracle Virtual Directoryの変換

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

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

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

    <host>cfcvip.mycompany.com</host>

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

    次に例を示します。

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1
10.2.3.2.2 Oracle Virtual Directoryクライアントの変換

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

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

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

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

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

10.2.3.3.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.mycompany.comを使用してこれらのアプリケーションにアクセスする必要があります。

  2. Oracle HTTP ServerがOracle Directory Services Managerのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_ODS管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。これを実行するには、mod_wl_ohsファイルをテキスト・エディタで開き、Oracle HTTP ServerとOracle Directory Services Managerで使用するマウント・ポイント用にこれらの編集を行います。

    #Oracle Directory Services Manager
<Location /odsm>
SetHandler weblogic-handler
WebLogicHost  cfcvip.mycompany.com:<port>
</Location>

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

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

10.2.3.4.1 Oracle Identity Federationの変換

Oracle Identity Federationは、管理サーバーにデプロイされるコンポーネントです。コールド・フェイルオーバー･クラスタ変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成します。第10.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にログインして、次の手順を実行します。

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

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

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

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

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

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

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

前述の変更を行った後にメタデータを生成する必要があります。

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

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

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

  2. Oracle HTTP ServerがOracle Identity Federationのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_OIF管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。これを実行するには、mod_wl_ohsファイルをテキスト・エディタで開き、Oracle HTTP ServerとOracle Directory Services Managerで使用するマウント・ポイント用にこれらの編集を行います。

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

10.2.3.5 Oracle SOA Suiteの変換

Oracle SOA Suiteは、管理対象サーバーにデプロイされるJava EEコンポーネントで構成されます。一般的な構成では、OWSM-PMアプリケーションとSOAアプリケーションのデプロイメントがあります。SOAアプリケーションは必ず、個別の管理対象サーバーにデプロイされます。多くのコールド・フェイルオーバー・クラスタ・デプロイメントでは、OWSM-PMは管理サーバーにデプロイされますが、管理対象サーバー自体（WLS_OWSMなど）やSOA管理対象サーバーにもデプロイできます。これらはJava EEコンポーネントであるため、すべての場合で、コールド・フェイルオーバー・クラスタ変換手順には、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーのWLS_OWSMおよびWLS_SOAを変換する方法の詳細は、第10.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。

また、次の手順に従って、SOAコンポーネントの管理対象サーバーを変換します。

  1. WLS_SOA管理対象サーバーのフロントエンド・ホストをcfcvip.mycompany.comに設定します。

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

    2. 「環境」セクションで「サーバー」を選択します。

    3. 管理対象サーバー名を選択します。

    4. 「プロトコル」を選択してから、「HTTP」を選択します。

    5. 「フロントエンド・ホスト」フィールドで、ホスト名をcfcvip.mycompany.comとして入力します。

    6. フロントエンド・ポートをHTTPポートに設定します。

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

    8. 変更をアクティブ化します。

    9. 管理対象サーバーを再起動します。

  2. Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_OWSMとWLS_SOAにデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。この構成変更はmod_wl_ohs.confで行い、SOAコンポーネントが使用するマウント・ポイントを変更します。次に例を示します。

    #SOA soa-infra app
<Location /soa-infra>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

# Worklist
<Location /integration/>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

# B2B
<Location /b2b>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui >
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

# WSM
<Location /wsm-pm>
          SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

# workflow
<Location /workflow>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>
)

10.2.3.6 Oracle WebCenter Suiteの変換

WebCenter SuiteはJava EEコンポーネントで構成されます。一般的なWebCenter Suiteデプロイメントには3つの管理対象サーバーが含まれますが、WebCenterカスタム・アプリケーションを使用している場合は、追加の管理対象サーバーが含まれることもあります。一般的な管理対象サーバー・デプロイメントの内容は次のとおりです。

  • WLS_SPACES

  • WLS_PORTLETS

  • WLS_SERVICES

これらはJava EEコンポーネントであるため、コールド・フェイルオーバー・クラスタ変換手順では、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成します。Oracle WebCenterのコールド・フェイルオーバー・クラスタ・デプロイメントでは、多くの場合、OWSM-PMをWLS_PortletsおよびWLS_Spacesコンテナにデプロイできます。Oracle WebCenter Suite管理対象サーバーを変換する方法の詳細は、第10.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。

また、Oracle HTTP Serverをフロントエンドとして使用している場合は、WebCenter Suiteアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。この構成変更はmod_wl_ohs.confで行い、WebCenterコンポーネントが使用するマウント・ポイントを変更します。次に例を示します。

LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"

# Spaces

<Location /webcenter>
          SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

<Location /webcenterhelp>
          SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

<Location /rss>
          SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

# Portlet

<Location /portalTools>
          SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

<Location /wsrp-tools>
          SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

# WSM

<Location /wsm-pm>
          SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

# Discussions and Wiki

<Location /owc_discussions>
          SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

<Location /owc_wiki>
          SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
</Location>

10.2.3.7 Oracle Portal、Forms、ReportsおよびDiscovererの変換

コールド・フェイルオーバー・クラスタ構成は、それぞれのOracle Portal、Forms、ReportsおよびDiscovererコンポーネントごとに異なります。この項では、Oracle Portal、Forms、ReportsおよびDiscovererのコールド・フェイルオーバー・クラスタ変換手順について説明します。

10.2.3.7.1 コールド・フェイルオーバー・クラスタ用のOracle Formsの変換

Oracle FormsはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Formsをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。


注意:

この変換プロセスでは、ファイルの編集前にドメインを停止する必要があります。

  1. WLS_FORMS管理対象サーバーを変換します。この手順の詳細は、第10.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。

  2. Oracle Forms OPMNを変換します。この手順の詳細は、第10.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。

  3. Enterprise Managerを変換します。この手順の詳細は、第10.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。

  4. Oracle Forms Web層コンポーネントを変換します。この手順の詳細は、第10.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。

  5. 第12.6.4.8.4項「シングル・サインオンの有効化」で説明している手順に従って、シングル・サインオンを再登録します。

  6. INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるforms.confファイルで、mod_weblogic構成を変更します。

    WebLogicドメイン内の管理サーバーと管理対象サーバーだけでなくOracleインスタンスも起動して、コールド・フェイルオーバー・クラスタ・インストールを検証します。

    <Location /Forms>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:<port>
    DynamicServerList OFF
</Location>
10.2.3.7.2 コールド・フェイルオーバー・クラスタ用のOracle Reportsの変換

Oracle ReportsはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Reportsをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。

  1. WLS_REPORTS管理対象サーバーを変換します。この手順の詳細は、第10.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。

  2. Oracle Reports OPMNを変換します。この手順の詳細は、第10.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。

    また、次の操作を行います。

    1. INSTANCE_HOME/config/OPMN/opmnディレクトリにあるopmn.xmlファイルで、ias-componentのReportsサーバー名を新しい名前に変更して、新しい名前を反映させます。

      次に一般的な形式を示します。

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

    2. 管理サーバー・ドメイン・ホームのDOMAIN_HOME/opmn/topology.xmlで、このファイル内で、Reportsサーバー名のすべての記述をReportsServer_<physical_hostname>_<instance_name>形式（例: ReportServer_node1_asinst）からReportsServer_<virtual_hostname>_<instance_name>形式（例: ReportServer_cfcvip_asinst）に変更します。

  3. Oracle Enterprise Managerを変換します。この手順の詳細は、第10.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。

  4. Oracle Reports Web層コンポーネントを変換します。この手順の詳細は、第10.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。

  5. シングル・サインオンを再登録します。そのためには、第12.6.4.8.4項「シングル・サインオンの有効化」で説明している手順に従ってください。

  6. INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるreports_ohs.confファイルで、次を変更します。

    <Location /reports>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com:port
    WebLogicPort 9001
</Location>

  7. INSTANCE_HOME/config/ReportsServerComponentディレクトリで、次のディレクトリ名を探して、その名前を変更します。

    ReportsServer_physical_hostname_instance_name (for example: ReportServer_node1_asinst)

    前述の名前を次のように変更します。

    ReportsServer_VIP_instance_name (for example: ReportServer_cfcvip_asinst)

    注意:

    インスタンスの再起動後、レポート・サーバーの新しいログはすべて、ReportsServer_virtual_hostname_instance_nameに送信されます。

  8. 名前を変更したディレクトリで、次のファイルに記載された物理ホスト名を仮想ホスト名に置き換えます。

    • component-logs.xml

    • logging.xml

  9. INSTANCE_HOME/EMAGENT/emagent_dir/sysman/emdディレクトリにあるtargets.xmlファイルで、次の変更を行います。

    1. すべてのホスト名をnode1.mycompany.comからcfcvip.mycompany.comに変更します。

    2. 次の2つの要素で、Reportsサーバー名をReportsServer_<physical_hostname>_<instance_name>形式（例: ReportServer_node1_asinst）からReportsServer_<VIP>_<instance_name>形式（例: ReportServer_cfcvip_asinst）に変更します。

      Target TYPE="oracle_repserv"

      Target TYPE="oracle_repapp"

  10. INSTANCE_HOME/reportsディレクトリにあるreports_install.propertiesで、物理ホスト名を仮想ホスト名に置き換えます。

  11. INSTANCE_HOME/reports/serverディレクトリにある次のファイルの名前を変更します。

    • reportsserver_physical hostname_instance name.datを、reportsserver_virtual host name_instance name.datに変更します。

    • rep_wls_reports_physical hostname_instance name.datを、rep_wls_reports_virtual hostname_instance name.datに変更します。

    • WebLogicドメイン内の管理サーバーと管理対象サーバーだけでなくOracleインスタンスも起動して、コールド・フェイルオーバー・クラスタ・インストールを検証します。

  12. DOMAIN_HOME/servers/WLS_REPORTS/stage/reports/reports/configurationディレクトリにあるrwservlet.propertiesファイルで、物理ホスト名を仮想ホスト名に置き換えます（Reportsサーバー名のすべての記述に関する変更を含む）。

  13. DOMAIN_HOME/servers/WLS_REPORTS/stage/reports/reports/META-INF構成ディレクトリにあるmbeans.xmlファイルで、物理ホスト名を仮想ホスト名に置き換えます（Reportsサーバー名のすべての記述に関する変更を含む）。

10.2.3.7.3 コールド・フェイルオーバー・クラスタ用のOracle Discovererの変換

Oracle DiscovererはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Discovererをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。

  1. WLS_DISCO管理対象サーバーを変換します。この手順の詳細は、第10.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。

  2. Oracle Discoverer OPMNを変換します。この手順の詳細は、第10.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。

  3. Oracle Enterprise Managerを変換します。この手順の詳細は、第10.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。

  4. Oracle Discoverer Web層コンポーネントを変換します。この手順の詳細は、第10.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。

  5. シングル・サインオンを再登録します。そのためには、第12.6.4.8.4項「シングル・サインオンの有効化」で説明している手順に従ってください。

  6. INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるreports_ohs.confファイルで、次を変更します。

    <IfModule mod_weblogic.c><Location /discoverer>
SetHandler weblogic-handler
WebLogicCluster cfcvip.mycompany.com:<port>
DynamicServerList ON
</Location>
</IfModule> >

  7. DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/ディレクトリにあるconfiguration.xmlファイルで、次の変更を行います。

    applicationURL="http://cfcvip.mycompany.com:8090/discoverer">

    前述のapplicationURLで指しているポートはOracle HTTP Serverポートです（Oracle HTTP Serverもコールド・フェイルオーバー・クラスタに変換されていることが前提）。

    WebLogicドメイン内の管理サーバーと管理対象サーバーだけでなくOracleインスタンスも起動して、コールド・フェイルオーバー・クラスタ・インストールを検証します。

10.2.3.7.4 コールド・フェイルオーバー・クラスタ用のOracle Portalの変換

Oracle PortalはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Portalをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。

  1. WLS_PORTAL管理対象サーバーを変換します。この手順の詳細は、第10.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。

  2. Oracle Portal OPMNを変換します。この手順の詳細は、第10.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。

  3. Oracle Enterprise Managerを変換します。この手順の詳細は、第10.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。

  4. Oracle Portal Web層コンポーネントを変換します。この手順の詳細は、第10.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。

    また、無効化パスワードと管理者パスワードをリセットします。

    1. Oracle Enterprise Manager Fusion Middleware Consoleにログインし、「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

    2. wc1などのWebキャッシュ・コンポーネントをクリックします。

    3. ページの最上部にあるドロップダウン・リストから、「管理」、「パスワード」の順に選択します。

      新しい無効化パスワードの入力と確認を行ってから、「適用」をクリックします。

      新しい管理者パスワードの入力と確認を行ってから、「適用」をクリックします。

  5. シングル・サインオンを再登録します。そのためには、第12.6.4.8.4項「シングル・サインオンの有効化」で説明している手順に従ってください。

  6. 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
WebLogicPort <port>
</Location>

<Location /portalTools>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogicPort <port>
</Location>

<Location /wsrp-tools>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogicPort <port>
</Location>

<Location /richtextportlet>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogicPort <port>
</Location>

<Location /jpdk>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogicPort <port>
</Location>

<Location /portalHelp>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogicPort <port>
</Location>

<Location /portalHelp2>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogicPort <port>
</Location>

  7. Portalレジストリをリワイヤします。

    1. 次のURLを使用して、WebLogic Server Enterprise Managerにログインします。

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

    2. 無効化パスワードと管理者パスワードを変更します。

      「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

      wc1コンポーネントをクリックします。

      ページの最上部にあるドロップダウン・リストから「管理」、「パスワード」の順に選択します。

      新しい無効化パスワードの入力と確認を行ってから、「適用」をクリックします。

      新しい管理者パスワードの入力と確認を行ってから、「適用」をクリックします。

    3. 左側のペインで、「Fusion Middleware」メニューを開きます。

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

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

      「ポータル・ドメイン」情報ページが表示されます。

    6. 「Portal」を右クリックして、「設定」、「ワイヤ構成」の順に選択します。

    7. 「ポータル中間層」に関して次の情報を入力します。

      ホスト: Webキャッシュ・ホストのcfcvip.mycompany.comのコールド・フェイルオーバー・クラスタ仮想IP名を入力します。

      ポート: 使用するWebキャッシュ・ポート（HTTPまたは非HTTP）を入力します。

      SSLプロトコル: 該当する場合は、この値を入力します。

    8. 「Webキャッシュ」に関して次の情報を入力します。

      ホスト: Webキャッシュ･ホストのcfcvip.mycompany.comとmysite.mycompany.comのコールド・フェイルオーバー・クラスタ仮想IP名を入力します。

      無効化ポート: 9401などの無効化ポートを入力します。

      無効化ユーザー名: Portal無効化のユーザー名を入力します。

      無効化パスワード: このアカウントのパスワードを入力します。

    9. 「適用」をクリックし、リワイヤを開始します。

    10. リワイヤが完了したら、「Portal」メニュー・オプションを再びクリックして、URLが次のようになっていることを確認します。

      https://cfcvip.mycompany.com:WCHTTPPort/portal/pls/portal

  8. Oracle WebLogic Serverにおけるホスト・アサーションを変更します。

    Oracle HTTP ServerはWebLogicのプロキシとして機能するため、デフォルトでは、ホストやポートなどの特定のCGI変数はWebLogicに渡されません。仮想サイト名とポートを使用していることをWebLogicに認識させ、内部URLが適切に生成できるようにする手順は次のとおりです。

    1. 次のURLを使用して、WebLogic Server管理コンソールにログインします。

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

    2. ホーム・ページから「WLS_PORTAL」を選択するか、「ドメイン構造」メニューから「環境」、「クラスタ」の順に選択します。

    3. 「チェンジ・センター」ウィンドウで「ロックして編集」をクリックして、編集可能にします。

    4. 「プロトコル」をクリックしてから、「HTTP」を選択します。

    5. 次の値を入力します。

      フロントエンド・ホスト: Cfcvip.mycompany.com

      フロントエンドHTTPポート: WCHTTPPort（8090）

      フロントエンドHTTPSポート: WCHTTPSPort（8094）

      これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート44380に送られます。

    6. 「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックして、編集可能にします。

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

10.2.3.7.5 Oracle Business Activity Management（BAM）の変換

Oracle BAMは、管理対象サーバーにデプロイされるJava EEコンポーネントで構成されます。これらはJava EEコンポーネントであることから、コールド・フェイルオーバー・クラスタ変換手順には、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーのWLS_BAMを変換する方法の詳細は、第10.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。

Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_BAMにデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。この構成変更はmod_wl_ohs.confファイルで行い、SOAコンポーネントが使用するマウント・ポイントを変更します。次に例を示します。

# BAM Web Application
<Location /OracleBAM >
    SetHandler weblogic-handler
WebLogicHost  cfcvip.mycompany.com:<port>
</Location>
10.2.3.7.6 カスタムADFデプロイメントの変換

カスタムADFアプリケーションを使用するデプロイメントでも、あらゆるFusions Middlewareデプロイメントと同じように、コールド・フェイルオーバー・クラスタを使用できます。この場合、Oracle Application DeveloperのDVDからのインストールを使用して、ドメインを作成します。これは主にJava EEコンポーネントであるため、コールド・フェイルオーバー・クラスタ変換手順は、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーを変換する方法の詳細は、第10.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。

Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_ADF（カスタマ・アプリケーションの管理対象サーバーの名前）にデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。この構成変更はmod_wl_ohs.confで行い、SOAコンポーネントが使用するマウント・ポイントを変更します。次に例を示します。

# BAM Web Application
<Location /ADFApplicationMountPoint >
    SetHandler weblogic-handler
WebLogicHost  cfcvip.mycompany.com:<port>
</Location>

10.2.3.8 シングル・サインオンの再登録（必要な場合）

シングル・サインオン（SSO）の再登録は通常、Oracle Portal、Forms、ReportsおよびDiscovererにのみ適用されます。この層のOracle HTTP Server上のフロントエンド・リスニング・エンドポイントが仮想IPに変更されている場合、保護されるURLを仮想IPによって構成するために、SSOの再登録が必要になります。SSOを再登録するには、SSOサーバーが配置されているIdentity Management 10.1.xインストールに対して次の手順を実行します。

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

  2. 次のパラメータを指定して、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

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

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

    ORACLE_INSTANCE/config/OHS/ohs1

  5. ORACLE_HOME/opm/bin/directoryから次のコマンドを実行して、Oracle HTTP Serverを再起動します。

    opmnctl restartproc process-type=OHS

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

    http://login.mycompany.com/pls/orasso

  7. 「管理」ページ、「パートナ・アプリケーション管理」の順に選択して、node1.mycompany.comのエントリを削除します。

10.2.4 Oracleデータベースの変換

Oracle Fusion Middlewareデプロイメントにおいて、Oracleデータベースは重要な役割を果たします。Oracle Fusion Middlewareの一般的コールド・フェイルオーバー・クラスタ・デプロイメントでは、データベースもコールド・フェイルオーバー・クラスタとしてデプロイされます。この項では、単一インスタンスのOracleデータベースをコールド・フェイルオーバー・クラスタ・データベースに変換する手順について説明します。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.mycompany.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.mycompany.com)(PORT = 1521))
   )
   (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = cfcdb)
      (INSTANCE_NAME = cfcdb)
   )
 )

  3. ローカルのSPFILEを変更して、インスタンスのlocal_listenerパラメータを更新します。

    sqlplusを使用して、sysdbaとしてログインします。

    SQL> alter system set local_listener='<tns alias name>' scope=both;
)

    次に例を示します。

    SQL> alter system set local_listener='CFCDB' scope=both;

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

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

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

    Oracle Application Serverで使用するデフォルト・データベース・サービスとは別に、専用のサービスを作成することをお薦めします。このサービスを作成するには、次のsqlplusコマンドを実行します。

    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> execute DBMS_SERVICE.START_SERVICE(   'cfcdb_asservice' )

    インストールによっては、必要に応じてこのサービス用に追加パラメータを設定する場合があります。DBMS_SERVICEコマンドの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

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

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

10.3.1 トポロジ例1

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

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

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

10.3.2 トポロジ例2

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

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

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

10.3.3 トポロジ例3

図10-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 Suite、Oracle WebCenter Suite、Oracle Portal、Forms、ReportsおよびDiscovererスイートにも有効です。この推奨アーキテクチャでは、Oracle Fusion Middlewareはハードウェア･クラスタの1つのノードとして実行します。別のノードではOracleデータベースが実行します。各ノードは互いにバックアップ・ノードになります。Oracle Fusion Middlewareインスタンスとデータベース・インスタンスは、異なる共有ディスクとVIPを使用し、互いに独立してフェイルオーバーします。また、このアーキテクチャでは、ハードウェア・クラスタ・リソースの使用率が最適化されます。

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

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

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引