はじめに

IBM Connections は IBM WebSphere® Application Server (WAS) をベースにしています。11 の機能があり、そのそれぞれに固有のクラスターを設定できます。Connections 3.0 がサポートしているのは Network Deployment のみなので、最小のトポロジーは、単一ノード・クラスターと、同一サーバー・インスタンス上の機能ということになります。

パイロットまたはスタンドアロン・デプロイメントは提供されていません。ユーザーは一般に、実稼働環境で図 1 に示されているようなクラスター・デプロイメントを選択するからです。この図は 2 ノード・トポロジーを示していますが、実際には、1 つの Deployment Manager (DM) で多くのノードを管理できます。

従来、3.0 より前のバージョンの Connections では、各ノードでインストーラーを実行してインストールしていました (図 2 を参照)。そのため、クラスター化するノードが 5 つある場合は、各ノード上で、合計 5 回インストーラーを実行する必要がありました。1 回のインストールに 1 時間かかると仮定すると、インストールが失敗した場合のデバッグ時間を計算に入れなくても、5 時間はかかります。このように待機時間が長いことは、明らかに望ましくありません。

さらに、クラスター・デプロイメントの「旧」プロセスでは、基本的に、まずスタンドアロンがインストールされ、次にノードが DM に統合されます。ただし、統合実行時には多くの問題が報告されました。幸運にも、IBM Connections 3.0 ではそうした状況に変化がもたらされました。

上に戻る

WAS 同期メカニズム

まず WAS 同期メカニズムについて説明が必要でしょう。これが、高速クラスター・デプロイメントに使用する技法だからです。特に、エポックとダイジェストという 2 つの概念は紹介しておく必要があります。

エポック

大まかに言って、エポックとは、ノード・エージェントおよび DM に使用されるキャッシュ・メカニズムであり、同期操作が最後に実行された後に、マスター・リポジトリーでどのファイルが変更されたかを判断するものと考えられます。

次の同期操作が実行される際には、キャッシュ内のフォルダーのみが比較されます。キャッシュ内のフォルダーのエポックが異なる場合、そのようなフォルダーは修正済みと見なされ、同期プロセスで後からさらにチェックが実行されます。

詳しく説明するならば、エポック (com.ibm.websphere.management.repository.ConfigEpoch により実装される) は、long 型の変数を含むオブジェクトです。変数には、最初の初期設定時に、System.currentTimeMillis の値が設定されます。エポックを更新すると long 変数が 1 ずつ増加するのに対して、エポックをリフレッシュすると long 変数が System.currentTimeMillis にリセットされます。

エポックには、リポジトリー・エポックとフォルダー・エポックの 2 種類があります。リポジトリーには関連するエポックがあり、リポジトリーレベル・エポックと呼ばれます。リポジトリー内の各フォルダーにも関連するエポックがあり、フォルダーレベル・エポックと呼ばれます。

セルレベル・エポックとフォルダーレベル・エポックは 2 セットがあります。一方のセットは DM リポジトリーに、もう一方のセットはノード・リポジトリーにあります。エポックを比較する際には、一方のリポジトリーのエポックを、もう一方のリポジトリーのエポックと比較します。

例えば、マスター・リポジトリーのセルレベル・エポックをノード・リポジトリーのセルレベル・エポックと比較したり、マスター・リポジトリーのフォルダーレベル・エポックをノード・リポジトリーの同じフォルダーレベル・エポックと比較したりします。

ダイジェスト

ダイジェストのチェック (チェックサム) とは、同期によって 2 ファイルが同一かどうかを判断する方法のことです。2 ファイルのダイジェストが異なる場合、同期によりファイルが異なると見なされ、ノード・リポジトリーが更新されます。それ以外の場合は、2 ファイルは同一と考えられ、ファイルは転送されません。

実際のダイジェスト計算は Java API を介して実行されます (com.ibm.ws.management.repository.DocumentDigestImpl, calc() メソッドおよび getMessageDigest() メソッドを参照)。リスト 1 は、同期でのダイジェストの計算を示しています。

MessageDigest oneMessageDigest = MessageDigest.getInstance("SHA"); <-- digest algorithm 
is "SHA"

if (oneMessageDigest != null)
{

// Get the digest for the data in the stream
while ((bytesRead = input.read(buffer)) > 0)

oneMessageDigest.update(buffer, 0, bytesRead);
digest = oneMessageDigest.digest(); <-- calculate digest

}

}

同期

同期操作は、自動同期やユーザーが明示的に開始した同期などの場合にノード・エージェントにより実行されるか、syncNode.bat/sh や addNode.bat/sh の実行時に syncNode/addNode プロセスにより実行されます。すべての同期シナリオにおいて、同期操作の初期設定プロセスで DM との通信が行われます。

DM では、マスター・リポジトリーの状態についての情報が検索され、ノード・リポジトリーと比較されます。2 つのリポジトリーのエポックが比較された後で、変更フォルダーのリストがノード・エージェントに戻されます。

次に、リストの各フォルダーについて、DM で文書のダイジェストが比較され、ファイルが本当に異なるのかが判断されます。変更されたファイルはファイル転送によってノードに転送され、ノード・エージェントによりノード・リポジトリーにチェック・インされます。

同期操作は、既に別の同期操作を実行中でない限り、開始できます。同期操作を実行中の場合は、終了するまで待ってから、新たな同期操作を開始してください。

上に戻る

高速クラスター・デプロイメント

使用するステップについて説明します。

プロセスの向上

WAS を使用するすべての構成では、結果的に構成ファイルが変更されます。クラスターは同一の WAS 構成セットを共有するので、同期メカニズムにより、DM のすべての構成ファイルが各ノードに同期されます。

つまり、DM でインストールを実行すると、すべての構成が各ノードに同期されるので、各ノードでの再インストールは必要なくなります。そのため、IBM Connections のような製品のインストール・ステップは以下のとおりになります。

1. WAS をインストールして DM に全ノードを追加する。
2. LDAP を DM 用に構成する。
3. DM マシンで IBM Connections インストーラーを実行し、全アプリケーションを DM 上にデプロイする。
4. インストール後にノード・エージェントを開始する。これにより、同期が自動実行される。
5. およそ 30 分後 (Web パフォーマンスによって異なる)、同期が終了し、クラスターの開始および IBM Connections へのログインが可能になる。

つまり、インストールに 1 時間かかると仮定すると、この高速クラスター・デプロイメントでは、5 ノードのクラスター・デプロイメントにわずか 1.5 時間しか要しません。前の方式では 5 時間かかると予測されていたので、インストーラーのパフォーマンスが著しく向上することになります (図 3 を参照)。

この高速クラスター・デプロイメント方式によって、IBM Connections では、より集中化されたデプロイメントが可能となり、すべてを DM と連携させることができます。ユーザーはインストールを完了させて、DM のノードやアプリケーションを管理できます。また、今後のアップグレード/マイグレーションも DM 上で実行できます。

リソースの相違

この新たなインストール方式を実現するために、セル・レベルまたはクラスター・レベルでリソースが作成され、全ノードにわたる可視化が保証されます。これは旧デプロイメントとの大きな相違点です。ノード・レベルのリソースは作成されず、必要がない限り、サーバー・レベルのリソースも作成されません。
表 1 には、IBM Connections 3.0 のこれらのリソースがすべてリストアップされています。

制限

同期により、AppServer\profiles\<プロファイル名>\config の構成ファイルを同期化できます。このディレクトリー以外の場所に構成ファイルがある場合は、各ノードへの手動コピーが必要になる可能性があります。また、例えば、複数 lib ファイルが AppServer の別々のディレクトリーにある場合も、各ノードでの同期化は実行されません。

同期が終了する前にクラスターを開始すると、問題が起きます。具体的には、同期が中断され、一部のアプリケーションがノードと同期化されない可能性があります。AppServer\profiles\<プロファイル名>\config\cell\<セル名>\applications をチェックすると、全アプリケーションが存在するかどうかを確認できます。

上に戻る

結論

IBM Connections 3.0 では、WAS 同期メカニズムを使用して、高速のクラスター・デプロイメント方法を提供しています。この方法は、ユーザーによる実装およびスケールが容易で、インストールに必要な時間が大幅に削減されます。

上に戻る

リソース

developerWorks IBM Connections 製品ページ：
https://www.ibm.com/developerworks/lotus/products/connections/

著者について

Zhang Zhi Hao has a Masters degree in Communication Engineering from Tongji University and has worked with the IBM China Development Lab since 2006. He is interested in RIA and portal development.

Jing Guo Yao is a Software Engineer at the IBM China Software Development Laboratory. His primary focus is test case automation of IBM Enterprise Content Management products. Jing Guo has a lot of experience with Rational Robot, Test Manager and Functional Tester. He has worked on numerous GUI and API test case automation projects. He can be reached by e-mail.

この記事を評価する

コメント

上に戻る

目次

• はじめに
• WAS 同期メカニズム
• 高速クラスター・デプロイメント
• 結論
• リソース
• 著者について
• コメント