| 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エンタープライズ・デプロイメントの計画を立てる場合は、この章を使用します。
この章には次のトピックが含まれます:
このドキュメントの手順とダイアグラムでは、バリエーションの適用が可能な参照用トポロジについて説明します。この項を使用してエンタープライズ・デプロイメント・トポロジを計画してください。
この項の項目は次のとおりです。
このドキュメントでは、図2-1に示すとおり、Oracle Business IntelligenceでOracle Access Managerを使用する参照用エンタープライズ・トポロジの構成手順について説明します。
Oracle Identity Managementシステムとの統合は、エンタープライズ・デプロイメント・アーキテクチャの重要な側面です。この統合により、シングル・サインオン、Oracle Platform Security Servicesとの統合、一元化されたアイデンティティおよび資格証明ストア、WebLogicドメインにおける認証などの機能が実現されます。IDM(Identity Management)エンタープライズ・デプロイメントは、このエンタープライズ・デプロイメントとは別であり、それ自体で別のドメイン内に存在します。エンタープライズ・デプロイメント環境におけるOracle Identity Managementの詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。
Oracle Identity Managementエンタープライズ・デプロイメントへの主要インタフェースは、LDAPサーバーへのLDAPトラフィック、OAMアクセス・サーバーへのOAP(Oracle Access Protocol)および認証リクエストのHTTPリダイレクトです。
Web層のノードはDMZパブリック・ゾーンにあります。
この層では、WEBHOST1とWEBHOST2という2つのノードが、Webゲートおよびmod_wl_ohsとともに構成されているOracle HTTP Serverを実行します。
Oracle HTTP Serverを、ロード・バランサと複数のWebLogic Server間の仲介ポイントとして使用した場合、次のようなメリットが得られます。
これは犠牲エリア/DMZを提供します。これはセキュリティ監査で求められる一般的な要件であり、ロード・バランサ/WebLogicシステムにおける大きな問題でもあります。ロード・バランサがWebLogic Serverに直接ルーティングされると、リクエストの移動がロード・バランサからアプリケーション層に1回のHTTPジャンプで行われるため、セキュリティ上の問題が生じます。
Webサーバー構成を変更することなく、WebLogic Serverクラスタ・メンバーシップを再構成(新規サーバーの追加とサーバーの削除)できます(構成したリスト内のサーバーのいくつかがアライブであることが条件)。プラグインはクラスタ・メンバーシップを学習し、それに応じて作業を振り分けます。
WebLogic Serverインスタンスで障害が発生した場合に、すぐにフェイルオーバーできます。プラグインは、障害が発生したWebLogic Serverインスタンスについて、ピアから得た情報を利用してアクティブに学習します。プラグインでは、障害の発生したサーバーについて、再び利用可能である旨の通知をピアから受けるまで回避を継続します。一般的にロード・バランサにはこれよりも多くの制限があります。
Oracle HTTP Serverは、WebLogic Serverよりも速く効率的に静的コンテンツを配信します。
WebLogic Serverで提供されているものを超えるHTTPリダイレクション。Oracle HTTP Serverは、多数の様々なWebLogic Serverクラスタのフロント・エンドとして使用できるほか、コンテンツ・ベースのルーティングも実現可能です。
SSOが必要な場合、Oracle Identity ManagementをサポートできるのはOracle HTTP Server (WebLogic 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のみが開いています。
このエンタープライズ・トポロジでは外部のロード・バランサを使用します。この外部ロード・バランサには、次の機能が必要です。
仮想ホスト名を介した実サーバー・プールへのトラフィックのロード・バランシング機能
クライアントは、仮想ホスト名を使用して(実ホスト名を使用するかわりに)、サービスにアクセスします。ロード・バランサは、リクエストをプールのサーバーにロード・バランスできるようになります。
ポート変換の構成
仮想ホスト名とポートにおける受信リクエストが、バックエンド・サーバーにある別のポートにダイレクトされるためには、この機能が必要です。
プールにあるサーバーのポートを監視してサービスの可用性を判定する機能
仮想サーバー名とポートを構成する機能
次の要件に注意してください。
ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。ロード・バランサでは、仮想サーバーごとに複数のポートにおいてトラフィック管理の構成が可能である必要があります。たとえば、Web層のOracle HTTP Serverの場合、ロード・バランサは、HTTPとHTTPSのトラフィック用の仮想サーバーとポートで構成されている必要があります。
仮想サーバー名は、IPアドレスに関連付けられていて、DNSの一部である必要がある。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。
ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能
フォルト・トレラント・モード
ロード・バランサをフォルト・トラレント・モードに構成することを強くお薦めします。
仮想サーバーがコール元のクライアントに即座に戻るよう構成する機能
トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようにロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。この構成は、クライアント・コンピュータのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりもお薦めされます。
スティッキーなルーティング機能とは、コンポーネントに対してスティッキーな接続を維持できる機能です。この例には、Cookieベースの永続性やIPベースの永続性などが含まれています。
SSLアクセラレーション
ロード・バランサはSSLリクエストをロード・バランサで終了して、同等の非SSLプロトコル(たとえば、HTTPSからHTTP)を使用してトラフィックを実際のバックエンド・サーバーに転送できる必要があります。一般的にこの機能はSSLアクセラレーションと呼ばれ、このEDGで必要になります。
アプリケーション層のノードはDMZセキュア・ゾーンにあります。
この層で、APPHOST1とAPPHOST2では、Oracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlが実行されますが、構成はアクティブ/パッシブです。管理サーバーは手動でフェイルオーバーできます(第8.5項「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つの管理対象サーバーでアクティブ/アクティブ構成で実行されます。
データ層のノードは、最もセキュアなネットワーク・ゾーン(イントラネット)に配置されます。
この層では、Oracle RACデータベースは、CUSTDBHOST1とCUSTDBHOST2のノードで実行されます。このデータベースには、Oracle Business Intelligenceコンポーネントが必要とするスキーマが含まれます。アプリケーション層で実行されるOracle Business Intelligenceコンポーネントはこのデータベースにアクセスします。
データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(一般的には1521)が開かれている必要があります。また、IDM EDGでLDAP記憶域にアクセスするトラフィックに対して、LDAPポート(一般的に、389と636)が開いている必要があります。
MyBICompanyトポロジにあるノードはユニキャストを使用して通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。
ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。
クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。
ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。
ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。
WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。
個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプの上書きはできません。
メッセージ・モードを変更(マルチキャストとユニキャストとの間における切替え)するには、クラスタ全体を停止してから再起動する必要があります。
マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。
クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。
JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。
エンタープライズ・デプロイメントをインストールして構成する前に、Oracle Technology Network (OTN)でOracle Fusion Middlewareのシステム要件と仕様に関するドキュメントを確認し、インストールする製品の最小インストール要件を満たす環境であることを確認します。
さらに、表2-1では、このガイドで説明されているエンタープライズ・デプロイメントの標準的なハードウェア要件でLinuxオペレーティング・システムに関するものを示しています。
適切なキャパシティ・プランニングを実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。
表2-2に、このガイドの手順を開始する前に入手しておく必要のあるOracleソフトウェアを示します。
Oracle Fusion Middlewareソフトウェアのダウンロードの詳細は、Oracle Technology Network (OTN)のOracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルを参照してください。
表2-2 コンポーネントおよびインストール・ソース
| コンポーネント | 詳細 |
|---|---|
|
Oracle Database 10gまたは11g |
Oracle Database(10gシリーズの場合は10.2.0.4以降、11gシリーズの場合は11.1.0.7以降) |
|
Repository Creation Utility(RCU) |
Oracle Fusion Middleware Repository Creation Utility 11g(11.1.1.1.0) |
|
Oracle WebLogic Server(WLS) |
Oracle Weblogic Server(10.3.6) |
|
Oracle HTTP Server |
Oracle Fusion Middleware WebTier and Utilities 11g(11.1.1.5.0) |
|
Oracle Business Intelligence |
Oracle Business Intelligence Enterprise Edition 11gパッチ(11.1.1.6.0) および Oracle Business Intelligence Enterprise Edition 11gパッチ(11.1.1.6.2) |
|
Oracle Access Manager 10g Webゲート または Oracle Access Manager 11g Webゲート |
Oracle Access Manager 10g Webゲート(10.1.4.3.0)、使用するプラットフォームに対応したOAM OHS 11g Webゲート Oracle Access Manager 11g Webゲート(11.1.1.5.0)、使用するプラットフォームに対応したOAM OHS 11g Webゲート |
|
Oracle Virtual Directory(OVD) |
Oracle Identity Management 11g(11.1.1.5.0) |
クラスタに参加しているすべてのサーバーにおけるクロックは、ジョブやアダプタが適切に機能できるように1秒以内の誤差で同期している必要があります。これを実現するには、ネットワーク・タイム・サーバーを1つ使用して、各サーバーがそのネットワーク・タイム・サーバーを参照するようにします。
ネットワーク・タイム・サーバーを参照させる手順は、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムのドキュメントを参照してください。
図2-3では、Oracle Business Intelligenceエンタープライズ・デプロイメント・プロセスの各手順が説明されています。この表では、処理における各ステップの詳細について、その参照先も示します。
図2-3 Oracle Business Intelligenceエンタープライズ・デプロイメント・プロセスの手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
エンタープライズ・デプロイメント用のネットワークの準備 |
仮想サーバー名、IP、仮想IPSなどの概念を理解し、仮想ホスト名を定義してロード・バランサを構成します。 |
第3章「エンタープライズ・デプロイメント用のネットワークの準備」 |
|
エンタープライズ・デプロイメント用のファイル・システムの準備 |
ディレクトリとディレクトリ環境変数の用語を確認し、共有記憶域を構成します。 |
第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」 |
|
エンタープライズ・デプロイメント用のデータベースの準備 |
データベース要件の確認、データベース・サービスの作成、Oracle RACデータベースへのOracle Business Intelligenceスキーマのロードおよびデータベースのバックアップを行います。 |
第5章「エンタープライズ・デプロイメント用のデータベースの準備」 |
|
エンタープライズ・デプロイメント用のソフトウェアのインストール |
Oracle HTTP Server、Oracle WebLogic ServerおよびOracle Fusion Middlewareをインストールします。 |
第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」 |
|
エンタープライズ・デプロイメント用のWeb層の構成 |
Oracle Web層とOracle WebLogic Domainとの関連付け、ロード・バランサの構成および仮想ホスト名の構成を行います。 |
第7章「エンタープライズ・デプロイメント用のWeb層の構成」 |
|
管理サーバーと最初の管理対象サーバーが含まれたドメインの作成 |
Oracle Business Intelligence Configuration Assistantを実行し、ドメインを作成して、構成後タスクと検証タスクを実行します。 |
第8章「管理サーバーと最初の管理対象サーバーが含まれたドメインの作成」 |
|
Oracle Business Intelligenceシステムのスケール・アウト |
BIシステムのスケーリングやシステム・コンポーネントのスケーリング、シングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成、さらに高可用性の追加構成の実行など、APPHOST2でOracle Business Intelligenceをスケール・アウトしてドメインを拡張します。 |
第9章「Oracle Business Intelligenceシステムのスケール・アウト」 |
|
ノード・マネージャの設定 |
ホスト名検証を有効化し、ノード・マネージャを起動し、カスタム・キーストアを使用してWebLogic Serverを構成することで、ノード・マネージャを設定します。 |
第10章「エンタープライズ・デプロイメント用のノード・マネージャの設定」 |
|
サーバー移行の構成 |
WLS_SOA1およびWLS_SOA2管理対象サーバーのサーバー移行を構成します。WLS_SOA1管理対象サーバーは障害時にSOAHOST2で再起動するように構成されます。WLS_SOA2管理対象サーバーは障害時にSOAHOST1で再起動するように構成されます。 |
第11章「エンタープライズ・デプロイメント用のサーバー移行の構成」 |
|
Oracle Identity Managementとの統合 |
資格証明ストアおよびポリシー・ストアを構成し、Oracle Access Manager 10gまたは11gと統合して、Identity Managementの構成をバックアップします。 |
第12章「エンタープライズ・デプロイメントとOracle Identity Managementの統合」 |
|
エンタープライズ・デプロイメントの管理 |
Oracle Business Intelligenceの起動と停止、エンタープライズ・デプロイメントの監視、スケーリングおよびパッチ適用、バックアップとリカバリの実行、さらにトラブルシューティング情報の確認について学習します。 |
|
