| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-04 |
|
前 |
次 |
この章では、このガイドで使用するエンタープライズ・デプロイメントの参照用トポロジについて具体的に説明します。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からWebLogic Serverへのリクエストのプロキシを許可するmod_wl_ohsを通じて、Oracle HTTP Serverはアプリケーション層で実行されている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のみが開いています。
アプリケーション層のノードはDMZセキュア・ゾーンにあります。
この層で、APPHOST1とAPPHOST2では、Oracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlが実行されますが、構成はアクティブ/パッシブです。管理サーバーは手動でフェイルオーバーできます(第13.5項「APPHOST2への管理サーバーの手動フェイルオーバー」を参照)。その一方で、管理コンソールをCFC/CRSで構成し、別のハードウェア・クラスタで自動フェイルオーバーすることもできます(このアーキテクチャでは示されていません)。
Oracle Business Intelligence Cluster Controller、Oracle BI SchedulerおよびOracle Essbase Serverシステム・コンポーネントはアクティブ/パッシブ構成で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 Presentation Services Plug-in(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つの管理対象サーバーでアクティブ/アクティブ構成で実行されます。
リリース11.1.1.7から、Oracle Hyperion Smart View for Office(Smart View)は、Microsoft Office製品からOracle Business IntelligenceおよびEnterprise Performance Managementコンテンツにアクセスして統合するための包括的ツールとして、Oracle BI Add-in for Microsoft Officeを置き換えます。Smart Viewは、Oracle Business IntelligenceおよびOracle Enterprise Performance Management用に設計された共通のMicrosoft Officeインタフェースを提供します。
データ層のノードは、最もセキュアなネットワーク・ゾーン(イントラネット)に配置されます。
この層では、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) |
Oracle Fusion Middlewareでは、WebLogicドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、XMLファイルまたは様々なタイプのLDAPプロバイダに基づいてストアを使用できます。ドメインでLDAPストアを使用する場合は、すべてのポリシー・データと資格証明データが、一元化されたストアで保持および管理されます。ただし、XMLポリシー・ストアを使用すると、管理対象サーバー上で行われる変更は、管理サーバーに伝播されません(両方のサーバーが同じドメイン・ホームを使用していない場合)。
Oracle Business Intelligenceエンタープライズ・デプロイメント・トポロジでは、第4.3項「各種ディレクトリの推奨場所について」の記載のとおり、管理サーバーおよび管理対象サーバー用に異なるドメイン・ホームが使用されています。その結果、整合性と一貫性を保持するために、Oracle Business Intelligenceエンタープライズ・デプロイメント環境では、資格証明ストアとポリシー・ストアとしてLDAPストアを使用する必要があります。LDAPストアを資格証明ストアおよびポリシー・ストアとして使用するようにOracle Business Intelligenceエンタープライズ・デプロイメントを構成するには、第12.1項「資格証明ストアとポリシー・ストアの構成」の手順に従います。
クラスタに参加しているすべてのサーバーのクロックは、ジョブやアダプタが適切に機能できるように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の起動と停止、エンタープライズ・デプロイメントの監視、スケーリングおよびパッチ適用、バックアップとリカバリの実行、さらにトラブルシューティング情報の確認について学習します。 |
|
