ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド
11gリリース1（11.1.1）
B61378-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

2 エンタープライズ・デプロイメントの前提条件

この章では、Oracle Identity Managementインフラストラクチャのエンタープライズ・デプロイメント・トポロジの前提条件について説明します。

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

2.1 ハードウェア・リソースの計画

表1-2は、Linuxオペレーティング・システムでのエンタープライズ・デプロイメントの最小ハードウェア要件を示しています。メモリーの数値は、Oracle Fusion Middlewareサーバーのインストールと実行に必要なメモリーを表していますが、ほとんどの本稼働サイトでは、4GB以上の物理メモリーを構成する必要があります。

詳細な要件や他のプラットフォームの要件については、そのプラットフォームのOracle Fusion Middlewareインストレーション・ガイドを参照してください。

表2-1 標準ハードウェア要件

サーバー プロセッサ ディスク メモリー TMPディレクトリ スワップ

INFRADBHOSTn

1.5GHz以上で動作するX Pentiumが4個以上

nXm

n=ディスク数。最小4個（1個のディスクとしてストライプ化）

m=ディスクのサイズ（最小30GB）

6-16GB

デフォルト

デフォルト

WEBHOSTn

1.5GHz以上で動作するX Pentiumが2個以上

10GB

4GB

デフォルト

デフォルト

IDMHOSTn、OAMHOSTn、OIMHOSTn、OAAMHOSTn

1.5GHz以上で動作するX Pentiumが2個以上

10GB

4GB

デフォルト

デフォルト

OIDHOSTn、OVDHOSTn

1.5GHz以上で動作するX Pentiumが2個以上

10GB

4GB

デフォルト

デフォルト

これらは標準ハードウェア要件です。各層に対して、負荷、スループット、レスポンス時間およびその他の要件を注意深く考慮し、必要な実際の容量を計画してください。必要なノード、CPU、およびメモリーの数は、デプロイメント・プロファイルに基づいて各層で異なる場合があります。本稼働要件は、アプリケーションおよびユーザー数に依存して異なる場合があります。

このマニュアルで説明しているエンタープライズ・デプロイメント構成では、各層に2つのサーバーを使用してフェイルオーバー機能が実現されています。ただし、これがどのようなアプリケーションやユーザー数に対しても十分な計算リソースであるとはかぎりません。システムのワークロードが増大してパフォーマンスが低下した場合は、必要に応じて2番目のサーバー（つまり、WEBHOST2、IDMHOST2、OIDHOST2、OVDHOST2、INFRADBHOST2）の構成手順を繰り返し、さらにサーバーをインストールおよび構成することで、サーバーを構成に追加することができます。

2.2 ネットワークの前提条件

この項では、エンタープライズ・デプロイメント・トポロジのネットワークの前提条件について説明します。

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

2.2.1 ロード・バランサ

このエンタープライズ・トポロジでは、外部のロード・バランサを使用します。この外部ロード・バランサは次の機能を備えている必要があります。

  • 仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします（実際のホスト名は使用しない）。ロード・バランサは、リクエストをプールのサーバーにロード・バランスできるようになります。

  • ポート変換構成

  • ポート（HTTPとHTTPS）の監視

  • 仮想サーバーとポート構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。仮想サーバー名とポートは次の要件を満たす必要があります。

    • ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、OracleASクラスタの場合、ロード・バランサは、仮想サーバーおよびHTTPとHTTPSトラフィックのポートを使用して構成される必要があります。

    • 仮想サーバー名は、IPアドレスに関連付けられていて、DNSの一部である必要がある。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。

  • ノードの障害を検出し、障害のあるノードへのトラフィックのルーティングを即時に停止する機能。

  • リソースの監視/ポートの監視/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を（通知またはその他の方法によって）検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。ご使用の外部ロード・バランサに障害の自動検出機能がある場合、これを使用する必要があります。

  • フォルト・トレラント・モード: ロード・バランサをフォルト・トレラント・モードに構成することを強くお薦めします。

  • その他: トラフィックの転送先のバックエンド・サービスが使用できないとき、ロード・バランサの仮想サーバーを呼び出し元のクライアントに即時に戻すように構成することを強くお薦めします。これは、クライアントのマシンのTCP/IP設定に基づくタイムアウトの後、自ら接続解除するクライアントに対して好ましい構成です。

  • スティッキーなルーティング機能: CookieまたはURLに基づくコンポーネントへのスティッキーな接続を維持する機能

  • SSLアクセラレーション（この機能は推奨しますが必須ではありません）

  • TCP接続の接続タイムアウトに大きい値を使用したディレクトリ層に対するロード・バランサの仮想サーバーの構成。この値は、Oracle Access Managerとディレクトリ層の間でトラフィックがない場合に、その予想される最大時間より大きい必要があります。

  • クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。

2.2.2 ロード・バランサの仮想サーバー名とポートの構成

ロード・バランサ上には、各種のネットワーク・トラフィックおよび監視用に、いくつかの仮想サーバーおよびそれらに関連付けられたポートを構成する必要があります。これらは、サービスを実行するために適切な実際のホストおよびポートに対して構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。こうすることにより、指定の仮想ホスト上の着信トラフィックがその他の層の使用できないサービスに転送されなくなります。

推奨のトポロジには2つのロード・バランサ・デバイスがあります。一方のロード・バランサは外部HTTPトラフィック用に設定され、他方のロード・バランサは内部LDAPトラフィック用に設定されます。様々な理由により、デプロイメントで単一のロード・バランサ・デバイスを持つことを選択する場合があります。このことはサポートされていますが、デプロイメントでこれを行うことによるセキュリティ上の影響を考慮する必要があります。適切であると判明した場合、関連するファイアウォール・ポートを開き、様々なDMZへのトラフィックを可能にします。どちらの場合も、指定のロード・バランサ・デバイスをフォルト・トレラント・モードにすることを強くお薦めします。このドキュメントの残りの部分では、第1.4項「エンタープライズ・デプロイメントの参照トポロジ」に示したデプロイメントのいずれかであることを想定します。

oid.mycompany.com

  • この仮想サーバーはLBR2で有効になっています。これは、ディレクトリ層のOracle Internet DirectoryサーバーへのすべてのLDAPトラフィックのアクセス・ポイントとして動作します。SSLと非SSLの両方へのトラフィックが構成されています。クライアントは、アドレスoid.mycompany.com:636（SSL用）およびoid.mycompany.com:389（非SSL用）を使用してこのサービスにアクセスします。


    注意:

    LDAPサーバーのSSL接続と、Oracle Internet Directoryがインストールされた各コンピュータ上のOracle Internet DirectoryのSSL接続には、同じポートを構成することをお薦めします。

    これは、ロード・バランシング・ルーターを介してOracle Internet Directoryを使用する必要があるほとんどのOracle 10g製品の要件です。

  • OIDHOST1およびOIDHOST2上でOracle Internet Directoryプロセスのハートビートを監視します。Oracle Internet DirectoryプロセスがOIDHOST1またはOIDHOST2で停止した場合、またはOIDHOST1またはOIDHOST2のいずれかのホストがダウンした場合、ロード・バランサは稼動しているコンピュータへのLDAPトラフィックのルーティングを継続する必要があります。

ovd.mycompany.com

  • この仮想サーバーはLBR2で有効になっています。これは、ディレクトリ層のOracle Virtual DirectoryサーバーへのすべてのLDAPトラフィックのアクセス・ポイントとして動作します。SSLと非SSLの両方へのトラフィックが構成されています。クライアントは、アドレスovd.mycompany.com:636（SSL用）およびovd.mycompany.com:389（非SSL用）を使用してこのサービスにアクセスします。

  • OVDHOST1およびOVDHOST2上でOracle Virtual Directoryプロセスのハートビートを監視します。Oracle Virtual DirectoryプロセスがOVDHOST1またはOVDHOST2で停止した場合、またはOVDHOST1またはOVDHOST2のいずれかのホストがダウンした場合、ロード・バランサは稼動しているコンピュータへのLDAPトラフィックのルーティングを継続する必要があります。

admin.mycompany.com

  • この仮想サーバーはLBR1で有効になっています。これは、管理サービスに転送されるすべての内部HTTPトラフィックのアクセス・ポイントとして動作します。クライアントからの着信トラフィックは非SSLで有効になっています。したがって、クライアントはアドレスadmin.mycompany.com:80を使用してこのサービスにアクセスし、次にこれらのサービスをWEBHOST1およびWEBHOST2上のポート7777に転送します。この仮想ホストでアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Control、およびOracle Directory Services Managerが含まれます。

  • ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/console URLおよび/em URLにアクセスすることを防止します。DMZ内部のトラフィックのみがadmin.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。

oiminternal.mycompany.com

  • この仮想サーバーはLBR1で有効になっています。クライアントからの着信トラフィックは非SSLで有効になっています。したがって、クライアントはアドレスoiminternal.mycompany.com:80を使用してこのサービスにアクセスし、次にこれらのサービスをWEBHOST1およびWEBHOST2上のポート7777に転送します。SOA管理対象サーバーは、この仮想ホストにアクセスし、OIM Webサービスをコールバックします。

  • ファイアウォールでルールを作成し、外部トラフィックがこの仮想ホストにアクセスすることを防止します。DMZ内部のトラフィックのみがoiminternal.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。

sso.mycompany.com

  • この仮想サーバーはLBR1で有効になっています。これは、シングル・サインオン・サービスに転送されるすべてのHTTPトラフィックのアクセス・ポイントとして動作します。クライアントからの着信トラフィックはSSLで有効になっています。したがって、クライアントはアドレスsso.mycompany.com:443を使用してこのサービスにアクセスし、次にこれらのサービスをWEBHOST1およびWEBHOST2上のポート7777に転送します。シングル・サインオンが有効になっている保護されたリソースはすべて、この仮想ホスト上でアクセスされます。

  • ロード・バランサでポート80とポート443の両方を使用してこの仮想サーバーを構成します。ポート80へのリクエストはすべてロード・バランサのポート443に転送される必要があります。

  • この仮想ホストは、リクエストのクライアントIPアドレスを保持するように構成する必要があります。一部のロード・バランサでは、ロード・バランサを有効にしてリクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入することにより、これを構成します。

また、仮想サーバー名がIPアドレスに関連付けられていることと、DNSの一部に含まれていることを確認します。Oracle Fusion Middlewareを実行するコンピュータでは、これらの仮想サーバー名を解決できる必要があります。

2.2.3 管理サーバーの仮想IPアドレス

idmhost-vip.mycompany.com

仮想IPアドレスは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。WebLogic管理サーバーは、このマニュアルで後ほど説明するように、この仮想IPアドレスをリスニングするように後で構成されます。この仮想IPアドレスは、管理サーバーとともに、IDMHOST1からIDMSHOST2に（またはIDMSHOST2からIDMHOST1に）フェイルオーバーします。

2.2.4 Oracle Fusion Middlewareコンポーネントの接続の管理

すべてのサービスを常時使用可能にするために、すべてのOracle Fusion Middlewareコンポーネントの接続のタイムアウト値を、ファイアウォールおよびロード・バランシング・ルーターのタイムアウト値より短く設定してください。ファイアウォールまたはロード・バランシング・ルーターがTCPクローズ通知メッセージを送信することなく接続を切断すると、Oracle Fusion Middlewareコンポーネントは接続が使用不可になっても継続してその接続を使用しようとします。

2.2.5 Oracle Access Manager通信プロトコルと用語

Oracle Access Managerコンポーネントは、Oracle Accessプロトコル（OAP）およびOracle Identityプロトコル（OIP）と呼ばれる独自のプロトコルを使用して、相互に通信します。

2.2.5.1 Oracle Access Managerプロトコル

Oracle Accessプロトコル（OAP）は、ユーザー認証および認可の間に、アクセス・システム・コンポーネント（ポリシー・マネージャ、アクセス・サーバー、Webゲートなど）間の通信を可能にします。このプロトコルは、以前NetPointアクセス・プロトコル（NAP）またはCOREidアクセス・プロトコルと呼ばれていました。

Oracle Identityプロトコル（OIP）は、アイデンティティ・システム・コンポーネント（アイデンティティ・サーバー、Webパスなど）とWebサーバーの間の通信を管理します。このプロトコルは、以前NetPointアイデンティティ・プロトコル（NIP）またはCOREidアイデンティティ・プロトコルと呼ばれていました。

2.2.5.2 ユーザー・リクエストの概要

次にユーザーがアクセスをリクエストしたときのリクエスト・フローを説明します。

  1. ユーザーは、HTTPまたはHTTPSを介して保護されたリソースへのアクセスをリクエストします。

  2. Webゲートはリクエストを捕捉します。

  3. Webゲートは、Oracle Accessプロトコルを介してリクエストをアクセス・サーバーに転送し、リソースが保護されているかどうか、ユーザーの認証方法、およびユーザーが認証されているかどうかを判定します（認証されていない場合は問題になります）。

  4. アクセス・サーバーは、ディレクトリ・サーバーで資格証明（ユーザーIDとパスワードなど）を確認し、Oracle Accessプロトコルを介して情報をWebゲートに戻し、暗号化Cookieを生成してユーザーを認証します。

  5. 認証に従い、WebゲートがOracle Accessプロトコルを介してアクセス・サーバーに要求し、アクセス・サーバーは適切なセキュリティ・ポリシーを検索し、そのポリシーをユーザーのアイデンティティと比較してユーザーの認証水準を判別します。

    • アクセス・ポリシーが有効な場合、ユーザーは目的のコンテンツまたはアプリケーション（あるいはこれら両方）へのアクセスを許可されます。

    • ポリシーが偽の場合、ユーザーはアクセスを拒否され、組織の管理者が決めた別のURLにリダイレクトされます。

2.2.6 ファイアウォールとポート構成

多くのOracle Fusion Middlewareコンポーネントとサービスではポートを使用します。管理者はこれらのサービスに使用するポート番号を把握し、ホスト上の2つのサービスが同じポート番号を使用しないようにする必要があります。

ほとんどのポート番号はインストール時に割り当てられます。

表2-2は、Oracle Identity Managementトポロジで使用されるポート（トポロジのファイアウォールで開く必要があるポートを含む）の一覧です。

ファイアウォールの表記法

  • FW0は、最も外側のファイアウォールを表します。

  • FW1は、Web層とアプリケーション層の間のファイアウォールを表します。

  • FW2は、アプリケーション層とディレクトリ層の間のファイアウォールを表します。

表2-2 Oracle Identity Managementエンタープライズ・デプロイメント・トポロジで使用されるポート

タイプ ファイアウォール ポートとポートの範囲 プロトコル/アプリケーション インバウンド/アウトバウンド タイムアウト

ブラウザ・リクエスト

FW0

80

HTTP/ロード・バランサ

両方

Oracle Identity Managementで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツに応じて、タイムアウトは異なります。

ブラウザ・リクエスト

FW0

443

HTTPS/ロード・バランサ

両方

Oracle Identity Managementで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツに応じて、タイムアウトは異なります。

Web層からのOracle WebLogic管理サーバー・アクセス

FW1

7001

HTTP/Oracle HTTP Serverと管理サーバー

インバウンド

該当なし

Enterprise Managerエージェント - Web層からEnterprise Managerへ

FW1

5160

HTTP/Enterprise ManagerエージェントとEnterprise Manager

両方

該当なし

Oracle HTTP ServerからWLS_ODSへ

FW1

7006

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

Oracle HTTP ServerからWLS_OAMへ

FW1

14100

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

Oracle HTTP ServerからWLS_OAAM_ADMINへ

FW1

14200

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

mod_weblogicパラメータに応じて、タイムアウトは異なります。

Oracle HTTP ServerからWLS_OAAMへ

FW1

14300

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

WLS_OIM

FW1

14000

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

WLS_SOA

FW1

8001

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

Web層でのOracle Process Manager and Notification Server（OPMN）アクセス

FW1

OPMNリモート・ポート

HTTP/管理サーバーからOPMNへ

アウトバウンド

該当なし

Oracle HTTP Serverプロキシ・ポート

FW1

9999

HTTP/管理サーバーからOracle HTTP Serverへ

アウトバウンド

該当なし

アクセス・サーバー10gアクセス

FW1

6021

OAP

両方

該当なし

アクセス・サーバー11g

FW1

5574-5575

OAP

両方

該当なし

Oracle Coherenceポート

FW1

9095

TCMP

両方

該当なし

ディレクトリ層からのOracle WebLogic管理サーバー・アクセス

FW2

7001

HTTP/Oracle Internet Directory、Oracle Virtual Directory、および管理サーバー

アウトバウンド

該当なし

Enterprise Managerエージェント - ディレクトリ層からEnterprise Managerへ

FW2

5160

HTTP/Enterprise ManagerエージェントとEnterprise Manager

両方

該当なし

ディレクトリ層でのOPMNアクセス

FW2

OPMNリモート・ポート

HTTP/管理サーバーからOPMNへ

インバウンド

該当なし

Oracle Virtual Directoryプロキシ・ポート

FW2

8899

HTTP/管理サーバーからOracle Virtual Directoryへ

インバウンド

該当なし

データベース・アクセス

FW2

1521

SQL*Net

両方

Oracle Identity Managementで使用されるプロセス・モデルのタイプとすべてのデータベース・コンテンツに応じて、タイムアウトは異なります。

Oracle Internet Directoryアクセス

FW2

389

LDAP

インバウンド

ロード・バランサに基づいてディレクトリ・サーバーのパラメータを調整します。それ以外の方法では調整しないでください。理想的には、タイムアウトが発生しないようにこれらの接続を構成します。

Oracle Internet Directoryアクセス

FW2

636

LDAP SSL

インバウンド

ロード・バランサに基づいてディレクトリ・サーバーのパラメータを調整します。それ以外の方法では調整しないでください。理想的には、タイムアウトが発生しないようにこれらの接続を構成します。

Oracle Virtual Directoryアクセス

FW2

6501

LDAP

インバウンド

理想的には、タイムアウトが発生しないようにこれらの接続を構成します。

Oracle Virtual Directoryアクセス

FW2

7501

LDAP SSL

インバウンド

理想的には、タイムアウトが発生しないようにこれらの接続を構成します。

ロード・バランサからOracle HTTP Serverへ

該当なし

7777

HTTP

該当なし

該当なし

WebLogicサーバー・クラスタ内でのセッション・レプリケーション

該当なし

該当なし

該当なし

該当なし

デフォルトでは、この通信はサーバーのリスニング・アドレスと同じポートを使用します。

ノード・マネージャ

該当なし

5556

TCP/IP

該当なし

該当なし

OAMADMINHOSTからのWebゲート・アクセス

該当なし

これはオプションです。Webゲートが構成されているOracle HTTP Serverのリスニング・ポート（7777）を使用できます。

OAP

該当なし

該当なし

OAMADMINHOSTからのWebパス・アクセス

該当なし

6022

OIP

該当なし

該当なし

アイデンティティ・サーバー・アクセス

該当なし

6022

OIP

該当なし

該当なし


注意:

ファイアウォール間で追加のポートを開き、外部ドメイン（SOA、WebCenterドメインなど）でアプリケーションを有効にし、このアイデンティティ管理ドメインに対して認証する必要がある場合があります。

2.3 WebLogicドメインの考慮事項

ドメインは、WebLogic Serverインスタンスの基本的な管理単位です。ドメインは、単一の管理サーバーを使用して管理する1つ以上のWebLogic Serverインスタンス（およびその関連リソース）から構成されています。様々なシステム管理者の責任、アプリケーション境界、またはサーバーの地理的な場所に基づいて複数のドメインを定義できます。逆に、単一のドメインを使用して、すべてのWebLogic Serverの管理アクティビティを一元管理できます。

アイデンティティ管理のコンテキストでは、配置される場合があるSOA、WebCenterおよびその他の顧客アプリケーションから隔離されたWebLogic Serverドメインにアイデンティティ管理コンポーネントを配置することをお薦めします。標準のエンタープライズ・デプロイメントでは、アイデンティティ管理コンポーネント（LDAPディレクトリ、シングル・サインオン・ソリューション、プロビジョニング・ソリューションなど）の管理は、ミドルウェア・インフラストラクチャおよびアプリケーションを管理する管理者とは異なる管理者が行います。

開発環境またはテスト環境において単一のドメインにすべてを配置することは技術的には可能です。ただし、本番環境では、別々のドメインを使用するという推奨事項により、アイデンティティ管理スタックと残りのミドルウェアおよびアプリケーションのデプロイメントの間に論理的管理境界が作成されます。

2.4 共有記憶域と推奨ディレクトリ構造

この項では、EDGトポロジ用に推奨するディレクトリおよびディレクトリ構造を詳細に説明します。その他のディレクトリ・レイアウトも可能であり、サポートされていますが、このマニュアルで採用するモデルは、可用性を最大化するために選択されており、コンポーネントの最良の独立性と構成の対称性の両方を実現し、バックアップおよび災害からのリカバリを容易にします。ドキュメントの残りの部分では、このディレクトリ構造およびディレクトリ用語を使用します。

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

2.4.1 ディレクトリ構造の用語および環境変数

この項では、ディレクトリ構造の用語および環境変数について説明します。

  • ORACLE_BASE: この環境変数および関係するディレクトリ・パスは、Oracle製品がインストールされるベース・ディレクトリを表します。

  • MW_HOME: この環境変数および関係するディレクトリ・パスは、Oracle Fusion Middlewareが配置されている場所を表します。MW_HOMEにはWL_HOME、ORACLE_COMMON_HOME、および1つ以上のORACLE_HOMEがあります。

  • WL_HOME: この環境変数および関係するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。

  • ORACLE_HOME: この環境変数および関係するディレクトリ・パスは、Oracle Fusion Middleware Identity Managementがインストールされている場所を表します。

  • ORACLE_COMMON_HOME: この環境変数および関係するディレクトリ・パスは、Oracle Fusion Middleware Common Java Required Files（JRF）ライブラリおよびOracle Fusion Middleware Enterprise Managerライブラリがインストールされている場所を表します。

  • DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報（構成アーティファクト）が格納されている場所を表します。各種WebLogic Serverは、異なるドメイン・ディレクトリを使用できます。これは第2.4.2項「各種ディレクトリの推奨場所」で説明されているように、同じノード内の場合でも同様です。

  • ORACLE_INSTANCE: Oracleインスタンスには、1つ以上のシステム・コンポーネント（Oracle Webキャッシュ、Oracle HTTP Server、Oracle Internet Directoryなど）が含まれています。Oracleインスタンス・ディレクトリには、更新可能ファイル（構成ファイル、ログ・ファイル、一時ファイルなど）が含まれています。

2.4.2 各種ディレクトリの推奨場所

Oracle Fusion Middleware 11gは、製品バイナリとランタイム・アーティファクトの分離が可能です。

このエンタープライズ・デプロイメント・モデルのWeb層およびデータ層では、1つのホストにつき1つのORACLE_HOME（製品バイナリ用）と1つのインスタンスに1つのORACLE_INSTANCEをローカル・ディスクまたは共有ディスクにインストールすることをお薦めします。このORACLE_HOMEは、ホスト上で実行中のすべてのインスタンスで共有できます。各インスタンスには、独自のORACLE_INSTANCEの場所があります。ORACLE_HOMEとORACLE_INSTANCEの両方をそれぞれのボックスにマウントされた共有ディスクに配置することもできます。同じタイプの追加サーバー（スケールアウトやスケール・アップを行うとき）でこれらのMW_HOMEのいずれかを使用できます。その際、さらに別のインストールは必要ありません。

アプリケーション層では、Middlewareホーム（MW_HOME）を共有ディスクに配置することをお薦めします。高可用性を実現するために、このドメインに2つのMW_HOMEを配置することをお薦めします。アプリケーション層ノードは、これらのいずれかをマウント・ポイントにマウントします。このマウント・ポイントは、すべてのアプリケーション層ノードで同じである必要があります。同じタイプの追加サーバー（スケールアウトやスケール・アップを行うとき）でこれらのMW_HOMEのいずれかを使用できます。その際、さらに別のインストールは必要ありません。

前述の推奨事項に基づいて、表2-3に推奨のディレクトリ構造を示します。リストされたディレクトリの場所は例であり、変更できます。ただし、均一性、一貫性および簡潔性を実現するためにこれらの場所を使用することをお薦めします。


注意:

下記の表において、ディレクトリに共有記憶域が必要な場合、共有記憶域の列に「」が入ります。ローカル・ディスクまたは共有記憶域の使用がオプションの場合、共有記憶域の列に「オプション」が入ります。共有記憶域の場所は例であり、指定のマウント・ポイントが使用されるかぎり、これを変更できます。

表2-3 推奨ディレクトリ構造


 環境変数 マウント・ポイントまたはディレクトリ構造 共有記憶域の場所 ホスト名 共有記憶域

共通

ORACLE_BASE

/u01/app/oracle



MW_HOME

ORACLE_BASE/product/fmw


Web層

ORACLE_HOME

MW_HOME/web

オプション

ORACLE_INSTANCE

ORACLE_BASE/admin/instanceName

オプション

アイデンティティ管理アプリケーション層

MW_HOME

ORACLE_BASE/product/fmw

/vol/MW_HOME1

IDMHOST OIMHOST1 OIFHOST1 OAAMHOST1


MW_HOME

ORACLE_BASE/product/fmw

/vol/MW_HOME2

IDMHOST2 OIMHOST2 OIFHOST2 OAAMHOST2


IDM ORACLE_HOME

MW_HOME/idm


IAM_ORACLE_HOME

MW_HOME/iam



SOA_ORACLE_HOME

MW_HOME/soa



WL_HOME

MW_HOME/wlserver_version


ORACLE_INSTANCE

ORACLE_BASE/admin/instanceName

オプション

ASERVER_HOME

ORACLE_BASE/admin/domainName/aserver

/vol/admin

IDMHOST1


ASERVER_DOMAIN_HOME

ASERVER_HOME/domainName



ASERVER_APP_HOME

ASERVER_HOME/applications



MSERVER_HOME

ORACLE_BASE/admin/domainName/mserver

オプション

MSERVER_DOMAIN_HOME

MSERVER_HOME/domainName



MSERVER_APP_HOME

MSERVER_HOME/applications


OAM 10gアプリケーション層

OAM_BASE

MW_HOME/oam

オプション

IDENTITY_SERVER_ORACLE_HOME

OAM_BASE/identity

オプション

ACCESS_SERVER_ORACLE_HOME

OAM_BASE/access

オプション

WEBPASS_ORACLE_HOME

OAM_BASE/webcomponents/identity

オプション

POLICY_MANAGER_ORACLE_HOME

OAM_BASE/webcomponents/access

オプション

WEBGATE_ORACLE_HOME

OAM_BASE/webgate

オプション

ディレクトリ層

ORACLE_HOME

MW_HOME/idm

オプション

ORACLE_INSTANCE

ORACLE_BASE/admin/instanceName

オプション

次のコマンドは例です。ご使用のオペレーティング・システムに適切なコマンドを使用してください。

  • 共有記憶域のMW_HOME1ボリュームをIDMHOST1のMW_HOMEマウント・ポイントにマウントするには、IDMHOST1上でrootとして次のコマンドを実行します。

    mount storageHost:/Path_to_MW_HOME1_volume_on_SharedDisk 
MW_HOME_moutpoint_on_IDMHOST1 
-t nfs 
-o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

    次に例を示します。

    mount storageHost:/vol/MW_HOME1 /u01/app/oracle/product/fmw -t nfs \
   -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

  • 共有記憶域のMW_HOME2ボリュームをIDMHOST2のMW_HOMEマウント・ポイントにマウントするには、IDMHOST2上でrootとして次のコマンドを実行します。

    mount storageHost:/Path_to_MW_HOME2_volume_on_SharedDisk 
MW_HOME_moutpoint_on_IDMHOST2 
-t nfs 
-o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

    次に例を示します。

    mount storageHost:/vol/MW_HOME2 /u01/app/oracle/product/fmw -t nfs \
   -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

  • 共有記憶域のADMINボリュームをIDMHOST1のAServer_Homeマウント・ポイントにマウントするには、IDMHOST1上でrootとして次のコマンドを実行します。

    mount storageHost:/Path_to_ADMIN_volume_on_SharedDisk 
ASERVER_HOME_moutpoint_on_IDMHOST1 
-t nfs 
-o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

    次に例を示します。

    mount storageHost:/vol/ADMIN /u01/app/oracle/admin/IDMDomain/aserver -t nfs \
   -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

図2-1は、推奨のディレクトリ構造を示します。

図2-1 アイデンティティ管理のディレクトリ構造

図2-1の説明
「図2-1 アイデンティティ管理のディレクトリ構造」の説明

表2-4は、図2-1で色付きでコード化された要素の意味を説明します。図2-1のディレクトリ構造は、ORACLE_COMMON_HOMEやjrockitなどのその他の必須の内部ディレクトリを示すものではありません。

表2-4 ディレクトリ構造の要素

要素 説明
共有記憶域

管理サーバー・ドメインのディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ・コントロール・ディレクトリ、JMSログ、TXログ、およびMW_HOME全体は共有ディスク上にあります。
ローカルまたは共有記憶域

管理対象サーバー・ドメインのディレクトリは、ローカル・ディスクまたは共有ディレクトリに配置できます。また、管理対象サーバー・ドメインのディレクトリを複数のノード上で共有する場合、ノード間で同じ共有ディスクの場所をマウントする必要があります。Web層のinstance_nameディレクトリは、ローカル・ディスクまたは共有ディスクに配置できます。
固定名

固定名
インストール依存名

インストール依存名

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引