|
|
以下の節では、WebLogic Server クラスタでホストされるアプリケーションのスケーラビリティ、信頼性、およびパフォーマンスを最大にする設計およびデプロイメントのプラクティスを紹介します。
以下の節では、クラスタ化されたアプリケーションの一般的な設計上のガイドラインを説明します。
分散システムは本質的にどうしても複雑になります。さまざま理由から、設計ではシンプルさを第一の目標にしてください。「可動部品」を最小限に抑え、アルゴリズムが複数のオブジェクトに分散しないようにします。
リモート呼び出しを最小限に抑えると、パフォーマンスが向上し、障害の影響が少なくなります。
クライアントまたはサーブレット コードから EJB エンティティ Bean にアクセスしないようにします。その代わりに、セッション Bean (「Facade」と呼ばれる) を使用して複雑な対話を内包し、Web アプリケーションから RMI オブジェクトへの呼び出しを削減します。クライアント アプリケーションが直接エンティティ Bean にアクセスする場合、各ゲッター メソッドはリモート呼び出しです。セッション Facade Bean はエンティティ Bean にローカルでアクセスし、データを構造体に収集して、それを値で返すことができます。
EJB の実行には、システム リソースとネットワーク帯域幅が著しく消費されます。このため、EJB はアプリケーションのすべてのオブジェクトの適切な実装になるとは考えられません。
EJB を使用すると、情報と関連するビジネス ロジックの論理的なグループをモデル化できます。たとえば EJB を使用して、インボイスの項目の論理的な部分集合 (割引、払い戻し、税金などの調整が適用される項目群など) をモデル化できます。
一方、インボイスの個々の項目は細かいので、それを EJB として実装するのはネットワーク リソースの浪費になります。データ フィールドの集合のみを表すオブジェクト (get と set の機能のみを必要とする) は、転送オブジェクトとして実装します。
転送オブジェクト (値オブジェクトまたはヘルパー クラスとも呼ばれる) は、常に一緒にアクセスされる属性のグループを格納するエンティティをモデル化するのに適しています。転送オブジェクトは、関連する属性をグループ化して複合値を形成する EJB 内のシリアライズ可能クラスです。このクラスは、リモート ビジネス メソッドの戻り値の型として使用されます。
クライアントは、大まかなビジネス メソッドを呼び出してこのクラスのインスタンスを受信し、ローカルでその転送オブジェクト内の細かな値にアクセスします。サーバとの間を 1 往復するだけで複数の値を取得すると、ネットワーク トランザクションが削減され、レイテンシとサーバ リソースの使用量が最小限に抑えられます。
複数のサーバ インスタンスにまたがるトランザクションは避けます。分散トランザクションではリモート呼び出しが発行され、ネットワーク帯域幅が消費されて、リソース調整のオーバーヘッドが生じます。
以下の節では、クラスタ化されたサーブレットおよび JSP の設計上の考慮事項について説明します。
サーブレットまたは JSP の自動フェイルオーバを有効にするには、セッション ステートをメモリに保持する必要があります。HTTP セッション ステートのインメモリ レプリケーションをコンフィグレーションする手順については、「HTTP セッション ステートのレプリケーションに関する必要条件」および「インメモリ HTTP レプリケーションをコンフィグレーションする」を参照してください。
障害あるいは短気なユーザにより、サーブレット リクエストが重複する場合があります。サーブレットは、リクエストの重複に耐えられるように設計してください。
「クラスタ化されるサーブレットおよび JSP のプログラミング上の考慮事項」を参照してください。
以下の節では、クラスタ化された RMI オブジェクトの設計上の考慮事項について説明します。
サーバ インスタンスでいつ障害が発生したのかを、その障害が発生したときに行われていた処理との関連で判断するのは必ずしも可能ではありません。たとえば、クライアント リクエストの処理後、応答を返す前にサーバ インスタンスで障害が発生した場合は、そのリクエストが処理されたのかを確認する手段がありません。応答を受信していないユーザは再試行するので、余分なリクエストが発行されることになります。
RMI オブジェクトのフェイルオーバでは、メソッドが多重呼び出し不変でなければなりません。多重呼び出し不変のメソッドは、ネガティブな副作用なしに繰り返すことができます。
次の表は、EJB の使い方とコンフィグレーションのガイドラインをまとめたものです。コンフィグレーション可能なクラスタ動作のリストについては、表 11-2 を参照してください。
|
||||
|
||||
次の表は、クラスタでコンフィグレーションできる主要な動作とコンフィグレーションの方法をリストしています。
weblogic-ejb-jar.xml の home-call-router-class-name を使用すると、これらのタイプの Bean の Bean メソッド呼び出しをルーティングするために使用するカスタム クラスの名前を指定できる。このクラスは weblogic.rmi.cluster.CallRouter() を実装する必要がある。詳細については、「WebLogic クラスタの API」を参照。 |
|
weblogic-ejb-jar.xml の stateless-bean-call-router-class-name を使用すると、ステートレス セッション Bean のメソッド呼び出しのルーティングに使用するカスタム クラスの名前を指定できる。このクラスは weblogic.rmi.cluster.CallRouter を実装する必要がある。詳細については、「WebLogic クラスタの API」を参照。
|
|
WebLogic Server クラスタのさまざまなサービスによって、いろいろな種類と程度のステート管理が提供されます。次のリストでは、メモリまたは永続ストレージでのステートの保持方法によって区別される 4 つのカテゴリを定義します。
表 11-3 は、Java EE と WebLogic が各カテゴリのサービスをどのようにサポートしているかをまとめたものです。
| 注意 : | 表 11-3 で、ステートレス サービスと会話型サービスは、2 つのタイプのクライアントごとに説明されています。 |
クラスタ対応オブジェクトは、クラスタ内の個別の管理対象サーバではなくクラスタにデプロイします。情報と推奨事項については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。
各種のクラスタ アーキテクチャ、ロード バランシング オプション、およびセキュリティ オプションについては、「クラスタ アーキテクチャ」を参照してください。
以下の節では、クラスタのプランニングとコンフィグレーションで留意すべき考慮事項を示します。
クラスタのサーバ インスタンスの命名とアドレッシングのガイドラインについては、「名前とアドレスを識別する」を参照してください。
クラスタに参加している 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 が必須です。 |
次の図に、WebLogic Server インスタンスの識別に IP アドレスを使用する場合に発生する可能性のある問題を示します。この図では、ファイアウォールは、サブネット「xxx」の外部 IP リクエストを、サブネット「yyy」の内部 IP アドレスに変換しています。
以下の手順では、接続プロセスと、考えられる障害ポイントについて説明します。
外部 IP アドレスと内部 IP アドレスの間の変換が行われなかった場合は、上記のようなクライアント リクエストがファイアウォールで問題なく処理されます。ただし、ほとんどのセキュリティ ポリシーでは内部 IP アドレスへのアクセスは拒否されます。
クラスタのアーキテクチャは、システムのキャパシティに影響します。プロダクション環境で使用するためにアプリケーションをデプロイする前に、パフォーマンスを評価して、実際の運用におけるクライアント負荷を処理するためにサーバまたはサーバ ハードウェアを追加する必要があるかどうか、また必要であればどの場所に追加するべきかを判断してください。Mercury Interactive の LoadRunner のようなテスト ソフトウェアを使用すると、多数のクライアントによる利用時の負荷をシミュレートできます。
  
|
