Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11gリリース1(11.1.1) B61378-01 |
|
戻る |
次へ |
この章では、Oracle Identity Managementインフラストラクチャのエンタープライズ・デプロイメント・トポロジの前提条件について説明します。
この章の内容は次のとおりです。
表1-2は、Linuxオペレーティング・システムでのエンタープライズ・デプロイメントの最小ハードウェア要件を示しています。メモリーの数値は、Oracle Fusion Middlewareサーバーのインストールと実行に必要なメモリーを表していますが、ほとんどの本稼働サイトでは、4GB以上の物理メモリーを構成する必要があります。
詳細な要件や他のプラットフォームの要件については、そのプラットフォームのOracle Fusion Middlewareインストレーション・ガイドを参照してください。
表2-1 標準ハードウェア要件
サーバー | プロセッサ | ディスク | メモリー | TMPディレクトリ | スワップ |
---|---|---|---|---|---|
|
1.5GHz以上で動作するX Pentiumが4個以上 |
nXm n=ディスク数。最小4個(1個のディスクとしてストライプ化) m=ディスクのサイズ(最小30GB) |
6-16GB |
デフォルト |
デフォルト |
|
1.5GHz以上で動作するX Pentiumが2個以上 |
10GB |
4GB |
デフォルト |
デフォルト |
|
1.5GHz以上で動作するX Pentiumが2個以上 |
10GB |
4GB |
デフォルト |
デフォルト |
|
1.5GHz以上で動作するX Pentiumが2個以上 |
10GB |
4GB |
デフォルト |
デフォルト |
これらは標準ハードウェア要件です。各層に対して、負荷、スループット、レスポンス時間およびその他の要件を注意深く考慮し、必要な実際の容量を計画してください。必要なノード、CPU、およびメモリーの数は、デプロイメント・プロファイルに基づいて各層で異なる場合があります。本稼働要件は、アプリケーションおよびユーザー数に依存して異なる場合があります。
このマニュアルで説明しているエンタープライズ・デプロイメント構成では、各層に2つのサーバーを使用してフェイルオーバー機能が実現されています。ただし、これがどのようなアプリケーションやユーザー数に対しても十分な計算リソースであるとはかぎりません。システムのワークロードが増大してパフォーマンスが低下した場合は、必要に応じて2番目のサーバー(つまり、WEBHOST2、IDMHOST2、OIDHOST2、OVDHOST2、INFRADBHOST2)の構成手順を繰り返し、さらにサーバーをインストールおよび構成することで、サーバーを構成に追加することができます。
この項では、エンタープライズ・デプロイメント・トポロジのネットワークの前提条件について説明します。
ロード・バランサ
ロード・バランサの仮想サーバー名とポートの構成
管理サーバーの仮想IP
Oracle Fusion Middlewareコンポーネントの接続の管理
Oracle Access Manager通信プロトコルと用語
ファイアウォールとポート構成
この項の内容は次のとおりです。
このエンタープライズ・トポロジでは、外部のロード・バランサを使用します。この外部ロード・バランサは次の機能を備えている必要があります。
仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。ロード・バランサは、リクエストをプールのサーバーにロード・バランスできるようになります。
ポート変換構成
ポート(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つのロード・バランサ・デバイスがあります。一方のロード・バランサは外部HTTPトラフィック用に設定され、他方のロード・バランサは内部LDAPトラフィック用に設定されます。様々な理由により、デプロイメントで単一のロード・バランサ・デバイスを持つことを選択する場合があります。このことはサポートされていますが、デプロイメントでこれを行うことによるセキュリティ上の影響を考慮する必要があります。適切であると判明した場合、関連するファイアウォール・ポートを開き、様々なDMZへのトラフィックを可能にします。どちらの場合も、指定のロード・バランサ・デバイスをフォルト・トレラント・モードにすることを強くお薦めします。このドキュメントの残りの部分では、第1.4項「エンタープライズ・デプロイメントの参照トポロジ」に示したデプロイメントのいずれかであることを想定します。
この仮想サーバーはLBR2
で有効になっています。これは、ディレクトリ層のOracle Internet DirectoryサーバーへのすべてのLDAPトラフィックのアクセス・ポイントとして動作します。SSLと非SSLの両方へのトラフィックが構成されています。クライアントは、アドレスoid.mycompany.com:636
(SSL用)およびoid.mycompany.com:389
(非SSL用)を使用してこのサービスにアクセスします。
OIDHOST1およびOIDHOST2上でOracle Internet Directoryプロセスのハートビートを監視します。Oracle Internet DirectoryプロセスがOIDHOST1またはOIDHOST2で停止した場合、またはOIDHOST1またはOIDHOST2のいずれかのホストがダウンした場合、ロード・バランサは稼動しているコンピュータへのLDAPトラフィックのルーティングを継続する必要があります。
この仮想サーバーは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トラフィックのルーティングを継続する必要があります。
この仮想サーバーは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にアクセスできる必要があります。
この仮想サーバーは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を実行するコンピュータでは、これらの仮想サーバー名を解決できる必要があります。
idmhost-vip.mycompany.com
仮想IPアドレスは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。WebLogic管理サーバーは、このマニュアルで後ほど説明するように、この仮想IPアドレスをリスニングするように後で構成されます。この仮想IPアドレスは、管理サーバーとともに、IDMHOST1からIDMSHOST2に(またはIDMSHOST2からIDMHOST1に)フェイルオーバーします。
すべてのサービスを常時使用可能にするために、すべてのOracle Fusion Middlewareコンポーネントの接続のタイムアウト値を、ファイアウォールおよびロード・バランシング・ルーターのタイムアウト値より短く設定してください。ファイアウォールまたはロード・バランシング・ルーターがTCPクローズ通知メッセージを送信することなく接続を切断すると、Oracle Fusion Middlewareコンポーネントは接続が使用不可になっても継続してその接続を使用しようとします。
Oracle Access Managerコンポーネントは、Oracle Accessプロトコル(OAP)およびOracle Identityプロトコル(OIP)と呼ばれる独自のプロトコルを使用して、相互に通信します。
Oracle Accessプロトコル(OAP)は、ユーザー認証および認可の間に、アクセス・システム・コンポーネント(ポリシー・マネージャ、アクセス・サーバー、Webゲートなど)間の通信を可能にします。このプロトコルは、以前NetPointアクセス・プロトコル(NAP)またはCOREidアクセス・プロトコルと呼ばれていました。
Oracle Identityプロトコル(OIP)は、アイデンティティ・システム・コンポーネント(アイデンティティ・サーバー、Webパスなど)とWebサーバーの間の通信を管理します。このプロトコルは、以前NetPointアイデンティティ・プロトコル(NIP)またはCOREidアイデンティティ・プロトコルと呼ばれていました。
次にユーザーがアクセスをリクエストしたときのリクエスト・フローを説明します。
ユーザーは、HTTPまたはHTTPSを介して保護されたリソースへのアクセスをリクエストします。
Webゲートはリクエストを捕捉します。
Webゲートは、Oracle Accessプロトコルを介してリクエストをアクセス・サーバーに転送し、リソースが保護されているかどうか、ユーザーの認証方法、およびユーザーが認証されているかどうかを判定します(認証されていない場合は問題になります)。
アクセス・サーバーは、ディレクトリ・サーバーで資格証明(ユーザーIDとパスワードなど)を確認し、Oracle Accessプロトコルを介して情報をWebゲートに戻し、暗号化Cookieを生成してユーザーを認証します。
認証に従い、WebゲートがOracle Accessプロトコルを介してアクセス・サーバーに要求し、アクセス・サーバーは適切なセキュリティ・ポリシーを検索し、そのポリシーをユーザーのアイデンティティと比較してユーザーの認証水準を判別します。
アクセス・ポリシーが有効な場合、ユーザーは目的のコンテンツまたはアプリケーション(あるいはこれら両方)へのアクセスを許可されます。
ポリシーが偽の場合、ユーザーはアクセスを拒否され、組織の管理者が決めた別のURLにリダイレクトされます。
多くの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から |
FW1 |
7006 |
HTTP/Oracle HTTP ServerからWebLogic Serverへ |
インバウンド |
使用される |
Oracle HTTP Serverから |
FW1 |
14100 |
HTTP/Oracle HTTP ServerからWebLogic Serverへ |
インバウンド |
使用される |
Oracle HTTP Serverから |
FW1 |
14200 |
HTTP/Oracle HTTP ServerからWebLogic Serverへ |
インバウンド |
|
Oracle HTTP Serverから |
FW1 |
14300 |
HTTP/Oracle HTTP ServerからWebLogic Serverへ |
インバウンド |
使用される |
|
FW1 |
14000 |
HTTP/Oracle HTTP ServerからWebLogic Serverへ |
インバウンド |
使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。 |
|
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 |
該当なし |
該当なし |
|
該当なし |
これはオプションです。Webゲートが構成されているOracle HTTP Serverのリスニング・ポート(7777)を使用できます。 |
OAP |
該当なし |
該当なし |
|
該当なし |
6022 |
OIP |
該当なし |
該当なし |
アイデンティティ・サーバー・アクセス |
該当なし |
6022 |
OIP |
該当なし |
該当なし |
注意: ファイアウォール間で追加のポートを開き、外部ドメイン(SOA、WebCenterドメインなど)でアプリケーションを有効にし、このアイデンティティ管理ドメインに対して認証する必要がある場合があります。 |
ドメインは、WebLogic Serverインスタンスの基本的な管理単位です。ドメインは、単一の管理サーバーを使用して管理する1つ以上のWebLogic Serverインスタンス(およびその関連リソース)から構成されています。様々なシステム管理者の責任、アプリケーション境界、またはサーバーの地理的な場所に基づいて複数のドメインを定義できます。逆に、単一のドメインを使用して、すべてのWebLogic Serverの管理アクティビティを一元管理できます。
アイデンティティ管理のコンテキストでは、配置される場合があるSOA、WebCenterおよびその他の顧客アプリケーションから隔離されたWebLogic Serverドメインにアイデンティティ管理コンポーネントを配置することをお薦めします。標準のエンタープライズ・デプロイメントでは、アイデンティティ管理コンポーネント(LDAPディレクトリ、シングル・サインオン・ソリューション、プロビジョニング・ソリューションなど)の管理は、ミドルウェア・インフラストラクチャおよびアプリケーションを管理する管理者とは異なる管理者が行います。
開発環境またはテスト環境において単一のドメインにすべてを配置することは技術的には可能です。ただし、本番環境では、別々のドメインを使用するという推奨事項により、アイデンティティ管理スタックと残りのミドルウェアおよびアプリケーションのデプロイメントの間に論理的管理境界が作成されます。
この項では、EDGトポロジ用に推奨するディレクトリおよびディレクトリ構造を詳細に説明します。その他のディレクトリ・レイアウトも可能であり、サポートされていますが、このマニュアルで採用するモデルは、可用性を最大化するために選択されており、コンポーネントの最良の独立性と構成の対称性の両方を実現し、バックアップおよび災害からのリカバリを容易にします。ドキュメントの残りの部分では、このディレクトリ構造およびディレクトリ用語を使用します。
この項の内容は次のとおりです。
この項では、ディレクトリ構造の用語および環境変数について説明します。
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インスタンス・ディレクトリには、更新可能ファイル(構成ファイル、ログ・ファイル、一時ファイルなど)が含まれています。
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 推奨ディレクトリ構造
環境変数 | マウント・ポイントまたはディレクトリ構造 | 共有記憶域の場所 | ホスト名 | 共有記憶域 | |
---|---|---|---|---|---|
共通 |
|
|
|||
|
|
||||
Web層 |
|
|
オプション |
||
|
|
オプション |
|||
アイデンティティ管理アプリケーション層 |
|
|
|
|
|
|
|
|
|
||
IDM |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
オプション |
|||
|
|
|
|
||
|
|
||||
|
|
||||
|
|
オプション |
|||
|
|
||||
|
|
||||
OAM 10gアプリケーション層 |
|
|
オプション |
||
|
|
オプション |
|||
|
|
オプション |
|||
|
|
オプション |
|||
|
|
オプション |
|||
|
|
オプション |
|||
ディレクトリ層 |
|
|
オプション |
||
|
|
オプション |
次のコマンドは例です。ご使用のオペレーティング・システムに適切なコマンドを使用してください。
共有記憶域の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-4は、図2-1で色付きでコード化された要素の意味を説明します。図2-1のディレクトリ構造は、ORACLE_COMMON_HOME
やjrockitなどのその他の必須の内部ディレクトリを示すものではありません。
表2-4 ディレクトリ構造の要素
要素 | 説明 |
---|---|
管理サーバー・ドメインのディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ・コントロール・ディレクトリ、JMSログ、TXログ、およびMW_HOME全体は共有ディスク上にあります。 |
|
管理対象サーバー・ドメインのディレクトリは、ローカル・ディスクまたは共有ディレクトリに配置できます。また、管理対象サーバー・ドメインのディレクトリを複数のノード上で共有する場合、ノード間で同じ共有ディスクの場所をマウントする必要があります。Web層の |
|
固定名 |
|
インストール依存名 |