Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド 11gリリース2 (11.1.2.2) B69538-05 |
|
前 |
次 |
この章では、アクティブ/パッシブ・トポロジを構成して管理する方法について説明します。次の項目が含まれます。
Oracle Fusion Middlewareは、Oracle Fusion Middleware Cold Failover Cluster(コールド・フェイルオーバー・クラスタ)を使用して、すべてのコンポーネントにアクティブ/パッシブ・モデルを提供します。コールド・フェイルオーバー・クラスタ構成では、複数の管理対象サーバー・インスタンスが同じアプリケーション・ワークロードを処理するように構成されますが、アクティブになるインスタンスは常に1つのみです。
2つのノードのコールド・フェイルオーバー・クラスタを使用すると、中間層コンポーネントのアクティブ/パッシブ構成の可用性を実現できます。コールド・フェイルオーバー・クラスタでは、1つのノードがアクティブになり、別のノードはスタンバイ・ノードとしてパッシブになります。アクティブ・ノードで障害が発生すると、スタンバイ・ノードがアクティブ化され、中間層コンポーネントはそのノードからクライアント・リクエストの処理を続行します。すべての中間層コンポーネントが新しいアクティブ・ノードにフェイルオーバーします。フェイルオーバー後、障害ノードでは中間層コンポーネントは実行されなくなります。
コールド・フェイルオーバー・クラスタ構成の最も一般的なプロパティは、次のとおりです。
共有記憶域: 共有記憶域は、コールド・フェイルオーバー・クラスタにおける主要プロパティです。アクティブ/パッシブ構成におけるOracle Fusion Middlewareパッシブ・インスタンスは、アクティブ・インスタンスと同じように、Oracleバイナリ、構成ファイル、ドメイン・ディレクトリおよびデータにアクセスできます。コールド・フェイルオーバー・クラスタ構成にあるすべての参加ノードでアクセス可能な記憶域にこれらのアーティファクトを配置することで、このアクセスを構成します。通常、アクティブ・ノードでは共有記憶域がマウントされて、パッシブ・ノードではアンマウント状態になりますが、ノードがアクティブになるとこの記憶域にアクセス可能になります。この共有記憶域は、両方のノードでアクセス可能な二重ポート対応ディスク・デバイスにできますし、NASやSANなどのデバイスベース記憶域にもできます。共有記憶域は通常のファイル・システム上にインストールできます。コールド・フェイルオーバー・クラスタの場合、ボリュームをマウントするノードは一度に1つのみです。
仮想ホスト名: コールド・フェイルオーバー・クラスタ・ソリューションでは、2つのノードが1つの仮想ホスト名と1つの仮想IPを共有します。(仮想ホスト名と仮想IPは対応するもので、このガイドでは互換的に使用します。)ただし、この仮想IPを使用できるノードは、常に1つのアクティブ・ノードに限定されます。アクティブ・ノードで障害が発生してスタンバイ・ノードがアクティブになると、仮想IPが新しいアクティブ・ノードに移行します。この新しいアクティブ・ノードでは仮想IPによりすべてのリクエストが処理されます。仮想ホスト名により、デプロイメントの単一システム・ビューが実現されます。コールド・フェイルオーバー・クラスタのデプロイメントは、この仮想IP上でリスニングするように構成されます。たとえば、ハードウェア・クラスタの2つの物理ホスト名がnode1.example.com
およびnode2.example.com
である場合、名前cfcvip.example.com
によって、このクラスタの単一のビューが提供されます。DNSでは、cfcvip.example.com
が仮想IPにマップされます。この仮想IPは、ノード1とノード2との間で変動します。ハードウェア・クラスタを使用すると、仮想IPのフェイルオーバーが管理されるため、どの物理ノードがアクティブでリクエストを実際に処理しているのかを中間層のクライアントでは検出されません。
ハードウェア・クラスタ: 通常、コールド・フェイルオーバー・クラスタ・デプロイメントでは、ハードウェア・クラスタを使用します。ハードウェア・クラスタでは、そのアーキテクチャにおいて共有記憶域と仮想IPが管理されます。これは、これらの共有リソースの高信頼性フェイルオーバーの役割を果たし、堅牢なアクティブ/パッシブ・ソリューションを実現します。ほとんどのコールド・フェイルオーバー・クラスタは、次のもので構成されるハードウェア・クラスタにデプロイされます。
同じサブユニット内にある2つのノード
2つのノード間における高速プライベート・インターコネクト
パブリック・ネットワーク・インタフェース: このインタフェース上でクライアント・リクエストが処理され、仮想IPが有効化されます。
2つのノードからアクセス可能な共有記憶域:これには、クォーラム・デバイスとして機能する共有記憶域と、Oracle Fusion Middlewareインストールとデータベース・インストールの共有記憶域が含まれます。
ノードとコンポーネントの障害を管理するために実行されるクラスタウェア
予定のスイッチオーバーと予定外のフェイルオーバー: コールド・フェイルオーバー・クラスタの一般的デプロイメントは、2つのノードのハードウェア・クラスタです。使用率を最大にするために、通常、これらのノードにはどちらも、実行しているデプロイメントの要素がいくつかあり、必要に応じて一方のノードが他方のノードの要素のバックアップ・ノードの役割を果たします。たとえば、あるノードでアプリケーション層(WebLogicコンテナ)が実行され、別のノードでWeb層(Oracle HTTP Server)が実行されるデプロイメントなどがあります。どちらか一方のノードをメンテナンスのために停止した場合や、どちらか一方のノードで障害が発生した場合には、停止していないノードが現在のサービスのホスト処理が継続しながら、停止したノードのサービスのホスト処理を実行します。
スタンバイ・ノードにスイッチオーバーするための高レベル手順は次のとおりです。
1次ノード上の中間層サービスを停止します(そのノードが利用可能な場合)。
現在のアクティブ・ノードからパッシブ・ノードへ仮想IPをフェイルオーバーさせます。現在のノードでそれを停止してから、パッシブ・ノードで有効化し起動します。
現在のアクティブ・ノードからパッシブ・ノードへ共有ディスクをフェイルオーバーさせます。この操作には、現在のノードから共有ディスクをアンマウントしてからパッシブ・ノードにマウントする操作が含まれます。
パッシブ・ノード上で中間層サービスを起動し、アクティブにします。
フェイルオーバーを管理するには、計画スイッチオーバーの手順を手動で実行します(障害の検出およびフェイルオーバーは手動です)。
アクティブ/パッシブ・デプロイメントの場合、通常、サービスが停止する時間は短時間です。これは、同じノード上でインスタンスを再起動するのに要する時間、またはパッシブ・ノードにインスタンスをフェイルオーバーするに要する時間になります。
アクティブ/パッシブ・トポロジ: 長所
可用性の向上
アクティブ・インスタンスに障害が発生した場合や、アクティブ・インスタンスをオフラインにする必要がある場合、いつでも同一構成のパッシブ・インスタンスで処理の引継ぎができます。この構成では、通常の単一インスタンス型デプロイメントより可用性のレベルが高くなります。また、アクティブ/パッシブ・デプロイメントは、ハードウェアの計画メンテナンス操作や計画外メンテナンス操作に対して可用性と保護機能を実現します。計画メンテナンスのためにノードを停止する必要がある場合、パッシブ・ノード上のミドルウェア・サービスを起動できます。適切な時点で元のノードへスイッチバックします。
運用コストの削減
アクティブ/パッシブ構成では、1つのプロセス・セットのみが稼働して、リクエストを処理します。アクティブ・インスタンスの管理では通常、複数のアクティブ・インスタンスの配列の管理より低コストです。
コールド・フェイルオーバー・クラスタ・トポロジの実装はそれほど難しくありません。それらのクラスタではロード・バランサが不要ですが、アクティブ/アクティブ・トポロジでは必要になるからです。
ロード・バランシング・アルゴリズム、クラスタリング、レプリケーションなどのオプションを構成する必要がないため、コールド・フェイルオーバー・クラスタ・トポロジの実装は、アクティブ/アクティブ・トポロジほど難しくありません。
アクティブ/パッシブ・トポロジでは、アクティブ/アクティブ・トポロジより正確に、1つのインスタンスのトポロジがシミュレートされます。
アプリケーションの非依存性
一部のアプリケーションは、アクティブ/アクティブ構成に適さない場合があります。このようなアプリケーションには、アプリケーションの状態への依存度が高いアプリケーションや、ローカルに格納された情報への依存度が高いアプリケーションなどあります。シングルトン・アプリケーションには、アクティブ/パッシブ・デプロイメントが適しています。アクティブ/パッシブ構成では、常に1つのインスタンスのみがリクエストを処理します。
アクティブ/パッシブ・トポロジ: 短所
アクティブ/パッシブ・トポロジは、アクティブ/アクティブ・トポロジほどスケーラビリティが高くありません。ノードをトポロジに追加して処理能力を増強することはできません。
HTTPセッションの状態およびEJBステートフル・セッションBeanからの状態情報は、レプリケートされないため、ノードが予期せずに終了すると失われます。そのような状態は、データベースまたは共有記憶域にあるファイル・システムに永続的に保持されます。ただし、これは余分なオーバーヘッドを必要とするため、単一ノードのコールド・フェイルオーバー・クラスタ・デプロイメントのパフォーマンスに影響する可能性があります。
アクティブ/パッシブ・デプロイメントでは、単一ノードのデプロイメントよりも停止時間が短縮されます。ただし、アクティブ/アクティブ・デプロイメントでは、さらに停止時間が短縮されます。
Oracle Fusion Middlewareコンポーネントには、様々な種類の、Java EEコンテナにデプロイされたコンポーネントと非Java EEコンポーネントがあります。Oracle Internet Directory、Oracle Virtual DirectoryおよびOracle Reportsはシステム・コンポーネントです。Oracle SOA SuiteやOracle WebCenter Portalは、Oracle WebLogic ServerにデプロイされるJava EEコンポーネントです。
管理コンソールとOracle Enterprise Manager Fusion Middleware ControlもWebLogicコンテナにデプロイされます。Java EEコンポーネントとシステム・コンポーネントのどちらも、コールド・フェイルオーバー・クラスタ環境にデプロイでき、同じシステム上または異なるシステム上で共存させることができます。同じシステムに配置すると、同じ仮想IPを共有して単一ユニットとしてフェイルオーバーするように構成できますし、別々の仮想IPを使用して個別にフェイルオーバーするようにも構成できます。ほとんどのOracle Fusion Middlewareデプロイメントでは、リポジトリ作成ユーティリティ(RCU)を使用して作成されたコンポーネント・メタデータ用やアプリケーション・データ用にデータベースが使用されます。多くの場合、コールド・フェイルオーバー・クラスタ中間層デプロイメントでは、同じクラスタにデプロイされたコールド・フェイルオーバー・クラスタ・データベースが使用されます。一般的なデプロイメントには、同じハードウェア・クラスタにある異なる共有ディスクと異なるVIPを使用して別々のフェイルオーバー・ユニットとして構成されたコンポーネントが2つあります。
Oracle Fusion Middlewareにおいて、アクティブ/パッシブ・トポロジを作成するには、次の手順を実行します。
単一インスタンス構成としてコンポーネントをインストールします。このインスタンスをコールド・フェイルオーバー・クラスタ・デプロイメントに変換する予定がある場合、共有ディスクを使用してインストールします。つまり、Middlewareホーム、インスタンス・ホーム(システム・コンポーネントの場合)およびドメイン・ディレクトリ(WebLogicデプロイメントの場合)を共有ディスク上に配置します。1つのユニットとしてフェイルオーバーするものはすべて、共有ディスク上に配置する必要があります。
インストール後、デプロイメントをコールド・フェイルオーバー・クラスタ・デプロイメントに変換し、仮想IP上でリスニングするように構成します。この仮想IPは現在のアクティブ・ノード上で構成します。障害が発生すると、Oracle Fusion Middlewareデプロイメントとともにパッシブ・ノードにフェイルオーバーします。
この一般的手順は、コールド・フェイルオーバー・クラスタのOracle Databaseに適用されます。たとえば、Oracle Databaseインスタンスを単一インスタンスのデプロイメントとしてインストールしてから、コールド・フェイルオーバー・クラスタ用に変換します。コールド・フェイルオーバー・クラスタのOracle Fusion Middlewareデプロイメントでは、Oracle Real Application Cluster (Oracle RAC)データベースも使用できます。
次の各項では、インストール後の構成手順について説明します。この手順によって単一インスタンスのデプロイメントをコールド・フェイルオーバー・クラスタ・デプロイメントに変換します。
この章の残りの部分では、Oracle Fusion Middlewareスイートの個別コンポーネントごとに、コールド・フェイルオーバー・クラスタを変換する方法について説明します。最初の項では、基本インフラストラクチャ・コンポーネントの手順について詳細に説明します。そしてその後続の項では、Oracle Fusion Middlewareの個別コンポーネントの手順について詳細に説明します。Oracleインスタンスやドメインなど、あらゆるデプロイメントでは、これらの複数のコンポーネントがマシンにインストールされます。インスタンスやドメインの全体を変換する手順は次のとおりです。
フェイルオーバー・ユニットに組み込むコンポーネントを決定します。
それらを同じ共有ディスク上にデプロイします。
注意: Oracle Fusion Middlewareコンポーネントのインストールとデプロイの詳細は、それぞれのFusion Middlewareコンポーネントのインストレーション・ガイドを参照してください。 |
このフェイルオーバー・ユニットで使用する仮想IPを決定します。通常、すべてのコンポーネントで同じ仮想IPを使用しますが、別々のIPも使用できます。ただし、すべてのコンポーネントをまとめてフェイルオーバーさせます。
個々のコンポーネントごとに変換手順を適用して、デプロイメント全体を変換します。インストールのコールド・フェイルオーバー・クラスタ変換には複数の項の手順が適用されるため、必ず次の順序で変換を実行してください。
管理サーバーまたはEnterprise Managerインスタンス(該当する場合)を変換します。
デプロイメントにあるすべての管理対象サーバーを変換します。
Oracleインスタンス(非Java EEデプロイメント)を変換します。
この項の内容は次のとおりです。
コールド・フェイルオーバー・クラスタのデプロイには、2つ以上のノードを使用します。これらのノードの1つにインストールを行い、もう一方のノードはパッシブ・ノードとなります。両方のノードの要件は、次のとおりです。
各ノードはオペレーティング・システム・レベルのあらゆる面で同じである必要があります。たとえば、オペレーティング・システム、バージョンおよびパッチ・レベルが同一である必要があります。
各ノードはハードウェアの特性が同じである必要があります。それによって、通常の運用中とフェイルオーバー時のパフォーマンスが予測可能になります。通常の役割を処理できる処理能力に加えて、フェイルオーバー・シナリオに対応するために対応が必要な負荷が増大しても処理できるように、各ノードを設計することをお薦めします。停止シナリオ中におけるパフォーマンスの低下がサービス・レベル合意(SLA)で許容される場合のみ、その必要はありません。
通常の運用中とフェイルオーバー時のどちらでも同じノードに対して共有記憶域をマウントできるように、各ノードで同じマウント・ポイントが解放されている必要があります。
2つのノードのユーザーIDとグループIDが類似しており、インスタンスを所有するユーザーのユーザーIDとグループIDが両方のノードで同じである必要があります。
oraInventory
の場所が両方のノードで同じであり、インスタンスまたはドメインの所有者のアクセス・レベルが類似している必要があります。oraInst.loc
ファイルの場所だけでなくbeahomelist
ファイルの場所も同じである必要があります。
指定インスタンスでは、現在アクティブになっているマシンには関係なく、同じリスニング・ポートを使用するため、コールド・フェイルオーバー・クラスタのインスタンスで使用するポートが両方のノードで解放されていることを確認します。
注意: 変換を開始する前に、ドメイン全体のバックアップを実行してください。また、ソース・ファイルの編集前にローカル・バックアップ・ファイルを作成することをお薦めします。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。次のバックアップを作成することをお薦めします。
|
次のリストは、この章で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware (FMW)が常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、特定のOracle FMW Suite (SOAなど)がインストールされている場所を指します。
ORACLE_COMMON_HOME: すべてのOracle Fusion Middlewareソフトウェア・スイートに共通するバイナリおよびライブラリ・ファイルを含むOracleホームです。特に、Oracle共通ホームには、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middlewareの管理に使用される)に必要なファイルとOracle Java Required Files (JRF)が含まれています。
DOMAIN_HOME: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。
ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどのシステム・コンポーネントが1つ以上含まれています。Oracleインスタンス・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルが格納されています。
/localdisk: FMWインストール(MW_HOMEまたはDOMAIN_HOME)がローカル・ディスク上にある場合のディレクトリ・ツリーのルート。それはローカル・ディスクのMW_HOMEを表すために使用されます。
/shareddisk: FMWインストール(MW_HOMEまたはDOMAIN_HOME)がCFC構成のいずれかのノードによってマウントされている共有ストレージ・システム上にある場合に、ディレクトリ・ツリーのルート。それは、共有ディスクのMW_HOMEを表すために使用されます。
これらのディレクトリで一貫性を保つためにこのガイドで使用しておりお薦めする値の例は、次のとおりです。
ORACLE_BASE: /u01/app/oracle
MW_HOME(アプリケーション層): ORACLE_BASE/product/fmw
ORACLE_COMMON_HOME
: MW_HOME/oracle_common
WL_HOME: MW_HOME/wlserver_10.3
次の表は、いくつかのOracle Fusion Middlewareコンポーネントで使用されるOracleホーム、ドメイン・ホーム、およびドメイン・ディレクトリの値の例を示します。
コンポーネント | ORACLE_HOME | DOMAIN_HOME | ドメイン・ディレクトリ |
---|---|---|---|
Identity Management |
MW_HOME/idm |
IDMDomain |
MW_HOME/user_projects/domains/IDMDomain |
Oracle SOA |
MW_HOME/soa |
SOADomain |
MW_HOME/user_projects/domains/SOADomain |
WebCenter |
MW_HOME/wc |
WCDomain |
MW_HOME/user_projects/domains/WCDomain |
WebCenter Content |
MW_HOME/wcc |
WCCDomain |
MW_HOME/user_projects/domains/WCCDomain |
Oracle Portal |
MW_HOME/portal |
PortalDomain |
MW_HOME/user_projects/domains/PortalDomain |
Oracle Forms |
MW_HOME/forms |
FormsDomain |
MW_HOME/user_projects/domains/FormsDomain |
Oracle Reports |
MW_HOME/reports |
ReportsDomain |
MW_HOME/user_projects/domains/ReportsDomain |
Oracle Discoverer |
MW_HOME/disco |
DiscoDomain |
MW_HOME/user_projects/domains/DiscoDomain |
Web層 |
MW_HOME/web |
適用なし |
適用なし |
ディレクトリ層 |
MW_HOME/idm |
適用なし |
適用なし |
アプリケーション・ディレクトリの場所の例: ORACLE_BASE/admin/domain_name/apps
Oracleインスタンスの場所の例: ORACLE_BASE/admin/instance_name
共有記憶域のマウント・ポイントにはORACLE_BASEをお薦めします。多くの場合、この場所に、フェイルオーバー・ユニットのすべての永続ビットが同じ共有記憶域に格納されることになります。1つのノードに複数のコールド・フェイルオーバー・クラスタが存在する場合に、それぞれが独立してフェイルオーバーすると、フェイルオーバー・ユニットのそれぞれに対して異なるマウント・ポイントが存在します。
Oracle Fusion Middlewareデプロイメントは、すべての製品セットに共通する基本インフラストラクチャ・コンポーネントで構成されます。この項では、これらのコンポーネントのコールド・フェイルオーバー・クラスタ変換手順について説明します。
コールド・フェイルオーバー・クラスタ構成では、2つの管理サーバー・トロポジがサポートされています。次の各項では、これら2つのトポロジについて説明します。また、コールド・フェイルオーバー・クラスタ変換用に管理サーバーを準備するためにインストールと構成を行う手順についても説明します。
この項の内容は次のとおりです。
図15-1は、Oracle Cold Failover Clusterにおける最初のサポート対象トポロジを示しています。
図15-1では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。Middlewareホームとドメイン・ディレクトリは、ある時点でノード1またはノード2にマウントされている共有ディスク上にあります。Middlewareホームとドメイン・ディレクトリは両方とも、同じ共有ディスク上、またはいっしょにフェイルオーバーできる複数の共有ディスク上にあります。複数のアプリケーションまたは環境用に複数のFusion Middlewareドメインがある企業では、管理サーバーの高可用性にはこのトポロジが最適です。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。それぞれの管理サーバーでは、その仮想IPおよび一連の共有ディスクを使用して、ドメイン・サービスの高可用性を実現できます。
このトロポジの管理対象サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。
Middlewareホームのインストール
このインストールには、共有ディスク上におけるOracleホーム、WebLogicホームおよびドメイン・ホームが含まれます。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。ストレージ・サブシステムにおいて複数のノードでの同時マウントが可能な場合でも、これが推奨構成になります。これは、通常の単一インスタンス型インストールとして実行されます。管理サーバー(およびEnterprise Manager)の単体インストールの詳細は、当該コンポーネントに関連する章を参照してください。各スイートの全体的な手順は次のとおりです。
管理サーバーのみ:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
構成ウィザードを起動して、管理サーバーのみのドメインを作成します。
「ドメイン・ソースの選択」画面で、次を選択します。
以下の製品をサポートするために、自動的に構成されたドメインを生成する
「Enterprise Manager」と「Oracle JRF」を選択します。
For Oracle SOA、Oracle WebCenter PortalまたはOracle WebCenter Contentの場合:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
Oracle SOA、Oracle WebCenter PortalまたはOracle WebCenter ContentのOracleホームをインストールします。
Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』または『Oracle WebCenter Contentインストレーション・ガイド』を参照してください。
Oracle Identity Managementの場合:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
Oracle Identity Management 11gのインストーラで、ドメイン作成オプションを使用してIDMドメインをインストールおよび構成します。「コンポーネントの構成」画面で、Enterprise Manager(デフォルトで選択されています)以外のすべての選択を解除します。
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
Oracle Portal、Forms、ReportsおよびDiscovererの場合:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
Oracle Fusion Middleware 11g Portal、Forms、ReportsおよびDiscovererのインストーラで、ドメイン作成オプションを使用してクラシック・ドメインをインストールおよび構成します。「コンポーネントの構成」画面で、Enterprise Managerが選択されていることを確認します。
注意: この場合、製品コンポーネント用に1つ以上の管理対象サーバーがこのプロセスでインストールされます(管理サーバー単独のインストールはできません)。この管理対象サーバーは、該当コンポーネントの手順に従ってCFCに変換する必要があります。これは、管理サーバーのユニットと同じフェイルオーバー・ユニットの一部になります。 |
Oracle Business Intelligenceの場合:
WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
Oracle Fusion Middleware 11g Business Intelligenceインストーラで、BIシステムを新規作成するオプションを使用して、Business Intelligenceドメインのインストールと構成を実行します。
注意: この場合、製品コンポーネント用に1つ以上の管理対象サーバーがこのプロセスでインストールされます(管理サーバー単独のインストールはできません)。この管理対象サーバーは、該当コンポーネントの手順に従ってCFCに変換する必要があります。これは、管理サーバーのユニットと同じフェイルオーバー・ユニットの一部になります。 |
コールド・フェイルオーバー・クラスタ用の管理サーバーの構成
コールド・フェイルオーバー・クラスタ用に管理サーバーを構成する手順は次のとおりです。
rootユーザーとして次のコマンドを使用して、仮想IPをプロビジョニングします。
/sbin/ifconfig interface:index IP_Address netmask netmask /sbin/arping -q -U -c 3 -I interface IP_Address
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIP_addressが有効化されます。
/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0 /sbin/arping -q -U -c 3 -I eth0 130.35.46.17
第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
仮想IP上のコンソールにアクセスすることで、管理サーバーの変換を検証します。この仮想IPアドレスは、新規IPアドレスです。この仮想IPアドレスのみを使用することをお薦めします。
http://cfcvip.example.com:7001/console
http://cfcvip.example.com:7001/em
次の手順に従って、管理サーバーを2番目のノードに手動でフェイルオーバーさせます。
注意: 管理サーバーがノード・マネージャによって管理されている場合は、コールド・フェイルオーバー・クラスタのノードマネージャを有効にする必要があります。 |
管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。
Middlewareホームとドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。
記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。
rootユーザーとして次のコマンドを使用して、ノード1で仮想IPを無効化します。
/sbin/ifconfig interface:index down
次の例では、eth0インタフェースで仮想IP_Addressが無効化されます。
/sbin/ifconfig eth0:1 down
ステップ1と同じコマンドを使用して、ノード2で仮想IPを有効化します。
管理サーバー・プロセスを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。
管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。
図15-2は、Oracle Cold Failover Clusterにおける2番目のサポート対象管理サーバー・トポロジを示しています。
図15-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 Portal Suiteに対してのみサポートされています。
注意: Oracle Identity Managementについては、コールド・フェイルオーバー・クラスタのための代替トポロジもサポートされています。詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。 |
このトロポジの管理サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。
Middlewareホームのインストール
OracleホームとWebLogicホームを含むMiddlewareホームを、ドメインにある2つのノードに個別にインストールします。管理サーバー・ドメイン・ディレクトリは共有ディスク上に作成します。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。これは、通常の単一インスタンス型インストールです。管理サーバーおよびEnterprise Managerの単体インストールの詳細は、製品スイートを参照してください。
Oracle SOA Suite、Oracle WebCenter PortalまたはOracle WebCenter ContentのMiddlewareホームをインストールする手順は次のとおりです。
ノード1にOracle WebLogic Serverソフトウェアをインストールします。
ノード1にSOAまたはWebCenterのOracleホームをインストールします。
ノード2でステップ1とステップ2を繰り返します。
ノード1で構成ウィザードを起動して、管理サーバーのみのドメインを作成します。
「ドメイン・ソースの選択」画面で、次を選択します。
以下の製品をサポートするために、自動的に構成されたドメインを生成する
Enterprise ManagerとOracle JRFを選択します。
「ドメイン名と場所の指定」画面で、ドメイン名を入力し、ドメイン・ディレクトリがディレクトリと共有記憶域のマウント・ポイントに一致していることを確認します。
コールド・フェイルオーバー・クラスタ用のMiddlewareホームの構成
コールド・フェイルオーバー・クラスタ用にMiddlewareホームを構成する手順は次のとおりです。
仮想IPをプロビジョニングします。例:
/sbin/ifconfig eth0:1 IP_Address netmask netmask /sbin/arping -q -U -c 3 -I eth0 IP_Address
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIP_Addressが有効化されます。
/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0 /sbin/arping -q -U -c 3 -I eth0 130.35.46.17
第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.example.com:7001/console
http://cfcvip.example.com:7001/em
管理サーバーを2番目のノードに手動でフェイルオーバーさせます。
管理サーバー・プロセス、および指定されているMiddlewareホームの外部で実行されているその他のプロセスを停止します。
Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。
記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。
ノード1で仮想IPを無効化します。
/sbin/ifconfig interface:index down
次の例では、eth0
インタフェースでIP_Addressが無効化されます。
/sbin/ifconfig eth0:1 down
ノード2で仮想IPを有効化します。
次のコマンドを使用して、管理サーバー・プロセスを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。
管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。
共有ディスクにインストールされている管理サーバーをノード1から変換するには、この項の手順に従ってください。この手順ではコンテナを変換するため、管理コンソールとOracle Enterprise Manager Fusion Middleware Controlの両方がコールド・フェイルオーバー・クラスタ用に変換されます。それにより、このコンテナにデプロイされるOWSM-PMなどの他のコンポーネントも、コールド・フェイルオーバー・クラスタ対応になります。これらすべてのサービスのアドレスがcfcvip.example.com
に変換されます。インストール後、コールド・フェイルオーバー・クラスタでないインスタンスをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。
管理コンソールにログインします。
仮想ホストのマシンを作成します。
「環境」、「マシン」の順に選択します。
「チェンジ・センター」で、「ロックして編集」、「新規」の順にクリックします。
「名前」フィールドにcfcvip.example.comと入力します。
「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。
「次」、「終了」の順にクリックします。
注意: 「リスニング・アドレス」フィールドはlocalhostに設定したままにします(CFCソリューションはこの設定に依存します)。これを仮想IP_Addressまたはその他の値に変更しないでください。 |
「マシンのサマリー」タブで、作成したばかりのマシンの名前をクリックします。
「サーバー」タブをクリックしてから、「追加」をクリックします。
サーバー選択のドロップダウン・リストで、「AdminServer」が選択されていることを確認します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。
cfcvip.example.com上でリスニングするように管理サーバーを構成します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
管理サーバー(AdminServer)をクリックします。
リスニング・アドレスをcfcvip.example.comに変更します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理サーバーを再起動します。
注意: 通常、管理サーバーのコールド・フェイルオーバー・クラスタへの変換はドメイン作成時に実行されることが期待されるため、ドメインにおいて他の部分への変更は行われないものと考えられます。この変更がドメイン作成後に行われ、他のコンポーネントがドメインにインストールされている場合、次の管理サーバー変換項で説明している手順に従ってください。 |
管理サーバーのクライアント側構成の変更
ドメインにある既存エンティティでは、管理サーバーとの通信に新しいアドレスを使用する必要があります。たとえば、管理対象サーバーを手動で起動する際は、管理サーバーのアドレスをcfcvip.example.com
として指定します。
ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるinstance.properties
ファイルで、次の変更を行います。
adminHost=cfcvip.example.com
OPMN登録コマンドを使用して、コールド・フェイルオーバー・クラスタ管理サーバーにOracleインスタンスを登録したり再登録する場合は、opmnctlコマンドのAdminHost
の場所で管理サーバーの新しい場所(cfcvip.example.com
)を参照します。
Oracle Enterprise Managerのクライアント側構成の変更
Enterprise Managerは管理サーバーが稼働する同じコンテナの一部であるため、管理サーバーをコールド・フェイルオーバー・クラスタに変換すると、Enterprise Managerも変換されます。ドメインの一部として構成されたEnterprise Managerエージェントが存在する場合は、それらのエージェント構成でEnterprise Managerの新しい場所を使用する必要があります。Enterprise Managerの新しい場所を構成するには、エージェントごとに次の手順を行います。
ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/configに設定します。
emd.properties
ファイルで、次の属性内のnode1.example.com
をcfcvip.example.com
に変更します。
REPOSITORY_URL
emdWalletSrcUrl
次のコマンドを使用して、エージェントを停止してから再起動します。
cd ORACLE_INSTANCE/EMAGENT/emagent_dir/bin
./emctl stop agent
./emctl start agent
./emctl status agent
これによってリポジトリのURLが表示されます。このURLは新しいホストを指します。
すべてのOracle Fusion Middlewareコンポーネントは、管理対象サーバーにデプロイされます。Oracle WebLogic Serverにデプロイされたアプリケーションやコンポーネントをコールド・フェイルオーバー・クラスタに変換する際の重要な手順としては、使用する仮想IPにリスニング・アドレスを変更することがあります。この変更は、対象のコンポーネントがデプロイされている特定の管理対象サーバーに対して実行します。この変更には、管理コンソールまたはWLSTコマンドを使用できます。
次の例では、WLS_EXMPLという管理対象サーバーをコールド・フェイルオーバー・クラスタに変換する一般的手順について説明します。これらの手順は、Fusion Middlewareコンポーネントの管理対象サーバーに適用されます。
この項の内容は次のとおりです。
次の手順で、cfcvip.example.com
はコールド・フェイルオーバー・クラスタに使用する仮想IPで、WLS_EXMPL
は変換対象となる管理対象サーバーです。
管理コンソールにログインします。
仮想ホストのマシンを作成します。
「環境」→「マシン」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックし「新規」をクリックします。
注意: 管理サーバーの変換で別のVIPを使用した場合にのみ、新しいマシンを作成します。その場合、手順gに進みます。 |
「名前」フィールドでは、cfcvip.example.comと入力します。
「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。
「Next」をクリックして、「Finish」をクリックします。
ノード・マネージャを変換する場合は、次の手順を実行する必要があります。
新しく作成したマシンをクリックします。
「ノード・マネージャ」タブをクリックします。
リスニング・アドレスをcfcvip.example.comに更新します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
第15.2.3.7項「ノード・マネージャの変換」の手順を完了します。
WLS_EXMPL管理対象サーバーを停止します。
「環境」→「サーバー」を選択します。
「制御」をクリックします。
「WLS_EXMPL」を選択します。
「停止」ドロップダウン・メニューで、「ただちに強制停止」を選択します。
WLS_EXMPL管理対象サーバーを仮想ホストのマシンに関連付けます。
「環境」→「サーバー」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「構成」をクリックします。
「WLS_EXMPL」を選択します。
「マシン」では、プルダウン・メニューから新規作成マシンを選択して割り当てます。
「リスニング・アドレス」にcfcvip.example.comと入力します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理対象サーバー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://cfcvip.example.com:7001') wls:/DomainName/serverConfig> edit() wls:/DomainName/edit> startEdit() wls:/DomainName/edit !> create('cfcvip.example.com','Machine') wls:/DomainName/edit !> cd('Machines/cfcvip.example.com/NodeManager/cfcvip.example.com') wls:/DomainName/edit !> set('ListenAddress', 'cfcvip.example.com') wls:/DomainName/edit !>cd ('Servers') wls:/DomainName/edit/Servers !>cd ('WLS_EXMPL') wls:/DomainName/edit/Servers/WLS_EXMPL !>set('Machine',' cfcvip.example.com ') wls:/DomainName/edit/Servers/WLS_EXMPL !>set('ListenAddress',' cfcvip.example.com ') wls:/DomainName/edit/Servers/WLS_EXMPL !> save() wls:/DomainName/edit/Servers/WLS_EXMPL !> activate() wls:/DomainName/edit/Servers/WLS_EXMPL> exit()
管理対象サーバーを停止してから(停止していない場合)、再起動します。
管理対象サーバーの変換の完了後に、このサーバーに対するすべての参照で新しいリスニング・アドレスcfcvip.example.com
が使用されていることを確認します。Oracle HTTP Serverがこの管理対象サーバーのフロントエンドとして機能している場合、この管理対象サーバー上のアプリケーションを参照しているマウント・ポイントでmod_wls_ohs構成をすべて変更して、新しいリスニング・エンド・ポイントにルーティングします。
注意:
Oracle FMW SOAサーバーを既存またはデプロイされているコンポジットを使用して変換する場合は、以前のサーバーのリスニング・アドレスが表示される可能性のある場所がいくつかあります。OHSまたはLBRがサーバーのフロントエンドとなる場合、参照は、サーバーのリスニング・アドレスを反映しないため変更されません。
デプロイされたコンポジットには、特定のエンドポイント参照が含まれる場合があります。たとえば、特定の参照用のバインド・プロパティとして指定されたcallbackServerURL
が使用される場合があります。これらの参照は、新しいサーバーのVIPに更新する必要があります。
Enterprise Manager内のsoa-infraアプリケーションに指定されたSOAプロパティのコンポジット・リレー。ServerURL
およびCAllBackURL
がデフォルトのNull値から変更されている場合は、これらを更新する必要があります。
システムはサーバー・レベルで設定されたフロントエンド・アドレスを使用します。したがって、新しいVIPを反映するように更新する必要があります。
コールド・フェイルオーバー・クラスタ環境ではノード・マネージャを使用できます。コールド・フェイルオーバー・クラスタ・スタックの残りの部分とともにフェイルオーバーしないノード・マネージャ。この場合、ノード・マネージャはコールド・フェイルオーバー・クラスタ用に構成されずに、コールド・フェイルオーバー・クラスタの仮想IPだけでなく、マシン上のすべてのIPをリスニングします。また、フェイルオーバー・ノードには、同様に構成されているノード・マネージャが配置され、構成済になっています。WebLogicインスタンスに関連付けられたノードは、ローカル・ホスト上のノード・マネージャと通信します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』を参照してください。
一般的にコールド・フェイルオーバー・クラスタの場合、フェイルオーバー発生時にポートが競合しないように、ポートの使用を計画する必要があります。
ノード・マネージャをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。
ノード・マネージャが実行されている場合は停止します。
ノード・マネージャが最初に起動された後にのみ、nodemanager.properties
ファイルは作成されます。
必要に応じて、ノード・マネージャを再起動します。
WL_HOME
/common/nodemanager/ディレクトリにあるnodemanager.properties
ファイルで、ListenAddress
を仮想IPに設定します。
例:
ListenAddress=cfcvip.example.com
WL_HOME/server/binディレクトリにあるstartNodeManager.sh
ファイルを使用して、ノード・マネージャを再起動します。
注意: WebLogic管理対象サーバーおよび管理サーバーでは、ホスト名の検証は特定のインストールで有効化または無効化できます。検証が有効でノード・マネージャがこれらのインスタンスを管理しているCFCインストールでは、ホスト名の検証の手順の中で仮想IPのcfcvip.example.comの証明書を使用する必要があります。 |
Oracle Process Management and Notification Server (OPMN)は、システム・コンポーネントのプロセス管理に使用され、管理対象サーバー・インスタンスの一部です。
コールド・フェイルオーバー・クラスタ環境にデフォルトのOPMN構成を維持することをお薦めします。OPMNプロセス自体のコールド・フェイルオーバー・クラスタ変換で他に必要な手順はありません。
コールド・フェイルオーバー・クラスタ用にOracleインスタンスを変換する場合で、これが管理サーバーに登録されているときは、これらのファイルで次の変更を行います。
管理サーバー・ドメインのDOMAIN_HOME/opmnディレクトリにあるtopology.xml
ファイルで、このOracleインスタンス(コールド・フェイルオーバー・クラスタ変換の対象)のホスト名エントリをcfcvip.example.com
に変更します。
たとえば、Oracle HTTP Serverインスタンスをコールド・フェイルオーバー・クラスタに変換するには、topology.xml
ファイルで次のように設定します。
<property name="HTTPMachine" value="cfcvip.example.com"/>
インスタンス自体:
<ias-instance id="asinst " instance-home="/11gas3/MW/asinst" host="cfcvip.example.com" port="6701">
ORACLE_INSTANCE/config/OPMN/opmn
ディレクトリのinstance.properties
ファイルで、adminHost=<physical hostname>
をadminHost=<cfcvip.example.com>
に置き換えます。
すべてのOPMNコンポーネントを再起動します。
Oracleインスタンスをコールド・フェイルオーバー・クラスタに変換する場合は、そのOracleインスタンスの一部であるEnterprise Managerエージェントもコールド・フェイルオーバー・クラスタに変換する必要があります。このトピックでは、エージェントおよびサーバーを変換する方法について説明します。
Enterprise Managerエージェントを変換する手順は次のとおりです。
次のコマンドを使用して、Enterprise Managerエージェントを停止します。
cd ORACLE_INSTANCE/EMAGENT/emagent_dir/bin ./emctl stop agent
ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/configに設定します。
マネージドBeanを使用し、それに対する操作を設定して、物理ホスト名を仮想ホスト名に置換します。例: emoms.props:Location=
AdminServer,name
=emoms.properties
,type=
Properties
,Application=em
属性ごとにこの操作を行うには、次の手順を実行します。
Enterprise Manager (http://
cfcvip.example.com:7001/em
)にログインします。
注意: この手順では、仮想ホスト名cfcvip.example.comでリスニングするために、管理サーバーのリスニング・アドレスを変換しているものと仮定します。詳細は、第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。 |
「WebLogicドメイン」を展開します。
ドメイン名を右クリックして、「システムMBeanブラウザ」を選択します。
検索アイコン(双眼鏡)を選択します。enoms.props:Location
を入力して、マネージドBeanを表示します。
「属性」タブを選択します。
「プロパティ」を選択します。ホスト名は、要素のリスト内にあります。例:
+Element_ElementNumber key example.sysman.emSDK.svlt.ConsoleServerName value hostname.example.com:7001_Management_Service +Element_ElementNumber key example.sysman.emSDK.svlt.ConsoleServerHost value hostname.example.com
「操作」タブを選択してから、「SetProperty」リンクを選択します。
キー名と新しい値を入力します。「起動」を選択します。
emd.properties
ファイルで、EMD_URL
属性のnode1.example.com
をcfcvip.example.com
に変更します。
エージェント側のtargets.xml
ファイルを変更します。
cd ORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/emd cp targets.xml targets.xml.org
ホストとoracle_emd
に関連付けられたターゲットのみが含まれるように、targets.xml
を変更します。他のエントリはすべて削除します。例:
<Targets AGENT_TOKEN="ad4e5899e7341bfe8c36ac4459a4d569ddbf03bc">
<Target TYPE="oracle_emd" NAME="cfcvip.example.com:port"/>
<Target TYPE="host" NAME="cfcvip.example.com" DISPLAY_NAME="cfcvip.example.com/>"
</Targets>
エージェントを再起動します。
cd ORACLE_INSTANCE/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.example.com
からcfcvip.example.com
に変更します。
管理サーバーを再起動します。
Web層は、2つの主要コンポーネントであるOracle HTTP ServerとOracle Web Cacheで構成されます。次の2つの項では、Oracle HTTP ServerとOracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する方法について説明します。
Oracle HTTP Serverをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。
ORACLE_INSTANCE/config/OHS/component_name/httpd.confで、次の属性を変更します。
Listen cfcvip.example.com:port #OHS_LISTEN_PORT Listen cfcvip.example.com:port #OHS_PROXY_PORT ServerName cfcvip.example.com
ORACLE_INSTANCE/config/OHS/component_name/admin.confで、次の属性を変更します。
Listen cfcvip.example.com:port #OHS_LISTEN_PORT Listen cfcvip.example.com:port #OHS_ADMINISTRATOR_PORT ServerName cfcvip.example.com
Oracle HTTP Serverを再起動します。
.cd ORACLE_INSTANCE/bin ./opmnctl restartproc process-type=OHS
また、第15.2.4.7項「シングル・サインオンの再登録(必要な場合)」で説明されているシングル・サインオンの登録も実行します。
Oracle HTTP Serverのクライアント
コールド・フェイルオーバー・クラスタに変換したOracle HTTP ServerにOracle Web Cacheインスタンスがルーティングされる場合は、ORACLE_INSTANCE/config/WebCache/component_name/webcache.xmlで次の属性を変更します。
node1.example.comをcfcvip.example.comに変更します(node1.example.comは変換前のOracle HTTP Serverのアドレスです)。
<HOST ID="h1" NAME="cfcvip.example.com" PORT="8888" LOADLIMIT="100" OSSTATE="ON"/> <HOST ID="h2" NAME="cfcvip.example.com" PORT="8890" LOADLIMIT="100" OSSTATE="ON" SSLENABLED="SSL"/>
Oracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。
クラスタの両方のノードにある/etc/hosts
で、物理ホスト名に別名を設定します。
これはノードのIP_Addressの別名です。/etc/hosts
内で設定します。この別名は、wcprfx.example.com
です。たとえば、ノード1では、/etc/hosts
ファイルのエントリはn.n.n.n node1 node1.example.com wcprfx wcprfx.example.comになります。
フェイルオーバー・ノードのノード2では、/etc/hosts
ファイルのエントリはn.n.n.m node2 node2.example.com wcprfx wcprfx.example.comになります。
ORACLE_INSTANCE/config/WebCache/component_name/webcache.xmlで次を実行します。
node1.example.com
をcfcvip.example.com
に変更します(node1.example.comはOracle Web Cacheがインストールされている場所であり、変換前にリスニング対象となるホスト・アドレスです)。
SITE NAME="cfcvip.example.com"
SSLポートと非SSLポートで仮想ホスト名のエントリをcfcvip.example.comに変更します。例:
<HOST SSLENABLED="NONE" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5" PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8888" NAME="cfcvip.example.com" ID="h0"/> <HOST SSLENABLED="SSL" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5" PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8890" NAME="cfcvip.example.com" ID="h3"/> <VIRTUALHOSTMAP PORT="8094" NAME="cfcvip.example.com"> <HOSTREF HOSTID="h3"/> </VIRTUALHOSTMAP> <VIRTUALHOSTMAP PORT="8090" NAME="cfcvip.example.com"> <HOSTREF HOSTID="h0"/> </VIRTUALHOSTMAP>
wcprfx.example.comに基づくように、キャッシュ名エントリを変更します(wcprfx.example.comは、クラスタにあるすべてのノードの/etc/hostsで作成された別名です)。例:
<CACHE WCDEBUGON="NO" CAPACITY="30" VOTES="1" INSTANCENAME="asinst_1" COMPONENTNAME="wc1" ORACLEINSTANCE="ORACLE_INSTANCE" HOSTNAME="wcprfx.example.com" ORACLEHOME="ORACLE_HOME" NAME="wcprfx.example.com-WebCache">
MULTIPORTセクションで、次の構成のIPADDRをANYからcfcvip.example.comに変更します。
PORTTYPE="NORM" SSLENABLED="SSL" PORTTYPE="NORM" PORTTYPE="ADMINISTRATION" PORTTYPE="INVALIDATION" PORTTYPE="STATISTICS"
例:
<MULTIPORT>
<LISTEN PORTTYPE="NORM" PORT="8090"
IPADDR="cfcvip.example.com"/>
<LISTEN SSLENABLED="SSL" PORTTYPE="NORM" PORT="8094"
IPADDR="cfcvip.example.com">
<WALLET>ORACLE_INSTANCE/config/WebCache/wc1/keystores/
default</WALLET>
</LISTEN>
<LISTEN PORTTYPE="ADMINISTRATION" PORT="8091"
IPADDR="cfcvip.example.com"/>
<LISTEN PORTTYPE="INVALIDATION" PORT="8093" IPADDR="
cfcvip.example.com"/>
<LISTEN PORTTYPE="STATISTICS" PORT="8092"
IPADDR="cfcvip.example.com"/>
</MULTIPORT>
Oracle Web Cacheを再起動します。
cd ORACLE_INSTANCE/bin
./opmnctl restartproc process-type=WebCache
この項では、次のFusion Middlewareコンポーネントについて説明します。
第15.2.4.2項「Oracle Directory Integration PlatformおよびOracle Directory Services Managerとそれぞれのクライアントの変換」
製品コンポーネントの詳細は、このガイドで適切なコンポーネントに関連する章を参照してください。
この項では、Oracle Virtual Directoryとそのクライアントを変換する方法について説明します。次の項目が含まれます。
Oracle Virtual Directoryサーバーを変換する手順は次のとおりです。
テキスト・エディタで、ORACLE_INSTANCE/config/OVD/componentnameディレクトリにあるlisteners.os_xml
ファイルを開きます。
次の値を入力し、LDAPアドレスを仮想IPに設定します。
<host>cfcvip.example.com</host>
opmnctlを使用して、Oracle Virtual Directoryサーバーを再起動します。
例:
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1 ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1
管理者は、(自己署名またはCAによって署名された)仮想ホスト名を使用して新規鍵ペアを生成し、この証明書をOVDリスナー構成で関連付ける必要があります。この証明書は、EMAgentによって信頼される必要があり、これに対して信頼できる証明書としてEMAgentのcwallet.sso
にインポートする必要があります。
詳細は、第8.3.5.2項「WLSTを使用したキーストアの新しい鍵の生成」を参照してください。
管理ゲートウェイ・リスナーまたはLDAP SSLエンドポイント・リスナーで異なるキーストアを選択するか、キーストアの証明書を変更する場合は、Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに証明書をインポートする必要があります。証明書をインポートしない場合、Oracle Enterprise Manager Fusion Middleware ControlはOracle Virtual Directoryに接続してパフォーマンス・メトリックを取得することができません。
Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに証明書をインポートする手順:
次のコマンドを実行して、Oracle Virtual Directoryサーバーの証明書をエクスポートします。
ORACLE_HOME/jdk/jre/bin/keytool -exportcert \ -keystore OVD_KEYSTORE_FILE -storepass PASSWORD \ -alias OVD_SERVER_CERT_ALIAS -rfc \ -file OVD_SERVER_CERT_FILE
次のコマンドを実行して、Oracle Virtual Directoryサーバーの証明書を、Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに追加します。
ORACLE_COMMON_HOME/bin/orapki wallet add -wallet \ $ORACLE_INSTANCE/EMAGENT/EMAGENT/sysman/config/monwallet \ -trusted_cert -cert OVD_SERVER_CERT_FILE -pwd WALLET_PASSWORD
Oracle Virtual Directoryのすべてのクライアントは、仮想IPのcfcvip.example.com
を使用して、Oracle Virtual Directoryにアクセスする必要があります。たとえば、Oracle Directory Services Managerを使用してコールド・フェイルオーバー・クラスタのOracle Virtual Directoryインスタンスを管理する場合は、Oracle Virtual Directoryインスタンスの場所としてcfcvip.example.com
を使用して接続を作成します。
この項では、Oracle Directory Integration Platform、Oracle Directory Services Managerおよびそれぞれのクライアントを変換する方法について説明します。
Oracle Directory Integration PlatformとOracle Directory Services Managerは管理対象サーバーにデプロイされます。CFC変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.example.com
の仮想IP上でリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_ODS管理対象サーバーを、cfcvip.example.com
の仮想IP上でリスニングするように構成してください。
次の手順に従って、Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントを変換します。
Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントは、仮想IPのcfcvip.example.com
を使用してこれらのアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Directory Services Managerのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_ODS管理対象サーバーのアドレスとして仮想IPのcfcvip.example.com
を指定する必要があります。そのためには、Oracle HTTP ServerおよびOracle Directory Services Managerで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.conf
ファイルを次のように編集します。
#Oracle Directory Services Manager
<Location /odsm>
SetHandler weblogic-handler
WebLogicHost cfcvip.example.com
WebLogic port
</Location>
この項では、Oracle Identity Federationとそのクライアントを変換する方法について説明します。
Oracle Identity Federationは、管理サーバーにデプロイされるコンポーネントです。コールド・フェイルオーバー・クラスタ変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.example.com
の仮想IP上でリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OIF管理対象サーバーを、cfcvip.example.com
の仮想IP上でリスニングするように構成してください。Oracle Identity Federationコールド・フェイルオーバー・クラスタ・デプロイメントは通常、サービス・プロバイダとアイデンティティ・プロバイダに分割されるため、特定のデプロイメントに複数のWLS_OIFインスタンスが存在する場合があります。どちらのWLS_OIFインスタンスに対しても、同じコールド・フェイルオーバー・クラスタ手順を適用してください。
cfcvip.example.com
の仮想IP上でリスニングするように管理対象サーバーを構成した後、Oracle Enterprise Manager Fusion Middleware Controlにログインして、次の手順を実行します。
「ファーム」→「Identity and Access」→OIFに移動します。
右側のフレームで、「Oracle Identity Federation」→「管理」に移動し、次の変更を行います。
サーバー・プロパティ: ホストをcfcvip.example.com
に変更します。
「アイデンティティ・プロバイダ」→「共通」: providerIdをcfcvip.example.com
に変更します。
「サービス・プロバイダ」→「共通」: providerIdをcfcvip.example.com
に変更します。
データ・ストア: データ・ストアがLDAPの場合は、ユーザー・データ・ストアとフェデレーション・データ・ストアの接続URLの値をcfcvip.example.com
に置き換えます。
「認証エンジン」→「LDAPディレクトリ」: ConnectionURLをcfcvip.example.com
に設定します。
メタデータを生成するため、管理対象サーバーを再起動します。
次の手順に従って、Oracle Identity Federationクライアントを変換します。
Oracle Identity Federationクライアントは、仮想IPのcfcvip.example.com
を使用してこのアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Identity Federationのフロントエンドである場合、Oracle Identity FederationのWebLogic構成で、WLS_OIF管理対象サーバーのアドレスとして仮想IP cfcvip.example.com
を指定する必要があります。そのためには、Oracle HTTP ServerおよびOracle Identity Federationで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、oif.conf
ファイルを次のように編集します。
#Oracle Identity Federation
<Location /oif>
SetHandler weblogic-handler
WebLogicHost cfcvip.example.com
WebLogic port
</Location>
この項では、Oracle Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定すること、および管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.example.com
)に指定することによって設定可能です。この場合、明確な変換手順は不要です。
Oracle Access Managerは管理対象サーバー(WLS_OAM1
など)にデプロイされ、CFC変換を行うためには、この管理対象サーバーを、仮想IPのcfcvip.example.comでリスニングするように構成します。第15.2.3.6,項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OAM1管理対象サーバーを、cfcvip.example.com
の仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第15.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。
Oracle Access Managerコンソールは、ドメインの管理サーバーの一部としてデプロイされます。このコンソールのコールド・フェイルオーバー・クラスタ構成では、管理サーバー全体をアクティブ/パッシブで構成する必要があります。管理サーバーは、同じ仮想IPのcfcvip.example.com
を共有することも、個別の仮想IPと共有ディスクを使用して独立してフェイルオーバーするように構成することもできます。同じ仮想IPを使用している場合、管理サーバーとOracle Access Manager管理対象サーバーは1つのユニットとしてフェイルオーバーします。
次の手順に従って、Oracle Access Managerクライアントを変換します。
Oracle Access Managerクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Identity ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.example.comを使用してアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Access Managerのフロントエンドである場合、Oracle Access Managerに関するmod_weblogic構成では、Oracle Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.example.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.conf
ファイルを次のように編集します。
#Oracle Access Manager <Location /oam> SetHandler weblogic-handler WebLogicHost cfcvip.example.com:port </Location>
Oracle管理サーバーの一部としてOracle Access Managerコンソールもアクティブ/パッシブに構成し、Oracle HTTP Serverがその管理サーバーのフロントエンドに配置されるように構成する場合、Webサーバー・プロキシ・プラグイン構成ファイルのWebLogicホスト構成を変更する必要があります。たとえば、テキスト・エディタを使用して、mod_wl_ohs.conf
ファイルを次のように編集します。
#Oracle Access Manager Admin Console deployed to the Admin Server <Location /oamconsole> SetHandler weblogic-handler WebLogicHost ADMINVHN WebLogicPort 7001 </Location>
この項では、Oracle Adaptive Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.example.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。
Oracle Adaptive Access Managerは管理対象サーバーにデプロイされます。両方とも単一のユニットとしてフェイルオーバーするようにデプロイされ、そのために同じ仮想IPと同じ共有記憶域を共有します。OAAM Admin管理対象サーバーおよびOAAM Server管理対象サーバーをCFC変換のために変換するには、これらの管理対象サーバーを、仮想IPのcfcvip.example.comでリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第15.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。
次の手順に従って、Oracle Adaptive Access Managerクライアントを変換します。
Oracle Adaptive Access Managerクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Identity Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.example.comを使用してアプリケーションにアクセスする必要があります。
Oracle HTTP ServerがOracle Adaptive Access Managerのフロントエンドである場合、Oracle Adaptive Access Managerに関するmod_weblogic構成では、Oracle Adaptive Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.example.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.conf
ファイルを次のように編集します。
#Oracle Adaptive Access Manager <Location /oaam_server> SetHandler weblogic-handler WebLogicHost cfcvip.example.com WebLogicPort port </Location> #Oracle Adaptive Access Manager Admin Console <Location /oaam_admin> SetHandler weblogic-handler WebLogicHost cfcvip.example.com:port </Location>
この項では、Oracle Identity Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。
構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.example.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。
Oracle Identity Managerは、管理対象サーバーにデプロイされます。一般的なCFCデプロイメントでは、Oracle Identity Manager管理対象サーバーと、Oracle SOAおよびOracle Web Services Managerを含む別の管理対象サーバーは1つのユニットとしてフェイルオーバーするようにデプロイされ、そのために同じ仮想IPと同じ共有記憶域を共有します。この両方の管理対象サーバーをCFC変換のために変換するには、これらの管理対象サーバーを、仮想IPのcfcvip.example.comでリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第15.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。
次の手順に従って、Oracle Identity Managerクライアントを変換します。
Oracle Identity Managerクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.example.comを使用してアプリケーションにアクセスする必要があります。SOAもOracle Identity Managerでフェイルオーバーするように構成されているので、Oracle Identity ManagerからSOAへの接続でも共通の仮想IPを使用する必要があります。
Oracle HTTP ServerがOracle Identity Managerのフロントエンドである場合、Oracle Identity Managerに関するmod_weblogic構成では、管理対象サーバーのアドレスとして仮想IPのcfcvip.example.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.conf
ファイルまたはoim.conf
ファイルを次のように編集します。
#Oracle Identity Manager <Location /oim> SetHandler weblogic-handler WebLogicHost cfcvip.example.com:port WebLogicPort port </Location>
Oracle Identity Managerでの構成変更の詳細は、Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドを参照してください。
シングル・サインオン(SSO)の再登録は通常、Oracle Portal、Forms、ReportsおよびDiscovererにのみ適用されます。この層のOracle HTTP Server上のフロントエンド・リスニング・エンドポイントが仮想IPに変更された後で、保護されるURLを仮想IPによって構成するために、SSOの再登録が必要になります。
注意: 11gでは、再登録ではなく新しいVIPを使用してWebGateを作成する必要があります。 |
SSOを再登録するには、SSOサーバーが配置されているIdentity Management 10.1.xインストールに対して次の手順を実行します。
ORACLE_HOME変数をSSOのORACLE_HOMEの場所に設定します。
次のパラメータを指定して、ORACLE_HOME/sso/bin/ssoreg.sh
を実行します。
-site_name cfcvip.example.com:port -mod_osso_url http://cfcvip.example.com -config_mod_osso TRUE -oracle_home_path ORACLE_HOME -config_file /tmp/osso.conf -admin_info cn=orcladmin -virtualhost -remote_midtier
次に示す中間層ホームの場所に/tmp/osso.conf
ファイルをコピーします。
ORACLE_INSTANCE/config/OHS/ohs1
次のコマンドをORACLE_INSTANCE/binディレクトリから実行して、Oracle HTTP Serverを再起動します。
./opmnctl restartproc process-type=OHS
次のURLでSSOサーバーにログインします。
http://sso.example.com/pls/orasso
「管理」ページの「パートナ・アプリケーション管理」で、node1.example.comのエントリを削除します。
コールド・フェイルオーバー・クラスタ環境では、フェイルオーバー・ノード(node2.example.com)をすべての面でインストール・マシン(node1.example.com)と同じにする必要があります。フェイルオーバー・ノードをインストール・ノードと同じにするには、フェイルオーバー・インスタンスで次の手順を実行します。
UNIXプラットフォームでの手順は次のとおりです。
前述のマウントおよびアンマウントの手順に従って、ノード1(インストール・ノード)からフェイルオーバー・ノード(ノード2)へMiddlewareホームをフェイルオーバーさせます。
rootとして、次の操作を行います。
ノード1にあるものと同一のoraInst.loc
ファイルを/etc
ディレクトリに作成します。
ORACLE_HOME
ディレクトリにあるroot.shファイルをノード2で実行します(これは、製品スイートで利用可能な場合や必要に応じて実行します)。
ORACLE_HOME/oui/bin/attachHome.sh
ディレクトリにあるattachHome
コマンドを使用して、oraInventory
を2番目のノードで作成します。
Oracle Fusion Middlewareの一般的コールド・フェイルオーバー・クラスタ・デプロイメントでは、データベースもコールド・フェイルオーバー・クラスタとしてデプロイされます。この項では、単一インスタンスのOracle Databaseをコールド・フェイルオーバー・クラスタ・データベースに変換する方法について説明します。まず、この変換を実行してから、RCUを使用してデータベースをシードします。その後で、このシード済データベースを使用してFusion Middlewareをインストールします。
データベースをコールド・フェイルオーバー・クラスタ用に有効化する手順は次のとおりです。
データベース・インスタンスによって使用されるリスナー構成をlistener.ora
ファイルで変更します。
リスナー構成のホスト名では値として仮想ホスト名が指定されていることを確認します。さらに、リスナー・ポートを使用している他のプロセス(Oracleまたはサード・パーティ)が存在しないことも確認します。
<listener_name> = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = <virtual_hostname>)(PORT = port)) ) )
例:
LISTENER_CFCDB = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST cfcdbhost.example.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.example.com)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = cfcdb) (INSTANCE_NAME = cfcdb) ) )
ローカルのspファイルを変更して、インスタンスのlocal_listenerパラメータを更新します。
SQL*Plusを使用して、sysdbaとしてログインします。
SQL> alter system set local_listener='<tns_alias_name>' scope=both;
)
例:
SQL> alter system set local_listener='CFCDB' scope=both;
リスナーを停止してから再起動します。
データベース・インスタンスを停止してから再起動します。
アプリケーション・サーバーのデータベース・サービスを作成します。
デフォルト・データベース・サービスとは別の、専用のサービスをお薦めします。このサービスを作成するには、次のSQL*Plusコマンドを実行します。
SQL> execute DBMS_SERVICE.CREATE_SERVICE ('<cfc_db_service_name>','<cfc_db_network_name>')
例:
SQL> execute DBMS_SERVICE.CREATE_SERVICE ('cfcdb_asservice','cfcdb_asservice')
このサービスを開始するには、次のSQL*PLUSコマンドを実行します。
SQL> execute DBMS_SERVICE.START_SERVICE ('cfcdb_asservice')
インストールの必要性に応じて、このサービスに追加パラメータを設定することもできます。DBMS_SERVICEコマンドの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
Unixプラットフォームのデータベース・インスタンスについて次の手順を検討してください。
前述のマウントおよびアンマウントの手順に従って、ノード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番目のノードで作成します。
この項では、コールド・フェイルオーバー・クラスタのトポロジ例について説明します。トポロジでは様々な組合せが考えられるため、ここで示すトポロジは例にすぎません。これらのトポロジを実現するには、複数の変換手順が適用されます。変換を構成する方法の詳細は、前述の各手順を参照してください。
この項の内容は次のとおりです。
図15-3は、Oracle WebCenter Portalのコールド・フェイルオーバー・クラスタ・デプロイメントを示しています。ドメイン内には管理サーバーとWebCenter管理対象サーバーの両方があり、1つのユニットとしてフェイルオーバーします。したがって、これらは同じ仮想IPを共有し、同じ共有ディスク上にまとめてインストールされています。このトポロジのフロントエンドとしてOracle HTTP Serverも使用できます。このトポロジ例では、別のノードに配置されています。同じノードに配置して、コールド・フェイルオーバー・クラスタ・デプロイメントの一部とすることも可能です。この例では、データベースも別のノードに配置されています。しかし、データベースも同様に、同じクラスタ上に配置して、コールド・フェイルオーバー・クラスタベースにする場合もあります(仮想IPと共有ディスクは専用のものを使用)。
図15-4は、SOAコールド・フェイルオーバー・クラスタ・デプロイメント例を示しています。この例では、SOAインスタンスのみがコールド・フェイルオーバー・クラスタとしてデプロイされ、管理サーバーは別のノードに配置されています。このトポロジ例では、データベースも別のノードに配置されています。この例では、Oracle HTTP Serverはコールド・フェイルオーバー・クラスタ・デプロイメントの一部であり、SOA管理対象サーバーと同じフェイルオーバー・ユニットの一部になります。このトポロジの重要なバリエーションの1つは、同じハードウェア・クラスタにコールド・フェイルオーバー・クラスタ管理サーバーを組み込むことです。この場合、仮想IPと共有ディスクをSOA管理対象サーバーと共有するか(管理サーバーをSOAと同じフェイルオーバー・ユニットに組み込む)、別の仮想IPと共有ディスクを使用(管理サーバーを別個にフェイルオーバーさせる)できます。同様に、マシンの処理能力に応じて、データベース・インスタンスも同じハードウェア・クラスタに配置できます。
図15-5は、Oracle Identity Managementデプロイメントを示しています。このトポロジ例では、すべてのコンポーネントが、2つのノードのハードウェア・クラスタに配置されています。Identity Managementは1つのユニットとしてフェイルオーバーし、Java EEコンポーネント(管理サーバーとWLS_ods管理対象サーバー)とシステム・コンポーネントの両方が、同じフェイルオーバー・ユニットの一部となっています。これらは同じ仮想IP (cfcvip1.example.com)と共有ディスクを使用しています。データベースも同じハードウェア・クラスタに配置されています。異なる仮想IP cfcvip2.example.com
と、異なる共有ディスク・セットを使用しています。通常の運用中では、データベースはノード2で実行し、IDMスタックはノード1で実行します。それぞれのノードは互いにバックアップ・ノードとして機能します。
このトポロジは、ほとんどのコールド・フェイルオーバー・クラスタ・デプロイメントの推奨トポロジです。例ではIdentity Managementを使用していますが、Oracle SOA、Oracle WebCenter Portal、Oracle Portal、Forms、ReportsおよびDiscovererスイートにも有効です。推奨アーキテクチャでは、Oracle Fusion Middlewareはハードウェア・クラスタの1つのノードとして実行します。別のノードではOracle Databaseを実行します。各ノードは互いにバックアップ・ノードになります。Oracle Fusion Middlewareインスタンスとデータベース・インスタンスは、異なる共有ディスクと異なるVIPを使用し、互いに独立してフェイルオーバーします。また、このアーキテクチャでは、ハードウェア・クラスタ・リソースの使用率が最適化されます。
この項では、既存のドメインの管理サーバーをコールド・フェイルオーバー・クラスタに変換する手順について説明します。
注意: 管理サーバーの変換後、第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」で述べられているように、管理サーバーおよびEnterprise Managerのクライアント側の変更が必要になる場合があります。 |
前提事項
この項の手順は、次を前提としています。
すべてのFusion Middlewareコンポーネントは、nostageデプロイメントに配置されています。
起動トポロジが製品スイートのアクティブ/アクティブ・クラスタです(ノード1およびノード2)。
開始する管理サーバーはノード1です。
ノード1の管理対象サーバーと同じドメイン・ホームを共有しています。
MW_HOMEパスがノード1とノード2で同じです。
これらの手順は、前提が満たされていれば、Oracle WebLogicクラスタ・インストールにデプロイされているカスタマ・アプリケーションにも適用されます。
開始トポロジ
図15-6は、管理サーバーを変換する前の開始トポロジの例を示しています。
図15-7に、コールド・フェイルオーバー・クラスタ用に管理サーバーを変換した後の可能なトポロジを示します。このトポロジは、次のような特性を持ちます。
管理サーバー・ドメイン・ホームは、ノード1とノード2の両方でマウント可能な共有ディスクに移動しますが、任意の時点では片方のみがマウントされます。
引き続き、ノード1とノード2からアクセスできる元のMiddlewareホームが使用されます。
管理サーバーのリスニング・アドレスは、仮想IPになります。
既存のドメインで管理サーバーを変換するには、次の手順を実行します。
コンポーネントの管理対象サーバーおよび管理サーバーのクラスタをシャットダウンします。
各ノードでノード・マネージャ・プロセスが稼働していれば、それをシャットダウンします。
ドメイン全体をバックアップします。
ノード1で仮想IPをプロビジョニングします。例:
/sbin/ifconfig eth0:1 IP_Address netmask netmask /sbin/arping -q -U -c 3 -I eth0 IP_Address
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。
次の例では、Local Area Connection
のインタフェースでIP_Addressが有効化されます。
/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0
/sbin/arping -q -U -c 3 -I eth0 IP_Address
ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。
次の例では、Local Area Connection
のインタフェースでIP_Addressが有効化されます。
netsh interface ip add address "Local Area connection" IP_Address netmask
ローカルのドメイン・ホームから管理サーバーを起動します。
cd DOMAIN_HOME/bin
./startWeblogic.sh
管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
管理コンソールにログインします。
仮想ホストのマシンを作成します。
「環境」、「マシン」の順に選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。「新規」をクリックします。
「名前」フィールドにcfcvip.example.comと入力します。
注意: 「リスニング・アドレス」フィールドはlocalhostに設定したままにします(CFCソリューションはこの設定に依存します)。これを仮想IP_Addressまたはその他の値に変更しないでください。 |
管理サーバーには、ローカルだけでなく複数のノード・マネージャと対話できるように新しい仮想ホスト・マシンが必要です。各ホストの各ノード・マネージャは、実際のIPおよびローカル・ホスト(127.0.0.1)の両方のすべてのインタフェースでリスニングします。管理サーバーは、新しい仮想ホスト・マシン定義を排他的に使用します。
localhostはすべてのアクティブなマシンの相対内部アドレスであり、管理サーバーに固定されるため、仮想ホスト・マシンはlocalhostを指す必要があります。管理サーバーをあるホストから別のホストに変更しても、同じ仮想名およびVIPが保持されます。管理サーバーはlocalhost属性と1つ目のノードを組み合せて使用し、フェイルオーバー後は2つ目のノードも使用するため、管理サーバーと関連付けられているノード・マネージャも変更されます。図xを参照してください。
適切なオペレーティング・システムを選択して、「OK」をクリックします。
作成したマシンを選択します。
「サーバー」タブをクリックしてから、「追加」をクリックします。
既存のサーバーを選択して、このマシンに関連付けます。
「サーバーの選択」ドロップダウン・リストで、「AdminServer」が選択されていることを確認します。
「終了」→「変更のアクティブ化」をクリックします。
cfcvip.example.com上でリスニングするように管理サーバーを構成します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
管理サーバー(AdminServer)をクリックします。
「リスニング・アドレス」をcfcvip.example.comに変更し、「保存」をクリックします。
管理コンソールから管理サーバーを停止します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」をクリックします。
その横にあるチェック・ボックスをクリックして、「Adminserver」を選択します。
「停止」プルダウン・メニューで、「ただちに強制停止」を選択して、管理サーバーをシャットダウンします。
「はい」をクリックします。
コマンド行から、システムでVIPが有効で、管理サーバーが起動していることを確認します。
cd DOMAIN_HOME/bin
./startWeblogic.sh
仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.example.com:7001/console
http://cfcvip.example.com:7001/em
管理コンソールを使用して、ノード1の管理サーバーシャットダウンします。
ノード1で共有ディスクがプロビジョニングおよびマウントされていることを確認します。
ノード1でドメイン全体をパックします。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=false -domain=/localdisk/user_projects/domains/domain_name -template=cfcdomaintemplate_all.jar -template_name=cfc_domain_template_all
それを共有ディスク上に解凍します。
./unpack.sh -domain=/shareddisk/user_projects/domains/domain_name
-template=cfcdomaintemplate_all.jar
-app_dir=/shareddisk/user_projects/apps -server_start_mode=prod
製品スイート固有の変更:
Oracle Identity Management製品スイート:
config.xml
ファイルをバックアップします。この例では、/shareddisk/user_projects/domains/
domain_name/config/
ディレクトリにあります。
WCCソケット・ホスト・フィルタを次のファイル内のVIPに変更します。
{domain}/ucm/ibr/config/config.cfg
{domain}/ucm/urm/config/config.cfg
{domain}/ucm/cs/config/config.cfg
config.xml
ファイルを編集してソースパスに次の変更を行います。この例では、/shareddisk/user_projects/domains/
domain_name/config
にあります。
dipapp
で、ソースパスをORACLE_HOME/ldap/odi/dipapp/dipapps.ear
に変更します。
例:
<app-deployment> <name>DIP#11.1.1.2.0</name> <target>cluster_ods</target> <module-type>ear</module-type> <source-path>ORACLE_HOME/ldap/odi/dipapp/dipapps.ear</source_path> <security-dd-model>DDOnly</security-dd-model> <staging-mode>nostage</staging-mode> </app-deployment>
ODSMアプリケーションで、ソースパスをORACLE_HOME/ldap/odsm/odsm.ear
に変更します。
例:
<app-deployment> <name>odsm#11.1.1.2.0</name> <target>cluster_ods</target> <module-type>ear</module-type> <source-path>ORACLE_HOME/ldap/odsm/odsm.ear</source-path> <security-dd-model>DDOnly</security-dd-model> <staging-mode>nostage</staging-mode> </app-deployment>
OIF:
次のようにして、OIF-APP
のソースパスを ORACLE_HOME/fed/install/oif.ear
に変更します。
<app-deployment> <name>OIF#11.1.1.2.0</name> <target>cluster_oif</target> <module-type>ear</module-type> <source-path>ORACLE_HOME/fed/install/oif.ear</source-path> <security-dd-model>Advanced</security-dd-model> <staging-mode>nostage</staging-mode> </app-deployment>
oif-libsのソースパスをORACLE_HOME/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.ear
に変更します。
<library> <name>oif-libs#11.1.1.2.0@11.1.1.2.0</name> <target>cluster_oif</target> <module-type>ear</module-type> <source-path>ORACLE_HOME/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.ear</source-path> <security-dd-model>DDOnly</security-dd-model> </library>
管理サーバーを起動します。
cd /shareddisk/user_projects/domains/domain_name/bin
./startWeblogic.sh
仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.example.com:7001/console
http://cfcvip.example.com:7001/em
管理サーバーをシャットダウンします。
ノード1で次を実行します。
mv /localdisk/user_projects/domains/domain_name /localdisk/user_projects/domains/domain_name_old mv /localdisk/user_projects/applications/domain_name /localdisk/user_projects/applications/domain_name_old cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=/shareddisk/user_projects/domains/domain_name -template=cfcdomaintemplate_mngd.jar -template_name=cfc_domain_template_mngd ./unpack.sh -domain=/localdisk/user_projects/domains/domain_name -template=cfcdomaintemplate_mngd.jar
注意: これらのコマンドでは、アプリケーション・ディレクトリが |
テンプレートをノード2にコピーします。
scp ORACLE_COMMON_HOME/common/bin/cfcdomaintemplate_mngd.jar Node2:ORACLE_COMMON_HOME/common/bin
ノード2にログインして、ノード2上で解凍します。
mv /localdisk/user_projects/domains/domain_name /localdisk/user_projects/domains/domain_name_old mv /localdisk/user_projects/applications/domain_name /localdisk/user_projects/applications/domain_name_old cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=/localdisk/user_projects/domains/domain_name -template=cfcdomaintemplate_mngd.jar
注意: これらのコマンドでは、アプリケーション・ディレクトリが |
Oracle Identity Manager Suiteでは、次の追加手順が必要です。
DIPの場合:
ノード1で、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/user_projects/domains/domain_name/bin
./startWeblogic.sh
ノード1およびノード2でノード・マネージャが使用されている場合、それを起動します。
cd WL_HOME/server/bin
./startNodeManager.sh
管理サーバー・コンソール(ノード・マネージャが使用されている場合)またはコマンド行からノード1およびノード2上のコンポーネントの管理対象サーバーを起動します。
コンポーネント固有の機能テストを使用してデプロイメントを検証します。
管理サーバーのフェイルオーバーをテストします。
管理サーバーを2番目のノードに手動でフェイルオーバーさせます。
管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。
Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。
記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。
ノード1で仮想IPを無効化します。
ifconfig interface:index down
次の例では、eth0インタフェースでIP_Addressが無効化されます。
ifconfig eth0:1 down
netsh interface ip delete address interface addr=IP_Address
この場合、IP_Address
は仮想IP_Addressです。
次の例では、IP_AddressはインタフェースLocal Area Connection
上で有効になります。
netsh interface ip delete address 'Local Area connection' addr=130.35.46.17
ノード2で仮想IPを有効化します。
次のコマンドを使用して、管理サーバー・プロセスを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。
管理サーバーとOracle Enterprise Manager管理コンソールの両方へのアクセスを検証します。
コンポーネント固有のテストで検証します。
検証後、管理サーバーが通常に稼働し、通常に処理を実行するノード(ノード1またはノード2)にフェイルバックします。