| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.3.0) E61956-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.3.0) E61956-03 |
|
前 |
次 |
この章では、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントの全般的な特徴について説明します。ここで説明する概念は、どの製品固有のエンタープライズ・デプロイメントにも適用できます。
この章の構成は、次のとおりです。
すべてのOracle Fusion Middlewareエンタープライズ・デプロイメントは、Oracle Fusion Middleware本番環境のインストールと構成に関するベスト・プラクティスを示すように設計されています。
ベスト・プラクティス・アプローチは、複数層デプロイメントと、異なるソフトウェア層間の標準的通信の基本概念で始まります。
図1-1は、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントを示しています。
標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで通信に使用される各層と標準プロトコルの説明は、第1.2項「標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解」を参照してください。
次の項では、標準的なエンタープライズ・トポロジ・ダイアグラムについて詳しく説明します。
トポロジは、ファイアウォールによって隔てられている、次のようないくつかのセキュリティ・ゾーンに分かれています。
ファイアウォールは、特定の通信ポートを介した場合にのみデータ転送が許可されるように構成されています。これらのポート(または、場合によってはファイアウォール内の開いているポートを必要とするプロトコル)は、ダイアグラム内の各ファイアウォール・ライン上に示しています。
次に例を示します。
Web層を保護しているファイアウォールでは、HTTPポート、つまりHTTPS用のポート443とHTTP用のポート80のみが開いています。
アプリケーション層を保護しているファイアウォールでは、Oracle WebLogic Serverノード・マネージャ、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エンタープライズ・デプロイメント・トポロジにおいて開いておく必要があるポートの全リストは、実装するトポロジについて説明している章を参照するか、実装するトポロジのエンタープライズ・デプロイメント・ワークブックを参照してください。詳細は、LINK TO CHAPTERを参照してください。
エンタープライズ・デプロイメント・トポロジは、大まかに次の層で構成されます。
ハードウェア・ロード・バランサ。インターネットからのリクエストをWeb層内のWebサーバーにルーティングします。また、社内ネットワーク内で内部呼出しを実行する内部クライアントや他のコンポーネントからのリクエストもルーティングします。
Web層。Webサーバー・インスタンスをホストする2つ以上の物理コンピュータで構成されています(ロード・バランシングと高可用性のため)。
Webサーバー・インスタンスは、ユーザーを認証し(外部アイデンティティ・ストアおよびシングル・サインオン・サーバーを使用)、HTTPリクエストを、アプリケーション層内で実行されているOracle Fusion Middleware製品とコンポーネントにルーティングするように構成されています。
また、Webサーバー・インスタンスは、アプリケーション・ロジックの提供を必要としない静的Webコンテンツをホストします。このようなコンテンツをWeb層に配置することで、アプリケーション・サーバーのオーバーヘッドが低減され、不要なネットワーク・アクティビティが排除されます。
アプリケーション層。Oracle WebLogic Server管理対象サーバーのクラスタとドメイン用の管理サーバーをホストする2つ以上の物理コンピュータで構成されています。管理対象サーバーは、Oracle SOA SuiteとOracle Service Busなどの様々なOracle Fusion Middleware製品を実行するように構成されています。
データ層。Oracle RACデータベースをホストする2つ以上の物理ホストで構成されています。
標準的なエンタープライズ・トポロジでは、ハードウェア・ロード・バランサによってインターネットからの受信HTTPおよびHTTPSリクエストがWeb層に送られます。さらに、ハードウェア・ロード・バランサは、Oracle Fusion Middlewareコンポーネントとアプリケーション層のアプリケーション間に特有の通信をルーティングします。内部専用のリクエストも、ロード・バランサを介してルーティングされます(一意の仮想ホスト名を使用する)。詳細については、次の情報を参照してください。
ハードウェア・ロード・バランサは、次のタイプのリクエストをルーティングします。
ハードウェア・ロード・バランサは、1つの仮想ホスト名へのリクエストを受信して各リクエストをロード・バランシング・アルゴリズムに基づいてWebサーバー・インスタンスの1つにルーティングすることで、Web層でのロードをバランシングします。このようにして、ロード・バランサは、特定のWebサーバーがHTTPリクエストによってオーバーロードにならないようにします。
ハードウェア・ロード・バランサの特定の仮想ホスト名の用途の詳細は、第1.2.3.2項「標準的なロード・バランサの仮想サーバー名のサマリー」を参照してください。
参照用トポロジでは、HTTPリクエストのみがハードウェア・ロード・バランサからWeb層にルーティングされます。Secure Socket Layer (SSL)リクエストはロード・バランサで終了され、HTTPリクエストのみがOracle HTTP Serverインスタンスに転送されます。このガイドでは、ロード・バランサとOracle HTTP Serverインスタンス間およびWeb層とアプリケーション層間のSSL構成について説明していません。
ロード・バランサは、Webサーバーの1つが停止した場合に残りの稼働中のWebサーバーにリクエストがルーティングされるようにすることで、高可用性を実現します。
また、標準的な高可用性構成では、メインのロード・バランシング装置で障害が発生した場合に、パッシブ・ロード・バランサがホット・スタンバイとして機能してすぐにサービスを再開できるように、1つのアクティブ/パッシブ構成内に2つのハードウェア・ロード・バランサが構成されます。多種のサービスおよびシステムにとってハードウェア・ロード・バランサは呼出しを行う唯一のアクセス・ポイントとなり、保護されていない場合にはシステム全体の単一障害点となるため、このことは重要です。
さらに、ハードウェア・ロード・バランサは、Oracle Fusion Middlewareコンポーネントとアプリケーション層のアプリケーション間に特有の通信をルーティングします。内部専用のリクエストも、ロード・バランサを介してルーティングされます(一意の仮想ホスト名を使用する)。
サーバー上のロードのバランシングと高可用性の提供のために、ハードウェア・ロード・バランサは一連の仮想サーバー名を認識するように構成されています。ダイアグラムに示すように、このトポロジではハードウェア・ロード・バランサによって次の仮想サーバー名が認識されます。
<product>.example.com: この仮想サーバー名はすべての受信トラフィックに使用されます。
ユーザーは、このURL (http://myapplication.example.com)を入力して、このサーバー上で使用可能なOracle Fusion Middleware製品およびカスタム・アプリケーションにアクセスします。その後、ロード・バランサによってそれらのリクエストが(ロード・バランシング・アルゴリズムを使用して)Web層内のサーバーの1つにルーティングされます。このようにすることで、1つの仮想サーバー名を使用してトラフィックを複数のサーバーにルーティングすることが可能になり、Webサーバー・インスタンスのロード・バランシングと高可用性が実現されます。
edginternal.example.com: この仮想サーバー名は、内部通信専用です。
ロード・バランサは、そのネットワーク・アドレス変換(NAT)機能を使用して、アプリケーション層コンポーネントからhttp://edginternal.example.com/イントラネットURLへの内部通信をすべてルーティングします。このURLは、インターネット上の外部顧客またはユーザーには公開されていません。
admin.example.com: この仮想サーバー名は、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server管理コンソール・インタフェースにアクセスする必要がある管理者用です。
このURLは、内部管理者のみが知っています。また、ロード・バランサのNAT機能を使用することで、管理者はドメイン内のアクティブな管理サーバーにルーティングされます。
自身のトポロジに対して定義する必要がある仮想サーバー名の完全なセットについては、製品固有のトポロジが記載されている章を参照してください。
ポート80 (非SSLプロトコル)に対するリクエストはすべて、ポート443 (SSLプロトコル)にリダイレクトされます。このルールの例外としては、パブリックWSDLからのリクエストがあります。詳細は、第6.1項「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。
共有記憶域は、ファイル記憶域として使用し、サブスクライバのコンピュータにファイルを複製せずに複数のサブスクライバが同時にアクセスできるように、ネットワーク内のすべてのサブスクライバがアクセスできるディスク領域の割当てです。共有記憶域は、通常、ストレージ・エリア・ネットワーク(SAN)またはネットワーク接続記憶域サーバー(NAS)から提供されます。
ディスク・ボリュームまたは共有はSAN/NASに割り当てられたディスク領域で、通常はファイル・システムが含まれます。このボリュームは、必要に応じて個々のホスト・コンピュータにマウントされます。
アプリケーションで多数のディスク共有を使用する場合は、それらをプロジェクトまたはボリューム・グループにグループ化できます。プロジェクトの中では、複数の共有を1つの共有で共有ベースまたはまとめて管理できます。たとえば、SANまたはNASからバックアップおよびリカバリ用にスナップショットが提供される場合は、プロジェクト全体のスナップショットを作成すると、アプリケーションで実行したすべての処理を1つの単位にバックアップでき、個々の共有/ボリューム・レベルでスナップショットを作成すると、より正確なバックアップを作成できます。これは、構成情報が含まれる共有についてプロジェクト全体を毎月または毎日バックアップする場合など、バックアップ戦略の一部として使用できます。
共有は排他的または共有でマウントできます。
共有を排他的にマウントする場合は、ローカル記憶域を拡張します。つまり、一度に1つのホストのみにマウントして専用に使用します。これはローカル・ディスクを直接使用するよりも処理が遅くなりますが、SAN/NASのバックアップおよびリカバリの利点を利用できます。
共有マウントを複数のホストにマウントし、すべてのホストで共有への書込みおよび共有からの読取りを可能にします。各ホストが同じファイルに同時に書込みを行う共有マウントがある場合は、サービスで問題が発生する可能性があります。
参照用トポロジのWeb層は、2つのOracle HTTPインスタンスで構成されています。
Web層の詳細は、次の項を参照してください。
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接続のサポートを提供します。
Exalogicへのデプロイメントなど一部のデプロイメントでは、Oracle HTTP ServerのかわりにOracle Traffic Directorを使用できます。
Oracle HTTP Serverの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』の「Oracle HTTP Serverの概要」を参照してください。
Oracle HTTP Serverはエンタープライズ・トポロジに様々な利点をもたらしますが、中間層でハードウェア・ロード・バランサから管理対象サーバーへリクエストを直接ルーティングする方法もサポートされています。
この方法には、次の利点があります。
フロントエンドOracle HTTP ServerのWeb層フロントエンドを使用するよりも構成と処理のオーバーヘッドが小さい。
管理対象サーバーごとに固有のURLを監視するようにロード・バランサを構成できるので、アプリケーション・レベルでの監視が可能(OHSでは不可能)。
ダイアグラムに示すように、Oracle HTTP Serverインスタンスは、Oracle HTTP Serverからアプリケーション層のOracle WebLogic Server管理対象サーバーへのHTTPリクエストのプロキシに、WebLogicプロキシ・プラグイン(mod_wl_ohs)を使用します。
詳細は、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』のWebサーバー・プロキシ・プラグイン12.1.3の概要に関する項を参照してください。
アプリケーション層は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つずつ配置します。
管理サーバーのドメイン・ディレクトリと管理対象サーバーのドメイン・ディレクトリの構造、およびこれらのディレクトリの参照に使用する変数の詳細は、第7.5項を参照してください。
標準的なエンタープライズ・デプロイメントでは、アプリケーション層内の2つ以上のホスト上にあるクラスタで管理対象サーバーを構成します。特定のOracle Fusion Middleware製品について、エンタープライズ・デプロイメント参照トポロジは、管理対象サーバー数、クラスタ数および各クラスタをターゲットとするサービスに関するベスト・プラクティスを示しています。
これらのベスト・プラクティスは、各製品の標準的なパフォーマンス、メンテナンスおよびスケールアウトの各要件を考慮したものです。その結果、管理対象サーバーは、ドメイン内の適切なクラスタ・セットにグループ化されます。
エンタープライズ・デプロイメント・トポロジのバリエーションとして、特定の製品またはコンポーネントを追加のクラスタまたはホストにターゲット設定できます。これにより、パフォーマンスと独立性が向上します。
別の例として、管理サーバーを別個の比較的小規模なホスト・コンピュータにホストすることで、FMWコンポーネントおよび製品を管理サーバーから隔離できます。
トポロジのこれらのバリエーションはサポートされていますが、エンタープライズ・デプロイメント参照トポロジでは、高可用性、スケーラビリティおよびセキュリティに留意しながら最小のハードウェア・リソースを使用します。各種サーバーのシステム要件と、システムが対応する必要のある負荷に応じて、適切なリソース・プランニングおよびサイジングを実施してください。これらの決定に基づいて、これらのバリエーションをインストールおよび構成する手順を、このガイドに記載の説明から適切に変更する必要があります。
標準的なエンタープライズ・デプロイメントでは、ホストごとに1つのノード・マネージャがあります。このノード・マネージャは、すべてのドメインから管理対象サーバーを起動できます。エンタープライズ・デプロイメントには、このノード・マネージャ構成をお薦めします。
標準的なエンタープライズ・デプロイメントでは、ドメインごとのノード・マネージャを構成して、管理サーバー上で2つのノード・マネージャ・インスタンスを起動します。1つは管理サーバーのドメイン・ディレクトリから、もう1つは管理対象サーバーのドメイン・ディレクトリから起動します。
それぞれのドメイン・ディレクトリからノード・マネージャを起動すると、2つの独立したノード・マネージャ・プロセスが作成され、各タイプのサーバーを別々に管理できます。別々のノード・マネージャ・プロセスにより、管理サーバーのノード・マネージャと管理対象サーバーのノード・マネージャでそれぞれ異なる機能を使用できます。
エンタープライズ・デプロイメントにおける管理対象サーバーとOracle WebLogic Serverクラスタ内のホストの間の通信にはユニキャスト通信プロトコルをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。
独自のデプロイメントでマルチキャストかユニキャストのどちらのプロトコルを使用するかを検討するときは、ネットワークの種類、クラスタ内のメンバー数、およびクラスタ・メンバーシップの信頼性要件を考慮してください。また、各プロトコルが持つ次の利点も考慮してください。
エンタープライズ・デプロイメントにおけるユニキャストの利点:
グループ・リーダーを使用し、このリーダーにすべてのサーバーがメッセージを直接送信します。このリーダーは、他のすべてのグループ・メンバーと他のグループ・リーダー(該当する場合)にメッセージを再送信する役割を担います。
ほとんどのネットワーク・トポロジでそのまま動作します。
ネットワーク・トポロジに関係なく、追加の構成は不要です。
単一の欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。
エンタープライズ・デプロイメントにおけるマルチキャストの利点:
マルチキャストは、より拡張性の高いピア・ツー・ピア・モデルを採用します。このモデルでは、サーバーが各メッセージを一度だけネットワークに直接送信し、各クラスタ・メンバーがネットワークからメッセージを直接受信することをネットワークが保証します。
クラスタ・メンバーが単一のサブネット内にある最近のほとんどの環境でそのまま動作します。
クラスタ・メンバーが複数のサブネットにまたがっている場合は、ルーターとWebLogic Server (マルチキャストTTL)で追加構成が必要です。
連続する3つの欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。
どちらのモデルの方がより適切に動作するかは、クラスタ内のサーバー数と、基礎となるアプリケーションにとってクラスタ・メンバーシップが不可欠かどうか(たとえば、セッション・レプリケーションを大量に行うアプリケーションやクラスタ全体でRMI呼出しが大量に発生するクラスタなど)によって異なります。
使用するトポロジがアクティブ/アクティブ型の障害時リカバリ・システムに参加するかどうか、またクラスタが複数のサブネットを横断するどうかを考慮してください。一般に、これらの場合にはユニキャストの方がより適切に動作します。
詳細は、次のリソースを参照してください。
『Oracle Fusion Middleware高可用性ガイド』のWebLogic Serverクラスタのマルチキャスト・メッセージングの構成に関する項
『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のユニキャストを使用した1対多通信に関する項
Oracle Fusion Middleware製品およびコンポーネントの多くでは、認証プロバイダ(アイデンティティ・ストア)、ポリシー、資格証明、キーストアおよび監査データのためにOracle Platform Security Services (OPSS)セキュリティ・ストアが必要です。結果として、アプリケーション層とセキュリティ・プロバイダとの間でリクエストを送受信できるように通信を有効化する必要があります。
Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic認証プロバイダを使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用する必要があります。
認可(およびポリシー・ストア)の場合、層によってセキュリティ・ストアの位置が異なります。
アプリケーション層では、認可ストアはデータベース・ベースです。したがって、必要なOPSSデータを取得するために、Oracle WebLogic Server管理対象サーバーからデータベースへの頻繁な接続が必要になります。
Web層では、認可ストアはファイル・ベースです。したがって、データベースへの接続は必要ありません。
OPSSセキュリティ・ストアの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の次の各項を参照してください。
認証の基本
OPSSポリシー・モデル
データ層では、Oracle RACデータベースは2つのホスト(DBHOST1とDBHOST2)上で実行されます。データベースには、Oracle SOA SuiteコンポーネントとOracle Platform Security Services (OPSS)ポリシー・ストアが必要とするスキーマが含まれています。
エンタープライズ・デプロイメントでは製品およびコンポーネントごとに複数のサービスを定義することで、スループットとパフォーマンスの分離および優先順位の決定ができます。このガイドでは、例として1つのデータベース・サービスを使用します。また、データベースを保護する他の高可用性データベース・ソリューションも使用できます。
Oracle Data Guard: 詳細は、Oracle Data Guard概要および管理を参照してください。
Oracle RAC One Node: 詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドのOracle RAC One Nodeの概要に関する項を参照してください。
これらのソリューションは、エンタープライズ・デプロイメントに一般に適用されるスケーラビリティと可用性の要件を満たす場合、Oracle RACデータベースの使用に重点を置いたこのガイドに記載されている情報以上のデータベース保護を実現します。
高可用性環境でのOracleデータベースの使用の詳細は、『Oracle Fusion Middleware高可用性ガイド』のデータベースの考慮事項に関する項を参照してください。
