ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド
11gリリース2 (11.1.2.2)
B69538-05
  目次へ移動
目次
前
前 		 次
次		  

5 Oracle Identity Managerコンポーネントの高可用性の構成

この章では、Oracle Identity Managerの高可用性環境を設計およびデプロイする方法について説明します。

Oracle Identity Managerは、アプリケーションおよびディレクトリからユーザー・アカウントを追加、更新および削除するプロセスを自動化するユーザー・プロビジョニングおよび管理ソリューションです。また、誰が何にアクセスしたかを示すきめ細かいレポートを提供することで、法規制コンプライアンスの向上にも寄与します。Oracle Identity Managerは、スタンドアロン製品として、またはOracle Identity and Access Management Suiteの一部として使用可能です。

ユーザー・アイデンティティのプロビジョニングを自動化すると、ITの管理コストを削減し、セキュリティを高めることができます。プロビジョニングは、法規制コンプライアンスにおいても重要な役割を果たします。Oracle Identity Managerの主要機能には、パスワード管理、ワークフローとポリシーの管理、アイデンティティ調整、レポートと監査、アダプタによる拡張性などがあります。

Oracle Identity Managerの機能は、次のとおりです。

Oracle Identity Managerの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドを参照してください。

この項の内容は次のとおりです。

5.1 Oracle Identity Managerコンポーネント・アーキテクチャ

図5-1は、Oracle Identity Managerのアーキテクチャを示しています。

図5-1 Oracle Identity Managerコンポーネント・アーキテクチャ

図5-1の説明が続きます
「図5-1 Oracle Identity Managerコンポーネント・アーキテクチャ」の説明

5.1.1 Oracle Identity Managerコンポーネントの特性

Oracle Identity Manager Serverは、Java EE標準に準拠した、スタンドアロンの自己完結型アイデンティティ管理ソリューションです。ユーザー管理、ワークフローおよびポリシー、パスワード管理、監査およびコンプライアンス管理、ユーザー・プロビジョニング、および組織およびロール管理機能を提供します。

Oracle Identity Managerは、標準Java EEアプリケーションであり、Oracle WebLogic Server上にデプロイされ、データベースを使用してランタイムおよび構成データを格納します。MDSスキーマには構成情報が含まれ、OIMスキーマにはランタイムおよびユーザー情報が格納されます。

Oracle Identity Managerは、RMIを使用してSOA管理対象サーバーに接続し、SOA EJBを呼び出します。

Oracle Identity Managerは、Oracle SOA Suiteのヒューマン・ワークフロー・モジュールを使用して、そのリクエスト・ワークフローを管理します。Oracle Identity Managerは、SOA用のフロントエンドURLであるSOAサーバーのT3 URLを使用してSOAに接続します。クラスタ化されたSOAサーバーでは、ロード・バランサまたはWebサーバーのURLを使用することをお薦めします。ワークフローが完了すると、SOAはOIMFrontEndURLを使用してOracle Identity Manager Webサービスをコールバックします。Oracle SOAは、Oracle Identity Managerとともにデプロイされます。

いくつかのOracle Identity ManagerモジュールはJMSキューを使用します。各キューは、個別のメッセージドリブンBean (MDB)によって処理されます。MDBもOracle Identity Managerアプリケーションの一部です。メッセージ・プロデューサもOracle Identity Managerアプリケーションの一部です。

Oracle Identity Managerは、埋込みOracle Entitlements Serverを使用しますが、これもOracle Identity Managerエンジンの一部です。Oracle Entitlements Server (OES)は、Oracle Identity Manager内部で認可の確認に使用されます。たとえば、ポリシー制約の1つで、特定のロールを持つユーザーのみがユーザーの作成を許可されると決定されているとします。これは、Oracle Identity Managerユーザー・インタフェースを使用して定義します。

Oracle Identity Managerは、スケジュール済アクティビティのためにクォーツ・ベースのスケジューラを使用します。バックグラウンドで実行される様々なスケジュール済アクティビティがあります。たとえば、スケジュール済タスクの1つは、ユーザーの終了日後にそのユーザーを無効化することです。

Oracle Identity Managerは、すべてのレポート作成機能のためにOracle BI Publisherと連携します。BI Publisherは、異なるドメインまたは同じドメインに配置され、単純な静的なURL統合のみで統合されます。BI PublisherとOracle Identity Managerランタイム・コンポーネントとの間に相互作用はありません。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コマンドのリストを参照してください。

5.1.2 ランタイム・プロセス

Oracle Identity Managerは、Oracle WebLogic ServerにnostageアプリケーションとしてデプロイされるJava EEアプリケーションです。Oracle Identity Managerサーバーは、それがデプロイされたWebLogic Serverの起動時に初期化されます。アプリケーションの初期化の一部として、クォーツ・ベースのスケジューラも起動されます。初期化が完了すると、システムはクライアントからリクエストを受信できるようになります。

Remote ManagerおよびDesign Consoleは別にスタンドアロンのユーティリティとして起動する必要があります。

5.1.3 コンポーネントとプロセスのライフサイクル

Oracle Identity Managerは、外部的に管理されるアプリケーションとしてOracle WebLogic Serverにデプロイされます。WebLogic Serverはデフォルトで、Oracle Identity Managerアプリケーションに対する他のライフサイクル・イベントの起動、停止、監視および管理を行います。

Oracle Identity Managerは、標準Java EEアプリケーションであり、アプリケーション・サーバー・コンポーネントが起動した後に起動します。また、Oracle Identity Managerでは、Oracle Identity Managerコンポーネント・メカニズムの一部である認証システムも使用され、それはWebLogic JNDIが初期化されてアプリケーションが起動する前に起動されます。これは、OIM ORACLE_HOMEからロードされます。

Oracle Identity Managerでは、クォーツ・ベースのスケジューラが使用されます。クォーツは、すべてのWebLogic Serverインスタンスでスケジューラ・スレッドを起動します。データベースが、スケジュール済アクティビティの選択と実行のための中央記憶域として使用されます。スケジューラ・インスタンスの1つがジョブを選択した場合、その他のインスタンスがその同じジョブを選択することはありません。

Oracle Identity Managerは、データベースから、サーバー・インスタンスのメモリー内のキャッシュに特定のシステム構成値をキャッシュします。これらのキャッシュは独立してロードされ、サーバー間で共有されません。システム構成が変更されるとキャッシュがクリーンアップされ、これはクラスタ内のすべてのサーバーに通知されます。Oracle Identity Managerは、この目的のためにOSCache、JGroupsを使用します。JGroupsはマルチキャスト・アドレスを使用します。有効なマルチキャスト・アドレスは、インストール中にランダムに生成され、Oracle Identity Managerメタデータ・リポジトリ・ファイルにシードされます。

WebLogicノード・マネージャは、サーバー・プロセスを監視し、障害発生時にそのプロセスを再起動するように構成できます。

Oracle Enterprise Manager Fusion Middleware Controlは、アプリケーションの監視および構成の変更に使用します。

5.1.4 Oracle Identity Managerの起動と停止

Oracle Identity Managerのライフサイクル・イベントは、次に示すコマンド行ツールおよびコンソールを1つ以上使用して管理できます。

  • Oracle WebLogic Scripting Tool (WLST)

  • WebLogic Server管理コンソール

  • Oracle Enterprise Manager Fusion Middleware Control

  • Oracle WebLogicノード・マネージャ

5.1.5 構成アーティファクト

Oracle Identity Managerサーバーの構成は、MDSリポジトリに格納され、MBeanを使用して管理されます。oim-config.xmlファイルがメイン構成ファイルです。OIM構成は、Oracle Enterprise Manager Fusion Middleware Controlまたはコマンド行MDSユーティリティを介してMBeanブラウザを使用して管理します。oim-config.xmlファイルは、MDSリポジトリの/db/oim-config.xmlの場所に格納されています。

MDSユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のMDSユーティリティに関する説明を参照してください。

JMSは、インストーラによってすぐに使用可能な状態に構成されます。JMSキュー、接続プール、データ・ソースなど必要なものはすべて、WebLogicアプリケーション・サーバー上に構成されます。次のキューが、Oracle Identity Managerをデプロイするときに作成されます。

  • oimAttestationQueue

  • oimAuditQueue

  • oimDefaultQueue

  • oimKernelQueue

  • oimProcessQueue

  • oimReconQueue

  • oimSODQueue

Design ConsoleおよびRemote Managerの構成は、xlconfig.xmlに格納されます。

5.1.6 外部依存性

Oracle Identity Managerは、Oracle WebLogic管理対象サーバーにデプロイされるJava EEアプリケーションです。Oracle Identity Managerは、Oracle SOA Suiteのワークリストおよびヒューマン・ワークフロー・モジュールを使用して、そのリクエスト・フローを管理します。Oracle Identity Managerは、外部リポジトリと対話して、構成およびランタイム・データを格納します。Oracle Identity Managerでは、初期化および実行時に、これらのリポジトリが使用可能である必要があります。Oracle Identity Managerの資格証明はすべて、OIMリポジトリに格納されます。Oracle Identity Managerサーバーの機能に必要な外部コンポーネントは次のとおりです。

  • WebLogic Server

    • 管理サーバー

    • 管理対象サーバー

  • データ・リポジトリ

    • 構成リポジトリ(MDSスキーマ)

    • ランタイム・リポジトリ(OIMスキーマ)

    • ユーザー・リポジトリ(OIMスキーマ)

    • SOAリポジトリ(SOAスキーマ)

  • 外部LDAPストア(LDAP同期を使用する場合)

  • BI Publisher

Design Consoleは、管理者が、開発とカスタマイズのために使用するツールです。Design Consoleは、Oracle Identity Managerエンジンと直接通信し、Oracle Identity Managerサーバーが依存するものと同じコンポーネントに依存します。

Remote Managerは、オプションの独立したスタンドアロン・アプリケーションであり、ローカル・システムのカスタムAPIを呼び出します。そのため、それらのカスタムAPIのJARファイルがそのクラスパスに含まれている必要があります。

5.1.7 Oracle Identity Managerのログ・ファイルの場所

Oracle Identity Managerは、Oracle WebLogic ServerにデプロイされるJava EEアプリケーションです。サーバーに関連するログ・メッセージはすべて、サーバーのログ・ファイルに記録され、Oracle Identity Managerに固有のメッセージはすべて、アプリケーションがデプロイされた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を使用して表示できます。

5.2 Oracle Identity Managerの高可用性の概要

この項では、Oracle Identity Managementの高可用性の概要およびOracle Identity Managerの高可用性環境の設計とデプロイについて説明します。


注意:

Oracle Identity Managerを高可用性構成にデプロイする場合は、次のことに注意してください。

  • Oracle Identity ManagerはOracle RACデータベースにデプロイできますが、Oracle RACのフェイルオーバーは、このリリースではOracle Identity Managerに対して透過的ではありません。Oracle RACのフェイルオーバーが発生すると、エンド・ユーザーは、各自のリクエストを再送信する必要がある場合があります。

  • Oracle Identity Managerは常に、SOAクラスタ内で少なくとも1つのノードが使用可能であることを必要とします。SOAクラスタが使用可能でない場合、エンド・ユーザーのリクエストは失敗します。Oracle Identity Managerノードは、失敗したSOA呼出しに対して再試行しません。そのため、SOA呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。

5.2.1 Oracle Identity Managerの高可用性アーキテクチャ

図5-2は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたOracle Identity Managerを示しています。

図5-2 Oracle Identity Managerの高可用性アーキテクチャ

図5-2の説明が続きます
「図5-2 Oracle Identity Managerの高可用性アーキテクチャ」の説明

OIMHOST1では、次のインストールが実行されています。

  • Oracle Identity ManagerインスタンスはWLS_OIM1管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA1管理対象サーバーにインストールされています。

  • Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

  • WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。

OIMHOST2では、次のインストールが実行されています。

  • Oracle Identity ManagerインスタンスはWLS_OIM2管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA2管理対象サーバーにインストールされています。

  • Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

  • OIMHOST1およびOIMHOST2上のWLS_OIM1およびWLS_OIM2管理対象サーバーのインスタンスは、OIM_Clusterクラスタとして構成されています。

  • OIMHOST1およびOIMHOST2上のWLS_SOA1およびWLS_SOA2管理対象サーバーのインスタンスは、SOA_Clusterクラスタとして構成されています。

  • WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OIMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。

図5-2のOracle Identity Managerの高可用性構成では、次の仮想ホスト名が使用されています。

  • 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アドレスを指します。

5.2.2 Oracle Identity Managerクラスタの起動と停止

高可用性アーキテクチャでは、Oracle Identity Managerは、Oracle WebLogicクラスタにデプロイされます。このクラスタには、クラスタのメンバーとして少なくとも2つのサーバーが存在します。

デフォルトでは、WebLogic Serverによって、このアプリケーションに対する様々なライフサイクル・イベントの起動、停止、監視および管理が行われます。Oracle Identity Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

Oracle Identity Managerのライフサイクル・イベントは、次に示すコマンド行ツールおよびコンソールを1つ以上使用して管理できます。

  • WebLogic Server管理コンソール

  • Oracle Enterprise Manager Fusion Middleware Control

  • Oracle WebLogic Scripting Tool (WLST)

5.2.3 クラスタワイドの構成変更

高可用性環境では、1つのOracle Identity Managerインスタンスの構成変更により、他のすべてのインスタンスの構成が変更されます。これは、すべてのOracle Identity Managerインスタンスが同じ構成リポジトリを共有しているためです。

5.2.4 LDAPとの同期に関する考慮事項

LDAPとOracle Identity Managerデータベースとの間の同期情報は、調整と呼ばれるプロセスによって処理されます。このプロセスは、主にバックグラウンドで実行されるスケジュール済プロセスです。このプロセスは手動で実行することもできます。

同期プロセス中にLDAPが停止した場合、Oracle Identity Managerによって取得されていないデータは、調整タスクの次回の実行時に取得されます。

5.3 Oracle Identity Managerの高可用性の構成手順

この項では、Oracle Identity Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。

この項の内容は次のとおりです。

5.3.1 Oracle Identity Managerの構成のための前提条件

Oracle Identity Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。

  • データベースに OIMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。手順は、第5.3.1.1項「データベースにOIMスキーマを作成するためのRCUの実行」を参照してください。

  • OIMHOST1およびOIMHOST2にWebLogicサーバーをインストールします。手順は、第5.3.1.1.1項「Oracle WebLogic Serverのインストール」を参照してください。

  • OIMHOST1およびOIMHOST2にOracle SOA Suiteをインストールします。手順は、第5.3.1.2項「OIMHOST1およびOIMHOST2へのOracle SOA Suiteのインストール」を参照してください。

  • OIMHOST1およびOIMHOST2にOracle Identity Managementソフトウェアをインストールします。手順は、第5.3.1.3項「OIMHOST1およびOIMHOST2へのOracle Identity Managerのインストール」を参照してください。

  • 高可用性LDAP実装が使用可能であることを確認します。


    注意:

    この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managementと統合されているOracle Identity Managerインストールでのみ必要です。

    LDAPSyncオプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップできます。

    Oracle Identity Managerは、Oracle Internet Directoryと直接通信しません。それは、Oracle Virtual Directoryと通信し、Oracle Virtual DirectoryがOracle Internet Directoryと通信します。

  • wlfullclient.jarファイルを、OIMHOST1およびOIMHOST2で作成します。

    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ファイルを作成するには、次の手順を実行します。

    1. MW_HOME/wlserver_10.3/server/libディレクトリに移動します。

    2. JAVA_HOMEをMW_HOME/jdk160_18に設定し、JAVA_HOME/binディレクトリがパスに含まれていることを確認します。

    3. 次のファイルを実行することによって、wlfullclient.jarファイルを作成します。

      java -jar wljarbuilder.jar

5.3.1.1 データベースにOIMスキーマを作成するためのRCUの実行

OIMHOST1およびOIMHOST2にOracle Identity ManagerおよびSOAインスタンスをインストールする前に、リポジトリ作成ユーティリティ(RCU)を使用して、Oracle Identity Managerで使用するスキーマのコレクションを作成しておく必要があります。

RCUは、Oracle Fusion Middleware 11gキットの部品として付属する専用のCDに収録されています。

RCUを実行し、Oracle RACデータベース・リポジトリにOracle Identity Managerスキーマを作成するには、次の手順を実行します。

  1. 次のコマンドを発行します。

    prompt> RCU_HOME/bin/rcu &

  2. 「ようこそ」画面で、「次へ」をクリックします。

  3. 「リポジトリの作成」画面で、「作成」操作を選択してコンポーネント・スキーマを既存のデータベースにロードします。

    「次へ」をクリックします。

  4. 「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。

    • データベース・タイプ: Oracle Database

    • ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: OIMDBHOST1-VIPまたはOIMDBHOST2-VIP

    • ポート: データベースのポート番号。例: 1521

    • サービス名: データベースのサービス名。例: oim.example.com

    • ユーザー名: SYS

    • パスワード: SYSユーザーのパスワード

    • ロール: SYSDBA

    「次へ」をクリックします。

  5. グローバルな前提条件が完了したら、「前提条件チェック」画面で「OK」をクリックします。

  6. 「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。

    接頭辞の新規作成: ha

    コンポーネント:

    • 「アイデンティティ管理」の下では、次のように指定します。

      • Oracle Identity Manager - OIM

      • Oracle Platform Security Services - OPSS

      • デフォルトで、「Metadata Services - MDS」が選択されていることに注意してください。

    • 「SOAおよびBAMインフラストラクチャ」の下で:

      • SOAインフラストラクチャ: デフォルトで、SOAINFRAが選択済です。

      • ユーザー・メッセージング・サービス: デフォルトで、ORASDPMが選択済です。

    「次へ」をクリックします。

  7. コンポーネントの前提条件が完了したら、「前提条件チェック」画面で「OK」をクリックします。

  8. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。

    「次へ」をクリックします。

  9. 「表領域のマップ」画面で、コンポーネントの表領域を選択します。

  10. 「サマリー」画面で「作成」をクリックします。

  11. 「完了サマリー」画面で「閉じる」をクリックします。

5.3.1.1.1 Oracle WebLogic Serverのインストール

WebLogic Serverをインストールする前に、お使いのマシンが、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』に指定されているシステム、パッチ、カーネルなどの要件を満たしていることを確認します。

インストーラを起動し、OIMHOST1およびOIMHOST2で次の手順を実行します。

  1. 「ようこそ」画面で、「次へ」をクリックします。

  2. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。

    「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。

    ORACLE_BASE/product/fmw


    注意:

    ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。推奨値は/u01/app/oracleです。

    「次へ」をクリックします。

  3. セキュリティ・アップデートが通知されるようにするために、「セキュリティ更新のための登録」画面で連絡先情報を入力します。

    「次へ」をクリックします。

  4. 「インストール・タイプの選択」画面で、「カスタム」を選択します。

    「次へ」をクリックします。

  5. 「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。

  6. 「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。

    「次へ」をクリックします。

  7. 「インストールの概要」画面で「次へ」をクリックします。

  8. 「インストール完了」画面で、「Quickstartの実行」の選択を解除します。

    「完了」をクリックします。

5.3.1.2 OIMHOST1およびOIMHOST2へのOracle SOA Suiteのインストール

次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOIMHOST1およびOIMHOST2にインストールします。

/etc/oraInst.locファイルが存在している場合は、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合、この手順をスキップできます。

次のようにOracle Fusion Middlewareコンポーネントのインストーラを起動します。

HOST1> runInstaller

インストーラで、JRE/JDKの場所を入力するよう求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_14_<バージョン>のように入力します。

次のように実行します。

  1. 「ようこそ」画面で、「次へ」をクリックします。

  2. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

  3. 「インストール場所の指定」画面で、次の値を入力します。

    • Oracle Middlewareホーム: MW_HOMEのリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。

      /u01/app/oracle/product/fmw

    • Oracleホーム・ディレクトリ:

      • ORACLE_HOMEにOracle SOA Suiteをインストールするときに、Oracleホーム・ディレクトリ名としてsoaを入力します。

    「次へ」をクリックします。

  4. 「インストール・サマリー」画面で「インストール」をクリックします。

  5. 「インストール完了」画面で「終了」をクリックします。

5.3.1.3 OIMHOST1およびOIMHOST2へのOracle Identity Managerのインストール

次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOIMHOST1およびOIMHOST2にインストールします。

/etc/oraInst.locファイルが存在している場合は、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合、この手順をスキップできます。

次のようにOracle Fusion Middlewareコンポーネントのインストーラを起動します。

HOST1> runInstaller

インストーラで、JRE/JDKの場所を入力するよう求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_<バージョン>のように入力します。

次のように実行します。

  1. 「ようこそ」画面で、「次へ」をクリックします。

  2. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

  3. 「インストール場所の指定」画面で、次の値を入力します。

    • Oracle Middlewareホーム: MW_HOMEのリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。

      /u01/app/oracle/product/fmw

    • Oracleホーム・ディレクトリ:

      • ORACLE_HOMEにOracle Identity and Access Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてiamを入力します。

    「次へ」をクリックします。

  4. 「インストール・サマリー」画面で「インストール」をクリックします。

  5. 「インストール完了」画面で「終了」をクリックします。

5.3.2 OIMHOST1でのOIMとSOAのためのWebLogicドメインの作成と構成

OIMHOST1にドメインを作成するには、次の手順を実行します。

  1. このコマンドを実行して、構成ウィザードを起動します。

    MW_HOME/oracle_common/common/bin/config.sh

  2. 「ようこそ」画面で、「WebLogicドメインの作成」を選択します。

    「次へ」をクリックします。

  3. 「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

    リストから、次のように選択します。

    • Oracle Identity Manager

      Oracle SOA Suite、Oracle Enterprise Manager、Oracle Platform Security Service、Oracle JRF、Oracle JRF WebServices AsynchronousサービスおよびOracle WSM Policy Managerが自動的に選択されます。

    • Oracle Enterprise Manager

      Oracle JRFが自動的に選択されます。

  4. 「ドメイン名と場所の指定」画面で、ドメインおよびそのすべてのアプリケーションの名前と場所を入力します。

    次の項目を入力します。

    • ドメイン名: IDMDomain

    • ドメインの場所: デフォルトを受け入れます。

    • アプリケーションの場所: デフォルトを受け入れます。

    「次へ」をクリックします。

  5. 管理サーバーのユーザー名とパスワードの構成画面で、次のように入力します。

    • 名前: weblogic

    • ユーザー・パスワード: weblogicユーザーのパスワードを入力します。

    • ユーザー・パスワードの確認: weblogicユーザーのパスワードを入力します。

    • 説明: ユーザーの説明を入力します。

    「次へ」をクリックします。

  6. 「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JRockit SDK 1.6.n」を選択します。

    「次へ」をクリックします。

  7. 「JDBCコンポーネント・スキーマの構成」画面で、次に示すコンポーネント・スキーマを選択します。

    • SOAインフラストラクチャ

    • ユーザー・メッセージング・サービス

    • OIM MDSスキーマ

    • OWSM MDSスキーマ

    • SOA MDSスキーマ

    • OIMインフラストラクチャ

    • OPSSスキーマ

    「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」の横のチェック・ボックスを選択します。


    注意:

    GridLinkデータ・ソースを使用することもできます。詳細は、第3.13項「GridLinkデータ・ソース」を参照してください。

    「次へ」をクリックします。

  8. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、マルチ・データ・ソース・スキーマをすべて選択し、次の項目を入力します。

    • サービス名: oim.example.com

    • 最初のRACノードの場合は、次のように入力します。

      • ホスト名: OIMDBHOST1-VIP.example.com

      • インスタンス名: oimdb1

      • ポート: 1521

    • 2つ目のRACノードの場合は、次のように入力します。

      • ホスト名: OIMDBHOST2-VIP.example.com

      • インスタンス名: oimdb2

      • ポート: 1521

    各スキーマを個別に選択し、スキーマのユーザー名とパスワードを表5-1に示すように入力します。

    表5-1 各マルチ・データ・ソース・スキーマのスキーマ所有者とパスワードの入力

    スキーマ名 スキーマ所有者 パスワード

    SOAインフラストラクチャ

    HA_SOAINFRA

    <パスワードを入力>

    ユーザー・メッセージング・サービス

    HA_ORASDPM

    <パスワードを入力>

    OIM MDSスキーマ

    HA_MDS

    <パスワードを入力>

    OWSM MDSスキーマ

    HA_MDS

    <パスワードを入力>

    SOA MDSスキーマ

    HA_MDS

    <パスワードを入力>

    OIMスキーマ

    HA_OIM

    <パスワード>

    OPSSスキーマ

    HA_OPSS

    <パスワード>

    「次へ」をクリックします。

  9. 「コンポーネント・スキーマのテスト」画面で、すべてのスキーマを選択して「接続のテスト」をクリックします。すべてのスキーマに対するテストが正常に完了したことを確認します。

    「次へ」をクリックします。

  10. 「オプションの構成を選択」画面で、次を選択します。

    • 管理サーバー

    • JMS分散宛先 (OIMのインストールされたドメインでのみ必要)

    • 管理対象サーバー、クラスタ、およびマシン

    • JMSファイル・ストア (OIMのインストールされたドメインでのみ必要)

    「次へ」をクリックします。

  11. 「管理サーバーの構成」画面で、次の値を入力します。

    • 名前: AdminServer

    • リスニング・アドレス: oimhost1.example.com

    • リスニング・ポート: 7001

    • SSLリスニング・ポート: 適用なし

    • SSL有効: 選択を解除

    「次へ」をクリックします。

  12. 「JMS分散宛先タイプの選択」画面で、リストされているすべてのJMSシステム・リソースが共通分散宛先であることを確認します。そのようになっていない場合は、ドロップダウン・ボックスから「UDD」を選択します。エントリが表5-2に示すように設定されていることを確認します。

    表5-2 JMSシステム・リソースに対して選択する値

    JMSシステム・リソース 共通/重み設定された分散宛先

    UMSJMSSystemResource

    UDD

    SOAJMSModule

    UDD

    OIMJMSModule

    UDD

    BPMJMSModule

    UDD

    「次へ」をクリックします。

    「オーバーライドの警告」ボックスに次のメッセージが表示されます。

    「CFGFWK-40915: 共通分散宛先(UDD)への変換対象として少なくとも1つのJMSシステム・リソースが選択されています。この変換は、JMSシステム・リソースがクラスタに割り当てられている場合にのみ行われます。」

    「警告」ボックスで「OK」をクリックします。

  13. 「管理対象サーバーの構成」画面を初めて表示した場合、構成ウィザードによって2つのデフォルト管理対象サーバー(oim_server1とsoa_server1)が作成されています。デフォルトの管理対象サーバーの詳細を変更し、2つ目の管理対象サーバーを追加します。次の手順に従います。

    oim_server1エントリについては、そのエントリを次の値に変更します。

    • 名前: WLS_OIM1

    • リスニング・アドレス: OIMVHN1

    • リスニング・ポート: 14000

    soa_server1エントリについては、そのエントリを次の値に変更します。

    • 名前: WLS_SOA1

    • リスニング・アドレス: SOAVHN1

    • リスニング・ポート: 8001

    2つ目のOIMサーバーに対して、「追加」をクリックし、次の情報を入力します。

    • 名前: WLS_OIM2

    • リスニング・アドレス: OIMVHN2

    • リスニング・ポート: 14000

    2つ目のSOAサーバーに対して、「追加」をクリックし、次の情報を入力します。

    • 名前: WLS_SOA2

    • リスニング・アドレス: SOAVHN2

    • リスニング・ポート: 8001

    「次へ」をクリックします。


    注意:

    さらに管理対象サーバーを追加するには、2つ目の管理対象サーバーを追加するための手順に従ってください。

  14. 「クラスタの構成」画面で、「追加」をクリックして2つのクラスタを作成します。

    OIMクラスタに関して次の情報を入力します。

    • 名前: oim_cluster

    • クラスタのメッセージング・モード: unicast

    • クラスタ・アドレス: oimhost1:14000,oimhost2:14000

    SOAクラスタに関して次の情報を入力します。

    • 名前: soa_cluster

    • クラスタのメッセージング・モード: unicast

    • クラスタ・アドレス: oimhost1:8001,oimhost2:8001

    他のフィールドはすべてデフォルト設定のままにして、「次へ」をクリックします。

  15. 「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタと関連付けます。右のウィンドウでクラスタ名をクリックします。

    サーバーの下の管理対象サーバーをクリックし、矢印をクリックしてそれをクラスタに割り当てます。

    WLS_OIM1およびWLS_OIM2管理対象サーバーをoim_clusterのメンバーになるように割り当てます。

    WLS_SOA1およびWLS_SOA2管理対象サーバーをsoa_clusterのメンバーになるように割り当てます。

    「次へ」をクリックします。

  16. 「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。

    ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。

    次の情報を指定します。

    • 名前: ホスト名です。ここでは、DNS名を使用することをお薦めします。

    • ノード・マネージャ・リスニング・アドレス: ここにマシンのDNS名を入力します。

    • ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。

    「次へ」をクリックします。


    注意:

    UNIXでは、「マシン」タブの下のデフォルト・ローカル・マシン・エントリを削除します。

  17. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。

    右側のウィンドウでマシンをクリックします。

    左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。

    矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。

    すべての管理対象サーバーが適切なマシンに割り当てられるまで、この手順を繰り返します。

    一般的な例は、次のようになります。

    • Host1: Admin Server、WLS_OIM1、およびWLS_SOA1

    • Host2: WLS_OIM2およびWLS_SOA2

    「次へ」をクリックします。

  18. 「JMSファイル・ストアの構成」画面で、JMSファイル・ストアのディレクトリの場所を更新します。次の値を入力します。

    名前 ディレクトリ

    UMSJMSFileStore_auto_1

    /u01/app/oracle/admin/domain_name/soa_cluster/jms/UMSJMSFileStore_auto_1

    UMSJMSFileStore_auto_2

    /u01/app/oracle/admin/domain_name/soa_cluster/jms/UMSJMSFileStore_auto_2

    BPMJMSFileStore_auto_1

    /u01/app/oracle/admin/domain_name/soa_cluster/jms/BPMJMSFileStore_auto_1

    BPMJMSFileStore_auto_2

    /u01/app/oracle/admin/domain_name/soa_cluster/jms/BPMJMSFileStore_auto_2

    JRFWSAsyncFileStore_auto_1

    /u01/app/oracle/admin/domain_name/oim_cluster/jms/JRFWSAsyncFileStore_auto_1

    JRFWSAsyncFileStore_auto_2

    /u01/app/oracle/admin/domain_name/oim_cluster/jms/JRFWSAsyncFileStore_auto_2

    SOAJMSFileStore_auto_1

    /u01/app/oracle/admin/domain_name/soa_cluster/jms/SOAJMSFileStore_auto_1

    SOAJMSFileStore_auto_2

    /u01/app/oracle/admin/domain_name/soa_cluster/jms/SOAJMSFileStore_auto_2

    OIMJMSFileStore_auto_1

    /u01/app/oracle/admin/domain_name/oim_cluster/jms/OIMJMSFileStore_auto_1

    OIMJMSFileStore_auto_2

    /u01/app/oracle/admin/domain_name/oim_cluster/jms/OIMJMSFileStore_auto_2

    PS6SOAJMSFileStore_auto_1

    /u01/app/oracle/admin/domain_name/soa_cluster/jms/PS6SOAJMSFileStore_auto_1

    PS6SOAJMSFileStore_auto_2

    /u01/app/oracle/admin/domain_name/soa_cluster/jms/PS6SOAJMSFileStore_auto_2

  19. 「構成のサマリー」画面で、「作成」をクリックしてドメインを作成します。

5.3.3 Oracle Platform Security Servicesスキーマのアップグレード

パッチ・セット・アシスタントを使用して、Oracle Platform Security Servicesスキーマをアップグレードする必要があります。これを行うには、次の手順を実行します。

  1. 次のコマンドを使用して、MW_HOME/oracle_common/binからパッチ・セット・アシスタントを起動します。

    ./psa

  2. opssを選択します。

  3. データベース接続の詳細を指定し、アップグレード対象のスキーマを選択します。

  4. Oracle Platform Security Servicesスキーマのアップグレード後、MW_HOME/oracle_common/upgrade/logs/psa<timestamp>.logにあるログ・ファイルをチェックしてアップグレードを確認してください。

    timestampは、パッチ・セット・アシスタントが実行された実際の日時を示します。アップグレードが失敗した場合は、ログ・ファイルをチェックしてエラーを修正し、パッチ・セット・アシスタントを再実行してください。

5.3.4 ドメイン用のデータベース・セキュリティ・ストアの構成

データベース・セキュリティ・ストアには、セキュリティ・ポリシー、監査メタデータ、資格証明、キー、およびOPSSによって管理されるその他のセキュリティ・アーティファクトが格納されます。トポロジ内のポリシーが重複しないように動作することで、ドメイン構成(単一、複数または拡張)に関係なく高可用性を円滑化します。

ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Managementドメインに対するデータベース・セキュリティ・ストアの構成に関する項を参照してください。

5.3.5 OIMHOST1でのインストール後の手順

この項では、OIMHOST1で実行するインストール後の手順について説明します。次のトピックが含まれます:

5.3.5.1 OIMHOST1での管理サーバー用boot.propertiesの作成

この項では、OIMHOST1上の管理サーバー用boot.propertiesファイルを作成する方法を説明します。boot.propertiesファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。

boot.propertiesファイルを作成する手順は次のとおりです。

  1. OIMHOST1で、次のディレクトリを作成します。

    MW_HOME/wlserver_10.3/server/bin

    例:

    $ mkdir -p 
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

  2. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

    username=adminUser
password=adminUserPassword

    注意:

    管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。

    セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。

5.3.5.2 OIMHOST1でのノード・マネージャの更新

管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャではStartScriptEnabledプロパティをtrueに設定する必要があります。

これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。

MW_HOME/oracle_common/common/bin

5.3.5.3 OIMHOST1でのノード・マネージャの起動

次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST1上のノード・マネージャを起動します。

MW_HOME/wlserver_10.3/server/bin

5.3.5.4 OIMHOST1での管理サーバーの起動

次の手順に従い、管理サーバーを起動し、その起動を確認します。

  1. 次のコマンドを実行し、OIMHOST1上の管理サーバーを起動します。

    DOMAIN_HOME/bin/startWebLogic.sh

  2. Webブラウザを開いて次のページにアクセスし、管理サーバーの起動が正常に行われたことを確認します。

    • 次の場所にある管理コンソール:

      http://oimhost1.example.com:7001/console

    • Oracle Enterprise Manager Fusion Middleware Control:

      http://oimhost1.example.com:7001/em

    weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

5.3.6 OIMHOST1でのOracle Identity Managerの構成

この項では、Oracle Identity ManagerとSOA管理対象サーバーの起動前の構成方法について説明します。

この項の内容は次のとおりです。

5.3.6.1 Oracle Identity Managerの構成のための前提条件

Oracle Identity Managerを構成する前に、次のタスクが実行済であることを確認します。


注意:

この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managementと統合されているOracle Identity Managerインストールでのみ必要です。

LDAPSyncオプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップできます。

  1. 「Oracle Identity Manager用のディレクトリ・スキーマの拡張」

  2. 「Oracle Identity Manager用のユーザーとグループの作成」

  3. 「Oracle Virtual Directoryでのアダプタの作成」

Oracle Identity Manager用のディレクトリ・スキーマの拡張

アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。

アイデンティティ・ストアを事前構成するには、OIMHOST1で次の手順を実行します。

  1. 環境変数MW_HOME、JAVA_HOMEおよびORACLE_HOMEを設定します。

    ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

  2. 次の項目を含む、プロパティ・ファイル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ユーザーにも使用されるOracle Identity Managerリコンシリエーション・ユーザーがあげられます。

  3. idmConfigToolコマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。

    コマンド構文は次のとおりです。

    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

  4. ログ・ファイルを確認して、エラーや警告を修正します。

Oracle Identity Manager用のユーザーとグループの作成

oimadminユーザーをアイデンティティ・ストアに追加する手順を実行して、そのユーザーをOracle Identity Manager管理者グループに割り当てます。また、リコンシリエーションを実行するために、標準の場所cn=Users以外にもユーザーを作成します。Oracle Virtual Directoryを使用したディレクトリに直接接続するときには、このユーザーをバインドDNとして選択することをお薦めします。


注意:

このコマンドでは、アイデンティティ・ストアに予約用のコンテナも作成します。

xelsysadmユーザーをアイデンティティ・ストアに追加して、そのユーザーを管理グループに割り当てるには、OIMHOST1で次のタスクを実行します。

  1. 環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。

    IDM_HOMEをIDM_ORACLE_HOMEに設定します。

    ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

  2. 次の項目を含む、プロパティ・ファイル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=us,dc=oracle,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は、Oracle Identity Managerコンソールにログインするために使用する、管理ユーザーの名前です。
      

      • 

    • 

      IDSTORE_OIMADMINGROUPは、Oracle Identity Manager管理ユーザーを保持するために作成するグループの名前です。
      

      • 

    • 

      IDSTORE_USERSEARCHBASEは、ユーザーを配置するアイデンティティ・ストアの場所です。
      

      • 

    • 

      IDSTORE_GROUPSEARCHBASEは、グループを配置するアイデンティティ・ストアの場所です。
      

      • 

    • 

      IDSTORE_SYSTEMIDBASEは、Oracle Identity Managerリコンシリエーション・ユーザーを配置するディレクトリの場所です。
      

      • 

    • 

      POLICYSTORE_SHARES_IDSTOREは、ポリシー・ストアとアイデンティティ・ストアが同じディレクトリに存在する場合にはtrueを設定します。そうでない場合は、falseを設定します。
      

      • 

    

    3. 

  3. 

    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は、Oracle Identity Manager構成の一部として作成したアカウントと同じ値を設定するようにお薦めします。
    

    次に、コマンドの出力例を示します。
    

    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

    

    4. 

  4. 

    ログ・ファイルを確認して、エラーや警告を修正します。
    

    5. 




Oracle Virtual Directoryでのアダプタの作成


Oracle Identity Managerは、Oracle Virtual Directoryを使用して外部LDAPストアに接続します。Oracle Identity ManagerがOracle Internet Directoryなどの外部LDAPストアに接続できるようにするには、ユーザー・アダプタと変更ログ・アダプタをOracle Virtual Directoryに作成する必要があります。次の手順に従って、アダプタを作成します。













注意:


Oracle Internet Directoryのみを実装する場合は、Oracle Virtual Directoryにアダプタを作成する必要はありません。












ユーザー・アダプタ


OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれにユーザー・アダプタを作成します。


Oracle Directory Services Managerを使用して、Oracle Virtual Directoryにユーザー・アダプタを作成する手順は次のとおりです。


    

  1. 

    ブラウザを開き、ODSMコンソール(http://admin.example.com/odsm)を表示します。
    

    


    

    


    


    注意:
    

    Oracle Directory Services Managerは、図5-2には記載されていませんが、Oracle Internet DirectoryとOracle Virtual Directoryを管理するために必要です。Oracle Directory Services Managerが環境に存在している必要があります。
    
    		

    
    

    

    

    

    2. 

  2. 

    OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれへの接続がまだ存在していない場合は、作成します。
    

    3. 

  3. 

    適切な接続エントリを使用して、各Oracle Virtual Directoryインスタンスに接続します。
    

    4. 

  4. 

    ホームページで、「アダプタ」タブをクリックします。
    

    5. 

  5. 

    アダプタ・ウィンドウの上部にある「アダプタの作成」をクリックして、「新規アダプタ・ウィザード」を起動します。
    

    6. 

  6. 

    「新規アダプタ・ウィザード」で次のパラメータを指定して、新しいアダプタを作成します。
    

    


    

    


    


    注意:
    

    前にユーザー・アダプタを作成した場合は、アダプタを作成する手順をスキップし、アダプタを編集する手順に従います。
    
    		

    
    

    

    

    

    

    





    
画面
フィールド
値/手順

    
    


    


    タイプ
    
    		


    アダプタ・タイプ
    
    		


    LDAP
    
    		

    

    

    		


    アダプタ名
    
    		


    ユーザー・アダプタ
    
    		

    

    

    		


    アダプタ・テンプレート
    
    		


    User_OID
    
    		

    

    


    接続
    
    		


    DNS設定を使用
    
    		


    いいえ
    
    		

    

    

    		


    ホスト
    
    		


    oid.example.com
    
    		

    

    

    		


    ポート
    
    		


    389
    
    		

    

    

    		


    サーバー・プロキシ・バインドDN
    
    		


    cn=oimadmin,cn=systemids,dc=example,dc=com
    
    		

    

    

    		


    プロキシ・パスワード
    
    		


    oimadminのパスワード。これは、「Oracle Identity Manager用のディレクトリ・スキーマの拡張」のパスワードと同じにします。
    
    		

    

    


    接続テスト
    
    		

    		


    テストが正常に行われたことを確認します。
    
    		

    

    


    ネームスペース
    
    		


    リモート・ベース
    
    		


    dc=example,dc=com
    
    		

    

    

    		


    マップされたネームスペース
    
    		


    dc=example,dc=com
    
    		

    

    


    概要
    
    		

    		


    概要に誤りがないことを確認し、「終了」をクリックします。
    
    		

    
    

    

    

    7. 

  7. 

    ユーザー・アダプタを次のように編集します。
    

      

    1. 

      OIMユーザー・アダプタを選択します。
      

      2. 

    2. 

      「プラグイン」タブをクリックします。
      

      3. 

    3. 

      「ユーザー管理」プラグインをクリックし、プラグイン表で「編集」をクリックします。プラグインの編集ウィンドウが表示されます。
      

      4. 

    4. 

      「パラメータ」表で、次のようにパラメータ値を更新します。
      

      

      




      
パラメータ
値

      
      


      


      directoryType
      
      		


      oid
      
      		

      

      


      pwdMaxFailure
      
      		


      10
      
      		

      

      


      oamEnabled
      
      		


      true
      
      		

      
      

      

      

      5. 

    5. 

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

      6. 

    6. 

      「適用」をクリックします。
      

      7. 

    

    8. 



変更ログ・アダプタ


OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれに変更ログ・アダプタを作成します。次の手順に従い、Oracle Directory Services Managerを使用してOracle Virtual Directoryに変更ログ・アダプタを作成します。


    

  1. 

    ブラウザを開き、ODSMコンソール(http://admin.example.com/odsm)を表示します。
    

    2. 

  2. 

    OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれへの接続がまだ存在していない場合は、作成します。
    

    3. 

  3. 

    適切な接続エントリを使用して、Oracle Virtual Directoryインスタンスに接続します。
    

    4. 

  4. 

    ホームページで、「アダプタ」タブをクリックします。
    

    5. 

  5. 

    アダプタ・ウィンドウの上部にある「アダプタの作成」をクリックして、「新規アダプタ・ウィザード」を起動します。
    

    6. 

  6. 

    「新規アダプタ・ウィザード」および次のパラメータを使用して、新規アダプタを作成します。
    

    

    





    
画面
フィールド
値/手順

    
    


    


    タイプ
    
    		


    アダプタ・タイプ
    
    		


    LDAP
    
    		

    

    

    		


    アダプタ名
    
    		


    OIM変更ログ・アダプタ
    
    		

    

    

    		


    アダプタ・テンプレート
    
    		


    Changelog_OID
    
    		

    

    


    接続
    
    		


    DNS設定を使用
    
    		


    いいえ
    
    		

    

    

    		


    ホスト
    
    		


    oid.example.com
    
    		

    

    

    		


    ポート
    
    		


    389
    
    		

    

    

    		


    サーバー・プロキシ・バインドDN
    
    		


    cn=oimadmin,cn=systemids,dc=example,dc=com
    
    		

    

    

    		


    プロキシ・パスワード
    
    		


    oimadminのパスワード。これは、「Oracle Identity Manager用のディレクトリ・スキーマの拡張」で指定したパスワードと同じにします。
    
    		

    

    


    接続テスト
    
    		

    		


    テストが正常に行われたことを確認します。
    
    		

    

    


    ネームスペース
    
    		


    リモート・ベース
    
    		


    cn=changelog
    
    		

    

    


    マップされたネームスペース
    
    		

    		


    cn=changelog
    
    		

    

    


    概要
    
    		

    		


    概要に間違いがないことを確認してから、「終了」をクリックします。
    
    		

    
    

    

    

    7. 

  7. 

    変更アダプタを編集する手順は、次のとおりです。
    

      

    1. 

      OIM変更ログ・アダプタを選択します。
      

      2. 

    2. 

      「プラグイン」タブをクリックします。
      

      3. 

    3. 

      「デプロイ済プラグイン」表で、「変更ログ」プラグインをクリックしてから、「編集」をプラグイン表でクリックします。プラグインの編集ウィンドウが表示されます。
      

      4. 

    4. 

      「パラメータ」表で、パラメータ値を更新します。
      

      5. 

    5. 

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

      6. 

    6. 

      「適用」をクリックします。
      

      7. 

    

    変更ログ・アダプタを編集してプロパティを追加または変更し、それらが次の表に示す値に一致するようにします。mapObjectclass、modifierDNFilter、sizeLimit、およびtargetDNFilterプロパティをアダプタに追加する必要があります。
    

    

    




    
パラメータ
値

    
    


    


    directoryType
    
    		


    oid
    
    		

    

    


    mapAttribute
    
    		


    targetGUID=orclguid
    
    		

    

    


    requiredAttribute
    
    		


    orclguid
    
    		

    

    


    modifierDNFilter
    
    		


    cn=oimadmin,cn=systemids,dc=example,dc=com
    
    		

    

    


    sizeLimit
    
    		


    1000
    
    		

    

    


    targetDNFilter
    
    		


    dc=example,dc=com
    

    調整が必要な検索ベース。この値は、OIMのインストール時に指定したLDAP SearchDNと同一である必要があります。
    
    		

    

    


    mapUserState
    
    		


    true
    
    		

    

    


    oamEnabled
    
    		


    true
    
    		

    
    

    

    

    8. 



Oracle Internet DirectoryとOracle Virtual Directoryの起動と停止


次のインスタンスを起動および停止します。


    

  • 

    OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンス。
    

    • 

  • 

    OIDHOST1とOIDHOST2上で実行されているOracle Internet Directoryインスタンス。
    

    • 









5.3.6.2 CoherenceクラスタのためのCoherenceの構成の更新


次の手順に従い、SOA管理対象サーバーのCoherence構成を更新します。


    

  1. 

    管理コンソールにログインします。
    

    2. 

  2. 

    「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
    

    3. 

  3. 

    「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
    

    4. 

  4. 

    表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。
    

    5. 

  5. 

    「サーバーの起動」タブをクリックします。
    

    6. 

  6. 

    「引数」フィールドで、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

    7. 

  7. 

    「保存」をクリックして、変更をアクティブ化します。
    

    この変更を有効にするには、SOAサーバーの再起動が必要です。
    

    8. 









5.3.6.3 Oracle Identity Management構成ウィザードの実行


Oracle Identity Manager管理対象サーバーを起動する前に、Oracle Identity Managerサーバー・インスタンスを構成しておく必要があります。これらの構成手順を実行するのは、一度のみ(たとえば、ドメインを最初に作成するとき)です。Oracle Identity Management構成ウィザードによって、OIMメタデータがデータベースにロードされ、インスタンスが構成されます。


構成ウィザードを実行する前に、次を検証する必要があります。


    

  • 

    管理サーバーが起動されて、実行中であること。
    

    • 

  • 

    wls_soa1のコヒーレンスを設定していること。
    

    • 

  • 

    wls_soa1が実行中であること。
    

    • 

  • 

    環境変数DOMAIN_HOMEおよびWL_HOMEが現在のシェル内で設定されていないこと。
    

    • 



Oracle Identity Managementの構成ウィザードは、Identity ManagementのOracleホームの下にあります。次のように入力します。


IAM_ORACLE_HOME/bin/config.sh


次の手順を実行します。


    

  1. 

    「ようこそ」画面で、「次へ」をクリックします。
    

    2. 

  2. 

    構成するコンポーネント画面で、OIMサーバーを選択します。トポロジに必要な場合は、OIM Remote Managerを選択します。
    

    「次へ」をクリックします。
    

    3. 

  3. 

    「データベース」画面で、次の値を入力します。
    

      

    • 

      接続文字列: 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
      

      • 

    

    「次へ」を選択します。
    

    4. 

  4. 

    WebLogic管理サーバー画面で、WebLogic管理サーバーについて次の詳細を入力します。
    

      

    • 

      URL: WebLogic管理サーバーに接続するためのURLです。例: t3://oimhost1.example.com:7001。
      

      • 

    • 

      ユーザー名: weblogic
      

      • 

    • 

      パスワード: weblogicユーザーのパスワードです。
      

      • 

    

    「次へ」をクリックします。
    

    5. 

  5. 

    「OIMサーバー」画面で、次の値を入力します。
    

      

    • 

      OIM管理者パスワード: OIM管理者のパスワード。これは、xelsysadmユーザーのパスワードです。このパスワードは、事前にidmconfigtoolで入力したパスワードと同じにします。
      

      • 

    • 

      パスワードの確認: パスワードを確認するためのものです。
      

      • 

    • 

      OIM HTTP URL: OIMサーバーのプロキシURL。これは、OIM用のOHSサーバーのフロントエンドに配置されているハードウェア・ロード・バランサのURLです。例: http://oiminternal.example.com:80。
      

      • 

    • 

      キー・ストア・パスワード: キー・ストア・パスワードです。パスワードには大文字と数字をそれぞれ1文字含める必要があります。例: MyPassword1
      

      • 

    

    「次へ」をクリックします。
    

    6. 

  6. 

    環境に必要な場合は、LDAP同期とOAM画面で、BI Publisherの構成を選択し、BI Publisher URLに値を指定します。環境においてBI Publisherに接続するためのURLを入力します。
    

    LDAP同期の有効化を選択します。
    

    


    

    


    


    注意:
    

      

    • 

      OAMとのアイデンティティ管理の統合の有効化は選択しないでください。
      

      • 

    • 

      BI PublisherはIDMDomainの一部ではありません。
      

      • 

    
    		

    
    

    

    

    

    「次へ」をクリックします。
    

    7. 

  7. 

    「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
      

      • 

    

    「次へ」をクリックします。
    

    8. 

  8. 

    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値と同じ値を使用してください。
      
      		

      
      

      

      

      

      • 

    

    「次へ」をクリックします。
    

    9. 

  9. 

    Remote Manager画面で、次の値を指定します。
    

    


    

    


    


    注意:
    

    この画面は、ステップ2でRemote Managerユーティリティを選択した場合にのみ表示されます。
    
    		

    
    

    

    

    

      

    • 

      サービス名: HA_RManager
      

      • 

    • 

      RMIレジストリ・ポート: 12345
      

      • 

    • 

      リスニング・ポート(SSL): 12346
      

      • 

    

    10. 

  10. 

    「構成サマリー」画面で、サマリー情報を確認します。
    

    「構成」をクリックし、Oracle Identity Managerインスタンスを構成します。
    

    11. 

  11. 

    「構成の進行状況」画面で、構成が正常に完了すると、「次へ」をクリックします。
    

    12. 

  12. 

    「構成が完了しました」画面で、構成されたOracle Identity Managerインスタンスの詳細を確認します。
    

    「終了」をクリックし、Configuration Assistantを終了します。
    

    13. 

  13. 

    WebLogic管理サーバーを停止します。
    

    14. 

  14. 

    WebLogic管理サーバーを起動します。
    

    15. 











5.3.7 管理対象サーバーに対する構成後の手順


この項では、管理対象サーバーの構成後の手順について説明します。





5.3.7.1 OIMHOST1でのWLS_SOA1およびWLS_OIM1管理対象サーバーの起動


OIMHOST1上でWLS_SOA1およびWLS_OIM1管理対象サーバーを起動するには、次の手順を実行します。


    

  1. 

    OIMHOST1上のWebLogic管理サーバーを停止します。この操作にはWebLogic管理コンソールを使用します。
    

    2. 

  2. 

    DOMAIN_HOME/binディレクトリの下にあるstartWebLogic.shスクリプトを使用して、OIMHOST1上のWebLogic管理サーバーを起動します。例:
    

    /u01/app/oracle/admin/OIM/bin/startWebLogic.sh > /tmp/admin.out 2>1&

    3. 

  3. 

    WebLogic管理コンソールを表示して、WebLogic管理サーバーが正常に起動されたことを確認します。
    

    4. 

  4. 

    WebLogic管理コンソールを使用して、WLS_SOA1管理対象サーバーを再起動します。
    

    5. 

  5. 

    WebLogic管理コンソールを使用して、WLS_OIM1管理対象サーバーを起動します。
    

    6. 











5.3.8 OIMHOST1でのOracle Identity Managerインスタンスの検証


Webブラウザを使用してOracle Identity Managerコンソールを起動することによって、OIMHOST1上のOracle Identity Managerサーバー・インスタンスを検証します。


Oracle Identity ManagerコンソールのURLは、次のとおりです。


http://identityvhn1.example.com:14000/identity



xelsysadmパスワードを使用してログインします。








5.3.9 OIMHOST2へのOracle Identity Managerの伝播


OIMHOST1で構成を完了したら、その構成をOIMHOST2に伝播できます。これを行うには、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。


次の手順に従い、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。


    

  1. 

    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

    2. 

  2. 

    前の手順で作成したoim_domain.jarファイルは、次のディレクトリにあります。
    

    /u01/app/oracle/admin/templates

    

    このoim_domain.jarファイルをOIMHOST1からOIMHOST2上の一時ディレクトリにコピーします。
    

    3. 

  3. 

    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

    4. 









5.3.10 OIMHOST2におけるインストール後の手順


この項では、OIMHOST2で実行するインストール後の手順について説明します。これらの項目が含まれます。






5.3.10.1 OIMHOST2でのノード・マネージャの更新


WebLogic管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャでStartScriptEnabledプロパティがtrueに設定されていることが必要です。


これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。


MW_HOME/oracle_common/common/bin







5.3.10.2 OIMHOST2でのノード・マネージャの起動


次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST2上のノード・マネージャを起動します。


MW_HOME/wlserver_10.3/server/bin







5.3.10.3 OIMHOST2でのWLS_SOA2およびWLS_OIM2管理対象サーバーの起動


次の手順に従い、OIMHOST2上のWLS_SOA2およびWLS_OIM2管理対象サーバーを起動します。


    

  1. 

    WebLogic管理コンソールを表示して、WebLogic管理サーバーが正常に起動されたことを確認します。
    

    2. 

  2. 

    WebLogic管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。
    

    3. 

  3. 

    WebLogic管理コンソールを使用して、WLS_OIM2管理対象サーバーを起動します。WLS_OIM2管理対象サーバーを起動する前に、WLS_SOA2管理対象サーバーを起動してください。
    

    4. 











5.3.11 OIMHOST2でのOracle Identity Managerインスタンスの検証


Webブラウザを使用してOracle Identity Managerコンソールを起動することによって、OIMHOST2上のOracle Identity Managerサーバー・インスタンスを検証します。


Oracle Identity ManagerコンソールのURLは、次のとおりです。


http://identityvhn2.example.com:14000/oim



xelsysadmパスワードを使用してログインします。








5.3.12 SOAサーバーのデフォルト・コンポジットの更新


統合環境では、Oracle Identity ManagerはOHSによってフロントエンド処理されます。すべてのSOAサーバーのデフォルト・コンポジットを更新する必要があります。SOAサーバーのデフォルト・コンポジットの更新手順は、Oracle Fusion Middleware Oracle Identity Management統合ガイドのSOAサーバーのデフォルト・コンポジットの更新に関する説明を参照してください。








5.3.13 LDAP構成ポストセットアップ・スクリプトを使用したOracle Internet Directoryの構成













注意:


この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managementと統合されているOracle Identity Managerインストールでのみ必要です。


LDAP同期オプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップできます。












現在のリリースでは、LDAPConfigPostSetupスクリプトを使用すると、LDAPSync関連の増分リコンシリエーション・スケジューラ・ジョブがすべて有効になります。これらのジョブはデフォルトでは無効です。LDAP構成ポストセットアップ・スクリプトは、IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあります。スクリプトを実行する手順は、次のとおりです。


    

  1. 

    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は、この手順で使用しません。
    
    		

    
    

    

    

    

    2. 

  2. 

    ファイルを保存します。
    

    3. 

  3. 

    次のように、JAVA_HOME、WL_HOME、APP_SERVER、OIM_ORACLE_HOMEおよびDOMAIN_HOME環境変数を設定します。
    

      

    • 

      JAVA_HOMEをMW_HOME/jrockit_versionに設定
      

      • 

    • 

      WL_HOMEをMW_HOME/wlserver_10.3に設定
      

      • 

    • 

      APP_SERVERをweblogicに設定
      

      • 

    • 

      OIM_ORACLE_HOMEをIAM_ORACLE_HOMEに設定
      

      • 

    • 

      DOMAIN_HOMEをMSERVER_HOMEに設定
      

      • 

    

    4. 

  4. 

    LDAPConfigPostSetup.shを実行します。このスクリプトでは、LDAPの管理者パスワードとOracle Identity Managerの管理者パスワードが要求されます。例:
    

    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

    5. 









5.3.14 OIMおよび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をリスニングします。


次の手順を実行すると、WLS_OIM1、WLS_SOA1、WLS_OIM2、およびWLS_SOA2管理対象サーバーのサーバー移行を行うことができ、これにより、サーバーまたはプロセスの障害時に、管理対象サーバーは別のノードにフェイルオーバーできます。






5.3.14.1 サーバー移行リース・テーブルのユーザーおよび表領域の設定


最初の手順では、サーバー移行リース表のユーザーと表領域を設定します。













注意:


同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。この場合、データベース・リース用にデータ・ソースおよびマルチ・データ・ソースを再作成する必要はありませんが、これらをサーバー移行用に構成しているクラスタにターゲット指定しなおす必要があります。












    

  1. 

    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;

    2. 

  2. 

    leasingという名前のユーザーを作成し、リース表領域に割り当てます。
    

    SQL> create user leasing identified by welcome1;
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;

    3. 

  3. 

    leasing.ddlスクリプトを使用してリース表を作成します。
    

      

    1. 

      WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。
      

      2. 

    2. 

      leasingユーザーとしてデータベースに接続します。
      

      3. 

    3. 

      SQL*Plusでleasing.ddlスクリプトを実行します。
      

      SQL> @Copy_Location/leasing.ddl;

      4. 

    

    4. 









5.3.14.2 Oracle WebLogic管理コンソールを使用したマルチ・データ・ソースの作成


マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。


    

  • 

    このデータ・ソースが非XAデータ・ソースであることを確認します。
    

    • 

  • 

    マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。
    

    • 

  • 

    Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
    

    • 

  • 

    データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。
    

    • 

  • 

    これらのデータ・ソースをクラスタにターゲット指定します。
    

    • 

  • 

    データ・ソースの接続プールの初期容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」、「接続プール」タブの順にクリックし、「初期容量」フィールドに0(ゼロ)を入力します。
    

    • 




マルチ・データ・ソースの作成


マルチ・データ・ソースを作成する手順は、次のとおりです。


    

  1. 

    管理者の資格証明を使用して、管理コンソールにログインします。
    

    2. 

  2. 

    「ドメイン構造」ウィンドウで「サービス」ノードを開き、次に、「データ・ソース」ノードを開きます。
    

    3. 

  3. 

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

    4. 

  4. 

    「新規」をクリックしてから、「マルチ・データ・ソース」をクリックします。
    

    5. 

  5. 

    名前として、leasingと入力します。
    

    6. 

  6. 

    JNDI名として、jdbc/leasingと入力します。
    

    7. 

  7. 

    アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。「次」をクリックします。
    

    8. 

  8. 

    ターゲット・クラスタを選択します。「次へ」をクリックします。
    

    9. 

  9. 

    「非XAドライバ」(デフォルト)を選択します。「次へ」をクリックします。
    

    10. 

  10. 

    「新しいデータ・ソースの作成」をクリックします。
    

    11. 

  11. 

    名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。
    

    


    

    


    


    注意:
    

    リース表のマルチ・データ・ソースを作成する場合は、名前を<MultiDS>-rac0や<MultiDS>-rac1などの形式で入力します。
    
    		

    
    

    

    

    

    12. 

  12. 

    「次へ」をクリックします。
    

    13. 

  13. 

    「グローバル・トランザクションのサポート」の選択を解除します。「次へ」をクリックします。
    

    14. 

  14. 

    leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。
    

    15. 

  15. 

    「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。
    

    


    

    


    


    注意:
    

    作成するデータ・ソースすべての作成を完了するまで、「終了」をクリックしないでください。作成したデータ・ソースが表示されない場合は、「終了」をクリックするのが早すぎたことを示しています。「終了」をクリックすると、データ・ソースをターゲット指定する画面が管理コンソールに表示されなくなります。
    
    		

    
    

    

    

    

    16. 

  16. 

    データ・ソースをクラスタにターゲット指定します。
    

    17. 

  17. 

    データ・ソースを選択して、右の画面に追加します。
    

    18. 

  18. 

    Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。
    

    19. 

  19. 

    2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
    

    20. 

  20. 

    保存して、「変更のアクティブ化」をクリックします。
    

    21. 









5.3.14.3 ノード・マネージャのプロパティ・ファイルの編集


nodemanager.propertiesファイルを編集して、サーバー移行を構成するノードごとに次のプロパティを追加する必要があります。


Interface=eth0
NetMask=255.255.255.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
...














注意:


サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合、次の手順は必要ありません。












    

  1. 

    nodemanager.propertiesファイルで次のプロパティを設定します。
    

      

    • 

      StartScriptEnabled: このプロパティをtrueに設定して、ノード・マネージャが管理対象サーバーで起動するようにします。
      

      • 

    

    2. 

  2. 

    WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、OIMHOST1とOIMHOST2でノード・マネージャを起動します。
    

    3. 














注意:


共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個別にパラメータを指定します。たとえば、HOSTnで異なるインタフェース(eth3)を使用するには、Interface環境変数をHOSTn> export JAVA_OPTIONS=-DInterface=eth3のように使用して、この変数がシェル内で設定された後にノード・マネージャを起動します。


















5.3.14.4 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定


サーバー移行を構成するノードごとにwlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は、次のとおりです。


    

  1. 

    PATH環境変数に次のファイルが含まれていることを確認します。
    

    

    表5-3 PATH環境変数に必要なファイル
    

    




    
ファイル
格納されているディレクトリ

    
    


    


    wlsifconfig.sh
    
    		


    DOMAIN_HOME/bin/server_migration
    
    		

    

    


    wlscontrol.sh
    
    		


    WL_HOME/common/bin
    
    		

    

    


    nodemanager.domains
    
    		


    WL_HOME/common
    
    		

    
    

    

    

    2. 

  2. 

    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とシステム権限はシステム管理者にお問い合せください。
    
    		

    
    

    

    

    

    3. 









5.3.14.5 サーバー移行ターゲットの構成


まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。


    

  1. 

    管理コンソールにログインします。
    

    2. 

  2. 

    「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
    

    3. 

  3. 

    「名前」列で、移行を構成するクラスタをクリックします。
    

    4. 

  4. 

    「移行」タブをクリックします。
    

    5. 

  5. 

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

    6. 

  6. 

    「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
    

    7. 

  7. 

    自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
    

    8. 

  8. 

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

    9. 

  9. 

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

    10. 

  10. 

    サーバー移行の候補となるマシンを設定します。このタスクは、次の手順に従って、すべての管理対象サーバーについて実行する必要があります。
    

      

    1. 

      管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
      

      


      

      


      


      ヒント:
      

      「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックして、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動し、サーバーが実行されているマシンを表示します。サーバーが自動的に移行される場合、これは実際の構成とは異なります。
      
      		

      
      

      

      

      

      2. 

    2. 

      移行を構成するサーバーを選択します。
      

      3. 

    3. 

      「移行」タブをクリックします。
      

      4. 

    4. 

      「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
      

      5. 

    5. 

      「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
      

      6. 

    6. 

      「保存」をクリックしてから、「変更のアクティブ化」をクリックします。
      

      7. 

    7. 

      追加の管理対象サーバーに対して、前述の手順を繰り返します。
      

      8. 

    8. 

      管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。
      

      9. 

    

    11. 









5.3.14.6 サーバー移行のテスト


サーバー移行が適切に機能していることを確認する手順は次のとおりです。



OIMHOST1から次の処理を実行します。


    

  1. 

    WLS_OIM1管理対象サーバーを停止します。これには、次のコマンドを実行します。
    

    OIMHOST1> kill -9 pid

    

    pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
    

    OIMHOST1> ps -ef | grep WLS_OIM1

    2. 

  2. 

    ノード・マネージャのコンソールを確認します。WLS_OIM1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
    

    3. 

  3. 

    ノード・マネージャがWLS_OIM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
    

    4. 

  4. 

    ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
    

    5. 




OIMHOST2から次の処理を実行します。


    

  1. 

    ローカルのノード・マネージャのコンソールを確認します。OIMHOST1でのWLS_OIM1の再起動が前回試行されてから30秒間経過した後に、WLS_OIM1の浮動IPが表示されサーバーをこのノードで再起動することを示すメッセージがOIMHOST2のノード・マネージャにより表示されます。
    

    2. 

  2. 

    同じIPでsoa-infraコンソールにアクセスします。
    

    3. 



前述の手順に従い、WLS_OIM2、WLS_SOA1、およびWLS_SOA2管理対象サーバーのサーバー移行をテストします。


表5-4は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。




表5-4 WLS_OIM1、WLS_OIM2、WLS_SOA1、WLS_SOA2サーバー移行









管理対象サーバー
移行元
移行先








WLS_OIM1




OIMHOST1




OIMHOST2








WLS_OIM2




OIMHOST2




OIMHOST1








WLS_SOA1




OIMHOST1




OIMHOST2








WLS_SOA2




OIMHOST2




OIMHOST1












管理コンソールからの検証


移行は管理コンソールで確認することもできます。


    

  1. 

    管理者の資格証明を使用して、管理コンソール(http://oimhost1.example.com:7001/console)にログインします。
    

    2. 

  2. 

    左側のコンソールで、「ドメイン」をクリックします。
    

    3. 

  3. 

    「監視」タブをクリックし、「移行」サブタブをクリックします。
    

    「移行の状態」表に、移行の状態に関する情報が表示されます。
    

    4. 














注意:


サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。




















5.3.15 共有JMS永続ストアの構成


OIMHOST1とOIMHOST2の両方から参照できる共有ディレクトリに、すべての永続ストアの場所を構成します。JMSメッセージは、各サーバーのローカル・ファイル・システムのファイル・システムで永続化されているため、WebLogicサーバー移行のためにはJMS永続ストア用の共有記憶域が必要です。共有記憶域がない場合、移行先サーバーからは保留中のJMSメッセージにアクセスできなくなります。













注意:


JMSメッセージ、トランザクション・ログおよびファイル・ストアでのロックの解放の詳細は、「NFSでのファイル・ストアの使用に関する考慮事項」を参照してください。












共有のベース・ディレクトリを使用するように、すべての永続ストアを変更する手順は、次のとおりです。


    

  1. 

    管理者の資格証明を使用して、管理コンソール(http://oimhost1.example.com:7001/console)にログインします。
    

    2. 

  2. 

    「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアの概要」ページが表示されます。
    

    3. 

  3. 

    表BPM、SOA、OIMおよびUMSの「名前」列から、永続ストアのハイパーリンクを選択します。その永続ストアの「設定」ページが表示されます。
    

    4. 

  4. 

    「構成」タブの「ディレクトリ」フィールドに、クラスタ内の他のサーバーで使用可能な永続記憶域ソリューション(NASやSANなど)の場所を入力します。この場所を指定することで、保留中のJMSメッセージを送信できます。
    

    5. 

  5. 

    場所は、次のディレクトリ構造に従う必要があります。
    

      

    • 

      WLS_SOA1およびWLS_SOA2サーバーについては、次のようなディレクトリ構造を使用します。
      

      ORACLE_BASE/admin/domainName/soaClusterName/jms

      • 

    • 

      WLS_OIM1およびWLS_OIM2サーバーについては、次のようなディレクトリ構造を使用します。
      

      ORACLE_BASE/admin/domainName/oimClusterName/jms

      

      


      

      


      


      注意:
      

      WLS_OIM1およびWLS_OIM2サーバーは、このディレクトリにアクセスできる必要があります。
      

      WLS_SOA1およびWLS_SOA2 サーバーは、このディレクトリにアクセスできる必要があります。
      

      このディレクトリは、サーバーを再起動する前に存在している必要があります。
      
      		

      
      

      

      

      

      • 

    

    6. 

  6. 

    「保存してアクティブ化」をクリックします。
    

    7. 

  7. 

    サーバーを再起動して、永続ストア内の変更を有効化します。
    

    8. 









5.3.16 トランザクション・リカバリ用のデフォルト永続ストアの構成


各Oracle WebLogic管理対象サーバーにはトランザクション・ログがあり、サーバーによって調整された、未完了の可能性のある、進行中のトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、クラスタ内のすべてのサーバーからアクセス可能な場所にトランザクション・ログを格納します。共有記憶域がないと、サーバーに障害が発生したときにクラスタ内の他のサーバーがトランザクション・リカバリを実行できず、操作の再試行が必要になることがあります。













注意:


可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。












Oracle Identity ManagerおよびSOAサーバーのデフォルトの永続ストアの場所を設定する手順は次のとおりです。


    

  1. 

    管理者の資格証明を使用して、管理コンソール(http://oimhost1.example.com:7001/console)にログインします。
    

    2. 

  2. 

    「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。
    

    3. 

  3. 

    表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)を選択します。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
    

    4. 

  4. 

    「サービス」タブをクリックします。
    

    5. 

  5. 

    ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようにする必要があります。
    

      

    • 

      WLS_SOA1およびWLS_SOA2サーバーについては、次のようなディレクトリ構造を使用します。
      

      ORACLE_BASE/admin/domainName/soaClusterName/tlogs

      • 

    • 

      WLS_OIM1およびWLS_OIM2サーバーについては、次のようなディレクトリ構造を使用します。
      

      ORACLE_BASE/admin/domainName/oimClusterName/tlogs

      • 

    

    6. 

  6. 

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

    


    

    


    


    注意:
    

    トランザクション回復サービスの移行機能を有効化するには、クラスタ内の管理対象サーバーで利用可能な永続記憶域ソリューション上の場所を指定します。WLS_SOA1、WLS_SOA2、WLS_OIM1、およびWLS_OIM2は、このディレクトリにアクセスできる必要があります。
    
    		

    
    

    

    

    

    7. 









5.3.17 WEBHOST1およびWEBHOST2へのOracle HTTP Serverのインストール


WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールします。








5.3.18 Web Tierと連携するためのOracle Identity Managerの構成


この項では、Oracle Identity Managerを構成してOracle Web Tierと連携する方法について説明します。





5.3.18.1 前提条件


次のタスクが実行済であることを確認します。


    

  1. 

    Oracle Web TierをWEBHOST1とWEBHOST2にインストールしました。
    

    2. 

  2. 

    Oracle Identity ManagerがOIMHOST1およびOIMHOST2にインストールされ、構成済であること。
    

    3. 

  3. 

    ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(sso.example.com)で構成済であること。
    

    4. 

  4. 

    ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(oiminternal.example.com)で構成済であること。
    

    5. 









5.3.18.2 OIMおよびSOA管理対象サーバーのフロントエンドに使用できるようにするためのOracle HTTP Serverの構成


    

  1. 

    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 oimvhn1.example.com:8001,oimvhn2.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:8001,oimvhn2.example.com:8001
    oimvh1.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 oimvhn1.example.com:8001,oimvhn2.example.com:8001
    oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    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>

    2. 

  2. 

    ORACLE_INSTANCE/config/OHS/component/moduleconfにvirtual_hosts.confというファイルを作成します。このファイルは、次の情報を含む必要があります。
    

    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>

    3. 

  3. 

    WEBHOST1とWEBHOST2の両方でファイルを保存します。
    

    4. 

  4. 

    WEBHOST1およびWEBHOST2の両方で、Oracle HTTP Serverインスタンスを停止および起動します。
    

    5. 











5.3.19 Oracle HTTP Serverの構成の検証


Oracle HTTP Serverが適切に構成されていることを検証する手順は次のとおりです。


    

  1. 

    Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。
    

    http://sso.example.com:7777/identity

    

    Oracle Identity Managerコンソール・ログイン・ページが表示されます。
    

    2. 

  2. 

    xelsysadmユーザーの資格証明を使用してOracle Identity Managerコンソールにログインします。
    

    3. 









5.3.20 Oracle Identity Managerのフェイルオーバーおよび予想される動作


高可用性環境では、WebLogicノード・マネージャはOracle WebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。


高可用性環境では、ハードウェア・ロード・バランサを使用して、複数のOracle Identity Managerインスタンス間のリクエストをロード・バランシングします。Oracle Identity Managerインスタンスのいずれかに障害が発生した場合は、ロード・バランサによって障害が検出され、障害が発生していないインスタンスにリクエストがルーティングされます。


高可用性環境では、状態情報と構成情報は、クラスタ内のすべてのメンバーが共有するデータベースに格納されます。


状態情報が共有データベースに格納されており、クラスタ内のすべてのメンバーがこの情報を使用できるため、障害が発生していないOracle Identity Managerインスタンスでは、障害が発生したインスタンスで開始された未完了のトランザクションの処理をシームレスに継続します。


Oracle Identity Managerインスタンスのいずれかで障害が発生すると、そのデータベースとLDAP接続は解放されます。アクティブ/アクティブ・デプロイメント内にある障害が発生していないインスタンスは、独自の接続を行い、障害が発生したインスタンス上にある未完了のトランザクションの処理を継続します。


Oracle Identity Managerを高可用性構成にデプロイする場合は、次のことに注意してください。


    

  • 

    Oracle Identity ManagerはOracle RACデータベースにデプロイできますが、Oracle RACのフェイルオーバーは、このリリースではOracle Identity Managerに対して透過的ではありません。Oracle RACのフェイルオーバーが発生すると、エンド・ユーザーは、各自のリクエストを再送信する必要がある場合があります。
    

    • 

  • 

    Oracle Identity Managerは常に、SOAクラスタ内で少なくとも1つのノードが使用可能であることを必要とします。SOAクラスタが使用可能でない場合、エンド・ユーザーのリクエストは失敗します。Oracle Identity Managerノードは、失敗したSOA呼出しに対して再試行しません。そのため、SOA呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。
    

    • 









5.3.21 Oracle Identity Managerの高可用性のトラブルシューティング


アクティブ/アクティブOracle Identity Manager構成において、Oracle Identity Managerでユーザーを作成していて(Oracle Identity Managerにログインし、「管理」タブをクリックして、「ユーザーの作成」リンクをクリックし、フィールドに必要な情報を入力してから、「保存」をクリックします)、そのリクエストを処理中のOracle Identity Managerサーバーに障害が発生した場合、Oracle Identity Managerログ・ファイルに次のようなResourceConnectionValidationxceptionが記述されることがあります。


[2010-06-14T15:14:48.738-07:00] [oim_server2] [ERROR] [] [XELLERATE.SERVER]
[tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: xelsysadm] [ecid:
004YGJGmYrtEkJV6u3M6UH00073A0005EI,0:1] [APP: oim#11.1.1.3.0] [dcid:
12eb0f9c6e8796f4:-785b18b3:12938857792:-7ffd-0000000000000037] [URI:
/admin/faces/pages/Admin.jspx] Class/Method:
PooledResourceConnection/heartbeat encounter some problems: Operation timed
out[[
com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception: Operation
timed out
        at
oracle.iam.ldapsync.impl.repository.LDAPConnection.heartbeat(LDAPConnection.ja
va:162)
        at
com.oracle.oim.gcp.ucp.PooledResourceConnection.heartbeat(PooledResourceConnec
tion.java:52)
         .
         .
         .



この例外を受け取った場合でも、ユーザーは正常に作成されます。








5.3.22 Oracle Identity Managerトポロジのスケール・アップとスケール・アウト


Oracle Identity Manager高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。





5.3.22.1 Oracle Identity Managerのスケール・アップ


この場合は、SOAコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードには、既存の管理対象サーバーのMiddlewareホーム、Oracleホーム(SOA)およびドメイン・ディレクトリが含まれます。


新しいWLS_OIMおよびWLS_SOAサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。OIMおよびSOAのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。


トポロジをスケール・アップするには:


    

  1. 

    管理コンソールを使用して、WLS_OIM1またはWLS_SOA1のクローンを新しい管理対象サーバーに作成します。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
    

    管理対象サーバーのクローンを作成する手順は次のとおりです。
    

      

    1. 

      管理コンソールから「環境」→「サーバー」を選択します。
      

      2. 

    2. 

      クローンを作成する管理対象サーバー(WLS_OIM1またはWLS_SOA1)を選択します。
      

      3. 

    3. 

      「クローンの作成」を選択します。
      

      4. 

    4. 

      新しい管理対象サーバーにWLS_OIMnまたはWLS_SOAnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
      

      5. 

    

    この後の手順では、すでにWLS_SOA1およびWLS_OIM1を実行しているOIMHOST1に新しいサーバーを追加することを想定しています。
    

    2. 

  2. 

    リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPを割り当てます。このサーバーでお薦めしているサーバー移行を実行する予定の場合は、別のノードへの移動を可能にするために、このアドレスはVIP(別称: 浮動IP)である必要があります。このVIPは、実行されている管理対象サーバーとは別のものを使用してください。
    

    3. 

  3. 

    新しい管理対象サーバーにSOA、OIM、BPM、UMS、JRFWSAsyncおよびPS6SOAのJMSサーバーを作成します。
    

      

    1. 

      管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_nのような名前を付けます。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      
      		

      
      

      

      

      

      2. 

    2. 

      SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n)。このJMSサーバーに対して、SOAJMSFileStore_nを使用します。SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      3. 

    3. 

      新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      4. 

    4. 

      UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。このJMSサーバーに対して、UMSJMSFileStore_nを使用します。UMSJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      5. 

    5. 

      新しいOIMJMSServerの新しい永続ストアを作成します(たとえば、OIMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいOIM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      6. 

    6. 

      OIMの新しいJMSサーバーを作成します(たとえば、OIMJMSServer_n)。このJMSサーバーに対して、OIMJMSFileStore_nを使用します。OIMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。
      

      7. 

    7. 

      新しいJRFWSAsyncJMSServerの新しい永続ストアを作成します(たとえば、JRFWSAsyncJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n

      8. 

    8. 

      JRFWSAsync用の新しいJMSサーバーを作成します(たとえば、JRFWSAsyncJMSServer_n)。このJMSServerに対して、JRFWSAsyncJMSFileStore_nを使用します。JRFWSAsyncJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。
      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいJRFWSAsync JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      9. 

    9. 

      新しいPS6JMSServerの新しい永続ストアを作成します(たとえば、PS6JMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/PS6JMSFileStore_n

      10. 

    10. 

      PS6用の新しいJMSサーバーを作成します(たとえば、PS6JMSServer_n)。このJMSServerに対して、PS6JMSFileStore_nを使用します。PS6JMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。
      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいPS6 JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      11. 

    11. 

      新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      12. 

    12. 

      サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      13. 

    13. 

      新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUMSJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      14. 

    14. 

      サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      15. 

    15. 

      新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      16. 

    16. 

      サブデプロイメント「OIMJMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      17. 

    17. 

      新たに作成されたJRFWSAsync JMSサーバーが含まれるように、JRFWSAsyncJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「JRFWSAsyncJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。JRFWSAsyncJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。JRFWSAsyncJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたJRFWSAsyncJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      18. 

    18. 

      サブデプロイメント「JRFWSAsyncJMSServerXXXXXX」をクリックします。このサブデプロイメントに、JRFWSAsyncJMSServer_nと呼ばれる、JRFWSAsyncの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      19. 

    19. 

      新たに作成されたPS6SOA JMSサーバーが含まれるように、PS6SOAJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「PS6SOAJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。PS6SOAJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。PS6SOAJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたPS6SOAJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      20. 

    20. 

      サブデプロイメント「PS6SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、PS6SOAJMSServer_nと呼ばれる、PS6SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      21. 

    

    4. 

  4. 

    デプロイするコンポジットのOracle Coherenceを構成します。
    

    


    

    


    


    注意:
    

    サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例:
    

    Dtangosol.coherence.localhost=SOAHOST1VHNn
    
    		

    
    

    

    

    

    5. 

  5. 

    新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
    

    管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
    

    6. 

  6. 

    新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再度有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
    

    ホスト名の検証を無効化するには、次の手順を実行します。
    

      

    1. 

      Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
      

      2. 

    2. 

      「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
      

      3. 

    3. 

      「サーバー」をクリックします。表の「名前」列で「WLS_SOAn」を選択します。
      

      4. 

    4. 

      「SSL」タブをクリックします。「詳細」をクリックします。
      

      5. 

    5. 

      「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
      

      6. 

    

    7. 

  7. 

    管理コンソールから新しい管理対象サーバーを起動して、テストします。
    

      

    1. 

      クラスタ内の既存の管理対象サーバーを停止します。
      

      2. 

    2. 

      新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。
      

      3. 

    3. 

      新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。
      

      4. 

    

    8. 

  8. 

    管理コンソールにログインします。「サービス」→「外部JNDIプロバイダ」リンクを選択します。「ForeignJNDIProvider-SOA」を選択し、新しいサーバーを既存の値に追加します。
    

    9. 

  9. 

    新しい管理対象サーバーに対してサーバー移行を構成します。
    

    


    

    


    


    注意:
    

    これはスケール・アップ操作であるため、ノード・マネージャ、サーバー移行に対して構成された環境および新しいSOA管理対象サーバーの浮動IPがあらかじめノードに用意されている必要があります。
    
    		

    
    

    

    

    

    サーバー移行を構成する手順は次のとおりです。
    

      

    1. 

      管理コンソールにログインします。
      

      2. 

    2. 

      左側のペインで、「環境」を開き、「サーバー」を選択します。
      

      3. 

    3. 

      移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。
      

      4. 

    4. 

      「移行」タブをクリックします。
      

      5. 

    5. 

      「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。
      

      たとえば、すでにWLS_SOA1が実行されているSOAHOST1上の新しい管理対象サーバーには、SOAHOST2を選択します。すでにWLS_SOA2が実行されているSOAHOST2上の新しい管理対象サーバーには、SOAHOST1を選択します。
      

      移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。
      

      6. 

    6. 

      「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
      

      7. 

    7. 

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

      8. 

    8. 

      管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
      

      9. 

    9. 

      新しく作成したWLS_OIMn管理対象サーバーに対してサーバー移行を構成するために、このリストの手順を繰り返します。
      

      10. 

    

    10. 

  10. 

    この新規サーバーのサーバー移行をテストするには、新規サーバーの追加先となったノードで、次の手順を実行します。
    

      

    1. 

      管理対象サーバーWLS_SOAnを停止します。
      

      そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを入力します。
      

      2. 

    2. 

      ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
      

      3. 

    3. 

      ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
      

      4. 

    4. 

      ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
      

      5. 

    

    11. 









5.3.22.2 Oracle Identity Managerのスケール・アウト


トポロジのスケール・アウトでは、SOAで構成された新しい管理対象サーバーを新しいノードに追加します。


この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。


    

  • 

    SOAで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。
    

    • 

  • 

    新しいノードがWebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること。(新しい管理対象サーバーWLS_SOAまたはWLS_OIMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやSOAバイナリをインストールする必要はありませんが、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ファイルを編集します。次の手順を参照してください。
    
    		

    
    

    

    

    

    • 



トポロジをスケール・アウトするには、次の手順を実行します。


    

  1. 

    新しいノードで、SOAのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
    

    2. 

  2. 

    共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。
    

    SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>

    

    Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
    

    3. 

  3. 

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

    4. 

  4. 

    新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
    

    5. 

  5. 

    このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
    

    6. 

  6. 

    管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。このサーバーにWLS_SOAnという名前を付けます。nは番号です。
    

    


    

    


    


    注意:
    

    これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。
    
    		

    
    

    

    

    

    7. 

  7. 

    新しい管理対象サーバーでその管理対象サーバーのリスニング・アドレスに使用するホスト名またはIPを割り当てます。
    

    このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーのVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、既存の管理対象サーバーとは別のものを使用してください。
    

    8. 

  8. 

    新しい管理対象サーバーにSOA、OIM (該当する場合)、UMS、BPM、JRFWSAsyncおよびPS6SOAのJMSサーバーを作成します。
    

      

    1. 

      管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_nのような名前を付けます。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      
      		

      
      

      

      

      

      2. 

    2. 

      SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n)。このJMSサーバーに対して、SOAJMSFileStore_nを使用します。SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      3. 

    3. 

      新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      4. 

    4. 

      UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。このJMSサーバーに対して、UMSJMSFileStore_nを使用します。UMSJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      5. 

    5. 

      新しいOIMJMSServerの新しい永続ストアを作成します(たとえば、OIMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいOIM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      6. 

    6. 

      OIMの新しいJMSサーバーを作成します(たとえば、OIMJMSServer_n)。このJMSサーバーに対して、OIMJMSFileStore_nを使用します。OIMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。
      

      7. 

    7. 

      新しいBPMJMSServerの新しい永続ストアを作成します(たとえば、BPMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいBPM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      8. 

    8. 

      BPMの新しいJMSサーバーを作成します(たとえば、BPMJMSServer_n)。このJMSServerに対して、BPMJMSFileStore_nを使用します。BPMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      9. 

    9. 

      新しいJRFWSAsyncJMSServerの新しい永続ストアを作成します(たとえば、JRFWSAsyncJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいJRFWSAsync JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      10. 

    10. 

      JRFWSAsync用の新しいJMSサーバーを作成します(たとえば、JRFWSAsyncJMSServer_n)。このJMSServerに対して、JRFWSAsyncJMSFileStore_nを使用します。JRFWSAsyncJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      11. 

    11. 

      新しいPS6SOAJMSServerの新しい永続ストアを作成します(たとえば、PS6SOAJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/PS6SOAJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいPS6SOA JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      12. 

    12. 

      PS6SOA用の新しいJMSサーバーを作成します(たとえば、PS6SOAJMSServer_n)。このJMSServerに対して、PS6SOAJMSFileStore_nを使用します。PS6SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      13. 

    13. 

      新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      14. 

    14. 

      サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      15. 

    15. 

      新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUMSJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      16. 

    16. 

      サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      17. 

    17. 

      新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      18. 

    18. 

      サブデプロイメント「OIMJMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      19. 

    

    9. 

  9. 

    次のようにpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。
    

    SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true/
-domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

    

    次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをSOAHOSTnにコピーします。
    

    SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/
ORACLE_BASE/product/fmw/soa/common/bin

    

    次のようにSOAHOSTnでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
    

    SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/common/bin
SOAHOSTN> ./unpack.sh /
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar

    10. 

  10. 

    デプロイするコンポジットのOracle Coherenceを構成します。
    

    


    

    


    


    注意:
    

    サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例:
    

    Dtangosol.coherence.localhost=SOAHOST1VHNn
    
    		

    
    

    

    

    

    11. 

  11. 

    新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
    

    管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
    

    12. 

  12. 

    新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
    

    ホスト名の検証を無効化するには、次の手順を実行します。
    

      

    1. 

      Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
      

      2. 

    2. 

      「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
      

      3. 

    3. 

      「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
      

      4. 

    4. 

      表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。
      

      5. 

    5. 

      「SSL」タブをクリックします。
      

      6. 

    6. 

      「詳細」をクリックします。
      

      7. 

    7. 

      「ホスト名の検証」を「なし」に設定します。
      

      8. 

    8. 

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

      9. 

    

    13. 

  13. 

    新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
    

    SOAHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip

    14. 

  14. 

    管理コンソールから新しい管理対象サーバーを起動して、テストします。
    

      

    1. 

      クラスタ内の既存の管理対象サーバーを停止します。
      

      2. 

    2. 

      新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。
      

      3. 

    3. 

      新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。
      

      4. 

    

    15. 

  15. 

    新しい管理対象サーバーに対してサーバー移行を構成します。
    

    


    

    


    


    注意:
    

    この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャと、ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しいSOA管理対象サーバーの浮動IPが存在します。
    
    		

    
    

    

    

    

    次の手順を実行してサーバー移行を構成します。
    

      

    1. 

      管理コンソールにログインします。
      

      2. 

    2. 

      左側のペインで、「環境」を開き、「サーバー」を選択します。
      

      3. 

    3. 

      移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。
      

      4. 

    4. 

      「移行」タブをクリックします。
      

      5. 

    5. 

      「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
      

      


      

      


      


      注意:
      

      マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードのリソースが追加の管理対象サーバーの持続に十分対応できるように、必須の容量計画を立てる必要があります。
      
      		

      
      

      

      

      

      6. 

    6. 

      「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
      

      7. 

    7. 

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

      8. 

    8. 

      管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
      

      9. 

    

    16. 

  16. 

    この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。
    

      

    1. 

      管理対象サーバーWLS_SOAnを停止します。
      

      そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを実行します。
      

      2. 

    2. 

      ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。
      

      3. 

    3. 

      ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
      

      4. 

    4. 

      ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
      

      5. 

    

    17. 































 
前
 前 		
次
 次		











 
目次へ移動
 目次