6 エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

この章では、エンタープライズ・デプロイメント用にネットワークを構成する方法について説明します。

ハードウェア・ロード・バランサでの仮想ホストの構成
この項では、エンタープライズ・デプロイメント用にハードウェア・ロード・バランサを構成する方法について説明します。
エンタープライズ・デプロイメントのファイアウォールとポートの構成
この項では、ファイアウォールでエンタープライズ・デプロイメント用に開く必要のあるポートを示します。

6.1 ハードウェア・ロード・バランサでの仮想ホストの構成

この項では、エンタープライズ・デプロイメント用にハードウェア・ロード・バランサを構成する方法について説明します。

次の各項で、ハードウェア・ロード・バランサの構成方法について説明し、必要な仮想サーバーのサマリーとこれらの仮想サーバーに関する追加指示を示します。

6.1.1 ハードウェア・ロード・バランサ構成の概要

トポロジのダイアグラムに示すように、リクエストを認識し、様々な種類のネットワーク・トラフィックや監視に対応する複数の仮想サーバーと関連ポートにリクエストをルーティングできるように、ハードウェア・ロード・バランサを構成する必要があります。

ロード・バランシング・デバイスにおける仮想サーバーとは、ロード・バランシングのために複数の物理サーバーを1つのサーバーのように見せかけることができる構成です。仮想サーバーは通常、IPアドレスとサービスによって表され、受信したクライアント・リクエストをサーバー・プール内の各サーバーに配信するために使用されます。

仮想サーバーは、(エンタープライズ・デプロイメントで使用可能な各種サービス用の)適切なホスト・コンピュータおよびポートにトラフィックをルーティングするように構成しておく必要があります。

さらに、サービスが停止したときに特定のサーバーへのトラフィックをできるだけ早く停止できるように、ホスト・コンピュータとポートの可用性を監視するようにロード・バランサを構成する必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

ロード・バランサを構成した後で、同じ名前を持つ一連の仮想ホストを、ロード・バランサに定義した仮想サーバーとして認識するように、Web層のWebサーバー・インスタンスを構成することも可能です。Webサーバーは、ハードウェア・ロード・バランサから受信した各リクエストを、リクエストのヘッダーに記述されているサーバー名に基づいて適切にルーティングできます。詳細は、「管理およびOracle Web Services Manager用のOracle HTTP Serverの構成」を参照してください。

6.1.2 ハードウェア・ロード・バランサの構成の一般的な手順

次の手順では、エンタープライズ・デプロイメントのハードウェア・ロード・バランサを構成する一般的な手順を示します。

特定のロード・バランサを構成する実際の手順は、ロード・バランサのタイプによって異なります。ロード・バランシングされるプロトコルのタイプによっては、複数の相違点が存在することもあります。たとえば、TCP仮想サーバーおよびHTTP仮想サーバーでは、そのプールに対して異なるタイプの監視を使用します。実際の手順については、ベンダーが提供するマニュアルを参照してください。

サーバーのプールを作成します。このプールには、ロード・バランシングの定義に含まれているサーバーとポートのリストが格納されます。

たとえば、Webホスト間のロード・バランシングの場合、リクエストをポート7777でWEBHOST1およびWEBHOST2のホストに送信するサーバーのプールを作成します。
特定のホストとサービスが使用可能かどうかを決定するルールを作成し、手順1で説明したサーバーのプールに割り当てます。
ロード・バランサ上に、アプリケーションのリクエストを受信するアドレスおよびポート用の必須仮想サーバーを作成します。

エンタープライズ・デプロイメントに必要な仮想サーバーの完全なリストは、「エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー」を参照してください。

ロード・バランサで各仮想サーバーを定義するときは、次のことを考慮します。
1. ロード・バランサでサポートされている場合は、仮想サーバーが内部から、外部から、またはその両方から利用できるのかどうかを指定します。内部アドレスはネットワーク内からのみ解決可能であることを確認します。
2. 適用可能な場合は、仮想サーバーに対するSSL終端を構成します。
3. 手順1で作成したサーバーのプールを仮想サーバーに割り当てます。

6.1.3 エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー

この項では、エンタープライズ・デプロイメントに必要な仮想サーバーについて説明します。

次の表は、Oracle SOA Suiteエンタープライズ・トポロジのハードウェア・ロード・バランサで定義する必要がある仮想サーバーの一覧です。

仮想ホスト	サーバー・プール	プロトコル	SSL終端	外部
`admin.example.com:80`	`WEBHOST1.example.com:7777` `WEBHOST2.example.com:7777`	HTTP	いいえ	いいえ
`soa.example.com`:`443`	`WEBHOST1.example.com:7777` `WEBHOST2.example.com:7777`	HTTPS	はい	はい
`soainternal.example.com:80`	`WEBHOST1.example.com:7777` `WEBHOST2.example.com:7777`	HTTP	いいえ	いいえ
`osb.example.com:443`	`WEBHOST1.example.com:7777` `WEBHOST2.example.com:7777`	HTTPS	いいえ	はい
`mft.example.com:7501`	`WEBHOST1.example.com:7501WEBHOST2.example.com:7501`	TCP	いいえ	はい
`soahealthcare.example.com:95nn`	`WEBHOST1.example.com:7777WEBHOST2.example.com:7777`	TCP	いいえ	はい

注意:

SOA SuiteとOracle Managed File Transferが同じホストにデプロイされている場合、Managed File Transferは、SOAによって使用されるHTTP仮想サーバーとHTTPS仮想サーバーを共有して、Managed File Transferコンソールにアクセスできます。ただし、(SFTリクエストをロード・バランシングするために使用される) TCPプロトコル7に対しては、個別のManaged File Transfer仮想サーバーが必要です。

6.1.4 admin.example.comに関する追加手順

この項では、仮想サーバーadmin.example.comに必要な追加手順を示します。

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

アドレスとポートの変換を有効にします。
サービスまたはホストが停止した場合に接続のリセットを有効にします。

6.1.5 soa.example.comに関する追加手順

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

ポート80とポート443を使用します。ポート80 (非SSLプロトコル)に入力するリクエストはすべて、ポート443 (SSLプロトコル)にリダイレクトされる必要があります。
ANYをプロトコルとして指定します(B2BではHTTPでないプロトコルが必要)。
アドレスとポートの変換を有効にします。
サービスやノードが停止した場合に接続のリセットを有効にします。
この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

これらのコンテキスト文字列は、リクエストをOracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlにルーティングするため、admin.example.comからシステムへのアクセス時にのみ使用する必要があります。

6.1.6 soainternal.example.comに関する追加手順

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

アドレスとポートの変換を有効にします。
サービスまたはノードが停止した場合に接続のリセットを有効にします。
soa.example.comと同様に、この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

6.1.7 osb.example.comに関する追加手順

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

ポート80とポート443を使用します。ポート80 (非SSLプロトコル)に入力するリクエストはすべて、ポート443 (SSLプロトコル)にリダイレクトされる必要があります。
ANYをプロトコルとして指定します(B2BではHTTPでないプロトコルが必要)。
アドレスとポートの変換を有効にします。
サービスやノードが停止した場合に接続のリセットを有効にします。
この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

これらのコンテキスト文字列は、リクエストをOracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlにルーティングするため、admin.example.comからシステムへのアクセス時にのみ使用する必要があります。

6.1.8 soahealthcare.example.comに関する追加手順

Healthcare Minimum Lower Layer Protocol (MLLP)の各エンドポイントには、ロード・バランサ上の別個の仮想サーバーが必要です。ロード・バランサは、特定ポートでいずれかのHealthcare管理対象サーバーで実行されているMLLPサービスにルーティングします。この仮想サーバーのプールは、Healthcareコンソールでエンドポイントの作成に使用されたホスト名とポートをポイントしています。

たとえば、SOAHOST1:9501 (SOAHOST2:9501にフェイルオーバー)でエンドポイントが作成されている場合、9501をサービス・ポートとして、SOAHOST1:9501およびSOAHOST2:9501を含むプールで仮想サーバーを作成する必要があります。Healthcareロード・バランサ仮想サーバーは、TCPをプロトコルとして使用し、接続のソート・ポートを維持するアドレスおよびポート・トランザクションを使用する必要があります。

6.1.9 mft.example.comに関する追加手順

Managed File Transferでは、Secure File Transfer Protocol (SFTP)に対して単一のOracle Traffic Director仮想サーバーが必要です。詳細は、「エンタープライズ・デプロイメントでのOracle Managed File Transferの構成」を参照してください。

Managed File Transferのシナリオでは、ロード・バランサによって、2つのOracle Traffic Directorインスタンス間でSFTPリクエストがルーティングされます。Oracle Traffic Directorインスタンスによって、Managed File Transfer管理対象サーバーで実行されているSFTP埋込みサーバーにリクエストがルーティングされます。一貫性を維持するため、ハードウェア・ロード・バランサ、Oracle File TransferおよびSFTPサーバーで使用されるポートは、7501です。

6.2 エンタープライズ・デプロイメントのファイアウォールとポートの構成

この項では、ファイアウォールでエンタープライズ・デプロイメント用に開く必要のあるポートを示します。

管理者は、様々なOracle Fusion Middleware製品およびサービスで使用されるポート番号を熟知している必要があります。これにより、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにし、エンタープライズ・トポロジで正しいポートがファイアウォールで開かれるようにすることができます。

次の表に、トポロジ内のファイアウォールで開く必要のあるポートをリストします。

注意:

B2BのTCP/IPポートは、ユーザーが構成するポートであり、事前定義されません。同様に、ファイアウォールのポートは、TCP/IPポートの定義によって異なります。

ファイアウォールの表記法:

FW0は、最も外側のファイアウォールを表します。
FW1は、Web層とアプリケーション層の間のファイアウォールを表します。
FW2は、アプリケーション層とデータ層との間におけるファイアウォールを示します。

すべてのFusion Middlewareエンタープライズ・デプロイメントに共通のファイアウォール・ポート

タイプ	ファイアウォール	ポートとポートの範囲	プロトコル/アプリケーション	インバウンド/アウトバウンド	その他の考慮事項とタイムアウトのガイドライン
ブラウザ・リクエスト	FW0	80	HTTP/ロード・バランサ	インバウンド	タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。
ブラウザ・リクエスト	FW0	443	HTTPS/ロード・バランサ	インバウンド	タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。
ブラウザ・リクエスト	FW1	80	HTTPS/ロード・バランサ	アウトバウンド(イントラネット・クライアント)	タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。
ブラウザ・リクエスト	FW1	443	HTTPS/ロード・バランサ	アウトバウンド(イントラネット・クライアント)	タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。
コールバックおよびアウトバウンド呼出し	FW1	80	HTTPS/ロード・バランサ	アウトバウンド	タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。
コールバックおよびアウトバウンド呼出し	FW1	443	HTTPS/ロード・バランサ	アウトバウンド	タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。
ロード・バランサからOracle HTTP Serverへ	n/a	7777	HTTP	n/a	n/a
管理サーバーによるOHS登録	FW1	7001	HTTP/t3	インバウンド	タイムアウトを短い時間(5から10秒)に設定します。
管理サーバーによるOHS管理	FW1	OHS管理ポート(7779)	それぞれTCPとHTTP	アウトバウンド	タイムアウトを短い時間(5から10秒)に設定します。
WebLogic Serverクラスタ内におけるセッション・レプリケーション	n/a	n/a	n/a	n/a	デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。
管理コンソールのアクセス	FW1	7001	HTTP/管理サーバーとEnterprise Manager t3	両方	管理コンソールへのアクセスのタイプ(アプリケーション層のクライアントからOracle WebLogic Server管理コンソールを使用する予定があるか、またはアプリケーション層の外部のクライアントから使用する予定があるか)に基づいてこのタイムアウト時間をチューニングする必要があります。
データベース・アクセス	FW2	1521	SQL*Net	両方	タイムアウトは、SOAに使用されるプロセス・モデルのタイプとデータベース・コンテンツによって異なります。
デプロイメント用Coherence	n/a	8088 範囲: 8000から8090		n/a	n/a
Oracle Unified Directoryアクセス	FW2	389 636 (SSL)	LDAPまたはLDAP/ssl	インバウンド	ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。
Oracle Notification Server (ONS)	FW2	6200	ONS	両方	Gridlinkに必要。ONSサーバーは各データベース・サーバー上で稼働します。

*外部クライアントは、RMIまたはJMSでSOAサーバーに直接アクセスできます(JDeveloperデプロイメント、JMXモニタリングなど)。この場合、実装するセキュリティ・モデルによってFW0を開く必要がある場合とない場合があります。

Oracle SOA Suiteエンタープライズ・デプロイメントに固有のファイアウォール・ポート

タイプ	ファイアウォール	ポートとポートの範囲	プロトコル/アプリケーション	インバウンド/アウトバウンド	その他の考慮事項とタイムアウトのガイドライン
WSM-PMのアクセス	FW1	7010 範囲: 7010から7999	HTTP/WLS_WSM-PMn	インバウンド	タイムアウトを60秒に設定します。
SOAサーバーのアクセス	FW1*	8001 範囲: 8000から8010	HTTP / WLS_SOAn	インバウンド	タイムアウトは、SOAによって使用されるプロセス・モデルのタイプによって異なります。
Oracle Service Busのアクセス	FW1	8011 範囲: 8011から8021	HTTP / WLS_OSBn	インバウンド/アウトバウンド	タイムアウトを短い時間(5から10秒)に設定します。
BAMのアクセス	FW1	9001 範囲: 9000から9080	HTTP / WLS_BAMn	インバウンド	レポートやブラウザが閉じられるまでBAM WebAppsへの接続は開いたまま維持されます。これによって、ユーザー・セッションの最長持続可能時間と同じ時間のタイムアウトを設定します。
MLLPリクエスト	FW0、FW1	9500 — 95nn	アプリケーション: MLLP/HC	インバウンド	タイムアウトは、予想されるMLLP転送サイズによって異なります。