第 7 章 リダイレクトサーバーによる Instant Messaging サーバープールの最適化

サーバープール (複数ノード配備) 内のサーバーの負荷分散を行うには、Instant Messaging に付属するリダイレクトサービスを使用します。単一配備内のサーバー間で必要とされる通信量がパフォーマンスに直接的な影響を与えるため、Presence 情報やメッセージを共有する可能性の高い 2 人のユーザーが最終的に同一ノード上に存在する確率を高めれば、パフォーマンスが改善されます。

この章では、Instant Messaging リダイレクトサーバーの使用方法について、次の各節で説明します。

• 「Instant Messaging リダイレクトの概要」

• 「Instant Messaging サーバーインスタンスをリダイレクトサーバーとして設定する」

• 「Instant Messaging リダイレクトサーバーの管理」

• 「rdadmin ユーティリティーによる Instant Messaging リダイレクトテーブルの作成と管理」

• 「Instant Messaging リダイレクトサーバーによる物理ホストの監視」

• 「Instant Messaging リダイレクトサーバーのベストプラクティスとトラブルシューティング」

Instant Messaging リダイレクトの概要

リダイレクトサーバーとは、Instant Messaging サーバーへの接続エンドポイントの割り当てなどの、リダイレクトタスクのみを実行するように特に設定された Instant Messaging サーバーインスタンスのことです。配備にリダイレクトサーバーを追加すると、互いに通信する可能性の高いユーザーが同一ホスト上にまとめられるため、サーバー間の通信量が減ります。これにより、配備内のサーバー間で送受信される Presence 通知の量が減ります。ユーザーのグループは連絡先一覧の内容によって決まります。連絡先一覧内のエントリが共有されていれば、通信が行われる可能性も高くなります。

Instant Messaging ユーザーパーティション分割アルゴリズム

Instant Messaging は、配備内のユーザーの最適な分割方法を決定し、ユーザーのグループ、つまりパーティションを作成します。Instant Messaging が使用するアルゴリズムは、次のとおりです。

1. 配備内で 1 つ以上のユーザーセット、つまりユーザーネットワークと、それらの接続関係を決定します。次に、リダイレクトサーバーは各ユーザーをユーザーネットワークにマップするためのユーザー - ネットワーク間のマップと呼ばれるテーブルを作成します。

2. 最大パーティションサイズよりも大きいユーザーネットワークが存在する場合、それらをもっとも弱い結合のところでパーティション分割します。このとき、分割後の各コンポーネントの最大サイズが設定されたパーティションサイズよりも大きくならないように留意します。分割する箇所として弱い結合を特定する際には、ユーザーネットワーク間で接続の数が少ない箇所を特定することが決め手の一つになるかもしれません。ただし、地理的な制約、ユーザーネットワークごとの接続数、管理者によって設定されたその他の制約といったほかのパラメータも、ユーザーネットワークのパーティション分割時に考慮されることがあります。

3. これらのセットを、指定された数のほぼ同じサイズのパーティションに分配します。リダイレクトサーバーは、まずネットワーク - パーティション間テーブルをこのプロセスの一部として作成し、最後にユーザー - パーティション間テーブルを作成します。これらのテーブルをまとめたものが、リダイレクトデータベースです。リダイレクトデータベースは、各ユーザーを 1 つのパーティション ID にマップします。このデータベースを作成および管理するには、rdadmin コマンド行ユーティリティーを使用します。

例 7–1 Instant Messaging リダイレクトのイベントシーケンス

この例では、正常なクライアントリダイレクトが行われる場合のイベントシーケンスについて説明します。

1. 管理者が、rdadmin を実行することで、リダイレクトデータベースの生成または更新、あるいはその両方を行います。

2. ユーザーがリダイレクトサーバーに接続し、認証を試みます。

3. リダイレクトサーバーが、そのユーザーのアイデンティティーを決定し、対応するユーザー ID をリダイレクトデータベース内で検索します。

4. リダイレクトデータベース内でそのユーザー ID が見つからない場合、リダイレクトサーバーは (ラウンドロビン機構で決定される) 次のリダイレクトサーバーにアクセスし、そのユーザー ID を含むリダイレクトデータベースを探します。そのユーザー ID がリダイレクトデータベース内で見つかった場合、リダイレクトサーバーはそのユーザーが割り当てられているパーティション ID を取得します。

5. リダイレクトサーバーが、ユーザーのリダイレクト先となるノードを、割り当てられたパーティション ID に基づいて決定します。

6. リダイレクトサーバーは、リダイレクト先のノードを含むエラーをクライアントに返し、クライアントへの接続を閉じます。

   リダイレクトサーバーは、see-other-host ストリームエラーを使ってこの情報をクライアントに返します。詳細は、RFC 3920 を参照してください。

7. クライアントがそのエラーを解釈し、そのエラーが返されたノードへの接続を確立します。

8. リダイレクトサーバーはノードを継続的に監視し、そのパーティションからホストへのテーブルを必要に応じて更新します。

Instant Messaging リダイレクトデータベースについて

このデータベースにはローカルユーザーしか含まれません。ゲートウェイ、コンポーネント、およびリモートユーザーはリダイレクトデータベースに含まれません。

Instant Messaging リダイレクトサーバーの概要

リダイレクトサーバーとは、クライアント接続のリダイレクトを唯一の機能として持つ、Instant Messaging サーバーのインスタンスのことです。リダイレクトサーバーは、エンドユーザーに対してその他のサービスは何も実行しません。リダイレクトサーバーは起動時に、サーバー設定とパーティションファイルを読み込み、次のデータ構造を作成します。

• このサーバーがクライアント接続のリダイレクト先として使用できるインスタンスのリスト。これが、リダイレクトサーバーのインスタンスリストです。インスタンスリストは、redirect.hosts ファイルのエントリに基づいて構築されます。

• パーティションを物理ホストにマップするテーブル。このテーブルは「パーティションマップ」と呼ばれます。リダイレクトサーバーは、指定された最大パーティション数に達するまでインスタンスリスト内で検索を行うことで、パーティションマップを構築します。

リダイレクトサーバーは、この両方のデータ構造を使ってクライアント接続のリダイレクトを行います。リダイレクトサーバーがこの情報をどのように使用するかについては、例 7–1 を参照してください。

Instant Messaging リダイレクトサーバーと StartTLS

接続しようとしているクライアントのアイデンティティーを確立するのに必要とされるだけの StartTLS ネゴシエーションが、クライアントとリダイレクトサーバー間で行われる可能性があります。クライアントが資格を確認する必要はありません。必要とされるのはユーザー ID だけです。

Instant Messaging サーバーインスタンスをリダイレクトサーバーとして設定する

サーバーインスタンスがリダイレクトサーバーであることを指定するには、iim.conf 内で iim_server.redirect.provider パラメータの値を指定する必要があります。そのインスタンスをリダイレクトサーバーとして指定したら、詳細な設定情報を提供するために、リダイレクト固有の追加パラメータの値を iim.conf 内で指定する必要があります。表 7–1 では、リダイレクト設定パラメータについて説明します。

Instant Messaging サーバーをリダイレクトサーバーとして設定する

始める前に

2006Q1 より古いバージョンの Instant Messenger をリダイレクトサーバーとともに使用することはできません。他社製のクライアントを使用する場合、そのクライアントが XMPP リダイレクションをサポートしていることを確認してください。

1. 上の表 7–1 に記載された情報を収集します。

2. iim.conf を開きます。

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

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

   表 7–1 に、値を指定する必要のあるパラメータを示しています。iim.conf 内に存在しないパラメータは、追加します。次の例は、iim.siroe.com 上の iim.conf 内の、変更する必要のあるリダイレクトサーバーパラメータに対応する部分を示したものです。

   iim_server.redirect.provider=db,roundrobin iim_server.redirect.to=imserverA,imserverB iim_server.redirect.to.imserverA.host=iimA.siroe.com iim_server.redirect.to.imserverB.host=iimB.siroe.com iim_server.redirect.to.imserverA.usessl=false iim_server.redirect.to.imserverB.usessl=false

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

5. リダイレクトサーバー上で設定を更新します。

   imadmin refresh server

6. マルチプレクサではなくリダイレクトサーバーに接続するように、クライアントを設定します。

Instant Messaging リダイレクトサーバーの管理

次の各節では、Instant Messaging リダイレクトサーバーの管理について説明します。

• 「Instant Messaging リダイレクトサーバーの停止、起動、再起動、更新、およびステータス確認」

• 「Instant Messaging リダイレクトサーバーのロギング」

• 「Instant Messaging リダイレクトサーバーのパーティションサイズの設定」

• 「Instant Messaging リダイレクトサーバーのパーティションリストの指定」

Instant Messaging リダイレクトサーバーの停止、起動、再起動、更新、およびステータス確認

リダイレクトサーバーとは、リダイレクトのみを行うように設定された Instant Messaging サーバーインスタンスのことです。通常のサーバーインスタンスで使用するものと同じ停止、起動、再起動、更新、およびステータス確認手順を使用してください。たとえば、リダイレクトサーバーを起動するには、次のように入力します。

imadmin start server

詳細は、「Instant Messaging コンポーネントの停止、起動、更新、および確認」を参照してください。

Instant Messaging リダイレクトサーバーのロギング

リダイレクトサーバーとは、リダイレクトのみを行うように設定された Instant Messaging サーバーインスタンスのことです。通常のサーバーインスタンスで使用するものと同じ手順やログを使用してください。詳細は、第 13 章「Instant Messaging のロギングの管理」を参照してください。

Instant Messaging リダイレクトサーバーのパーティションサイズの設定

最大パーティションサイズを指定するには、iim.conf の iim_server.redirect.db.partitionsize パラメータを設定します。このパラメータの値は、1 つのパーティションで許可されるユーザー数に等しくなります。デフォルトは 5000 (ユーザー) です。

Instant Messaging リダイレクトサーバーのパーティションリストの指定

redirect.partitions ファイルには、ある特定のパーティション内のユーザーのリダイレクト先となる主ノードと、必要に応じて一連の代替ノードを定義します。ファイル内の空行でもコメント行でもない行にはそれぞれ、パーティションのノードリストを定義します。リスト内の各ノードは、iim.conf 内の iim_server.redirect.to パラメータの値として定義されたノードに対応している必要があります。定義されたパーティションの数が redirect.partitions ファイル内の行数よりも多い場合、指定されていないパーティションはラウンドロビン方式で処理されます。

redirect.partitions ファイルはデフォルトで次の場所に格納されます。

im-cfg-base/redirect.partitions

例 7–2 redirect.partitions ファイルの設定

この redirect.partitions ファイル例の前提条件は、次のとおりです。

• リダイレクトサーバーが db および roundrobin 検索用に設定されている。

• クライアントのリダイレクト先として、次の 3 つのノードが特定されている。

  • imserverA

  • imserverB

  • imserverC

• これら 3 つのノードは次のホストに対応している。

  • iimA.siroe.com

  • iimB.siroe.com

  • iimC.siroe.com.

  これは、iim.conf では次のように表現されます。

  iim_server.redirect.provider=db,roundrobin iim_server.redirect.to=imserverA,imserverB, imserverC iim_server.redirect.to.imserverA.host=iimA.siroe.com iim_server.redirect.to.imserverB.host=iimB.siroe.com iim_server.redirect.to.imserverC.host=iimC.siroe.com

• ユーザーパーティションが少なくとも 2 つ存在する。

このシナリオでは、たとえば、redirect.partitions を次のように設定できます。

imserverA, imserverB, imserverC
imserverB, imserverC

空行でもコメント行でもない行が 2 行ありますが、これは、ユーザーパーティションが少なくとも 2 つ存在することを示しています。1 行目はパーティション 1 のリダイレクト動作を定義しています。リダイレクトサーバーは、パーティション 1 のユーザーをまず imserverA にリダイレクトします。それが失敗すると、リダイレクトサーバーは imserverB、imserverC の順にリダイレクトを試みます。正常に動作しているノードが存在しない場合、リダイレクトサーバーはクライアントにエラーを返します。

rdadmin ユーティリティーによる Instant Messaging リダイレクトテーブルの作成と管理

通常、rdadmin ユーティリティーは必要に応じて使用します。名簿の変更は一般にそれほど大量には発生しないため、このテーブルを頻繁に生成し直す必要はありません。とはいえ、少なくとも 2 週間に一度はこのユーティリティーを実行するようにしてください。

新しい Instant Messaging リダイレクトデータベースを作成するか、既存のデータベースを更新する

1. リダイレクトサーバーを停止します。

   imadmin stop redirect

2. 既存のリダイレクトデータベースを更新する場合、rdadmin によって以前に作成されたパーティションの数を取得します。

   1. テキストエディタで rdadmin.log を開きます。

      rdadmin.log ファイルの格納場所は次のとおりです。

      im-runtime-base/log

   2. 「NO OF PARTITIONS RUN」の値を探します。

3. 少なくともパーティションと同じ数のユーザーエントリが存在していることを確認します。

4. 新しいリダイレクトデータベースを生成します。

   たとえば、次のように入力します。

   rdadmin generate

   その他の rdadmin オプションについては、rdadmin の man ページを参照してください。

   rdadmin ユーティリティーは新しいデータベースを作成し、別の名前が指定されないかぎり、それを im-db-base/redirect.new.db として保存します。

5. リダイレクトデータベースを初めて生成している場合には、データベースの名前を redirect.db に変更します。

6. 既存のリダイレクトデータベースを更新する場合には、古いリダイレクトデータベースを新しいデータベースで置き換えます。

   たとえば、次のように入力します。

   rm im-db-base/redirect.db cp im-db-base/redirect.new.db im-db-base/redirect.db

7. リダイレクトサーバーを起動します。

   imadmin start redirect

Instant Messaging リダイレクトサーバーによる物理ホストの監視

リダイレクトサーバーは、クライアントのリダイレクト先となるホストの動作ステータスを監視します。リダイレクトサーバーは、ホストのいずれかで障害が発生したと判断すると、redirect.partitions ファイル内に定義された後続のホストにパーティションを割り当て直します。さらに、リダイレクトサーバーはオンライン状態に復帰したホストを検出するので、その復帰したホストにパーティションをリダイレクトし直すことができます。リダイレクトサーバーがホストを監視する方法には、次の 2 つがあります。

• 定期的なポーリング: リダイレクトサーバーは、iim.conf 内の iim_server.redirect.pollfrequency パラメータに指定された間隔で、接続を確立して XMPP ストリームを開きます。

• クライアントの再試行の監視: リダイレクトサーバーは、単一のクライアントが短期間に繰り返し、接続を試みていることを検出すると、そのホストが正しく動作していないと判断することがあります。

Instant Messaging リダイレクトサーバーのホストポーリング頻度の設定

1. リダイレクトサーバー上で iim.conf を開きます。

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

2. iim_server.redirect.pollfrequency パラメータを設定します。

   この値の単位は「分」です。たとえば、次のように入力します。

   iim_server.redirect.pollfrequency=200

3. iim.conf を保存して閉じます。

4. リダイレクトサーバーを更新します。

   imadmin refresh server

Instant Messaging リダイレクトサーバーのベストプラクティスとトラブルシューティング

次の各節では、Instant Messaging リダイレクトサーバー使用時のベストプラクティスとトラブルシューティング情報について説明します。

• 「リダイレクトサーバーの証明書」

• 「Instant Messaging リダイレクトサーバーがサポートするクライアント」

• 「リダイレクトサーバーの使用と LDAP へのユーザープロパティーの格納」

• 「リダイレクトデータベースのパーティションサイズの決定」

• 「リダイレクトサーバーのパーティションホストとしての使用」

リダイレクトサーバーの証明書

証明書を使って認証のセキュリティー保護を行うような配備では、クライアントは接続するたびに 2 つの証明書 (リダイレクトサーバー用の証明書とクライアントのリダイレクト先となるホスト用の証明書) の同意を要求される可能性があります。同意の要求が行われないようにするには、信頼できる証明書を使用するか、同じ証明書を両方のサーバー上で使用します。

Instant Messaging リダイレクトサーバーがサポートするクライアント

RFC 3920 をサポートしないクライアント、および特に see-other-hosts ストリームエラー (XMPP リダイレクト) をサポートしないクライアントでは、リダイレクトが正しく動作しません。Instant Messenger 2006Q1 以降では、リダイレクトサーバーとともに使用できます。他社製のクライアントを使用する場合、そのクライアントが XMPP リダイレクションをサポートしていることを確認してください。

リダイレクトサーバーの使用と LDAP へのユーザープロパティーの格納

LDAP を使ってユーザープロパティーを格納する場合 (iim.userprops.store=ldap)、iim_ldap.usergroupbinddn と iim_ldap.usergroupbindcred の値が、ディレクトリマネージャーレベルのディレクトリアクセス権を持っていることを確認する必要があります。

リダイレクトデータベースのパーティションサイズの決定

ユーザーネットワークを可能なかぎり分割しないですむように、パーティションサイズはできるだけ大きくするようにしてください。ただし、同時にパーティションは、もっとも小さいシステムでサポート可能なサイズよりも大きくならないようにしてください。

リダイレクトサーバーのパーティションホストとしての使用

あるリダイレクトサーバーに 1 つ以上のパーティションのホストも行わせることができます。それには、そのリダイレクトサーバーインスタンスを redirect.partitions ファイル内に指定するか、iim_server.redirect.to パラメータの値として指定します。ただし、複数のリダイレクトサーバーをパーティションホストにすべきではありません。なぜなら、同期が取れていない redirect.partitions ファイルによってリダイレクションループが発生する可能性があるからです。