| Oracle® Fusion Middleware高可用性ガイド 11g リリース1 (11.1.1) B55898-10 |
|
 前 |
 次 |
Oracle Identity Management製品を使用すると、多様なサーバーにわたるユーザー、デバイス、およびサービスを構成および管理して、これらのアイデンティティの管理を委託し、エンド・ユーザーにセルフサービスの特権を提供することができます。これらの製品を使用すると、アプリケーション全体にわたるシングル・サインオンを構成し、有効な資格証明を持つユーザーのみがオンライン・リソースにログインしてアクセスできるように、ユーザーの資格証明を処理できます。
他のエンタープライズ・レベルのアプリケーションは、Oracle Identity Management製品に依存するため、高可用性を構成しておくことが必要不可欠になります。Oracle Identity Management製品に障害が発生すると、この製品に依存するアプリケーションにも障害が発生します。
この章では、アクティブ/アクティブ構成における高可用性のためのIdentity Management製品の構成について説明します。
この章の内容は次のとおりです。
図8-1は、Oracle Fusion Middleware 11g Oracle Identity Managementの高可用性アーキテクチャの例を示しています。このアーキテクチャには、Web層、アプリケーション層、およびディレクトリ層があります。
図8-1 Oracle Fusion Middleware 11g Oracle Identity Managementの高可用性アーキテクチャ
図8-1では、Web層にコンピュータWEBHOST1とWEBHOST2があります。
別々のOracle HTTP ServerインスタンスがWEBHOST1およびWEBHOST2にインストールされます。ロード・バランシング・ルーターによって、WEBHOST1およびWEBHOST2上のOracle HTTP Serverインスタンスにリクエストがルーティングされます。
アプリケーション層には、コンピュータIDMHOST1とIDMHOST2コンピュータがあります。
IDMHOST1では、次のインストールが実行されています。
Oracle Directory Services ManagerインスタンスとOracle Directory Integration Platformインスタンスが、WLS_ODS1管理対象サーバー上にインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
Oracle Access Manager Access ServerインスタンスがWLS_OAM1管理対象サーバーにインストールされています。
WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。管理サーバーは、シングルトン・アプリケーションです。Oracle Access Manager Consoleもシングルトン・アプリケーションとしてインストールされています。
IDMHOST2では、次のインストールが実行されています。
Oracle Directory Services ManagerインスタンスとOracle Directory Integration Platformインスタンスが、WLS_ODS2管理対象サーバー上にインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
IDMHOST2上のWLS_ODS2管理対象サーバーにあるインスタンスと、IDMHOST1上のWLS_ODS1管理対象サーバーにあるインスタンスは、Cluster_ODSクラスタとして構成されています。
Oracle Access Manager Access ServerインスタンスがWLS_OAM2管理対象サーバーにインストールされています。
IDMHOST2上のWLS_OAM2管理対象サーバーにあるAccess Serverインスタンスと、IDMHOST1上のWLS_OAM1管理対象サーバーにあるAccess Serverインスタンスは、Cluster_OAMクラスタとして構成されています。
WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。IDMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。アクティブ/パッシブの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。Oracle Access Manager Consoleもシングルトン・アプリケーションとしてインストールされており、それはIDMHOST2上の管理サーバーがアクティブになるまではパッシブです。
ディレクトリ層には、コンピュータOIDHOST1とOIDHOST2があります。
OIDHOST1上には、Oracle Internet DirectoryインスタンスとOracle Virtual Directoryインスタンスがインストールされています。Oracle RACデータベースをセキュリティ・メタデータ・リポジトリとして使用しているOracle Internet Directoryインスタンスの接続には、透過的アプリケーション・フェイルオーバー(TAF)が使用されます。サーバー側のTAFおよび高可用性のイベント通知に対してデータベースが有効化されます。
OIDHOST2上には、Oracle Internet DirectoryインスタンスとOracle Virtual Directoryインスタンスがインストールされています。Oracle RACデータベースをセキュリティ・メタデータ・リポジトリとして使用しているOracle Internet Directoryインスタンスの接続には、透過的アプリケーション・フェイルオーバー(TAF)が使用されます。サーバー側のTAFおよび高可用性のイベント通知に対してデータベースが有効化されます。
OIDHOST1およびOIDHOST2上のOracle Internet Directoryインスタンスは、クラスタとして構成されています。
Oracle Real Applications Cluster (Oracle RAC)データベースは、セキュリティ・メタデータ・リポジトリとして使用されます。
表8-1は、Oracle Identity Management製品の要約です。これらの製品は、11gスイートレベルのインストール・プログラムを使用してインストールできます。詳細は、『Oracle Fusion Middleware Oracle Identity Managementクイック・インストレーション・ガイド』の序章を参照してください。
表8-1 11g Identity Managementコンポーネントおよび製品スイート
| 製品 | 説明 | 製品スイート |
|---|---|---|
|
Oracle Internet Directory |
Oracle Internet Directoryは、分散したユーザー、ネットワーク構成およびその他のリソースに関する情報をすばやく取得して集中管理できるLDAP Version 3対応のサービスです。 |
Oracle Identity Management Platform and Directory Services Suite |
|
Oracle Virtual Directory |
Oracle Virtual Directoryは、LDAP Version 3対応のサービスで、1つ以上のエンタープライズ・データ・ソースの1つのビューとして要約します。 Oracle Virtual Directoryは複数のソースを1つのディレクトリ・ビューに集約するので、LDAP認識アプリケーションと様々なディレクトリ・サーバー・データ・ストアとの統合が可能になります。 |
Oracle Identity Management Platform and Directory Services Suite |
|
Oracle Directory Integration Platform |
Oracle Directory Integration Platformは、様々なディレクトリとOracle Internet Directory間のデータ同期を可能にするJ2EEアプリケーションです。Oracle Directory Integration Platformには、他のエンタープライズ・リポジトリとの同期ソリューションのデプロイを可能とするサービスとインタフェースが含まれています。Oracle Internet Directoryとサード・パーティのメタディレクトリ・ソリューションとの相互運用性を実現するためにも使用できます。 |
Oracle Identity Management Platform and Directory Services Suite |
|
Oracle Directory Services Manager |
Oracle Directory Services Managerは、Oracle Virtual DirectoryおよびOracle Internet Directory用の統一されたグラフィカル・ユーザー・インタフェース(GUI)です。Oracle Directory Services Managerでは、Webベースのフォームやテンプレートを使用できるため、Oracle Virtual DirectoryとOracle Internet Directoryの管理および構成が簡素化されます。 Oracle Directory Services Managerは、Oracle Enterprise Manager Fusion Middleware Control、または独自のURLから使用できます。 |
Oracle Identity Management Platform and Directory Services Suite |
|
Oracle Access Manager |
Oracle Access Manager 11gは、Oracle Access Manager 10g(アクセスのみ)とOracle Single Sign-On 10gの両方の後継製品です。Oracle Access Manager 11gによって、すべての認証および認可サービスの一元的な提供が可能になります。提供されるコア・サービスは、有効なセッション・トークンのチェック、セッション・トークンが無効であるか見つからない場合の資格証明の要求、セッション・トークンの発行、リソース・リクエストのインターセプト、およびリソースへのアクセスを制御するためのアクセス制御ポリシーの評価です。 |
Oracle Identity and Access Management Suite |
|
Oracle Identity Manager |
Oracle Identity Managerは、アプリケーションおよびディレクトリからユーザー・アカウントを追加、更新および削除するプロセスを自動化するユーザー・プロビジョニングおよび管理ソリューションです。また、誰が何にアクセスしたかを示すきめ細かいレポートを提供することで、法規制コンプライアンスの向上にも寄与します。Oracle Identity Managerは、スタンドアロン製品として、またはOracle Identity and Access Management Suiteの一部として使用可能です。 |
Oracle Identity and Access Management Suite |
|
認可ポリシー・マネージャ |
認可ポリシー・マネージャは、アプリケーション・ポリシーを管理するためのグラフィカル・インタフェース・ツールです。認可ポリシー・マネージャの対象ユーザーは、セキュリティ管理者です。このツールを使用することで、管理者はエンタープライズ・アプリケーション全体にわたるポリシーを表示および管理できます。管理者は、ドメイン内で実行されているすべてのアプリケーションを管理することも、アプリケーションのサブセットのみを管理することもできます。 |
Oracle Identity and Access Management Suite |
|
Oracle Identity Navigator |
Oracle Identity Navigatorは、Oracle Identity Management製品のスタート地点として機能するよう設計されている管理ポータルです。これは、個々の製品コンソールに代わるものではありません。1つのサイトからOracle Identity Managementの各コンソールにアクセスできるようにするためのものです。 |
Oracle Identity and Access Management Suite |
|
Oracle Adaptive Access Manager |
Oracle Adaptive Access Manager (OAAM)は、エンタープライズ向けにWebアクセスのリアルタイム不正検出およびオンライン多要素認証セキュリティを提供するOracle Identity Managementのソリューションです。OAAMは、不正アクセス・リクエストのリアルタイム・ブロッキングを可能にし、高度なアラート・メカニズムを提供し、フィッシング、トロイの木馬、ウイルス、詐欺、介入者攻撃などの攻撃から企業とその顧客を保護します。 |
Oracle Identity and Access Management Suite |
|
Oracle Identity Federation |
Oracle Identity Federationは、各企業のセキュリティ・ドメイン境界を越えたサービスの提供やアイデンティティの共有を可能にするとともに不正アクセスに対する保護機能を提供します。 |
Oracle Identity Management Platform and Directory Services Suite |
この項では、Oracle Identity Managementの高可用性構成を設定する前に完了する必要のある前提条件の手順について説明します。
この項の内容は次のとおりです。
Identity ManagementコンポーネントのOracleホームは、すべてのノードで同一である必要があります。たとえば、Node1でOracleホームとして/u01/app/oracle/product/fmw/idmを選択した場合は、すべての後続のノードのOracleホームとして/u01/app/oracle/product/fmw/idmを選択する必要があります。
いくつかのOracle Identity Managementコンポーネントでは、サポートされているデータベースおよびスキーマが存在している必要があります。
データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
データベースのバージョンを調べるには、次の問合せを実行します。
SQL>select version from sys.product_component_version where product like 'Oracle%';
高可用性データベースを使用してメタデータ・リポジトリを格納することをお薦めします。可用性を最大にするために、Oracle Real Application Cluster (Oracle RAC) データベースの使用をお薦めします。必須ではありませんが、データベースではデータ記憶域にOracle自動ストレージ管理を使用することをお薦めします。Oracle ASMを使用する場合、ベスト・プラクティスはOracle Managed Filesも使用することです。
Oracle ASMを使用する場合、Oracle ASMを独自のOracleホームにインストールし、次の2つのディスク・グループを用意します。
データベース・ファイル用のグループ。
フラッシュ・リカバリ領域用のグループ。
この項には、データベース・リポジトリのインストールおよび構成手順への関連項目が記載されています。
Oracle Clusterware
10g リリース2 (10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1 (11.1)以降については、Oracle Clusterwareインストレーション・ガイドを参照してください。
自動ストレージ管理
10g リリース2 (10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1 (11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。
インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。
Oracle Real Application Cluster
10g リリース2 (10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11g リリース1 (11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。
Oracle Fusion Middlewareコンポーネントの多くは、インストールの前にデータベース内にスキーマが存在している必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するツール、リポジトリ作成ユーティリティ(RCU)があります。高可用性環境では、これらのスキーマを作成して、Real Application Clusters (Oracle RAC)データベースにロードする必要があります。
RCUを使用してOracle Identity ManagementスキーマをOracle RACデータベース・リポジトリにロードする操作の詳細は、次の項を参照してください。
RCUの最新バージョンを取得するには、次のOracle Technology NetworkのOracle Fusion Middleware 11gR1のソフトウェア・ダウンロード・ページにアクセスしてください。
http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html
Required Additional Softwareの表でRepository Creation Utilityを探します。.zipファイルをダウンロードした後で、選択したディレクトリに内容を抽出します。このガイドでは、このディレクトリをRCU_HOMEと呼びます。
|
注意: Windowsオペレーティング・システムでは、名前に空白が含まれていないディレクトリにRCUの.zipファイルを解凍してください。 |
この章で説明するOracle Identity Managementコンポーネントのいずれもインストールする前には、RCUを実行して、そのコンポーネントで使用されるスキーマをOracle RACデータベースに作成しておきます。これらのスキーマは、この章で説明するOracle Identity Managementの高可用性構成に必要です。
RCUの詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』および『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。
RCUの実行の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』および『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
作成するスキーマは、インストールおよび構成するアイデンティティ管理製品に応じて異なります。例:
Oracle Identity Manager用のデータベースである場合は、「アイデンティティ管理 - Oracle Identity Manager」を選択します。
|
注意: SOAおよびMDSスキーマは自動的に選択されています。 |
Oracle Internet Directory用のデータベースである場合は、「アイデンティティ管理 - (Oracle Internet Directory - ODS)」を選択します。
Oracle Access Manager用のデータベースである場合は、「アイデンティティ管理 - Oracle Access Manager」を選択します。
Oracle Identity Federation用のデータベースである場合は、「アイデンティティ管理 - Oracle Identity Federation」を選択します。
Oracle Adaptive Access Manager用のデータベースである場合は、「アイデンティティ管理 - Oracle Adaptive Access Manager」を選択します。
次の特性を持つOracle Fusion Middleware 11gメタデータを格納するOracle Real Application Clustersデータベースを作成します。
バックアップとリカバリを容易にするためにアーカイブ・ログ・モードになっている必要があります。
オプションでフラッシュバックを有効化する必要があります。
ALT32UTF8キャラクタ・セットで作成されている必要があります。
静的なPROCESSES初期化パラメータの値は、Oracle Internet Directoryに対して500以上にする必要があります。この値は、リポジトリ作成ユーティリティによってチェックされます。
この値をチェックするには、次のようにSQL*PlusでSHOW PARAMETERコマンドを使用します。
prompt> sqlplus "sys/password as sysdba" SQL> SHOW PARAMETER processes
パラメータの値を変更する一般的な方法の1つとして、次のようなコマンドを使用し、データベースの停止および再起動をしてパラメータを有効化する方法があります。
prompt> sqlplus "sys/password as sysdba" SQL> ALTER SYSTEM SET PROCESSES=500 SCOPE=SPFILE;
パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイル、サーバー・パラメータ・ファイル、およびパラメータ値の変更方法の詳細は、Oracle Database管理者ガイドを参照してください。
表8-2は、この章のデータベースの構成例で使用されている値を示しています。
表8-2 アイデンティティ管理で使用されるデータベースの構成例
| コンポーネント | データベース・サービス名 | データベース・インスタンス名 |
|---|---|---|
|
Oracle Internet Directory |
oid.example.com |
oiddb1、oiddb2 |
|
Oracle Virtual Directory |
N/A |
N/A |
|
Oracle Directory Integration Platform |
oid.example.com |
oiddb1、oiddb2 |
|
Oracle Directory Services Manager |
N/A |
N/A |
|
Oracle Access Manager |
oam.example.com |
oamdb1、oamdb2 |
|
Oracle Identity Manager |
oim.example.com |
oimdb1、oimdb2 |
|
認可ポリシー・マネージャ |
apm.example.com |
apmdb1、apmdb2 |
|
Oracle Identity Navigator |
N/A |
N/A |
|
Oracle Adaptive Access Manager |
oaam.example.com |
oaamdb1、oaamdb2 |
|
Oracle Identity Federation |
oif.example.com |
oifdb1、oifdb2 |
Oracle Enterprise Manager Cluster Managed Services Pageを使用して、クライアント・アプリケーションがデータベースへの接続に使用するデータベース・サービスを作成することをお薦めします。データベース・サービスの作成の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドの「ワークロード管理」を参照してください。
SQL*Plusを使用して、Oracle RACデータベースを構成し、次の指示に従ってOracle Internet Directoryのフェイルオーバーを自動化することもできます。次の各コマンドは、クラスタ内の1つのノードにのみ実行してください。
CREATE_SERVICEサブプログラムは、データベース・サービスの作成、および高可用性通知の有効化とサーバー側の透過的アプリケーション・フェイルオーバー(TAF)設定の構成の両方に使用します。
prompt> sqlplus "sys/password as sysdba" SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE (SERVICE_NAME => 'idm.example.com', NETWORK_NAME => 'idm.example.com', AQ_HA_NOTIFICATIONS => TRUE, FAILOVER_METHOD => DBMS_SERVICE.FAILOVER_METHOD_BASIC, FAILOVER_TYPE => DBMS_SERVICE.FAILOVER_TYPE_SELECT, FAILOVER_RETRIES => 5, FAILOVER_DELAY => 5);
EXECUTE DBMS_SERVICEコマンドは、1行で入力する必要があります。
サービスをデータベースに追加し、srvctlを使用してインスタンスに割り当てます。
prompt> srvctl add service -d idmdb -s idm -r idmdb1,idmdb2
srvctlを使用してサービスを開始します。
prompt> srvctl start service -d idmdb -s idm
|
注意: SRVCTLコマンドの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。 |
データベースにサービスが存在している場合は、高可用性通知が有効化され、サーバー側の透過的アプリケーション・フェイルオーバー(TAF)の設定が適切に構成されていることを確認します。高可用性通知がアドバンスト・キューイング(AQ)を通して送信されるように、DBMS_SERVICEパッケージを使用してサービスを変更します。具体的には、次のようにAQ_HA_NOTIFICATIONS属性をTRUEに設定して、サーバー側の透過的アプリケーション・フェイルオーバー(TAF)の設定を構成します。
prompt> sqlplus "sys/password as sysdba" SQL> EXECUTE DBMS_SERVICE.MODIFY_SERVICE (SERVICE_NAME => 'idm.example.com', AQ_HA_NOTIFICATIONS => TRUE, FAILOVER_METHOD => DBMS_SERVICE.FAILOVER_METHOD_BASIC, FAILOVER_TYPE => DBMS_SERVICE.FAILOVER_TYPE_SELECT, FAILOVER_RETRIES => 5, FAILOVER_DELAY => 5);
EXECUTE DBMS_SERVICEコマンドは、1行で入力する必要があります。
|
注意: DBMS_SERVICEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプのリファレンスを参照してください。 |
11.2データベースを使用する場合は、11gリリース2 (11.2)用のOracle Database管理者ガイドのSRVCTLを使用したデータベース・サービスの作成と削除に関する項の手順に従ってください。
ここでは、すでに設定されている透過的アプリケーション・フェイルオーバー(TAF)構成を検証する方法について説明します。
Oracle Internet Directoryプロセスの起動後、V$SESSION_VIEWのFAILOVER_TYPE、FAILOVER_METHOD、およびFAILED_OVER列を問い合せて、接続されているクライアントおよびそのTAFステータスを取得できます。
たとえば、次のSQL文を使用して、TAFが正しく構成されていることを検証します。
SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER, COUNT(*) FROM V$SESSION GROUP BY MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER;
フェイルオーバー前の出力は次のようになります。
MACHINE FAILOVER_TYPE FAILOVER_M FAI COUNT(*) -------------------- ------------- ---------- ---- ---------- oidhost1 SELECT BASIC NO 11 oidhost1 SELECT BASIC NO 1
フェイルオーバー後の出力は次のようになります。
MACHINE FAILOVER_TYPE FAILOVER_M FAI COUNT(*) -------------------- ------------- ---------- ---- ---------- oidhost2 SELECT BASIC NO 11 oidhost2 SELECT BASIC NO 1
この項では、Oracle Identity Managementの高可用性環境をデプロイするためのネットワークの前提条件について説明します。
Oracle Identity Managementソフトウェア・スタック内のコンポーネントを高可用性構成にデプロイする場合は、すべてのコンポーネントにハードウェア・ロード・バランサが必要です。ハードウェア・ロード・バランサには、次の機能が必要です。
仮想ホスト名を介した実サーバー・プールへのトラフィックのロード・バランシング機能
クライアントは、仮想ホスト名を使用して(実ホスト名を使用するかわりに)、サービスにアクセスします。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。
ポート変換の構成: ロード・バランサには、1つのポートで受信した受信リクエストを別のポートで実行されているサーバー・プロセスにルーティングできるポート変換機能が必要です。たとえば、ポート80で受信したリクエストをポート7777にルーティングできます。
プロトコル変換: ロード・バランサには、異なるプロトコルを実行するシステム間のプロトコル変換機能が必要です。これにより、発行元デバイスとターゲット指定されたホストに関連付けられているネイティブ・プロトコル・スタックが異なる場合も、あるネットワークに接続しているユーザーが別のネットワーク上のホストにアクセスできます。たとえば、HTTPSリクエストを受信して、HTTPリクエストを送信することができます。
この機能は推奨されますが、必須ではありません。
SSLアクセラレーション: SSLアクセラレーションは、SSLトランザクションで実行され、プロセッサを集中的に使用する公開鍵暗号化アルゴリズムを、ハードウェア・アクセラレータにオフロードする方法です。
この機能は推奨されますが、必須ではありません。
ポート(HTTP、HTTPS、LDAP、LDAPS)の監視
仮想サーバーとポートの構成
外部ロード・バランサの仮想サーバー名とポートを構成する機能。さらに、仮想サーバー名とポートは次の要件を満たしている必要があります。
ロード・バランサには複数の仮想サーバーを構成できる必要があります。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、Oracle Internet Directoryクラスタでは、LDAPおよびLDAPSトラフィック用の仮想サーバーとポートでロード・バランサを構成する必要があります。
仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは、仮想サーバー名を介してロード・バランサへアクセスできる必要があります。
ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングをすぐに停止する機能
リソースの監視/ポートの監視/プロセス障害検出
ロード・バランサは、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへの非Oracle Netトラフィックの送信を停止できる必要があります。ロード・バランサに障害の自動検出機能がある場合は、それを使用する必要があります。
フォルト・トレラント・モード
ロード・バランサをフォルト・トラレント・モードに構成することを強くお薦めします。
その他
トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、すぐにコール元クライアントに戻るようロード・バランサの仮想サーバーを構成しておくことをお薦めします。この構成は、クライアント・マシンのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。
スティッキーなルーティング機能
CookieまたはURLに基づいたコンポーネントへのスティッキーな接続を維持する機能
表8-3は、Oracle Identity Managementの高可用性環境で外部ロード・バランサに使用する仮想サーバー名を示しています。
表8-3 外部ロード・バランサの仮想サーバー名
| コンポーネント | 仮想サーバー名 |
|---|---|
|
Oracle Internet Directory |
oid.example.com |
|
Oracle Virtual Directory |
ovd.example.com |
|
Oracle Identity Federation |
oif.example.com |
|
Oracle Directory Services Managerコンソール |
admin.example.com |
|
Oracle Access Manager |
sso.example.com |
|
Oracle Adaptive Access Manager |
oaam.example.com |
|
Oracle Identity Manager |
sso.example.com |
この項では、この章で説明する高可用性デプロイメントのために設定が必要な仮想サーバー名について説明します。
仮想サーバー名に対応するIPアドレスが設定されていることと、仮想サーバー名がドメイン・ネーム・システム(DNS)に登録されていることを確認します。Oracle Fusion Middlewareを実行するコンピュータは、これらの仮想サーバー名を解決できることが必要です。
oid.example.com
この仮想サーバーは、ディレクトリ層のOracle Internet DirectoryサーバーへのすべてのLDAPトラフィックのアクセス・ポイントとして機能します。SSLポートおよび非SSLポートの両方へのトラフィックが構成されます。クライアントは、SSLの場合はアドレスoid.example.com:636、非SSLの場合はoid.example.com:389を使用してこのサービスにアクセスします。
OIDHOST1およびOIDHOST2上のOracle Internet Directoryプロセスのハートビートを監視します。OIDHOST1またはOIDHOST2上でOracle Internet Directoryプロセスが停止した場合、あるいはホストOIDHOST1またはホストOIDHOST2のいずれかで障害が発生した場合、ロード・バランサは障害が発生していないコンピュータへのLDAPトラフィックのルーティングを継続する必要があります。
ovd.example.com
この仮想サーバーは、ディレクトリ層のOracle Virtual DirectoryサーバーへのすべてのLDAPトラフィックのアクセス・ポイントとして機能します。SSLポートおよび非SSLポートの両方へのトラフィックが構成されます。クライアントは、SSLの場合はアドレスovd.example.com:7501、非SSLの場合はovd.example.com:6501を使用してこのサービスにアクセスします。
OVDHOST1およびOVDHOST2上のOracle Virtual Directoryプロセスのハートビートを監視します。OVDHOST1またはOVDHOST2上でOracle Virtual Directoryプロセスが停止した場合、あるいはホストOVDHOST1またはホストOVDHOST2のいずれかで障害が発生した場合、ロード・バランサは障害が発生していないコンピュータへのLDAPトラフィックのルーティングを継続する必要があります。
oif.example.com
この仮想サーバーは、アプリケーション層のOracle Identity FederationサーバーへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。
oaam.example.com
この仮想サーバーは、Webサイトへ送信されるすべてのOracle Adaptive Access Managerトラフィックのアクセス・ポイントとして機能します。
sso.example.com
この仮想サーバーは、Webサイトへ送信されるすべてのOracle Access Managerトラフィックのアクセス・ポイントとして機能します。
この仮想サーバーは、シングル・サインオン・サービスへ送信されるすべてのHTTPトラフィックのアクセス・ポイントとして機能します。
この仮想ホストは、リクエストのクライアントIPアドレスを保持するように構成する必要があります。いくつかのロード・バランシング・ルーターでは、ロード・バランシング・ルーターがリクエストのオリジナルのクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入できるようにすることで、これを実現できます。
この項では、Oracle Internet Directoryの概要、およびOracle Internet Directoryの高可用性環境の設計とデプロイ方法について説明します。
この項の内容は次のとおりです。
Oracle Internet Directoryは、Directory Integration Platform、Oracle Directory Services Manager、JPSなどのOracleコンポーネント、およびOracle以外のコンポーネントから使用可能なLDAPストアです。これらのコンポーネントは、LDAPまたはLDAPSプロトコルを使用してOracle Internet Directoryに接続します。
Oracleディレクトリ・レプリケーション・サーバーはLDAPを使用して、Oracleディレクトリ(LDAP)サーバー・インスタンスと通信します。データベースとの通信には、すべてのコンポーネントでOCI/Oracle Net Servicesを使用します。Oracle Directory Services Managerおよびコマンドライン・ツールは、LDAPを介してOracleディレクトリ・サーバーと通信します。
図8-2は、非高可用性アーキテクチャにおけるOracle Internet Directoryを示しています。
Oracle Internet Directoryのノードは、同じディレクトリ・ストアに接続された1つ以上のディレクトリ・サーバー・インスタンスで構成されます。ディレクトリ・ストア、つまりディレクトリ・データのリポジトリは、Oracle Databaseになります。
図8-2に示すように、Oracle Internet Directoryのノードには次の主要な要素が組み込まれています。
表8-4 Oracle Internet Directoryのノード
| 要素 | 説明 |
|---|---|
|
Oracleディレクトリ・サーバー・インスタンス |
LDAPサーバー・インスタンスまたはディレクトリ・サーバー・インスタンスとも呼びます。特定のTCP/IPポートをリスニングする単一のOracle Internet Directoryのディスパッチャ・プロセスを介してディレクトリ・リクエストに応じます。異なるポートをリスニングする1つ以上のディレクトリ・サーバー・インスタンスが同一ノードに存在する場合もあります。 |
|
Oracleディレクトリ・レプリケーション・サーバー |
レプリケーション・サーバーとも呼びます。別のOracle Internet Directoryシステムにあるレプリケーション・サーバーに対する変更の追跡と送信を行います。1つのノードのレプリケーション・サーバーは、1つに限られます。レプリケーション・サーバーを構成するかどうかは選択できます。同一データベースを使用するOracle Internet Directoryに複数のインスタンスがある場合、そのうちの1つのみがレプリケーションを実行できます。これは、Oracle Internet Directoryインスタンスが複数のノードに存在する場合も同様です。 レプリケーション・サーバー・プロセスは、Oracle Internet Directory内のプロセスです。レプリケーションが構成されている場合にのみ実行されます。 Oracle Internet Directoryのレプリケーションの詳細は、第10章「高可用性を最大化するIdentity Managementの構成」を参照してください。 |
|
Oracle Databaseサーバー |
ディレクトリ・データを格納します。ディレクトリ専用のデータベースとすることを強くお薦めします。データベースは、ディレクトリ・サーバー・インスタンスと同じノードに配置できます。 |
|
Oracle Process Manager and Notification Server (OPMN) |
Oracle Fusion Middlewareのコンポーネントの1つとしてOracle Internet Directoryを管理します。OPMNは、 |
|
OIDモニター(OIDMON) |
LDAPサーバーとレプリケーション・サーバー・プロセスの起動、監視および終了を行います。oidctl、opmnctlなどのプロセス管理コマンドを呼び出す場合、またはFusion Middleware Controlを使用してサーバー・インスタンスを起動または停止する場合は、このプロセスによってコマンドが解釈されます。 OIDMONはサーバーを監視し、異常のため実行を停止した場合はそのサーバーを再起動します。 OIDMONは、OIDLDAPDのデフォルト・インスタンスを起動します。OIDCTLコマンドを使用してOIDLDAPDのデフォルト・インスタンスが停止された場合、OIDMONがそのインスタンスを停止します。OPMNによってOIDMONが再起動された場合、OIDMONはデフォルト・インスタンスを再起動します。 OIDモニターのアクティビティはすべて、ファイル OIDモニターは、オペレーティング・システムのメカニズムを介して、サーバーの状態をチェックします。 |
|
OID制御ユーティリティ(OIDCTL) |
Oracle Internet Directoryサーバーの表にメッセージ・データを配置して、OIDモニターと通信します。このメッセージ・データには、各Oracleディレクトリ・サーバー・インスタンスの実行に必要な構成パラメータが含まれます。通常は、コマンドラインからのレプリケーション・サーバーの停止と起動のみに使用されます。 |
Oracle Internet Directoryは、OracleのLDAPストアであり、データベースを永続ストアとして使用するCベースのコンポーネントです。これはステートレスなプロセスで、すべてのデータと構成情報の大部分をバックエンド・データベースに格納します。データベースへの接続には、Oracle Net Servicesを使用します。
Oracle Internet Directoryには、次のランタイム・プロセスがあります。
OIDLDAPD: Oracle Internet Directoryのメイン・プロセスです。OIDLDAPDは、ディスパッチャ・プロセスとサーバー・プロセスで構成されます。ディスパッチャ・プロセスは、起動時にOIDLDAPDサーバー・プロセスを作成します。各OIDLDAPDディスパッチャ・プロセスには、リクエストを受信するための固有のSSLポートおよび非SSLポートがあります。デフォルトでは、各OIDインスタンスにはディスパッチャとサーバー・プロセスが1つずつあります。1つのインスタンスに作成されるサーバー・プロセスの数は、orclserverprocs属性によって制御されます。
OIDMON: OIDMONは、Oracle Internet Directoryインスタンスのプロセス制御を行います。このプロセスは、Oracle Internet Directoryの起動、停止および監視を行います。OIDMONは起動時にOIDLDAPDディスパッチャ・プロセスを作成し、インスタンスにレプリケーションが構成されている場合はレプリケーション・サーバー・プロセスも作成します。
レプリケーション・サーバー・プロセス: Oracle Internet Directory内のプロセスで、レプリケーションが構成されている場合にのみ実行されます。レプリケーション・サーバー・プロセスは、起動時にOIDMONによって作成されます。
OPMN: Oracle Process Manager and Notification Server (OPMN)は、Oracle Internet DirectoryなどのOracle Fusion Middlewareコンポーネントを監視するデーモン・プロセスです。Oracle Enterprise Manager Fusion Middleware ControlはOPMNを使用して、Oracle Internet Directoryのインスタンスの停止と起動を行います。Oracle Internet Directoryコンポーネントの停止と起動をコマンドラインから行う場合は、OPMNに対するコマンドライン・インタフェースであるopmnctlを使用します。
OPMNは、OIDMONを直接、起動、停止、再起動、および監視します。サーバー・プロセスを直接起動または停止することはありません。
OPMNは、デーモン・プロセスOIDMON(ORACLE_HOME/bin/oidmon)を直接、起動、停止、再起動、および監視します。OIDMONは、Oracle Internet Directoryインスタンスのプロセスを制御します。11gリリース1 (11.1.1)では、同一ノードの同一Oracleインスタンスに複数のOracle Internet Directoryインスタンスを設定できます。詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドを参照してください。
プロセス・ステータス表
Oracle Internet Directoryのプロセス情報は、ODSデータベース・ユーザー・スキーマのODS_PROCESS_STATUS表で管理されます。OIDMONは、指定された間隔で表の内容を読み取り、その表の内容が伝える目的に従って動作します。この間隔は、OIDMON起動時に使用されたスリープ・コマンド・ラインの引数の値によって制御されます。デフォルト値は10秒です。
Oracle Internet Directoryの起動と停止
Oracle Enterprise Manager Fusion Middleware Controlまたはコマンドopmnctlを使用して、Oracle Internet Directoryインスタンスの起動と停止ができます。
プロセスの起動
Oracle Internet Directoryの起動プロセスは次のとおりです。
起動コマンドを受信すると、OPMNはopmn.xmlファイルで指定された適切な引数を使用してoidmon起動コマンドを発行します。
これにより、OIDMONは、ODS_PROCESS_STATUS表内の情報で状態の値が1または4、かつORACLE_INSTANCE、COMPONENT_NAME、INSTANCE_NAMEの値がOPMNによって設定された環境パラメータと一致するすべてのOracle Internet Directoryサーバー・インスタンスを起動します。
プロセスの停止
Oracle Internet Directoryの停止プロセスは次のとおりです。
停止コマンドを受信すると、OPMNは、oidmon停止コマンドを発行します。
ODS_PROCESS_STATUS表内で環境パラメータORACLE_INSTANCE、COMPONENT_NAME、およびINSTANCE_NAMEに一致する各行に対して、oidmon停止コマンドがOIDMON、OIDLDAPD、およびOIDREPLDの各プロセスを停止し、状態を4に更新します。
監視
OPMNは、サーバー・プロセスを直接監視しません。OPMNはOIDMONを監視し、OIDMONがサーバー・プロセスを監視します。イベントは次のとおりです。
OPMNを介してOIDMONを起動すると、OPMNはOIDMONを起動し、OIDMONが実行中であることを確認します。
なんらかの理由でOIDMONが停止すると、OPMNによって再起動されます。
OIDMONは、Oracle Internet Directoryディスパッチャ・プロセス、LDAPサーバー・プロセス、およびレプリケーション・サーバー・プロセスのステータスを監視し、このステータスをOPMNとOracle Enterprise Manager Fusion Middleware Controlで使用できるようにします。
Oracle Internet Directoryプロセスが起動すると、クライアントはLDAPまたはLDAPSプロトコルを使用してOracle Internet Directoryにアクセスします。Oracle Internet Directoryインスタンスの起動時に、他の実行インスタンスへの影響はありません。
Oracle Internet Directoryリスナー/ディスパッチャは、起動時に構成された数のサーバー・プロセスを起動します。サーバー・プロセスの数は、インスタンス固有の構成エントリ内のorclserverprocs属性によって制御されます。orclserverprocsのデフォルト値は1です。Oracle Internet Directoryでは複数のサーバー・プロセスによって、マルチ・プロセッサ・システムのメリットが得られます。
Oracle Internet Directoryのディスパッチャ・プロセスは、Oracle Internet Directoryのサーバー・プロセスに対するLDAP接続をラウンドロビン方式で送信します。各サーバーで受入れ可能なLDAP接続の最大数は、デフォルトでは1024です。この数は、インスタンス固有の構成エントリ内の属性orclmaxldapconnsを変更して増やせます。このDNの形式は次のとおりです。
cn=componentname,cn=osdldapd,cn=subconfigsubentry
各サーバー・プロセスからのデータベース接続は、インスタンス構成パラメータORCLMAXCCおよびORCLPLUGINWORKERSに設定された値に応じてサーバーの起動時に作成されます。各サーバーで作成されるデータベース接続の数は、ORCLMAXCC + ORCLPLUGINWORKERS + 2と等しくなります。Oracle Internet Directoryのサーバー・プロセスはOracle Net Servicesを介してOracle Databaseサーバーと通信します。Oracle Net Servicesリスナー/ディスパッチャは、リクエストをOracle Databaseに中継します。詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。
記憶域の配置にはDB接続文字列が必要です。TNSNAMES.ORAは、ORACLE_INSTANCE/configに保存されます。ウォレットはORACLE_INSTANCE/OID/adminに保存されます(DB ODSユーザー・パスワードはウォレットに格納されます)。
Oracle Internet Directoryでは、データと同様に構成情報の格納にもOracle Databaseを使用します。この情報の格納にはODSスキーマを使用します。
Oracleディレクトリ・レプリケーション・サーバーはLDAPを使用して、Oracleディレクトリ(LDAP)サーバー・インスタンスと通信します。データベースとの通信には、すべてのコンポーネントでOCI/Oracle Net Servicesを使用します。Oracle Directory Services Managerおよびコマンドライン・ツールは、LDAPを介してOracleディレクトリ・サーバーと通信します。
Oracle Internet Directoryのログ・ファイルは、次のディレクトリにあります。
ORACLE_INSTANCE/diagnostics/log/OID
表8-5は、Oracle Internet Directoryのプロセスとログ・ファイル名、およびプロセスの場所を示しています。
表8-5 Oracle Internet Directoryのプロセス・ログ・ファイルの場所
| プロセス | ログ・ファイルの場所 |
|---|---|
|
ディレクトリ・サーバー(oidldapd) |
00はインスタンス番号です(デフォルトは00)。 sはサーバーを表します。 PIDはサーバー・プロセス識別子です。 XXXXは、0000からorclmaxlogfilesconfiguredまでの数値です。orclmaxlogfilesconfigured値に達すると、再び0000から開始されます。この開始時にはファイルは0バイトに切り捨てられます。
|
|
LDAPディスパッチャ(oidldapd) |
00はインスタンス番号です(デフォルトは00)。 XXXXは、0000からorclmaxlogfilesconfiguredまでの数値です。 |
|
OIDモニター(OIDMON) |
XXXXは、0000からorclmaxlogfilesconfiguredまでの数値です。 |
|
ディレクトリ・レプリケーション・サーバー(oidrepld) |
XXXXは、0000からorclmaxlogfilesconfiguredまでの数値です。 |
ログ・ファイルを使用したOracle Internet Directoryの問題のトラブルシューティングの詳細は、第8.3.6項「Oracle Internet Directoryの高可用性のトラブルシューティング」を参照してください。
この項では、Oracle Internet Directoryを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。前提条件については、第8.3.2.3項「Oracle Internet Directoryの前提条件」を、2ノードのクラスタ構成を設定するための固有の手順については、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。
図8-3は、Oracle Internet Directoryクラスタ構成のアクティブ/アクティブ構成における高可用性アーキテクチャを示しています。
図8-3 Oracle Internet Directoryクラスタ構成の高可用性アーキテクチャ
図8-3では、クラスタ構成の高可用性アーキテクチャのディレクトリ層にOracle Internet Directoryがあります。クラスタ化はインストール時に設定されます。ロード・バランシング・ルーターによってLDAPクライアント・リクエストが2つのOracle Internet Directoryインスタンスにルーティングされます。この2つのインスタンスは、OIDHOST1とOIDHOST2上にあり、クラスタ化されています。
Oracle RACデータベースをセキュリティ・メタデータ・リポジトリとして使用しているOracle Internet Directoryインスタンスの接続には、透過的アプリケーション・フェイルオーバー(TAF)が使用されます。Oracle RACデータベースは、TNSNAMES.ORAに構成されます。高可用性イベント通知は、Oracle RACインスタンスが使用不可となった場合の通知に使用されます。Oracle RACでOracle Internet Directoryを使用する方法の詳細は、第5.1.7.1項「Oracle Internet Directory」を参照してください。
クラスタ構成では、各Oracle Internet Directoryインスタンスの起動にOPMNコマンドを使用します。起動時にOracle Internet Directoryへの影響はありません。Oracle Internet Directoryの起動時に新しいデータベース接続が作成されます。
OPMNを使用してクラスタを停止すると、Oracle Internet Directoryは、データベースとの接続を切断し、Oracle Internet Directoryサーバーが停止します。
構成の変更は、クラスタ構成内のすべてのインスタンスに対してクラスタ・レベルで行われます。同じデータベースを共有するクラスタ構成内のノードはすべて同じ構成情報を読み込みます。OIDMONプロセスは、各Oracle Internet Directoryサーバーの構成変更をポーリングし、構成変更に関するデータベース・リポジトリを更新します。OIDMONおよびその他のOracle Internet Directoryサーバーは、データベース・リポジトリから変更を取得します。このようにして、クラスタ・メンバー・レベルで加えられた変更はすべて、クラスタ内のすべてのOracle Internet Directoryサーバーに伝播されます。
Oracle Internet Directory LDAPサーバーの構成に必要なインスタンス固有の構成属性は、次のLDAPエントリに格納されます。
cn=<component-name>,cn=osdldapd,cn=subconfigsubentry
Oracle Internet Directoryサーバー構成の各面(サーバー数、データベース接続、サイズ制限、時間制限など)は、インスタンス固有のサーバー構成エントリに含まれます。
クラスタ内のすべてのOracle Internet Directoryインスタンスに共通の構成属性は、次のLDAPエントリに格納されます。
cn=dsaconfig,cn=configsets,cn=oracle internet directory
クラスタ内の各Oracle Internet Directoryインスタンスに対してインスタンス固有のサーバー構成属性を保持する場合は、インストール時/構成時に各Oracle Internet Directoryインスタンスに対して個別のOracle Internet Directoryコンポーネント名を選択する必要があります(ノード1はoid1、ノード2はoid2など)。この場合、構成エントリは、それぞれcn=oid1,cn=osdldapd,cn=subconfigsubentryおよびcn=oid2,cn=osdldapd,cn=subconfigsubentryとなり、Oracle Internet Directoryインスタンスごとに更新する必要があります。
一方、クラスタ内のOracle Internet Directoryインスタンスの両方に共通のサーバー構成属性セットを使用するように選択した場合は、Oracle Internet Directoryインスタンスの両方に同じOracle Internet Directoryコンポーネント名を選択する必要があります(Oracle Internet Directoryのノード1とノード2の両方にoid1を使用するなど)。この場合、cn=oid1,cn=osdldapd,cn=subconfigsubentryのように、共通の構成エントリになります。
Oracle Internet Directory LDAPサーバー・インスタンスは、スキーマ、ACL、パスワード・ポリシーなど、特定のLDAPメタデータ・アーティファクトをキャッシュします。任意のノードにある複数のOracle Internet Directory LDAPサーバー・プロセスは、各ノードのOracle Internet Directoryで管理される共有メモリー・セグメントに関して構築されるセマンティックを介して、キャッシュの同期を管理します。OIDMONは、ノード間の共有メモリー・セグメントの同期を保証することで、ノード間のキャッシュの同期を管理します。これはOracle Internet Directoryデータベースを使用して実現されます。
Oracle Internet Directoryでは、メタデータもキャッシュされ、メタデータの変更によって、ノード間の通知がトリガーされます。メタデータの変更にはldapmodifyユーティリティを使用します。メタデータ変更に関するldapmodifyリクエストを取得したOracle Internet Directoryサーバーは、他のOracle Internet Directoryサーバーに対してメタデータの変更を通知します(OIDMONを含む)。OIDMONは、他のノードのOIDMONにメタデータの変更を通知する役割を持ちます。
この項では、Oracle Internet Directoryクラスタ構成における様々な障害からの保護について説明します。
OIDMONは、Oracle Internet Directoryプロセスを監視します。Oracle Internet Directoryプロセスが停止すると、OIDMONが再起動を試行します。
OPMNはOIDMONを監視します。OIDMONが停止すると、OPMNがOIDMONを再起動します。
Oracle Internet Directoryプロセスを再起動できない場合は、フロントエンドのロード・バランシング・ルーターによってクラスタ構成内のOracle Internet Directoryインスタンスの障害が検出され、障害が発生していないインスタンスにLDAPトラフィックがルーティングされます。障害が発生した場合、LDAPクライアントによってトランザクションが再試行されます。トランザクションの途中でインスタンスに障害が発生した場合は、そのトランザクションはデータベースにコミットされません。障害が発生したインスタンスが再起動すると、ロード・バランシング・ルーターによってこれが検出され、すべてのインスタンスにリクエストがルーティングされます。
クラスタ構成内のOracle Internet Directoryインスタンスが停止すると、ロード・バランシング・ルーターによってこれが検出され、障害が発生していないインスタンスにリクエストがルーティングされます。
2ノードのクラスタ構成で一方のOracle Internet Directoryインスタンスに障害が発生した場合(またはインスタンスをホストするコンピュータの一方に障害が発生した場合)は、ロード・バランシング・ルーターによって、障害が発生していないOracle Internet Directoryインスタンスにクライアントがルーティングされます。
通常、Oracle Internet Directoryサーバーの障害は、Oracle Internet Directoryクライアントに対して透過的です。これは、ロード・バランサを介してクライアントへのルーティングが継続されるためです。通常、外部ロード・バランサはOracle Internet Directoryプロセスのヘルス・チェックを実行するように構成されます。プロセスが利用不可であることをロード・バランサが検出する前にリクエストが受信されると、クライアント・アプリケーションでエラーを受信することがあります。クライアント・アプリケーションが再試行した場合、ロード・バランサは、これを正常なOracle Internet Directoryインスタンスにルーティングし、リクエストは正常に行われます。
Oracle Internet Directoryのアクティブ/アクティブ構成では、フェイルオーバー時にLDIFファイルを介してldapadd操作を実行していると、ロード・バランサ・ホストとポートを介して実行している場合でも、この操作がエラーになることがあります。これは、Oracle Internet Directoryが一瞬停止するためです。ほとんどのアプリケーションには、固定回数の接続を再試行する機能があるためこの問題は発生しません。
この項では、Oracle Internet Directoryに利用できるデータベース障害からの保護について説明します。
デフォルトでは、Oracle Internet DirectoryのORACLE_INSTANCEで構成されたtnsnames.oraファイルによって、Oracle Internet Directoryからデータベースへの接続はOracle RACデータベース・インスタンス間でロード・バランシングされることが保証されます。たとえば、Oracle Internet Directoryインスタンスが4つのデータベース接続を確立した場合、各データベース・インスタンスに対して接続が2つ確立されます。
Oracle Internet Directoryは、データベースの高可用性イベント通知を使用してデータベースのノード障害を検出し、障害が発生していないノードへフェイルオーバーします。
透過的アプリケーション・フェイルオーバー(TAF)が構成されている場合は、データベース・インスタンスの障害発生時に、Oracle Internet Directoryが正常に稼働しているデータベース・インスタンスにデータベース接続をフェイルオーバーします。これにより、フェイルオーバー時に行われていたLDAPの検索操作が継続されます。
透過的アプリケーション・フェイルオーバー(TAF)と高可用性イベント通知の両方が構成されている場合は、フェイルオーバーには透過的アプリケーション・フェイルオーバー(TAF)が使用され、高可用性イベント通知は、イベントの記録にのみ使用されます。高可用性イベント通知は、OIDLDAPDログ・ファイルに記録されます。
Oracle Internet Directoryには、失効したデータベース接続を検出するメカニズムもあり、これにより、データベースへの再接続が可能になります。
いずれのデータベース・インスタンスも使用できない状態が長く続いた場合は、Oracle Internet DirectoryのLDAPおよびREPLの各プロセスは自動的に停止します。ただし、OIDMONとOPMNは、データベース・インスタンスの可用性に対してpingを継続し、データベースが使用可能になると、OIDMONによってOracle Internet Directoryのプロセス(LDAPとREPL)が自動的に再起動されます。
すべてのデータベース・インスタンスが停止している場合でも、OIDMONは実行を継続し、opmnctl statusコマンドによってOIDLDAPDインスタンスの停止が示されます。データベース・インスタンスが利用可能になると、OIDMONは構成されているすべてのOracle Internet Directoryインスタンスを再起動します。
Oracle Internet Directoryのアクティビティに起因するデータベースのフェイルオーバーはすべて、OIDMONログ・ファイルに記録されます。
この項では、Oracle Internet Directoryの高可用性アーキテクチャを設定するための前提条件について説明します。
高可用性環境でOracle Internet Directoryを設定する前に、各Oracle Internet Directoryのノードの時間が同期していることを確認しておく必要があります。
グリニッジ標準時を使用して全ノードの時間を同期し、ノード間で250秒を超える差異が発生しないようにします。
OIDモニターが2つのノード間で250秒を超える時間の差異を検出すると、遅れているノードのOIDモニターがそのノード上のすべてのサーバーを停止します。この問題を修正するには、遅れているノードの時間を正しい時間に同期させます。OIDモニターはシステム時間の変更を自動的に検出して、そのノードのOracle Internet Directoryサーバーを起動します。
2つ以上のノードがある場合は同様の動作が続きます。たとえば、3つのノードがあり、1つ目のノードが2つ目のノードより150秒進み、2つ目のノードは3つ目のノードより150秒進んでいるとします。この場合、3つ目のノードは最初のノードから300秒遅れているため、OIDモニターは時間が同期するまで3つ目のノードのサーバーを起動しません。
OIDHOST1およびOIDHOST2にOracle Internet Directoryインスタンスをインストールする前に、リポジトリ作成ユーティリティ(RCU)の最新バージョンを使用して、Oracle Identity ManagementおよびManagement Serviceで使用するスキーマのコレクションを作成します。
最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
次の手順に従って、RCUを実行し、Oracle RACデータベース・リポジトリにアイデンティティ管理スキーマを作成します。
次のコマンドを発行します。
prompt> RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」操作を選択してコンポーネント・スキーマを既存のデータベースにロードします。
「次へ」をクリックします。
「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。
データベース・タイプ: Oracle Database
ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: INFRADBHOST1-VIPまたはINFRADBHOST2-VIP
ポート: データベースのポート番号。例: 1521
サービス名: データベースのサービス名。例: oid.example.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワード
ロール: SYSDBA
「次へ」をクリックします。
「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: idm(「コンポーネント」フィールドで「アイデンティティ管理」(Oracle Internet Directory - ODS)しか選択していない場合は、接頭辞の入力はオプションです)。
コンポーネント: 「アイデンティティ管理」(Oracle Internet Directory - ODS)を選択します。その他のスキーマは選択を解除します。
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。
「表領域のマップ」画面で、コンポーネントの表領域を選択します。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
Oracle Internet Directoryを高可用性構成でデプロイする場合は、Oracle Internet Directoryインスタンスのフロントエンドに外部ロード・バランサを使用して、各種Oracle Internet Directoryインスタンス間のリクエストをロード・バランシングすることをお薦めします。
詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。
Oracle Internet Directoryは、スタンドアロン・モードまたはWebLogic Serverドメインの一部として可用性の高い構成にデプロイできます。
Oracle Internet Directoryの全体をコマンドライン・ツールで管理し、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Directory Services Managerが必須ではないと判断される場合は、スタンドアロン・モードのデプロイを選択する必要があります。必要な場合は、後から、opmnctlコマンドを使用してリモートのOracle WebLogic ServerドメインにスタンドアロンのOracle Internet Directoryインスタンスを登録できます。Oracle Enterprise Manager Fusion Middleware ControlとOracle Directory Services Managerを使用して、Oracle WebLogic Serverドメインで構成されたOracle Internet Directoryインスタンスを管理できます。
Oracle Internet Directoryをクラスタ・デプロイメント内に設定することをお薦めします。クラスタ化されたOracle Internet Directoryインスタンスは、同じOracle RACデータベース・リポジトリにアクセスします。
この項の内容は次のとおりです。
この章では、Oracle Identity Management用にOracle WebLogic Server (WL_HOME)およびOracleホーム(ORACLE_HOME)に必要なバイナリをインストールする方法について説明します。
設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。
このインストール手順では、最初にOracle WebLogic Serverをインストールします。
最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の理解に関する項を参照してください。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイドにあります。
Oracle WebLogic Serverインストーラを起動します。
インストーラが起動したら、次の手順に従ってOracle WebLogic Serverをコンピュータにインストールします。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。次に、Oracle WebLogicソフトウェアのインストール先となるコンピュータ上のディレクトリを選択します。
「ミドルウェア・ホーム・ディレクトリ」に、次の値を指定します。
/u01/app/oracleproduct/fmw
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、「My Oracle Support」のユーザー名とパスワードを入力して、セキュリティ・アップデートが通知されるようにします。
「インストール・タイプの選択」画面では、完全インストールとカスタム・インストールのどちらを実行するかを指示するように求めるプロンプトが、インストール・プログラムによって表示されます。
「カスタム」を選択します。
「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、ディレクトリ/u01/app/oracle/fmw/wlserver_10.3を受け入れます。
「次へ」をクリックします。
「インストール・サマリー」画面に、インストール対象として選択したコンポーネントの一覧と、それらをインストールするために使用されるディスク領域の概算値が表示されます。
「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除します。
「完了」をクリックします。
次の手順は、Oracle Fusion Middlewareコンポーネントをインストールすることです。
|
注意: インストールは共有記憶域で実行されるため、トポロジの残りのサーバーからは2つのMW_HOMEインストールにアクセスし、使用できます。 |
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。
Oracle Fusion Middlewareコンポーネント用のインストーラを起動します。
UNIXの場合は、次のコマンドを発行します。
HOST1> runInstaller
Windowsの場合は、setup.exeをダブルクリックします。
インストールを開始する前に、次の環境変数が設定されていないことを確認してください。
LD_ASSUME_KERNEL
ORACLE_INSTANCE
「インベントリ・ディレクトリの指定」画面で、次の操作を行います。
HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。
インストールを実行するユーザーのOSグループを入力します。「次へ」をクリックします。
UNIXのインストールの場合は、画面の手順に従ってrootとしてcreateCentralInventory.shを実行します。
「OK」をクリックします。
次の手順を実行します。
「Oracleインベントリ・ディレクトリの指定」画面で、HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。
インストールを実行するユーザーのOSグループを入力します。
「次へ」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、インストール-構成しないを選択します。
「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
MW_HOME: MW_HOMEの値を入力します。例:
/u01/app/product/fmw
ドロップダウン・リストから、すでにインストールされているMiddlewareホームを選択します。「Oracleホーム」ディレクトリには、ディレクトリ名IDMを入力します。
「次へ」をクリックします。
「サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。
「インストール完了」画面で「終了」をクリックします。
この項では、Oracle Identity Managementソフトウェアをアップグレードする手順について説明します。詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』のOracle Fusion Middlewareの最新パッチ・セットの適用に関する項を参照してください。
./runinstallerを実行してIDMアップグレード・インストーラを起動します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、「次へ」をクリックします。
「インストール場所の指定」画面で、Oracle MiddlewareホームへのパスとOracleホーム・ディレクトリの名前を入力します。
「インストール・サマリー」画面で、選択内容を確認して「インストール」をクリックします。
「インストールの進行状況」画面に、インストールの進行状況が示されます。
インストールが終了すると、oracleRoot.shの確認ダイアログ・ボックスが表示されます。このダイアログ・ボックスは、インストールを続行する前に構成スクリプトをrootユーザーとして実行する必要があることを示しています。確認ダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootユーザーとしてログインして、スクリプト・ファイル/u01/app/oracle/product/fmw/id/oracleRoot.shを実行します。スクリプトが完了したら、確認ダイアログ・ボックスの「OK」をクリックします。
「インストール完了」画面で「終了」をクリックして終了します。
この項では、WebLogic Serverドメインを使用せずにOracle Internet Directoryをデプロイする手順について説明します。
スキーマ・データベースが実行中であり、RCUを使用してODSデータベース・スキーマをシードしてあることを確認してから、次の手順に従ってOIDHOST1上のOracle Internet Directoryインスタンスを構成します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIDHOST1にインストールされ、アップグレードされていることを確認します。
使用しているオペレーティング・システムに対して次のコマンドを発行して、ポート389と636がコンピュータ上の他のサービスに使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":389" netstat -an | grep LISTEN | grep ":636"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr ":389" netstat -an | findstr "LISTEN" | findstr ":636"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
/etc/servicesファイルでポート389と636のエントリを削除して、サービスまたはコンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Internet Directoryのポート番号を指定する行は非コメント化)を割り当てます。
# The Non-SSL port for OID Oracle Internet Directory Port No = 389 # The SSL port for OID Oracle Internet Directory (SSL) Port No = 636
次のようにして、ORACLE_HOME/binディレクトリの下にあるOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、「ドメインなしで構成」を選択して「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。
Oracleホーム・ディレクトリ:
/u01/app/oracle/product/fmw/idm
Oracleインスタンスの場所:
/u01/app/oracle/admin/oid_instance1
Oracleインスタンス名:
oid_instance1
|
注意: OIDHOST1のOracleホームの場所を示すディレクトリ・ パスが、OIDHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OIDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。
この場合、OIDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。
|
「次へ」をクリックします。
「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle Internet Directory」を選択し、その他のすべてのコンポーネントの選択を解除して「次へ」をクリックします。
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。
「スキーマ・データベースの指定」画面で、既存のスキーマの使用を選択し、次の値を指定します。
接続文字列:
infradbhost1-vip.example.com:1521^infradbhost2-vip.example.com:1521@oid.example.com
|
注意: Oracle RACデータベースの接続文字列の情報は、host1:port1^host2:port2@servicenameという短い形式で入力する必要があります。 インスタンス名を含む長い形式で接続文字列を入力しないでください。 前述のように指定した情報は、完全で正確である必要があります。具体的には、各Oracle RACインスタンスのホストおよびポートを正しく入力する必要があります。また、指定したすべてのOracle RACインスタンスに、指定したサービス名が構成されている必要があります。 Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。 このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。 |
ユーザー名: ODS
パスワード: ******
「次へ」をクリックします。
「Oracle Internet Directoryの作成」画面で、レルムを指定し、管理者(cn=orcladmin)パスワードを入力して、「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
Oracle Identity Management 11gインストーラを使用してOracle Internet Directoryのインストールを実行する場合、インストーラがOracle Internet Directoryインスタンスに割り当てるデフォルトのコンポーネント名はoid1です。このコンポーネント名は変更できません。
このOracle Internet Directoryインスタンスのインスタンス固有の構成エントリは、cn=oid1, cn=osdldapd, cn=subconfigsubentryです。
別のコンピュータ上で2つ目のOracle Internet Directoryのインストールを実行し、そのOracle Internet Directoryインスタンスで1つ目のインスタンスと同じデータベースを使用する場合、インストーラは、同一データベースを使用する他のコンピュータにすでにインストールされているOracle Internet Directoryインスタンスを検出し、2つ目のOracle Internet Directoryインスタンスにはコンポーネント名oid2を割り当てます。
2つ目のOracle Internet Directoryインスタンスのインスタンス固有の構成エントリは、cn=oid2, cn=osdldapd, cn=subconfigsubentryです。エントリcn=oid2, cn=osdldapd, cn=subconfigsubentryのプロパティを変更しても、1つ目のインスタンス(oid1)には影響しません。
さらに別のコンピュータ上に3つ目のOracle Internet Directoryがインストールされ、このインスタンスでも、前の2つのインスタンスと同じデータベースを使用する場合、インストーラは3つ目のOracle Internet Directoryインスタンスにコンポーネント名oid3を割り当てます。同じデータベースを使用する別のホストには、このような方法でコンポーネント名が割り当てられます。
すべてのOracle Internet Directoryインスタンスで共有される構成は、cn=dsaconfig, cn=configsets,cn=oracle internet directoryです。このエントリに変更が加えられた場合は、Oracle Internet Directoryのすべてのインスタンスに影響します。
このネーミング・スキームによって、各Oracle Internet Directoryインスタンスに異なるコンポーネント名が割り当てられるため、Oracle Enterprise Managerを使用してドメインを表示する際に混乱を回避できます。
Oracle Internet Directoryリポジトリが実行されていることを確認してから、次の手順に従ってOIDHOST2上のOracle Internet Directoryインスタンスを構成します。
|
注意: この項で説明する手順は、11g Oracle Identity Managementの高可用性構成でOracle Internet Directoryをスケール・アウトするときにも使用できます。 |
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIDHOST2にインストールされ、アップグレードされていることを確認します。
OIDHOST1では、Oracle Internet Directoryによってポート389と636が使用されています。OIDHOST2のOracle Internet Directoryインスタンスにも同じポートを使用する必要があります。したがって、 ポート389および636がOIDHOST2上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに応じて次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":389" netstat -an | grep LISTEN | grep ":636"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr ":389" netstat -an | findstr "LISTEN" | findstr ":636"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
/etc/servicesファイルでポート389と636のエントリを削除して、サービスまたはコンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Internet Directoryのポート番号を指定する行は非コメント化)を割り当てます。
# The Non-SSL port for OID Oracle Internet Directory Port No = 389 # The SSL port for OID Oracle Internet Directory (SSL) Port No = 636
次のようにして、ORACLE_HOME/binディレクトリの下にあるOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、「ドメインなしで構成」を選択して「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。
Oracleホーム・ディレクトリ:
/u01/app/oracle/product/fmw/idm
Oracleインスタンスの場所:
/u01/app/oracle/admin/oid_instance2
Oracleインスタンス名:
oid_instance2
|
注意: OIDHOST2のOracleホームの場所を示すディレクトリ パスが、OIDHOST1のOracleホームの場所を示すパスと同じであることを確認します。たとえば、OIDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。
この場合、OIDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。
|
「次へ」をクリックします。
「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle Internet Directory」を選択し、その他のすべてのコンポーネントの選択を解除して「次へ」をクリックします。
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。
「スキーマ・データベースの指定」画面で、既存のスキーマの使用を選択し、次の値を指定します。
接続文字列:
infradbhost1-vip.example.com:1521^infradbhost2-vip.example.com:1521:@oid.example.com
|
注意: Oracle RACデータベース接続文字列情報は、次のような短い形式で入力する必要があります。 host1:port1:instance1^host2:port2:instance2@servicename インスタンス名を含む長い形式で接続文字列を入力しないでください。 接続文字列の情報は、完全で正確である必要があります。具体的には、各Oracle RACインスタンスに正しいホストおよびポートを入力し、指定したすべてのOracle RACインスタンス用に構成されているサービス名を入力する必要があります。 Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。 このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。 |
ユーザー名: ODS
パスワード: ******
「次へ」をクリックします。
ODSスキーマが使用中であることを示すメッセージが表示されます。選択したODSスキーマはすでに既存のOracle Internet Directoryインスタンスで使用されています。したがって、構成中の新しいOracle Internet Directoryインスタンスは、この同じスキーマを再利用します。
「はい」を選択して続行します。
「OID管理者パスワードの指定」画面で、OID管理者のパスワードを指定し、「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Internet Directoryコンポーネントを管理する場合は、コンポーネントとそれを含むOracle Fusion MiddlewareインスタンスをOracle WebLogic Serverドメインに登録する必要があります。インストール時またはOracleインスタンスの作成時に、Oracle Fusion MiddlewareインスタンスをWebLogicドメインに登録できますが、必須事項ではありません。
WebLogicドメインにOracle Internet Directoryコンポーネントを登録するには、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのWebLogic ServerにおけるOracle Fusion Middlewareインスタンスまたはコンポーネントの登録に関する説明を参照してください。
この項では、WebLogic Serverドメインの一部としてOracle Internet Directoryの高可用性構成をデプロイする手順について説明します。
この構成では、1つ目のホストにOracle Internet DirectoryとWebLogic Serverドメインが構成され、2つ目のホストにはOracle Internet Directoryのみが構成されます。2つ目のホストのOracle Internet Directoryインスタンスは、1つ目のホストで作成されたドメインに参加します。
スキーマ・データベースが実行中であり、RCUを使用してODSデータベース・スキーマをシードしてあることを確認してから、次の手順に従ってOIDHOST1上のOracle Internet Directoryインスタンスを構成します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIDHOST1にインストールされ、アップグレードされていることを確認します。
使用しているオペレーティング・システムに対して次のコマンドを発行して、ポート389と636がコンピュータ上の他のサービスに使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":389" netstat -an | grep LISTEN | grep ":636"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr ":389" netstat -an | findstr "LISTEN" | findstr ":636"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
/etc/servicesファイルでポート389と636のエントリを削除して、サービスまたはコンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Internet Directoryのポート番号を指定する行は非コメント化)を割り当てます。
# The Non-SSL port for OID Oracle Internet Directory Port No = 389 # The SSL port for OID Oracle Internet Directory (SSL) Port No = 636
次のようにして、ORACLE_HOME/binディレクトリの下にあるOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、新規ドメインの作成を選択します。次の値を指定します。
ユーザー名: weblogic
パスワード: <weblogicユーザーのパスワード>
パスワードの確認: <weblogicユーザーのパスワードを再度入力します>
ドメイン名: IDMDomain
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。
Oracleホーム・ディレクトリ:
/u01/app/oracle/product/fmw/idm
WebLogic Serverのディレクトリ:
/u01/app/oracle/product/fmw/wlserver_10.3
Oracleインスタンスの場所:
/u01/app/oracle/admin/oid_inst1
Oracleインスタンス名:
oid_inst1
|
注意: OIDHOST1のOracleホームの場所を示すディレクトリ・ パスが、OIDHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OIDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。
この場合、OIDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。
|
「次へ」をクリックします。
「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle Internet Directory」を選択し、その他のすべてのコンポーネントの選択を解除して「次へ」をクリックします。
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。
|
注意: インストーラによって設定されるデフォルトのOracle WebLogic Serverのクラスタ・モードは、(マルチキャストではなく)ユニキャストになります。 |
「スキーマ・データベースの指定」画面で、既存のスキーマの使用を選択し、次の値を指定します。
接続文字列:
infradbhost1-vip.example.com:1521:oiddb1^infradbhost2-vip.example.com:1521:oiddb2@oid.example.com
|
注意: Oracle RACデータベースの接続文字列の情報は、host1:port1:instance1^host2:port2:instance2@servicenameの書式で指定する必要があります。 このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。 前述のように指定した情報は、完全で正確である必要があります。具体的には、ホスト、ポート、およびインスタンス名が各Oracle RACインスタンスに正しく指定されている必要があります。また、指定したOracle RACインスタンスのすべてにサービス名が構成されている必要があります。 Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。 |
ユーザー名: ODS
パスワード: ******
「次へ」をクリックします。
「OIDの構成」画面で、レルムを指定し、管理者(cn=orcladmin)パスワードを入力して、「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
|
注意: Oracle Identity Management 11gのインストーラによって割り当てられるOracle Internet Directoryコンポーネント名の詳細は、第8.3.3.2.2項「Oracle Identity Managementのインストーラによって割り当てられるOracle Internet Directoryのコンポーネント名」を参照してください。 |
この項では、OIDHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法について説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。
次の手順に従って、boot.propertiesファイルを作成します。
OIDHOST1で、次のディレクトリに移動します。
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
例:
cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security
テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUserpassword=adminUserPassword
|
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。 |
管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OIDHOST1上の管理サーバーを起動します。
Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
WebLogic Server管理コンソール:
http://oidhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oidhost1.example.com:7001/em
weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。
Oracle Internet Directoryリポジトリが実行されていることを確認してから、次の手順に従ってOIDHOST2上のOracle Internet Directoryインスタンスを構成します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIDHOST2にインストールされ、アップグレードされていることを確認します。
OIDHOST1では、Oracle Internet Directoryによってポート389と636が使用されています。OIDHOST2のOracle Internet Directoryインスタンスにも同じポートを使用する必要があります。したがって、 ポート389および636がOIDHOST2上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに応じて次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":389" netstat -an | grep LISTEN | grep ":636"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr ":389" netstat -an | findstr "LISTEN" | findstr ":636"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
/etc/servicesファイルでポート389と636のエントリを削除して、サービスまたはコンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Internet Directoryのポート番号を指定する行は非コメント化)を割り当てます。
# The Non-SSL port for OID Oracle Internet Directory Port No = 389 # The SSL port for OID Oracle Internet Directory (SSL) Port No = 636
次のようにして、ORACLE_HOME/binディレクトリの下にあるOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、既存ドメインの拡張を選択して、次の値を指定します。
ホスト名: idmhost1.example.com (WebLogic管理サーバーを実行しているホスト)
ポート: 7001(これはWebLogic管理サーバーのポートです。)
ユーザー名: weblogic
パスワード: <weblogicユーザーのパスワード>
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。
Oracleホーム・ディレクトリ: idm
WebLogic Serverのディレクトリ:
/u01/app/oracle/product/fmw/wlserver_10.3
Oracleインスタンスの場所:
/u01/app/oracle/admin/oid_inst2
Oracleインスタンス名: oid_inst2
|
注意: OIDHOST1のOracleホームの場所を示すディレクトリ・ パスが、OIDHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OIDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。
この場合、OIDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。
|
「次へ」をクリックします。
「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle Internet Directory」を選択し、「次へ」を選択します。
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。
「スキーマ・データベースの指定」画面で、既存のスキーマの使用を選択し、次の値を指定します。
接続文字列:
infradbhost1-vip.example.com:1521:oiddb1^infradbhost2-vip.example.com:1521:oiddb2@oid.example.com
|
注意: Oracle RACデータベースの接続文字列の情報は、host1:port1:instance1^host2:port2:instance2@servicenameの書式で指定する必要があります。 このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。 前述のように指定した情報は、完全で正確である必要があります。具体的には、ホスト、ポート、およびインスタンス名が各Oracle RACインスタンスに正しく指定されている必要があります。また、指定したOracle RACインスタンスのすべてにサービス名が構成されている必要があります。 Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。 |
ユーザー名: ODS
パスワード: ******
「次へ」をクリックします。
ODSスキーマが使用中であることを示すメッセージが表示されます。選択したODSスキーマはすでに既存のOracle Internet Directoryインスタンスで使用されています。したがって、構成中の新しいOracle Internet Directoryインスタンスは、この同じスキーマを再利用します。
「はい」を選択して続行します。
「OID管理者パスワードの指定」画面で、Oracle Internet Directory管理者のパスワードを指定し、「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
ldapbindコマンドライン・ツールを使用して、各Oracle Internet DirectoryインスタンスとLDAP仮想サーバーに接続できることを確認します。ldapbindツールでは、サーバーに対してクライアントを認証できるかどうかを確認できます。
|
注意:
|
非SSLの場合:
ldapbind -h oidhost1.example.com -p 389 -D "cn=orcladmin" -q ldapbind -h oidhost2.example.com -p 389 -D "cn=orcladmin" -q ldapbind -h oid.example.com -p 389 -D "cn=orcladmin" -q
|
注意: 前述の-qオプションを指定すると、ユーザーのパスワードの入力が求められます。LDAPツールでは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定されている場合、-w passwordおよび-P passwordの各オプションが無効になるよう変更されています。可能なかぎり、この機能を使用してください。 |
SSLの場合:
ldapbind -h oidhost1.example.com -p 636 -D "cn=orcladmin" -q -U 1 ldapbind -h oidhost2.example.com -p 636 -D "cn=orcladmin" -q -U 1 ldapbind -h oid.example.com -p 636 -D "cn=orcladmin" -q -U 1
-Uは、SSL認証モードの指定に使用されるオプション引数です。SSL認証モードに有効な値は次のとおりです。
1 = 認証は必要ありません。
2 = 一方向認証が必要です。このオプションを使用する場合は、ウォレットの場所(-W "file:/home/my_dir/my_wallet")およびウォレットのパスワード(-P wallet_password)も指定する必要があります。
3 = 双方向認証が必要です。このオプションを使用する場合は、ウォレットの場所(-W "file:/home/my_dir/my_wallet")およびウォレットのパスワード(-P wallet_password)も指定する必要があります。
ldapbindコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Managementリファレンスのldapbindに関する項を参照してください。
Oracle Internet Directoryに対するSSLの設定の詳細は、『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』マニュアルのSecure Sockets Layer (SSL)の構成に関する項を参照してください。
次のURLのWebLogic Server管理コンソールにアクセスします。
http://oidhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middlewareコンソール
http://oidhost1.example.com:7001/em
この項では、Oracle Internet DirectoryのフェイルオーバーとOracle RACのフェイルオーバーを実行する手順を説明します。
次の手順に従って、Oracle Internet Directoryインスタンスのフェイルオーバーを実行し、Oracle Internet Directoryのステータスを調べます。
OIDHOST1で、opmnctlコマンドを使用して、Oracle Internet Directoryインスタンスを停止します。
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1
OIDHOST2で、ロード・バランシング・ルーターを使用して、Oracle Internet Directoryのステータスをチェックします。
|
注意:
|
ldapbind -h oid.example.com -p 389 -D "cn=orcladmin" -q
|
注意: 前述の-qオプションを指定すると、ユーザーのパスワードの入力が求められます。LDAPツールでは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定されている場合、-w passwordおよび-P passwordの各オプションが無効になるよう変更されています。可能なかぎり、この機能を使用してください。 |
OIDHOST1で、opmnctlコマンドを使用して、Oracle Internet Directoryインスタンスを起動します。
ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running) ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1
OIDHOST2で、opmnctlコマンドを使用して、Oracle Internet Directoryインスタンスを停止します。
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1
OIDHOST1で、ロード・バランシング・ルーターを使用して、Oracle Internet Directoryのステータスをチェックします。
ldapbind -h oid.example.com -p 389 -D "cn=orcladmin" -q
OIDHOST2で、opmnctlコマンドを使用して、Oracle Internet Directoryインスタンスを起動します。
ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running) ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1
次の手順に従って、Oracle RACのフェイルオーバーを実行します。
srvctlコマンドを使用して、データベース・インスタンスを停止します。
srvctl stop instance -d db_unique_name -i inst_name_list
srvctlコマンドを使用して、データベース・インスタンスのステータスを確認します。
srvctl status database -d db_unique_name -v
Oracle Internet Directoryのステータスを確認します。
|
注意:
|
ldapbind -h oid_host1 -p 389 -D "cn=orcladmin" -q ldapbind -h oid_host2 -p 389 -D "cn=orcladmin" -q ldapbind -h oid.example.com -p 389 -D "cn=orcladmin" -q
|
注意: 前述の-qオプションを指定すると、ユーザーのパスワードの入力が求められます。LDAPツールでは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定されている場合、-w passwordおよび-P passwordの各オプションが無効になるよう変更されています。可能なかぎり、この機能を使用してください。 |
srvctlコマンドを使用して、データベース・インスタンスを起動します。
srvctl start instance -d db_unique_name -i inst_name_list
この項では、Oracle Internet Directoryの高可用性の問題のトラブルシューティングに役立つ情報について説明します。
Oracle Internet Directoryのログ・ファイルは次のディレクトリにあります。
ORACLE_INSTANCE/diagnostics/log/OID
トラブルシューティングの際に調査するログ・ファイルの順序は次のとおりです。
oidmon-xxx.log
oidldapd01-xxxx.log
oidldapd01s-xxxx.log
この項では、高可用性に関連するエラー・メッセージの一部とその意味を示します。
エラー: ログ・ファイルにORA-3112、ORA-3113エラーがあります
原因: データベース・ノードのいずれかが停止し、障害が発生していないノードにOIDが再接続します。
処置: データベース・ノードの停止、またはOracleプロセスの停止の原因を確認します。
エラー: フェイルオーバーしています...ログ・ファイルでスタンバイしてください
原因: OIDサーバーがOracleプロセスからデータベース・ノードのいずれかが停止したことを知らせる通知を受信しました。OIDは障害が発生していないノードに接続します。
フェイルオーバーが正常完了すると、次のメッセージが表示されます。
フェイルオーバーが終了しました...サービスを再開しています
フェイルオーバーが失敗すると、次のようなエラーが表示されます。
a. 10回試行しましたが、フェイルオーバー機能を終了しています
b. 無効なフェイルオーバー・イベント:
c. セッションのDBパラメータを設定できないため、フェイルオーバーを強制終了しました
高可用性イベント通知が有効な場合は、次のようなメッセージが表示されます。
HA Callback Event Thread Id: 8 Event type: 0 HA Source: OCI_HA_INSTANCE Host name: dbhost1 Database name: orcl Instance name: orcl1 Timestamp: 14-MAY-09 03.25.24 PM -07:00 Service name: orcl.example.com HA status: DOWN - TAF Capable
TAFが無効な場合、HAステータスは「DOWN」と表示されます。
処置: データベース・ノードが停止した原因を確認します。
エラー: ノード1とノード2の間で250秒以上の時間差異が検出されました.
原因: 2つのノード間の時間に差異があります。
処置: システム時間を同期します。
エラー: ノード=%が構成された%d回までに応答しませんでした。フェイルオーバーしています...
原因: OIDノード(oidmon)のいずれかが応答しません。
処置: ノードが稼働中か、またはOIDMONプロセスが実行中であるかを確認します。
Oracle Internet Directoryのトラブルシューティングの詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドを参照してください。
この項では、高可用性環境のOracle Internet Directoryに関する問題について説明します。
Oracle Internet Directory Database Password Utility (oidpasswd)を使用すると、どのOracle Internet DirectoryのノードからもOracle Internet Directoryデータベースのスキーマ・パスワード(データベースのODSユーザーのパスワード)を変更できます。ただし、ODSスキーマ・パスワードは、各OIDインスタンスのORACLE_INSTANCEにあるパスワード・ウォレットに格納されるため、それぞれのOracle Internet Directoryノードでパスワード・ウォレットを更新する必要があります。
ODSデータベース・ユーザー・パスワードを変更するには、いずれかのOracle Internet Directoryノードから次のコマンドを呼び出します。
oidpasswd connect=database-connection-string change_oiddb_pwd=true
その他のすべてのOracle Internet Directoryノードで、次のコマンドを呼び出して、パスワード・ウォレットを同期化します。
oidpasswd connect=database-connection-string create_wallet=true
OID Database Password Utility (oidpasswd)を使用して、Oracle RACノードの1つでODSパスワードを変更する場合は、次のいずれかを実行して、他のOracle RACノードのウォレットORACLE_HOME/ldap/admin/oidpwdlldap1を更新する必要があります。
その他のすべてのノードでOID Database Password Utilityを起動して、ウォレット・ファイルのみを更新します。これは、レプリケーション・パスワードの変更にも当てはまりますが、レプリケーション・パスワードの変更には、OID Database Password Utilityではなくレプリケーション環境管理ツールを使用してパスワードを更新します。
変更後のウォレットを他のノードにコピーします。
1つのノードでしかoidpasswdコマンドを実行せず、すべてのOracle RACノードのウォレットを更新していない場合、2つ目のノードのOracle Internet Directoryインスタンスは、他のノードで起動できなくなります。このエラーは、OIDMONログ・ファイルに次のように表示されます。
[gsdsiConnect] ORA-1017, ORA-01017: invalid username/password; logon denied.
これを修正するには、oidpwdlldap1ファイルを他のOracle RACノードにコピーするか、他のノードでオプションcreate_wallet=trueオプションを指定してoidpasswdツールを起動します。
この項では、Oracle Virtual Directoryの概要およびOracle Virtual Directoryの高可用性環境の設計とデプロイについて説明します。
この項の内容は次のとおりです。
Oracle Virtual DirectoryはLDAP Version 3対応のサービスであり、1つ以上のエンタープライズ・データ・ソースを単一のディレクトリ・ビューに仮想的に抽象化します。Oracle Virtual Directoryを使用すると、インフラストラクチャとアプリケーションのいずれかを変更する必要性を最小限に抑えるか、またはその必要性をなくして、LDAPを認識するアプリケーションを多様なディレクトリ環境に統合できます。図8-4に示すように、Oracle Virtual DirectoryはWebアプリケーションやポータルなど、一連の各種クライアントをサポートし、ディレクトリ、データベース、およびWebサービスに接続できます。
図8-4は、非高可用性アーキテクチャのOracle Virtual Directoryを示しています。
Oracle Virtual Directoryサーバーは、Javaで作成され、内部は複数の層で構成されます。この層は論理的な層で、管理者やクライアントからはOracle Virtual Directoryは1つの完全なサービスのように見えます。
OPMNは、Oracle Virtual Directoryプロセスを起動、監視、および管理するために使用され、Oracle Virtual Directoryプロセスが停止した場合はそれを再起動するために使用されます。Oracle Virtual Directoryインスタンスは、Oracle Enterprise Manager Fusion Middleware Controlを使用しても起動および停止できます。Oracle Virtual Directoryインスタンスを起動および停止するためのOPMNCTLやEnterprise Managerの使用方法の詳細は、Oracle Fusion Middleware Oracle Virtual Directoryに関する管理者ガイドを参照してください。
Oracle Virtual Directoryのインストール時にインストールされるJPSを除き、Oracle Virtual Directoryには外部依存性はありません。独立して実行できます。
Oracle Virtual Directoryは、LDAPオブジェクトをローカル・ファイルシステムに格納するように構成できます。この機能はJPSおよびその他のコンポーネントで使用できます。
Oracle Virtual Directoryには、2つのタイプのリスナー(LDAPとHTTP)があります。いずれのリスナーも基本プロトコルに加えてSSL/TLSもサポートします。LDAP層にはデジタル証明認証をサポートするLDAP-SASLに対応する機能もあります。
LDAPプロトコルは、LDAPv2/v3ベースのサービスを提供し、HTTPプロトコルはDSMLv2などの1つ以上のサービスや、XSLT対応のWebゲートウェイによる基本的なホワイト・ページ機能を提供します。
運用の特質に応じて、クライアント接続は永続または短期のいずれかにできます。
この項では、Oracle Virtual Directoryの様々な構成アーティファクトについて説明します。次のOracle Virtual Directory構成ファイルは、ORACLE_INSTANCE/config/OVD/OVDComponentNameにあります。
server.os_xml:
Oracle Virtual Directoryには、サーバーが匿名ユーザーや認証ユーザーに返すことができるエントリの数などの項目を管理する機能があります。また、インバウンド・トランザクション・トラフィックを制限することもできます。これは、プロキシ設定されたソースをサービス拒否攻撃から保護するため、またはLDAPトラフィックを制限して一定のディレクトリ・インフラストラクチャ・リソースへのアクセスを制御するために利用できます。これらを含むプロパティはserver.os_xmlで構成されます。
listeners.os_xml:
Oracle Virtual Directoryは、リスナーと呼ばれる接続を介してクライアントにサービスを提供します。Oracle Virtual Directoryでは、2つのタイプのリスナー(LDAPとHTTP)をサポートします。Oracle Virtual Directoryの構成では、任意の数のリスナーを設定できます。また、リスナーを設定しないことにより、アクセスを管理ゲートウェイのみに制限することもできます。ほとんどのOracle Virtual Directoryのデプロイでは、2つのHTTPリスナーと2つのLDAPリスナーが必要になります。この場合、各プロトコルで一方のリスナーがSSL、もう一方が非SSLに使用されます。リスナー構成ファイルは、listeners.os_xmlです。
adapters.os_xml:
複数かつ様々なデータ・リポジトリにあるデータの単一の仮想ディレクトリ・ビューを表示するには、Oracle Virtual Directoryをこれらのリポジトリに接続して、データの仮想化とリポジトリ間でのデータのルーティングを可能にする必要があります。Oracle Virtual Directoryは、基盤となるデータ・リポジトリへの接続にアダプタを使用します。各アダプタが、特定の親識別名(DN)で識別されるディレクトリのネームスペースを管理します。構成可能なアダプタの数に制限はありません。また、アダプタの結合やオーバーラップによって、カスタマイズされたディレクトリ・ツリーを表示することもできます。アダプタの構成ファイルは、adapters.os_xmlです。
|
注意: Oracle Virtual DirectoryとプロキシLDAPディレクトリとの間の非SSL認証接続の構成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドを参照してください。この手順は、匿名暗号をサポートするように構成されている任意のプロキシLDAPディレクトリに対して使用できます。 |
acls.os_xml
Oracle Virtual Directoryは、接続されたすべてのデータ・ストアに一様に適用できる詳細なアクセス制御を提供します。また、Internet Engineering Task ForceのRFC 2820「Access Control Requirements for LDAP」にも準拠しています。アクセス制御のルールは、IETFの「LDAP Access Control Model for LDAPv3」(2001年3月2日草稿)というタイトルのインターネット・ドラフトに基づいてモデル化されています。
Oracle Virtual Directoryは、1つ以上のエンタープライズ・データ・ソースを単一のディレクトリ・ビューに仮想的に抽象化します。このためアクセス制御リスト(ACL)とアダプタのネームスペースは相互に独立しています。ネームスペース内のすべてのエントリの削除やアダプタのルート値を変更しても、ACLに対して自動的に作用することはありません。ACLとアダプタのネームスペースは、相互に独立して構成する必要があります。ACL構成ファイルは、acls.os_xmlです。
Oracle Virtual Directoryインスタンス固有のデータは、ORACLE_INSTANCEホームに格納されます。ウォレットもインスタンスのホームに格納されます。
単一のOracle Virtual Directoryインスタンスで障害が発生した場合は、OPMNを使用してインスタンスを再起動します。
Oracle Virtual Directoryインスタンスのログ・ファイルは、インスタンスのホームにある次のディレクトリに保存されます。
ORACLE_INSTANCE/diagnostics/logs/OVD/OVDComponentName/
Oracle Virtual Directoryのログ・ファイルを使用したOracle Virtual Directoryに関する問題のトラブルシューティングについては、第8.4.6項「Oracle Virtual Directoryの高可用性のトラブルシューティング」を参照してください。
この項では、Oracle Virtual Directoryを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。前提条件については、第8.4.2.2項「Oracle Virtual Directoryの前提条件」を、2ノードのクラスタを設定するための固有の手順については、第8.4.3項「Oracle Virtual Directoryの高可用性の構成手順」を参照してください。
図8-5は、Oracle Virtual Directoryのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。
図8-5では、高可用性アーキテクチャのディレクトリ層にOracle Virtual Directoryがあります。2ノードのクラスタはインストール時に設定されます。ロード・バランシング・ルーターによって、2つのOracle Virtual Directoryインスタンスにリクエストがルーティングされます。これらのインスタンスはOVDHOST1およびOVDHOST2上にあり、クラスタ化されています。Oracle RACインスタンスが使用不可になった場合の通知には、高速接続フェイルオーバー(FCF)が使用されます。
2つのコンピュータには同一のOracle Virtual Directoryが構成されています。各インスタンスのOracle Virtual Directory構成は、それぞれのORACLE_INSTANCEに格納されます。各Oracle Virtual Directoryインスタンスの構成は、Oracle Directory Services Managerを使用して別々に更新し、それぞれ一度に1つのOracle Virtual Directoryインスタンスに接続する必要があります。これにかわる方法としては、一方のOracle Virtual Directoryインスタンスの構成を更新し、クローニングを使用してもう一方のOracle Virtual Directoryインスタンスに構成をコピーします。
|
注意: Oracle Virtual Directoryの構成を管理するには、Oracle Directory Services Managerを使用する必要があります。Oracle Virtual Directoryインスタンスの構成を更新する際に、ロード・バランサを介してOracle Directory Services ManagerをOracle Virtual Directoryに接続しないでください。このインスタンスの構成を更新するには、物理的なOracle Virtual Directoryインスタンスに明示的に接続する必要があります。 |
OPMNを使用してOracle Virtual Directoryインスタンスの起動と停止をします。複数のOracle Virtual Directoryインスタンスを含むクラスタを起動する場合、クラスタ内の各Oracle Virtual Directoryインスタンスに影響はありません。
ロード・バランシング・ルーターによってOracle Virtual Directoryインスタンスの停止または障害が検出されると、障害が発生していないインスタンスにLDAPおよびHTTPトラフィックがルーティングされます。障害が発生したインスタンスが再起動すると、ロード・バランシング・ルーターによってこれが検出され、障害が発生していないすべてのインスタンスにトラフィックがルーティングされます。
トランザクションの途中でインスタンスに障害が発生した場合は、このトランザクションはバックエンドにコミットされません。
2ノードのOracle Virtual Directoryクラスタで一方のOracle Virtual Directoryインスタンスに障害が発生した場合、ロード・バランシング・ルーターによってこれが検出され、クラスタ内で障害が発生していないインスタンスにLDAPクライアント・トラフィックがルーティングされます。障害があったOracle Virtual Directoryインスタンスが再起動すると、ロード・バランシング・ルーターによってこれが検出され、クラスタ内で障害が発生していないインスタンスにLDAPクライアント・トラフィック・インスタンスがルーティングされます。
Oracle Virtual Directoryには、次のように高可用性に関する多数の機能があります。
フォルト・トレランスとフェイルオーバー: Oracle Virtual Directoryのフォルト・トレランスには、次の2つの形態があります。
フォルト・トレラント構成内で構成できる
フォルト・トレラント・プロキシ・ソースへのフローを管理できる
構成ファイルをコピーまたは共有することにより、複数のOracle Virtual Directoryを迅速にデプロイできます。ラウンドロビンDNS、リダイレクタまたはクラスタ・テクノロジと組み合せると、Oracle Virtual Directoryは完全なフォルト・トレラント・ソリューションとなります。
プロキシ設定された各ディレクトリ・ソースについて、特定のソースの複数のホスト(レプリカ)にアクセスするようにOracle Virtual Directoryを構成できます。ホスト間のフェイルオーバーと負荷分散もインテリジェントに実行されます。柔軟な構成オプションを使用して、管理者は特定のレプリカ・ノードに与える負荷の割合を制御したり、特定のホストを読取り専用レプリカか読取り/書込みサーバー(マスター)かに指定することができます。これにより、読取り専用レプリカに書込もうとすることから生じる不要な参照を回避できます。
ロード・バランシング: Oracle Virtual Directoryの設計には、プロキシ設定されたLDAPディレクトリ・ソース間で負荷を分散し、障害を管理することのできる強力なロード・バランシング機能が組み込まれています。
Oracle Virtual Directoryの仮想ディレクトリ・ツリー機能により、大容量のディレクトリ情報のセットを複数の個別ディレクトリ・サーバーに細分化することができます。また、独立したディレクトリ・ツリー・ブランチを結合すれば、分割したデータ・セットを再び結合して1つの仮想ツリーに戻すこともできます。
特定のソースに対して複数のLDAPサーバーがある場合は、Oracle Virtual DirectoryのLDAPアダプタ自身でロード・バランシングとフェイルオーバーを実行できます。このロード・バランシングとフェイルオーバーは、クライアントから意識されることなく行われるので、ハードウェアの追加や、Oracle Virtual Directoryに接続しているクライアントへの変更は必要ありません。
データベース・アダプタは、下位のJDBCドライバにロード・バランシングとフェイルオーバー機能がある場合、この機能をサポートします。また、Oracle Virtual DirectoryはOracle Real Application Clusters (Oracle RAC)とともに使用できることが保証されています。Oracle Virtual DirectoryをOracle RACと使用する方法の詳細は、第5.1.6項「JDBCクライアント」を参照してください。
Oracle Virtual Directoryのルーティングも、ロード・バランシング機能を提供します。ルーティングでは、最適な検索ターゲットを決定するために、検索フィルタを検索ベースに追加することができます。この方法でロード・バランシングを行うと、仮想化された適切なディレクトリ・ソースに問合せが自動的にルーティングされるので、大量のディレクトリ・エントリも処理できるようになります。
|
注意: Oracle Virtual Directoryの価値は、ディレクトリ・ストアとしてではなく、仮想化とプロキシのサービスとして発揮されます。可用性の高いディレクトリ・ストレージ・システムが必要な場合は、Oracle Internet Directoryの使用をお薦めします。 |
Oracle Virtual Directoryインスタンスのログ・ファイルは、インスタンスのホームにある次のディレクトリに保存されます。
ORACLE_INSTANCE/diagnostics/logs/OVD/OVDComponentName/
Oracle Virtual Directoryのログ・ファイルを使用したOracle Virtual Directoryに関する問題のトラブルシューティングについては、第8.4.6項「Oracle Virtual Directoryの高可用性のトラブルシューティング」を参照してください。
この項では、Oracle Virtual Directoryの前提条件について説明します。
|
注意: Oracle Virtual Directoryを高可用性デプロイメントで使用する場合は、クラスタ・ノードのシステム・クロックを同期する必要があります。 |
Oracle Virtual Directoryを高可用性構成でデプロイする場合は、Oracle Virtual Directoryインスタンスのフロントエンドに外部ロード・バランサを使用して、各種のOracle Virtual Directoryインスタンス間のLDAPリクエストをロード・バランシングすることをお薦めします。
詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。
Oracle Virtual Directoryは、スタンドアロン・モードまたはWebLogicサーバー・ドメインの一部として可用性の高い構成にデプロイできます。
Oracle Virtual Directoryを効率的に管理するには、Oracle Directory Services ManagerとOracle Enterprise Manager Fusion Middleware Controlが必要であるため、Oracle Virtual DirectoryはOracle WebLogic Serverドメインの一部としてデプロイすることをお薦めします。コロケート構成でのOracle Virtual DirectoryとOracle Directory Services Managerの構成の詳細は、第8.7項「コロケート・アーキテクチャの高可用性」を参照してください。
高可用性環境では、Oracle Virtual Directoryをクラスタ・デプロイメント内に設定することをお薦めします。クラスタ化されたOracle Virtual Directoryインスタンスは、同じOracle RACデータベース・リポジトリ、またはLDAPリポジトリにアクセスします。
この項では、Oracle WebLogic Serverドメインを使用せずにOracle Virtual Directoryをデプロイする手順について説明します。
|
注意: Oracle Identity Management 11gインストーラで、「ドメインなしで構成」オプションを使用してOracle Virtual Directoryをホストにインストールすると、インストーラによってデフォルトでは 「ドメインなしで構成」でのインストール時に、インストーラでは、コンポーネント名 第8.4.3.1.1項「OVDHOST1でのOracle Virtual Directoryの構成」および第8.4.3.1.2項「OVDHOST2でのOracle Virtual Directoryの構成」でOVDHOST1およびOVDHOST2にインストールするOracle Virtual Directoryインスタンスは、「ドメインなしで構成」インストール・オプションを使用してインストールします。 |
次の手順に従ってOVDHOST1上のOracle Virtual Directoryインスタンスを構成します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOVDHOST1にインストールされ、アップグレードされていることを確認します。
使用しているオペレーティング・システムに対して次のコマンドを発行して、ポート6501と7501がコンピュータ上の他のサービスに使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":6501" netstat -an | grep LISTEN | grep ":7501"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr ":6501" netstat -an | findstr "LISTEN" | findstr ":7501"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
/etc/servicesファイルでポート6501と7501のエントリを削除して、サービスまたはコンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Virtual Directoryのポート番号を指定する行は非コメント化)を割り当てます。
# The Non-SSL LDAP port for OVD Oracle Virtual Directory (Non-SSL) Port No for LDAP= 6501 # The SSL LDAP Port for OVD Oracle Virtual Directory (SSL) Port No for LDAP = 7501
次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、「ドメインなしで構成」を選択して「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。
Oracleホーム・ディレクトリ:
/u01/app/oracle/product/fmw/idm_1
Oracleインスタンスの場所:
/u01/app/oracle/admin/ora_inst1
Oracleインスタンス名:
ora_inst1
|
注意: OVDHOST1のOracleホームの場所を示すディレクトリ・ パスが、OVDHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OVDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。
この場合、OVDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。
|
「次へ」をクリックします。
「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle Virtual Directory」を選択し、「次へ」を選択します。
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。
「仮想ディレクトリの指定」画面で、次の値を指定します。
「クライアント・リスナー」セクションで、次のように入力します。
LDAP v3名前空間: Oracle Virtual Directoryの名前空間を入力します。デフォルト値はdc=us,dc=mycompany,dc=comです。
dc=us,dc=mycompany,dc=com
HTTP Webゲートウェイ: このオプションを選択して、Oracle Virtual DirectoryのHTTP Webゲートウェイを有効化します。
保護: HTTP Webゲートウェイを有効化し、SSLを使用して保護する場合はこのオプションを選択します。
「OVD管理者」セクションで、次のように入力します。
管理者ユーザー名: Oracle Virtual Directory管理者のユーザー名を入力します(例: cn=orcladmin)。
パスワード: Oracle Virtual Directory管理者のパスワードを入力します(例: *******)。
パスワードの確認: Oracle Virtual Directory管理者のパスワードを再度入力します(例: *******)。
管理サーバーを保護モードで構成: このオプションを選択し、SSLを使用してOracle Virtual Directory管理リスナーを保護します。このオプションはデフォルトで選択されます。このオプションを選択することをお薦めします。
「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
次の手順に従ってOVDHOST2上のOracle Virtual Directoryインスタンスを構成します。
|
注意: この項で説明する手順は、11g Oracle Identity Managementの高可用性構成でOracle Virtual Directoryをスケール・アウトするときにも使用できます。 |
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOVDHOST2にインストールされ、アップグレードされていることを確認します。
OVDHOST1では、 ポート6501と7501がOracle Virtual Directoryによって使用されています。OVDHOST2のOracle Virtual Directoryインスタンスにも同じポートを使用する必要があります。このため、ポート6501および7501がOVDHOST2上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":6501" netstat -an | grep LISTEN | grep ":7501"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr ":6501" netstat -an | findstr "LISTEN" | findstr ":7501"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
/etc/servicesファイルでポート6501と7501のエントリを削除して、サービスまたはコンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Virtual Directoryのポート番号を指定する行は非コメント化)を割り当てます。
# The Non-SSL LDAP port for OVD Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501 # The SSL LDAP Port for OVD Oracle Virtual Directory (SSL) Port No for LDAP = 7501
次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、「ドメインなしで構成」を選択して「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。
Oracleホーム・ディレクトリ:
/u01/app/oracle/product/fmw/idm_1
Oracleインスタンスの場所:
/u01/app/oracle/admin/ora_inst2
Oracleインスタンス名:
ora_inst2
|
注意: OVDHOST2のOracleホームの場所を示すディレクトリ・ パスが、OVDHOST1のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OVDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。
この場合、OVDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。
|
「次へ」をクリックします。
「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle Virtual Directory」を選択し、「次へ」を選択します。
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。
「仮想ディレクトリの指定」画面で、次の値を指定します。
「クライアント・リスナー」セクションで、次のように入力します。
LDAP v3名前空間: Oracle Virtual Directoryの名前空間を入力します。デフォルト値はdc=us,dc=mycompany,dc=comです。
dc=us,dc=mycompany,dc=com
HTTP Webゲートウェイ: このオプションを選択して、Oracle Virtual DirectoryのHTTP Webゲートウェイを有効化します。
保護: HTTP Webゲートウェイを有効化し、SSLを使用して保護する場合はこのオプションを選択します。
「OVD管理者」セクションで、次のように入力します。
管理者ユーザー名: Oracle Virtual Directory管理者のユーザー名を入力します(例: cn=orcladmin)。
パスワード: Oracle Virtual Directory管理者のパスワードを入力します(例: *******)。
パスワードの確認: Oracle Virtual Directory管理者のパスワードを再度入力します(例: *******)。
管理サーバーを保護モードで構成: このオプションを選択し、SSLを使用してOracle Virtual Directory管理リスナーを保護します。このオプションはデフォルトで選択されます。このオプションを選択することをお薦めします。
「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
Oracle Virtual Directoryコンポーネントの管理には、Oracle Enterprise Manager Fusion Middleware Controlを使用することをお薦めします。Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Virtual Directoryを管理する場合は、コンポーネントとそれを含むOracle Fusion MiddlewareインスタンスをOracle WebLogic Serverドメインに登録する必要があります。インストール時またはOracleインスタンスの作成時に、Oracle Fusion MiddlewareインスタンスをWebLogicドメインに登録できますが、必須事項ではありません。Oracle Fusion MiddlewareインスタンスがWebLogicドメインに事前に登録されていない場合は、opmnctl registerinstanceを使用して登録できます。
opmnctl registerinstanceコマンドを使用してOracle Virtual DirectoryインスタンスをOracle WebLogic Serverドメインに登録する前に、WebLogic Serverがインストールされていることを確認します。
続いて、次の形式でopmnctl registerinstanceコマンドを実行します(各インストールで変数ORACLE_HOMEとORACLE_INSTANCEを設定してからOracle Virtual Directoryインスタンスのホーム・ディレクトリでこのコマンドを実行してください)。
opmnctl registerinstance -adminHost WLSHostName -adminPort WLSPort -adminUsername adminUserName
例:
opmnctl registerinstance -adminHost idmhost1.example.com -adminPort 7001 -adminUsername weblogic Command requires login to weblogic admin server (idmhost1.example.com) Username: weblogic Password: *******
WebLogicドメインにおけるOracle Virtual Directoryコンポーネントの登録の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのOPMNCTLを使用したOracleインスタンスの登録に関する項を参照してください。
この項では、WebLogic Serverドメインの一部としてOracle Virtual Directoryの高可用性構成をデプロイする手順について説明します。
この構成では、1つ目のホストにOracle Virtual DirectoryとWebLogic Serverドメインが構成され、2つ目のホストにはOracle Virtual Directoryのみが構成されます。2つ目のホストのOracle Virtual Directoryインスタンスは、1つ目のホストで作成されたドメインに参加します。
次の手順に従ってOVDHOST1上のOracle Virtual Directoryインスタンスを構成します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOVDHOST1にインストールされ、アップグレードされていることを確認します。
ポート6501および7501がOVDHOST1上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":6501" netstat -an | grep LISTEN | grep ":7501"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr ":6501" netstat -an | findstr "LISTEN" | findstr ":7501"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
/etc/servicesファイルでポート6501と7501のエントリを削除して、サービスまたはコンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Virtual Directoryのポート番号を指定する行は非コメント化)を割り当てます。
# The Non-SSL LDAP port for OVD Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501 # The SSL LDAP port for OVD Oracle Virtual Directory (SSL) Port No for LDAP = 7501
次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、新規ドメインの作成を選択して、次の値を指定します。
ユーザー名: weblogic
パスワード: <weblogicユーザーのパスワード>
パスワードの確認: <weblogicユーザーのパスワードを再度入力します>
ドメイン名: IDMDomain
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所:
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ: idm
WebLogic Serverのディレクトリ:
/u01/app/oracle/product/fmw/wlserver_10.3
Oracleインスタンスの場所:
/u01/app/oracle/admin/ovd_inst1
Oracleインスタンス名:
ovd_inst1
|
注意: OVDHOST1のOracleホームの場所を示すディレクトリ・ パスが、OVDHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OVDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。
この場合、OVDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。
|
「次へ」をクリックします。
「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle Virtual Directory」を選択し、「次へ」を選択します。
|
注意: このインストールでは、Oracle Directory Services ManagerとFusion Middleware Controlの管理コンポーネントが自動的に選択されます。この選択は解除できません。 |
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。
「仮想ディレクトリの指定」画面で、次の値を指定します。
「クライアント・リスナー」セクションで、次のように入力します。
LDAP v3名前空間: Oracle Virtual Directoryの名前空間を入力します。デフォルト値はdc=us,dc=mycompany,dc=comです。
dc=us,dc=mycompany,dc=com
HTTP Webゲートウェイ: このオプションを選択して、Oracle Virtual DirectoryのHTTP Webゲートウェイを有効化します。
保護: HTTP Webゲートウェイを有効化し、SSLを使用して保護する場合はこのオプションを選択します。
「OVD管理者」セクションで、次のように入力します。
管理者ユーザー名: Oracle Virtual Directory管理者のユーザー名を入力します(例: cn=orcladmin)。
パスワード: Oracle Virtual Directory管理者のパスワードを入力します(例: *******)。
パスワードの確認: Oracle Virtual Directory管理者のパスワードを再度入力します(例: *******)。
管理サーバーを保護モードで構成: このオプションを選択し、SSLを使用してOracle Virtual Directory管理リスナーを保護します。このオプションはデフォルトで選択されます。このオプションを選択することをお薦めします。
「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
この項では、OVDHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法を説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。
次の手順に従って、boot.propertiesファイルを作成します。
OVDHOST1で、次のディレクトリに移動します。
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
例:
cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security
テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUserpassword=adminUserPassword
|
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。 |
管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OVDHOST1上の管理サーバーを起動します。
Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
WebLogic Server管理コンソール:
http://oidhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oidhost1.example.com:7001/em
weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。
次の手順に従ってOVDHOST2上のOracle Virtual Directoryインスタンスを構成します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOVDHOST2にインストールされ、アップグレードされていることを確認します。
OVDHOST1では、 ポート6501と7501がOracle Virtual Directoryによって使用されています。OVDHOST2のOracle Virtual Directoryインスタンスにも同じポートを使用する必要があります。このため、ポート6501および7501がOVDHOST2上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":6501" netstat -an | grep LISTEN | grep ":7501"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr ":6501" netstat -an | findstr "LISTEN" | findstr ":7501"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
/etc/servicesファイルでポート6501と7501のエントリを削除して、サービスまたはコンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Virtual Directoryのポート番号を指定する行は非コメント化)を割り当てます。
# The Non-SSL LDAP port for OVD Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501 # The SSL LDAP port for OVD Oracle Virtual Directory (SSL) Port No for LDAP = 7501
次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、既存ドメインの拡張を選択して、次の値を指定します。
ホスト名: ovdhost1.example.com (Oracle WebLogic管理サーバーを実行しているホスト)
ポート: 7001(これは管理サーバーのポートです。)
ユーザー名: weblogic
パスワード: <weblogicユーザーのパスワード>
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所:
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ: idm
WebLogic Serverのディレクトリ:
/u01/app/oracle/product/fmw/wlserver_10.3
Oracleインスタンスの場所:
/u01/app/oracle/admin/ovd_inst2
Oracleインスタンス名:
ovd_inst2
|
注意: OVDHOST1のOracleホームの場所を示すディレクトリ・パスが、OVDHOST2のOracleホームの場所を示すディレクトリ・パスと同じであることを確認してください。たとえば、OVDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。
この場合、OVDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。
|
「次へ」をクリックします。
「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle Virtual Directory」を選択し、「次へ」を選択します。
|
注意: このインストールでは、Oracle Directory Services ManagerとFusion Middleware Controlの管理コンポーネントが自動的に選択されます。 |
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。
「仮想ディレクトリの指定」画面で、次の値を指定します。
「クライアント・リスナー」セクションで、次のように入力します。
LDAP v3名前空間: Oracle Virtual Directoryの名前空間を入力します。デフォルト値はdc=us,dc=mycompany,dc=comです。
dc=us,dc=mycompany,dc=com
HTTP Webゲートウェイ: このオプションを選択して、Oracle Virtual DirectoryのHTTP Webゲートウェイを有効化します。
保護: HTTP Webゲートウェイを有効化し、SSLを使用して保護する場合はこのオプションを選択します。
「OVD管理者」セクションで、次のように入力します。
管理者ユーザー名: Oracle Virtual Directory管理者のユーザー名を入力します(例: cn=orcladmin)。
パスワード: Oracle Virtual Directory管理者のパスワードを入力します(例: *******)。
パスワードの確認: Oracle Virtual Directory管理者のパスワードを再度入力します(例: *******)。
管理サーバーを保護モードで構成: このオプションを選択し、SSLを使用してOracle Virtual Directory管理リスナーを保護します。このオプションはデフォルトで選択されます。このオプションを選択することをお薦めします。
「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
Oracle Virtual Directoryは、Oracle RACデータベース・リポジトリまたは可用性の高いLDAPリポジトリをデータ・ソースとして使用するように構成できます。
この項では、Oracle RACデータベース・リポジトリおよびLDAPリポジトリを使用した高可用性環境にOracle Virtual Directoryを構成する方法を説明します。
|
注意: Oracle Virtual Directoryを高可用性トポロジで構成する場合は、すべてのノードで個別に構成手順を完了する必要があります。 |
リポジトリとしてOracle RACデータベースを使用するOracle Virtual Directory高可用性環境では、Oracle Virtual Directoryデータベース・アダプタを作成して構成する必要があります。
Oracle Virtual Directoryアダプタの概要は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのOracle Virtual Directoryアダプタの理解に関する項を参照してください。
Oracle RACデータベースのデータベース・アダプタの作成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのRACデータベースのデータベース・アダプタの作成に関する項を参照してください。
データベース・アダプタの構成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのデータベース・アダプタの構成に関する項を参照してください。
Oracle Virtual Directoryは、LDAPアダプタを介してOracle Internet DirectoryなどのLDAPリポジトリに接続します。高可用性環境では、ロード・バランシング・アルゴリズムを使用してノードのホストおよびポート情報を追加するか、LDAPリポジトリのロード・バランサのURLを追加することでLDAPアダプタを構成できます。
Oracle Virtual Directoryアダプタの概要は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのOracle Virtual Directoryアダプタの理解に関する項を参照してください。
LDAPアダプタの作成と構成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのLDAPアダプタの構成に関する項を参照してください。
可用性の高いデプロイメントでは、Oracle Virtual Directoryインスタンスは、ハードウェア・ロード・バランサによりフロントエンド処理されます。Oracle Virtual Directoryインスタンス間でリクエストのロード・バランシングが行われ、障害(インスタンス障害またはホスト障害)が発生した場合、ハードウェアのロード・バランサによって障害が検出され、障害が発生していないインスタンスにすべてのリクエストがルーティングされます。
Oracle Virtual Directoryの高可用性をテストするには、ノードを1つずつ停止し、ldapbindなどのツールを使用してロード・バランサのURLを経由しOracle Virtual Directoryインスタンスに接続します。ノードの1つが稼働しトポロジの構成が正しければ、接続は常に成功します。
ldapbindコマンドライン・ツールを使用し、ロード・バランサの仮想ホストを介してOracle Virtual Directoryインスタンスに接続します。ldapbindツールでは、サーバーに対してクライアントを認証できるかどうかを確認できます。
次の手順に従って、OVDHOST1およびOVDHOST2のOracle Virtual Directoryの高可用性設定を検証します。
Oracle Fusion Middleware Oracle Identity Managementリファレンスの環境の構成に関する項の手順に従って環境を構成します。この項には、ldapbindコマンドを使用する前に設定する必要がある環境変数の一覧があります。
OVDHOST1で、opmnctlコマンドを使用して、Oracle Virtual Directoryインスタンスを停止します。
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
OVDHOST2で、ldapbindを使用してロード・バランシング仮想アドレスにバインドし、Oracle Virtual Directoryのステータスをチェックします。
非SSL:
ldapbind -h ovd.example.com -p 6501 -D "cn=orcladmin" -q
|
注意: 前述の-qオプションを指定すると、ユーザーのパスワードの入力が求められます。LDAPツールでは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定されている場合、-w passwordおよび-P passwordの各オプションが無効になるよう変更されています。可能なかぎり、この機能を使用してください。 |
正常にバインドされると、ロード・バランサによってすべてのトラフィックがOVDHOST2にルーティングされます。
OVDHOST1で、opmnctlコマンドを使用して、Oracle Virtual Directoryインスタンスを起動します。
ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running) ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1
OVDHOST2で、opmnctlコマンドを使用してOracle Virtual Directoryインスタンスを停止します。
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
OVDHOST1で、ldapbindを使用してロード・バランシング仮想アドレスにバインドし、Oracle Virtual Directoryのステータスをチェックします。
非SSL:
ldapbind -h ovd.example.com -p 6501 -D "cn=orcladmin" -q
OVDHOST2で、opmnctlコマンドを使用してOracle Virtual Directoryインスタンスを起動します。
ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running) ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1
ldapbindコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Managementリファレンスのldapbindに関する項を参照してください。
Oracle Virtual Directoryは、デフォルトではサーバーのみのSSL認証モードを使用するように構成されます。ldapbindなどのコマンドライン・ツールを使用して、SSLサーバー認証モードで保護された接続を使用する接続を検証する場合は、Oracleウォレットにサーバー証明書が格納されている必要があります。次の手順に従って、このタスクを実行します。
次のコマンドを実行して、Oracleウォレットを作成します。
ORACLE_HOME/bin/orapki wallet create -wallet DIRECTORY_FOR_SSL_WALLET -pwd WALLET_PASSWORD
次のコマンドを実行して、Oracle Virtual Directoryサーバー証明書をエクスポートします。
ORACLE_HOME/jdk/jre/bin/keytool -exportcert -keystore OVD_KEYSTORE_FILE -storepass PASSWORD -alias OVD_SERVER_CERT_ALIAS -rfc -file OVD_SERVER_CERT_FILE
次のコマンドを実行して、Oracle Virtual Directoryサーバー証明書をOracleウォレットに追加します。
ORACLE_HOME/bin/orapki wallet add -wallet DIRECTORY_FOR_SSL_WALLET -trusted_cert -cert OVD_SERVER_CERT_FILE -pwd WALLET_PASSWORD
第8.4.4項「Oracle Virtual Directoryの高可用性の検証」の手順に従って次のldapbindコマンドを使用し、OVDHOST1およびOVDHOST2のOracle Virtual Directoryの高可用性設定を検証します。次のコマンドの実行中に、手順3からOracleウォレットを使用します。
ORACLE_HOME/bin/ldapbind -D cn=orcladmin -q -U 2 -h HOST -p SSL_PORT -W "file://DIRECTORY_FOR_SSL_WALLET" -q
Oracle Virtual Directoryの高可用性デプロイメントがロード・バランサによってフロントエンド処理される場合は、すべてのOracle Virtual Directoryノードのウォレットに、トポロジの構成要素であるすべてのOracle Virtual Directoryインスタンスのクライアント証明書が格納されている必要があります。トポロジ内のすべてのOracle Virtual Directoryインスタンスのクライアント証明書をトポロジ内の全ノードのウォレットに追加します。これによって、ロード・バランサのURLを経由する有効な接続リクエストが正常に処理されることが保証されます。
|
注意: 11g リリース1 (11.1.1)のインストール後にデフォルトの設定を使用している場合は、この項に記載された変数に次の値を使用できます。
|
この項では、Oracle Virtual DirectoryのフェイルオーバーとOracle RACのフェイルオーバーを実行する手順を説明します。
この項の内容は次のとおりです。
第8.5.1項「Oracle Directory Integration Platformコンポーネント・アーキテクチャ」
第8.5.3項「Oracle Directory Integration PlatformおよびOracle Directory Services Managerの高可用性の構成手順」
第8.5.4項「Oracle Directory Integration Platformのフェイルオーバーおよび予想される動作」
第8.5.5項「Oracle Directory Integration Platformの高可用性のトラブルシューティング」
次の手順に従って、Oracle Virtual Directoryインスタンスのフェイルオーバーを実行し、Oracle Virtual Directoryのステータスを調べます。
opmnctlコマンドを使用して、Oracle Virtual Directoryインスタンスを停止します。
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
opmnctlコマンドを使用して、Oracle Virtual Directoryインスタンスを起動します。
ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running) ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1
Oracle Virtual Directoryのステータスを確認します。
ORACLE_INSTANCE/bin/opmnctl status ias-component=ovd1
次の手順に従って、Oracle RACのフェイルオーバーを実行します。
srvctlコマンドを使用して、データベース・インスタンスを停止します。
srvctl stop instance -d db_unique_name -i inst_name_list
srvctlコマンドを使用して、データベース・インスタンスのステータスを確認します。
srvctl status database -d db_unique_name -v
Oracle Virtual Directoryのステータスを確認します。
ORACLE_INSTANCE/bin/opmnctl status ias-component=ovd1
srvctlコマンドを使用して、データベース・インスタンスを起動します。
srvctl start instance -d db_unique_name -i inst_name_list
|
注意: Oracle RACデータベースに対するデータベース・アダプタを使用してOracle Virtual Directoryを構成している場合は、Oracle RACフェイルオーバー後の最初の検索に失敗します。ただし、その後の検索リクエストは問題なく正常に行われます。 |
Oracle Virtual Directoryのログ・ファイルの情報は、Oracle Virtual Directoryに関する問題のトラブルシューティングに役立ちます。Oracle Virtual Directoryのログ・ファイルは、次のディレクトリにあります。
ORACLE_INSTANCE/diagnostics/log/OVD/<OVDComponentName>
トラブルシューティングの際に調査するログ・ファイルの順序は次のとおりです。
diagnostic.log: 診断メッセージが記録されます。
http-errors.log: HTTPエラーが記録されます。
access.log: Oracle Virtual Directoryインスタンスにアクセスするプロセスとクライアントに関する情報が記録されます。
LDAPアダプタを作成するときは、アダプタ作成ウィザードの「接続」ページでLDAPサーバーのホスト名とポート番号を指定します。LDAPサーバーが「SSLサーバー認証のみ」モードまたは「相互認証」モードでリスニングしている場合、ODSMによってサーバー証明書がOracle Virtual Directoryのトラスト・ストアにインポートされます。ただし、複数のLDAPサーバーのフロントエンドに使用されるロード・バランサの名前を指定した場合、そのLDAPサーバーの証明書の1つのみがインポートされます。これにより、Oracle Virtual Directoryサーバーのリクエストが、証明書に信頼性がないLDAPサーバーにルーティングされる場合に問題が発生します。
この問題を回避するには、LDAPアダプタの作成中に、ロード・バランサ・ホストとポートの詳細を指定するだけでなく、ロード・バランサがフロント・エンドとして使用されるLDAPサーバーのホストとポートの詳細を指定し、すべてのLDAPサーバーの証明書がインポートされるようにします。アダプタを作成した後、アダプタ設定を編集し、物理LDAPサーバーのホストとポートの詳細を削除する、つまりそれらの重みを0(ゼロ)に設定することができます。
この項では、Oracle Directory Integration Platformの概要、およびOracle Directory Integration PlatformとOracle Directory Services Managerの高可用性環境の設計とデプロイについて説明します。
Oracle Directory Services Managerの詳細は、第8.6項「Oracle Directory Services Managerの高可用性」を参照してください。
この項の内容は次のとおりです。
第8.5.1項「Oracle Directory Integration Platformコンポーネント・アーキテクチャ」
第8.5.3項「Oracle Directory Integration PlatformおよびOracle Directory Services Managerの高可用性の構成手順」
第8.5.4項「Oracle Directory Integration Platformのフェイルオーバーおよび予想される動作」
第8.5.5項「Oracle Directory Integration Platformの高可用性のトラブルシューティング」
Oracle Directory Integration Platformは、アプリケーションやディレクトリ(サード・パーティのLDAPディレクトリなど)とOracle Internet Directoryとの統合を可能にするJ2EEアプリケーションです。
Oracle Directory Integration Platformには、他のエンタープライズ・リポジトリとの同期ソリューションのデプロイを可能とするサービスとインタフェースが含まれています。Oracle Internet Directoryとサード・パーティのメタディレクトリ・ソリューションとの相互運用性を実現するためにも使用できます。
Oracle Directory Integration Platformには、必要な統合のタイプに応じた次の2つのサービスがあります。
Oracle Directory Integration Platform Synchronization Serviceによる同期化では、中央のOracle Internet Directoryを使用して接続ディレクトリの整合性が保持されます。
Oracle Directory Integration Platform Provisioning Serviceによる通知では、ターゲット・アプリケーションに定期的に通知が送信され、ユーザーのステータスや情報に対する変更が反映されます。
|
注意: この章の以降では、次の用語を使用します。
|
図8-6は、Oracle Directory Integration Platformのアーキテクチャを示しています。
図8-6 Oracle Directory Integration Platformのアーキテクチャ
図8-6は、Oracle Directory Integration Platformの様々なコンポーネントを示しています。Oracle Internet Directoryは、Oracle Directory Integration Platformの同期化Enterprise JavaBeans (EJB)とクォーツ・スケジューラを使用して接続ディレクトリと同期化されます。
同様に、Oracle Internet Directoryでの変更は、Oracle Directory Integration PlatformのプロビジョニングEnterprise JavaBeans (EJB)とクォーツ・スケジューラを使用して各種アプリケーションに送信されます。
Oracle Directory Integration Platformは、アプリケーションやディレクトリ(サード・パーティのLDAPディレクトリなど)とOracle Internet Directoryとの統合を可能にするJ2EEアプリケーションです。
Oracle Directory Integration Serverは、次で説明するように、同期化サービスによって各同期化サービスを、プロビジョニング・サービスによって各統合サービスを提供します。
同期化サービスには、次の機能があります。
スケジュール: 事前定義済スケジュールに基づいた同期化プロファイルを処理します。
マッピング: 接続ディレクトリとOracle Internet Directory間のデータ交換のルールを実行します。
データの伝播: コネクタを使用して接続ディレクトリとデータを交換します。
エラーを処理します。
プロビジョニング・サービスには、次の機能があります。
データの伝播: コネクタを使用して接続ディレクトリとデータを交換します。
イベント通知: Oracle Internet Directoryに格納されたユーザーまたはグループ・データに関連する変更をアプリケーションに通知します。
エラーを処理します。
Oracle Directory Integration Platformは、Oracle WebLogic Serverにデプロイされます。デフォルトでは、Oracle Directory Integration Platformは、Oracle Identity Managementソフトウェア・スタックの一部としてインストールされますが、アーキテクチャの要件に応じて、スタンドアロン・アプリケーションとしてインストールすることもできます。
Oracle Directory Integration Serverには、次の機能があります。
同期化Enterprise JavaBeans (EJB)とクォーツ・スケジューラを使用した同期化サービス。同期化EJBは本質的にステートレスです。
クォーツ・スケジューラは、同期化EJBを起動し、すべての接続ディレクトリに対して該当する変更を同期します。
同期化サービスは、接続ディレクトリで必要とされるインタフェースとフォーマットを使用してこれらの変更を提供します。Oracle Directory Integration Platformコネクタを介した同期化では、Oracle Internet Directoryクライアントが必要とするすべての情報に対してOracle Internet Directoryが最新の状態に維持されることが保証されます。
プロビジョニング・サービスでは、プロビジョニングEnterprise JavaBeans (EJB)とクォーツ・スケジューラが使用されます。プロビジョニングEJBは本質的にステートレスです。
クォーツ・スケジューラは、プロビジョニングEJBを起動し、プロビジョニングされた各アプリケーションに変更を通知します。
UpdateJob EJBは、Oracle Internet Directory変更ログに対して同期またはプロビジョニング・プロファイルの変更のポーリングを定期的に行います。プロファイルの変更が検出されると、それに応じてクォーツ・スケジューラ・ジョブが更新されます。
Oracle Directory Integration Platformは、外部管理アプリケーションとしてOracle WebLogic Serverにデプロイされます。Oracle Directory Integration Platformアプリケーションはデフォルトで、起動、停止、監視および他のライフサイクル・イベントに、基礎となるWebLogic Serverインフラストラクチャを使用します。WebLogicノード・マネージャは、サーバー・プロセスを監視し、障害発生時にそのプロセスを再起動するように構成できます。
Oracle Directory Integration Platformは、デプロイされた管理対象サーバーの起動時に初期化されます。Oracle Directory Integration Platformアプリケーションが起動すると、初期化コードによって既存のディレクトリ統合プロファイルにジョブの初期セットが作成され、UpdateJobBean EJBが起動されます。
UpdateJobBeanは、クォーツ・スケジューラに送信されたジョブを更新します。
クォーツ・スケジューラはジョブに応じて、プロビジョニングEJBまたは同期化EJBを起動します。プロビジョニングEJBが起動された場合は、プロビジョニング対象の各アプリケーションに対してOracle Internet Directoryの変更が通知されます。同期化EJBが起動された場合は、すべての接続ディレクトリに対して該当する変更が同期化されます。
起動および停止
Oracle Directory Integration Platformのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理します。
Oracle WebLogic Scripting Tool (WLST)
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Server管理コンソール
Oracle WebLogicノード・マネージャ
Oracle Directory Integration Platformは、外部リクエストを処理しません。この主要機能は、作成されたプロファイルに基づいて、同期化とプロビジョニングをサポートすることです。
この項では、同期化およびプロビジョニングの際の情報フローについて説明します。
Oracle Directory Integration Platform Synchronization Serviceフロー
Oracle Directory Integration Platformは、ディレクトリ同期プロファイルに従ってOracle Internet Directoryと接続ディレクトリ間の変更を同期します。
変更が行われた場所に応じて、次のような同期化が発生します。
接続ディレクトリからOracle Internet Directoryへの同期化
Oracle Internet Directoryから接続ディレクトリへの同期化
双方向での同期化
Oracle Internet Directoryから接続されたディレクトリへの同期化
Oracle Internet Directoryでは、ディレクトリ・オブジェクトに対する増分変更が保存される変更ログが管理されます。これには、変更ログ番号に基づいて連続的に変更が保存されます。
Oracle Internet Directoryから接続ディレクトリへの同期では、この変更ログが利用されます。このため、Oracle Directory Integration Platformの実行時には、変更ロギングが有効化されているデフォルト設定を使用してOracle Internet Directoryを起動する必要があります。
Oracle Directory Integration Platform Synchronization Serviceが同期プロファイルを処理するたびに、次の処理が行われます。
すべての変更が適用された最新の変更ログ番号が取得されます。
この番号より新しい変更ログ・エントリがそれぞれチェックされます。
プロファイルのフィルタリング・ルールを使用して、接続ディレクトリとの同期対象の変更が選択されます。
エントリにマッピング・ルールが適用され、接続ディレクトリで対応する変更が実行されます。
該当するエントリまたは属性がその接続ディレクトリで更新されます。接続ディレクトリで、DB、LDAP、タグ付き、またはLDIFの各形式が直接使用されていない場合は、プロファイルに指定されているエージェントが起動されます。正常に使用された最後の変更番号がプロファイルに保存されます。
Oracle Internet Directoryは、すべてのプロファイルが必要な変更ログを使用した後、変更ログをパージして、後続の同期の開始位置を示します。
接続されたディレクトリからOracle Internet Directoryへの同期化
接続ディレクトリで、DB、LDAP、タグ付き、またはLDIFの各形式が直接使用されている場合、そのエントリまたは属性に対する変更は、Oracle Directory Integration Platform Synchronization Serviceによって自動的に同期化されます。それ以外の場合、コネクタは同期プロファイルにエージェントを持ち、エージェントがLDIFまたはタグ付き形式でファイルへの変更を書き込みます。次に、Oracle Directory Integration Platform Synchronization Serviceは、この接続ディレクトリ・データのファイルを使用して、Oracle Internet Directoryを更新します。
プロビジョニング・フロー
プロビジョニングとは、ユーザー、グループおよび他のオブジェクトに対し、環境内で利用可能なアプリケーションや他のリソースへのアクセスを提供するプロセスです。プロビジョニング統合アプリケーションとは、プロビジョニング・イベント用に、Oracle Internet Directoryにプロビジョニング統合プロファイルが登録されているアプリケーションです。
Oracle Directory Integration Platform Provisioningでは、次の方法のいずれかを使用してアプリケーションをプロビジョニングできます。
同期プロビジョニング
非同期プロビジョニング
プロビジョニングのデータ・フロー
それぞれのプロビジョニング方法については、後続の各項で説明します。
同期プロビジョニング
Oracle Internet Directoryでユーザー情報を管理するアプリケーションでは、データ・アクセスJavaプラグインを使用して、Oracle Internet Directoryに変更が発生するたびにユーザー・エントリを作成、変更および削除でき、同期的にプロビジョニングされます。これは、Oracle Identity Management(プロビジョニング・コンソールやコマンドラインLDAPツールなど)からデータ・アクセスJavaプラグインを直接起動できるためです。
Oracle Directory Integration Platform Provisioning Serviceの同期プロビジョニングは、Oracle Identity Managementツール(Oracle Fusion Middleware Controlのプロビジョニング・コンソールやbulkprovなど)、サード・パーティ・ディレクトリ、またはコマンドラインLDAPツールから起動できます。
Oracle Identity Managementツール(Oracle Fusion Middleware Controlのプロビジョニング・コンソール画面やprovProfileBulkProvコマンドによるバルク・プロビジョニングなど)、およびサード・パーティ・ディレクトリを使用したOracle Directory Integration Platform Provisioning Serviceの同期プロビジョニングは、次のプロセスに従います。
Oracle Internet Directoryに新規ユーザー・エントリが作成されます。
新規ユーザー・エントリを作成したOracle Identity Managementコンポーネントは、データ・アクセスJavaプラグインを起動します。
データ・アクセスJavaプラグインは、アプリケーションにこの新規ユーザー・アカウントをプロビジョニングします。
コマンドラインLDAPツールを使用した同期プロビジョニングは、次のプロセスに従います。
コマンドラインLDAPツールによって、Oracle Internet Directoryに新規ユーザー・エントリが作成されます。
次にスケジュールされた同期間隔で、Oracle Directory Integration Platformは、プロビジョニングの必要な新規ユーザー・エントリがOracle Internet Directoryに存在することを確認します。
Oracle Directory Integration Platformは、データ・アクセスJavaプラグインを起動します。
データ・アクセスJavaプラグインは、アプリケーションに新規ユーザー・アカウントをプロビジョニングします。
非同期プロビジョニング
非同期プロビジョニングでは、プロビジョニングは、任意のOracle Identity ManagementのコンポーネントではなくPL/SQLプラグインによって処理されます。
Oracle Directory Integration Platformは、PL/SQLイベントをプロビジョニング統合アプリケーションに伝播し、次に、このアプリケーションがイベントを処理するためにPL/SQLプラグインを実行します。PL/SQLプラグインの実行は、アプリケーション・リポジトリ内で発生し、任意のOracle Identity Managementコンポーネントのアドレス空間では発生しません。プロビジョニングは、任意のOracle Identity ManagementのコンポーネントではなくPL/SQLプラグインによって処理されるため、PL/SQLプラグインを実装するプロビジョニング統合アプリケーションは、非同期的にプロビジョニングされます。
Oracle Directory Integration Platform Provisioning Serviceを使用した非同期プロビジョニングは、Oracle Identity Managementツール(プロビジョニング・コンソールやbulkprovなど)、サード・パーティ・ディレクトリとの同期化、またはコマンドラインLDAPツールから起動できます。
Oracle Identity Managementツール(プロビジョニング・コンソール、provProfileBulkProvコマンドによるバルク・プロビジョニングなど)、およびサード・パーティ・ディレクトリからの非同期プロビジョニングは、次のプロセスに従います。
Oracle Internet Directoryに新規ユーザー・エントリとアプリケーション固有のユーザー・プリファレンスを含む関連エントリが作成されます。
次にスケジュールされた同期間隔で、Oracle Directory Integration Platformは、プロビジョニングの必要な新規ユーザー・エントリがOracle Internet Directoryに存在することを確認します。
Oracle Directory Integration PlatformからPL/SQLプラグインにプロビジョニング・イベントが送信されます。
コマンドラインLDAPツールを使用した非同期プロビジョニングは、次のプロセスに従います。
コマンドラインLDAPツールを使用して、Oracle Internet Directoryに新規ユーザー・エントリが作成されます。
次に、Oracle Directory Integration Platformはスケジュールされた同期間隔で、プロビジョニングの必要な新規ユーザー・エントリがOracle Internet Directoryに存在するか確認し、アプリケーション固有のユーザー・プリファレンスを含む関連エントリを作成します。
Oracle Directory Integration PlatformからPL/SQLプラグインにプロビジョニング・イベントが送信されます。
プロビジョニングのデータ・フロー
プロビジョニングが同期か非同期かにかかわらず、アプリケーションでは、プロビジョニング・インテリジェント機能を拡張してビジネス・ポリシーを実装するために、プレデータ・エントリ・プラグインとポストデータ・エントリ・プラグインを起動できます。どちらのプラグインも、Oracle Internet Directoryプロビジョニング・コンソールなどのOracle Identity ManagementコンポーネントやprovProfileBulkProvコマンドによるバルク・プロビジョニングから起動できます。
プレデータ・エントリ・プラグインは、プロビジョニング・ポリシーに基づいてフィールドを移入します。このプラグインの主な目的は、アプリケーションでユーザーをプロビジョニングするかどうかを決定することです。たとえば、財務管理アプリケーションにはマネージャのみをプロビジョニングするというポリシーを持つ組織の場合、プレデータ・エントリ・プラグインを使用することで、どのユーザー・エントリをプロビジョニングするかを特定できます。共通のユーザー属性は、このプラグインの起動時にすでに移入が行われているため、プロビジョニングの決定を行うための十分な情報がすでに存在していることになります。
ポストデータ・エントリ・プラグインは、主に、ユーザーによって入力された共通属性とアプリケーション固有属性に関するデータを検証します。プロビジョニングを続けるためには、このプラグインでの検証に成功する必要があります。
プロビジョニングのデータ・フローは、次のプロセスに従います。
ベース・ユーザー情報が作成されます。
プレデータ・エントリ・プラグインが起動し、ポリシーに基づいてフィールドの移入が行われます。
ポストデータ・エントリ・プラグインが起動し、ユーザーが入力したデータが検証されます。
プロビジョニング方式に応じて、非同期または同期プロビジョニング・プロシージャが起動します。
プロビジョニング・コンソールでプロビジョニングを実行する場合、管理者は、プレデータ・エントリ・プラグインが起動した後、かつポストデータ・エントリ・プラグインが起動する前にアプリケーション属性を変更できます。
Oracle Directory Integration Platformに関する構成の詳細は、dip-config.xmlファイルで管理されます。この構成ファイルは、Oracle Directory Integration Platformアプリケーションの一部としてパッケージ化されています。dip-config.xmlファイルのデフォルトの場所は、次のとおりです。
MW_HOME/user_projects/domains/domainName/config/ fmwconfig/servers/serverName/applications/DIP_11.1.1.2.0/configuration
domainNameはドメインの名前で、serverNameは管理対象サーバーの名前です。
パラメータは、Config MBeansにより管理されます。表8-6は、Oracle Directory Integration Platformを起動するためにdip-config.xmlに必要な構成パラメータを示しています。
表8-6 Directory Integration Platformの起動に必要な構成パラメータ
| パラメータ | 説明 |
|---|---|
|
OIDホスト |
Oracle Directory Integration Platformが接続する必要のあるOracle Internet Directoryのホスト名。 |
|
OIDポート |
Oracle Internet Directoryのポート |
|
SSLモード |
Oracle Internet Directoryへの接続に使用されるSSLモード。有効な値は次のとおりです。
|
|
JKSの場所 |
Javaキーストア(JKS)を格納するファイル・システムの場所 |
|
クォーツ・スレッド |
プロセスをスケジュールするクォーツで使用できる最大スレッド数 |
Oracle Directory Integration Platformサーバーは、実行状態になると、同期化の処理および機能のプロビジョニングに関する詳細をOracle Internet Directoryから読み込みます。
同期プロファイルおよびプロビジョニング・プロファイル作成の詳細は、次を参照してください。
Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイドの同期プロファイルの作成に関する項。
Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイドのoidprovtoolを使用したプロビジョニング・プロファイルの管理に関する項。
Oracle Directory Integration Platformは、メタデータの格納にOracle Internet Directoryを使用します。クォーツ・スケジューラは、ODSSMスキーマを使用してデータベースにスケジュール情報を格納します。Oracle Internet DirectoryとOracle Directory Integration Platformは、同じデータベースを使用します。Oracle Directory Integration Platformに必要なODSSMスキーマは、Oracle Internet Directoryのスキーマ作成の一環として作成されます。
Oracle Directory Integration Platformは、Oracleが提供するセキュアなフレームワークであるOracle資格証明ストア・フレームワーク(CSF)、およびSSLを介したOracle Internet Directoryやサード・パーティのLDAPストアへの接続に使用されるウォレットと資格証明を保存するJavaキーストア(JKS)にも依存します。
Oracle Directory Integration Platformは、デフォルトでインストールされるOracle Fusion Middleware共通の監査フレームワークにも依存します。
Oracle Directory Integration Platformは、Oracle WebLogic Server上にデプロイされるJ2EEアプリケーションです。ログ・メッセージはすべて、アプリケーションがデプロイされるOracle WebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。
WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
この項では、Oracle Directory Integration Platformを高可用性構成で使用する場合の概要について説明します。
この項で説明するOracle Directory Integration Platformの高可用性構成では、2つのホスト上にOracle Directory Integration PlatformとOracle Directory Services Managerが、2ノードのアクティブ/アクティブの高可用性構成で、インストールおよび構成されています。
図8-7は、Oracle Directory Integration PlatformとOracle Directory Services Managerのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。
図8-7 高可用性アーキテクチャのOracle Directory Integration PlatformとOracle Directory Services Manager
図8-7では、アプリケーション層にコンピュータIDMHOST1とIDMHOST2があります。
IDMHOST1では、次のインストールが実行されています。
Oracle Directory Integration PlatformインスタンスとOracle Directory Services Managerインスタンスが、WLS_ODS1管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。
IDMHOST2では、次のインストールが実行されています。
Oracle Directory Integration PlatformインスタンスとOracle Directory Services Managerインスタンスが、WLS_ODS2管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
IDMHOST2上のWLS_ODS2管理対象サーバーにあるインスタンスと、IDMHOST1上のWLS_ODS1管理対象サーバーにあるインスタンスは、CLUSTER_ODSクラスタとして構成されています。
WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。IDMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
高可用性アーキテクチャでは、Oracle Directory Integration PlatformおよびOracle Directory Services ManagerはOracle WebLogicクラスタにデプロイされます。このクラスタには、その一部として少なくとも2つのサーバーが存在します。
WebLogic Serverはデフォルトで、アプリケーションの起動、停止および監視を行います。Oracle Directory Integration PlatformとOracle Directory Services Managerの各アプリケーションはともにデフォルトで、基盤となるWebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。ノード・マネージャがこのサーバーを再起動できない場合は、フロントエンドのロード・バランシング・ルーターによってクラスタ内のWebLogicインスタンスの障害が検出され、障害が発生していないインスタンスにトラフィックがルーティングされます。
Oracle Internet Directoryをアクティブ/アクティブの高可用性構成にデプロイする場合は、そのクラスタに属するすべてのOracle Internet Directoryインスタンスが同じデータベースを共有します。いずれかのOracle Internet DirectoryノードのOracle Directory Integration Platformに加えられた変更は、クラスタ内のすべてのOracle Internet Directoryインスタンスに自動的に伝播されます。
次の各項では、Oracle Internet Directoryマルチマスター・レプリケーション・デプロイメントにおけるOracle Directory Integration Platformアプリケーションの構成変更について説明します。マルチマスター・レプリケーションでは、次に説明するように、クラスタ内のすべてのノードに構成の変更を適用する必要があります。
ディレクトリ統合プロファイル
デフォルトのOracle Internet Directoryマルチマスター・レプリケーション環境では、任意のOracle Internet Directoryノード上のディレクトリ統合プロファイルへの変更は、他のOracle Internet Directoryノードへは自動的にレプリケートされません。これらのファイルは、1次ノードから2次ノードに対して定期的に手動でコピーする必要があります。これにより、1次ノードで問題が発生した場合、2次ノードでディレクトリ同期プロファイルを実行できます。
Oracle Directory Integration Platformで使用されるパラメータの1つにorcllastappliedchangenumberがあります。ディレクトリ同期プロファイルのlastchangenumber属性に指定した値は、Oracle Directory Integration Platformが実行されているディレクトリ・サーバーによって異なります。アクティブ/アクティブ構成のOracle Directory Integration Platformでは、すべてのインスタンスのlastchangenumber属性を手動で更新する必要があります。
次の項では、同期プロファイルとプロビジョニング・プロファイルをマルチマスター・レプリケーション・デプロイメントの1次Oracle Internet Directoryから2次Oracle Internet Directoryにコピーする手順の詳細について説明します。
ディレクトリ同期プロファイル
エクスポート・プロファイルをターゲット・ノードにコピーした後、lastchangenumber属性をターゲット・ノードの値で更新する必要があります。値を更新する手順は次のとおりです。
同期プロファイルを無効化します。
ldapsearchコマンドを使用して、ターゲット・ノードのlastchangenumber属性の値を取得します。
ldapsearchを使用して、プロファイル・エントリのLDIFダンプを取得します。
ldapaddを使用して、他のOracle Internet Directoryインスタンスにプロファイルを追加します。
manageSyncProfilesコマンドのupdatechgnum演算子を使用して、ターゲット・ノードにコピーしたエクスポート・プロファイルのlastchangenumber属性をステップ2で取得した値で更新します。
同期プロファイルを有効化します。
ディレクトリ・プロビジョニング・プロファイル
デフォルトのOracle Internet Directoryマルチマスター・レプリケーション環境では、Oracle Directory Integration Platformは1次Oracle Internet Directoryと同じ場所にインストールされます。この項の情報と手順は、マルチマスター・レプリケーションが設定されている場合にのみ適用できます。
1次ノードで障害が発生した場合、そのノードにあるすべてのプロファイルに対するイベント伝播は停止します。イベントはキューに入れられ、1次ノードの停止中にも失われることはありませんが、どのアプリケーションにもイベントは伝播されません。バージョン1.0および2.0のプロファイルで、1次ノードが停止した場合でもイベントの伝播が継続されることを保証するには、ディレクトリ・プロビジョニング・プロファイルを他の2次ノードにコピーする必要があります。
ただし、ディレクトリ・プロビジョニング・プロファイルは、アプリケーションがインストールされた直後からOracle Internet Directoryでユーザー変更が行われる前にしか、1次ノードから任意の2次ノードに対してコピーされません。
1次ノードと2次ノード間でディレクトリ・プロビジョニング・プロファイルを同期するには、次の手順を実行する必要があります。
1次ノードで、ldifwriteコマンドを使用してこのコンテナからエントリのLDIFダンプを作成します。
cn=provisioning profiles,cn=changelog subscriber,cn=oracle internet directory
LDIFダンプを2次ノードにコピーします。
ldapaddコマンドを使用して、2次ノードにプロファイルを追加します。
この項では、Oracle Directory Integration Platformのアクティブ/アクティブ・クラスタにおける様々な障害からの保護について説明します。
高可用性環境では、Oracle Directory Integration Platformアプリケーションは、少なくとも2つのWebLogicインスタンスで構成されるOracle WebLogic Serverクラスタにデプロイされます。
Oracle Directory Integration Platformアプリケーションはデフォルトで、基盤となるWebLogicクラスタの高可用性機能を利用します。Oracle Directory Integration Platformがデプロイされるときに、クォーツ・スケジューラはクラスタリング・オプションを使用して起動されます。クラスタリング・オプションを指定して起動されると、スケジューラはノードの負荷に応じて、クラスタ内の利用可能なノードのいずれかでジョブを実行します。1つ以上のノードでハードウェアなどの障害が発生すると、スケジューラは利用可能なノードでジョブを実行します。
さらに、高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。
Oracle Directory Integration Platformアプリケーション内では、クォーツ・スケジューラによって、実際の処理を行うプロビジョニングまたは同期化EJBが起動されます。クォーツ・スケジューラによってEJBが起動されるとただちに、そのEJBにはジョブ実行中のタグが付けられます。EJBがジョブに失敗した場合は、クォーツ・スケジューラはジョブに失敗のマークを付け、後で別のEJBで実行されるよう再スケジュールします。
Oracle Directory Integration Platformのフェイルオーバーは、エンド・ユーザーに対して透過的ではありません。
高可用性トポロジにデプロイされたOracle Directory Integration Platformインスタンスに対する構成の変更は、トポロジ内のすべてのOracle Directory Integration Platformインスタンスに自動的には伝播されません。
トポロジ内のすべてのOracle Directory Integration Platformインスタンスに同一の構成変更を行うには、manageDIPServerConfigツールの使用をお薦めします。これにより、トポロジ内のすべてのOracle Directory Integration Platformインスタンスの構成が同一になることが保証されます。
manageDIPServerConfigツールの詳細は、Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイドを参照してください。
この項では、Oracle Directory Integration Platformの高可用性アーキテクチャを設定するための前提条件について説明します。
|
注意: Oracle Directory Integration Platformは、クォーツを使用して、データベース内のジョブとスケジュールを管理します。クォーツ・ジョブをクラスタ内の複数のOracle Directory Integration Platformノードで実行するには、クラスタ・ノードのシステム・クロックを同期させる必要があります。 |
Oracle Internet Directoryのインストールと構成は、次の各項の説明に従います。
高可用性環境では、WebLogic Serverのユーティリティを使用してOracle Directory Integration PlatformインスタンスとOracle Directory Services Managerのクラスタ化、ロード・バランシングおよびフェイルオーバーを行うことをお薦めします。
この項では、IDMHOST1とIDMHOST2で次のインストールと構成を実行する手順について説明します。
第8.5.3.1項「IDMHOST1でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成」
第8.5.3.3項「IDMHOST2でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成」
第8.5.3.4項「Oracle Directory Integration PlatformとOracle Directory Services Managerのインストール後の手順」
第8.5.3.5項「WEBHOST1およびWEBHOST2へのOracle Fusion Middlewareコンポーネントのインストール」
Oracle Directory Integration PlatformおよびOracle Directory Services Managerは、同一インストール・セッション、同一管理対象サーバー、または同一ホストにインストールする必要はありません。この項のインストールと構成の手順は、Oracle Directory Integration PlatformとOracle Directory Services Managerを2ノードのアクティブ/アクティブ・クラスタにインストールする場合の一例です。
次の手順に従って、IDMHOST1上のOracle Directory Integration PlatformとOracle Directory Services Managerを構成します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがIDMHOST1にインストールされ、アップグレードされていることを確認します。
ポート7006がIDMHOST1上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":7006"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr ":7006"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
ポート7006のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Directory Services Managerのポート番号を指定する行は非コメント化)を割り当てます。
# The port for ODSM server port ODS Server Port No = 7006
次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、新規ドメインの作成を選択して、ドメインの詳細を入力します。
ユーザー名: weblogic
ユーザー・パスワード: ******
パスワードの確認: ******
ドメイン名: IDMDomain
「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。
Oracleホーム・ディレクトリ: この値は入力済になっており、変更できません。
ods
WebLogic Serverのディレクトリ:
/u01/app/oracle/product/fmw/wlserver_10.3
Oracleインスタンスの場所:
/u01/app/oracle/admin/ods_instance1
Oracleインスタンス名:
ods_instance1
「次へ」をクリックします。
「Oracle Configuration Managerの詳細の指定」画面で、次の値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、Oracle Directory Integration Platform、管理コンポーネント - Oracle Directory Services Managerを選択します。他のコンポーネントをすべて選択解除します。Oracle Internet Directoryを前提条件どおりに構成する必要があるという警告は無視します。
「クラスタ化」チェック・ボックスを選択します。
「次へ」をクリックします。
|
注意: インストーラによって設定されるデフォルトのOracle WebLogic Serverのクラスタ・モードは、(マルチキャストではなく)ユニキャストになります。 |
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。
「OID詳細の指定」画面で、次のように指定します。
ホスト名: oid.example.com
ポート: 636
ユーザー名: cn=orcladmin
パスワード: ******
「次へ」をクリックします。
「スキーマ・データベースの指定」画面で、既存のスキーマの使用を選択し、次の値を指定します。
接続文字列:
infradbhost1-vip.example.com:1521:oiddb1^infradbhost2-vip.example.com:1521:oiddb2@oid.example.com
|
注意: Oracle RACデータベースの接続文字列の情報は、host1:port1:instance1^host2:port2:instance2@servicenameの書式で指定する必要があります。 このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。 前述のように指定した情報は、完全で正確である必要があります。具体的には、ホスト、ポート、およびインスタンス名が各Oracle RACインスタンスに正しく指定されている必要があります。また、指定したOracle RACインスタンスのすべてにサービス名が構成されている必要があります。 Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。 |
ユーザー名: ODSSM
パスワード: ******
「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
この項では、IDMHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法を説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。
次の手順に従って、boot.propertiesファイルを作成します。
IDMHOST1で、次のディレクトリに移動します。
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
例:
cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security
テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUserpassword=adminUserPassword
|
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。 |
管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、IDMHOST1上の管理サーバーを起動します。
Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
WebLogic Server管理コンソール:
http://oidhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oidhost1.example.com:7001/em
weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。
IDMHOST2上のOracle Directory Integration PlatformとOracle Directory Services Managerを構成する手順は、次のとおりです。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがIDMHOST2にインストールされ、アップグレードされていることを確認します。
次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
「ドメインの選択」画面で、「クラスタを開く」オプションを選択して、次の例の値を指定します。
ホスト名: idmhost1.example.com
ポート: 7001
ユーザー名: weblogic
パスワード: <weblogicユーザーのパスワード>
「次へ」をクリックします。
|
注意: IDMHOST1上で、Oracle WebLogic管理サーバーが実行されています。 |
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所: 入力済になっており、変更できません。
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ: 入力済になっており、変更できません。
ods
WebLogic Serverのディレクトリ:
/u01/app/oracle/product/fmw/wlserver_10.3
Oracleインスタンスの場所:
/u01/app/oracle/admin/ods_instance2
Oracleインスタンス名:
ods_instance2
「次へ」をクリックします。
「コンポーネントの構成」画面で、Oracle DIPおよび管理コンポーネントを除く全製品の選択を解除します。
「次へ」をクリックします。
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリで編集したstaticports.iniファイルへのフルパス名を入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で、選択した内容を確認します。なんらかの変更が必要な場合は、「戻る」をクリックします。選択が適切であれば、「インストール」をクリックします。
「インストールの進行状況」画面で、インストールの進行状況を確認します。
UNIXシステムでは、インストールが終了すると、oracleRoot.shの確認ダイアログ・ボックスが開きます。これは、インストールを続行する前に構成スクリプトをrootとして実行する必要があることを説明しています。
確認ダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootとしてログインして、次のスクリプト・ファイルを実行します。
/u01/app/oracle/product/fmw/ods/oracleRoot.sh
「構成の進行状況」画面で、構成の進行状況を確認します。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
前の項では、インストーラによってIDMHOST2に2つ目の管理対象サーバーwls_ods2が作成されました。ただし、IDMHOST2上にOracle Directory Integration Platformアプリケーションがデプロイされていないため、新たに作成した管理対象サーバーは自動的に起動されません。また、WebLogic管理コンソールには、IDMHOST2上のwls_ods2管理対象サーバーの状態がUNKNOWNと表示されます。
この項にあるインストール後の手順を実行して、IDMHOST2上のOracle Directory Integration PlatformとOracle Directory Services Managerアプリケーションのインストールと構成を完了します。
IDMHOST1からIDMHOST2にOracle Directory Integration Platformアプリケーションを直接コピーする手順は、次のとおりです。
IDMHOST1にあるディレクトリMW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applicationsをIDMHOST2の場所MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ ods2にコピーします。
たとえば、IDMHOST1から次のコマンドを実行します。
scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applications/odsm user@IDMHOST2:/MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods2
クラスタ内のIDMHOST2上に新たに作成したwls_ods2管理対象サーバーを起動する手順は、次のとおりです。
このURLを使用して、Oracle WebLogic Server管理コンソールにアクセスします。
http://idmhost1.example.com:7001/console
管理者の資格証明を使用して、コンソールにログインします。
左側のペインで、「環境」を開き、「クラスタ」を選択します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
停止する管理対象サーバー(wls_ods2)が存在するクラスタ(cluster_ods)のリンクをクリックします。
「制御」を選択します。
「このクラスタの管理対象サーバーのインスタンス」で、起動する管理対象サーバー(wls_ods2)の横のチェック・ボックスを選択して「起動」をクリックします。
「クラスタ・ライフサイクル・アシスタント」ページで、「はい」をクリックして確定します。
ノード・マネージャによって、ターゲット・マシン上のサーバーが起動されます。ノード・マネージャによる起動シーケンスが終了すると、「サーバー状態」表の「状態」列にサーバーの状態が表示されます。この状態はRUNNINGになります。
この項では、Oracle HTTP Server用にOracleホーム(ORACLE_HOME)に必要なバイナリをインストールする方法について説明します。
設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。
この項では、Oracle HTTP Serverをインストールする方法について説明します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。
Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。
Oracle Web Tierコンポーネントのインストーラを起動します。
HOST1> ./runInstaller
その後、次のインストール手順を実行します。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
MW_HOME: MW_HOMEの値を入力します。例:
/u01/app/product/fmw
ドロップダウン・リストから、すでにインストールされているMiddlewareホームを選択します。Oracle HTTP Server Oracleホーム(OHS_ORACLE_HOME)ディレクトリには、ディレクトリ名WEBを入力します。
「次へ」をクリックします。
「サマリー」画面で「インストール」をクリックします。
「インストール完了」画面で「終了」をクリックします。
Oracle HTTP Serverソフトウェアを11.1.1.4(パッチ・セット3)にアップグレードする手順は、次のとおりです。
./runinstallerを実行して、Web Tierアップグレード・インストーラを起動します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、「次へ」をクリックします。
「インストール場所の指定」画面で、Oracle MiddlewareホームへのパスおよびOracle HTTP Server Oracleホーム・ディレクトリの名前を指定します。
「インストール・サマリー」画面で、選択内容を確認して「インストール」をクリックします。
「インストール完了」画面で「終了」をクリックして終了します。
この項では、Oracle HTTP ServerをWEBHOST1およびWEBHOST2で構成する方法について説明します。Oracle Directory Integration Platform以外にインストール済のコンポーネントがない場合は、Oracle HTTP Serverは必要ありません。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。
第8.5.3.5項「WEBHOST1およびWEBHOST2へのOracle Fusion Middlewareコンポーネントのインストール」の説明に従って、Oracle HTTP ServerソフトウェアがWEBHOST1およびWEBHOST2にインストールされ、アップグレードされていることを確認します。
ポート7777がWEBHOST1またはWEBHOST2上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":7777"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr ":7777"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle HTTP Serverのポート番号を指定する行は非コメント化)を割り当てます。
# The http_main port for ohs component OHS Port = 7777
次のようにして、ORACLE_HOME/binディレクトリの下にあるOracle Fusion Middleware 11g Web Tierユーティリティの構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」を選択します。
「次へ」をクリックします。
「WebLogicドメインの指定」画面で:
Oracle WebLogic Serverをインストールした場所を入力します。管理サーバーが実行されている必要があります。
ドメイン・ホスト名: IDMHOST1
ドメインのポート番号: 7001
ユーザー名: weblogic
パスワード: ******
「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、次の操作を行います。
WEBHOST1に次の値を入力します。
インスタンス・ホームの場所: /u01/app/oracle/admin/ohs_inst1
インスタンス名: ohs_inst1
OHSコンポーネント名: ohs1
WEBHOST2に次の値を入力します。
インスタンス・ホームの場所: /u01/app/oracle/admin/ohs_inst2
インスタンス名: ohs_inst2
OHSコンポーネント名: ohs2
「次へ」をクリックします。
「Web Tierポートの詳細の指定」画面で、次の操作を行います。
「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
Oracle HTTP Serverポートを入力します(例: 7777)。
「次へ」をクリックします。
「Oracle Configuration Manager」画面で、次のように入力します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
セキュリティ・アップデートをMy Oracle Support経由で受け取ります。: このチェック・ボックスを選択します。
「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「次へ」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。
「構成が完了しました」画面で「終了」をクリックして終了します。
この項の手順に従って、Oracle Directory Services ManagerのためのOracle HTTP Serverの高可用性を構成します。
Oracle HTTP Serverで、ロード・バランシング・ルーターの仮想ホストを使用するように構成します。
WEBHOST1およびWEBHOST2上のOracle HTTP Serverインスタンスは、ロード・バランサの仮想ホストの設定を使用するように構成する必要があります。仮想ホストの詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。
Oracle HTTP Serverインスタンスでロード・バランシング・ルーターの仮想ホストを使用するように構成するには、httpd.confファイルを編集して、仮想ホストのディレクティブを次のように定義します。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName admin.example.com:7777 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit </VirtualHost>
httpd.confファイルは、WEBHOST1およびWEBHOST2上のORACLE_INSTANCE/config/OHS/componentNameディレクトリにあります。
Oracle HTTP ServerからOracle Directory Services Manager、Oracle Enterprise Manager Fusion Middleware Control、およびOracle WebLogic Server管理コンソールにルーティングされるように構成します。
Oracle HTTP Serverインスタンスで、IDMHOST1とIDMHOST2のOracle Directory Services Managerアプリケーションへのルーティングを有効にするには、WEBHOST1とWEBHOST2のORACLE_INSTANCE/config/OHS/componentNameディレクトリにあるmod_wl_ohs.confファイルに次のディレクティブを追加します。
<Location /odsm> SetHandler weblogic-handler WebLogicCluster IDMHOST1.EXAMPLE.COM:<PORT>,IDMHOST2.EXAMPLE.COM:<PORT> WLProxySSL ON WLProxySSLPassThrough ON </Location> #AdminServer and EM <Location /console> SetHandler weblogic-handler WebLogicHost VIP1 WeblogicPort 7001 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /consolehelp> SetHandler weblogic-handler WebLogicHost VIP1 WeblogicPort 7001 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /em> SetHandler weblogic-handler WebLogicHost VIP1 WeblogicPort 7001 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /odsm-config> SetHandler weblogic-handler WebLogicCluster IDMHOST1.EXAMPLE.COM:<PORT>,IDMHOST2.EXAMPLE.COM:<PORT> </Location>
opmnctlコマンドを使用してOracle HTTP Serverの停止と起動を行います。
ORACLE_INSTANCE/bin/opmnctl stopallORACLE_INSTANCE/bin/opmnctl startall
次を実行して、WebLogicにおけるホスト・アサーションを変更します。
WebLogic管理コンソール(http://oaamhost1.example.com:7001/console)にログインします。
ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。
「チェンジ・センター」で「ロックして編集」をクリックし、編集可能にします。
「クラスタ名」(cluster_ods)をクリックします。
「一般」で、拡張プロパティのボックスを選択して、WebLogicプラグインを「有効」に設定します。
「保存」をクリックします。
「HTTP」を選択し、次の値を入力します。
- フロントエンド・ホスト: loadbalancer.example.com
- フロントエンドHTTPポート: 7777(ロード・バランサ上のポート)
- フロントエンドHTTPSポート: SSL通信を使用している場合、ロード・バランサ上のSSLポートまたはOracle HTTP Server SSLポートに設定します。
これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート443または80に送られます。
「保存」をクリックします。
「チェンジ・センター」で「変更のアクティブ化」をクリックし、変更を保存します。
2台のODSMサーバーを再起動して、変更を検証します。
ロード・バランシング・ルーターの仮想ホストを使用して、次の各コンソールにアクセスできることを確認します。
Oracle Directory Services Managerコンソール:
http://admin.example.com:7777/odsm
Oracle WebLogic Server管理コンソール:
http://idmhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://idmhost1.example.com:7001/em
|
注意: 高可用性構成にデプロイされたOracle Directory Integration PlatformがサーバーのみのSSL認証(SSL Mode2)に対応している場合は、すべてのOracle Internet Directoryインスタンスの証明書を含む共通キーストアを使用する必要があります。共通キーストアは、すべてのOracle Internet Directoryインスタンスから証明書をインポートし、Oracle Directory Integration Platformが実行されているすべてのノードにそのキーストアをコピーすることによって作成できます。 Oracle Directory Integration PlatformにおけるSSLの使用の詳細は、Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイドを参照してください。 |
高可用性環境では、Oracle Directory Integration Platformアプリケーションは、少なくとも2つのWebLogicインスタンスで構成されるOracle WebLogic Serverクラスタにデプロイされます。
Oracle Directory Integration Platformアプリケーションはデフォルトで、基盤となるWebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
さらに、高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。データベース・インスタンスの障害が発生した場合は、障害が発生していないOracle RACノードが残りのプロセスを引き継ぎます。第8.5.5項「Oracle Directory Integration Platformの高可用性のトラブルシューティング」で説明されているように、Oracle RACのフェイルオーバー時には、管理対象サーバー・ログに無害のエラーが記録される場合があります。
この項では、Oracle Directory Integration Platformの高可用性に関する問題に対処する方法について説明します。
Oracle RACのフェイルオーバー時に、Oracle Directory Integration Platformアプリケーションを実行する管理対象サーバーのログ・ファイルに次のような例外が表示されることがあります。これらのエラーは、フェイルオーバー時に、WebLogic Serverプラットフォーム上に構成された複数のデータ・ソースによって、Oracle RAC データベースのヘルス状態の検証が試行されるときにスローされます。これらは無害なエラーであり、無視してかまいません。Oracle Directory Integration Platformアプリケーションは、数分の遅延の後、リカバリして正常動作を開始します。Oracle RACのフェイルオーバー時に、1つのOracle RACインスタンスが実行を続けていれば、Oracle Directory Integration Platformに停止時間は発生しません。
RuntimeException:
[2008-11-21T00:11:10.915-08:00] [wls_ods] [ERROR] []
[org.quartz.impl.jdbcjobstore.JobStoreTX] [tid: 25] [userId: <anonymous>]
[ecid: 0000Hqy69UiFW7V6u3FCEH199aj0000009,0] [APP: DIP] ClusterManager: Error
managing cluster: Failed to obtain DB connection from data source
'schedulerDS': java.sql.SQLException: Could not retrieve datasource via JNDI
url 'jdbc/schedulerDS' java.sql.SQLException: Cannot obtain connection:
driverURL = jdbc:weblogic:pool:schedulerDS, props =
{EmulateTwoPhaseCommit=false, connectionPoolID=schedulerDS,
jdbcTxDataSource=true, LoggingLastResource=false,
dataSourceName=schedulerDS}.[[
Nested Exception: java.lang.RuntimeException: Failed to setAutoCommit to true
for pool connection
AuthenticationException while connecting to OID:
[2008-11-21T00:12:08.812-08:00] [wls_ods] [ERROR] [DIP-10581] [oracle.dip]
[tid: 11] [userId: <anonymous>] [ecid: 0000Hqy6m54FW7V6u3FCEH199apO000000,0]
[APP: DIP] DIP was not able to get the context with the given details {0}[[
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]
ほとんどの例外は、スケジューラまたはLDAPに関連するものです。たとえば次のような例外です。
1. JNDI url 'jdbc/schedulerDS' java.sql.SQLExceptionによってデータ・ソースを取得できませんでした。
2. javax.naming.AuthenticationException: [LDAP: エラー・コード49 - 無効な資格証明]
WebLogicノード・マネージャの起動後に次のエラー・メッセージが表示された場合は、エラー・メッセージの後に表示される手順に従います。
<Dec 15, 2008 8:40:05 PM> <Warning> <Uncaught exception in server handler: javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com - 152.68.64.2155. Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.> javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com - 152.68.64.215. Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.
まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。
コンソールの左側のペインで、「サーバー」を開いて、「AdminServer (admin)」をクリックします。
「構成」→「SSL」→詳細リンクを選択します。
「ホスト名の検証」に「なし」を選択します。
「保存」をクリックして設定を保存します。
これらの変更をアクティブにするには、管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックします。
すべてのサーバーを再起動します。
管理対象サーバーが管理モードで起動したら、次の手順を実行します。
まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。
コンソールの左側のペインで、「サーバー」を開いて、ADMINモードで実行されているサーバーの名前をクリックします。
「制御」→「起動と停止」タブを選択します。
サーバーの名前を選択します。
「再開」をクリックします。
「はい」をクリックしてサーバーを再開します。
WebLogicノード・マネージャの起動に失敗する場合は、次のドメイン・ファイルをIDMHOST1からIDMHOST2にコピーしてあることを確認します。
WL_HOME/common/nodemanager/nodemanager.domains
高可用性トポロジのOracle Directory Integration Platformインスタンスの構成を変更した場合、この構成の変更はトポロジ内のすべてのOracle Directory Integration Platformインスタンスに自動的には伝播されません。
かわりに、manageDIPServerConfigツールを使用して、トポロジ内の各Oracle Directory Integration Platformインスタンスに対して同一の構成変更を行います。これにより、トポロジ内のすべてのOracle Directory Integration Platformインスタンスが同じ構成になります。manageDIPServerConfigツールの詳細は、Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイドを参照してください。
この項では、Oracle Directory Services Managerの概要、およびOracle Directory Integration PlatformとOracle Directory Services Managerに対して高可用性環境を設計およびデプロイする方法について説明します。
Oracle Directory Integration Platformの詳細は、第8.5項「Oracle Directory Integration Platformの高可用性」を参照してください。
この項の内容は次のとおりです。
Oracle Directory Services Managerは、Oracle Internet DirectoryおよびOracle Virtual Directoryのインスタンスの管理用に統一されたグラフィカル・ユーザー・インタフェース(GUI)です。非推奨となったOracle Directory Managerにかわるものです。Oracle Directory Services Managerでは、ディレクトリ構造の構成、ディレクトリ内のオブジェクトの定義、ユーザー、グループおよびその他のエントリの追加と構成ができます。
エンド・ユーザーは、Oracle Directory Services Managerを使用して、各自のディレクトリ・エントリ、スキーマ、セキュリティおよびその他の機能を管理できます。
図8-8は、Oracle Directory Services Managerのアーキテクチャを示しています。
図8-8は、非高可用性アーキテクチャにデプロイされたOracle Directory Services Managerを示しています。Oracle Directory Services ManagerはOracle WebLogic Server上にデプロイされます。Oracle Directory Services Managerは、管理対象となるOracle Virtual DirectoryとOracle Internet Directoryの各インスタンスと通信を行うよう構成されます。
Oracle Directory Services Managerでは、クライアント・ブラウザとの通信にHTTPプロトコルが使用されます。Oracle Internet Directoryとの通信には、LDAPプロトコルを使用し、Oracle Virtual Directoryとの通信はWebサービスを介して行われます。
Oracle Directory Services Managerは、Oracle Application Development Framework (ADF)ベースのJ2EEアプリケーションであり、Oracle WebLogic Server上にデプロイされます。
Oracle Directory Services Managerは、Oracle Internet Directoryと同じノードまたは独立したノードにデプロイできます。
Oracle Directory Services Managerは、直接またはOracle Enterprise Manager Fusion Middleware Controlから起動できます。
Oracle Directory Services Managerを直接起動するには、次のURLをブラウザのアドレス・フィールドに入力します。
http://host:port/odsm/faces/odsm.jspx
説明:
hostは、Oracle Directory Services Managerが実行されている管理対象サーバーの名前です。
portは、管理対象サーバーのポート番号です。
Oracle Directory Services ManagerをOracle Enterprise Manager Fusion Middleware Controlから起動する手順は次のとおりです。
Oracle Internet Directoryターゲットの「Oracle Internet Directory」メニューで「Directory Services Manager」を選択して、「データ・ブラウザ」、「スキーマ」、「セキュリティ」、または「拡張」を選択します。
Oracle Virtual Directoryターゲットの「Oracle Virtual Directory」メニューで「Directory Services Manager」を選択してから、「データ・ブラウザ」、「スキーマ」、「アダプタ」、「拡張機能」、または「クイック構成ウィザード」を選択します。
Oracle Directory Services Managerは、Oracle WebLogic Serverに対して外部的にステージングされたアプリケーションとしてデプロイされます。WebLogicサーバーは、Oracle Directory Services Managerアプリケーションの起動、停止、監視を管理します。Oracle Directory Services Managerは、管理対象サーバーの起動時に初期化を実行します。Oracleノード・マネージャは、サーバー・プロセスを監視して、障害発生時には再起動するように構成されます。
Oracle Directory Services Managerアプリケーションのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールのいずれかを使用して管理できます。
次のツールは、Oracle Directory Services Managerプロセスの起動と停止に使用できます。
Oracle WebLogic Server Scripting Tool (WLST)
Oracle Enterprise Manager Fusion Middleware Control
WebLogic Server管理コンソール
WebLogicノード・マネージャ
この項では、Oracle Directory Services Managerを高可用性構成で使用する場合の概要について説明します。
この項で説明するOracle Directory Services Managerの高可用性構成では、2つのホスト上にOracle Directory Services ManagerとOracle Directory Integration Platformが、2ノードのアクティブ/アクティブの高可用性構成でインストールおよび構成されています。
図8-9は、Oracle Directory Integration PlatformとOracle Directory Services Managerのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。
図8-9 高可用性アーキテクチャのOracle Directory Services ManagerとOracle Directory Integration Platform
図8-9では、アプリケーション層にコンピュータIDMHOST1とIDMHOST2があります。
IDMHOST1では、次のインストールが実行されています。
Oracle Directory Integration PlatformインスタンスとOracle Directory Services Managerインスタンスが、WLS_ODS1管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。
IDMHOST2では、次のインストールが実行されています。
Oracle Directory Integration PlatformインスタンスとOracle Directory Services Managerインスタンスが、WLS_ODS2管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
IDMHOST2上のWLS_ODS2管理対象サーバーにあるインスタンスと、IDMHOST1上のWLS_ODS1管理対象サーバーにあるインスタンスは、CLUSTER_ODSクラスタとして構成されています。
WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。IDMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
高可用性アーキテクチャでは、Oracle Directory Integration PlatformおよびOracle Directory Services ManagerはOracle WebLogicクラスタにデプロイされます。このクラスタには、その一部として少なくとも2つのサーバーが存在します。
WebLogic Serverはデフォルトで、アプリケーションの起動、停止および監視を行います。Oracle Directory Integration PlatformとOracle Directory Services Managerの各アプリケーションはともにデフォルトで、基盤となるWebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。ノード・マネージャがこのサーバーを再起動できない場合は、フロントエンドのロード・バランシング・ルーターによってクラスタ内のWebLogicインスタンスの障害が検出され、障害が発生していないインスタンスにトラフィックがルーティングされます。
この項では、Oracle Directory Services Managerのアクティブ/アクティブ・クラスタにおける様々な障害からの保護について説明します。
高可用性環境では、Oracle Directory Services Managerアプリケーションは、少なくとも2つのWebLogicインスタンスで構成されるOracle WebLogic Serverクラスタにデプロイされます。
Oracle Directory Services Managerアプリケーションはデフォルトで、基盤となるWebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
さらに、高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。ノード・マネージャがこのサーバーを再起動できない場合は、Oracle HTTP Serverの一部として構成されているmod_wl_ohsによって、障害が発生していないWebLogicインスタンスにリクエストがルーティングされます。
OPMNは、Oracle HTTP Serverプロセスを監視し、障害発生時にはこのプロセスを再起動します。OPMNがHTTPプロセスを再起動できない場合は、フロントエンドのロード・バランシング・ルーターによってOracle HTTP Serverインスタンスの障害が検出され、障害が発生していないインスタンスにトラフィックがルーティングされます。
Oracle Directory Services Managerによって、セッション状態が管理されますが、障害発生時には、セッション状態の情報は障害が発生していないノードに対して引き継がれません。
Oracle Directory Services Managerのフェイルオーバーは、透過的ではありません。Oracle WebLogic Serverインスタンスのフェイルオーバー時は、Oracle Directory Services Managerを使用して接続を再確立する必要があります。
この項では、Oracle Directory Services Managerの高可用性アーキテクチャを設定するための前提条件について説明します。
|
注意: Oracle Directory Services Managerを高可用性デプロイメントで使用する場合は、クラスタ・ノードのシステム・クロックを同期する必要があります。 |
Oracle Directory Services Managerをインストールする前に、次に示すコンポーネントをインストールして構成しておくことをお薦めします。前提条件、およびインストールと構成の手順については、次の各項を参照してください。
Oracle Database
Oracle Real Application Clustersデータベースのインストールと構成は、次の各項の説明に従います。
Oracleリポジトリ作成ユーティリティ
Oracleリポジトリ作成ユーティリティをインストールして、必要なスキーマを作成しロードするには、次の各項の説明に従います。
ロード・バランサと仮想ホスト
ロード・バランサの構成と必要な仮想サーバーの作成の詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。
Oracle Internet Directory
Oracle Internet Directoryのインストールと構成は、次の各項の説明に従います。
図8-9に示されているアクティブ/アクティブの高可用性構成のインストールおよび構成の手順については、第8.5.3項「Oracle Directory Integration PlatformおよびOracle Directory Services Managerの高可用性の構成手順」を参照してください。
この項では、高可用性構成のOracle Directory Services Managerを検証する方法について説明します。
Oracle HTTP Serverを通してOracle Directory Services Managerにアクセスしている間に、この項の手順を使用してWebLogic Serverインスタンスをフェイルオーバーし、フェイルオーバー後もOracle Directory Services Managerがアクセス可能であることを検証できます。
この例で使用するOracle HTTP Server仮想サーバー名は次のとおりです。
http://admin.example.com
次の手順を実行します。
Oracle HTTP Server仮想サーバー名を使用してOracle Directory Services Managerにアクセスします。
http://admin.example.com/odsm/faces/odsm.jspx
「Oracle Directory Services Managerへようこそ」画面が表示されたら、Webブラウザを開いて次のURLを入力します。
http://hostname:port/console
hostnameは管理サーバーのDNS名、portは管理サーバーがリクエストをリスニングするポートのアドレス(デフォルトでは7001)です。
ログイン・ページで、管理サーバーの起動に使用するユーザー名とパスワードを入力して、「ログイン」をクリックします。
次の手順に従って、Oracle Directory Services Managerがデプロイされている管理対象サーバーの1つを停止させます。
Oracle WebLogic Server管理コンソールの左側のペインで、「環境」を開いて、「サーバー」を選択します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
停止させる管理対象サーバーの名前をクリックします。(例:wls_ods1)。
wls_ods1の設定画面で「制御」→「起動と停止」タブを選択します。
停止する管理対象サーバーの名前(wls_ods1)の横にあるチェック・ボックスを選択し、「停止」→「作業完了時」をクリックします。
管理対象サーバー(wls_ods1)のステータスを確認します。
コンソールの左側のペインで、「環境」を開いて、「サーバー」を選択します。
管理対象サーバー(wls_ods1)の状態はSHUTDOWNとなっているはずです。
Oracle HTTP Server仮想サーバー名を使用してOracle Directory Services Managerにアクセスします。
http://admin.example.com/odsm/faces/odsm.jspx
「Oracle Directory Services Managerへようこそ」画面が表示されます。
ロード・バランシング・ルーターを介してOracle Directory Services Managerにアクセスしている間に、この項の手順に従ってOracle RACデータベース・インスタンスを一度に1つずつフェイルオーバーし、フェイルオーバー後もOracle Directory Services Managerが機能していることを確認します。この例では、Oracle Directory Services Managerの確認だけでなく、Oracle Internet Directoryからデータベースへのアクセスも確認します。
この例で使用するOracle HTTP Server仮想サーバー名は次のとおりです。
http://admin.example.com
この例で使用するLDAP仮想サーバー名は次のとおりです。
oid.example.com:389
次の手順を実行します。
Oracle HTTP Server仮想サーバー名を使用してOracle Directory Services Managerにアクセスします。
http://admin.example.com/odsm/faces/odsm.jspx
「Oracle Directory Services Managerへようこそ」画面が表示されます。
LDAP仮想サーバーを使用してOracle Internet Directoryに接続できることを確認します。
右上隅にある「ディレクトリに接続」→「新規接続の作成」リンクを選択します。
「新規接続」画面で、次の接続情報を入力し、「接続」をクリックします。
ディレクトリ・タイプ: OID
名前: OIDHA
サーバー: oid.example.com
ポート: 389
SSL有効: 空白にしておきます。
ユーザー名: cn=orcladmin
パスワード: ********
開始ページ: Home(デフォルト)
INFRADBHOST1-VIP上のOracle Internet Directoryスキーマ・データベース・インスタンスを停止させるために、次のようにsrvctlコマンドを実行します(この例では、INFRADBというデータベース名を使用します)。
ORACLE_HOME/bin/srvctl stop instance -d infradb -i infradb1ORACLE_HOME/bin/srvctl status database
Oracle Directory Services Managerの画面を再表示するか、タブ(「ホーム」、「データ・ブラウザ」、「スキーマ」、「セキュリティ」、「詳細」)の1つをクリックします。依然としてOracle Internet Directoryの情報にアクセスできるはずです。
INFRADBHOST1-VIP上でOracle Internet Directoryスキーマ・データベース・インスタンスを再起動させるために、次のようにsrvctlコマンドを実行します。
ORACLE_HOME/bin/srvctl start instance -d infradb -i infradb1ORACLE_HOME/bin/srvctl status database
INFRADBHOST2-VIPでステップ3、4、および5を実行します。
この項では、Oracle Directory Services Managerを使用して、管理対象サーバー、Oracle Internet Directoryインスタンス、およびOracle RACデータベースのフェイルオーバーを検証する手順について説明します。
Oracle Directory Services Managerを使用して、管理対象サーバーのフェイルオーバーを検証する手順は次のとおりです。
Webブラウザで、Oracle HTTP Serverのホストとポートを使用して、「Oracle Directory Services Manager」ページを起動します。例:
http://WEBHOST1:PORT/odsm/faces/odsm.jspx
Oracle Internet Directoryに接続します。
管理コンソールに移動して、wls_ods1管理対象サーバーを停止します。
「Oracle Directory Services Manager」ページに戻り、作業を続行します。
「Oracle Directory Services Manager」ページの接続が切断されます。
同じブラウザから、Oracle HTTP Serverのホストとポートを使用して「Oracle Directory Services Manager」ページを再起動します。
接続を再確立します。
この動作が必要となる動作です。Oracle Directory Services Managerのフェイルオーバーは、透過的ではありません。WebLogic Serverインスタンスのフェイルオーバー時は、Oracle Directory Services Managerを使用して接続を再確立する必要があります。
Oracle Directory Services Managerを使用して、Oracle Internet Directoryインスタンスのフェイルオーバーを検証する手順は次のとおりです。
Webブラウザで、Oracle HTTP Serverのホストとポートを使用して、「Oracle Directory Services Manager」ページを起動します。例:
http://WEBHOST1:PORT/odsm/faces/odsm.jspx
Oracle Internet Directoryハードウェア・ロード・バランサに接続します。
一度に1つずつOracle Internet Directoryインスタンスを停止します。
フェイルオーバー時には、「Oracle Directory Services Manager」ページに戻り、作業を続行します。
これは、Oracle Directory Services ManagerにOracle Internet Directoryが停止しているというメッセージのウィンドウが表示された場合に必要な対応です。Oracle Directory Services Managerは、Oracle Internet Directoryに再接続しますが、その接続はフェイルオーバー時には永続しないことがあります。詳細は、第8.6.6.4項「Oracle Internet Directoryのフェイルオーバー時に、メッセージ「LDAPサーバーが停止しています。」がOracle Directory Services Managerに表示される」を参照してください。
Oracle Directory Services Managerにアクセスしている間に、Oracle Internet Directoryインスタンスを一度に1つずつフェイルオーバーし、フェイルオーバー後もLDAPストアがアクセス可能であることを確認します。Oracle Directory Services ManagerからOracle Internet Directoryへの接続が永続的でない場合もあります。
Oracle Directory Services Managerを使用して、Oracle RACのフェイルオーバーを検証する手順は次のとおりです。
Webブラウザで、Oracle HTTP Serverのホストとポートを使用して、「Oracle Directory Services Manager」ページを起動します。例:
http://WEBHOST1:PORT/odsm/faces/odsm.jspx
「Oracle Directory Services Manager」ページからOracle Internet Directoryに接続します。
一度に1つずつOracle RACデータベース・インスタンスを停止します。
「Oracle Directory Services Manager」ページに戻り、ステップ2で確立したOracle Internet Directoryの接続から作業を続行します。
Oracle RACのフェイルオーバー時に一時的に接続が失われますが、これはOracle Directory Services Managerに必要な動作です。Oracle RACのフェイルオーバー時にOracle Directory Services Managerに表示されるエラー・メッセージの詳細は、第8.6.6.5項「Oracle RACフェイルオーバー時のOracle Directory Services Managerの一時的な接続の消失」を参照してください。
ハードウェア・ロード・バランサを介してOracle Directory Services Managerへアクセスしている間に、Oracle RACデータベース・インスタンスを一度に1つずつフェイルオーバーし、フェイルオーバー後もOracle Directory Services Managerが機能していることを確認します。これによって、Oracle Directory Services Managerの確認だけでなく、Oracle Internet DirectoryからOracle RACデータベースへのアクセスも確認できます。
この項では、Oracle Directory Services Managerの高可用性に関する問題に対処する方法について説明します。
WebLogicノード・マネージャの起動後に次のエラー・メッセージが表示された場合は、エラー・メッセージの後に表示される手順に従います。
<Dec 15, 2008 8:40:05 PM> <Warning> <Uncaught exception in server handler: javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com - 152.68.64.2155. Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.> javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com - 152.68.64.215. Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.
まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。
コンソールの左側のペインで、「サーバー」を開いて、「AdminServer (admin)」をクリックします。
「構成」→「SSL」→詳細リンクを選択します。
「ホスト名の検証」に「なし」を選択します。
「保存」をクリックします。
管理コンソールの「チェンジ・センター」で、「変更のアクティブ化」をクリックします。
すべてのサーバーを再起動します。
管理対象サーバーが管理モードで起動したら、次の手順を実行します。
まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。
コンソールの左側のペインで、「サーバー」を開いて、ADMINモードで実行されているサーバーの名前をクリックします。
「制御」→「起動と停止」タブを選択します。
サーバーの名前を選択します。「再開」をクリックします。
「はい」をクリックしてサーバーを再開します。
WebLogicノード・マネージャの起動に失敗する場合は、次のドメイン・ファイルをIDMHOST1からIDMHOST2にコピーしてあることを確認します。
WL_HOME/common/nodemanager/nodemanager.domains
Oracle HTTP Serverを使用してOracle Directory Services Managerのフェイルオーバーを実行する場合、このフェイルオーバーは透過的には行われません。次の手順を実行すると、この動作を確認できます。
Oracle HTTP Serverを使用して、Oracle Directory Services Managerをアクティブ/アクティブの高可用性構成にデプロイします。
Oracle HTTP Serverの名前とポート番号を使用して、「Oracle Directory Services Manager」ページを開きます。
Oracle Internet DirectoryサーバーやOracle Virtual DirectoryサーバーなどのLDAPサーバーに接続します。
現行のOracle Directory Services ManagerのOracle HTTP Serverホストとポートを使用して、LDAPサーバーで作業します。
Oracle WebLogic Server管理コンソールを使用して、一度に1つずつ管理対象サーバーを停止します。
「Oracle Directory Services Manager」ページとポート、およびすでに確立されているOracle Internet DirectoryまたはOracle Virtual Directoryの接続に戻ります。この操作を行うと、「Oracle Directory Services Manager」ページへの接続を再確立する必要があることを示すメッセージが表示されます。
このような場合は、次の手順を実行する必要があります。
Webブラウザで、現在の「Oracle Directory Services Manager」ページを終了します。
新たにWebブラウザ・ページを起動して、同じOracle Directory Services ManagerのOracle HTTP Serverの名前とポートを指定します。
前述の手順で作業中を行っていたLDAPサーバー(Oracle Internet DirectoryまたはOracle Virtual Directory)への接続を再確立します。
Oracle Directory Services Managerがロード・バランサを介してOracle Internet Directoryに接続される高可用性構成では、Oracle Internet Directoryのインスタンス間のフェイルオーバー時にOracle Directory Services Managerにメッセージ「LDAPサーバーが停止しています。」が表示されます。
Oracle Internet Directoryのフェイルオーバーが完了すると、この接続は数分以内に再確立されるため、再ログインすることなく作業を続行できます。
Oracle Directory Services Managerでは、Oracle RACのフェイルオーバー時にOracle RACデータベースを使用中のOracle Internet Directoryインスタンスとの接続が一時的に失われます。Oracle Directory Services Managerに、メッセージFailure accessing Oracle database (oracle errcode=errcode)が表示されることがあります(errcodeは、次のいずれかです。値: 3113、3114、1092、28、1041、または1012)。
Oracle RACのフェイルオーバーが完了すると、この接続は数分以内に再確立されるため、再ログインすることなく作業を続行できます。
Oracle Directory Services Managerを使用して、Oracle Internet Directoryクラスタを管理する場合は、接続文字列にロード・バランサの仮想アドレスを使用します。ただし、Oracle Directory Services Managerを使用してOracle Virtual Directoryクラスタを管理する場合は、具体的なOracle Virtual Directoryインスタンスのホスト名とポートを指定する必要があります。
この項では、Oracle Internet Directory、Oracle Directory Integration Platform、Oracle Virtual Directory、およびOracle Directory Services Managerをコロケートの高可用性環境に設計し、デプロイする方法について説明します。これらのコンポーネントの概要は、このマニュアルの前の項に記載されています。
この項では、Oracle Internet Directory、Oracle Directory Integration Platform、Oracle Virtual Directory、およびOracle Directory Services Managerを高可用性構成にデプロイする場合のコロケート・アーキテクチャについて説明します。
この項の内容は次のとおりです。
この項で説明するコロケート・アーキテクチャにおける各コンポーネントのアーキテクチャの概要は、次の各項を参照してください。
Oracle Internet Directory: 第8.3.1項「Oracle Internet Directoryコンポーネント・アーキテクチャ」
Oracle Virtual Directory: 第8.4.1項「Oracle Virtual Directoryコンポーネント・アーキテクチャ」
Oracle Directory Integration Platform: 第8.5.1項「Oracle Directory Integration Platformコンポーネント・アーキテクチャ」
Oracle Directory Services Manager: 第8.6.1項「Oracle Directory Services Managerコンポーネント・アーキテクチャ」
図8-10では、Oracle Internet Directory、Oracle Directory Integration Platform、Oracle Virtual Directory、およびOracle Directory Services Managerが、単一ホストにコロケートされており、非高可用性アーキテクチャにデプロイされています。
図8-10のコンポーネントはすべて、同一ホストにデプロイされていますが、それぞれ個別のOracleホームとOracleインスタンスを持ちます。Oracle Internet Directoryは、セキュリティ・メタデータ・リポジトリとして、スタンドアロンのOracle Databaseを使用します。
図8-11では、Oracle Internet Directory、Oracle Virtual Directory、Oracle Directory Integration Platform、およびOracle Directory Services Managerが、IDMHOST1とIDMHOST2にコロケートされており、高可用性アーキテクチャでデプロイされています。
この項で説明するコロケート・アーキテクチャにおける各コンポーネントの前提条件については、次の各項を参照してください。
Oracle Internet Directory: 第8.3.2.3項「Oracle Internet Directoryの前提条件」
Oracle Virtual Directory: 第8.4.2.2項「Oracle Virtual Directoryの前提条件」
Oracle Directory Integration Platform: 第8.5.2.3項「Oracle Directory Integration Platformの前提条件」
Oracle Directory Services Manager: 第8.6.2.3項「Oracle Directory Services Managerの前提条件」
Oracle Identity Federation: 第8.13.2.3項「Oracle Identity Federationの前提条件」
この項では、IDMHOST1とIDMHOST2にOracle Internet Directory、Oracle Directory Integration Platform、Oracle Virtual Directory、およびOracle Directory Services Managerを高可用性アーキテクチャでインストールし、構成する手順を説明します。
|
注意: コロケート環境では、Oracle Identity Managementの各コンポーネントを個別のOracleホームにインストールする必要があります。これらのコンポーネントは同じMW_HOMEを共有できます。 各コンポーネントで、1つ目のインスタンスのOracleホームの場所のディレクトリ・パスが、2つ目のインスタンスのOracleホームの場所のディレクトリ・パスと同じであることを確認します。 たとえば、OIDHOST1の1つ目のOracle Internet DirectoryインスタンスのOracleホームの場所のディレクトリ・パスが |
データベースをインストールします。詳細は、第8.2.3項「データベース・リポジトリのインストールと構成」を参照してください。
RCUをインストールします。詳細は、第8.2.4項「リポジトリ作成ユーティリティ・ソフトウェアの取得」を参照してください。
データベースを構成します。詳細は、第8.2.5項「Oracle Fusion Middleware 11gメタデータのデータベースの構成」を参照してください。
RCUを実行して、Oracle Internet DirectoryとOracle Identity Federationに必要なスキーマをインストールします。詳細は、第8.3.2.3.2項「RCUを使用したリポジトリへのOracle Internet Directoryスキーマの作成」と第8.13.2.3.1項「RCUを使用したリポジトリへのOracle Identity Federationスキーマの作成」を参照してください。
1つ目のホストで、Oracle Internet Directoryのインストールと構成を行います。詳細は、第8.3.3.2.1項「OIDHOST1でのOracle Internet Directoryの構成」または第8.3.3.3.1項「OIDHOST1でのOracle Internet Directoryの構成」を参照してください。
2つ目のホストで、Oracle Internet Directoryのインストールと構成を行います。詳細は、第8.3.3.2.3項「OIDHOST2でのOracle Internet Directoryの構成」または第8.3.3.3.3項「OIDHOST2でのOracle Internet Directoryの構成」を参照してください。
1つ目のホストでOracle Virtual Directoryのインストールと構成を行います。詳細は、第8.4.3.1.1項「OVDHOST1でのOracle Virtual Directoryの構成」または第8.4.3.2.1項「OVDHOST1でのOracle Virtual Directoryの構成」を参照してください。
2つ目のホストでOracle Virtual Directoryのインストールと構成を行います。詳細は、第8.4.3.1.2,項「OVDHOST2でのOracle Virtual Directoryの構成」または第8.4.3.2.3,項「OVDHOST2でのOracle Virtual Directoryの構成」を参照してください。
1つ目のホストで、Oracle Directory Integration PlatformとOracle Directory Services Managerのインストールと構成を行います。詳細は、第8.5.3.1項「IDMHOST1でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成」を参照してください。
2つ目のホストで、Oracle Directory Integration PlatformとOracle Directory Services Managerのインストールと構成を行います。詳細は、第8.5.3.3項「IDMHOST2でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成」を参照してください。
高可用性アーキテクチャにコロケートされたコンポーネントの検証、およびこれらのコンポーネントとOracle RACをフェイルオーバーする方法の詳細は、次の各項を参照してください。
高可用性アーキテクチャにコロケートされた次のコンポーネントの検証については、次の各項を参照してください。
Oracle Internet Directory: 第8.3.4項「Oracle Internet Directoryの高可用性の検証」
Oracle Virtual Directory: 第8.4.4項「Oracle Virtual Directoryの高可用性の検証」
Oracle Directory Integration Platform: 第8.6.4項「Oracle Directory Services Managerの高可用性の検証」
Oracle Directory Services Manager: 第8.6.4項「Oracle Directory Services Managerの高可用性の検証」
Oracle Identity Federation: 第8.13.3.6項「Oracle Identity Federationの高可用性の検証」
高可用性アーキテクチャにコロケートされた次のコンポーネントの障害および予想される動作の詳細は、次の各項を参照してください。
Oracle Internet Directory: 第8.3.5項「Oracle Internet Directoryのフェイルオーバーおよび予想される動作」
Oracle Virtual Directory: 第8.4.5項「Oracle Virtual Directoryのフェイルオーバーおよび予想される動作」
Oracle Directory Integration Platform: 第8.5.4項「Oracle Directory Integration Platformのフェイルオーバーおよび予想される動作」
Oracle Directory Services Manager: 第8.6.5項「Oracle Directory Services Managerのフェイルオーバーおよび予想される動作」
Oracle Identity Federation: 第8.13.4項「Oracle Identity Federationのフェイルオーバーおよび予想される動作」
高可用性アーキテクチャにコロケートされた次のコンポーネントのトラブルシューティングについては、次の各項を参照してください。
Oracle Internet Directory: 第8.3.6項「Oracle Internet Directoryの高可用性のトラブルシューティング」
Oracle Virtual Directory: 第8.4.6項「Oracle Virtual Directoryの高可用性のトラブルシューティング」
Oracle Directory Integration Platform: 第8.5.5項「Oracle Directory Integration Platformの高可用性のトラブルシューティング」
Oracle Directory Services Manager: 第8.6.6項「Oracle Directory Services Managerのトラブルシューティング」
Oracle Identity Federation: 第8.13.5項「Oracle Identity Federationの高可用性のトラブルシューティング」
高可用性アーキテクチャにコロケートされた次のコンポーネントのその他の考慮事項については、次の各項を参照してください。
Oracle Internet Directory: 第8.3.7項「Oracle Internet Directoryの高可用性に関するその他の問題」
Oracle Directory Services Manager: 第8.6.7項「Oracle Directory Services Managerの高可用性に関するその他の考慮事項」
この項では、Oracle Access Manager 11gR1の概要、およびOracle Access Manager 11gR1の高可用性環境の設計およびデプロイ方法について説明します。
Oracle Access Manager 11gR1は、Oracle Access Manager 10g(アクセスのみ)とOracle Single Sign-On 10gの両方の後継製品です。Oracle Access Manager 11gR1によって、すべての認証および認可サービスの一元的な提供が可能になります。提供されるコア・サービスは、有効なセッション・トークンのチェック、セッション・トークンが無効であるか見つからない場合の資格証明の要求、セッション・トークンの発行、リソース・リクエストのインターセプト、およびリソースへのアクセスを制御するためのアクセス制御ポリシーの評価です。Oracle Access Manager 11gR1は、Pure Javaサーバーの機能を備えていますが、Oracle Single Sign-On 10gおよびOracle Access Manager 10gエージェント・コンポーネントも引き続き使用します。エージェントに関する11gR1の主な新しい機能は、WebGateごとの共有秘密鍵(SSKPWG)機能です。
Oracle Access Managerはシングル・サインオン機能を提供し、これにより、ユーザーは、一度認証された後に毎回再ログインせずに済みます。これは、ユーザー・セッションのライフ・サイクルを管理することによって実現します。これには、有効なユーザー・セッションにおけるすべてのリライイング・パーティにわたるログアウトをオーケストレートすることでグローバル・ログアウトを容易にすることも含まれます。また、Oracle Access Managerによって、ユーザーによるリソース・アクセスが指定済認可ポリシーに従って認可されるようになります。
Oracle Access Manager 10gとは異なり、Oracle Access Manager 11gR1にはアイデンティティ・サービスは備わっておらず、ネイティブLDAPやOracle Identity Managerなどの他のアイデンティティ管理サービスからのアイデンティティ情報が使用されます。
Oracle Access Manager 11gR1は、アクセス管理領域におけるアーキテクチャの進化であり、エンタープライズおよびWebシングル・サインオンのための統合された製品アーキテクチャを提供します。Oracle Access Managerのコンポーネントは、相互運用性とシームレスな統合に重点を置いており、一般的な基盤データ・モデル、共有基盤機能、一貫したセマンティックを持つJava EEミドルウェア・プラットフォームを活用します。Oracle Access Manager 11gR1は、既存のシングル・サインオン・デプロイメントに対して共存および増分移行することができます。
この項の内容は次のとおりです。
図8-12は、Oracle Access Manager 11gR1コンポーネントのアーキテクチャを示しています。
図8-12は、次のコンポーネントを示しています。
ユーザー・エージェント: これらには、Webブラウザ、Javaアプリケーション、およびWebサービス・アプリケーションが含まれます。ユーザー・エージェントは、HTTPを使用してアクセス・サーバーと管理および構成ツールにアクセスします。
保護されたリソース: 保護されたリソースとは、それへのアクセスが制限されたアプリケーションまたはWebページのことです。保護されたリソースへのアクセスは、WebGateまたはカスタム・エージェントによって制御されます。
管理および構成ツール: Oracle Access Managerは、Oracle Access Managerコンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Enterprise Manager Grid ControlおよびWebLogic Scripting Tool (WLST)を使用して管理および構成できます。
アクセス・サーバー: アクセス・サーバーには、資格証明コレクタ、OSSOプロキシおよびOAMプロキシ・コンポーネントが含まれます。Coherence分散オブジェクト・キャッシュは、アクセス・サーバー間で構成ファイルの変更を伝播するために使用されます。
Oracle Access Manager 11gR1デプロイメントは、次のシステム・エンティティで構成されます。
Oracle Access Managerエージェント - Oracle Access Managerエージェントは、アクセス・サーバーの拡張機能であり、アクセス・サーバーで管理されているポリシーのとおりにアクセスが制御されるようにする役割を担います。エージェントは、Oracle Access Manager 11gR1によって保護される様々なWebリソースにアクセスするためにエンドユーザーによって使用されるクライアントおよびプログラム(WebGate、Javaエージェント、カスタム・エージェント、Oracle Single Sign-On Apacheモジュールなど)です。最もよく使用されるユーザー・エージェントはWebブラウザです。Oracle Access Manager 11gは、主に、HTTPを介してアクセス可能なリソース(URLによって識別されるリソース)およびカスタム・リソース・タイプの制御に焦点を当てたWebシングル・サインオン・ソリューションです。
エージェントがその機能を実行するには、アクセス・サーバー・コンポーネントが必要です。アクセス・サーバーが使用不可である場合、保護されるサーバーへのアクセスは許可されません(ユーザーはシステムからロックアウトされます)。
Oracle Access Manager 11gR1エージェントは、フロント・チャネルとバック・チャネルを介してアクセス・サーバーに接続します。ユーザーが認証を必要とする場合、フロント・チャネル通信はHTTP(S)を介して行われます。フロント・チャネル通信の存続時間は短い傾向があります。
Oracle Access Managerエージェントがフロント・チャネルHTTPバインディングを使用してアクセス・サーバーと通信する場合は、ロード・バランシング・ルーターを介して通信する必要があります。この情報は、エージェントに渡され、認証スキームでチャレンジ・リダイレクトURLとして構成されます。
バック・チャネル通信は、TCP接続を介して行われるOracle Access Protocol (OAP)と呼ばれる専用プロトコルを使用して行われます。エージェントは、認可の決定を行うためにすべてのリソース・アクセス・リクエストに対してアクセス・サーバーとのバック・チャネル通信を使用します。したがって、これらのバック・チャネル接続は永続的であり、存続時間が長くなります。
Oracle Access Managerエージェントがバック・チャネルOAPバインディングを使用してアクセス・サーバーと通信する場合は、プライマリ/セカンダリ・モデルを使用するように構成されています。
Oracle Access Managerエージェントは、外部ステージング(Web層にデプロイ)されます。それはこれが最良のスケーラビリティを提供するためです。
WebGateは、リソース・リクエストおよび認証スキームに関する情報をキャッシュします。WebGateキャッシュは、構成済タイムアウトまたはサーバーによって開始されるキャッシュ・パージに基づいてフラッシュされます。
WebGateは、60秒ごとにサーバーをポーリングすることで構成をリフレッシュします。構成の変更が検出された時点で、その変更内容が永続化されます。接続情報が変更された場合は、既存の接続を終了してから、新しい接続が作成されます。
WebGateの構成には、エージェントのアイデンティティに関する情報、エージェント資格証明、エージェント・サーバー・セキュリティ・コンテキストおよび接続パラメータが含まれます。
保護されたリソース - これらは、Oracle Access Manager11gR1によって保護されたアプリケーションです(パートナ・アプリケーションとも呼ばれます)。これらのリソースへのアクセスは、Oracle Access Manager 11gR1のアクセス制御ポリシーに従って行われ、保護されたリソースのアクセス・パスにデプロイされたOracle Access Managerエージェント(WebサーバーにデプロイされたOracle Access Managerエージェント、アプリケーション・サーバーにデプロイされたJ2EEエージェントなど)によって制御されます。エージェントは、保護されたアプリケーションへのアクセスをセキュリティ・ポリシーに基づいて制御するエンティティです。リソース・アクセス・パスに配置されたエージェントは、すべてのリソース・アクセス・リクエストをインターセプトし、リソースを保護するセキュリティ・ポリシーを適用します。
アクセス・サーバー - コア・ランタイム・アクセス管理サービスを提供するサーバー・サイド・コンポーネントです。これは、コアOracle Access Managerサービスを実現するイベントベースの設計パターンを使用しています。アクセス・サーバーは、EARファイルとしてパッケージ化されたJ2EEアプリケーションであり、Javaクラスに加えてサーブレットとJSPで構成されています。これは、様々なアイデンティティ・プロバイダ(IDP)サービスを提供します。Oracle Access Manager 11gR1のアクセス・サーバーは、シングル・サインオン、認証、および認可サービスを提供します。
JMX Mbean - ランタイムMBeanは、アクセス・サーバー・パッケージの一部としてパッケージ化されています。構成Mbeanは、スタンドアロンWARファイルとしてパッケージ化されています。
WebLogic 11g SSPIプロバイダは、Access Java Access JDKとともにSSPIインタフェースを実現するJavaクラスで構成されています。AccessGateは、Pure Java Access JDKを使用して構築されています。
管理コンソール - Oracle Access Manager管理コンソールは、管理コンソールをホストするJ2EEアプリケーションであり、Oracle Access Manager 11gR1デプロイメントを管理するための管理や構成などのサービスを提供します。Oracle Access Manager 11gR1では、このコンポーネントはWebLogic Administration Serverにデプロイする必要があります。
WebLogic Scripting Tool (WLST)は、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。Oracle Access Manager 11gR1デプロイメントの管理の一部は、コマンドラインからサポートされます。
Fusion Middleware ControlおよびEnterprise Manager Grid Control - Oracle Access Manager 11gR1は、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。
Coherence分散オブジェクト・キャッシュ - Oracle Access Manager 11gR1コンポーネントは、このインフラストラクチャに依存して、変更をリアルタイムに伝播します。
外部資格証明コレクタは、一連のJSPです。
Oracle Access Manager Proxyは、Apache MINAサーバーのカスタマイズ・バージョン(JCAアーキテクチャに基づく)であり、Javaサーバー・クラスに加えてMessageDrivenBeanおよびResourceAdapterが含まれています。これは、アクセス・サーバー・パッケージに含まれています。
Oracle Single Sign-On (OSSO)プロキシは、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。
データ・リポジトリ - Oracle Access Manager 11gR1は、次のようなアイデンティティ、ポリシー、パートナ、セッション、一時データを含む様々なタイプの情報を処理します。
アイデンティティ・データ用LDAP
構成およびパートナ・データ用ファイル
セッションおよび一時データ用Coherenceインメモリー
ポリシー・データはファイルまたはRDBMSに格納されます
Oracle Access Manager 10g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。
Oracle Single Sign-On Apacheモジュールは、Oracle HTTP Server Webサーバーにデプロイすることを意図したCベースのエージェントです。
Oracle Access Manager 11g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。
認証ユーザー・セッション情報は、Coherence分散オブジェクト・キャッシュを介して永続化されます。Oracle Access Manager 11gR1に対しては、Coherence分散オブジェクト・キャッシュ・インメモリー・モードを使用します。
Oracle Access Managerによって、ログイン処理中に、認証されていないユーザーに対して一時状態が作成されることがあります。この状態は、通常、Oracle Access Managerノード間でレプリケートされません。ログイン処理中のノードの障害の影響を防止するために、オプションでその状態を暗号化されたクライアントCookieに格納することができます。
認証されていないユーザーの一時状態をログイン処理中に格納するには、次の手順に従ってOracle Access Managerサーバー・パラメータRequestCacheTypeをBASICからCOOKIEに変更します。
次のコマンドを実行して、WLSTの環境を設定します。
DOMAIN_HOME/bin/setDomainEnv.sh
次のコマンドを発行して、WLSTを起動します。
Start WLST by issuing this command:
ORACLE_HOME/common/bin/wlst.sh
ドメインに接続します。
wls:/IDM_Domain/serverConfig> connect()
WebLogic管理ユーザー名とパスワードを入力し、管理サーバーのURLを次の形式で入力します。
t3://OAMHOST1.example.com:7001
次のコマンドを発行します。
wls:/IDM_Domain/serverConfig> configRequestCacheType(type="COOKIE")
次のコマンドを発行して、コマンドが動作したことを確認します。
wls:/IDM_Domain/serverConfig> displayRequestCacheType()
Oracle Access Manager管理対象サーバーを再起動します。
次に、Oracle Access Managerのリクエスト・フローを示します。
ユーザーが、Oracle Access Manager 11gR1によって保護されたWebリソースに、自身のWebブラウザを使用してアクセスしようとします。
Oracle Access Managerエージェント脚注1 によって、そのリクエストはインターセプトされ、ユーザーが認証済セッションを持っているかどうかの確認が試みられます。
これは、ユーザーの最初のアクセスであるため、ユーザーは認証のためにOracle Access Manager 11gR1アクセス・サーバーにリダイレクトされます。
アクセス・サーバーの資格証明コレクタ脚注2 ・コンポーネントによってログイン・フォームが表示されます。脚注3 ユーザーは、自身の資格証明をアクセス・サーバーに送信します。
アクセス・サーバーによって、ユーザーの資格証明が検証され、セキュリティ・トークンが生成されます。ユーザーは、ステップ1でアクセスを試みたリソースにリダイレクトされます。
Oracle Access Managerエージェントによってリクエストがインターセプトされ、セキュリティ・トークン(Cookie)が抽出されます。
次に、Oracle Access Managerエージェントによってアクセス・サーバーにバック・チャネル呼出し脚注4 (TCPを介したOAP)が行われ、セッションが検証され、リクエストが認可されます。
Oracle Access Managerによって、LDAPリポジトリを利用してユーザーが認証されます。
アクセス・サーバーによって、そのWebリソースの構成済ポリシーに対してユーザーの権限が検証されます。
アクセス・サーバーは、WebGateリクエストに応答し、そのアクセスが許可されることを示します。
Oracle Access Managerエージェントによってリクエストの転送が許可されます。脚注5
ユーザーは、ステップ1でアクセスを試みたWebリソースにアクセスできるようになります。
アクセス・サーバーと管理コンソールは、WebLogic Serverの提供するユーザー・インタフェースおよびコマンドライン・ツールから起動できます。
アクセス・サーバーは、障害の検出のためにロード・バランサで使用できるヘルス・チェック・リクエスト(HTTPを介したpingリクエスト)をサポートしています。
Oracle Access Managerエージェントは、保護されたアプリケーション環境に常駐するネイティブ・アプリケーションです。OAM 11gR1の一部として提供されているツールはありませんが、環境固有のツールが使用可能な場合は、それが前述の目的で使用されます。
Oracle Access Manager 11gR1は、サーバー・サイド・メトリック用(DMSを使用)にインストゥルメント処理されており、この情報は管理コンソールに公開されます。コンポーネントの監視のかわりとして、DMSメトリック収集を使用してエージェントおよびサーバー・コンポーネント・メトリックを監視できます。さらに、Oracle Access Manager 11gR1は、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。
アクセス・サーバーは、起動時にバックエンド・リポジトリへの接続を初期化します。リポジトリに到達不能な場合、アクセス・サーバーはリポジトリへの接続を再試行します。この接続の再試行には指数関数的に増加するタイムアウトが使用されます。タイムアウトの上限は構成可能です。
アクセス・サーバーは、バックエンド接続が停止した場合はローカルにキャッシュしたデータに基づいてサービスの継続性を提供します。これは、キャッシュが失効するか、バックエンド接続が復活するまで継続されます。
Oracle Access Managerの構成アーティファクトには、次のファイルが含まれています。
DOMAIN_HOME/config/fmwconfig/oam-configuration.xml
構成ファイル。インスタンス固有の情報が含まれています。
DOMAIN_HOME/config/fmwconfig/oam-policy.xml
DOMAIN_HOME/config/fmwconfig/.oamkeystore
これは、対称鍵および非対称鍵の格納に使用されます。
DOMAIN_HOME/config/fmwconfig/component_events.xml
監査定義に使用されます。
DOMAIN_HOME/config/fmwconfig/jazn-data.xml
管理コンソールの権限に使用されます。
DOMAIN_HOME/config/fmwconfig/servers/インスタンス名/logging.xml
ロギング構成に使用されます。
DOMAIN_HOME/config/fmwconfig/servers/インスタンス名/dms_config.xml
トレース・ロギングに使用されます。
DOMAIN_HOME/config/fmwconfig/cwallet.sso
パスワードに使用されます。
Oracle Access Managerは、次のものに対して外部ランタイム依存性があります。
LDAPベースのアイデンティティ・ストア
ユーザー・アイデンティティ・リポジトリ
ユーザー/ロールAPIによって抽象化されるLDAPアクセス
|
注意: Oracle Access Managerは、常に1つのアイデンティティ・ストアに接続します。そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Oracle Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。 |
OCSPレスポンダ・サービス
リアルタイムX.509認証検証
RDBMSポリシー・ストア
ポリシー(認証および認可)リポジトリ
OAMポリシー・エンジンによって抽象化されるRDBMSアクセス
Oracle Identity Manager (OIMベースのパスワード管理が有効化されている場合)
Oracle Identity Managerは、パスワード管理サービスを提供するために使用され、Oracle Access Manager 10g Identity Serverのかわりとなります。
Oracle Identity Managerポリシー・ストア(Oracle Identity Managerベースのパスワード管理が有効化されている場合)
構成、メタデータなどを格納するために使用されるOblixスキーマ要素を含むLDAPリポジトリ
Oracle Adaptive Access Manager (Oracle Adaptive Access Managerの拡張認証スキームが選択されている場合)
Oracle Identity Federation (Oracle Identity Federationの認証スキームが選択されている場合)
この項では、Oracle Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
図8-13は、Oracle Access Managerの高可用性アーキテクチャを示しています。
図8-13では、着信認証リクエストは、ハードウェア・ロード・バランサによって受信されてからWeb層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohsが使用されてWebLogic管理対象サーバーにリクエストが転送されます。
ロード・バランシング・ルーターは、HTTPトラフィックに対してのみセッション・スティックネスを使用する必要があります。OAPトラフィックは、ロード・バランシング・ルーターを使用しません。そのため、OAPトラフィックに対してはセッション・スティックネスは必要ありません。
他のOracle HTTP Serverからアクセスされ、アクセスが制限されているリソースを持つアプリケーションには、WebGate、Oracle Single Sign-On Serverエージェント(mod_ossoエージェント)、またはカスタム・エージェントを構成する必要があります。WEBHOST3上のWebGateは、OAPを使用してアプリケーション層のOAMHOST1およびOAMHOST2上のアクセス・サーバーと通信します。WEBHOST3は、アプリケーションWebサーバーであり、認証のためにHTTPリダイレクトを使用して、リクエストをロード・バランサへ、そしてWEBHOST1およびWEBHOST2にルーティングします。高可用性デプロイメントにするために、オプションでWEBHOST3と同じコンポーネントを持つホストをもう1つ(たとえばWEBHOST4)を構成できます。
OAMHOST1およびOAMHOST2は、Oracle Access Serverアプリケーションをホストする管理対象サーバーをデプロイします。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。
Oracle WebLogic管理サーバーは、OAMHOST1上で実行され、WebLogic管理コンソールとOracle Enterprise Manager Fusion Middleware Control、およびOracle Access Managerコンソールをデプロイします。管理サーバーは、OAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAMHOST1が使用不可になった場合に、管理サーバーをOAMHOST2上で手動で起動できます。
ディレクトリ層で、仮想IP ovd.example.comは、Oracle Virtual DirectoryリクエストをOVDHOST1とOVDHOST2にルーティングするように設定されます。OVDHOST1とOVDHOST2は、アクティブ/アクティブのOracle Virtual Directoryクラスタを構成します。仮想IP oid.example.comは、Oracle Internet DirectoryリクエストをOIDHOST1とOIDHOST2にルーティングするように設定されます。OIDHOST1とOIDHOST2は、アクティブ/アクティブのOracle Internet Directoryクラスタを構成します。
Oracle RACデータベースは、データ層における高可用性を提供します。
Oracle Access Manager 11gR1では、WebLogic ServerドメインごとにサポートされるOracle Access Managerクラスタは1つのみです。さらに、Oracle Access Managerクラスタは、複数のWebLogic Serverドメインにわたることはできません。
単一インスタンスのOracle Access Manager 11gR1デプロイメントは、次の高可用性要件を満たします。
ロード処理
外部接続管理と監視
リカバリ
フォルト包含
フォルト診断
管理サーバーのオフライン
複数インスタンスのOracle Access Manager 11gR1デプロイメントは、さらに次の高可用性要件を満たします。
冗長性
クライアント接続のフェイルオーバー/継続性
クライアントのロード・バランシング
状態管理
インバウンドHTTP接続の場合は、外部ロード・バランシング・ルーターの使用をお薦めします。LDAPサーバー(またはOAMポリシー・エンジンPDP/PIP)へのアウトバウンド外部接続はロード・バランシングされ、接続フェイルオーバーに対してもサポートされます。Oracle Access Managerエージェントは、複数のアクセス・サーバーにわたる接続をロード・バランシングできます。
Oracle Access Managerエージェントは、アクセス・サーバーへの永続TCP接続を開きます。これには、TCP接続の早すぎる終了を回避するためにファイアウォール接続タイムアウトを十分大きい値にする必要があります。
アクセス・サーバーとOracle Access Manager管理コンソールは、ポリシー評価および管理のために、OAMポリシー・エンジンと連動します。OAMポリシー・エンジンは、ポリシー・リポジトリとしてのデータベースに内部依存します。データベースの相互作用はOAMポリシー・エンジン内にカプセル化され、Oracle Access Managerからは、その接続構成情報のみ管理できます。Oracle Access ManagerとOAMポリシー・エンジン間の相互作用の高可用性の特性は、次のとおりです。
データベース接続情報は、Oracle Access Managerインスタンス間で同期されるOracle Access Manager構成ファイルで構成されます。データベース接続情報が実行時に変更された場合、アクセス・サーバー・インスタンスがOESを再初期化し、変更のアクティブ化を完了します。
データベース通信はOAMポリシー・エンジン内で管理され、通常、Oracle Access ManagerとOAMポリシー・エンジンの相互作用からは分離されます。ただし、Oracle Access Managerサーバー・インスタンスの最初の起動は、データベースに到達不能な場合、失敗します。OAMポリシー・エンジンのブートストラップの障害はOracle Access Managerによって致命的として処理され、起動操作は中断されます。
一時的なデータベースの使用不能は、OAMポリシー・エンジン・ポリシー評価サービスによって透過的に許容され、Oracle Access Managerサーバー・ランタイムは中断されることなく継続的に機能します。最初のOAMポリシー・エンジンのブートストラップの後、データベースが到達不能でも、Oracle Access Managerインスタンスは再起動できます。OAMポリシー・エンジンはそのローカルにキャッシュされたポリシーに対して処理を継続します。
Oracle Access Managerポリシー管理インタフェース(Oracle Access Manager管理コンソールおよびCLIツール内)は、OAMポリシー・エンジン管理サービス・インタフェースからみてデータベースが到達不能である場合に失敗します。操作は後で再試行できますが、管理操作に対して自動化された再試行は提供されていません。
データベース・リポジトリでポリシーが変更されると、Oracle Access Managerサーバー・ランタイムのOAMポリシー・エンジン・レイヤーが、(Oracle Access Managerの構成で構成される)構成可能なOAMポリシー・エンジン・データベース・ポーリング間隔内でその変更を取得し、アクティブ化します。ポリシー変更の肯定応答を、各Oracle Access Managerサーバー・ランタイムから受信する必要があります。それ以外の場合は、そのポリシー変更はアクティブ化に成功したとみなされません。管理者は、Oracle Access Manager管理コンソールを使用して、サービスから、ポリシー・アクティブ化が失敗したOracle Access Managerインスタンスを削除できます。
高可用性アーキテクチャでは、Oracle Access Managerサーバーは、Oracle WebLogicクラスタにデプロイされます。このクラスタには、その一部として少なくとも2つのサーバーが存在します。
デフォルトでは、Oracle WebLogic Serverによって、このアプリケーションの起動、停止、監視および様々なライフサイクル・イベントの監視が行われます。Oracle Access Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
高可用性環境では、WebLogicノード・マネージャはOracle WebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。
Oracle Access Managerが使用する標準Java EEアーティファクトは、Oracle Access ManagerがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle Access Managerコンポーネントで使用されるライブラリを同期します。
さらに、Oracle Access Managerのアプリケーション・レベルの構成は、Oracle Access Managerリポジトリに格納されます。すべてのクラスタ・メンバーへのOracle Access Managerの構成変更の伝播は、Coherence分散オブジェクト・キャッシュを活用する配布メカニズムに基づきます。すべてのOracle Access Managerコンポーネントは、変更イベントをCoherenceレイヤーから通知されて取得します。変更の原子性を確保するために、Oracle Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。
Oracle Access Managerの構成は、クラスタ内のすべてのインスタンスに適用されます。Oracle Access Manager 11gでサポートされる前述の構成(インスタンス固有の構成)の例外は、Oracle Access Managerプロキシ・ホスト、Oracle Access Managerプロキシ・ポート、およびインスタンス固有のCoherence構成(Well Knownアドレス(WKA)が使用されている場合)のみです。プロキシ・ホストのIPアドレスおよびプロキシ・ポートは、構成ファイルに格納されます。Oracle Access Managerプロキシ・ポートは、エージェントからのOAPリクエストのエンドポイントです。Coherence WKAのIPアドレスも、構成ファイルに格納されます。Coherence WKAは、Oracle Access Manager固有のトラフィックを受信する権限を付与されたCoherenceノードを判別するために使用されます。oam-configuration.xmlファイルは、この構成情報を格納する構成ファイルです。
Oracle Access Managerプロキシのクライアントが、この仮想IP(論理IP)を使用してサービスにアクセスするように構成できます。
Oracle Access Managerプロキシは、論理IPおよびコンポーネント・インスタンスが、同様に構成された他の物理的に異なるマシンに移行されている場合に、デプロイできます(そして、そのクライアントは依然としてサービスにアクセスできます)。
アクセス・サーバー・インスタンスの追加および削除は、クラスタ内の他のOracle Access Manager Access Serverインスタンスに対して透過的です。ただし、特定のアクセス・サーバーの削除が、エージェントのロード・バランシングとフェイルオーバーの特性に影響を与えないように注意してください。
Oracle Access Manager Access Serverを再起動しても、クラスタ内の他の実行中のコンポーネントやメンバーには影響ありません。
オンライン・アプリケーション・デプロイメントによって問題が発生することはありません。
この項では、Oracle Identity Managementの高可用性クラスタのデプロイメントでコンポーネントがどのようにして障害から保護されるかを説明します。この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。
WebLogic Serverインフラストラクチャにより、Identity Managementサービス・インフラストラクチャ・システムは、あらゆるプロセス障害から保護されます。
また、次の機能もOracle Access Managerの高可用性構成を障害から保護します。
セッションの状態は、Coherence分散オブジェクト・キャッシュで保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。Coherenceはインメモリー・モードで使用されるため、この情報は、すべてのOracle Access Managerコンポーネントが同時に再起動された場合は保持されません。
アクセス・サーバーで障害が発生した場合、そのサーバーへの永続接続を持つWebGateは、接続がタイムアウトするまで待機し、その後にセカンダリ(バックアップ)アクセス・サーバーに切り替えます。未処理のリクエストは、セカンダリ・サーバーにフェイルオーバーされます。
Oracle Access Manager Access Serverは、ハート・ビート・チェック(HTTPを介したpingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視し、アプリケーションが実行されていない場合は再起動することができます。
WebLogic Serverノードで障害が発生した場合、外部接続のフェイルオーバーは、構成、再試行のタイムアウトおよび再試行回数に基づいて行われます。Oracle Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。
ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、それはセッション状態をCoherence分散オブジェクト・キャッシュから取得し、処理を実行します。
バック・チャネルOAPバインディングでは、フェイルオーバーのためにプライマリ/セカンダリ・モデルが使用されます。フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。
接続の存続時間が期限切れした場合、保留中のリクエストは接続が終了する前に完了できます。接続オブジェクトは、プールに返されます。
別のサービスから例外を受信した場合、Oracle Access Managerは、外部接続リクエストを再試行します。再試行の回数は構成可能であり、no retriesに設定することもできます。
ユーザーが保護されたリソースへのアクセスを最初に要求したときに、Oracle HTTP ServerによってOracle Access Serverとの接続が確立され、最初のユーザー認証の後、Oracle Access Managerエージェント(たとえば、WebGate)によって、2つのアクセス・サーバーに対してブラウザCookieにエントリが配置されます。この時点から、クライアント・アプリケーションは、Cookieで識別されるアクセス・サーバーの1つと直接通信します。そのアクセス・サーバーが使用不可になった場合、アプリケーションは、Cookieで識別される代替アクセス・サーバーと通信します。両方のサーバーが使用不可になった場合は、ユーザーの再認証が必要になります。
WLS_OAMxサーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。
HTTP Serverからの処理中のリクエストはタイムアウトして、新しいリクエストは他のWLS_OAMxサーバーに送られます。障害が発生したノードでサーバーが正常に再起動されると、Oracle HTTP Serverは、受信したリクエストのサーバーへのルーティングを再開します。
|
注意: Oracle Access Managerサーバーは、ハートビート・チェックもサポートしています。このハートビートによって、アクセス・サーバーがリクエストを処理できるかどうかを判別します。これにより、次のようなものがチェックされます。
ハートビート・チェックに成功した場合、アクセス・サーバーはリクエストに対してサービス提供可能であり、リクエストがそれに送信されます。ハートビート・チェックに失敗した場合、リクエストは、問題のあるアクセス・サーバーにルーティングされることはありません。 |
ノード障害は、WebLogic Serverの障害と同じ方法で処理されます。
Oracle Access Managerサービス・インフラストラクチャは、マルチ・データ・ソースの使用によりデータベースの障害から保護されます。通常、これらのマルチ・データ・ソースは、システムの初期設定時に構成されます(Oracle Fusion Middleware構成ウィザードで、インストール時にこれらのマルチプールを直接定義できます)。これらのソースによって、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。
Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第5.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
この項では、Oracle Security Token Service (OSTS)の高可用性について説明します。
Oracle Security Token Serviceは、共有Webサービス(JAX-WS)であり、様々なIdentityドメインとインフラストラクチャ層との間での信頼を仲介する機能が統合された標準ベースのメカニズムを提供します。Oracle Security Token Serviceは、Webサービス・コンシューマ(WSC)とWebサービス・プロバイダ(WSP)との間での信頼を仲介し、プロバイダとコンシューマに対してセキュリティ・トークンのライフサイクル管理サービスを提供します。Oracle Security Token Serviceでは、標準化されたインタフェースのセットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。
Oracle Security Token Serviceの高可用性デプロイメントは、OAMに依存します。Oracle Access Manager (OAM)アプリケーションには、Oracle Security Token Serviceのサーバー・ランタイムが含まれています。Oracle Security Token Serviceの高可用性デプロイメントは、OAMがなければ成り立ちません。Oracle Access ManagerとOracle Security Token Serviceは、どちらもOAM J2EEアプリケーションEARファイルに同梱されていて、WebLogicドメイン内の同じ管理対象サーバーに両方ともにインストールされデプロイされます。さらに、Oracle Security Token Serviceは、Oracle Access Managerコンソールに統合されます。
Oracle Security Token Serviceの管理と構成の詳細は、Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイドを参照してください。
Oracle Security Token Serviceの主な用語と概要
Oracle Access Managerを使用するOracle Security Token Serviceについて
Oracle Security Token Serviceのデプロイメントについて
Oracle Security Token Serviceの管理について
Oracle Security Token Serviceの実装シナリオ
Oracle Security Token Serviceの設定値と設定の管理
Oracle Security Token Serviceの証明書と鍵の管理
テンプレート、エンドポイントおよびポリシーの管理
Token Serviceパートナとパートナ・プロファイルの管理
パッチの適用については、Oracle Access Managerの管理の第11.1.1.3.0項から第11.1.1.6.0項を参照してください。
この項の内容は次のとおりです。
次の図は、高可用性アーキテクチャのOracle Security Token Serviceを示しています。
図8-14 Oracle Security Token Serviceの高可用性アーキテクチャ
この図は、Oracle Access Manager/Oracle Security Token Serviceコンポーネントの2ノード・デプロイメントを示しています。この項では、Oracle Security Token Serviceの高可用性デプロイメントについて詳しく説明します。これの一部としてデプロイされるOracle Access Managerの全体的な高可用性アーキテクチャについては、第8.8.2.1項「Oracle Access Managerの高可用性アーキテクチャ」を参照してください。
Security Token Serviceは、WS-Trustプロトコルのサポートを実装するサーバー側コンポーネントです。
ロード・バランサはトークン・リクエストを受信すると、そのリクエストをSecurity Token Service (STS)にルーティングします。
Oracle Access Manager管理コンソールは、Oracle Security Token Serviceデプロイメントを管理するためのサービスを提供するJ2EEアプリケーションです。OAMデプロイメントの一部として、管理コンソールをWeblogic管理サーバーにデプロイする必要があります。
Oracle Security Token Serviceの場合、各WLSドメインで1つのOracle Security Token Serviceクラスタをサポートします。OAM/Oracle Security Token Serviceクラスタは、WebLogic Serverドメイン間にまたがることはできません。
Oracle Security Token Serviceは、主にOASIS WS-Trustプロトコルを基盤とします。ただし、Oracle Security Token Serviceは、SOAPメッセージに含まれるその他のWS-*プロトコルの処理を、JAX-WSスタックに委任します。
HTTP/SOAPのインバウンド接続には、外部ロード・バランサを使用することをお薦めします。LDAPに対するアウトバウンド外部接続は、接続フェイルオーバーのサポートとともにロード・バランシングされます。
WS-Trustプロトコルを実装するWebサービス・クライアントは、トークンの発行および検証のために、Oracle Security Token Serviceと対話します。STSサーバーと対話するように設計されたクライアント(OWSMクライアントなど)は、リライイング・パーティへのWebサービス・コールの一環として、Oracle Security Token Serviceを呼び出すことができます。
このクライアント接続は、次のように処理されます。
Webサービス・クライアントは、httpまたはhttpsによってSOAPメッセージを送信します。
WSSプロトコルによって、メッセージを保護します。ペイロードには、実行する操作、発行または検証するトークンの種類、およびトークンの特性についての追加情報を示すWS-Trustリクエスト(RST)が格納されます。
サーバーはリクエストを処理して、そのリクエストをサーバーが受信したチャネルと同じチャネルでレスポンスを送信します。
WSSプロトコルによって、メッセージを保護します。処理が成功したときには、ペイロードにWS-Trustレスポンス(RSTRC)が格納されます。エラーが発生したときには、SOAP障害が格納されます。
Oracle Security Token Serviceアクセス・サーバーの各インスタンスは、他のインスタンスのピアになりますがインスタンス間の通信はありません。サーバーがリクエストを受信できるようになる前に、すべての初期化が組込のスロット機能と同時に行われるため、WebLogic ServerはOracle Security Token Serviceアクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく急増する条件を適切に処理します。
クラスタが停止すると、Oracle Security Token Serviceは新しいリクエストを拒否し、アクセス・サーバーのアプリケーションが停止する前に既存のリクエストを完了できるようにします。強制停止が行われた場合、Oracle Security Token Serviceはその強制停止によって破損または無効になったデータをリカバリできます。
構成の変更は、Coherence分散オブジェクト・キャッシュを利用する分散メカニズムに基づいて、すべてのクラスタ・メンバー伝播されます。Coherenceレイヤーは、すべてのOracle Security Token Serviceコンポーネントに変更イベントを通知します。その後、このコンポーネントはそれらの変更を取り込みます。OAMコンポーネントは、そのコンポーネントの構成全体を変更が行われる度にリロードします。
|
注意: アクセス・サーバーのインスタンスの追加または削除は、クラスタ内の他のOracle Security Token Serviceインスタンスに対して透過的になります。特定のOracle Security Token Serviceサーバーの削除が、ロードに影響しないことを確認してください。 |
この項では、Oracle Security Token Serviceコンポーネントの特性と、次の項目について説明します。
起動時に、OAMとOracle Security Token Service Serverは、バックエンド・リポジトリへの接続を初期化します。このリポジトリにアクセスできない場合、OAMとOracle Security Token Serviceサーバーは、指数関数的に増加するタイムアウトを使用してリポジトリへの接続を再試行します(このタイムアウトは上限を構成できます)。
OAMとOracle Security Token Service Serverは、バックエンドの接続が停止したときには、ローカルにキャッシュしたデータに基づいてサービスの持続性を提供します。サービスは、キャッシュの有効性が失われるか、バックエンドの接続が回復するまで持続されます。
次の図は、Oracle Security Token Serviceのランタイム・プロセスを示しています。
Oracle Security Token Serviceのランタイム・プロセスは、次の説明のように動作します。
Webサービス・コンシューマ(WSC)は、WSPが要求するセキュリティ・トークンのタイプについてのWeb Services-Trust (WS-Trust) Request Security Token (RST)メッセージを送信します。クライアントの認証は、トランスポート・レイヤーの認証を使用するか、WSSトークンをRSTメッセージにバインドすることで行われます。
Security Token Service (STS)はRSTメッセージを検証し、リクエストを認証してから、要求された操作の権限を付与します。
RSTメッセージによって指定されたメタデータに応じて、適切なセキュリティ・トークンが生成されます。ポリシー主導型の交換ユースケースでは、STSが適切なトークン生成ポリシーを検索し、該当するセキュリティ・トークンを生成します。
STSは、生成されたセキュリティ・トークンを格納するRSTメッセージを生成し、このメッセージをレスポンスとしてWSCに送信します。
|
注意: WSPによるセキュリティ・トークンの検証は、トークンのタイプに応じて異なります。STSが信頼の仲介者としてのみ機能する場合は、Kerberosなどの基幹セキュリティ・インフラストラクチャに対する検証が実行されます。 |
アクセス・サーバー(Oracle Security Token Serviceのデプロイ先)と管理コンソールは、どちらもJ2EEアプリケーションであるため、アプリケーション・サーバーが提供するユーザー・インタフェースやコマンドライン・ツールから起動できます。
J2EEのコンポーネントとサブコンポーネントには、次のものがあります。
STS - イベント・ベースの設計パターンであり、コアOracle Security Token Service 11g-PS1を実装します。WARアプリケーションとしてOAM EARファイルにパッケージ化されています。WSプロバイダ・サーブレットとJavaクラスが含まれています。STS Webアプリケーションは、/stsルート・パスにバインドされます。
管理コンソール - ADF/IDMシェルに基づくスタンドアロン・コンソールであり、EARファイルとしてパッケージ化されています。
JMX Mbeans - アクセス・サーバー・パッケージにパッケージ化されています。構成Mbeanは、スタンドアロンのJARファイルとしてパッケージ化されています。
WSLTコマンド - OAM/Oracle Security Token Serviceパッケージに含まれているJavaクラスで構成されています。
OWSMエージェント - WSSプロトコルのサポートを提供するWebサービスのインターセプタです。JRFに含まれます。
ORAProvider - JRF Webサービス・プロバイダです。
Oracle Security Token Serviceは、ステートレスのJ2EEアプリケーションですが、ユーザー名トークン用のNonceキャッシュがあります。OSTSはリプレイ攻撃を防止するために、Nonceが存在する場合は、提示されたユーザー名トークンを記録します。
Oracle Access ManagerとOracle Security Token Serviceは一組になるように構築され、構成やロギングなどのプロセスに同一のモジュールを使用します。Oracle Security Token Serviceの構成アーティファクトには、次のファイルが含まれます。
DOMAIN_HOME/config/fmwconfig/oam-config.xml — インスタンス固有の情報を格納する構成ファイルです。
DOMAIN_HOME/config/fmwconfig/oam-policy.xml — OES Micro SMが使用されていない場合にのみ存在します。
DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml — ロギング構成です。
DOMAIN_HOME/config/fmwconfig/cwallet.sso — パスワードです。
DOMAIN_HOME/config/fmwconfig/oamkeystore — OAM/Oracle Security Token Serviceが所有する鍵と証明書を格納するキーストアです。
DOMAIN_HOME/config/fmwconfig/amtruststore — X509証明書の検証に使用されるトラスト・アンカーを格納するキーストアです。
DOMAIN_HOME/config/fmwconfig/amcrl.jar — 証明書失効に使用するCRLを格納するzipファイルです。
DOMAIN_HOME/config/fmwconfig/default-keystore.jks — OWSMエージェントが使用する鍵と証明書を格納するOWSMキーストアです。また、WSS操作のためのX.509証明書の検証に使用されるトラステッド・アンカーも格納されます。
Oracle Security Token Serviceは、次の項目に依存します。
LDAPベースのアイデンティティ・ストア
ユーザー・アイデンティティ・リポジトリ
ユーザー/ロールAPIによって抽象化されるLDAPアクセス
|
注意: Oracle Access Managerは、常に1つのアイデンティティ・ストアに接続します。そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Oracle Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。 |
OCSPレスポンダ・サービス
リアルタイムX.509認証検証
RDBMSポリシー・ストア
ポリシー(認証および認可)リポジトリ
OAMポリシー・エンジンによって抽象化されるRDBMSアクセス
Oracle Security Token Serviceの高可用性は、Oracle Access Managerの一部として構成されます。Oracle Security Token Serviceシステムのすべての構成は、Oracle Access Managerコンソールを使用して実行します。OAMを構成する手順は、第8.8.4項「Oracle Access Managerの高可用性の構成手順」を参照してください。
個別のOracle Security Token Serviceサーバー上のOracle Security Token Serviceのエンドポイントが稼働状態であり実行中であることを検証できます。これを実行するには、Oracle Security Token ServiceのエンドポイントのWSDLドキュメントに、次のように直接アクセスします: http(s)://[hostname:port]/sts/[ENDPOINT]?WSDL
[ENDPOINT]の部分は、既存の公開エンドポイントに置換してください。
この項では、高可用性環境におけるOracle Security Token Serviceのフェイルオーバーの特性について説明します。
Oracle Access Managerアクセス・サーバーは、ハートビート・チェック(HTTPによるPingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視して、そのアプリケーションを必要に応じて再起動できます。
WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Oracle Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。
ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出すると、後続のクライアント接続はアクティブなインスタンスにルーティングされます。このインスタンスは、セッション状態をCoherence分散オブジェクト・キャッシュから取得して処理を継続します。
フロント・チャネルHTTPバインディングは、フェイルオーバーにロード・バランシング・ルーターを使用します。
別のサービスから例外を受信した場合、Oracle Access Managerは、外部接続リクエストを再試行します。再試行の回数は構成可能であり、no retriesのオプションもあります。
詳細は次のトピックを参照してください。
OAM/Oracle Security Token Serviceアクセス・サーバーは、HTTPでPingリクエストを送信する方式によるハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャでは、アプリケーションを監視して、イベントが実行されていない場合にはアプリケーションを再起動できます。OAMアクセス・サーバーを再起動しても、その他のクラスタ・コンポーネントまたはメンバーに影響はありません。
Oracle Security Token Serviceは、デフォルトで有効化されています。Oracle Security Token Serviceを無効化するには、Oracle Access Managerコンソールを使用します。Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイドの使用可能なサービスの有効化または無効化に関する項を参照してください。
Oracle Security Token Serviceのログは、管理対象サーバーのログ・ファイルに記録されます。ただし、logging.xmlを編集すると、OSTS情報を個別のログ・ファイルdiagnostic.logに記録できます。このログファイルは、<DomainHome>/config/fmwconfig/servers/<servername>/sts/log/フォルダに格納されます。
Oracle Security Token Serviceをトラブルシューティングするために、Oracle Security Token Serviceのログ・ファイルを作成する手順は次のとおりです。
ファイルDomainHome/config/fmwconfig/servers/servername/logging.xmlを開きます。
次を、適切なセクションに追加します。
<log_handler name='sts-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='sts/log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
</log_handler>
<logger name='oracle.security.fed' level='TRACE:32'>
<handler name='sts-handler'/>
</logger>
すべてのログ・メッセージは、アプリケーションがデプロイされたWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。
WL_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
Oracle Security Token Serviceサーバーは、リプレイ攻撃などの偽のリクエストを検出できます。リプレイ攻撃は、リクエストからトークン・データを不正入手しようとして、同じトークンで別のリクエストを送信した場合に発生することがあります。この場合には、サーバーは2番目の偽のリクエストを検出します。2番目に発行された<Env: Body>に同一のトークンを持つリクエストは、Oracle Security Token Serviceサーバーに送られます。このサーバーは、UNTトークン・キャッシュを確認して、リプレイ攻撃を示すリクエストを拒否します。
この項では、Oracle Access Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAMサーバーに配布します。これらのOAMサーバーは、Oracle Real Application Clusters (Oracle RAC)データベースおよびオプションで外部LDAPストアと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。
この項の内容は次のとおりです。
Oracle Access Managerを高可用性のために構成する前に、次の手順を実行しておく必要があります。
データベースにOAMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。
OAMスキーマを作成するためのリポジトリ作成ユーティリティの実行手順は、第8.8.4.2項「データベースにOAMスキーマを作成するためのリポジトリ作成ユーティリティの実行」を参照してください。
OAMHOST1およびOAMHOST2にOracle WebLogic Serverをインストールします。
第8.8.4.3項「Oracle WebLogic Serverのインストール」の手順に従い、OAMHOST1およびOAMHOST2にOracle WebLogic Serverをインストールします。
OAMHOST1およびOAMHOST2にOracle Identity Management実行可能ファイルをインストールします。
第8.8.4.4項「Oracle Access Manager Application Tierのインストールと構成」の手順に従い、OAMHOST1およびOAMHOST2にOracle Identity Management実行可能ファイルをインストールします。
高可用性LDAP実装が使用可能であることを確認します。Oracle Internet Directoryのインストールと構成の詳細は、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。Oracle Virtual Directoryのインストールと構成の詳細は、第8.4.3項「Oracle Virtual Directoryの高可用性の構成手順」を参照してください。
データベース・リポジトリにOAMスキーマを作成するためのリポジトリ作成ユーティリティの実行手順は、第8.2.4.1項「リポジトリ作成ユーティリティの実行」を参照してください。
Oracle WebLogic Serverをインストールする前に、お使いのマシンが、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』に指定されているシステム、パッチ、カーネルなどの要件を満たしていることを確認します。
インストーラを起動し、次の手順を実行します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
ORACLE_BASE/product/fmw
|
注意: ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。 |
「次へ」をクリックします。
セキュリティ・アップデートが通知されるようにするために、連絡先情報を入力します。
「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択します。
「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
「完了」をクリックします。
この項では、Oracle Fusion MiddlewareコンポーネントをOAMHOST1およびOAMHOST2にインストールする方法について説明します。
この項では、Oracle Identity Managementソフトウェアを、前に作成したミドルウェア・ホーム・ディレクトリにインストールする手順について説明します。この手順を、OAMHOST1およびOAMHOST2で実行します。
Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。
次のようにOracle Fusion Middlewareのインストーラを起動します。
OAMHOST1> runInstaller
インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_<バージョン>のように入力します。
次の手順を実行します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
Oracleミドルウェア・ホーム: MW_HOMEのリストから前にインストールしたミドルウェア・ホームを選択します。例:
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ: idmを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。
「インストール完了」画面で「終了」をクリックします。
この項では、OAMHOST1にOracle Identity Managementドメインを作成します。
次のコマンドを実行して、構成ウィザードを起動します。
MW_HOME/oracle_common/common/bin/config.sh
次の手順を実行します。
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で、次を選択します。
「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
次の製品を選択します。
Oracle Enterprise Manager
Oracle JRF(デフォルトで選択)
Oracle Access Managerおよびデータベース・ポリシー・ストア
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、次を入力します。
ドメイン名: IDM_Domain
ドメインの場所: デフォルトを受け入れます。
アプリケーション・ディレクトリ: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択します。
JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。
「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAMインフラストラクチャを選択し、次の項目を入力します。
データ・ソース: OAM
サービス名: oam.example.com
ユーザー名: OAM_OAM (OAMがRCU接頭辞として使用されていたと想定)
パスワード: 前述のアカウント用のパスワード
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: OAMDBHOST1
インスタンス名: oamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: OAMDBHOST2
インスタンス名: oamdb2
ポート: 1521
「次へ」をクリックします。
「コンポーネント・スキーマのテスト」画面で、構成ウィザードはデータ・ソースの検証を試行します。
データ・ソースの検証が成功したら、「次へ」をクリックします。
失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「次へ」をクリックします。
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: OAMHOST1.example.com
Listen port: 7001
SSLリスニング・ポート: 適用なし
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、トポロジのOAMHOSTごとにエントリを作成します。つまり、OAMHOST1上で実行されているOAMサーバーに対して1つと、OAMHOST2上で実行されているOAMサーバーに対して1つ作成します。
OAM_SERVERエントリを選択し、そのエントリを次の値に変更します。
Name: WLS_OAM1
リスニング・アドレス: OAMHOST1.example.com
Listen port: 14100
2つ目のOAM_SERVERに対して、「追加」をクリックし、次の情報を入力します。
Name: WLS_OAM2
リスニング・アドレス: OAMHOST2.example.com
Listen port: 14100
「次へ」をクリックします。
「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前としてOAM_Clusterを入力します。
その他すべてのフィールドはデフォルトの設定のままにします。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。
右のウィンドウでクラスタ名OAM_Clusterをクリックします。
管理対象サーバーWLS_OAM1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。
管理対象サーバーWLS_OAM2に対しても同様に繰り返します。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジ内の各サーバーのマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を入力します。
名前: ホストの名前。ベスト・プラクティスは、DNS名(OAMHOST1)を使用することです。
ノード・マネージャ・リスニング・アドレス: マシン(OAMHOST1.example.com)のDNS名。
ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
OAMHOST2に対しても次のように手順を繰り返します。
名前: ホストの名前。ベスト・プラクティスは、DNS名(OAMHOST2)を使用することです。
ノード・マネージャ・リスニング・アドレス: マシン(OAMHOST2.example.com)のDNS名。
ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。
右のウィンドウでマシンOAMHOST1をクリックします。
左のウィンドウで管理対象サーバーWLS_OAM1をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAMHOST1に割り当てます。
右のウィンドウでマシンOAMHOST2をクリックします。
左のウィンドウで管理対象サーバーWLS_OAM2をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAMHOST2に割り当てます。
「次へ」をクリックします。
「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。
|
注意: 構成を変更するためにconfig.shスクリプトを2回実行することはできません。構成に追加の変更を行う場合は、別のツールを使用する必要があります(Fusion Middleware ControlのMBeansブラウザなど)。 |
この項では、OAMHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法について説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。
次の手順に従って、boot.propertiesファイルを作成します。
OAMHOST1で、次のディレクトリに移動します。
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
例:
cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security
テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUserpassword=adminUserPassword
|
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。 |
管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OAMHOST1の管理サーバーを起動します。
Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
WebLogic Server管理コンソール:
http://oamhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oamhost1.example.com:7001/em
weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。
この項では、OAMHOST1の起動手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:
OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
次のコマンドを発行してノード・マネージャを起動します。
OAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
OAMHOST1上のOracle Access Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oamhost1.example.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAM1をクリックします。
「起動」をクリックします。
「OK」をクリックし、サーバーを起動することを確認します。
次のURLにあるOAMコンソールに接続することによって実装を検証します。
http://OAMHOST1.example.com:7001/oamconsole
OAM管理コンソールのログイン・ページが表示され、WebLogic administratorアカウントを使用してログインできる場合、実装は有効です。
OAMHOST1において構成が完了すると、これをOAMHOST2に伝播できます。これを実行するには、OAMHOST1でpackスクリプトを使用してドメインをパックし、OAMHOST2でunpackスクリプトを使用してドメインを解凍します。
スクリプトは両方とも、MW_HOME/oracle_common/common/binディレクトリにあります。
OAMHOST1で、次のように入力します。
pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true
これにより、/tmpディレクトリにidm_domain.jarというファイルが作成されます。このファイルをOAMHOST2にコピーします。
OAMHOST2で、次のように入力します。
unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar
この項では、OAMHOST2を起動する手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:
OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
次のコマンドを発行してノード・マネージャを起動します。
OAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
OAMHOST2上のOracle Access Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oamhost2.example.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAM2をクリックします。
「起動」をクリックします。
「OK」をクリックし、サーバーを起動することを確認します。
次のURLを使用してOAMサーバーに接続することによって実装を検証します。
http://OAMHOST2.example.com:14100/oam
OAMログイン・ページが表示される場合、実装は有効です。この時点では、アクションが失敗したことを示すエラーがページに表示されることに注意してください。これは、ログイン・リクエストとしてではなくページに直接アクセスしたためであり、正常な動作です。
この項では、Oracle HTTP Serverと連携するためのOracle Access Managerの構成手順について説明します。
WEBHOST1およびWEBHOST2で、次のディレクトリにoam.confというファイルを作成します。
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
次の行を指定してファイルを作成します。
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName sso.example.com:7777
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
</Location>
</VirtualHost>
WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。
WEBHOST1>opmnctl stopall WEBHOST1>opmnctl startall WEBHOST2>opmnctl stopall WEBHOST2>opmnctl startall
デフォルトでは、Oracle Access Managerではローカル・サーバーにあるログイン・ページにリクエストに送信します。高可用性デプロイメントでは、この設定を変更してログイン・ページ・リクエストがローカル・バランサに送信されるようにする必要があります。
Oracle Access Managerにロード・バランサを認識させる手順は、次のとおりです。
次のURLで、Oracle Access Managerコンソールにweblogicユーザーとしてログインします。
http://IDMHOST1.example.com/oamconsole
「システム構成」タブをクリックします。
Access Managerの設定を開きます。
Access Managerの設定をダブルクリックします。
次の情報を入力します。
OAMサーバー・ホスト: sso.example.com
OAMサーバー・ポート: 7777
OAMサーバー・プロトコル: http
「適用」をクリックします。
管理対象サーバーWLS_OAM1およびWLS_OAM2を再起動します。
デフォルトでは、Oracle Access Managerは、組込みLDAPサーバーに含まれるそれ自体のLDAPストアを使用します。高可用性構成では、ディレクトリ・ストアとして外部LDAPディレクトリを使用することをお薦めします。この項では、外部LDAPストアの設定方法について説明します。
|
注意: この項で説明する手順を実行する前に、環境およびLDAPストアをバックアップしておくことをお薦めします。 |
アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。
Oracle Access Managerのためにディレクトリ・スキーマを拡張するには、OAMHOST1上で次のタスクを実行します。
環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
IDM_HOMEをIDM_ORACLE_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
次の項目を含む、プロパティ・ファイルextend.propsを作成します。
IDSTORE_HOST : idstore.example.com
IDSTORE_PORT : 389
IDSTORE_BINDDN : cn=orcladmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE:cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com
説明:
IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。非OIDディレクトリを使用している場合は、Oracle Virtual Directoryのホスト(IDSTORE.example.com)を指定します。
IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
IDSTORE_USERSEARCHBASEは、ユーザーを配置するアイデンティティ・ストアの場所です。
IDSTORE_GROUPSEARCHBASEは、グループを配置するアイデンティティ・ストアの場所です。
IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。
IDSTORE_SYSTEMIDBASEは、Oracle Identity Managerリコンシリエーション・ユーザーを配置するディレクトリの場所です。
IDSTORE_SYSTEMIDBASEは、メイン・ユーザー・コンテナに配置する必要のないユーザーを配置できるディレクトリにあるコンテナの場所です。このような事態はほとんどありませんが、その一例としてOracle Virtual DirectoryアダプタのバインドDNユーザーにも使用されるOracle Identity Managerリコンシリエーション・ユーザーがあげられます。
idmConfigToolコマンドを使用して、アイデンティティ・ストアを構成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
Linuxコマンドの構文:
idmConfigTool.sh -preConfigIDStore input_file=configfile
Windowsコマンドの構文:
idmConfigTool.bat -prepareIDStore input_file=configfile
例:
idmConfigTool.sh -preConfigIDStore input_file=extend.props
このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。
次に、コマンドの出力例を示します。
Enter ID Store Bind DN password : Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif The tool has completed its operation. Details have been logged to automation.log
ログ・ファイルを確認して、エラーや警告を修正します。
Oracle Access Managerが必要とするユーザーをアイデンティティ・ストアに追加する手順は、次のとおりです。
環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
IDM_HOMEをIDM_ORACLE_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
次の項目を含む、プロパティ・ファイルoam.propsを作成します。
IDSTORE_HOST : idstore.example.com
IDSTORE_PORT : 389
IDSTORE_BINDDN : cn=orcladmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
POLICYSTORE_SHARES_IDSTORE: true
OAM11G_IDSTORE_ROLE_SECURITY_ADMIN:OAMAdministrators
IDSTORE_OAMSOFTWAREUSER:oamLDAP
IDSTORE_OAMADMINUSER:oamadmin
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=vm,dc=oracle,dc=com
IDSTORE_NEW_SETUP:true
説明:
IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。
IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
IDSTORE_USERSEARCHBASEは、ユーザーが格納されるディレクトリの場所です。
IDSTORE_GROUPSEARCHBASEは、グループが格納されるディレクトリの場所です。
IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。
POLICYSTORE_SHARES_IDSTOREは、ポリシー・ストアとアイデンティティ・ストアが同じディレクトリに存在する場合にはtrueを設定します。そうでない場合は、falseを設定します。
IDSTORE_OAMSOFTWAREUSERは、LDAPに作成されるユーザーです。これは、Oracle Access Managerが実行中にLDAPサーバーに接続するために使用されます。
IDSTORE_OAMADMINUSERは、Oracle Access Manager管理者として作成するユーザーの名前です。
IDSTORE_SYSTEMIDBASEは、SystemIDbaseのディレクトリの中にある場所で、必ずcn=systemidsで始まります。
IDSTORE_NEW_SETUPは、常にTRUEを設定します。
idmConfigToolコマンドを使用して、アイデンティティ・ストアを構成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
Linuxコマンドの構文:
idmConfigTool.sh -prepareIDStore mode=OAM input_file=configfile
Windowsコマンドの構文:
idmConfigTool.bat -prepareIDStore mode=OAM input_file=configfile
例:
idmConfigTool.sh -prepareIDStore mode=OAM input_file=oam.props
このコマンドを実行すると、IDストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。
次に、コマンドの出力例を示します。
Enter ID Store Bind DN password : Apr 5, 2011 3:53:28 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_schema_add.ldif Apr 5, 2011 3:54:12 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_schema_index_add.ldif Apr 5, 2011 3:55:10 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_pwd_schema_add.ldif Apr 5, 2011 3:55:11 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oim_pwd_schema_add.ldif *** Creation of Oblix Anonymous User *** Apr 5, 2011 3:55:11 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_10g_anonymous_user_template.ldif Enter User Password for oblixanonymous: Confirm User Password for oblixanonymous: Apr 5, 2011 3:55:53 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_group_member_template.ldif The tool has completed its operation. Details have been logged to automation.log
ログ・ファイルを確認して、エラーや警告を修正します。
idmConfigToolコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Management Suite統合概要を参照してください。
ユーザー・アイデンティティ・ストアを作成する手順は、次のとおりです。
次のURLのOracle Access Managerコンソールに移動します。
http://adminvhn.example.com:7001/oamconsole
WebLogic管理ユーザーを使用してログインします。
「ユーザー・アイデンティティ・ストアの追加」をクリックして、次の情報を入力します。
ストア名: LDAP_DIR
ストア・タイプ: OVD
説明: ディレクトリ・ストアの説明を入力します
SSLの有効化: これは、SSLを使用してディレクトリと通信する場合に選択します
場所: 場所を入力します(例: ovd.example.com:389)
バインドDN: LDAPストアを検索する権限を与えるユーザーを入力します。例: cn=orcladmin
パスワード: oracleadminパスワードを入力します
ユーザー名属性: たとえば、uidとします。
ユーザー検索ベース: LDAPストアのユーザーの場所を入力します。例: cn=Users,dc=mycompany,dc=com
グループ名属性: 例: orclguid
グループ検索ベース: LDAPストアのグループの場所を入力します。例: cn=Groups,dc=mycompany,dc=com
OAM管理者ロール: OAMAdministrator
「適用」をクリックします。
「接続テスト」をクリックし、LDAPサーバーへの接続を検証します。
LDAPアイデンティティ・ストアを定義したので、プライマリ認証ストアとして設定する必要があります。これを行うには、Oracle Access Managerコンソールで次の手順を実行します。
「システム構成」タブをクリックします。
ナビゲーション・ペインから「データ・ソース - ユーザー・アイデンティティ・ストア」を選択します。
LDAP_DIRをクリックします。
「アクション」メニューから「開く」を選択します。
「デフォルト・ストアとして設定」をクリックします。
「システム・ストアとして設定」をクリックします。
「アクセス・システム管理者」の追加[+]アイコンをクリックします。
検索名フィールドにOAM*を入力して、「検索」をクリックします。
検索結果からOAMAdministratorを選択して、「選択済の追加」をクリックします。
「適用」をクリックします。
「システム管理者の検証」ウィンドウで、OAM管理者のユーザー名とパスワード(例: oamadmi)を入力します。
「検証」をクリックします。
「接続テスト」をクリックして接続をテストします。
デフォルトでは、Oracle Access Managerは、ユーザーの検証に統合LDAPストアを使用します。LDAP認証モジュールを更新して、そのモジュールが新しい外部LDAPストアに対してユーザーを認証できるようにします。
LDAP認証モジュールが外部LDAPを使用するように更新する手順は、次のとおりです。
「システム構成」タブをクリックします。
「Access Managerの設定」→「認証モジュール」→「LDAP認証モジュール」を選択します。
「LDAP」をクリックします。
「アクション」メニューから「開く」を選択します。
「ユーザー・アイデンティティ・ストア」をLDAP_DIRに設定します。
「適用」をクリックします。
管理対象サーバーの管理サーバー、WLS_OAM1およびWLS_OAM2を再起動します。
http://oamhost1.example.com:7001/oamconsoleでOracle Access Managerコンソールにoamadminとしてログインすることで、構成を検証します。
高可用性環境では、Oracleでは、Oracle Coherenceを使用して構成ファイルの同期を保ちます。Oracle Coherenceは、デフォルトではポート9095を使用しますが、これはOracle Access Managerコンソールを使用して変更できます。
URL http://admin.example.com/oamconsoleを使用して、コンソールにログインし、次の手順を実行します。
「システム構成」タブをクリックします。
ナビゲータでサーバーを展開します。
ポートを変更する管理対象サーバーをダブルクリックします。
「コヒーレンス」タブをクリックします。
「ローカル・ポート」の値を目的の値に変更します。
「適用」をクリックします。
管理サーバーと、更新された管理対象サーバーと同じクラスタに配置されている管理対象サーバーすべてを再起動します。
この項では、Oracle Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいOracle Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいOracle Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。
OAMをスケール・アップする手順は、次のとおりです。
Oracle WebLogic Server管理コンソール(http://oamhost1.example.com:7001/console)にログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
拡張するホストで既存のサーバーを選択します。例: WLS_OAM1
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前。例: WLS_OAM3
サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。
「OK」をクリックします。
新しく作成したサーバーWLS_OAM3をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOAMHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。表の「名前」列で「WLS_OAM3」を選択します。
「SSL」タブをクリックします。「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
「チェンジ・センター」メニューで構成のアクティブ化をクリックします。
新しい管理対象サーバーをOAMに登録します。この時点で、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。Oracle OAMコンソールでこれを行います。
OAMコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
「アクション」メニューから「作成」を選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行するホスト。
ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート
OAMプロキシ・ポート: OAMプロキシを実行するポート。これは、ホストに対して一意です。
プロキシ・サーバーID: AccessServerConfigProxy
モード: Open
「コヒーレンス」タブをクリックします。
「ローカル・ポート」をそのホストで一意の値に設定します。
「適用」をクリックします。
「適用」をクリックします。
これでアクセス・サーバーを起動できます。このアクセス・サーバーを使用するには、その存在をWebgateに通知する必要があります。次の手順を実行します。
OAMコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
エージェント→OAMエージェント→10gエージェント」(10g WebGatesの場合)、またはエージェント→OAMエージェント→11gエージェント(11g WebGatesの場合)を開きます。
変更するWebGateをダブルクリックします。
「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。
リストからサーバー名を選択します。
「適用」をクリックします。
スケール・アウトはスケール・アップと非常によく似ていますが、スケール・アウトでは、新しいノードにインストールされるソフトウェアが必要です。
第8.8.4.3項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。
第8.8.4.4項「Oracle Access Manager Application Tierのインストールと構成」の手順に従い、新しいホストにOracle Fusion Middleware Identity Managementコンポーネントをインストールします。
Oracle WebLogic Server管理コンソール(http://oamhost1.example.com:7001/oamconsole)にログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
拡張するホストで既存のサーバーを選択します。例: WLS_OAM1
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前。例: WLS_OAM3
サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。
「OK」をクリックします。
新しく作成したサーバーWLS_OAM3をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOAMHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ペインで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
「チェンジ・センター」メニューで構成のアクティブ化をクリックします。
次のコマンドを使用してOAMHOST1上のドメインをパックします。
pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true
pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
次のコマンドを使用して新しいホスト上のドメインを解凍します。
unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications
unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
コンソールから管理対象サーバーを起動する前に、OAMHOST3上にノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binにあるsetNMProps.shスクリプトを実行することによって行います。次のように入力します。
MW_HOME/oracle_common/common/bin/setNMProps.sh
新しい管理対象サーバーをOAMに登録します。ここで、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。これは、Oracle OAMコンソールから次のように実行します。
OAMコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「アクション」メニューから「作成」を選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行するホスト、OAMHOST3。
ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート。
OAMプロキシ・ポート: OAMプロキシを実行するポート。これは、ホストに対して一意です。
プロキシ・サーバーID: AccessServerConfigProxy
モード: Open
「適用」をクリックします。
これでアクセス・サーバーを起動できます。このサーバーを使用するには、その存在をWebgateに通知する必要があります。次の手順を実行します。
OAMコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「エージェント」→「OAMエージェント」→「10gエージェント」を展開します。
変更するWebGateをダブルクリックします。
「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。
リストからサーバー名を選択します。
「適用」をクリックします。
Web層を更新します。これで、新しい管理対象サーバーが作成されて起動され、Web層はリクエストをその管理対象サーバーに転送するようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
これを行うには、各Web層でファイルOAM.confを更新します。このファイルは、ディレクトリORACLE_INSTANCE/config/OHS/component name/moduleconfにあります。
新しいサーバーをファイル内のWebLogicClusterディレクティブに追加します。次に例を示します。
<Location /OAM_admin>
SetHandler weblogic-handler
WebLogicCluster
OAMhost1.example.com:14200,OAMhost2.example.com:14200
</Location>
変更後:
<Location /OAM_admin>
SetHandler weblogic-handler
WebLogicCluster
OAMhost1.example.com:14200,OAMhost2.example.com:14200,OAMhsot3.example.com:14300
</Location>
この項では、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システム管理者ガイドを参照してください。
この項の内容は次のとおりです。
図8-16は、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 Webサービスに接続するためのSOA Soapurlを使用してSOAに接続します。これは、SOA用のフロントエンドURLであり、クラスタ化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コマンドの一覧を参照してください。
Oracle Identity Managerは、Oracle WebLogic ServerにステージなしアプリケーションとしてデプロイされるJava EEアプリケーションです。Oracle Identity Managerサーバーは、それがデプロイされたWebLogic Serverの起動時に初期化されます。アプリケーションの初期化の一部として、クォーツ・ベースのスケジューラも起動されます。初期化が完了すると、システムはクライアントからリクエストを受信できるようになります。
Remote ManagerおよびDesign Consoleは別にスタンドアロンのユーティリティとして起動する必要があります。
Oracle Identity Managerは、外部的に管理されるアプリケーションとしてOracle WebLogic Serverにデプロイされます。Oracle 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は、アプリケーションの監視および構成の変更に使用します。
Oracle Identity Managerのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理できます。
Oracle WebLogic Scripting Tool (WLST)
Oracle WebLogic Server管理コンソール
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogicノード・マネージャ
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ファイルに格納されます。
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サーバーの機能に必要な外部コンポーネントは次のとおりです。
Oracle 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ファイルがそのクラスパスに含まれている必要があります。
Oracle Identity Managerは、Oracle WebLogic ServerにデプロイされるJava EEアプリケーションです。サーバーに関連するログ・メッセージはすべて、サーバーのログ・ファイルに記録され、Oracle Identity Managerに固有のメッセージはすべて、アプリケーションがデプロイされたOracle WebLogic Serverの診断ログ・ファイルに記録されます。
Oracle WebLogic Serverのログ・ファイルは、次のディレクトリに配置されます。
DOMAIN_HOME/servers/serverName/logs
メイン・ログ・ファイルは、serverName.log、serverName.out、およびserverName-diagnostic.logの3つです。ここでserverNameはOracle WebLogic Serverの名前です。たとえば、Oracle WebLogic Server名がwls_OIM1の場合、診断ログ・ファイル名はwls_OIM1-diagnostic.logになります。
このログ・ファイルは、Oracle Enterprise Manager Fusion Middleware Controlを使用して表示できます。
この項では、Oracle Identity Managementの高可用性の概要およびOracle Identity Managerの高可用性環境の設計とデプロイについて説明します。
|
注意: Oracle Identity Managerを高可用性構成にデプロイする場合は、次のことに注意してください。
|
図8-17は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされた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の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
図8-17の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アドレスを指します。
高可用性アーキテクチャでは、Oracle Identity Managerは、Oracle WebLogicクラスタにデプロイされます。このクラスタには、クラスタのメンバーとして少なくとも2つのサーバーが存在します。
デフォルトでは、Oracle WebLogic Serverによって、このアプリケーションの起動、停止、監視および様々なライフサイクル・イベントの監視が行われます。Oracle Identity Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
Oracle Identity Managerのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理できます。
Oracle WebLogic Server管理コンソール
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Scripting Tool (WLST)
高可用性環境では、1つのOracle Identity Managerインスタンスの構成変更により、他のすべてのインスタンスの構成が変更されます。これは、すべてのOracle Identity Managerインスタンスが同じ構成リポジトリを共有しているためです。
この項では、Oracle Identity Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。
この項には、高可用性を得るためのOracle Identity Managementの構成に関する次の項目があります。
Oracle Identity Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。
データベースに OIMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。
OIMスキーマを作成するためのリポジトリ作成ユーティリティの実行手順は、第8.9.3.1.1項「データベースにOIMスキーマを作成するためのRCUの実行」を参照してください。
OIMHOST1およびOIMHOST2にOracle WebLogic Serverをインストールします。
第8.9.3.1.2項「Oracle WebLogic Serverのインストール」の手順に従い、OIMHOST1およびOIMHOST2にOracle WebLogic Serverをインストールします。
OIMHOST1およびOIMHOST2にOracle SOA Suiteをインストールします。
第8.9.3.1.3項「OIMHOST1およびOIMHOST2へのOracle SOA Suiteのインストール」の手順に従い、OIMHOST1およびOIMHOST2にOracle SOA Suiteソフトウェアをインストールします。
OIMHOST1およびOIMHOST2にOracle Identity Managementソフトウェアをインストールします。
第8.9.3.1.4項「OIMHOST1およびOIMHOST2へのOracle Identity Managerのインストール」の手順に従い、OIMHOST1およびOIMHOST2にOracle Identity Managementソフトウェアをインストールします。
高可用性LDAP実装が使用可能であることを確認します。
|
注意: この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managerと統合されているOracle Identity Managerインストールでのみ必要です。 LDAPSyncオプションの有効化や、Oracle Access Managerとの統合を計画していない場合は、この項をスキップできます。 |
Oracle Internet Directoryのインストールと構成の詳細は、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。Oracle Virtual Directoryのインストールと構成の詳細は、第8.4.3項「Oracle Virtual Directoryの高可用性の構成手順」を参照してください。Oracle Identity Managerは、Oracle Internet Directoryと直接通信しないことに注意してください。それは、Oracle Virtual Directoryと通信し、Oracle Virtual DirectoryがOracle Internet Directoryと通信します。
wlfullclient.jarファイルを、OIMHOST1およびOIMHOST2で作成します。
Oracle Identity Managerは、特定の操作にwlfullclient.jarライブラリを使用します。このライブラリは出荷されていないため、手動で作成する必要があります。このライブラリは、環境のアプリケーション層にあるすべてのマシンのMW_HOME/wlserver_10.3/server/libディレクトリの下に作成することをお薦めします。このライブラリは、OIDHOST1、OIDHOST2、OVDHOST1、OVDHOST2などのディレクトリ層マシンに作成する必要はありません。
次の手順に従って、wlfullclient.jarファイルを作成します。
MW_HOME/wlserver_10.3/server/libディレクトリに移動します。
JAVA_HOMEをMW_HOME/jdk160_18に設定し、JAVA_HOME/binディレクトリがパスに含まれていることを確認します。
次のファイルを実行することによって、wlfullclient.jarファイルを作成します。
java -jar wljarbuilder.jar
OIMHOST1およびOIMHOST2にOracle Identity ManagerおよびSOAインスタンスをインストールする前に、リポジトリ作成ユーティリティ(RCU)を使用して、Oracle Identity Managerで使用するスキーマのコレクションを作成しておく必要があります。
RCUは、Oracle Fusion Middleware 11gキットの部品として付属する専用のCDに収録されています。
次の手順に従って、RCUを実行し、Oracle RACデータベース・リポジトリにOracle Identity Managerスキーマを作成します。
次のコマンドを発行します。
prompt> RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」操作を選択してコンポーネント・スキーマを既存のデータベースにロードします。
「次へ」をクリックします。
「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。
データベース・タイプ: Oracle Database
ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: OIMDBHOST1-VIPまたはOIMDBHOST2-VIP
ポート: データベースのポート番号。例: 1521
サービス名: データベースのサービス名。たとえば、oim.example.comなどです。
ユーザー名: SYS
パスワード: SYSユーザーのパスワード
ロール: SYSDBA
「次へ」をクリックします。
グローバルな前提条件が完了したら、「前提条件チェック」画面で「OK」をクリックします。
「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: ha
コンポーネント:
「Identity Management」の下では次のように指定します。
Oracle Identity Manager - OIM
デフォルトで、「Metadata Services - MDS」が選択されていることに注意してください。
「SOAおよびBAMインフラストラクチャ」の下で:
SOAインフラストラクチャ - デフォルトで、SOAINFRAが選択済です。
ユーザー・メッセージング・サービス - デフォルトで、ORASDPMが選択済です。
「次へ」をクリックします。
コンポーネントの前提条件が完了したら、「前提条件チェック」画面で「OK」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。
「表領域のマップ」画面で、コンポーネントの表領域を選択します。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
Oracle WebLogic Serverをインストールする前に、お使いのマシンが、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』に指定されているシステム、パッチ、カーネルなどの要件を満たしていることを確認します。
インストーラを起動し、OIMHOST1およびOIMHOST2で次の手順を実行します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
ORACLE_BASE/product/fmw
|
注意: ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。 |
「次へ」をクリックします。
セキュリティ・アップデートが通知されるようにするために、「セキュリティ更新のための登録」画面で連絡先情報を入力します。
「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択します。
「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
「完了」をクリックします。
次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOIMHOST1およびOIMHOST2にインストールします。
Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。
次のようにOracle Fusion Middlewareコンポーネントのインストーラを起動します。
HOST1> runInstaller
インストーラで、JRE/JDKの場所を入力するよう求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_14_<バージョン>のように入力します。
次の手順を実行します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
Oracleミドルウェア・ホーム: MW_HOMEのリストから前にインストールしたミドルウェア・ホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ:
ORACLE_HOMEにOracle SOA Suiteをインストールするときに、Oracleホーム・ディレクトリ名としてsoaを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。
「インストール完了」画面で「終了」をクリックします。
次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOIMHOST1およびOIMHOST2にインストールします。
Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。
次のようにOracle Fusion Middlewareコンポーネントのインストーラを起動します。
HOST1> runInstaller
インストーラで、JRE/JDKの場所を入力するよう求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_<バージョン>のように入力します。
次の手順を実行します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
Oracleミドルウェア・ホーム: MW_HOMEのリストから前にインストールしたミドルウェア・ホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ:
ORACLE_HOMEにOracle Identity and Access Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてiamを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。
「インストール完了」画面で「終了」をクリックします。
OIMHOST1にドメインを作成する必要があります。次の手順を実行します。
このコマンドを実行して、構成ウィザードを起動します。
MW_HOME/oracle_common/common/bin/config.sh
「ようこそ」画面で、「WebLogicドメインの作成」を選択します。
「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
リストから、次のように選択します。
Oracle Identity Manager
Oracle SOA SuiteとOracle WSM Policy Managerが自動的に選択されます。
Oracle Enterprise Manager
Oracle JRFが自動的に選択されます。
「ドメイン名と場所の指定」画面で、ドメインおよびそのすべてのアプリケーションの名前と場所を入力します。
次の項目を入力します。
ドメイン名: IDMDomain
ドメインの場所: デフォルトを受け入れます。
アプリケーションの場所: デフォルトを受け入れます。
「次へ」をクリックします。
「管理サーバーのユーザー名とパスワードの構成」画面で、次のように入力します。
Name: weblogic
User Password: weblogicユーザーのパスワードを入力します。
Confirm User Password: weblogicユーザーのパスワードを入力します。
Description: ユーザーの説明を入力します。
「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JRockit SDK 1.6.n」を選択します。
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次に示すコンポーネント・スキーマを選択します。
SOAインフラストラクチャ
ユーザー・メッセージング・サービス
OIM MDSスキーマ
OWSM MDSスキーマ
SOA MDSスキーマ
OIMスキーマ
「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」の横のチェック・ボックスを選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、すべてのマルチ・データ・ソース・スキーマを選択し、次のように入力します。
サービス名: oim.example.com
最初のRACノードの場合は、次のように入力します。
ホスト名: OIMDBHOST1-VIP.example.com
インスタンス名: oimdb1
ポート: 1521
2つ目のRACノードの場合は、次のように入力します。
ホスト名: OIMDBHOST2-VIP.example.com
インスタンス名: oimdb2
ポート: 1521
各スキーマを個別に選択し、スキーマのユーザー名とパスワードを表8-7に示すように入力します。
表8-7 各マルチ・データ・ソース・スキーマのスキーマ所有者とパスワードの入力
| スキーマ名 | スキーマ所有者 | パスワード |
|---|---|---|
|
SOAインフラストラクチャ |
HA_SOAINFRA |
<パスワードを入力> |
|
ユーザー・メッセージング・サービス |
HA_ORASDPM |
<パスワードを入力> |
|
OIM MDSスキーマ |
HA_MDS |
<パスワードを入力> |
|
OWSM MDSスキーマ |
HA_MDS |
<パスワードを入力> |
|
SOA MDSスキーマ |
HA_MDS |
<パスワードを入力> |
|
OIMスキーマ |
HA_OIM |
<パスワードを入力> |
「次へ」をクリックします。
「コンポーネント・スキーマのテスト」画面で、すべてのスキーマを選択して「接続のテスト」をクリックします。すべてのスキーマに対するテストが正常に完了したことを確認します。
「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
JMS分散宛先
管理対象サーバー、クラスタ、およびマシン
「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: oimhost1.example.com
Listen port: 7001
SSLリスニング・ポート: 適用なし
SSL有効: 選択を解除
「次へ」をクリックします。
「JMS分散宛先タイプの選択」画面で、リストされているすべてのJMSシステム・リソースが共通分散宛先であることを確認します。そのようになっていない場合は、ドロップダウン・ボックスから「UDD」を選択します。エントリが表8-8に示すように設定されていることを確認します。
表8-8 JMSシステム・リソースに対して選択する値
| JMSシステム・リソース | 共通/重み設定された分散宛先 |
|---|---|
|
UMSJMSSystemResource |
UDD |
|
SOAJMSModule |
UDD |
|
OIMJMSModule |
UDD |
|
BPMJMSModule |
UDD |
「次へ」をクリックします。
次のメッセージの「オーバーライドの警告」ダイアログ・ボックスが表示されます。
「CFGFWK-40915: 共通分散宛先(UDD)への変換対象として少なくとも1つのJMSシステム・リソースが選択されています。この変換は、JMSシステム・リソースがクラスタに割り当てられている場合にのみ行われます。」
「警告」ボックスで「OK」をクリックします。
「管理対象サーバーの構成」画面を初めて表示した場合、構成ウィザードによって2つのデフォルト管理対象サーバー(oim_server1とsoa_server1)が作成されています。デフォルトの管理対象サーバーの詳細を変更し、2つ目の管理対象サーバーを追加します。次の手順に従います。
oim_server1エントリについては、そのエントリを次の値に変更します。
Name: WLS_OIM1
Listen address: OIMVHN1
Listen port: 14000
soa_server1エントリについては、そのエントリを次の値に変更します。
Name: WLS_SOA1
Listen address: SOAVHN1
Listen port: 8001
2つ目のOIMサーバーに対して、「追加」をクリックし、次の情報を入力します。
Name: WLS_OIM2
Listen address: OIMVHN2
Listen port: 14000
2つ目のSOAサーバーに対して、「追加」をクリックし、次の情報を入力します。
Name: WLS_SOA2
Listen address: SOAVHN2
Listen port: 8001
「次へ」をクリックします。
|
注意: さらに管理対象サーバーを追加するには、2つ目の管理対象サーバーを追加するための手順に従ってください。 |
「クラスタの構成」画面で、「追加」をクリックして2つのクラスタを作成します。
OIMクラスタに関して次の情報を入力します。
名前: oim_cluster
クラスタのメッセージング・モード: unicast
SOAクラスタに関して次の情報を入力します。
名前: soa_cluster
クラスタのメッセージング・モード: unicast
その他すべてのフィールドをデフォルトの設定のままにして、「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。右のウィンドウでクラスタ名をクリックします。
サーバーの下の管理対象サーバーをクリックし、矢印をクリックしてそれをクラスタに割り当てます。
WLS_OIM1およびWLS_OIM2管理対象サーバーをoim_clusterのメンバーになるように割り当てます。
WLS_SOA1およびWLS_SOA2管理対象サーバーをsoa_clusterのメンバーになるように割り当てます。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジ内の各サーバーのマシンを作成します。
ホストでいずれかのタイプのUnixオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」をクリックします。
次の情報を入力します。
名前: ホストの名前。ここでは、DNS名を使用することをお薦めします。
ノード・マネージャ・リスニング・アドレス: ここにマシンのDNS名を入力します。
ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。
「次へ」をクリックします。
|
注意: UNIXでは、「マシン」タブの下のデフォルト・ローカル・マシン・エントリを削除します。 |
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
右側のウィンドウでマシンをクリックします。
左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。
矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。
すべての管理対象サーバーが適切なマシンに割り当てられるまで、この手順を繰り返します。
一般的な例は、次のようになります。
Host1: Admin Server、WLS_OIM1、およびWLS_SOA1
Host2: WLS_OIM2およびWLS_SOA2
「次へ」をクリックします。
「構成のサマリー」画面で、「作成」をクリックしてドメインを作成します。
この項では、OIMHOST1で実行するインストール後の手順について説明します。これらの項目が含まれます。
この項では、OIMHOST1上の管理サーバー用boot.propertiesファイルを作成する方法を説明します。boot.propertiesファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。
次の手順に従って、boot.propertiesファイルを作成します。
OIMHOST1で、次のディレクトリを作成します。
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
例:
$ mkdir -p MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUser password=adminUserPassword
|
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。 |
WebLogic管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャではStartScriptEnabledプロパティがtrueに設定されていることが必要です。
これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。
MW_HOME/oracle_common/common/bin
次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST1上のノード・マネージャを起動します。
MW_HOME/wlserver_10.3/server/bin
次の手順に従い、管理サーバーを起動し、その起動を確認します。
次のコマンドを実行し、OIMHOST1上の管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
Webブラウザを開いて次のページにアクセスし、管理サーバーの起動が正常に行われたことを確認します。
WebLogic Server管理コンソール:
http://oimhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oimhost1.example.com:7001/em
weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。
この項では、Oracle Identity ManagerとSOA管理対象サーバーの起動前の構成方法について説明します。
この項の内容は次のとおりです。
Oracle Identity Managerを構成する前に、次のタスクが実行済であることを確認します。
|
注意: この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managerと統合されているOracle Identity Managerインストールでのみ必要です。 LDAPSyncオプションの有効化や、Oracle Access Managerとの統合を計画していない場合は、この項をスキップできます。 |
Oracle Identity Manager用のディレクトリ・スキーマの拡張
アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。
アイデンティティ・ストアを事前構成するには、OIMHOST1で次の手順を実行します。
環境変数MW_HOME、JAVA_HOMEおよびORACLE_HOMEを設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
次の項目を含む、プロパティ・ファイルextend.propsを作成します。
IDSTORE_HOST : idstore.example.com
IDSTORE_PORT : 389
IDSTORE_BINDDN: cn=orcladmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,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リコンシリエーション・ユーザーがあげられます。
idmConfigToolコマンドを使用して、アイデンティティ・ストアを構成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
Linuxのコマンド構文:
idmConfigTool.sh -preConfigIDStore input_file=configfile
Windowsのコマンド構文:
idmConfigTool.bat -preConfigIDStore input_file=configfile
例:
idmConfigTool.sh -preConfigIDStore input_file=extend.props
このコマンドを実行すると、IDストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。
次に、コマンドの出力例を示します。
./preconfig_id.sh Enter ID Store Bind DN password : Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif The tool has completed its operation. Details have been logged to automation.log
ログ・ファイルを確認して、エラーや警告を修正します。
Oracle Identity Manager用のユーザーとグループの作成
oimadminユーザーをアイデンティティ・ストアに追加する手順を実行して、そのユーザーをOracle Identity Manager管理者グループに割り当てます。また、リコンシリエーションを実行するために、標準の場所cn=Users以外にもユーザーを作成します。Oracle Virtual Directoryを使用したディレクトリに直接接続するときには、このユーザーをバインドDNとして選択することをお薦めします。
|
注意: このコマンドでは、アイデンティティ・ストアに予約用のコンテナも作成します。 |
xelsysadmユーザーをアイデンティティ・ストアに追加して、そのユーザーを管理グループに割り当てるには、OIMHOST1で次のタスクを実行します。
環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
IDM_HOMEをIDM_ORACLE_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
次の項目を含む、プロパティ・ファイルoim.propsを作成します。
IDSTORE_HOST : idstore.example.com
IDSTORE_PORT : 389
IDSTORE_BINDDN : cn=orcladmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE:cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
POLICYSTORE_SHARES_IDSTORE: true
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com
IDSTORE_OIMADMINUSER: oimadmin
IDSTORE_OIMADMINGROUP:OIMAdministrators
説明:
IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。
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を設定します。
idmConfigToolコマンドを使用してアイデンティティ・ストアを構成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
Linuxコマンドの構文:
idmConfigTool.sh -prepareIDStore mode=OIM input_file=configfile
Windowsコマンドの構文:
idmConfigTool.bat -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
ログ・ファイルを確認して、エラーや警告を修正します。
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にユーザー・アダプタを作成する手順は次のとおりです。
ブラウザを開き、ODSMコンソール(http://admin.example.com/odsm)を表示します。
|
注意: Oracle Directory Services Managerは、図8-17には記載されていませんが、Oracle Internet DirectoryとOracle Virtual Directoryを管理するために必要です。環境にOracle Directory Services Managerが存在していることを想定しています。 |
OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれへの接続がまだ存在していない場合は、作成します。
適切な接続エントリを使用して、各Oracle Virtual Directoryインスタンスに接続します。
ホームページで、「アダプタ」タブをクリックします。
アダプタ・ウィンドウの上部にある「アダプタの作成」をクリックして、「新規アダプタ・ウィザード」を起動します。
「新規アダプタ・ウィザード」で次のパラメータを指定して、新しいアダプタを作成します。
|
注意: 前にユーザー・アダプタを作成した場合は、アダプタを作成する手順をスキップし、アダプタを編集する手順に従います。 |
| 画面 | フィールド | 値/手順 |
|---|---|---|
|
タイプ |
アダプタ・タイプ |
|
|
アダプタ名 |
|
|
|
アダプタ・テンプレート |
|
|
|
接続 |
DNS設定を使用 |
いいえ |
|
ホスト |
|
|
|
ポート |
|
|
|
サーバー・プロキシ・バインドDN |
|
|
|
プロキシ・パスワード |
|
|
|
接続テスト |
テストが正常に行われたことを確認します。 |
|
|
ネームスペース |
リモート・ベース |
|
|
マップされたネームスペース |
|
|
|
概要 |
概要に誤りがないことを確認し、「終了」をクリックします。 |
ユーザー・アダプタを次のように編集します。
OIMユーザー・アダプタを選択します。
「プラグイン」タブをクリックします。
「ユーザー管理」プラグインをクリックし、プラグイン表で「編集」をクリックします。プラグインの編集ウィンドウが表示されます。
「パラメータ」表で、次のようにパラメータ値を更新します。
| パラメータ | 値 |
|---|---|
|
directoryType |
oid |
|
pwdMaxFailure |
10 |
|
oamEnabled |
true |
「OK」をクリックします。
「適用」をクリックします。
変更ログ・アダプタ
OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれに変更ログ・アダプタを作成します。次の手順に従い、Oracle Directory Services Managerを使用してOracle Virtual Directoryに変更ログ・アダプタを作成します。
ブラウザを開き、ODSMコンソール(http://admin.example.com/odsm)を表示します。
OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれへの接続がまだ存在していない場合は、作成します。
適切な接続エントリを使用して、Oracle Virtual Directoryインスタンスに接続します。
ホームページで、「アダプタ」タブをクリックします。
アダプタ・ウィンドウの上部にある「アダプタの作成」をクリックして、「新規アダプタ・ウィザード」を起動します。
「新規アダプタ・ウィザード」で次のパラメータを指定して、新しいアダプタを作成します。
| 画面 | フィールド | 値/手順 |
|---|---|---|
|
タイプ |
アダプタ・タイプ |
LDAP |
|
アダプタ名 |
OIM変更ログ・アダプタ |
|
|
アダプタ・テンプレート |
|
|
|
接続 |
DNS設定を使用 |
いいえ |
|
ホスト |
|
|
|
ポート |
|
|
|
サーバー・プロキシ・バインドDN |
|
|
|
プロキシ・パスワード |
|
|
|
接続テスト |
テストが正常に行われたことを確認します。 |
|
|
ネームスペース |
リモート・ベース |
|
|
マップされたネームスペース |
|
|
|
概要 |
概要に間違いがないことを確認してから、「終了」をクリックします。 |
変更アダプタを編集する手順は、次のとおりです。
OIM変更ログ・アダプタを選択します。
「プラグイン」タブをクリックします。
「デプロイ済プラグイン」表で、「変更ログ」プラグインをクリックし、プラグイン表で「編集」をクリックします。プラグインの編集ウィンドウが表示されます。
「パラメータ」表で、パラメータ値を更新します。
「OK」をクリックします。
「適用」をクリックします。
変更ログ・アダプタを編集してプロパティを追加または変更し、それらが次の表に示す値に一致するようにします。mapObjectclass、modifierDNFilter、sizeLimit、およびtargetDNFilterプロパティをアダプタに追加する必要があります。
| パラメータ | 値 |
|---|---|
|
directoryType |
|
|
mapAttribute |
|
|
requiredAttribute |
|
|
modifierDNFilter |
|
|
sizeLimit |
|
|
targetDNFilter |
調整が必要な検索ベース。この値は、OIMのインストール時に指定したLDAP SearchDNと同一である必要があります。 |
|
mapUserState |
|
|
oamEnabled |
|
Oracle Internet DirectoryとOracle Virtual Directoryの起動と停止
次のインスタンスを起動および停止します。
OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンス。
OIDHOST1とOIDHOST2上で実行されているOracle Internet Directoryインスタンス。
手順については、第8.14項「コンポーネントの起動および停止」を参照してください。
Oracle Identity ManagerおよびSOA管理対象サーバーを起動する前に、Oracle Identity Managerサーバー・インスタンスを構成しておく必要があります。これらの構成手順を実行する必要があるのは、一度のみ(たとえば、ドメインを最初に作成するとき)です。Oracle Identity Management構成ウィザードによって、OIMメタデータがデータベースにロードされ、インスタンスが構成されます。
続行する前に、次の条件を満たしていることを確認します。
管理サーバーが起動されて、実行中であること。
環境変数DOMAIN_HOMEおよびWL_HOMEが現在のシェル内で設定されていないこと。
Oracle Identity Management構成ウィザードは、Identity Management Oracleホームの下にあります。次のように入力します。
IAM_ORACLE_HOME/bin/config.sh
次の手順を実行します。
「ようこそ」画面で「次へ」をクリックします。
「構成するコンポーネント」画面で、OIMサーバーを選択します。トポロジに必要な場合は、OIM Remote Managerを選択します。
「次へ」をクリックします。
「データベース」画面で、次の値を指定します。
接続文字列: OIMデータベースの接続文字列。例:
oimdbhost1-vip.example.com:1521:oimdb1^oimdbhost2-vip.example.com:1521:oimdb2@oim.example.com
OIMスキーマ・ユーザー名: HA_OIM
OIMスキーマ・パスワード: password
MDSスキーマ・ユーザー名: HA_MDS
MDSスキーマ・パスワード: password
「次へ」を選択します。
「WebLogic管理サーバー」画面で、WebLogic管理サーバーについて次の詳細を入力します。
URL: WebLogic管理サーバーに接続するためのURL。例: t3://oimhost1.example.com:7001。
ユーザー名: weblogic
パスワード: weblogicユーザーのパスワード
「次へ」をクリックします。
「OIMサーバー」画面で、次の値を指定します。
OIM管理者パスワード: OIM管理者のパスワード。これは、xelsysadmユーザーのパスワードです。このパスワードは、事前にidmconfigtoolで入力したパスワードと同じにします。
パスワードの確認: パスワードの再入力·
OIM HTTP URL: OIMサーバーのプロキシURL。これは、OIM用のOHSサーバーのフロントエンドに配置されているハードウェア・ロード・バランサのURLです。例: http://oiminternal.example.com:80。
キーストア・パスワード: キー・ストア・パスワード。パスワードには、大文字と数字を含める必要があります。例: MyPassword1
「次へ」をクリックします。
環境に必要な場合は、「LDAP同期とOAM」画面で、BI Publisherの構成を選択し、BI Publisher URLに値を指定します。環境においてBI Publisherに接続するためのURLを入力します。
LDAP同期の有効化を選択します。
|
メモ:
|
「次へ」をクリックします。
「LDAPサーバー」画面で、次のLDAPサーバーの詳細を指定します。
|
注意: このリリースのOracle Identity Manager LDAPSyncモジュールは、Oracle Virtual Directoryを介したOracle Internet Directoryへの接続のみをサポートしています。 この手順および次の手順のLDAPサーバーとは、Oracle Virtual Directoryのことを指します。 |
ディレクトリ・サーバー・タイプ: ディレクトリ・サーバーのタイプです。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=mycompany,dc=com
「次へ」をクリックします。
「LDAPサーバー(続き)」画面で、次のLDAPサーバー詳細を入力します。
LDAPロール・コンテナ: ロール・コンテナ用DN。これは、OIMロールが格納されているコンテナです。例: cn=Groups,dc=mycompany,dc=com
LDAPユーザー・コンテナ: ユーザー・コンテナ用DN。これは、OIMユーザーが格納されているコンテナです。例: cn=Users,dc=mycompany,dc=com·
ユーザー予約コンテナ: ユーザー予約コンテナ用DN。
|
注意: 「Oracle Identity Manager用のユーザーとグループの作成」の手順の |
「次へ」をクリックします。
「Remote Manager」画面で、次の値を指定します。
|
注意: この画面は、ステップ2でRemote Managerユーティリティを選択した場合にのみ表示されます。 |
サービス名: HA_RManager
RMIレジストリ・ポート: 12345
リスニング・ポート(SSL): 12346
「構成サマリー」画面で、サマリー情報を確認します。
「構成」をクリックし、Oracle Identity Managerインスタンスを構成します。
「構成の進行状況」画面で構成が正常に完了したら、「次へ」をクリックします。
「構成が完了しました」画面で、構成されたOracle Identity Managerインスタンスの詳細を表示します。
「終了」をクリックして、構成アシスタントを終了します。
第8.14項「コンポーネントの起動および停止」の説明に従い、WebLogic管理サーバーを停止します。
第8.14項「コンポーネントの起動および停止」の説明に従い、WebLogic管理サーバーを起動します。
この項では、管理対象サーバーの構成後の手順について説明します。
次の手順に従い、OIMHOST1上のWLS_SOA1およびWLS_OIM1管理対象サーバーを起動します。
OIMHOST1上のWebLogic管理サーバーを停止します。WebLogic管理コンソールを使用して、管理サーバーを停止します。
$DOMAIN_HOME/binディレクトリの下にあるstartWebLogic.shスクリプトを使用して、OIMHOST1上のWebLogic管理サーバーを起動します。例:
/u01/app/oracle/admin/OIM/bin/startWebLogic.sh > /tmp/admin.out 2>1&
WebLogic管理コンソールを表示して、WebLogic管理サーバーが正常に起動されたことを確認します。
WebLogic管理コンソールを使用して、WLS_SOA1管理対象サーバーを起動します。
WebLogic管理コンソールを使用して、WLS_OIM1管理対象サーバーを起動します。
次の手順に従い、SOA管理対象サーバーのCoherence構成を更新します。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。
「サーバーの起動」タブをクリックします。
「引数」フィールドで、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
「保存」をクリックして、変更をアクティブ化します。
この変更を適用するには、SOAサーバーを再起動する必要があります。
Webブラウザを使用してOracle Identity Managerコンソールを起動することによって、OIMHOST1上のOracle Identity Managerサーバー・インスタンスを検証します。
Oracle Identity ManagerコンソールのURLは、次のとおりです。
http://oimvhn1.example.com:14000/oim
xelsysadmパスワードを使用してログインします。
OIMHOST1で構成を完了したら、その構成をOIMHOST2に伝播できます。これを行うには、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。
次の手順に従い、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。
OIMHOST1上で、MW_HOME/oracle_common/common/binディレクトリにあるpackユーティリティを呼び出します。
pack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain - template =/u01/app/oracle/admin/templates/oim_domain.jar - template_name="OIM Domain" -managed=true
前の手順で作成したoim_domain.jarファイルは、次のディレクトリにあります。
/u01/app/oracle/admin/templates
このoim_domain.jarファイルをOIMHOST1からOIMHOST2上の一時ディレクトリにコピーします。
OIMHOST2上で、MW_HOME/oracle_common/common/binディレクトリにあるunpackユーティリティを呼び出し、その一時ディレクトリにあるoim_domain.jarファイルの場所を指定します。
unpack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain - template=/tmp/oim_domain.jar
この項では、OIMHOST2で実行するインストール後の手順について説明します。これらの項目が含まれます。
WebLogic管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャでStartScriptEnabledプロパティがtrueに設定されていることが必要です。
これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。
MW_HOME/oracle_common/common/bin
次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST2上のノード・マネージャを起動します。
MW_HOME/wlserver_10.3/server/bin
次の手順に従い、OIMHOST2上のWLS_SOA2およびWLS_OIM2管理対象サーバーを起動します。
WebLogic管理コンソールを表示して、WebLogic管理サーバーが正常に起動されたことを確認します。
WebLogic管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。
WebLogic管理コンソールを使用して、WLS_OIM2管理対象サーバーを起動します。WLS_OIM2管理対象サーバーを起動する前に、WLS_SOA2管理対象サーバーを起動してください。
Webブラウザを使用してOracle Identity Managerコンソールを起動することによって、OIMHOST2上のOracle Identity Managerサーバー・インスタンスを検証します。
Oracle Identity ManagerコンソールのURLは、次のとおりです。
http://oimvhn2.example.com:14000/oim
xelsysadmパスワードを使用してログインします。
|
注意: この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managerと統合されているOracle Identity Managerインストールでのみ必要です。 LDAP同期オプションの有効化や、Oracle Access Managerとの統合を計画していない場合は、この項をスキップできます。 |
Oracle Identity Manager LDAP構成ポストセットアップ・スクリプトは、Oracle Internet Directoryからの最後の変更番号でOracle Identity Manager LDAP同期スケジュール済ジョブを更新します。LDAP構成ポストセットアップ・スクリプトは、IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあります。スクリプトを実行する手順は、次のとおりです。
wlfullclient.jarファイルが、第8.9.3.1項「Oracle Identity Managerの構成のための前提条件」の説明に従って作成されていることを確認します。
IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあるldapconfig.propsファイルを編集し、次の値を設定します。
OIMProviderURL: t3://oimvhn1.example.com:14000,oimvhn2.example.com:14000
OIDURL: ldap://oid.example.com:389
OIDAdminUsername: cn=orcladmin
OIDSearchBase: dc=mycompany,dc=com
UserContainerName: cn=Users
RoleContainerName: cn=Groups
ReservationContainerName: cn=Reserve
ファイルを保存します。
WL_HOMEおよびJAVA_HOME環境変数を設定します。
LDAPConfigPostSetup.shを実行します。このスクリプトでは、OID管理パスワードとOIM管理パスワードの入力が求められます。例:
Prompt> ./LDAPConfigPostSetup.sh [Enter OID admin password: ] [Enter OIM admin password: ]
ここで、OID admin passwordは、Oracle Internet Directoryの管理用の管理アカウントのパスワード、OIM admin passwordは、Oracle Identity ManagerがLDAP同期を必要とするアクションで使用するためにLDAPリポジトリ内に作成される管理LDAPアカウントのパスワードです。
|
注意:
|
この高可用性トポロジでは、管理対象サーバーWLS_OIM1、WLS_SOA1、WLS_OIM2、WLS_SOA2に対してサーバー移行を構成することをお薦めします。
OIMHOST1上のWLS_OIM1およびWLS_SOA1管理対象サーバーは、OIMHOST1で障害が発生した場合に、OIMHOST2で自動的に再起動するように構成されます。
OIMHOST2上のWLS_OIM2およびWLS_SOA2管理対象サーバーは、OIMHOST2で障害が発生した場合に、OIMHOST1で自動的に再起動するように構成されます。
このような構成では、WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2サーバーは、WebLogicサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。
次の手順を実行すると、WLS_OIM1、WLS_SOA1、WLS_OIM2、およびWLS_SOA2管理対象サーバーのサーバー移行を行うことができ、これにより、サーバーまたはプロセスの障害時に、管理対象サーバーは別のノードにフェイルオーバーできます。
ステップ1: サーバー移行leasing表のユーザーと表領域を設定する
ステップ3: ノード・マネージャのプロパティ・ファイルを編集する
ステップ5: サーバー移行ターゲットを構成する
ステップ6: サーバー移行をテストする
最初の手順では、サーバー移行leasing表のユーザーと表領域を設定します。
|
注意: 同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。この場合、データベース・リース用にデータ・ソースおよびマルチ・データ・ソースを再作成する必要はありませんが、これらをサーバー移行用に構成しているクラスタにターゲット指定しなおす必要があります。 |
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;
ユーザーleasingを作成し、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;
leasing.ddlスクリプトを使用してleasing表を作成します。
WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。
データベースにleasingユーザーとして接続します。
SQL*Plusでleasing.ddlスクリプトを実行します。
SQL> @Copy_Location/leasing.ddl;
マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。
このデータ・ソースが非XAデータ・ソースであることを確認します。
マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。
これらのデータ・ソースをクラスタにターゲット指定します。
データ・ソースの接続プールの初期容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」、「接続プール」タブの順にクリックし、「初期容量」フィールドに0(ゼロ)を入力します。
マルチ・データ・ソースの作成
マルチ・データ・ソースを作成する手順は、次のとおりです。
管理者の資格証明を使用して、Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで「サービス」ノードを開き、次に、「データ・ソース」ノードを開きます。
「チェンジ・センター」で「ロックして編集」をクリックします。
「新規」をクリックしてから、「マルチ・データ・ソース」をクリックします。
名前として、leasingと入力します。
JNDI名として、jdbc/leasingと入力します。
アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。「次」をクリックします。
ターゲット・クラスタを選択します。「次へ」をクリックします。
「非XAドライバ」(デフォルト)を選択します。「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。
|
注意: leasing表のマルチ・データ・ソースを作成する場合は、名前を<MultiDS>-rac0や<MultiDS>-rac1などの形式で入力します。 |
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。「次へ」をクリックします。
leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。
|
注意: 作成するデータ・ソースすべての作成を完了するまで、「終了」をクリックしないでください。作成したデータ・ソースが表示されない場合は、「終了」をクリックするのが早すぎたことを示しています。「終了」をクリックすると、データ・ソースをターゲット指定する画面が管理コンソールに表示されなくなります。 |
データ・ソースをクラスタにターゲット指定します。
データ・ソースを選択して、右の画面に追加します。
Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。
2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
保存して、「変更のアクティブ化」をクリックします。
nodemanager.propertiesファイルを編集して、サーバー移行を構成するノードごとに次のプロパティを追加する必要があります。
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
Interface: 浮動IPのインタフェース名(eth0など)を指定します。
|
注意: サブ・インタフェース( |
|
注意: Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: |
NetMask: 浮動IPのインタフェースのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります(255.255.255.0は一例です)。実際の値は、ネットワークにより異なります。
UseMACBroadcast: ARPパケットの送信時にノードのMACアドレスを使用するかどうか、つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。
これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力で、次のようなエントリが表示されることを確認します。
... StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 ...
|
注意: サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合、次の手順は必要ありません。 |
nodemanager.propertiesファイルで、StartScriptEnabledプロパティをtrueに設定します。
WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、OIMHOST1とOIMHOST2でノード・マネージャを起動します。
|
注意: 共有記憶域のインストールからノード・マネージャを実行している場合、同じ |
サーバー移行を構成するノードごとにwlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は、次のとおりです。
|
注意: Windowsでは、このスクリプトは |
PATH環境変数に次のファイルが含まれていることを確認します。
wlsifconfig.shスクリプトに対するsudo構成権限を付与します。
パスワード・プロンプトを使用しないで機能するsudoを構成します。
セキュリティ上の理由から、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定することをお薦めします。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。
WebLogicユーザー(oracle)に、パスワードによる制限なしのsudo権限を付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
WebLogicユーザーがこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
|
注意: この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。 |
まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
「名前」列で、移行を構成するクラスタをクリックします。
「移行」タブをクリックします。
「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
サーバー移行の候補マシンを設定します。このタスクは、次の手順に従って、すべての管理対象サーバーについて実行する必要があります。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
|
ヒント: 「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックして、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動し、サーバーが実行されているマシンを表示します。サーバーが自動的に移行される場合、これは実際の構成とは異なります。 |
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックしてから、「変更のアクティブ化」をクリックします。
追加の管理対象サーバーに対して、前述の手順を繰り返します。
管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。
サーバー移行が適切に機能していることを確認する手順は次のとおりです。
OIMHOST1から次の処理を実行します。
WLS_OIM1管理対象サーバーを停止します。これには、次のコマンドを実行します。
OIMHOST1> kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
OIMHOST1> ps -ef | grep WLS_OIM1
ノード・マネージャのコンソールを確認します。WLS_OIM1の浮動IPが無効になっていることを示すメッセージが表示されることを確認します。
ノード・マネージャがWLS_OIM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
OIMHOST2から次の処理を実行します。
ローカルのノード・マネージャのコンソールを確認します。OIMHOST1でWLS_OIM1の再起動が最後に試行されてから30秒経過した後、OIMHOST2のノード・マネージャによって、WLS_OIM1の浮動IPが有効化されていること、およびこのノードでサーバーが再起動されていることが表示されます。
同じIPでsoa-infraコンソールにアクセスします。
前述の手順に従い、WLS_OIM2、WLS_SOA1、およびWLS_SOA2管理対象サーバーのサーバー移行をテストします。
表8-10は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。
表8-10 WLS_OIM1、WLS_OIM2、WLS_SOA1、WLS_SOA2サーバー移行
| 管理対象サーバー | 移行元 | 移行先 |
|---|---|---|
|
WLS_OIM1 |
OIMHOST1 |
OIMHOST2 |
|
WLS_OIM2 |
OIMHOST2 |
OIMHOST1 |
|
WLS_SOA1 |
OIMHOST1 |
OIMHOST2 |
|
WLS_SOA2 |
OIMHOST2 |
OIMHOST1 |
管理コンソールからの検証
管理コンソールで移行を検証することもできます。
管理者の資格証明を使用して、Oracle WebLogic Server管理コンソール(http://oimhost1.example.com:7001/console)にログインします。
左側のコンソールで、「ドメイン」をクリックします。
「監視」タブ→「移行」サブタブをクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。
|
注意: サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。 |
OIMHOST1とOIMHOST2の両方から参照できる共有ディレクトリに、すべての永続ストアの場所を構成します。JMSメッセージは、各サーバーのローカル・ファイル・システムのファイル・システムで永続化されているため、WebLogicサーバー移行のためにはJMS永続ストア用の共有記憶域が必要です。共有記憶域がない場合、移行先サーバーからは保留中のJMSメッセージにアクセスできなくなります。
共有のベース・ディレクトリを使用するように、すべての永続ストアを変更する手順は、次のとおりです。
管理者の資格証明を使用して、Oracle WebLogic Server管理コンソール(http://oimhost1.example.com:7001/console)にログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアの概要」ページが表示されます。
表BPM、SOA、OIMおよびUMSの「名前」列から、永続ストアのハイパーリンクを選択します。その永続ストアの「設定」ページが表示されます。
「構成」タブの「ディレクトリ」フィールドに、クラスタ内の他のサーバーで使用可能な永続記憶域ソリューション(NASやSANなど)の場所を入力します。この場所を指定することで、保留中のJMSメッセージを送信できます。
場所は、次のディレクトリ構造に従う必要があります。
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 サーバーは、このディレクトリにアクセスできる必要があります。 このディレクトリは、サーバーを再起動する前に存在している必要があります。 |
保存してアクティブ化をクリックします。
サーバーを再起動して、永続ストア内の変更を有効化します。
各Oracle WebLogic管理対象サーバーにはトランザクション・ログがあり、サーバーによって調整された、未完了の可能性のある、進行中のトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、クラスタ内のすべてのサーバーからアクセス可能な場所にトランザクション・ログを格納します。共有記憶域がないと、サーバーに障害が発生したときにクラスタ内の他のサーバーがトランザクション・リカバリを実行できず、操作の再試行が必要になることがあります。
|
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。 |
Oracle Identity ManagerおよびSOAサーバーのデフォルトの永続ストアの場所を設定する手順は次のとおりです。
管理者の資格証明を使用して、Oracle WebLogic Server管理コンソール(http://oimhost1.example.com:7001/console)にログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)を選択します。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
「サービス」タブをクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようにする必要があります。
WLS_SOA1およびWLS_SOA2サーバーについては、次のようなディレクトリ構造を使用します。
ORACLE_BASE/admin/domainName/soaClusterName/tlogs
WLS_OIM1およびWLS_OIM2サーバーについては、次のようなディレクトリ構造を使用します。
ORACLE_BASE/admin/domainName/oimClusterName/tlogs
「保存」をクリックします。
|
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の管理対象サーバーで利用可能な永続記憶域ソリューション上の場所を指定します。WLS_SOA1、WLS_SOA2、WLS_OIM1、およびWLS_OIM2は、このディレクトリにアクセスできる必要があります。 |
WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールする手順は、第8.5.3.5.1項「Web Tier用のOracle HTTP Serverのインストール」を参照してください。
この項では、Oracle Web Tierと連携するためのOracle Identity Managerの構成手順について説明します。
次のタスクが実行済であることを確認します。
Oracle Web TierがWEBHOST1およびWEBHOST2にインストール済であること。
Oracle Identity ManagerがOIMHOST1およびOIMHOST2にインストールされ、構成済であること。
ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(sso.example.com)で構成済であること。
ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(oiminternal.example.com)で構成済であること。
ロード・バランサのVIPの構成の詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。
WEBHOST1およびWEBHOST2上の各Webサーバーに対して、ディレクトリORACLE_INSTANCE/config/OHS/component/moduleconfにoim.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>
# 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>
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>
このファイルをWEBHOST1とWEBHOST2の両方に保存します。
第8.14項「コンポーネントの起動および停止」の説明に従い、WEBHOST1およびWEBHOST2上のOracle HTTP Serverインスタンスを停止および起動します。
Oracle HTTP Serverが適切に構成されていることを検証する手順は次のとおりです。
Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。
http://sso.example.com:7777/oim
Oracle Identity Managerコンソール・ログイン・ページが表示されます。
xelsysadmユーザーの資格証明を使用して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呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。
アクティブ/アクティブOracle Identity Manager構成において、Oracle Identity Managerでユーザーを作成していて(Oracle Identity Managerにログインし、「管理」タブをクリックして、「ユーザーの作成」リンクをクリックし、フィールドに必要な情報を入力してから、「保存」をクリックします)、そのリクエストを処理中のOracle Identity Managerサーバーに障害が発生した場合、Oracle Identity Managerログ・ファイルに次のようなResourceConnectionValidation例外が記述されることがあります。
[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)
.
.
.
この例外を受け取った場合でも、ユーザーは正常に作成されます。
Oracle Identity Manager高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。
この場合は、SOAコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードには、既存の管理対象サーバーのMiddlewareホーム、Oracleホーム(SOA)およびドメイン・ディレクトリが含まれます。
新しいWLS_OIMおよびWLS_SOAサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。OIMおよびSOAのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
トポロジをスケール・アップするには、次の手順を実行します。
管理コンソールを使用して、WLS_OIM1またはWLS_SOA1のクローンを新しい管理対象サーバーに作成します。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。
管理コンソールから「環境」→「サーバー」を選択します。
クローンを作成する管理対象サーバー(WLS_OIM1やWLS_SOA1など)を選択します。
「クローンの作成」を選択します。
新しい管理対象サーバーにWLS_OIMnまたはWLS_SOAnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
この後の手順では、すでにWLS_SOA1およびWLS_OIM1を実行しているOIMHOST1に新しいサーバーを追加することを想定しています。
リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPを割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、VIP(浮動IPともいう)を割り当てて他のノードに移動できるようにします。VIPは、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。
新しい管理対象サーバーにSOA、OIM、BPMおよびUMSのJMSサーバーを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_nのような名前を付けます。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 |
SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n)。このJMSサーバーに対して、SOAJMSFileStore_nを使用します。SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
|
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。このJMSサーバーに対して、UMSJMSFileStore_nを使用します。UMSJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
新しいOIMJMSServerの新しい永続ストアを作成します(たとえば、OIMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n
|
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 新しいOIM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
OIMの新しいJMSサーバーを作成します(たとえば、OIMJMSServer_n)。このJMSサーバーに対して、OIMJMSFileStore_nを使用します。OIMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。
新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUCMJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「OIMMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。
第4.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、コンポジットをデプロイする場合のOracle Coherenceを構成します。
|
注意: サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例: Dtangosol.coherence.localhost=SOAHOST1VHNn |
新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。表の「名前」列で「WLS_SOAn」を選択します。
「SSL」タブをクリックします。「詳細設定」をクリックします。
「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。
新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。
新しい管理対象サーバーに対してサーバー移行を構成します。
|
注意: これはスケール・アップ操作であるため、ノード・マネージャ、サーバー移行に対して構成された環境および新しいSOA管理対象サーバーの浮動IPがあらかじめノードに用意されている必要があります。 |
サーバー移行を構成する手順は次のとおりです。
管理コンソールにログインします。
左側のペインで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。
たとえば、すでにWLS_SOA1が実行されているSOAHOST1上の新しい管理対象サーバーには、SOAHOST2を選択します。すでにWLS_SOA2が実行されているSOAHOST2上の新しい管理対象サーバーには、SOAHOST1を選択します。
移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
新しく作成したWLS_OIMn管理対象サーバーに対してサーバー移行を構成するために、このリストの手順を繰り返します。
この新規サーバーのサーバー移行をテストするには、新規サーバーの追加先となったノードで、次の手順を実行します。
管理対象サーバーWLS_SOAnを停止します。
そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを入力します。
ノード・マネージャのコンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
トポロジのスケール・アウトでは、SOAで構成された新しい管理対象サーバーを新しいノードに追加します。
この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。
SOAで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。
新しいノードがWebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること。(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやSOAバイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります。)
|
注意: 共有記憶域にインストールが存在しない場合は、第4.13項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」の説明に従って、新しいノードにWebLogic ServerとSOAをインストールする必要があります。 |
|
注意: ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、user_home/bea/beahomelistファイルを編集します。次の手順を参照してください。 |
トポロジをスケール・アウトするには、次の手順を実行します。
新しいノードで、SOAのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内の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を追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。このサーバーにWLS_SOAnという名前を付けます。nは番号です。
|
注意: これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバーでその管理対象サーバーのリスニング・アドレスに使用するホスト名またはIPを割り当てます。
このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーのVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、既存の管理対象サーバーで使用されているものとは別のものである必要があります。
新しい管理対象サーバーにSOA、OIM(該当する場合)およびUMSのJMSサーバーを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_nのような名前を付けます。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_n
|
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 |
SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n)。このJMSサーバーに対して、SOAJMSFileStore_nを使用します。SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
|
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。このJMSサーバーに対して、UMSJMSFileStore_nを使用します。UMSJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
新しいOIMJMSServerの新しい永続ストアを作成します(たとえば、OIMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n
|
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 新しいOIM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
OIMの新しいJMSサーバーを作成します(たとえば、OIMJMSServer_n)。このJMSサーバーに対して、OIMJMSFileStore_nを使用します。OIMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。
新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUCMJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「OIMMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。
次のように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
第4.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、コンポジットをデプロイする場合のOracle Coherenceを構成します。
|
注意: サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例: Dtangosol.coherence.localhost=SOAHOST1VHNn |
新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
SOAHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。
新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。
新しい管理対象サーバーに対してサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャと、ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しいSOA管理対象サーバーの浮動IPが存在します。 |
次の手順を実行してサーバー移行を構成します。
管理コンソールにログインします。
左側のペインで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
|
注意: 新しいサーバーの移行ターゲットには、負荷が最小のマシンを指定します。このノードのリソースが追加の管理対象サーバーの持続に十分対応できるように、必須のキャパシティ・プランニングを行う必要があります。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。
管理対象サーバーWLS_SOAnを停止します。
そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは、ps -ef | grep WLS_SOAnを使用して確認できます。
ノード・マネージャのコンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
この項では、認可ポリシー・マネージャ11gの概要および認可ポリシー・マネージャの高可用性環境の設計とデプロイについて説明します。
高可用性アクティブ/パッシブ・コールド・フェイルオーバー・クラスタで認可ポリシー・マネージャを使用するには、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」のアクティブ/パッシブ・コールド・フェイルオーバー・クラスタでのWebLogicサーバーの設定手順に従います。
認可ポリシー・マネージャは、WebLogic管理サーバーJVMにデプロイされるため、高可用性アクティブ/アクティブ・デプロイメントでは使用されません。
認可ポリシー・マネージャは、アプリケーション・ポリシーを管理するためのグラフィカル・インタフェース・ツールです。
認可ポリシー・マネージャの対象ユーザーは、セキュリティ管理者です。このツールを使用することで、管理者はエンタープライズ・アプリケーション全体にわたるポリシーを表示および管理できます。管理者は、ドメイン内で実行されているすべてのアプリケーションを管理することも、アプリケーションのサブセットのみを管理することもできます。
認可ポリシー・マネージャは、次の条件が満たされていることを必要とします。
ドメイン・ポリシー・ストアがLDAPベースであること。サポートされているポリシー・ストアはOracle Internet Directoryです。
ドメイン・アイデンティティ・ストアがLDAPベースであること。サポートされているアイデンティティ・ストア・タイプは、Oracle Internet Directory、Oracle Virtual Directory、Oracle WebLogic Server組込みLDAP、Sun Java System Directory Serviceバージョン6.3、Active Directory 2003および2008、Novell eDirectory 8.8、およびOpenLDAP 2.2および2.4です。
2つの特別なデータ・ソース(mds-ApplicationMDSDBとapm-DBDS)を設定します。これらのデータ・ソースは、WebLogicコンソール(「JDBC」→「データ・ソース」の下)で構成できます。
認可ポリシー・マネージャの使用方法の詳細は、Oracle Fusion Middleware Authorization Policy Manager管理者ガイドを参照してください。
Oracle Identity Management Navigatorは、Oracle Identity Management製品のスタート地点として機能するよう設計されている管理ポータルです。これは、個々の製品コンソールに代わるものではありません。1つのサイトからOracle Identity Managementの各コンソールにアクセスできるようにするためのものです。Oracle Identity Management Navigatorの詳細は、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドを参照してください。
Oracle Identity Navigatorは、WebLogic管理サーバーJVMにデプロイされるため、高可用性アクティブ/アクティブ・デプロイメントでは使用されません。
高可用性アクティブ/パッシブ・コールド・フェイルオーバー・クラスタでOracle Identity Navigatorを使用するには、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」のアクティブ/パッシブ・コールド・フェイルオーバー・クラスタでのWebLogicサーバーの設定手順に従います。
この項では、Oracle Adaptive Access Managerの概要およびOracle Adaptive Access Managerの高可用性環境の設計とデプロイについて説明します。
Oracle Adaptive Access Managerは、プラットフォームのプレゼンテーション層、ビジネス・ロジック層、およびデータ層を分けた、J2EEベースの複数層デプロイメント・アーキテクチャに構築されています。層がこのように分離されているため、Oracle Adaptive Access Managerは、お客様のパフォーマンス要件に合せてすばやくスケールできます。このアーキテクチャでは、Java、XML、およびオブジェクト・テクノロジを組み合せた、最も柔軟なサポートされているクロス・プラットフォームJ2EEサービスを利用できます。Oracle Adaptive Access Managerは、このアーキテクチャによって、スケーラブルでフォルト・トレラントなソリューションとなっています。
この項の内容は次のとおりです。
図8-18は、Oracle Adaptive Access Managerの単一インスタンスのアーキテクチャを示しています。
図8-18 Oracle Adaptive Access Managerの単一インスタンス・アーキテクチャ
図8-18に示すOracle Adaptive Access Managerの単一インスタンス・アーキテクチャでは、エンド・ユーザーは、カスタマWebアプリケーションにアクセスし、それがSOAPを使用してOAAM Serverアプリケーションおよびそのポリシーと通信します。かわりに、OAAMプロキシを設定して、エンド・ユーザーがそのマシンと通信し、それがHTTP(S)を使用してOAAM_Serverアプリケーションと通信することもできます。エンド・ユーザーは、認可された場合、カスタマWebアプリケーションにアクセスできます。OAAM_ADMINコンポーネントは、OAAM_SERVERアプリケーションの管理と構成のために使用されます。OAAM_Serverアプリケーションの管理と構成を担当する管理者は、Webブラウザを使用してOAAM_ADMINアプリケーションにアクセスします。ポリシーと構成情報の格納にはOracle RACデータベースが使用されます。
Oracle Adaptive Access Managerは、次の2つのコンポーネントで構成されています。
OAAM_ADMIN: このコンポーネントは、OAAM_SERVERアプリケーションの管理と構成のために使用されます。このコンポーネントは、Oracle JAVA ADF FrameworkのIdentity Managementシェルを使用して開発されており、J2EEコンテナにWebアプリケーションとしてデプロイされます。これは、EARファイルとしてパッケージされています。
OAAM_SERVER: このコンポーネントは、1つのWebアプリケーション内にOAAM AdminサブコンポーネントとOAAM Serverサブコンポーネントが含まれています。OAAM_SERVERコンポーネントはEARファイルとしてパッケージ化されており、Javaクラスに加えてサーブレットとJSPで構成されています。OAAM_SERVERのサブコンポーネントについては、次にレイヤー別に説明します。
プレゼンテーション・レイヤー: 通常、JSP、サーブレットなどのサービスを提供するWebアプリケーション。プレゼンテーション・レイヤーは、強いオーセンティケータを提供します。これはビジネス・レイヤーによって提供されるインタフェース(SOAPまたはJavaネイティブ)を使用してそのサービスにアクセスします。
ビジネス・ロジック・レイヤー: このレイヤーには、リスク分析エンジンを実装するコア・アプリケーション・ロジックが含まれています。このレイヤーは、プレゼンテーション・レイヤーのためのJavaおよびSOAPインタフェースを提供します。Javaインタフェースを使用する場合、ビジネス・ロジック・レイヤーとプレゼンテーション・レイヤーを1つのWebアプリケーションの一部とすることができます。SOAPインタフェースの場合は、これらのレイヤーは異なるアプリケーションとしてデプロイされます。
データ・アクセス・レイヤー: サポートされているリレーショナル・データベースに接続するためのデータ・アクセス・コンポーネントが含まれています。Oracle Adaptive Access Managerは、リレーショナル・データベースにJavaオブジェクトを格納するための強力で柔軟なフレームワークを提供するOracle TopLinkを使用します。
次に示すコンポーネントも、Oracle Adaptive Access Manager 11gR1デプロイメントで使用できます。
Fusion Middleware ControlおよびEnterprise Manager Grid Control: Oracle Adaptive Access Managerは、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。Oracle Adaptive Access Managerは、DMSおよびDiscovery Mbeanを使用してEnterprise Managerと統合します。Enterprise Managerは、コンポーネント・トレースの向上と、監査の構成のためにも使用されます。
Enterprise Managerは、ドメイン内の各管理対象サーバーのログ・ファイルの表示するため、およびトレースをデバッグ・レベル、トレース・レベル、および情報レベルに高めるためにも使用できます。
データ・リポジトリ: Oracle Adaptive Access Managerは、RDBMSデータベースをそのデータ・ストアとして使用します。Oracle Adaptive Access Managerがサポートし、機能するデータベース・トポロジは、次のとおりです。
Oracle Real Application Cluster
Oracle Data Guard
レプリケーション・ストリーム
データベース・パーティション化
Oracle Adaptive Access Managerは、RCUを使用してデータベースにそのスキーマを作成します。
OAAM_Serverコンポーネントには、OAAM ServerサブコンポーネントとOAAM Adminサブコンポーネントが含まれています。
OAAM Serverは、HTTPセッションに状態を格納するステートフル・アプリケーションです。
OAAM Adminは、データベースにそのセッション情報を格納するステートフル・アプリケーションです。
OAAM_Adminコンポーネントは、ADFおよびアイデンティティ管理UIシェルベース・アプリケーションです。それは、ステートレス・アプリケーションであり、そのアプリケーションの状態は、ADFフレームワークによって保持されます。
Oracle Adaptive Access Manager管理コンソールを使用して次のランタイム・タスクを実行できます。
カスタマ・ケア・アプリケーション・タスク
ポリシー、グループ、およびプロパティを含むシステム構成タスク
セッション・データ情報の表示
システム統計ダッシュボードの表示
たとえば、次の管理フローを実行できます。
最近のユーザー問合せ:
最近のログインとセッションの詳細を表示します。
問合せを実行します。
「セッションの詳細」をクリックします。
ログアウトします。
手動によるCSRとエージェント・エースの作成:
カスタマ・ケアをリセットするには、ログインします。
ケースを作成します。
カスタマをリセットします。
ログアウトします。
Oracle Adaptive Access Manager Serverを使用してランタイム処理も実行できます。
Oracle Adaptive Access Manager Serverでは、次のランタイム処理が実行されます。
Oracle Adaptive Access Managerが、デプロイされ、カスタマのアプリケーションと統合されています。
ユーザーがカスタマのアプリケーションにアクセスし、ユーザー資格証明を入力します。
OAAMで構成されたシステムとルールに基づき、次のように様々なログイン・フローがあります。
ユーザー登録: 登録フロー
フローR1: (新規ユーザーとして)ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録をスキップしてログアウトします。
フローR2: ログインし、パスワードを入力し、登録をスキップしてログアウトします。
フローR3: ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行してログアウトします。
フローR4: ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行して無効なアンサーを入力し、検証してログアウトします。
フローR5: (新規デバイスに新規ユーザーとして)ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行してログアウトします。
ログイン・フロー:
フローL1: ログインし、誤ったパスワードを入力します(「ログイン」画面)。
フローL2: ログインし、正しいパスワードを入力し、チャレンジオンが表示される場合は正しい答えを入力し、ログインします。
フローL3: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、正しい答えを入力し、ログインします。
フローL4: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、誤った答えを入力し、チャレンジオンが再表示され、正しい答えを入力し、ログインします。
フローL5: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、誤った答えを入力し、ログインがブロックされます。
フローL6: ログインし、正しいパスワードを入力し、ログインがブロックされます(「ログイン」画面)。
フローL7: ログインし、正しいパスワードを入力し、ログインします。
フローLNU1: (新規ユーザーとしてログイン)ログインし、正しいパスワードを入力し、ログインします。
フローLND1: (既存のユーザー)新しいデバイスでログインし、正しいパスワードを入力し、ログインします。
フローLNUD1: (新規ユーザー)新しいデバイスでログインし、正しいパスワードを入力し、ログインします。
セッション内トランザクション・フロー: ログインし、パスワードを入力し、トランザクションを作成し、トランザクションを更新し、ログアウトします。
OAAMは、次のデータ要素を追跡し、登録します。
ユーザー・ログイン
ユーザー名
デバイス(Cookie、ブラウザ・ヘッダー、提供されたフラッシュ・データ)
IPアドレス
トランザクション・データ
OAAMは、ログイン動作に基づいて適切なポリシーをトリガーします。
Oracle Adaptive Access Manager Serverと管理コンソールは、J2EEアプリケーションとして、WebLogic Serverから提供されるユーザー・インタフェースおよびコマンドライン・ツールを使用して起動できます。
Oracle Adaptive Access Manager Serverは、障害の検出のためにロード・バランサが使用できるヘルス・チェック・リクエスト(HTTPを介したpingリクエスト)をサポートしています。
Oracle Adaptive Access Managerは、サーバー・サイド・メトリック用(DMSを使用)にインストゥルメント処理されており、この情報は管理コンソールに公開されます。DMSメトリック収集が有効化されている場合、エージェントおよびサーバー・コンポーネント・メトリックの監視は、コンポーネントの監視のかわりとして使用できます。さらに、Oracle Adaptive Access Managerは、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。
Oracle Adaptive Access Managerは、その構成情報をデータベースに格納します。これらの構成プロパティは、Oracle Adaptive Access Manager管理コンソールを使用して変更できます。
Oracle Adaptive Access Managerは、構成情報をファイル・システムや展開したEARファイルに格納することはありません。
Oracle Adaptive Access Managerは、デプロイメント・ステージングのnostageモードをサポートします。つまり、すべてのデプロイメント・ファイルはローカルです。
Oracle Adaptive Access Managerは、RDBMSデータベースに外部依存し、それに構成情報を格納します。
Oracle Adaptive Access Managerは、Oracle RACデータベースのためにWebLogic Serverマルチ・データ・ソースを使用します。
Oracle Adaptive Access Managerは、標準Oracle TopLinkオブジェクト・キャッシュ・メカニズムを使用します。
Oracle Adaptive Access Managerは、標準セッション・オブジェクト・シリアライズを使用して、オブジェクトの永続状態を保持します。
Oracle Adaptive Access Managerは、どのようなホスト名、IPアドレス、またはポートにも依存しません。コンテナ固有のポートまたはホスト名で機能します。
Oracle Adaptive Access Managerは、WebLogic Server上にデプロイされるJ2EEアプリケーションです。すべてのログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。
WL_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
この項では、Oracle Adaptive Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
図8-19は、Oracle Adaptive Access Managerの高可用性アーキテクチャを示しています。
図8-19 Oracle Adaptive Access Managerの高可用性アーキテクチャ
図8-19では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてからWeb層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohsが使用されてOAAMHOST1およびOAAMHOST2上のWebLogic管理対象サーバーにリクエストが転送されます。
OAAMHOST1とOAAMHOST2には、Oracle Adaptive Access Manager ServerアプリケーションとOracle Adaptive Access Manager Adminアプリケーションをホストする管理対象サーバーが含まれています。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。
WebLogic管理サーバーは、OAAMHOST1上で実行され、WebLogic管理コンソールとOracle Enterprise Manager Fusion Middleware Controlを含んでいます。管理サーバーは、OAAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAAMHOST1が使用不可になった場合に、管理サーバーをOAAMHOST2上で手動で起動できます。
ディレクトリ層で、仮想IP ovd.example.comは、Oracle Virtual DirectoryリクエストをOVDHOST1とOVDHOST2にルーティングするように設定されます。OVDHOST1とOVDHOST2は、アクティブ/アクティブのOracle Virtual Directoryクラスタを構成します。仮想IP oid.example.comは、Oracle Internet DirectoryリクエストをOIDHOST1とOIDHOST2にルーティングするように設定されます。OIDHOST1とOIDHOST2は、アクティブ/アクティブのOracle Internet Directoryクラスタを構成します。
Oracle RACデータベースは、データ層における高可用性を提供します。
図8-19は、OAAMの高可用性構成アーキテクチャを示しています。図では、ロード・バランサによって、WEBHOST1およびWEBHOST2上の2つのOracle HTTP Serverインスタンスを介してOAAMHOST1およびOAAMHOST2にリクエストがルーティングされます。OAAM管理サーバー・インスタンスおよびOAAM管理対象サーバー・インスタンスは、OAAMHOST1およびOAAMHOST2にインストールされ、これらのインストールは、OAAM Serverクラスタ(OAAM_Cluster)およびOAAM Adminクラスタ(OAAM_Admin_Cluster)として構成されます。OAAM ServerクラスタはOAAM Serverデータ・ソースを使用し、OAAM AdminクラスタはOAAM Adminデータ・ソースを使用して、Oracle RACデータベースと通信します。
図8-19に示すように、1つのWebLogic ServerドメインでサポートされるOracle Adaptive Access Manager ServerクラスタとOracle Adaptive Access Manager Administrationクラスタはそれぞれ1つです。さらに、Oracle Adaptive Access Manager関連のクラスタは、複数のWebLogic Serverドメインにわたることはできません。
単一インスタンスのOracle Adaptive Access Managerデプロイメントは、次の高可用性要件を満たします。
ロード処理
外部接続管理と監視
リカバリ
フォルト包含
フォルト診断
Oracle Adaptive Access Manager AdminまたはServerのオフライン
複数インスタンスのOracle Adaptive Access Managerデプロイメントは、次の追加の高可用性要件を満たします。
冗長性
クライアント接続のフェイルオーバー/継続性
クライアントのロード・バランシング
状態管理
インバウンドHTTP接続の場合は、外部ロード・バランシング・ルーターの使用をお薦めします。
Webセッションは、Oracle Adaptive Access Manager管理コンソールおよびサーバーへの永続TCP接続を開きます。これには、TCP接続の早すぎる終了を回避するために、ロード・バランシング・ルーターとファイアウォール接続タイムアウトを十分大きい値にする必要があります。
各Oracle Adaptive Access Manager管理コンソールおよびサーバー・インスタンスは、他のインスタンスのピアです。すべての初期化は、サーバーがリクエストを受信できるようになる前に行われることと、組込みのスロットル機能のために、サージ状態はOracle Adaptive Access Manager 11gR1アクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく正常に処理されます。
クラスタが停止した場合、新しいリクエストは拒否され、既存のリクエストはOracle Adaptive Access Manager管理コンソールおよびサーバー・アプリケーションが停止する前に完了できます。強制シャットダウンが行われた場合、Oracle Adaptive Access Manager 11gR1は、その強制シャットダウンによって破損または無効になったデータをリカバリします。
Oracle Adaptive Access Managerコンポーネントは、Pure J2EEアプリケーションであり、それ自体に起動および停止の機能はありません。かわりに、それらは、コンテナ固有の起動および停止機能に依存します。
Oracle Adaptive Access Managerコンポーネントは、WebLogic Server管理対象サーバー・ノードにデプロイされます。ノード・マネージャを使用してコンポーネントを再起動します。
Oracle Adaptive Access Managerは、構成全体をデータベースに格納するため、構成変更のすべてのクラスタ・メンバーへの伝播は透過的です。すべてのOracle Adaptive Access Managerコンポーネントは、変更イベントを内部レイヤーから通知されて取得します。変更の原子性を確保するために、Oracle Adaptive Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。
Oracle Adaptive Access Managerの構成は、クラスタ内のすべてのインスタンスに適用されます。
Oracle Adaptive Access Manager管理コンソールおよびサーバー・インスタンスの追加および削除は、クラスタ内の他のOracle Adaptive Access Managerインスタンスに対して透過的です。
Oracle Adaptive Access Managerクラスタには、任意の数のインスタンスを含めることができます。1つのクラスタ当たりのインスタンス数に制限はありません。
オンライン・アプリケーション・デプロイメントによって問題が発生することはありません。
次の機能が、Oracle Adaptive Access Managerの高可用性構成を障害から保護します。
クラスタのセッションの状態は、メモリー内に保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。
Oracle Adaptive Access Managerサーバーは、ハート・ビート・チェック(HTTPを介したpingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視し、アプリケーションが実行されていない場合は再起動することができます。Oracle Adaptive Access Managerサーバーを再起動しても、他の実行中のコンポーネントやクラスタ・メンバーには影響ありません。
WebLogic Serverノードで障害が発生した場合、外部接続のフェイルオーバーは、構成、再試行のタイムアウトおよび再試行回数に基づいて行われます。
ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、それはその後の処理のためにそのセッション状態を取得します。
Oracle Adaptive Access Managerセッションが、Oracle RACデータベース・ノードの障害に直接影響を与えることはありません。それは、WebLogic Serverがそのデータベース接続の状態を保持しているためです。
この項では、Oracle Adaptive Access Managerで最大限の高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAAMサーバーに配布します。これらのOAAMサーバーは、Oracle Real Application Clusters (Oracle RAC)データベースと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。
この項の内容は次のとおりです。
第8.12.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」
第8.12.3.12項「Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成」
第8.12.3.14項「Oracle Adaptive Access Managerトポロジのスケール・アップとスケール・アウト」
|
注意: Oracle Adaptive Access Managerをインストールしてオフラインで構成するには、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のAdaptive Access Managerのインストールとオフライン構成に関する項を参照してください。 |
Oracle Adaptive Access Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。
データベースにOAAMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。
OAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行手順は、第8.12.3.2項「データベースにOAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行」を参照してください。
OAAMHOST1およびOAAMHOST2にOracle WebLogic Serverをインストールします。
第8.12.3.3項「Oracle WebLogic Serverのインストール」の手順に従い、OAMHOST1およびOAMHOST2にOracle WebLogic Serverをインストールします。
OAAMHOST1およびOAAMHOST2にOracle Identity Management実行可能ファイルをインストールし、構成します。
第8.12.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」の手順に従い、OAAMHOST1およびOAAMHOST2にOracle Identity Management実行可能ファイルをインストールします。
データベース・リポジトリにOAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行手順は、第8.2.4.1項「リポジトリ作成ユーティリティの実行」を参照してください。
Oracle WebLogic Serverをインストールする前に、お使いのマシンが、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』に指定されているシステム、パッチ、カーネルなどの要件を満たしていることを確認します。
インストーラを起動し、次の手順を実行します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
ORACLE_BASE/product/fmw
|
注意: ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。 |
「次へ」をクリックします。
セキュリティ・アップデートが通知されるようにするために、「セキュリティ更新のための登録」画面で連絡先情報を入力します。
「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択します。
「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
「完了」をクリックします。
次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOAAMHOST1およびOAAMHOST2にインストールします。
Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。
次のようにOracle Fusion Middlewareのインストーラを起動します。
OAAMHOST1> runInstaller
インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_<バージョン>のように入力します。
次の手順を実行します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
Oracleミドルウェア・ホーム: MW_HOMEのリストから前にインストールしたミドルウェア・ホームを選択します。例:
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ:
IDM_ORACLE_HOMEにOracle Identity Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてidmを入力します。
IAM_ORACLE_HOMEにOracle Identity and Access Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてiamを入力します。SOA_ORACLE_HOMEにOracle SOA Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてsoaを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストールと構成」をクリックします。
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で、次を選択します。
「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
次の製品を選択します。
Oracle Enterprise Manager
Oracle JRF(デフォルトで選択)
Oracle Adaptive Access Manager - Server
Oracle Adaptive Access Manager管理サーバー
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、次を入力します。
ドメイン名: IDM_Domain
ドメイン・ディレクトリ: デフォルトを受け入れます。
アプリケーション・ディレクトリ: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択します。
JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。
「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAAM Admin Serverを選択し、次の項目を入力します。
データ・ソース: OAAM Admin Server
サービス名: oaam.example.com
ユーザー名: OAAM_OAAM (OAAMがRCU接頭辞として使用されていたと想定)
パスワード: 前述のアカウント用のパスワード
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: OAAMDBHOST1
インスタンス名: oaamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: OAAMDBHOST2
インスタンス名: oaamdb2
ポート: 1521
このデータ・ソースの選択を解除します。次のデータ・ソースであるOAAM Admin MDSスキーマを選択し、次の情報を入力します。
データ・ソース: OAAM Admin MDSスキーマ
サービス名: oaam.example.com
ユーザー名: OAAM_MDS (OAAMがRCU接頭辞として使用されていたと想定)
パスワード: OAAM_MDSアカウント用パスワードです。
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: OAAMDBHOST1
インスタンス名: oaamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: OAAMDBHOST2
インスタンス名: oaamdb2
ポート: 1521
このデータ・ソースの選択を解除します。次のデータ・ソースであるOAAM Serverを選択し、次の情報を入力します。
データ・ソース: OAAM Server
サービス名: oaam.example.com
ユーザー名: OAAM_OAAM (OAAMがRCU接頭辞として使用されていたと想定)
パスワード: OAAM_OAAMアカウント用パスワードです。
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: OAAMDBHOST1
インスタンス名: oaamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: OAAMDBHOST2
インスタンス名: oaamdb2
ポート: 1521
このデータ・ソースの選択を解除します。次のデータ・ソースであるOWSM MDSスキーマを選択し、次の情報を入力します。
データ・ソース: OWSM MDSスキーマ
サービス名: oaam.example.com
ユーザー名: OAAM_MDS (OAAMがRCU接頭辞として使用されていたと想定)
パスワード: OAAM_MDSアカウント用パスワードです。
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: INFRADBHOST1
インスタンス名: oaamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: INFRADBHOST2
インスタンス名: oaamdb2
ポート: 1521
このデータ・ソースの選択を解除します。
「次へ」をクリックします。
「コンポーネント・スキーマのテスト」画面で、構成ウィザードはデータ・ソースの検証を試行します。
データ・ソースの検証が成功したら、「次へ」をクリックします。
失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「次へ」をクリックします。
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: 管理サーバーの仮想ホスト名を入力します(例: OAAMHOST1.example.com)。
Listen port: 7001
SSLリスニング・ポート: 適用なし
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、トポロジのOAAMHOSTごとに2つのエントリを作成します。つまり、OAAM Serverに対して1つと、OAAM Admin Serverに対して1つ作成します。
OAAM_SERVERエントリを選択し、そのエントリを次の値に変更します。
Name: WLS_OAAM1
リスニング・アドレス: OAAMHOST1.example.com
Listen port: 14300
SSLリスニング・ポート: 14301
SSL有効: 選択
2つ目のOAAM_SERVERに対して、「追加」をクリックし、次の情報を入力します。
Name: WLS_OAAM2
リスニング・アドレス: OAAMHOST2.example.com
Listen port: 14300
SSLリスニング・ポート: 14301
SSL有効: 選択
OAAM_ADMIN_SERVERエントリを選択し、そのエントリを次の値に変更します。
Name: WLS_OAAM_ADMIN1
リスニング・アドレス: OAAMHOST1.example.com
Listen port: 14200
SSLリスニング・ポート: 14201
SSL有効: 選択
2つ目のOAAM_ADMIN_SERVERに対して、「追加」をクリックし、次の情報を入力します。
Name: WLS_OAAM_ADMIN2
リスニング・アドレス: OAAMHOST2.example.com
Listen port: 14200
SSLリスニング・ポート: 14201
SSL有効: 選択
その他すべてのフィールドはデフォルトの設定のままにします。
「次へ」をクリックします。
「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前としてOAAM_Clusterを入力します。
「追加」をクリックし、2つ目のクラスタを作成します。
名前としてOAAM_Admin_Clusterを入力します。
その他すべてのフィールドはデフォルトの設定のままにします。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。
右のウィンドウでクラスタ名OAAM_Clusterをクリックします。
管理対象サーバーWLS_OAAM1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。
管理対象サーバーWLS_OAAM2に対しても同様に繰り返します。
続いて、次のように操作します。
右のウィンドウでクラスタ名OAAM_Admin_Clusterをクリックします。
管理対象サーバーWLS_OAAM_ADMIN1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。
管理対象サーバーWLS_OAAM_ADMIN2に対しても同様に繰り返します。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジ内の各サーバーのマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を入力します。
名前: ホストの名前。ベスト・プラクティスは、DNS名(OAAMHOST1)を使用することです。
ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAAMHOST1.example.com)
ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。
OAAMHOST1について、次のように操作します。
右のウィンドウでマシンOAAMHOST1をクリックします。
左のウィンドウで管理対象サーバーWLS_OAAM1をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。
左のウィンドウで管理対象サーバーWLS_OAAM_ADMIN1をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。
OAAMHOST2について、次のように操作します。
右のウィンドウでマシンOAAMHOST2をクリックします。
左のウィンドウで管理対象サーバーWLS_OAAM2をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。
左のウィンドウで管理対象サーバーWLS_OAAM_ADMIN2をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。
「次へ」をクリックします。
「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。
この項では、OAAMHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法について説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。
次の手順に従って、boot.propertiesファイルを作成します。
管理サーバーを起動します。
OAAMHOST1で、次のディレクトリに移動します。
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
例:
cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security
テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUserpassword=adminUserPassword
|
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。 |
管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OAAMHOST1上の管理サーバーを起動します。
Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
WebLogic Server管理コンソール:
http://oaamhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oaamhost1.example.com:7001/em
weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。
OAAMコンソールへのアクセスに使用する管理ユーザーを作成します。そのためには、次の手順を実行してください。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oaamhost1.example.com:7001/console
「ドメイン構造」メニューで、「セキュリティ・レルム」→「myrealm」を選択します。
「ユーザーとグループ」タブをクリックします。
「ユーザー」サブタブをクリックします。
「新規」をクリックします。
次の値を入力します。
名前: ユーザーの名前。例: oaam_admin
プロバイダ: デフォルト・オーセンティケータ
パスワード/確認: ユーザーのパスワード
「OK」をクリックします。
ユーザーを作成したら、そのユーザー名をクリックします。
「グループ」サブタブをクリックします。
ユーザーを次のグループに割り当てます。
OAAMCSRGroup
OAAMCSRManagerGroup
OAAMInvestigatorGroup
OAAMInvestigationManagerGroup
OAAMRuleAdministratorGroup
OAAMEnvAdminGroup
OAAMSOAPServicesGroup
「保存」をクリックします。
OAAMHOST1を起動します。
この項では、OAAMHOST1の起動手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:
OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
次のコマンドを発行してノード・マネージャを起動します。
OAAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
OAAMHOST1上のOracle Adaptive Access Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oaamhost1.example.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAAM1およびWLS_OAAM_ADMIN1をクリックします。
「起動」をクリックします。
「OK」をクリックし、サーバーを起動することを確認します。
次のURLにあるOAAM管理サーバーに接続することによって実装を検証します。
http://OAAMHOST1.example.com:14200/oaam_admin
OAAM管理コンソールのログイン・ページが表示され、第8.12.3.6項「Oracle Adaptive Access Manager管理ユーザーの作成」で作成したoaamadminアカウントを使用してログインできる場合、実装は有効です。
次の場所にあるOAAMサーバーに接続することによって実装を検証します:
http://OAAMHOST1.example.com:14300/oaam_server
OAAMサーバーのログイン・ページが表示される場合、実装は有効です。
OAAMHOST1で構成を完了したら、それをOAAMHOST2に伝播できます。これを実行するには、OAAMHOST1でpackスクリプトを使用してドメインをパックし、OAAMHOST2でunpackスクリプトを使用してドメインを解凍します。
スクリプトは両方とも、MW_HOME/oracle_common/common/binディレクトリにあります。
OAAMHOST1で、次のように入力します。
pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar -template_name="OAAM Domain" -managed=true
これにより、/tmpディレクトリにidm_domain.jarというファイルが作成されます。このファイルをOAAMHOST2にコピーします。
OAAMHOST2で、次のように入力します。
unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar
OAAMHOST2を起動します。
この項では、OAAMHOST2の起動手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:
OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
次のコマンドを発行してノード・マネージャを起動します。
OAAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
OAAMHOST2上のOracle Adaptive Access Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oaamhost2.example.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAAM2およびWLS_OAAM_ADMIN2をクリックします。
「起動」をクリックします。
「OK」をクリックし、サーバーを起動することを確認します。
次のURLにあるOAAM管理サーバーに接続することによって実装を検証します。
http://OAAMHOST2.example.com:14200/oaam_admin
OAAM管理コンソールのログイン・ページが表示され、第8.12.3.6項「Oracle Adaptive Access Manager管理ユーザーの作成」で作成したoaamadminアカウントを使用してログインできる場合、実装は有効です。
次の場所にあるOAAMサーバーに接続することによって実装を検証します:
http://OAAMHOST2.example.com:14300/oaam_server
OAAMサーバーのログイン・ページが表示される場合、実装は有効です。
この項では、Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成手順について説明します。
WEBHOST1およびWEBHOST2で、次のディレクトリにoaam.confというファイルを作成します。
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
次の行を指定してファイルを作成します。
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName oaam.example.com:7777
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
<Location /oaam_server>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.example.com:14300,oaamhost2.example.com:14300
</Location>
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.example.com:14200,oaamhost2.example.com:14200
WebLogicPort 7001
</Location>
</VirtualHost>
WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。
WEBHOST1>opmnctl stopall WEBHOST1>opmnctl startall WEBHOST2>opmnctl stopall WEBHOST2>opmnctl startall
Oracle HTTP Serverは、WebLogicのプロキシとして機能するため、デフォルトでは、特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。
そのためには、次のWebLogic管理コンソールにログインします。
http://oaamhost1.example.com:7001/console
次の手順を実行します。
ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。
「チェンジ・センター」ウィンドウで「ロックして編集」をクリックし、編集可能にします。
クラスタ名(oaam_cluster)をクリックします。
「一般」タブで、「拡張プロパティ」セクションのボックスを選択して、WebLogicプラグインを「有効」に設定します。
「保存」をクリックします。
「HTTP」を選択し、次の値を入力します。
フロントエンド・ホスト: oaam.example.com
フロントエンドHTTPポート: 7777
フロントエンドHTTPSポート: SSL通信を使用している場合は、ロード・バランサ上のSSLポートまたはOracle HTTP Server SSLポートに設定します。
これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート443または80に送られます。
「保存」をクリックします。
ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。
クラスタ名(oaam_admin_cluster)をクリックします。
「一般」タブで、「拡張プロパティ」セクションのボックスを選択して、WebLogicプラグインを「有効」に設定します。
「保存」をクリックします。
「HTTP」を選択し、次の値を入力します。
フロントエンド・ホスト: oaam.example.com
フロントエンドHTTPポート: 7777
フロントエンドHTTPSポート: SSL通信を使用している場合は、ロード・バランサ上のSSLポートまたはOracle HTTP Server SSLポートに設定します。
「保存」をクリックします。
「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックし、変更を保存します。
管理対象サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1、およびWLS_OAAM_ADMIN2を次のようにして再起動します。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oaamhost1.example.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2をクリックします。
「停止 - ただちに強制停止」を選択します。
「はい」をクリックし、サーバーを停止することを確認します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2をクリックします。
「起動」をクリックします。
「はい」をクリックし、サーバーを起動することを確認します。
管理サーバーを再起動します。
Oracle Adaptive Access Manager管理コンソール(http://oaam.example.com:7777/oaam_admin)に、作成したoaamadminアカウントを使用してログインします。
Oracle Adaptive Access Managerサーバー(http://oaam.example.com:7777/oaam_server)に、作成したoaamadminアカウントおよびパスワード・テストを使用してログインします。
この項では、Oracle Adaptive Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいOracle Adaptive Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいOracle Adaptive Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。
OAAMをスケール・アップするには、OAAMサーバーとOAAM管理サーバーの両方に対して同じ手順を使用します。
Oracle WebLogic Serverコンソール(http://oaamhost1.example.com:7001/console)にログインします。次の手順を実行します。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」メニューで「ロックして編集」をクリックします。
拡張するホストで既存のサーバーを選択します。例: WLS_OAAM1またはWLS_OAAM_ADMIN1
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前。例: WLS_OAAM3
サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。
「OK」をクリックします。
新しく作成したサーバーWLS_OAAM3をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOAAMHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ペインで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
「チェンジ・センター」メニューで構成のアクティブ化をクリックします。
スケール・アウトはスケール・アップと非常によく似ていますが、スケール・アウトでは、新しいノードにインストールされるソフトウェアが必要です。次の手順を実行します。
第8.12.3.3項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。
第8.12.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」の手順に従い、新しいホストにOracle Fusion Middleware Identity Managementコンポーネントをインストールします。
WebLogicコンソール(http://oaamhost1.example.com:7001/console)にログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」メニューで「ロックして編集」をクリックします。
拡張するホストで既存のサーバーを選択します。例: WLS_OAAM1またはWLS_OAAM_ADMIN1
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前。例: WLS_OAAM3
サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。
「OK」をクリックします。
新しく作成したサーバーWLS_OAAM3をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOAAMHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ペインで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
「チェンジ・センター」メニューで構成のアクティブ化をクリックします。
次のコマンドを使用してOAAMHOST1上のドメインをパックします。
pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAAM Domain" -managed=true
pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
次のコマンドを使用して新しいホスト上のドメインを解凍します。
unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications
unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
コンソールから管理対象サーバーを起動する前に、スクリプトsetNMProps.shを実行してOAAMHOST2上にノード・マネージャのプロパティ・ファイルを作成しておく必要があります。setNMProps.shスクリプトは、MW_HOME/oracle_common/common/binにあります。次のように入力します。
OAAMHOST2> $MW_HOME/oracle_common/common/bin/setNMProps.sh
新しいホストでノード・マネージャと新しい管理対象サーバーを起動します。
これで、新しい管理対象サーバーが作成されて起動され、Web層はリクエストをその管理対象サーバーに転送するようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
これを行うには、各Web層でファイルoaam.confを更新します。このファイルは、ディレクトリORACLE_INSTANCE/config/OHS/component_name/moduleconfにあります。
新しいサーバーをファイル内のWebLogicClusterディレクティブに追加します。次に例を示します。
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.example.com:14200,oaamhost2.example.com:14200
</Location>
変更後:
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster
oaamhost1.example.com:14200,oaamhost2.example.com:14200,oaamhost3.example.com:14300
</Location>
この項では、Oracle Identity Federationの概要およびOracle Identity Federationの高可用性環境の設計とデプロイについて説明します。
Oracle Identity Federationは、複数ドメインのアイデンティティ・ネットワークのシングル・サインオンと認証を提供し、最も広範なフェデレーション標準のセットをサポートするスタンドアロンの自己完結型フェデレーション・サーバーです。これにより、ソリューション・セットでその他のOracle Identity Management製品が実装されているかどうかに関係なく、異種環境とビジネス結合に属するユーザーのフェデレーションが可能になります。
これは、アイデンティティ・プロバイダ(IdP)およびサービス・プロバイダ(SP)両方の役割を果たすマルチプロトコル・ハブとしてデプロイできます。
Oracle Identity Federationは、SPとして機能することで、帯域外の複数のセキュリティ・ドメイン間でユーザー同期をせずに、実際のユーザー認証をIdPにオフロードする間もリソース管理を可能にします。IdPで認証されると、SPは、ローカル・アクセス・ポリシーに応じて、そのSPのアプリケーションに対するユーザーのアクセスを許可または拒否できます。
ユーザーがそのIdPに対するアカウントを持っていない場合、フェデレーションは終了し、そのユーザーのドメイン間でのシングル・サインオンは自動的に無効化されます。Oracle Identity FederationをIdPとして利用すると、信頼できるプロバイダからの連携リクエストに基づいて、ローカル・ユーザーの管理と認証が実行できます。
Oracle Identity Federationの主要な機能には、次のサポートが含まれます。
SAML 1.x、SAML 2.0、WS-Federation、SAML 1.x/2.0属性共有機能、Liberty ID-FF 1.1/ Liberty ID-FF 1.2などの複数の主要なフェデレーション・プロトコル
プロトコルを超えたシングル・サインオンおよびサインアウト
サービス・プロバイダのフェデレーション情報の共有化およびフェデレーションの数の削減によるアフィリエーション
X.509証明書検証
Oracle Access ManagerおよびOracle Single Sign-Onとの統合
Oracle Internet Directoryとの統合および広範な認証エンジン、ユーザー・データ・リポジトリ、リレーショナル・データベースのサポート
アイデンティティ・プロバイダおよびサービス・プロバイダの両方が含まれる環境でのサイトを超えたアクセスと認証の実装
外部サイトを構成、有効化および無効化する機能
シングル・サインオンを使用した宛先サイトのアプリケーションへのアクセス
図8-20は、非高可用性アーキテクチャのOracle WebLogic ServerにデプロイされたOracle Identity Federationと、他のフェデレーション・コンポーネントとの関係を示しています。
図8-20は、他のアイデンティティ・プロバイダ(IdP)およびサービス・プロバイダ(SP)間のフェデレーション・メンバーとしてのOracle Identity Federationを示しています。
Oracle Identity Federation認証サービスは次のように構成できます。
Oracle Single Sign-On (Oracle Internet Directoryユーザー・リポジトリを使用)またはOracle Access Manager(各種リポジトリを使用)により保護されたリソースへのシングル・サインオン・アクセスを可能にします。リソースとして、Oracle Collaboration Suite、Oracle E-Business Suite、PeopleSoftモジュールなどを含めることができます。
LDAPディレクトリ、RDBMSデータベース、Oracle Access Managerなどのアイデンティティおよびアクセス管理ソリューションと相互運用できます。
|
注意: Oracle Identity FederationとOracle Single Sign-Onの両方がリソースを保護している環境では、いずれかのコンポーネントを、ユーザー・リクエストが保護リソースにアクセスした場合に認証メカニズムとして動作するように構成できます。また、Oracle Identity FederationとOracle Access Managerの両方を含む環境にも同様の機能があります。 Oracle Identity Federation認証の詳細は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドを参照してください。 |
Oracle Identity Federationは、J2EE標準に準拠した、スタンドアロンの自己完結型フェデレーション・サーバーです。複数ドメインのアイデンティティ・ネットワークのシングル・サインオンと認証を提供し、SAML 1.x、SAML 2.0、WS-Federation、およびSAML 1.x/2.0属性共有機能など、広範なフェデレーション標準のセットをサポートします。
Oracle Identity Federationは、デフォルトでは、Oracle WebLogic Serverに対して外部的にステージングされたアプリケーションとしてデプロイされます。
Oracle Identity Federationは、Oracle WebLogic Serverに対して外部的にステージングされたアプリケーションとしてデプロイされるJ2EEアプリケーションです。Oracle Identity Federationサーバーは、デプロイされたWebLogic Serverの起動時に初期化されます。
Oracle Identity Federationアプリケーションは、資格証明ストア・フレームワークにアクセスして、バックエンド・サーバーに接続するための資格証明を取得します。この処理が完了すると、Oracle Identity Federationサーバーは実行状態となり、リクエストを受け入れて処理する準備ができます。
Oracle Identity Federationは、外部的に管理されるアプリケーションとしてOracle WebLogic Serverにデプロイされます。Oracle WebLogic Serverはデフォルトで、Oracle Identity Federationアプリケーションに対する他のライフサイクル・イベントの起動、停止、監視、および管理を行います。
このアプリケーションは、デプロイされるOracle WebLogic Serverの起動時に初期化され、WebLogic Serverの停止時に停止されます。
WebLogicノード・マネージャは、サーバー・プロセスを監視し、障害発生時にそのプロセスを再起動するように構成できます。
Oracle Enterprise Manager Fusion Middleware Controlは、アプリケーションの監視および構成の変更に使用します。
起動および停止
Oracle Identity Federationのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理できます。
Oracle WebLogic Scripting Tool (WLST)
Oracle WebLogic Server管理コンソール
Oracle Enterprise Manager Fusion Middleware Control
WebLogicノード・マネージャ
通常、ユーザーは、会社のポータルを介して複数のドメインのアプリケーションにアクセスします。たとえば、Alpha Corporationが、Alphaのユーザー・ログイン、ページのパーソナライズを管理するポータル・サーバーを備えているとします。そのポータル・サーバーは、アプリケーション・サーバー内で動作する自社製ロジックで構成されている場合や、市販の製品の場合があります。パートナ会社であるBeta Corporationは、MyBeta.comというタイプのポータルを使用して、その技術的なデータベース・アプリケーションを提供できます。この場合、それぞれが自社ポータル・サーバーを運用していることになります。
プロセス・フローは次のようになります。
ユーザーは、Oracle Access ManagerやOracle Single Sign-OnなどのWebアクセス管理(WAM)システムによりアクセスが管理されているAlphaポータルにログインします。
ユーザーは、実際にはBeta Corporationがホストしているリソースをクリックしてリクエストを開始します。
アイデンティティ・プロバイダ(IdP)として動作しているAlphaポータルのOracle Identity Federationインスタンスが、ユーザー情報をWAMシステムに送信します。
WAMシステムは、ローカル・アイデンティティ・ストアのアイデンティティにユーザーをマッピングした後、セッションを作成します。
WAMシステムにより、成功したレスポンスとセッション・トークンがAlphaポータルのOracle Identity Federation IdPサーバーに戻されます。
前述の情報を使用して、AlphaポータルのIdPはSAMLアイデンティティ・アサーションを作成し、プライベート署名キーを使用して署名します。このレスポンスは、Beta Corporationのサービス・プロバイダ(SP)として動作するOracle Identity Federationインスタンスに送信されます。
Beta CorporationのSPとして動作するOracle Identity Federationサーバーは、署名キーに関連付けられたIdPのパブリック証明書を使用して署名付きレスポンスを検証します。
Beta CorporationのOracle Identity Federationサービス・プロバイダはアサーションを抽出し、ユーザー・セッションをローカル認証システムにマッピングした後、アサーションに対するユーザー・セッションを作成します。
Oracle Identity Federationサービス・プロバイダは、ユーザーのブラウザにリクエストされたリソースへのリダイレクトを送信します。
ユーザーのブラウザは、サービス・プロバイダによって作成されたユーザー・セッションを介して、ターゲット・リソースへのリクエストを送信します。
Oracle Identity Federationサーバーの構成は、MBeansによって管理されます。Oracle Identity Federationの構成データは、次の3つのメイン・ファイルに格納されます。
config.xml: サーバー全体の構成が格納されます。
cot.xml: プロバイダ固有の構成が格納されます。
datastore.xml: バックエンドのデータ・ストアの構成が格納されます。
Oracle Identity Federationアプリケーションは、Oracle Identity Management 11gインストーラによって、EARファイルとしてデプロイされます。Oracle Identity Federationアプリケーションは、ORACLE_HOME/fed/install/oif.earディレクトリの下にあります。
Oracle Identity Federation構成アーティファクトは、アプリケーションがデプロイされた管理対象サーバーのDOMAIN_HOME/config/fmwconfig/servers/serverName/applications/OIF_11.1.1.2.0/configurationディレクトリの下にあります。
Oracle Enterprise Manager Fusion Middleware Controlを使用して構成を変更すると、ノード間での構成の不整合を回避できます。これは、アプリケーションが高可用性構成にデプロイされている場合、特に有効です。ただし、WLSTスクリプトおよびJMX MBeansを使用してOracle Identity Federationサーバーを構成することもできます。
Oracle Identity Federationサーバーは、Oracle WebLogic管理対象サーバーにデプロイされるJ2EEアプリケーションです。Oracle Identity Federationサーバーは外部構成データ、ランタイム一時データ(メッセージ、ユーザー・セッション)、およびフェデレーション・データを格納するリポジトリと対話して、ユーザーの認証を行います。Oracle Identity Federationサーバーでは、初期化中または実行時に、これらのリポジトリが使用可能である必要があります。Oracle Identity Federationサーバーの機能に必要な外部コンポーネントは次のとおりです。
Oracle WebLogic Server
管理サーバー
管理対象サーバー
データ・リポジトリ
メッセージ・データ・ストアおよびユーザー・セッション・データ・ストア(一時データ・ストア)
構成データ・ストア
ユーザー・データ・ストア
フェデレーション・データ・ストア
認証エンジン
サービス・プロバイダ・エンジン
これらの外部コンポーネントがOracle Identity Federationを使用してどのように機能するかについては、次の各項を参照してください。
Oracle WebLogic Server
Oracle Identity Federationサーバーは、Oracle WebLogic管理対象サーバーにデプロイされるJ2EEアプリケーションです。このサーバーは、Oracle Enterprise Manager Fusion Middlewareを使用して管理されます。
管理対象サーバーが実行されていない場合は、アプリケーションを起動できません。管理サーバーが使用できない場合は、このサーバーは現行の状態で実行を続けますが、構成の変更はできません。
データ・リポジトリ
Oracle Identity Federationサーバーは、様々な外部データ・リポジトリを使用して、構成、ユーザー・セッション、メッセージ、およびフェデレーション・データを格納します。このサーバーでは、初期化中または実行時、あるいはその両方で、これらのデータ・ストアが使用可能である必要があります。リポジトリの詳細は次のとおりです。
メッセージ・データ・ストアとユーザー・セッション・データ・ストア(一時データ・ストア)
Oracle Identity Federationサーバーは、フェデレーション・プロトコル/セッションの状態などの一時データの格納にメッセージ・データ・ストアとユーザー・データ・ストアを使用します。メッセージ・データ・ストアはユーザー・セッション・データ・ストアとともに、一時データ・ストアとも呼ばれます。
Oracle Identity Federationサーバーのデプロイメント・オプションに応じて、一時データは、メモリーまたはリレーショナル・データベースに格納されます。表8-11は、デプロイメント・オプションとそのオプションに必要な一時データ・ストアのタイプとの関係を示しています。
構成データ・ストア
Oracle Identity Federationアプリケーションは、構成データ・ストアを使用して、構成アーティファクトを格納します。Oracle Identity Federationサーバーのデプロイメント・オプションに応じて、構成データ・ストアはXMLファイル、またはリレーショナル・データベースに格納されます。
表8-12は、デプロイメント・オプションとそのオプションに必要な構成データ・ストアのタイプとの関係を示しています。
表8-12 Oracle Identity Federationのデプロイメント・オプションに対応する構成データ・ストアのタイプ
| デプロイメント・オプション | ストア・タイプ |
|---|---|
|
非高可用性/スタンドアロン |
XML リレーショナル・データベース・ストア |
|
高可用性 |
リレーショナル・データベース・ストア |
Oracle Identity Federationアプリケーションは、プロセスの起動時に、構成データ・ストアに接続して構成データを取得します。構成データ・ストアが使用できない場合は、アプリケーションを起動できません。
ユーザー・データ・ストア
Oracle Identity Federationサーバーでは、ローカル認証の後、またはSAMLアサーションの受信処理の後にユーザーを特定するとき、およびユーザー固有の属性を取得するときに、ユーザー・データ・ストアを使用します。ユーザー・データ・リポジトリは、リレーショナル・データベースまたはLDAPリポジトリになります。
Oracle Identity Federationサーバーでは、Oracle Internet Directory、Sun Java System Directory Server、Microsoft Active DirectoryなどのLDAPリポジトリ、およびリレーショナル・データベースと使用した場合の動作が保証されます。
ユーザー・データ・リポジトリの役割は、Oracle Identity Federationをアイデンティティ・プロバイダ(IdP)またはサービス・プロバイダ(SP)のどちらとして構成するかによって異なります。
IdPとして構成する場合
Oracle Identity Federationは、ユーザー・アイデンティティの検証およびプロトコル・アサーションの構築にリポジトリを使用します。
SPとして構成する場合
Oracle Identity Federationは、リポジトリを使用して、受信したアサーションの情報を宛先のユーザー・アイデンティティにマッピングしてから、ユーザーに対して保護されたリソースへのアクセスを認可します。
新たにフェデレーションを作成する場合、Oracle Identity Federationは、リポジトリを使用してユーザーを特定し、新しいフェデレーションをそのユーザーのアカウントにリンクします。
Oracle Identity Federationアプリケーションでは、起動時にユーザー・データ・ストアが使用可能である必要はありません。ユーザー・データ・ストアは実行時に必要になります。
|
注意: Oracle Identity Federationでは、Oracle Databaseバージョン10.2.0.4以上、Oracle Database 11.1.0.7以上またはOracle Database 11.2.0.2以上を使用した場合のみ、動作が保証されます。 |
フェデレーション・データ・ストア
フェデレーション・データ・ストアには、XML、RDBMS、またはLDAPを使用できます。高可用性モードでは、RDBMSまたはLDAPのみを使用して、クラスタ内のすべてのノードでフェデレーション・データ・ストアを使用できるようにします。
Oracle Identity Federationサーバーは、フェデレーション・データ・ストアを使用して、ユーザーのフェデレーション・レコードを永続化します。アイデンティティ・フェデレーションとは、あるトラスト・サークル内の1つ以上のアイデンティティ・プロバイダまたはサービス・プロバイダで、プリンシパルによって保持される可能性のある2つ以上のアカウントのリンクです。ユーザーが複数のビジネスに対して持っている、相互に孤立している個別のアカウント(ローカル・アイデンティティ)をフェデレートすると、2つのエンティティ間にリレーションシップ(任意の数のサービス・プロバイダとアイデンティティ・プロバイダで構成される関連付け)が作成されます。
Oracle Identity Federationサーバーでは、Oracle Internet Directory、Sun Java System Directory Server、およびMicrosoft Active Directoryなどの業界標準のLDAPリポジトリ、またはリレーショナル・データベースが保証されています。
表8-13は、デプロイメント・オプションとそのオプションに必要なフェデレーション・データ・ストアのタイプとの関係を示しています。
表8-13 Oracle Identity Federationのデプロイメント・オプションに対応するフェデレーション・データ・ストアのタイプ
| デプロイメント・オプション | ストア・タイプ |
|---|---|
|
非高可用性/スタンドアロン |
なし、またはXML |
|
高可用性 |
なし、LDAP、またはリレーショナル・データベース・ストア |
フェデレーション・データ・ストアは、プロトコルの交換の際に永続的な名前識別子フォーマットを使用する場合にかぎり、実行時に必要となります。電子メール・アドレスなど不透明でない名前識別子を使用する場合は、実行時のフェデレーション・データ・ストアはオプションになります。
|
注意: Oracle Identity Federationでは、Oracle Databaseバージョン10.2.0.4以上またはOracle Database 11.1.0.7以上を使用した場合のみ、動作が保証されます。 |
Oracle Identity Federationのフェデレーション・データ・ストアの詳細は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドのフェデレーション・データ・ストアに関する項を参照してください。
認証エンジン
Oracle Identity FederationのIdPおよびSPプロトコルの操作(シングル・サインオン、フェデレーションの作成、フェデレーションの終了、および名前ID登録など)では、ユーザーの認証が必要です。Oracle Identity Federationの認証モジュールは、ユーザー認証に対応しています。認証モジュールは、ユーザー認証で次の2つの異なる役割を果たします。
Oracle Identity Federationがアイデンティティ・プロバイダとしてデプロイされる場合は、認証モジュールは、ローカル認証メカニズムとして動作します。認証モジュールでは、認証を委任することも、各種のリポジトリやアイデンティティ管理ソリューションと直接対話することも可能です。
Oracle Identity Federationがサービス・プロバイダとしてデプロイされる場合は、フェデレーション・プロトコルを使用して、ピア・アイデンティティ・プロバイダでユーザーを認証します。Oracle Identity Federationは、ユーザーを認証モジュールに転送します。このモジュールは、SPにデプロイされたアイデンティティ管理ソリューションに認証済のユーザー・セッションを伝播し作成します。これにより、リクエストされた保護リソースへのアクセスが順に可能になります。
サポート対象のRDBMSおよびLDAPリポジトリには、Oracle Database、Oracle Internet Directory、Sun Java System Directory Server、およびMicrosoft Active Directoryなどがあります。
サポート対象のリポジトリおよびアイデンティティ管理ソリューションには、Oracle Access Manager、Oracle Single Sign Onなどがあります。
認証モジュールの実行時には、外部の認証エンジンが使用できるだけでかまいません。
サービス・プロバイダ・エンジン
サービス・プロバイダ統合エンジン(SP統合エンジン)は、アイデンティティとアクセス管理(IAM)サーバーの認証済ユーザー・セッションの作成に使用します。SPエンジンを付属したOracle Identity Federationには、各種IAMサーバーとの相互運用を可能にする、次のような内部プラグインが含まれています。
Oracle Single Sign-On
Oracle Access Manager
Oracle Identity Federationテスト・アプリケーション
Oracle Identity Federationでは、サード・パーティのIAMフレームワークと統合するためのフレームワークが提供されています。カスタマイズされたSP統合モジュールが内部のJ2EEサーブレット転送を使用してOracle Identity Federationと対話し、サード・パーティのIAMシステムと通信して認証済ユーザー・セッションを作成します。
いずれのカスタムSPエンジン・モジュールも、クラスタ内の各管理対象サーバーにデプロイされる必要があります。
Oracle Identity Federationは、Oracle WebLogic Server上にデプロイされるJ2EEアプリケーションです。サーバーに関連するログ・メッセージはすべて、サーバーのログ・ファイルに記録され、Oracle Identity Federationに固有のメッセージはすべて、アプリケーションがデプロイされたOracle WebLogic Serverの診断ログ・ファイルに記録されます。
Oracle WebLogic Serverのログ・ファイルのデフォルトの場所は次のとおりです。
WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
Oracle Identity Federationのログ・ファイルの名前は、serverName-diagnostic.logです。たとえば、Oracle WebLogic Server名がwls_oif1の場合、ログ・ファイル名はwls_oif1-diagnostic.logになります。
ログ・ファイルを表示するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。
この項では、Oracle Identity Federationの概要およびOracle Identity Federationの高可用性環境の設計とデプロイについて説明します。
Oracle Identity Federationを高可用性構成でデプロイする場合のガイドラインを次に示します。
一時データおよび構成データは、常に共有リレーショナル・データベースに格納する必要があります。これは、次の場合に必要です。
Oracle Identity FederationがIdPとして機能し、アーティファクトSSOプロファイルが使用される場合。この場合、ユーザーは、アサーションが作成されるIdP #1と対話します。その後アーティファクトが間接参照されるときに、SPがIdP #2に接続します。2つのOracle Identity Federationサーバーが同じメッセージ・ストアを共有していない場合、IdP #2は、IdP #1が作成したアーティファクトのアサーションをロケーティングできません。
Oracle Identity FederationがSPとして機能し、POST SSOプロファイルが使用される場合。POSTプロファイルでは、ユーザーのブラウザによってアサーションが行われるため、そのアサーションのOracle Identity Federation SPへの再送信が可能になります。潜在的なリプレイ攻撃に対処するため、Oracle Identity Federation SPサーバーは、受信したアサーションを追跡して、同じアサーションが再度使用されないようにします。
Oracle Identity Federationが認証問合せ局として機能する場合。Oracle Identity Federationサーバーは、Oracle Identity Federationサーバーの特定ユーザーの既存セッションを示すアサーションを返すことによって、リモート・プロバイダからの問合せに応じます。このため、Oracle Identity Federationサーバーは一時セッション・ストアを共有する必要があります。
Oracle Identity FederationがIdP/属性認証局として機能し、アサーションIDレスポンダ機能が有効化されている場合。この機能を使用すると、リモート・プロバイダはIdPに対して問合せを行い、以前のSAMLフローで作成されたアサーションを取得します。このため、レスポンダは、作成されるすべてのアサーションを格納するストアに、アクセスできる必要があります。
高可用性環境では、Oracle HTTP ServerインスタンスがOracle Identity Federationアプリケーションのフロントエンドに使用されていない場合、次のようにすることをお薦めします。
Oracle Identity Federationアプリケーションのフロントエンドに使用されているハードウェア・ロード・バランサでスティッキー・セッションを有効化します。
スティッキー・セッションにより、ユーザー・リクエストはそのセッションの間は同じOracle Identity Federationサーバーに送信されるようになります。
|
注意: HTTPセッションの状態は、Oracle Identity FederationがHTTPリクエストを処理する際、実行時に使用されます。HTTPセッション状態に格納される情報は短期間しか保持されません。情報の有効期間は、シングル・サインオンなどのフェデレーション操作の長さに相当します。 HTTPセッション・レプリケーションでは、ノード間でセッション情報がレプリケートされるため、メモリーが大量に消費されるので、お薦めしません。 デフォルトでは、HTTPセッションは有効化されていません。 Oracle Identity Managementソフトウェアを高可用性構成でデプロイする場合に、ロード・バランサでの有効化が必要な機能についての説明は、第8.2.5.4.1項「ロード・バランサ」を参照してください。 |
Oracle Identity Federationサーバーでは、次の2つのタイプのHTTPセッション・レプリケーションがサポートされます。
インメモリー・セッション・レプリケーション
JDBCセッション・レプリケーション
インメモリー・セッション・レプリケーションには、次のような特性があります。
セッション作成時に、クラスタ内でOracle Identity Federationアプリケーションを実行するすべての管理対象サーバーが起動されている必要があります。
パフォーマンスが低下する可能性があります。
セッション・レプリケーションが完了する前に、サーバーがリクエストを受信すると、サーバーからエラーがスローされます。
これを回避するために、DOMAIN_HOME/config/fmwconfig/servers/serverName/applications/OIF_11.1.1.2.0/configurationディレクトリのconfig.xmlファイル内の、次に示すパラメータを更新します。これは、Oracle Identity Federationアプリケーションを実行しているすべてのノードで行う必要があります。
sessionreplicationenabled: これをtrueに設定します。
sessionreplicationtimeout: これは、デフォルトで2000に設定されています。必要に応じてこの値を大きくします。
JDBCセッション・レプリケーションには、次のような特性があります。
堅牢性を備えています。
データベース呼出しに余分なオーバーヘッドがかかるため、インメモリー・セッション・レプリケーションに比べてパフォーマンスが低下します。
セッションの永続性の状態が、共有リレーショナル・データベースに格納されます。
JDBCセッションの永続性のためにOracle WebLogic Serverを構成するには、『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の永続記憶域(JDBC永続性)のためのデータベースの使用に関する項を参照してください。
図8-21は、Oracle Identity Federationのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。
図8-21では、アプリケーション層にコンピュータIDMHOST1とIDMHOST2があります。
IDMHOST1では、次のインストールが実行されています。
Oracle Identity FederationインスタンスがWLS_OIF1管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。
IDMHOST2では、次のインストールが実行されています。
Oracle Identity FederationインスタンスがWLS_OIF2管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
IDMHOST2上のWLS_OIF2管理対象サーバーにあるインスタンスと、IDMHOST1上のWLS_OIF1管理対象サーバーにあるインスタンスは、CLUSTER_OIFクラスタとして構成されています。
WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。IDMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
高可用性アーキテクチャでは、Oracle Identity Federationサーバーは、Oracle WebLogicクラスタにデプロイされます。このクラスタには、その一部として少なくとも2つのサーバーが存在します。
デフォルトでは、Oracle WebLogic Serverによって、このアプリケーションの起動、停止、監視および様々なライフサイクル・イベントの監視が行われます。Oracle Identity Federationアプリケーションは、基盤となるWebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
高可用性環境では、WebLogicノード・マネージャはOracle WebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。
高可用性環境では、ハードウェア・ロード・バランサを使用して、複数のOracle Identity Federationインスタンス間のリクエストをロード・バランシングします。Oracle Identity Federationインスタンスのいずれかに障害が発生した場合は、ロード・バランサによって障害が検出され、障害が発生していないインスタンスにリクエストがルーティングされます。
高可用性環境では、状態情報と構成情報は、クラスタ内のすべてのメンバーが共有するデータベースに格納されます。
状態情報が共有データベースに格納されており、クラスタ内のすべてのメンバーがこの情報を使用できるため、障害が発生していないOracle Identity Federationインスタンスでは、障害が発生したインスタンスで開始された未完了のトランザクションの処理をシームレスに継続します。
Oracle Identity Federationインスタンスのいずれかで障害が発生すると、そのデータベースとLDAP接続は解放されます。アクティブ/アクティブ・デプロイメント内にある障害が発生していないインスタンスは、独自の接続を行い、障害が発生したインスタンス上にある未完了のトランザクションの処理を継続します。
Oracle Identity Federationアプリケーションのライフサイクル・イベントは、次に示すコマンドライン・ツールまたはコンソールのいずれかを使用して管理できます。
Oracle WebLogic Server管理コンソール
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Scripting Tool (WLST)
1つのクラスタ・メンバーによって加えられた構成変更は、その構成が共有データベースに格納されているため、すべてのメンバーに自動的に伝播されます。
|
注意: デフォルトでは、HTTPセッション・レプリケーションは無効化されており、お薦めしません。これはノード間でセッション情報をレプリケートするため、メモリーが大量に消費されます。ただし、環境で、HTTPセッション・レプリケーションを有効化する必要がある場合は、次の手順に従ってください。 |
セッション・レプリケーションのオンとオフを切り替えるには、Oracle Identity Federationがデプロイされているすべての管理対象サーバーで、次のようにweblogic.xmlファイルを更新する必要があります。
ORACLE_HOME/fed/install/oif.earファイルを一時的な場所にコピーします。
oif.earファイルに含まれているweb.warファイルからMETA-INF/weblogic.xmlファイルを抽出します。
パラメータset persistent-store-typeをreplicated_if_clusteredに更新します。
weblogic.xmlファイルを保存します。
Oracle Identity Federationアプリケーションを適切なツールを使用して再度パッケージ化します。
更新したoif.earファイルを、Oracle Identity Federationを実行しているすべてのノードのORACLE_HOME/fed/installディレクトリにコピーします。
更新したOracle Identity Federationアプリケーションを、環境内の、そのアプリケーションを実行しているすべてのノードで再起動します。
管理対象サーバーを再起動します。
HTTPセッション・レプリケーションを無効化するには、前の手順に従い、ステップ3でパラメータset persistent-store-type to memoryを更新します。
|
注意: これらの手動の手順は、すべてのパッチ・セットで環境を更新してから実行する必要があります。そのようにしない場合は、セッション・レプリケーションの変更は失われます。 |
この項では、Oracle Identity FederationとOracle Access Managerを高可用性トポロジで統合する際に必要な手順を説明します。
高可用性モードでOracle Identity Federationをデプロイすることに加えて、Oracle Access Managerも高可用性モードでデプロイする必要があります。
クラスタ内のすべてのOracle Identity Federationサーバーに、Oracle Access Server SDKをインストールする必要があります。Oracle Identity Federationは、SDKをインストールしたディレクトリを参照するように構成する必要があります。SDKがドメインのホーム・ディレクトリにインストールされている場合は、ドメイン・ホーム・フォルダからの相対パスを使用してSDKを参照できます。SDKが別の場所にインストールされている場合は、Oracle Identity Federationは、絶対パスを使用してSDKフォルダを参照する必要があります。
高可用性環境でOracle Identity Federationを使用する場合は、Oracle Identity Federationがインストールされているすべてのコンピュータで同じディレクトリ名を使用して、Access Server SDKをドメイン・ホーム・フォルダにインストールすることをお薦めします。すべてのOracle Identity Federationインスタンスは、同じ構成、具体的にはAccess Server SDKがインストールされているディレクトリを共有するため、これはOracle Identity FederationとOracle Access Managerで可用性の高い統合を行う場合の要件となります。相対パスを使用することにより、Oracle Identity Federationインスタンスで同一の構成を共有できます。
Oracle Fusion Middleware Oracle Identity Federation管理者ガイドのSP統合モジュールとしてのOracle Access Managerの統合に関する項のSP統合モジュールとしてのOracle Access Managerの統合に関する説明に従って、各Oracle Identity Federationサーバー上のSDKインスタンスとOracle Access Managerを統合します。
必要に応じて、ドメイン・ライブラリに必要なファイルをコピーし、各Oracle Identity FederationサーバーのWebLogic Server起動スクリプトを更新して、SDK jarファイルをクラスパスに追加し、LD_LIBRARY_PATH環境変数およびLD_ASSUME_KERNEL環境変数を設定します。詳細は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドのOracle WebLogic Server環境の更新に関する項を参照してください。
Oracle Identity Federationには、次のコンポーネントが必要です。
Oracle JRockit SDK(インストールにバンドル)
Oracle WebLogic Server(インストールにバンドル)
ユーザー・データ・ストア。通常はLDAPディレクトリですが、オプションでデータベース・ストアにすることもできます。
フェデレーション・データ・ストア。これは、Oracle Internet Directory、Microsoft Active Directory、Sun Java System Directory Serverなどの、標準のLDAPディレクトリです。
|
注意: Oracle Identity Federationではユーザー・フェデレーション・データ・ストアがすべての場合に必ず必要になるとはかぎりません。Liberty 1.xおよびSAML 2.0の不透明な永続識別子には必要ですが、SAML 1.x、WS-Federation、およびSAML 2.0の不透明でない識別子(電子メール・アドレス、サブジェクトDNなど)では任意です。 |
Oracle Databaseバージョン10.2.0.4.0以上、またはRDBMS一時データ・ストアの場合は11.1.0.7以上。
プロキシ実装用のOracle HTTP Server。これはOracle Identity Federationでサポートされる唯一のプロキシ・サーバーで、インストールにバンドルされています。
|
注意: Oracle Identity Federationを高可用性デプロイメントで使用する場合は、クラスタ・ノードのシステム・クロックを同期する必要があります。 |
OIFHOST1およびOIFHOST2にOracle Internet Directoryインスタンスをインストールする前に、最新バージョンのリポジトリ作成ユーティリティ(RCU)を使用して、Oracle Identity Federationで使用するスキーマのコレクションを作成します。
最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
次の手順に従って、RCUを実行し、Oracle RACデータベース・リポジトリにOracle Identity Federationスキーマを作成します。
次のコマンドを発行します。
prompt> RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」操作を選択してコンポーネント・スキーマを既存のデータベースにロードします。
「次へ」をクリックします。
「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。
データベース・タイプ: Oracle Database
ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: INFRADBHOST1-VIPまたはINFRADBHOST2-VIP
ポート: データベースのポート番号。例: 1521
サービス名: データベースのサービス名。例: oif.example.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワード
ロール: SYSDBA
「次へ」をクリックします。
「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: idm
コンポーネント: Identity Management (Oracle Identity Federation - OIF)を選択します。その他のスキーマは選択を解除します。
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。
「表領域のマップ」画面で、コンポーネントの表領域を選択します。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
高可用性環境では、Oracle WebLogic Serverのユーティリティを使用してOracle Identity Federationインスタンスのクラスタ化、ロード・バランシングおよびフェイルオーバーを行うことをお薦めします。
スキーマ・データベースが稼働中であることを確認してから、次の手順に従ってインストールします。
この項では、OIFHOST1およびOIFHOST2にOracle Identity Federationインスタンスをインストールして、構成する手順について説明します。
次の手順に従って、OIFHOST1上のOracle Identity Federationの1つ目のインスタンスを構成します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIFHOST1にインストールされ、アップグレードされていることを確認します。
ポート7499がこのコンピュータ上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":7499"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr "7499"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
ポート7499のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Identity Federationのポート番号を指定する行は非コメント化)を割り当てます。
# The port for OIF Server port OIF Server Port No = 7499
次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、新規ドメインの作成を選択して、次の値を指定します。
ホスト名: OIFHOST1.example.com
ポート: 7001
ユーザー名: weblogic
パスワード: <weblogicユーザーのパスワード>
「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所: この値は入力済になっており、更新できません。
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ: この値は入力済になっており、更新できません。
oif
WebLogic Serverのディレクトリ:
/u01/app/oracle/product/fmw/wlserver_10.3
Oracleインスタンスの場所:
/u01/app/oracle/admin/oif_inst1
インスタンス名: oif_inst1
|
注意: OIFHOST1のOracleホームの場所を示すディレクトリ・パスが、OIFHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OIFHOST1のOracleホームの場所のディレクトリ・パスが |
「次へ」をクリックします。
「Oracle Configuration Managerの詳細の指定」画面で、次の例で示すように値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle Identity Federation」コンポーネントを除く全製品の選択を解除します。Oracle Identity Federationコンポーネントには、Oracle Identity FederationとOracle HTTP Serverが含まれています。「クラスタ化」チェック・ボックスを選択します。
「次へ」をクリックします。
|
注意: インストーラによって設定されるデフォルトのOracle WebLogic Serverのクラスタ・モードは、(マルチキャストではなく)ユニキャストになります。 |
「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を指定します。一時ディレクトリにコピーしたstaticports.iniファイルへのパスを入力します。
「次へ」をクリックします。
「OIF詳細の指定」画面で、次の値を指定します。
PKCS12パスワード: <パスワード>
パスワードの確認: <入力したパスワードの再入力>
サーバーID: oif_OIFDomain
「次へ」をクリックします。
「OIF拡張フロー属性の選択」画面で、次の値を指定します。
認証タイプ: LDAP
ユーザー・ストア: LDAP
フェデレーション・ストア: LDAP
ユーザー・セッション・ストア: RDBMS(デフォルトの選択、クラスタに対する変更は不可)
メッセージ・ストア: RDBMS(デフォルトの選択、クラスタに対する変更は不可)
構成ストア: RDBMS(デフォルトの選択、クラスタに対する変更は不可)
|
注意: 拡張インストールの際にセッション、メッセージ、および構成のデータ・ストアに これらの各ストアに個別のデータベースを設定する場合は、インストール後に構成する必要があります。 |
「認証LDAPの詳細の指定」画面で、次の例で示すように値を指定します。
LDAPタイプ: ドロップ・ダウンから「Oracle Internet Directory」を選択します。
LDAP URL: LDAPストアに接続するLDAP URLを次の形式で指定します(ldap://host:portまたはldaps://host:port)。例:
ldaps://oid.example.com:636
LDAPバインドDN: cn=orcladmin
LDAPパスワード: <orcladminのパスワード>
ユーザー資格証明ID属性: uid
ユーザーの一意ID属性: orclguid
個人オブジェクト・クラス: inetOrgPerson
「次へ」をクリックします。
「ユーザー・データ・ストアのLDAP属性の指定」画面で、次の例で示すように値を指定します。
LDAPタイプ: ドロップ・ダウンから「Oracle Internet Directory」を選択します。
LDAP URL: LDAPストアに接続するLDAP URLを次の形式で指定します(ldap://host:portまたはldaps://host:port)。例:
ldaps://oid.example.com:636
LDAPバインドDN: cn=orcladmin
LDAPパスワード: <orcladminのパスワード>
ユーザー説明属性: uid
ユーザーID属性: orclguid
個人オブジェクト・クラス: inetOrgPerson
ベースDN: dc=us,dc=mycompany,dc=com
「次へ」をクリックします。
「フェデレーション・データ・ストアのLDAP属性の指定」画面で、次の例で示すように値を指定します。
LDAPタイプ: ドロップ・ダウンから「Oracle Internet Directory」を選択します。
LDAP URL: LDAPストアに接続するLDAP URLを次の形式で指定します(ldap://host:portまたはldaps://host:port)。例:
ldaps://oid.example.com:636
LDAPバインドDN: cn=orcladmin
LDAPパスワード: <orcladminのパスワード>
ユーザー・フェデレーション・レコード・コンテキスト: cn=myfed,dc=us,dc=mycompany,dc=com
コンテナ・オブジェクト・クラス: Oracle Identity FederationがLDAPコンテナを作成するときに、このコンテナがまだ存在しない場合に使用するユーザー・フェデレーション・レコード・コンテキストのタイプです。このフィールドが空白の場合は、applicationprocessに値が設定されます。Microsoft Active Directoryの場合は、このフィールドをcontainerに設定する必要があります。
「次へ」をクリックします。
「一時ストア・データベースの詳細の指定」画面で、次の例で示すように値を指定します。
接続文字列: データベースへの接続文字列を入力します。例:
infradbhost1-vip.example.com:1521:oifdb1^infradbhost2-vip.example.com: 1521:oifdb2@oif.example.com
|
注意: Oracle RACデータベースの接続文字列の情報は、host1:port1:instance1^host2:port2:instance2@servicenameの書式で指定する必要があります。 このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。 前述のように指定した情報は、完全で正確である必要があります。具体的には、ホスト、ポート、およびインスタンス名が各Oracle RACインスタンスに正しく指定されている必要があります。また、指定したOracle RACインスタンスのすべてにサービス名が構成されている必要があります。 Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。 |
ユーザー名: OIFスキーマのユーザー名を入力します(例: ha_oif)。
パスワード: oifユーザーのパスワード
「次へ」をクリックします。
「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は「戻る」をクリックして前の画面に戻り、修正します。「インストール」をクリックします。
「インストールの進行状況」画面で、インストールの進行状況を確認します。
インストールが終了すると、oracleRoot.shの確認ダイアログ・ボックスが表示されます。このダイアログ・ボックスは、インストールを続行する前に構成スクリプトをrootユーザーとして実行する必要があることを示しています。このダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootユーザーとしてログインして、次のスクリプト・ファイルを実行します。
/u01/app/oracle/product/fmw/oif/oracleRoot.sh
「構成の進行状況」画面で、構成の進行状況を確認します。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。
boot.propertiesファイルを作成する手順は次のとおりです。
OIFHOST1で、次のディレクトリに移動します。
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
例:
cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security
テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUserpassword=adminUserPassword
|
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。 |
管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
MW_HOME/user_projects/domains/domainName/binディレクトリにある、startWebLogic.shスクリプトを使用して、OIFHOST1上の管理サーバーを起動します。
Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
WebLogic Server管理コンソール:
http://oidhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oidhost1.example.com:7001/em
weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。
次の手順に従って、OIFHOST2上のOracle Identity Federationの2つ目のインスタンスを構成します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。
第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIFHOST2にインストールされ、アップグレードされていることを確認します。
OIFHOST1では、 Oracle Identity Federationによってポート7499が使用されています。OIFHOST2上のOracle Identity Federationインスタンスにも同じポートを使用する必要があります。ポート7499がOIFHOST2上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep LISTEN | grep ":7499"
Windowsの場合:
netstat -an | findstr "LISTEN" | findstr "7499"
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
ポート7499のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Identity Federationのポート番号を指定する行は非コメント化)を割り当てます。
# The port for OIF Server port OIF Server Port No = 7499
次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。
Windowsでは、config.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「ドメインの選択」画面で、「クラスタを開く」オプションを選択して、次の値を指定します。
ホスト名: OIFHOST1.example.com
ポート: 7001
ユーザー名: weblogic
パスワード: <weblogicユーザーのパスワード>
「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を指定します。
Oracle Middlewareホームの場所: この値は入力済になっており、更新できません。
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ: この値は入力済になっており、更新できません。
oif
WebLogic Serverのディレクトリ:
/u01/app/oracle/product/fmw/wlserver_10.3
Oracleインスタンスの場所:
/u01/app/oracle/admin/oif_inst2
インスタンス名: oif_inst2
|
注意: OIFHOST1のOracleホームの場所を示すディレクトリ・パスが、OIFHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OIFHOST1のOracleホームの場所のディレクトリ・パスが |
「次へ」をクリックします。
「Oracle Configuration Managerの詳細の指定」画面で、次の例で示すように値を指定します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
「セキュリティ・アップデートをMy Oracle Support経由で受け取る」フィールドの横のチェック・ボックスを選択します。
「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle Identity Federation」コンポーネントを除く全製品の選択を解除します。Oracle Identity Federationコンポーネントには、Oracle Identity FederationとOracle HTTP Serverが含まれています。
「次へ」をクリックします。
「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は「戻る」をクリックして前の画面に戻り、修正します。「インストール」をクリックします。
「インストールの進行状況」画面で、インストールの進行状況を確認します。
インストールが終了すると、oracleRoot.shの確認ダイアログ・ボックスが表示されます。このダイアログ・ボックスは、インストールを続行する前に構成スクリプトをrootユーザーとして実行する必要があることを示しています。このダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootユーザーとしてログインして、次のスクリプト・ファイルを実行します。
/u01/app/oracle/product/fmw/oif/oracleRoot.sh
「構成の進行状況」画面で、構成の進行状況を確認します。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
この項のインストール後の手順に従って、Oracle Identity Federationアプリケーションのインストールと構成を完了します。
OIFHOST1からOIFHOST2にOracle Identity Federation構成ディレクトリをコピーする手順は、次のとおりです。
OIFHOST1にあるディレクトリMW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif1/applicationsを、OIFHOST2のMW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif2/applicationsの場所にコピーします。
たとえば、OIFHOST1から次のコマンドを実行します。
scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif1/applicationsuser@OIFHOST2:/MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif2/applications
次の手順に従って、クラスタ内でOIFHOST2上に新たに作成したwls_oif2管理対象サーバーを起動します。
WebLogic Server管理コンソールの左側のペインで、「環境」を開いて、「クラスタ」を選択します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
停止する管理対象サーバー(wls_oif2)が存在するクラスタ(cluster_oif)のリンクをクリックします。
「制御」を選択します。
「このクラスタの管理対象サーバーのインスタンス」で、起動する管理対象サーバー(wls_oif2)の横のチェック・ボックスを選択して「起動」をクリックします。
「クラスタ・ライフサイクル・アシスタント」ページで、「はい」をクリックして確定します。
ノード・マネージャによって、ターゲット・マシン上のサーバーが起動されます。ノード・マネージャによる起動シーケンスが終了すると、「サーバー状態」表の「状態」列にサーバーの状態が表示されます。
Oracle HTTP Serverは、OIFHOST1およびOIFHOST2上にOracle Identity Federationサーバーとともにインストールされます。次の手順に従って、Oracle HTTP Serverを構成します。
OIFHOST1で、INSTANCE_HOME/config/OHS/ohsName/moduleconfディレクトリにあるoif.confファイルを編集します。
アイデンティティ管理インストールがスタンドアロン・モードの場合は、Oracle Identity Federationが実行されているWebLogic Serverの管理対象サーバーが反映されるようにWebLogicHostおよびWebLogicPort変数を非コメント化して設定します(例: oifhost1.example.comと7499)。
アイデンティティ管理インストールがクラスタ化ノード内にある場合は、Oracle Identity Federationが実行されているWebLogic Server管理対象サーバーが反映されるようにWebLogicCluster変数を非コメント化して設定します(例: oifhost1.example.com:7499、oifhost2.example.com:7499)。
oif.confファイルを保存して終了します。
Oracle HTTP Serverを再起動します。
高可用性構成では、外部ロード・バランサをフロントエンドに使用して、様々なOracle Identity Federationインスタンス間のリクエストをロード・バランシングすることをお薦めします。
高可用性環境では、Oracle HTTP ServerインスタンスがOracle Identity Federationアプリケーションのフロントエンドに使用されていない場合、ハードウェア・ロード・バランサでスティッキー・セッションを有効化することをお薦めします。
詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。
ロード・バランサVIPを使用するようにOracle Identity Federationアプリケーションを構成する手順は、次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlで、「管理」→「サーバー・プロパティ」に移動します。
ホスト名とポートを変更し、ロード・バランサのホストとポートを反映するようにします。
Oracle Enterprise Manager Fusion Middleware Controlで、「管理」→「アイデンティティ・プロバイダ」に移動します。
URLをhttp://LoadBalancerHost:LoadBalancerPortに変更します。
Oracle Enterprise Manager Fusion Middleware Controlで、「管理」→「サービス・プロバイダ」に移動します。
URLをhttp://LoadBalancerHost:LoadBalancerPortに変更します。
Oracle Identity Federationがデプロイされている各管理対象サーバーで、この手順を実行します。
高可用性構成のOracle Identity Federationを検証する手順は次のとおりです。
正しく構成されていれば、Webブラウザで次のURLにアクセスできます。
http://<LoadBalancerHost>:<LoadBalancerPort>/fed/sp/metadata http://<LoadBalancerHost>:<LoadBalancerPort>/fed/idp/metadata
Oracle Fusion Middleware Oracle Identity Federation管理者ガイドのサーバー・メタデータの取得に関する項と信頼できるプロバイダの追加に関する項の手順に従って、SPからメタデータをIdPに、IDPメタデータをSPにインポートします。
次のURLに移動して、シングル・サインオンの操作を実行します。
http://<SP_Host>:<SP_port>/fed/user/testspsso
Oracle Identity Federationは、デフォルトでは、高可用性構成にデプロイされたLDAPサーバーと統合するように構成されていません。Oracle Identity Federationを可用性の高いLDAPサーバーと統合して、ユーザー・データ・ストア、フェデレーション・データ・ストア、または認証エンジンとして機能させるには、LDAPサーバーの機能に基づいてOracle Identity Federationを構成する必要があります。$ORACLE_HOME/common/binディレクトリの下にあるWLSTスクリプトを使用します。
Oracle Identity FederationにWLSTスクリプト環境を入力してから、必要に応じて次のプロパティを設定します。
ユーザー・データ・ストアを可用性の高いLDAPサーバーと統合するには、datastoreグループのuserldaphaenabledブール型プロパティをtrueに設定します。統合しない場合はfalseに設定します。
setConfigProperty('datastore','userldaphaenabled', 'true', 'boolean')
フェデレーション・データ・ストアを可用性の高いLDAPサーバーと統合するには、datastoreグループのfedldaphaenabledブール型プロパティをtrueに設定します。統合しない場合はfalseに設定します。
setConfigProperty('datastore', 'fedldaphaenabled','true', 'boolean')
LDAP認証エンジンを可用性の高いLDAPサーバーと統合するには、authnenginesグループのldaphaenabledブール型プロパティをtrueに設定します。統合しない場合はfalseに設定します。
setConfigProperty('authnengines','ldaphaenabled', 'true', 'boolean')
この項では、高可用性環境にデプロイされたOracle Identity Federationインスタンスの様々なフェイルオーバー操作の実行手順と、予想される動作について説明します。この項の手順に従って、次の操作を実行します。
Oracle Identity Federationインスタンスのフェイルオーバー
Oracle Real Application Clustersのフェイルオーバー
次の手順に従って、Oracle Identity Federationインスタンスのフェイルオーバーのテストを実行し、Oracle Identity Federationのステータスを確認します。
|
注意: 次の手順で指定されているtestspsso URLは、Oracle Identity Federation 11gにバンドルされているTest SP SSOサービスです。 テスト・サービスはデフォルトで有効化されていますが、管理者により無効にできます。本番環境では、Test SP SSOサービスを無効にできます。 Test SP SSOサービスが無効化されている場合は、SPからフェデレーションSSOフローを起動するように統合したサービスであればどのサービスでも使用できます。 |
フェデレーション・シングル・サインオン操作を実行できるように、Oracle Identity Federationを設定します。
サービス・プロバイダとして動作するOracle Identity Federationから、シングル・サインオン操作を開始します。これを実行する1つの方法として、http://<SPhost>:<SPport>/fed/user/testspsso URLを使用して、「アーティファクト」プロファイルを選択します。
IdPのログイン・ページで、「管理対象サーバー」ページからwls_oif1を停止し、ユーザー名とパスワードを入力します。
シングル・サインオン操作が正常に行われます。
Oracle RACフェイルオーバーを実行する手順は次のとおりです。
OIFスキーマがインストールされているデータベース・ホストの1つ(infradbhost1-vip)で、srvctlコマンドを使用してデータベース・インスタンスを停止します。
srvctl stop instance -d db_unique_name -i inst_name_list
srvctlコマンドを使用して、データベース・インスタンスのステータスを確認します。
srvctl status database -d db_unique_name -v
Oracle Identity Federationの操作を実行します。
ORACLE_INSTANCE/bin/opmnctl status ias-component=oif1
srvctlコマンドを使用して、データベース・インスタンスを起動します。
srvctl start instance -d db_unique_name -i inst_name_list
次の情報は、Oracle Identity Federationに関する問題のトラブルシューティングに役立ちます。
Oracle Identity Federationのメッセージは、Oracle WebLogic Server管理対象サーバーのログ・ファイルに記録されます。たとえば、次のファイルがあります。
DOMAIN_HOME/servers/wls_oif1/logs/wls_oif1-diagnostic.log
Oracle Enterprise Manager Fusion Controlを使用して、「Identity and Access」→OIF→「ログ」→「ログ・メッセージの表示」を選択することで、ログ・ファイルを表示することをお薦めします。
Oracle Identity Federationで使用するデータベースに古い構成データがないことを確認します。古いデータが存在する場合、新しいデータで上書きされることがあります。Oracle Identity Federationがデータベースをポイントする前に、Oracle Identity Federation構成データベース表の古いデータを削除するか、スキーマを作成しなおします。
Oracle Identity Federationサーバー構成のホスト名とポートには、ロード・バランサのホストとポートを設定してください(このように設定しない場合、シングル・サインオン操作でエラーが発生します)。
IdPとSPが実行されている各コンピュータのクロックの時間が異なると、シングル・サインオンの際にエラーが発生します。これを修正するには、同じ時間になるようにシステム・クロックの時間を設定するか、Oracle Enterprise Manager Fusion Middleware Controlの「サーバー・プロパティ」ページを使用してサーバー・ドリフトを調整します。
ProviderIdは、IdP/SPを一意に識別する文字列です。クラスタ内のすべてのサーバーのProviderIdを同じにする必要があります。インストール時のProviderIdのデフォルトは、host:port/fed/<sp|idp>です。必要に応じて、インストール後にこの値を変更または設定します。運用時には変更しないでください。
Oracle Identity Federationのトラブルシューティングの詳細は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドを参照してください。
コンポーネントを起動および停止するには、『Oracle Fusion Middleware管理者ガイド』のコンポーネントの起動と停止に関する説明に記載されている手順を参照してください。
脚注の説明文
脚注 1: 使用されるエージェントはデプロイメント固有であり、デプロイメントによって(異なる機能を持つ)様々なタイプのエージェントを使用できます。