| Oracle® Fusion Middleware Exalogicエンタープライズ・デプロイメント・ガイド ExalogicリリースX2-2、X3-2およびX5-2 E88001-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Exalogicエンタープライズ・デプロイメント・ガイド ExalogicリリースX2-2、X3-2およびX5-2 E88001-01 |
|
|
前 |
次 |
この章では、Oracle Fusion Middlewareエンタープライズ・デプロイメントをExalogicハードウェアにデプロイする標準的な方法を紹介し、説明します。
Oracle Exalogic上の特定の製品のデプロイメント・アーキテクチャに関する情報は、該当する製品固有のエンタープライズ・デプロイメント・ガイドを参照してください。
このガイドでは、Exalogicに製品をデプロイする際に考慮する必要のある事項の概要を説明します。このガイドでは、エンタープライズ・デプロイメントでOracle Fusion MiddlewareをデプロイするためのExalogicアプライアンスの設定に必要な手順を中心に説明します。このドキュメントでは、Oracle Fusion Middleware製品のインストール方法は説明しません。Oracle Fusion Middlewareのインストールの詳細は、デプロイする製品固有のエンタープライズ・デプロイメント・ガイドを参照してください。
Oracle Exalogicは、Oracleの高可用性、高性能の統合ハードウェア・アプライアンスです。Exalogicにデプロイすると、Oracle Fusion MiddlewareコンポーネントはExalogicの優れたネットワークの恩恵を受け、アプリケーションのスループットが向上します。
さらに、Oracle WebLogic Serverでは、Oracle Exalogic上でより高速に実行できるように、いくつかの最適化が行われています。これらの最適化により、デプロイされるアプリケーションのスループットがさらに向上します。
Oracle Fusion MiddlewareをExalogicにデプロイすることで、可用性とパフォーマンスを最大限に高める高可用性インフラストラクチャを確保できます。
このガイドでは、ExalogicにOracle Fusion Middlewareをデプロイするための2つの主要な参照トポロジを中心に説明します。インストールされるコンポーネントは本質的に同じですが、Exalogicアプライアンスの稼働方法はトポロジごとに異なります。
Exalogicの標準的なデプロイメントは、物理ExalogicデプロイメントとExalogic Elastic Cloudデプロイメントです。
物理Exalogicデプロイメント。このデプロイメント・タイプでは、Exalogic計算ノードのそのままの処理能力が直接使用されます。計算ノードの処理能力のため、単一の計算ノードにより多くの製品をデプロイすると、処理リソースを最大限に利用できます。
Exalogic Elastic Cloudデプロイメント。このデプロイメントでは、アプリケーションは計算ノードの基礎となる能力には直接アクセスできません。Exalogic Elastic Cloudデプロイメントでは、処理能力が仮想化されます。このデプロイメントにより、ユーザーは必要に応じて基礎となる計算ノード間を移動できる多数の仮想マシンを作成できます。このデプロイメントでは、製品は区分化されます。つまり、製品は多数の小さな仮想マシンに分かれています。
今後、このガイドでは、この2つの異なるタイプのデプロイメントを物理および仮想と呼びます。
これらのトポロジは、標準のプラットフォーム・トポロジに非常によく似ています。つまり、仮想Exalogicデプロイメントに適した分散トポロジと、物理Exalogicデプロイメントに適した統合トポロジがあります。しかし、3番目のトポロジがあり、それはExalogicにインストールされたいくつかのコンポーネントと、Exalogicマシン以外の一般的なハードウェアにインストールされたその他のWeb層を使用するハイブリッド・トポロジです。
実際の組織にインストールして構成するOracle Fusion Middlewareトポロジとは多少異なる場合もありますが、このガイドでは、3つの主要なトポロジについて、エンタープライズ・デプロイメント用のExalogic環境の設定に必要な手順を説明します。
次の項では、主要なExalogicエンタープライズ・デプロイメント・トポロジの図を示します。
注意:
次の各図では、HOST1やHOST2といった任意のホスト名を使用しています。これらの名前は、説明の目的でのみ使用しています。実際のデプロイメントでは、これらの名前はデプロイメントで使用されるホスト名を反映して変更されます。この項の内容は次のとおりです。
図2-1に、Oracle Traffic Directorを使用する物理Exalogicエンタープライズ・デプロイメント・トポロジを示します。
図2-1 Oracle Traffic Directorを使用する物理Exalogicデプロイメント
この図に示されている標準的な要素の説明は、「標準的なエンタープライズ・デプロイメント・トポロジの図の理解」を参照してください。
図2-2に、仮想Exalogicエンタープライズ・デプロイメント・トポロジを示します。
図2-2 標準的な仮想Exalogicトポロジ
この図に示されている標準的な要素の説明は、「標準的なエンタープライズ・デプロイメント・トポロジの図の理解」を参照してください。
図2-3に、Web層、アプリケーション層、データ層など、標準的なエンタープライズ・デプロイメントを示します。
図2-3 Web層を使用する標準的なエンタープライズ・デプロイメント
Oracle Fusion MiddlewareおよびExalogicのネットワークおよびエンタープライズ・デプロイメント・トポロジの要素に関する情報を提供します。
次の項では、標準的なエンタープライズ・デプロイメント・トポロジの図に関する概念的な情報を提供します。
Oracle Fusion MiddlewareをExalogicにデプロイすると、ほとんど(すべてではない)のコンポーネントがExalogicアプライアンス内にインストールされます。標準的なプラットフォーム・エンタープライズ・デプロイメントは、様々な層に配置されています。各層はファイアウォールで分離されています。
すべてのハードウェア・コンポーネントがExalogicアプライアンスに組み込まれているため、使用可能な層の数が減ります。
アプリケーション層やディレクトリ層は必要ありません。また、ExalogicアプライアンスがExadataアプライアンスにリンクされている場合、データ層は必要ありません。
エンタープライズ・デプロイメント・トポロジの図では、次の2つのゾーンが使用され、それぞれがファイアウォールで分離されています。
ロード・バランサが存在するDMZ。このゾーンには、ロード・バランサで定義されている仮想サーバー名でのみ、アクセスできます。
すべてのアプリケーション・コンポーネントが存在するExalogicゾーン。このゾーンでは、外部リソースへのアクセスを必要とするコンポーネントのみが企業のネットワーク上に表示されます。
このトポロジのよくあるバリエーションは、WebサーバーをDMZに移動するものです。これによりセキュリティが強化されます。
Exalogicの主な利点の1つは、高速で柔軟なネットワークです。Oracle Fusion MiddlewareをExalogicにデプロイする場合は、Oracle Exalogicネットワークの使用方法を検討する必要があります。
この項の内容は次のとおりです。
Exalogicアプライアンスには3つのタイプのネットワークがあります。
IP over Infiniband(IPoIB): これは、Exalogicアプライアンスの内部コンポーネントを接続する内部Infinibandネットワークです。このネットワークは高速ですが、外部の世界には接続できません。このネットワークの利点は、ネットワーク・トラフィックを外部の世界に対して非公開とすることを保証するために使用できることです。このネットワークを使用することのマイナス面は、外部コンポーネントからExalogicアプライアンス内のアプリケーション・コンポーネントに直接アクセスできないことです。
イーサネット管理ネットワーク(eth0): この管理ネットワークは、組込みのイーサネット・ネットワークを介してExalogicコンポーネントに接続するために使用されます。このネットワークは管理操作にのみ使用し、本番デプロイメントには使用しないでください。このネットワークは、Exalogicコンポーネントを構成するためのログインに使用されます。
Ethernet over Infiniband(EoIB): このネットワークもExalogic Infinibandネットワークを使用しますが、これは標準の企業のネットワークに接続することが可能です。これにより、外部コンポーネントはExalogic内部のコンポーネントと直接通信できます。このネットワークは、ハードウェア・ロード・バランサとOracle Traffic Director間の通信のため、常に使用されます。
デフォルトでは、Oracle Fusion Middleware内の一部のコンポーネントは、単一のネットワーク上でのみ通信します。WebLogic Managed ServerやOracle Traffic Directorなど、その他のコンポーネントは、内部ネットワークと外部ネットワークの両方で通信するように構成できます。
Oracle Traffic Directorは、Exalogicアプライアンスに入力されるトラフィックの優先ロード・バランサです。Oracle Traffic Directorはまた、Exalogic内に完全に配置されたデプロイメント用の優先Webサーバーです。
使用するExalogicネットワークを選択するときは、次の点を考慮してください。
外部Web層を使用する場合は、EoIBネットワークをリスニングし、IPoIBへルーティングするコンポーネントを構成する必要があります。
すべてのトラフィックがOracle Traffic Directorを経由し、Exalogicアプライアンスに到達したらその中に留まることが予想される場合は、コンポーネントがIPoIBネットワークを使用するように構成する必要があります。
すべてのLDAPトラフィックがExalogicアプライアンス内で発生すると予想される場合は、IPoIBネットワークを使用するようにLDAPサーバーを構成する必要があります。
データベースがExalogicアプライアンスに存在し、それが直接Exadataアプライアンスに接続されている場合は、IPoIBネットワークを使用する必要があります。
Exadataを使用してデータベースをホストしており、そのデータベースがExalogicソースと非Exalogicソースの両方からアクセスされる場合は、データベース・リスナーをIPoIBとEoIBの両方のネットワークをリスニングするように構成する必要があります。
異なるチャネルを使用して複数のネットワークでリスニングするようにWebLogic管理対象サーバーを構成する場合は、追加の構成が必要です。Exalogicネットワークの使用は、アクセス要件によって異なります。採用するソリューションは、内部ネットワークと外部ネットワークの両方の要素を含む可能性があります。
使用するネットワークに必須のルールはありません。あるものに他のものを重ねても、大幅なパフォーマンスの向上はありません。どちらのネットワークでも、すべてのコンポーネントが同じように機能します。
エンタープライズ・デプロイメント・トポロジは、ハードウェア・ロード・バランサ、Web層、アプリケーション層、ディレクトリ層、およびデータ層で構成されます。
エンタープライズ・デプロイメント・トポロジは、次の高レベル要素で構成されています。
ハードウェア・ロード・バランサは、インターネットからのリクエストをWeb層のWebサーバーにルーティングします。この場合のWebサーバーは、一般的なハードウェア上の外部Webサーバーか、Exalogicホスト内のOracle Traffic Directorのいずれかです。
Web層は、Webサーバー・インスタンス(ロード・バランシングと高可用性用)をホストする2つ以上のホスト・コンピュータで構成されます。Webサーバー・インスタンスは、(外部アイデンティティ・ストアおよびシングル・サインオン・サーバーを介して)ユーザーを認証し、HTTPリクエストをアプリケーション層で実行されているOracle Fusion Middleware製品およびコンポーネントにルーティングするように構成されます。Web層インスタンスは、外部ハードウェア・ロード・バランサを経由するリクエストを必要とせず、内部リクエストのロード・バランシングにも使用されます。通常、使用されるWebサーバーはOracle Traffic Directorで、外部Web層の場合はOracle HTTP Serverです。
アプリケーション層は、Oracle WebLogic Server管理対象サーバーのクラスタ、およびそのドメインのWebLogic管理サーバーをホストする2つ以上のホストで構成されます。管理対象サーバーは、Oracle Identity and Access ManagementやOracle SOA Suiteなど、様々なOracle Fusion Middleware製品を実行するように構成されます。
ディレクトリ層は、Oracle Unified Directoryなど、LDAP準拠のディレクトリをホストする2つ以上のサーバーで構成されます。
データ層は、Oracle RACデータベースをホストする2つ以上の物理ホスト、またはOracle RACデータベースをホストするExadataアプライアンスで構成されます。
注意:
この項では、標準的なエンタープライズ・デプロイメント・トポロジの様々な層について説明します。このガイドでは、層とは論理的な分離を意味します。一般的なデプロイメントでは、通常、各層はファイアウォールによって分離されています。しかし、ExalogicデプロイメントではトラフィックがExalogicマシンに限定されているため、これは必要ありません。Exalogicデプロイメントでは、通常、ファイアウォールはDMZとExalogicアプライアンスの間にのみ存在します。
エンタープライズ・デプロイメント・トポロジの前段にはハードウェア・ロード・バランサが配置され、ハードウェア・ロード・バランサはインターネットからWeb層への受信HTTPおよびHTTPSリクエストを振り分けます。
この項の内容は次のとおりです。
ハードウェア・ロード・バランサは、仮想ホスト名へのリクエストを受信し、ロード・バランシング・アルゴリズムに基づいて各リクエストをWebサーバー・インスタンスの1つにルーティングすることによって、Web層の負荷を分散します。
このようにして、ロード・バランサは、1つのWebサーバーにHTTPリクエストがオーバーロードされないようにします。
ハードウェア・ロード・バランサ上の特定の仮想ホスト名の目的の詳細は、「標準的なロード・バランサの仮想サーバー名の概要」を参照してください。
参照トポロジでは、HTTPリクエストのみがハードウェア・ロード・バランサからWeb層にルーティングされることに注意してください。Secure Socket Layer(SSL)リクエストは、ロード・バランサで終了します。
ロード・バランサは、1つのWebサーバーが使用できない場合、起動している残りのWebサーバーにリクエストをルーティングすることで、高可用性を実現します。
さらに、標準的な高可用性構成では、ハードウェア・ロード・バランサは、メインのロード・バランシング装置に障害が発生した場合に、ホット・スタンバイ装置がサービスを再開できるように構成されています。保護されていない場合、多くのタイプのサービスやシステムでは、ハードウェア・ロード・バランサが呼出しを行うための唯一のアクセス・ポイントとなり、その結果、システム全体にとっての単一障害点(SPOF)となるため、これは重要です。
Oracle Fusion Middlewareコンポーネントとアプリケーション層のアプリケーション間の通信は、Oracle Traffic Director(OTD)のロード・バランシング機能によって処理されます。
この項では、標準的なエンタープライズ・デプロイメントにおいて、ハードウェア・ロード・バランサおよびOracle Traffic Director(OTD)で認識される仮想サーバー名について説明します。
Webホストの負荷を分散し、高可用性を提供するために、ハードウェア・ロード・バランサは仮想サーバー名のセットを認識するように構成されています。
図に示すように、このトポロジ内のハードウェア・ロード・バランサによって、次の仮想サーバー名が認識されます。
product.example.com - この仮想サーバー名は、すべての受信トラフィックに使用されます。ユーザーは、このURLを入力して、このサーバーで使用可能なOracle Fusion Middleware製品およびカスタム・アプリケーションにアクセスします。ロード・バランサは、(ロード・バランシング・アルゴリズムを使用して)Web層内のいずれかのサーバーにこれらのリクエストをルーティングします。このように、ロード・バランシングおよびWebサーバー・インスタンスの高可用性のため、単一の仮想サーバー名を使用して複数のサーバーにトラフィックをルーティングできます。
admin.example.com - この仮想サーバー名は、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server Administration Consoleインタフェースにアクセスする必要のある管理者用です。このURLは内部の管理者のみが知っています。ロード・バランサのネットワーク・アドレス変換(NAT)機能を使用して、管理者をドメイン内のアクティブな管理サーバーにルーティングします。
これらの仮想サーバー名は、通常、企業のDNSで定義されています。product.example.comなどのインターネットに向けたエントリ・ポイントは、インターネットに公開されます。ただし、admin.example.comなどの管理仮想サーバーは、企業のネットワーク内でのみ解決可能です。
トポロジに定義する必要のある仮想サーバー名の完全なセットについては、製品のエンタープライズ・デプロイメント・ガイドの製品固有のトポロジを説明する章を参照してください。
内部コンポーネントの負荷を分散し、高可用性を実現するために、Oracle Traffic Director(OTD)は一連の仮想サーバー名を認識するように構成されています。
図に示すように、このトポロジ内のOTDによって、次の仮想サーバー名が認識されます。
edginternal.example.com - この仮想サーバー名は、内部通信専用です。ロード・バランサは、Network Address Translation(NAT)機能を使用して、イントラネットURLのhttp://edginternal.example.com/に向けられたアプリケーション層コンポーネントからの内部通信をルーティングします。このURLは、外部の顧客またはインターネット上のユーザーには公開されません。
idstore.example.com - この仮想サーバー名は、内部LDAP通信専用です。
OTDは、通常、内部ネットワークでこれらの仮想サーバーを有効にします。これらは、ローカル・ホストのエントリを使用してExalogicアプライアンス内でのみ解決可能です。
参照トポロジのWeb層は、2つのOracle Traffic Directorインスタンスで構成されています。
この項の内容は次のとおりです。
Oracle Fusion Middleware製品の多くでは、Oracle Traffic Director(OTD)を使用したWeb層は要件ではありません。ハードウェア・ロード・バランサからアプリケーション層のWebLogic Serverに直接トラフィックをルーティングできます。
ただし、Web層にはいくつかの利点があるため、参照トポロジの一部として推奨されます。
ロード・バランサがWebLogic Serverに直接ルーティングする場合、リクエストはロード・バランサからアプリケーション層に単一のHTTPジャンプで移動するため、セキュリティの問題が発生する可能性があります。前述の参照トポロジでは、アプリケーション層との通信は、ロード・バランサがアクセスできない内部Exalogicネットワークに限定されています。OTDを使用すると、アプリケーション層へのインタフェースが提供され、その層を企業のネットワークに公開しないという利点があります。
Web層を使用すると、Webサーバー構成を変更することなく、WebLogic Serverクラスタのメンバーシップを再構成(新規サーバーの追加やサーバーの削除)できます(構成済リスト内のサーバーの一部が稼働しているかぎり)。
Oracle Traffic Directorは、WebLogic Serverが提供するもの以上のHTTPリダイレクションを提供します。Oracle HTTP Serverは、様々なWebLogic Serverクラスタに対するフロント・エンドとして使用でき、場合によっては、コンテンツ・ベース・ルーティングによってルーティングを制御することもできます。
Oracle Traffic Directorは、内部リクエストのための内部ロード・バランサとして機能することにより、追加のセキュリティを提供します。
Oracle Traffic Directorにより、エンタープライズ・デプロイメントにシングル・サインオン機能を統合する機能が提供されます。たとえば、後で、Oracle Identity and Access ManagementのコンポーネントであるOracle Access Managerを使用して、エンタープライズ・デプロイメント用のシングル・サインオンを実装できます。
Oracle Fusion Middleware製品の多くでは、HTTP Serverを使用したWeb層は要件ではありません。ハードウェア・ロード・バランサからアプリケーション層のWebLogic Serverに直接トラフィックをルーティングできます。
ただし、Oracle HTTP Serverには次の利点があります。
Exalogicホストの外部の一般的なハードウェアにファイアウォールとともにOracle HTTP Serverを配置すると、Webサーバーとアプリケーション・サーバー間のセキュリティが強化されます。
Oracle HTTP Serverを使用して静的コンテンツをホストできます。
Oracle Traffic Director(OTD)は、エンタープライズ・デプロイメント・トポロジで様々な利点を提供しますが、Oracle HTTP Serverへの、またはハードウェア・ロード・バランサから直接中間層の管理対象サーバーへのルーティング・リクエストもサポートされています。
直接アクセスの利点は次のとおりです。
Web層のフロント・エンドとしてOracle HTTP Serverフロント・エンドを使用する場合よりも、構成および処理のオーバーヘッドが削減されます。
管理対象サーバーごとに特定のURLをモニターするようにロード・バランサを構成できるため、アプリケーション・レベルでモニタリング可能です(OTDでは不可能な機能)。
このロード・バランサ機能を使用して、SOAコンポジット・アプリケーションのURLをモニターできます。これによって管理対象サーバーへのルーティングが可能になるのは、すべてのコンポジットがデプロイされている場合のみであるため、適切なモニタリング・ソフトウェアを使用する必要があることに注意してください。
どちらの方法も、内部コンポーネントをEoIBネットワークに公開する必要があります。これにより、Web層とExalogic層との間にファイアウォールをプロビジョニングできます。このアプローチのマイナス面は、Exalogicアプライアンス内のすべてのコンポーネントを外部ネットワーク上に表示する必要があることです。
Oracle Traffic Director(OTD)は、アプリケーションと同じ計算ノードにデプロイされているものとして示されています。これにより、OTDインスタンスは特定のアプリケーション・トラフィックを適切なアプリケーション層にルーティングし、計算ノード自体の計算能力を最大限に活用できます。
これに対する別のアプローチは、OTDを専用の計算ノードにデプロイし、Exalogicアプライアンス全体にサービスを提供することです。
たとえば、Oracle Identity Management、Oracle SOA SuiteおよびOracle WebCenterの3つのアプリケーションがデプロイされている場合、共通のOTDインスタンスを使用して、デプロイされているすべてのアプリケーションにリクエストをルーティングできます。これはサポートされている構成です。個々の製品のエンタープライズ・デプロイメント・ガイドでは、簡略化のため、専用のOTDデプロイメントを使用しています。
仮想デプロイメントでは、Oracle Traffic Directorを専用のvServerに配置することをお薦めします。
このデプロイメントでは、OTDクラスタを特定のアプリケーション・デプロイメントの専用にでき、管理が容易になります。別の配布グループを作成することで、2つのOTDインスタンスが、同じ基礎となる計算ノード上で実行されないようにできます。
ロード・バランサは、リクエストをOracle HTTP Serverにルーティングするのと同じ方法で、リクエストをOracle Traffic Director(OTD)に直接ルーティングできます。Oracle Traffic Directorを使用する場合は、ロード・バランサのモニタリングによってOracle Traffic Directorインスタンスの応答の有無を判断します。
内部のテストでは、フェイルオーバー検出のより高速な方法が使用可能であることが示されています。これには、2つの外部OTDフェイルオーバー・グループの作成が必要です。この方法を使用すると、ロード・バランサはOTDインスタンス自体ではなく、これらの外部フェイルオーバー・グループにリクエストを送信できます。OTDフェイルオーバー・グループが使用されると、内部のOTDハートビートがOTDインスタンスの障害を検出するために使用されます。障害が検出されるとすぐに、存続しているインスタンスが、障害が発生したインスタンスからの処理リクエストを引き継ぎます。このフェイルオーバー検出方法は、通常、ロード・バランサによるフェイルオーバー検出に依存するよりも高速です。
アプリケーション層は、Oracle WebLogic ServerおよびOracle Fusion Middleware製品がインストールおよび構成されている2つ以上のホストで構成されています。
アプリケーション層ホストは、Exalogicアプライアンス内にあります。
この項の内容は次のとおりです。
ドメイン内の管理対象サーバーとは異なり、管理サーバーはアクティブ-パッシブ高可用性構成を使用します。
これは、Oracle WebLogic Serverドメイン内で実行できるのは、1つの管理サーバーのみであるためです。
トポロジ図では、HOST1上の管理サーバーはアクティブ状態にあり、HOST2上の管理サーバーはパッシブ(非アクティブ)状態にあります。
システム障害が発生した場合の管理サーバーの手動フェイルオーバーをサポートするため、標準的なエンタープライズ・デプロイメント・トポロジには次のものが含まれます。
管理サーバーのリクエストのルーティング用の仮想IPアドレス(VIP)
共有ZFS記憶域デバイス上の管理サーバー・ドメイン・ディレクトリの構成。
Exalogicアプライアンス以外の管理サーバーにアクセスする必要がない場合、管理サーバーに使用するVIPは内部ネットワーク上にある必要があります。ただし、t3リクエストやDMSモニタリングなどのために管理サーバーに直接外部からアクセスする場合は、外部ネットワークで構成する必要があります。
システム障害(たとえば、HOST1の障害)が発生した場合は、管理サーバーのVIPアドレスをドメイン内の別のホストに手動で再割当てし、管理サーバーのドメイン・ディレクトリを新規ホストにマウントし、新規ホストで管理サーバーを起動します。
ただし、管理サーバーとは異なり、管理対象サーバーを共有記憶域に格納するメリットはありません。実際、管理対象サーバーの構成データがホスト・コンピュータのローカル・ディスクに格納されていないと、ディスク競合の問題によってパフォーマンスに影響する可能性があります。Exalogicデプロイメントでは、ZFSアプライアンスに各ホストに排他的にマウントされるプライベート・ファイル・システムを作成することで、これが実現されます。
その結果、標準的なエンタープライズ・デプロイメントでは、管理サーバー・ドメインを共有記憶域に構成した後、ドメイン構成のコピーが各ホスト・コンピュータのローカル・ストレージ・デバイスに置かれ、このドメイン構成のコピーから管理対象サーバーが起動されます。このコピーは、Oracle WebLogic Serverのパックおよびアンパック・ユーティリティを使用して作成します。
結果の構成は、ホストごとに別々のドメイン・ディレクトリで構成され、1つは管理サーバー用(共有記憶域上)、1つは管理対象サーバー用(ローカル記憶域上)です。必要なアクションに応じて、1つのドメイン・ディレクトリまたは他のドメイン・ディレクトリから構成タスクを実行する必要があります。
管理サーバーのドメイン・ディレクトリおよび管理対象サーバーのドメイン・ディレクトリの構造、これらのディレクトリの参照に使用される変数の詳細は、「エンタープライズ・デプロイメントのディレクトリ構造の理解」を参照してください。
複数ドメイン・ディレクトリ・モデルのもう1つのメリットは、管理対象サーバーから管理サーバーを分離できることです。
エンタープライズ・デプロイメントでは、Oracle WebLogic Serverクラスタ内の管理対象サーバーとホスト間の通信にユニキャスト通信プロトコルを使用することをお薦めします。
マルチキャスト通信とは異なり、ユニキャストはネットワーク間の構成を必要とせず、マルチキャスト・アドレスの競合から発生する潜在的なネットワーク・エラーも減少します。
独自のデプロイメントでマルチキャストまたはユニキャスト・プロトコルの使用を検討する場合は、ネットワークのタイプ、クラスタ内のメンバー数、およびクラスタ・メンバーシップの信頼性要件を考慮してください。また、各プロトコルの次の利点も考慮してください。
エンタープライズ・デプロイメントにおけるユニキャストの利点または特性:
すべてのサーバーが直接メッセージを送信するグループ・リーダーを使用します。このリーダーは、必要な場合、他のすべてのグループ・メンバーおよび他のグループのリーダーにメッセージを再送信する責任があります。
ほとんどのネットワーク・トポロジですぐに使用できます。
ネットワーク・トポロジにかかわらず、追加の構成は必要ありません。
1つのハートビートの欠落を使用して、クラスタ・メンバーシップ・リストからサーバーを削除します。
エンタープライズ・デプロイメントにおけるマルチキャストの利点または特性:
マルチキャストは、スケーラビリティの高いピアツーピア・モデルを使用し、このモデルでは、サーバーが各メッセージをいったんネットワークに直接送信し、ネットワークは各クラスタ・メンバーがネットワークから直接メッセージを受信するようにします。
クラスタ・メンバーが単一のサブネット内に存在する最新の環境で、すぐに使用できます。
クラスタ・メンバーが複数のサブネットにまたがる場合は、ルーターおよびWebLogic Serverで追加の構成が必要です(つまり、マルチキャストTTL)。
3つ連続するハートビートの欠落を使用して、クラスタ・メンバーシップ・リストからサーバーを削除します。
クラスタ内のサーバーの数、および基礎となるアプリケーション(たとえば、セッション・レプリケーション集約型アプリケーションやクラスタ全体で集中的なRMI呼出しが発生するクラスタ)にとってクラスタ・メンバーシップがクリティカルであるかどうかによって、各モデルの動作が向上する場合があります。
トポロジをアクティブ-アクティブ・ディザスタ・リカバリ・システムに含めるかどうか、またはクラスタが複数のサブネットを横断するかどうかを検討します。一般的に、ユニキャストはそのような場合に、より適切に動作します。
ほとんどのOracle Fusion Middlewareコンポーネントでは、どちらの形式の通信も使用できます。しかし、いずれか1つの形式に制限されているものもあります。必要に応じて、製品固有のガイドを参照してください。
Oracle Fusion Middleware製品およびコンポーネントの多くでは、認証プロバイダ(アイデンティティ・ストア)、ポリシー、資格証明、キーストアおよび監査データ用のOracle Platform Security Services(OPSS)セキュリティ・ストアが必要です。
そのため、アプリケーション層がセキュリティ・プロバイダとの間でリクエストを送受信できるように、通信を有効にする必要があります。
認証の場合、この通信は、Oracle Internet Directory(OID)またはOracle Unified Directory(OUD)などのLDAPディレクトリとの間で、通常はポート1389または1636を介して行われます。Oracle Fusion Middlewareドメインを構成すると、そのドメインはデフォルトでWebLogic認証プロバイダを使用するように構成されます。ただし、エンタープライズ・デプロイメントの場合、専用の集中管理されたLDAP準拠認証プロバイダを使用する必要があります。
Exalogicデプロイメントでは、LDAPディレクトリはアプライアンスの内側にあり、LDAPサーバーの通信は、通常、内部Exalogicネットワークを介して行われます。
認可(およびポリシー・ストア)の場合、セキュリティ・ストアの場所は層によって異なります。
アプリケーション層では、認可ストアはデータベース・ベースであり、必要なOPSSデータを取得するために、Oracle WebLogic Server管理対象サーバーからデータベースへの頻繁な接続が必要です。
Web層の場合、認可ストアはファイル・ベースであり、データベースへの接続は必要ありません。
OPSSセキュリティ・ストアの詳細は、「Oracle Platform Security Servicesによるアプリケーションのセキュリティ保護」の次の項を参照してください。
認証の基本
OPSSポリシー・モデル
標準のOracle Fusion Middlewareエンタープライズ・デプロイメントには、ストレージ対応のManaged Coherence ServerのあるCoherenceクラスタが含まれています。
この構成がCoherenceを使用する場合の出発点となりますが、特定の要件に応じてCoherenceのチューニングと再構成を検討し、本番環境でのパフォーマンスを向上させたり、ポートの競合を解決したりできます。
ポートの割当てを確認する際、Oracle Fusion Middleware製品およびコンポーネントは、デフォルトで、構成ウィザードの「Coherence Clusters」画面で指定されたポートを使用するウェル・ノウン・アドレス(WKA)リストに設定されていることに注意してください。また、WKAリストでは、Coherenceクラスタに参加しているすべてのサーバーのリスニング・アドレスがWKAリストのリスニング・アドレスとして使用されます。
ExalogicでCoherenceクラスタを構成する場合、通常、内部ネットワークを使用するようにCoherenceクラスタが構成されます。
これらの設定は、WebLogic Server管理コンソールを使用してカスタマイズできます。
詳細は、次のリソースを参照してください。
Coherenceクラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』の「Coherenceクラスタの構成と管理」を参照してください。
Coherenceのチューニングの詳細は、『Oracle Coherenceの管理』を参照してください。
CoherenceでのHTTPセッション・データ格納の詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』の「Coherence*WebをWebLogic Serverで使用する」を参照してください。
Coherenceアプリケーションの作成およびデプロイの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。
デフォルトでは、WebLogic Serverは外部ネットワークを使用するようにセッション・レプリケーションを構成します。Exalogicにデプロイする場合、Sockets Direct Protocol(SDP)を利用する追加のレプリケーション・チャネルを構成することで、よりよいスループットを得ることができます。
詳細は、「クラスタ・レベルのセッション・レプリケーション拡張機能の有効化」を参照してください。
Oracle Fusion Middleware製品は、多くの場合、LDAPディレクトリとやりとりします。前項の図は、そのようなトポロジでLDAPディレクトリにアクセスする方法を示しています。
これを図に含める目的は、Exalogicアプライアンス内にLDAPディレクトリを含めることによって、ネットワークがどのように影響を受けるかを示すことです。
これは一例にすぎず、すべての製品がLDAPディレクトリのインストールを必要とすること、またはすべての製品がLDAPディレクトリとやりとりすることを前提としていません。その製品がLDAPとやりとりするかどうかは、個々の製品のガイドを参照してください。Exalogic内でLDAPディレクトリを設定する方法の詳細は、Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイドを参照してください。
Exalogicマシンの内部にLDAPディレクトリがある場合。通常、ディレクトリは内部IPoIBネットワークをリスニングするように構成されます。LDAPインスタンスへのリクエストは、Oracle Traffic Directorを介してロード・バランシングされます。Exalogicマシンの外部にLDAPディレクトリが構成されている場合、ディレクトリとの通信はEoIBネットワーク経由で行われ、ハードウェア・ロード・バランサを介してロード・バランシングされます。
データ層では、Oracle RACデータベースが2つのホスト(DBHOST1とDBHOST2)上で実行されます。データベースには、Oracle Fusion Middlewareコンポーネントに必要なスキーマ、およびOracle Platform Security Services(OPSS)ポリシー・ストアが含まれています。
エンタープライズ・デプロイメント内で、様々な製品およびコンポーネントに対して複数のサービスを定義して、スループットとパフォーマンスを分離し、優先順位を付けられます。このガイドでは、例として1つのデータベース・サービスが使用されています。Exalogicデプロイメントでは、データベースは、任意の標準イーサネット・ネットワークを介してアクセス可能なハードウェア上、またはInfinibandを介してExalogicに直接接続されたExadataシステム上で実行できます。
さらに、他の高可用性データベース・ソリューションを使用してデータベースを保護することもできます。
Oracle Data Guardの詳細は、『Oracle Data Guard概要および管理』を参照してください
Oracle RAC One Nodeの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracle RAC One Nodeの概要に関する項を参照してください
前述のソリューションでは、このガイドで提供される情報を超えてデータベースが保護されています。このガイドでは、エンタープライズ・デプロイメントに標準的に適用されるスケーラビリティと可用性の要件を考慮して、Oracle RACデータベースの使用を中心に説明しています。
高可用性環境でのOracle Databaseの使用の詳細は、『高可用性ガイド』の「データベースに関する考慮事項」を参照してください。
Exalogic仮想デプロイメントでは、物理サーバーは仮想サーバーに置き換えられます。
仮想サーバーにアプリケーションをデプロイする場合、様々なデプロイメント・オプションを検討できます。
単一のインスタンスまたはvServerごとに実行されるJVMを使用して、より小さい仮想サーバーを作成します。このアプローチの利点は、必要に応じて個々のJVMを拡張するのが簡単なことです。
依存する複数のアプリケーションを、一緒に、より大きなvServerに配置します。たとえば、各ドメインに属するコンポーネント群をより大きなvServerに配置するなどです。このアプローチの利点は、ドメイン機能の全体をスケールアウトするのが簡単なことです。
vServerのサイズを変更すると、vServerでホストされているJVMまたはインスタンスの合計メモリー要件が加算され、vServerオーバーヘッド用に2GBが追加されます。
Oracle Weblogic Serverには、Oracle Fusion Middleware製品がExalogicインフラストラクチャを最大限に活用するためのいくつかの拡張機能が含まれています。
これらの拡張機能を有効にすると、Fusion Middlewareインストールのパフォーマンスが向上します。拡張機能の完全なリストは、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のExalogic環境用のWebLogic Serverのチューニングに関する項を参照してください。
