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

この章では、Oracle WebCenterのエンタープライズ・トポロジの概要を示します。この章の項目は次のとおりです。

• 第1.1項「エンタープライズ・デプロイメントとは」

• 第1.2項「用語」

• 第1.3項「Oracle推奨事項のメリット」

• 第1.4項「ハードウェア要件」

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

• 第1.6項「このガイドの使用方法」

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

エンタープライズ・デプロイメントは、Oracle Fusion Middlewareの実証済高可用性テクノロジ、セキュリティ・テクノロジおよび推奨事項に基づいたベスト・プラクティスの青写真です。これらの青写真に示すベスト・プラクティスは、技術スタック全体においてすべてのOracle製品を対象にしています。それらの製品には、Oracle Database、Oracle Fusion Middleware、Oracle Applications、Oracle Collaboration Suite、Fusion Middleware Controlがあります。

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

• 様々な業務のサービス・レベル合意（SLA）を考慮して、高可用性ベスト・プラクティスをできるだけ広範囲に適用できるようにします。

• データベース・グリッド・サーバーと低コストのストレージを使用したストレージ・グリッドを活用し、回復力に優れ低コストのインフラストラクチャを提供します。

• 様々な構成を対象として広範囲なパフォーマンス影響調査の結果を利用し、ビジネス・ニーズに応じて実行およびスケールできるように高可用性アーキテクチャが最適に構成されます。

• 停止状態からのリカバリ時間と自然災害時に許容可能なデータ損失量を制御できます。

• ベスト・プラクティスと推奨アーキテクチャが使用されます。それらは、ハードウェアとオペレーティング・システムには依存していません。

高可用性ベスト・プラクティスの詳細は、http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmのWebサイトを参照してください。

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

1.2 用語

この項では、以前のリリースのコンポーネントに使用されていた用語と、リリース11g（11.1.1）における対応する用語について説明します。

• Oracleホーム: Oracleホームには、特定の製品をホストするために必要な、インストール済のファイルが含まれています。たとえば、SOAのOracleホームには、Oracle SOA Suiteのバイナリとバイナリ・ファイルが格納されているディレクトリがあります。Oracleホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。各Oracleホームは、複数のOracleインスタンスやOracle WebLogic Serverドメインと関連付けることができます。

• WebLogic Serverホーム: WebLogic Serverホームには、WebLogic Serverをホストするために必要な、インストール済のファイルが含まれています。WebLogic Serverホームのディレクトリは、Oracleホームのディレクトリのピアで、ミドルウェア・ホームのディレクトリ構造の内部にあります。

• ミドルウェア・ホーム: ミドルウェア・ホームは、Oracle WebLogic Serverホームと、オプションとして1つまたは複数のOracleホームで構成されます。ミドルウェア・ホームは、ローカル・ファイル・システムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。

• Oracleインスタンス: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどの、1つ以上のアクティブなミドルウェア・システム・コンポーネントが含まれます。インストール時かその後でインスタンスの作成と構成を行うときに、インスタンスにどのコンポーネントを含めるかを決定しますOracleインスタンスには、更新可能なファイルがあります。それらのファイルの例には、構成ファイル、ログ・ファイル、一時ファイルなどがあります。

• フェイルオーバー: 高可用性システムのメンバーで、障害（計画外停止時間）が突然発生した場合、システムでは、コンシューマへのサービスの提供を続けるために、フェイルオーバー操作が実行されます。システムがアクティブ/パッシブ型システムの場合、パッシブ・メンバーはフェイルオーバー操作においてアクティブになります。そしてコンシューマは、障害が発生したメンバーではなく、アクティブになったメンバーにリダイレクトされます。フェイルオーバー操作は、手動でも実行できます。また、障害を検出した場合にクラスタのリソースを障害ノードからスタンバイ・ノードに移動するように、ハードウェア・クラスタ・サービスを設定することで、フェイルオーバー操作を自動化することもできます。システムがアクティブ/アクティブ型システムの場合、ロード・バランサのエンティティによりフェイルオーバーが実行されます。このエンティティによって、リクエストがアクティブ・メンバーで処理されます。アクティブ・メンバーに障害が発生すると、ロード・バランサにより障害が検出され、障害メンバーへのリクエストが、正常に動作しているアクティブ・メンバーに自動的にリダイレクトされます。アクティブ/アクティブ型システムとアクティブ/パッシブ型システムの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

• フェイルバック: システムのフェイルオーバー操作が正常に終了した後、最初に障害を起こしたメンバーは修復され、スタンバイ・メンバーとしてシステムに再導入されます。必要に応じて、フェイルバック処理を開始して、このメンバーをアクティブにし、別のメンバーを非アクティブにすることができます。この処理によりシステムは、障害発生前の構成に戻ります。

• ハードウェア・クラスタ: ハードウェア・クラスタは、これらのサービスのクライアントにネットワーク・サービス（例: IPアドレス）や、アプリケーション・サービス（例: データベース、Webサーバー）の単一ビューを提供するコンピュータの集まりです。ハードウェア・クラスタの各ノードは、それぞれ固有のプロセスを実行するスタンドアロン・サーバーです。これらのプロセスは互いに通信して、単一のシステムであるかのように動作して、アプリケーション、システム・リソースおよびデータを連携してユーザーに提供できます。

  特別なハードウェア（クラスタ・インターコネクト、共有記憶域）とソフトウェア（ヘルス・モニター、リソース・モニター）を使用することで、ハードウェア・クラスタにより高可用性とスケーラビリティが実現されます。クラスタ・インターコネクトは、ハートビート情報でノード障害を検出するハードウェア・クラスタで使用されるプライベート・リンクです。ハードウェア・クラスタでは特別なハードウェアとソフトウェアが必要なので、一般的にSun社、HP社、IBM社、Dell社などのハードウェア・ベンダーによりハードウェア・クラスタは提供されています。ハードウェア・クラスタで構成可能なノードの数はベンダーによって異なりますが、Oracle Fusion Middlewareの高可用性を実現するのに必要なノードの数は2つのみです。このため、ハードウェア・クラスタを使用する高可用性ソリューションでは、2つのノードによるハードウェア・クラスタがこのドキュメントで前提にされています。

• クラスタ・エージェント: ハードウェア・クラスタのノード・メンバー上で実行されるソフトウェアで、他のノードとの可用性やパフォーマンスの操作の調整をします。クラスタウェアによりリソースのグループ化と監視を行い、サービスを移行できます。クラスタ・エージェントではサービスのフェイルオーバーを自動化できます。

• クラスタウェア: クラスタのメンバーの操作をシステムとして管理するソフトウェア。リソースとサービスのセットを定義してから、ハートビートのメカニズムにより複数のクラスタ・メンバー間において監視を行い、これらのリソースとサービスを別のクラスタ・メンバーにできるだけ効率的で透過的に移動できます。

• 共有記憶域: 共有記憶域は、EDGドメイン内のすべてのマシンがアクセスできる記憶域サブシステムです。特に、次に示すものが共有ディスクに配置されます。

  • ミドルウェア・ホームのソフトウェア

  • AdminServerドメイン・ホーム

  • JMS

  • Tlogs（該当する場合）

  必要に応じて、管理対象サーバーのホームを共有ディスクに配置できます。共有記憶域は、Network Attached Storage（NAS）またはStorage Area Network（SAN）にすることができます。また、複数のノードが同時にアクセスして読込みと書込みができる他のストレージ・システムにすることもできます。

• 1次ノード: Oracle Fusion Middlewareインスタンスをいつでもアクティブに実行しているノードであり、バックアップ/2次ノードを持つように構成されているノードです1次ノードに障害が発生すると、Oracle Fusion Middlewareインスタンスは2次ノードにフェイルオーバーされます。このフェイルオーバーは、管理サーバー用のクラスタウェアを使用して、手動または自動で実行できます。サーバー移行機能に基づいたシナリオでは、WebLogic Whole Server移行機能が自動化フェイルオーバーに使用されています。

• 2次ノード: Oracle Fusion Middlewareインスタンスのバックアップ・ノードであるノード。1次ノードが使用できなくなると、アクティブなインスタンスでフェイルオーバーが実行されます。この項で、1次ノードに関する定義を参照してください。

• ネットワーク・ホスト名: ネットワーク・ホスト名は、/etc/hostsファイルまたはDNS名前解決を通じてIPアドレスに割り当てられる名前です。この名前は、参照先マシンに接続する際にネットワークで参照可能です。ネットワーク・ホスト名と物理ホスト名が同一である場合があります。ただし、各マシンには物理ホスト名は1つのみ付与されますが、ネットワーク・ホスト名は複数付与される場合があります。そのため、マシンのネットワーク・ホスト名はその物理ホスト名であるとはかぎりません。

• 物理ホスト名: このガイドでは、物理ホスト名とネットワーク・ホスト名を区別しています。このガイドでは、現在のマシンの内部名を指す場合に物理ホスト名が使用されます。UNIXでは、hostnameコマンドにより返される名前です。

  Oracle Fusion Middlewareで使用される物理ホスト名は、ローカル・ホストを示します。インストール中に、インストーラでは物理ホスト名が現在のマシンから自動的に取得され、ディスク上のOracle Fusion Middleware構成メタデータに格納されます。

• 物理IP: 物理IPは、ネットワーク上のマシンのIPを示します。ほとんどの場合、マシンの物理ホスト名と関連付けられます（物理ホスト名に関する定義を参照）。仮想IPと対照的に、マシンがネットワークに接続されると、必ず同じマシンと関連付けられます。

• スイッチオーバー: 通常の操作中に、システムのアクティブなメンバーのメンテナンスやアップグレードが必要になることがあります。スイッチオーバー処理を開始して、メンテナンスやアップグレード（計画停止中に実施）が必要なメンバーが処理していたワークロードを、代替メンバーが引き継ぐことができます。スイッチオーバー処理により、システムのコンシューマに対してサービスが続行できるようになります。

• スイッチバック: スイッチオーバー操作の実行時、メンテナンスまたはアップグレードのためにシステムのメンバーは非アクティブ化されます。メンテナンスやアップグレードが完了すると、システムでスイッチバック処理を実行して、アップグレードしたメンバーをアクティブ化し、スイッチオーバー前の構成にシステムを戻すことがきます。

• 仮想ホスト名: 仮想ホスト名はネットワーク・アドレスを指定可能なホスト名で、ロード・バランサまたはハードウェア・クラスタを通じて、1つ以上の物理マシンにマップされます。ロード・バランサの場合、このマニュアルでは仮想サーバー名の名前は仮想ホスト名と同じ意味で使用されます。複数のサーバーのセットを代表する仮想ホスト名をロード・バランサに付与でき、クライアントは仮想ホスト名を使用して、間接的にマシンと通信します。ハードウェア・クラスタの仮想ホスト名は、クラスタの仮想IPに割り当てられるネットワーク・ホスト名です。クラスタにある特定ノードにクラスタの仮想IPが永続的に付与されないため、仮想ホスト名も特定ノードに永続的に付与されません。

  
  

  注意: 仮想ホスト名の用語がこのドキュメントで使用されるときは必ず、仮想IPアドレスで割り当てられることが前提になります。IPアドレスが必要とされたり使用される場合、明示的に言及します。

  
  

• 仮想IP: クラスタ仮想IP、ロード・バランサ仮想IPとも言います。一般的に、仮想IPはハードウェア・クラスタやロード・バランサに割り当てることができます。クラスタにおいて単一のシステム・ビューをネットワークのクライアントに対して実現するために、クラスタのメンバーであるサーバーのグループに対して仮想IPはエントリ・ポイントのIPアドレスとして機能します。仮想IPはハードウェア・クラスタやサーバーのロード・バランサに割り当てることができます。

  ハードウェア・クラスタではクラスタの仮想IPが使用され、外部の世界に対してクラスタ（スタンドアロンのマシンにも設定可能）へのエントリ・ポイントを実現します。ハードウェア・クラスタのソフトウェアにより、クラスタにある2台の物理ノード間においてこのIPアドレスの変更が管理されますが、クライアントはこのIPアドレスに接続します。その際、このIPアドレスが現在アクティブである物理ノードを判別する必要はありません。2台のノードによる標準的ハードウェア・クラスタ構成では、各マシンには固有の物理IPアドレスと物理ホスト名が付与されながら、数個のクラスタIPアドレスを付与することもできます。これらのクラスタIPアドレスは、2台のノードにおいて切り替わります。クラスタIPアドレスを現在所有しているノードは、そのアドレスでアクティブになります。

  また、ロード・バランサでも、複数のサーバーのセットのエントリ・ポイントとして仮想IPが使用されます。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーには割り当てられませんが、サーバーとクライアントとの間においてプロキシとして動作するロード・バランサに割り当てられます。

1.3 Oracle推奨事項のメリット

このガイドで説明するOracle Fusion Middleware構成では、すべての起動でセキュリティが確保され、ハードウェア・リソースが最大化され、様々なアプリケーションを使用したエンタープライズ・コンピューティングのために信頼性が高く標準に準拠したシステムを提供するために設計されています。

• 第1.3.1項「組込みセキュリティ」

• 第1.3.2項「高可用性」

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

1.3.1 組込みセキュリティ

エンタープライズ・デプロイメントのアーキテクチャは、ソフトウェア・コンポーネントの各機能グループが独自のDMZ内で独立しており、すべてのトラフィックがプロトコルとポートによって制限されているため、保護されています。次の特長により、必要なレベルのすべてのセキュリティが確保され、高レベルの標準の準拠が実現します。

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

  
  

  注意: Oracle Technology Network（http://www.oracle.com/technology/index.html）には、検証されたロード・バランサと構成の一覧（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サーバーのインストールと実行に必要なメモリーを表していますが、ほとんどの本番サイトには4GB以上の物理メモリーを構成してください。

要件の詳細または他のプラットフォームの要件については、ご使用のプラットフォーム用に対応した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	デフォルト	デフォルト
SOAHOSTn	2基以上のX Pentium（1.5GHz以上）	10GB脚注1	4GB	デフォルト	デフォルト
WCHOSTn	2基以上のX Pentium（1.5GHz以上）	10GB	4GB	デフォルト	デフォルト

^脚注 1 共有記憶域のMW_HOME構成の場合、2つのインストールではスロットの数とは関係なく合計20GBになるようにすると十分です。

注意: 適切な容量計画を実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。これらは、使用するカスタムSOAシステムやアプリケーションごとに異なります。

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

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

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

図1-1 Oracle Access Managerを使用するMyWCCompanyトポロジ

この項の項目は次のとおりです。

• 第1.5.1項「Oracle Identity Management」

• 第1.5.2項「Web層」

• 第1.5.3項「アプリケーション層」

• 第1.5.4項「データ層」

• 第1.5.5項「インストールするコンポーネント」

• 第1.5.6項「ユニキャスト要件」

1.5.1 Oracle Identity Management

Oracle Identity Managementシステムとの統合は、エンタープライズ・デプロイメントのアーキテクチャにおいて重要な側面になります。この統合により、シングル・サインオン、OPSSとの統合、一元化されたアイデンティティとアイデンティティ・ストア、WebLogicドメインにおける認証機能などが実現されます。IDM EDGはこのEDGとは別々であり、それ自体別のドメインに存在します。エンタープライズ・デプロイメントのコンテキストにおけるアイデンティティ管理の詳細は、『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management』を参照してください。

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

1.5.2 Web層

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

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

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

Oracle HTTP ServerにあるWebGate（Oracle Access Managerコンポーネント）はOracle Access Protocol（OAP）を使用して、アイデンティティ管理DMZ内のOAMHOST2で実行されているOracle Access Managerと通信します。WebGateと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プロトコル（たとえば、HTTPSからHTTP）を使用してトラフィックを実際のバックエンド・サーバーに転送できる必要があります。一般的にこの機能はSSLの高速化と呼ばれ、このEDGで必要になります。

1.5.3 アプリケーション層

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

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

WebCenter Spaces、ポートレット、Wiki/ディスカッション・フォーラム、WebCenterカスタム・アプリケーションなどのOracle WebCenterコンポーネントは、アクティブ/アクティブ構成になっており、WCHOST1およびWCHOST2上で実行されます。通常、管理対象サーバーは、WLS_Spaces、WLS_PortletおよびWLS_Services（Wiki/ディスカッション・フォーラム用）と呼ばれます。WebCenterカスタム・アプリケーションの要件に応じて、カスタム・アプリケーションを実行する管理対象サーバーを作成することもできます。

WCHOST1およびWCHOST2は、Oracle Content Server（OCS）も実行します。OCSは、アクティブ/アクティブ構成になっています。

このトポロジでSOAコンポーネントも実行している場合、SOAHOST1とSOAHOST2は、SOAコンポーネントを実行する管理対象サーバーWLS_SOAおよびWLS_WSMとともに構成されているWebLogic Serverを実行します。これらのコンポーネントはアクティブ/アクティブ構成です。

Oracle Web Services Manager（Oracle WSM）では、ポリシー・フレームワークが用意されており、EDGトポロジでWebサービスの管理と保護が行われます。また、WSMのポリシー・マネージャでは、さらに2台のWebLogic Serverでアクティブ/アクティブ構成で実行されます。

アプリケーション層を保護しているファイアウォールでは、HTTPポート、OAPポートおよびプロキシ・ポートが開きます。OAPポートは、Web層のOracle HTTP Serverで実行されているWebGateモジュールがOracle Access Managerと通信するためのものです。外部のHTTPアクセスが必要なアプリケーションでは、Oracle HTTP Serverがプロキシとして使用されます。Oracle HTTP Server上のプロキシが有効にされて、このアクセスが許可される必要があります。

1.5.4 データ層

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

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

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

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

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

表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 SOA Suite	Oracle SOA Suite 11g（11.1.1.1.0）のDVD
Oracle Access Manager 10g Webgate	Oracle Access Manager 10g Webgates（10.1.4.3.0）のDVD、使用するプラットフォームに対応したOAM OHS 11g Webgate
Oracle Virtual Directory（OVD）	Oracle Identity Management 11g（11.1.1.1.0）のDVD

1.5.6 ユニキャスト要件

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

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

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

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

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

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

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

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

1.6 このガイドの使用方法

この項の項目は次のとおりです。

• 第1.6.1項「インストールと構成の手順」

• 第1.6.2項「インストール計画の概要」

1.6.1 インストールと構成の手順

表1-3は、WebCenterのインストールと構成の手順をまとめたものです。選択された構成では、最初の列に記載された手順を記載順序に従って実行してください。

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

表1-3 WebCenterのインストール手順

実行する手順	管理サーバーとWSM-PMでのみドメインを構成するには	管理サーバー、WSM-PMでドメインを構成し、SOAクラスタでドメインを拡張するには	管理サーバー、WCM-PM、SOAクラスタおよびWebCenterを使用してドメインを構成するには
第2章「データベースと環境の事前構成」	はい	はい	はい
第3章「Oracle HTTP Serverのインストール」	はい	はい	はい
第4章「ドメインの作成」	はい	はい	はい
第5章「SOAコンポーネントを使用するためのドメインの拡張」	いいえ	はい	はい
第6章「WebCenterコンポーネントを使用するためのドメインの拡張」	いいえ	いいえ	はい
第7章「ノード・マネージャの設定」	推奨（オプションであり、アプリケーション層で必要なセキュリティのタイプによって異なります）	推奨（オプションであり、アプリケーション層で必要なセキュリティのタイプによって異なります）	推奨（オプションであり、アプリケーション層で必要なセキュリティのタイプによって異なります）
第8章「外部サービスの構成」	いいえ	いいえ	はい
第9章「Oracle Content Serverのインストールと構成」	いいえ	いいえ	はい

1.6.2 インストール計画の概要

構成ウィザードにより、必要なコンポーネントのみを追加することでOracle WebLogicドメインを拡張できます。構成ウィザードを使用して、管理サーバー、Enterprise ManagerおよびWSM-PMが含まれているドメインとともに、SOAコンポーネントとOracle WebCenterコンポーネントを1回のパスで作成するかわりに、ドメインとその管理サーバー、Enterprise ManagerおよびWSM-PMを構成ウィザードの1つのパスで作成してから、SOAコンポーネントのみ（または必要に応じて、WebCenterコンポーネントのみ）を追加することで、後続のパスでドメインを拡張できます。この増分方式を使用すると、サーバーのインストールを検証して、構成ウィザードの各パスを実行後に、特定の検証を実行できます。一般的に、次の方式をお薦めします。

1. 構成ウィザードの最初のパスを実行して、管理サーバー、Enterprise ManagerおよびWSM-PMをインストールします（第4章「ドメインの作成」を参照）。

2. 必要に応じて、構成ウィザードの2番目のパスを実行して、SOAコンポーネントをインストールします（第5章「SOAコンポーネントを使用するためのドメインの拡張」を参照）。

3. 3番目のパスを実行してWebCenterコンポーネントをインストールします（第6章「WebCenterコンポーネントを使用するためのドメインの拡張」を参照）。

個々のコンポーネントを1つずつ検証する作業を容易にするためにこのモジュール方式をお薦めします。このブロック階層方式により、設定プロセスにおけるトラブルシューティングが単純になり、少ない手順で構成が容易になります。

前述のトポロジからのバリエーションもいくつか可能になります。たとえば、デプロイメントにおいてWebCenter単独でインストールすることを選択した場合、WebCenterの拡張に該当する項目にのみ従う必要があります。この場合、かわりに管理サーバーはBAMHOST1に配置することも求められます。また、ドメインの作成に関する指示は適切に変更する必要があります。