| Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド 11g リリース2 (11.1.2.3) E61957-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド 11g リリース2 (11.1.2.3) E61957-01 |
|
前 |
次 |
この章では、Oracle Identity Managerの高可用性環境を設計およびデプロイする方法について説明します。
Oracle Identity Manager (OIM)は、アプリケーションおよびディレクトリからユーザー・アカウントを追加、更新および削除するプロセスを自動化するユーザー・プロビジョニングおよび管理ソリューションです。また、誰が何にアクセスしたかを示すきめ細かいレポートを提供することで、法規制コンプライアンスの向上にも寄与します。OIMは、スタンドアロン製品として、またはOracle Identity and Access Management Suiteの一部として使用可能です。
OIMの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』を参照してください。
この項の内容は次のとおりです。
図5-1は、Oracle Identity Managerのアーキテクチャを示しています。
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は、埋込みOracle Entitlements Serverを使用しますが、これもOIMエンジンの一部です。Oracle Entitlements Server (OES)は、OIM内部で認可の確認に使用されます。たとえば、ポリシー制約の1つで、特定のロールを持つユーザーのみがユーザーを作成できると決定されているとします。これは、OIMユーザー・インタフェースを使用して定義します。
OIMは、スケジュール済アクティビティのためにクォーツ・ベースのスケジューラを使用します。ユーザーの終了日後にそのユーザーを無効化するなど、バックグラウンドで様々なスケジュール済アクティビティが実行されます。
OIMドメインの一部としてOracle BI Publisherをデプロイおよび構成します。BI Publisherは、レポート作成のために同じOIMデータベース・スキーマを使用します。統合を円滑化するためにOIMの別のドメインまたは同じドメインにBI Publisherを配置することをお薦めします。つまり、統合は静的URLの統合で構成されます。BI PublisherとOIMランタイム・コンポーネントとの間に相互作用はありません。BI Publisherは、レポート作成のために同じOIMデータベース・スキーマを使用するように構成されます。
LDAPSyncが外部ディレクトリ・サーバー(Oracle Internet Directory、ODSEE、Microsoft Active Directoryなど)と直接通信できるようにすると、高可用性とフェイルオーバー機能をサポートするためにIdentity Virtualization Library (libOVD)の構成が必要になります。
libOVDを構成するには、WLSTコマンドのaddLDAPHostを使用します。libOVDを管理する場合は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のIdentity Virtualization Library (libOVD)アダプタの管理に関する説明でWLSTコマンドのリストを参照してください。
Oracle Identity Managerは、WebLogic Serverにno-stageアプリケーションとしてデプロイされます。OIMサーバーは、それがデプロイされたWebLogic Serverの起動時に初期化されます。アプリケーションの初期化の一部として、クォーツ・ベースのスケジューラも起動されます。初期化が完了すると、システムはクライアントからリクエストを受信できるようになります。
Remote ManagerおよびDesign Consoleは別にスタンドアロンのユーティリティとして起動する必要があります。
Oracle Identity Managerは、外部的に管理されるアプリケーションとしてWebLogic Serverにデプロイされます。デフォルトでは、WebLogic Serverによって、OIMアプリケーションに対する他のライフサイクル・イベントの起動、停止、監視および管理が行われます。
OIMは、アプリケーション・サーバー・コンポーネントが起動した後に起動します。OIMコンポーネント・メカニズムの一部である認証システムが使用され、それはWebLogic JNDIが初期化されてアプリケーションが起動する前に起動します。
OIMは、すべてのWebLogic Serverインスタンスでスケジューラ・スレッドを起動するクォーツ・テクノロジ・ベースのスケジューラを使用します。データベースが、スケジュール済アクティビティの選択と実行のための中央記憶域として使用されます。1つのスケジューラ・インスタンスがジョブを選択した場合、その他のインスタンスがその同じジョブを選択することはありません。
ノード・マネージャは、サーバー・プロセスを監視し、障害発生時にそのプロセスを再起動するように構成できます。
Oracle Enterprise Manager Fusion Middleware Controlは、アプリケーションの監視および構成の変更に使用します。
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 Identity Managerのためのアプリケーションの開発とカスタマイズ』のMDSユーティリティに関する項を参照してください。
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リポジトリ(BIPLATFORMスキーマ)
外部LDAPストア(LDAP同期を使用する場合)
BI Publisher
Design Consoleは、管理者が、開発とカスタマイズのために使用するツールです。Design Consoleは、OIMエンジンと直接通信し、OIMサーバーが依存するものと同じコンポーネントに依存します。
Remote Managerは、オプションの独立したスタンドアロン・アプリケーションであり、ローカル・システムのカスタムAPIを呼び出します。それには、カスタムAPIのJARファイルがそのクラスパスに含まれている必要があります。
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を使用します。
この項の内容は次のとおりです。
|
注意: OIMをデプロイする場合は、次のことに注意してください。
|
図5-2は、高可用性アーキテクチャにデプロイされたOIMを示しています。
OIMHOST1では、次のインストールが実行されています。
OIMインスタンスはWLS_OIM1管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA1管理対象サーバーにインストールされています。
BI Publisherインスタンスは、WLS_BI1 Manager Serverにインストールされています。
Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにGridLinkデータ・ソース内に構成されています。
WebLogic Server管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。
OIMHOST2では、次のインストールが実行されています。
OIMインスタンスはWLS_OIM2管理対象サーバーに、SOAインスタンスはWLS_SOA2管理対象サーバーに、BI PublisherインスタンスはWLS_BI2管理対象サーバーにそれぞれインストールされています。
Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにGridLinkデータ・ソース内に構成されています。
OIMHOST1およびOIMHOST2上のWLS_OIM1およびWLS_OIM2管理対象サーバーのインスタンスは、OIM_Clusterクラスタとして構成されています。
OIMHOST1およびOIMHOST2上のWLS_SOA1およびWLS_SOA2管理対象サーバーのインスタンスは、SOA_Clusterクラスタとして構成されています。
OIMHOST1およびOIMHOST2上のWLS_BI1およびWLS_BI2管理対象サーバーのインスタンスは、BI_Clusterクラスタとして構成されています。
管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OIMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
図5-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)で有効化されます。
BIPVHN1は、WLS_BI1管理対象サーバーのリスニング・アドレスで、WLS_BI1管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_BI1管理対象サーバーが実行されているノード(デフォルトではOIMHOST1)で有効化されます。
BIPAVHN2は、WLS_BI2管理対象サーバーのリスニング・アドレスで、WLS_BI2管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_BI2管理対象サーバーが実行されているノード(デフォルトではOIMHOST2)で有効化されます。
VHNは、Oracle Real Application Clusters (Oracle RAC)データベース・ホストの仮想IPアドレスを指します。
デフォルトでは、WebLogic Serverによって、このアプリケーションに対するライフサイクル・イベントの起動、停止、監視および管理が行われます。OIMアプリケーションは、クラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
OIMライフサイクル・イベントを管理するには、次のコマンド行ツールおよびコンソールを使用します。
WebLogic Server管理コンソール
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Scripting Tool (WLST)
高可用性環境では、すべてのOIMインスタンスが同じ構成リポジトリを共有するため、OIMの1つのインスタンスの構成を変更するとその他すべてのインスタンスの構成も変更されます。
LDAPとOIMデータベースとの間の同期情報は、調整よって処理されますが、これはバックグラウンドで実行されるスケジュール済プロセスです。同期プロセス中にLDAPが停止した場合、OIMによって取得されていないデータは、調整タスクの次回の実行時に取得されます。
高可用性を構成する前に、第6.3項「高可用性のディレクトリ構造の前提条件」で説明している要件を使用環境が満たしていることを確認してください。
この項では、OIMの高可用性デプロイメントを設定する大まかな手順について説明し、次のトピックが含まれます。
第5.4.2項「OIMHOST1でのOIM、SOAおよびBI PublisherのためのWebLogicドメインの作成と構成」
第5.4.11項「LDAP構成ポストセットアップ・スクリプトを使用したOracle Internet Directoryの構成」
OIMを高可用性のために構成する前に、次の操作を実行しておく必要があります。
Oracle Databaseをインストールします。『Oracle Identity and Access Managementインストレーション・ガイド』のデータベース要件に関する項を参照してください。
データベースに OIMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。第5.4.1.1項「データベースにOIMスキーマを作成するためのRCUの実行」を参照してください。
OIMHOST1およびOIMHOST2にJDKをインストールします。『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の「インストールの準備」を参照してください。
OIMHOST1およびOIMHOST2にWebLogicサーバーをインストールします。第5.4.1.2項「Oracle WebLogic Serverのインストール」を参照してください。
OIMHOST1およびOIMHOST2にOracle SOA Suiteをインストールします。第II部「OIMHOST1およびOIMHOST2へのOracle SOA Suiteのインストール」を参照してください。
OIMHOST1およびOIMHOST2にOracle Identity Managementソフトウェアをインストールします。第5.4.1.4項「OIMHOST1およびOIMHOST2へのOracle Identity and Access Managementのインストール」を参照してください。
高可用性LDAP実装が使用可能であることを確認します。
|
注意: これは、LDAPSyncが有効なOIMインストール、およびOracle Access Managementと統合されているOIMインストールでのみ必要です。LDAPSyncの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップしてください。 |
OIMは、Oracle Internet Directory (OID)と直接通信しません。それは、Oracle Virtual Directoryと通信し、Oracle Virtual DirectoryがOIDと通信します。
wlfullclient.jarファイルを、OIMHOST1およびOIMHOST2で作成します。第5.4.1.5項「OIMHOST1およびOIMHOST2でのwlfullclient.jarライブラリの作成」を参照してください。
作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。RCU実行の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』および『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
Oracle WebLogic Serverをインストールするには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
|
注意: 64ビットのプラットフォームで汎用JARファイルを使用してWebLogic Serverをインストールすると、JDKはインストールされません。WebLogic Serverをインストールする前に、JDKを個別にインストールする必要があります。 |
『Oracle Identity and Access Managementインストレーション・ガイド』のOracle SOA Suite (Oracle Identity Managerユーザーのみ)のインストールに関する項を参照してください。
『Oracle Identity and Access Managementインストレーション・ガイド』の「Identity and Access Managementのインストールおよび構成」を参照してください。
Oracle Identity Managerでは、一部の操作にwlfullclient.jarライブラリが必要です。たとえば、Design Consoleでは、サーバー接続にこのライブラリを使用します。このライブラリは出荷されていないため、手動で作成する必要があります。このライブラリは、使用環境のアプリケーション層にあるすべてのマシンのMW_HOME/wlserver_10.3/server/libディレクトリの下に作成することをお薦めします。このライブラリは、OIDHOST1、OIDHOST2、OVDHOST1、OVDHOST2などのディレクトリ層マシンに作成する必要はありません。詳細は、Oracle Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントのプログラミングのWebLogicフル・クライアントの開発に関する説明を参照してください。
wlfullclient.jarファイルを作成するには、次の手順を実行します。
MW_HOME/wlserver_10.3/server/libディレクトリに移動します。
JAVA_HOMEをJDKパスに設定し、JAVA_HOME/binディレクトリがパスに含まれていることを確認します。
次のファイルを実行することによって、wlfullclient.jarファイルを作成します。
java -jar wljarbuilder.jar
ドメインを作成するには、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity Manager、SOAおよびBI Publisher用の新しいWebLogicドメインの作成に関する項を参照してください。
ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、『Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Managementドメインのデータベース・セキュリティ・ストアの構成に関する項を参照してください。
この項では、OIMHOST1におけるインストール後の手順について説明します。次のトピックが含まれます:
boot.propertiesファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。
boot.propertiesファイルを作成する手順は次のとおりです。
OIMHOST1で、次のディレクトリを作成します。
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
例:
$ mkdir -p
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUser password=adminUserPassword
|
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルを編集した後、エントリが暗号化されるように、できるだけ速やかにサーバーを起動してください。 |
管理対象サーバーを起動する前に、ノード・マネージャではStartScriptEnabledプロパティをtrueに設定する必要があります。
これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。
MW_HOME/oracle_common/common/bin
次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST1上のノード・マネージャを起動します。
MW_HOME/wlserver_10.3/server/bin
管理サーバーを起動し、その起動を確認するには、次の手順を実行します。
次のコマンドを実行し、OIMHOST1上の管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
Webブラウザを開いて次のページにアクセスし、管理サーバーの起動が正常に行われたことを確認します。
次の場所にある管理コンソール:
http://oimhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oimhost1.example.com:7001/em
weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。
この項の内容は次のとおりです。
OIMを構成する前に、次のタスクが完了していることを確認してください。
|
注意: この項は、LDAPSyncが有効なOIMインストール、およびOracle Access Managementと統合されているOIMインストールでのみ必要です。LDAPSyncオプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップしてください。 |
Oracle Identity Manager用のディレクトリ・スキーマの拡張
アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。
アイデンティティ・ストアを事前構成するには、OIMHOST1で次の手順を実行します。
環境変数MW_HOME、JAVA_HOMEおよびORACLE_HOMEを設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
次の項目を含む、プロパティ・ファイルextend.propsを作成します。
IDSTORE_HOST : idstore.example.com
IDSTORE_PORT : 389
IDSTORE_BINDDN: cn=orcladmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com
IDSTORE_SEARCHBASE: dc=example,dc=com
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com
説明:
IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。非OIDディレクトリを使用している場合は、Oracle Virtual Directoryのホスト(IDSTORE.example.com)を指定します。
IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
IDSTORE_USERSEARCHBASEは、ユーザーが格納されるディレクトリの場所です。
IDSTORE_GROUPSEARCHBASEは、グループが格納されるディレクトリの場所です。
IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。
IDSTORE_SYSTEMIDBASEは、メイン・ユーザー・コンテナに配置する必要のないユーザーを配置できるディレクトリにあるコンテナの場所です。このような事態はほとんどありませんが、その一例としてOracle Virtual DirectoryアダプタのバインドDNユーザーにも使用されるOIMリコンシリエーション・ユーザーがあげられます。
IAM_ORACLE_HOME/idmtools/binにあるidmConfigToolコマンドを使用して、アイデンティティ・ストアを構成します。
コマンド構文は次のとおりです。
idmConfigTool.sh -preConfigIDStore input_file=configfile
例:
idmConfigTool.sh -preConfigIDStore input_file=extend.props
このコマンドを実行すると、IDストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。
次に、コマンドの出力例を示します。
./preconfig_id.sh Enter ID Store Bind DN password : Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif The tool has completed its operation. Details have been logged to automation.log
ログ・ファイルを確認して、エラーや警告を修正します。
Oracle Identity Manager用のユーザーとグループの作成
oimadminユーザーをアイデンティティ・ストアに追加して、そのユーザーをOIM管理者グループに割り当てる場合。また、リコンシリエーションを実行するために、標準の場所cn=Users以外にもユーザーを作成します。Oracle Virtual Directoryを使用したディレクトリに直接接続するときには、このユーザーをバインドDNとして選択することをお薦めします。
|
注意: このコマンドでは、アイデンティティ・ストアに予約用のコンテナも作成します。 |
xelsysadmユーザーをアイデンティティ・ストアに追加して、そのユーザーを管理グループに割り当てるには、OIMHOST1で次のタスクを実行します。
環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
IDM_HOMEをIDM_ORACLE_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
次の項目を含む、プロパティ・ファイルoim.propsを作成します。
IDSTORE_HOST : idstore.example.com
IDSTORE_PORT : 389
IDSTORE_BINDDN : cn=orcladmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE:cn=Users,dc=example,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com
IDSTORE_SEARCHBASE: dc=example,dc=com
POLICYSTORE_SHARES_IDSTORE: true
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com
IDSTORE_OIMADMINUSER: oimadmin
IDSTORE_OIMADMINGROUP:OIMAdministrators
説明:
IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。OVDではなく、バックエンド・ディレクトリを指定します。
IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
IDSTORE_OIMADMINUSERは、OIMコンソールにログインするために使用する、管理ユーザーの名前です。
IDSTORE_OIMADMINGROUPは、OIM管理ユーザーを保持するために作成するグループの名前です。
IDSTORE_USERSEARCHBASEは、ユーザーを配置するアイデンティティ・ストアの場所です。
IDSTORE_GROUPSEARCHBASEは、グループを配置するアイデンティティ・ストアの場所です。
IDSTORE_SYSTEMIDBASEは、OIMリコンシリエーション・ユーザーを配置するディレクトリの場所です。
POLICYSTORE_SHARES_IDSTOREは、ポリシー・ストアとアイデンティティ・ストアが同じディレクトリに存在する場合にはtrueを設定します。そうでない場合は、falseを設定します。
アイデンティティ・ストアを構成します。IAM_ORACLE_HOME/idmtools/binにあるidmConfigToolに移動します。
idmConfigTool.sh -prepareIDStore mode=OIM input_file=configfile
例:
idmConfigTool.sh -prepareIDStore mode=OIM input_file=oim.props
このコマンドを実行すると、システムによってアカウントのパスワードを求めるプロンプトが表示され、アカウントに割り当てるパスワードが要求されます。
IDSTORE_OIMADMINUSER oimadmin
oimadminは、OIM構成の一部として作成したアカウントと同じ値を設定するようにお薦めします。
次に、コマンドの出力例を示します。
Enter ID Store Bind DN password : *** Creation of oimadmin *** Apr 5, 2011 4:58:51 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_user_template.ldif Enter User Password for oimadmin: Confirm User Password for oimadmin: Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_template.ldif Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_member_template.ldif Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_groups_acl_template.ldif Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_reserve_template.ldif *** Creation of Xel Sys Admin User *** Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_user_template.ldif Enter User Password for xelsysadm: Confirm User Password for xelsysadm: The tool has completed its operation. Details have been logged to /home/oracle/idmtools/oim.log
ログ・ファイルを確認して、エラーや警告を修正します。
SOA管理対象サーバーのCoherence構成を更新するには、次の手順を実行します。
管理コンソールにログインします。
左上隅の「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。
「サーバーの起動」タブをクリックします。
「引数」フィールドで、WLS_SOA1とWLS_SOA2について次のように入力します。
WLS_SOA1について、改行を入れず、1行で次のように入力します。
-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1
WLS_SOA2について、改行を入れず、1行で次のように入力します。
-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1
「保存」をクリックして、変更をアクティブ化します。
管理コンソールから、WLS_SOA1を開始します。
OIM管理対象サーバーを起動する前に、OIMサーバー・インスタンスを構成する必要があります。これらの構成手順を実行するのは、一度のみ(たとえば、ドメインを最初に作成するとき)です。Oracle Identity Management構成ウィザードによって、OIMメタデータがデータベースにロードされ、インスタンスが構成されます。
構成ウィザードを実行する前に、次を検証する必要があります。
管理サーバーが起動されて、実行中であること。
第5.4.5.2項「CoherenceクラスタのためのCoherenceの構成の更新」の説明に従って、CoherenceクラスタのためのCoherence構成を更新します。
wls_soa1が実行中であること。
環境変数DOMAIN_HOMEおよびWL_HOMEが現在のシェル内で設定されていないこと。
Oracle Identity Managementの構成ウィザードは、Identity ManagementのOracleホームの下にあります。次のように入力します。
IAM_ORACLE_HOME/bin/config.sh
OIM構成ウィザードを実行するには、次の手順を実行します。
「ようこそ」画面で、「次へ」をクリックします。
構成するコンポーネント画面で、OIMサーバーを選択します。トポロジに必要な場合は、「OIM Design Console」を選択します。
「次へ」をクリックします。
「データベース」画面で、次の値を入力します。
接続文字列: OIMデータベースの接続文字列。例:
oimdbhost1-vip.example.com:1521:oimdb1^oimdbhost2-vip.example.com:1521:oimdb2@oim.example.com
OIMスキーマ・ユーザー名: HA_OIM
OIMスキーマのパスワード: password
MDSスキーマ・ユーザー名: HA_MDS
MDSスキーマのパスワード: password
「次へ」を選択します。
「Weblogic管理サーバー」画面で、次の詳細を入力します。
URL: 管理サーバーに接続するためのURLです。例: t3://oimhost1.example.com:7001。
ユーザー名: weblogic
パスワード: weblogicユーザーのパスワードです。
「次へ」をクリックします。
「OIMサーバー」画面で、次の値を入力します。
OIM管理者パスワード: OIM管理者のパスワード。これは、xelsysadmユーザーのパスワードです。このパスワードは、事前にidmconfigtoolで入力したパスワードと同じにします。
パスワードの確認: パスワードを確認するためのものです。
OIM HTTP URL: OIMサーバーのリバース・プロキシURL。これは、OIM用のOHSサーバーのフロントエンドに配置されているハードウェア・ロード・バランサのURLです。例: http://oiminternal.example.com:80。
キー・ストア・パスワード: キー・ストア・パスワードです。パスワードには大文字と数字をそれぞれ1文字含める必要があります。例: MyPassword1
キーストア・パスワードの確認: キーストア・パスワードをもう一度入力します。
スイート統合のOIMの有効化: このチェック・ボックスは、OAMまたはOAM-OAAM統合のOIMを構成する場合にのみ選択します。
「次へ」をクリックします。
「LDAPサーバー」画面で、次のLDAPサーバーの詳細を指定します。
ディレクトリ・サーバー・タイプ: ディレクトリ・サーバーのタイプです。OID、ACTIVE_DIRECTORY、IPLANETまたはOVDを選択します。デフォルトはOIDです。
ディレクトリ・サーバーID: ディレクトリ・サーバーのIDです。
サーバーURL: LDAPサーバーにアクセスするためのURLです。例: Oracle Virtual Directory Serverを使用する場合はldap://ovd.example.com:389、Oracle Internet Directoryを使用する場合はldap://oid.example.com:389。
サーバーのユーザー: サーバーに接続するためのユーザー名前。例: cn=orcladmin·
サーバー・パスワード: LDAPサーバーに接続するためのパスワード。
サーバー検索DN: 検索DN。例: dc=example,dc=com
「次へ」をクリックします。
LDAPサーバー(続き)画面で、次のLDAPサーバー詳細を入力します。
LDAPロール・コンテナ: ロール・コンテナのDN (このコンテナにOIMロールが格納されています)。例: cn=Groups,dc=example,dc=com
LDAPユーザー・コンテナ: ユーザー・コンテナのDN (このコンテナにOIMユーザーが格納されています)。例: cn=Users,dc=example,dc=com
ユーザー予約コンテナ: ユーザー予約コンテナのDNです。
|
注意: 「Oracle Identity Manager用のユーザーとグループの作成」の手順のidmconfigtoolで作成したコンテナDN値と同じ値を使用してください。 |
「次へ」をクリックします。
Remote Manager画面で、次の値を指定します。
|
注意: この画面は、ステップ2でRemote Managerユーティリティを選択した場合にのみ表示されます。 |
サービス名: HA_RManager
RMIレジストリ・ポート: 12345
リスニング・ポート(SSL): 12346
「構成サマリー」画面で、サマリー情報を確認します。
「構成」をクリックし、Oracle Identity Managerインスタンスを構成します。
「構成の進行状況」画面で、構成が正常に完了すると、「次へ」をクリックします。
「構成が完了しました」画面で、構成されたOracle Identity Managerインスタンスの詳細を確認します。
「終了」をクリックし、Configuration Assistantを終了します。
OIMHOST1で管理対象サーバーを起動するには、次の手順を実行します。
管理コンソールを使用して、OIMHOST1上で管理サーバーおよびSOA管理対象サーバーを停止します。
DOMAIN_HOME/binディレクトリの下にあるstartWebLogic.shスクリプトを使用して、OIMHOST1上の管理サーバーを起動します。例:
/u01/app/oracle/admin/OIM/bin/startWebLogic.sh > /tmp/admin.out 2>&1 &
管理コンソールを開いて、管理サーバーが正常に起動したことを確認します。
管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。
管理コンソールを使用してWLS_BIP1管理対象サーバーを起動します。
管理コンソールを使用して、WLS_OIM1管理対象サーバーを起動します。
WebブラウザでOracle Identity Managerコンソールを開くことによって、OIMHOST1上のOracle Identity Manager管理対象サーバーのインスタンスを検証します。
Oracle Identity ManagerコンソールのURLは、次のとおりです。
http://identityvhn1.example.com:14000/identity
xelsysadmパスワードを使用してログインします。
OIMHOST1で構成を完了したら、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍することにより、OIMHOST1の構成をOIMHOST2に伝播できます。
|
注意: 構成をOIMHOST2に伝播する前に、OIMHOST1上の管理対象サーバーをすべてクリーン・シャット・ダウンすることをお薦めします。 |
OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍するには、次の手順を実行します。
OIMHOST1上で、ORACLE_HOME/oracle_common/common/binディレクトリにあるpackユーティリティを呼び出します。
pack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
template =/u01/app/oracle/admin/templates/oim_domain.jar -
template_name="OIM Domain" -managed=true
前の手順で作成したoim_domain.jarファイルは、次のディレクトリにあります。
/u01/app/oracle/admin/templates
oim_domain.jarをOIMHOST1からOIMHOST2上の一時ディレクトリにコピーします。
OIMHOST2上で、MW_HOME/oracle_common/common/binディレクトリにあるunpackユーティリティを呼び出し、その一時ディレクトリにあるoim_domain.jarファイルの場所を指定します。
unpack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
template=/tmp/oim_domain.jar
この項の内容は次のとおりです。
管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャのStartScriptEnabledプロパティをtrueに設定する必要があります。
これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。
MW_HOME/oracle_common/common/bin
次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST2上のノード・マネージャを起動します。
MW_HOME/wlserver_10.3/server/bin
OIMHOST2で管理対象サーバーを起動するには、次の手順を実行します。
管理コンソールを表示して、管理サーバーが正常に起動されたことを確認します。
管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。
管理コンソールを使用してWLS_BIP2管理対象サーバーを起動します。
管理コンソールを使用して、WLS_OIM2管理対象サーバーを起動します。WLS_OIM2管理対象サーバーを起動する前に、WLS_SOA2管理対象サーバーを起動してください。
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パスワードを使用してログインします。
BI Publisherを構成する手順は次のとおりです。
すべてのBIサーバーで同じBI構成が使用されていることを確認します。これを行うには、DOMAIN_HOME/config/bipublisher/repositoryディレクトリの内容を構成フォルダの共有場所にコピーします。
|
注意: フォルダの場所は、両方のホストが各自の同じマウント・ポイントでアクセス可能な共有記憶域(NFSまたはクラスタ・ファイル・システム)上にあれば、どの場所を使用しても構いません。 |
OIMHOST1で管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「サーバー構成」を選択します。
「構成フォルダ」の「パス」フィールドで、構成フォルダの共有場所を入力します。
「カタログ」の下の「BI Publisherリポジトリ」フィールドに、BI Publisherリポジトリの共有場所を入力します。変更を適用します。
BIが実行されている管理対象サーバーごとに、前述の手順を繰り返します。
BI Publisherアプリケーションを再起動するには:
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「デプロイメント」をクリックして、bipublisher(11.1.1)を選択します。
「停止」をクリックしてから、「作業完了時」または「ただちに強制停止」を選択します。
アプリケーションが停止している場合は、「起動」をクリックしてから「すべてのリクエストを処理」を選択します。
BI Publisherに再度ログインして、構成変更が正しく行われたことを確認します。
|
注意: 間違った共有構成フォルダのパスを入力すると、BI Publisherを再起動した後のログイン時に、次のエラーが表示されることがあります。
|
次の手順を続行します。
スケジューラ構成オプションを設定するには、次の手順を実行します。
OIMHOST1で管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。
「システム・メンテナンス」で「スケジューラ構成」を選択します。
「クォーツ・クラスタリング」を「スケジューラ選択」で選択して、「適用」をクリックします。
この手順では、すべての永続ストアの場所を両方のノードから参照できるディレクトリに構成します。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。
管理コンソールにログインします。「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「チェンジ・センター」で「ロックして編集」をクリックします。既存のファイル・ストア(BipJmsStoreなど)をクリックして、ターゲットを確認します。WLS_BIP2である場合、新しいファイル・ストアはWLS_BIP1をターゲット指定する必要があります。
「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。
BipJmsStore1などの名前を入力して、WLS_BIP1をターゲット指定します。OIMHOST1およびOIMHOST2がアクセスできるように共有記憶域にあるディレクトリを入力します。
ORACLE_BASE/admin/domain_name/bi_cluster/jms
「OK」をクリックし、「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSサーバー」ノードをクリックします。
チェンジ・センターの「ロックして編集」をクリックして、「新規」をクリックします。
BipJmsServer1などの名前を入力します。「永続ストア」ドロップダウン・リストで、「BipJmsStore1」を選択して、「次へ」をクリックします。
「WLS_BIP1」をターゲットとして選択します。「終了」→「変更のアクティブ化」をクリックします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。
「チェンジ・センター」で「ロックして編集」をクリックします。
「BipJmsResource」→「サブデプロイメント」タブをクリックします。「サブデプロイメント」で「BipJmsSubDeployment」を選択します。
サブデプロイメントの追加ターゲットとして、新しいBI Publisher JMSサーバーBipJmsServer1を追加します。
「保存」→「変更のアクティブ化」をクリックします。
|
注意: 高可用性設定では、BI、OIMおよびSOAノードのクロックの同期を維持する必要があります。 |
BI Publisherに対してJMS構成を検証するには、第5.4.10.3項「BI Publisher Schedulerの構成の検証」の手順に従います。
この手順に従い、BI Publisher SchedulerのJMS共有一時ディレクトリを検証します。この手順は、1つのOIMHOST (OIMHOST1またはOIMHOST2)でのみ実行します。
BI Publisher Schedulerの構成を検証する手順は次のとおりです。
次のどちらかのURLにアクセスしてBI Publisherにログインします。
http://OIMHOST1VHN1:9704/xmlpserver http://OIMHOST2VHN1:9704/xmlpserver
「管理」をクリックし、「システム・メンテナンス」の下の「スケジューラ構成」をクリックして「スケジューラ構成」ページを開きます。
共有記憶域のあるディレクトリを入力して、「共有ディレクトリ」を更新します。この共有記憶域には、OIMHOST1およびOIMHOST2の両方からアクセスできます。
「JMSのテスト」をクリックします。
|
注意: テストの成功を示す確認メッセージが表示されない場合は、JNDI URLがcluster:t3://bi_clusterに設定されていることを確認します。 |
「適用」をクリックします。スケジューラのステータスを「スケジューラ診断」タブでチェックします。
WLS_BIP1およびWLS_BIP2を再起動します。
詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』を参照してください。
|
注意: この項は、LDAPSyncが有効なOIMインストール、およびOracle Access Managementと統合されているOIMインストールでのみ必要です。LDAP同期オプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップできます。 |
現在のリリースでは、LDAPConfigPostSetupスクリプトを使用すると、LDAPSync関連の増分リコンシリエーション・スケジューラ・ジョブがすべて有効になります。これらのジョブはデフォルトでは無効です。LDAP構成ポストセットアップ・スクリプトは、IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあります。スクリプトを実行する手順は、次のとおりです。
IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあるldapconfig.propsファイルを編集して、次の値を指定します。
| パラメータ | 値 | 説明 |
|---|---|---|
OIMProviderURL |
t3://OIMHOST1VHN.example.com:14000,OIMHOST2VHN.example.com:14000 |
Oracle Identity Manager管理対象サーバーのリスト |
LDAPURL |
Oracle Virtual DirectoryインスタンスのURL (例: ldap://idstore.example.com:389) |
アイデンティティ・ストアのURL。Oracle Virtual Directoryを使用してIDストアにアクセスする場合のみ必要 |
LDAPAdminUserName |
cn=oimadmin,cn=systemids,dc=example,dc=com |
アイデンティティ・ストアに接続するユーザーの名前。アイデンティティ・ストアがOracle Virtual Directoryに存在する場合のみ必要です。このユーザーは、cn=Users,dc=example,dc=comに配置しないでください。 |
LIBOVD_PATH_PARAM |
MSERVER_HOME/config/fmwconfig/ovd/oim |
Oracle Virtual Directoryを使用してアイデンティティ・ストアにアクセスしない場合は必要です。 |
|
注意: usercontainerName、rolecontainernameおよびreservationcontainernameは、この手順で使用しません。 |
ファイルを保存します。
次のように、JAVA_HOME、WL_HOME、APP_SERVER、OIM_ORACLE_HOMEおよびDOMAIN_HOME環境変数を設定します。
JAVA_HOMEをMW_HOMEJRE-JDK_versionに設定
WL_HOMEをMW_HOME/wlserver_10.3に設定
APP_SERVERをweblogicに設定
OIM_ORACLE_HOMEをIAM_ORACLE_HOMEに設定
DOMAIN_HOMEをMSERVER_HOMEに設定
LDAPConfigPostSetup.shを実行します。このスクリプトでは、LDAPの管理者パスワードとOIMの管理者パスワードが要求されます。例:
IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh path_to_property_file
例:
IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh IAM_ORACLE_HOME/server/ldap_config_util
この高可用性トポロジでは、管理対象サーバー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をリスニングします。
次の手順を実行すると、WLS_OIM1、WLS_SOA1、WLS_OIM2、およびWLS_SOA2管理対象サーバーのサーバー移行を行うことができ、これにより、サーバーまたはプロセスの障害時に、管理対象サーバーは別のノードにフェイルオーバーできます。
ステップ1: サーバー移行リース表のユーザーと表領域を設定する
手順2: GridLinkデータ・ソースを作成する
ステップ3: ノード・マネージャのプロパティ・ファイルを編集する
ステップ5: サーバー移行ターゲットを構成する
ステップ6: サーバー移行をテストする
最初の手順では、サーバー移行リース表のユーザーと表領域を設定します。
|
注意: 同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用してください。この場合、データベース・リース用にデータ・ソースおよびGridLinkデータ・ソースを再作成する必要はありませんが、これらをサーバー移行用に構成しているクラスタにターゲット指定しなおす必要があります。 |
leasingという名前の表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。
SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;
|
注意: Oracle Managed Files (OMF)を構成した場合は、 |
leasingという名前のユーザーを作成し、リース表領域に割り当てます。
SQL> create user leasing identified by password; SQL> grant create table to leasing; SQL> grant create session to leasing; SQL> alter user leasing default tablespace leasing; SQL> alter user leasing quota unlimited on LEASING;
leasing.ddlスクリプトを使用してリース表を作成します。
WL_HOME/server/db/oracle/920ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。
leasingユーザーとしてデータベースに接続します。
SQL*Plusでleasing.ddlスクリプトを実行します。
SQL> @Copy_Location/leasing.ddl;
|
注意: 次のエラーは正常です。無視して構いません。
SP2-0734: unknown command beginning "WebLogic S..." - rest of line ignored.
SP2-0734: unknown command beginning "Copyright ..." - rest of line ignored.
DROP TABLE ACTIVE
*
ERROR at line 1:
ORA-00942:table or view does not exist
|
GridLinkデータ・ソースを作成するには、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのGridLinkデータ・ソースの作成に関する項を参照してください。**
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、ethnとなります。 |
NetMask: 浮動IPのインタフェースのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります(255.255.255.0は一例です)。実際の値は、ネットワークにより異なります。
UseMACBroadcast: ARPパケットの送信時にノードのMACアドレスを使用するかどうか、つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。
これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。(これを行うには、ノード・マネージャを再起動する必要があります。)ノード・マネージャの出力で、次のようなエントリが表示されることを確認します。
... StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 ...
サーバー移行を構成するノードごとにwlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は、次のとおりです。
ノード・マネージャの実行に使用するユーザー・アカウントのログイン・プロファイルを変更して、ノード・マネージャ・プロセスのPATH環境変数にwlsifconfig.shスクリプトとwlscontrol.shスクリプトおよびnodemanager.domains構成ファイルが格納されているディレクトリを必ず含めるようにします。PATH環境変数に次のファイルが含まれていることを確認します。
wlsifconfig.shスクリプトに対するsudo構成権限を付与します。
パスワード・プロンプトを使用しないで機能するsudoを構成します。
セキュリティ上の理由から、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定することをお薦めします。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。
WebLogicユーザー(oracle)に、パスワードによる制限なしのsudo権限を付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
WebLogicユーザーがこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
|
注意: この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。 |
まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
「名前」列で、移行を構成するクラスタをクリックします。
「移行」タブをクリックします。
「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
サーバー移行の候補となるマシンを設定します。このタスクは、次の手順に従って、すべての管理対象サーバーについて実行する必要があります。
管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
|
ヒント: 「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックして、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動し、サーバーが実行されているマシンを表示します。サーバーが自動的に移行される場合、これは実際の構成とは異なります。 |
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックしてから、「変更のアクティブ化」をクリックします。
追加の管理対象サーバーに対して、前述の手順を繰り返します。
管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。
サーバー移行が適切に機能していることを確認する手順は次のとおりです。
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管理対象サーバーのサーバー移行をテストします。
表5-2は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。
表5-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 |
管理コンソールからの検証
管理コンソールで移行を検証する手順は、次のとおりです。
管理者の資格証明を使用して、管理コンソール(http://oimhost1.example.com:7001/console)にログインします。
左側のコンソールで、「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。
|
注意: サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、管理コンソールで管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。 |
各管理対象サーバーにはトランザクション・ログがあり、管理対象サーバーによって調整された、未完了の可能性のある、進行中のトランザクションについての情報が格納されます。WebLogic Serverは、このトランザクション・ログを使用して、システムやネットワーク障害からリカバリします。トランザクション回復サービスの移行機能を活用するには、クラスタ内のすべての管理対象サーバーがアクセス可能な場所にトランザクション・ログを格納します。共有記憶域がないと、サーバーに障害が発生したときにクラスタ内の他のサーバーがトランザクション・リカバリを実行できず、操作の再試行が必要になることがあります。
|
注意: ネットワーク接続ストレージ(NAS)デバイスまたはストレージ・エリア・ネットワーク(SAN)上の場所をお薦めします。 |
OIMおよびSOAサーバーのデフォルト永続ストアの場所を設定する手順は次のとおりです。
管理者の資格証明を使用して、管理コンソール(http://oimhost1.example.com:7001/console)にログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)を選択します。サーバーの「設定」ページが開き、「構成」タブが表示されます。
「構成」タブの「サービス」サブタブを選択します(トップレベルの「サービス」タブではありません)。
「デフォルト・ストア」セクションで、デフォルトの永続ストアでデータ・ファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようにする必要があります。
WLS_SOA1およびWLS_SOA2サーバーについては、次のようなディレクトリ構造を使用します。
ORACLE_BASE/admin/domainName/soaClusterName/tlogs
WLS_OIM1およびWLS_OIM2サーバーについては、次のようなディレクトリ構造を使用します。
ORACLE_BASE/admin/domainName/oimClusterName/tlogs
「保存」をクリックします。
|
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の管理対象サーバーで利用可能な永続記憶域ソリューション上の場所を指定します。WLS_SOA1、WLS_SOA2、WLS_OIM1、およびWLS_OIM2は、このディレクトリにアクセスできる必要があります。 |
WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールします。
この項では、OIMを構成してOracle Web Tierと連携する方法について説明します。
次のタスクが実行済であることを確認します。
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は内部コールバック用で、顧客向けではありません。
WEBHOST1とWEBHOST2上の各Webサーバーで、oim.confという名前のファイルをORACLE_INSTANCE/config/OHS/COMPONENT/moduleconfディレクトリに作成します。
このファイルには次の情報が記載されている必要があります。
# oim admin console(idmshell based)
<Location /admin>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# oim self and advanced admin webapp consoles(canonic webapp)
<Location /oim>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /identity>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /sysadmin>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
<Location /sodcheck>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster soavhn1.example.com:8001,soavhn2.example.com:8001
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Callback webservice for SOA. SOA calls this when a request is approved/rejected
# Provide the SOA Managed Server Port
<Location /workflowservice>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# xlWebApp - Legacy 9.x webapp (struts based)
<Location /xlWebApp>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Nexaweb WebApp - used for workflow designer and DM
<Location /Nexaweb>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# used for FA Callback service.
<Location /callbackResponseService>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# spml xsd profile
<Location /spml-xsd>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /HTTPClnt>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /reqsvc>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /integration>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster soavhn1.example.com:8001,soavhn2.example.com:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /provisioning-callback>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /xmlpserver>
SetHandler weblogic-handler
WLCookieName JSESSIONID
WebLogicCluster oimvhn1.example.com:9704,oimvhn2.example.com:9704
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /CertificationCallbackService>
SetHandler weblogic-handler
WLCookieName JSESSIONID
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
ORACLE_INSTANCE/config/OHS/COMPONENT/moduleconfにvirtual_hosts.confというファイルを作成します。このファイルは、次の情報を含む必要があります。
|
注意: COMPONENTは通常、ohs1またはohs2です。ただし、この名前はOHSのインストール時の選択内容によって異なります。 |
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName http://sso.example.com:7777 RewriteEngine On RewriteOptions inherit UseCanonicalName On </VirtualHost> <VirtualHost *:7777> ServerName http://oiminternal.example.com:80 RewriteEngine On RewriteOptions inherit UseCanonicalName On </VirtualHost>
WEBHOST1とWEBHOST2の両方でファイルを保存します。
WEBHOST1およびWEBHOST2の両方で、Oracle HTTP Serverインスタンスを停止および起動します。
Oracle HTTP Serverが適切に構成されていることを検証する手順は次のとおりです。
Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。
http://sso.example.com:7777/identity
Oracle Identity Managerコンソール・ログイン・ページが表示されます。
xelsysadmユーザーの資格証明を使用してOracle Identity Managerコンソールにログインします。
高可用性環境では、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呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。
OIMの高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。スケール・アウトするには、第5.4.19項「Oracle Identity Managerのスケール・アウト」を参照してください。
この場合は、SOAおよびBIコンポーネントを使用して構成されている管理対象サーバーを実行するノードが存在しています。ノードには次のものが含まれます。
Middlewareホーム
Oracleホーム(SOA)
Oracleホーム(BIP)
既存の管理対象サーバーのドメイン・ディレクトリ
新しいWLS_OIM、WLS_SOAおよびWLS_BIP管理対象サーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。OIM、SOAおよびBIPのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
この手順では、OIM、SOAおよびBIP管理対象サーバーのクローンを作成する方法について説明します。これらのコンポーネント・タイプの3つすべてでも、2つでも、そのうちの1つがOIMであればクローンを作成できます。
次のことに注意してください。
この手順は、WLS_OIM、WLS_SOAおよびWLS_BIPについて説明しています。しかし、3つすべてのコンポーネントをスケール・アップする可能性は少ないです。手順ごとに、使用環境でスケール・アップする対象のコンポーネントを選択してください。また、一部のコンポーネントには適用されない手順もあります
JMSサーバーの永続ストア用の共有記憶域ディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。
永続ストアのパスを指定するときは必ず、共有記憶域上のディレクトリを指定する必要があります
トポロジをスケール・アップするには:
管理コンソールで、WLS_OIM1、WLS_SOA1またはWLS_BIP1のクローンを作成します。クローンを作成する管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理コンソールから「環境」→「サーバー」を選択します。
クローンを作成する管理対象サーバーを選択します。
「クローンの作成」を選択します。
新しい管理対象サーバーにWLS_OIMn、WLS_SOAnまたはWLS_BIPnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
残りの手順では、WLS_OIM1、WLS_SOA1およびWLS_BIP1がすでに実行されているOIMHOST1に新しい管理対象サーバーを追加することを前提にしています。
リスニング・アドレスとして、新しい管理対象サーバーのホスト名またはIPを割り当てます。サーバー移行の使用を計画している場合は、VIP (浮動IP)を使用して、管理対象サーバーを別のノードに移動できるようにします。既存の管理対象サーバーで使用されているVIPとは別のVIPを使用してください。
新しい管理対象サーバーにOIM、SOA、BIP、BPM、UMS、JRFWSAsyncおよびPS6SOAのJMSサーバーを作成します。
管理コンソールで、OIM、SOAまたはBIPのJMSサーバーの新しい永続ストアを作成し、SOAJMSFileStore_nやBipJmsStorenのような名前を付けます。ストアのパス(共有記憶域上のディレクトリ)を指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
OIM、SOAまたはBIPの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n、BipJmsServern)。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
JMSの新しいJMSサーバーを作成します(たとえば、BPMJMSServer_n)。それを新しい管理対象サーバー(WLS_SOAn)にターゲット指定します。
新しいBipJmsServerの永続ストアを作成します(たとえば、BipJmsStore_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms/BipJmsStore_n
新しい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を割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
新しいPS6SOAJMSServerの永続ストアを作成します(たとえば、PS6SOAJMSFileStore_auto_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms/PS6SOAJMSFileStore_auto_n
PS6SOAのJMSサーバーを作成します(たとえば、PS6SOAJMSServer_auto_n)。このJMSサーバーに対して、PS6SOAJMSFileStore_auto_nを使用します。PS6SOAJMSServer_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を追加します。「保存」をクリックします
新しいPS6SOA JMSサーバーが含まれるように、PS6SOAJMSModuleのSubDeploymentターゲットを更新します。「サービス」ノード、「メッセージング」ノードの順に開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「PS6SOAJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント「PS6SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、PS6SOAJMSServer_auto_nを追加します。「保存」をクリックします。
新しいBPM JMSサーバーが含まれるように、BPM JMSモジュールのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「BPMJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、BIPJMSServerXXXXXXサブデプロイメントをクリックし、BPMJMSServer_nを追加します。「保存」をクリックします。
(SOA管理対象サーバーのみ)コンポジットのデプロイ用にOracle Coherenceを構成します。
|
注意: サーバーのlocalhostフィールドを、新しいサーバーのリスニング・アドレスでのみ置き換えます。例:
|
新しいサーバーのトランザクション永続ストアを、他のノードから参照可能な共有記憶域の場所に構成します。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアのパスを入力します。
新しい管理対象サーバーのホスト名検証を無効にします(WLS_SOAn管理対象サーバーの起動と検証を行う前に実行する必要があります)。SOAHOSTnで管理サーバーとノード・マネージャとの通信用のサーバー証明書を構成した後で、これを再度有効化できます。(新しい管理対象サーバーのクローン元となった)ソース・サーバーで、ホスト名の検証が無効化されている場合、これらの手順は不要です。ホスト名の検証の設定はクローンされたサーバーに伝播されます。
ホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールの「ドメイン構造」ウィンドウで「環境」ノードを展開します。
「サーバー」をクリックします。表の「名前」列で「WLS_SOAn」を選択します。
「SSL」タブをクリックします。「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新たに作成した管理対象サーバーが起動していることを確認します。
新たに作成した管理対象サーバーのアプリケーションにアクセスし、それが動作していることを確認します。OIMおよびBI Publisher用のログイン・ページが開きます。SOAの場合は、HTTP基本認証が開きます。
管理コンソールで、「サービス」→「外部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_SOAnのように入力します。必要に応じてSOAをBIPに変更してください。
ノード・マネージャのコンソールに、管理対象サーバーの浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
OHS構成ファイルを編集して、新しい管理対象サーバーを追加します。第5.4.19.1項「新しい管理対象サーバーを認識するためのOracle HTTP Serverの構成」を参照してください。
トポロジのスケール・アウトでは、ソフトウェアで構成された新しい管理対象サーバーを新しいノードに追加します。
|
注意: この手順の各ステップは、WLS_OIM、WLS_SOAおよびWLS_BIPについて説明しています。しかし、3つすべてのコンポーネントをスケール・アップする可能性は少ないです。手順ごとに、使用環境でスケール・アップする対象のコンポーネントを選択してください。一部のコンポーネントには適用されない手順もあります。 |
スケール・アウトする前に、次の要件を満たしていることを確認してください。
OIM、SOAまたはBIPで構成された管理対象サーバーを実行している既存のノードがトポロジ内に存在していること。
新しいノードがWebLogic Server、SOAおよびBIPの既存のホーム・ディレクトリにアクセスできること。(新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic Serverやコンポーネント・バイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります。)
|
注意: 共有記憶域に既存のインストールが存在しない場合は、WebLogic ServerおよびSOAを新しいノードにインストールする必要があります。 |
|
注意: ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを追加する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、次の手順でuser_home/bea/beahomelistを編集します。 |
トポロジをスケール・アウトするには:
新しいノードで、既存のMiddlewareホームをマウントします。SOAまたはBIP (あるいはその両方)のインストールとドメイン・ディレクトリを追加して、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内の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またはWLS_BIP1のクローンを作成します。クローンを作成する管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
OIM、SOAおよびBIPのクローンを作成するには、次の手順を実行します。
管理コンソールから「環境」→「サーバー」を選択します。
クローンを作成する管理対象サーバーを選択します。
「クローンの作成」を選択します。
新しい管理対象サーバーにWLS_OIMn、WLS_SOAnまたはWLS_BIPnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
|
注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバーでその管理対象サーバーのリスニング・アドレスに使用するホスト名またはIPを割り当てます。
このサーバーに対してサーバー移行の使用を計画している場合(推奨)、これはサーバーのVIP (浮動IP)であることが必要です。このVIPは、既存の管理対象サーバーとは別のものを使用してください。
新しい管理対象サーバーにSOA、OIM (該当する場合)、UMS、BPM、JRFWSAsyncおよびPS6SOAのJMSサーバーを作成します。
管理コンソールで、OIM、SOAまたはBIPのJMSサーバーの新しい永続ストアを作成し、SOAJMSFileStore_nやBipJmsStorenのような名前を付けます。ストアのパス(共有記憶域上のディレクトリ)を指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
OIM、SOAまたはBIPの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n、BipJmsServern)。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
JMSの新しいJMSサーバーを作成します(たとえば、BPMJMSServer_n)。それを新しい管理対象サーバー(WLS_SOAn)にターゲット指定します。
新しいBipJmsServerの永続ストアを作成します(たとえば、BipJmsStore_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms/BipJmsStore_n
新しい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を割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
新しいPS6SOAJMSServerの永続ストアを作成します(たとえば、PS6SOAJMSFileStore_auto_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms/PS6SOAJMSFileStore_auto_n
PS6SOAのJMSサーバーを作成します(たとえば、PS6SOAJMSServer_auto_n)。このJMSサーバーに対して、PS6SOAJMSFileStore_auto_nを使用します。PS6SOAJMSServer_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を追加します。「保存」をクリックします
新しいPS6SOA JMSサーバーが含まれるように、PS6SOAJMSModuleのSubDeploymentターゲットを更新します。「サービス」ノード、「メッセージング」ノードの順に開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「PS6SOAJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント「PS6SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、PS6SOAJMSServer_auto_nを追加します。「保存」をクリックします。
新しいBPM JMSサーバーが含まれるように、BPM JMSモジュールのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「BPMJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、BIPJMSServerXXXXXXサブデプロイメントをクリックし、BPMJMSServer_nを追加します。「保存」をクリックします。
SOAHOST1またはBIPHOST1 (あるいはその両方)でpackコマンドを実行してテンプレート・パックを作成します。たとえば、SOAの場合は次のようにします。
cd ORACLE_COMMON_HOME/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_BASE/product/fmw/soa/common/bin /unpack.sh / -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar
デプロイするコンポジットのOracle Coherenceを構成します。
|
注意: この手順はSOA管理対象サーバーのみに必要で、OIMやBIP管理対象サーバーでは不要です。 |
|
注意: サーバーに対しては、localhostフィールドのみを変更します。localhostを、新しいサーバーのリスニング・アドレスに置き換えます。例:Dtangosol.coherence.localhost=SOAHOST1VHNn |
新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名の検証を無効化します。この操作は管理対象サーバーを起動して検証する前に実行しておく必要があります。管理サーバーとノード・マネージャとの通信用のサーバー証明書を構成した後で、これを再度有効化できます。(新しい管理対象サーバーのクローン元となった)ソース管理対象サーバーで、ホスト名の検証がすでに無効化されている場合、これらの手順は不要です。ホスト名の検証の設定はクローンされたサーバーに伝播されます。
ホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールを開きます。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。
表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
WL_HOME/server/bin/startNodeManager new_node_ip
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新たに作成した管理対象サーバーが起動していることを確認します。
新たに作成した管理対象サーバーのアプリケーションにアクセスし、それが動作していることを確認します。OIMおよびBI Publisher用のログイン・ページが表示されます。SOAの場合は、HTTP基本認証が開きます。
新しい管理対象サーバーに対してサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャおよびネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しい管理対象サーバーの浮動IPが存在します。 |
サーバー移行を構成する手順は次のとおりです。
管理コンソールにログインします。
左側のペインで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印をクリックします。
|
注意: 新しいサーバーの移行ターゲットには、負荷が最小のマシンを指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。
管理対象サーバーを停止します。
管理対象サーバーのPIDに対してkill -9 pidを実行します。ps -ef | grep WLS_SOAnなどを使用して、ノードのPIDを特定します。
ノード・マネージャ・コンソールに、浮動IPが無効になったことを示すメッセージが表示されることを確認します。
ノード・マネージャが新しい管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは、再起動するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動しないことを示すメッセージがノード・マネージャによってログに記録されます。
OHS構成ファイルを編集して、新しい管理対象サーバーを追加します。第5.4.19.1項「新しい管理対象サーバーを認識するためのOracle HTTP Serverの構成」を参照してください。
スケール・アップまたはスケール・アウトを完了するには、oim.confファイルを編集して、新しい管理対象サーバーを追加してから、Oracle HTTP Serverを再起動する必要があります。
ディレクトリORACLE_INSTANCE/config/OHS/component/moduleconfに移動します
oim.confを編集し、新しい管理対象サーバーをWebLogicClusterディレクティブに追加します。この手順は、OIM、SOAまたはBIPubに対して定義されているURLごとに実行する必要があります。製品ごとに個別の<Location>セクションが必要です。また、ポートは管理対象サーバーを参照している必要があります。例:
<Location /oim
SetHandler weblogic-handler
WebLogicCluster
host1.example.com:14200,host2.example.com:14200
</Location>
WEBHOST1およびWEBHOST2で、Oracle HTTP Serverを再起動します。
WEBHOST1>opmnctl stopall WEBHOST1>opmnctl startall WEBHOST2>opmnctl stopall WEBHOST2>opmnctl startall
|
注意: 共有記憶域システムを使用していない場合(推奨)、oim.confを他のOHSサーバーにコピーします。 |
|
注意: デプロイメントを容易にする他のパラメータについては、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』のWebLogic Serverプラグインの一般的なパラメータに関する項を参照してください。 |
