この章では、アクティブ/パッシブ・トポロジを構成して管理する方法について説明します。この章の項は次のとおりです。
Oracle Fusion Middlewareは、Oracle Fusion Middleware Cold Failover Clusters(コールド・フェイルオーバー・クラスタ)を使用して、すべてのコンポーネントにアクティブ/パッシブ・モデルを提供します。コールド・フェイルオーバー・クラスタ構成では、複数のアプリケーション・サーバー・インスタンスが同じアプリケーション・ワークロードを処理するように構成されますが、アクティブになるインスタンスは常に1つのみです。
2つのノードのコールド・フェイルオーバー・クラスタを使用すると、Oracle Application Server中間層コンポーネントのアクティブ/パッシブ構成の可用性を実現できます。コールド・フェイルオーバー・クラスタでは、1つのノードがアクティブになり、別のノードはスタンバイ・ノードとしてパッシブになります。アクティブ・ノードで障害が発生すると、スタンバイ・ノードがアクティブ化され、中間層コンポーネントはそのノードからクライアント・リクエストの処理を続行します。すべての中間層コンポーネントが新しいアクティブ・ノードにフェイルオーバーします。フェイルオーバー後、障害ノードでは中間層コンポーネントは実行されなくなります。
コールド・フェイルオーバー・クラスタ構成の最も一般的なプロパティは、次のとおりです。
共有記憶域: アクティブ/パッシブ構成におけるOracle Fusion Middlewareパッシブ・インスタンスは、アクティブ・インスタンスと同じように、Oracleバイナリ、構成ファイル、ドメイン・ディレクトリおよびデータにアクセスできます。コールド・フェイルオーバー・クラスタ構成にあるすべての参加ノードでアクセス可能な記憶域にこれらのアーティファクトを配置することで、このアクセスを構成します。通常、アクティブ・ノードでは共有記憶域がマウントされて、パッシブ・ノードではアンマウント状態になりますが、ノードがアクティブになるとこの記憶域にアクセス可能になります。この共有記憶域は、両方のノードでアクセス可能な二重ポート対応ディスク・デバイスにできますし、NASやSANなどのデバイスベース記憶域にもできます。共有記憶域は通常のファイル・システム上にインストールできます。コールド・フェイルオーバー・クラスタの場合、ボリュームをマウントするノードは一度に1つのみです。共有記憶域は、コールド・フェイルオーバー・クラスタのデプロイメントにおける主要プロパティです。
仮想ホスト名: コールド・フェイルオーバー・クラスタのソリューションでは、仮想ホスト名と仮想IPが2つのノードで共有されます(仮想ホスト名は仮想IPにマッピングされるため、このガイドではこれらを同じ意味で使用しています)。ただし、この仮想IPを使用できるノードは、一度に1つ(アクティブ・ノード)のみです。アクティブ・ノードで障害が発生してスタンバイ・ノードがアクティブになると、仮想IPは新しいアクティブ・ノードに移行します。この新しいアクティブ・ノードでは仮想IPによりすべてのリクエストが処理されます。仮想ホスト名により、デプロイメントの単一システム・ビューが実現されます。コールド・フェイルオーバー・クラスタのデプロイメントは、この仮想IP上でリスニングするように構成されます。たとえば、ハードウェア・クラスタにおいて2つの物理ホスト名がnode1.mycompany.comとnode2.mycompany.comである場合、cfcvip.mycompany.comの名前でこのクラスタの単一ビューが実現されます。cfcvip.mycompany.comは、DNSにより、ノード1(node1.mycompany.com)とノード2(node2.mycompany.com)との間で切り替わる仮想IPにマッピングされます。ハードウェア・クラスタを使用すると、仮想IPのフェイルオーバーが管理されるため、どの物理ノードがアクティブでリクエストを実際に処理しているのかを中間層のクライアントでは検出されません。
ハードウェア・クラスタ: コールド・フェイルオーバー・クラスタのデプロイメントでは通常、ハードウェア・クラスタが使用されます。ハードウェア・クラスタでは、そのアーキテクチャにおいて共有記憶域と仮想IPが管理されます。これは、これらの共有リソースの高信頼性フェイルオーバーの役割を果たし、堅牢なアクティブ/パッシブ・ソリューションを実現します。ほとんどのコールド・フェイルオーバー・クラスタは、次のもので構成されるハードウェア・クラスタにデプロイされます。
同じサブユニット内にある2つのノード
2つのノード間における高速プライベート・インターコネクト
パブリック・ネットワーク・インタフェース: このインタフェース上でクライアント・リクエストが処理され、仮想IPが有効化されます。
2つのノードからアクセス可能な共有記憶域: これには、クォーラム・デバイスとして機能する共有記憶域だけでなく、Oracle Fusion Middlewareインストールとデータベース・インストールの共有記憶域も含まれます。
ノードとコンポーネントの障害を管理するために実行されるクラスタウェア
予定のスイッチオーバーと予定外のフェイルオーバー: コールド・フェイルオーバー・クラスタの一般的デプロイメントは、2つのノードのハードウェア・クラスタです。使用率を最大にするために、通常、これらのノードにはどちらも、実行しているデプロイメントの要素がいくつかあり、必要に応じて一方のノードが他方のノードの要素のバックアップ・ノードの役割を果たします。たとえば、あるノードでアプリケーション層(WebLogicコンテナ)が実行され、別のノードでWeb層(Oracle HTTP Server)が実行されるデプロイメントなどがあります。どちらか一方のノードがハードウェアやソフトウェアのメンテナンスで停止したりクラッシュすると、残りのノードでは、現在のサービスのホスト処理を続行しながら、停止ノードのサービスのホスト処理としても使用されます。
スタンバイ・ノードにスイッチオーバーするための高レベル手順は次のとおりです。
1次ノード上の中間層サービスを停止します(ノードが利用可能な場合)。
現在のアクティブ・ノードからパッシブ・ノードへ仮想IPをフェイルオーバーさせます。この操作には、現在のノードで停止してからパッシブ・ノードで有効化し起動する操作が含まれます。
現在のアクティブ・ノードからパッシブ・ノードへ共有ディスクをフェイルオーバーさせます。この操作には、現在のノードから共有ディスクをアンマウントしてからパッシブ・ノードにマウントする操作が含まれます。
パッシブ・ノード上で中間層サービスを起動し、アクティブにします。
フェイルオーバー管理には、次の2つの方法があります。
クラスタ・マネージャ機能を使用した自動フェイルオーバー
クラスタ・マネージャではサービスを提供します。これによって、サービスの状態を監視するパッケージを開発できます。サービスやノードの停止(計画停止の操作または計画外停止の操作)が検出されると、あるノードから別のノードへサービスが自動的にフェイルオーバーします。フェイルオーバー前に、所定のノード上でサービスの再起動を試みるようにパッケージを開発できます。同様に、アクティブ・ノード自体が停止した場合、クラスタウェアでノードの停止状態が検出され、指定のパッシブ・ノード上で起動を試行できます。任意のクラスタウェアを使用してこれらの操作を自動化すると、完全な自動フェイルオーバー機能を実現できます。
Oracle Fusion MiddlewareではOracle Clusterwareを使用してこの機能を実現します。Oracle Cluster Ready Services(CRS)によるコールド・フェイルオーバー・クラスタ環境の管理の詳細は、第13章「Oracle Cluster Ready Servicesの使用」を参照してください。ただし、クラスタ・フェイルオーバーの管理には、任意の利用可能クラスタウェアを使用できます。
手動フェイルオーバー
この方法では、計画的なスイッチオーバーの手順が手動で実行されます。この方法の場合、障害の検出とフェイルオーバー自体の両方が手動で実行されるため、サービスが利用できない状態が長期化することがあります。
アクティブ/パッシブ・デプロイメントの場合、通常、サービスが停止する時間は短時間です。これは、同じノード上でインスタンスを再起動するのに要する時間、またはパッシブ・ノードにインスタンスをフェイルオーバーするに要する時間になります。
可用性の向上
なんらかの理由でアクティブ・インスタンスに障害が発生した場合や、アクティブ・インスタンスをオフラインにする必要がある場合、いつでも同一構成のパッシブ・インスタンスで処理の引継ぎができます。この構成では、通常の単一インスタンス型デプロイメントより可用性のレベルが高くなります。また、アクティブ/パッシブ・デプロイメントは、使用されるハードウェアの計画メンテナンス操作や計画外メンテナンス操作に対して可用性と保護機能を実現するためにも使用されます。パッチの適用やOSのアップグレードなど、計画的なメンテナンスでノードを停止する必要がある場合に、パッシブ・ノード上でミドルウェア・サービスを起動できます。元のノードへのスイッチバックは適切な時点で実行できます。
運用コストの削減
アクティブ/パッシブ構成では、1つのプロセス・セットのみが稼働して、リクエストを処理します。アクティブ・インスタンスの管理では通常、複数のアクティブ・インスタンスの配列の管理より低コストです。
コールド・フェイルオーバー・クラスタ・トポロジの実装はそれほど難しくありません。それらのクラスタではロード・バランサが不要ですが、アクティブ/アクティブ・トポロジでは必要になるからです。
ロード・バランシング・アルゴリズム、クラスタリング、レプリケーションなどのオプションを構成する必要がないため、コールド・フェイルオーバー・クラスタ・トポロジの実装は、アクティブ/アクティブ・トポロジほど難しくありません。
アクティブ/パッシブ・トポロジでは、アクティブ/アクティブ・トポロジより正確に、1つのインスタンスのトポロジがシミュレートされます。
アプリケーションの非依存性
一部のアプリケーションは、アクティブ/アクティブ構成に適さない場合があります。このようなアプリケーションには、アプリケーションの状態への依存度が高いアプリケーションや、ローカルに格納された情報への依存度が高いアプリケーションなどあります。シングルトン・アプリケーションにはその性質上、アクティブ/パッシブ・デプロイメントが適しています。アクティブ/パッシブ構成では、常に1つのインスタンスのみがリクエストを処理します。
アクティブ/パッシブ・トポロジは、アクティブ/アクティブ・トポロジほどスケーラビリティが高くありません。ノードをトポロジに追加して処理能力を増強することはできません。
HTTPセッションの状態およびEJBステートフル・セッションBeanからの状態情報は、レプリケートされないため、ノードが予期せずに終了すると失われます。このような状態情報は共有記憶域上のデータベースやファイル・システムに永続的に保持できます。ただし、その場合、さらにオーバーヘッドが必要になるため、単一ノードのコールド・フェイルオーバー・クラスタ・デプロイメントのパフォーマンスに影響することがあります。
アクティブ/パッシブ・デプロイメントでは、単一ノードのデプロイメントよりも停止時間が短縮されます。ただし、アクティブ/アクティブ・デプロイメントでは、さらに停止時間が短縮されます。
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において、アクティブ/パッシブ・トポロジを作成するための推奨手順は次のとおりです。
単一インスタンス構成としてコンポーネントをインストールします。このインスタンスをコールド・フェイルオーバー・クラスタ・デプロイメントに変換する予定がある場合、共有ディスクを使用してインストールします。これは、Middlewareホーム、インスタンス・ホーム(システム・コンポーネントの場合)およびドメイン・ディレクトリ(WebLogicデプロイメントの場合)を共有ディスク上に配置することを意味します。1つのユニットとしてフェイルオーバーするものはすべて、共有ディスク上に配置する必要があります。
インストール後、デプロイメントをコールド・フェイルオーバー・クラスタ・デプロイメントに変換し、仮想IP上でリスニングするように構成します。この仮想IPは現在のアクティブ・ノード上で構成します。障害が発生すると、Oracle Fusion Middlewareデプロイメントとともにパッシブ・ノードにフェイルオーバーします。
この一般的手順は、コールド・フェイルオーバー・クラスタのOracleデータベースに適用されます。たとえば、Oracleデータベース・インスタンスを単一インスタンスのデプロイメントとしてインストールしてから、コールド・フェイルオーバー・クラスタ用に変換します。コールド・フェイルオーバー・クラスタのOracle Fusion Middlewareデプロイメントでは、Oracle Real Application Cluster(Oracle RAC)データベースも使用できます。
次の各項では、インストール後の構成手順について説明します。この手順によって単一インスタンスのデプロイメントをコールド・フェイルオーバー・クラスタ・デプロイメントに変換します。
この章の残りの部分では、Oracle Fusion Middlewareスイートの個別コンポーネントごとに、コールド・フェイルオーバー・クラスタを変換する方法について説明します。最初の項では、基本インフラストラクチャ・コンポーネントの手順について詳細に説明します。そしてその後続の項では、Oracle Fusion Middlewareの個別コンポーネントの手順について詳細に説明します。Oracleインスタンスやドメインなど、あらゆるデプロイメントでは、これらの複数のコンポーネントが指定マシンにインストールされます。インスタンスやドメインの全体を変換する手順は次のとおりです。
フェイルオーバー・ユニットに組み込むコンポーネントを決定します。
それらを同じ共有ディスク上にデプロイします。
注意: Oracle Fusion Middlewareコンポーネントのインストールとデプロイの詳細は、それぞれのFusion Middlewareコンポーネントのインストレーション・ガイドを参照してください。 |
このフェイルオーバー・ユニットで使用する仮想IPを決定します。通常、すべてのコンポーネントで同じ仮想IPを使用しますが、別々のIPも使用できます。ただし、すべてのコンポーネントをまとめてフェイルオーバーさせます。
個々のコンポーネントごとに変換手順を適用して、デプロイメント全体を変換します。インストールのコールド・フェイルオーバー・クラスタ変換には複数の項の手順が適用されるため、必ず次の順序で変換を実行してください。
管理サーバーまたはEnterprise Managerインスタンス(該当する場合)を変換します。
デプロイメントにあるすべての管理対象サーバーを変換します。
Oracleインスタンス(非Java EEデプロイメント)を変換します。
前述のように、コールド・フェイルオーバー・クラスタ・デプロイメントでは、2つ以上のノードがデプロイメントに含まれます。これらのノードのいずれか1つで、インストールが行われます。別のノードはパッシブ・ノードです。これら2つのノードにおける要件は次のとおりです。
各ノードはオペレーティング・システム・レベルのあらゆる面で同じである必要があります。たとえば、オペレーティング・システム、バージョンおよびパッチ・レベルが同一である必要があります。
各ノードはハードウェアの特性が同じである必要があります。それによって、通常の運用中とフェイルオーバー時のパフォーマンスが予測可能になります。通常の役割を処理できる処理能力に加えて、フェイルオーバー・シナリオに対応するために対応が必要な負荷が増大しても処理できるように、各ノードを設計することをお薦めします。ただし、停止シナリオ中におけるパフォーマンスの低下がサービス・レベル合意(SLA)で許容される場合、その必要はありません。
通常の運用中とフェイルオーバー時のどちらでも同じノードに対して共有記憶域をマウントできるように、各ノードで同じマウント・ポイントが解放されている必要があります。
2つのノードのユーザーIDとグループIDが類似しており、インスタンスを所有するユーザーのユーザーIDとグループIDが両方のノードで同じである必要があります。
oraInventory
の場所が両方のノードで同じであり、インスタンスまたはドメインの所有者のアクセス・レベルが類似している必要があります。oraInst.loc
ファイルの場所だけでなくbeahomelist
ファイルの場所も同じである必要があります。
指定インスタンスでは、現在アクティブになっているマシンには関係なく、同じリスニング・ポートを使用するため、コールド・フェイルオーバー・クラスタのインスタンスで使用するポートが両方のノードで解放されている必要があります。
注意: 変換を開始する前に、ドメイン全体のバックアップを実行してください。また、編集前にローカル・バックアップ・ファイルを作成することをお薦めします。ドメインのバックアップの詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。次のバックアップを作成することをお薦めします。
|
次のリストは、この章で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware(FMW)が常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middleware SOA Suite(SOA、WebCenter、Identity Managementなど)がインストールされている場所を指します。
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
WL_HOME: MW_HOME/wlserver_10.3
次の表は、いくつかのOracle Fusion Middlewareコンポーネントで使用されるOracleホーム、ドメイン・ホーム、およびドメイン・ディレクトリの値の例を示します。
コンポーネント | ORACLE_HOME | DOMAIN_HOME | ドメイン・ディレクトリ |
---|---|---|---|
Identity Management | MW_HOME/idm | IDMDomain | MW_HOME/user_projects/domains/IDMDomain |
Oracle SOA | MW_HOME/soa | SOADomain | MW_HOME/user_projects/domains/SOADomain |
WebCenter | MW_HOME/wc | WCDomain | MW_HOME/user_projects/domains/WCDomain |
Oracle Portal | MW_HOME/portal | PortalDomain | MW_HOME/user_projects/domains/PortalDomain |
Oracle Forms | MW_HOME/forms | FormsDomain | MW_HOME/user_projects/domains/FormsDomain |
Oracle Reports | MW_HOME/reports | ReportsDomain | MW_HOME/user_projects/domains/ReportsDomain |
Oracle Discoverer | MW_HOME/disco | DiscoDomain | MW_HOME/user_projects/domains/DiscoDomain |
Web層 | MW_HOME/web | 適用なし | 適用なし |
ディレクトリ層 | MW_HOME/idm | 適用なし | 適用なし |
アプリケーション・ディレクトリの場所: ORACLE_BASE/admin/domain_name/appsなど
Oracleインスタンスの場所: ORACLE_BASE/admin/instance_nameなど
1つのユニットとしてフェイルオーバーするディスク上のすべてのエンティティは、同じマウント・ポイント上に配置することをお薦めします。しかし、別の共有記憶域に格納して、別のマウント・ポイントに配置することも可能です。共有記憶域のマウント・ポイントはORACLE_BASEにすることをお薦めします。ほとんどの場合、それによって、フェイルオーバー・ユニットのすべての永続ビットが同じ共有記憶域に格納されます。1つのノードに複数のコールド・フェイルオーバー・クラスタが存在する場合に、それぞれが他のクラスタと独立してフェイルオーバーすると、このようなフェイルオーバー・ユニットのそれぞれに対して異なるマウント・ポイントが存在します。
Oracle Fusion Middlewareデプロイメントは、すべての製品セットに共通する基本インフラストラクチャ・コンポーネントで構成されます。この項では、これらのコンポーネントのコールド・フェイルオーバー・クラスタ変換手順について説明します。
コールド・フェイルオーバー・クラスタ構成では、2つの管理サーバー・トロポジがサポートされています。次の各項では、これら2つのトポロジについて説明します。また、コールド・フェイルオーバー・クラスタ変換用に管理サーバーを準備するためにインストールと構成を行う手順についても説明します。
図12-1は、Oracle Cold Failover Clustersにおける最初のサポート対象トポロジを示しています。
図12-1では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。Middlewareホームとドメイン・ディレクトリは、ある時点でノード1またはノード2にマウントされている共有ディスク上にあります。Middlewareホームとドメイン・ディレクトリは両方とも、同じ共有ディスク上、またはいっしょにフェイルオーバーできる複数の共有ディスク上にあります。複数のアプリケーションまたは環境用に複数のFusion Middlewareドメインがある企業では、管理サーバーの高可用性にはこのトポロジが最適です。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。それぞれの管理サーバーでは、その仮想IPおよび一連の共有ディスクを使用して、ドメイン・サービスの高可用性を実現できます。
このトロポジのアプリケーション・サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。
Middlewareホームのインストール
このインストールには、共有ディスク上におけるOracleホーム、WebLogicホームおよびドメイン・ホームが含まれます。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。ストレージ・サブシステムにおいて複数のノードでの同時マウントが可能な場合でも、これが推奨構成になります。これは、通常の単一インスタンス型インストールとして実行されます。管理サーバー(およびEnterprise Manager)の単体インストールの詳細は、当該コンポーネントに関連する章を参照してください。各スイートの全体的な手順は次のとおりです。
Oracle SOAまたはOracle WebCenterの場合:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server』を参照してください。
Oracle SOAまたはWebCenterのOracleホームをインストールします。
『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』または『Oracle Fusion Middleware Oracle WebCenterインストレーション・ガイド』を参照してください。
構成ウィザードを起動して、管理サーバーのみのドメインを作成します。
「ドメイン・ソースの選択」画面で、次を選択します。
以下の製品をサポートするために、自動的に構成されたドメインを生成する
Enterprise ManagerとOracle JRFを選択します。
Oracle Identity Managementの場合:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
Oracle Identity Management 11gのインストーラで、ドメイン作成オプションを使用してIDMドメインをインストールおよび構成します。「コンポーネントの構成」画面で、Enterprise Manager以外のすべての選択を解除します(これはデフォルトで選択されています)。
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
Oracle Portal、Forms、ReportsおよびDiscovererの場合:
WebLogic Serverソフトウェアをインストールします。
Oracle Fusion Middleware 11g Portal、Forms、ReportsおよびDiscovererのインストーラで、ドメイン作成オプションを使用してクラシック・ドメインをインストールおよび構成します。「コンポーネントの構成」画面で、Enterprise Managerも選択されていることを確認します。
注意: この場合、製品コンポーネント用に1つ以上の管理対象サーバーがこのプロセスでインストールされます(管理サーバー単独のインストールはできません)。この管理対象サーバーも、該当コンポーネントの手順に従ってCFCに変換する必要があります。これは、管理サーバーのユニットと同じフェイルオーバー・ユニットの一部になります。 |
コールド・フェイルオーバー・クラスタ用の管理サーバーの構成
コールド・フェイルオーバー・クラスタ用に管理サーバーを構成する手順は次のとおりです。
rootユーザーとして次のコマンドを使用して、仮想IPをプロビジョニングします。
Linuxの場合
/sbin/ifconfig interface:index IP_Address netmask netmask /sbin/arping -q -U -c 3 -I interface IP_Address
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIPアドレスが有効化されます。
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
第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
仮想IP上でコンソールにアクセスして、管理サーバーの変換を検証します。
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
次の手順に従って、管理サーバーを2番目のノードに手動でフェイルオーバーさせます。
管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。
Middlewareホームとドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。
記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。
rootユーザーとして次のコマンドを使用して、ノード1で仮想IPを無効化します。
Linuxの場合:
/sbin/ifconfig interface:index down
ここで、IP Addressは仮想IPです。次の例では、eth0インタフェースでIPアドレスが無効化されます。
/sbin/ifconfig eth0:1 down
Windowsの場合:
netsh interface ip delete address interface IP_Address
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、"Local Area Connection"のインタフェースでIPアドレスが有効化されます。
netsh interface ip delete address "Local Area connection" 130.35.46.17
手順1と同様のコマンドを使用して、ノード2で仮想IPを有効化します。
管理サーバー・プロセスを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。
管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。
図12-2は、Oracle Cold Failover Clustersにおける2番目のサポート対象管理サーバー・トポロジを示しています。
図12-2では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。管理サーバーが使用するドメイン・ディレクトリは、共有ディスク上にあります。これは必須です。この共有ディスクは、ある時点でノード1またはノード2にマウントされます。ソフトウェアを格納するMiddlewareホーム(WebLogicホームとOracleホーム)は、共有ディスク上でなくてもかまいません。ローカル・ディスクにも配置できます。ソフトウェアがノード1で実行しているときは、ノード1にあるソフトウェア用Middlewareホームを管理サーバーで使用し、ソフトウェアがノード2で実行しているときは、ノード2にあるMiddlewareホームを使用します。2つのMiddlewareホームでは、デプロイされた製品、Oracleホームおよびパッチに関して同じ状態に維持する必要があります。どちらの場合も、共有ドメイン・ディレクトリやドメイン・ホームで利用できる構成を使用します。これは共有されるため、フェイルオーバーの前後で同じ構成が使用されるようになります。
この共有ドメイン・ディレクトリでは、他の管理対象サーバーも実行できます。また、管理サーバー専用にも使用できます。ドメイン・ディレクトリを他の管理対象サーバーと共有する場合、管理サーバーがフェイルオーバーされるときのために、それらのフェイルオーバーに関して適切に考慮する必要があります。考慮事項の一部を次に示します。
読取りや書込みを行うために複数のノードで同時に共有記憶域をマウントできる場合は、管理サーバーのドメイン・ディレクトリを他の管理対象サーバーと共有できます。また、管理対象サーバーとは独立してフェイルオーバーさせることもできます。管理サーバーをフェイルオーバーして、指定ノードで独立して管理対象サーバーの実行を継続できます。これが可能な理由は、この場合、管理サーバーはVIPのフェイルオーバーのみを必要とし、共有ディスクのフェイルオーバーは必要としないためです。管理対象サーバーは、引き続きドメイン・ディレクトリやドメイン・ホームを利用できます。このような記憶域の例として、クラスタ・ファイル・システムに接続されたNASやSAN/Directなどの記憶域があります。
一度に1つのノードのみ共有記憶域をマウントできる場合、管理サーバーのドメイン・ディレクトリを管理対象サーバーと共有することは、管理サーバーがフェイルオーバーされると、同じドメイン・ディレクトリから切り離される管理対象サーバーを停止する必要があることを意味します。
このトロポジではハードウェア・クラスタも使用できます。クラスタはフェイルオーバーの自動化に役立ちます(適切に構成されたクラスタウェアを使用した場合)。ただし、これは必須ではありません。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。各管理サーバーでそれぞれ固有の仮想IPと共有ディスク・セットを使用して、ドメイン・サービスの高可用性を実現できます。
このトポロジは、Oracle SOA SuiteとOracle WebCenter Suiteのみでサポートされています。
注意: Oracle Identity Managementでは、コールド・フェイルオーバー・クラスタの代替トポロジもサポートされています。詳細は、『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management』を参照してください。 |
このトロポジの管理サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。
Middlewareホームのインストール
OracleホームとWebLogicホームを含むMiddlewareホームを、ドメインにある2つのノードに個別にインストールします。管理サーバー・ドメイン・ディレクトリは共有ディスク上に作成します。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。これは、通常の単一インスタンス型インストールです。管理サーバーおよびEnterprise Managerの単体インストールの詳細は、製品スイートを参照してください。Middlewareホームをインストールする手順は次のとおりです。
Oracle SOA SuiteまたはOracle WebCenterの場合:
ノード1にOracle WebLogic Serverソフトウェアをインストールします。
ノード1にSOAまたはWebCenterのOracleホームをインストールします。
ノード2で手順1と手順2を繰り返します。
ノード1で構成ウィザードを起動して、管理サーバーのみのドメインを作成します。
「ドメイン・ソースの選択」画面で、次を選択します。
以下の製品をサポートするために、自動的に構成されたドメインを生成する
Enterprise ManagerとOracle JRFを選択します。
「ドメイン名と場所の指定」画面で、ドメイン名を入力し、ドメイン・ディレクトリがディレクトリと共有記憶域のマウント・ポイントに一致していることを確認します。
コールド・フェイルオーバー・クラスタ用のMiddlewareホームの構成
コールド・フェイルオーバー・クラスタ用にMiddlewareホームを構成する手順は次のとおりです。
仮想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
第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
管理サーバーを2番目のノードに手動でフェイルオーバーさせます。
管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。
Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。
記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。
ノード1で仮想IPを無効化します。
Linuxの場合:
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は、ドメイン・ディレクトリの場所を示します。
ノード2で仮想IPを有効化します。
次のコマンドを使用して、管理サーバー・プロセスを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。
管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。
共有ディスクにインストールされている管理サーバーをノード1から変換するには、この項の手順に従ってください。この手順ではコンテナを変換するため、WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlの両方がコールド・フェイルオーバー・クラスタ用に変換されます。それにより、このコンテナにデプロイされるOWSM-PMなどの他のコンポーネントも、コールド・フェイルオーバー・クラスタ対応になります。これらすべてのサービスのアドレスがcfcvip.mycompany.comに変換されます。インストール後、コールド・フェイルオーバー・クラスタでないインスタンスをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
仮想ホストのマシンを作成します。
「環境」、「マシン」の順に選択します。
「ロックして編集」をクリックします。
新規をクリックします。
「名前」フィールドにcfcvip.mycompany.comと入力します。
適切なオペレーティング・システムを選択します。
「OK」をクリックします。
「マシンのサマリー」タブで、作成したばかりのマシンの名前をクリックします。
「サーバー」タブをクリックします。
「追加」をクリックします。
既存のサーバーを選択して、このマシンに関連付けます。
サーバー選択のドロップダウン・リストで、「AdminServer」が選択されていることを確認します。
「変更のアクティブ化」をクリックします。
cfcvip.mycompany.com上でリスニングするように管理サーバーを構成します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「チェンジ・センター」で「ロックして編集」をクリックします。
管理サーバー(AdminServer)をクリックします。
リスニング・アドレスをcfcvip.mycompany.comに変更します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理サーバーを再起動します。
注意: 通常、管理サーバーのコールド・フェイルオーバー・クラスタへの変換はドメイン作成時に実行されることが期待されるため、ドメインにおいて他の部分への変更は行われないものと考えられます。この変更がドメイン作成後に行われ、他のコンポーネントがドメインにインストールされている場合、次の管理サーバー変換項で説明している手順に従ってください。 |
管理サーバーのクライアント側構成の変更
ドメインにある既存エンティティでは、管理サーバーとの通信に新しいアドレスを使用する必要があります。たとえば、管理対象サーバーを手動で起動する際、管理サーバーのアドレスを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の新しい場所を構成するには、エージェントごとに次の手順を行います。
ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_asinst_ 1/sysman/configに設定します。
emd.properties
ファイルで、次の属性内のnode1.mycompany.com
をcfcvip.mycompany.com
に変更します。
REPOSITORY_URL
EmdWalletSrcUrl
次のコマンドを使用して、エージェントを停止してから再起動します。
cd INSTANCE_HOME/EMAGENT/emagent_dir/bin
./emctl stop agent
./emctl start agent
./emctl status agent
これによってリポジトリのURLが表示されます。このURLは新しいホストを指します。
すべてのOracle Fusion Middlewareコンポーネントは、管理対象サーバーにデプロイされます。Oracle WebLogic Serverにデプロイされたアプリケーションやコンポーネントをコールド・フェイルオーバー・クラスタに変換する際の重要な手順としては、使用する仮想IPにリスニング・アドレスを変更することがあります。この変更は、対象のコンポーネントがデプロイされている特定の管理対象サーバーに対して実行します。この変更には、WebLogic Server管理コンソールまたはWLSTコマンドを使用できます。
次の例では、WLS_EXMPLという管理対象サーバーをコールド・フェイルオーバー・クラスタに変換する一般的手順について説明します。これらの手順は、Fusion Middlewareコンポーネントの管理対象サーバーに適用されます。
この手順を実行するには、WebLogic Server管理コンソールが稼働していることが必要です。次の例で、cfcvip.mycompany.comはコールド・フェイルオーバー・クラスタに使用する仮想IPで、WLS_EXMPLは変換対象となる管理対象サーバーです。
WebLogic Server管理コンソールにログインします。
仮想ホストのマシンを作成します。
「環境」→「マシン」を選択します。
「ロックして編集」をクリックします。
「新規」をクリックします。
「名前」フィールドでは、cfcvip.mycompany.comと入力します。
「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。
「OK」をクリックします。
新しく作成したマシンをクリックします。
「ノード・マネージャ」タブをクリックします。
リスニング・アドレスをcfcvip.mycompany.comに更新します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
WLS_EXMPL管理対象サーバーを停止します。
「環境」→「サーバー」を選択します。
「制御」をクリックします。
「WLS_EXMPL」を選択します。
「停止」ドロップダウン・メニューで、「ただちに強制停止」を選択します。
WLS_EXMPL管理対象サーバーを仮想ホストのマシンに関連付けます。
「環境」→「サーバー」を選択します。
「ロックして編集」をクリックします。
「構成」をクリックします。
「WLS_EXMPL」を選択します。
「マシン」では、プルダウン・メニューから新規作成マシンを選択して割り当てます。
「リスニング・アドレス」にcfcvip.mycompany.comと入力します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理対象サーバーWLS_EXMPLを起動します。
「環境」→「サーバー」を選択します。
「制御」をクリックします。
「WLS_EXMPL」を選択します。
「起動」をクリックします。
WLSTコマンドを使用してもOracle WebLogic管理対象サーバーを変換できます。
次の手順を実行する前に、変換対象となる管理対象サーバーを停止することをお薦めします。
オンライン・モード(WebLogic Server管理サーバーが稼働している状態)でWLSTコマンドラインを使用して管理対象サーバーを変換する手順は次のとおりです。
コマンドラインで次のように入力します。
WL_HOME/server/bin/setWLSEnv.sh WL_HOME/common/bin/wlst.sh
WLSTで、次のコマンドを入力します。
wls:/offline>connect(<username>,<password>,<AdminServer location>)
次に例を示します。
wls:/offline>connect('WebLogic', 'welcome1', 't3://admin.mycompany.com:7001') wls:/DomainName/serverConfig> edit() wls:/DomainName/edit> startEdit() wls:/DomainName/edit !> create('cfcvip.mycompany.com','Machine') wls:/DomainName/edit !> cd('Machines/cfcvip.mycompany.com/NodeManager/cfcvip.mycompany.com') wls:/DomainName/edit !> set('ListenAddress', 'cfcvip.mycompany.com') wls:/DomainName/edit !>cd ('Servers') wls:/DomainName/edit/Servers !>cd ('WLS_EXMPL') wls:/DomainName/edit/Servers/WLS_EXMPL !>set('Machine',' cfcvip.mycompany.com ') wls:/DomainName/edit/Servers/WLS_EXMPL !>set('ListenAddress',' cfcvip.mycompany.com ') wls:/DomainName/edit/Servers/WLS_EXMPL !> save() wls:/DomainName/edit/Servers/WLS_EXMPL !> activate() wls:/DomainName/edit/Servers/WLS_EXMPL> exit()
管理対象サーバーを停止してから(停止していない場合)、再起動します。
管理対象サーバーの変換が完了したら、このサーバーに対するすべての参照で新しいリスニング・アドレス(cfcvip.mycompany.com)を使用する必要があります。Oracle HTTP Serverがこの管理対象サーバーのフロントエンドとして機能している場合、この管理対象サーバー上のアプリケーションを参照しているマウント・ポイントでmod_wls_ohs構成をすべて変更して、新しいリスニング・エンドポイントにルーティングする必要があります。
コールド・フェイルオーバー・クラスタ環境ではノード・マネージャを使用できます。次の構成が可能です。
仮想IP上で同様にリスニングし、コールド・フェイルオーバー・クラスタ・スタックの残りの部分とともにフェイルオーバーするノード・マネージャの使用:ASCRSベースのデプロイメントでは、コールド・フェイルオーバー・クラスタのFusion Middlewareインスタンスが稼働しているMiddlewareホームと同じMiddlewareホームにノード・マネージャが属している必要があります。このノード・マネージャはこのFusion Middlewareインスタンス専用であることが前提になります。この場合は、ローカル・ホストでリスニングするネットワーク・チャネルを別に構成することをお薦めします。他のポートでリスニングするボックス上に他のノード・マネージャを共存させることができます。詳細は、第13章「Oracle Cluster Ready Servicesの使用」を参照してください。
コールド・フェイルオーバー・クラスタ・スタックの残りの部分とともにフェイルオーバーしないノード・マネージャ:この場合、ノード・マネージャはコールド・フェイルオーバー・クラスタ用に構成されずに、コールド・フェイルオーバー・クラスタの仮想IPだけでなく、マシン上のすべてのIPをリスニングします。また、フェイルオーバー・ノードには、同様に構成されているノード・マネージャが配置され、構成されています。WebLogicインスタンスに関連付けられたマシンはローカル・ホスト上のノード・マネージャと通信します。詳細は、『Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server』を参照してください。
一般的にコールド・フェイルオーバー・クラスタの場合、フェイルオーバー発生時にポートが競合しないように、ポートの使用を計画する必要があります。
ノード・マネージャをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。
ノード・マネージャが実行されている場合は停止します。
ノード・マネージャが最初に起動された後にのみ、nodemanager.properties
ファイルは作成されます。
必要に応じて、ノード・マネージャを再起動します。
WL_HOME
/common/nodemanager/ディレクトリにあるnodemanager.propertiesファイルで、ListenAddress
を仮想IPに設定します。
次に例を示します。
ListenAddress=cfcvip.mycompany.com
WL_HOME/server/binディレクトリにあるStartNodeManager.sh
ファイルを使用して、ノード・マネージャを再起動します。ASCRSベースのデプロイメントの場合は、WL_HOME/server/bin/cfcStartNodemanager.shを使用してノード・マネージャを起動します。
詳細は、第13章「Oracle Cluster Ready Servicesの使用」を参照してください。
注意: 必要に応じて、startNodeManager.sh スクリプトのかわりにcfcStartNodemanager.sh スクリプトのみを使用して、ノード・マネージャを起動します。 |
注意: WebLogic管理対象サーバーおよび管理サーバーでは、ホスト名の検証は特定のインストールで有効化または無効化できます。検証が有効でノード・マネージャがこれらのインスタンスを管理しているCFCインストールでは、ホスト名の検証の手順の中で仮想IPのcfcvip.mycompany.comの証明書を使用する必要があります。 |
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">
INSTANCE_HOME/config/OPMN/opmn
ディレクトリのopmn.xml
ファイルで、「<physicalhostname>」を「cfcvip.mycompany.com」に置き換えます。
</ias-component><ias-component id="ReportsServer_<physicalhostname>_asinst_2"> <process-set id="ReportsServer_<physicalhostname>_asinst_2" restart-on-death="true" numprocs="1">
INSTANCE_HOME/config/OPMN/opmn
ディレクトリのinstance.propertiesファイルで、「adminHost=<physical hostname>」を「adminHost=<cfcvip.mycompany.com>」に置き換えます。
Oracle Internet Directory、Oracle Virtual Directory、Web層コンポーネント、Oracle Portal、Forms、ReportsおよびDiscovererコンポーネントなどのOracleインスタンスをコールド・フェイルオーバー・クラスタに変換する場合は、そのOracleインスタンスの一部であるEnterprise Managerエージェントもコールド・フェイルオーバー・クラスタに変換する必要があります。
Enterprise Managerエージェントを変換する手順は次のとおりです。
次のコマンドを使用して、Enterprise Managerエージェントを停止します。
cd INSTANCE_HOME/EMAGENT/emagent_dir/bin ./emctl stop agent
ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_instance name/sysman/configに設定します。
emd.properties
ファイルで、emd_url
属性のnode1.mycompany.com
をcfcvip.mycompany.com
に変更します。
エージェント側のtargets.xml
ファイルを変更します。
cd INSTANCE_HOME/EMAGENT/emagent_dir/cp targets.xml targets.xml.org
ホストとoracle_emd
に関連付けられたターゲットのみ含まれるように、targets.xmlを変更します。他のエントリはすべて削除します。次に例を示します。
<Targets AGENT_TOKEN="ad4e5899e7341bfe8c36ac4459a4d569ddbf03bc"> <Target TYPE="oracle_emd" NAME=cfcvip.mycompany.com:<port>"/> <Target TYPE="host" NAME=cfcvip.mycompany.com DISPLAY_NAME=cfcvip.mycompany.com/> </Targets>
エージェントを停止してから再起動します。
cd INSTANCE_HOME/EMAGENT/emagent_dir/bin ./emctl start agent
管理サーバーのドメイン・ディレクトリにあるEnterprise Managerサーバーに対して、次の変更を行います。
使用ディレクトリをMW_HOME/user_projects/domains/domain_name/sysman/stateに設定します。
MW_HOME/user_projects/domains/domain_name/sysman/stateディレクトリにあるtargets.xml
ファイルで、ホスト名をnode1.mycompany.com
からcfcvip.mycompany.com
に変更します。
Web層は、2つの主要コンポーネントであるOracle HTTP ServerとOracle Web Cacheで構成されます。次の2つの項では、Oracle HTTP ServerとOracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する方法について説明します。
Oracle HTTP Serverをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。
INSTANCE_HOME/config/OHS/component_name/httpd.confで、次の属性を変更します。
Listen cfcvip.mycompany.com:<port> #OHS_LISTEN_PORT Listen cfcvip.mycompany.com:<port> #OHS_PROXY_PORT ServerName cfcvip.mycompany.com
また、第12.2.3.13項「シングル・サインオンの再登録(必要な場合)」で説明されているシングル・サインオンの再登録も実行します。
Oracle HTTP Serverのクライアント
コールド・フェイルオーバー・クラスタに変換したOracle HTTP ServerにOracle Web Cacheインスタンスがルーティングされる場合は、INSTANCE_HOME/config/WebCache/component_name/webcache.xmlで次の属性を変更します。
node1.mycompany.comをcfcvip.mycompany.comに変更します。このnode1.mycompany.comは、変換前のOracle HTTP Serverのアドレスです。
HOST ID="h1" NAME="cfcvip.mycompany.com" PORT="8888" LOADLIMIT="100" OSSTATE="ON"/> <HOST ID="h2" NAME="cfcvip.mycompany.com" PORT="8890" LOADLIMIT="100" OSSTATE="ON" SSLENABLED="SSL"/>
Oracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。
クラスタの両方のノードにある/etc/hostsで、物理ホスト名に別名を設定します。
これはノードのIPアドレスの別名です。Linuxの場合は/etc/hostsでこれを設定します。Windowsの場合はWindowsの場所でこれを設定します。この別名はwcprfx.mycompany.comです。たとえば、ノード1では、/etc/hostsファイル(UNIXの場合)のエントリはn.n.n.n node1 node1.mycompany.com wcprfx wcprfx.mycompany.comになります。
フェイルオーバー・ノードのノード2では、/etc/hostsファイル(UNIXの場合)のエントリはn.n.n.m node2 node2.mycompany.com wcprfx wcprfx.mycompany.comになります。
Windowsの場合は、すべてのノードにおいてC:\SystemRoot\system32\drivers\etc\hostsにあるファイルでこの変更を行います。SystemRootはWinntまたはWindowsです。
INSTANCE_HOME/config/WebCache/wc1/webcache.xmlで、次の操作を行います。
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>
コールド・フェイルオーバー・クラスタ環境では、フェイルオーバー・ノード(node2.mycompany.com)をすべての面でインストール・マシン(node1.mycompany.com)と同じにする必要があります。フェイルオーバー・ノードをインストール・ノードと同じにするには、フェイルオーバー・インスタンスで次の手順を実行します。
UNIXプラットフォームでの手順は次のとおりです。
前述のマウントおよびアンマウントの手順に従って、ノード1(インストール・ノード)からフェイルオーバー・ノード(ノード2)へMiddlewareホームをフェイルオーバーさせます。
rootとして、次の操作を行います。
ノード1にあるものと同一のoraInst.loc
ファイルを/etc
ディレクトリに作成します。
ORACLE_HOME
ディレクトリにあるoracleRoot.sh
ファイルをノード2で実行します。これは、製品スイートで利用可能な場合や必要に応じて実行します。
ORACLE_HOME/oui/bin/attachHome.sh
ディレクトリにあるattachHome
コマンドを使用して、oraInventory
を2番目のノードで作成します。
Windowsでの手順は次のとおりです。
アプリケーション・サーバー・インスタンス(Web層、IDMインストールのOID/OVD、Oracle Portal、Form、ReportsおよびDiscoverer)の場合:
マシン2でOPMNサービスを作成するには、次のコマンドを実行します。
sc create OracleProcessManager_instance_name binPath= "ORACLE_HOME\opmn\bin\opmn.exe -S -I Instance_Home"
次に例を示します。
sc create OracleProcessManager_asinst binPath= "X:\Middleware\im_oh\opmn\bin\opmn.exe -S -I X:\Middleware\asinst"
マシン1とマシン2の両方で、OracleProcessManager_instance_name
サービスが手動で起動するように設定します。
sc config OracleProcessManager_instance_name start= demand
すべてのインストールの場合:
マシン1のシステム環境変数Pathになんらかのインスタンス固有の情報が含まれている場合、それと同じ情報をマシン2の同じ変数にも設定します。また、マシン1からレジストリHKEY_LOCAL_MACHINE/Oracleをエクスポートして、それをマシン2にインポートします。
マシン1からマシン2にスタート・メニューをコピーするため、マシン1のC:\Document and Settings\All Users\スタート メニュー\プログラム\<メニュー>
にあるファイルをマシン2にコピーします。この操作には、Windowsバックアップ・ツールやZipユーティリティを使用できます。たとえば、Windowsバックアップ・ユーティリティを使用する場合、次のように実行します。
「アクセサリ」、「システム ツール」、「バックアップ」の順に選択して、Windowsバックアップ・ユーティリティを起動します。
C:\Document and Settings\All Users\スタート メニュー\プログラム\<メニュー>を選択します。
バックアップ・ファイルを2番目のノードにコピーします。
同じ場所(C:\Document and Settings\All Users\スタート メニュー\プログラム\
)でバックアップをリストアします。
ノード・マネージャについては、WebLogic Serverの標準手順に従って、ノード・マネージャをサービスとして構成します。
ノード・マネージャをサービスとして構成するには、WL_HOME\server\bin\installNodeMgrSvc.cmd
コマンドを使用します。ノード・マネージャの構成の要件は次のとおりです。
両方のマシンで設定する必要があります。
両方のノードで、手動で起動するようにノード・マネージャを設定する必要があります。
マシンでノード・マネージャを構成する手順は次のとおりです。
マシンでMiddlewareホームが使用できることを確認します。
前述のコマンドを実行して、サービスをインストールします。
次のコマンドを使用して、手動で起動するようにサービスを設定します。
sc config nodemanager_service_name start= demand
この項では、Oracle製品スイートごとの考慮事項と変換手順について説明します。製品コンポーネントの詳細は、このガイドで適切なコンポーネントに関連する章を参照してください。
この項では、Oracle Internet Directoryとそのクライアントを変換する方法について説明します。
Oracle Internet Directoryサーバーを変換する手順は次のとおりです。
テキスト・エディタで、Oracle Internet Directoryサーバーに対して仮想IPのcfcvip.mycompany.com
を設定するoidcfc.ldif
というファイルを次のように作成します。
dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclhostname orclhostname: cfcvip.mycompany.com
次のコマンドを実行します。
ORACLE_HOME/bin/ldapmodify -p <oidPort> -h <oidHost> -D cn=orcladmin –w <adminPasswd> -f oidcfc.ldif
このコマンドを実行する際、OIDが稼働している必要があります。前述のコマンドで使用されているoidHostは、OIDのインストールに使用された物理ホスト名のリスニング・エンド・ポイントです。
opmnctlを使用して、Oracle Internet Directoryサーバーを停止してから再起動します。
次に例を示します。
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1 ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1
OIDを管理サーバーに再登録します。
ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration -adminHost
myAdminHost -adminPort 7001 -adminUsername weblogic -componentType OID
-componentName oid1 -Host cfcvip.mycompany.com
Oracle Internet Directoryクライアントを変換する手順は次のとおりです。
Oracle Internet Directoryサーバーのすべてのクライアントは、仮想IPのcfcvip.mycompany.comを使用してそのOracle Internet Directoryサーバーにアクセスします。
Oracle Internet Directoryサーバーを使用するOracle Directory Integration Platformインストールでは、仮想IPを使用してOracle Internet Directoryサーバーにアクセスする必要があります。そのための手順は次のとおりです。
テキスト・エディタで、DOMAIN_HOME/config/fmwconfig/servers/wls_ods1/applications/DIP_<version_number>/configurationディレクトリにあるdip-config.xml
ファイルを開きます。
次に例を示します。
MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/ wls_ods1/applications/DIP_11.1.1.2.0/configuration
次の値を入力し、LDAPアドレスを仮想IPに設定します。
OID_NODE_HOST>cfcvip.mycompany.com</OID_NODE_HOST>
Oracle Internet Directoryサーバーを管理するOracle Directory Services Managerインスタンス(第12.2.2.8.1項「Oracle HTTP Serverの変換」を参照)は、仮想IPを使用してOracle Internet Directoryサーバーに接続する必要があります。
たとえば、「Oracle Directory Services Manager」画面で、仮想サーバーを使用してOracle Internet Directoryに接続できることを次の手順で検証します。
右上にある「ディレクトリに接続」→「新規接続の作成」リンクを選択します。
「新規接続」画面で、次の接続情報を入力し、「接続」をクリックします。
ディレクトリ・タイプ: OID
名前: OIDHA
サーバー: cfcvip.mycompany.com
ポート: 389
SSL有効: 空白にしておきます。
ユーザー名: cn=orcladmin
パスワード: ********
開始ページ: Home
(デフォルト)
この項では、Oracle Virtual Directoryとそのクライアントを変換する方法について説明します。
Oracle Virtual Directoryサーバーを変換する手順は次のとおりです。
テキスト・エディタで、ORACLE_INSTANCE/config/OVD/componentnameディレクトリにあるlisteners.os_xml
ファイルを開きます。
次の値を入力し、LDAPアドレスを仮想IPに設定します。
<host>cfcvip.mycompany.com</host>
opmnctlを使用して、Oracle Virtual Directoryサーバーを再起動します。
次に例を示します。
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1 ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1
Oracle Virtual Directoryのすべてのクライアントは、仮想IPのcfcvip.mycompany.com
を使用して、Oracle Virtual Directoryにアクセスする必要があります。たとえば、Oracle Directory Services Managerを使用してコールド・フェイルオーバー・クラスタのOracle Virtual Directoryインスタンスを管理する場合は、Oracle Virtual Directoryインスタンスの場所としてcfcvip.mycompany.com
を使用して接続を作成します。
この項では、Oracle Directory Integration Platform、Oracle Directory Services Managerおよびそれぞれのクライアントを変換する方法について説明します。
Oracle Directory Integration PlatformとOracle Directory Services Managerは管理対象サーバーにデプロイされます。CFC変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.mycompany.com
の仮想IP上でリスニングするように構成します。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_ODS管理対象サーバーを、cfcvip.mycompany.com
の仮想IP上でリスニングするように構成してください。
次の手順に従って、Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントを変換します。
Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントは、仮想IPのcfcvip.mycompany.com
を使用してこれらのアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Directory Services Managerのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_ODS管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.com
を指定する必要があります。そのためには、Oracle HTTP ServerおよびOracle Directory Services Managerで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#Oracle Directory Services Manager
<Location /odsm>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:<port>
</Location>
この項では、Oracle Identity Federationとそのクライアントを変換する方法について説明します。
Oracle Identity Federationは、管理サーバーにデプロイされるコンポーネントです。コールド・フェイルオーバー・クラスタ変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.mycompany.com
の仮想IP上でリスニングするように構成します。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OIF管理対象サーバーを、cfcvip.mycompany.com
の仮想IP上でリスニングするように構成してください。Oracle Identity Federationコールド・フェイルオーバー・クラスタ・デプロイメントは通常、サービス・プロバイダとアイデンティティ・プロバイダに分割されるため、特定のデプロイメントに複数のWLS_OIFインスタンスが存在する場合があります。どちらのWLS_OIFインスタンスに対しても、同じコールド・フェイルオーバー・クラスタ手順を適用してください。
cfcvip.mycompany.com
の仮想IP上でリスニングするように管理対象サーバーを構成した後、Oracle Enterprise Manager Fusion Middleware Controlにログインして、次の手順を実行します。
「ファーム」→「Identity and Access」→OIFに移動します。
右側のフレームで、「Oracle Identity Federation」→「管理」に移動して、次の変更を行います。
サーバー・プロパティ: ホストをcfcvip.mycompany.com
に変更します。
「アイデンティティ・プロバイダ」→「共通」: ProviderIdをcfcvip.mycompany.com
に変更します。
「サービス・プロバイダ」→「共通」: ProviderIdをcfcvip.mycompany.com
に変更します。
データ・ストア: データ・ストアがLDAPの場合は、ユーザー・データ・ストアとフェデレーション・データ・ストアの接続URLの値をcfcvip.mycompany.com
に置き換えます。
「認証エンジン」→「LDAPディレクトリ」: 接続URLをcfcvip.mycompany.com
に設定します。
前述の変更を行った後にメタデータを生成する必要があります。
次の手順に従って、Oracle Identity Federationクライアントを変換します。
Oracle Identity Federationクライアントは、仮想IPのcfcvip.mycompany.com
を使用してこのアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Identity Federationのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_OIF管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.com
を指定する必要があります。そのためには、Oracle HTTP ServerおよびOracle Directory Services Managerで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#Oracle Identity Federation
<Location /oif>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:<port>
</Location>
Oracle SOA Suiteは、管理対象サーバーにデプロイされるJava EEコンポーネントで構成されます。一般的な構成では、OWSM-PMアプリケーションとSOAアプリケーションのデプロイメントがあります。SOAアプリケーションは必ず、個別の管理対象サーバーにデプロイされます。多くのコールド・フェイルオーバー・クラスタ・デプロイメントでは、OWSM-PMは管理サーバーにデプロイされますが、管理対象サーバー自体(WLS_OWSMなど)やSOA管理対象サーバーにもデプロイできます。WLS_SOAコンテナには、デプロイされたBPEL、UMS、B2Bなどのアプリケーションが含まれ、さらにデプロイされたBPMコンポーネントが含まれる場合もあります。これらはJava EEコンポーネントであるため、すべての場合で、コールド・フェイルオーバー・クラスタ変換手順には、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーのWLS_OWSMおよびWLS_SOAを変換する方法の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。
また、次の手順に従って、SOAコンポーネントの管理対象サーバーを変換します。
WLS_SOA管理対象サーバーのフロントエンド・ホストをcfcvip.mycompany.comに設定します。
Oracle WebLogic Server管理コンソールにログインします。
「環境」セクションで「サーバー」を選択します。
管理対象サーバー名を選択します。
「プロトコル」を選択してから、「HTTP」を選択します。
「フロントエンド・ホスト」フィールドで、ホスト名をcfcvip.mycompany.comとして入力します。
フロントエンド・ポートをHTTPポートに設定します。
「保存」をクリックします。
変更をアクティブ化します。
管理対象サーバーを再起動します。
Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_OWSMとWLS_SOAにデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。そのためには、SOAコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#SOA soa-infra app <Location /soa-infra> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<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> #Required if attachments are added for workflow tasks <Location /ADFAttachmentHelper> SetHandler weblogic-handler WebLogicCluster cfcvip.mycompany.com:<port> </Location>
この項では、Oracle Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.mycompany.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。
Oracle Access Managerは管理対象サーバー(WLS_OAM1など)にデプロイされます。CFC変換の手順はこの管理対象サーバーを仮想IPのcfcvip.mycompany.comでリスニングするように構成することになります。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OAM1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置に関する他のすべての要件およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトは、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明に適用されます。
Oracle Access Managerコンソールは、ドメインの管理サーバーの一部としてデプロイされます。このコンソールのコールド・フェイルオーバー・クラスタ構成では、管理サーバー全体をアクティブ/パッシブで構成する必要があります。管理サーバーは、同じ仮想IPのcfcvip.mycompany.comを共有することも、個別の仮想IPと共有ディスクを使用して独立にフェイルオーバーするように構成することもできます。同じ仮想IPを使用している場合、管理サーバーとOracle Access Manager管理対象サーバーは1つのユニットとしてフェイルオーバーします。
次の手順に従って、Oracle Access Managerクライアントを変換します。
Oracle Access Managerクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Identity ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.mycompany.comを使用してアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Access Managerのフロントエンドである場合、Oracle Access Managerに関するmod_weblogic構成では、Oracle Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#Oracle Access Manager <Location /oam> SetHandler weblogic-handler WebLogicHost cfvcip.mycompany.com:<port> </Location>
Oracle Adminstration Serverの一部としてOracle Access Managerをアクティブ/パッシブに構成し、管理サーバーのフロントエンドをOracle HTTP Serverで構成する場合、Webサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更する必要があります。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#Oracle Access Manager Admin Console deployed to the Admin Server <Location /oamconsole> SetHandler weblogic-handler WebLogicHost ADMINVHN WebLogicPort 7001 </Location>
この項では、Oracle Adaptive Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.mycompany.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。
Oracle Adaptive Access Managerは管理対象サーバーにデプロイされます。両方とも単一のユニットとしてフェイルオーバーさせるためにデプロイするため、同じ仮想IPと同じ共有記憶域を共有します。OAAM Admin管理対象サーバーおよびOAAM Server管理対象サーバーをCFC変換する手順は、仮想IPのcfcvip.mycompany.comをリスニングするようにこれらの管理対象サーバーを構成するということになります。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置に関する他のすべての要件およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトは、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明に適用されます。
次の手順に従って、Oracle Adaptive Access Managerクライアントを変換します。
Oracle Adaptive Access Managerクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Identity Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.mycompany.comを使用してアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Adaptive Access Managerのフロントエンドである場合、Oracle Adaptive Access Managerに関するmod_weblogic構成では、Oracle Adaptive Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
#Oracle Adaptive Access Manager <Location /oaam_server> SetHandler weblogic-handler WebLogicHost cfvcip.mycompany.com:<port> </Location> #Oracle Adaptive Access Manager Admin Console <Location /oaam_admin> SetHandler weblogic-handler WebLogicHost cfvcip.mycompany.com:<port> </Location>
この項では、Oracle Identity Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.mycompany.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。
Oracle Identity Managerは、管理対象サーバーにデプロイされます。一般的なCFCデプロイメントでは、Oracle Identity Manager管理対象サーバーと、Oracle SOAおよびOracle Web Services Managerを含む別の管理対象サーバーを1つのユニットとしてフェイルオーバーするようにデプロイさせるため、同じ仮想IPと同じ共有記憶域を共有します。この両方の管理対象サーバーをCFC変換で変換する手順は、仮想IPのcfcvip.mycompany.comをリスニングするようにこれらの管理対象サーバーを構成するということになります。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置に関する他のすべての要件およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトは、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明に適用されます。
次の手順に従って、Oracle Identity Managerクライアントを変換します。
Oracle Identity Managerクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.mycompany.comを使用してアプリケーションにアクセスする必要があります。SOAもOracle Identity Managerでフェイルオーバーするように構成されているので、Oracle Identity ManagerからSOAへの接続でも共通の仮想IPを使用する必要があります。
Oracle HTTP ServerがOracle Identity Managerのフロントエンドである場合、Oracle Identity Managerに関するmod_weblogic構成では、管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルまたはoim.confファイルを次のように編集します。
#Oracle Identity Manager <Location /oim> SetHandler weblogic-handler WebLogicHost cfvcip.mycompany.com:<port> </Location>
Oracle Identity Managerの構成変更の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドを参照してください。
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管理対象サーバーを変換する方法の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。
また、Oracle HTTP Serverをフロントエンドとして使用している場合は、WebCenter Suiteアプリケーションに関するmod_weblogic構成で、管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。そのためには、WebCenterコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
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>
は、これら4つの個別コンポーネントで構成されます。コールド・フェイルオーバー・クラスタ構成は、それぞれのOracle Portal、Forms、ReportsおよびDiscovererコンポーネントごとに異なります。この項では、Oracle Portal、Forms、ReportsおよびDiscovererのコールド・フェイルオーバー・クラスタ変換手順について説明します。
Oracle FormsはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Formsをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。
注意: この変換プロセスでは、ファイルの編集前にドメインを停止する必要があります。 |
WLS_FORMS管理対象サーバーを変換します。この手順の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。
Oracle Forms OPMNを変換します。この手順の詳細は、第12.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。
Enterprise Managerを変換します。この手順の詳細は、第12.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。
Oracle Forms Web層コンポーネントを変換します。この手順の詳細は、第12.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。
第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従って、シングル・サインオンを再登録します。
INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるforms.confファイルで、mod_weblogic構成を変更します。
WebLogicドメイン内の管理サーバーと管理対象サーバーだけでなくOracleインスタンスも起動して、コールド・フェイルオーバー・クラスタ・インストールを検証します。
<Location /Forms> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> DynamicServerList OFF </Location>
Oracle ReportsはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Reportsをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。
WLS_REPORTS管理対象サーバーを変換します。この手順の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。
Oracle Reports OPMNを変換します。この手順の詳細は、第12.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。
また、次の操作を行います。
INSTANCE_HOME/config/OPMN/opmnディレクトリにあるopmn.xml
ファイルで、ias-component
のReportsサーバー名を新しい名前に変更して、新しい名前を反映させます。
次に例を示します。
<ias-component id="ReportsServer_virtual_hostname_instance_name"> <process-set id="ReportsServer_virtual_hostname_instance_name" restart-on-death="true" numprocs="1"> </ias-component>
次に例を示します。
<ias-component id="ReportsServer_cfcvip_asinst1"> <process-set id="ReportsServer_ cfcvip asinst1"restart-on-death="true" numprocs="1"> </ias-component>
管理サーバー・ドメイン・ホームのDOMAIN_HOME/opmn/topology.xmlで、このファイル内で、Reportsサーバー名のすべての記述をReportsServer_<physical_hostname>_<instance_name>形式(例: ReportServer_node1_asinst)からReportsServer_<virtual_hostname>_<instance_name>形式(例: ReportServer_cfcvip_asinst)に変更します。
Oracle Enterprise Managerを変換します。この手順の詳細は、第12.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。
Oracle Reports Web層コンポーネントを変換します。この手順の詳細は、第12.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。
シングル・サインオンを再登録します。そのためには、第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従ってください。
INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるreports_ohs.confファイルで、次を変更します。
<Location /reports>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:port
WebLogicPort 9001
</Location>
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に送信されます。 |
名前を変更したディレクトリで、次のファイルに記載された物理ホスト名を仮想ホスト名に置き換えます。
component-logs.xml
logging.xml
INSTANCE_HOME/EMAGENT/emagent_dir/sysman/emdディレクトリにあるtargets.xml
ファイルで、次の変更を行います。
すべてのホスト名をnode1.mycompany.com
からcfcvip.mycompany.com
に変更します。
次の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"
INSTANCE_HOME/reportsディレクトリにあるreports_install.propertiesで、物理ホスト名を仮想ホスト名に置き換えます。
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に変更します。
DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_<version_number>/1ww3jm/configurationディレクトリ(たとえばDOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_11.1.1.3.0/1ww3jm/configurationディレクトリ)にあるrwservlet.propertiesファイルで、物理ホスト名を仮想ホスト名に置き換えます(Reportsサーバー名のすべての記述に関する変更を含む)。
DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_<version_number>/1ww3jm/META-INFディレクトリ(たとえばDOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_11.1.1.3.0/1ww3jm/META-INFディレクトリ)にあるmbeans.xmlファイルで、物理ホスト名を仮想ホスト名に置き換えます(Reportsサーバー名のすべての記述に関する変更を含む)。
WebLogicドメイン内の管理サーバーと管理対象サーバーだけでなくOracleインスタンスも起動して、コールド・フェイルオーバー・クラスタ・インストールを検証します。
Oracle DiscovererはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Discovererをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。
WLS_DISCO管理対象サーバーを変換します。この手順の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。
Oracle Discoverer OPMNを変換します。この手順の詳細は、第12.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。
Oracle Enterprise Managerを変換します。この手順の詳細は、第12.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。
Oracle Discoverer Web層コンポーネントを変換します。この手順の詳細は、第12.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。
シングル・サインオンを再登録します。そのためには、第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従ってください。
INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるreports_ohs.confファイルで、次を変更します。
<IfModule mod_weblogic.c><Location /discoverer> SetHandler weblogic-handler WebLogicCluster cfcvip.mycompany.com:<port> DynamicServerList ON </Location> </IfModule> >
Oracle PortalはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Portalをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。
WLS_PORTAL管理対象サーバーを変換します。この手順の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。
Oracle Portal OPMNを変換します。この手順の詳細は、第12.2.2.6項「Oracle Process Management and Notification Serverの変換」を参照してください。
Oracle Enterprise Managerを変換します。この手順の詳細は、第12.2.2.7項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。
Oracle Portal Web層コンポーネントを変換します。この手順の詳細は、第12.2.2.8項「Web層のコンポーネントとクライアントの変換」を参照してください。
シングル・サインオンを再登録します。そのためには、第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従ってください。
INSTANCE_HOME/config/config/OHS/ohs1/moduleconfにあるportal.confファイルで、mod_weblogic構成を変更します。mod_weblogic構成を変更します。
# WLS routing configuration <Location /portal> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com 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>
Portalレジストリをリワイヤします。
次のURLを使用して、WebLogic Server Enterprise Managerにログインします。
http://cfcvip.mycompany.com:7001/em
無効化パスワードと管理者パスワードを変更します。
「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。
wc1コンポーネントをクリックします。
ページの最上部にあるドロップダウン・リストから「管理」、「パスワード」の順に選択します。
新しい無効化パスワードの入力と確認を行ってから、「適用」をクリックします。
新しい管理者パスワードの入力と確認を行ってから、「適用」をクリックします。
左側のペインで、「Fusion Middleware」メニューを開きます。
「Classic」を選択します。
「Portal」をクリックします。
ポータル・ドメイン情報ページが表示されます。
「Portal」を右クリックして、「設定」、「ワイヤ構成」の順に選択します。
「ポータル中間層」に関して次の情報を入力します。
ホスト: Webキャッシュ・ホストのcfcvip.mycompany.comのコールド・フェイルオーバー・クラスタ仮想IP名を入力します。
ポート: 使用するWebキャッシュ・ポート(HTTPまたは非HTTP)を入力します。
SSLプロトコル: 該当する場合は、この値を入力します。
「Webキャッシュ」に関して次の情報を入力します。
ホスト: Webキャッシュ・ホストのcfcvip.mycompany.comとmysite.mycompany.comのコールド・フェイルオーバー・クラスタ仮想IP名を入力します。
無効化ポート: 9401などの無効化ポートを入力します。
無効化ユーザー名: Portal無効化のユーザー名を入力します。
無効化パスワード: このアカウントのパスワードを入力します。
「適用」をクリックし、リワイヤを開始します。
リワイヤが完了したら、「Portal」メニュー・オプションを再びクリックして、URLが次のようになっていることを確認します。
https://cfcvip.mycompany.com:WCHTTPPort/portal/pls/portal
Oracle WebLogic Serverにおけるホスト・アサーションを変更します。
Oracle HTTP ServerはWebLogicのプロキシとして機能するため、デフォルトでは、ホストやポートなどの特定のCGI変数はWebLogicに渡されません。仮想サイト名とポートを使用していることをWebLogicに認識させ、内部URLが適切に生成できるようにする手順は次のとおりです。
次のURLを使用して、WebLogic Server管理コンソールにログインします。
http://cfcvip.mycompany.com:7001/console
ホーム・ページから「WLS_PORTAL」を選択するか、「ドメイン構造」メニューから「環境」、「クラスタ」の順に選択します。
「チェンジ・センター」ウィンドウで「ロックして編集」をクリックして、編集可能にします。
「プロトコル」をクリックしてから、「HTTP」を選択します。
次の値を入力します。
フロントエンド・ホスト: Cfcvip.mycompany.com
フロントエンドHTTPポート: WCHTTPPort(8090)
フロントエンドHTTPSポート: WCHTTPSPort(8094)
これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート44380に送られます。
「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックして、編集可能にします。
WLS_PORTAL管理対象サーバーを再起動します。
Oracle BAMは、管理対象サーバーにデプロイされるJava EEコンポーネントで構成されます。これらはJava EEコンポーネントであることから、コールド・フェイルオーバー・クラスタ変換手順には、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーのWLS_BAMを変換する方法の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。
Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_BAMにデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。そのためには、SOAコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
# BAM Web Application <Location /OracleBAM > SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location>
カスタムADFアプリケーションを使用するデプロイメントでも、あらゆるFusions Middlewareデプロイメントと同じように、コールド・フェイルオーバー・クラスタを使用できます。この場合、Oracle Application DeveloperのDVDからのインストールを使用して、ドメインを作成します。これは主にJava EEコンポーネントであるため、コールド・フェイルオーバー・クラスタ変換手順は、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーを変換する方法の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。
Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_ADF(カスタマ・アプリケーションの管理対象サーバーの名前)にデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。そのためには、SOAコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
# BAM Web Application <Location /ADFApplicationMountPoint > SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location>
Oracle Enterprise Content Management Suite(ECM Suite)には、Oracle Imaging and Process Management(Oracle I/PM)、Oracle Universal Content Management(Oracle UCM)、Oracle Universal Records Management(URM)、Oracle Inbound Refineries(Oracle IBR)などの製品が含まれます。
ECM Suiteをインストールする場合、一般的には次の管理対象サーバーが含まれます。
Oracle I/PM(WLS_IPM)
Oracle UCM(WLS_UCM)
Oracle URM(WLS_URM)
Oracle IBR(WLS_IBR)
コールド・フェイルオーバー・デプロイメントでは、この章の前の項でCFCデプロイメントに推奨されているアプリケーション層およびWeb層の設定を行い、これらの管理対象サーバーに対してコールド・フェイルオーバー・クラスタ変換の手順を実行することをお薦めします。Oracle I/PM、UCM(またはURM)、およびIBR管理対象サーバーを変換する方法の詳細は、第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」を参照してください。
ECM Suiteのコールド・フェイルオーバー・クラスタ・デプロイメントについては、さらに次も考慮してください。
ECM Suiteの多くのコールド・フェイルオーバー・クラスタでは、次のようなデプロイメント・トポロジになります。
I/PMとUCMの両方ともハードウェア・クラスタの同じノードにデプロイされます。
ハードウェア・クラスタの一方のノードにI/PM、もう一方のノードにUCMというデプロイメントで、相互的なフェイルオーバーに構成されます。
I/PMサーバーがフェイルオーバーするときにアクセスする必要があるすべてのI/PM関連のファイルも、共有ディスクに配置する必要があります。これには、入力ファイルやイメージなどが含まれます。CFC構成のすべてのノードからアクセスできるように、これらは必ず共有ディスクに配置してください。入力ファイルとイメージ・ファイルは個別のボリュームを用意することをお薦めします。
JMSやTLogsなどで使用される永続ストアも、すべて共有ディスクに配置する必要があります。
Inbound Refineryに関連するすべての制限は、CFC構成にも引き継がれて適用されます。Inbound Refineryインスタンスの構成の詳細は、Oracle Fusion Middleware Conversion管理者ガイドを参照してください。
UCMのコンテンツに関するすべてのフォルダも同様に共有ディスクに配置する必要があります。これは、UCMサーバー構成とともに1つのユニットとしてフェイルオーバーされます。これには、次のようなフォルダが含まれます。
コンテンツ・サーバー・インスタンス・フォルダ
ネイティブ・ファイル・リポジトリの場所
Webレイアウト・フォルダ
http://cfcvip.mycompany.com:port/cs
を使用してUCMまたはURMを構成する場合、「WebサーバーのHTTPアドレス」がECM管理対象サーバーのフロントエンドとなるHTTPサーバーのホスト名および場所になります。HTTPサーバーの高可用性構成に応じて、これはロード・バランサのアドレス、物理ホスト、または仮想ホストになります。Oracle HTTP ServerもCFCデプロイメントに含まれる場合、上の値はOracle HTTP Serverの仮想IPに設定する必要があります。Oracle HTTP ServerがECMサーバーと同じハードウェア・クラスタに存在する場合、これはcfcvip.mycompany.com
のようになります。
UCMがコールド・フェイルオーバー・クラスタで構成され(上の例に含まれます)、I/PMがUCMに接続されている場合、UCMの仮想IPアドレスを使用することをお薦めします。http://cfcvip.mycompany.com:port/imaging
を使用してこの構成を行う場合、次の手順を実行します。
左側のペインで、「接続の管理」→「Content Server接続の作成」をクリックします。
新しい接続の名前と説明を入力し、「次へ」をクリックします。
「接続設定」画面で、次を入力します。
Content Server Version: CS 11g
Primary: cfcvip.mycompany.com:4444
「次へ」をクリックします。
接続セキュリティ画面で、WebLogicユーザーに対するデフォルトの選択をそのまま受け入れ、「次へ」をクリックします。
接続の詳細を確認し、「送信」をクリックします。
また、Oracle HTTP ServerをECM Suiteアプリケーションのフロントエンドとして使用している場合、mod_weblogic構成で、管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを使用する必要があります。そのためには、ECMコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。
LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so" # Content Server <Location /cs> WebLogicHost cfcvip.mycompany.com:<port> SetHandler weblogic-handler WLCookieName IDCCS_SESSIONID </Location> # URM <Location /urm> WebLogicHost cfcvip.mycompany.com:<port> SetHandler weblogic-handler WLCookieName IDCURM_SESSIONID </Location> # IBR <Location /ibr> WebLogicHost cfcvip.mycompany.com:<port> SetHandler weblogic-handler WLCookieName IDCIBR_SESSIONID </Location> # IPM <Location /imaging> WebLogicHost cfcvip.mycompany.com:<port> SetHandler weblogic-handler </Location>
Oracle Business Intelligenceは、ビジネス・ユーザーに組織の全体像を提供する統合ビジネス・インテリジェンス(BI)ソリューションです。Oracle Business Intelligenceは、迅速かつ簡単に様々なデータソースを統合し、データベースの情報を検索し、データベース情報を共有して、企業およびその顧客に関する情報を得るためにデータを有効に利用することを目的として設計されています。
この項では、Oracle Business Intelligence PublisherおよびOracle Real-Time Decisionsに対するアクティブ/パッシブによる高可用性構成について説明します。
この項では、Oracle Business Intelligence Publisher(Oracle BI Publisher)をコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
Oracle Business Intelligence Publisherの変換
次の項では、Oracle BI Publisherをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
管理対象サーバーの変換
Oracle BI Publisherは管理対象サーバー(BI_SERVER1など)にデプロイされます。コールド・フェイルオーバー・クラスタ変換の手順はこの管理対象サーバーをインストール後に仮想IPのcfcvip.mycompany.com
でリスニングするように構成することになります。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、BI_SERVER1管理対象サーバーを、cfcvip.mycompany.com
の仮想IP上でリスニングするように構成してください。
ここで、WebLogic Server管理コンソールまたはWLSTコマンドを使用して、管理対象サーバーを再起動します。
Middlewareホームの配置に関するすべての要件およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトは、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明に適用されます。Oracle BI Publisherのコールド・フェイルオーバー・クラスタに固有の要件は、必ず次のアーティファクトが共有ディスクにも存在し、フェイルオーバー・クラスタの両方のノードから同じマウント・ポイントにアクセスできるということです。デフォルトのインストールで構成する場合、暗黙的にこのようになります。
トランザクション・ログおよびJMS永続的ストア
BI Publisher構成フォルダ
BI Publisherカタログ・リポジトリ
BI Publisher Scheduler一時ディレクトリ
次の手順に従って、Oracle BI Publisherクライアントを変換します。
Oracle BI Publisherクライアントは、仮想IPのcfcvip.mycompany.com
を使用してこのアプリケーションにアクセスする必要があります。
WSM-PMは同じ管理対象サーバーにデプロイされるため、WSM-PMで必要なクライアント側の構成変更が同じように実行されていることを確認してください。
Oracle HTTP ServerがOracle Directory Services Managerのフロントエンドである場合、次の例に示すように、mod_wl_ohsファイルを編集して仮想IPのcfcvip.mycompany.com
をOracle BI Publisher管理対象サーバーのアドレスに指定します。
# BI Publisher
<Location /xmlpserver>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:port
</Location>
# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster APPHOST1:9704, APPHOST2:9704
</Location>
この項では、Oracle Real-Time Decisions(Oracle RTD)をコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
Oracle RTDの変換
Oracle RTDをコールド・フェイルオーバー・クラスタ・デプロイメントに変換するには、この項の手順を実行します。
Oracle RTDは管理対象サーバー(BI_SERVER1など)にデプロイされます。コールド・フェイルオーバー・クラスタ変換の手順はこの管理対象サーバーをインストール後に仮想IPのcfcvip.mycompany.com
でリスニングするように構成することになります。第12.2.2.4項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、BI_SERVER1管理対象サーバーを、cfcvip.mycompany.com
の仮想IP上でリスニングするように構成してください。
Middlewareホームの配置に関するすべての要件およびフェイルオーバー可能な共有記憶域上のその他のドメイン・アーティファクトは、第12.2.1項「コールド・フェイルオーバー・クラスタの一般的要件」の説明に適用されます。
次の手順に従って、Oracle RTDクライアントを変換します。
Oracle RTDクライアントは、仮想IPのcfcvip.mycompany.com
を使用してこのアプリケーションにアクセスする必要があります。
WSM-PMは同じ管理対象サーバーにデプロイされるため、WSM-PMで必要なクライアント側の構成変更が同じように実行されていることを確認してください。
Oracle HTTP ServerがOracle RTDのフロントエンドである場合、次の例に示すように、mod_wl_ohsファイルを編集して仮想IPのcfcvip.mycompany.com
をOracle RTD管理対象サーバーのアドレスに指定します。
<Location /rtis> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:port </Location> <Location /schemas> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:port </Location> <Location /ws> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:port </Location> # WSM-PM <Location /wsm-pm> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 </Location> # RTD <Location /ui> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 </Location>
シングル・サインオン(SSO)の再登録は通常、Oracle Portal、Forms、ReportsおよびDiscovererにのみ適用されます。この層のOracle HTTP Server上のフロントエンド・リスニング・エンドポイントが仮想IPに変更されている場合、保護されるURLを仮想IPによって構成するために、SSOの再登録が必要になります。SSOを再登録するには、SSOサーバーが配置されているIdentity Management 10.1.xインストールに対して次の手順を実行します。
ORACLE_HOME変数をSSOのORACLE_HOMEの場所に設定します。
次のパラメータを指定して、ORACLE_HOME/sso/bin/ssoreg.sh(Windowsの場合はssoreg.bat)を実行します。
-site_name cfcvip.mycompany.com:port
-mod_osso_url http://cfcvip.mycompany.com
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier
ORACLE_HOME変数をSSOのORACLE_HOMEの場所に設定します。
次に示す中間層ホームの場所に/tmp/osso.confファイルをコピーします。
ORACLE_INSTANCE/config/OHS/ohs1
ORACLE_HOME/opmn/bin/ディレクトリから次のコマンドを実行して、Oracle HTTP Serverを再起動します。
opmnctl restartproc process-type=OHS
次のURLでSSOサーバーにログインします。
http://login.mycompany.com/pls/orasso
「管理」ページ、「パートナ・アプリケーション管理」の順に選択して、node1.mycompany.comのエントリを削除します。
Oracle Fusion Middlewareデプロイメントにおいて、Oracleデータベースは重要な役割を果たします。Oracle Fusion Middlewareの一般的コールド・フェイルオーバー・クラスタ・デプロイメントでは、データベースもコールド・フェイルオーバー・クラスタとしてデプロイされます。この項では、単一インスタンスのOracleデータベースをコールド・フェイルオーバー・クラスタ・データベースに変換する手順について説明します。RCUを使用してデータベースをシードする作業と、後続のFusion Middlewareインストールでこのシード済データベースを使用する作業の前に、この変換を実行します。データベースをコールド・フェイルオーバー・クラスタ用に有効化する手順は次のとおりです。
データベース・インスタンスが使用するリスナー構成を変更します。
そのためには、listener.oraファイルを変更する必要があります。リスナー構成のホスト名では値として仮想ホスト名が指定されていることを確認します。また、リスナー・ポートが他のプロセス(Oracleまたはサード・パーティのプロセス)によって使用されていないことを確認します。
<listener_name> = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = <virtual hostname>)(PORT = <port>)) ) )
次に例を示します。
LISTENER_CFCDB = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST cfcdbhost.mycompany.com)(PORT = 1521)) ) )
tnsnames.oraファイルを変更します。
既存のTNSサービス別名エントリを変更するか、新しいエントリを作成します。
<tns alias name> = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = <virtual hostname>)(PORT = <port>)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <db service name>) (INSTANCE_NAME = <db instance name>) ) ) )
次に例を示します。
CFCDB = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = cfcdbhost.mycompany.com)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = cfcdb) (INSTANCE_NAME = cfcdb) ) )
ローカルのSPFILEを変更して、インスタンスのlocal_listenerパラメータを更新します。
SQL*Plusを使用して、sysdbaとしてログインします。
SQL> alter system set local_listener='<tns alias name>' scope=both; )
次に例を示します。
SQL> alter system set local_listener='CFCDB' scope=both;
リスナーを停止してから再起動します。
データベース・インスタンスを停止してから再起動します。
アプリケーション・サーバーのデータベース・サービスを作成します。
Oracle Application Serverで使用するデフォルト・データベース・サービスとは別に、専用のサービスを作成することをお薦めします。このサービスを作成するには、次のSQL*Plusコマンドを実行します。
SQL> execute DBMS_SERVICE.CREATE_SERVICE( '<cfc db service name>' '<cfc db network name>' ) \
次に例を示します。
SQL> execute DBMS_SERVICE.CREATE_SERVICE( 'cfcdb_asservice' 'cfcdb_asservice' ) SQL> execute DBMS_SERVICE.START_SERVICE( 'cfcdb_asservice' )
インストールによっては、必要に応じてこのサービス用に追加パラメータを設定する場合があります。DBMS_SERVICEコマンドの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
Windowsリソース・キットのSCツールを使用して、次のサービスを作成します。
UnixおよびWindowsプラットフォームのデータベース・インスタンスについて次の手順を検討してください。
Unixの場合:
前述のマウントおよびアンマウントの手順に従って、ノード1(インストール・ノード)からフェイルオーバー・ノード(ノード2)へ手動でデータベースのOracleホームをフェイルオーバーさせます。
rootとして、次の操作を行います。
ノード1にあるものと同一のoraInst.locファイルを/etc
ディレクトリに作成します。
ノード1にあるものと同一のoratab
ファイルを/etc
ディレクトリに作成します。
ORACLE_HOME
ディレクトリにあるoracleRoot.sh
ファイルをノード2で実行します。これは、製品スイートで利用可能な場合や必要に応じて実行します。
ORACLE_HOME/oui/bin/attachHome.sh
ディレクトリにあるattachHome
コマンドを使用して、oraInventory
ファイルを2番目のノードで作成します。
Windowsの場合:
ノード1のシステム環境変数Pathにこのデータベースに関するなんらかの情報が含まれている場合、ノード2の同じ変数にも必ずその情報を設定します。ノード1からレジストリHKEY_LOCAL_MACHINE/Oracleをエクスポートしてそれをノード2にインポートします。ノード2のORA_DBAグループにもユーザー「system」が存在することを確認します。
Windowsリソース・キットのSCツールを使用して、次のサービスを作成します。
dbサービス
sc create OracleService<oracle_sid> start= demand binPath= "ORACLE_HOME\bin\ORACLE.EXE <oracle_sid>"
次に例を示します。
sc create OracleServiceORCL start= auto binPath= "C:\Oracle\db\product\11.1.0\bin\ORACLE.EXE <oracle_sid>"
注意: oracle_sid は大文字で指定する必要があります。 |
リスナー
sc create Oracle<home name>TNSListener start= demand binPath= "ORACLE_HOME\bin\TNSLSNR"
次に例を示します。
sc create OracleINFRATNSListener start= demand binPath= "C:\Oracle\db\product\11.1.0\bin\TNSLSNR"
クラスタ・サービス
sc create OracleCSService start= auto binPath= "ORACLE_HOME\bin\ocssd.exe service"
次に例を示します。
sc create OracleCSService start= auto binPath= "INFRAHOME\bin\ocssd.exe service"
データベース・コンソール
sc create OracleDBConsole<oracle_sid> start= auto binPath= "ORACLE_HOME\bin\nmesrvc service"
次に例を示します。
sc create OracleDBConsoleorcl start= auto binPath= " C:\Oracle\db\product\11.1.0\bin\nmesrvc service"
ジョブ・スケジューラ
sc create OracleJobScheduler<oracle_sid> start= demand binPath= "ORACLE_HOME\bin\extjob.exe <oracle_sid>"
次に例を示します。
sc create OracleJobSchedulerORCL start= auto binPath= "C:\Oracle\db\product\11.1.0\INFRAHOME\bin\extjob.exe <oracle_sid>"
注意: oracle_sid は大文字で指定する必要があります。 |
Vssサービス
sc create OracleVssWriter<oracle_sid> start= demand binPath= "ORACLE_HOME\bin\OraVSSW.exe <oracle_sid>"
次に例を示します。
sc create OracleJobSchedulerORCL start= auto binPath= "C:\Oracle\db\product\11.1.0\INFRAHOME\bin\ OraVSSW.exe <oracle_sid>"
注意: oracle_sid は大文字で指定する必要があります。 |
この項では、コールド・フェイルオーバー・クラスタのトポロジ例をいくつか示します。トポロジでは様々な組合せが考えられるため、ここで示すトポロジは例にすぎません。これらのトポロジを実現するには、複数の変換手順が適用されます。変換を構成する方法の詳細は、前述の各手順を参照してください。
図12-3は、Oracle WebCenterコールド・フェイルオーバー・クラスタ・デプロイメントを示しています。ドメイン内には管理サーバーとWebCenter管理対象サーバーの両方があり、1つのユニットとしてフェイルオーバーします。したがって、これらは同じ仮想IPを共有し、同じ共有ディスク上にまとめてインストールされています。このトポロジのフロントエンドとしてOracle HTTP Serverも使用できます。このトポロジ例では、別のノードに配置されています。同じノードに配置して、コールド・フェイルオーバー・クラスタ・デプロイメントの一部とすることも可能です。この例では、データベースも別のノードに配置されています。しかし、データベースも同様に、同じクラスタ上に配置して、コールド・フェイルオーバー・クラスタベースにする場合もあります(仮想IPと共有ディスクは専用のものを使用)。
図12-4は、SOAコールド・フェイルオーバー・クラスタ・デプロイメント例を示しています。この例では、SOAインスタンスのみがコールド・フェイルオーバー・クラスタとしてデプロイされ、管理サーバーは別のノードに配置されています。このトポロジ例では、データベースも別のノードに配置されています。この例では、Oracle HTTP Serverはコールド・フェイルオーバー・クラスタ・デプロイメントの一部であり、SOA管理対象サーバーと同じフェイルオーバー・ユニットの一部になります。このトポロジの重要なバリエーションの1つは、同じハードウェア・クラスタにコールド・フェイルオーバー・クラスタ管理サーバーを組み込むことです。この場合、仮想IPと共有ディスクをSOA管理対象サーバーと共有するか(管理サーバーをSOAと同じフェイルオーバー・ユニットに組み込む)、別の仮想IPと共有ディスクを使用(管理サーバーを別個にフェイルオーバーさせる)できます。同様に、マシンの処理能力に応じて、データベース・インスタンスも同じハードウェア・クラスタに配置できます。
図12-5は、Oracle Identity Managementデプロイメントを示しています。このトポロジ例では、すべてのコンポーネントが、2つのノードのハードウェア・クラスタに配置されています。Identity Managementは1つのユニットとしてフェイルオーバーし、Java EEコンポーネント(管理サーバーとWLS_ods管理対象サーバー)とシステム・コンポーネントの両方が、同じフェイルオーバー・ユニットの一部となっています。これらは同じ仮想IP(cfcvip1.mycompany.com)と共有ディスクを使用しています。データベースも同じハードウェア・クラスタに配置されています。データベースは異なる仮想IP(cfcvip2.mycompany.com)と、異なる共有ディスク・セットを使用しています。通常の運用中では、データベースはノード2で実行し、IDMスタックはノード1で実行します。それぞれのノードは互いにバックアップ・ノードとして機能します。
このトポロジは、ほとんどのコールド・フェイルオーバー・クラスタ・デプロイメントの推奨トポロジです。例ではIdentity Managementを使用していますが、Oracle SOA Suite、Oracle WebCenter Suite、Oracle Portal、Forms、ReportsおよびDiscovererスイートにも有効です。この推奨アーキテクチャでは、Oracle Fusion Middlewareはハードウェア・クラスタの1つのノードとして実行します。別のノードではOracleデータベースが実行します。各ノードは互いにバックアップ・ノードになります。Oracle Fusion Middlewareインスタンスとデータベース・インスタンスは、異なる共有ディスクとVIPを使用し、互いに独立してフェイルオーバーします。また、このアーキテクチャでは、ハードウェア・クラスタ・リソースの使用率が最適化されます。
この項では、既存のドメインの管理サーバーをコールド・フェイルオーバー・クラスタに変換する手順について説明します。
注意: 管理サーバーの変換後、第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」で述べられているように、管理サーバーおよびEnterprise Managerのクライアント側の変更が必要になる場合があります。 |
前提事項
この項の手順は、次を前提としています。
すべてのFusion Middlewareコンポーネントは、nostageデプロイメントに配置されている。
起動トポロジが製品スイートのアクティブ/アクティブ・クラスタである(ノード1およびノード2)。
開始する管理サーバーはノード1である。
ノード1の管理対象サーバーと同じドメイン・ホームを共有している。
MW_HOMEパスがノード1とノード2で同じである。
トポロジの起動を実行するには、次の項を参照してください。
Oracle SOA Suite: Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成
Oracle ADF: Oracle ADFの高可用性デプロイメントの構成
Oracle WebCenter: Oracle WebCenterの高可用性の構成
Oracle Identity Manager: Identity Managementコンポーネントの高可用性の構成
これらの手順は、前述の前提が満たされていれば、Oracle WebLogicクラスタ・インストールにデプロイされているカスタマ・アプリケーションにも適用されます。
図12-6は、管理サーバーを変換する前の開始トポロジの例を示しています。
図12-7に、コールド・フェイルオーバー・クラスタ用に管理サーバーを変換した後の可能なトポロジを示します。このトポロジは、次のような特性を持ちます。
管理サーバー・ドメイン・ホームは、ノード1とノード2の両方でマウント可能な共有ディスクに移動します。ただし、任意の時点では片方のみがマウントされます。
引き続き、ノード1とノード2からアクセスできる元のMiddlewareホームが使用されます。
管理サーバーのリスニング・アドレスは、仮想IPになります。
既存のドメインで管理サーバーを変換するには、次の手順を実行します。
コンポーネントの管理対象サーバーおよび管理サーバーのクラスタをシャットダウンします。
各ノードでノード・マネージャ・プロセスが稼働していれば、それをシャットダウンします。
ドメイン全体をバックアップします。
ノード1で仮想IPをプロビジョニングします。次に例を示します。
Linuxの場合:
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アドレスが有効化されます。
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
ローカルのドメイン・ホームから管理サーバーを起動します。
cd DOMAIN_HOME/bin
./startWeblogic.sh
管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
Oracle WebLogic Server管理コンソールにログインします。
仮想ホストのマシンを作成します。
「環境」、「マシン」の順に選択します。
「チェンジ・センター」で「ロックして編集」をクリックします。
「新規」をクリックします。
「名前」フィールドでは、cfcvip.mycompany.comと入力します。
適切なオペレーティング・システムを選択します。
「OK」をクリックします。
作成したマシンを選択します。
「サーバー」タブをクリックします。
「追加」をクリックします。
既存のサーバーを選択して、このマシンに関連付けます。
「サーバーの選択」ドロップダウン・リストで、「AdminServer」が選択されていることを確認します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。
cfcvip.mycompany.com上でリスニングするように管理サーバーを構成します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「チェンジ・センター」で「ロックして編集」をクリックします。
管理サーバー(AdminServer)をクリックします。
「リスニング・アドレス」をcfcvip.mycompany.comに変更します。
「保存」をクリックします。
WebLogic Server管理コンソールから管理サーバーを停止します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」をクリックします。
その横にあるチェック・ボックスをクリックして、「Adminserver」を選択します。
「停止」プルダウン・メニューで、「ただちに強制停止」を選択して、管理サーバーをシャットダウンします。
「はい」をクリックします。
コマンドラインから、システムでVIPが有効で、管理サーバーが起動していることを確認します。
cd DOMAIN_HOME/bin
./startWeblogic.sh
仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
管理コンソールを使用して、ノード1の管理サーバーシャットダウンします。
ノード1で共有ディスクがプロビジョニングおよびマウントされていることを確認します。
ノード1でドメイン全体をパックします。
cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=false -domain=/localdisk/Oracle/Middleware/
user_projects/domains/base_domain -template=cfcdomaintemplate_all.jar
-template_name=cfc_domain_template_all
それを共有ディスク上に解凍します。
./unpack.sh -domain=/shareddisk/Oracle/Middleware/user_projects/domains/ base_domain -template=cfcdomaintemplate_all.jar -app_dir=/shareddisk/Oracle/Middleware/user_projects/apps -server_start_mode=prod
製品スイート固有の変更:
Oracle WebCenter製品スイート:
共有ディスクでowc_wikiをプロビジョニングすることをお薦めします。つまり、管理サーバー・ドメイン・ホームを含む共有ディスク上のアプリケーション・ディレクトリにこれをデプロイします。次に例を示します。
/shareddisk/Oracle/Middleware/user_projects/apps
アプリケーション・ディレクトリは両方のノードでマウントされ使用できる必要があります。この推奨構成はデフォルトで実行され、追加手順は不要です。
Oracle Identity Management製品スイート:
この例の/shareddisk/Oracle/Middleware/user_projects/domains/base_domain/config/
にあるconfig.xml
ファイルをバックアップします。
この例の/shareddisk/Oracle/Middleware/user_projects/domains/base_domain/config/
にあるconfig.xml
ファイルを編集してソースパスに次の変更を行います。
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>/uo1/app/Oracle/Middleware1/Oracle_IDM1/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>/u01/app/Oracle/Middleware1/Oracle_IDM1/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>/u01/app/Oracle/Middleware1/Oracle_IDM1/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>/u01/app/Oracle/Middleware1/Oracle_IDM1/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.ear</source-path>
<security-dd-model>DDOnly</security-dd-model>
</library>
管理サーバーを起動します。
cd /shareddisk/Oracle/Middleware/user_projects/domains/base_domain/bin ./startWeblogic.sh
仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
管理サーバーをシャットダウンします。
ノード1で次を実行します。
mv /localdisk/Oracle/Middleware/user_projects/domains/base_domain
/localdisk/Oracle/Middleware/user_projects/domains/base_domain_old
mv /localdisk/Oracle/Middleware/user_projects/applications/base_domain
/localdisk/Oracle/Middleware/user_projects/applications/base_domain_old
cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true -domain=/shareddisk/Oracle/Middleware/user
_projects/domains/base_domain
-template=cfcdomaintemplate_mngd.jar -template_name=cfc_domain_template_mngd
./unpack.sh -domain=/localdisk/Oracle/Middleware/user_projects/domains/base_domain
-template=cfcdomaintemplate_mngd.jar
注意: これらのコマンドでは、アプリケーション・ディレクトリがuser_projects の下に存在すると想定しています。 |
テンプレートをノード2にコピーします。
scp ORACLE_COMMON_HOME/common/bin/cfcdomaintemplate_mngd.jar Node2:ORACLE_COMMON_HOME/common/bin
ノード2にログインして、ノード2上で解凍します。
mv /localdisk/Oracle/Middleware/user_projects/domains/base_domain
/localdisk/Oracle/Middleware/user_projects/domains/base_domain_old
mv /localdisk/Oracle/Middleware/user_projects/applications/base_domain
/localdisk/Oracle/Middleware/user_projects/applications/base_domain_old
cd ORACLE_COMMON_HOME/common/bin
./unpack.sh -domain=/localdisk/Oracle/Middleware/user_projects/domains/base_domain -template=cfcdomaintemplate_mngd.jar
注意: これらのコマンドでは、アプリケーション・ディレクトリがuser_projects の下に存在すると想定しています。 |
Oracle Identity Manager Suiteでは、次の追加手順が必要です。
DIPの場合:
ノード1で、Oracle WebLogic Serverドメイン・ディレクトリ内のアプリケーション・ディレクトリを探します。
MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applications
ノード1のアプリケーション・ディレクトリとその内容を、ノード2のドメイン・ディレクトリ内の同じ場所にコピーします。
scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers
/wls_ods1/applications
user@IDMHOST2:MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig
/servers/wls_ods2/applications
OIFの場合:
ノード1で、Oracle WebLogic Serverドメイン・ディレクトリ内のアプリケーション・ディレクトリを探します。
MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig/servers/wls_oif1/applications
ノード1のアプリケーション・ディレクトリとその内容を、ノード2のドメイン・ディレクトリ内の同じ場所にコピーします。
scp -rp MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig/servers
/wls_oif1/applications
user@IDMHOST2:MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig
/servers/wls_oif2/applications
管理サーバーを起動します。
cd /shareddisk/Oracle/Middleware/user_projects/domains/base_domain/bin ./startWeblogic.sh
ノード1およびノード2でノード・マネージャが使用されている場合、それを起動します。
cd WL_HOME/server/bin
./startNodeManager.sh
管理サーバー・コンソール(ノード・マネージャが使用されている場合)またはコマンドラインからノード1およびノード2上のコンポーネントの管理対象サーバーを起動します。
コンポーネント固有の機能テストを使用してデプロイメントを検証します。
管理サーバーのフェイルオーバーをテストします。
管理サーバーを2番目のノードに手動でフェイルオーバーさせます。
管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。
Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。
記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。
ノード1で仮想IPを無効化します。
Linuxの場合:
ifconfig interface:index down
次の例では、eth0インタフェースでIPアドレスが無効化されます。
ifconfig eth0:1 down
Windowsの場合:
netsh interface ip delete address interface addr=IP Address
この場合、IP Addressは仮想IPアドレスです。
次の例では、「Local Area Connection」のインタフェースでIPアドレスが有効化されます。
netsh interface ip delete address 'Local Area connection' addr=130.35.46.17
ノード2で仮想IPを有効化します。
次のコマンドを使用して、管理サーバー・プロセスを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。
管理サーバーとOracle Enterprise Manager管理コンソールの両方へのアクセスを検証します。
コンポーネント固有のテストで検証します。
検証後、管理サーバーが通常に稼働し、通常に処理を実行するノード(ノード1またはノード2)にフェイルバックします。