1. Oracle Identity and Access Managementのインストールおよび構成
  2. Oracle Identity Governanceコンポーネントの高可用性の構成

6 Oracle Identity Governanceコンポーネントの高可用性の構成

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

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

OIGの詳細については、『Oracle Fusion Middleware Oracle Identity Governanceの管理』のOracle Identity Governanceの製品の概要に関する項を参照してください。

ノート:

ドキュメント内のOracle Identity GovernanceおよびOracle Identity Managerの製品名のリファレンスは同じものを意味します。
  • Oracle Identity Governanceのアーキテクチャ
    Oracle Identity Governanceのアーキテクチャは、そのコンポーネント、ランタイム・プロセス、プロセス・ライフサイクル、構成アーティファクト、外部依存性、およびログ・ファイルからなります。
  • Oracle Identity Governanceの高可用性の概念
    Oracle Identity Governanceの高可用性に関連する概念は、OIG高可用性アーキテクチャ、OIGクラスタの起動と停止、およびクラスタワイドの構成変更です。
  • 高可用性のディレクトリ構造の前提条件
    高可用性デプロイメントでは、製品インストールとファイルが特定のディレクトリに存在する必要があります。標準のディレクトリ構造を用いることで、ノード全体の構成および製品の統合が容易になります。
  • Oracle Identity Governanceの高可用性の構成ステップ
    Oracle Identity Governanceの高可用性の構成には、前提条件の設定、ドメインの構成、インストール後のステップ、サーバーの起動、SOA統合、管理対象サーバー・インスタンスの検証、Oracle Identity Governanceのスケール・アップおよびスケール・アウトが含まれます。
  • 共有記憶域の準備
    Oracle Fusion Middlewareでは、単一のOracleホームから複数のWebLogic Serverドメインを構成することができます。これにより、共有ボリューム上の1つの場所にOracleホームをインストールすることや、複数のホストのインストールにOracleホームを再利用することができます。
  • ユニキャスト構成を使用したOracle Identity and Access Managementクラスタのデプロイ
    デプロイメント環境でマルチキャストIPが無効になっている場合は、ユニキャスト構成でOracle Identity and Access Managementクラスタをデプロイできます。

Oracle Identity Governanceのアーキテクチャ

Oracle Identity Governanceのアーキテクチャは、そのコンポーネント、ランタイム・プロセス、プロセス・ライフサイクル、構成アーティファクト、外部依存性、およびログ・ファイルからなります。

図6-1は、Oracle Identity Governanceのアーキテクチャを示しています:

図6-1 Oracle Identity Governanceコンポーネントのアーキテクチャ

図6-1の説明が次にあります
「図6-1 Oracle Identity Governanceコンポーネントのアーキテクチャ」の説明

親トピック: Oracle Identity Governanceコンポーネントの高可用性の構成

Oracle Identity Governanceコンポーネントの特性

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

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

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

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

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

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

このリリースでは、BI PublisherはOIMに組み込まれていません。しかし、Oracle Identity Manager Governanceのためのアプリケーションの開発とカスタマイズのレポートの構成に関する項の手順に従って、BI PublisherとOIMを統合できます。

親トピック: Oracle Identity Governanceのアーキテクチャ

ランタイム・プロセス

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

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

親トピック: Oracle Identity Governanceのアーキテクチャ

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

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

OIMは、アプリケーション・サーバー・コンポーネントが起動した後に起動します。OIMコンポーネント・メカニズムの一部である認証システムが使用され、それはWebLogic JNDIが初期化されてアプリケーションが起動する前に起動します。

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

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

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

親トピック: Oracle Identity Governanceのアーキテクチャ

Oracle Identity Governanceの起動および停止

OIMライフサイクル・イベントは、次のコマンド行ツールおよびコンソールを使用して管理します。

  • Oracle WebLogic Scripting Tool(WLST)

  • WebLogic Server管理コンソール

  • Oracle Enterprise Manager Fusion Middleware Control。

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

親トピック: Oracle Identity Governanceのアーキテクチャ

構成アーティファクト

OIMサーバー構成は、MDSリポジトリ(/db/oim-config.xml)に格納されます。oim-config.xmlファイルがメイン構成ファイルです。OIM構成は、Oracle Enterprise Manager Fusion Middleware Controlまたはコマンド行MDSユーティリティを介してMBeanブラウザを使用して管理します。MDSユーティリティの詳細は、Oracle Fusion Middleware Oracle Identity Managerのためのアプリケーションの開発とカスタマイズのユーザー構成可能メタデータ・ファイルの移行に関する項を参照してください。

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

  • oimAttestationQueue

  • oimAuditQueue

  • oimDefaultQueue

  • oimKernelQueue

  • oimProcessQueue

  • oimReconQueue

  • oimSODQueue

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

親トピック: Oracle Identity Governanceのアーキテクチャ

外部依存性

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

  • WebLogic Server

    • 管理サーバー

    • 管理対象サーバー

  • データ・リポジトリ

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

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

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

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

  • BI Publisher、これはオプションでOIMと統合できます

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

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

親トピック: Oracle Identity Governanceのアーキテクチャ

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

Java EEアプリケーションはWebLogic Serverにデプロイされるので、サーバー・ログ・メッセージはすべてサーバーのログ・ファイルに記録されます。OIM固有のメッセージは、アプリケーションがデプロイされるWebLogic Serverの診断ログ・ファイルに記録されます。

WebLogic Serverのログ・ファイルは、次のディレクトリにあります。

DOMAIN_HOME/servers/serverName/logs

主なログ・ファイルは、serverName.log、serverName.outおよびserverName-diagnostic.logの3つですが、ここでserverNameはWebLogic Serverの名前です。たとえば、WebLogic Server名がwls_OIM1の場合、診断ログ・ファイル名はwls_OIM1-diagnostic.logになります。ログ・ファイルを表示するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。

親トピック: Oracle Identity Governanceのアーキテクチャ

Oracle Identity Governanceの高可用性の概念

Oracle Identity Governanceの高可用性に関連する概念は、OIG高可用性アーキテクチャ、OIGクラスタの起動と停止、およびクラスタワイドの構成変更です。

ノート:

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

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

親トピック: Oracle Identity Governanceコンポーネントの高可用性の構成

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

図6-2は、高可用性アーキテクチャにデプロイされたOIMを示しています。

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

図6-2の説明が次にあります
「図6-2 Oracle Identity Governanceの高可用性アーキテクチャ」の説明

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

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

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

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

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

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

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

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

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

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

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

  • OIMVHN1は、WLS_OIM1管理対象サーバーのリスニング・アドレスにマップし、WLS_OIM1管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_OIM1管理対象サーバーが実行されているノード(デフォルトではOIMHOST1)で有効化されます。

  • OIMVHN2は、WLS_OIM2管理対象サーバーのリスニング・アドレスにマップし、WLS_OIM2管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_OIM2管理対象サーバーが実行されているノード(デフォルトではOIMHOST2)で有効化されます。

  • SOAVHN1は、WLS_SOA1管理対象サーバーのリスニング・アドレスで、WLS_SOA1管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_SOA1管理対象サーバーが実行されているノード(デフォルトではOIMHOST1)で有効化されます。

  • SOAVHN2は、WLS_SOA2管理対象サーバーのリスニング・アドレスで、WLS_SOA2管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_SOA2管理対象サーバーが実行されているノード(デフォルトではOIMHOST2)で有効化されます。

  • VHNは、Oracle Real Application Clusters (Oracle RAC)データベース・ホストの仮想IPアドレスを指します。

親トピック: Oracle Identity Governanceの高可用性の概念

OIGクラスタの起動と停止

デフォルトでは、WebLogic Serverによって、このアプリケーションに対するライフサイクル・イベントの起動、停止、監視および管理が行われます。OIMアプリケーションは、クラスタの高可用性機能を利用します。ハードウェアまたは他の原因により失敗が発生した場合、他のクラスタ・ノードでセッション状態を利用でき、そのノードで障害の起きたノードの作業を再開できます。

OIMライフサイクル・イベントを管理するには、次のコマンド行ツールおよびコンソールを使用します。

  • WebLogic Server管理コンソール

  • Oracle Enterprise Manager Fusion Middleware Control。

  • Oracle WebLogic Scripting Tool(WLST)

親トピック: Oracle Identity Governanceの高可用性の概念

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

高可用性環境では、すべてのOIMインスタンスが同じ構成リポジトリを共有するため、OIMの1つのインスタンスの構成を変更するとその他すべてのインスタンスの構成も変更されます。

親トピック: Oracle Identity Governanceの高可用性の概念

高可用性のディレクトリ構造の前提条件

高可用性デプロイメントでは、製品インストールとファイルが特定のディレクトリに存在する必要があります。標準のディレクトリ構造を用いることで、ノード全体の構成および製品の統合が容易になります。

高可用性を構成する前に、「高可用性のディレクトリ構造の前提条件」で説明している要件を使用環境が満たしていることを確認してください。

親トピック: Oracle Identity Governanceコンポーネントの高可用性の構成

Oracle Identity Governanceの高可用性の構成ステップ

Oracle Identity Governanceの高可用性の構成には、前提条件の設定、ドメインの構成、インストール後のステップ、サーバーの起動、SOA統合、管理対象サーバー・インスタンスの検証、Oracle Identity Governanceのスケール・アップおよびスケール・アウトが含まれます。

この項では、OIMの高可用性デプロイメントを設定する大まかな手順について説明し、次のトピックが含まれます。

親トピック: Oracle Identity Governanceコンポーネントの高可用性の構成

Oracle Identity Governanceの構成のための前提条件

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

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

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

作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。「データベース・スキーマの作成」を参照。

ドメインの構成

構成ウィザードを使用して、ドメインを作成および構成します。

アイデンティティ管理ドメインの作成の詳細は、「ドメインの構成」、「追加のドメイン構成」、「構成後タスクの実行」を参照してください。

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

OIMHOST1におけるインストール後のステップ

この項では、OIMHOST1におけるインストール後のステップについて説明します。

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

オフライン構成コマンドの実行

Oracle Identity Governanceドメインを構成した後、offlineConfigManagerスクリプトを実行して、構成後のタスクを実行します。

必ずこのコマンドを実行してから、サーバーを起動します。offlineConfigManagerコマンドを実行するには、次を行います。
  1. 次の環境変数を正しい値に設定します。

    • DOMAIN_HOME

    • JAVA_HOME

  2. ファイルOIM_HOME/server/bin/offlineConfigManager.shに対する実行権限を持っていることを確認します。
  3. OIM_HOME/server/bin/から次のコマンドを実行します。

    • UNIXの場合: ./offlineConfigManager.sh

    • Windowsの場合: offlineConfigManager.bat

SSL有効サーバーのシステム・プロパティの更新

SSL有効サーバーの場合、ドメイン・ホームのsetDomainEnvファイルで必要なプロパティを設定する必要があります。

サーバーを起動する前に、DOMAIN_HOME/bin/setDomainEnv.sh (UNIXの場合)またはDOMAIN_HOME\bin\setDomainEnv.cmd (Windowsの場合)ファイルで次のプロパティを設定します。

  • -Dweblogic.security.SSL.ignoreHostnameVerification=true

  • -Dweblogic.security.TrustKeyStore=DemoTrust

管理サーバー、oim_server1およびsoa_server1の起動

管理サーバー、oim_server1およびsoa_server1を起動するには、次のようにします。
  1. 管理サーバーを起動するには、DOMAIN_HOME/binディレクトリに移動し、次のコマンドを実行します。

    UNIXの場合: ./startWebLogic.sh

    Windowsの場合: startWebLogic.cmd

    「ドメイン・モードおよびJDK」画面で「本番モード」を選択した場合、「管理者アカウント」画面に表示されたように、管理者ユーザーのログイン資格証明のプロンプトが表示されます。

    管理サーバー・コンソールにアクセスすることで、管理サーバーが稼働中であることを確認できます。URLは「構成の終了」画面に指定されます(http://administration_server_host:administration_server_port/console)。デフォルトの管理サーバーのポート番号は7001です。

    ノート:

    製品スキーマをホストしているデータベースが稼働中であり、管理サーバーからアクセスできることを確認してください。
  2. HOST1でノード・マネージャを起動します。このためには、DOMAIN_HOME/binディレクトリから次のコマンドを実行します。

    (UNIX) nohupと nm.outをサンプル出力ファイルとして使用します。

    nohup ./startNodeManager.sh > LOG_DIR/nm.out&

    ここで、LOG_DIRは、ログ・ファイルを格納するディレクトリの場所になります。

    (Windows) startNodeManager.cmd

  3. 先にOracle SOA Suite管理対象マネージャを起動してからOracle Identity Governance管理対象サーバーを実行します。管理サーバーを起動するには:

    1. Oracle Fusion Middleware Controlにログインします。

      http://administration_server_host:administration_server_port/em

      Enterprise Managerのランディング・ページには、このドメインに構成されているサーバーのリストと、それらのステータスが表示されます(「実行中」または「停止」など)。新しく構成されたドメインでは、AdminServer(admin)のみが実行されています。

    2. 「wls_soa1」を選択します。

    3. 「コントロール」リストから「起動」を選択します。

    4. ステップbおよびcを繰り返してwls_oim1を起動します。

      ノート:

      サーバーが次の順序で起動されることを確認します。

      1. ノード・マネージャ

      2. 管理サーバー

      3. Oracle SOA Suite管理対象サーバー

      4. Oracle Identity Manager管理対象サーバー

    5. メインのランディング・ページで、すべての管理対象サーバーが稼働中であることを確認します。

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

Oracle Identity GovernanceとOracle SOA Suiteの統合

Oracle Identity GovernanceとOracle SOA Suiteを統合するには、次のようにします。
  1. 次のURLに移動してOracle Fusion Middleware Controlにログインします。

    http://administration_server_host:administration_server_port/em

  2. weblogic_domainをクリックし、「システムMBeanブラウザ」を選択します。
  3. 検索ボックスに、OIMSOAIntegrationMBeanと入力して、「検索」をクリックします。mbeanが表示されます。

    ノート:

    Oracle Identity Governanceがまだ起動している(起動中)または起動したばかり(RUNNING MODE)な場合、Enterprise ManagerはOIGにより定義されたMbeanを表示しません。サーバーが起動するのを2分間待ってから、Enterprise ManagerのシステムMbeanブラウザでMbeanの検索を試みます。
  4. Mbeanの「操作」タブをクリックし、integrateWithSOAServerを選択します。
  5. 必要な属性を入力して、「呼出し」をクリックします。

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

OIMHOST2へのOracle Identity Governanceの伝播

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

ノート:

構成をOIMHOST2に伝播する前に、OIMHOST1上の管理対象サーバーをすべてクリーン・シャット・ダウンすることをお薦めします。

OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍するには:

  1. OIMHOST1上で、ORACLE_HOME/oracle_common/common/binディレクトリにあるpackユーティリティを呼び出します。
    pack.sh -domain=ORACLE_HOME/user_projects/domains/OIM_Domain -
template =/u01/app/oracle/admin/templates/oim_domain.jar -
template_name="OIM Domain" -managed=true
  2. 前のステップで作成したoim_domain.jarファイルは、次のディレクトリにあります。
    /u01/app/oracle/admin/templates

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

  3. OIMHOST2上で、ORACLE_HOME/oracle_common/common/binディレクトリにあるunpackユーティリティを呼び出し、その一時ディレクトリにあるoim_domain.jarファイルの場所を指定します。
    unpack.sh -domain=ORACLE_HOME/user_projects/domains/OIM_Domain -
template=/tmp/oim_domain.jar

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

OIMHOST2におけるインストール後のステップ

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

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

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

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

OIMHOST2で管理対象サーバーを起動するには:

  1. 管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。
  2. 管理コンソールを使用して、WLS_OIM2管理対象サーバーを起動します。WLS_OIM2管理対象サーバーを起動する前に、WLS_SOA2管理対象サーバーを起動してください。
SOAエンド・ポイントの構成

SOAエンド・ポイントを構成するには:
  1. 次のURLに移動して、Oracle Fusion Middleware Enterprise Manager Controlにログインします:

    http://ADMINISTRATION_SERVER_HOST:ADMINISTRATION_SERVER_PORT/em

  2. weblogic_domainをクリックし、「システムMBeanブラウザ」を選択します。
  3. 「アプリケーション定義のMBean」→「oracle.iam」→「Server: OIM_SERVER_NAME」→「Application: oim」→「XMLConfig:Config」→「XMLConfig.SOAConfig:SOAConfig」に移動します。
  4. 次の属性の値を入力します:

    SOA構成RMI URL: cluster:t3://<SOA_cluster>

    SOA構成SOAP URL: http://<OHS_hostname>:<OHS_PORT>

    ノート:

    Oracle HTTPサーバーの階層を上位のロード・バランサまたはWebホストとともに使用してシングル・ポイント障害を軽減している場合は、公開されているマシンのホストおよびポートを使用してOIMアイデンティティおよびsysadmin URLにアクセスします。

  5. 「呼出し」をクリックします。

OIMHOST2での管理対象サーバー・インスタンスの検証

OIMHOST2でOracle Identity Manager (OIM)インスタンスを検証します。

次のURLを使用してOIMコンソールを開きます。

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

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

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

OIGおよびSOA管理対象サーバーに対するサーバーの移行の構成

この高可用性トポロジでは、管理対象サーバーWLS_OIM1、WLS_SOA1、WLS_OIM2、WLS_SOA2に対してサーバー移行を構成することをお薦めします。サーバー全体の移行を使用する利点と推奨する理由については、第3.9項「サーバー全体の移行」を参照してください。

  • OIMHOST1上のWLS_OIM1およびWLS_SOA1管理対象サーバーは、OIMHOST1で障害が発生した場合に、OIMHOST2で自動的に再起動するように構成されます。

  • OIMHOST2上のWLS_OIM2およびWLS_SOA2管理対象サーバーは、OIMHOST2で障害が発生した場合に、OIMHOST1で自動的に再起動するように構成されます。

このような構成では、WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2サーバーは、WebLogicサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。

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

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

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

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

Interface=eth0
eth0=*,NetMask=255.255.248.0
UseMACBroadcast=true

  • Interface: 浮動IPのインタフェース名(eth0など)を指定します。

    ノート:

    サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

  • NetMask: 浮動IPのインタフェースのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります(255.255.255.0は一例です)。実際の値は、ネットワークにより異なります。

  • UseMACBroadcast: ARPパケットの送信時にノードのMACアドレスを使用するかどうか、つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。(これを行うには、ノード・マネージャを再起動する必要があります。)ノード・マネージャの出力で、次のようなエントリが表示されることを確認します。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...
wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定

サーバー移行を構成するノードごとにwlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには:

  1. ノード・マネージャの実行に使用するユーザー・アカウントのログイン・プロファイルを変更して、ノード・マネージャ・プロセスのPATH環境変数にwlsifconfig.shスクリプトとwlscontrol.shスクリプトおよびnodemanager.domains構成ファイルが格納されているディレクトリを必ず含めるようにします。PATH環境変数に次のファイルが含まれていることを確認します。

    表6-1 PATH環境変数に必要なファイル

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

    wlsifconfig.sh

    DOMAIN_HOME/bin/server_migration

    wlscontrol.sh

    WL_HOME/common/bin

    nodemanager.domains

    WL_HOME/common

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      ヒント:

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

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

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

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

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

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

    7. 追加の管理対象サーバーに対して、前述のステップを繰り返します。

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

サーバー移行のテスト

サーバー移行が適切に機能していることを確認するには:

OIMHOST1から:

  1. 次のコマンドを実行して、WLS_OIM1管理対象サーバーを停止します。

    OIMHOST1> kill -9 pid

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

    OIMHOST1> ps -ef | grep WLS_OIM1

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

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

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

OIMHOST2から:

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

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

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

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

表6-2 WLS_OIM1、WLS_OIM2、WLS_SOA1、WLS_SOA2サーバー移行

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

WLS_OIM1

OIMHOST1

OIMHOST2

WLS_OIM2

OIMHOST2

OIMHOST1

WLS_SOA1

OIMHOST1

OIMHOST2

WLS_SOA2

OIMHOST2

OIMHOST1

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

管理コンソールで移行を検証するには:

  1. 管理者の資格証明を使用して、管理コンソール(http://oimhost1.example.com:7001/console)にログインします。
  2. 左側のコンソールで、「ドメイン」をクリックします。
  3. 「監視」タブをクリックし、「移行」サブタブをクリックします。

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

ノート:

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

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

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

ノート:

ネットワーク接続ストレージ(NAS)デバイスまたはストレージ・エリア・ネットワーク(SAN)上の場所をお薦めします。

OIMおよびSOAサーバーのデフォルト永続ストアの場所を設定するには:

  1. 管理者の資格証明を使用して、管理コンソール(http://oimhost1.example.com:7001/console)にログインします。
  2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。
  3. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)を選択します。サーバーの「設定」ページが開き、「構成」タブが表示されます。
  4. 「構成」タブの「サービス」サブタブを選択します(トップレベルの「サービス」タブではありません)。
  5. 「デフォルト・ストア」セクションで、デフォルトの永続ストアでデータ・ファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようにする必要があります。

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

      ORACLE_BASE/admin/domainName/soaClusterName/tlogs

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

      ORACLE_BASE/admin/domainName/oimClusterName/tlogs
  6. 「保存」をクリックします。

    ノート:

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

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

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

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

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

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

次の方法で、高可用性設定でOracle HTTP ServerとOracle Identity Governanceを同じ場所に配置できます。

  • OIGドメインを作成し、Oracle HTTP Serverを使用して同じOIMドメインを拡張します。この場合、Oracle HTTP ServerとOIGの両方に同じスキーマを再使用できます。
  • Oracle HTTP ServerおよびOIG用の個別のドメインを作成します。この場合、Oracle HTTP ServerとOIGの両方に同じスキーマを再使用できません。2つの個別のスキーマが必要です。
  • サイレントまたはwlstを使用してOracle HTTP Server用とOIG用の個別のドメインを作成します。この場合、Oracle HTTP ServerとOIGの両方に同じスキーマを再使用できます。

次のトピックでは、Oracle Web Tierと連携するためのOIGの構成方法について説明します。

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

Web Tierと連携するためのOIGの構成の前提条件

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

  1. Oracle Web TierをWEBHOST1とWEBHOST2にインストールしました。
  2. OIMがOIMHOST1およびOIMHOST2にインストールされ、構成済であること。
  3. ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(sso.example.com)で構成済であること。sso.example.comは顧客が接続する主要エントリ・ポイントで、通常はSSL終端です。
  4. ロード・バランサがWebサーバーWEBHOST1およびWEBHOST2を指す仮想ホスト名(oiminternal.example.com)で構成済であること。oiminternal.example.comは内部コールバック用で、顧客向けではありません。
ロード・バランサのSSL証明書の構成

ロード・バランサを使用するSSL対応サーバーでは、Oracle Web TierをOIMExternalFrontendURLに使用する際にSSL証明書を構成する必要があります。

  1. SSL証明書をロード・バランサからエクスポートします。
  2. SSL証明書をDemoTrust / cacertsキーストアにインポートします。デフォルト・ストアを使用していない場合は、SSL証明書をカスタム・ストアにインポートします。
  3. SOAサーバーとOIMサーバーの両方を停止します。
  4. サーバー・キャッシュおよび一時ディレクトリをクリアします。
  5. SOAサーバーとOIMサーバーの両方を再起動します。

    ノート:

    キーストアの詳細は、WebLogic Serverでのキーストアの構成に関する項を参照してください
OIMおよびSOA管理対象サーバーのフロントエンドに使用できるようにするためのOracle HTTP Serverの構成
  1. WEBHOST1とWEBHOST2上の各Webサーバーで、ディレクトリOHS_DOMAIN_HOME /config/fmwconfig/components/OHS/instances/OHS_INSTANCE_NAMEにmod_wls_ohs.confという名前のファイルを作成します。

    このファイルには次の情報が記載されている必要があります。

    # oim admin console(idmshell based)
   <Location /admin>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>
 
# oim self and advanced admin webapp consoles(canonic webapp)
 
  <Location /oim>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>

  <Location /identity>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid 
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>

  <Location /sysadmin>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>

# SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
  <Location /sodcheck>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster soavhn1.example.com:7003,soavhn2.example.com:7003
    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 OIM 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>
# used for FA Callback service.
  <Location /callbackResponseService>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# spml xsd profile
  <Location /spml-xsd>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

  <Location /HTTPClnt>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>
 

  <Location /reqsvc>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>
 
 
  <Location /integration>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicCluster soavhn1.example.com:7003,soavhn2.example.com:7003
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

 
  <Location /provisioning-callback>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>
 
  <Location /CertificationCallbackService>
   SetHandler weblogic-handler
   WLCookieName JSESSIONID
   WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
   WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
   WLProxySSL ON
   WLProxySSLPassThrough ON
 </Location>

  <Location /ucs>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicCluster soavhn1.example.com:7003,soavhn2.example.com:7003
   WLLogFile /tmp/web_log.log
   WLProxySSL ON
   WLProxySSLPassThrough ON
  </Location>

  <Location /FacadeWebApp>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
   WLLogFile /tmp/web_log.log
   WLProxySSL ON
   WLProxySSLPassThrough ON
  </Location>

  <Location /iam/governance/configmgmt>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
   WLLogFile /tmp/web_log.log
   WLProxySSL ON
   WLProxySSLPassThrough ON
  </Location>

  <Location /iam/governance/scim/v1>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
   WLLogFile /tmp/web_log.log
   WLProxySSL ON
   WLProxySSLPassThrough ON>
  </Location>

  <Location /iam/governance/token/api/v1>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
   WLLogFile /tmp/web_log.log
   WLProxySSL ON
   WLProxySSLPassThrough ON
  </Location>

  <Location /OIGUI>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
   WLLogFile /tmp/web_log.log
   WLProxySSL ON
   WLProxySSLPassThrough ON
  </Location>

  <Location /iam/governance/applicationmanagement>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
   WLLogFile /tmp/web_log.log
   WLProxySSL ON
   WLProxySSLPassThrough ON
  </Location>

  <Location /iam/governance/adminservice/api/v1>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
   WLLogFile /tmp/web_log.log
   WLProxySSL ON
   WLProxySSLPassThrough ON
  </Location>

  <Location /iam/governance/selfservice/api/v1>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
   WLLogFile /tmp/web_log.log
   WLProxySSL ON
   WLProxySSLPassThrough ON
  </Location>
  2. ORACLE_INSTANCE/config/OHS/COMPONENT/moduleconfにvirtual_hosts.confというファイルを作成します。このファイルは、次の情報を含む必要があります。

    ノート:

    COMPONENTは通常、ohs1またはohs2です。ただし、この名前はOHSのインストール時の選択内容によって異なります。 

    NameVirtualHost *:7777
<VirtualHost *:7777>

  ServerName http://sso.example.com:7777
  RewriteEngine On
  RewriteOptions inherit
  UseCanonicalName On
  </VirtualHost>

<VirtualHost *:7777>
  ServerName http://oiminternal.example.com:80
  RewriteEngine On
  RewriteOptions inherit
  UseCanonicalName On
</VirtualHost>
  3. WEBHOST1とWEBHOST2の両方でファイルを保存します。
  4. WEBHOST1およびWEBHOST2の両方で、Oracle HTTP Serverインスタンスを停止および起動します。

Oracle HTTP Serverの構成の検証

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

  1. Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。
    http://sso.example.com:7777/identity

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

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

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

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

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

ハードウェア・ロード・バランサでは、複数のOIMインスタンス間のリクエストをロード・バランシングします。OIM管理対象サーバーのいずれかに障害が発生した場合は、ロード・バランサによって障害が検出され、障害が発生していないインスタンスにリクエストがルーティングされます。

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

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

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

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

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

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

Oracle Identity Governanceのスケール・アップ

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

この場合は、SOAコンポーネントとともに構成された管理対象サーバーが実行されているノードが存在しています。ノードには次のものが含まれます。

  • Middlewareホーム

  • Oracleホーム(SOA)

  • 既存の管理対象サーバーのドメイン・ディレクトリ

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

この手順では、OIMおよびSOA管理対象サーバーのクローンを作成する方法について説明します。これらのコンポーネント・タイプの1つまたは2つでも、そのうちの1つがOIMであればクローンを作成できます。

次の点に注意してください。

  • この手順は、WLS_OIMおよびWLS_SOAについて説明しています。しかし、両方のコンポーネントをスケール・アップする可能性は少ないです。ステップごとに、使用環境でスケール・アップする対象のコンポーネントを選択してください。また、一部のコンポーネントには適用されないステップもあります

  • JMSサーバーの永続ストア用の共有記憶域ディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。

  • 永続ストアのパスを指定するときは必ず、共有記憶域上のディレクトリを指定する必要があります

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

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

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

    2. クローンを作成する管理対象サーバーを選択します。

    3. 「クローン」を選択します。

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

    この後のステップでは、すでにWLS_SOA1およびWLS_OIM1を実行しているOIMHOST1に新しい管理対象サーバーを追加することを想定しています。

  2. リスニング・アドレスとして、新しい管理対象サーバーのホスト名またはIPを割り当てます。サーバー移行の使用を計画している場合は、VIP (浮動IP)を使用して、管理対象サーバーを別のノードに移動できるようにします。既存の管理対象サーバーで使用されているVIPとは別のVIPを使用してください。

  3. 新しい管理対象サーバーにOIM/SOA、BPM、UMS、JRFWSAsyncおよびSOAJMServerを作成します。

    1. 管理コンソールで、OIM JMSサーバーの新しい永続ストアを作成し、名前を付けます。ストアのパス(共有記憶域上のディレクトリ)を指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms

    2. OIMの新しいJMSサーバーを作成します。JMSServerに対して、JMSFileStore_nを使用します。JMSServer_nを新しい管理対象サーバーにターゲット指定します。

    3. 新しいUMSJMSServerの永続ストアを作成します(たとえば、UMSJMSFileStore_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。 

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n

    4. UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。それを新しい管理対象サーバー(WLS_SOAn)にターゲット指定します。

    5. 新しいBPMJMSServerの永続ストアを作成します(たとえば、BPMJMSFileStore_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。 

      ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_n

    6. BPMの新しいJMSサーバーを作成します(たとえば、BPMJMSServer_n)。それを新しい管理対象サーバー(WLS_SOAn)にターゲット指定します。

    7. 新しいJRFWSAsyncJMSServerの新しい永続ストアを作成します(たとえば、JRFWSAsyncJMSFileStore_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。 

      ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n

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

      ノート:

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

    9. 新しいSOAJMSServerの永続ストアを作成します(たとえば、SOAJMSFileStore_auto_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。 

      ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_auto_n

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

      ノート:

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

    11. 新しいSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「SOAJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、SOAJMSServerXXXXXXサブデプロイメントをクリックし、SOAJMSServer_nを追加します。「保存」をクリックします。

      ノート:

      サブデプロイメント・モジュール名は、COMPONENTJMSServerXXXXXXという形式のランダム名です。これは、構成ウィザードにおける最初の2つの管理対象サーバー(WLS_COMPONENT1とWLS_COMPONENT2)のJMS構成から取得します。

    12. 新しいUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「UMSJMSSystemResource」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、UMSJMSServerXXXXXXサブデプロイメントをクリックし、UMSJMSServer_nを追加します。「保存」をクリックします。

    13. 新しいOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「OIMJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、OIMJMSServerXXXXXXとそのOIMJMSServer_nをクリックします。「保存」をクリックします。

    14. 新しいJRFWSAsync JMSサーバーが含まれるように、JRFWSAsyncJmsModuleのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JRFWSAsyncJmsModule」をクリックします(表の「名前」列内のハイパーリンク)。「設定」ページで「サブデプロイメント」タブをクリックします。JRFWSAsyncJMSServerXXXXXXサブデプロイメントをクリックし、このサブデプロイメントにJRFWSAsyncJMSServer_nを追加します。「保存」をクリックします

    15. 新しいBPM JMSサーバーが含まれるように、BPM JMSモジュールのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「BPMJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、BPMJMSServerXXXXXXサブデプロイメントをクリックし、BPMJMSServer_nを追加します。「保存」をクリックします。

  4. 新しいサーバーのトランザクション永続ストアを、他のノードから参照可能な共有記憶域の場所に構成します。

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

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

    ホスト名の検証を無効化するには:

    1. 管理コンソールの「ドメイン構造」ウィンドウで「環境」ノードを展開します。

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

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

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

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

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

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

    3. 新たに作成した管理対象サーバーのアプリケーションにアクセスし、それが動作していることを確認します。OIMのログイン・ページが開きます。SOAの場合は、HTTP基本認証が開きます。

    表6-3 管理対象サーバーのテストURL

    コンポーネント 管理対象サーバーのテストURL

    SOA

    http://vip:port/soa-infra

    OIM

    http://vip:port/identity

  7. 管理コンソールで、「サービス」→「外部JNDIプロバイダ」を選択します。ForeignJNDIProvider-SOAが、管理対象サーバーではなくcluster:t3://soa_clusterにターゲット指定されていることを確認します。クラスタにターゲット指定すると、新しい管理対象サーバーを構成する必要がありません。ForeignJNDIProvider-SOAのターゲットがクラスタでない場合は、クラスタにターゲット指定してください。

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

    ノート:

    スケール・アップの場合、ノードにはノード・マネージャ、サーバー移行に対して構成された環境、および新しい管理対象サーバーの浮動IPが必要です。

    サーバー移行を構成するには:

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

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

    3. 移行を構成するサーバー(ハイパーリンク)を選択します。

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

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

      たとえば:

      SOAHOST1 (すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。

      SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

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

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

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

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

    9. これらのステップを繰り返し、新たに作成したWLS_OIMn管理対象サーバーに対してサーバー移行を構成します。

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

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

      管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDを特定するには、ps -ef | grep WLS_SOAnのように入力します。

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

    3. ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

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

  10. OHS構成ファイルを編集して、新しい管理対象サーバーを追加します。「新しい管理対象サーバーを認識するためのOracle HTTP Serverの構成」を参照してください。

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

Oracle Identity Governanceのスケール・アウト

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

ノート:

この手順の各ステップは、WLS_OIMおよびWLS_SOAについて説明しています。しかし、両方のコンポーネントをスケール・アップする可能性は少ないです。ステップごとに、使用環境でスケール・アップする対象のコンポーネントを選択してください。一部のコンポーネントには適用されないステップもあります。

スケール・アウトする前に、次の要件を満たしていることを確認してください。

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

  • 新しいノードがWebLogic Server、SOAおよびOIMの既存のホーム・ディレクトリにアクセスできること。(新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic Serverやコンポーネント・バイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります。)

    ノート:

    共有記憶域に既存のインストールが存在しない場合は、WebLogic Server、SOAおよびOIMを新しいノードにインストールする必要があります。

    ノート:

    ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを追加する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。

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

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

  2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加します。たとえば: 

    cd /u01/app/oracle/soa/
./attachHome.sh -jreLoc u01/app/JRE-JDK_version>

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

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

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

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

  6. WLS_OIM1/WLS_SOA1のクローンを作成します。

    OIMおよびSOAのクローンを作成するには:

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

    2. クローンを作成する管理対象サーバーを選択します。

    3. 「クローン」を選択します。

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

    ノート:

    このステップでは、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

  7. 新しい管理対象サーバーでその管理対象サーバーのリスニング・アドレスに使用するホスト名またはIPを割り当てます。さらに、ステップ4で作成した新しいマシンで、「マシン」パラメータの値を更新します。

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

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

    1. 管理コンソールで、OIM JMSサーバーの新しい永続ストアを作成し、名前を変更します。ストアのパス(共有記憶域上のディレクトリ)を指定します。

      ORACLE_BASE/admin/domain_name/cluster_name/jms

    2. OIMの新しいJMSサーバーを作成します。JMSServerに対して、JMSFileStore_nを使用します。JMSServer_nを新しい管理対象サーバーにターゲット指定します。

    3. 新しいUMSJMSServerの永続ストアを作成します(たとえば、UMSJMSFileStore_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。 

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n

    4. UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。それを新しい管理対象サーバーWLS_SOAnにターゲット指定します(移行可能)。

    5. 新しいBPMJMSServerの永続ストアを作成します(たとえば、BPMJMSFileStore_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。 

      ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_n

    6. BPMの新しいJMSサーバーを作成します(たとえば、BPMJMSServer_n)。それを新しい管理対象サーバーWLS_SOAnにターゲット指定します(移行可能)。

    7. 新しいJRFWSAsyncJMSServerの新しい永続ストアを作成します(たとえば、JRFWSAsyncJMSFileStore_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。 

      ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n

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

      ノート:

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

    9. 新しいSOAJMSServerの永続ストアを作成します(たとえば、SOAJMSFileStore_auto_n)。ストアのパス(共有記憶域上のディレクトリ)を指定します。 

      ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_auto_n

    10. SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_auto_n)。このJMSServerに対して、SOAJMSFileStore_auto_nを使用します。SOAJMSServer_auto_nを新しい管理対象サーバーWLS_SOAnにターゲット指定します(移行可能)。

      ノート:

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

    11. 新しいSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「SOAJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、SOAJMSServerXXXXXXサブデプロイメントをクリックし、SOAJMSServer_nを追加します。「保存」をクリックします。

      ノート:

      サブデプロイメント・モジュール名は、COMPONENTJMSServerXXXXXXという形式のランダム名です。これは、構成ウィザードにおける最初の2つの管理対象サーバー(WLS_COMPONENT1とWLS_COMPONENT2)のJMS構成から取得します。

    12. 新しいUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「UMSJMSSystemResource」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、UMSJMSServerXXXXXXサブデプロイメントをクリックし、UMSJMSServer_nを追加します。「保存」をクリックします。

    13. 新しいOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「OIMJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、OIMJMSServerXXXXXXとそのOIMJMSServer_nをクリックします。「保存」をクリックします。

    14. 新しいJRFWSAsync JMSサーバーが含まれるように、JRFWSAsyncJmsModuleのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JRFWSAsyncJmsModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。JRFWSAsyncJMSServerXXXXXXサブデプロイメントをクリックし、このサブデプロイメントにJRFWSAsyncJMSServer_nを追加します。「保存」をクリックします

    15. 新しいBPM JMSサーバーが含まれるように、BPM JMSモジュールのSubDeploymentターゲットを更新します。「サービス」ノードを開いてから、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「BPMJMSModule」(「名前」列のハイパーリンク)をクリックします。「設定」ページで「サブデプロイメント」タブをクリックします。サブデプロイメント・モジュールで、BPMJMSServerXXXXXXサブデプロイメントをクリックし、BPMJMSServer_nを追加します。「保存」をクリックします。

  9. SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。たとえば:

    cd ORACLE_HOME/oracle_common/common/bin
./pack.sh -managed=true/
-domain=ORACLE_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name='soa_domain_templateScale'

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

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

    次のように、unpackコマンドをHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。たとえば、SOAの場合は次のようにします。

    ORACLE_HOME/oracle_common/common/bin
/unpack.sh /
-domain=ORACLE_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar

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

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

  11. 新しい管理対象サーバーのホスト名の検証を無効化します。この操作は管理対象サーバーを起動して検証する前に実行しておく必要があります。管理サーバーとノード・マネージャとの通信用のサーバー証明書を構成した後で、これを再度有効化できます。(新しい管理対象サーバーのクローン元となった)ソース管理対象サーバーで、ホスト名の検証がすでに無効化されている場合、これらのステップは不要です。ホスト名の検証の設定はクローンされたサーバーに伝播されます。

    ホスト名の検証を無効化するには:

    1. 管理コンソールを開きます。

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

    3. 「サーバー」をクリックします。

    4. 表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。

    5. 「SSL」タブをクリックします。

    6. 「詳細」をクリックします。

    7. 「ホスト名の検証」を「なし」に設定します。

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

  12. 次に示すように、新しいノードでノード・マネージャを起動します。

    ORACLE_HOME/user_projects/domains/soadomain/bin/startNodeManager.sh

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

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

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

    3. 新たに作成した管理対象サーバーのアプリケーションにアクセスし、それが動作していることを確認します。OIMのログイン・ページが表示されます。SOAの場合は、HTTP基本認証が開きます。

    表6-4 管理対象サーバーのテストURL

    コンポーネント 管理対象サーバーのテストURL

    SOA

    http://vip:port/soa-infra

    OIM

    http://vip:port/identity

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

    ノート:

    この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャおよびネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しい管理対象サーバーの浮動IPが存在します。

    サーバー移行を構成するには:

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

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

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

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

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

      ノート:

      新しいサーバーの移行ターゲットには、負荷が最小のマシンを指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。

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

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

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

  15. この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。

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

      管理対象サーバーのPIDに対してkill -9 pidを実行します。ps -ef | grep WLS_SOAnなどを使用して、ノードのPIDを特定します。

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

    3. ノード・マネージャが新しい管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは、再起動するまでに30秒間待機します。

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

  16. OHS構成ファイルを編集して、新しい管理対象サーバーを追加します。「新しい管理対象サーバーを認識するためのOracle HTTP Serverの構成」を参照してください。

親トピック: Oracle Identity Governanceの高可用性の構成ステップ

新しい管理対象サーバーを認識するためのOracle HTTP Serverの構成

スケール・アップまたはスケール・アウトを完了するには、oim.confファイルを編集して、新しい管理対象サーバーを追加してから、Oracle HTTP Serverを再起動する必要があります。

  1. ディレクトリOHS_DOMAIN_HOME/config/fmwconfig/components/OHS/instances/OHS_INSTANCE_NAMEに移動します。
  2. mod_wl_ohs.confを編集し、新しい管理対象サーバーをWebLogicClusterディレクティブに追加します。このステップは、OIMまたはSOAに対して定義されているURLごとに実行する必要があります。製品ごとに個別の<Location>セクションが必要です。また、ポートは管理対象サーバーを参照している必要があります。たとえば:
    <Location /oim
    SetHandler weblogic-handler
    WebLogicCluster
 host1.example.com:14200,host2.example.com:14200
</Location>
  3. WEBHOST1およびWEBHOST2で、Oracle HTTP Serverを再起動します。
    WEBHOST1>OHS_DOMAIN_HOME/bin/stopComponent.sh OHS_Instance_NAME
WEBHOST1>OHS_DOMAIN_HOME/bin/startComponent.sh OHS_Instance_NAME

WEBHOST2>OHS_DOMAIN_HOME/bin/stopComponent.sh OHS_Instance_NAME
WEBHOST2>OHS_DOMAIN_HOME/bin/startComponent.sh OHS_Instance_NAME

ノート:

共有記憶域システムを使用していない場合(推奨)、oim.confを他のOHSサーバーにコピーします。

ノート:

デプロイメントを容易にする他のパラメータについては、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』のWebLogic Serverプラグインの一般的なパラメータに関する項を参照してください。

共有記憶域の準備

Oracle Fusion Middlewareでは、1つのOracleホームから複数のWebLogic Serverドメインを構成できます。これにより、共有ボリューム上の1つの場所にOracleホームをインストールすることや、複数のホストのインストールにOracleホームを再利用することができます。

ご使用の環境で共有記憶域を使用する場合は、詳細について高可用性ガイドの共有記憶域の使用に関する説明を参照してください。

親トピック: Oracle Identity Governanceコンポーネントの高可用性の構成

ユニキャスト構成を使用したOracle Identity and Access Managementクラスタのデプロイ

デプロイメント環境でマルチキャストIPが無効になっている場合は、ユニキャスト構成でOracle Identity and Access Managementクラスタをデプロイできます。

デプロイメント環境で、セキュリティ上の理由からマルチキャストIPが無効になっている場合、またはデプロイメントにクラウド・インフラストラクチャを使用している場合、デフォルトの構成(マルチキャスト)でOracle Identity and Access Managementをデプロイすることはできません。Oracle Identity and Access Management 12cは、JavaGroupまたはJGroupライブラリに依存するEHキャッシュを使用していて、マルチキャスト構成をメッセージのブロードキャストのデフォルトとしてサポートしているため、実現できません。

EHキャッシュのユニキャスト構成を行うには、次のステップを実行します:

  1. ホスト・マシンおよび使用可能なポートのリストを取得して、次のJGroup構成を準備します。
    例: 
    connect=TCP(bind_port=7800): TCPPING(initial_hosts=<Node1 IP>[7800],<Node2 IP>[7800];port_range=10;timeout=3000; num_initial_members=3): pbcast.NAKACK(use_mcast_xmit=false;retransmit_timeout=10000):pbcast.GMS(print_local_addr=true;join_timeout=3000)
  2. EMコンソールで、「アイデンティティとアクセス」を展開し、「OIM」をクリックします。
  3. 「oim(version_number)」を右クリックして「システムMBeanブラウザ」を選択します。

    ここで、version_numberはOracle Identity and Access Managementの現在のバージョン番号です。

  4. 「oracle.iam」を展開し、「サーバー:oim」、「アプリケーション:oim」、「XMLConfig」、「構成」、「XMLConfig.CacheConfig」の順に選択し、「キャッシュ」をクリックします。
  5. 右ペインで、「属性」タブに移動し、「クラスタ化」属性値をtrueに設定します。
  6. 左ペインで、「キャッシュ」フォルダを展開し、「XMLConfig.CacheConfig.XLCacheProvider」を選択して、「XLCacheProvider」をクリックします。
  7. 右ペインで、「属性」タブに移動し、MulticastAddress:の値をemptyに設定し、MulicastConfig属性値をステップ1で識別した同等のJGroup文字列に設定します。
  8. 「oracle.iam」で、「Server:oim」をクリックして「Application:oim」を選択し、「XMLConfig」をクリックして「Config」を選択し、「XMLConfig.DeploymentConfig」をクリックして「DeploymentConfig」を選択し、「アプリケーション定義のMBean: XMLConfig.DeploymentConfig:DeploymentConfig」をクリックして、「デプロイメント構成デプロイメント・モード」の値をclusterとして指定します。
  9. 「適用」をクリックします。
  10. ユニキャストIPV4を使用する場合は、JVMプロパティがすべてのノードのSetDomainEnvスクリプトで設定されているかどうかを確認します。そうでない場合は、JVMプロパティを設定し、SetDomainEnvスクリプトに次のパラメータを追加します:
    EXTRA_JAVA_PROPERTIES="-Djava.net.preferIPv4Stack=true ${EXTRA_JAVA_PROPERTIES}"
    export EXTRA_JAVA_PROPERTIES
  11. すべてのOracle Identity and Access Management管理対象サーバーを再起動します。

親トピック: Oracle Identity Governanceコンポーネントの高可用性の構成