| Oracle® Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド 11gリリース2 (11.1.2.2.0) B71694-10 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド 11gリリース2 (11.1.2.2.0) B71694-10 |
|
前 |
次 |
この章では、Oracle Identity and Access Managementのエンタープライズ・トポロジの概要について説明します。
この章の構成は、次のとおりです。
Oracle Identity and Access Managementはアイデンティティ管理およびアクセス管理全般に対応する総合的な製品スイートです。このガイドでは、Oracle Fusion MiddlewareのOracle Identity And Access Managementインフラストラクチャ・コンポーネント向けの参照エンタープライズ・トポロジを説明します。また、エンタープライズ・デプロイメントのガイドラインに沿ってトポロジを作成するための詳しい手順と推奨事項についても説明します。
エンタープライズ・デプロイメントは、定評のあるOracle高可用性テクノロジとOracle Fusion Middlewareに関する推奨事項に基づいた、Oracleベスト・プラクティスの青写真です。このマニュアルに示す高可用性ベスト・プラクティスは、Oracle Database、Oracle Fusion Middleware、Oracle Applications、Oracle Enterprise Manager Cloud Controlなど、技術スタック全体におよぶOracle製品を対象とした様々な高可用性ベスト・プラクティスの1つです。
Oracle Fusion Middlewareのエンタープライズ・デプロイメントの特長は、次のとおりです。
様々なビジネス上のサービス・レベル合意(SLA)を考慮し、高可用性に対するベスト・プラクティスを可能なかぎり広範囲に適用できるようにします。
データベース・グリッド・サーバーと低コストのストレージを使用したストレージ・グリッドを活用し、回復力に優れた低コストのインフラストラクチャを提供します。
様々な構成を対象として広範囲なパフォーマンス影響調査の結果を利用し、ビジネス・ニーズに応じて実行およびスケールできるように高可用性アーキテクチャが最適に構成されます。
停止状態からのリカバリ時間と自然災害時に許容可能なデータ損失量を制御できます。
各Oracleバージョンと共に内容が向上し、ハードウェアとオペレーティング・システムからは完全に独立しています。
高可用性の実現に関する詳細は、次のOracle Technology Networkで、Oracle Databaseの高可用性のページを参照してください。
http://www.oracle.com/technetwork/database/features/availability/index-087701.html
|
注意: 『Oracle Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド』では、Linux環境におけるエンタープライズ・デプロイメントを中心に説明しています。しかしながら、UNIX環境を使用したエンタープライズ・デプロイメントの実装も可能です。 |
このガイドで示されているUNIXおよびLinuxのコマンド例はすべて、bashシェルを使用して実行されます。
OracleホームやOracleインスタンスなどの一般的な用語は、『Oracle Fusion Middlewareコンセプト・ガイド』の主要概念の理解に関する項を参照してください。
この項では、このガイドで使用されている追加のエンタープライズ・デプロイメント用語について説明します。
フェイルオーバー: 高可用性システムのメンバーに予期しない障害(計画外停止時間)が発生した場合、コンシューマへのサービス提供を継続するために、フェイルオーバー操作が実行されます。システムがアクティブ/パッシブ型システムの場合、パッシブ・メンバーはフェイルオーバー操作においてアクティブになります。そしてコンシューマは、障害が発生したメンバーではなく、アクティブになったメンバーにダイレクトされます。フェイルオーバー操作は、手動でも実行できます。また、障害を検出した場合にクラスタのリソースを障害ノードからスタンバイ・ノードに移動するように、ハードウェア・クラスタ・サービスを設定することで、フェイルオーバー操作を自動化することもできます。システムがアクティブ/アクティブ型システムの場合、ロード・バランサのエンティティによりフェイルオーバーが実行されます。このエンティティによって、リクエストがアクティブ・メンバーで処理されます。アクティブ・メンバーに障害が発生すると、ロード・バランサにより障害が検出され、障害メンバーへのリクエストが、正常に動作しているアクティブ・メンバーに自動的にリダイレクトされます。アクティブ/アクティブ型システムとアクティブ/パッシブ型システムの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。
フェイルバック: システムのフェイルオーバー操作が正常に終了した後、最初に障害を起こしたメンバーは修復され、スタンバイ・メンバーとしてシステムに再導入されます。必要に応じて、フェイルバック処理を開始して、このメンバーをアクティブにし、別のメンバーを非アクティブにすることができます。このプロセスにより、システムは障害発生前の構成に戻ります。
ハードウェア・クラスタ: ハードウェア・クラスタとはコンピュータの集まりであり、ネットワーク・サービス(例: IPアドレス)またはアプリケーション・サービス(例: データベース、Webサーバー)のシングル・ビューをこれらのサービスのクライアントに提供します。ハードウェア・クラスタの各ノードは、それぞれ固有のプロセスを実行するスタンドアロン・サーバーです。これらのプロセスは互いに通信して、単一のシステムであるかのように動作して、アプリケーション、システム・リソースおよびデータを連携してユーザーに提供できます。
特別なハードウェア(クラスタ・インターコネクト、共有記憶域)とソフトウェア(ヘルス・モニター、リソース・モニター)を使用することで、ハードウェア・クラスタにより高可用性とスケーラビリティが実現されます。(クラスタ・インターコネクトは、ハートビート情報がノードの停止を検出する際にハードウェア・クラスタで使用されるプライベート・リンクです。)専用のハードウェアとソフトウェアが必要であるため、通常、ハードウェア・クラスタはSun社、HP社、IBM社、Dell社などのハードウェア・ベンダーによって提供されます。1つのハードウェア・クラスタ内で構成可能なノード数は、ベンダーによって異なりますが、Oracle Fusion Middlewareの高可用性では2つのノードのみを必要とします。このため、ハードウェア・クラスタを使用する高可用性ソリューションでは、2つのノードによるハードウェア・クラスタがこのドキュメントで前提にされています。
クラスタ・エージェント: ハードウェア・クラスタのノード・メンバー上で実行されるソフトウェアで、可用性とパフォーマンスの操作を他のノードと協調させます。クラスタウェアによりリソースのグループ化と監視を行い、サービスを移行できます。クラスタ・エージェントではサービスのフェイルオーバーを自動化できます。
クラスタウェア: クラスタ・メンバーの処理を、1つのシステムとして管理するソフトウェアです。これにより、クラスタ・メンバー間のハートビート・メカニズムを使用して、監視対象のリソースとサービスのセットを定義したり、これらのリソースとサービスをクラスタ内の別のメンバーにできるだけ効率的かつ透過的な方法で移動することができます。
共有記憶域: エンタープライズ・デプロイメント・ドメイン内のすべてのマシンがアクセスできる記憶域のサブシステムです。共有ディスクには特に次のものが配置されています。
Middlewareホームのソフトウェア
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インスタンスのバックアップ・ノードであるノード。プライマリ・ノードが使用できなくなると、アクティブなインスタンスでフェイルオーバーが実行されます。この項で、プライマリ・ノードに関する定義を参照してください。
ネットワーク・ホスト名: ネットワーク・ホスト名は、/etc/hostsファイルまたはDNS名前解決を通じてIPアドレスに割り当てられる名前です。この名前は、参照先マシンに接続する際にネットワークで参照可能です。ネットワーク・ホスト名と物理ホスト名が同一である場合があります。ただし、各マシンには物理ホスト名は1つのみ付与されますが、ネットワーク・ホスト名は複数付与される場合があります。そのため、マシンのネットワーク・ホスト名はその物理ホスト名であるとはかぎりません。
物理ホスト名: このガイドでは、物理ホスト名とネットワーク・ホスト名を区別しています。このガイドでは、現在のマシンの内部名を指す場合に物理ホスト名が使用されます。Linuxでは、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構成のセキュリティと高可用性のメリットは、ファイアウォール・ゾーンの分離とソフトウェア・コンポーネントのレプリケーションを通じて実現されます。
この項には次のトピックが含まれます:
エンタープライズ・デプロイメント・アーキテクチャのセキュリティは、ソフトウェア・コンポーネントのすべての機能グループが各グループ固有のゾーンに分離され、すべてのトラフィックがプロトコルとポートによって制限されることによって確保されます。次の特長により、必要なレベルのすべてのセキュリティが確保され、高レベルの標準の準拠が実現します。
ポート80 (HTTP_PORT)で受信するすべての外部通信がポート443 (HTTP_SSL_PORT)にリダイレクトされます。
外部との通信には、Secure Socket Layer (SSL)セキュアWebプロトコルを使用します。この通信はサイトのロード・バランサで終了します。
外部のクライアントからの通信はロード・バランシング・ルーターを超えたレベルでは発生しません。
ロード・バランシング・ルーターからデータ層ゾーンへの直接的な通信は許可されません。
コンポーネントは、Web層、アプリケーション層およびデータベース層の各ゾーン間で分離されます。
いずれの時点においても、2つのファイアウォール間での直接的な通信は禁止されています。
1つのファイアウォール・ゾーンで通信が始まった場合、それは次のファイアウォール・ゾーンで終わる必要があります。
LDAPディレクトリはディレクトリ層ゾーンに分離できます。(Oracle Unified Directoryはアプリケーション層ゾーン内に配置されます。)
Identity And Access Managementコンポーネントはアプリケーション層ゾーン内に配置されます。
ゾーンをまたぐすべてのコンポーネント間通信は、ファイアウォールのルールに従い、ポートとプロトコルによって制限されます。
エンタープライズ・デプロイメント・アーキテクチャは、きわめて高い可用性を提供します。それは、ソフトウェア・コンポーネントの各コンポーネントまたは機能グループがそれぞれ別のコンピュータ上でレプリケートされ、コンポーネント・レベルの高可用性を確保するように構成されるためです。
