Oracle® Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1.8.3) B55900-10 |
|
前 |
次 |
この章では、Oracle WebCenter Portalのエンタープライズ・トポロジの概要を示します。
この章には次のトピックが含まれます:
この項では、WebCenter Portalのエンタープライズ・トポロジについて説明します。この項を使用してエンタープライズ・デプロイメント・トポロジを計画してください。
この項の項目は次のとおりです。
このマニュアルでは、図2-1に示す、Oracle WebCenter PortalでOracle Access Managerを使用する参照用エンタープライズ・トポロジの構成手順を示します。
注意: エンタープライズ・デプロイメントの実際のトポロジでは、このガイドで説明するトポロジの一部変更が必要な場合もあります。 |
図2-1 Oracle Access Managerを使用したMyWCPCompanyトポロジ
Oracle Identity Managementシステムとの統合は、エンタープライズ・デプロイメント・アーキテクチャの重要な側面です。この統合により、シングル・サインオン、Oracle Platform Security Servicesとの統合、一元化されたアイデンティティおよび資格証明ストア、WebLogicドメインにおける認証などの機能が実現されます。Oracle Identity Management (IDM)エンタープライズ・デプロイメントはこのエンタープライズ・デプロイメントとは別であり、それ自体で別のドメイン内に存在します。エンタープライズ・デプロイメントにおけるOracle Identity Managementの詳細は、Oracle Fusion MiddlewareのOracle Identity Managementアプリケーション・エンタープライズ・デプロイメント・ガイドを参照してください。
Oracle Identity Managementエンタープライズ・デプロイメントへの主要インタフェースは、LDAPサーバーへのLDAPトラフィック、OAMアクセス・サーバーへのOAP (Oracle Access Protocol)および認証リクエストのHTTPリダイレクトです。
Web層のノードはDMZパブリック・ゾーンにあります。この層では、2つのノード(WEBHOST1とWEBHOST2)が、WebGateおよび*_vh.conf
ファイルとともに構成されているOracle HTTP Serverを実行します。
Oracle HTTP ServerからWebLogic Serverへのリクエストのプロキシを許可する*_vh.conf
ファイルを通じて、Oracle HTTP Serverはアプリケーション層で実行されているWebLogic Serverにリクエストを転送します。
Oracle HTTP ServerにあるWebゲート(Oracle Access Managerコンポーネント)はOracle Access Protocol (OAP)を使用して、Oracle Identity Management DMZ内のOAMHOST2で実行されているOracle Access Managerと通信します。WebGateとOracle Access Managerは、ユーザー認証などの操作を実行するために使用されます。Oracle HTTP Server内のWebGateモジュールは、Oracle Access Protocol (OAP)を使用してOracle Access Managerと通信し、ユーザー・グループへの問合せなどの操作を実行します。
Web層には外部リクエストを処理するロード・バランサ・ルーターも含まれています。外部リクエストは、ロード・バランサで構成されている仮想ホスト名に送信されます。ロード・バランサは、このリクエストをOracle HTTP Serverに転送します。
Web層を保護しているファイアウォールでは、HTTPポート、つまりHTTPS用のポート443とHTTP用のポート80のみが開いています。
このエンタープライズ・トポロジは外部のロード・バランサを使用します。この外部ロード・バランサには、次の機能が必要です。
仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。
ポート変換構成が可能である必要があります。これによって、仮想ホスト名とポートにおける入力リクエストが、バックエンド・サーバーにある別のポートにリダイレクトされます。
プールにあるサーバーのポートを監視してサービスの可用性を判定する機能。
仮想サーバーとポートの構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。さらに、仮想サーバー名とポートは次の要件を満たしている必要があります。
ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、Web層のOracle HTTP Serverの場合、ロード・バランサでは、HTTPとHTTPSのトラフィックに対して仮想サーバーとポートで構成されている必要があります。
仮想サーバー名は、IPアドレスに関連付けられていて、DNSの一部であることが必要です。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。
ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。
フォルト・トレラント・モード: ロード・バランサをフォルト・トレラント・モードに構成することを強くお薦めします。
トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようにロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。これは、クライアント・マシンのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断するより望ましい方法です。
スティッキーなルーティング機能: コンポーネントに対してスティッキーな接続を維持できる機能です。この例には、Cookieベースの永続性やIPベースの永続性などが含まれています。
ロード・バランサはSSLリクエストをロード・バランサで終了して、同等の非SSLプロトコル(たとえば、HTTPSからHTTP)を使用してトラフィックを実際のバックエンド・サーバーに転送できる必要があります。この機能は一般にSSLの高速化と呼ばれ、このエンタープライズ・デプロイメントで必要になります。
注意: ロード・バランサは、外部向けのURLを介した、すべてのクライアント・リクエストのエントリ・ポイントです。同じように構成されている内部URLは、クライアントが一般的に使用することを意図したものではなく、内部での使用用です。WebCenter Portalエンタープライズ・デプロイメント・トポロジでは、内部/外部設定はサポートしていません。 |
ロード・バランサの構成方法の詳細は、第3.3項「ロード・バランサの構成」を参照してください。
アプリケーション層のノードはDMZセキュア・ゾーンにあります。
この層では、SOAHOST1とSOAHOST2の2つのノードが、Oracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlを実行しますが、構成はアクティブ/パッシブです。管理サーバーは、手動でフェイルオーバーすることも(第8.7.6項「管理サーバーの手動フェイルオーバーの検証」を参照)、Oracle WebLogic Server管理コンソールをCFC/CRSで構成して、自動で別のハードウェア・クラスタにフェイルオーバーすることもできます(このアーキテクチャでは記載されていません)。
Oracle WebCenter Portalコンポーネントは、アクティブ/アクティブ構成で、WCPHOST1とWCPHOST2上で実行されます。一般的に管理対象サーバーはWC_Spaces (すぐに使用可能なWebCenter Portalアプリケーション用)、WC_Portlet (ポートレットとページレット・プロデューサ用)、WC_Collaboration (ディスカッション用)、WC_Utilities (分析、アクティビティ・グラフ、パーソナライズ用)と呼ばれます。カスタムの管理対象サーバーを作成して、JDeveloperを使用して構築されたWebCenter Portal Frameworkアプリケーションを実行することもできます。
WCPHOST1とWCPHOST2では、Oracle WebCenter Content Serverも実行され、アクティブ/アクティブ構成で構成されています。
このトポロジでSOAコンポーネントも実行している場合、SOAHOST1とSOAHOST2は、SOAコンポーネントを実行する管理対象サーバーWLS_SOAおよびWLS_WSMとともに構成されているWebLogic Serverを実行します。これらのコンポーネントはアクティブ/アクティブ構成です。
Oracle Web Services Manager (Oracle WSM)は、エンタープライズ・デプロイメント・トポロジにおけるWebサービスの管理と保護を目的としたポリシー・フレームワークを提供します。また、WSMのポリシー・マネージャでは、さらに2台のWebLogic Serverでアクティブ/アクティブ構成で実行されます。
アプリケーション層を保護しているファイアウォールでは、HTTPポート、OAPポートおよびプロキシ・ポートが開きます。OAPポートは、Web層のOracle HTTP Serverで実行されているWebGateモジュールがOracle Access Managerと通信するためのものです。外部のHTTPアクセスが必要なアプリケーションでは、Oracle HTTP Serverがプロキシとして使用されます。Oracle HTTP Server上のプロキシが有効にされて、このアクセスが許可される必要があります。
データ層のノードは、最もセキュアなネットワーク・ゾーン(イントラネット)に配置されます。
この層では、Oracle RACデータベースがCUSTDBHOST1とCUSTDBHOST2のノードで実行されます。このデータベースには、WebCenter Portal、WebCenter Content、SOA Suiteコンポーネントに必要なスキーマが含まれています。アプリケーション層で実行される、WebCenter Portal、WebCenter Content、およびSOAコンポーネントがこのデータベースにアクセスします。
データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(一般的には1521)が開かれている必要があります。また、IDMエンタープライズ・デプロイメントでLDAP記憶域にアクセスするトラフィックに対して、LDAPポート(一般的には389および636)が開いている必要があります。
MyWCPCompanyトポロジ内のノードでは、ユニキャストを使用し通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。
ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。
クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。
ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。
ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。
WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。
個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプのオーバーライドはできません。
メッセージ・モードを変更(マルチキャストとユニキャストとの間における切替え)するには、クラスタ全体を停止してから再起動する必要があります。
マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。
クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。
JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。
エンタープライズ・デプロイメントをインストールして構成する前に、Oracle Technology Network (OTN)でOracle Fusion Middlewareのシステム要件と仕様に関するドキュメントに目を通して、インストールする製品の最小インストール要件を環境が満たしていることを確認します。
さらに、表2-1では、このガイドで説明されているエンタープライズ・デプロイメントの標準的なハードウェア要件でLinuxオペレーティング・システムに関するものを示しています。
適切なキャパシティ・プランニングを実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。これは、使用される各WebCenter PortalアプリケーションまたはカスタムSOAシステムによって異なります。
表2-1 標準ハードウェア要件
サーバー | ディスク | メモリー | TMPディレクトリ | スワップ |
---|---|---|---|---|
データベース |
nXm n: ディスクの台数(台数は4台以上で、1台のディスクはストライプ) m: ディスクの容量(30GB以上) |
6 - 8GB |
デフォルト |
デフォルト |
WEBHOSTn |
10GB |
4GB |
デフォルト |
デフォルト |
SOAHOSTn |
10GB脚注 1 |
10GB |
デフォルト |
デフォルト |
WCPHOSTn |
10GB |
10GB |
デフォルト |
デフォルト |
脚注 1 共有記憶域のミドルウェア・ホーム構成の場合、2つのインストールでは、スロット数と関係なく合計20GBになるようにすると十分です。第4.4項「共有記憶域の構成」を参照してください。
Oracle Fusion Middlewareでは、WebLogicドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、XMLファイルまたは様々なタイプのLDAPプロバイダに基づいてストアを使用できます。ドメインがLDAPストアを使用する場合は、ポリシーと資格証明のデータはすべて、集中管理されたストアで保持および保守されます。ただし、XMLポリシー・ストアを使用している場合、管理対象サーバーへの変更は、同じドメイン・ホームを使用していなければ管理サーバーには伝播されません。
注意: ドメイン・ホームは、サーバーが実行される物理ディレクトリ( |
Oracle Fusion Middleware WebCenter Portalのエンタープライズ・デプロイメント・トポロジでは、第4章「異なるディレクトリの推奨場所」の説明のとおり、管理サーバーと管理対象サーバーに対して異なるドメイン・ホームが使用されます。そのため、整合性と一貫性を保持するため、Oracle Fusion Middleware WebCenter Portalのエンタープライズ・デプロイメント・トポロジのコンテキストでは、LDAPをポリシー・ストアおよび資格証明ストアとして使用する必要があります。
LDAPを資格証明およびポリシー・ストアとしてWebCenter Portalエンタープライズ・デプロイメント・トポロジに構成するには、第15.2項「資格証明ストアの構成」および第15.3項「ポリシー・ストアの構成」の手順を実行します。
ジョブ、アダプタおよびOracle B2Bを正常に機能させるため、クラスタに参加するすべてのサーバーのクロックを同期させ、クロックの時間差を1秒以内に収める必要があります。これを実現するには、ネットワーク・タイム・サーバーを1つ使用して、各サーバーがそのネットワーク・タイム・サーバーを参照するようにします。
ネットワーク・タイム・サーバーを参照させる手順は、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムのドキュメントを参照してください。
表2-2に、このガイドの手順を開始する前に入手しておく必要のあるOracleソフトウェアを示します。
Oracle Fusion Middlewareソフトウェアのダウンロードの詳細は、Oracle Technology Network (OTN)のOracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルを参照してください。
『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』も参照してください。
表2-2 コンポーネントおよびインストール・ソース
コンポーネント | 配布メディア |
---|---|
Oracle Database 10gまたは11g |
AL32UTF8文字セットを使用するOracle Database 10gディストリビューション(データベース10.2.0.4以降のSEまたはEEバージョン) AL32UTF8文字セットを使用するOracle Database Server 11gディストリビューション(データベース11.1.0.7以降のSEまたはEEバージョン)
|
Repository Creation Utility (RCU) |
Oracle Fusion Middleware Repository Creation Utility 11g (11.1.1.8)ディストリビューション |
Oracle WebLogic Server (WLS) |
Oracle WebLogic Server (10.3.6)ディストリビューション |
Oracle HTTP Server (OHS) |
Oracle Fusion Middleware WebTier and Utilities 11g (11.1.1.7)ディストリビューション |
Oracle SOA Suite |
Oracle SOA Suite 11g (11.1.1.7)ディストリビューション |
Oracle WebCenter Portal |
Oracle WebCenter Portal 11g (11.1.1.8)のディストリビューション |
Oracle WebCenter Content |
Oracle WebCenter Content 11g (11.1.1.8)ディストリビューション |
Oracle Access Manager (OAM) WebGate |
WebGate 10g (10.1.4.3) for OAM 10gまたはWebGate 11g (11.1.1.7) for OAM 11g。 |
Oracle Virtual Directory (OVD) |
Oracle Identity and Access Management 11g (11.1.2.0)ディストリビューション |
Oracle Internet Directory (OID) |
Oracle Identity and Access Management 11g (11.1.2.0)ディストリビューション |
Oracle WebCenter Portalエンタープライズ・デプロイメントを開始する前に、図2-2のフロー・チャートを参照してください。このフロー・チャートは、このガイドで説明するエンタープライズ・デプロイメントを完成させるための大まかなプロセスを示しています。表2-3はこのフロー・チャート内の手順を説明するものであり、ここから各手順の項または章にジャンプできます。
この項の内容は次のとおりです。
図2-2に、Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスのフロー・チャートを示します。このチャートを確認し、既存の環境に基づいた実行手順を理解してください。
図2-2 Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスのフロー・チャート
表2-3では、図2-2に示す、Oracle WebCenter Portalのエンタープライズ・デプロイメント・プロセスのフロー・チャートの各手順を示します。この表では、処理における各ステップの詳細について、その参照先も示します。
表2-3 Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスの手順
手順 | 説明 | 詳細 |
---|---|---|
エンタープライズ・デプロイメント用のネットワークの準備 |
エンタープライズ・デプロイメント用のネットワークを準備するには、仮想サーバー名、IP、仮想IPSなどの概念を理解し、仮想ホスト名を定義してロード・バランサを構成する必要があります。 |
第3章「エンタープライズ・デプロイメント用のネットワークの準備」 |
エンタープライズ・デプロイメント用のファイル・システムの準備 |
エンタープライズ・デプロイメント用のファイル・システムを準備するには、ディレクトリおよびディレクトリ環境変数の用語を理解し、共有記憶域を構成する必要があります。 |
第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」 |
エンタープライズ・デプロイメント用のデータベースの準備 |
エンタープライズ・デプロイメント用のデータベースを準備するには、データベース要件の確認、データベース・サービスの作成、Oracle RACデータベースへのメタデータ・リポジトリのロード、トランザクション・リカバリ権限用のSOA、WCPおよびWCCスキーマの構成ならびにデータベースのバックアップを実行します。 |
第5章「エンタープライズ・デプロイメント用のデータベースの準備」 |
エンタープライズ・デプロイメント用のソフトウェアのインストール |
Oracle HTTP Server、Oracle WebLogic ServerおよびOracle Fusion Middlewareをインストールし、Oracle Fusion Middlewareコンポーネントにパッチ・セットを適用します。 |
第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」 |
エンタープライズ・デプロイメント用のWeb層の構成 |
ロード・バランサを使用してOracle HTTPサーバーを構成し、仮想ホスト名を構成します。 |
第7章「エンタープライズ・デプロイメント用のWeb層の構成」 |
エンタープライズ・デプロイメント用のドメインの作成 |
構成ウィザードを起動してドメインを作成します。 |
第8章「エンタープライズ・デプロイメント用のドメインの作成」 |
SOAのためのドメインの拡張 |
構成ウィザードを実行してOracle SOAコンポーネントを構成し、既存のWebLogicドメインを拡張します。 |
第9章「SOAコンポーネントを使用するためのドメインの拡張」 |
WebCenter Portalコンポーネントを使用するためのドメインの拡張 |
構成ウィザードを実行して既存のWebLogicドメインを拡張し、Oracle WebCenter Portalを構成します。 |
第10章「WebCenter Portalコンポーネントを使用するためのドメインの拡張」 |
ノード・マネージャの設定 |
ホスト名検証を有効化し、ノード・マネージャを起動して、カスタム・キーストアを使用するようにWebLogic Serverを構成し、ノード・マネージャを設定します。 |
第11章「エンタープライズ・デプロイメント用のノード・マネージャの設定」 |
WebCenter Portalの外部サービスの構成 |
ディスカッション、メール、検索などのWebCenter Portalアプリケーションの外部サービスを設定および構成します。 |
第12章「エンタープライズ・デプロイメントにおけるWebCenter Portalの外部ツールおよびサービスの構成」 |
WebCenter Contentを使用するためのドメインの拡張 |
構成ウィザードを実行して既存のWebLogicドメインを拡張し、Content ServerとInbound Refineryを構成します。 |
第13章「Oracle WebCenter Contentを追加するためのドメインの拡張」 |
サーバー移行の構成 |
WLS_SOA1およびWLS_SOA2管理対象サーバーのサーバー移行を構成します。WLS_SOA1管理対象サーバーは障害時にSOAHOST2で再起動するように構成されます。WLS_SOA2管理対象サーバーは障害時にSOAHOST1で再起動するように構成されます。 |
第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」 |
Oracle Identity Managementとの統合 |
Oracle SOAエンタープライズ・デプロイメントとOracle Identity Management 10gまたは11gを統合できます。 |
第15章「エンタープライズ・デプロイメントとOracle Identity Managementの統合」 |
このドキュメントではインクリメンタルなモジュラ・アプローチでエンタープライズ・デプロイメントの設定方法を説明しています。
記憶域、データベース、ネットワーキングおよびWeb層インフラストラクチャの設定手順は、その他のOracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドで説明している手順とほぼ同じです。これらのトポロジ要素は、この後の手順で構成するOracle WebLogic Serverドメインの基盤となるもので、このドメインがエンタープライズ・デプロイメントの土台となります。
ドメインの作成手順はガイドによって異なります。しかし、どのエンタープライズ・デプロイメント・ガイドでも、Oracle WebLogic Serverドメインの作成方法と拡張方法を次のようなモジュラの手順で説明しています。
Oracle Fusion Middlewareソフトウェアをディスクにインストールし、必要なバイナリ・ディレクトリを作成します。
Oracle Fusion Middleware構成ウィザードを実行してドメインを作成し、管理コンポーネントのみを構成します。
管理コンポーネントには、管理サーバー、Oracle WebLogic Server管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Web Services Managerが含まれます。
構成ウィザードを再度実行し、使用する主なOracle Fusion Middleware製品を追加するためドメインを拡張します。
オプションで、構成ウィザードを再度実行して、その他のサポート・コンポーネントおよび製品を追加するためにドメイン拡張します。
このインクリメンタルなアプローチに従うことで、構成ウィザードの各ステップ後に環境を確認できます。また、セットアップ・プロセス中のトラブルシューティングが容易になります。
さらに、このモジュラ・アプローチでは代替トポロジの検討が可能になります。これは特に、管理コンポーネントの構成後、このガイドに記述されているコンポーネントをすべてドメインに含める必要がないことが判明したような場合です。この場合は、ドメイン拡張に関する章を個々に選択して参照し、組織で必要とされるコンポーネントを構成します。