オブジェクトのクラスタリング

JRun のクラスタリングアーキテクチャは、クラスタリングが有効になっている JRun サーバで実行されるクラスタマネージャによって制御されます。サーバの開始時に、クラスタ可能なサービスは、JINI ルックアップサービスを使用して、クラスタ内の各クラスタマネージャに自分自身を登録します。これによって、各クラスタマネージャはクラスタ内にあるすべてのクラスタ可能なサービスを検出することができます。同時にクラスタ可能な各サービスは、クラスタ内でピアを検出できます。次の図は、クラスタマネージャとクラスタ可能なサービスを示したものです。

JRun は次のクラスタ可能なサービスを提供しています。
サービス
説明
JNDI コンテキストマネージャ
クライアントが JNDI Lookup を使用してクラスタ可能なオブジェクトをリクエストすると、JRun はクラスタ内にあるすべてのサーバの情報を持つコンテキストマネージャを返します。JRunサーバがクラスタに参加していると自動的にフェイルオーバーが有効になり、これらのリソースはいつでも利用できます。また、JRun によってロードバランスが行われることも示しています。
RMI ブローカー
JRun でのすべてのリモートアクセスに対する RMI トランスポート実装です。
セッションレプリケーション
Web アプリケーションにセッションレプリケーションを使用する場合、セッションレプリケーションサービスはクラスタリングを使用して、クラスタ内のバディーサーバとステートを同期します。詳細については、「セッションレプリケーションの使用」を参照してください。

メモ:  クラスタ名は固有であることが必要です。また、クラスタ内の JRun サーバにも固有の名前が必要です。たとえば、複数の開発者が同じサブネット上でデフォルトのクラスタ名を使用してクラスタを定義し、それらのクラスタにデフォルトの JRun サーバが含まれている場合、問題 (JNDI へのランダムアクセス) が発生します。

JRun のクラスタリングには次の制限があります。

JMC 内にクラスタを定義すると、オブジェクトのクラスタリングはほとんどのユーザーに対して行われます。ただし、特定のタイプの開発者は、クラスタリングについて次の点を考慮しなければなりません。

次のセクションでは、これらのトピックについて説明します。

EJB とオブジェクトのクラスタリングの使用

クライアントが JNDI を使用して EJB を参照すると、JRun はクラスタ内のすべてのサーバの情報を持つコンテキストマネージャを返します。JRunサーバがクラスタに参加していると自動的にフェイルオーバーが有効になり、これらのリソースはいつでも利用できます。また、次に示すように、異なるロードバランスアルゴリズムを使用して、JRun がクラスタ内でロードバランスを自動的に行います。

次の図は、EJB のクラスタリングを示すものです。

EJB メソッドの呼び出し中に JRun サーバがオフラインになった場合、クライアントスタブは自動的にリクエストをクラスタ内の別のサーバに再転送します。さらに、オブジェクトのクラスタリングによってステートが自動的にクラスタ内のバディーサーバにパッシベートされ、ステートフルセッション bean が複製されます。

JMC でクラスタを作成する際、EJB のクラスタリングが自動的に有効になります。EJB のクラスタリングを無効にするには、jrun-ejb-jar.xml ファイルの cluster-home 要素および cluster-object 要素に false を指定します。ローカル EJB はクラスタできません。

クラスタ定義の詳細については、JMC のオンラインヘルプを参照してください。

クラスタされた環境での JMS の使用

JRun JMS は、クラスタされた JRun サーバの JMS サービスのディスクリプタファイルを変更することによって、クラスタリングをサポートします。

JMS のクラスタリングを有効にするには

  1. JMS のデスティネーションと接続ファクトリ (jrun-resources.xml で定義されているもの) ファイルが、クラスタ内のすべての JRun サーバで同じであることを確認します。
  2. クラスタ内の JRun サーバを 1 台選択し、JMSService を実行します (ターゲットサーバと呼びます)。クラスタ内の他のすべてのサーバで、次の手順を実行します。
  3. クラスタ内にあるすべてのサーバの SERVER-INF/jrun-resources.xml ファイルを参照し、JMS デスティネーションと JMC 接続ファクトリが、ターゲットサーバのものと一致していることを確認します。
  4. ターゲットサーバを起動します。
  5. クラスタ内の他のサーバを起動します。

次の例は、ターゲットサーバ以外のすべての JRun サーバについて JMS のクラスタリングを有効にするために、jrun.xml ファイルに加える変更を示すものです。

...
<service class="jrun.jms.JRunJMS" name="JRunJMS">
...
<!-- ======================================================================= -->
<!-- このサービスは、JMS プロバイダを開始します。(JRun ビルトイン) -->
<!-- ======================================================================= -->
<!--
<service class="jrun.jms.adapter.JRunMQAdapter" name="JMSAdapter">
<attribute name="ConfigFileName">jrun-jms.xml</attribute>
<attribute name="bindToJNDI">true</attribute>
</service>
-->
<!-- ==================================================================== -->
<!--  このサービスは、J2EE クライアントに JMS アクセスを提供します (JRun ビルトイン)。   -->
<!-- ==================================================================== -->
<service class="jrun.jms.wrapper.JRunMQServiceWrapper" name="JMSServiceWrapper">
<attribute name="bindToJNDI">true</attribute>
<attribute name="DefaultQCFName">QueueConnectionFactory</attribute>
<attribute name="DefaultTCFName">TopicConnectionFactory</attribute>
<attribute name="DefaultTransport">RMI</attribute>
<attribute name="JMSUrl">localhost:2918</attribute>
<attribute name="JMSContextFactoryName">jrun.naming.JRunContextFactory
</attribute>
<!-- AdapterType は、ラッパーがリモートかローカル
     のどちらのアダプタを使用するかを示します。 -->
<attribute name="AdapterType">remote</attribute>
<attribute name="AdapterServerName">fresca</attribute>
</service>

JRun サービスとオブジェクトのクラスタリングの使用

JNDI はクラスタ可能なサービスなので、jrun-xml.file 定義で bindToJNDI 属性が true に設定されているサービスもすべてクラスタできます。たとえば、クラスタ内の 2 台のサーバが両方とも、compass という名前の JDBC データソースを定義している場合を考えます。クライアントアプリケーションが、InitialContext.lookup によってこのデータソースにアクセスすると、戻り値の javax.sql.DataSource はクラスタ内のいずれの JRun サーバからも返される可能性があります。

JRun サーバにデプロイされたリソースのクラスタリングに加えて、サービスもクラスタできます。JRun は、サービスへのリファレンスを、JNDI ツリー内の複数の場所に保存します。クラスタされたエントリは、jrun:service/<サービス名> にあります。ローカル JRun サーバのエントリは、jrun:service/<サーバ名>/<サービス名> にあります。JRun での JNDI 使用の詳細については、弟 8 章、「JNDI に関する考慮」を参照してください。

次のサンプルコードは、JRun の LoggerService にアクセスし、クラスタ内にある任意の JRun サーバへのリファレンスを取得するものです。

...
// この例を実行するには、LoggerService (jrun.xml ファイル) 内で bindToJNDI 属性を 
// true に設定してください。
import java.util.Properties;
import javax.naming.InitialContext;
import javax.naming.Context;
import jrunx.logger.LoggerService;
...
  try {
    Properties p = new Properties();
    p.put(Context.INITIAL_CONTEXT_FACTORY, 
"jrun.naming.JRunContextFactory");
    p.put(Context.PROVIDER_URL, "localhost:2918");
    InitialContext ctx = new InitialContext(p);
    LoggerService ls = (LoggerService) 
ctx.lookup("jrun:service/LoggerService");
    ls.logInfo("Message logged using LoggerService");
  } // try の終了
  catch (Exception e) {
    System.out.println(e);
    throw new Exception(e);
  }
...

JNDI Lookup が特定の JRun サーバにリファレンスを返すようにするためには、次の例のように、lookup メソッドに渡される文字列にサーバ名を含めます。

...
    LoggerService ls = (LoggerService) 
ctx.lookup("jrun:service/samples/LoggerService");
...

メモ:  JNDI からサービスにアクセスするには、そのサービスの bindToJNDI 属性が true に設定されていなければなりません。詳細については、「すべてのサービスに共通の属性」を参照してください。