 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||
|
||||||||||||||
| JBossの可用性向上 | ||||||||||||||
|
JBossは標準でクラスタリングの機能を提供しており、Hinemosで利用しているバージョン（4.0.3SP1）では、主な機能として表2にあげる機能を備えています。
表2：JBossの主なクラスタリング機能 これら表2の機能を活用することで、Hinemosで用いるJBossをクラスタ化します。 一般的にクラスタリングの構成を組む場合、アクティブ/スタンバイ構成とアクティブ/アクティブ構成の2つの方式が考えられます。JBossクラスタリングの機能では、クラスタ化するマシンの台数は限定されず、JMSサービスを除くJNDIやRMIのサービスおよび、EJBをすべてのマシンでアクティブにし、ロードバランシングすることが可能です（図2）。 この図では、データベースはPostgresForestを使って仮想的に1つのデータベースと見なしたものとして表現しています。PostgresForestについては後述します。  図2：JBossクラスタリング構成（アクティブ-アクティブ） （画像をクリックすると別ウィンドウに拡大図を表示します） この構成は、更新に比べ参照の多いシステムでは、負荷の分散が可能となり有効な方式となりますが、次の2つの観点を考慮する必要があります。 |
||||||||||||||
| JMSはシングルトンサービスである | ||||||||||||||
|
JMSサービスはクラスタノードのうちどれか1台でのみ動作し、フェイルオーバは提供されていますが、ロードバランシングは提供されていません。 |
||||||||||||||
| EntityBeanはクラスタノード間にまたがって整合性を維持するための仕組みを持っていない | ||||||||||||||
|
例えば、2つのクライアントがそれぞれクラスタノードAとクラスタノードBに対して同時に、同じレコードに対応するEntityBeanに対して更新をかけた場合、クラスタノードAの更新がクラスタノードBでは反映されていない可能性があります。 よって、下記のいずれかの方法でデータベースレベルでデータの整合性を確保する必要があります。
表3：データの整合性を取る方法 Hinemosでは、マネージャとエージェント間のデータのやり取りや非同期処理（MDB）で、JMSの機能を多く使っています。また、監視結果や実行結果の反映のためのデータの更新が頻繁であるため、ボトルネックとなるのはデータベースアクセス部分であることを考えると、アクティブ/アクティブの構成にするよりも、むしろシンプルに2台構成のアクティブ/スタンバイ方式の方が向いていると考えられます。2台構成のアクティブ/スタンバイ方式とすれば、EntityBeanが生成されるのは1台のノードに限定されるため、データの不整合が生じることはなくなります。  図3：HinemosでのJBossクラスタリング構成（アクティブ/スタンバイ） （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
