ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド
11g リリース1(11.1.1)
B63036-05
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

3 エンタープライズ・デプロイメント用のネットワークの準備

この章では、Oracle Business Intelligenceエンタープライズ・トポロジで必要なネットワーク環境の事前構成について説明します。この章を使用して、仮想サーバー名、ロード・バランサ、IPと仮想IP、ファイアウォールおよびポートの構成を計画してください。

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

3.1 エンタープライズ・デプロイメント用のネットワークの準備の概要

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

Oracle Business Intelligenceを実行する計画のあるすべてのコンピュータで、完全修飾ドメイン名を使用してクラスタのプライマリ・ホスト・コンピュータにアクセス(ping)できることを確認する必要があります。インストールが成功するには、インストールをスケール・アウトするすべてのコンピュータが、クラスタのプライマリ・ホスト上の管理サーバーとの双方向通信をサポートできる必要があります。

3.2 トポロジで使用する仮想サーバー名について

BIエンタープライズ・トポロジでは、次の仮想サーバー名を使用します。

仮想サーバー名がIPアドレスと関連付けられており、DNSの一部になっていることを確認してください。Oracle Fusion Middlewareを実行するノードは、これらの仮想サーバー名を解決できる必要があります。

さらに、仮想IPアドレスは、物理ホストのIPアドレスと同じサブネット上に存在する必要があります。

第3.3項「ロード・バランサの構成」の手順に従って、ロード・バランサで仮想サーバー名を定義します。

3.2.1 bi.mycompany.com

bi.mycompany.comは、ランタイムOracle Business IntelligenceコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。SSLへのトラフィックが構成されます。クライアントは、bi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

3.2.2 admin.mycompany.com

admin.mycompany.comは、Oracle WebLogic Server管理サーバー・コンソールやOracle Enterprise Managerなどの管理サービスに転送されるすべての内部HTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。

クライアントからの入力トラフィックは、SSL対応ではありません。クライアントはadmin.mycompany.com:80のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。この仮想サーバーは、ロード・バランサ上に定義されます。

3.2.3 biinternal.mycompany.com

biinternal.mycompany.comは、BIサービスの内部起動に使用される仮想サーバー名です。このURLはインターネットに公開されずに、イントラネットからのみアクセスできます。

クライアントからの入力トラフィックは、SSL対応ではありません。クライアントは、biinternal.mycompany.com:80のアドレスを使用してこのサービスにアクセスし、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。この仮想サーバーは、ロード・バランサ上に定義されます。

3.3 ロード・バランサの構成

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

このエンタープライズ・トポロジは外部のロード・バランサを使用します。第3.2項「トポロジで使用する仮想サーバー名について」で説明する仮想サーバー名を定義して、ロード・バランサを構成します。

第7.5項「仮想ホストの定義」のとおりに仮想ホストを構成すると、仮想ホスト名アドレスへのアクセスが可能になります。アクセスできない場合は、その手順が正しく完了していることを確認します。

ロード・バランサの詳細は、第2.1.3項「Web層ノードについて」を参照してください。

3.3.1 ロード・バランサの要件

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

  • 仮想ホスト名を介した実サーバー・プールへのトラフィックのロード・バランシング機能

    クライアントは、仮想ホスト名を使用して(実ホスト名を使用するかわりに)、サービスにアクセスします。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。

  • ポート変換の構成

    仮想ホスト名とポートにおける受信リクエストが、バックエンド・サーバーにある別のポートにダイレクトされるためには、この機能が必要です。

  • プールにあるサーバーのポートを監視してサービスの可用性を判定する機能

  • 仮想サーバー名とポートを構成する機能

    次の要件に注意してください。

    • ロード・バランサには複数の仮想サーバーを構成できる必要があります。ロード・バランサでは、仮想サーバーごとに複数のポートにおいてトラフィック管理の構成が可能である必要があります。たとえば、Web層のOracle HTTP Serverの場合、ロード・バランサは、HTTPとHTTPSのトラフィック用の仮想サーバーとポートで構成されている必要があります。

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

  • ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能

  • リソースの監視、ポートの監視、プロセス障害検出

    ロード・バランサは、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへの非Oracle Netトラフィックの送信を停止できる必要があります。外部ロード・バランサに障害の自動検出機能がある場合は、それを使用する必要があります。

  • フォルト・トレラント・モード

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

  • 仮想サーバーがコール元のクライアントに即座に戻るよう構成する機能

    トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようにロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。この構成は、クライアント・コンピュータのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりもお薦めされます。

  • スティッキーなルーティング機能

    スティッキーなルーティング機能とは、コンポーネントに対してスティッキーな接続を維持できる機能です。この例には、Cookieベースの永続性やIPベースの永続性などが含まれています。

  • SSLアクセラレーション

    ロード・バランサには、SSLリクエストをロード・バランサで終了して、同等の非SSLプロトコル(たとえば、HTTPSからHTTP)を使用してトラフィックを実際のバックエンド・サーバーに転送する機能が必要です。一般的にこの機能はSSLアクセラレーションと呼ばれ、このEDGで必要になります。

  • TCP接続の接続タイムアウト

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

  • クライアントIPアドレスを保持する機能

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

3.3.2 ロード・バランサの構成手順

この章で説明する手順には概要が含まれています。実行する必要がある実際の手順は、使用するロード・バランサのタイプによって異なります。詳細は、使用するロード・バランサのドキュメントを参照してください。

仮想サーバー名を定義してロード・バランサを構成する手順は次のとおりです。

  1. サーバーのプールを作成します。このプールを仮想サーバーに割り当てます。

  2. Oracle HTTP Serverホストのアドレスをプールに追加します。次に例を示します。

    • WEBHOST1:7777

    • WEBHOST2:7777

  3. ロード・バランサにbi.mycompany.com:443の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

    • この仮想サーバーでは、システムのフロントエンド・アドレスを仮想サーバーのアドレス(たとえば、bi.mycompany.com)として使用します。フロントエンド・アドレスは外部に公開されているホスト名で、システムで使用されるほか、インターネットに公開されます。

    • ポート80とポート443でこの仮想サーバーを構成します。ポート80(非SSLプロトコル)へのリクエストはすべてポート443(SSLプロトコル)に転送される必要があります。

    • HTTPをプロトコルとして指定します。

    • アドレスとポートの変換を有効にします。

    • サービスやノードが停止した場合に接続のリセットを有効にします。

    • 手順1で作成したプールを仮想サーバーに割り当てます。

    • この仮想サーバーの/console/emへのアクセスを除外するルールを作成します。

  4. ロード・バランサにadmin.mycompany.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

    • この仮想サーバーでは、内部管理アドレスを仮想サーバーのアドレス(たとえば、admin.mycompany.com)として使用します。このアドレスは一般的に外部化されません。

    • HTTPをプロトコルとして指定します。

    • アドレスとポートの変換を有効にします。

    • サービスやノードが停止した場合に接続のリセットを有効にします。

    • 必要に応じて、この仮想サーバーの/console/emのみへのアクセスを許可するルールを作成します。

    • ステップ1で作成したプールを仮想サーバーに割り当てます。

  5. ロード・バランサにbiinternal.mycompany.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

    • この仮想サーバーでは、内部管理アドレスを仮想サーバーのアドレス(たとえば、biinternal.mycompany.com)として使用します。このアドレスは一般的に外部化されません。

    • HTTPをプロトコルとして指定します。

    • アドレスとポートの変換を有効にします。

    • サービスやノードが停止した場合に接続のリセットを有効にします。

    • 手順1で作成したプールを仮想サーバーに割り当てます。

    • 必要に応じて、この仮想サーバーの/console/emへのアクセスを除外するルールを作成します。

  6. Oracle HTTP Serverノードに監視を構成してノードの障害を検出します。

    • /」のURLコンテキストに定期的にpingを実行するように監視を構成します。


      ヒント:

      Oracle HTTP Serverのドキュメント・ルートにindex.htmが存在せずにOracle WebLogic Serverで「/」の404エラーが返される場合は、かわりにGET /\n\nを使用してください。


    • ping実行間隔については、システムに負荷を与えないように値を指定します。とりあえず5秒で試してみることができます。

    • タイムアウト時間については、Oracle Business Intelligenceシステムで予測できる最長レスポンス時間に相当する値を指定します。つまり、HTTPサーバーへのリクエストに必要な最長所要時間より大きな値を指定します。

3.4 IPおよび仮想IPについて

表3-1では、様々な仮想ホストについて説明します。

表3-1 仮想ホスト

仮想IP VIPのマップ先 説明

VIP1

ADMINVHN

ADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名であり、管理サーバーの手動フェイルオーバーによりフェイルオーバーします。管理サーバーのプロセスが実行されているノード(デフォルトはAPPHOST1)で有効にされます。

VIP2

APPHOST1VHN1

APPHOST1VHN1は、bi_server1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、bi_server1プロセスが実行されているノード(デフォルトはAPPHOST1)で有効化されます。

VIP3

APPHOST2VHN1

APPHOST2VHN1は、bi_server2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、bi_server2プロセスが実行されているノード(デフォルトはAPPHOST2)で有効化されます。


3.4.1 APPHOST1上のADMINVHNの有効化

管理サーバーが1つのホストから別のホストにシームレスにフェイルオーバーできるよう、仮想IPアドレスをリスニングするよう構成する必要があります。障害時には、管理サーバーを仮想IPアドレスとともに1つのホストから別のホストに移行できます。

ただし、管理サーバーが仮想IPアドレスをリスニングするよう構成する前に、管理サーバーを実行しているホスト上のネットワーク・インタフェース・カードの1つが、この仮想IPアドレスをリスニングするよう構成されている必要があります。仮想IPアドレスを有効にする手順は、オペレーティング・システムによって完全に異なります。

APPHOST1上で仮想IPアドレスを有効にする手順は次のとおりです。UNIX環境では、rootユーザーとしてコマンドを実行する必要があります。

  1. APPHOST1でifconfigコマンドを実行し、ネットマスクの値を取得します。UNIX環境では、このコマンドをrootユーザーとして実行します。次に例を示します。

    [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
    
  2. APPHOST1で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
    
  3. 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およびAPPHOST2上の管理対象サーバーにおけるVIP2およびVIP3の有効化の詳細は、次の項を参照してください。

3.4.2 管理対象サーバーの仮想IPの有効化

BIドメインでは、Oracle Business Intelligenceの管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。これらのホスト名を2つのOracle BIコンピュータ(APPHOST1のVIP2とAPPHOST2のVIP3)にマップしてVIPを有効にする必要があります。またこれらのVIPが、トポロジで使用するネットワーク・システムの仮想ホスト名に(DNSサーバーまたはホスト解決によって)正しく解決されなければなりません。

管理対象サーバーで仮想IPアドレスをリスニングするよう構成する前に、管理対象サーバーを実行しているホスト上のネットワーク・インタフェース・カードのいずれかを、この仮想IPアドレスをリスニングするように構成する必要があります。

適切な仮想IPアドレス(APPHOST1のVIP2およびAPPHOST2のVIP3)が有効になるよう、各ホストで1回ずつ次の手順を実行します。UNIX環境では、rootユーザーとしてコマンドを実行する必要があります。

  1. 適切なホスト(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
    
  2. 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
    
  3. 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の有効化の詳細は、第3.4.1項「APPHOST1上のADMINVHNの有効化」を参照してください。

3.5 ファイアウォールとポートについて

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

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

表3-2には、Oracle Business Intelligenceトポロジで使用されるポートの一覧が記載されているほか、トポロジのファイアウォール上で開く必要のあるポートも記載されています。

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

表3-2 使用されるポート

タイプ ファイアウォール ポートとポート範囲 プロトコル/アプリケーション インバウンド/アウトバウンド その他の考慮事項とタイムアウトのガイドライン

ブラウザによるリクエスト

FW0

80

HTTP/ロード・バランサ

インバウンド

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

ブラウザによるリクエスト

FW0

443

HTTPS/ロード・バランサ

インバウンド

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

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

なし

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秒)に設定します。

BI Serverのアクセス

FW1

9704

HTTP/bi_servern

インバウンド

タイムアウトは、BIによって使用されるプロセス・モデルのタイプによって異なります。

BIクラスタ・メンバー間の通信

なし

9704

TCP/IPユニキャスト

なし

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

WebLogic Serverクラスタ内におけるセッション・レプリケーション

なし

なし

なし

なし

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

Oracle 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ポートの定義によって異なります。