|
|
|
|
|
|
| | | |
オブジェクトのクラスタ化について
以下の節では、オブジェクトのクラスタ化について説明します。
概要
オブジェクトをクラスタ化すると、そのオブジェクトのインスタンスがクラスタ内のすべての WebLogic Server にデプロイされます。クライアントでは、オブジェクトのどのインスタンスを呼び出すのかを選択できます。オブジェクトの各インスタンスはレプリカと呼ばれます。
WebLogic Server では、レプリカ対応スタブという技術を土台としてオブジェクトのクラスタ化を実現します。クラスタ化をサポート（デプロイメント記述子で定義）する EJB をコンパイルすると、ejbc によって EJB のインタフェースが rmic コンパイラに渡されてその Bean のレプリカ対応スタブが生成されます。RMI オブジェクトの場合は、rmic のコマンドライン オプションを使用して明示的にレプリカ対応スタブを生成します。詳細については、「WebLogic RMI コンパイラ」を参照してください。
レプリカ対応スタブ
レプリカ対応スタブは、呼び出し側では通常の RMI スタブとして認識されます。しかしながら、スタブは 1 つのオブジェクトではなく複数のレプリカを表します。レプリカ対応スタブは、オブジェクトがデプロイされるすべての WebLogic Server インスタンスで EJB クラスまたは RMI クラスを見つけるためのロジックを備えています。クラスタ対応の EJB オブジェクトまたは RMI オブジェクトをデプロイすると、その実装は JNDI ツリーにバインドされます。「 クラスタワイドの JNDI ネーミング サービス」で説明されているように、クラスタ化された WebLogic Server インスタンスではそのオブジェクトを利用できるすべてのサーバをリストするために JNDI ツリーを更新することができます。クライアントがクラスタ化されたオブジェクトにアクセスすると、その実装はクライアントに送信されるレプリカ対応スタブで置き換えられます。
スタブは、オブジェクトに対するメソッド呼び出しを負荷分散するためのロード バランシング アルゴリズム（呼び出しルーティング クラス）を備えています。呼び出しが行われるたびに、スタブではそのロード アルゴリズムを利用して呼び出すレプリカを選択できます。この機能により、呼び出し側からは意識されない方法でクラスタ全体でのロード バランシングが実現されます。呼び出しの途中でエラーが起きると、スタブによってその例外が横取りされ、別のレプリカで呼び出しが再試行されます。この機能により、同じように呼び出し側からは意識されないフェイルオーバが実現されます。
クラスタ化されたオブジェクトと RMI-IIOP クライアント
IIOP プロトコルを介して動作する RMI オブジェクトに対するクラスタ化のサポートは、サーバサイド オブジェクトに限られます。JDK ORB を使用するクライアントは、WebLogic のクラスにアクセスできず、ロード バランシングやフェイルオーバなど、WebLogic 固有の機能を利用することはできません。IIOP を介して動作するクラスタ化されたオブジェクトに対するロード バランシングとフェイルオーバは、オブジェクトが WebLogic Server の実行時環境内で動作している場合にのみサポートされます。クライアントサイドの RMI オブジェクトに対してロード バランシングとフェイルオーバを行うには、T3 プロトコルを使用する必要があります。
クラスタ化された EJB
EJB は、2 つの異なるレプリカ対応スタブ（EJBHome インタフェースのスタブと EJBObject インタフェースのスタブ）を生成できるという点で、単純な RMI オブジェクトとは異なります。つまり、EJB では以下の 2 段階でロード バランシングとフェイルオーバのメリットを実現できるのです。
以降の節では、さまざまな EJB の機能を概説します。さまざまな EJB タイプでのクラスタ化の動作に関する詳細については、「WebLogic Server クラスタにおける EJB」を参照してください。
EJB ホームのスタブ
すべての Bean ホームはクラスタ化可能です。Bean がサーバにデプロイされると、そのホームはクラスタワイドのネーミング サービスにバインドされます。ホームはクラスタ化可能なので、各サーバではそのホームのインスタンスを同じ名前でバインドできます。クライアントがこのホームをルックアップすると、そのクライアントでは Bean がデプロイされた各サーバ上のホームへの参照を持つレプリカ対応スタブが取得されます。create() または find() が呼び出されると、その呼び出しはレプリカ対応スタブによってレプリカの 1 つに転送されます。ホームのレプリカは、find() の結果を受信するか、またはそのサーバで Bean のインスタンスを作成します。
ステートレス EJB
ホームでステートレス Bean が作成されると、Bean がデプロイされたどのサーバにでも呼び出しを転送できるレプリカ対応 EJBObject スタブが返されます。ステートレス Bean ではステートが保持されないので、スタブでは Bean のホストであるどのサーバにでも呼び出しを転送できます。また、Bean はクラスタ化されるので、スタブでは障害が起きたときに自動的にフェイルオーバを実行できます。スタブでは、Bean は自動的には多重呼び出し不変として扱われないので、あらゆる障害から自動的に回復することはありません。Bean が多重呼び出し不変メソッドを利用して記述されている場合は、そのことをデプロイメント記述子で示すことができ、そうすればあらゆる場合で自動フェイルオーバが有効になります。
ステートフル EJB
あらゆる EJB の場合と同じように、クラスタ化されたステートフル セッション EJB でもレプリカ対応 EJBHome スタブが利用されます。ステートフル セッション EJB のレプリケーションを使用する場合、EJB ではそのプライマリ ステートとセカンダリ ステートの位置を保持するレプリカ対応 EJBObject スタブも利用されます。EJB のステートは、HTTP セッション ステートの場合と同様のレプリケーション方式で維持されます。詳細については、
ステートフル セッション Bean のレプリケーションを参照してください。
エンティティ EJB
エンティティ Bean には、読み書き対応エンティティと読み込み専用エンティティの 2 種類があります。
ホームで読み書き対応エンティティ Bean が検索または作成される場合は、ローカル サーバでインスタンスが取得され、そのサーバに固定されたスタブが返されます。ロード バランシングとフェイルオーバはホームのレベルでのみ行われます。クラスタにはエンティティ Bean の複数のインスタンスが存在する可能性があるため、各インスタンスは各トランザクションの前にデータベースから読み込まれ、各コミットで書き込まれなければなりません。
ホームで読み込み専用エンティティ Bean が検索または作成される場合は、レプリカ対応スタブが返されます。このスタブでは、すべての呼び出しでロード バランシングが行われますが、回復可能な呼び出しエラーが発生したときに自動的にフェイルオーバは行われません。読み込み専用 Bean は、データベース読み込みを防止するためにすべてのサーバでキャッシュされます。
クラスタで EJB を使用する方法の詳細については、「WebLogic Server EJB コンテナ」を参照してください。
エンティティ Bean と EJB ハンドルに対するフェイルオーバ
エンティティ Bean および EJB ハンドルに対するフェイルオーバでは、クラスタ内のすべてのサーバ インスタンスだけにマップされる DNS 名として、クラスタ アドレスを指定する必要があります。クラスタの DNS 名は、クラスタのメンバーではないサーバ インスタンスにマップされてはなりません。
クラスタ化された RMI オブジェクト
WebLogic RMI には、クラスタ化されたリモート オブジェクトをビルドするための特殊な拡張機能があります。それらの拡張機能は、EJB のセクションで説明されているレプリカ対応スタブをビルドするために使用します。WebLogic Server クラスタで RMI を使用する方法の詳細については、『WebLogic RMI プログラマーズ ガイド』を参照してください。
ステートフル セッション Bean のレプリケーション
WebLogic Server では、HTTP セッション ステートの場合と同じようにステートフル セッション EJB のステートがレプリケートされます。クライアントで EJBObject スタブが作成されると、接続先の WebLogic Server インスタンスでは EJB のレプリケートされたステートのホストとなるセカンダリ サーバ インスタンスが自動的に選択されます。セカンダリ サーバ インスタンスは、「
HTTP セッション ステートのレプリケーションについて」で定義されている同じルールに従って選択されます。たとえば、レプリケートするステートフル セッション EJB データのホストとなるレプリケーション グループとして動作するように、WebLogic Server インスタンスの集合を定義できます。
クライアントでは、EJB のステートをホストするクラスタ内のプライマリ サーバとセカンダリ サーバの位置が記録されたレプリカ対応スタブが受信されます。次の図は、クラスタ化されたステートフル セッション EJB にクライアントがアクセスする状況を示しています。
プライマリ サーバは、クライアントが対話する EJB の実際のインスタンスのホストとして機能します。セカンダリ サーバは、EJB のレプリケートされたステートのみを保持します。ステートのみなので、少しのメモリしか消費されません。セカンダリ サーバでは、フェイルオーバのとき以外は EJB の実際のインスタンスは作成されません。このため、セカンダリ サーバではリソースの使用が最小限に抑えられます。EJB ステートのレプリケートに備えて追加の EJB リソースをコンフィグレーションする必要はありません。
EJB ステートの変更のレプリケート
クライアントによって EJB のステートが変更されると、ステートの変更部分がセカンダリ サーバのインスタンスにレプリケートされます。トランザクションに関係している EJB の場合、レプリケーションはトランザクションのコミットの直後に行われます。トランザクションに関係していない EJB の場合、レプリケーションは各メソッド呼び出しの後に行われます。
両方の場合で、EJB のステートの実際の変更部分だけがセカンダリ サーバにレプリケートされます。このため、レプリケーション プロセスに伴うオーバーヘッドが最小限に抑えられます。
注意: EJB 仕様で説明されているように、ステートフル EJB の実際のステートはトランザクション非対応です。可能性は低いですが、EJB の現在のステートが失われることもあり得ます。たとえば、EJB の関与しているトランザクションがクライアントによってコミットされ、ステートの変更がレプリケートされる前にプライマリ サーバで障害が起きると、クライアントは以前に格納されていた EJB のステートにフェイルオーバされます。
どのような障害が起きても EJB のステートを維持する必要がある場合は、ステートフル セッション EJB ではなくエンティティ EJB を使用してください。
ステートフル セッション EJB のフェイルオーバ
プライマリ サーバで障害が起きると、以降のリクエストはクライアントの EJB スタブによって自動的にセカンダリ WebLogic Server インスタンスにリダイレクトされます。この時点で、レプリケートされたステート データを使用してセカンダリ サーバで新しい EJB インスタンスが作成され、セカンダリ サーバで処理が継続されます。
フェイルオーバの後、WebLogic Server では EJB セッション ステートをレプリケートする新しいセカンダリ サーバが選択されます（クラスタ内に利用可能な別のサーバがある場合）。新しいプライマリとセカンダリのサーバ インスタンスの位置は、次に示すように、次のメソッド呼び出しのときにクライアントのレプリカ対応スタブで自動的に更新されます。
レプリカ対応スタブはクラスタ化されたオブジェクトのロード バランシング ロジックを備えていますが、オブジェクトのメソッドが呼び出されるときに、WebLogic Server によって常にロード バランシングが実行されるわけではありません。ほとんどの場合は、リモート サーバにあるレプリカを使用するよりも、スタブ自体と連結しているレプリカを使用する方が効率的です。次の図は、そのような状況を詳しく説明しています。
上の例では、クライアントは、クラスタ内の最初の WebLogic Server インスタンスにあるサーブレットに接続します。クライアントの動作に対する応答として、サーブレットはオブジェクト A のレプリカ対応スタブを取得します。オブジェクト A のレプリカは同じサーバ上にもあるので、そのオブジェクトはクライアントのスタブと連結していると判断されます。
WebLogic Server では、クラスタ内のオブジェクト A の他のレプリカにクライアントの呼び出しを分散しないで、常に、ローカルにある連結されたオブジェクト A のコピーを使用します。クラスタ内の他のサーバとのピア接続を確立するネットワーク オーバーヘッドが避けられるので、ローカル コピーを使用した方が効率的です。
この最適化は、WebLogic Server クラスタの設計段階でよく見過ごされます。連結の最適化は、各メソッド呼び出しでのロード バランシングを必要としている管理者や開発者にとって混乱の元になることもよくあります。クラスタが 1 つの Web アーキテクチャでは、この最適化によってレプリカ対応スタブに固有のロード バランシング ロジックが無効になります。
クラスタ化されたオブジェクトに対する各メソッド呼び出しでロード バランシングが必要な場合、そのように WebLogic Server クラスタを設計する方法については、「 WebLogic Server クラスタのプランニング」を参照してください。
トランザクションの連結
基本的な連結方式の拡張として、WebLogic Server では同じトランザクションに関わっているクラスタ化されたオブジェクトも連結されます。クライアントによって UserTransaction オブジェクトが作成されると、WebLogic Server ではそのトランザクションと連結されているオブジェクトのレプリカが使用されます。次の図は、この最適化の仕組みを表しています。
この例では、クライアントは、クラスタ内の最初の WebLogic Server インスタンスに接続し、UserTransaction オブジェクトを取得します。新しいトランザクションが開始された後、クライアントはトランザクションの処理を実行するためにオブジェクト A とオブジェクト B をルックアップします。この状況では、A と B のスタブによるロード バランシングとは関係なく、WebLogic Server は常に UserTransaction オブジェクトと同じサーバにある A と B のレプリカを使用します。
このようなトランザクションの連結方式は、「 連結されたオブジェクトの最適化」で説明されている基本的な最適化よりも重要です。A と B のリモート レプリカが使用される場合は、トランザクションが終了するまでの間、余計なネットワーク オーバーヘッドが生じることになります。なぜなら、トランザクションがコミットされるまで A と B のピア接続がロックされるからです。その上、WebLogic Server ではトランザクションをコミットするために多層 JDBC 接続を利用しなければならないため、さらにネットワーク オーバーヘッドが生じることになります。
トランザクション コンテキストでクラスタ化されたオブジェクトを連結すると、WebLogic Server では個々のオブジェクトにアクセスするためのネットワーク負荷が削減されます。また、サーバでは多層接続ではなく単一層の JDBC 接続を利用してトランザクションの処理を実行できます。
オブジェクト デプロイメントの必要条件
WebLogic Server クラスタで使用する EJB をプログラムする場合は、クラスタ内の各種の EJB の機能について、この章の指示と「WebLogic Server EJB コンテナ」を参照してください。EJB のデプロイメント記述子でクラスタ化を有効にします。weblogic-ejb-jar.xml デプロイメント記述子は、クラスタ化に対応する XML デプロイメント要素を示します。
EJB またはカスタム RMI オブジェクトを開発する場合は、クラスタ化されたオブジェクトの実装を JNDI ツリーでバインディングする方法について「クラスタ環境での WebLogic JNDI の使い方」も参照してください。
|
|
|