| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-03 |
|
前 |
次 |
この章では、Oracle Business Intelligenceエンタープライズ・トポロジで必要なネットワーク環境の事前構成について説明します。この章を使用して、仮想サーバー名、ロード・バランサ、IPと仮想IP、ファイアウォールおよびポートの構成を計画してください。
この章の内容は次のとおりです。
様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらの仮想サーバーは、サービスを実行するために適切な実際のホストおよびポートに対して構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。
Oracle Business Intelligenceを実行する計画のあるすべてのコンピュータで、完全修飾ドメイン名を使用してクラスタのプライマリ・ホスト・コンピュータにアクセス(ping)できることを確認する必要があります。インストールが成功するには、インストールをスケール・アウトするすべてのコンピュータが、クラスタのプライマリ・ホスト上の管理サーバーとの双方向通信をサポートできる必要があります。
BIエンタープライズ・トポロジでは、次の仮想サーバー名を使用します。
仮想サーバー名がIPアドレスと関連付けられており、DNSの一部になっていることを確認してください。Oracle Fusion Middlewareを実行するノードは、これらの仮想サーバー名を解決できるようになっている必要があります。
さらに、仮想IPアドレスは、物理ホストのIPアドレスと同じサブネット上に存在する必要があります。
第3.3項「ロード・バランサの構成」の手順に従って、ロード・バランサで仮想サーバー名を定義します。
bi.mycompany.comは、ランタイムOracle BIコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。SSLへのトラフィックが構成されます。クライアントは、bi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。
admin.mycompany.comは、Oracle WebLogic管理サーバー・コンソールやOracle Enterprise Managerなどの管理サービスに転送されるすべての内部HTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。
クライアントからの入力トラフィックは、SSL対応ではありません。クライアントはadmin.mycompany.com:80のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。この仮想サーバーは、ロード・バランサ上に定義されます。
このエンタープライズ・トポロジは外部のロード・バランサを使用します。第3.2項「トポロジで使用する仮想サーバー名について」で説明する仮想サーバー名を定義して、ロード・バランサを構成します。
この章で説明する手順には概要が含まれています。実行する必要がある実際の手順は、使用するロード・バランサのタイプによって異なります。詳細は、使用するロード・バランサのドキュメントを参照してください。
ロード・バランサの詳細は、第2.1.3項「Web層ノードについて」を参照してください。
|
注意: 検証済ロード・バランサおよびその構成の詳細は、Oracle Technology Networkの次のページを参照してください。
|
仮想サーバー名を定義してロード・バランサを構成する手順は次のとおりです。
サーバーのプールを作成します。このプールを仮想サーバーに割り当てます。
Oracle HTTP Serverホストのアドレスをプールに追加します。たとえば、次のとおりになります。
WEBHOST1:7777
WEBHOST2:7777
ロード・バランサにbi.mycompany.com:443の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。
この仮想サーバーでは、システムのフロントエンド・アドレスを仮想サーバーのアドレス(たとえば、bi.mycompany.com)として使用します。フロントエンド・アドレスは外部に公開されているホスト名で、システムで使用されるほか、インターネットに公開されます。
ポート80とポート443でこの仮想サーバーを構成します。ポート80 (非SSLプロトコル)に入力するリクエストはすべて、ポート443 (SSLプロトコル)にリダイレクトされる必要があります。
HTTPをプロトコルとして指定します。
アドレスとポートの変換を有効にします。
サービスやノードが停止した場合に接続のリセットを有効にします。
ステップ1で作成したプールを仮想サーバーに割り当てます。
この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。
ロード・バランサにadmin.mycompany.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。
この仮想サーバーでは、内部管理アドレスを仮想サーバーのアドレス(たとえば、admin.mycompany.com)として使用します。このアドレスは一般的に外部化されません。
HTTPをプロトコルとして指定します。
アドレスとポートの変換を有効にします。
サービスやノードが停止した場合に接続のリセットを有効にします。
必要に応じて、この仮想サーバーの/consoleと/emのみへのアクセスを許可するルールを作成します。
ステップ1で作成したプールを仮想サーバーに割り当てます。
ロード・バランサにbiinternal.mycompany.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。
この仮想サーバーでは、内部管理アドレスを仮想サーバーのアドレス(たとえば、biinternal.mycompany.com)として使用します。このアドレスは一般的に外部化されません。
HTTPをプロトコルとして指定します。
アドレスとポートの変換を有効にします。
サービスやノードが停止した場合に接続のリセットを有効にします。
ステップ1で作成したプールを仮想サーバーに割り当てます。
必要に応じて、この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。
Oracle HTTP Serverノードに監視を構成してノードの障害を検出します。
「/」のURLコンテキストに定期的にpingを実行するように監視を設定します。
|
ヒント: Oracle HTTP Serverのドキュメント・ルートに |
ping実行間隔については、システムに負荷を与えないように値を指定します。とりあえず5秒で試してみることができます。
タイムアウト時間については、使用するBIシステムで予測できる最長レスポンス時間の説明として妥当な値を指定します。つまり、HTTPサーバーのリクエスト処理における最長所要時間より大きな値を指定します。
第7.5項「仮想ホストの構成」に従って仮想ホストを構成すると、仮想ホスト名アドレスへのアクセスが可能になります。アクセスできない場合は、その手順が正しく完了していることを確認します。
表3-1では、様々な仮想ホストについて説明します。
表3-1 仮想ホスト
| 仮想IP | VIPのマップ先 | 説明 |
|---|---|---|
|
VIP1 |
ADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名であり、管理サーバーの手動フェイルオーバーによりフェイルオーバーします。管理サーバーのプロセスが実行されているノード(デフォルトはAPPHOST1)で有効にされます。 |
|
|
VIP2 |
APPHOST1VHN1は、bi_server1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、bi_server1プロセスが実行されているノード(デフォルトはAPPHOST1)で有効化されます。 |
|
|
VIP3 |
APPHOST2VHN1は、bi_server2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、bi_server2プロセスが実行されているノード(デフォルトはAPPHOST2)で有効化されます。 |
BIドメインでは、Oracle Business Intelligenceの管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。これらのホスト名を2つのBIコンピュータ(APPHOST1のVIP2とAPPHOST2のVIP3)にマップしてVIPを有効にし、トポロジで使用するネットワーク・システムの仮想ホスト名に(DNSサーバーまたはホスト解決によって)正しく解決される必要があります。
管理対象サーバーで仮想IPアドレスをリスニングするよう構成する前に、管理対象サーバーを実行しているホスト上のネットワーク・インタフェース・カードのいずれかを、この仮想IPアドレスをリスニングするように構成する必要があります。
適切な仮想IPアドレス(APPHOST1のVIP2およびAPPHOST2のVIP3)が有効になるよう、各ホストで1回ずつ次の手順を実行します。UNIX環境では、コマンドはrootユーザーとして実行する必要があります。
適切なホスト(APPHOST1でまたはAPPHOST2)でifconfigコマンドを実行し、ネットマスクの値を取得します。UNIX環境では、このコマンドをrootユーザーとして実行します。たとえば、APPHOST1で次を行います:
[root@APPHOST1 ~] # /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:11:43:D7:5B:06
inet addr:139.185.140.51 Bcast:139.185.140.255 Mask:255.255.255.0
inet6 addr: fe80::211:43ff:fed7:5b06/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10626133 errors:0 dropped:0 overruns:0 frame:0
TX packets:10951629 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4036851474 (3.7 GiB) TX bytes:2770209798 (2.5 GiB)
Base address:0xecc0 Memory:dfae0000-dfb00000
ifconfigを使用し、仮想IPアドレスをネットワーク・インタフェース・カードにバインドします。UNIX環境では、このコマンドをrootユーザーとして実行します。ステップ1で取得したネットマスク値を使用します。
ifconfigコマンドの構文および用法は次のとおりです。
/sbin/ifconfig networkCardInterface Virtual_IP_Address netmask netMask
次に例を示します。
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
arpingを使用し、ルーティング表を更新します。UNIX環境では、このコマンドをrootユーザーとして実行します。
/sbin/arping -q -U -c 3 -I networkCardInterface Virtual_IP_Address
次に例を示します。
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
APPHOST1の管理サーバーでのVIP1の有効化の詳細は、第8.3.4.1項「APPHOST1上のADMINVHNの有効化」を参照してください。
多くのOracle Fusion Middlewareコンポーネントおよびサービスはポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにする必要があります。
ほとんどのポート番号はインストール中に割り当てられます。
表3-2には、Oracle Business Intelligenceトポロジで使用するポートがリストされており、トポロジのファイアウォールで開く必要のあるポートが含まれています。
ファイアウォール表記法:
FW0は外側のファイアウォールを示します。
FW1は、Web層とアプリケーション層との間におけるファイアウォールを示します。
FW2は、アプリケーション層とデータ層との間におけるファイアウォールを示します。
表3-2 使用されるポート
| タイプ | ファイアウォール | ポートとポート範囲 | プロトコル/アプリケーション | インバウンド/アウトバウンド | その他の考慮事項とタイムアウトのガイドライン |
|---|---|---|---|---|---|
|
ブラウザによるリクエスト |
FW0 |
80 |
HTTP/ロード・バランサ |
インバウンド |
タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
ブラウザによるリクエスト |
FW0 |
443 |
HTTPS/ロード・バランサ |
インバウンド |
タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
なし |
7777 |
HTTP |
なし |
第3.3項「ロード・バランサの構成」を参照してください。 |
|
|
管理サーバーへのOracle HTTP Serverの登録 |
FW1 |
7001 |
HTTP/t3 |
インバウンド |
タイムアウトを短い時間(5から10秒)に設定します。 |
|
管理サーバーによるOracle HTTP Serverの管理 |
FW1 |
OPMNポート(6701)およびOracle HTTP Server管理ポート(7779) |
それぞれTCPとHTTP |
アウトバウンド |
タイムアウトを短い時間(5から10秒)に設定します。 |
|
FW1 |
9704 |
HTTP/bi_servern |
インバウンド |
タイムアウトは、BIによって使用されるプロセス・モデルのタイプによって異なります。 |
|
|
BIクラスタ・メンバー間の通信 |
なし |
9704 |
TCP/IPユニキャスト |
なし |
デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。 |
|
WebLogic Serverクラスタ内におけるセッション・レプリケーション |
なし |
なし |
なし |
なし |
デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。 |
|
FW1 |
7001 |
HTTP/管理サーバーとEnterprise Manager |
両方 |
管理コンソールへのアクセスのタイプ(アプリケーション層のクライアントから管理コンソールを使用する予定があるか、またはアプリケーション層の外部のクライアントから使用する予定があるか)に基づいてこのタイムアウト時間をチューニングする必要があります。 |
|
|
なし |
5556 |
TCP/IP |
なし |
なし 実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールとポートの構成に関する項を参照してください。 |
|
|
アクセス・サーバーのアクセス |
FW1 |
6021 |
OAP |
インバウンド |
実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールとポートの構成に関する項を参照してください。 |
|
アイデンティティ・サーバーのアクセス |
FW1 |
6022 |
OAP |
インバウンド |
なし |
|
BI ServerおよびBI PublisherのJDBCデータ・ソース用のデータベース・アクセス |
FW1 |
クライアントがリスナーに接続するためのリスニング・ポート |
SQL*Net |
両方 |
タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのデータベース・コンテキストによって異なります。 |
|
FW2 |
1521 |
SQL*Net |
両方 |
タイムアウトは、BIによって使用されるプロセス・モデルのタイプとすべてのデータベース・コンテキストによって異なります。 |
|
|
Oracle Internet Directoryのアクセス |
FW2 |
389 |
LDAP |
インバウンド |
ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。 |
|
Oracle Internet Directoryのアクセス |
FW2 |
636 |
LDAP SSL |
インバウンド |
ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。 |
|
OWSM用JOC |
なし |
9991 |
TCP/IP |
なし |
なし |
|
注意: ファイアウォール・ポートはTCP/IPポートの定義によって異なります。 |
Oracle Fusion Middlewareでは、WebLogicドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、XMLファイルまたは様々なタイプのLDAPプロバイダに基づいてストアを使用できます。ドメインでLDAPストアを使用する場合は、すべてのポリシー・データと資格証明データが、一元化されたストアで保持および管理されます。ただし、XMLポリシー・ストアを使用すると、管理対象サーバー上で行われる変更は、両方のサーバーが同じドメイン・ホームを使用している場合を除いて、管理サーバーには伝播されません。
Oracle Business Intelligenceエンタープライズ・デプロイメント・トポロジでは、第4.3項「各種ディレクトリの推奨場所について」の記載のとおり、管理サーバーおよび管理対象サーバーの各種ドメイン・ホームが使用されています。その結果、整合性と一貫性を保持するために、Oracle Business Intelligenceエンタープライズ・デプロイメント環境では、資格証明ストアとポリシー・ストアとしてLDAPストアを使用する必要があります。LDAPストアを資格証明ストアおよびポリシー・ストアとして使用したOracle Business Intelligenceエンタープライズ・デプロイメントを構成するには、第12.1項「資格証明ストアとポリシー・ストアの構成」の手順に従います。
