Sun Java System Instant Messaging 7.2 管理ガイド

第 6 章サーバープールによる Instant Messaging 配備のスケーリング

サーバープールによって、数百万人のユーザーを単一ドメイン内でサポートできます。サーバープールを使えば、「サーバープール」内のいくつかのサーバー間で 1 つのドメインを共有できます。さらに、リダイレクトサーバーなどのロードバランサを使えば、プール内のサーバーの使用状況の管理が容易になります。この章では、サーバープールに関する情報を次の各節で提供します。

負荷分散やリダイレクトサーバーについては、第 7 章「リダイレクトサーバーによる Instant Messaging サーバープールの最適化」を参照してください。この章の手順は、Instant Messaging がサーバープール内のホスト上にすでにインストールされていることを前提にしています。さらに、サーバープール内の各ノードに Access Manager SDK をインストールし、単一のリモート Access Manager サーバーと通信するように SDK を設定する必要があります。

Instant Messaging のサーバープールの概要

サーバープールを作成すると、Instant Messaging 配備でサポート可能なユーザーの数が、単一のサーバーシステムの容量によって制約されることがなくなります。代わりに、数台のシステムのリソースを使って単一ドメイン内のユーザーをサポートできます。さらに、サーバープールは冗長性も提供するため、プール内のあるサーバーで障害が発生した場合、その影響を受けるクライアントはプール内の別のサーバー経由で再接続して、セッションを継続することができるため、不都合を最小限に抑えられます。1 つのサーバープール内で複数のサーバーを配備した場合、それは「複数ノード配備」となります。

サーバープールを作成するには、Instant Messaging サーバーがサーバー間ポートを介して通信し、同一の LDAP ディレクトリからユーザーデータを取得するように設定します。サーバーの設定が完了したら、ある単一ノードのホストとポートを指すようにではなく、ロードバランサつまり「ロードディレクタ」を指すようにクライアントリソースを設定する必要があります。

注意 –

ユーザープロパティーの格納場所として、LDAP ディレクトリの代わりに共有ファイルシステムを使用することも可能ですが、そうするとパフォーマンスや管理性に悪影響が及びます。このため、サーバープールでは LDAP ストレージのみがサポートされます。

サーバープール内のすべてのサーバーで一貫性のあるデータを持つことを保証するために、プール内のすべてのサーバー間で次の情報がレプリケートされます。

エンドユーザーのルーティング情報
会議室のメンバーシップと設定
マルチパーティー会議

次の情報はレプリケートされません。

1 対 1 のチャットメッセージ
Presence の登録と通知

さらに、配備内でアクセス制御ファイルからポリシーを適用している場合、そのアクセス制御ファイルの内容は、サーバープール内のすべてのサーバー間で同じでなければいけません。詳細は、「アクセス制御ファイルによるポリシー管理」を参照してください。

Instant Messaging サーバープール内での可用性

サーバープール内のあるノードが停止した場合、その時点で接続されていたすべてのクライアントの接続が切断され、セッションやリソースが利用できなくなります。ロードバランサを含めるように配備を設定した場合、ユーザーはすぐに再接続でき、ロードバランサによってプール内の別のノードに切り替えられます。そのように設定した場合、これらの情報はプール内のサーバー間で共有されるため、会議やニュースチャンネルを作成し直す必要はありません。さらに、プール内の別のノードへのユーザーの切り替えが行われたあと、1 対 1 のチャットセッションを継続することができます。

サーバープール内の Instant Messaging サーバー間におけるサーバー間通信の設定

この節では、サーバープール内の 2 つの Instant Messaging サーバー (これを仲間という意味で「ピア」サーバーと呼ぶ) 間の通信を有効にする方法を説明します。プール内のすべてのサーバーに、プール内のほかのすべてのサーバーに関する情報を設定する必要があります。

表 6–1 に、あるサーバープール内の 2 つの Instant Messaging サーバー例 iimA.siroe.com および iimB.siroe.com の通信を設定するために使用される、iim.conf 内のパラメータとその値の一覧を示します。

設定パラメータの詳細については、付録 A 「iim.conf の Instant Messaging の設定パラメータ」を参照してください。

表 6–1 サーバープール内の 2 つの Instant Messaging サーバーの設定情報の例


`iim.conf` 内のパラメータ	サーバー A の値	サーバー B の値	注
`iim_server.serverid`	`iimA.siroe.com`	`iimB.siroe.com`	サーバープール内では、この ID はダイアルバック機構をサポートするために使用され、認証用としては使用されません。この値は、サーバープール内で一意になるようにしてください。
`iim_server.password`	`secretforiimA`	`secret4iimB`
`iim_server.coservers`	`coserver1`	`coserver1`	各 Instant Messaging サーバーはそのシンボリック名で識別されます。サーバーのシンボリック名は、`iim.conf` 内の `iim_server.coservers` パラメータに追加します。このパラメータには、コンマで区切られた複数の値を含めることができます。
`iim_server.domainname`	`siroe.com`	`siroe.com`	サーバープール内のピアサーバーは同一のデフォルトドメインを共有します。
`iim_server.coserver1.host`	`iimB.siroe.com:5269`	`iimA.siroe.com:5269`	サーバープール内のピアサーバーのホスト名とポート番号。
`iim_server.coserver1.serverid`	`iimB.siroe.com`	`iimA.siroe.com`	サーバープール内のピアサーバーのサーバー ID (`iim_server.serverid`)。
`iim_server.coserver1.password`	`secret4iimB`	`secretforiimA`	サーバープール内のピアサーバーのパスワード (`iim_server.password`)。
`iim_server.coserver1.domain`	`siroe.com`	`siroe.com`	サーバープール内のピアサーバーは同一のデフォルトドメインを共有します。

サーバープール内の 2 つの Instant Messaging サーバー間における通信を設定する

表 6–1 に記載された情報を収集します。

サーバー iimA.siroe.com 上で im-cfg-base に移動します。

im-cfg-base を特定する手順については、「Instant Messaging サーバーのディレクトリ構造」を参照してください。

iim.conf を開きます。

iim.conf の場所、およびこのファイルを変更する手順については、付録 A 「iim.conf の Instant Messaging の設定パラメータ」を参照してください。

注 –
iim.conf ファイルの所有者は、インストール時に作成した Instant Messaging サーバーアカウントでなければなりません。iim.conf ファイルを Instant Messaging サーバーアカウントで読みとれなければ、サーバーとマルチプレクサは設定ファイルを読み取れません。さらに、iim.conf を編集できなくなる可能性もあります。

配備に合わせてパラメータ値を変更します。

表 6–1 に、変更する必要のあるパラメータの一覧を示します。iim.conf 内に存在していないパラメータは、追加します。次の例は、iimA.siroe.com 上の iim.conf 内の、変更する必要のあるサーバー間通信に対応する部分を示したものです。

iim_server.serverid=iimA.siroe.com
iim_server.password=secretforiimA
iim_server.domainname=siroe.com
iim_server.coservers=coserver1
iim_server.coserver1.host=iimB.siroe.com:5269
iim_server.coserver1.serverid=iimB.siroe.com
iim_server.coserver1.password=secret4iimB
iim_server.coserver1.domain=siroe.com

サーバー iimB.siroe.com 上の iim.conf ファイルについては、手順 2 から 4 に従います。

次の例は、iimB.siroe.com 上の iim.conf 内の、変更する必要のあるサーバー間通信に対応する部分を示したものです。

iim_server.serverid=iimB.siroe.com
iim_server.password=secret4iimB
iim_server.domainname=siroe.com
iim_server.coservers=coserver1
iim_server.coserver1.host=iimA.siroe.com:5269
iim_server.coserver1.serverid=iimA.siroe.com
iim_server.coserver1.password=secretforiimA
iim_server.coserver1.domain=siroe.com

変更を保存し、iim.conf を閉じます。

両方のサーバー上で設定を更新します。
imadmin refresh server

既存の Instant Messaging 配備への新しいノードの追加

既存のサーバープールに新しいノードを追加する必要がある場合、その新しいサーバーをサーバー間通信を行えるように設定したあと、その新しいサーバーに関する設定情報を、プール内の既存のすべてのサーバーに追加する必要があります。さらに、プール内のすべてのサーバーに関する設定情報を、新しいノードに追加する必要があります。手順については、「サーバープール内の 2 つの Instant Messaging サーバー間における通信を設定する」を参照してください。

複数ノード配備のセキュリティー保護

あるノードがリモートサーバーに接続したとき、そのノードは「ダイアルバックキー」を提示します。すると、リモートサーバーは、ダイアルバックキーを確認するためにそのノードに接続し直します。複数ノード配備では、ダイアルバックキーを最初に送信したノードとは異なるプール内のノードに、リモートサーバーが接続し直す可能性があります。リモートサーバーが接続するノードは、最初の接続ノードが提供したものと同じダイアルバックキーを提示する必要があります。iim_server.dialback key 設定パラメータは、ノードが使用すべきダイアルバックキーを定義します。ダイアルバックキーの値は、ユーザーが明示的に指定しないかぎり、ランダムに生成されます。手順については、「サーバープール内の Instant Messaging サーバーのダイアルバックキーを手動で定義する」を参照してください。

From 属性は、リモートサーバーが起動元サーバーに接続し直す際に使用されます。通常、Jabber に基づいたサーバー間通信では、From 属性の値としてサーバーのドメイン名が使用されます。しかし、サーバープール内のサーバーはすべて、同じドメイン名を共有します。したがって、ドメイン名は、プール内の単一のサーバーを特定するキーとして使用できません。Instant Messaging は、ドメイン名ではなくサーバーまたはピアの識別子 (serverid) を、From 属性の値として使用します。

サーバープール内の Instant Messaging サーバーのダイアルバックキーを手動で定義する

ダイアルバックキーの値は、ユーザーが明示的に指定しないかぎり、ランダムに生成されます。

iim.conf を開きます。

iim.conf の場所、およびこのファイルを変更する手順については、「iim.conf ファイルの構文」を参照してください。

iim_server.dialback.key パラメータの値を変更します。

たとえば、次のように入力します。
iim_server.dialback.key=mymultinodedialbackkey

変更を保存し、iim.conf を閉じます。

両方のサーバー上で設定を更新します。
imadmin refresh server

第 6 章 サーバープールによる Instant Messaging 配備のスケーリング