10 Oracle Identity Governanceコンポーネントの高可用性の構成
この章では、Oracle Identity Governanceの高可用性環境を設計およびデプロイする方法について説明します。
Oracle Identity Governance (OIG)は、アプリケーションおよびディレクトリからユーザー・アカウントを追加、更新および削除するプロセスを自動化するユーザー・プロビジョニングおよび管理ソリューションです。また、誰が何にアクセスしたかを示すきめ細かいレポートを提供することで、法規制コンプライアンスの向上にも寄与します。OIGは、スタンドアロン製品として、またはOracle Identity and Access Management Suiteの一部として使用可能です。
OIGの詳細については、『Oracle Fusion Middleware Oracle Identity Governanceの管理』のOracle Identity Governanceの製品の概要に関する項を参照してください。
注意:
ドキュメント内のOracle Identity GovernanceおよびOracle Identity Managerの製品名のリファレンスは同じものを意味します。- Oracle Identity Governanceのアーキテクチャ
Oracle Identity Governanceのアーキテクチャは、そのコンポーネント、ランタイム・プロセス、プロセス・ライフサイクル、構成アーティファクト、外部依存性、およびログ・ファイルからなります。 - Oracle Identity Governanceの高可用性の概念
Oracle Identity Governanceの高可用性に関連する概念は、OIG高可用性アーキテクチャ、OIGクラスタの起動と停止、およびクラスタワイドの構成変更です。 - 高可用性のディレクトリ構造の前提条件
高可用性デプロイメントでは、製品インストールとファイルが特定のディレクトリに存在する必要があります。標準のディレクトリ構造を用いることで、ノード全体の構成および製品の統合が容易になります。 - Oracle Identity Governanceの高可用性の構成ステップ
Oracle Identity Governanceの高可用性の構成には、前提条件の設定、ドメインの構成、インストール後のステップ、サーバーの起動、SOA統合、管理対象サーバー・インスタンスの検証、Oracle Identity Governanceのスケール・アップおよびスケール・アウトが含まれます。
親トピック: コンポーネントの手順
Oracle Identity Governanceのアーキテクチャ
Oracle Identity Governanceのアーキテクチャは、そのコンポーネント、ランタイム・プロセス、プロセス・ライフサイクル、構成アーティファクト、外部依存性、およびログ・ファイルからなります。
図10-1は、Oracle Identity Governanceのアーキテクチャを示しています。
Oracle Identity Governanceコンポーネントの特性
Oracle Identity Manager Serverは、スタンドアロンの自己完結型アイデンティティ管理ソリューションです。ユーザー管理、ワークフローおよびポリシー、パスワード管理、監査およびコンプライアンス管理、ユーザー・プロビジョニング、および組織およびロール管理機能を提供します。
Oracle Identity Manager (OIM)は、標準Java EEアプリケーションであり、WebLogic Server上にデプロイされ、データベースを使用してランタイムおよび構成データを格納します。MDSスキーマには構成情報が含まれ、OIMスキーマにはランタイムおよびユーザー情報が格納されます。
OIMは、RMIを使用してSOA管理対象サーバーに接続し、SOA EJBを呼び出します。
OIMは、Oracle SOA Suiteのヒューマン・ワークフロー・モジュールを使用して、そのリクエスト・ワークフローを管理します。OIMは、SOA用のフロントエンドURLであるSOAサーバーのT3 URLを使用してSOAに接続します。クラスタ化されたSOAサーバーでは、ロード・バランサまたはWebサーバーのURLを使用することをお薦めします。ワークフローが完了すると、SOAはOIMFrontEndURLを使用してOIM Webサービスをコールバックします。Oracle SOAは、OIMとともにデプロイされます。
いくつかのOIMモジュールはJMSキューを使用します。各キューは、個別のメッセージドリブンBean (MDB)によって処理されます。MDBもOIMアプリケーションの一部です。メッセージ・プロデューサもOIMアプリケーションの一部です。
OIMは、スケジュール済アクティビティのためにクォーツ・ベースのスケジューラを使用します。ユーザーの終了日後にそのユーザーを無効化するなど、バックグラウンドで様々なスケジュール済アクティビティが実行されます。
このリリースでは、BI PublisherはOIMに組み込まれていません。しかし、Oracle Identity Manager Governanceのためのアプリケーションの開発とカスタマイズのレポートの構成に関する項の手順に従って、BI PublisherとOIMを統合できます。
ランタイム・プロセス
Oracle Identity Managerは、WebLogic Serverにno-stageアプリケーションとしてデプロイされます。OIMサーバーは、それがデプロイされたWebLogic Serverの起動時に初期化されます。アプリケーションの初期化の一部として、クォーツ・ベースのスケジューラも起動されます。初期化が完了すると、システムはクライアントからリクエストを受信できるようになります。
Design Consoleはスタンドアロンのユーティリティとして別に起動する必要があります。
コンポーネントとプロセスのライフサイクル
Oracle Identity Managerは、外部的に管理されるアプリケーションとしてWebLogic Serverにデプロイされます。デフォルトでは、WebLogic Serverによって、OIMアプリケーションに対する他のライフサイクル・イベントの起動、停止、監視および管理が行われます。
OIMは、アプリケーション・サーバー・コンポーネントが起動した後に起動します。OIMコンポーネント・メカニズムの一部である認証システムが使用され、それはWebLogic JNDIが初期化されてアプリケーションが起動する前に起動します。
OIMは、すべてのWebLogic Serverインスタンスでスケジューラ・スレッドを起動するクォーツ・テクノロジ・ベースのスケジューラを使用します。データベースが、スケジュール済アクティビティの選択と実行のための中央記憶域として使用されます。1つのスケジューラ・インスタンスがジョブを選択した場合、その他のインスタンスがその同じジョブを選択することはありません。
ノード・マネージャは、サーバー・プロセスを監視し、障害発生時にそのプロセスを再起動するように構成できます。
Oracle Enterprise Manager Fusion Middleware Controlは、アプリケーションの監視および構成の変更に使用します。
Oracle Identity Governanceの起動および停止
OIMライフサイクル・イベントは、次のコマンド行ツールおよびコンソールを使用して管理します。
-
Oracle WebLogic Scripting Tool(WLST)
-
WebLogic Server管理コンソール
-
Oracle Enterprise Manager Fusion Middleware Control。
-
Oracle WebLogicノード・マネージャ
構成アーティファクト
OIMサーバー構成は、MDSリポジトリ(/db/oim-config.xml
)に格納されます。oim-config.xml
ファイルがメイン構成ファイルです。OIM構成は、Oracle Enterprise Manager Fusion Middleware Controlまたはコマンド行MDSユーティリティを介してMBeanブラウザを使用して管理します。MDSユーティリティの詳細は、Oracle Fusion Middleware Oracle Identity Managerのためのアプリケーションの開発とカスタマイズのユーザー構成可能メタデータ・ファイルの移行に関する項を参照してください。
JMSは、インストーラによってすぐに使用可能な状態に構成されます。JMSキュー、接続プール、データ・ソースなど必要なものはすべて、WebLogicアプリケーション・サーバー上に構成されます。次のキューが、OIMをデプロイするときに作成されます。
-
oimAttestationQueue
-
oimAuditQueue
-
oimDefaultQueue
-
oimKernelQueue
-
oimProcessQueue
-
oimReconQueue
-
oimSODQueue
Design ConsoleおよびRemote Managerの構成は、xlconfig.xml
に格納されます。
外部依存性
Oracle Identity Managerは、Oracle SOA Suiteのワークリストおよびヒューマン・ワークフロー・モジュールを使用して、そのリクエスト・フローを管理します。OIMは、外部リポジトリと対話して、構成およびランタイム・データを格納するので、初期化および実行時に、これらのリポジトリが使用可能であることが必要です。OIMリポジトリには、OIMのすべての資格証明が格納されます。OIMに必要な外部コンポーネントは次のとおりです。
-
WebLogic Server
-
管理サーバー
-
管理対象サーバー
-
-
データ・リポジトリ
-
構成リポジトリ(MDSスキーマ)
-
ランタイム・リポジトリ(OIMスキーマ)
-
ユーザー・リポジトリ(OIMスキーマ)
-
SOAリポジトリ(SOAスキーマ)
-
-
BI Publisher、これはオプションでOIMと統合できます
Design Consoleは、管理者が、開発とカスタマイズのために使用するツールです。Design Consoleは、OIMエンジンと直接通信し、OIMサーバーが依存するものと同じコンポーネントに依存します。
Remote Managerは、オプションの独立したスタンドアロン・アプリケーションであり、ローカル・システムのカスタムAPIを呼び出します。それには、カスタムAPIのJARファイルがそのクラスパスに含まれている必要があります。
Oracle Identity Governanceのログ・ファイルの場所
Java EEアプリケーションはWebLogic Serverにデプロイされるので、サーバー・ログ・メッセージはすべてサーバーのログ・ファイルに記録されます。OIM固有のメッセージは、アプリケーションがデプロイされるWebLogic Serverの診断ログ・ファイルに記録されます。
WebLogic Serverのログ・ファイルは、次のディレクトリにあります。
DOMAIN_HOME/servers/serverName/logs
主なログ・ファイルは、serverName.log、serverName.outおよびserverName-diagnostic.logの3つですが、ここでserverNameはWebLogic Serverの名前です。たとえば、WebLogic Server名がwls_OIM1の場合、診断ログ・ファイル名はwls_OIM1-diagnostic.logになります。ログ・ファイルを表示するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。
Oracle Identity Governanceの高可用性の概念
Oracle Identity Governanceの高可用性に関連する概念は、OIG高可用性アーキテクチャ、OIGクラスタの起動と停止、およびクラスタワイドの構成変更です。
注意:
-
OIMはOracle RACデータベースにデプロイできますが、Oracle RACのフェイルオーバーは、このリリースではOIMに対して透過的ではありません。Oracle RACのフェイルオーバーが発生すると、エンド・ユーザーは、リクエストを再送信する必要がある場合があります。
-
OIMは常に、SOAクラスタ内で少なくとも1つのノードが使用可能であることを必要とします。SOAクラスタが使用可能でない場合、エンド・ユーザーのリクエストは失敗します。OIMは、失敗したSOA呼出しに対して再試行しません。そのため、SOA呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。
Oracle Identity Governanceの高可用性アーキテクチャ
図10-2は、高可用性アーキテクチャにデプロイされたOIMを示しています。
OIMHOST1では、次のインストールが実行されています。
-
OIMインスタンスはWLS_OIM1管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA1管理対象サーバーにインストールされています。
-
Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにGridLinkデータ・ソース内に構成されています。
-
WebLogic Server管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。
OIMHOST2では、次のインストールが実行されています。
-
OIMインスタンスはWLS_OIM2管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA2管理対象サーバーにインストールされています。
-
Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにGridLinkデータ・ソース内に構成されています。
-
OIMHOST1およびOIMHOST2上のWLS_OIM1およびWLS_OIM2管理対象サーバーのインスタンスは、OIM_Clusterクラスタとして構成されています。
-
OIMHOST1およびOIMHOST2上のWLS_SOA1およびWLS_SOA2管理対象サーバーのインスタンスは、SOA_Clusterクラスタとして構成されています。
-
管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OIMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
図10-2では、OIMの高可用性構成で、次の仮想ホスト名が使用されています。
-
OIMVHN1は、WLS_OIM1管理対象サーバーのリスニング・アドレスにマップし、WLS_OIM1管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_OIM1管理対象サーバーが実行されているノード(デフォルトではOIMHOST1)で有効化されます。
-
OIMVHN2は、WLS_OIM2管理対象サーバーのリスニング・アドレスにマップし、WLS_OIM2管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_OIM2管理対象サーバーが実行されているノード(デフォルトではOIMHOST2)で有効化されます。
-
SOAVHN1は、WLS_SOA1管理対象サーバーのリスニング・アドレスで、WLS_SOA1管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_SOA1管理対象サーバーが実行されているノード(デフォルトではOIMHOST1)で有効化されます。
-
SOAVHN2は、WLS_SOA2管理対象サーバーのリスニング・アドレスで、WLS_SOA2管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_SOA2管理対象サーバーが実行されているノード(デフォルトではOIMHOST2)で有効化されます。
-
VHNは、Oracle Real Application Clusters (Oracle RAC)データベース・ホストの仮想IPアドレスを指します。
OIGクラスタの起動と停止
デフォルトでは、WebLogic Serverによって、このアプリケーションに対するライフサイクル・イベントの起動、停止、監視および管理が行われます。OIMアプリケーションは、クラスタの高可用性機能を利用します。ハードウェアまたは他の原因により失敗が発生した場合、他のクラスタ・ノードでセッション状態を利用でき、そのノードで障害の起きたノードの作業を再開できます。
OIMライフサイクル・イベントを管理するには、次のコマンド行ツールおよびコンソールを使用します。
-
WebLogic Server管理コンソール
-
Oracle Enterprise Manager Fusion Middleware Control。
-
Oracle WebLogic Scripting Tool(WLST)
高可用性のディレクトリ構造の前提条件
高可用性デプロイメントでは、製品インストールとファイルが特定のディレクトリに存在する必要があります。標準のディレクトリ構造を用いることで、ノード全体の構成および製品の統合が容易になります。
高可用性を構成する前に、「高可用性のディレクトリ構造の前提条件」で説明している要件を使用環境が満たしていることを確認してください。
Oracle Identity Governanceの高可用性の構成ステップ
Oracle Identity Governanceの高可用性の構成には、前提条件の設定、ドメインの構成、インストール後のステップ、サーバーの起動、SOA統合、管理対象サーバー・インスタンスの検証、Oracle Identity Governanceのスケール・アップおよびスケール・アウトが含まれます。
この項では、OIMの高可用性デプロイメントを設定する大まかな手順について説明し、次のトピックが含まれます。
- Oracle Identity Governanceの構成のための前提条件
- ドメインの構成
- OIMHOST1におけるインストール後のステップ
- 管理サーバー、oim_server1およびsoa_server1の起動
- Oracle Identity GovernanceとOracle SOA Suiteの統合
- OIMHOST2へのOracle Identity Governanceの伝播
- OIMHOST2におけるインストール後のステップ
- OIMHOST2での管理対象サーバー・インスタンスの検証
- OIGおよびSOA管理対象サーバーに対するサーバーの移行の構成
- トランザクション・リカバリのためのデフォルトの永続ストアの構成
- WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールします
- Web Tierと連携するためのOracle Identity Governanceの構成
- Oracle HTTP Serverの構成の検証
- Oracle Identity Governanceのフェイルオーバーおよび予想される動作
- Oracle Identity Governanceのスケール・アップ
- Oracle Identity Governanceのスケール・アウト
Oracle Identity Governanceの構成のための前提条件
OIMを高可用性のために構成する前に、次の操作を実行しておく必要があります。
-
Oracle Databaseをインストールします。『Oracle Identity and Access Managementのインストールおよび構成』のデータベース要件に関する項を参照してください。
-
OIMHOST1およびOIMHOST2にJDKをインストールします。『Oracle WebLogic ServerおよびCoherenceのインストールと構成』のインストールの準備に関する項を参照してください。
-
クイック・インストーラを使用して、OIMHOST1およびOIMHOST2にWebLogic Server、Oracle SOA Suite、およびOracle Identity Managementソフトウェアをインストールします。『Oracle Identity and Access Managementのインストールおよび構成』のクイック・インストーラを使用したOracle Identity Governanceのインストールに関する項を参照してください。
-
データベースに OIMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。「データベースにOIMスキーマを作成するためのRCUの実行」を参照してください。
データベースにOIMスキーマを作成するためのRCUの実行
作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。『Oracle Identity and Access Managementのインストールおよび構成』のデータベーススキーマの作成に関する項を参照してください。
ドメインの構成
構成ウィザードを使用して、ドメインを作成および構成します。
Identity Managementドメインの作成の詳細は、『Oracle Identity and Access Managementのインストールおよび構成』のドメインの構成に関する項を参照してください。
OIMHOST1におけるインストール後のステップ
この項では、OIMHOST1におけるインストール後のステップについて説明します。
オフライン構成コマンドの実行
Oracle Identity Governanceドメインを構成した後、offlineConfigManager
スクリプトを実行して、構成後のタスクを実行します。
offlineConfigManager
コマンドを実行するには、次を行います。
親トピック: OIMHOST1におけるインストール後のステップ
SSL対応サーバーのシステム・プロパティの更新
SSL対応サーバーの場合、ドメイン・ホームのsetDomainEnv
ファイルに必要なプロパティを設定する必要があります。
DOMAIN_HOME/bin/setDomainEnv.sh
(UNIXの場合)またはDOMAIN_HOME\bin\setDomainEnv.cmd
(Windowsの場合)ファイルに次のプロパティを設定します。
-
-Dweblogic.security.SSL.ignoreHostnameVerification=true
-
-Dweblogic.security.TrustKeyStore=DemoTrust
親トピック: OIMHOST1におけるインストール後のステップ
Oracle Identity GovernanceとOracle SOA Suiteの統合
OIMHOST2へのOracle Identity Governanceの伝播
OIMHOST1で構成を完了したら、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍することにより、OIMHOST1の構成をOIMHOST2に伝播できます。
注意:
構成をOIMHOST2に伝播する前に、OIMHOST1上の管理対象サーバーをすべてクリーン・シャット・ダウンすることをお薦めします。
OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍するには、次の手順を実行します。
OIMHOST2におけるインストール後のステップ
OIMHOST2でのノード・マネージャの起動
次のディレクトリの下にあるstartNodeManager.sh
スクリプトを使用してOIMHOST2上のノード・マネージャを起動します。
DOMAIN_HOME/bin
親トピック: OIMHOST2におけるインストール後のステップ
OIMHOST2でのWLS_SOA2およびWLS_OIM2管理対象サーバーの起動
OIMHOST2で管理対象サーバーを起動するには、次の手順を実行します。
- 管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。
- 管理コンソールを使用して、WLS_OIM2管理対象サーバーを起動します。WLS_OIM2管理対象サーバーを起動する前に、WLS_SOA2管理対象サーバーを起動してください。
親トピック: OIMHOST2におけるインストール後のステップ
OIMHOST2での管理対象サーバー・インスタンスの検証
OIMHOST2でOracle Identity Manager (OIM)およびBI Publisher管理対象サーバー・インスタンスを検証します。
次のURLを使用してOIMコンソールを開きます。
http://identityvhn2.example.com:14000/oim
xelsysadm
パスワードを使用してログインします。
BI PublisherのURLは次のとおりです。
http://identityvhn2.example.com:9704/xmlpserver
xelsysadm
パスワードを使用してログインします。
OIGおよびSOA管理対象サーバーに対するサーバーの移行の構成
この高可用性トポロジでは、管理対象サーバーWLS_OIM1、WLS_SOA1、WLS_OIM2、WLS_SOA2に対してサーバー移行を構成することをお薦めします。サーバー全体の移行を使用する利点と推奨する理由については、第3.9項「サーバー全体の移行」を参照してください。
-
OIMHOST1上のWLS_OIM1およびWLS_SOA1管理対象サーバーは、OIMHOST1で障害が発生した場合に、OIMHOST2で自動的に再起動するように構成されます。
-
OIMHOST2上のWLS_OIM2およびWLS_SOA2管理対象サーバーは、OIMHOST2で障害が発生した場合に、OIMHOST1で自動的に再起動するように構成されます。
このような構成では、WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2サーバーは、WebLogicサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。
BI PublisherはオプションでOIGと統合できます。
次のトピックでは、WLS_OIM1、WLS_SOA1、WLS_OIM2、およびWLS_SOA2管理対象サーバーのサーバー移行を行うことができ、これにより、サーバーまたはプロセスの障害時に、管理対象サーバーは別のノードにフェイルオーバーできます。
ノード・マネージャのプロパティ・ファイルの編集
nodemanager.properties
ファイルを編集して、サーバー移行を構成するノードごとに次のプロパティを追加する必要があります。
Interface=eth0 eth0=*,NetMask=255.255.248.0 UseMACBroadcast=true
-
Interface
: 浮動IPのインタフェース名(eth0
など)を指定します。注意:
サブ・インタフェース(
eth0:1
、eth0:2
など)を指定しないでください。このインタフェースは、:0
または:1
なしに使用されます。ノード・マネージャのスクリプトは、別の:X
対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0
、eth1
、eth2
、eth3
、eth
nとなります。 -
NetMask
: 浮動IPのインタフェースのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります(255.255.255.0
は一例です)。実際の値は、ネットワークにより異なります。 -
UseMACBroadcast
: ARPパケットの送信時にノードのMACアドレスを使用するかどうか、つまり、arping
コマンドで-b
フラグを使用するかどうかを指定します。
これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。(これを行うには、ノード・マネージャを再起動する必要があります。)ノード・マネージャの出力で、次のようなエントリが表示されることを確認します。
... StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 ...
wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定
サーバー移行を構成するノードごとにwlsifconfig.sh
スクリプトの環境とスーパーユーザー権限を設定する手順は、次のとおりです。
サーバー移行ターゲットの構成
まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内のクラスタ移行を構成する手順は、次のとおりです。
-
管理コンソールにログインします。
-
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
-
「名前」列で、移行を構成するクラスタをクリックします。
-
「移行」タブをクリックします。
-
「ロックして編集」をクリックします。
-
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
-
自動移行に使用するデータ・ソースを選択します。この場合は、リース・データソース、
WLSSchemaDataSource
を選択します。 -
「保存」をクリックします。
-
「変更のアクティブ化」をクリックします。
-
サーバー移行の候補となるマシンを設定します。このタスクは、次の手順に従って、すべての管理対象サーバーについて実行する必要があります。
-
管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
ヒント:
「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックして、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動し、サーバーが実行されているマシンを表示します。サーバーが自動的に移行される場合、これは実際の構成とは異なります。
-
移行を構成するサーバーを選択します。
-
「移行」タブをクリックします。
-
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
-
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
-
「保存」をクリックしてから、「変更のアクティブ化」をクリックします。
-
追加の管理対象サーバーに対して、前述のステップを繰り返します。
-
管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。
-
サーバー移行のテスト
サーバー移行が適切に機能していることを確認する手順は次のとおりです。
OIMHOST1から:
-
次のコマンドを実行して、WLS_OIM1管理対象サーバーを停止します。
OIMHOST1> kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
OIMHOST1> ps -ef | grep WLS_OIM1
-
ノード・マネージャのコンソールを確認します。WLS_OIM1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
-
ノード・マネージャがWLS_OIM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
-
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
OIMHOST2から:
-
ローカルのノード・マネージャのコンソールを確認します。OIMHOST1でのWLS_OIM1の再起動が前回試行されてから30秒間経過した後に、WLS_OIM1の浮動IPが表示されサーバーをこのノードで再起動することを示すメッセージがOIMHOST2のノード・マネージャにより表示されます。
-
同じIPでsoa-infraコンソールにアクセスします。
前述のステップに従い、WLS_OIM2、WLS_SOA1、およびWLS_SOA2管理対象サーバーのサーバー移行をテストします。
表10-2は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。
表10-2 WLS_OIM1、WLS_OIM2、WLS_SOA1、WLS_SOA2サーバー移行
管理対象サーバー | 移行元 | 移行先 |
---|---|---|
WLS_OIM1 |
OIMHOST1 |
OIMHOST2 |
WLS_OIM2 |
OIMHOST2 |
OIMHOST1 |
WLS_SOA1 |
OIMHOST1 |
OIMHOST2 |
WLS_SOA2 |
OIMHOST2 |
OIMHOST1 |
管理コンソールからの検証
管理コンソールで移行を検証する手順は、次のとおりです。
注意:
サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、管理コンソールで管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。
トランザクション・リカバリのためのデフォルトの永続ストアの構成
各管理対象サーバーにはトランザクション・ログがあり、管理対象サーバーによって調整された、未完了の可能性のある、進行中のトランザクションについての情報が格納されます。WebLogic Serverは、このトランザクション・ログを使用して、システムやネットワーク障害からリカバリします。トランザクション回復サービスの移行機能を活用するには、クラスタ内のすべての管理対象サーバーがアクセス可能な場所にトランザクション・ログを格納します。共有記憶域がないと、サーバーに障害が発生したときにクラスタ内の他のサーバーがトランザクション・リカバリを実行できず、操作の再試行が必要になることがあります。
注意:
ネットワーク接続ストレージ(NAS)デバイスまたはストレージ・エリア・ネットワーク(SAN)上の場所をお薦めします。
OIMおよびSOAサーバーのデフォルト永続ストアの場所を設定する手順は次のとおりです。
Web Tierと連携するためのOracle Identity Governanceの構成
次のトピックでは、Oracle Web Tierと連携するためのOIMの構成方法について説明します。
Web Tierと連携するためのOIGの構成の前提条件
次のタスクが実行済であることを確認します。
- Oracle Web TierをWEBHOST1とWEBHOST2にインストールしました。
- OIMがOIMHOST1およびOIMHOST2にインストールされ、構成済であること。
- ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(
sso.example.com
)で構成済であること。sso.example.com
は顧客が接続する主要エントリ・ポイントで、通常はSSL終端です。 - ロード・バランサがWebサーバーWEBHOST1およびWEBHOST2を指す仮想ホスト名(
oiminternal.example.com
)で構成済であること。oiminternal.example.com
は内部コールバック用で、顧客向けではありません。
Oracle Identity Governanceのフェイルオーバーおよび予想される動作
高可用性環境では、Oracle WebLogic Serverを監視するようにノード・マネージャを構成します。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。
ハードウェア・ロード・バランサでは、複数のOIMインスタンス間のリクエストをロード・バランシングします。OIM管理対象サーバーのいずれかに障害が発生した場合は、ロード・バランサによって障害が検出され、障害が発生していないインスタンスにリクエストがルーティングされます。
高可用性環境では、状態情報と構成情報は、すべてのクラスタ・メンバーが共有するデータベースに格納されます。状態情報が共有データベースに格納されており、すべてのクラスタ・メンバーがこの情報を使用できるため、障害が発生していないOIMインスタンスでは、障害が発生したインスタンスで開始された未完了のトランザクションの処理をシームレスに継続します。
OIMインスタンスのいずれかで障害が発生すると、そのデータベースとLDAP接続は解放されます。アクティブ/アクティブ・デプロイメント内にある障害が発生していないインスタンスは、独自の接続を行い、障害が発生したインスタンス上にある未完了のトランザクションの処理を継続します。
OIMを高可用性構成にデプロイする場合は、次のことに注意してください。
-
OIMはOracle RACデータベースにデプロイできますが、Oracle RACのフェイルオーバーは、このリリースではOIMに対して透過的ではありません。Oracle RACのフェイルオーバーが発生すると、エンド・ユーザーは、各自のリクエストを再送信する必要がある場合があります。
-
Oracle Identity Managerは常に、SOAクラスタ内で少なくとも1つのノードが使用可能であることを必要とします。SOAクラスタが使用可能でない場合、エンド・ユーザーのリクエストは失敗します。OIMは、失敗したSOA呼出しに対して再試行しません。そのため、SOA呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。
Oracle Identity Governanceのスケール・アップ
OIGの高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。スケール・アウトするには、「Oracle Identity Governanceのスケール・アウト」を参照してください。
この場合は、SOAコンポーネントとともに構成された管理対象サーバーが実行されているノードが存在しています。ノードには次のものが含まれます。
-
Middlewareホーム
-
Oracleホーム(SOA)
-
既存の管理対象サーバーのドメイン・ディレクトリ
新しいWLS_OIMおよびWLS_SOA管理対象サーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。OIMおよびSOAのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
この手順では、OIMおよびSOA管理対象サーバーのクローンを作成する方法について説明します。これらのコンポーネント・タイプの1つまたは2つでも、そのうちの1つがOIMであればクローンを作成できます。
次の点に注意してください。
-
この手順は、WLS_OIMおよびWLS_SOAについて説明しています。しかし、両方のコンポーネントをスケール・アップする可能性は少ないです。ステップごとに、使用環境でスケール・アップする対象のコンポーネントを選択してください。また、一部のコンポーネントには適用されないステップもあります
-
JMSサーバーの永続ストア用の共有記憶域ディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。
-
永続ストアのパスを指定するときは必ず、共有記憶域上のディレクトリを指定する必要があります
トポロジをスケール・アップするには:
-
管理コンソールで、WLS_OIM1またはWLS_SOA1のクローンを作成します。クローンを作成する管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
-
管理コンソールから「環境」→「サーバー」を選択します。
-
クローンを作成する管理対象サーバーを選択します。
-
「クローン」を選択します。
-
新しい管理対象サーバーにWLS_OIM
n
/WLS_SOAn
という名前を付けます。n
は新しい管理対象サーバーを識別する番号を示します。
この後のステップでは、すでにWLS_SOA1およびWLS_OIM1を実行しているOIMHOST1に新しい管理対象サーバーを追加することを想定しています。
-
-
リスニング・アドレスとして、新しい管理対象サーバーのホスト名またはIPを割り当てます。サーバー移行の使用を計画している場合は、VIP (浮動IP)を使用して、管理対象サーバーを別のノードに移動できるようにします。既存の管理対象サーバーで使用されているVIPとは別のVIPを使用してください。
-
新しい管理対象サーバーにOIM/SOA、BPM、UMS、JRFWSAsyncおよびSOAJMServerを作成します。
-
管理コンソールで、OIM JMSサーバーの新しい永続ストアを作成し、名前を付けます。ストアのパス(共有記憶域上のディレクトリ)を指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
-
OIMの新しいJMSサーバーを作成します。JMSServerに対して、
JMSFileStore
_nを使用します。JMSServer_
nを新しい管理対象サーバーにターゲット指定します。 -
新しいUMSJMSServerの永続ストアを作成します(たとえば、
UMSJMSFileStore
_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
-
UMSの新しいJMSサーバーを作成します(たとえば、
UMSJMSServer
_n)。それを新しい管理対象サーバー(WLS_SOAn)にターゲット指定します。 -
新しいBPMJMSServerの永続ストアを作成します(たとえば、
BPMJMSFileStore
_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_n
-
BPMの新しいJMSサーバーを作成します(たとえば、
BPMJMSServer
_n)。それを新しい管理対象サーバー(WLS_SOAn)にターゲット指定します。 -
新しいJRFWSAsyncJMSServerの新しい永続ストアを作成します(たとえば、
JRFWSAsyncJMSFileStore
_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n
-
JRFWSAsyncのJMSサーバーを作成します(たとえば、
JRFWSAsyncJMSServer
_n)。このJMSServerに対して、JRFWSAsyncJMSFileStore
_nを使用します。JRFWSAsyncJMSServer
_nを新しい管理対象サーバー(WLS_OIMn)にターゲット指定します。注意:
新しいJRFWSAsync JMSサーバーのストアとして
SOAJMSFileStore
_nを割り当てることもできます。わかりやすさと独立性を保つために、以降のステップでは個別の永続ストアを使用します。 -
新しいSOAJMSServerの永続ストアを作成します(たとえば、
SOAJMSFileStore_auto
_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_auto_n
-
SOAの新しいJMSサーバーを作成します(たとえば、
SOAJMSServer_auto
_n)。このJMSServerに対して、SOAJMSFileStore_auto_
nを使用します。SOAJMSServer_auto
_nを新しい管理対象サーバー(WLS_SOAn)にターゲット指定します。注意:
新しいPS6 JMSサーバーのストアとして
SOAJMSFileStore
_nを割り当てることもできます。わかりやすさと独立性を保つために、以降のステップでは個別の永続ストアを使用します。 -
新しいSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「SOAJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、SOAJMSServerXXXXXXサブデプロイメントをクリックし、
SOAJMSServer
_nを追加します。「保存」をクリックします。注意:
サブデプロイメント・モジュール名は、COMPONENTJMSServerXXXXXXという形式のランダム名です。これは、構成ウィザードにおける最初の2つの管理対象サーバー(WLS_COMPONENT1とWLS_COMPONENT2)のJMS構成から取得します。
-
新しいUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「UMSJMSSystemResource」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、UMSJMSServerXXXXXXサブデプロイメントをクリックし、
UMSJMSServer
_nを追加します。「保存」をクリックします。 -
新しいOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「OIMJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、OIMJMSServerXXXXXXとその
OIMJMSServer
_n
をクリックします。「保存」をクリックします。 -
新しいJRFWSAsync JMSサーバーが含まれるように、JRFWSAsyncJmsModuleのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JRFWSAsyncJmsModule」をクリックします(表の「名前」列内のハイパーリンク)。「設定」ページで「サブデプロイメント」タブをクリックします。JRFWSAsyncJMSServerXXXXXXサブデプロイメントをクリックし、このサブデプロイメントに
JRFWSAsyncJMSServer
_nを追加します。「保存」をクリックします -
新しいBPM JMSサーバーが含まれるように、BPM JMSモジュールのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「BPMJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、BPMJMSServerXXXXXXサブデプロイメントをクリックし、
BPMJMSServer
_nを追加します。「保存」をクリックします。
-
-
新しいサーバーのトランザクション永続ストアを、他のノードから参照可能な共有記憶域の場所に構成します。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアのパスを入力します。
-
新しい管理対象サーバーのホスト名検証を無効にします(WLS_SOAn管理対象サーバーの起動と検証を行う前に実行する必要があります)。SOAHOSTnで管理サーバーとノード・マネージャとの通信用のサーバー証明書を構成した後で、これを再度有効化できます。(新しい管理対象サーバーのクローン元となった)ソース・サーバーで、ホスト名の検証が無効化されている場合、これらのステップは不要です。ホスト名の検証の設定はクローンされたサーバーに伝播されます。
ホスト名の検証を無効化するには、次の手順を実行します。
-
管理コンソールの「ドメイン構造」ウィンドウで「環境」ノードを展開します。
-
「サーバー」をクリックします。表の「名前」列で「WLS_SOAn」を選択します。
-
「SSL」タブをクリックします。「詳細」をクリックします。
-
「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
-
-
管理コンソールから新しい管理対象サーバーを起動して、テストします。
-
クラスタ内の既存の管理対象サーバーを停止します。
-
新たに作成した管理対象サーバーが起動していることを確認します。
-
新たに作成した管理対象サーバーのアプリケーションにアクセスし、それが動作していることを確認します。OIMのログイン・ページが開きます。SOAの場合は、HTTP基本認証が開きます。
表10-3 管理対象サーバーのテストURL
コンポーネント 管理対象サーバーのテストURL SOA
http://vip:port/soa-infra
OIM
http://vip:port/identity
-
-
管理コンソールで、「サービス」→「外部JNDIプロバイダ」を選択します。ForeignJNDIProvider-SOAが、管理対象サーバーではなく
cluster:t3://soa_cluster
にターゲット指定されていることを確認します。クラスタにターゲット指定すると、新しい管理対象サーバーを構成する必要がありません。ForeignJNDIProvider-SOAのターゲットがクラスタでない場合は、クラスタにターゲット指定してください。 -
新しい管理対象サーバーに対してサーバー移行を構成します。
注意:
スケール・アップの場合、ノードにはノード・マネージャ、サーバー移行に対して構成された環境、および新しい管理対象サーバーの浮動IPが必要です。
サーバー移行を構成する手順は次のとおりです。
-
管理コンソールにログインします。
-
左側のペインで、「環境」を開き、「サーバー」を選択します。
-
移行を構成するサーバー(ハイパーリンク)を選択します。
-
「移行」タブをクリックします。
-
「移行の構成」セクションの「使用可能」フィールドで、移行を許可するマシンを選択し、右矢印をクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。
例:
SOAHOST1 (すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。
SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。
移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。
-
「サーバーの自動移行を有効化」オプションを選択して、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようにします。
-
「保存」をクリックします。
-
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
-
これらのステップを繰り返し、新たに作成したWLS_OIMn管理対象サーバーに対してサーバー移行を構成します。
-
-
この新規サーバーのサーバー移行をテストするには、新規サーバーの追加先となったノードで、次のステップを実行します。
-
管理対象サーバーを停止します。
管理対象サーバーのPIDに対して
kill -9
pidを実行します。ノードのPIDを特定するには、ps -ef | grep WLS_SOA
nのように入力します。 -
ノード・マネージャのコンソールに、管理対象サーバーの浮動IPが無効になったことを示すメッセージが表示されます。
-
ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
-
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
-
-
OHS構成ファイルを編集して、新しい管理対象サーバーを追加します。「新しい管理対象サーバーを認識するためのOracle HTTP Serverの構成」を参照してください。
Oracle Identity Governanceのスケール・アウト
トポロジのスケール・アウトでは、ソフトウェアで構成された新しい管理対象サーバーを新しいノードに追加します。
注意:
この手順の各ステップは、WLS_OIMおよびWLS_SOAについて説明しています。しかし、両方のコンポーネントをスケール・アップする可能性は少ないです。ステップごとに、使用環境でスケール・アップする対象のコンポーネントを選択してください。一部のコンポーネントには適用されないステップもあります。
スケール・アウトする前に、次の要件を満たしていることを確認してください。
-
OIMおよびSOAで構成された管理対象サーバーを実行している既存のノードがトポロジ内に存在していること。
-
新しいノードがWebLogic Server、SOAおよびOIMの既存のホーム・ディレクトリにアクセスできること。(新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic Serverやコンポーネント・バイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります。)
注意:
共有記憶域に既存のインストールが存在しない場合は、WebLogic Server、SOAおよびOIMを新しいノードにインストールする必要があります。
注意:
ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを追加する場合は、ORACLE_HOME
/oui/bin/attachHome.sh
を使用します。
トポロジをスケール・アウトするには:
-
新しいノードで、既存のMiddlewareホームをマウントします。SOAおよびOIMのインストールとドメイン・ディレクトリを追加して、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
-
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加します。例:
cd /u01/app/oracle/soa/ ./attachHome.sh -jreLoc u01/app/JRE-JDK_version>
Middlewareホーム・リストを更新するには、MW_HOME
/bea/beahomelist
ファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにu01/app/oracle
を追加します。 -
管理コンソールにログインします。
-
新しいノード用の新しいマシンを作成します。このマシンをドメインに追加します。
-
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
-
WLS_OIM1/WLS_SOA1のクローンを作成します。
OIMおよびSOAのクローンを作成するには、次の手順を実行します。
-
管理コンソールから「環境」→「サーバー」を選択します。
-
クローンを作成する管理対象サーバーを選択します。
-
「クローン」を選択します。
-
新しい管理対象サーバーにWLS_OIM
n
/WLS_SOAn
という名前を付けます。n
は新しい管理対象サーバーを識別する番号を示します。
注意:
このステップでは、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。
-
-
新しい管理対象サーバーでその管理対象サーバーのリスニング・アドレスに使用するホスト名またはIPを割り当てます。
このサーバーに対してサーバー移行の使用を計画している場合(推奨)、これはサーバーのVIP (浮動IP)であることが必要です。このVIPは、既存の管理対象サーバーとは別のものを使用してください。
-
新しい管理対象サーバーにSOA、OIM (該当する場合)、UMS、BPM、JRFWSAsyncおよびSOAのJMSサーバーを作成します。
-
管理コンソールで、OIM JMSサーバーの新しい永続ストアを作成し、名前を変更します。ストアのパス(共有記憶域上のディレクトリ)を指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
-
OIMの新しいJMSサーバーを作成します。JMSServerに対して、
JMSFileStore
_nを使用します。JMSServer_
nを新しい管理対象サーバーにターゲット指定します。 -
新しいUMSJMSServerの永続ストアを作成します(たとえば、
UMSJMSFileStore
_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
-
UMSの新しいJMSサーバーを作成します(たとえば、
UMSJMSServer
_n)。それを新しい管理対象サーバー(WLS_SOAn)にターゲット指定します。 -
新しいBPMJMSServerの永続ストアを作成します(たとえば、
BPMJMSFileStore
_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_n
-
BPMの新しいJMSサーバーを作成します(たとえば、
BPMJMSServer
_n)。それを新しい管理対象サーバー(WLS_SOAn)にターゲット指定します。 -
新しいJRFWSAsyncJMSServerの新しい永続ストアを作成します(たとえば、
JRFWSAsyncJMSFileStore
_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n
-
JRFWSAsyncのJMSサーバーを作成します(たとえば、
JRFWSAsyncJMSServer
_n)。このJMSServerに対して、JRFWSAsyncJMSFileStore
_nを使用します。JRFWSAsyncJMSServer
_nを新しい管理対象サーバー(WLS_OIMn)にターゲット指定します。注意:
新しいJRFWSAsync JMSサーバーのストアとして
SOAJMSFileStore
_nを割り当てることもできます。わかりやすさと独立性を保つために、以降のステップでは個別の永続ストアを使用します。 -
新しいSOAJMSServerの永続ストアを作成します(たとえば、
SOAJMSFileStore_auto
_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_auto_n
-
SOAの新しいJMSサーバーを作成します(たとえば、
SOAJMSServer_auto
_n)。このJMSServerに対して、SOAJMSFileStore_auto_
nを使用します。SOAJMSServer_auto
_nを新しい管理対象サーバー(WLS_SOAn)にターゲット指定します。注意:
新しいPS6 JMSサーバーのストアとして
SOAJMSFileStore
_nを割り当てることもできます。わかりやすさと独立性を保つために、以降のステップでは個別の永続ストアを使用します。 -
新しいSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「SOAJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、SOAJMSServerXXXXXXサブデプロイメントをクリックし、
SOAJMSServer
_nを追加します。「保存」をクリックします。注意:
サブデプロイメント・モジュール名は、COMPONENTJMSServerXXXXXXという形式のランダム名です。これは、構成ウィザードにおける最初の2つの管理対象サーバー(WLS_COMPONENT1とWLS_COMPONENT2)のJMS構成から取得します。
-
新しいUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「UMSJMSSystemResource」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、UMSJMSServerXXXXXXサブデプロイメントをクリックし、
UMSJMSServer
_nを追加します。「保存」をクリックします。 -
新しいOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「OIMJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、OIMJMSServerXXXXXXとその
OIMJMSServer
_n
をクリックします。「保存」をクリックします。 -
新しいJRFWSAsync JMSサーバーが含まれるように、JRFWSAsyncJmsModuleのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JRFWSAsyncJmsModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。JRFWSAsyncJMSServerXXXXXXサブデプロイメントをクリックし、このサブデプロイメントに
JRFWSAsyncJMSServer
_nを追加します。「保存」をクリックします -
新しいBPM JMSサーバーが含まれるように、BPM JMSモジュールのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「BPMJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、BPMJMSServerXXXXXXサブデプロイメントをクリックし、
BPMJMSServer
_nを追加します。「保存」をクリックします。
-
-
SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。例:
cd ORACLE_HOME/oracle_common/common/bin ./pack.sh -managed=true/ -domain=MW_HOME/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar -template_name='soa_domain_templateScale'
次のコマンドをHOST1で実行し、作成したテンプレート・ファイルをHOSTnにコピーします。
scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_BASE/product/fmw/soa/common/bin
次のように、unpackコマンドをHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。たとえば、SOAの場合は次のようにします。
ORACLE_HOME/oracle_common/common/bin /unpack.sh / -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar
-
新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
-
新しい管理対象サーバーのホスト名の検証を無効化します。この操作は管理対象サーバーを起動して検証する前に実行しておく必要があります。管理サーバーとノード・マネージャとの通信用のサーバー証明書を構成した後で、これを再度有効化できます。(新しい管理対象サーバーのクローン元となった)ソース管理対象サーバーで、ホスト名の検証がすでに無効化されている場合、これらのステップは不要です。ホスト名の検証の設定はクローンされたサーバーに伝播されます。
ホスト名の検証を無効化するには、次の手順を実行します。
-
管理コンソールを開きます。
-
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
-
「サーバー」をクリックします。
-
表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。
-
「SSL」タブをクリックします。
-
「詳細」をクリックします。
-
「ホスト名の検証」を「なし」に設定します。
-
「保存」をクリックします。
-
-
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
WL_HOME/server/bin/startNodeManager new_node_ip
-
管理コンソールから新しい管理対象サーバーを起動して、テストします。
-
クラスタ内の既存の管理対象サーバーを停止します。
-
新たに作成した管理対象サーバーが起動していることを確認します。
-
新たに作成した管理対象サーバーのアプリケーションにアクセスし、それが動作していることを確認します。OIMのログイン・ページが表示されます。SOAの場合は、HTTP基本認証が開きます。
表10-4 管理対象サーバーのテストURL
コンポーネント 管理対象サーバーのテストURL SOA
http://vip:port/soa-infra
OIM
http://vip:port/identity
-
-
新しい管理対象サーバーに対してサーバー移行を構成します。
注意:
この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャおよびネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しい管理対象サーバーの浮動IPが存在します。
サーバー移行を構成する手順は次のとおりです。
-
管理コンソールにログインします。
-
左側のペインで、「環境」を開き、「サーバー」を選択します。
-
移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。
-
「移行」タブをクリックします。
-
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印をクリックします。
注意:
新しいサーバーの移行ターゲットには、負荷が最小のマシンを指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。
-
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
-
「保存」をクリックします。
-
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
-
-
この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。
-
管理対象サーバーを停止します。
管理対象サーバーのPIDに対して
kill -9
pidを実行します。ps -ef | grep WLS_SOA
nなどを使用して、ノードのPIDを特定します。 -
ノード・マネージャ・コンソールに、浮動IPが無効になったことを示すメッセージが表示されることを確認します。
-
ノード・マネージャが新しい管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは、再起動するまでに30秒間待機します。
-
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動しないことを示すメッセージがノード・マネージャによってログに記録されます。
-
-
OHS構成ファイルを編集して、新しい管理対象サーバーを追加します。「新しい管理対象サーバーを認識するためのOracle HTTP Serverの構成」を参照してください。
新しい管理対象サーバーを認識するためのOracle HTTP Serverの構成
スケール・アップまたはスケール・アウトを完了するには、oim.conf
ファイルを編集して、新しい管理対象サーバーを追加してから、Oracle HTTP Serverを再起動する必要があります。
注意:
共有記憶域システムを使用していない場合(推奨)、oim.confを他のOHSサーバーにコピーします。
注意:
デプロイメントを容易にする他のパラメータについては、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』のWebLogic Serverプラグインの一般的なパラメータに関する項を参照してください。