1. Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの理解
  3. 標準的なエンタープライズ・デプロイメントについて

2 標準的なエンタープライズ・デプロイメントについて

標準的なエンタープライズ・デプロイメント・トポロジのコンポーネントを理解することが不可欠です。

この章では、エンタープライズ・デプロイメント・トポロジのダイアグラムについて説明します。

上位トピック: 「エンタープライズ・デプロイメントの理解」

標準的なエンタープライズ・デプロイメントのダイアグラム

このダイアグラムは、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントのすべてのコンポーネントを示しています。すべてのエンタープライズ・デプロイメントは、これらの基本原則に基づいています。

すべてのOracle Fusion Middlewareエンタープライズ・デプロイメントは、Oracle Fusion Middleware本番環境のインストールと構成に関するベスト・プラクティスを示すように設計されています。

ベスト・プラクティス・アプローチは、複数層デプロイメントと、異なるソフトウェア層間の標準的通信の基本概念で始まります。

図2-1に、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントを示します。すべてのエンタープライズ・デプロイメントは、これらの基本原則に基づいています。

標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで通信に使用される各層と標準プロトコルの説明は、標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムについてを参照してください。

図2-1 標準的なエンタープライズ・デプロイメント・トポロジのダイアグラム

図2-1の説明が続きます
「図2-1 標準的なエンタープライズ・デプロイメント・トポロジのダイアグラム」の説明

親トピック: 標準的なエンタープライズ・デプロイメントについて

標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムについて

標準的なエンタープライズ・デプロイメント・トポロジは、ハードウェア・ロード・バランサ(LBR)、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 Server管理対象サーバーのクラスタとドメイン用の管理サーバーをホストする複数の物理コンピュータで構成されています。管理対象サーバーは、エンタープライズ・デプロイメントで選択する製品に応じて、様々なOracle Fusion Middleware製品(Oracle SOA Suite、Oracle Service Bus、Oracle WebCenter Content、Oracle WebCenter Portalなど)を実行するように構成されています。

  • データ層。Oracle RACデータベースをホストする2つ以上の物理ホストで構成されています。

親トピック: 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムについて

ハードウェア・ロード・バランサを介したリクエストの受信

ここでは、ハードウェア・ロード・バランサと、エンタープライズ・デプロイメントにおけるその役割について説明します。

親トピック: 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムについて

ハードウェア・ロード・バランサ(LBR)の目的

ロード・バランサには、ローカル・ロード・バランサとグローバル・ロード・バランサの2つのタイプがあります。ロード・バランサは、Big IP、Cisco、Brocadeなどのハードウェア・デバイスの場合もあれば、Oracle Traffic Directorなどのソフトウェア・アプリケーションの場合もあります。ほとんどのロード・バランサ・アプライアンスは、ローカルとグローバルの両方のロード・バランサに対して構成できます

ロード・バランサは、いずれのロード・バランサも単一点障害にならないように常にペアでデプロイする必要があります。ほとんどのロード・バランサでは、これをアクティブ/パッシブ手法で実現しています。これを実現する最善の方法については、ロード・バランサに関するドキュメントを参照する必要があります。

ノート:

Oracleでは、特定のロード・バランサに対する動作保証をしていません。エンタープライズ・デプロイメント・ガイドに記載されているロード・バランサの構成情報はあくまでも参考用であるため、使用しているデバイスの構成に関連するベスト・プラクティスについてはロード・バランサのベンダーに問い合せる必要があります。

ローカル・ロード・バランサは、サイト内でトラフィックを分散するために使用します。これは、HTTPトラフィックとTCPトラフィックの両方を分散でき、デプロイメントの要件により、使用する必要があるオプションが決まります。多くの場合、ローカル・ロード・バランサには、SSLの暗号化と復号化を加速する機能とともに、SSLリクエストを終了またはオフロードする機能が用意されています。ロード・バランサでのSSL終了により、アプリケーションのパフォーマンスが大幅に向上するため、デプロイメント自体でのオンザフライ方式のソフトウェア暗号化のオーバーヘッドなしに、サイトとのトラフィックのやり取りが暗号化された状態を保持できます。エンタープライズ・デプロイメント・ガイドの環境では、常にローカル・ロード・バランサを使用します。

グローバル・ロード・バランサは、同じ論理環境として機能させるサイトが複数ある場合に使用します。その目的は、事前に決定されたルール・セットに基づいてサイト間でリクエストを分散することにあります。グローバル・ロード・バランサは通常、障害時リカバリ(DR)デプロイメントまたはアクティブ/アクティブ・マルチデータ・センター(MDC)デプロイメントで使用されます。

次の各項では、エンタープライズ・デプロイメントでハードウェア・ロード・バランサによって処理されるリクエストのタイプについて説明します。

インターネットから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)となるため、このことは重要です。

アプリケーション層のコンポーネント間特有の内部専用通信

さらに、ハードウェア・ロード・バランサは、Oracle Fusion Middlewareコンポーネントとアプリケーション層のアプリケーション間に特有の通信をルーティングします。内部専用のリクエストも、一意の仮想ホスト名を使用してロード・バランサ経由でルーティングされます。

障害時リカバリ・トポロジおよびマルチデータ・センター・トポロジのロード・バランサに関する考慮事項

前のトピックで説明したローカル・サイト・トラフィック用のロード・バランシング機能以外にも、多くのLBRには、DRまたはアクティブ/アクティブMDCトポロジ内の複数のサイト全体にわたるグローバル・ロード・バランシングを構成するための項目も含まれています。

グローバル・ロード・バランサ構成では、条件付きDNSを使用して別のサイトのローカル・ロード・バランサにトラフィックをルーティングします。Oracle Fusion Middlewareのグローバル・ロード・バランサは通常、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アドレスとして解決しますが、どちらのサイトを使用するかは、どちらがリクエストを行うクライアントに近いかによって決まります。

障害時リカバリの詳細は、『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』を参照してください。

様々なFusion Middleware製品のマルチデータ・センター・トポロジの詳細は、Oracle Technology Network Webサイトの「Fusion MiddlewareのMAAのベスト・プラクティス」ページを参照してください。

標準的なロード・バランサの仮想サーバー名のサマリー

サーバー上のロードのバランシングと高可用性の提供のために、ハードウェア・ロード・バランサは一連の仮想サーバー名を認識するように構成されています。図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サーバーが含まれます。標準的なエンタープライズ・デプロイメントでは、2つ以上のOracle HTTP ServerインスタンスがWeb層に構成されます。次の各項で、詳細を説明します。

親トピック: 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムについて

リクエストのルーティングにOracle HTTP Serverインスタンスを使用する利点

Oracle HTTP Serverを含むWeb層の使用は、多くのOracle Fusion Middleware製品の必要条件ではありません。アプリケーション層でハードウェア・ロード・バランサからWLSサーバーへ直接トラフィックをルーティングできます。ただし、Web層にはいくつかの利点があり、それが、参照用トポロジの一部としてお薦めする理由です。

  • Web層はDMZパブリック・ゾーンを提供します。これはセキュリティ監査における一般的な必要条件です。ロード・バランサがWebLogic Serverに直接ルーティングを行うと、リクエストがロード・バランサからアプリケーション層に1回のHTTPジャンプで移動するため、セキュリティ上の問題を引き起こす可能性があります。

  • Web層では、Webサーバー構成を変更することなく、WebLogic Serverクラスタ・メンバーシップを再構成(新規サーバーの追加とサーバーの削除)できます(構成したリスト内のサーバーのいくつかがアライブであることが条件)。

  • Oracle HTTP ServerはWebLogic Serverより効率的かつ高速に静的コンテンツを提供します。また、一部のエンタープライズ・デプロイメントに必要なFTPサービス、およびOracle HTTP Server構成ファイルによる仮想ホストおよびプロキシの作成機能も提供します。

  • Oracle HTTP Serverは、WebLogic Serverが提供する機能に加えてHTTPリダイレクションを提供します。Oracle HTTP Serverを多様なWebLogic Serverクラスタのフロント・エンドとして使用でき、場合によっては、コンテンツ・ベースのルーティングを実行してルーティングを制御できます。

  • Oracle HTTP Serverは、エンタープライズ・デプロイメントにシングル・サインオン機能を統合する機能を提供します。たとえば、Oracle Identity and Access Management製品ファミリの一部であるOracle Access Managerを使用して、後からシングル・サインオンをエンタープライズ・デプロイメントに実装できます。

  • Oracle HTTP Serverは、WebLogic Server内にデプロイされているWebSocket接続のサポートを提供します。

Oracle HTTP Serverの詳細は、『Oracle Fusion Middleware Oracle HTTP Serverの管理』のOracle HTTP Serverの概要に関する項を参照してください。

親トピック: Web層の理解

Web層でのOracle HTTP Serverの構成

Oracle Fusion Middleware 12c以降、Oracle HTTP Serverソフトウェアは2つの方法のいずれか(既存のOracle WebLogic Serverドメインの一部または専用スタンドアロン・ドメイン)で構成できるようになりました。それぞれの構成にはそのメリットがあります。

Oracle HTTP Serverインスタンスを既存のWebLogic Serverドメインの一部として構成すると、Oracle Enterprise Manager Fusion Middleware Controlを使用して、WebサーバーとOracle WebLogic Server管理対象サーバー間の通信のワイヤリングなど、Oracle HTTP Serverインスタンスの管理を実行できます。Oracle HTTP Serverをスタンドアロン構成で構成すると、Oracle HTTP Serverインスタンスをアプリケーション層ドメインと個別に構成して管理できます。

このエンタープライズ・デプロイメント・ガイドでは、Oracle HTTP Serverインスタンスは各Web層ホストに1つずつ個別のスタンドアロン・ドメインとして構成されます。Oracle HTTP Serverインスタンスをアプリケーション層ドメインの一部として構成するように選択できますが、このエンタープライズ・デプロイメント・ガイドではその方法でOracle HTTP Serverインスタンスを構成するステップは説明しません。

『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Serverプロキシ・プラグインの使用12.2.1.1』の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 Fusion Middleware 12c以降では、ドメインごとのノード・マネージャまたはホストごとのノード・マネージャのいずれかを使用できます。次の項では、典型的なエンタープライズ・デプロイメントでのノード・マネージャ構成の影響について詳しく説明します。

ノート:

これらの2つのタイプのノード・マネージャについての一般情報は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャの管理』の概要に関する項を参照してください。

ドメインごとのノード・マネージャ構成の使用について

ドメインごとのノード・マネージャ構成では、ホストごとのノード・マネージャ構成とは異なり、実際に管理サーバー上で2つのノード・マネージャ・インスタンスを起動します。1つは管理サーバーのドメイン・ディレクトリから、もう1つは管理対象サーバーのドメイン・ディレクトリから起動します。また、個別のノード・マネージャ・インスタンスが、トポロジのそれ以外の各ホストで実行します。

管理サーバーを制御するノード・マネージャでは、管理サーバー用に作成された仮想ホスト名のリスニング・アドレスが使用されます。管理対象サーバーを制御するノード・マネージャでは、物理ホストのリスニング・アドレスが使用されます。管理サーバーがもう1つのホストにフェイルオーバーすると、ノード・マネージャの追加のインスタンスが起動され、フェイルオーバー・ホスト上の管理サーバーを制御します。

ドメインごとの構成の大きなメリットは、ノード・マネージャの初期設定が容易かつ単純であること、管理サーバーに固有のノード・マネージャ・プロパティを設定できることです。以前のリリースでは、クラッシュ・リカバリなど一部の機能は管理対象サーバーには適用されず、管理サーバーのみに適用されたため、後者の機能が重要でした。現在のリリースでは、Oracle SOA Suite製品はサーバー全体の移行ではなく自動サービス移行を行うように構成できます。つまり、管理対象サーバーも管理サーバーと同様にクラッシュ・リカバリを利用できるため、管理サーバーのドメイン・ディレクトリと管理対象サーバーのドメイン・ディレクトリに異なるプロパティを適用する必要がありません。

もう1つのメリットは、ドメインごとのノード・マネージャでは、各ドメインに作成されるデモ・アイデンティティ・ストアに基づいて、ノード・マネージャとサーバーとの通信にデフォルトでSSL構成が提供されることです。

ホストごとのノード・マネージャ構成の使用について

ホストごとのノード・マネージャ構成では、単一のノード・マネージャ・インスタンスを起動して、ホスト上の管理サーバーおよびすべての管理対象サーバーを、別のドメインに存在するものも含めて制御します。これにより、特に同じコンピュータに複数のドメインが共存する場合に、管理サーバー・ホストでのフットプリントおよびリソース使用率が削減されます。

ホストごとのノード・マネージャ構成を使用すると、すべてのノード・マネージャでANYのリスニング・アドレスを使用できるため、ノード・マネージャでホスト上の使用可能なすべてのアドレスがリスニングされます。つまり、管理サーバーが新しいホストにフェイルオーバーする際に、追加の構成は必要ありません。ホストごとの構成では保守が容易になります。複数のノード・マネージャ・プロパティ・ファイルではなく、各ホストで1つのノード・マネージャ・プロパティ・ファイルを更新および保守できるためです。

ホストごとのノード・マネージャ構成では、追加の構成ステップが必要になります。ノード・マネージャとサーバーの通信でSSLが必要な場合は、追加のアイデンティティおよび信頼ストアを構成する必要があります。また、ノード・マネージャが複数のアドレスでリスニングするためサブジェクト代替名(SAN)を使用する必要があります。アプリケーション層は2つのファイアウォールで保護されているため、通常、アプリケーション層ではSSL通信は必要ありません。

アプリケーション層内での通信のためのユニキャストの使用について

エンタープライズ・デプロイメントにおける管理対象サーバーとOracle WebLogic Serverクラスタ内のホストの間の通信にはユニキャスト通信プロトコルをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。

独自のデプロイメントでマルチキャストかユニキャストのどちらのプロトコルを使用するかを検討するときは、ネットワークの種類、クラスタ内のメンバー数、およびクラスタ・メンバーシップの信頼性要件を考慮してください。また、各プロトコルが持つ次の機能も考慮してください。

エンタープライズ・デプロイメントにおけるユニキャストの機能:

  • グループ・リーダーを使用し、このリーダーにすべてのサーバーがメッセージを直接送信します。このリーダーは、他のすべてのグループ・メンバーと他のグループ・リーダー(該当する場合)にメッセージを再送信する役割を担います。

  • ほとんどのネットワーク・トポロジでそのまま動作します。

  • ネットワーク・トポロジに関係なく、追加の構成は不要です。

  • 単一の欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。

エンタープライズ・デプロイメントにおけるマルチキャストの機能:

  • マルチキャストは、より拡張性の高いピア・ツー・ピア・モデルを採用します。このモデルでは、サーバーが各メッセージを一度だけネットワークに直接送信し、各クラスタ・メンバーがネットワークからメッセージを直接受信することをネットワークが保証します。

  • クラスタ・メンバーが単一のサブネット内にある最近のほとんどの環境でそのまま動作します。

  • クラスタ・メンバーが複数のサブネットにまたがっている場合は、ルーターとWebLogic Server (マルチキャストTTL)で追加構成が必要です。

  • 連続する3つの欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。

どちらのモデルの方がより適切に動作するかは、クラスタ内のサーバー数と、基礎となるアプリケーションにとってクラスタ・メンバーシップが不可欠かどうか(たとえば、セッション・レプリケーションを大量に行うアプリケーションやクラスタ全体でRMI呼出しが大量に発生するクラスタなど)によって異なります。

使用するトポロジがアクティブ/アクティブ型の障害時リカバリ・システムに参加するかどうか、またクラスタが複数のサブネットを横断するどうかを考慮してください。一般に、このような場合にはユニキャストの方がより適切に動作します。

マルチキャストおよびユニキャスト通信タイプの詳細は、次のリソースを参照してください。

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 Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護』の次の項を参照してください。

データ層について

データ層では、Oracle RACデータベースは2つのホスト(DBHOST1とDBHOST2)上で実行されます。データベースには、Oracle WebCenter ContentコンポーネントとOracle Platform Security Services (OPSS)ポリシー・ストアが必要とするスキーマが含まれています。

エンタープライズ・デプロイメントでは製品およびコンポーネントごとに複数のサービスを定義することで、スループットとパフォーマンスの分離および優先順位の決定ができます。このガイドでは、例として1つのデータベース・サービスを使用します。また、データベースを保護する他の高可用性データベース・ソリューションも使用できます。

これらのソリューションは、エンタープライズ・デプロイメントに一般に適用されるスケーラビリティと可用性の要件を満たす場合、Oracle RACデータベースの使用に重点を置いたこのガイドに記載されている情報以上のデータベース保護を実現します。

高可用性環境でのOracleデータベースの使用の詳細は、『Oracle Fusion Middleware高可用性ガイド』のデータベースの考慮事項に関する項を参照してください。

親トピック: 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムについて