2 標準的なエンタープライズ・デプロイメントについて
標準的なエンタープライズ・デプロイメント・トポロジのコンポーネントを理解することが重要です。
この章では、エンタープライズ・デプロイメント・トポロジのダイアグラムについて説明します。
- 標準的なエンタープライズ・デプロイメントのダイアグラム
この図には、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントのコンポーネントをすべて示します。すべてのエンタープライズ・デプロイメントは、これらの基本原則に基づいています。 - 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムについて
標準的なデプロイメント・トポロジは、ハードウェア・ロード・バランサ(LBR)、Web層、アプリケーション層およびデータ層で構成されます。この項では、これらの構成要素の詳細を説明します。
親トピック: エンタープライズ・デプロイメントの理解
標準的なエンタープライズ・デプロイメントのダイアグラム
この図では、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントのすべてのコンポーネントを示します。すべてのエンタープライズ・デプロイメントは、これらの基本原則に基づいています。
すべてのOracle Fusion Middlewareエンタープライズ・デプロイメントは、Oracle Fusion Middleware本番環境のインストールと構成に関するベスト・プラクティスを示すように設計されています。
ベスト・プラクティス・アプローチは、複数層デプロイメントと、異なるソフトウェア層間の標準的通信の基本概念で始まります。
図2-1に、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントを示します。すべてのエンタープライズ・デプロイメントは、これらの基本原則に基づいています。
標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで通信に使用される各層と標準プロトコルの説明は、標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムについてを参照してください。
親トピック: 標準的なエンタープライズ・デプロイメントについて
標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムについて
標準的なデプロイメント・トポロジは、ハードウェア・ロード・バランサ(LBR)、Web層、アプリケーション層およびデータ層で構成されます。この項では、これらの構成要素の詳細を説明します。
- 標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解
- 標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解
- ハードウェア・ロード・バランサを介したリクエストの受信
- Web層の理解
- アプリケーション層の理解
- データ層について
親トピック: 標準的なエンタープライズ・デプロイメントについて
標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解
トポロジは、ファイアウォールによって隔てられている、次のようないくつかのセキュリティ・ゾーンに分かれています。
-
Web層(またはDMZ)。ハードウェア・ロード・バランサとユーザーからの初期リクエストを受信するWebサーバー(ここではOracle HTTP Serverインスタンス)で使用されます。このゾーンには、ロード・バランサ上で定義されている単一の仮想サーバー名を介してのみアクセスできます。
-
アプリケーション層。これはビジネスおよびアプリケーション・ロジックが配置されている場所です。
-
データ層。これには、インターネットからアクセスできず、このトポロジ内で可用性の高いデータベース・インスタンス用に予約されています。
ファイアウォールは、特定の通信ポートを介した場合にのみデータ転送が許可されるように構成されています。これらのポート(または、場合によってはファイアウォール内の開いているポートを必要とするプロトコル)は、ダイアグラム内の各ファイアウォール・ライン上に示しています。
たとえば:
-
Web層を保護しているファイアウォールでは、HTTPポート、つまりHTTPS用のポート443とHTTP用のポート80のみが開いています。
-
アプリケーション層を保護するファイアウォール上では、HTTPポートとMBeanプロキシ・ポートが開いています。
外部HTTPアクセスが必要なアプリケーションは、プロキシとしてOracle HTTP Serverインスタンスを使用できます。このポートはアウトバウンド通信専用であり、Oracle HTTP Serverのプロキシ機能を有効にする必要があります。
-
データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(通常は1521)が開かれている必要があります。
また、認可プロバイダとLDAPベースのアイデンティティ・ストア間の通信用に、LDAPポート(通常は389と636)も開いている必要があります。
アプリケーション層がOracle RACデータベースでのワークロードとイベントに関する通知を受信できるように、ONSポート(通常は6200)も必要です。これらのイベントは、Oracle RACデータベース・インスタンスの可用性とワークロードに応じて、Oracle WebLogic Server接続プールが迅速に調整(接続の作成または破棄)するために使用されます。
特定のOracle Fusion Middlewareエンタープライズ・デプロイメント・トポロジにおいて開いておく必要があるポートの全リストは、実装するトポロジについて説明している章を参照するか、実装するトポロジのエンタープライズ・デプロイメント・ワークブックを参照してください。「エンタープライズ・デプロイメント・ワークブックの使用 」を参照してください。
標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解
エンタープライズ・デプロイメント・トポロジは、大まかに次の要素で構成されます。
-
ハードウェア・ロード・バランサ。インターネットからのリクエストをWeb層内のWebサーバーにルーティングします。また、社内ネットワーク内で内部呼出しを実行する内部クライアントや他のコンポーネントからのリクエストもルーティングします。
-
Web層。ハードウェア・ロード・バランサと、Webサーバー・インスタンスをホストする複数の物理コンピュータで構成されています(高可用性のため)。
Webサーバー・インスタンスは、ユーザーを認証し(外部アイデンティティ・ストアおよびシングル・サインオン・サーバーを使用)、HTTPリクエストをアプリケーション層内で実行されているOracle Fusion Middleware製品およびコンポーネントにルーティングするように構成されています。
また、Webサーバー・インスタンスは、アプリケーション・ロジックの提供を必要としない静的Webコンテンツをホストします。このようなコンテンツをWeb層に配置することで、アプリケーション・サーバーのオーバーヘッドが低減され、不要なネットワーク・アクティビティが排除されます。
-
アプリケーション層。Oracle WebLogic管理対象サーバーのクラスタとドメイン用の管理サーバーをホストする2つ以上の物理コンピュータで構成されています。管理対象サーバーは、エンタープライズ・デプロイメントでの製品の選択に応じて、Oracle SOA Suite、Oracle Service Bus、Oracle WebCenter Content、Oracle WebCenter Portalなどの様々なOracle Fusion Middleware製品を実行するように構成されています。
-
データ層。Oracle RACデータベースをホストする2つ以上の物理ホストで構成されています。
ハードウェア・ロード・バランサを介したリクエストの受信
次の各項で、エンタープライズ・デプロイメントでのハードウェア・ロード・バランサとそのロールについて説明します。
ハードウェア・ロード・バランサ(LBR)の目的
ロード・バランサには、ローカル・ロード・バランサとグローバル・ロード・バランサの2種類があります。ロード・バランサは、Big IP、Cisco、Brocadeのようにハードウェアの場合も、Oracle Traffic Directorのようにソフトウェア・アプリケーションの場合もあります。ロード・バランサ・アプライアンスのほとんどは、ローカル・ロード・バランサとグローバル・ロード・バランサのどちらも構成できます。
ロード・バランサは、いずれかが単一障害点にならないように、必ずペアでデプロイする必要があります。たいていのロード・バランサは、これをアクティブ/パッシブ式で実行します。最も適切にこれを実行するには、ロード・バランサのドキュメントを参照してください。
ノート:
Oracleでは、特定のロード・バランサを動作保証しているわけではありません。エンタープライズ・デプロイメント・ガイドで説明しているロード・バランサの構成は、あくまでも参考用であり、ご使用になっているデバイスの構成に関するベスト・プラクティスについては、それぞれのロード・バランサ・ベンダーにお問い合せください。ローカル・ロード・バランサは、サイト内でトラフィックを分散するために使用します。HTTPとTCPどちらのトラフィックも分散でき、どちらのオプションを使用するかはデプロイメントの要件によって決まります。ローカル・ロード・バランサを使用すると、SSL暗号化と復号化が加速し、またSSLリクエストを終端する(off-load
)こともできます。ロード・バランサにおけるSSL終端は、アプリケーションの大幅なパフォーマンス・アップにつながります。デプロイメント自体の内部におけるオンザフライ方式のソフトウェア暗号化に伴うオーバーヘッドを生じることなく、サイト間のトラフィックを暗号化したままにできます。エンタープライズ・デプロイメント・ガイドでは、常にローカル・ロード・バランサを使用します。
グローバル・ロード・バランサは、同じ論理環境として機能させるサイトが複数ある場合に使用します。目的は、あらかじめ決められた一連のルールに基づいてサイト間でリクエストを分散することです。グローバル・ロード・バランサは一般的に、障害リカバリ(DR)デプロイメント、またはアクティブ/アクティブのマルチデータセンター(MDC)デプロイメントで使用されます。
次の項では、エンタープライズ・デプロイメントでハードウェア・ロード・バランサによって処理されるリクエストのタイプについて説明します。
- インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト
- 障害時リカバリおよびマルチデータセンターのトポロジにおけるロード・バランサの考慮事項
- Oracle MFT IntegrationのSFTPリクエスト
- アプリケーション層のコンポーネント間特有の内部専用通信
親トピック: ハードウェア・ロード・バランサを介したリクエストの受信
インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト
ハードウェア・ロード・バランサは、1つの仮想ホスト名へのリクエストを受信して各リクエストをロード・バランシング・アルゴリズムに基づいてWebサーバー・インスタンスの1つにルーティングすることで、Web層でのロードをバランシングします。このようにして、ロード・バランサは、特定のWebサーバーがHTTPリクエストによってオーバーロードにならないようにします。
ハードウェア・ロード・バランサの特定の仮想ホスト名の用途の詳細は、「標準的なロード・バランサの仮想サーバー名のサマリー」を参照してください。
参照用トポロジでは、HTTPリクエストのみがハードウェア・ロード・バランサからWeb層にルーティングされることに注意してください。Secure Socket Layer (SSL)リクエストはロード・バランサで終了され、HTTPリクエストのみがOracle HTTP Serverインスタンスに転送されます。このガイドでは、ロード・バランサとOracle HTTP Serverインスタンスとの間、およびWeb層とアプリケーション層との間のSSL構成については説明していません。
ロード・バランサは、Webサーバーの1つが停止した場合に残りの稼働中のWebサーバーにリクエストがルーティングされるようにすることで、高可用性を実現します。
また、標準的な高可用性構成では、メインのロード・バランシング装置で障害が発生した場合にホット・スタンバイ・デバイスがすぐにサービスを再開できるように、複数のハードウェア・ロード・バランサが構成されます。多種のサービスおよびシステムにとってハードウェア・ロード・バランサは呼出しを行う唯一のアクセス・ポイントとなり、保護されていない場合にはシステム全体の単一障害点(SPOF)となるため、このことは重要です。
親トピック: ハードウェア・ロード・バランサ(LBR)の目的
障害時リカバリおよびマルチデータセンターのトポロジにおけるロード・バランサの考慮事項
前項で説明したローカル・サイト・トラフィックのロード・バランシング機能に加えて、LBRの多くでは、DRまたはアクティブ/アクティブMDCトポロジの複数サイト間でグローバル・ロード・バランシングを構成する機能も用意されています。
-
アクティブ/パッシブDR: サイト1が使用不可でないかぎりリクエストを常にサイト1に送信します(使用不可の場合は、サイト2にトラフィックを送信します)。
-
アクティブ/アクティブMDC: たいていはサイトの物理的な地理的位置に関連するソース・リクエストの地理的位置に基づいて、リクエストをサイト1およびサイト2に常に送信します。アクティブ/アクティブ・デプロイメントは、その機能をサポートしているアプリケーションでしか使用できません。
Application entry point: app.example.com
Site 1 - Local Load Balancer Virtual Host: site1app.example.com
Site 2 - Local Load Balancer Virtual Host: site2app.example.com
app.example.com
に対するリクエストを受信した場合、グローバル・ロード・バランサは、次のように動作します。
-
トポロジがアクティブ/パッシブDRの場合:
DNSで
app.example.com
のIPアドレスを変更し、アクティブなサイトのローカル・ロード・バランサ仮想ホストのIPアドレスとして解決します。たとえば:site1app.example.com
(アクティブなサイトと仮定する)。 -
トポロジがアクティブ/アクティブMDCの場合:
DNSで
app.example.com
のIPアドレスを変更し、リクエストを送信したクライアントにどちらのサイトが近いかによって、site1app.example.com
またはsite2app.example.com
のIPアドレスとして解決します。
障害時リカバリに関する詳細は、ディザスタ・リカバリ・ガイドを参照してください。
各種Fusion Middleware製品のマルチデータ・センター・トポロジの詳細は、Oracle Technology NetworkのWebサイトで、「MAA Best Practices for Fusion Middleware」を参照してください。
親トピック: ハードウェア・ロード・バランサ(LBR)の目的
Oracle MFT IntegrationのSFTPリクエスト
MFTがデプロイされている場合、ロード・バランサは、DMZ内の様々なOTDインスタンスにわたりsFTPリクエストをロード・バランシングする、TCP仮想サーバーを構成する必要もあります。sFTPプロトコルは、このエンタープライズ・デプロイメント・ガイドにおいては、MFTのファイル転送を提供するために使用されるセキュア・プロトコルです。『Oracle Managed File Transferの使用』でFTPおよびsFTPサーバーの埋込みに関する項を参照してください。
親トピック: ハードウェア・ロード・バランサ(LBR)の目的
アプリケーション層のコンポーネント間特有の内部専用通信
さらに、ハードウェア・ロード・バランサは、Oracle Fusion Middlewareコンポーネントとアプリケーション層のアプリケーション間に特有の通信をルーティングします。内部専用のリクエストも、ロード・バランサを介してルーティングされます(一意の仮想ホスト名を使用する)。
親トピック: ハードウェア・ロード・バランサ(LBR)の目的
標準的なロード・バランサの仮想サーバー名のサマリー
サーバー上のロードのバランシングと高可用性の提供のために、ハードウェア・ロード・バランサは一連の仮想サーバー名を認識するように構成されています。図2-1に示した命名規則を使用すると、このトポロジではハードウェア・ロード・バランサによって次の仮想サーバー名が認識されます。
-
product.example.com
: この仮想サーバー名は、すべての受信トラフィックに使用されます。ユーザーは、このURLを入力して、デプロイしたOracle Fusion Middleware製品、およびこのサーバー上で使用可能なカスタム・アプリケーションにアクセスします。その後、ロード・バランサによってそれらのリクエストが(ロード・バランシング・アルゴリズムを使用して)Web層内のサーバーの1つにルーティングされます。このようにすることで、1つの仮想サーバー名を使用してトラフィックを複数のサーバーにルーティングすることが可能になり、Webサーバー・インスタンスのロード・バランシングと高可用性が実現されます。
-
productinternal.example.com
: この仮想サーバー名は、内部通信専用です。ロード・バランサは、そのネットワーク・アドレス変換(NAT)機能を使用して、アプリケーション層コンポーネントからこのURLへの内部通信をすべてルーティングします。このURLは、インターネット上の外部顧客またはユーザーには公開されていません。各製品の内部URLの使用目的はそれぞれ固有であるため、このデプロイメント手順では、仮想サーバー名の先頭に製品名を付けています。
-
admin.example.com
: この仮想サーバー名は、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server管理コンソール・インタフェースにアクセスする必要がある管理者用です。このURLは、内部管理者のみが知っています。また、ロード・バランサのNAT機能を使用することで、管理者はドメイン内のアクティブな管理サーバーにルーティングされます。
自身のトポロジに対して定義する必要がある仮想サーバー名の完全なセットについては、製品固有のトポロジが記載されている章を参照してください。
親トピック: ハードウェア・ロード・バランサを介したリクエストの受信
外部仮想サーバー名に対するHTTPSリクエストとHTTPリクエストの対比
ハードウェア・ロード・バランサを構成する場合は、メインの外部URL (たとえば、http://myapplication.example.com
)をポート80およびポート443に割り当てることをお薦めします。
ポート80 (非SSLプロトコル)に対するリクエストはすべて、ポート443 (SSLプロトコル)にリダイレクトする必要があります。このルールの例外としては、パブリックWSDLからのリクエストがあります。「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。
親トピック: ハードウェア・ロード・バランサを介したリクエストの受信
Web層の理解
参照用トポロジのWeb層は、ロード・バランサからリクエストを受信するWebサーバーで構成されています。標準的なエンタープライズ・デプロイメントでは、Web層に2つ以上のOracle HTTP Serverインスタンスまたは2つ以上のOracle Traffic Directorインスタンスが構成されています。次の各項で、詳細を説明します。
リクエストのルーティングにWeb層を使用する利点
Oracle HTTP ServerまたはOracle Traffic Directorを含むWeb層の使用は、多くのOracle Fusion Middleware製品の必要条件ではありません。アプリケーション層でハードウェア・ロード・バランサからWLSサーバーへ直接トラフィックをルーティングできます。ただし、Web層にはいくつかの利点があり、それが、参照用トポロジの一部としてお薦めする理由です。
-
Web層では、WebLogic Serverインスタンスで障害が発生した場合に、より迅速なフェイルオーバーが実現されます。プラグインは、障害が発生したWebLogic Serverインスタンスについて、ピアから得た情報を利用してアクティブに学習します。プラグインでは、障害の発生したサーバーについて、利用可能である旨の通知をピアから受けるまで回避を継続します。ロード・バランサは通常もっと限定されており、それを監視するにはオーバーヘッドが大きくなります。
-
Web層は、DMZパブリック・ゾーンを提供します。これは、セキュリティ監査における一般的な必要条件です。ロード・バランサがWebLogic Serverに直接ルーティングを行うと、リクエストがロード・バランサからアプリケーション層に1回のHTTPジャンプで移動するため、セキュリティ上の問題を引き起こす可能性があります。
-
Web層では、Webサーバー構成を変更することなく、WebLogic Serverクラスタ・メンバーシップを再構成(新規サーバーの追加とサーバーの削除)できます(構成したリスト内のサーバーのいくつかがアライブであることが条件)。
-
Oracle HTTP ServerはWebLogic Serverより効率的かつ高速に静的コンテンツを提供します。また、Oracle HTTP Server構成ファイルによる仮想ホストおよびプロキシの作成機能も提供します。静的コンテンツをキャッシュするようにOracle Traffic Directorを構成できます。これにより、バック・エンドのサーバーの負荷を削減し、クライアントのパフォーマンスを向上できます。
-
Web層は、WebLogic Serverが提供する機能に加えてHTTPリダイレクションを提供します。Oracle HTTP ServerまたはOracle Traffic Directorを多様なWebLogic Serverクラスタのフロント・エンドとして使用でき、場合によっては、コンテンツ・ベースのルーティングを使用してルーティングを制御できます。
-
Oracle HTTP Serverは、エンタープライズ・デプロイメントにシングル・サインオン機能を統合する機能を提供します。たとえば、Oracle Identity and Access Management製品ファミリの一部であるOracle Access Managerを使用して、後からシングル・サインオンをエンタープライズ・デプロイメントに実装できます。
-
Oracle HTTP ServerまたはOracle Traffic DirectorがあるWeb層は、WebLogic Server内にデプロイされているWebSocket接続のサポートを提供します。
-
Oracle Traffic Directorは、一部のエンタープライズ・デプロイメントに必要なFTP/SFTPサービスを提供するTCPプロキシとして機能できます。
ノート:
リリース12.2.1.4.0以降、Oracle Traffic Directorは非推奨になりました。SOAエンタープライズ・デプロイメント・アーキテクチャにOracle HTTP Serverを使用することを強くお薦めします。Oracle Traffic Directorは、Oracle Managed File TransferのFTPサービスやSFTPサービスなど、TCPルーティングを必要とする非常に特定のユースケースでのみ使用してください。「エンタープライズ・デプロイメントでのOracle Managed File Transferの構成」を参照してください。
Oracle HTTP Serverの詳細は、『Oracle HTTP Serverの管理』のOracle HTTP Serverの概要に関する項を参照してください。
Oracle Traffic Directorの詳細は、『Oracle Traffic Directorの管理』のOracle Traffic Directorの概要に関する項を参照してください。
親トピック: Web層の理解
Web層の使用にかわる方法
Web層はエンタープライズ・トポロジに様々な利点をもたらしますが、中間層でハードウェア・ロード・バランサから管理対象サーバーへリクエストを直接ルーティングする方法もサポートされています。
この方法には、次の利点があります。
-
フロントエンドOracle HTTP ServerのWeb層フロントエンドを使用するよりも構成と処理のオーバーヘッドが小さい。
-
管理対象サーバーごとに固有のURLを監視するようにLBRを構成できるので、アプリケーション・レベルでの監視が可能(Oracle HTTP Serverでは不可能)。
このロード・バランサ機能を使用して、SOAコンポジット・アプリケーションのURLを監視することもできます。この場合、すべてのコンポジットがデプロイされたときにのみ管理対象サーバーへのルーティングが可能になります。また、適切な監視ソフトウェアを使用する必要があります。
親トピック: Web層の理解
Web層でのOracle HTTP Serverの構成
Oracle Fusion Middleware 12c以降、Oracle HTTP Serverソフトウェアは、既存のOracle WebLogic Serverドメインの一部としてまたは独自のスタンドアロン・ドメインで、の2つの方法のいずれかで構成できるようになりました。各構成には固有の利点があります。
Oracle HTTP Serverインスタンスを既存のWebLogic Serverドメインの一部として構成する場合、Oracle Enterprise Manager Fusion Middleware Controlの使用によるWebサーバーとOracle WebLogic Server管理対象サーバーとの間の通信のワイヤリングなど、Oracle HTTP Serverインスタンスの管理が可能です。Oracle HTTP Serverをスタンドアロン構成で構成する場合、Oracle HTTP Serverインスタンスをアプリケーション層ドメインとは別個に構成および管理できます。
このエンタープライズ・デプロイメント・ガイドでは、各Web層ホストに1つずつ、別個のスタンドアロン・ドメインとしてOracle HTTP Serverインスタンスを構成する方法について説明します。「エンタープライズ・デプロイメント用のOracle HTTP Serverの構成」を参照してくださいOracle HTTP Serverインスタンスをアプリケーション層ドメインの一部として構成するのではなく、この方法をお薦めします。
『Oracle HTTP Serverのインストールと構成』の、Oracle HTTP Serverについてに関する項を参照してください。
親トピック: Web層の理解
Mod_WL_OHSについて
ダイアグラムに示すように、Oracle HTTP Serverインスタンスは、Oracle HTTP Serverからアプリケーション層のOracle WebLogic Server管理対象サーバーへのHTTPリクエストのプロキシに、WebLogicプロキシ・プラグイン(mod_wl_ohs
)を使用します。
『Oracle WebLogic Serverプロキシ・プラグインの使用』の、Oracle WebLogic Serverプロキシ・プラグインに関する項を参照してください。
親トピック: Web層の理解
アプリケーション層の理解
アプリケーション層は2つの物理ホスト・コンピュータで構成されており、そこにOracle WebLogic ServerおよびOracle Fusion Middleware製品がインストールされて構成されます。アプリケーション層のコンピュータは、ファイアウォール1とファイアウォール2の間のセキュリティ保護されたゾーンに配置されます。
詳細は、次の各項を参照してください。
管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成
ドメイン内の管理対象サーバーとは異なり、管理サーバーはアクティブ/パッシブ高可用性構成を使用します。これは、Oracle WebLogic Serverドメイン内で実行できる管理サーバーは1つのみであるためです。
トポロジ・ダイアグラムでは、HOST1上の管理サーバーがアクティブな状態で、HOST2上の管理サーバーがパッシブ(非アクティブ)の状態です。
システム障害時に管理サーバーの手動フェイル・オーバーをサポートする標準的なエンタープライズ・デプロイメント・トポロジには、次のものが含まれます。
-
管理サーバーのリクエストのルーティング用の仮想IPアドレス(VIP)
-
共有記憶域デバイス上の管理サーバー・ドメイン・ディレクトリの構成
システム障害(HOST1の障害など)が発生した場合、管理サーバーのVIPアドレスをドメイン内の別のホストに手動で再割当てし、管理サーバーのドメイン・ディレクトリをその新しいホストにマウントして、新しいホスト上で管理サーバーを起動できます。
ただし、管理サーバーと違い、管理対象サーバーを共有記憶域に格納するメリットはありません。実際に、管理対象サーバーの構成データをホスト・コンピュータのローカル・ディスクに格納しないと、パフォーマンスに影響するおそれがあります。
したがって、標準的なエンタープライズ・デプロイメントでは、管理サーバーのドメインを共有記憶域上で構成すると、ドメイン構成のコピーが各ホスト・コンピュータのローカル記憶域デバイスに配置され、このドメイン構成のコピーから管理対象サーバーが起動されます。このコピーの作成には、Oracle WebLogic Serverのpackおよびunpackユーティリティを使用します。
結果として、各ホストに別個のドメイン・ディレクトリを配置する構成となります。つまり、管理サーバー(共有記憶域上)と管理対象サーバー(ローカル記憶域上)に1つずつ配置します。必要なアクションに応じて、いずれかのドメイン・ディレクトリから構成タスクを実行する必要があります。
管理サーバーのドメイン・ディレクトリと管理対象サーバーのドメイン・ディレクトリの構造、およびこれらのディレクトリの参照に使用する変数の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。
複数ドメイン・ディレクトリ・モデルには、他にも利点があります。管理サーバーを管理対象サーバーから分離できます。デフォルトのプライマリ・エンタープライズ・デプロイメント・トポロジでは、アプリケーション層のホストの1つに管理サーバーのドメイン・ディレクトリが存在することを想定していますが、管理サーバーによるCPUまたはRAMの消費量が多いときなど、必要な場合は、管理サーバーを独自のホストから実行することでさらに分離できます。管理者によっては、管理サーバーを別個の専用ホストに構成することを好みますが、複数ドメイン・ディレクトリ・モデルではそれを実現できます。
親トピック: アプリケーション層の理解
アプリケーション層でのOracle Web Services Managerの使用
Oracle Web Services Manager (Oracle WSM)は、エンタープライズ・デプロイメント・トポロジにおけるWebサービスの管理と保護を目的としたポリシー・フレームワークを提供します。
ほとんどのエンタープライズ・デプロイメント・トポロジでは、Oracle Web Services Manager Policy Managerは、アクティブ/アクティブの高可用性構成でデプロイできる、別のクラスタ内の管理対象サーバー上で実行されます。
影響を理解していれば、Oracle Web Services ManagerおよびFusion Middleware製品またはアプリケーションを同じクラスタにターゲット設定できます。
Oracle Web Services Managerを専用の管理対象サーバーにデプロイする主な理由は、パフォーマンスと可用性の分離性を高めるためです。Oracle Web Services Managerは、多くの場合、ドメイン内のカスタムWebサービスやその他の製品およびコンポーネントにポリシーを提供します。この場合、Oracle Web Services Managerの追加アクティビティがOracle Web Services Managerと同じ管理対象サーバーまたはクラスタを共有するアプリケーションのパフォーマンスに影響を及ぼすことは望ましくありません。
スケール・アウトやスケール・アップのプロセスが発生した場合でも、コンポーネント同士が分離されていれば、より適切な対応が可能です。他の製品に影響を及ぼすことなく、製品がデプロイされているFusion Middlewareアプリケーション管理対象サーバーのみ、またはOracle Web Services Managerがデプロイされている管理対象サーバーのみをスケール・アウトしたりスケール・アップしたりできます。
親トピック: アプリケーション層の理解
アプリケーション層におけるクラスタとホストの構成のベスト・プラクティスとバリエーション
標準的なエンタープライズ・デプロイメントでは、アプリケーション層内の2つ以上のホスト上にあるクラスタで管理対象サーバーを構成します。特定のOracle Fusion Middleware製品について、エンタープライズ・デプロイメント参照トポロジは、管理対象サーバー数、クラスタ数、および各クラスタをターゲットとするサービスに関するベスト・プラクティスを示しています。
これらのベスト・プラクティスは、各製品の標準的なパフォーマンス、メンテナンスおよびスケールアウトの各要件を考慮したものです。その結果、管理対象サーバーは、ドメイン内の適切なクラスタ・セットにグループ化されます。
エンタープライズ・デプロイメント・トポロジのバリエーションとして、特定の製品またはコンポーネントを追加のクラスタまたはホストにターゲット設定できます。これにより、パフォーマンスと独立性が向上します。
たとえば、管理サーバーを別個の小規模なホスト・コンピュータでホストして、FMWコンポーネントおよび製品を管理サーバーから隔離することを検討できます。
別の例として、Oracle SOA Suiteデプロイメントで、Oracle SOA SuiteとOracle Service Busを別々のホストにデプロイできます。同様に、Oracle Business Activity MonitoringとOracle Enterprise Schedulerを別のホスト・コンピュータ上にある別のクラスタにターゲット設定できます。
トポロジのこれらのバリエーションはサポートされていますが、エンタープライズ・デプロイメント参照トポロジでは、高可用性、スケーラビリティおよびセキュリティに留意しながら最小のハードウェア・リソースを使用します。各種サーバーのシステム要件と、システムが対応する必要のある負荷に応じて、適切なリソース・プランニングおよびサイジングを実施してください。これらの決定に基づいて、これらのバリエーションをインストールおよび構成するステップを、このガイドに記載の説明から適切に変更する必要があります。
SOAエンタープライズ・デプロイメントは、静的クラスタベースのトポロジと、動的クラスタベースのトポロジの2種類をサポートしています。静的クラスタは、構成済クラスタとも言い、各サーバー・インスタンスを手動で構成して追加する従来型のクラスタです。動的クラスタは、アプリケーションのリソース・ニーズを満たすように動的にスケール・アップできるサーバー・インスタンスで構成されます。動的クラスタは、指定した数の生成された(動的)サーバー・インスタンスの構成を定義する単一のサーバー・テンプレートを使用します。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。これにより、追加のサーバー容量が必要になったときに、動的クラスタ内のサーバー・インスタンスの数をスケール・アップできます。動的サーバーは、最初に手動で構成してそれらをクラスタに追加する必要なく起動できます。
複合クラスタ(動的サーバー・インスタンスと構成済サーバー・インスタンスの両方を備えたクラスタ)は、SOAエンタープライズ・デプロイメントではサポートされません。
親トピック: アプリケーション層の理解
標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について
Oracle Fusion Middleware 12c以降、ドメインごとのノード・マネージャまたはホストごとのノード・マネージャを使用できます。次の各項では、標準的なエンタープライズ・デプロイメントでのノード・マネージャ構成の影響について詳しく説明します。
ノート:
これらの2つのタイプのノード・マネージャについての一般情報は、『Oracle WebLogic Serverノード・マネージャの管理』の概要に関する項を参照してください。
ドメインごとのノード・マネージャ構成の使用について
ドメインごとのノード・マネージャ構成では、ホストごとのノード・マネージャ構成とは異なり、管理サーバー・ホスト上で実際に2つのノード・マネージャ・インスタンスを起動します。1つは管理サーバーのドメイン・ディレクトリから、もう1つは管理対象サーバーのドメイン・ディレクトリから起動します。さらに、トポロジ内の他のホストで、別個のノード・マネージャ・インスタンスが実行されます。
管理サーバーを制御するノード・マネージャでは、管理サーバー用に作成された仮想ホスト名のリスニング・アドレスが使用されます。管理対象サーバーを制御するノード・マネージャでは、物理ホストのリスニング・アドレスが使用されます。管理サーバーが別のホストにフェイルオーバーすると、フェイルオーバー・ホスト上の管理サーバーを制御するために、ノード・マネージャの追加のインスタンスが起動されます。
ドメインごと構成の主な利点は、ノード・マネージャの初期設定が容易かつ簡易であることと、管理サーバーに固有のノード・マネージャ・プロパティを設定できることです。後者は、前のリリースでは重要でした。クラッシュ・リカバリなど一部の機能が、管理サーバーにのみ適用され、管理対象サーバーには適用されていなかったためです。現在のリリースでは、Oracle SOA Suite製品に対して、サーバー全体の移行ではなく自動サービス移行を構成できます。これは、管理サーバーだけでなく管理対象サーバーもクラッシュ・リカバリを利用できるため、管理サーバー・ドメイン・ディレクトリと管理対象サーバー・ドメイン・ディレクトリに異なるプロパティを適用する必要がないということです。
もう1つの利点は、ドメインごとのノード・マネージャでは、各ドメインに作成されたデモ・アイデンティティ・ストアに基づいて、ノード・マネージャとサーバーとの通信にデフォルトのSSL構成が提供される点です。
ホストごとのノード・マネージャ構成の使用について
ホストごとのノード・マネージャ構成では、単一のノード・マネージャ・インスタンスを起動して、管理サーバー、およびホスト上のすべての管理対象サーバー(別のドメインに配置されているものも含む)を制御します。これにより、特に同一コンピュータ上に複数のドメインが共存する場合に、管理サーバー・ホストでのフットプリントおよびリソース使用率が削減されます。
ホストごとのノード・マネージャ構成では、すべてのノード・マネージャが任意のリスニング・アドレスを使用できるため、ノード・マネージャはホスト上で使用可能なすべてのアドレスでリスニングします。これは、管理サーバーが新しいホストにフェイルオーバーする際に、追加の構成が必要ないことを意味します。ホストごとの構成では、各ホストで複数のノード・マネージャ・プロパティ・ファイルではなく単一のノード・マネージャ・プロパティ・ファイルを更新および保守できるため、保守が簡易化されます。
ホストごとのノード・マネージャ構成では、追加の構成ステップが必要になります。ノード・マネージャとサーバーとの通信にSSLが必要な場合は、追加のアイデンティティ・ストアおよびトラスト・ストアを構成する必要があり、またノード・マネージャは複数のアドレスでリスニングするため、Subject Alternate Names (SAN)を使用する必要もあります。なお、2つのファイアウォールで保護されているため、通常はアプリケーション層にSSL通信は必要ありません。
親トピック: アプリケーション層の理解
アプリケーション層内での通信のためのユニキャストの使用について
エンタープライズ・デプロイメントにおける管理対象サーバーとOracle WebLogic Serverクラスタ内のホストの間の通信にはユニキャスト通信プロトコルをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。
独自のデプロイメントでマルチキャストかユニキャストのどちらのプロトコルを使用するかを検討するときは、ネットワークの種類、クラスタ内のメンバー数、およびクラスタ・メンバーシップの信頼性要件を考慮してください。また、各プロトコルが持つ次の機能も考慮してください。
エンタープライズ・デプロイメントにおけるユニキャストの機能:
-
グループ・リーダーを使用し、このリーダーにすべてのサーバーがメッセージを直接送信します。このリーダーは、他のすべてのグループ・メンバーと他のグループ・リーダー(該当する場合)にメッセージを再送信する役割を担います。
-
ほとんどのネットワーク・トポロジでそのまま動作します。
-
ネットワーク・トポロジに関係なく、追加の構成は不要です。
-
単一の欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。
エンタープライズ・デプロイメントにおけるマルチキャストの機能:
-
マルチキャストは、より拡張性の高いピア・ツー・ピア・モデルを採用します。このモデルでは、サーバーが各メッセージを一度だけネットワークに直接送信し、各クラスタ・メンバーがネットワークからメッセージを直接受信することをネットワークが保証します。
-
クラスタ・メンバーが単一のサブネット内にある最近のほとんどの環境で、そのまま動作します。
-
クラスタ・メンバーが複数のサブネットにまたがっている場合は、ルーターとWebLogic Server (マルチキャストTTL)でさらに構成が必要です。
-
連続する3つの欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。
どちらのモデルがより適切に動作するかは、クラスタ内のサーバー数と、基礎となるアプリケーションにとってクラスタ・メンバーシップが不可欠かどうか(たとえば、セッション・レプリケーションを大量に行うアプリケーションや、クラスタ全体でRMI呼出しが大量に発生するクラスタなど)によって異なります。
使用するトポロジがアクティブ/アクティブ型の障害時リカバリ・システムに参加するかどうか、またクラスタが複数のサブネットを横断するどうかを考慮してください。一般に、これらの場合にはユニキャストの方がより適切に動作します。
マルチキャストとユニキャストの通信タイプの詳細は、次の資料を参照してください。
-
『Oracle WebLogic Serverクラスタの管理』のユニキャストを使用した1対多通信に関する項
親トピック: アプリケーション層の理解
OPSSおよび認証ストアと認可ストアへのリクエストの理解
Oracle Fusion Middleware製品およびコンポーネントの多くでは、認証プロバイダ(アイデンティティ・ストア)、ポリシー、資格証明、キーストアおよび監査データのためにOracle Platform Security Services (OPSS)セキュリティ・ストアが必要です。結果として、アプリケーション層とセキュリティ・プロバイダとの間でリクエストを送受信できるように通信を有効化する必要があります。
認証の場合、この通信は、一般的にポート389または636で通信するOracle Internet Directory (OID)、Oracle Unified Directory (OUD)などのLDAPディレクトリ宛てです。Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダを使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用する必要があります。
認可(およびポリシー・ストア)の場合、層によってセキュリティ・ストアの位置が異なります。
-
アプリケーション層では、認可ストアはデータベース・ベースです。したがって、必要なOPSSデータを取得するために、Oracle WebLogic Server管理対象サーバーからデータベースへの頻繁な接続が必要になります。
-
Web層では、認可ストアはファイル・ベースです。したがって、データベースへの接続は必要ありません。
OPSSセキュリティ・ストアの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の次の項を参照してください:
親トピック: アプリケーション層の理解
標準的なエンタープライズ・デプロイメントでのCoherenceクラスタについて
標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントには、記憶域が有効な管理対象Coherenceサーバーを含むCoherenceクラスタが含まれます。Oracle FMW製品は、ドメインの作成または拡張中に、そのクラスタをデフォルトのCoherenceクラスタにメンバーとして追加します。
この構成はCoherenceの使用の適切な出発点です。特定の要件によっては、本番環境でのパフォーマンスを向上させるためにCoherenceをチューニングして再構成することを検討してください
ノート:
ほとんどのOracle Fusion Middleware製品にはCoherence GARデプロイメントが含まれます。これらのデプロイメントには、デフォルトのCoherenceクラスタ構成に関する特定の要件(ローカル・キャッシュまたは分散キャッシュなど)がある場合があります。Coherenceクラスタ構成の変更に関する特有の制限や処理については、適切な製品のインストールおよび管理ガイドを参照してください。
ポートの割当てを確認する際、Oracle Fusion Middleware製品およびコンポーネントが、構成ウィザードの「Coherenceクラスタ」画面で指定されたポートを使用するウェル・ノウン・アドレス(WKA)リストにデフォルト設定されていることに注意してください。WKAリストでは、coherenceクラスタに参加しているすべてのサーバーのリスニング・アドレスも、WKAリストのリスニング・アドレスとして使用されます。これらの設定は、WLS管理コンソールを使用してカスタマイズできます。
リスニング・アドレスについては、Coherenceクラスタはネットワーク通信に別のサービスとプロトコルを使用します。デフォルトのサービスとそのバインド・ポイントは次のとおりです。
-
検出サービス - クラスタを含む別のサービスを検出する役割を果たします。ワイルドカード・アドレスにデフォルト設定されています(つまり、すべてのアドレスをリスニングします)。操作構成のcoherence/cluster-config/unicast-listener/discovery-address (通常は未設定)によって構成できます。
-
クラスタリング/TCMP - クラスタ間通信の役割を果たします。WKAリストにルーティング可能なローカル・アドレスにデフォルト設定されています。つまり、エンタープライズ・デプロイメント・トポロジのSOAHOST1とSOAHOST2のIPに設定されています。操作構成のcoherence/cluster-config/unicast-listener/address (通常は未設定)によって構成できます。
-
拡張プロキシ - クラスタ化されていないクライアントとの通信の役割を果たします。検出アドレスにデフォルト設定されています。キャッシュのcache-config/caching-schemes/proxy-scheme/acceptor-config/tcp-acceptor/local-address (通常は未設定)によって構成できます。
詳細は、次のマニュアルを参照してください。
-
Coherenceクラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』の「Coherenceクラスタの構成と管理」を参照してください。
-
Coherenceのチューニングの詳細は、『Oracle Coherenceの管理』の「パフォーマンス・チューニング」を参照してください。
-
CoherenceにおけるHTTPセッション・データの格納の詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』のWebLogicサーバーでのCoherence*Webの使用を参照してください。
-
Coherenceアプリケーションの作成およびデプロイの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』の「WebLogic Server用Coherenceアプリケーションの作成」と「WebLogic ServerでのCoherenceアプリケーションのデプロイ」を参照してください。
-
Coherenceリスニング・アドレスの詳細は、『Oracle Coherenceでのアプリケーションの開発』の要素のリファレンスに関する項とキャッシュの構成に関する項を参照してください。
親トピック: アプリケーション層の理解
データ層について
データ層では、Oracle RACデータベースは2つのホスト(DBHOST1とDBHOST2)上で実行されます。データベースには、Oracle SOA SuiteコンポーネントとOracle Platform Security Services (OPSS)ポリシー・ストアが必要とするスキーマが含まれています。
エンタープライズ・デプロイメントでは製品およびコンポーネントごとに複数のサービスを定義することで、スループットとパフォーマンスの分離および優先順位の決定ができます。このガイドでは、例として1つのデータベース・サービスを使用します。また、データベースを保護する他の高可用性データベース・ソリューションも使用できます。
-
Oracle Data Guard: Oracle Data Guard概要および管理のOracle Data Guardの概要を参照してください。
-
Oracle RAC One Node: Oracle Real Application Clusters管理およびデプロイメント・ガイドのOracle RAC One Nodeの概要に関する項を参照してください。
これらのソリューションは、エンタープライズ・デプロイメントに一般に適用されるスケーラビリティと可用性の要件を満たす場合、Oracle RACデータベースの使用に重点を置いたこのガイドに記載されている情報以上のデータベース保護を実現します。
高可用性環境でのOracleデータベースの使用の詳細は、『高可用性ガイド』の「データベースに関する考慮事項」を参照してください。