 |
||||||||||||||
|
||||||||||||||
| 1 2 3 4 次のページ | ||||||||||||||
|
||||||||||||||
| クラスタリング／ファーミング | ||||||||||||||
|
クラスタリングとは、主としてハードウェア障害が発生した場合であってもサービスを提供し続けることを目的とした技術です。具体的には、2台以上のサーバを用意して、サーバ群の一部がダウンした場合であっても残りのサーバがサービスを提供し続けるようなしくみを用意することになります。 このとき注意して欲しいのは、サーバの台数が増えるからといってパフォーマンス、例えばレスポンスタイムやスループットなどが向上するわけではないという点です。むしろ多くの場合、可用性が向上する代わりにパフォーマンスが低下します。 パフォーマンスを向上するためには、ロードバランスのためのしくみ（ハードウェア／ソフトウェア・ロードバランサの導入など）を別途用意するなどの対応が必要となります。ただし後ほど説明しますが、JBossの場合はこういった問題を回避しようという仕掛けがあります。 |
||||||||||||||
| JBossのクラスタリング | ||||||||||||||
|
JBossにはクラスタリングのしくみが標準で用意されていますので、手軽に可用性を高めることができます。JBossをクラスタリング構成で稼働させるには、「default」ではなく「all」の設定を使用します。つまり、下記のコマンドでJBossを起動します。 |
||||||||||||||
run -c all
|
||||||||||||||
|
これだけで、JBossはクラスタで動作する準備が整いました。
※補足：
もちろん、以前の連載で説明したように$JBOSS_HOME\server以下の「all」ディレクトリをまるごとコピーして、例えばmyAppAllなどとディレクトリ名をリネームした場合は「run -c myAppAll」となります。
LANの同一セグメント上に接続されている2台のPCを用意して、両方のPC上で上記のようにall設定を用いてJBossを起動すれば、自動的にお互いのサーバの検出および認識をし、クラスタに必要なサービスが開始されます。 |
||||||||||||||
| ステート情報のレプリケーション | ||||||||||||||
|
JBossのクラスタリングは、メモリ上のステート（状態）をレプリケーションすることによって実現されています。例えば、サーバAとサーバBがあり、サーバAに接続してログオンしたとします。その後、サーバAを停止させてサーバBへアクセスした場合、再度ログオンすることなしに、あたかもサーバAに接続しているかのように継続してサービスを利用することができます。 この動作をもう少し細かく見ていくと、クライアント（ブラウザ）がサーバAにアクセスした時点で、サーバAのメモリ上にセッションと呼ばれるオブジェクトが作成されます。このオブジェクトの中には様々なステート、例えばログオンしたかどうかのフラグなどが含まれています。こういったステート情報が自動的にサーバBにレプリケーションされます。  図1：ステート情報のレプリケーション 例としてHTTPセッションを取り上げましたが、このステート情報はステートフル・セッションBeanにおいても適用することができます。ちなみステートレス・セッションBeanの場合は、そもそもレプリケーションするステートが存在しません。 先に掲げた図にもある通り、JBoss単体ではアクセスを振り分けるしくみを提供していませんので、別途用意する必要があります。最も手軽かつ安価にこれを実現するには、Apache httpdサーバ＋mod_jk 1.2.xを用いるなどの方法があります（注1）。もちろん、ハードウェア・ロードバランサやリバースプロキシなどを用いても構いません。 |
||||||||||||||
|
1 2 3 4 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
