WebLogic Server クラスタ ユーザーズ ガイド

クラスタ化のベスト プラクティス

以下の節では、WebLogic Server クラスタでホストされるアプリケーションのスケーラビリティ、信頼性、およびパフォーマンスを最大にする設計およびデプロイメントのプラクティスを紹介します。

• 一般的な設計上の考慮事項
• Web アプリケーション設計の考慮事項
• EJB 設計の考慮事項
• クラスタでのステート管理
• アプリケーション デプロイメントの考慮事項
• アーキテクチャに関する考慮事項
• 問題の回避

 

---

一般的な設計上の考慮事項

以下の節では、クラスタ化されたアプリケーションの一般的な設計上のガイドラインを説明します。

シンプルにする

分散システムは本質的にどうしても複雑になります。さまざま理由から、設計ではシンプルさを第一の目標にしてください。「可動部品」を最小限に抑え、アルゴリズムを複数のオブジェクトに分散しないようにします。

リモート呼び出しを最小限にする

リモート呼び出しを最小限に抑えると、パフォーマンスが向上し、障害の影響が少なくなります。

セッション Facade でリモート呼び出しが削減される

クライアントまたはサーブレット コードから EJB エンティティ Bean にアクセスしないようにします。その代わりに、セッション Bean (「Facade」と呼ばれる) を使用して複雑な対話を内包し、Web アプリケーションから RMI オブジェクトへの呼び出しを削減します。クライアント アプリケーションが直接エンティティ Bean にアクセスする場合、各ゲッター メソッドはリモート呼び出しです。セッション Facade Bean はエンティティ Bean にローカルでアクセスし、データを構造体に収集して、それを値で返すことができます。

転送オブジェクトでリモート呼び出しが削減される

EJB の実行には、システム リソースとネットワーク帯域幅が著しく消費されます。このため、EJB はアプリケーションのすべてのオブジェクトの適切な実装になるとは考えられません。

EJB を使用すると、情報と関連するビジネス ロジックの論理的なグループをモデル化できます。たとえば EJB を使用して、インボイスの項目の論理的な部分集合 (割引、払い戻し、税金などの調整が適用される項目群など) をモデル化できます。

一方、インボイスの個々の項目は細かいので、それを EJB として実装するのはネットワーク リソースの浪費になります。データ フィールドの集合のみを表すオブジェクト (get と set の機能のみを必要とする) は、転送オブジェクトとして実装します。

転送オブジェクト (値オブジェクトまたはヘルパー クラスとも呼ばれる) は、常に一緒にアクセスされる属性のグループを格納するエンティティをモデル化するのに適しています。転送オブジェクトは、関連する属性をグループ化して複合値を形成する EJB 内のシリアライズ可能クラスです。このクラスは、リモート ビジネス メソッドの戻り値の型として使用されます。

クライアントは、大まかなビジネス メソッドを呼び出してこのクラスのインスタンスを受信し、ローカルでその転送オブジェクト内の細かな値にアクセスします。サーバとの間を 1 往復するだけで複数の値を取得すると、ネットワーク トランザクションが削減され、レイテンシとサーバ リソースの使用量が最小限に抑えられます。

分散トランザクションでリモート呼び出しが増加する

複数のサーバ インスタンスにまたがるトランザクションは避けます。分散トランザクションではリモート呼び出しが発行され、ネットワーク帯域幅が消費されて、リソース調整のオーバーヘッドが生じます。

 

---

Web アプリケーション設計の考慮事項

以下の節では、クラスタ化されたサーブレットおよび JSP の設計上の考慮事項について説明します。

インメモリ レプリケーションのコンフィグレーション

サーブレットまたは JSP の自動フェイルオーバを有効にするには、セッション ステートをメモリに保持する必要があります。HTTP セッション ステートのインメモリ レプリケーションをコンフィグレーションする手順については、「HTTP セッション ステートのレプリケーションに関する必要条件」および「インメモリ HTTP レプリケーションをコンフィグレーションする」を参照してください。

多重呼び出し不変性に留意した設計

障害あるいは短気なユーザにより、サーブレット リクエストが重複する場合があります。サーブレットは、リクエストの重複に耐えられるように設計してください。

プログラミングの考慮事項

「クラスタ化されるサーブレットおよび JSP のプログラミング上の考慮事項」を参照してください。

 

---

EJB 設計の考慮事項

以下の節では、クラスタ化された RMI オブジェクトの設計上の考慮事項について説明します。

多重呼び出し不変のメソッドを設計する

サーバ インスタンスでいつ障害が発生したのかを、その障害が発生したときに行われていた処理との関連で判断するのは必ずしも可能ではありません。たとえば、クライアント リクエストの処理後、応答を返す前にサーバ インスタンスで障害が発生した場合は、そのリクエストが処理されたのかを確認する手段がありません。応答を受信していないユーザは再試行するので、余分なリクエストが発行されることになります。

RMI オブジェクトのフェイルオーバでは、メソッドが多重呼び出し不変でなければなりません。多重呼び出し不変のメソッドは、ネガティブな副作用なしに繰り返すことができます。

使い方およびコンフィグレーションのガイドラインに従う

次の表は、EJB の使い方とコンフィグレーションのガイドラインをまとめたものです。コンフィグレーション可能なクラスタ動作のリストについては、表 8-2  を参照してください。

表 8-1 EJB のタイプとガイドライン

オブジェクトの種類	適用	コンフィグレーション
全タイプの EJB	EJB を使用すると、情報と関連するビジネス ロジックの論理的なグループをモデル化できる。「転送オブジェクトでリモート呼び出しが削減される」を参照。	クラスタ対応ホームをコンフィグレーションする。
ステートフル セッション Bean	規模が大きくて書き込みの多いトランザクションに推奨。 EJB コンテナのオーバーヘッドを最小限に抑えるために、ステートフル セッション Bean は終了時点で削除する。ステートフル セッション Bean のインスタンスは特定のクライアントと関連付けられ、クライアントによって明示的に削除されるか、タイムアウトでコンテナによって削除されるまでコンテナに留まる。その間、コンテナはアクティブでないインスタンスをディスクにパッシベーションすることもある。その処理はオーバーヘッドを消費し、パフォーマンスに影響する。 注意 : 滅多にないが、ステートフル セッション Bean の現在のステートが失われることもある。たとえば、Bean の関与しているトランザクションがクライアントによってコミットされ、ステートの変更がレプリケートされる前にプライマリ サーバで障害が起きると、クライアントは以前に格納されていた Bean のステートにフェイルオーバされる。どのような障害が起きても Bean のステートを維持する必要がある場合は、ステートフル セッション EJB ではなくエンティティ EJB を使用する。	クラスタ対応ホームをコンフィグレーションする。 EJB のインメモリ レプリケーションをコンフィグレーションする。
ステートレス セッション Bean	クライアント単位でインスタンス化され、急激に増加してリソースを消費する可能性のあるステートフル セッション Bean よりスケーラビリティが高い。 ホームでステートレス Bean が作成されると、Bean がデプロイされたどのサーバにでも呼び出しを転送できるレプリカ対応スタブが返される。ステートレス Bean ではステートが保持されないので、スタブでは Bean のホストであるどのサーバにでも呼び出しを転送できる。	クラスタ対応ホームをコンフィグレーションする。 クラスタ アドレスをコンフィグレーションする。 メソッド呼び出し時のフェイルオーバをサポートするように、メソッドは多重呼び出し不変であるようにコンフィグレーションする。フェイルオーバは、メソッド呼び出しの間に障害が発生した場合、またはメソッドがサーバに接続できなかった場合のデフォルトの動作。 ステートレス セッション Bean ホームのメソッドは、自動的に多重呼び出し不変に設定される。これらについては多重呼び出し不変を明示的に設定する必要はない。
読み込み専用エンティティ Bean	古いデータでも問題ない場合に推奨。製品カタログや多くのアプリケーションの内容の大部分に適している。読み込みは、タイマーに基づいて無効化されるローカル キャッシュに対して実行される。読み込み専用エンティティのパフォーマンスは、トランザクション対応エンティティよりも 3 ～ 4 倍速い。 注意 : クライアントは読み込み専用エンティティ Bean でセッター メソッドを正常に呼び出すことができるが、データが永続ストアに移動することはあり得ない。	クラスタ対応ホームをコンフィグレーションする。 クラスタ アドレスをコンフィグレーションする。 メソッドはデフォルトで多重呼び出し不変になるようコンフィグレーションされる。
読み書き対応エンティティ Bean	リクエストや更新が頻繁に行われることのない共有永続データに最適。アクセスや更新の負荷が高い場合は、セッション Bean および JDBC を検討する。 顧客口座の保守など、高度なデータ一貫性が要求されるアプリケーションに推奨。読み書きはすべてデータベースで実行される。 isModified メソッドを使用すると、書き込みが少なくなる。 read-mostly アプリケーション (頻繁に読み込みが行われ、更新はまれであるカタログなど) では、読み込み専用 Bean と、読み込み専用 Bean を拡張する読み書き対応 Bean の組み合わせが適している。読み込み専用 Bean では高速で一貫性の乏しい読み込みが行われ、読み書き対応 Bean では一貫性の優れた書き込みが行われる。	クラスタ対応ホームをコンフィグレーションする。 メソッド呼び出し時のフェイルオーバをサポートするように、メソッドは多重呼び出し不変であるようにコンフィグレーションする。フェイルオーバは、メソッド呼び出しの間に障害が発生した場合、またはメソッドがサーバに接続できなかった場合のデフォルトの動作。 読み込み専用エンティティ Bean のメソッドは、自動的に多重呼び出し不変に設定される。

S

クラスタ関連のコンフィグレーション オプション

次の表は、クラスタでコンフィグレーションできる主要な動作とコンフィグレーションの方法をリストしています。

表 8-2 クラスタ関連のコンフィグレーション オプション

コンフィグレーション可能な動作またはリソース	コンフィグレーション方法
クラスタ対応ホーム	weblogic-ejb-jar.xml で home-is-clusterable を true に設定する。
多重呼び出し不変	Bean レベルでは、weblogic-ejb-jar.xml で stateless-bean-methods-are-idempotent を true に設定する。 メソッド レベルでは、weblogic-ejb-jar.xml で idempotent-methods を設定する。
EJB のインメモリ レプリケーション	weblogic-ejb-jar.xml で replication-type を InMemory に設定する。
クラスタ アドレス	クラスタ アドレスは、クラスタ内の管理対象サーバを識別する。クラスタ アドレスは、URL のホスト名部分を構築するためにエンティティ Bean およびステートレス Bean で使用される。クラスタ アドレスが設定されていない場合、EJB ハンドルは正しく動作しない。クラスタの含まれるドメインの config.xml ファイルの ClusterAddress 属性で定義する。開発環境およびプロダクション環境のクラスタ アドレス形式のガイドラインについては、「クラスタ アドレス」を参照。
clients-on-same- server	EJB にアクセスするクライアントのすべてが、その Bean がデプロイされているのと同じサーバ上からアクセスする場合には、weblogic-ejb-jar.xml で clients-on-same-server を True に設定する。 clients-on-same-server が True の場合、サーバ インスタンスはデプロイメント時に EJB の JNDI 通知をマルチキャストせず、したがって大きなクラスタの起動時間が短縮される。
エンティティ Bean およびエンティティ EJB のホームのロード バランシング アルゴリズム	weblogic-ejb-jar.xml の home-load-algorithm では、EJB ホームのレプリカ間でのロード バランシングに使用するアルゴリズムを指定する。この要素が定義されていない場合は、config.xml の weblogic.cluster.defaultLoadAlgorithm 属性で指定されたアルゴリズムが使用される。
エンティティ EJB、ステートフル セッション EJB、およびステートレス セッションのカスタム ロード バランシング	weblogic-ejb-jar.xml の home-call-router-class-name を使用すると、これらのタイプの Bean の Bean メソッド呼び出しをルーティングするために使用するカスタム クラスの名前を指定できる。このクラスは weblogic.rmi.cluster.CallRouter() を実装する必要がある。 詳細については、「WebLogic クラスタの API」を参照。
ステートレス セッション Bean のカスタム ロード バランシング	weblogic-ejb-jar.xml の stateless-bean-call-router-class-name を使用すると、ステートレス セッション Bean のメソッド呼び出しのルーティングに使用するカスタム クラスの名前を指定できる。このクラスは weblogic.rmi.cluster.CallRouter() を実装する必要がある。詳細については、「WebLogic クラスタの API」を参照。
ステートレス セッション Bean のクラスタ対応のコンフィグレーション	weblogic-ejb-jar.xml で stateless-bean-is-clusterable を true に設定すると、EJB をクラスタにデプロイできる。
ステートレス セッション Bean のロード バランシング アルゴリズム	weblogic-ejb-jar.xml の stateless-bean-load-algorithm を使用すると、EJB ホームのレプリカ間でのロード バランシングに使用するアルゴリズムを指定できる。このプロパティが定義されていない場合は、config.xml の weblogic.cluster.defaultLoadAlgorithm 属性で指定されたアルゴリズムが使用される。
マシン	WebLogic Server マシン リソースは、サーバ インスタンスとそのインスタンスが動作するコンピュータを関連付ける。詳細については、「マシン名をコンフィグレーションする」を参照。
レプリケーション グループ	レプリケーション グループを使用すると、HTTP セッション ステートがどこにレプリケートされるかを制御できる。詳細については、「レプリケーション グループをコンフィグレーションする」を参照。

 

---

クラスタでのステート管理

WebLogic Server クラスタのさまざまなサービスによって、いろいろな種類と程度のステート管理が提供されます。次のリストでは、メモリまたは永続ストレージでのステートの保持方法によって区別される 4 つのカテゴリを定義します。

• ステートレス サービス - ステートレス サービスは、呼び出し間でメモリをステートに保持しません。
• 対話サービス - 対話サービスは、あるセッションの期間中に特定のクライアント専用になります。セッションの期間中、そのクライアントからのリクエストのみをすべて処理します。一般に、セッションの間は、アプリケーション サーバがリクエスト間で保持する必要のあるステート情報が存在します。通常、対話サービスはメモリに一時的なステートを保持します。このステートは障害が発生すると失われる可能性があります。セッション ステートが呼び出しの間に共有の永続ストレージに書き込まれる場合、サービスはステートレスになります。ステートの永続ストレージが必要ない場合は、パフォーマンスとスケーラビリティを向上するために次のような選択肢があります。
• セッション ステートを背後でクライアント/サーバ間で往復させることができます。結果として再びステートレス サービスになります。この方法は、特に大量のデータがある場合には、必ずしも実現可能で望ましいとは限りません。
• より一般的には、リクエスト間でセッション ステートをアプリケーション サーバ上のメモリに保持することができます。メモリを解放する必要がある場合は、セッション ステートをメモリからページ アウトできます。個々の更新はディスクに書き込まれず、サーバに障害が発生した場合はデータが失われるため、この場合もパフォーマンスとスケーラビリティは向上します。
• キャッシュ サービス - キャッシュ サービスはメモリにステートを保持し、そのステートを使用して複数のクライアントからのリクエストを処理します。キャッシュ サービスの実装は、キャッシュされるデータのコピー同士の一貫性や、バッキング ストア内の関連データとの一貫性をどの程度維持するかによって異なります。
• シングルトン サービス - シングルトン サービスは、実行時にクラスタ内の 1 つのサーバ上でのみアクティブになり、複数のクライアントからのリクエストを処理します。通常、シングルトン サービスは、メモリにキャッシュしたプライベートな永続データによってバックアップされます。メモリに一時的なステートを保持することもできます。このステートは障害が発生した場合は再生成されるか、または失われます。障害が発生した場合、シングルトン サービスは同じサーバ上で再起動するか、新しいサーバに移行する必要があります。

表 8-3 は、J2EE と WebLogic が各カテゴリのサービスをどのようにサポートしているかをまとめたものです。

注意 : In 表 8-3 で、ステートレス サービスと対話サービスは、2 つのタイプのクライアントごとに説明されています。

• 疎結合クライアント。標準のプロトコルを使用してアプリケーション サーバと通信するブラウザまたは Web サービス クライアントです。
• 密結合クライアント。アプリケーション層またはクライアントサイド環境で動作し、独自のプロトコルを使用してアプリケーション サーバと通信するオブジェクトです。

表 8-3 サービス タイプごとの J2EE と WebLogic のサポート

サービス	J2EE のサポート	WebLogic Server のスケーラビリティと信頼性の機能
ステートレス サービス (疎結合クライアント)	すべての J2EE API はステートレス。または、呼び出し間でステート情報を共有永続ストレージに書き込むことで、ステートレスとして実装できる。 J2EE はロード バランシングとフェイルオーバに対する標準を指定していない。疎結合クライアントの場合、ロード バランシングは外部の IP ベースのメカニズムによって実行する必要がある。	WebLogic Server は、サービスの複数のインスタンスをクラスタにデプロイすることで、ステートレス サービスの可用性を向上させる。 ステートレス サービスの疎結合クライアントの場合、WebLogic Server は外部ロード バランシング ソリューションをサポートし、セッション フェイルオーバとロード バランシング用のプロキシ プラグインを提供する。 詳細については、以下を参照。 「ステートレス セッション Bean」 「外部ロード バランサによる HTTP セッションのロード バランシング」 「プロキシ プラグインによるロード バランシング」
ステートレス サービス (密結合クライアント)	次の J2EE API は、ステートレス サービスへの密結合アクセスをサポートする。 JNDI (初期アクセスの後) ファクトリ (EJB ホーム、JDBC 接続プール、および JMS 接続ファクトリなど) ステートレス セッション Bean エンティティ Bean (呼び出し間で共有永続ストレージに書き込まれる場合)	WebLogic Server は、サービスの複数のインスタンスをクラスタにデプロイすることで、ステートレス サービスの可用性を向上させる。 ステートレス サービスの密結合クライアントの場合、WebLogic Server は RMI 実装でロード バランシングとフェイルオーバをサポートする。 クラスタ化された RMI オブジェクトに対する WebLogic Server のレプリカ対応スタブは、現在オブジェクトに対してサービスとコンフィグレーション済みロード バランシング アルゴリズムを提供している、クラスタ内のサーバ インスタンスのリストを示す。WebLogic Server クラスタはスタブを使用して、ロード バランシングとフェイルオーバに関する決定を行う。 詳細については、以下を参照。 「ステートレス セッション Bean」 「EJB と RMI オブジェクトのロード バランシング」
対話サービス (疎結合クライアント)	次の J2EE API は、対話サービスへの疎結合アクセスをサポートする。 サーブレット Web サービス J2EE はロード バランシングとフェイルオーバに対する標準を指定していない。 ロード バランシングは、外部の IP ベースのメカニズム、またはプレゼンテーション層のアプリケーション サーバのコードによって実現できる。対話サービスのプロトコルはステートレスであるため、ロード バランシングはセッションの作成時にのみ発生する。以降のリクエストは選択したサーバに固定される。	WebLogic Server は次のようにセッションの信頼性を向上させる。 セッション ステートのインメモリ レプリケーションと、クラスタ全体でのプライマリとセカンダリの分散に基づくフェイルオーバ。 コンフィグレーション可能なレプリケーション グループと、セカンダリをホストするための優先レプリケーション グループの指定機能。 外部ロード バランサまたはプロキシ プラグインを使用したロード バランシング。 詳細については、以下を参照。 「HTTP セッション ステートのレプリケーション」 「サーブレットと JSP のロード バランシング」
対話サービス (密結合クライアント)	J2EE 標準は EJB ステートフル セッション Bean を提供して、密結合クライアントでの対話サービスをサポートする。	WebLogic Server は次の機能でステートフル セッション Bean の可用性と信頼性を向上させる。 キャッシング。 パッシベーションされた Bean のステートの永続ストレージ。 Bean を作成するために EJB ホームが選択されるときに、最初のロード バランシングが発生する。レプリカ対応スタブは選択されたサーバに固定され、セッション アフィニティを提供する。 プライマリ/セカンダリ レプリケーションが有効な場合、スタブはセカンダリを追跡してフェイルオーバを実行する。 更新は、トランザクションの境界上でのみ、プライマリからセカンダリに送信される。 詳細については、「ステートフル セッション Bean」を参照。
キャッシュ サービス	J2EE はキャッシュ サービスに対する標準を指定していない。 Bean 管理による永続性を持つエンティティ Bean はカスタム キャッシュを実装できる。	Weblogic Server は次のキャッシングをサポートする。 ステートフル セッション Bean ステートフル セッション Bean のスケーラビリティと信頼性を向上させる WebLogic 機能のリストについては、上記の行の説明を参照。 エンティティ Bean WebLogic Server はエンティティ Bean に対する次のキャッシング機能をサポートする。 短期間の、またはトランザクション間のキャッシング リレーションシップ キャッシング 組み合わせキャッシング。同じ J2EE アプリケーションに属する複数のエンティティ Bean が 1 つの実行時キャッシュを共有できる。 キャッシュと外部データ ストアの一貫性は、次の方法で向上させることができる。 キャッシュのフラッシュ 外部データ ストアの更新後のキャッシュの更新 キャッシュの無効化 同時実行性制御 「read-mostly パターン」 WebLogic Server は読み込み専用 EJB と読み書き対応 EJB を組み合わせて「read-mostly パターン」をサポートする。 JSP WebLogic Server はカスタム JSP タグを提供して、フラグメント レベルまたはページ レベルのキャッシングをサポートする。
シングルトン サービス	シングルトン サービスの実装に使用される J2EE API は次のとおり。 JMS 送り先 JTA トランザクション マネージャ ペシミスティックな同時実行性制御を持つ、キャッシュされたエンティティ Bean サービスを複数のインスタンスに「分割」することでスケーラビリティを向上させることができる。各インスタンスはバッキング データの別々の断片とそれに関連付けられたリクエストを処理する。	シングルトン サービスの可用性を向上させるための WLS 機能は次のとおり。 個々のサーバを障害に対して強くするための、サーバの複数スレッド プールのサポート 障害が発生したサーバや不調なサーバの検出と再起動をサポートするための状態モニタ API とライフサイクル API サービスを中断することなくソフトウェアをアップグレードする機能 JMS サーバと JTA トランザクション回復サービスを移行する機能

 

---

アプリケーション デプロイメントの考慮事項

クラスタ対応オブジェクトは、クラスタ内の個別の管理対象サーバではなくクラスタにデプロイします。 情報と推奨事項については、以下を参照してください。

• 2 フェーズ デプロイメントの概要
• クラスタへのデプロイメントのガイドライン

 

---

アーキテクチャに関する考慮事項

各種のクラスタ アーキテクチャ、ロード バランシング オプション、およびセキュリティ オプションについては、「クラスタ アーキテクチャ」を参照してください。

 

---

問題の回避

以降の節では、クラスタのプランニングとコンフィグレーションで留意すべき考慮事項を示します。

命名の考慮事項

クラスタのサーバ インスタンスの命名とアドレッシングのガイドラインについては、「名前とアドレスを識別する」を参照してください。

管理サーバについての考慮事項

クラスタに参加している WebLogic Server インスタンスを起動する場合、各管理対象サーバは、そのクラスタを含むドメインのコンフィグレーション情報を管理している管理サーバに接続できなくてはなりません。セキュリティ上の理由から、管理サーバは WebLogic Server クラスタと同じ DMZ 内に配置する必要があります。

管理サーバは、クラスタに参加しているすべてのサーバ インスタンスのコンフィグレーション情報を保持します。管理サーバ上にある config.xml ファイルには、クラスタ化されているかどうかに関係なく、管理サーバのドメイン内の全サーバのコンフィグレーション データが格納されます。クラスタ内のサーバごとに個別のコンフィグレーション ファイルは作成しません。

クラスタ化された WebLogic Server インスタンスが起動するためには、管理サーバが使用可能になっている必要があリます。ただし、いったんクラスタが起動したら、管理サーバに障害が発生しても実行中のクラスタの動作には影響しません。

管理サーバをクラスタに参加させないでください。管理サーバがサーバの管理 (コンフィグレーション データの保持、サーバの起動と停止、およびアプリケーションのデプロイメントとアンデプロイメント) プロセスだけを受け持つような構成を採ることをお勧めします。管理サーバにクライアントからのリクエストも処理させると、管理タスクの実行に遅れが生じるリスクが発生します。

管理サーバをクラスタ化する利点はありません。管理オブジェクトをクラスタ化することはできません。また、管理サーバで障害が発生した場合に、他のクラスタ メンバーにフェイルオーバもされません。管理サーバにアプリケーションをデプロイすると、サーバおよびサーバが提供している管理機能の安定性が損なわれる可能性があります。管理サーバにデプロイしたアプリケーションが予期しない動作を見せた場合、管理サーバの動作に影響するおそれもあります。

以上の理由から、管理サーバの IP アドレスがクラスタワイドの DNS 名に含まれていないことを確認してください。

ファイアウォールについての考慮事項

コンフィグレーションにファイアウォールが含まれている場合は、プロキシ サーバまたはロード バランサを DMZ に配置し、クラスタ (Web コンテナと EJB コンテナの両方とも) をファイアウォールの背後に配置します。Web コンテナを DMZ に配置することはお勧めしません。「プロキシ アーキテクチャの基本ファイアウォール」を参照してください。

多層アーキテクチャのサーブレット クラスタとオブジェクト クラスタの間にファイアウォールを配置する場合は、オブジェクト クラスタ内のすべてのサーバを IP アドレスではなく、外部に公開されている DNS 名にバインドさせます。サーバを IP アドレスにバインドさせると、アドレス変換に関する問題が発生し、サーブレット クラスタが各サーバ インスタンスにアクセスできなくなる場合があります。

WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が同じでない場合、サーバ インスタンスの ExternalDNSName 属性を使用して、サーバの外部 DNS 名を定義します。ファイアウォールの外で、ExternalDNSName はサーバの外部 IP アドレスに変換されます。Administration Console の [サーバ｜コンフィグレーション｜全般] タブで、この属性を設定します。Administration Console オンライン ヘルプの「[サーバ] --> [コンフィグレーション] --> [全般]」を参照してください。

1 つまたは複数のファイアウォールを利用するクラスタ アーキテクチャでは、すべての WebLogic Server インスタンスを IP アドレスではなく、外部に公開されている DNS 名を使用して識別することが重要です。DNS 名を使用することで、信頼性のないクライアントに対して内部 IP アドレスをマスクする場合に使用されるアドレス変換ポリシーに関連する問題を回避できます。

注意 : クライアントが t3 およびデフォルト チャネルを使用して WebLogic Server にアクセスする場合を除き、ファイアウォールがネットワーク アドレス変換を実行するコンフィグレーションでは、ExternalDNSName を使用する必要があります。たとえば、ファイアウォールがネットワーク アドレス変換を実行し、クライアントがプロキシ プラグインを介して HTTP で WebLogic Server にアクセスするコンフィグレーションでは、ExternalDNSName が必須です。

ExternalDNSName に対して IP アドレスを指定しないでください。ExternalDNSName は実際のドメイン名でなければなりません。

次の図に、WebLogic Server インスタンスの識別に IP アドレスを使用する場合に発生する可能性のある問題を示します。この図では、ファイアウォールは、サブネット「xxx」の外部 IP リクエストを、サブネット「yyy」の内部 IP アドレスに変換しています。

図 8-1 サーバが IP アドレスによって識別されるときに変換エラーが発生する可能性がある

 

以下の手順では、接続プロセスと、考えられる障害ポイントについて説明します。

クライアントは、205.20.xxx.100:7001 にある最初のサーバへの接続を要求して WebLogic Server クラスタへのアクセスを開始します。ファイアウォールは、このアドレスを 205.20.yyy.100:7001 という IP アドレスに変換し、クライアントをそのアドレスに接続します。
クライアントは、クラスタ内の 3 番目の WebLogic Server インスタンスにある、固定されているオブジェクト C の JNDI ルックアップを実行します。オブジェクト C のスタブには、そのオブジェクトのホストになっているサーバの内部 IP アドレス 205.20.yyy.300:7001 が含まれています。
オブジェクト C をインスタンス化しようとする場合、クライアントは IP アドレス 205.20.yyy.300:7001 を使用してオブジェクト C のホストになっているサーバへの接続を要求します。ファイアウォールはこの接続を拒否します。クライアントが、外部に公開されているサーバのアドレスではなく、制限されている内部 IP アドレスを使用して要求したことが原因です。

外部 IP アドレスと内部 IP アドレスの間の変換が行われなかった場合は、上記のようなクライアント リクエストがファイアウォールで問題なく処理されます。ただし、ほとんどのセキュリティ ポリシーでは内部 IP アドレスへのアクセスは拒否されます。

プロダクション環境で使用する前にクラスタのキャパシティを評価する

クラスタのアーキテクチャは、システムのキャパシティに影響します。プロダクション環境で使用するためにアプリケーションをデプロイする前に、パフォーマンスを評価して、実際の運用におけるクライアント負荷を処理するためにサーバまたはサーバ ハードウェアを追加する必要があるかどうか、また必要であればどの場所に追加するべきかを判断してください。Mercury Interactive の LoadRunner のようなテスト ソフトウェアを使用すると、多数のクライアントによる利用時の負荷をシミュレートできます。