TOP
＞
比較データ
＞ 前回から
Javaアプリケーションサーバのクラスタリング機能比較
第６回：WebLogic Serverが提供するクラスタ機能
著者：
サンモアテック 高木 基成
2005/11/28
1
2
3
4
次のページ
前回から
前回では、WebLogic Serverのクラスタリングの設定について解説しました。今回は各クラスタ機能について解説します。
クラスタへのデプロイ
実装したモジュールのデプロイ処理は、管理コンソールや「WebLogic Builder」「weblogic.Deployer」を使うことで簡単に行うことができます。ここでは表1の流れにそって、クラスタリングされたサーバへデプロイするときの処理を解説します。
クラスタへのデプロイにおける注意点
デプロイ処理をしている間はクラスタ内のすべての管理対象サーバが正常に稼動している（管理サーバからアクセスできる状態である）ことが望まれます。また、クラスタへ管理対象サーバを追加・削除する処理は行わないでください。
WebLogic Server 8.1では、管理対象サーバの一部が稼動していなくても、デプロイ処理が行われます。これのような状況を回避したい場合は、weblogic.DeployerでenforceClusterConstraintsフラグを「true」に設定するという方法があります。この設定をすれば、クラスタ内のすべての管理対象サーバがアクセス可能な場合にのみデプロイ処理が行われます。
以下は、enforceClusterConstraintsフラグを「true」に設定した場合の動きになります。
1. デプロイの準備処理
デプロイの準備処理として、WebLogic Serverはクラスタ内の管理対象サーバに対して生存確認を行います。
2. デプロイ対象モジュールの検証処理
次に、デプロイ対象のモジュールが管理対象サーバに配信されて、デプロイの検証が行われ、正常にデプロイされることが確認されます。この状態では、デプロイ対象のアプリケーションはリクエストを処理することができません。
このプロセスにおいて、クラスタ内の管理対象サーバの1つでも障害が発生した場合、すでにデプロイが完了している管理対象サーバも含めて、クラスタ内の全管理対象サーバにおけるデプロイ処理が中止されます。
3. デプロイ処理
すべての管理対象サーバがデプロイ対象のモジュールの検証を終えると、各管理対象サーバに完全にデプロイされます。この時点で、デプロイされたアプリケーションはリクエストを処理することができようになります。
このプロセス中に障害が発生すると、障害が発生したサーバへのデプロイは中断されます。しかし、他のクラスタ内の管理対象サーバで行われた正常なデプロイがキャンセルされることはありません。
表1：クラスタへのデプロイの流れ
1
2
3
4
次のページ
著者プロフィール
株式会社サンモアテック 高木 基成
株式会社サンモアテック 技術開発事業部
2002年入社。システム間連携を実現する各種ミドルウェアの調査・導入に従事。現在、ESBやSOAなどを実現するための新技術検証に携わっている。
INDEX
第6回：WebLogic Serverが提供するクラスタ機能
前回から
サーブレットとJSPのクラスタリング
EJBのクラスタリング
JMSのクラスタリング
