| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-07 |
|
前 |
次 |
この章では、このガイドで使用するエンタープライズ・デプロイメント参照用トポロジについて説明します。インストールと構成のロード・マップでは、実行する必要のあるタスクが記載されている章へと導きます。この章を利用してOracle SOAエンタープライズ・デプロイメントを計画してください。
この章の内容は次のとおりです。
このガイドでは考えられるデプロイメントとして3種類のエンタープライズ・デプロイメントを示しますが、この項ではこれらのデプロイメントを表現するダイアグムについて説明します。この項を使用してエンタープライズ・デプロイメント・トポロジを計画してください。
この項の項目は次のとおりです。
このガイドでは、サービス指向アーキテクチャ(SOA)を、Oracle Access Manager (図2-1)、Oracle Access ManagerおよびOracle Business Activity Monitoring (BAM)(図2-2)、Oracle Access ManagerおよびBAM (図2-3)またはOracle Service Bus (図2-4)とともに使用する参照用エンタープライズ・トポロジのための構成手順について説明します。
|
注意: 実際のエンタープライズ・デプロイメントでは、このガイドで説明するトポロジを一部変更して使用する場合もあります。 |
図2-1は、Oracle Access Managerが含まれているMySOACompnayトポロジを表しています。
図2-2は、Oracle Access ManagerおよびBusiness Activity Monitoringが含まれているMySOACompanyトポロジを表しています。
図2-3は、Oracle Access ManagerおよびBAMが含まれているMySOACompanyトポロジを表しています。
図2-4は、Oracle Service Busが含まれているMySOACompanyトポロジを表しています。
Oracle Identity Managementシステムとの統合は、エンタープライズ・デプロイメント・アーキテクチャの重要な側面です。この統合により、シングル・サインオン、Oracle Platform Security Servicesとの統合、一元化されたアイデンティティおよび資格証明ストア、WebLogicドメインにおける認証などの機能が実現されます。IDMエンタープライズ・デプロイメントはこのエンタープライズ・デプロイメントとは別であり、それ自体で別のドメイン内に存在します。エンタープライズ・デプロイメントにおける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つのノードが、WebGateおよび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にあるWebGate(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プロトコル(たとえば、HTTPSからHTTP)を使用してトラフィックを実際のバックエンド・サーバーに転送できる必要があります。この機能は一般にSSLの高速化と呼ばれ、このエンタープライズ・デプロイメントで必要になります。
アプリケーション層のノードはDMZセキュア・ゾーンにあります。
この層では、SOAHOST1とSOAHOST2の2つのノードが、BPELプロセス・マネージャやB2BなどのSOAコンポーネントを実行するための管理対象サーバーとともに構成されているOracle WebLogic Serverを実行します。管理対象サーバーは、アクティブ/アクティブで構成されます。
BAMHOST1とBAMHOST2では、BAMサーバーとBAM Webアプリケーションが実行されます。
また、SOAHOST1とSOAHOST2でもOracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlが実行されますが、アクティブ/パッシブ構成で動作します。1つのドメイン内で実行できる管理サーバーは1つのみなので、管理サーバーのアクティブ/パッシブ構成が必要です。図では、現在はSOAHOST1上の管理サーバーがアクティブな状態ですが、SOAHOST2上の管理サーバーに手動でフェイルオーバーできます。
詳細は、第8.6.6項「管理サーバーの手動フェイルオーバーの検証」を参照してください。また、そのかわりに、Oracle WebLogic Server管理コンソールをCFC/CRSで構成して、自動で別のハードウェア・クラスタでフェイルオーバーすることもできます(このアーキテクチャでは記載されていません)。
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のノードで実行されます。データベースには、SOA、BAMおよびOracle Service Busコンポーネントで必要となるスキーマが含まれています。アプリケーション層で実行するSOA、BAMおよびOracle Service Busコンポーネントはこのデータベースにアクセスします。
データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(一般的には1521)が開かれている必要があります。また、IDMエンタープライズ・デプロイメントでLDAP記憶域にアクセスするトラフィックに対して、LDAPポート(一般的には389および636)が開いている必要があります。
mySOACompanyトポロジにあるノードはユニキャストを使用して通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。
ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。
クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。
ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。
ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。
WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。
個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプの上書きはできません。
メッセージ・モードを変更(マルチキャストとユニキャストとの間における切替え)するには、クラスタ全体を停止してから再起動する必要があります。
マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。
クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。
JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。
Oracle Fusion Middlewareのシステム要件および仕様のドキュメントを読み、環境がインストールする製品の最低のインストール要件を満たしていることを確認します。このドキュメントには、ハードウェアとソフトウェアの要件、ディスク領域とメモリーの最小要件、データベース・スキーマの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が記載されています。しかし、このエンタープライズ・デプロイメント・トポロジでは、さらに別のシステム要件が必要になります。
表2-1は、このLinuxオペレーティング・システム向けガイドで説明するエンタープライズ・デプロイメントで要求される標準的なハードウェア要件です。メモリー容量の数値は、Oracle Fusion Middlewareサーバーのインストールと実行に必要なメモリーを表していますが、ほとんどの本番サイトには4GB以上の物理メモリーを構成してください。
適切な容量計画を実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。これらは、使用するカスタムSOAシステムやアプリケーションごとに異なります。
表2-1 標準ハードウェア要件
| サーバー | ディスク | メモリー | TMPディレクトリ | スワップ |
|---|---|---|---|---|
|
データベース |
nXm n: ディスクの台数(台数は4台以上で、1台のディスクはストライプ) m: ディスクの容量(30GB以上) |
6～8GB |
デフォルト |
デフォルト |
|
WEBHOSTn |
10GB |
4GB |
デフォルト |
デフォルト |
|
SOAHOSTn (SOAのみ) |
10GB脚注1 |
4GB |
デフォルト |
デフォルト |
|
SOAHOSTn (SOAおよびOSB) |
11GB脚注2 |
6GB |
デフォルト |
デフォルト |
|
BAMHOSTn |
10GB脚注3 |
4GB |
デフォルト |
デフォルト |
脚注 1 共有記憶域のミドルウェア・ホーム構成の場合、2つのインストールでは、スロット数と関係なく合計20GBになるようにすると十分です。
脚注2共有記憶域のミドルウェア・ホーム構成の場合、2つのインストールでは、スロット数と関係なく合計20GBになるようにすると十分です。
脚注3 BAMでは共有記憶域のSOAインストールからミドルウェア・ホーム・バイナリを再利用できます。
表2-2に、このガイドの手順を開始する前に入手しておく必要のあるOracleソフトウェアを示します。
Oracle Fusion Middlewareソフトウェアのダウンロードの詳細は、Oracle Technology Network (OTN)のOracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルを参照してください。
表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) (RCUは様々なLinuxプラットフォームで使用できる汎用ユーティリティです。32ビットおよび64ビットのLinuxに同じビット数のものがインストールされます。) |
Oracle Fusion Middleware Repository Creation Utility 11g (11.1.1.6)ディストリビューション |
|
Oracle WebLogic Server(WLS) |
Oracle WebLogic Server (10.3.6)ディストリビューション |
|
Oracle HTTP Server(OHS) |
Oracle Fusion Middleware WebTier and Utilities 11g (11.1.1.6)ディストリビューション |
|
Oracle SOA Suite |
Oracle SOA Suite 11g (11.1.1.6)ディストリビューション |
|
Oracle Access Manager (OAM) WebGate |
WebGate 10g (10.1.4.3) for OAM 10gまたはWebGate 11g (11.1.1.3) for OAM 11g。 |
|
Oracle Virtual Directory(OVD) |
Oracle Identity and Access Management 11g (11.1.1.5)ディストリビューション |
|
Oracle Internet Directory(OID) |
Oracle Identity and Access Management 11g (11.1.1.5)ディストリビューション |
|
Oracle Service Bus(OSB) |
Oracle Service Bus 11g (11.1.1.6)ディストリビューション |
ジョブ、アダプタおよびOracle B2Bを正常に機能させるため、クラスタに参加するすべてのサーバーのクロックを同期させ、クロックの時間差を1秒以内に収める必要があります。これを実現するには、ネットワーク・タイム・サーバーを1つ使用して、各サーバーがそのネットワーク・タイム・サーバーを参照するようにします。
ネットワーク・タイム・サーバーを参照させる手順は、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムのドキュメントを参照してください。
Oracle SOAエンタープライズ・デプロイメントを開始する前に、図2-5のフロー・チャートを参照してください。このフロー・チャートは、このガイドで説明するエンタープライズ・デプロイメントを完成させるための大まかなプロセスを示しています。表2-3はこのフロー・チャート内の手順を説明するものであり、ここから各手順の項または章にジャンプできます。
この項の項目は次のとおりです。
図2-5に、Oracle SOAエンタープライズ・デプロイメント・プロセスのフロー・チャートを示します。このチャートを確認し、既存の環境に基づいた実行手順を理解してください。
表2-3は、図2-5に示すOracle SOAのエンタープライズ・デプロイメント・プロセスの各ステップについて説明しています。この表では、処理における各ステップの詳細について、その参照先も示します。
表2-3 Oracle SOAエンタープライズ・デプロイメント・プロセスのステップ
| 手順 | 説明 | 詳細 |
|---|---|---|
|
エンタープライズ・デプロイメント用のネットワークの準備 |
エンタープライズ・デプロイメント用のネットワークを準備するには、仮想サーバー名、IP、仮想IPSなどの概念を理解し、仮想ホスト名を定義してロード・バランサを構成する必要があります。 |
第3章「エンタープライズ・デプロイメント用のネットワークの準備」 |
|
エンタープライズ・デプロイメント用のファイル・システムの準備 |
エンタープライズ・デプロイメント用のファイル・システムを準備するには、ディレクトリおよびディレクトリ環境変数の用語を理解し、共有記憶域を構成する必要があります。 |
第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」 |
|
エンタープライズ・デプロイメント用のデータベースの準備 |
エンタープライズ・デプロイメント用のデータベースを準備するには、データベース要件の確認、データベース・サービスの作成、Oracle RACデータベースへのメタデータ・リポジトリのロード、トランザクション・リカバリ権限用SOAスキーマの構成およびデータベースのバックアップを実行する必要があります。 |
第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コンポーネントを使用するためのドメインの拡張」 |
|
BAMのためのドメインの拡張 |
Oracle BAMコンポーネントを含めるためのドメイン拡張については2つのオプションがあります。
|
第10章「Oracle BPMを追加するためのドメインの拡張」 |
|
BAMのためのドメインの拡張 |
Oracle BAMコンポーネントを含めるためのドメイン拡張については2つのオプションがあります。
|
|
|
OSBのためのドメインの拡張 |
構成ウィザードを再度実行し、Oracle Service Busを追加するためにドメイン拡張します。 |
第11章「Oracle Service Busを追加するためのSOAドメインの拡張」 |
|
ノード・マネージャの設定 |
ホスト名検証を有効化し、ノード・マネージャを起動して、カスタム・キーストアを使用するようにWebLogic Serverを構成し、ノード・マネージャを設定します。 |
第13章「エンタープライズ・デプロイメント用のノード・マネージャの設定」 |
|
サーバー移行の構成 |
WLS_SOA1およびWLS_SOA2管理対象サーバーのサーバー移行を構成します。WLS_SOA1管理対象サーバーは障害時にSOAHOST2で再起動するように構成されます。WLS_SOA2管理対象サーバーは障害時にSOAHOST1で再起動するように構成されます。 |
第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」 |
|
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製品を追加するためドメインを拡張します。
オプションで、構成ウィザードを再度実行して、その他のサポート・コンポーネントおよび製品を追加するためにドメイン拡張します。
この増分アプローチに従うことで、構成ウィザードの各ステップ後に環境を確認できます。また、セットアップ・プロセス中のトラブルシューティングが容易になります。
さらに、このモジュラ・アプローチでは代替トポロジの検討が可能になります。これは特に、管理コンポーネントの構成後、このガイドに記述されているコンポーネントをすべてドメインに含める必要がないことが判明したような場合です。この場合は、ドメイン拡張に関する章を個々に選択して参照し、組織で必要とされるコンポーネントを構成します。
