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

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

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

• 第2.1項「ハードウェア・リソースの計画」

• 第2.2項「ネットワークの前提条件」

• 第2.3項「WebLogicドメインの考慮事項」

• 第2.4項「共有記憶域と推奨ディレクトリ構造」

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

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

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

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

サーバー	プロセッサ	ディスク	メモリー	TMPディレクトリ	スワップ
データベース・ホスト(OIDDBHOSTn、OIDDBHOSTn、OAAMDBHOSTn)	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	6GB	デフォルト	デフォルト
OIDHOSTn、OVDHOSTn	1.5GHz以上で動作するX Pentiumが2個以上	10GB	4GB	デフォルト	デフォルト

これらは標準的なハードウェア要件です。層ごとに、負荷、スループット、応答時間などの要件を慎重に考慮して、実際に必要な容量を計画してください。必要なノード数、CPU、およびメモリーは、デプロイメント・プロファイルに応じて層ごとに異なる可能性があります。本番での要件は、アプリケーションおよびユーザー数によって異なる場合があります。

本ガイドで説明するエンタープライズ・デプロイメント構成では、フェイルオーバー機能を提供するために層ごとに2つのサーバーを使用しています。ただし、これによってあらゆるアプリケーションやユーザー数に十分なコンピューティング・リソースが確実に用意できるとは限りません。システム・ワークロードの増加によってパフォーマンスが低下した場合は、2台目のサーバー(つまり、WEBHOST2、IDMHOST2、OIDHOST2、OVDHOST2、OIDDBHOST2)に対する手順を繰り返して構成にサーバーを追加することにより、必要な場所に追加のサーバーをインストールし、構成できます。

注意: オペレーティング・システム・レベル、パッチ・レベル、ユーザー・アカウント、およびユーザー・グループに関して、トポロジ内のノードすべての構成を同一にすることをお薦めします。

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

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

• ロード・バランサ

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

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

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

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

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

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

• 第2.2.1項「ロード・バランサ」

• 第2.2.2項「ロード・バランサの仮想サーバー名とポートの構成」

• 第2.2.3項「仮想IPアドレス」

• 第2.2.4項「Oracle Fusion Middlewareコンポーネントの接続の管理」

• 第2.2.5項「Oracle Access Manager通信プロトコルと用語」

• 第2.2.6項「ファイアウォールとポート構成」

2.2.1 ロード・バランサ

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

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

• ポート変換の構成。

• ポート(HTTPおよびHTTPS)の監視。

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

  • ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、OracleASクラスタの場合は、1つの仮想サーバーと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トラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なDMZ間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。

ロード・バランサを設定する際には、すべてのHTTPリクエストにリクエスト・ヘッダーを追加するHTTPプロファイルを定義する必要があります。タイプHTTPSのリクエストを受け取るこの項の各仮想サーバー名に、このHTTPプロファイルを割り当てる必要があります。

HTTPプロファイルは、次のリクエスト・ヘッダーを挿入します。

Header Name: IS_SSL
Header Value: ssl

本ドキュメントでは以降、デプロイメントは第1章に示したデプロイメントのいずれかであると想定します。

oididstore.mycompany.com

• このエントリは、アイデンティティ情報がOracle Internet Directoryに格納されている場合にのみ必要です。

• この仮想サーバーはLBR2上で有効になっています。これは、すべてのアイデンティティ・ベースのLDAPトラフィックに対してアクセス・ポイントの役割を果たします。これは、ディレクトリ層のOracle Internet Directoryサーバーに格納されます。SSLと非SSLの両方へのトラフィックが構成されます。クライアントは、アドレスoididstore.mycompany.com:636(SSLの場合)、およびoididstore.mycompany.com:389(非SSLの場合)を使用してこのサービスにアクセスします。

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

policystore.mycompany.com

• この仮想サーバーはLBR2上で有効になっています。これは、すべてのポリシー・ベースのLDAPトラフィックに対してアクセス・ポイントの役割を果たします。これは、ディレクトリ層のOracle Internet Directoryサーバーに格納されます。SSLと非SSLの両方へのトラフィックが構成されます。クライアントは、アドレスpolicystore.mycompany.com:636(SSLの場合)、およびpolicystore.mycompany.com:389(非SSLの場合)を使用してこのサービスにアクセスします。

  
  

  注意: LDAPサーバーのSSL接続と、Oracle Internet Directoryがインストールされた各コンピュータ上のOracle Internet DirectoryのSSL接続には、同じポートを構成することをお薦めします。 これは、ロード・バランシング・ルーターを介してOracle Internet Directoryを使用するほとんどのOracle 11g製品の要件です。

  
  

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

idstore.mycompany.com

• この仮想サーバーはLBR2上で有効になっています。これは、すべてのアイデンティティ・ストアLDAPトラフィックに対してアクセス・ポイントの役割を果たします。SSLと非SSLの両方へのトラフィックが構成されます。クライアントは、アドレスidstore.mycompany.com:636(SSLの場合)、およびidstore.mycompany.com:389(非SSLの場合)を使用してこのサービスにアクセスします。

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

• アイデンティティ・ストアがOracle Internet Directory内にあり、直接アクセスを受ける場合は、Oracle Internet Directoryホスト上でOracle Internet Directoryプロセスのハートビートを監視します。Oracle Internet DirectoryプロセスがいずれかのOIDHOSTで停止した場合、またはいずれかのOIDHOSTに障害が発生した場合は、ロード・バランサは障害が発生していないコンピュータにLDAPトラフィックを継続してルーティングする必要があります。

• Oracle Internet Directoryのみのトポロジを使用している場合、idstore.mycompany.comはアイデンティティ・データを格納するOracle Identity Federationを指します。サード・パーティ・ディレクトリにアイデンティティ・データを格納する場合、またはOracle Internet Directoryアイデンティティ・ストアの前にOracle Virtual Directoryを配置する場合は、idstoreはOracle Virtual Directoryを指します。

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管理対象サーバーは、この仮想ホストにアクセスして、Oracle Identity Manager Webサービスのコールバックを行います。

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

sso.mycompany.com

• これは、Oracle Identity Manager、Oracle Access Manager、OAAM、Oracle Identity Federationなど、すべてのアイデンティティ管理コンポーネントを代表する仮想名です。

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

• ロード・バランサでポート80とポート443の両方を使用してこの仮想サーバーを構成します。

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

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

2.2.3 仮想IPアドレス

仮想IPアドレスは、ホストの主要IPアドレスと同じサブネットに属する、未使用のIPアドレスです。このアドレスはホストに手動で割り当てられ、Oracle WebLogic管理対象サーバーはこのIPアドレスをリスニングするように構成されます。IPアドレスが割り当てられたノードに障害が発生した場合は、割り当てられた管理対象サーバーの実行を新しいノードが引き継ぐことができるように、このIPアドレスは同じサブネット内の別のノードに割り当てられます。

次に、Oracle Identity Managementが必要とする仮想IPアドレスのリストを示します。

adminvhn.mycompany.com

エンタープライズ・デプロイメントでは、WebLogic管理サーバーが、配置されているホストに障害が発生した後でも、リクエストの処理を継続できることが必要です。仮想IPアドレスは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。WebLogic管理サーバーは、後でこの仮想IPアドレスをリスニングするように構成されます。これについては、本ドキュメントで後述します。この仮想IPアドレスは、管理サーバーとともに、IDMHOST1からIDMSHOST2に(またはその逆に)フェイルオーバーします。

soavhnx

SOA管理対象サーバーごとに1つの仮想IPアドレスが必要です。これにより、サーバーをサーバー移行の処理対象にすることができます。

アプリケーション層内で仮想IPアドレスをプロビジョニングすることにより、アプリケーション層にある任意のホストのネットワーク・インタフェースにこのアドレスをバインドできるようにします。

oimvhnx

Oracle Identity Manager管理対象サーバーごとに1つの仮想IPアドレスが必要です。これにより、サーバーをサーバー移行の処理対象にすることができます。

アプリケーション層内で仮想IPアドレスをプロビジョニングすることにより、アプリケーション層にある任意のホストのネットワーク・インタフェースにこのアドレスをバインドできるようにします。

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

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

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

ここでは、Oracle Accessプロトコル(OAP)について説明し、ユーザー・リクエストの概要を示します。

2.2.5.1 Oracle Access Managerプロトコル

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

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

ユーザーがアクセスをリクエストするときのリクエスト・フローは、次のとおりです。

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

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

3. Webゲートは、Oracle Accessプロトコルを使用してリクエストをOracle Access Managerサーバーに転送し、リソースが保護されているかどうか、どのように保護されているか、またユーザーが認証されているかどうかを判別します(認証されていない場合は、チャレンジが行われます)。

4. Oracle Access Managerサーバーは、ユーザーIDやパスワードなどの資格証明についてディレクトリ・サーバーを確認し、Oracle Accessプロトコルを使用してWebゲートに情報を送り返し、ユーザーを認証するための暗号化Cookieを生成します。

5. 認証の後、WebゲートはOracle Accessプロトコルを使用してOracle Access Managerサーバーに指示し、Oracle Access Managerサーバーは該当するセキュリティ・ポリシーを検索してユーザーのアイデンティティと比較し、ユーザーの認証レベルを判別します。

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

   • ポリシーが偽の場合、ユーザーはアクセスを拒否され、組織の管理者が決めた別の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パラメータに応じて、タイムアウトは異なります。
Oracle HTTP Server WLS_OIM	FW1	14000	HTTP/Oracle HTTP ServerからWebLogic Serverへ	インバウンド	使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。
Oracle HTTP Server 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へ	アウトバウンド	該当なし
Oracle Access Managerサーバー11g	FW1	5574-5575	OAP	両方	該当なし
Oracle Coherenceポート	FW1	8000 - 8090	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 Identity Federationアクセス	FW2	7499	HTTP	両方	該当なし
OIN	FW2	7001	HTTP	両方	該当なし
ロード・バランサからOracle HTTP Serverへ	該当なし	7777	HTTP	該当なし	該当なし
WebLogicサーバー・クラスタ内でのセッション・レプリケーション	該当なし	該当なし	該当なし	該当なし	デフォルトでは、この通信はサーバーのリスニング・アドレスと同じポートを使用します。
ノード・マネージャ	該当なし	5556	TCP/IP	該当なし	該当なし

注意: 外部ドメイン(SOA、WebCenterドメインなど)のアプリケーションをこのアイデンティティ管理ドメインで認証できるように、ファイアウォール間で追加のポートを開く必要が生じることがあります。

2.3 WebLogicドメインの考慮事項

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

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

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

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

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

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

• 第2.4.1項「ディレクトリ構造の用語および環境変数」

• 第2.4.2項「各種ディレクトリの推奨場所」

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

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

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

• MW_HOME: この環境変数および関係するディレクトリ・パスは、Oracle Fusion Middlewareが配置されている場所を表します。MW_HOMEは、WL_HOME、ORACLE_COMMON_HOME、および1つ以上のORACLE_HOMEからなります。標準的なMW_HOMEの例は、ORACLE_BASE/product/fmwです。

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

• ORACLE_HOME: この環境変数は、Oracle Fusion Middleware製品(Oracle HTTP Server、Oracle SOA Suite、Oracle Internet Directoryなど)がインストールされている場所を示します。この場所にあるその製品のバイナリが現在のプロシージャで使用されています。例: MW_HOME/iam

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

• ドメイン・ディレクトリ: このパスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されているファイル・システムの場所を示します。同じノードに属している場合であっても、異なるWebLogic Serverは、それぞれ異なるドメイン・ディレクトリを使用できます。これについては、第2.4.2項「各種ディレクトリの推奨場所」を参照してください。

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

• ASERVER_HOME: これは、WebLogic管理サーバーに関連するアーティファクトの場所です。これらのアーティファクトは、管理対象サーバーに属するものとは別個に維持されるので、管理サーバーの独立した管理とフェイルオーバーが可能です。標準的な例: ORACLE_BASE/admin/IDMDomain/aserver

• MSERVER_HOME: 管理対象サーバーに関連するアーティファクトの場所です。これらは管理サーバーとは別個に格納されます。標準的な例: ORACLE_BASE/admin/IDMDomain/mserver

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

Oracle Fusion Middleware 11gを使用して、単一のバイナリ・インストールから複数のアイデンティティ管理サーバーを作成できます。これにより、共有記憶域上の単一の場所にバイナリをインストールし、異なるノード内にあるサーバーでこのインストールを再利用できます。ただし、可用性が最大になるように、バイナリの冗長インストールを使用することをお薦めします。エンタープライズ・デプロイメント・モデルでは、2つのMW_HOMEをインストールします(それぞれ、共有記憶域内の製品スイートごとにWL_HOMEとORACLE_HOMEを含む)。スケール・アウトまたはスケール・アップの際には、同じタイプの追加サーバーのためにこれら2つの場所のどちらかを使用でき、インストール作業をさらに行う必要はありません。理想的には、それぞれのボリュームの障害を可能なかぎり分離するために、2つの異なるボリュームを冗長バイナリ・ロケーションに使用することをお薦めします。さらに保護を強化するために、これらのボリュームのディスク・ミラーを行うことをお薦めします。複数ボリュームが利用できない場合は、共有記憶域上の異なるディレクトリで同じマウント場所をシミュレートするマウント・ポイントを使用することをお薦めします。複数のボリュームによって実現する保護は前述の例はNASに特有ですがこれによって保証されませんが、ユーザーによる削除や個々のファイルの破損から保護できます。

ORACLE_HOMEまたはWL_HOMEが異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保してください。ノードでoraInventory を更新して、これに共有記憶域のインストールを関連付けるには、ORACLE_HOME/oui/bin/attachHome.shを使用します。Middlewareホーム・リストを更新してWL_HOMEを追加または削除するには、ファイルbeahomelistを編集します。このファイルは、ユーザーのホーム・ディレクトリ内のbeaという名前のディレクトリにあります(例: /home/oracle/bea/beahomelist)。これは、このエンタープライズ・デプロイメントで使用される2つのノードに加えてインストールされるノードで必要になります。oraInventoryとbeahomelistを更新する例が、このガイドに記載されているスケール・アウト手順で用意されています。第21.3.2項「トポロジのスケール・アウト」を参照してください。

また、WebLogic管理サーバーで使用されるドメイン・ディレクトリと管理対象サーバーで使用されるドメイン・ディレクトリを別々にすることもお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有記憶域に配置する必要があります。管理対象サーバーのドメイン・ディレクトリは、ローカルの記憶域にも共有記憶域にも配置できます。

異なるノードに属するすべての管理対象サーバーに共有ドメイン・ディレクトリを使用することも、ノードごとに1つのドメイン・ディレクトリを使用することもできます。管理対象サーバーのドメイン・ディレクトリを共有すると、スケール・アウト手順が容易になります。この場合、ストレージ・システムの要件があればデプロイメントではその要件に適合する必要があります。これによって、複数のマシンで同じ共有ボリュームのマウントが容易になります。このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとに各ノードのローカル・ドメイン・ディレクトリが使用されると想定しています。

複数のローカル・ドメインに該当するすべての手順は、1つの共有ドメインにも該当します。したがって、このエンタープライズ・デプロイメント・ガイドでは1つのドメイン・ディレクトリが各ノードで使用されるモデルを使用しています。このディレクトリは、ローカルにも共有記憶域にも配置できます。

サーバーの障害や移行の場合にリカバリで複数のボックスを利用可能にするには、JMSファイル・ストアとJTAトランザクション・ログは共有記憶域に配置する必要があります。

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

前述の前提事項に基づいて、推奨されるディレクトリを次に示します。共有記憶域の場所が直接指定されている場合は必ず、そのディレクトリでは共有記憶域が必要とされることを意味します。ローカル・ディスクが使用されたり共有記憶域がオプションの場合、マウント指定では「共有記憶域を使用している場合」の語句で修飾されます。共有記憶域の場所は例であり、指定のマウント・ポイントが使用されるかぎり、これを変更できます。ただし、共有記憶域デバイスでは整合性と単純化のためこの構造をお薦めします。

注意: 次の表において、ディレクトリに共有記憶域が必要な場合、共有記憶域の列に「はい」が入ります。ローカル・ディスクまたは共有記憶域の使用がオプションの場合、共有記憶域の列に「オプション」が入ります。共有記憶域の場所は例であり、指定のマウント・ポイントが使用されるかぎり、これを変更できます。 複数のホームにわたる高可用性トポロジをインストールする際には、すべてのノードに同じディレクトリ構造を使用することをお薦めします。

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

	環境変数	マウント・ポイントまたはディレクトリ構造	共有記憶域の場所	ホスト名	共有記憶域
共通	ORACLE_BASE	/u01/app/oracle
	MW_HOME	ORACLE_BASE/product/fmw
	JAVA_HOME	MW_HOME/jrockit_version
	ORACLE_COMMON_HOME	MW_HOME/oracle_common
Web層	WEB_ORACLE_HOME	MW_HOME/web			オプション
	ORACLE_INSTANCE	ORACLE_BASE/admin/instanceName			オプション
アイデンティティ管理アプリケーション層	MW_HOME	ORACLE_BASE/product/fmw	/vol/MW_HOME1	IDMHOST1 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
ディレクトリ層	IDM_ORACLE_HOME	MW_HOME/idm			オプション
	ORACLE_INSTANCE	ORACLE_BASE/admin/instanceName			オプション

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

• 共有記憶域のvolume/vol/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
  

• 共有記憶域のvolume/vol/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
  

• 共有記憶域のvolume/vol/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-4は、図2-1で色付きでコード化された要素の意味を説明します。図2-1のディレクトリ構造は、ORACLE_COMMON_HOMEやjrockitなど、その他の必要な内部ディレクトリを示していません。

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

要素	説明
	管理サーバー・ドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSおよびTXのログ、およびMW_HOME全体が共有ディスクに配置されます。
	管理対象サーバー・ドメインのディレクトリは、ローカル・ディスクまたは共有ディレクトリに配置できます。また、管理対象サーバー・ドメインのディレクトリを複数のノード上で共有する場合、ノード間で同じ共有ディスクの場所をマウントする必要があります。Web層のinstance_nameディレクトリは、ローカル・ディスクまたは共有ディスクに配置できます。
	固定名
	インストール依存名