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

1 エンタープライズ・デプロイメントの概要

この章では、Oracle Business Intelligenceのエンタープライズ・トポロジの概要について説明します。


重要:

セットアップのプロセスを開始する前に、『Oracle Fusion Middlewareリリース・ノート』に目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。

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

1.1 エンタープライズ・デプロイメントとは

このエンタープライズ・デプロイメント・ガイドでは、可用性が高く、セキュアなOracle Business Intelligenceデプロイメントのために推奨されるベスト・プラクティスを示す構造計画を定義します。この計画で説明するベスト・プラクティスでは、テクノロジ・スタックから、Oracle Database、Oracle Fusion Middleware、およびOracle Enterprise Managerを含むOracle製品を利用しています。その結果実現するエンタープライズ・デプロイメントは、すぐにスケール・アウトして容量の拡張要求に対応できます。

特にOracle Business Intelligenceエンタープライズ・デプロイメントでは、次のとおりです。

高可用性を実現するためのプラクティスの詳細は、次を参照してください。

http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm


注意:

このドキュメントではLinux環境におけるエンタープライズ・デプロイメントを中心に説明していますが、エンタープライズ・デプロイメントは、UNIX環境やWindows環境でも実現できます。

1.2 用語

このドキュメントでは次の用語を使用します。

このエンタープライズ・デプロイメント・ガイドでは、この項で定義する用語以外に、Oracle Fusion MiddlewareおよびOracle WebLogic Serverの一般的な概念およびアーキテクチャを理解していることを前提としています。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

1.3 Oracle推奨事項のメリット

このドキュメントで説明するOracle Fusion Middleware構成は、すべての起動でセキュリティが確保され、ハードウェア・リソースが最大化され、信頼性が高く、標準に準拠したシステムをOracle Business Intelligenceに提供するために設計されています。

Oracle Fusion Middleware構成のセキュリティと高可用性のメリットは、ファイアウォール・ゾーンの分離とソフトウェア・コンポーネントのレプリケーションを通じて実現されます。

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

1.3.1 組込みセキュリティ

エンタープライズ・デプロイメント・アーキテクチャでは、ソフトウェア・コンポーネントのすべての機能グループが独自の非武装地帯(DMZ)に隔離されており、またプロトコルおよびポートによってすべてのトラフィックに制限がかけられているためセキュアです。DMZとは、外部サービスをより大規模な信頼されないネットワークに公開する境界ネットワークです。

次の特徴により、必要なすべてのレベルにおけるセキュリティの確保と、標準に対する高いレベルでの準拠が保証されています。

  • 外部のロード・バランサは、ポート80で受信した外部通信をすべてポート443にリダイレクトするように構成されています。


    注意:

    検証済ロード・バランサおよびその構成のリストは、Oracle Technology Networkの次の場所を参照してください。

    http://www.oracle.com/technology/products/ias/hi_av/Tested_LBR_FW_SSLAccel.html

  • 外部のクライアントからの通信はロード・バランシング・ルーターを超えたレベルでは発生しません。

  • ロード・バランシング・ルーターからデータ層への直接的な通信は許可されません。

  • コンポーネントは、Web層、アプリケーション層およびデータ層の異なる保護ゾーンで分離されています。

  • 一度に2つのファイアウォールをまたがる直接的な通信は禁止されています。

  • 1つのファイアウォール・ゾーンで通信が始まった場合、それは次のファイアウォール・ゾーンで終わる必要があります。

  • Oracle Internet Directoryはデータ層内で独立しています。

  • アイデンティティ管理コンポーネントは別のサブネットにあります。

  • 複数の保護ゾーンにおいて複数のコンポーネント間の通信はすべて、ファイアウォールのルールに従いポートとプロトコルによって制限されます。

1.3.2 高可用性

各コンポーネントまたはソフトウェア・コンポーネントの機能グループが別のコンピュータにレプリケートされており、コンポーネント・レベルでの高可用性を実現するように構成されます。このため、エンタープライズ・デプロイメント・アーキテクチャでは高い可用性が実現されます。

1.4 ハードウェア要件

Linuxオペレーティング・システム上のエンタープライズ・デプロイメントに対する標準的なハードウェア要件は、表1-1のとおりです。

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

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

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

データベース

4基以上のX Pentium(1.5GHz以上)

nXm

n: ディスクの台数(台数は4台以上で、1台のディスクはストライプ)

m: ディスクの容量(30GB以上)

6から8GB

デフォルト

デフォルト

WEBHOSTn

2基以上のX Pentium(1.5GHz以上)

10GB

4GB

デフォルト

デフォルト

APPHOSTn

1基のデュアルコア Pentium(2.8GHz以上)

20GB以上

8GB

デフォルト

デフォルト

1.5 エンタープライズ・デプロイメントの参照用トポロジ

このドキュメントの手順とダイアグラムでは、バリエーションの適用が可能な参照用トポロジについて説明します。

このドキュメントでは、図1-1に示すような、Oracle Business IntelligenceでOracle Access Managerを使用する参照用エンタープライズ・トポロジの構成手順を示します。

図1-1 Oracle Access Managerを使用したMyBICompanyトポロジ

図1-1の説明が続きます
「図1-1 Oracle Access Managerを使用したMyBICompanyトポロジ」の説明

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

1.5.1 Oracle Identity Management

Oracle Identity Managementシステムとの統合は、エンタープライズ・デプロイメント・アーキテクチャの重要な側面です。この統合により、シングル・サインオン、OPSSとの統合、一元化されたアイデンティティおよび資格証明ストア、WebLogicドメインにおける認証などの機能が実現されます。IDM (Identity Management) EDGはこのEDGから切り離されており、単独で別のドメインに存在します。エンタープライズ・デプロイメントにおけるアイデンティティ管理の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

IDM EDGへの主要インタフェースは、LDAPサーバーへのLDAPトラフィック、OAMアクセス・サーバーへのOAP(Oracle Access Protocol)および認証リクエストのHTTPリダイレクトです。

1.5.2 Web層

Web層のノードはDMZパブリック・ゾーンにあります。

この層では、WEBHOST1とWEBHOST2という2つのノードが、Webゲートおよびmod_wl_ohsとともに構成されているOracle HTTP Serverを実行します。

Oracle HTTP ServerからOracle WebLogic Serverへのリクエストのプロキシを許可するmod_wl_ohsを通じて、Oracle HTTP Serverはアプリケーション層で実行されているOracle WebLogic Serverにリクエストを転送します。

Oracle HTTP ServerにあるWebゲート(Oracle Access Managerコンポーネント)はOracle Access Protocol(OAP)を使用して、アイデンティティ管理DMZ内のOAMHOST2で実行されているOracle Access Managerと通信します。WebゲートとOracle Access Managerは、ユーザー認証などの操作を実行するために使用されます。

Web層には外部リクエストを処理するロード・バランサ・ルーターも含まれています。外部リクエストは、ロード・バランサで構成されている仮想ホスト名に送信されます。ロード・バランサは、このリクエストをOracle HTTP Serverに転送します。

Oracle HTTP Server内のWebGateモジュールは、Oracle Access Protocol(OAP)を使用してOracle Access Managerと通信し、ユーザー・グループへの問合せなどの操作を実行します。

Web層を保護しているファイアウォールでは、HTTPポート、つまりHTTPS用のポート443とHTTP用のポート80のみが開いています。

1.5.2.1 ロード・バランサ要件

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

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

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

  • ポート変換の構成

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

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

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

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

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

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

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

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

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

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

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

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

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

  • SSLアクセラレーション

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

1.5.3 アプリケーション層

アプリケーション層のノードはDMZセキュア・ゾーンにあります。

APPHOST1とAPPHOST2は、Oracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlを実行しますが、構成はアクティブ/パッシブです。管理サーバーは手動でフェイルオーバーできます(第5.14項「APPHOST2への管理サーバーの手動フェイルオーバー」を参照)。またそのかわりに、管理コンソールをCFC/CRSで構成して、自動で別のハードウェア・クラスタでフェイルオーバーすることもできます(このアーキテクチャでは記載されていません)。

Oracle Business Intelligence Cluster ControllerおよびOracle BI Schedulerシステム・コンポーネントはアクティブ/パッシブ構成でAPPHOST1およびAPPHOST2上で実行されます。その他のOracle Business Intelligenceシステム・コンポーネントであるOracle BI Server、Oracle BI JavaHost、およびOracle BI Presentation Servicesはアクティブ/アクティブ構成でAPPHOST1およびAPPHOST2で実行されます。すべてのシステム・コンポーネントはOPMNによって管理されており、管理対象サーバーでは実行されません。

Oracle Real-Time Decisions、Oracle BI Publisher、Oracle BI for Microsoft OfficeおよびOracle BI Enterprise Edition AnalyticsアプリケーションなどのOracle Business Intelligence Javaコンポーネントは、APPHOST1およびAPPHOST2の2つの管理対象サーバーで実行されます。Oracle Web Services Manager(Oracle WSM)は、EDGトポロジでWebサービスを管理し、保護するためのポリシー・フレームワークを提供するもう1つのJavaコンポーネントです。WSMポリシー・マネージャはAPPHOST1およびAPPHOST2の2つの管理対象サーバーでアクティブ/アクティブ構成で実行されます。

1.5.4 データ層

データ層のノードは、最もセキュアなネットワーク・ゾーン(イントラネット)に配置されます。

この層では、Oracle RACデータベースは、CUSTDBHOST1とCUSTDBHOST2のノードで実行されます。このデータベースには、Oracle Business Intelligenceコンポーネントが必要とするスキーマが含まれます。アプリケーション層で実行されるOracle Business Intelligenceコンポーネントはこのデータベースにアクセスします。

データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(一般的には1521)が開かれている必要があります。また、IDM EDGでLDAP記憶域にアクセスするトラフィックに対して、LDAPポート(一般的に、389と636)が開いている必要があります。

1.5.5 インストールするコンポーネント

各ソフトウェア・コンポーネントのインストール・ソースは、表1-2のとおりです。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。

表1-2 コンポーネントおよびインストール・ソース

コンポーネント 配布メディア

Oracle Database 10gまたは11g

Oracle DatabaseのCD(10gシリーズの場合は10.2.0.4以降、11gシリーズの場合は11.1.0.7以降)

リポジトリ作成ユーティリティ(RCU)

Oracle Fusion Middleware Repository Creation Utility 11g(11.1.1.1.0)のDVD

Oracle WebLogic Server(WLS)

Oracle Weblogic Server(10.3.1)のDVD

Oracle HTTP Server

Oracle Fusion Middleware WebTier and Utilities 11g(11.1.1.1.0)のDVD

Oracle Business Intelligence

Oracle Business Intelligence 11g(11.1.1.5.0)DVD

Oracle Access Manager 10g Webゲート

Oracle Access Manager 10g Webゲート(10.1.4.3.0)のDVD、使用するプラットフォームに対応したOAM OHS 11g Webゲート

Oracle Virtual Directory(OVD)

Oracle Identity Management 11g(11.1.1.1.0)のDVD

1.5.6 ユニキャスト要件

MyBICompanyトポロジにあるノードはユニキャストを使用して通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。

ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。

  • WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。

  • 個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプの上書きはできません。

  • メッセージ・モードを変更(マルチキャストとユニキャストとの間における切替え)するには、クラスタ全体を停止してから再起動する必要があります。

  • マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。

    • クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。

    • JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引