Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B55899-05 |
|
前 |
次 |
この章では、Oracle SOA Suite用エンタープライズ・トポロジの概要について説明します。この章の項目は次のとおりです。
エンタープライズ・デプロイメントは、Oracle Fusion Middlewareの実証済高可用性テクノロジ、セキュリティ・テクノロジおよび推奨事項に基づいたベスト・プラクティスの青写真です。これらの青写真に示すベスト・プラクティスは、技術スタック全体において多くのOracle製品を対象にしています。それらの製品には、Oracle Database、Oracle Fusion MiddlewareおよびEnterprise Manager Fusion Middleware Controlがあります。
Oracle Fusion Middlewareのエンタープライズ・デプロイメントの特長は、次のとおりです。
様々な業務のサービス・レベル合意(SLA)を考慮して、高可用性ベスト・プラクティスをできるだけ広範囲に適用できるようにします。
データベース・グリッド・サーバーと低コストのストレージを使用したストレージ・グリッドを活用し、回復力に優れ低コストのインフラストラクチャを提供します。
様々な構成を対象として広範囲なパフォーマンス影響調査の結果を利用し、ビジネス・ニーズに応じて実行およびスケールできるように高可用性アーキテクチャが最適に構成されます。
停止状態からのリカバリ時間と自然災害時に許容可能なデータ損失量を制御できます。
ベスト・プラクティスと推奨アーキテクチャが使用されます。それらは、ハードウェアとオペレーティング・システムには依存していません。
高可用性ベスト・プラクティスの詳細は、http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
のWebサイトを参照してください。
注意: このドキュメントではLinux環境におけるエンタープライズ・デプロイメントを中心に説明していますが、エンタープライズ・デプロイメントは、UNIX環境やWindows環境でも実現できます。 |
この項では、以前のリリースのコンポーネントに使用されていた用語と、リリース11g(11.1.1)において対応する用語について説明します。
Oracleホーム: Oracleホームには、特定の製品をホストするために必要なファイルがインストールされて格納されています。たとえば、SOAのOracleホームには、Oracle SOA Suiteのバイナリとライブラリ・ファイルが格納されているディレクトリがあります。Oracleホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。各Oracleホームは、複数のOracleインスタンスやOracle WebLogic Serverドメインと関連付けることができます。
Oracle共通ホーム: この環境変数と関連ディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが含まれるOracleホームを指しています。
WebLogic Serverホーム: WebLogic Serverホームには、WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。WebLogic Serverホームのディレクトリは、Oracleホームのディレクトリのピアで、ミドルウェア・ホームのディレクトリ構造の内部にあります。
ミドルウェア・ホーム: ミドルウェア・ホームは、Oracle WebLogic Serverホームと、オプションとして1つまたは複数のOracleホームで構成されます。ミドルウェア・ホームは、ローカル・ファイルシステムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。
Oracleインスタンス: Oracleインスタンスには、アクティブなミドルウェア・システム・コンポーネントが1つ以上あります。コンポーネントの例には、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどがあります。インストール時かその後でインスタンスの作成と構成を行うときに、インスタンスにどのコンポーネントを含めるかを決定します。Oracleインスタンスには、更新可能なファイルがあります。それらのファイルの例には、構成ファイル、ログ・ファイル、一時ファイルなどがあります。
フェイルオーバー: 高可用性システムのメンバーで障害(計画外停止時間)が突然発生した場合、システムでは、コンシューマへのサービスの提供を続けるために、フェイルオーバー操作が実行されます。システムがアクティブ/パッシブ型システムの場合、パッシブ・メンバーはフェイルオーバー操作においてアクティブになります。そしてコンシューマは、障害が発生したメンバーではなく、アクティブになったメンバーにリダイレクトされます。フェイルオーバー操作は、手動でも実行できます。また、障害を検出した場合にクラスタのリソースを障害ノードからスタンバイ・ノードに移動するように、ハードウェア・クラスタ・サービスを設定することで、フェイルオーバー操作を自動化することもできます。システムがアクティブ/アクティブ型システムの場合、ロード・バランサのエンティティによりフェイルオーバーが実行されます。このエンティティによって、リクエストがアクティブ・メンバーで処理されます。アクティブ・メンバーに障害が発生すると、ロード・バランサにより障害が検出され、障害メンバーへのリクエストが、正常に動作しているアクティブ・メンバーに自動的にリダイレクトされます。アクティブ/アクティブ型システムとアクティブ/パッシブ型システムの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。
フェイルバック: システムで正常にフェイルオーバー操作が実行されると、元の障害メンバーはしばらく時間をかけて修復することができ、スタンバイ・メンバーとしてシステムに再導入できます。必要に応じて、フェイルバック処理を開始して、このメンバーをアクティブにし、別のメンバーを非アクティブにすることができます。この処理によりシステムは、障害発生前の構成に戻ります。
ハードウェア・クラスタ: ハードウェア・クラスタは、ネットワーク・サービス(たとえば、IPアドレス)やアプリケーション・サービス(たとえば、データベース、Webサーバー)を単一のビューでサービスのクライアントに提供するコンピュータのコレクションです。ハードウェア・クラスタの各ノードは、それぞれ固有のプロセスを実行するスタンドアロン・サーバーです。これらのプロセスは互いに通信して、単一のシステムであるかのように動作して、アプリケーション、システム・リソースおよびデータを連携してユーザーに提供できます。
特別なハードウェア(クラスタ・インターコネクト、共有記憶域)とソフトウェア(ヘルス・モニター、リソース・モニター)を使用することで、ハードウェア・クラスタにより高可用性とスケーラビリティが実現されます。クラスタ・インターコネクトは、ハートビート情報でノード障害を検出するハードウェア・クラスタで使用されるプライベート・リンクです。ハードウェア・クラスタでは特別なハードウェアとソフトウェアが必要なので、一般的にSun社、HP社、IBM社、Dell社などのハードウェア・ベンダーによりハードウェア・クラスタは提供されています。ハードウェア・クラスタで構成可能なノードの数はベンダーによって異なりますが、Oracle Fusion Middlewareの高可用性を実現するのに必要なノードの数は2つのみです。このため、ハードウェア・クラスタを使用する高可用性ソリューションでは、2つのノードによるハードウェア・クラスタがこのドキュメントで前提にされています。
クラスタ・エージェント: ハードウェア・クラスタのノード・メンバー上で実行されるソフトウェアであり、可用性とパフォーマンスの操作を他のノードと連携して調整します。クラスタウェアによりリソースのグループ化と監視を行い、サービスを移行できます。クラスタ・エージェントではサービスのフェイルオーバーを自動化できます。
クラスタウェア: クラスタ・メンバーの操作をシステムとして管理するソフトウェアです。リソースとサービスのセットを定義してから、ハートビートのメカニズムにより複数のクラスタ・メンバー間において監視を行い、これらのリソースとサービスを別のクラスタ・メンバーにできるだけ効率的かつ透過的に移動できます。
共有記憶域: エンタープライズ・デプロイメント・ドメイン内のすべてのマシンがアクセスできる記憶域のサブシステムです。特に、次に示すものが共有ディスクに配置されます。
ミドルウェア・ホームのソフトウェア
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アドレスは個々のサーバーには割り当てられませんが、サーバーとクライアントとの間においてプロキシとして動作するロード・バランサに割り当てられます。
このガイドで説明するOracle Fusion Middleware構成では、すべての起動でセキュリティが確保され、ハードウェア・リソースが最大化され、様々なアプリケーションを使用したエンタープライズ・コンピューティングのために、信頼性が高く、標準に準拠したシステムを提供するために設計されています。
Oracle Fusion Middleware構成のセキュリティと高可用性のメリットは、ファイアウォール・ゾーンの分離とソフトウェア・コンポーネントのレプリケーションを通じて実現されます。
エンタープライズ・デプロイメントのアーキテクチャは、ソフトウェア・コンポーネントの各機能グループが独自のDMZ内で独立しており、すべてのトラフィックがプロトコルとポートによって制限されているため、保護されています。次の特長により、必要なレベルのすべてのセキュリティが確保され、高レベルの標準の準拠が実現します。
ポート80で受信した外部通信はすべてポート443にリダイレクトするように、外部のロード・バランサを構成します。
注意: Oracle Technology Network(http://www.oracle.com/technology/index.html )には、検証されたロード・バランサと構成の一覧(http://www.oracle.com/technetwork/middleware/ias/tested-lbr-fw-sslaccel-100648.html )が用意されています。 |
外部のクライアントからの通信はロード・バランシング・ルーターを超えたレベルでは発生しません。
ロード・バランシング・ルーターからデータ層への直接的な通信は許可されません。
コンポーネントは、Web層、アプリケーション層およびデータ層の異なる保護ゾーンで分離されています。
一度に2つのファイアウォールをまたがる直接的な通信は禁止されています。
1つのファイアウォール・ゾーンで通信が始まった場合、それは次のファイアウォール・ゾーンで終わる必要があります。
Oracle Internet Directoryはデータ層内で独立しています。
アイデンティティ管理コンポーネントは別のサブネットにあります。
複数の保護ゾーンにおいて複数のコンポーネント間の通信はすべて、ファイアウォールのルールに従いポートとプロトコルによって制限されます。
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 |
デフォルト |
デフォルト |
BAMHOSTn |
2基以上のX Pentium(1.5GHz以上) |
10GB脚注 2 |
4GB |
デフォルト |
デフォルト |
脚注 1 共有記憶域のミドルウェア・ホーム構成の場合、2つのインストールでは、スロット数と関係なく合計20GBになるようにすると十分です。
脚注2 BAMでは共有記憶域のSOAインストールからミドルウェア・ホーム・バイナリを再利用できます。
注意: 適切なキャパシティ・プランニングを実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。これらは、使用するカスタムSOAシステムやアプリケーションごとに異なります。 |
このガイドの手順とダイアグラムでは、バリエーションの適用が可能な参照用トポロジについて示しています。
このガイドでは、サービス指向アーキテクチャ(SOA)を、Oracle Access Manager(図1-1)、Oracle Access ManagerおよびOracle Business Activity Monitoring(BAM)(図1-2)、またはOracle Access ManagerおよびBPM(図1-3)とともに使用する参照用エンタープライズ・トポロジのための構成手順について説明します。
この項の項目は次のとおりです。
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へのリクエストのプロキシを許可する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のみが開いています。
このエンタープライズ・トポロジは外部のロード・バランサを使用します。この外部ロード・バランサは次の機能を備えている必要があります。
仮想ホスト名により実際のサーバーのプールにトラフィックの負荷を分散できる機能: クライアントは実際のホスト名でなく仮想ホスト名を使用してサービスにアクセスします。ロード・バランサは、プールにあるサーバーにリクエストの負荷を分散できます。
ポート変換構成が可能である必要があります。これによって、仮想ホスト名とポートにおける入力リクエストが、バックエンド・サーバーにある別のポートにダイレクトされます。
プールにあるサーバーのポートを監視してサービスの可用性を判定する機能。
仮想サーバーとポートの構成: 仮想サーバー名とポートを外部ロード・バランサ上で構成できる機能です。仮想サーバー名とポートは次の要件を満たす必要があります。
ロード・バランサでは、複数の仮想サーバーの構成が可能である必要があります。ロード・バランサでは、仮想サーバーごとに複数のポートにおいてトラフィック管理の構成が可能である必要があります。たとえば、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が実行されますが、アクティブ/パッシブ構成で動作します。管理サーバーは手動でフェイルオーバーできます(第4.22項「SOAHOST2への管理サーバーの手動フェイルオーバー」を参照)。またそのかわりに、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コンポーネントが必要とするスキーマが含まれています。アプリケーション層で実行されているSOAコンポーネントとBAMコンポーネントがこのデータベースにアクセスします。
データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(一般的には1521)が開かれている必要があります。また、IDMエンタープライズ・デプロイメントでLDAP記憶域にアクセスするトラフィックに対して、LDAPポート(一般的には389および636)が開いている必要があります。
表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.4.0)のDVD |
Oracle WebLogic Server(WLS) |
Oracle Weblogic Server 11g R1(10.3.4)のDVD |
Oracle HTTP Server |
Oracle Fusion Middleware WebTier and Utilities 11g(11.1.1.4.0)のDVD |
Oracle SOA Suite |
Oracle SOA Suite 11g(11.1.1.4.0)のDVD |
Oracle Business Activity Monitoring(BAM) |
Oracle Fusion Middleware 11g(11.1.1.4.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.4.0)のDVD |
mySOACompanyトポロジにあるノードはユニキャストを使用して通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。
ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。
WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。
個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプの上書きはできません。
メッセージ・モードを変更(マルチキャストとユニキャストとの間における切替え)するには、クラスタ全体を停止してから再起動する必要があります。
マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。
クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。
JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。
注意: ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。 ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。 |
この項の項目は次のとおりです。
表1-3は、SOAエンタープライズ・デプロイメントのインストールと構成の手順をまとめたものです。選択された構成では、最初の列に記載された手順を記載順序に従って実行してください。
注意: このドキュメントではLinux環境におけるエンタープライズ・デプロイメントを中心に説明していますが、エンタープライズ・デプロイメントは、UNIX環境やWindows環境でも実現できます。 |
表1-3 SOAインストール手順
実行する手順 | 管理サーバーとWSM-PMでのみドメインを構成するには | 管理サーバー、WSM-PMでドメインを構成し、SOAクラスタでドメインを拡張するには | 管理サーバー、WSM-PMでドメインを構成し、SOA/BPMクラスタでドメインを拡張するには | 管理サーバー、WSM-PM、SOAでドメインを構成し、BPMクラスタでドメインを拡張するには | 管理サーバー、WSM-PMおよびBAMクラスタで(SOAなしで)ドメインを構成するには | 管理サーバー、WSM-PM、SOA/BPMクラスタおよびBAMクラスタでドメインを構成するには |
---|---|---|---|---|---|---|
|
はい |
はい |
はい |
はい |
はい |
はい |
第3章「Oracle HTTP Serverのインストール」 |
はい |
はい |
はい |
はい |
はい |
はい |
|
はい |
はい |
はい |
はい |
はい |
はい |
第5章「SOAコンポーネントを使用するためのドメインの拡張」 |
いいえ |
はい |
いいえ |
はい |
いいえ |
はい |
第6章「Oracle BPMを追加するためのドメインの拡張」 |
いいえ |
いいえ |
はい(オプション1を使用) |
はい(オプション2を使用) |
いいえ |
はい(BAMでBPMを使用する場合) |
|
いいえ |
いいえ |
いいえ |
いいえ |
はい |
はい |
|
推奨(オプションであり、アプリケーション層で必要なセキュリティのタイプによって異なります) |
推奨(オプションであり、アプリケーション層で必要なセキュリティのタイプによって異なります) |
推奨(オプションであり、アプリケーション層で必要なセキュリティのタイプによって異なります) |
推奨(オプションであり、アプリケーション層で必要なセキュリティのタイプによって異なります) |
推奨(オプションであり、アプリケーション層で必要なセキュリティのタイプによって異なります) |
推奨(オプションであり、アプリケーション層で必要なセキュリティのタイプによって異なります) |
|
いいえ |
はい(本番環境の場合) |
はい(本番環境の場合) |
はい(本番環境の場合) |
はい |
はい |
構成ウィザードにより、必要なコンポーネントのみを追加することでOracle WebLogicドメインを拡張できます。構成ウィザードを使用して、管理サーバー、Enterprise ManagerおよびWSM-PMが含まれているドメインとともに、SOAコンポーネントとOracle Business Monitoring(BAM)コンポーネントを1回のパスで作成するかわりに、ドメインとその管理サーバー、Enterprise ManagerおよびWSM-PMを構成ウィザードの1つのパスで作成してから、SOAコンポーネントのみ(または必要に応じて、BAMコンポーネントのみ)を追加することで、後続のパスでドメインを拡張できます。この増分方式を使用すると、サーバーのインストールを検証して、構成ウィザードの各パスを実行後に、特定の検証を実行できます。一般的に、次の方式をお薦めします。
構成ウィザードの最初のパスを実行して、管理サーバー、Enterprise ManagerおよびWSM-PMをインストールします(第4章「ドメインの作成」を参照)。
構成ウィザードの2番目のパスを実行して、SOAコンポーネントをインストールします(第5章「SOAコンポーネント用のドメインの拡張」を参照)。
必要に応じて、3番目のパスを実行してBAMコンポーネントをインストールします(第7章「BAMを追加するためのドメインの拡張」を参照)。
個々のコンポーネントを1つずつ検証する作業を容易にするためにこのモジュール方式をお薦めします。このブロック階層方式により、設定プロセスにおけるトラブルシューティングが単純になり、少ない手順で構成が容易になります。
前述のトポロジからのバリエーションもいくつか可能になります。たとえば、デプロイメントにおいてBAM単独でインストールすることを選択した場合、BAMの拡張に該当する項目のみ従う必要があります。この場合、かわりにAdminServerはBAMHOST1に配置することも求められます。また、ドメインの作成に関する指示は適切に変更する必要があります。
また、Oracle Fusion Middleware 11g R1 11.1.1.3(PS2)では、以前のOracle Fusion Middleware 11g SOA Suiteリリースにあったサービス・エンジンのスーパーセットとしてOracle BPMを導入しています。そのシステムでは様々な方法でOracle BPM Suiteを有効化できます。構成ウィザードを使用して既存のSOAドメインを拡張したり、構成ウィザードを使用して管理+WSMドメインをSOAとBPMの両コンポーネントで拡張できます。両方のオプションの詳細は、第6章「Oracle BPMを追加するためのドメインの拡張」を参照してください。