|
|
|
|
|
|
| | | |
WebLogic Server クラスタのプランニング
以下の節では、1 つまたは複数の WebLogic Server クラスタをデプロイする前に考慮すべき一般的な問題について説明します。
概要
「 WebLogic Server のクラスタ化の概要」および「 WebLogic クラスタの管理」の各章も併せて読み、WebLogic Server クラスタの操作方法についてよく理解してください。
この節では、WebLogic Server 向けの推奨クラスタ アーキテクチャについても説明します。各推奨アーキテクチャをよく検討した上で、Web アプリケーションに最適なコンフィグレーションを決定してください。
キャパシティ プランニング
この節は、クラスタ化されたシステムのネットワーク トポロジのプランニングに重点を置いています。Web アプリケーションのロード バランシング機能およびフェイルオーバ機能を最大限に利用できるよう、ここでは、1 つまたは複数の WebLogic Server クラスタを、ロード バランサ、ファイアウォール、および Web サーバに関連付けてプランニングする方法について説明します。この種類のプランニングはクラスタ システムのキャパシティに直接影響しますが、ここでは従来のキャパシティ プランニングについては説明しません。クラスタ システムのレイアウトを決定したら、クライアントによる頻繁な使用をシミュレートするソフトウェア（Mercury Interactive の LoadRunner など）を使用して綿密なテストを実行する必要があります。負荷のかかった状況でシステムをテストすることにより、実際の環境でのクライアント負荷に対応するためにサーバまたはサーバ ハードウェアを追加する必要のある場所を特定できます。
マルチ CPU マシン上の WebLogic Server
BEA WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems, Inc. の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバは、大規模なクラスタまたは複数のクラスタのホストとなることができます。
ほとんどの場合、WebLogic Server クラスタは、1 つの WebLogic Server インスタンスを 2 つの CPU ごとにデプロイするのが最適です。ただし、すべてのキャパシティ プランニングと同じように、サーバ インスタンスの最適数および分散方法を決定する場合は、対象となる Web アプリケーションで実際のデプロイメントを事前にテストする必要があります。詳細については、「マルチ CPU マシンのパフォーマンスに関する考慮事項」を参照してください。
用語の定義
この節では、クラスタ化されたシステムの各部分の説明に以下の用語を使用します。
Web アプリケーションの「層」
Web アプリケーションは、複数の「層」に分けられます。「層」は、アプリケーションで提供される論理的なサービスを示します。すべての Web アプリケーションが同じような「層」に分けられるとは限りません。そのため、アプリケーションによっては、以下で説明する層の一部しか利用されない場合もあります。また、層はアプリケーションのサービスの論理的な区分を示すものであり、必ずしもハードウェアまたはソフトウェアのコンポーネント間の物理的な区分を示すものではありません。1 つの WebLogic Server インスタンスを実行している 1 台のマシンが、以下で説明するすべての層を提供する場合もあります。
Web 層
Web 層では、Web アプリケーションのクライアントに対して静的なコンテンツ（単純な HTML ページなど）が提供されます。Web 層は、通常、外部クライアントが Web アプリケーションにアクセス場合の最初のポイントになります。単純な Web アプリケーションでは、WebLogic Express、Apache、Netscape Enterprise Server、または Microsoft Internet Information Server を実行している 1 つまたは複数のマシンで構成される Web 層が存在する場合もあります。
プレゼンテーション層
プレゼンテーション層では、Web アプリケーションのクライアントに対して動的なコンテンツ（サーブレットや JavaServer Pages（JSP）など）が提供されます。Web アプリケーションのプレゼンテーション層は、サーブレットや JSP のホストになる WebLogic Server インスタンスのクラスタで構成されます。クラスタでアプリケーションの静的な HTML ページも提供される場合は、クラスタには Web 層とプレゼンテーション層の両方が含まれます。
オブジェクト層
オブジェクト層では、Web アプリケーションのクライアントに対して Java オブジェクト（エンタープライズ JavaBean や RMI クラスなど）や、それらに関連付けられたビジネス ロジックが提供されます。EJB のホストになる WebLogic Server クラスタは、オブジェクト層を提供します。
非武装地帯（DMZ）
非武装地帯（DMZ）とは、外部の、信頼性のないソースから使用できるハードウェアおよびサービスの論理的な集合のことです。ほとんどの Web アプリケーションでは、Web サーバのバンクは DMZ にあります。DMZ では、ブラウザ ベースのクライアントからの静的な HTML コンテンツへのアクセスが許可されています。
DMZ には、ハードウェアおよびソフトウェアに対する外部からの攻撃に備えてセキュリティが用意されている場合もあります。ただし、DMZ は信頼性のないソースから使用できるので、その安全性は内部システムよりは劣ります。たとえば、内部システムは、外部からのアクセスをすべて拒否するファイアウォールによって保護できます。DMZ は、アクセス先の個々のマシン、アプリケーション、またはポート番号を隠すファイアウォールによって保護できますが、信頼性のないクライアントからそれらのサービスにアクセスすることは可能です。
ロード バランサ
ロード バランサという用語は、このマニュアルでは、クライアントの接続リクエストを 1 つまたは複数の別々の IP アドレスに分散させる技術を指します。たとえば、単純な Web アプリケーションでは、DNS ラウンドロビン アルゴリズムがロード バランサとして使用される場合があります。大規模なアプリケーションでは、通常、Alteon WebSystems などから発売されているハードウェアベースのロード バランシング ソリューションが使用されます。このようなソリューションには、ファイアウォールのようなセキュリティ機能も用意されています。
ロード バランサには、クライアント接続をクラスタ内の特定のサーバに関連付ける機能があります。この機能は、クライアント セッション情報のインメモリ レプリケーションを使用する場合に必要です。一部のロード バランシング製品では、インメモリ レプリケーションで使用されるプライマリ サーバおよびセカンダリ サーバを追跡する WebLogic Server クッキーを上書きしないように、クッキーの永続性メカニズムをコンフィグレーションする必要があります。詳細については、 ロード バランシング ハードウェアをコンフィグレーションする（省略可能）を参照してください。
プロキシ プラグイン
プロキシ プラグインとは、WebLogic Server クラスタによって提供されるクラスタ化されたサーブレットにアクセスする Apache、Netscape Enterprise Server、または Microsoft Internet Information Server に対する WebLogic Server の拡張機能のことです。プロキシ プラグインには、WebLogic Server クラスタ内のサーブレットおよび JSP へのアクセスに対するロード バランシング ロジックが含まれます。また、クライアントのセッション状態のホストになっている主要な WebLogic Server に障害が発生した場合の、セッション状態のレプリカへのアクセスに対するロジックも含まれます。
推奨基本クラスタ アーキテクチャでは、すべての Web アプリケーション層を組み合わせ、関連するサービス（静的 HTTP、プレゼンテーション ロジック、およびオブジェクト）を WebLogic Server インスタンスの 1 つのクラスタに配置します。次の図に、このアーキテクチャを示します。
基本アーキテクチャには、以下のような利点があります。
注意: インメモリ セッション レプリケーションでサードパーティ製のロード バランサを使用する場合は、プライマリ セッション ステートのホストとなる WebLogic Server インスタンス（接続先サーバ）へのクライアント接続を、ロード バランサが維持するようにしなければなりません。詳細については、 ロード バランシング ハードウェアをコンフィグレーションする（省略可能）を参照してください。
アプリケーション層を分割したプランニング
基本クラスタ アーキテクチャでは、Web アプリケーションのすべての層（Web 層、プレゼンテーション層、およびオブジェクト層）を提供する WebLogic Server インスタンスの 1 つのクラスタが使用されます。この「組み合わせ層」クラスタでは、信頼性のない接続（HTTP および Java クライアント）の WebLogic Server クラスタへのインタフェースはロード バランシング ハードウェアを経由する 1 つだけです。基本アーキテクチャは簡略化されていますが、数多くの Web アプリケーションのニーズを満たしています。
しかし、クラスタ化された Web アプリケーションの 2 つの主要な機能（ロード バランシング機能とフェイルオーバ機能）は、Web アプリケーション層間のインタフェースにしか導入できません。基本クラスタ アーキテクチャのように、1 つのハードウェアとソフトウェアのプラットフォームに Web アプリケーション層が組み合わされている場合は、ロード バランシング機能およびフェイルオーバ機能をシステムに導入する機会が少なくなります。
ロード バランシングとフェイルオーバの大部分は、クライアントとクラスタ自身の間で発生するので、基本クラスタ アーキテクチャでも、ほとんどの Web アプリケーションのクラスタ化ニーズを満たすことができます。しかし、組み合わせ層クラスタには、クラスタ化された EJB へのメソッド呼び出しに対してロード バランシングを実行する機会がありません。クラスタ化されたオブジェクトは、クラスタ内のすべての WebLogic Server インスタンスにデプロイされるので、各オブジェクト インスタンスは各サーバでローカルに使用できます。WebLogic Server では、常にローカルのオブジェクト インスタンスを選択することにより、クラスタ化された EJB に対するメソッド呼び出しが最適化されます。リクエストをリモート オブジェクトに分散させないので、ネットワークのオーバーヘッドが増加しません。
この連結方式は、ほとんどの場合で、異なるサーバへの各メソッド リクエストに対してロード バランシングを行うよりも効率的です。ただし、各サーバの負荷が不均衡な場合は、ローカルでメソッドを処理するよりも、リモート オブジェクトにメソッド呼び出しを送信する方が結果的に効率的になる場合もあります。
クラスタ化された EJB へのメソッド呼び出しに対してロード バランシングを行うには、Web アプリケーションのプレゼンテーション層とオブジェクト層を物理的に異なるクラスタ上に分割する必要があります。これについては、以下の「 推奨多層アーキテクチャ」で説明します。
推奨多層アーキテクチャでは、2 つの異なる WebLogic Server クラスタを使用します。1 つは静的な HTTP コンテンツを提供するクラスタであり、もう 1 つはクラスタ化された EJB を提供するクラスタです。多層クラスタは、以下のような Web アプリケーションにお勧めします。
注意: 多層アーキテクチャを考慮する場合には、プレゼンテーション層からオブジェクト層の呼び出し頻度を考慮します。通常、プレゼンテーション オブジェクトがオブジェクト層を呼び出す場合には、組み合わせ層アーキテクチャの方が多層アーキテクチャに比べてパフォーマンスが良くなります。
次の図に、推奨多層アーキテクチャを示します。
ハードウェアとソフトウェアの物理レイヤ
高度な推奨コンフィグレーションには、ハードウェアとソフトウェアの物理レイヤが 2 つあります。物理レイヤはアプリケーション自身の論理層（Web 層、プレゼンテーション層、およびオブジェクト層）を構成します。
Web/プレゼンテーション レイヤ
Web/プレゼンテーション レイヤは、静的な HTTP ページ、サーブレット、および JSP の専用ホストになっている WebLogic Server インスタンスのクラスタで構成されます。このサーブレット クラスタは、クラスタ化されたオブジェクトのホストにはなりません。その代わりに、プレゼンテーション層クラスタ内のサーブレットは、オブジェクト レイヤにある異なる WebLogic Server クラスタ内のクラスタ化されたオブジェクトのクライアントとして機能します。
オブジェクト レイヤ
オブジェクト レイヤは、Web アプリケーションで必要なクラスタ化されたオブジェクト（EJB オブジェクトおよび RMI オブジェクト）専用のホストになる WebLogic Server インスタンスのクラスタで構成されます。専用クラスタにオブジェクト層のホストを配置することで、クラスタ化されたオブジェクトへのアクセスに対するデフォルトの連結の最適化（「 オブジェクトのクラスタ化について」参照）が失われます。ただし、特定のクラスタ化されたオブジェクトへの各メソッド呼び出しに対するロード バランシングは可能になります。
多層アーキテクチャの利点
多層アーキテクチャには、 推奨基本クラスタにある利点に加えて、以下のような利点があります。
クラスタ化されたオブジェクト呼び出しに対するロード バランシング
クラスタ化されたオブジェクトに対する WebLogic Server の連結の最適化は、クラスタ化されたオブジェクト（EJB または RMI クラス）のホストが、オブジェクトを呼び出すレプリカ対応スタブと同じサーバ インスタンスに配置されることに基づいています。
オブジェクト層を分離させることの最終的な効果は、クライアント（HTTP クライアント、Java クライアント、またはサーブレット）が、クラスタ化されたオブジェクトのホストになっている同じサーバ上のレプリカ対応スタブを取得しないことにあります。このため、WebLogic Server では、連結の最適化を使用できず、クラスタ化されたオブジェクトに対するサーブレット呼び出しでは、レプリカ対応スタブに含まれるロジックに従って自動的にロード バランシングが実行されます。次の図に、多層アーキテクチャ内のクラスタ化された EJB インスタンスにアクセスするクライアントを示します。
クライアント接続の経路をトレースすると、異なるハードウェアとソフトウェアにオブジェクト層を分離させる意味が理解できます。
サーブレットは、クラスタ化されたオブジェクトのホストになる、WebLogic Server クラスタにある EJB をルックアップします。サーブレットは、Bean のレプリカ対応スタブを取得します。スタブには、Bean のホストになるすべてのサーバのアドレスと、Bean のレプリカへのアクセスに対するロード バランシング ロジックが示されています。
注意: EJB のレプリカ対応スタブおよび EJB ホームのロード アルゴリズムは、EJB デプロイメント記述子の各要素を使用して指定します。詳細については、「weblogic-ejb-jar.xml デプロイメント記述子」を参照してください。
この例では、同じ WebLogic Server クラスタがサーブレットと EJB の両方のホストになっている場合（「 推奨基本クラスタ」参照）、WebLogic Server では EJB のリクエストに対するロード バランシングは実行されません。その代わり、サーブレットは常に、ローカル サーバがホストになっている EJB レプリカでメソッドを呼び出します。ローカルの EJB インスタンスを使用した方が、別のサーバにある EJB に対してリモート メソッド呼び出しを行うよりも効率的です。しかし、多層アーキテクチャでは、EJB メソッド呼び出しのロード バランシングを必要とするアプリケーションに対してリモート EJB アクセスが可能です。
多層アーキテクチャのコンフィグレーションに関する注意
多層アーキテクチャではクラスタ化されたオブジェクトへの呼び出しに対するロード バランシングが提供されるので、システムでは通常、組み合わせ層アーキテクチャよりも多い IP ソケットが利用されます。特に、ソケット使用のピーク時は、サーブレットおよび JPS のホストになるクラスタ内の各 WebLogic Server では以下のソケットが最大限に使用される可能性があります。
たとえば、「 推奨多層アーキテクチャ」で示された図では、サーブレット/JSP クラスタ内の各サーバは最大で 5 つのソケットをオープンする可能性があります。この最大数は、プライマリおよびセカンダリの各セッション ステートが均等にサーブレット クラスタ全体に分散していて、サーブレット クラスタ内の各サーバがオブジェクト クラスタ内の各サーバのリモート オブジェクトに同時にアクセスしたという、最悪のケースを表しています。ほとんどの場合、実際に使用されるソケット数は最大数より小さくなります。
多層アーキテクチャで pure-Java ソケット実装を使用する場合は、ソケットの最大使用に対応できるだけのソケット リーダー スレッドをコンフィグレーションしていることを確認してください。詳細については、「 Java ソケット実装用のリーダー スレッドのコンフィグレーション」を参照してください。
多層アーキテクチャではハードウェア ロード バランサを使用するため、インメモリ セッション ステート レプリケーションを使用する場合は、クライアントの接続先サーバに対するセッション維持型の接続を保持するように、ロード バランサをコンフィグレーションしなければなりません。詳細については、 ロード バランシング ハードウェアをコンフィグレーションする（省略可能）を参照してください。
多層アーキテクチャに関する制限
高度なコンフィグレーションでは、連結方式を使用してオブジェクト呼び出しを最適化できないので、Web アプリケーションでは、クラスタ化されたオブジェクトに対するすべてのメソッド呼び出しでネットワークのオーバーヘッドが発生します。ただし、このオーバーヘッドは、Web アプリケーションで「 多層アーキテクチャの利点」で説明した利点のいずれかが必要な場合には許容できる場合もあります。
たとえば、Web クライアントがサーブレットおよび JSP を頻繁に使用するものの、クラスタ化されたオブジェクトへのアクセスは比較的少ない場合、多層アーキテクチャではサーブレットおよびオブジェクトの負荷を適切に集中させることができます。各サーバの処理能力を最大限に利用しながら、10 個の WebLogic Server インスタンスを含むサーブレット クラスタと 3 個の WebLogic Server インスタンスを含むオブジェクト クラスタをコンフィグレーションできます。
ファイアウォールに関する制限
多層アーキテクチャのサーブレット クラスタとオブジェクト クラスタの間にファイアウォールを配置する場合は、オブジェクト クラスタ内のすべてのサーバを IP アドレスではなく、外部に公開されている DNS 名にバインドさせる必要があります。サーバを IP アドレスにバインドさせると、アドレス変換に関する問題が発生し、サーブレット クラスタが各サーバ インスタンスにアクセスできなくなる場合があります。
WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が同一でない場合、サーバ インスタンスの ExternalDNSName 属性を使用して、サーバの外部 DNS 名を定義します。ファイアウォールの外側では、ExternalDNSName がサーバの外部 IP アドレスに変換されます。Administration Console の [サーバ｜コンフィグレーション｜一般] タブを使用してこの属性を設定します。『Administration Console オンライン ヘルプ』の「[サーバ] --> [コンフィグレーション] --> [一般]」を参照してください。
推奨プロキシ アーキテクチャ
既存の Web サーバと連携して動作するよう、WebLogic Server クラスタをコンフィグレーションすることもできます。このアーキテクチャでは Web サーバのバンクは Web アプリケーションの静的な HTTP コンテンツを提供し、WebLogic プロキシ プラグインまたは HttpClusterServlet を使用してクラスタにサーブレット リクエストおよび JSP リクエストを送信します。
2 層プロキシ アーキテクチャ
2 層プロキシ アーキテクチャは、静的な HTTP サーバのホストが Web サーバのバンクに配置されるという点以外は 推奨基本クラスタとほぼ同じです。
ハードウェアとソフトウェアの物理レイヤ
2 層プロキシ アーキテクチャには、ハードウェアとソフトウェアの物理レイヤが 2 つあります。
Web レイヤ
プロキシ アーキテクチャでは、アプリケーションの Web 層を提供するタスクに特化したハードウェアとソフトウェアのレイヤが利用されます。この物理的な Web レイヤは、以下のアプリケーションの組み合わせのいずれか 1 つのホストになる、1 つまたは複数の同じようにコンフィグレーションされたマシンで構成されます。
HttpClusterServlet
選択する Web サーバ ソフトウェアに関係なく、Web サーバの物理層では静的な Web ページのみが提供されるようにする必要があります。動的なコンテンツ（サーブレットや JSP）は、プロキシ プラグインまたは HttpClusterServlet を経由して、プレゼンテーション層のサーブレットや JSP のホストになる WebLogic Server クラスタにプロキシされます。
サーブレット/オブジェクト レイヤ
推奨 2 層プロキシ アーキテクチャでは、プレゼンテーション層およびオブジェクト層のホストは WebLogic Server インスタンスのクラスタに配置されます。このクラスタは、マルチホームのマシンまたは複数の異なるマシンにデプロイできます。
サーブレット/オブジェクト レイヤは、組み合わせ層クラスタ（「 推奨基本クラスタ」参照）とは、アプリケーションのクライアントに静的な HTTP コンテンツを提供しないという点で異なります。
多層プロキシ アーキテクチャ
また、Web サーバのバンクを、プレゼンテーション層およびオブジェクト層のホストになる 1 対の WebLogic Server クラスタに対するフロント エンドとして使用することもできます。次の図に、このアーキテクチャを示します。
このアーキテクチャには、 推奨多層アーキテクチャと同じ利点（および同じ制限）があります。異なる点は、WebLogic プロキシ プラグインを利用する Web サーバの異なるバンクに Web 層が配置されることだけです。
プロキシ アーキテクチャにおけるトレードオフ
スタンドアロン Web サーバとプロキシ プラグインの使用には、以下のような利点があります。
スタンドアロン Web サーバとプロキシ プラグインの使用には、以下のような、Web アプリケーションに関する制限があります。
HttpClusterServlet を使用して、クラスタ化されたサーブレットにアクセスする場合は、ロード バランシング アルゴリズムが単純なラウンドロビン方式に制限されます。
プロキシ プラグインとロード バランサ
WebLogic Server クラスタでロード バランサを直接使用すると、サーブレット リクエストのプロキシに関する利点がもたらされます。まず、ロード バランサを持つ WebLogic Server を使用することにより、クライアントの設定における追加管理が不要になります。HTTP サーバのレイヤを別に設定し保持する必要もなく、1 つまたは複数のプロキシ プラグインをインストールおよびコンフィグレーションする必要もありません。また、Web プロキシ レイヤの削除により、クラスタへのアクセスに必要なネットワーク接続数も削減されます。
ロード バランシング ハードウェアを使用することで、システムの能力に適合したロード バランシング アルゴリズムをより柔軟に定義できるようになります。使用するロード バランシング ハードウェアでサポートされている、任意のロード バランシング方式（ロードベースのポリシーなど）を使用できます。プロキシ プラグインまたは HttpClusterServlet を使用する場合、クラスタ化されたサーブレットへのリクエストについては、単純なラウンドロビン アルゴリズムに制限されます。
ただし、インメモリ セッション ステート レプリケーションを使用している場合、サードパーティ製のロード バランサを使用するには、さらにコンフィグレーションを行う必要があります。この場合は、クライアントがプライマリ セッション ステート情報にアクセスできるようにするため、クライアントと接続先のサーバ間でセッション維持型の接続を保持するように、ロード バランサをコンフィグレーションしなければなりません。プロキシは自動的にセッション維持型の接続を保持するため、プロキシ プラグインを使用する場合は特別なコンフィグレーションは不要です。
管理サーバに関する考慮事項
クラスタに参加している WebLogic Server インスタンスを起動する場合、各サーバは、クラスタ自身のコンフィグレーション情報を格納している管理サーバに接続できなくてはなりません。セキュリティ上の理由から、管理サーバは WebLogic Server クラスタと同じ DMZ 内に配置する必要があります。
管理サーバは、クラスタに参加しているすべてのサーバ インスタンスのコンフィグレーション情報を保持します。管理サーバにある config.xml ファイルには、管理サーバのドメイン内のすべてのクラスタ化されたインスタンス（およびその他の管理されたインスタンス）のリポジトリが 1 つあります。WebLogic Server の以前のバージョンのように、クラスタ内のサーバごとに異なるコンフィグレーション ファイルを作成しないでください。
クラスタ化された WebLogic Server インスタンスが起動するためには、管理サーバが使用可能になっている必要があリます。ただし、いったんクラスタが起動したら、管理サーバに障害が発生しても実行中のクラスタの動作には影響しません。
管理サーバがサーバの管理（コンフィグレーション データの保持、サーバの起動とシャットダウン、およびアプリケーションのデプロイとアンデプロイ）プロセスだけを受け持つような構成を採ることをお勧めします。管理サーバにクライアントからのリクエストも処理させると、管理タスクの実行に遅れが生じるリスクが発生します。
管理サーバをクラスタ化することの利点はありません。管理オブジェクトはクラスタ化できず、管理サーバに障害が発生した場合に別のクラスタ メンバーへのフェイルオーバを行いません。管理サーバ上にアプリケーションをデプロイすると、サーバおよびサーバが提供する管理機能の安定性が損なわれるおそれがあります。管理サーバ上にデプロイしたアプリケーションが予期しない動作をすると、管理サーバの稼働の妨げとなることがあります。
管理サーバの IP アドレスがクラスタワイドの DNS 名に含まれていないことを確認します。
管理サーバの障害時に発生すること
あるドメインの管理サーバの障害は、そのドメイン内の管理対象サーバの処理には影響しません。ドメインの管理サーバが管理するサーバ インスタンスが（クラスタ化されていてもいなくても）起動されて実行中の間は、その管理サーバが使用不能になっても、その管理対象サーバは実行を続けます。そのドメインにクラスタ化されたサーバ インスタンスが含まれている場合、管理サーバが障害となった場合でも、そのドメインのコンフィグレーションでサポートするロード バランシングおよびフェイルオーバ機能はそのまま有効です。
注意: 管理サーバの障害の理由が、ホスト マシン上で発生したハードウェアまたはソフトウェアの障害ならば、同じマシン上のほかのサーバ インスタンスも同様の影響を受けるでしょう。しかし、1 つの管理サーバの生涯それ自体は、そのドメイン内の管理対象サーバの処理を中断することはありません。
管理サーバの再起動の方法については、『管理者ガイド』の「管理対象サーバの動作中における管理サーバの再起動 」 を参照してください。
クラスタ アーキテクチャのセキュリティ オプション
推奨コンフィグレーションにあるハードウェアとソフトウェアの物理レイヤの間の境界には、Web アプリケーションの非武装地帯（DMZ）を定義できるポイントがあります。ただし、すべての境界で物理的なファイアウォールがサポートされているわけではありません。特定の境界で典型的なファイアウォール ポリシーのサブセットがサポートされているだけです。
以降の節では、DMZ を定義して、さまざまなレベルのアプリケーション セキュリティを作成する方法について説明します。
プロキシ アーキテクチャの基本ファイアウォール
基本ファイアウォール コンフィグレーションでは、信頼性のないクライアントと Web サーバ レイヤの間に 1 つのファイアウォールを使用します。このファイアウォール コンフィグレーションは、組み合わせ層クラスタ アーキテクチャでも、多層クラスタ アーキテクチャでも使用できます。
上記のコンフィグレーションでは、1 つのファイアウォールで任意のポリシー（アプリケーションレベルの制限、NAT、IP マスカレード）の組み合わせを使用して、3 つの HTTP サーバへのアクセスをフィルタ処理しています。ファイアウォールの最も重要な役割は、システム内のその他のサーバへのアクセスを拒否することです。つまり、信頼性のないクライアントからは、サーブレット レイヤ、オブジェクト レイヤ、およびデータベースにはアクセスできないようにする必要があります。
物理的なファイアウォールは、DMZ 内の Web サーバの前にも後ろにも配置できます。Web サーバの前にファイアウォールを配置すると、Web サーバへのアクセスを許可し、その他のシステムへのアクセスを拒否するだけで済むので、ファイアウォール ポリシーを簡素化できます。
注意: 3 つの Web サーバと WebLogic Server クラスタの間にファイアウォールを配置する場合は、すべてのサーバ インスタンスを IP アドレスではなく、外部に公開されている DNS 名にバインドさせる必要があります。この作業を行うことで、プロキシ プラグインは自由にクラスタ内の各サーバに接続できるようになり、「 クラスタに関するファイアウォールの考慮事項」で説明したようなアドレス変換エラーが発生しなくなります。
WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が同一でない場合、サーバ インスタンスの ExternalDNSName 属性を使用して、サーバの外部 DNS 名を定義します。ファイアウォールの外側では、ExternalDNSName がサーバの外部 IP アドレスに変換されます。Administration Console の [サーバ｜コンフィグレーション｜一般] タブを使用してこの属性を設定します。『Administration Console オンライン ヘルプ』の「[サーバ] --> [コンフィグレーション] --> [一般]」を参照してください。
基本ファイアウォール コンフィグレーションの DMZ
Web サーバ レイヤへのアクセス以外のすべてのアクセスを拒否することによって、基本ファイアウォール コンフィグレーションでは、3 つの Web サーバのみが含まれる小規模な DMZ が作成されます。ただし、DMZ をどんなに慎重に定義しても、悪意のあるクライアントがプレゼンテーション層とオブジェクト層のホストになっているサーバにアクセスする可能性があることは考慮に入れておいてください。
たとえば、ハッカーが Web サーバのホストになっているマシンの 1 つにアクセスしたと仮定します。アクセスのレベルによっては、動的なコンテンツを求めて Web サーバがアクセスする、プロキシされたサーバに関する情報を、ハッカーが入手できる場合もあります。
DMZ をより慎重に定義する場合には、追加のファイアウォールを配置できます（「 共有データベースに対するセキュリティの追加」参照）。
ファイアウォールとロード バランサの組み合わせ
推奨クラスタ コンフィグレーションでロード バランシング ハードウェアを使用する場合は、基本ファイアウォールとの関連を考慮してハードウェアのデプロイ方法を決定する必要があります。数多くのハードウェア ソリューションでは、ロード バランシング サービスに加えてセキュリティ機能も提供されていますが、ほとんどのサイトでは Web アプリケーションの防御の最前線としてファイアウォールが使用されています。通常、ファイアウォールでは、Web トラフィックを制限するための、最もよくテストされた一般的なセキュリティ ソリューションが提供されます。ファイアウォールは、次の図に示すようにロード バランシング ハードウェアの前で使用する必要があります。
上記の設定では、Web 層を含む DMZ 内にロード バランサが配置されています。このコンフィグレーションでファイアウォールを使用すると、ファイアウォールはロード バランサへのアクセスを制限するだけで済むので、セキュリティ ポリシーの管理を簡素化できます。また、この設定では、以下で説明するような、Web アプリケーションにアクセスする内部クライアントをサポートするサイトの管理を簡素化することもできます。
内部クライアントに対するファイアウォールの拡張
Web アプリケーションへの直接アクセスを必要とする内部クライアント（独自の Java アプリケーションを実行するリモート マシンなど）をサポートする場合は、プレゼンテーション層への制限されたアクセスを許可できるよう、基本ファイアウォール コンフィグレーションを拡張できます。アプリケーションへのアクセスを拡張する方法は、リモート クライアントを信頼性のある接続として扱うか、または信頼性のない接続として扱うかによって変わります。
仮想プライベート ネットワーク（VPN）を使用して、リモート クライアントをサポートする場合は、クライアントを信頼性のある接続として扱うことができ、クライアントはファイアウォールの向こう側のプレゼンテーション層に直接接続できます。このコンフィグレーションは、次のようになります。
VPN を使用しない場合は、Web アプリケーションへのすべての接続を（独自のクライアント アプリケーションを使用するリモート サイトからの接続であっても）信頼性のない接続として扱う必要があります。この場合は、次の図のように、プレゼンテーション層のホストになっている WebLogic Server へのアプリケーションレベルの接続を許可するよう、ファイアウォール ポリシーを変更できます。
共有データベースに対するセキュリティの追加
Web アプリケーションの内部データと外部から入手できるデータの両方をサポートする 1 つのデータベースを使用する場合は、データベースにアクセスするオブジェクト レイヤの間に強固な境界を配置することを検討する必要があります。この場合、ファイアウォールを追加することによって、「 プロキシ アーキテクチャの基本ファイアウォール」で説明されている DMZ 境界を簡単に強化できます。
ファイアウォールが 2 つあるコンフィグレーションの DMZ
次のコンフィグレーションには、Web アプリケーションと内部（信頼性のある）クライアントによって共有されているデータベース サーバの前に追加のファイアウォールが配置されています。このコンフィグレーションでは、最初のファイアウォールが万一破られた場合や、ハッカーが最終的にオブジェクト層のホストになっているサーバにアクセスした場合のための追加のセキュリティが提供されています。プロダクション環境では、この環境はあり得ません。サイトでは、ハッカーがオブジェクト レイヤにあるマシンにアクセスするよりもずっと前に、悪意のある侵入を検出し、くい止める機能が必要になります。
上記のコンフィグレーションでは、オブジェクト層とデータベースの間の境界は追加のファイアウォールによって強固になっています。ファイアウォールは、オブジェクト層のホストになっている WebLogic Server からの JDBC 接続以外のすべての接続を拒否する厳密なアプリケーションレベルのポリシーを保持します。
クラスタに関するファイアウォールの考慮事項
1 つまたは複数のファイアウォールを利用するクラスタ アーキテクチャでは、すべての WebLogic Server インスタンスを IP アドレスではなく、外部に公開されている DNS 名を使用して識別することが重要です。DNS 名を使用することで、信頼性のないクライアントに対して内部 IP アドレスをマスクする場合に使用されるアドレス変換ポリシーに関連する問題を回避できます。
次の図に、WebLogic Server インスタンスの識別に IP アドレスを使用する場合に発生する可能性のある問題を示します。この図では、ファイアウォールは、サブネット「xxx」の外部 IP リクエストを、サブネット「yyy」の内部 IP アドレスに変換しています。
以下の手順では、接続プロセスと、考えられる障害ポイントについて説明します。
外部 IP アドレスと内部 IP アドレスの間の変換が行われなかった場合は、上記のようなクライアント リクエストがファイアウォールで問題なく処理されます。ただし、ほとんどのセキュリティ ポリシーでは内部 IP アドレスへのアクセスは拒否されます。
どの場合でもこの問題を回避するには、WebLogic Server インスタンスを DNS 名にバインドさせ、ファイアウォールの内側と外側で同じ DNS 名を使用します。WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が同一でない場合、サーバ インスタンスの ExternalDNSName 属性を使用して、サーバの外部 DNS 名を定義します。ファイアウォールの外側では、ExternalDNSName がサーバの外部 IP アドレスに変換されます。Administration Console の [サーバ｜コンフィグレーション｜一般] タブを使用してこの属性を設定します。『Administration Console オンライン ヘルプ』の「[サーバ] --> [コンフィグレーション] --> [一般]」を参照してください。
|
|
|