JGroupsクラスタグループ

JGroups通信モジュールはグループ間の通信を提供し、これによって共通の名前、マルチキャストアドレス、およびマルチキャストポートを共有します。JGroupsはJBossと同時にインストールされます。JBossがなくても使用できます。クラスタ環境におけるキャッシュをサポートするために、ユーザアプリケーションのユーザアプリケーションWARには、JGroupsモジュールが用意されています。

JBossグループのクラスタグループ

JBossクラスタは、JGroups通信モジュールに基づいています。クラスタ化されたJBossサーバをインストールすると、クラスタの管理に使用する複数のJGroupsグループクラスタ環境設定がJBossによって定義されます。この中の1つはDefaultPartitionと呼ばれ、/deploy/cluster-service.xmlに定義されています。このクラスタグループは、中核となるクラスタリングサービスを提供します。また、Tomcat-Clusterというクラスタグループも定義されます。この環境設定は、/deploy/jboss-web-cluster.sar/META-INF/jboss-service.xmlに定義されています。このファイルは、JBoss内で動作するWebサーバに対して、セッションのレプリケーションサポートを提供します。JBossには、ejb3サービスを管理するためのクラスタグループ環境設定も用意されています。

ユーザアプリケーションのクラスタグループ

Identity Managerユーザアプリケーションは、JBoss/Websphereクラスタ環境内のユーザアプリケーションキャッシュを調整するために、別のクラスタグループを使用します。

ユーザアプリケーションのクラスタグループは、2つのJBossクラスタグループとは独立しており、データのやり取りなどは行われません。ユーザアプリケーションのクラスタグループと2つのJBossグループは、異なるグループ名、マルチキャストアドレス、およびマルチキャストポートをデフォルトで使用するため、設定し直す必要はありません。

デフォルトでは、このクラスタグループはUUID名を使用します。そのため、ユーザがサーバに追加する他のクラスタグループ名との競合リスクを最小限に抑えられます。デフォルト名は「c373e901aba5e8ee9966444553544200」です。デフォルトでは、このグループはマルチキャストアドレス228.8.8.8を使用し、ポート45654上で動作します。このクラスタの設定はJBossサービスファイルを使用していません。その代わり、設定はディレクトリに存在し、ユーザアプリケーションの管理機能で設定できます。JGroupsおよびJBossのクラスタリングに精通しているユーザは、このインタフェースを使用してユーザアプリケーションのクラスタ設定を調整できます。クラスタ設定の変更をサーバノードに適用するには、そのサーバノードを再起動する必要があります。

ユーザアプリケーションのクラスタグループの設定は、ディレクトリ設定を共有するすべてのIdentity Manager アプリケーションと共有されます。ユーザアプリケーションの管理インタフェースにあるローカル設定オプションは、管理者がクラスタからノードを削除したり、クラスタ内のサーバのメンバーシップを変更したりできるようにする目的で用意されています。たとえば、グローバルでクラスタリングを無効にしてから、ディレクトリ設定を共有するサーバのサブセットに対してローカルでクラスタリングを有効にすることができます。

同じネットワーク内の複数のクラスタについて

ネットワーク上で複数のクラスタが動作している場合、パフォーマンスの低下や誤動作を防止するために、クラスタを分離する必要があります。分離するには、クラスタごとに別のパーティション名、マルチキャストアドレス、マルチキャストポートを使用します。同じネットワーク上に複数のクラスタがない場合でも、クラスタにはデフォルトのパーティション名を使用する代わりに、一意のパーティション名を指定することをお勧めします。

重要事項を次に示します。

JBossの場合、単一ネットワーク上での複数クラスタの運用に関する情報を、ブラウザを使ってTwo Clusters Same Network(同一ネットワーク上の2つのクラスタ)から参照することができます。

アプリケーションサーバ時刻の同期化

ユーザアプリケーションクラスタ内のサーバの時刻は同期化する必要があります。サーバの時刻を同期化しないと、セッションタイムアウトが早期に発生し、HTTPセッションのフェイルオーバーが正しく機能しない可能性があります。時刻を同期化するには、さまざまな方法があります。使用する方法は、組織のニーズによって異なります。方法の1つとして、ネットワークタイムプロトコルのNTPを使用することが考えられます。時刻同期にxNTPプロトコルを使用する方法については、『Time Synchronization using Extended Network Time Protocol (xntp)』を参照してください。

単一クラスタ内で同じブラウザの複数のタブからのログインの防止

あるブラウザで複数のタブを使ってログインしたり、同じホストで複数のブラウザセッションを使ってログインすることはお勧めいたしません。一部のブラウザはすべてのタブとプロセス間でcookiesを共有します。そのため、複数ログインを行う他HTTPセッションのフェイルオーバー時に問題が発生する可能性があります(さらに、1台のコンピュータを複数ユーザが共有している場合、予期しない認証動作が発生する危険性もあります)。

ユーザアプリケーションデータベースについて

ユーザアプリケーションのインストールプログラムを使ってユーザアプリケーションをインストールする場合、使用するデータベースを指定します(例:MySQL、Oracle、またはMicrosoft SQL Serverなど)。このデータベースは、ユーザアプリケーションデータと環境設定情報の保管に用いられます。

クラスタ環境にユーザアプリケーションをインストールする場合、JBossクラスタ内のすべてのノードが同じインスタンスのデータベースにアクセスしなければなりません。ユーザアプリケーションは標準のJDBCコールを使用してデータベースのアクセスや更新を行います。ユーザアプリケーションは、JNDIツリーにバインドされたJDBCデータソースを使用してデータベースへの接続を開きます。

ユーザアプリケーションインストールプログラムを使ってJBossクラスタにユーザアプリケーションをインストールする場合は、データソースがインストールされます。インストールプログラムはIDM-ds.xmlと言う名前のデータソースファイルを作成し、このファイルを展開用のディレクトリ(例:server/IDM/deploy)に格納します。 また、インストール時に指定されたデータベースに対応する適切なJDBCドライバを、libディレクトリに格納します(例:/server/IDM/lib)。 クラスタ環境におけるユーザアプリケーションデータベースの設定方法の詳細は、ユーザアプリケーションデータベースの指定を参照してください。

(java.sql.SQLException: Data source rejected establishment of connection, message from server: "Too many connections.")

サーバ環境設定について

JBossには、すぐに利用できる3種類のサーバ環境設定minimal、default、およびallが用意されています。クラスタリングはallの設定でのみ有効になります。/deployフォルダにあるcluster-service.xmlファイルには、デフォルトのクラスタパーティションの設定が記述されています。ユーザアプリケーションのインストール時に、インストールプログラムでクラスタにインストールするよう指定すると、インストールプログラムはすべての設定のコピーを作成し、そのコピーにIDMという名前を付けます(これはデフォルト設定です。インストールプログラムを使用して名前を変更できます)。それからこの設定にユーザアプリケーションをインストールします。

ユーザアプリケーションデータベースの指定

JBossクラスタのノードはすべて、同じデータベースインスタンスにアクセスする必要があります。ユーザアプリケーションインストールプログラムを使用する場合、データベース名、ホスト、およびポートの指定を要求するメッセージが表示されます。

図 2-3 データベースのホストとポートの指定

クラスタノードにユーザアプリケーションをインストールする際には、毎回同じデータベースパラメータを指定してください。

クラスタ(すべて)オプションの選択

ユーザアプリケーションインストールプログラムを使用する場合、IDM環境設定の指定を要求するメッセージが表示されます。

図 2-4 クラスタ(すべて)オプションとエンジンIDの指定

［クラスタ(すべて)］オプションを選択します。

ワークフローエンジンの環境設定

ワークフローエンジンのクラスタリングは、ユーザアプリケーションのキャッシュフレームワークとは無関係に動作します。クラスタ環境でワークフローエンジンを正常に動作させるには、いくつかの手順を実行する必要があります。

このシステムプロパティの設定と、他のシステムプロパティの設定を組み合わせることもできます(JBoss起動スクリプト中のJBossシステムプロパティの設定を参照)。

実行中のワークフローの管理については、クラスタ内のワークフローの管理を参照してください。

start run.bat -c IDM -Djboss.partition.name=Example_Partition -Djboss.partition.udpGroup=228.3.2.1 -Dcom.novell.afw.wf.engine-id=Engine1 

クラスタ内の各ユーザアプリケーションでの同じマスタキーの使用

Identity Managerユーザアプリケーションは、重要なデータを運号化します(セクション 2.2.7, 重要なユーザアプリケーションデータの暗号化を参照)。マスタキーは、暗号化データにアクセスするために用いられます。クラスタ内のすべてのユーザアプリケーションは、同じマスタキーを使用する必要があります。クラスタ内のすべてのユーザアプリケーションが同じマスタキーを使用するようにするには、これらの手順に従ってください。

ユーザアプリケーションクラスタグループの開始

クラスタ内にユーザアプリケーションをインストールし終わったら、ユーザアプリケーションのクラスタ設定でクラスタを有効にする必要があります。

クラスタリング用のユーザアプリケーションドライバの環境設定

クラスタリングでは、複数のユーザアプリケーションで同じユーザアプリケーションドライバが使用されます。これは、クラスタリングの場合のみです。ユーザアプリケーション用ドライバには、アプリケーション固有のさまざまな情報(例: ワークフロー環境設定情報、クラスタ情報)が保持されています。したがって、ユーザアプリケーション用ドライバの1つのインスタンスを複数のアプリケーション間で共有すべきではありません。

ユーザアプリケーションでは、アプリケーション環境を制御および設定するためのアプリケーション固有データがドライバに保持されます。たとえば、JBossアプリケーションサーバのクラスタ情報や、ワークフローエンジン環境設定情報などが保持されます。ユーザアプリケーション用ドライバの1つのインスタンスを共有するユーザアプリケーションは、同じJBossクラスタの一部です。

クラスタで、ユーザアプリケーションドライバは、クラスタのディスパッチャまたはロードバランサのホスト名またはIPアドレスを使用するように設定する必要があります。ユーザアプリケーションドライバは、ユーザアプリケーションのインストール時に作成します(『Novell Identity Managerインストールガイド』を参照)。ユーザアプリケーションドライバは、iManagerを使って環境設定します。

ユーザアプリケーションクラスタグループのキャッシングの環境設定

JGroupsおよびJBossクラスタリングに精通しているユーザは、ユーザアプリケーションの管理ユーザインタフェースを使用してクラスタグループのキャッシング設定を変更できます(クラスタのキャッシュ設定を参照してください)。クラスタ設定の変更をサーバノードに適用するには、そのサーバノードを再起動する必要があります。

たいていの場合、クラスタの設定時にはグローバル設定を行います。ただし、TCPを使用する必要がある場合、グローバル設定では問題が発生してしまいます。サーバのIPアドレスは、各サーバのJGroups初期化文字列に指定する必要があります。［クラスタのプロパティ:］の［ローカルの有効化］を選択して、次に［ローカル］フィールドにJGroups初期化文字列を入力して、ローカル設定を使ってJGroups初期化文字列を指定することができます。JGroupsのTCPプロトコルスタックに関する作業例については、『JGroupsStackTCP』を参照してください。

代わりに、［クラスタプロパティ］のグローバル設定にトークン(例:“IDM_HOST_ADDR”)を追加することもできます。次に、クラスタ内の各サーバのhostsファイルを編集して、サーバのIPアドレスを指定することができます。

クラスタ内のログの設定

この節では、クラスタ内でのログに関するヒントを説明しています。WebSphereに関するヒントはありません。

<!--  Clustering logging 
  --> 
- <!-- 
 Uncomment the following to redirect the org.jgroups and
      org.jboss.ha categories to a cluster.log file.
   <appender name="CLUSTER" class="org.jboss.logging.appender.RollingFileAppender">
     <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
     <param name="File" value="${jboss.server.home.dir}/log cluster.log"/>
     <param name="Append" value="false"/>
     <param name="MaxFileSize" value="500KB"/>
     <param name="MaxBackupIndex" value="1"/>
     <layout class="org.apache.log4j.PatternLayout">
       <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>
     </layout>
   </appender>
   <category name="org.jgroups">
     <priority value="DEBUG" />
     <appender-ref ref="CLUSTER"/>
   </category>
   <category name="org.jboss.ha">
     <priority value="DEBUG" />
     <appender-ref ref="CLUSTER"/>
   </category>
  --> 

クラスタ内のワークフローの管理

Identity Managerユーザアプリケーションワークフロークラスタは、プロセスインスタンスをそれが開始されたエンジンとバインドします。このために、ワークフロープロセスインスタンスが、エンジンIDと関連付けられ、クラスタデータベースで管理されます。ワークフローエンジンが開始されると、そのエンジンIDに割り当てられたプロセスインスタンスが再開されます。こうすることによって、クラスタ内の複数のエンジンが同じプロセスインスタンスを再開することを防止できます。ワークフローエンジンが失敗すると、そのエンジンで動作していたプロセスはクラスタ内の別のエンジンで自動的に再開されます。

プロセスをクラスタ内の他のエンジンに手動で再割り当てすることもできます。たとえば、管理者はワークフローエンジンが回復したときに失敗したワークフローエンジンにプロセスを再割り当てしたり、クラスタからエンジンが削除されたときに他のエンジンにプロセスを再配布することができます(セクション 18.2.7, クラスタ内のワークフロープロセスの管理を参照)。

ワークフローエンジンの開始時に、そのエンジンIDがクラスタ内のノードで使用されていないかどうかがチェックされます。使用されている場合は、クラスタデータベースをチェックして、エンジンのステータスがシャットダウンまたはタイムアウトになっているかどうかが確認されます。どちらかのステータスに該当する場合は、エンジンが開始されます。ステータスが開始中または実行中の場合、そのワークフローエンジンは警告メッセージをログに記録して、ハートビートタイムアウトが発生するまで待機します。ハートビートタイムアウトが発生した場合、それは同じIDを持つ他のワークフローエンジンが正しくシャットダウンされなかったことを表します。そのため、安全にエンジンを開始できます。ハートビートタイマーが更新された場合、それは同じIDを持つ他のワークフローエンジンがクラスタ内で動作中であることを表します。そのため、エンジンを開始することはできません。ハートビートタイムアウト(ワークフローエンジンがタイムアウトになったと判断するまでのハートビート間の最大経過時間)は、ユーザアプリケーションの［ハートビートの間隔:］と［ハートビートファクタ］で設定できます(セクション 8.4.2, ワークフロークラスタの環境設定を参照)。