| Oracle® Exalogic Elastic Cloud Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51446-03 |
|
 前 |
 次 |
| Oracle® Exalogic Elastic Cloud Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51446-03 |
|
前 |
次 |
この章では、Oracle Identity Management Infrastructureエンタープライズ・デプロイメント・トポロジの前提条件について説明します。
この章には次のトピックが含まれます:
表3-1に、Exalogicマシンでのエンタープライズ・デプロイメント用にネットワークを設定するために必要な手順をまとめます。
表3-1 Exalogicエンタープライズ・デプロイメント用のネットワーク構成プロセスの概要
| タスク | 説明 | 詳細情報 |
|---|---|---|
|
ネットワーク情報の確認 |
IDM Exalogicエンタープライズ・デプロイメントのネットワーク構成の特性および目的について読みます。 |
第3.2項「IDMエンタープライズ・トポロジのExalogicネットワーク構成について」 |
|
必要なホスト名解決の定義 |
必要なDNS (/etc/hostsまたは中央DNSサーバー)定義が配置され、IPと仮想IPを直接使用かわりにホスト名と仮想ホスト名をWebLogic Serverで使用することが重要です。 |
|
|
IPoIB用仮想IPアドレスの構成 |
IPoIBネットワークおよび必要な仮想IPアドレスについて読み、それらを構成します。 |
第3.4項「各計算ノードにおけるIPoIB用仮想IPアドレスの構成」 |
|
IPoIB用仮想IPアドレスの構成 |
EoIBネットワークおよび必要な仮想IPアドレスについて読み、それらを構成します。 |
第3.5項「各計算ノードにおけるEoIB用仮想IPアドレスの構成」 |
|
必要な仮想サーバー名の定義 |
エンタープライズ・デプロイメントでは、特定の仮想サーバー名がネットワークで定義されている必要があります。これらは、トポロジ内で特定の計算ノードおよびサーバーに解決される必要があります。 |
|
|
必要な仮想IPアドレスの定義 |
エンタープライズ・デプロイメントで、トポロジ内の適切なサーバーまたはサービスにリクエストをルーティングするには、仮想サーバー名のセットが必要です。 |
|
|
外部ハードウェア・ロード・バランサの構成 |
外部ハードウェア・ロード・バランサは、外部の顧客と社内の管理者の両方からのリクエストを受け付け、トポロジ内の適切なURLにルーティングするように構成する必要があります。 |
|
|
ファイアウォールの構成 |
トポロジのファイアウォールをインストールおよび構成する場合、この情報により必要なポートのみを開き、それぞれのポートに適したタイムアウトを設定します。 |
|
次の各項では、IDMエンタープライズ・トポロジのExalogicネットワーク構成に関する情報が記載されています。
Exalogicシステムは、管理、IP over InfiniBand (IPoIB)およびEthernet over InfiniBand (EoIB)の3つのネットワーク領域で構成されます。
IPoIBネットワーク - このネットワークは、ラック間通信に使用されます。このネットワークは、最も高速に使用できますが、Exalogicマシン・ラックの外部からはアクセスできません。
管理ネットワーク - このEoIBネットワークによって、ユーザーは、パブリック・イーサネットから個々の計算ノードに接続できます。これは、管理および設定の目的のみに使用されます。このネットワークは、通常のイーサネット通信には使用できません。
EoIBネットワーク - 計算ノードと外部のパブリック・ネットワーク間の通信を許可するために、このネットワークを手動で構成できます。このネットワークは、次の場合に使用されます。
外部ロード・バランサが計算ノード1および2でOracle Traffic Directorインスタンスと通信する場合。
計算ノードが外部データベースと通信する場合。
外部Webサーバー(Oracle HTTPサーバー)が計算ノードで実行中のWebLogic管理対象サーバーと通信する場合。
Exalogicシステムを最初に設定すると、管理およびIPoIBがデフォルトで構成されます。管理およびIPoIBに加えて、Exalogicマシン・ラックからイーサネットで公開されるこれらのコンポーネントのEoIBネットワーク・アクセスを手動で構成する必要があります。
最適化されたOracle Fusion Middlewareシステムでは、トポロジの様々な要素間における通信が制約されます。そのため、Exalogic InfiniBandネットワークでできるだけ多く実行されます。たとえば、コンポーネントはInfiniBandインタフェースでリスニングし、適切なゲートウェイへのアクセスでオーバーヘッドを削減して、最適化されたInfiniBandネットワークを使用する必要があります。
さらに、WebCenterやFusion Middleware SOAなどの他のOracle Fusion Middlewareシステムと、またはテストや開発などの他のタイプのデプロイメントとでも、同じExalogicマシン・ラックが共有する際、EoIBアクセスではOracle Identity and Access Management用に分離されたVLANベースのインタフェースが必要な場合があります。ワークロードのこの論理分割とセキュリティ分離の実施にVLANを使用できます。ただし、そのようなVLANの定義についてはこのガイドでは取り扱いません。
ExalogicにおけるOracle Fusion Middleware Identify and Access Managementエンタープライズ・デプロイメントのコンポーネント、および使用するインタフェースと通信プロトコルのタイプが図3-1で説明されています。
図3-1で使用されるIPアドレスは例であり、このドキュメント全体で一貫して使用されています。他のIPは有効です。順番に従ってサーバーのタイプをIP範囲で分けることをお薦めします。表3-2に、このガイドで使用される内部および外部IPアドレスの一覧を示します。
表3-2 内部および外部IPアドレス
| 用途 | ネットワーク | IPアドレス | ネットマスク |
|---|---|---|---|
|
外部計算ノード・アドレス |
EoIB |
10.10.10.x |
255.255.224.0 |
|
外部フローティング物理IPアドレス |
EoIB |
10.10.30.x |
255.255.224.0 |
|
外部フローティングOracle Traffic Director IPアドレス |
EoIB |
10.10.50.x |
255.255.224.0 |
|
内部計算ノード・アドレス |
IPoB |
192.168.10.x |
255.255.224.0 |
|
内部フローティング物理IPアドレス |
IPoB |
192.168.30.x |
255.255.240.0 |
|
内部Oracle Traffic Directorアドレス |
IPoB |
192.168.50.x |
255.255.224.0 |
|
注意: ここで使用されているサブネットは、単なる例です。外部向けサブネットが組織で使用される標準に従うように、これらのサブネットを使用できる場合があります。 |
ネットワーク・マップ・ダイアグラムの詳細は、次を参照してください。
Oracle Identity and Access Managementに使用されるExalogicマシン・ラックは、次の4つの計算ノードを使用します。
2つの計算ノードは、Oracle Traffic Directorをホストするために使用されます。Oracle Traffic Directorは、Webサーバーと内部ロード・バランサの両方として機能します。
2つの計算ノードは、Oracle Identity and Access Managementアプリケーションをホストするために使用されます。
この項の内容は次のとおりです。
外部ロード・バランサは、Exalogicマシン・ラックの外部に位置します。これの目的は、パブリック・イーサネット・ネットワーク上のリクエストを受信し、フロント・エンドEoIBネットワークを使用してマシン・ラック内のOracle Traffic Directorノードにこれらのリクエストを分散することです。
Oracle Traffic Directorは、ロード・バランシングとHTTPサーバーの2つの機能を果します。
ロード・バランサとしては、TCPを使用した内部IPoIBネットワークを使用してOracle Unified Directoryサーバーにリクエストを送信したり、HTTPを使用した内部IPoIBネットワークを使用してOracle Traffic DirectorからSOAサーバーに内部コール・バック・リクエストを送信できる方法で、Oracle Traffic Directorが構成されます。
HTTPサーバーとしては、Oracle Traffic Directorは、外部ロード・バランサから発生するHTTPリクエストのフロント・エンドEoIBネットワーク上でリスニングします。これらのリクエストが計算ノード上でWebLogic管理対象サーバーにアクセスする必要がある場合、それに応じて、内部IPoIBネットワークを使用してこれらのリクエストを送信します。フロント・エンドEoIBネットワーク上の*HTTP*リクエストです。
計算ノード1 (WEBHOST1)は、EoIBフロント・エンド・ネットワークを使用するように構成されます。このネットワークを使用して、外部ロード・バランサと通信します。
Oracle Traffic Directorによって、フェイルオーバー・グループを使用するIPアドレスは、IPoIBネットワークを使用するOracle Unified Directoryサーバーにリクエストをルーティングできます。
Oracle Traffic Directorは、内部コールバックに使用されたIPアドレスが失敗した場合に、フェイルオーバー・ノードとして機能します。
計算ノード2 (WEBHOST2)は、EoIBフロント・エンド・ネットワークを使用するように構成されます。このネットワークを使用して、外部ロード・バランサと通信します。
Oracle Traffic Directorによって、フェイルオーバー・グループを使用するIPアドレスは、内部IPoIBネットワークを使用するSOA管理対象サーバーに内部コールバック・リクエストをルーティングできます。
Oracle Traffic Directorは、Oracle Unified Directoryに使用されたIPアドレスが失敗した場合に、フェイルオーバー・ノードとして機能します。
計算ノード3は、Oracle Identity and Access Managerで必要なWebLogicおよびOracle Unified Directoryインスタンスをホストします。
WebLogic管理対象サーバーの起動および停止に使用されるノード・マネージャは、内部IPoIBインタフェースでリクエストを受け入れるように構成されます。
計算ノード自体は、フロント・エンドEoIBインタフェースで同様にアクセスするように構成されます。これにより、仮想IPアドレスをこのインタフェースで構成できます。仮想IPアドレスは、Weblogic管理サーバー用です。このアドレスは、外部モニタリングの目的で外部アクセス用に構成されます。
また、2つのフローティングIPアドレスは、サーバー移行を容易にするためにOIMおよびSOA管理対象サーバーで使用されるIPoIBインタフェースにアタッチされます。
Oracle Unified Directoryは、内部IPoIBネットワーク上でリクエストに対してリスニングします。これらのリクエストは、Oracle Traffic Directorから受信されます。
計算ノード4は、Oracle Identity and Access Managementで必要なWebLogicおよびOracle Unified Directoryインスタンスをホストします。
WebLogic管理対象サーバーの起動および停止に使用されるノード・マネージャは、内部IPoIBインタフェースでリクエストを受け入れるように構成されます。
計算ノード自体は、フロント・エンドEoIBインタフェースで同様にアクセスするように構成されます。これにより、仮想IPアドレスをこのインタフェースで構成できます。仮想IPアドレスはWeblogic管理サーバー用で、これは外部モニタリングの目的で外部アクセス用に構成されます。
また、2つのフローティングIPアドレスは、サーバー移行を容易にするためにOIMおよびSOA管理対象サーバーで使用されるIPoIBインタフェースにアタッチされます。
Oracle Unified Directoryは、内部IPoIBネットワーク上でリクエストに対してリスニングします。これらのリクエストは、Oracle Traffic Directorから受信されます。
ネットワーキングは複雑ですが、Exalogicデプロイメントの重要な部分です。このガイドでは、内部通信用にIPoIBネットワーク、外部通信用にEoIBネットワークを利用します。
表3-3に、Exalogicマシン・ラックで必要なネットワーキング設定のサマリーを示します。次の各項では、このネットワーキングの設定方法について詳細に説明します。
相互参照を容易にするために独自の値を追加できるように、表に列が追加されています。
ネットワーク変更、システム再配置および障害回復シナリオに対応できるトポロジ設計で、適切なホスト名解決が重要です。必要なDNS (/etc/hostsまたは中央DNSサーバー)定義が配置され、IPと仮想IPを直接使用かわりにホスト名と仮想ホスト名をWebLogic Serverで使用することが重要です。さらに、外部ロード・バランサとOracle Traffic Directorサーバーによりトポロジ内で適切なサーバーやサービスにリクエストがルーティングされるために、Exalogicエンタープライズ・デプロイメントでは、仮想サーバー名のセットが必要です。
これらの仮想サーバー名は、社内ネットワークで有効にされている必要があります。IPoIBアドレスをラックの名前解決システム内部のみで解決する必要があります。複数のラックが接続される場合、潜在的なIP競合を予防するには、これらも中央DNSサーバーに配置することをお薦めします。全社レベルのネットワーク管理者は、これを有効にする必要があります。または、異なるノードで伝播される適切な/etc/hostsファイルにより、ホスト名を解決できます。SOAシステムのサーバーで使用される異なるフローティングIPアドレスの名前の例が、表3-3に記載されています。
表3-3 ホスト名と仮想IPワークシート
| このガイドにおけるホスト名例 | インタフェース | IPアドレス/サブネット | 実際の値 | タイプ | ホスト | バインド | 詳細 |
|---|---|---|---|---|---|---|---|
|
WEBHOST1 |
bond0 |
192.168.10.1/255.255.224.0 |
IPoIB/ Fixed |
ComputeNode1/WEBHOST1 |
NA |
内部IPoIBネットワーク経由でComputeNode1/WEBHOST1にアクセスします。 |
|
|
WEBHOST2 |
bond0 |
192.168.10.2/255.255.224.0 |
IPoIB/ Fixed |
ComputeNode2/WEBHOST2 |
NA |
内部IPoIBネットワーク経由でComputeNode2/WEBHOST2にアクセスします。 |
|
|
IDMHOST1 |
bond0 |
192.168.10.3/255.255.224.0 |
IPoIB/ Fixed |
ComputeNode3/IDMHOST1 |
ノード・マネージャとWLS_OAM1 |
ノード・マネージャで使用される |
|
|
IDMHOST2 |
bond0 |
192.168.10.4/255.255.224.0 |
IPoIB/ Fixed |
ComputeNode4/IDMHOST2 |
ノード・マネージャとWLS_OAM2 |
ノード・マネージャで使用される |
|
|
ADMINVHN |
bond1:1 |
10.10.30.2/255.255.224.0 |
EoIB /Floating |
ComputeNode3/IDMHOST1 |
管理サーバー |
手動で管理サーバーをComputeNode3からComputeNode4に移行する場合、管理サーバーにフローティングIPアドレスを使用することをお薦めします。 |
|
|
WEBHOST1-VHN1 |
OTD |
10.10.50.1/255.255.224.0 |
EoIb /Floating |
ComputeNode1/WEBHOST1 |
OTD - Webhost1 |
OTDで管理されるフローティングIPアドレス。これは、ロード・バランサの接続先のIPアドレスです。 |
|
|
WEBHOST2-VHN1 |
OTD |
10.10.50.2/255.255.224.0 |
EoIb /Floating |
ComputeNode2/WEBHOST2 |
OTD - Webhost2 |
OTDで管理されるフローティングIPアドレス。これは、ロード・バランサの接続先のIPアドレスです。 |
|
|
OTDADMINVHN |
bond1:1 |
10.10.30.1/255.255.224.0 |
EoIb /Floating |
ComputeNode1/WEBHOST1 |
OTD管理サーバー |
手動でOTD管理サーバーをComputeNode1からComputeNode2に移行する場合、管理サーバーにフローティングIPアドレスを使用することをお薦めします。 |
|
|
SOAHOST1VHN |
bond0:2 |
192.168.30.3/255.255.240.0 |
IPoIB/ Floating |
ComputeNode3/IDMHOST1 |
WLS_SOA1デフォルト・チャネル |
ComputeNode3で最初に有効にされていると、サーバー移行によりComputeNode4にフェイルオーバーできます。 |
|
|
SOAHOST2VHN |
bond0:2 |
192.168.30.4/255.255.240.0 |
IPoIB/ Floating |
ComputeNode4/IDMHOST2 |
WLS_SOA2デフォルト・チャネル |
ComputeNode4で最初に有効にされていると、サーバー移行によりComputeNode3にフェイルオーバーできます。 |
|
|
OIMHOST1VHN |
bond0:1 |
192.168.30.1/255.255.240.0 |
IPoIB/ Floating |
ComputeNode3/IDMHOST1 |
WLS_OIM1デフォルト・チャネル |
ComputeNode3で最初に有効にされていると、サーバー移行によりComputeNode4にフェイルオーバーできます。 |
|
|
OIMHOST2VHN |
bond0:1 |
192.168.30.2/255.255.240.0 |
IPoIB/ Floating |
ComputeNode4/IDMHOST2 |
WLS_OIM2デフォルト・チャネル |
ComputeNode4で最初に有効にされていると、サーバー移行によりComputeNode3にフェイルオーバーできます。 |
|
|
IDMHOST1-EXT |
bond1 |
10.10.10.3/255.255.224.0 |
EoIB/Fixed |
ComputeNode3/IDMHOST1 |
NA |
計算ノードが外部データベースにアクセスするか、外部Webサーバー経由でアクセスされることが可能な固定IP。 |
|
|
IDMHOST2-EXT |
bond1 |
10.10.10.4/255.255.224.0 |
EoIB/Fixed |
ComputeNode3/IDMHOST2 |
NA |
計算ノードが外部データベースにアクセスするか、外部Webサーバー経由でアクセスされることが可能な固定IP。 |
|
|
WEBHOST1-EXT |
bond1 |
10.10.10.1/255.255.240.0 |
EoIB/Fixed |
ComputeNode1/WEBHOST1 |
NA |
計算ノードが外部ロード・バランサにアクセスすることが可能な固定IP。 |
|
|
WEBHOST2-EXT |
bond1 |
10.10.10.2/255.255.240.0 |
EoIB/Fixed |
ComputeNode2/WEBHOST2 |
NA |
計算ノードが外部ロード・バランサにアクセスすることが可能な固定IP。 |
|
|
IDMINTERNAL |
OTD |
192.168.50.1/255.255.224.0 |
IPoIB/ Floating |
ComputeNode1/WEBHOST1 |
NA |
SOAのOracle Traffic Directorフェイルオーバー・グループ。 |
|
|
OUDINTERNAL |
OTD |
192.168.50.2/255.255.224.0 |
IPoIB/ Floating |
ComputeNode2/WEBHOST2 |
NA |
Oracle Unified DirectoryのOracle Traffic Directorフェイルオーバー・グループ。 |
この項の内容は、次のとおりです。
IPoIBネットワーク経由のすべての通信では、WEBHOST計算ノードおよびWebLogic Server管理対象サーバーは、Exalogicハードウェアの委任時に割り当てられたデフォルトのbond0 IPアドレスを使用します。
表3-4に、IDMHOST1とIDMHOST2でOAMとOIMの管理対象サーバー用に定義する必要がある仮想IPの一覧を示します。
これらの仮想IPアドレスを定義する手順は、第3.4.2項「IDMHOST1とIDMHOST2におけるIPoIBネットワーク用仮想IPアドレスの作成」を参照してください。
表3-4 IPoIBネットワーク・インタフェースに関連付けられる仮想IPアドレス
| インタフェース | アドレス例 | ネットワーク例 | 使用者 | 仮想ホスト名 | タイプ | デフォルト・ホスト |
|---|---|---|---|---|---|---|
|
BOND0:1 |
192.168.30.1 |
255.255.240.0 |
WLS_OIM1 |
OIMHOST1VHN |
物理 |
IDMHOST1 |
|
BOND0:1 |
192.168.30.2 |
255.255.240.0 |
WLS_OIM2 |
OIMHOST2VHN |
物理 |
IDMHOST2 |
|
BOND0:2 |
192.168.30.3 |
255.255.240.0 |
WLS_SOA1 |
SOAHOST1VHN |
物理 |
IDMHOST1 |
|
BOND0:2 |
192.168.30.4 |
255.255.240.0 |
WLS_SOA2 |
SOAHOST2VHN |
物理 |
IDMHOST2 |
|
BOND0:1 |
192.168.50.1 |
255.255.224.0 |
SOAのOTDフェイルオーバー・グループ |
IDMINTERNAL |
OTD |
WEBHOST1 |
|
BOND0:1 |
192.168.50.2 |
255.255.224.0 |
OUDのOTDフェイルオーバー・グループ |
OUDINTERNAL |
OTD |
WEBHOST1 |
|
注意: 物理IPアドレスは手動で管理されます。Oracle Traffic DirectorのIPアドレスは、Oracle Traffic Directorで処理されます。 |
表3-4に示されている物理IPアドレスのみをIDMHOST1およびIDMHOST2で有効にするには、次を実行します。
ifconfigコマンドを使用して仮想IPアドレスを作成します。
ifconfig subinterface virtual_ip_address netmask netmask_value
たとえば、IDMHOST1で、次を入力します。
ifconfig bond0:1 192.168.20.3 netmask 255.255.240.0
定義した各仮想IPアドレスに対して、次のコマンドを使用してARPキャッシュを更新します。
arping -b -A -c 3 -I bond0 192.168.20.3
次のコマンドにより、IDMHOST1、IDMHOST2、WEBHOST1およびWEBHOST2の各ノードから肯定的な結果が返されることを確認します。
ping -I bond0 WEBHOST1 (192.168.10.1) ping -I bond0 WEBHOST2 (192.168.10.2) ping -I bond0 IDMHOST1 (192.168.10.3) ping -I bond0 IDMHOST2 (192.168.10.4) ping -I bond0 OIMHOST1VHN (192.168.30.1) ping -I bond0 OIMHOST2VHN (192.168.30.2) ping -I bond0 SOAHOST1VHN (192.168.30.3) ping -I bond0 SOAHOST2VHN (192.168.30.4)
デフォルトでは、計算ノードはExalogicマシン・ラックの外部では通信できません。これを行うには、外部ホストまたはロード・バランサ経由でアクセスされるこれらのホストにEoIBネットワークを構成する必要があります。
このアクセスが必要なOracle IAMホストは次のとおりです。
外部ロード・バランサと相互作用するWEBHOST1およびWEBHOST2。
外部データベースまたはOracle HTTP ServerのアクセスのためのIDMHOST1およびIDMHOST2。
この項の内容は次のとおりです。
表3-5に、各計算ノードで各EoIBインタフェースに関連付ける必要がある仮想IPアドレスの一覧を示します。これらの各インタフェースを図3-1に示します。
表3-5 EoIBネットワークと関連インタフェースのIPアドレス
| 計算ノード | インタフェース名 | 外部IPアドレス | ネットマスク | タイプ | 使用者 |
|---|---|---|---|---|---|
|
IDMHOST1 |
BOND1 |
10.10.10.3 |
255.255.224.0 |
物理 |
外部データベース・アクセス用の計算ノード |
|
BOND1:1 |
10.10.30.2 |
255.255.224.0 |
仮想 |
管理サーバー(ADMINVHN) |
|
|
IDMHOST2 |
BOND1 |
10.10.10.4 |
255.255.224.0 |
物理 |
外部データベース・アクセス用の計算ノード |
|
WEBHOST1 |
BOND1 |
10.10.10.1 |
255.255.224.0 |
物理 |
外部ロード・バランサ・アクセス用の計算ノード |
|
BOND1:1 |
10.10.30.1 |
255.255.224.0 |
仮想 |
OTD管理サーバー |
|
|
WEBHOST2 |
BOND1 |
10.10.10.2 |
255.255.224.0 |
物理 |
外部ロード・バランサ・アクセス用の計算ノード |
EoIBネットワークの構成は、複数ステージのプロセスです。
ステージ1 - ネットワーク・デバイスの作成に必要な情報を決定します。
ステージ2 - 通信する計算ノードのInfiniBandゲートウェイ・スイッチで仮想LAN (VLAN)を作成します。
ステージ3 - 計算ノードによって表示できるInfiniBandゲートウェイ・スイッチで仮想ネットワーク・カードを作成して、計算ノードがEoIBネットワークを利用できるようにします。
ステージ4 - IPアドレスを計算ノードに割り当てることによって、VNICを使用して通信するように計算ノードを構成します。
次の項では、VLANおよびVNICの作成に必要な情報の収集方法について説明します。これを容易にするには、進行とともに次のワークシートに記入します。
表3-6 VNICワークシート
| 計算ノード | 管理/外部IPアドレス | ベースLid | GUID | スイッチLid | スイッチ名 | コネクタ | スイッチGUID | MACアドレス |
|---|---|---|---|---|---|---|---|---|
|
WEBHOST1 |
||||||||
|
WEBHOST2 |
||||||||
|
IDMHOST1 |
||||||||
|
IDMHOST2 |
||||||||
各計算ノードはゲートウェイ・スイッチに接続され、計算ノードが使用するスイッチは、計算ノードで作成されたVLANを持っている必要があります。
|
注意: 管理IPは、委任時に管理LANで構成されている計算ノードのIPアドレスです。 外部IPアドレスは、EoIBインタフェースに割り当てる静的IPアドレスです。 |
計算ノードに接続するスイッチを決定するには、次を実行します。
rootユーザーを使用して、公開する計算ノードにログインします。
次に例を示します。
ssh root@WEBHOST1
次のコマンドを使用して、InfiniBandフレームワークでアクティブなリンクに関する情報を取得します。
iblinkinfo.pl -R | grep hostname
次に例を示します。
# iblinkinfo.pl -R | grep WEBHOST1 65 15[ ] ==( 4X 10.0 Gbps Active/ LinkUp)==> 121 2[ ] "el01cn01 EL-C 192.168.10.3 HCA-1" (Could be 5.0 Gbps) 64 15[ ] ==( 4X 10.0 Gbps Active/ LinkUp)==> 120 1[ ] "el01cn01 EL-C 192.168.10.3 HCA-1" (Could be 5.0 Gbps)
最初の列は、使用された各ゲートウェイ・スイッチのlid IDを示しています。この例では、これらはlid 65および64です。==>記号の後の数字は、InfinibandポートのベースLidを示しています。表3-6「VNICワークシート」にこれらをメモします。
ibswitchesコマンドを使用して、計算ノードの接続先のゲートウェイ・スイッチの名前を決定します。
#ibswitches Switch : 0x002128548042c0a0 ports 36 "SUN IB QDR GW switch el01gw03" enhanced port 0 lid 63 lmc 0 Switch : 0x002128547f22c0a0 ports 36 "SUN IB QDR GW switch el01gw02" enhanced port 0 lid 6 lmc 0 Switch : 0x00212856d0a2c0a0 ports 36 "SUN IB QDR GW switch el01gw04" enhanced port 0 lid 65 lmc 0 Switch : 0x00212856d162c0a0 ports 36 "SUN IB QDR GW switch el01gw05" enhanced port 0 lid 64 lmc 0
出力例は次のことを示しています。
lid 64は、ゲートウェイ・スイッチel01gw04に関連付けられています。
lid 65は、ゲートウェイ・スイッチel01gw05に関連付けられています。
スイッチのGUIDは、:の後の最後の16文字の値です。たとえば、スイッチel101gw04のGUIDは00212856d0a2c0a0です。
これらは、定義されたVLANおよびVNICを持っている必要があるゲートウェイ・スイッチです。表3-6「VNICワークシート」にこれらの値をメモします。
ibstatコマンドを使用して、InfiniBand構成に関する情報を取得します。
# ibstat
CA 'mlx4_0'
CA type: MT26428
Number of ports: 2
Firmware version: 2.7.8100
Hardware version: b0
Node GUID: 0x0021280001a0a364
System image GUID: 0x0021280001a0a367
Port 1:
State: Active
Physical state: LinkUp
Rate: 40
Base lid: 120
LMC: 0
SM lid: 6
Capability mask: 0x02510868
Port GUID: 0x0021280001a0a365
Link layer: IB
Port 2:
State: Active
Physical state: LinkUp
Rate: 40
Base lid: 121
LMC: 0
SM lid: 6
Capability mask: 0x02510868
Port GUID: 0x0021280001a0a366
Link layer: IB
出力では、計算ノードは各ポートに1つ、2つのInfiniBandスイッチに接続されていることを示しています。ベースLidは、前述の手順2で取得した値にリンクしています。表3-6「VNICワークシート」に、各GUIDの最後の16文字をメモします。
現在、既存のネットワーキングに関する情報があります。
作成する各VNICの一意のMACアドレスを決定します。
次の計算を使用したワークシートの情報を使用して、MACアドレスを導出できます。
スイッチGUIDの最後の3つのオクテット値に、内部IPアドレスの最後の3つのオクテット値(16進数)を加えたもの。たとえば、スイッチel101gw04のGUIDは00212856d162c0a0です。最後の3つのオクテット値はa2c0a0です。
各オクテット値をコロン(:)で区切ります(例: a2:c0:a0)。
計算ノードWEBHOST1の内部IPアドレスは192.168.10.1です。
最後の3つのオクテット値は168.10.1です。16進数に変換し、コロンで区切ると、a8:0a:01です。
|
注意: 次のコマンドを発行して、IPアドレスの最後の3つのオクテット値を決定できます。
IP=<enter-ip-here> && printf '%02X' ${IP//./ }; echo
次に例を示します。
IP=192.168.10.1 && printf '%02X' ${IP//./ }; echo
出力例: C0A80A01 |
したがって、次のようにMACアドレスを導出できます: a2:c0:a0:a8:0a:01。
ワークシートにMACアドレスをメモします。
スイッチ・アップロード・コネクタを決定します。
rootとしてスイッチの1つにログインします。
次に例を示します。
ssh root@el101gw04
コマンド・プロンプトで、次を実行します。
listlinkup | grep Bridge
Bridge-0 Port 0A-ETH-1 (Bridge-0-2) up (Enabled)
Bridge-0 Port 0A-ETH-2 (Bridge-0-2) down (Enabled)
Bridge-0 Port 0A-ETH-3 (Bridge-0-1) down (Enabled)
Bridge-0 Port 0A-ETH-4 (Bridge-0-1) down (Enabled)
Bridge-1 Port 1A-ETH-1 (Bridge-1-2) down (Enabled)
Bridge-1 Port 1A-ETH-2 (Bridge-1-2) down (Enabled)
Bridge-1 Port 1A-ETH-3 (Bridge-1-1) down (Enabled)
Bridge-1 Port 1A-ETH-4 (Bridge-1-1) down (Enabled)
ゲートウェイで使用できるアップリンクを識別します。upの値を持つアップリンクを使用できます。出力例では、OA-ETH-1のみが使用できます。
前述の例を使用すると、WEBHOST1のワークシート・エントリは次のようになります。
次の手順を使用して、これらの各スイッチで仮想LANを作成します。
ワークシートに格納されているゲートウェイ・スイッチ(el01g04など)に、ユーザーilom-adminとしてログインします。
次に例を示します。
ssh ilom-admin@el01gw04
次を入力して、システム管理フレームワークに変更します。
cd /SYS/Fabric_Mgmt
次に例を示します。
Oracle(R) Integrated Lights Out Manager Version ILOM 3.0 r47111 Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. -> cd /SYS/Fabric_Mgmt
showコマンドを入力して、制限付きシェルを起動します。
show
次のコマンドを実行し、使用するVLANにコネクタを関連付けます。
createvlan connector -vlan 0 -pkey default
各パラメータの意味は次のとおりです。
connectorは、ワークシートのスイッチ・インタフェースの名前です。
vlanは、仮想LANの数です。
pkeyは、パーティション・キーです。
次のコマンドを使用して、仮想LANが動作していることを確認します。
showvlan
予想される出力は次のとおりです。
Connector/LAG VLN PKEY ----------- ---- ---- 0A-ETH-1 125 ffff 0A-ETH-1 0 ffff
VNICワークシートのスイッチごとに1回繰り返します。
通信に使用できるネットワーク・カードとして計算ノードが認識できるように、スイッチで仮想ネットワーク・カードを作成します。
各外部向け計算ノードにアタッチされた各スイッチで、ポートごとにVNICを作成する必要があります。詳細は、表3-6「VNICワークシート」を参照してください。
VNICを作成するには、次を実行します。
ワークシートに格納されているゲートウェイ・スイッチ(el01g04など)に、ユーザーilom-adminとしてログインします。
次に例を示します。
ssh ilom-admin@el01gw04
次を入力して、システム管理フレームワークに変更します。
cd /SYS/Fabric_Mgmt
次に例を示します。
Version ILOM 3.0 r47111 Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. -> cd /SYS/Fabric_Mgmt/SYS/Fabric_Mgmt
showコマンドを入力して、制限付きシェルを起動します。
show
VNICに次のコマンドを実行します。
createvnic connector -guid compute_node_port_GUID -mac unique_mac_address -pkey default -vlan 0
connectorは、ワークシートのコネクタ列です。
compute_node_port_GUIDは、ワークシートのGUID列です。
unique_mac_addressは、ワークシートのMACアドレスです。
pkeyおよびvlanは、第3.5.3項「手順2 - 仮想LANの作成」でVLANの作成時に使用された値です。
次に例を示します。
createvnic connector -guid 0021280001a0a366 -mac A2:C0:A0:A8:0A:01 -pkey default -vlan 0
次のコマンドを実行して、VNICが正しく作成されたことを確認します。
showvnics
出力例:
ID STATE FLG IOA_GUID NODE IID MAC VLN PKEY GW --- -------- --- ----------------------- -------------------------------- ---- ----------------- --- ---- -------- 94 UP N 0021280001EFA4BF el01cn01EL-C 192.168.10.1 0000 A2:C0:A0:A8:0A:01 0 ffff 0A-ETH-1
作成されたカードのMACアドレスを探し、ステータスがupと示されていることを確認します。
VNICワークシートのインタフェースごとに繰り返します。
これで仮想ネットワーク・カードが作成されたため、カードを使用できるように各計算ノードを構成します。各計算ノードには、2つの仮想ネットワーク・インタフェース・カードが作成されます。
ネットワークの構成を容易にするために、次のワークシートを使用できます。
表3-8 VNICワークシート
| 計算ノード | EoIB IPアドレス | ネットマスク | インタフェース | ネットワーク・デバイス | MACアドレス | EPORT_ID | IOA_PORT | デバイス名 | インタフェース・ファイル |
|---|---|---|---|---|---|---|---|---|---|
|
WEBHOST1 |
|||||||||
|
WEBHOST2 |
|||||||||
|
IDMHOST1 |
|||||||||
|
IDMHOST2 |
|||||||||
ネットワークを構成するには、次を実行します。
rootユーザーとして計算ノードにログインします。
次に例を示します。
ssh root@WEBHOST1
計算ノードで次のコマンドを実行して、使用できるVNICを一覧表示します。
mlx4_vnic_info -i
このコマンドにより、仮想ネットワーク・カードの詳細が返されます。ワークシートに次をメモします。
ネットワーク・デバイス
MACアドレス
EPORT_ID
IOA_PORTのコロン(:)の後の数字
計算ノードで、VNIC用のインタフェース・ファイルを作成します。
フェイルオーバーが適切に動作するために、VNICインタフェース・ファイルの名前とそのインタフェース・ファイルのDEVICEディレクティブ値が、カーネルに割り当てられたethXインタフェース名(eth4、eth5など)に基づいてはいけません。かわりに、インタフェース・ファイル名とそのインタフェース・ファイルのDEVICEディレクティブ値を、EPORT_IDおよびIOA_PORTの値から導出することをお薦めします。
|
注意: それ以外の一意の名前付け方式も利用できます。 |
次の表記法を使用して、インタフェース・デバイス名を決定します。
ethEPORT_ID_IOA_PORT
次に例を示します。
eth331_1
ワークシートにインタフェース・デバイス名をメモします。
次の表記法を使用して、インタフェース・ファイル名を決定します。
ifcfg-DeviceName
次に例を示します。
ifcfg-eth331_1
ワークシートにインタフェース・ファイル名をメモします。
WEBHOST1の前述の例を使用すると、ワークシート・エントリは次のようになります。
表3-9 VNICワークシート
| 計算ノード | EoIB IPアドレス | ネットマスク | インタフェース | ネットワーク・デバイス | MACアドレス | EPORT_ID | IOA_PORT | デバイス名 | インタフェース・ファイル |
|---|---|---|---|---|---|---|---|---|---|
|
WEBHOST1 |
10.10.10.1 |
255.255.224.0 |
bond1 |
eth4 |
A2:C0:A0:A8:0A:03 |
331 |
1 |
eth331_1 |
ifcfg-eth331_1 |
|
eth5 |
62:C0:A0:A8:0A:03 |
331 |
2 |
eth331_2 |
ifcfg-eth331_2 |
VIなどのテキスト・エディタを使用して、例で最初のVNIC ( eth4)用にインタフェース・ファイルを作成し、ファイルを次のディレクトリに保存します。
/etc/sysconfig/network-scripts
(ワークシートの)ファイルifcfg-eth331_1に名前を付けます。
このファイルには次のコンテンツが含まれています。
DEVICE=eth331_1 BOOTPROTO=none ONBOOT=yes HWADDR=a2:c0:a0:a8:0A:03 MASTER=bond1 SLAVE=yes
各パラメータの意味は次のとおりです。
DEVICEは、ワークシートの導出名です。
HWADDRは、ワークシートのMACアドレスです。
残りのネットワーク・カード用に2番目のインタフェース・ファイルを作成します。
ifcfg-インタフェースという名前のファイルを作成することによって、各ネットワーク・デバイスを含んでいる結合されたイーサネット・カードを作成します。たとえば、次のようになります。
ifcfg-bond1
ファイルには次のコンテンツが含まれています。
DEVICE=bond1 IPADDR=10.10.10.1 NETMASK=255.255.224.0 BOOTPROTO=none USERCTL=no TYPE=Ethernet ONBOOT=yes IPV6INIT=no BONDING_OPTS="mode=active-backup miimon=100 downdelay=5000 updelay=5000" GATEWAY=10.10.18.1 MTU=65520
各パラメータの意味は次のとおりです。
Deviceは、インタフェース名です。
IPADDRは、割り当てられている外部IPアドレスです。
NETMASKは、IPアドレスのネットマスクです。
GATEWAYは、ゲートウェイのIPアドレスです。
次のコマンドを使用して、ネットワーキングを再起動します。
service network restart
これでネットワークが作成されたため、作成したインタフェースに仮想IPアドレスを追加します。
表3-4に示されている各仮想IPアドレスを有効にするには、次を実行します。
ifconfigコマンドを使用して仮想IPアドレスを作成します。
たとえば、WEBHOST1で、次を入力します。
ifconfig subinterface virtual_ip_address netmask netmask_value
たとえば、WEBHOST1で、次を入力します。
ifconfig bond1:1 10.10.30.1 netmask 255.255.224.0
定義した各仮想IPアドレスに対して、次のコマンドを使用してARPキャッシュを更新します。
arping -b -A -c 3 -I bond1 10.10.30.1
ネットワーク接続を定義したら、各ノードで次のコマンドを実行して、正しく動作していることを確認します。
ping -I bond1 ADMINVHN ping -I bond0 SOAHOST1VHN ping -I bond0 SOAHOST2VHN ping -I bond0 OIMHOST1VHN ping -I bond0 OIMHOST2VHN ping -I bond0 IDMHOST1 ping -I bond0 IDMHOST2 ping -I bond0 WEBHOST1 ping -I bond0 WEBHOST2 ping -I bond1 IDMHOST1-ext ping -I bond1 IDMHOST2-ext ping -I bond1 WEBHOST1-ext ping -I bond1 WEBHOST2-ext ping -I bond1 OTDADMINVHN ping -I bond1 DBHOST1 ping -I bond1 DBHOST2 ping -I bond1 IAMDBSCAN
仮想ホストは、サーバーまたはロード・バランシング・アプライアンスに永続的にバインドされていないIPアドレスと関連付けられています。これは、サーバーまたはロード・バランシング・アプライアンス上で常に有効化されていますが、必要に応じてサーバーとアプライアンス間で移動する場合があります。
Oracle Fusion Middlewareが実行される計算ノードは、これらの仮想サーバー名を解決できることが必要です。
仮想サーバーadmin.mycompany.comおよびsso.mycompany.comは、DNSで構成される必要があります。その他の仮想サーバーをDNSで構成する場合もありますが、セキュリティを追加するためにこれらを計算ノードのローカル・ホスト・ファイルに設定する必要はありません。ただし、設定することは可能です。
この項では、ロード・バランサに必要な仮想サーバー名について説明します。
この項の内容は次のとおりです。
この仮想サーバー名を定義する際には、次の点に注意してください。
この仮想サーバーはEoIBアドレスです。これは、Oracle Access ManagementやOracle Identity Managerを含むすべてのアイデンティティ管理コンポーネントに面する仮想名です。
この仮想サーバーは、シングル・サインオン・サービスに送信されるすべてのHTTPトラフィックのアクセス・ポイントとして機能します。クライアントからのトラフィックはSSLが有効です。したがって、クライアントはアドレスhttps://SSO.mycompany.com:443を使用してこのサービスにアクセスし、さらにこれらをWEBHOST1およびWEBHOST2上のポート7777 (OTD_PORT)に転送します。シングル・サインオンが有効なすべての保護されたリソースが、この仮想ホストでアクセスされます。
この仮想サーバーは、ポート443 (HTTP_SSL_PORT)を持つハードウェア・ロード・バランサで構成します。
この仮想ホストは、リクエストのクライアントIPアドレスを保持するように構成する必要があります。一部のロード・バランサでは、これを構成するため、ロード・バランサがリクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入できるようにします。
この仮想サーバーは、ロード・バランサで構成され、DNSで有効化されます。
この仮想サーバー名を定義する際には、次の点に注意してください。
この仮想サーバーはEoIBアドレスです。これは、ハードウェア・ロード・バランサのリクエストを、管理コンソール、Enterprise Managerおよびoamconsoleサーバーにルーティングします。
この仮想サーバーは、管理サービスに送信されるすべての内部HTTPトラフィックのアクセス・ポイントとして機能します。
クライアントからのトラフィックはSSLが無効です。したがって、クライアントはアドレスADMIN.mycompany.com:80を使用してこのサービスにアクセスし、さらにこれらをWEBHOST1およびWEBHOST2上のポート7777 (OTD_PORT)に転送します。
この仮想ホストでアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Authorization Policy Manager、Oracle Directory Services Managerなどがあります。
この仮想サーバーは、ハードウェア・ロード・バランサで構成します。この仮想ホストを使用して外部のトラフィックが/consoleおよび/emのURLにアクセスするのを阻止するように、ファイアウォール内のルールを作成します。
DMZ内のトラフィックのみがADMIN.mycompany.com仮想ホストのこれらのURLにアクセスできるようにする必要があります。
この仮想サーバーは、ロード・バランサで構成され、DNSで有効化されます。
この項では、Oracle Traffic Directorに必要な仮想サーバー名について説明します。
この項の内容は次のとおりです。
この仮想サーバー名について、次の点に注意してください。
この仮想サーバーはIPoIBアドレスです。これはロード・バランサとして機能し、リクエストをOUDインスタンスにルーティングします。
この仮想サーバーは、後述の第7.7項「エンタープライズ・デプロイメントで必要なOracle Traffic Director仮想サーバーの定義」で定義します。
この仮想サーバーは、すべてのアイデンティティ・ストアLDAPトラフィックのアクセス・ポイントとして機能します。クライアントは、SSLが無効な場合、アドレスOUDINTERNAL.mycompany.com:1489を使用してこのサービスにアクセスします。
Oracle Unified Directoryプロセスのハートビートをモニターするには、この仮想サーバーを使用します。Oracle Unified Directoryプロセスが停止した場合、ロード・バランサは、引き続きLDAPトラフィックを稼働しているOracle Unified Directoryインスタンスにルーティングする必要があります。
この仮想サーバーは、ポート1389 (LDAP_DIR_PORT)で、トラフィックを各Oracle Unified Directoryインスタンスに送信します。
この仮想サーバーは、ポート636 (LDAP_LBR_SSL_PORT)で受信したトラフィックを、ポート1636 (LDAP_DIR_SSL_PORT)で各Oracle Unified Directoryインスタンスに送信します。
この仮想サーバーは、OTDを使用して構成され、Exalogicマシン・ラック内でのみ解決可能です。
この仮想サーバー名について、次の点に注意してください。
この仮想サーバーはIPoIBアドレスです。これはロード・バランサとして機能し、リクエストをIDMHOST1およびIDMHOST2上のSOA管理対象サーバーにルーティングします。
この仮想サーバーは、後述の第7.7項「エンタープライズ・デプロイメントで必要なOracle Traffic Director仮想サーバーの定義」で定義します。
この仮想サーバーはOracle Traffic Directorで有効化されます。クライアントからのトラフィックはSSLが無効です。したがって、クライアントはアドレスIDMINTERNAL.mycompany.com:80を使用してこのサービスにアクセスし、さらにこれらをWEBHOST1およびWEBHOST2上のポート7777 (OTD_PORT)に転送します。SOA管理対象サーバーは、この仮想ホストにアクセスし、Oracle Identity Manager Webサービスにコールバックします。
外部のトラフィックがこの仮想ホストにアクセスするのを阻止するように、ファイアウォール内のルールを作成します。DMZ内のトラフィックのみがIDMINTERNAL.mycompany.com仮想ホストのこれらのURLにアクセスできるようにする必要があります。
この仮想サーバーは、OTDを使用して構成され、Exalogicマシン・ラック内でのみ解決可能です。
仮想IPアドレスは、ホストのプライマリIPアドレスと同じサブネットに属する未使用のIPアドレスです。これが手動でホストに割り当てられ、このIPアドレスでリスニングするようOracle WebLogic管理対象サーバーが構成されます。IPアドレスが割り当てられているノードに障害が発生した場合は、そのIPアドレスが同じサブネットの別のノードに割り当てられ、新しいノードがそれに割り当てられている管理対象サーバーの実行を担うことができるようにします。
図3-2に示すように、管理サーバーと管理対象サーバーを、異なる仮想IPおよび物理IPでリスニングするように構成します。
様々な仮想ホストについて、表3-10で説明します。
表3-10 VIPアドレスおよび仮想ホスト
| 仮想IP | 仮想ホスト名 | ネットワーク・インタフェース | 説明 |
|---|---|---|---|
|
VIP1 |
ADMINVHN |
EoIB |
ADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名で、管理サーバーの手動フェイルオーバーでフェイルオーバーします。これは、管理サーバー・プロセスが実行されているノード(デフォルトではIDMHOST1)で有効です。 |
|
VIP2 |
SOAHOST1VHN |
IPoIB |
SOAHOST1VHNは、WLS_SOA1のリスニング・アドレスにマップされる仮想ホスト名で、この管理対象サーバーのサーバー移行でフェイルオーバーします。これは、WLS_SOA1プロセスが実行されているノード(デフォルトではIDMHOST1)で有効です。 |
|
VIP3 |
OIMHOST1VHN |
IPoIB |
OIMHOST1VHNは、WLS_OIM1サーバーのリスニング・アドレスにマップされる仮想ホスト名で、このサーバーのサーバー移行でフェイルオーバーします。これは、WLS_OIM1プロセスが実行されているノード(デフォルトではIDMHOST1)で有効です。 |
|
VIP4 |
SOAHOST2VHN |
IPoIB |
SOAHOST2VHNは、WLS_SOA2のリスニング・アドレスにマップされる仮想ホスト名で、この管理対象サーバーのサーバー移行でフェイルオーバーします。これは、WLS_SOA2プロセスが実行されているノード(デフォルトではIDMHOST2)で有効です。 |
|
VIP5 |
OIMHOST2VHN |
IPoIB |
OIMHOST2VHNは、WLS_OIM2サーバーのリスニング・アドレスにマップされる仮想ホスト名で、このサーバーのサーバー移行でフェイルオーバーします。これは、WLS_OIM2プロセスが実行されているノード(デフォルトではIDMHOST2)で有効です。 |
このエンタープライズ・トポロジでは、外部のハードウェア・ロード・バランサを使用します。
様々なタイプのネットワーク・トラフィックとモニタリング用に、ロード・バランサ上にいくつかの仮想サーバーと関連ポートを構成する必要があります。これらの仮想サーバーは、サービスを実行するのに適した物理ホストおよびポートに構成される必要があります。
また、ロード・バランサは、可用性を実現するため、実際のホストおよびポートをモニターし、サービスが停止したら早急にこれらへのトラフィックが停止されるように構成する必要があります。これにより、特定の仮想ホストの着信トラフィックが、他の層の使用できないサービスに送信されることはありません。
|
注意: Oracleではほとんどの業界標準ロード・バランサをサポートしています。以前のOracleミドルウェア・ソフトウェア・リリースでサポートされていたロード・バランサのリストは、Oracle Technology Networkの次の情報を参照してください。
|
この項の内容は次のとおりです。
エンタープライズ・トポロジでは、外部のロード・バランサを使用します。外部ロード・バランサには、次の機能が必要です。
仮想ホスト名を通じて実際のサーバーのプールにトラフィックをロード・バランシングできること: クライアントは(実際のホスト名を使用するかわりに)仮想ホスト名を使用してサービスにアクセスします。ロード・バランサはこれを受けて、リクエストをプール内のサーバーにロード・バランシングします。
ポート変換構成。
ポートのモニタリング(HTTPおよびHTTPS)。
仮想サーバーとポートの構成: 外部ロード・バランサに仮想サーバー名とポートを構成できること。この仮想サーバー名とポートは、次の要件を満たしている必要があります。
ロード・バランサでは、仮想サーバーを複数構成できる必要があります。それぞれの仮想サーバーについて、ロード・バランサでは、複数のポート上でのトラフィック管理を構成できる必要があります。たとえば、Oracle WebLogicクラスタの場合、ロード・バランサは、HTTPおよびHTTPSトラフィック用の仮想サーバーおよびポートで構成される必要があります。
仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは、仮想サーバー名を通じて外部ロード・バランサにアクセスできる必要があります。
ノードの障害を検出し、障害の発生したノードへのトラフィックのルーティングを即座に停止できること。
リソース・モニタリング/ポート・モニタリング/プロセスの障害検出: ロード・バランサは、(通知やその他の手段により)URL、サービスおよびノードの障害を検出し、障害の発生したノードへのOracle以外のネット・トラフィックの送信を停止できる必要があります。外部ロード・バランサに自動で障害を検出する機能がある場合は、これを使用してください。
フォールト・トレラント・モード: ロード・バランサはフォルト・トレラントに構成し、アプライアンスでソフトウェアまたはハードウェアの障害が発生した場合に代替のフェイルオーバー・デバイスが処理を再開できるようにすることを強くお薦めします。
その他: トラフィックの転送先であるバックエンド・サービスが使用できない場合は、呼出し側のクライアントにただちに戻るようにロード・バランサの仮想マシンを構成することを強くお薦めします。クライアント・マシン上のTCP/IP設定に基づくタイムアウトの後にクライアント自身が接続切断するより、こちらのほうが好ましい構成です。
SSLアクセラレーション(この機能はお薦めしますが、必須ではありません)。
ディレクトリ層のロード・バランサの仮想サーバーを、TCP接続の接続タイムアウト値を高い値にして構成します。この値は、Oracle Access Management Access Managerとディレクトリ層間でトラフィックが発生しないと予測される最長時間より大きく設定する必要があります。
クライアントIPアドレスを保持する機能: ロード・バランサには、クライアントIPアドレスを保持するため、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入する機能が必要です。
WL-Proxy-SSLを追加する機能: HTTPリクエスト・ヘッダーに該当します。ロード・バランサによっては、これは自動的に行われます。
ロード・バランサの構成手順は、ロード・バランサ固有のタイプにより異なります。実際の手順については、ベンダーが提供するドキュメントを参照してください。次の手順は、一般的な構成フローの概要を示しています。
サーバーのプールを作成します。このプールには、ロード・バランシング定義に含まれるサーバーおよびポートのリストが格納されます。たとえば、Webホスト間のロード・バランシング用に、ポート7777 (OTD_PORT)でホストWEBHOST1およびWEBHOST2にリクエストを送信するサーバーのプールを作成します。
特定のホストおよびサービスが使用可能かどうかを判断するルールを作成し、これを手順1に示したサーバーのプールに割り当てます。
ロード・バランサで仮想サーバーを作成します。これは、アプリケーションで使用するリクエストを受信するアドレスおよびポートです。たとえば、Web層リクエストをロード・バランシングするには、https://sso.mycompany.com:443の仮想ホストを作成します。
ロード・バランサがこれをサポートしている場合、仮想サーバーが内部的に、外部的に、あるいはその両方で使用可能かどうかを指定します。内部アドレスが、ネットワーク内部からのみ解決可能であることを確認します。
可能な場合、仮想サーバー用にSSLの終了を構成します。
手順1で作成したサーバーのプールを仮想サーバーに割り当てます。
第3.10項にある「参照トポロジで使用されるポート」に示すとおり、タイムアウト設定を調整します。これには、サービスが停止したかどうかを検出する時間が含まれます。
アイデンティティ管理デプロイメントでは、ロード・バランサは、表3-11に示すように構成します。
表3-11 ロード・バランサ構成詳細
| 仮想ホスト | サーバー・プール | プロトコル | SSLの終了 | 外部 | その他の必要な構成/コメント |
|---|---|---|---|---|---|
|
|
|
HTTP |
いいえ |
はい |
アイデンティティ管理では、HTTPヘッダーに次を追加する必要があります。
|
|
|
|
HTTP |
はい |
はい |
アイデンティティ管理では、HTTPヘッダーに次を追加する必要があります。
|
|
|
|
HTTP |
いいえ |
いいえ |
脚注 1 IS_SSLの構成については、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のユーザー定義のWebゲート・パラメータに関する項を参照してください。
多くのOracle Fusion Middlewareコンポーネントおよびサービスがポートを使用します。管理者は、これらのサービスで使用されるポート番号を知っている必要があります。また、同じホスト上の2つのサービスで同じポート番号が使用されていないことを確認する必要があります。
ほとんどのポート番号は、インストール時に割り当てられます。
表3-12に、Oracle Exalogicデプロイメント参照トポロジで使用されるポートの一覧を示します。これには、トポロジ内のファイアウォールで開いておく必要のあるポートも含まれています。
ファイアウォールの表記法は次のとおりです。
FW0は、最も外側のファイアウォールを指します。
FW1は、Web層とアプリケーション層の間にあるファイアウォールを指します。
FW2は、アプリケーション層とデータ層の間にあるファイアウォールを指します。
表3-12 参照トポロジで使用されるポート
| タイプ | ファイアウォール | ポートおよびポート範囲 | プロトコル/アプリケーション | インバウンド/アウトバウンド | その他の考慮事項およびタイムアウトのガイドライン |
|---|---|---|---|---|---|
|
ブラウザ・リクエスト |
FW0 |
80 |
HTTP/ロード・バランサ |
インバウンド |
タイムアウトは、Exalogic環境で使用しているOracle Fusion Middleware製品のすべてのHTMLコンテンツやプロセス・モジュールによって決まります。 |
|
ブラウザ・リクエスト |
FW0 |
443 |
HTTPS/ロード・バランサ |
インバウンド |
タイムアウトは、Exalogic環境で使用しているOracle Fusion Middleware製品のすべてのHTMLコンテンツやプロセス・モジュールによって決まります。 |
|
ロード・バランサからOracle Traffic Directorへ |
n/a |
7777 ( 443 ( |
HTTP/HTTPS |
n/a |
第3.9項「ロード・バランサの構成」を参照してください。 実際の値は、『Oracle Fusion Middleware管理者ガイド』のコンポーネント別のポート番号に関する項を参照してください。 |
|
管理コンソールへのアクセス |
FW1 |
7001 |
HTTP/管理サーバーおよびEnterprise Manager |
両方 |
このタイムアウトは、管理コンソールへのアクセスのタイプ(Oracle WebLogic Server管理コンソールをアプリケーション層のクライアントから使用するか、アプリケーション層の外部のクライアントから使用するか)に基づいて調整してください。 |
|
管理コンソールへのアクセス |
FW1 |
7002 |
HTTP/管理サーバーおよびEnterprise Manager |
両方 |
このタイムアウトは、管理コンソールへのアクセスのタイプ(Oracle WebLogic Server管理コンソールをアプリケーション層のクライアントから使用するか、アプリケーション層の外部のクライアントから使用するか)に基づいて調整してください。 管理サーバーSSLアクセス |
|
Coherence |
n/a |
8088 範囲: 8080 - 8090 |
n/a |
n/a |
|
|
アプリケーション層からデータ層へ(Oracle Exalogicマシン外部のOracleデータベースまたはRAC、イーサネット経由) |
FW2 |
1521 |
n/a |
n/a |
|
|
管理対象サーバーへのアクセス(WLS_OAM1、WLS_OAM2、WLS_OIM1、WLS_OIM2、WLS_SOA1、WLS_SOA2) |
FW1 |
8001 14000, 14100 |
HTTP |
インバウンド |
管理対象サーバー( |
