• 検索結果がありません。

F5のBlG-IPロード・バランサによる高可用性を持つOracleASインフラストラクチャの構成

N/A
N/A
Protected

Academic year: 2021

シェア "F5のBlG-IPロード・バランサによる高可用性を持つOracleASインフラストラクチャの構成"

Copied!
20
0
0

読み込み中.... (全文を見る)

全文

(1)

F5 の BIG-IP ロード・バランサを用い

た OracleAS インフラストラクチャの

高可用性構成

Oracle-F5 Networks ホワイト・ペーパー

2004 年 8 月

(2)

F5 の BIG-IP ロード・バランサを用いた OracleAS イ

ンフラストラクチャの高可用性構成

概要 ... 3

アクティブ-アクティブ方式インフラストラクチャ・ソリューション... 4

基本 AFC... 4

分散 AFC... 4

基本マルチ・ノード ... 5

分散マルチ・ノード ... 5

アクティブ-アクティブ方式インフラストラクチャでのロード・

バランサの使用 ... 6

F5 の BIG-IP ロード・バランサ ... 7

基本用語 ... 7

BIG-IP ロード・バランサを使用するアクティブ-アクティブ方式

インフラストラクチャの構成 ... 9

定義 ... 9

構成手順 ... 11

プールの作成... 11

ルールの作成... 12

仮想サーバーの作成およびプール/ルールとの関連付け... 12

モニターの作成およびノードとの関連付け... 13

冗長 BIG-IP への情報の伝播 ... 14

インフラストラクチャのインストール前の手順 ... 14

Staticports.ini... 14

ロード・バランサ構成... 14

インストール ... 15

インストール後の手順 ... 15

両方のノードで OID トラフィックを有効化... 15

検証手順 ... 15

SSO および DAS のための SSL プロキシの構成 ... 15

ロード・バランサ構成... 15

SSO の構成... 16

DAS の構成 ... 16

検証手順... 17

中間層インストール時のロード・バランサ構成 ... 17

付録 A - Staticports.ini テンプレート ... 18

基本 AFC および基本マルチ・ノード・インストール用... 18

分散 AFC インストールおよび分散マルチ・ノード・

インストール用 ... 18

(3)

F5 の BIG-IP ロード・バランサを用いた OracleAS イ

ンフラストラクチャの高可用性構成

概要

Oracle Application Server インフラストラクチャは、アプリケーション・デプロイ のために集中化されたセキュリティおよび管理プラットフォームを提供します。 これには、Oracle Identity Management インフラストラクチャの他、集中化された Product Metadata 管理および構成管理の機能を含みます。このインフラストラク チャは、Oracle9i Application Server 9.0.2 への導入以降、引き続き Oracle Application Server 10g(9.0.4)でも提供されています。

Oracle Application Server のデプロイメントの高可用性のためには、高可用性を提 供するインフラストラクチャ・サービスが必要です。Oracle Application Server 10g (9.0.4)リリースは、様々な顧客要件に合せて、多様な高可用性(HA)アーキテ

クチャでインフラストラクチャ配置をサポートします。主な HA ソリューション には、Cold Failover Cluster(CFC)、Active Failover Cluster(AFC)、Multi Node (ラック・マウント型)インフラストラクチャなどがあります。Active Failover Cluster およびマルチ・ノードのインフラストラクチャ・ソリューションは、本質 的にアクティブ-アクティブ方式です。アクティブ-アクティブ方式では、異なる サーバーにインフラストラクチャ・プロセスの複数のインスタンスがあり、同時 にリクエストの処理を意味します。すべてのアクティブ-アクティブ方式配置で、 ハードウェア・ロード・バランサは、このような同時にアクティブなインスタン ス全体に、着信 OID(Oracle Internet Directory)、SSO(Single Sign On)、および DAS(Delegated Administrative Service)の各サービス・リクエストを分配します。 いずれかのインスタンスで障害が発生すると、ロード・バランサは単に以後のリ クエストを有効なインスタンスに送ります。

したがって、ロード・バランシングとフェイルオーバーの機能を提供するハード ウェア・ロード・バランサは、アーキテクチャにとって不可欠といえます。さら に、ロード・バランサの SSL アクセラレータ機能も、Single Sign On および DAS における HTTPS ベースへの接続に SSL プロキシとして使用できます。高可用性 の実現には、常にロード・バランサを冗長的に配置します。このホワイト・ペー パーは、オラクル社および F5 Networks 社により共同で執筆されたもので、F5 の BIG-IP ロード・バランサを高可用性(HA)インフラストラクチャ配置で使用する 場合の構成および運用上のベスト・プラクティスについて説明します。

(4)

アクティブ-アクティブ方式インフラストラクチャ・ソリュー

ション

Oracle Application Server 10g(9.0.4)の主要なアクティブ-アクティブ方式インフラ ストラクチャ高可用性ソリューションは、Active Failover Cluster(AFC)およびマ ルチ・ノード・インフラストラクチャ・ソリューションです。理解しやすくする ため、データベース層、OID 層、Web 層(Oracle Single Sign-On および Delegated Administrative Service アプリケーションを稼働する Oracle HTTP サーバーと OC4J インスタンスがあります)の 3 つの層の配置を仮定します。次のブロック・ダイ アグラムに、このアーキテクチャの配置を示します。アーキテクチャの基本配置 と分散配置の両方が示されています。このような高レベル・ブロック・ダイアグ ラムは、様々なアクティブ-アクティブ方式のアーキテクチャを説明することが目 的です。複雑なトラフィックも一緒に表示した詳細なダイアグラムは別に提供さ れています。ここでのデータベース層は常に Real Application Clusters(RAC)ベー スとして仮定します。ただし、多くの場合、これはコールド・フェイルオーバー・ クラスタ構成で配置されるデータベースとしても可能です。

基本 AFC

図 1: 基本 Active Failover Cluster のブロック・ダイアグラム

基本 AFC 配置(前述の図 1)には、1 つのハードウェア・クラスタの 2 つのノー ド上に 3 つの層が示されています。この場合、単一のインストール・セッション で、ハードウェア・クラスタにすべての層がインストールされます。

分散 AFC

(5)

一般的な分散 AFC 配置における Web 層の 2 つのインスタンスは、データベース と OID 層を持つクラスタとは異なる 2 台のマシンに置かれます。この場合、ハー ドウェア・クラスタで 1 回のインストールが必要です。これにより、データベー ス層と OID 層がインストールされます。Web 層のその後のインストールは、別の マシンで独立して行われます。Web 層の各インスタンスに対し 1 回のインストー ルが必要です。

基本マルチ・ノード

図 3: 基本マルチ・ノード・インフラストラクチャのブロック・ダイアグラム 基本マルチ・ノード・インフラストラクチャ HA 配置(前述の図 3)は、2 台の独 立したマシンに(冗長性のため)OID 層および Web 層があり、RAC クラスタとし てデータベース層を持ちます。データベース層は、OracleAS repCA(リポジトリ 構成アシスタント)を使用して既存の RAC データベースに作成されます。OID 層 および Web 層は、複数のマシンの同じ Oracle Home に一緒にインストールされま す。マシンへの各インストールは、独立したインストール・セッションです。

分散マルチ・ノード

図 4: 分散マルチ・ノード構成

分散マルチ・ノード構成(図 4)は、ハードウェア・クラスタ上の RAC データベー ス層と 2 台以上の独立したマシン上の OID 層と 2 台以上の独立したマシン上の Web 層を持ちます。この場合、OID 層は、同じ RAC クラスタに共存できますが、 データベース・インストールとは別の Oracle Home に置きます。データベース層 は、OracleAS repCA(リポジトリ構成アシスタント)を使用して既存の RAC デー タベースで作成されます。OID 層は、2 台以上の独立したマシンへ別々にインス

(6)

トールされます。これは、それぞれ独立したインストールです。Web 層も、独立 したインストール・セッションである各インストールで複数のマシン上にインス トールされます。

ここではこれらのアーキテクチャの完全な説明と詳細なインストールについて説 明しませんが、他のオラクル・ドキュメントと関連ホワイト・ペーパーでは説明 しています。基本AFC構成のインストールは、『Oracle Application Server 10g イン ストレーション・ガイド』で説明しています。分散AFC構成のインストールは、 ホワイト・ペーパー『高可用性の分散ID管理』で説明しています。基本および分 散マルチ・ノード構成のインストールは、ホワイト・ペーパー『ID管理の可用性 を高める配置例: マルチボックスID管理』で説明しています。

アクティブ-アクティブ方式インフラストラクチャでのロー

ド・バランサの使用

前述したアーキテクチャのすべてのバリエーションでのハードウェア・ロード・ バランサは、LDAP トラフィックに対する着信リクエストを OID 層に送り、HTTP トラフィックに対する着信リクエストを Web 層に送る構成がされています。これ らは、インフラストラクチャのクライアント、中間層ノード、またはユーザー・ ブラウザからリクエストされます。データベースに対する Oracle Net トラフィッ クは、Oracle Net ロード・バランシングで、Oracle Net 接続記述子と複数アドレス をそのアドレス・リストに指定することによりロード・バランシングされます。 典型的な OID LDAP 接続は、中間層コンポーネントの起動時に、SSO/DAS および 中間層コンポーネントから確立され、接続の寿命の間は常に使用可能で、接続指 向的です。したがって、ロード・バランサは、これらの接続をタイムアウトしな いことが重要です。また、リクエストの瞬間のみ有効な他の OID LDAP リクエス トもあります。OID 接続は、2 つのポートで確立されます。その 1 つは OID の SSL 暗号化接続、もう 1 つは非 SSL 接続に使用されます。各ポートは、インストール 時に定義されます。ポートは、インストーラに自動的に選択させるか、またはユー ザーの事前定義ができます。アクティブ-アクティブ方式の HA インフラストラク チャのインストールでは、Oracle Installer の Static Ports 機能によりポートの事前定 義をお薦めします。インストーラによりポートが選択される場合、非 SSL OID ポー トのデフォルトは(使用中でない場合)389 で、可能なポートは 389 と 3060∼3129 の範囲の空いている 1 つです。また SSL OID ポートのデフォルトは 636 で、可能 なポートは 636 と 3130∼3199 の範囲の空いている 1 つです。

Oracle HTTP Server に対するクライアント接続は、主に SSO サービスおよび DAS サービスのためです。これらは、HTTP または HTTPS ができます。これらの大部 分は、インフラストラクチャ自体の外部、主にユーザーのブラウザから送られま す。ロード・バランサは、いずれかのノードの HTTP サーバーにこのトラフィッ クを振り分けます。HTTP サーバーは、リクエストをローカル OC4J インスタンス に転送し、SSO/DAS リクエストに対応します。 SSO HTTP/HTTPS リクエストは、本質的にステートレスです。これらの接続に関 する滞留時間の要件はありません。DAS HTTP/HTTPS リクエストは、ステート指 向であり、滞留時間が必要です。SSO と DAS は、同じ OC4J コンテナで稼働する 2 つの独立したアプリケーションです。HTTP プロセスの共有セットは、この OC4J コンテナにトラフィックを送ります。使用される HTTP/HTTPS ポートは、インス

(7)

トール時に定義されます。ポートは、インストーラの自動的な選択も、またはユー ザーの事前定義もできます。アクティブ-アクティブ方式の HA インフラストラク チャのためのインストールでは、Oracle Installer の Static Ports 機能によりポートの 事前定義をお薦めします。インストーラによりポートが選択される場合、HTTP ポートのデフォルトは 7777 で、可能なポートは 7777∼7877 の範囲の空いている 1 つです。また HTTPS ポートのデフォルトは 4443 で、可能なポートは 4443∼4543 の範囲の空いている 1 つです。 多くの配置では、ファイアウォールにより、ロード・バランサと一部の層を隔て ることができます。そのような場合、層がファイアウォールに対する層の位置に よって、ファイアウォールでの適切なポートのオープンが必要となります。オー プンが必要なのは、Oracle Net ポート、SSL 接続と非 SSL 接続のための OID ポー ト、HTTP ポートと HTTPS のポートです。

前述のブロック・ダイアグラムでは、複数のロード・バランサを示していますが、 OID 層と Web 層の両方に対して同じロード・バランサ・デバイスの使用もありま す。

基本 AFC と基本マルチ・ノード構成では、OID 層と Web 層がそれぞれ専用のポー トで、同じロード・バランサ仮想サーバー・ホスト名を使用します。分散 AFC と 分散マルチ・ノード構成では、OID 層と Web 層がそれぞれ異なるロード・バラン サ仮想サーバーでそれぞれ専用のポートを使用します。

F5 の BIG-IP ロード・バランサ

このドキュメントでは、BIG-IP ロード・バランサについての十分な理解を前提と しています。次にこの後に役立ついくつかの基本用語について説明します。詳細 は、『BIG-IP Solutions Guide』および『BIG-IP Reference Guide』を参照してくださ い。次の定義は、これらのガイドからの抜粋です。

この後の説明で仮定している BIG-IP のバージョンは、BIG-IP 4.5 です。iControl API ドキュメントについては、iControl SDK 4.5 を参照してください。

基本用語

アプリケーション・トラフィックを適切なサーバーに送るために BIG-IP システム による基本要素は 4 つあります。それは、仮想サーバー、プール、ルールおよび ノードです。その他の要素としては、モニター、プロキシなどがあります。一般 に BIG-IP システムには、複数の仮想サーバー、プール、および関連ノード(メン バー)を含みます。 プール プールとは、ロード・バランシング方式にしたがってトラフィックを受信するた めにグループ分けされたデバイス(サーバー)のセットです。プールのメンバー は、1 つまたは複数のサーバー(ノードと呼ばれる)で構成され、IP アドレスと ポート(IP address:port)の組合せで定義されます。各プールは、永続性(滞留時 間)定義と使用されるロード・バランシング・アルゴリズムの点でそれぞれ独自 の特性を持ちます。プールは、特定の仮想サーバーや iRule と関連付けられます。 したがって、仮想サーバーに到着するトラフィックは、通常関連付けられたプー

(8)

ルの 1 つに送られます。プールは、リクエストを受け取ると、選択されたロード・ バランシング方式に基づいてプールのメンバーにさらに転送します。プールは、 仮想サーバーから直接またはルールを介してトラフィックの受取り後、任意に 様々な種類の操作ができます。たとえば、HTTP リクエストへのヘッダーの挿入、 パケット内のサービス品質またはサービス・タイプのレベルの設定、フォールバッ ク宛先に対するリクエストのリダイレクトなどです。 仮想サーバー 仮想アドレスを持つ仮想サーバーは、クライアントがアドレス指定できるホスト 名/IP およびポートです。それによって、クライアントは、ロード・バランシング・ プールのノードを、直接またはルールを介して間接的に利用できます。つまり、 仮想サーバーとは、BIG-IP がトラフィックをロード・バランシングするデバイス へのアクセスにクライアントによって使用されるホスト・アドレス/IP です。仮想 サーバーの作成前に、トラフィックの転送先とする実際の物理デバイスのロー ド・バランシング・プールの構成が必要となります。その後、仮想サーバーを作 成してそのサーバーからのトラフィックの宛先として、そのプールが指定できま す。さらに、トラフィックの一部を仮想サーバーから事前に定められた基準に基 づく複数のプールへ送る場合、基準を指定するルールを作成しておくと、BIG-IP により基準に合うプールへ適切にトラフィックが転送されます。 ルール ルールとは、2 つ以上のロード・バランシング・プールの中から選択するユーザー が作成したスクリプトです。つまり、仮想サーバーにおける特定な着信リクエス トについて、それを送信するプールをルールは選択します。そのため、トラフィッ クのリダイレクトに対してより細かいレベルでの制御がルールによって可能にな ります。 あるリクエストのためにルールから選択されたプールは、それ自体が 1 つまたは 複数のメンバーになります。 モニター モニターは、ノードの状態またはノード・アドレスの確認に使用します。モニター は、ロード・バランシング・プールのメンバーであるノードで接続とサービスを 確認します。モニターは、設定されたインターバルでその時点のノードまたはサー ビスのステータスを確認する設計がされています。チェック対象のノードまたは サービスが指定されたタイムアウト期間内に応答しない場合、またはノードのス テータスとしてノードのパフォーマンス低下が示された場合、BIG-IP システムが 自動的にそのプールを外してプールの他のメンバーにトラフィックをリダイレク トします。ノードまたはサービスが使用可能になると、モニターはこれを検出し、 ノードまたはサービスが自動的にプールへ戻されます。 プロキシ BIG-IP システムは、SSL Accelerator プロキシにより、完全に SSL カプセル化され たプロトコルで送信されたすべての接続を受け入れて終了できます。オプション として、ターゲット Web サーバーに対する安全な接続の開始にも SSL プロキシを

(9)

構成できます。インフラストラクチャでは、一般的に SSO/DAS HTTP リクエスト 用として使用されます。このホワイト・ペーパーでは、その例を示します。

BIG-IP ロード・バランサを使用するアクティブ-アクティブ方式

インフラストラクチャの構成

ここからは、ロード・バランサ構成における最も一般的な要件について検討しま す。ここでは、基本 BIG-IP セットアップ、VLAN のセットアップなど必要となる 事前構成作業が完了していることを前提にします。ここでのロード・バランサ構 成の説明は、アクティブ-アクティブ方式インフラストラクチャ構成において必要 なものに限定します。アクティブ-アクティブ方式インフラストラクチャの構成に は、このコンテキストで次の手順が重要です。 • 仮想サーバー名、oidPort、oid_sslPort および sso_dasPort を決定します。 • 仮想サーバーに割り当てられた IP アドレスを取得し、これが Domain Name Server(DNS)に含まれていることを確認します。 • 次のガイドラインに基づいて F5 BIG-IP を構成します。 • OracleAS インフラストラクチャ・インストール用の staticports.ini ファイ ルを作成し、以前に決定された、ロード・バランサ構成で消費されるポー トを使用します。 • ロード・バランサとサービス/クラスタ・ノードが異なるセキュリティ・ ゾーンにある場合(1 つ以上のファイアウォールにより区切られている場 合)、ファイアウォール間の双方向トラフィックのために適切なポート がオープンであることを確認します。 • インストールされていないノードやロード・バランサで停止している ノードを適切にマークします。 • ここで作成した staticports.ini ファイルによりインフラストラクチャをイ ンストールします。

定義

ポート数 次の表に、これから使用するポートを定義します。理解しやすくするため、特定 なサービスに使用されるポートはサービスのすべてのインスタンスで同じと仮定 します。たとえば、server1 で OID に使用されるポートが oidPort の場合、同じポー トが OID の冗長インスタンスの OID にも使用されます。多くの場合、これは OracleAS インストールにより自動です。

サービス ポート

OID ポート oidPort SSL 接続用の OID ポート oid_sslPort

SSO および DAS URL で使用される HTTP ポート sso_dasPort

Application Server Control ポート emPort SSO および DAS URL で使用される HTTPS ポート sso_das_sslPort

(10)

リアル・サーバー

次の表に、この後の説明で必要な物理ホスト名をリストします。これをデータベー ス層、OID 層、Web 層(SSO と DAS)の 3 つの層に分けました。

サーバー・タイプ ホスト名

データベース層のホスト d1.acme.com と d2.acme.com OID 層のホスト o1.acme.com と o2.acme.com Web 層のホスト s1.acme.com と s2.acme.com

基本 AFC インストールの場合、この 3 つの層はすべて同じハードウェア・クラス タ上にあり、o1=s1=d1 および o2=s2=d2 となります。分散 AFC インストールの場 合、データベースと OID は同じクラスタにあり、Web 層は別のボックスにあるた め、d1=o1 および d2=o2 です。 基本マルチ・ノード HA インストールの場合、OID 層と Web 層は同じボックスに 一緒にインストールされるため、o1=s1 および o2=s2 となります。分散マルチ・ノー ド・インストールの場合、通常サーバーはすべて異なります。 プール名 次の表に、ロード・バランサで構成されるプールをリストします。プール・メン バーは、プールが着信リクエストをバランシングする host:port です。 プール・タイプ プール名 プール・メンバー

OID に対する非 SSL 接続 ldap o1.acme.com:oidPort o2.acme.com:oidPort

OID に対する SSL 接続 ldap_ssl o1.acme.com:oid_sslPort o2.acme.com:oid_sslPort

SSO サービスに対する HTTP 接続 sso s1.acme.com:sso_dasport s2.acme.com:sso_dasPort

DAS サービスに対する HTTP 接続 das s1.acme.com:sso_dasport s2.acme.com:sso_dasPort

OID 層での EM ポートに対する HTTP 接続 em_ldap o1.acme.com:emPort o2.acme.com:emPort Web 層での EM ポートに対する HTTP 接続 em_sso s1.acme.com:emPort

s2.acme.com:emPort

SSO サービスに対する HTTPS 接続 sso_ssl s1.acme.com:sso_das_sslPort s2.acme.com:sso_das_sslPort

DAS サービスに対する HTTPS 接続 das_ssl s1.acme.com:sso_das_sslport s2.acme.com:sso_das_ssl port

仮想サーバー

この表は、OID 層と Web 層の仮想サーバーを一覧表示しています。仮想サーバー のホスト名は、Domain Name Server の一部として必要です。

基本 AFC インストールおよび基本マルチ・ノード・インフラストラクチャ・イン ストールの場合、両方の層に対して 1 つのみの仮想サーバー・ホスト名、つまり oid=sso が存在します。これらのアーキテクチャの分散形式では、oid≠sso です。

(11)

仮想サーバーは、virtualhost:port(service)ベースで BIG-IP に作成されます。理解 しやすくするため、仮想サーバー・ポートが、マップされるプールのポートと同 じであると仮定しました。たとえば、仮想サーバーの oid ポートはプールの oid ポー トと同じであり、すなわち OID がリスニングするポートと同じです。ただし、こ れらは異なっていてもかまいません。ただしこれは、インストール後のみ可能で す。OID アクセス・ポートまたは SSO アクセス・ポートの変更に必要な詳しい手 順は、『Oracle Application Server 管理者ガイド』を参照してください。

仮想サーバー・タイプ 仮想サーバー名 OID 層の仮想サーバー oid.acme.com:oidPort OID 層(SSL)の仮想サーバー oid.acme.com:oid_sslPort Web 層の仮想サーバー sso.acme.com:sso_dasPort OID 層の EM の仮想サーバー oid.acme.com:emport SSO 層の EM の仮想サーバー sso.acme.com:emport Web 層(SSL)の仮想サーバー sso.acme.com:sso_das_sslport ルール

Web 層仮想サーバーは、sso プールと das プールの 2 つにマップされる予定です。 この場合、着信トラフィックを管理し、2 つのプールに分配するルールが必要で す。

ルールの機能 ルール名

Web 層の着信 HTTP トラフィックを sso プールまたは das プール のいずれかに送るルール sso_das_rule

構成手順

プールの作成

BIG-IP 構成プールによる新しいプールの作成には、冗長ロード・バランサ構成の アクティブなロード・バランサに接続し、「プール」をクリックし、「+」ボタン をクリックします。各プールは個別の作成が必要です。これらのプールの特性に ついて、次の表で説明します。 プール名 プール・メンバー 永続性 ロード・バランシング ldap o1.acme.com:oidPort 02.acme.com:oidPort 永続性なし 最小接続(メンバー) またはラウンド・ロビン ldap_ssl o1.acme.com:oid_sslPort 02.acme.com:oid_sslPort 永続性なし 最小接続(メンバー) またはラウンド・ロビン sso s1.acme.com:sso_dasPort s2.acme.com:sso_dasPort 永続性なし 最小接続(メンバー) またはラウンド・ロビン das s1.acme.com:sso_dasPort s2.acme.com:sso_dasPort アクティブな HTTP Cookie 方法: 挿入 有効期限: NULL 最小接続(メンバー) またはラウンド・ロビン

(12)

em_ldap o1.acme.com:emPort 02.acme.com:emPort アクティブな HTTP Cookie 方法: 挿入 有効期限: NULL 最小接続(メンバー) またはラウンド・ロビン ern_sso s1.acme.com:emPort s2.acme.com:emPort アクティブな HTTP Cookie 方法: 挿入 有効期限: NULL 最小接続(メンバー) またはラウンド・ロビン それに加え、プールのそれぞれについて次の有効(デフォルトにより)が必要で す。 Enable SNAT Enable NAT

ルールの作成

ルールの作成には、「Rules」をクリックし、「+」をクリックして、新しいルー ルを追加します。 SSO_DAS_rule

if (http_uri starts_with "/oiddas/") { use pool das

} else { use pool sso }

仮想サーバーの作成およびプール/ルールとの関連付け

仮想サーバーを作成してそれぞれ対応するプールまたはルールと関連付けます。 仮想サーバーの作成には、「Virtual Servers」をクリックし、「+」をクリックし て、新しい仮想サーバーを追加します。 Address サービス プール ルール oid.acme.com oidPort ldap なし oid.acme.com oid_sslPort ldap_ssl なし

sso.acme.com ssoPort なし sso_das_rule oid.acme.com emPort em_Idap なし

sso.acme.com emPort em_sso なし

その他のデフォルト・エントリは、仮想サーバー作成に適しています。

OID サービスに関係する仮想サーバーの場合(oid.acme.com:oidPort と

oid.acme.com:oid_sslPort)、TCP Enabled がチェックされ、Idle Connection Timeout TCP(seconds)が十分に大きい値(たとえば 345600)に設定されていることを確

(13)

モニターの作成およびノードとの関連付け

次のモニターを作成します。モニターの作成には、「Monitors」をクリックし、 「+」をクリックして、新しいモニターを追加します。 モニター名 構成 infra_http http から継承 Interval: 20 Timeout: 61

Send String: GET /sso/status

Receive Rule: OC4J_SECURITY is running

infra_ldap ldap から継承

Interval: 20 Timeout: 61

Username: cn=orcladmin Pas sword: orcladmin_password Filter: cn=databasename infra_ldap_ssl tcp から継承 Interval: 20 Timeout: 61 モニターのインターバルとタイムアウトは、必要な要件に基づいて調整が必要で す。 インターバルは、BIG-IP がサービスをピングする頻度です。またタイムアウトは、 サービスを停止する決定までに待つ最大時間です。 インターバル時間が短いと(たとえば 5 秒)、ピングの頻度が高くなりますが、 サービスが停止した場合の自動フェイルオーバーが速くなります。 タイムアウトの最小値は、interval*3+1 です。ネットワーク遅延のため、低速のバッ クエンド・サーバーや負荷の高いサーバーでは、偽のアラームの防止に、この値 を高めに調整する必要があります。

OPMN(Oracle Process Manager and Notification server)プロセスは、アプリケーショ ン・サーバー・コンポーネント・プロセスをモニターして再起動することに注意 してください。したがって、ここで指定するインターバルとタイムアウトの値が、 コンポーネントの ORACLE_HOME/opmn/conf/opmn.xml に指定されたピング・タ イムアウト値および再起動タイムアウト値で正しく機能することは重要です。前 述の値は、推奨されるデフォルト設定です。 モニターの作成後、次のノードとモニターを関連付けます(ノード関連付け)。 モニター名 ノード infra_http s1.acme.com:sso_dasport s2.acme.com:sso_dasPort infra_ldap o1.acme.com:oidPort o1.acme.com:oidPort infra_ldap_ssl o1.acme.com:oid_sslPort o1.acme.com:oid_sslPort

(14)

Application Server Control 関係のプールのモニターは、オプションで停止できるた め、ここには示しません。ただし、必要に応じて同様のモニターが作成できます。 infra_ldap モニターが orcladmin パスワードを表示することでこれを作成できない 場合、非 SSL oid ポートのかわりに infra_ldap_ssl モニターが使用できます。

冗長 BIG-IP への情報の伝播

特に冗長ロード・バランサの配置が推奨されているため、ここでのアクティブな ロード・バランサの構成を、冗長構成の他のロード・バランサに伝播が必要です。 BIG-IP Configuration Utility では、ホームページで「Redundant Properties」をクリッ クし、「Synchronize Configuration」をクリックします。 これは、新しく作成された構成を冗長ロード・バランサに伝播し、アクティブな ロード・バランサで障害が発生した場合に新しい構成をすぐに使用できるように します。

インフラストラクチャのインストール前の手順

ここでは、各種アクティブ-アクティブ方式のインフラストラクチャ配置のインス トールで一般的なインストール前の手順について説明します。これは、この構成 での BIG-IP ロード・バランサに関係する手順です。その他の詳細なインストール 前の手順については、『Oracle Application Server 10g インストレーション・ガイ ド』を参照してください。

Staticports.ini

各層に staticports.ini ファイルを作成します。

Oracle インストーラの Static Ports 機能により、インストールに特定なポートの使 用が保証されます。これらのポートは、関係するすべてのノードで確実にフリー なことを前提としています。計画プロセスでは、各種ポート(oidPort、oid_sslPort、 httpPort、emPort)の決定に考慮が必要となります。 理解しやすくするため、すべてのノードとすべてのマシンで emPort が同じである と仮定しました。テンプレートについては、付録 A を参照してください。

ロード・バランサ構成

インストール中に 1 つの OID にのみロード・バランサをポイントすることがイン フラストラクチャ・インストールの要件です。ロード・バランサは、両方のノー ドにトラフィックを送りながら、層の中のインストールされたノードにはトラ フィックを送らない構成が必要となります。 インストールされていないノードにトラフィックを送らないためには、「Nodes」 をクリックしてから、インストールされていないノードをクリックし、これらの インストール前に次を操作します。

インストールされていない OID ノードの「Enable Session」を無効にする。 o2.acme.com:oidPort

インストールされていない OID ノードの「Enable Connections」を無効にする。 o2.acme.com:oid_sslPort

(15)

インストール

インフラストラクチャのインストールです。構成に応じて、1 つ以上のインストー ル・セッションが必要なことがあります。どの場合も、ファイル staticports.ini の 使用に必要な引数を指定してインストールを開始してください。

インストール後の手順

ここで説明するインストール後の手順は、この構成での BIG-IP ロード・バランサ に関係するものであり、アクティブ-アクティブ方式のインフラストラクチャ配置 のすべてのインストールで共通です。その他の詳細なインストール後の手順につ いては、『Oracle Application Server 10g インストレーション・ガイド』と『Oracle Application Server 10g Notes』を参照してください。

両方のノードで OID トラフィックを有効化

すべてのノードに対する OID トラフィックの有効化には、「Nodes」をクリック してから、インストールされていないノードをクリックし、それぞれのインストー ル前に次を操作します。

インストールされていない OID ノードの「Enable Session」を有効にする。 o2.acme.com:oidPort

インストールされていない OID ノードの「Enable Connections」を有効にする。 o2.acme.com:oid_sslPort

検証手順

http://sso.acme.com:sso_dasPort/oiddasに複数回アクセスして検証します。 http://sso.acme.com:sso_dasPort/pls/orassoに複数回アクセスして検証します。

SSO および DAS のための SSL プロキシの構成

一般的セキュリティ要件は、クライアント・ブラウザからロード・バランサへの トラフィックの SSL 暗号化です。その場合、ロード・バランサは、SSL アクセラ レータとして機能し、変換された http トラフィックを Web 層 HTTP リスナーに送 ります。これは、SSO ログインに必要なセキュリティを提供しますが、Web 層マ シンに対する SSL の負荷はありません。このための Web 層と BIG-IP ロード・バ ランサを構成する、インストール後の手順を次に示します。

この例では、SSO アクセス URL を login.acme.com に、ポートを 443(標準 https ポート)に変更します。

ロード・バランサ構成

「Proxy」をクリックし、「+」をクリックして新しいプロキシを作成することで、 次の SSL プロキシを作成します。プロキシは、次のプロパティを持つ必要があり ます。 Proxy Type: SSL

Proxy Address: login.acme.com Proxy Service: https

(16)

Destination Service: sso_dasPort Destination Target: Local Virtual Server SSL Certificate: <appropriate entry> SSL Key: <appropriate entry>

使用の環境に合ったプロパティをテストします。

SSO の構成

それぞれの Web 層のマシンで、次の変更を実行します。 • IP チェックをオフにします。 ° SSO管理ページにログインします (http://sso.acme.com:sso_dasPort/pls/orasso)。 ° 「SSO Server Administration」をクリックします。 ° 「Edit SSO Server configuration」をクリックします。

° 「Verify IP addresses for requests made to the SSO Server」の選択を 解除します。 • プロキシ・サーバーを有効にします。 ° いずれかの Web 層インストールから次を実行します。 $ORACLE_HOME/sso/bin/ssocfg.sh https login.acme.com 443 ° 各 Web 層インストールの ORACLE_HOME の $ORACLE_HOME/Apache/Apache/conf/httpd.conf で次を変更します。 KeepAlive Off ServerName login.acme.com Port 443 ° 次を同じ httpd.conf ファイルに追加します。

LoadModule certheaders_module libexec/mod_certheaders.so SimulareHttps on ° Web 層で http サーバーを再起動します。

DAS の構成

OID 層のいずれかのノードから次を操作します。 ° OID 管理ツールを開始します。 „ ORACLE_HOME 環境変数を設定します。 „ 必要に応じて、DISPLAY 環境変数を設定します。 „ OID 管理ツール$ORACLE_HOME/bin/oidadmin を開始します。 ° Server をローカル・ホストに設定し、Port を oidPort に設定します。 ° cn=orcladmin としてログインします。

(17)

° 「Entry Management」→「cn=OracleContext」→「cn=Products」→ 「cn=DAS」→「cn=OperationURLs」と順にナビゲートして、 「orcldasurlbase」の入っているエントリに移動します。 ° 次のようにorcldasurlbase属性値を変更して、「Apply」をクリックします。 https://login.acme.com/

検証手順

https://login.acme.com/oiddasに複数回アクセスして検証します。 https://login.acme.com/pls/orassoに複数回アクセスして検証します。

中間層インストール時のロード・バランサ構成

中間層のインストール時、OID 層(oid.acme.com)に使用されるロード・バランサ 仮想サーバーは、インストール中 1 つのノードのみをポイントする構成が必要で す。サービスの中断を最小限にしながら、これを可能にするには、次に示すロー ド・バランサ構成での設定が必要です。 中間層インストール前に、仮想サーバーoid.acme.com に対して

1 つを除くすべての OID ノードの「Enable Session」を無効にする。 (たとえば o1.acme.com:oidPort)

中間層インストールの成功後、仮想サーバーoid.acme.com に対して すべての OID ノードの「Enable Session」を有効にする。

(18)

付録 A - Staticports.ini テンプレート

基本 AFC および基本マルチ・ノード・インストール用

テンプレートstaticports.iniファイル

Oracle HTTP Server port = httpPort

Oracle HTTP Server Listen port = httpPort Oracle HTTP Server SSL port = http_sslPort

Oracle HTTP Server Listen (SSL) port = http_sslPort Oracle HTTP Server Diagnostic port = nnnn

Oracle Notification Server Request port = nnnn Oracle Notification Server Local port = nnnn Oracle Notification Server Remote port = nnnn Application Server Control RMI port = nnnn Application Server Control port = emPort Oracle Management Agent port = nnnn Oracle Internet Directory port = oidport

Oracle Internet Directory (SSL) port = oid_sslPort

分散 AFC インストールおよび分散マルチ・ノード・インストール用

OID層のテンプレート - staticports.ini.oidファイル

Oracle Notification Server Request port = nnnn Oracle Notification Server Local port = nnnn Oracle Notification Server Remote port = nnnn Application Server Control RMI port = nnnn Application Server Control port = emPort Oracle Management Agent port = nnnn Oracle Internet Directory port = oidport

Oracle Internet Directory (SSL) port = oid_sslPort

Web層のテンプレート - staticports.ini.ssoファイル

Oracle HTTP Server port = httpPort

Oracle HTTP Server Listen port = httpPort Oracle HTTP Server SSL port = http_sslPort

Oracle HTTP Server Listen (SSL) port = http_sslPort Oracle HTTP Server Diagnostic port = nnnn

Oracle Notification Server Request port = nnnn Oracle Notification Server Local port = nnnn Oracle Notification Server Remote port = nnnn Application Server Control RMI port = nnnn Application Server Control port = emPort Oracle Management Agent port = nnnn

(19)

F5 の BIG-IP ロード・バランサを用いた OracleAS インフラストラクチャの高可用性構成 2004 年 8 月

著書: Pradeep S.Bhat、HA Systems Group、オラクル社 寄稿者: Randy Cleveland、F5 Networks

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com このドキュメントはあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。 内容の誤りがある場合は、オラクル社までお知らせください。 オラクル社は、このドキュメントに関する保証を行うものでなく、また、記載の内容に対して責任を負いません。 Oracle はオラクル社の登録商標です。 このガイドで使用されているさまざまな製品名およびサービス名には、オラクル社の商標が含まれています。 その他のすべての製品名およびサービス名は、各社の商標です。

Copyright © 2004 Oracle Corporation All rights reserved.

F5 Networks, Inc. 401 Elliott Avenue West Seattle, WA 98119 U.S.A. 海外からのお問合せ窓口: 電話: +1.206.272.5555 ファックス: +1.206.272.5556 www.f5.com

(20)

F5、F5 Networks、BIG-IP、Control、iRules は、米国およびその他の国における F5 Networks, Inc.の商標 または登録商標です。本書に記載されている他のすべての商標は、それぞれの所有者に所有権があります。 F5 Networks の商標は、F5 の書面による許可がある場合を除き、いかなる製品またはサービスに関連して使用 することも禁じられます。

図 1:  基本 Active Failover Cluster のブロック・ダイアグラム
図 4:  分散マルチ・ノード構成

参照

関連したドキュメント

中間層 Oracle Application Server インスタンスおよび Infrastructure

『Oracle Content Database Installation Guide』、「Oracle Content DB 中間層のインストール」の章の手順に従って Oracle

Port Klang Terengganu FGV KILANG SAWIT JERANGAU BARAT Port Klang Pahang FGV KILANG SAWIT KERATONG 3 Port Klang Pahang FGV KILANG SAWIT SEROJA Port Klang Pahang FGV

今回、日本オラクル株式会社と株式会社日立製作所は Oracle GRID Center にて、日立の高性 能 ブ レ ー ド ・ サ ー バ ーBladeSymphony と Oracle Application Server

Remote Sharing Support for DLNA Appliances with Rule-based Access Control Functions Daigo Muto†1 and Tsutomu Yoshinaga†1 We developed a software named wormhole device WD

「成長可能性都市ランキング」結果 成長可能性都市ランキング 結果まとめ 第1位 第2位 第3位 総合ランキング

サーバサイドのネットワークは、前段に WebAccelerator Module を組み込んだ BIG-IP 6400 (v9.4)を設置 し、その背後に Web サーバおよび

Features and Sustainability of Local Public Finance in Remote