test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

パート IV Instant Messaging の配備

この部には、次の章があります。

第 21 章 Instant Messaging ソフトウェアの紹介

Instant Messaging では、チャット、会議室、アラート、ニュース、ポーリング、ファイル転送などのインスタントメッセージング機能と在席確認機能とを組み合わせることで豊かな共同作業環境を形成し、セキュリティー保護された、リアルタイムの通信や共同作業を行えます。これらの機能は、グループによる共同作業だけでなく 1 対 1 にも対応し、短期間の通信のほか、会議室やニュースチャネルなどの持続的な場の利用を可能にします。

Instant Messaging では、複数の認証メカニズムと SSL (Secure Sockets Layer) 接続を使用することで、通信の整合性が保たれます。Portal Server と Access Manager との統合によって、さらなるセキュリティー機能、サービスベースのプロビジョニングアクセスポリシー、ユーザー管理、セキュリティー保護されたリモートアクセスが可能になります。

この章には、次の節があります。

Instant Messaging サービスとは

インスタントメッセージングサービスの単純化した段階は次のとおりです。

さらに、Instant Messaging サービスはリアルタイムの会議室、ニュース、およびカレンダアラート機能を提供し、オフラインユーザーには電子メールメッセージの転送機能を提供します。

優れた Instant Messaging サービスには、スケーラビリティー、高可用性、信頼性、および良好なパフォーマンスの実現が不可欠です。

Instant Messaging コア製品コンポーネント

Instant Messaging には、次のコアコンポーネントが含まれています。

Instant Messaging の関連コンポーネント

この節で説明するソフトウェアコンポーネントは Instant Messenger サーバーで使用されますが、インストールは個別に行われます。これらのサーバーと Instant Messenger の詳細なやり取りについては、第 23 章「Instant Messaging アーキテクチャーの開発」を参照してください。

Web サーバー

(必須) どのような配備においても、Sun Java System Web Server や Sun Java System Application Server などの Web サーバーをインストールする必要があります。また、Apache などのオープン標準に準拠した Web サーバーを使用することもできます。いずれの場合も、Instant Messenger リソースは Web サーバーホストに存在する必要があります。

Instant Messaging では、Web サーバーが Instant Messenger リソースを処理します。Instant Messenger リソースには次のものが存在します。

Instant Messenger リソースは、Web サーバーと同じホストにインストールする必要があります。Access Manager の配備では、これらのリソースを Access Manager のホスト、または別の Web サーバーホストにインストールできます。多くの場合、リソースは Instant Messaging サーバーソフトウェアと同じホストにインストールされます。ただし、Instant Messenger リソースを Instant Messaging サーバーまたはマルチプレクサと別のホストに置くこともできます。

注 –

Instant Messaging を設定する前に Web サーバーをインストールしてください。

LDAP サーバー

(必須) Instant Messaging は、エンドユーザーの認証と検索に Directory Server などの LDAP サーバーを使用します。Portal Server を実装する配備では、Instant Messaging は Portal Server と同じ LDAP サーバーを使用します。LDAP ディレクトリがまだインストールされていない場合は、インストールする必要があります。

Instant Messaging サーバーには Instant Messenger のエンドユーザー認証情報は格納されません。この情報は LDAP サーバーに格納されます。

デフォルトでは、エンドユーザーとグループ情報の検索に Instant Messaging サーバーは共通エンドユーザー属性 cn および uid を使用します。サーバーが別の属性を使用して検索を行うように設定することもできます。また、連絡先リストやその登録情報などの Instant Messaging のプロパティーは、Instant Messaging サーバー上のファイル、または LDAP サーバーに格納できます。

デフォルト以外の属性を使用してユーザー検索を行うようにサーバーを設定する方法については、『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』を参照してください。

注 –

Instant Messaging の配備を成功させるには適切な Directory Server 実装が前提となるため、このマニュアルのほかに『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』も参照してください。

SMTP サーバー

(省略可能) インスタントメッセージを電子メールとしてオフラインのエンドユーザーに送信するときは、Messaging Server などの SMTP メッセージングサーバーが使用されます。SMTP サーバーは、Instant Messaging サーバーと同じホスト上に存在する必要はありません。

Calendar Server

(省略可能) カレンダベースの予定をユーザーに通知するときは、Calendar Server が使用されます。

Access Manager と Access Manager SDK

(省略可能) Access Manager と Access Manager SDK は、エンドユーザーとサービスの管理に認証サービスとシングルサインオンサービスを提供します。さらに、Portal Server を含む配備では、Access Manager と Access Manager SDK が必須となります。どちらの配備でも、Instant Messaging サーバーと同じホストに SDK をインストールする必要があります。

Portal Server

(省略可能) Portal Server は、メッセージアーカイブをサポートし、Instant Messaging をセキュリティー保護されたモードで実行できるようにします。また、Portal Server デスクトップによりエンドユーザーは Instant Messenger クライアントを利用することができます。次の 2 つの Portal Server コンポーネントは追加機能を提供します。

Portal Server デスクトップ

Portal Server 環境にインストールした Instant Messenger は、Portal Server デスクトップのエンドユーザーが使用できる Instant Messaging チャネルから起動できます。

Secure Remote Access

Secure Remote Access を使えば、リモートエンドユーザーは所属する組織のネットワークとサービスに、インターネット経由で安全にアクセスできます。エンドユーザーは、ポータルゲートウェイ経由で Web ベースの Portal Server デスクトップにログインし、Secure Remote Access にアクセスします。Portal Server に設定された認証モジュールで、エンドユーザーが認証されます。エンドユーザーのセッションが Portal Server との間で確立されると、エンドユーザーの Portal Server Desktop へのアクセスが有効になります。

Portal Server 環境では、Instant Messenger をセキュリティー保護されたモードにも、セキュリティー保護されていないモードにも設定できます。セキュリティー保護されたモードでは、通信内容は Portal Server の Netlet によって暗号化されます。セキュリティー保護されたモードで Instant Messenger にアクセスすると、Instant Messenger の「状態」領域に鍵のアイコンが表示されます。セキュリティー保護されていないモードでは、Instant Messenger セッションは暗号化されません。Netlet の詳細については、『Sun Java System Portal Server 6 2005Q4 Secure Remote Access 管理ガイド』を参照してください。

Instant Messaging でサポートされている標準

Instant Messaging はネイティブのインターネットテクノロジに対応しているので、顧客やパートナー企業と共同作業を行う場合でも、組織の内外をまとめて 1 つのアーキテクチャーとして維持することができます。また、特定のシステムに束縛されることもありません。Instant Messaging の主要コンポーネントは、すでに定着しているオープンなインターネット標準に基づいています。次に、代表的な標準を示します。

インスタントメッセージの構造フォーマット

インスタントメッセージのフォーマットとしては、XMPP プロトコルが使用されます。メッセージの本文自体は HTML 内に格納できます。

アクセスプロトコル

Instant Messaging では、ユーザーの情報と設定は LDAP ディレクトリから取得されます。このディレクトリは、Instant Messaging 専用でもかまいませんし、Access Manager や Portal Server など、ほかのコンポーネントと共用でもかまいません。ユーザーデータは通常は LDAP 検索機能によって取得されます。Access Manager と Portal Server を使用する Instant Messaging 配備では、同一の LDAP サーバーが使用されます。

通信プロトコルとメッセージ転送プロトコル

Instant Messaging のサーバー対サーバーおよびクライアント対サーバーの通信は、TCP/IP を通じて行われます。

Instant Messaging は、SMTP を使ってオフラインユーザーにメッセージを送信します。

ブラウザは、Web サーバーからの Instant Messenger リソースファイルの取得に HTTP を使用します。ブラウザは、取得したリソースファイルから HTML を読み取り、ファイルのコンテンツを表示します。

Instant Messaging 7 は、XMPP (Jabber) 対応のクライアントサーバーソリューションであり、XMPP に準拠したサーバー、クライアント、およびゲートウェイと通信を行えます。オープンソースコミュニティーでゲートウェイが利用でき、Jabber と AOL や Yahoo、およびその他の Instant Messaging システムとの通信が可能です。

Instant Messaging のソフトウェアアーキテクチャー

図 21–1 は、Instant Messaging ソフトウェアアーキテクチャーを示しています。

図 21–1 Instant Messaging のソフトウェアアーキテクチャー

この図は、Instant Messaging のコンポーネント間の関係を示しています。

Web サーバー (または Web サービスが組み込まれたアプリケーションサーバー) は、ブラウザ経由でクライアントに Instant Messaging リソースをダウンロードします。クライアントはリソースファイルから構成されます。クライアントは、Instant Messaging サーバーにメッセージを転送するマルチプレクサを通じて相互にメッセージを送信します。

ディレクトリサーバーは、設定情報、位置、メッセージのルーティング先マルチプレクサなどの、ユーザーおよびグループの配信情報を格納、取得します。Instant Messaging サーバーがメッセージを受信すると、Directory Server は、この情報を使用してメッセージの配信場所と配信方法を決定します。また、連絡先リストやその登録情報などのユーザー情報がディレクトリサーバーに格納されることもあります。

この基本的な設定によって、Instant Messaging は直接 Directory Server にアクセスし、Instant Messaging を使用するメールクライアントのユーザーログイン名とパスワードを検証します。

クライアントから送信されるインスタントメッセージは、直接マルチプレクサにルーティングされます。マルチプレクサは、該当する Instant Messaging サーバーにメッセージを送信し、順に別の Instant Messaging サーバーにメッセージを転送するか、またはメッセージがローカルの場合は受信者が関連するマルチプレクサにメッセージを転送します。この処理の図については、「Instant Messaging の物理的な配備例」を参照してください。

新規ユーザーを作成するときは、ディレクトリにユーザーエントリを追加します。ディレクトリ内のエントリを作成または変更するときは、Directory Server に付属するツールを使用します。

Instant Messaging コンポーネントの管理には、一連のコマンド行インタフェースとテキストベースの設定ファイルを使用します。管理者が必要な権限を持っている場合は、Instant Messaging ホストに接続された任意のマシンで管理タスクを実行することができます。

注 –

Instant Messaging 配備は通常、単一マシン上にはインストールされません。また、そうした配備には、多重化や高可用性化などの追加機能も搭載されます。詳細については、第 23 章「Instant Messaging アーキテクチャーの開発」を参照してください。

次に、Instant Messaging の 3 つの主要コンポーネントについて、さらに詳しく説明します。

Instant Messaging Server

Instant Messaging サーバーは、Instant Messenger の権限やセキュリティーの制御、アラートの送信による Instant Messenger クライアントどうしの通信の実現、チャットの開始、および使用可能なニュースチャネルへのメッセージの投稿などのタスクを処理します。また、Instant Messaging サーバーは、アーカイブ、カレンダアラート、およびオフライン電子メール通知も処理します。

Instant Messaging は、接続を 1 つのソケットに統合するマルチプレクサの接続をサポートしています。マルチプレクサについては、「Instant Messaging マルチプレクサ」を参照してください。

エンドユーザー、ニュースチャネル、および会議室の管理には、アクセス制御ファイルと Access Manager ポリシーが使用されます。

Instant Messaging サーバーは、Instant Messaging 製品のインスタントメッセージをルーティング、転送、配信します。

LDAP 直接検索

サーバーは、LDAP サーバーの情報を直接検索できます。LDAP クエリの結果は、事前に設定可能な有効期限に達するまでプロセスにキャッシュされます。詳細については、『Sun Java System Directory Server 5 2005Q1 Administration Guide』を参照してください。

メッセージ配信

サーバーは、作成されたメッセージをメッセージ配信経路の次の配信先に送信します。送信先は、受信者のマルチプレクサまたは別のサーバーです。マルチプレクサが受信すると、メッセージは適切な受信者に直接ルーティングされます。この処理の図については、「Instant Messaging の基本アーキテクチャー」を参照してください。

Instant Messaging マルチプレクサ

Instant Messaging マルチプレクサコンポーネントは、複数のインスタントメッセンジャー接続を 1 つの TCP (Transmission Control Protocol) 接続にまとめ、この TCP 接続を Instant Messaging サーバーに接続します。マルチプレクサは Instant Messenger からのデータを読み取り、それをサーバーに書き込みます。反対に、サーバーが Instant Messenger にデータを送信すると、マルチプレクサはそのデータを読み取り、適切な接続にそれを書き込みます。マルチプレクサは、エンドユーザーの認証やクライアントサーバー間のプロトコル (IM プロトコル) 解析は行いません。各マルチプレクサは、1 つの Instant Messaging サーバーにだけ接続されます。

Instant Messaging マルチプレクサは、必ずしもインストールする必要はありません。つまり、マルチプレクサを使用しない Instant Messaging 構成にすることも可能です。ただし、本稼働配備ではマルチプレクサを使用する構成にすることをお勧めします。

配備環境の要件に応じて、複数のマルチプレクサをインストールできます。詳細については、第 23 章「Instant Messaging アーキテクチャーの開発」を参照してください。

Instant Messenger クライアント

Instant Messenger は、Java プラグインを使用してブラウザベースのアプレットとして設定したり、JavaTM Web Start を使用してスタンドアロンの Java アプリケーションとして設定したりできる Instant Messaging のクライアントです。

Solaris または Linux 上で Instant Messenger クライアントを実行するには、Java Web Start を使用する必要があります。Microsoft Windows では、アプレットまたは Java Web Start アプリケーションとして Instant Messenger を実行できます。ほとんどの場合、Java Web Start アプリケーションとして Instant Messenger を実行します。

Instant Messenger のカスタマイズについては、『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』を参照してください。

Instant Messenger には、次の通信モードがあります。

注 –

インスタントメッセージには URL を埋め込むことができます。プロキシサーバーを使用している場合は、このような URL を解決できるように、Java Web Start を使用するクライアントでプロキシ設定の修正が必要になることがあります。

プロキシ設定の手動変更については、『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』を参照してください。

Instant Messaging 配備の設計

配備プロセスは、次の基本フェーズから構成されており、ソリューションライフサイクルと呼ばれます。

配備フェーズは固定的なものではなく、配備プロセスは反復して行われます。

Instant Messaging やその他の Java Enterprise System コンポーネントの配備プロセスの詳細については、『Sun Java Enterprise System 2005Q4 Deployment Planning Guide』を参照してください。

第 22 章 Instant Messaging サイズ決定戦略の計画

この章では、Instant Messaging 配備のサイズ決定に関する概念、背景、および理論的根拠を紹介します。

この章には、次の節があります。

Instant Messaging サイズ決定戦略の概要

配備を計画する場合には、Instant Messaging サーバーの設定方法を検討して、パフォーマンス、スケーラビリティー、および信頼性を最適化する必要があります。

サイズ決定はそうした設計作業の重要な要素の 1 つです。サイズ決定のプロセスを実行することで、Instant Messaging サーバーユーザーへの作業負荷の見積もりを踏まえた、希望するレベルのサービスまたは応答時間を実現するために必要となるハードウェアとソフトウェアを確認できます。サイズ決定は反復的な作業です。

配備にはそれぞれに固有の特徴があるため、この章では特定のサイトに関する Instant Messaging サイズ決定情報の詳細な説明はしていません。また、この章では、LDAP や SMTP など、Instant Messaging と連携して動作するサーバーに対するサイズ決定情報も提供しません。代わりにここでは、サイズ決定計画を構築する場合には何を考慮しなければならないのかを説明します。また、Instant Messaging コンポーネントに関する一般的なガイドラインも提示します。このガイドラインは、ユーザーのサイトのニーズに合わせて変更してかまいません。配備のハードウェアとソフトウェアのニーズを決定する場合には、ご購入先のテクニカルサポート担当者と共に作業を行なってください。

Instant Messaging サイズ決定データの収集

この節の説明を読んで、Instant Messaging のサイズ決定に必要なデータを確認してください。この節には、次の項目があります。

一意 Instant Messaging ログインのピークボリュームの決定

ピークボリュームは、1 日の特定の時間帯で Instant Messaging システムにトランザクションが最も集中したときの一意ログイン数です。このボリュームは、サイト間やユーザークラスの違いにより大きく異なります。たとえば、グループ間のピークボリュームは業務時間内のコアタイムに発生することが考えられますが、コアタイムはタイムゾーンによって異なります。

ピークボリュームの分析には、次の 3 つの基本処理が含まれます。

  1. ピークがいつ発生し、どのくらい継続するかを判断します

  2. ピークボリューム負荷を前提として配備のサイズを決定します

    パターンの分析が終了すれば、システムの負荷を処理しやすくし、ユーザーの求めるサービスを提供するための選択を行えます。

  3. ユーザーが決定したピークボリュームを Instant Messaging 配備がサポートできることを確認します

Instant Messaging の使用率プロファイルの作成

正確なサイズ決定には、負荷の測定が不可欠です。「使用率」プロファイルは、プログラムとプロセスが Instant Messaging サーバーおよびマルチプレクサに及ぼす負荷要因を特定します。

この節では、使用率プロファイルを作成して、配備で発生する負荷の量を測定する方法について説明します。

使用率プロファイルを作成するには、次の質問に答えてください。

  1. システムの合計ユーザー数は何人ですか。

    システムのユーザー数を数えるときは、アカウントを持ち、システムにログインできるユーザーだけを対象とするだけでなく、アカウントを持ち、現在システムにログインしていないユーザーも対象に含めます。次の表は、全ユーザーの種類別の内訳を示しています。

    接続 

    説明 

    アクティブでないユーザー 

    Instant Messaging のアカウントを持ち、システムに現在ログインしていないユーザー。接続していないユーザーは、ディスク領域を消費しますが、CPU またはメモリーは消費しません。 

    接続非アクティブユーザー 

    ログインはしているが、インスタントメッセージを現在送受信していないユーザー。 

    接続アクティブユーザー 

    システムにログインし、メッセージの送信、連絡先リストなどのユーザー情報の更新、会議室への参加などの処理を一日中、活発に行なっているユーザー。 

    次の 3 つの一般的なプロファイルで、ユーザーを分類します。これらのユーザーの合計から、サポートが必要な同時接続の総数を想定することができます。

    小規模な配備であれば、デフォルトの設定でもサイトのニーズを満たすことができます。このため、配備の規模がごく小規模 (たとえば 300 ユーザー未満) であれば、サイズ設定については考慮する必要がない場合もあります。クライアントサービス担当者と作業を行い、個別のニーズについて判断します。

  2. システムのピークボリューム時の接続はいくつですか。

    システムで維持する必要がある同時接続ユーザーの最大数を正確に算定しておくことが、リソースの条件を計画する上で重要です。配備では設定済みユーザーの最大数を想定しますが、計画では、アクティブかどうかにかかわらず接続されている同時接続ユーザーの最大数を想定するほうが重要です。同時接続ユーザー数は、安全な見積もりとして、1 対 10 で算出できます。つまり、50,000 ユーザーが設定されている配備では、同時接続ユーザーは 5,000 人と算定します。

    具体的には、同時平行接続、アイドル接続、ビジー接続の数に注意してください。

    接続 

    説明 

    並行接続 

    ある時点にシステムで確立されている一意の TCP 接続またはセッションの数。 

    アイドル接続 

    クライアントとマルチプレクサ、またはサーバーとマルチプレクサの間で情報が送信されていない接続。 

    ビジー接続 

    進行中の接続。クライアントとマルチプレクサ、またはマルチプレクサとサーバーの間で確立され、情報の送信が行われている接続。 

    配備の「同時接続数」を決定するには、Solaris プラットフォームの netstat コマンドを使って確立済み TCP 接続の数をカウントします。

    サポートできる同時接続数を決定するには、マルチプレクサのパフォーマンス調整に使用される iim.conf ファイルから 2 つのパラメータの値を取得する必要があります。

    1. iim_mux.numinstances - マルチプレクサインスタンスの数を指定する

    2. iim_mux.maxsessions - 1 つのマルチプレクサプロセスが処理できる最大クライアント数を指定する。デフォルトは 1000。

    これらの値を取得したら、numinstances の値と maxsessions の値を掛け合わせます。これにより、配備でサポートされる同時接続の総数が算出されます。iim.conf ファイルについては、『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』を参照してください。

  3. 大規模な配備を行う場合には、ユーザーをどのように組織化しますか。

    たとえば、アクティブユーザーと非アクティブユーザーをそれぞれ異なるサーバーに配置することを検討します。

  4. 1 ユーザーあたりのストレージ容量

    連絡先リストなどのエンドユーザーデータを LDAP に格納しない場合、このデータの格納に必要な容量を計画する必要があります。このデータを LDAP 外に格納するようにサーバーを設定した場合、サーバーはこれをフラットファイルに格納します。詳細については、『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』を参照してください。

  5. インターネットからどれぐらいの数のメッセージが Instant Messaging システムに送信されますか。

    メッセージの数は、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。

  6. ユーザー別ではどれぐらいの数のメッセージが送信されますか。

    • システム上のエンドユーザー

    • インターネットに対して送信される数

    このメッセージの数も、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。

  7. SSL を使用しますか。使用する場合は、ユーザーの何パーセントが、またどのようなタイプのユーザーが使用しますか。

    たとえばある組織では、ピーク時の 20% の接続が SSL で保護されます。

これらの質問に答えることで、配備のための、準備段階としての使用率プロファイルが完成します。Instant Messaging のニーズの変更に応じて、この使用率プロファイルにも修正を加えます。

その他の質問

次の質問は使用率プロファイルの作成に使用できるものではありませんが、配備のサイズ決定戦略には重要なものです。これらの質問にどのように答えるかによって、ハードウェアの追加を検討しなければならなくなる場合もあります。

  1. 配備にどの程度の冗長性を持たせますか。

    たとえば、高可用性が重要であると考えられますか。

  2. バックアップと復元 (障害回復やサイトフェイルオーバーなど) はどのように計画されていますか。回復タスクが完了するまでにどのくらいの時間を予想しますか。

    通常は、サーバー設定ファイル、データベース、カスタマイズされたリソースファイルのバックアップが必要です。

Instant Messaging のユーザーベースまたはサイトプロファイルの定義

ユーザープロファイルの作成が完了したら、次にそれをこの節で説明されているユーザーベースの例と比較してみます。ユーザーベースは、ユーザーが実行する Instant Messaging オペレーションの種類から構成されます。Instant Messaging ユーザーは、次のいずれかのユーザーベースに分類されます。

この節のユーザーベースの例では、ユーザーの行動を幅広く一般化しています。実際の使用率プロファイルがこのユーザーベースと一致するとは限りません。負荷シミュレータ (「Instant Messaging 負荷シミュレータの使用」を参照) の実行時に、差異を調節してください。

一般ユーザー

一般に、軽量なユーザーベースは、シンプルな Instant Messaging 要件を持つユーザーから構成されます。これらのユーザーがチャットセッションを開始したり、出席依頼を受け取ったりすることはほとんどありません。Instant Messaging を在席確認ツールとしてだけ使用する場合もあります。

ヘビーユーザー

ヘビーユーザーは、一般ユーザーとは比較にならないほど多くのシステムリソースを消費します。これらのユーザーの一般的なリソース使用状況は、たとえば次のようなものです。

Instant Messaging 負荷シミュレータの使用

Instant Messaging アーキテクチャーのパフォーマンスを測定するには、負荷シミュレータの入力としてユーザーベース (「Instant Messaging のユーザーベースまたはサイトプロファイルの定義」を参照) と使用率プロファイル (「Instant Messaging の使用率プロファイルの作成」を参照) を使用します。

負荷シミュレータは、ピークボリューム環境を作り出し、サーバーにかかる負荷の量を調整します。これにより、システムに過負荷をかけることなく希望する応答時間を実現するには、ハードウェア、スループット、または配備のアーキテクチャーを変更する必要があるかどうかを判断できます。負荷シミュレータを使用するには、次の 5 つの基本手順に従います。

  1. テストするユーザーベース (たとえば、一般ユーザー) を定義します

    必要に応じて、使用率プロファイルに最適化するように個別のパラメータを調整します。

  2. テストするハードウェアを定義します

  3. 負荷シミュレータを実行し、ユーザーベースを使用してテストされたハードウェアの最大同時接続数を測定します

  4. 結果を記録して、稼働中の配備の結果と比較します

  5. ピーク負荷状態の応答時間が組織で容認されるレベルになるまで、さまざまなユーザーベースとハードウェアを使用してこのプロセスを繰り返します

注 –

推奨負荷シミュレータとサポートについては、ご購入先のクライアントサービス担当者に連絡してください。

Instant Messaging のシステムパフォーマンスガイドラインについて

負荷シミュレータを使用してハードウェアとユーザーベースの評価を行うと、システムパフォーマンスを測定する必要があります。この節の各トピックでは、システムの全体的なパフォーマンスを向上させる方法について説明します。

Instant Messaging のメモリー使用率

配備で使用するそれぞれのマシンに、適切な量の物理メモリーが搭載されていることを確認してください。物理メモリーを追加するとパフォーマンスが向上し、ピークボリューム時でも Instant Messaging サーバーが適切に動作するようになります。メモリー容量が十分であれば、Instant Messaging は過度のスワッピングをすることなく効率的に動作できます。

ほとんどの配備では、256M バイト以上の RAM が必要です。RAM の必要容量は、同時並行クライアント接続の数、およびサーバーとマルチプレクサが同じホストに配備されているかどうかによって異なります。同時接続については、「Instant Messaging の使用率プロファイルの作成」を参照してください。サーバーとマルチプレクサの同一ホスト上でのホスティングについては、「Instant Messaging アーキテクチャー戦略の構築」を参照してください。

Solaris システムでは、iim.conf ファイルの iim.jvm.maxmemorysize パラメータを変更して、サーバーに割り当てるメモリーの容量を設定できます。このパラメータは、サーバーを実行する JVM (Java Virtual Machine) が使用できる最大メモリー数を M バイト単位で指定します。デフォルトの設定は 256M バイト、最大設定は 500M バイトです。このパラメータの設定方法については、『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』を参照してください。

Windows NT システムでは、現時点ではこの値を変更できません。

Instant Messaging のディスクスループット

ディスクのスループットとは、システムでメモリーからディスクに、またはディスクからメモリーに転送されるデータ量のことです。このデータ転送レートは、Instant Messaging のパフォーマンスに重大な影響を及ぼします。システムのディスクスループット効率を向上させる方法は、次のとおりです。

Instant Messaging のディスク容量

サーバーシステムのディスク容量を計画するときは、オペレーティング環境ソフトウェア、Instant Messaging ソフトウェア、Instant Messaging をサポートするためにインストールが必要で、現在ネットワーク内に存在しないサーバー (LDAP など) の容量を考慮してください。必ず外部ディスク配列を使用してください。さらに、ユーザーディスク容量を割り当てます。この容量は、通常、サイトのポリシーに従って決定されます。一般的なインストールでは、次の容量が必要です。

表 22–1 は、アーカイブ機能を有効または無効にした場合のサーバーおよびマルチプレクサのディスク容量のサイズ設定を示しています。この表に示す値は、400MHz の Ultra SPARC II Processor を使用して算出したものです。

表 22–1 同時接続ユーザーを考慮した、Instant Messaging サーバーとマルチプレクサのメモリーディスク容量のサイズ設定

 

接続/非アクティブユーザーのサーバーメモリー消費量 

接続/アクティブユーザーのサーバーメモリー消費量 

接続/非アクティブユーザーのマルチプレクサメモリー消費量 

接続/アクティブユーザーのマルチプレクサメモリー消費量 

アーカイブ無効 

ユーザーあたり 8M バイト + 20K バイト 

ユーザーあたり 120M バイト +20K バイト 

ユーザーあたり 8M バイト +20K バイト 

ユーザーあたり 8M バイト + 28K バイト 

SSO/ ポータル / アーカイブ有効 

ユーザーあたり 100M バイト + 25K バイト 

ユーザーあたり 120M バイト + 30K バイト 

ユーザーあたり 8M バイト + 35K バイト 

ユーザーあたり 8M バイト + 40K バイト 

Instant Messaging のネットワークスループット

ネットワークスループットは、一定時間内にクライアントアプリケーションとサーバー間のネットワークで転送可能なデータ量のことです。ネットワークに接続されたサーバーがクライアントからの要求に応答できない場合、通常クライアントは要求の再送信を何度も行います。再送信のたびに、システムにはオーバーヘッドと余分なネットワークトラフィックが生じます。

データの完全性とシステムのパフォーマンスを向上させ、ネットワークの混雑を解消することで、再送信の数を減らすことができます。それには、次の手順に従います。

Instant Messaging の CPU リソース

サーバーとマルチプレクスサービス用に十分な数の CPU を用意します。さらに、使用を計画している RAID システムにも十分な CPU を用意します。配備でアーカイブ機能を利用する場合は、ディスク容量の要件についても考慮する必要があります。

表 22–2 は、アーカイブが有効または無効な場合のインストールの最適なパフォーマンスに必要な CPU 数を示しています。この表に示す値は、400MHz の Ultra SPARC II Processor を使用して算出したものです。

表 22–2 Instant Messaging の CPU の使用に関する数値

 

接続/非アクティブユーザーのサーバー CPU 使用率 

接続/アクティブユーザーのサーバー CPU 使用率 

接続/非アクティブユーザーのマルチプレクサ CPU 使用率 

接続/アクティブユーザーのマルチプレクサ CPU 使用率 

アーカイブ無効 

1 CPU あたり数十万のユーザー 

1 CPU あたり 30,000 ユーザー 

1 CPU あたり 50,000 ユーザー 

1 CPU あたり 5,000 ユーザー 

Instant Messaging マルチプレクサの最適設定

マルチプレクサの配備を計画するときは、次に提案する一般的な値を参考にしてください。ここで説明するパラメータは、iim.conf ファイルで設定できます。

これらのパラメータの詳細については、『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』を参照してください。

Instant Messaging アーキテクチャー戦略の構築

システムパフォーマンスのニーズを確認した後、Instant Messaging 配備のサイズ決定では次に、アーキテクチャーの決定に基づいて特定のコンポーネントのサイズを決定します。

この節の各トピックでは、2 層と 1 層のアーキテクチャーを配備する場合のサイズ決定で考慮しなければならないことについて説明します。Instant Messaging と共にロードバランサを使用する方法についても説明します。

2 層 Instant Messaging アーキテクチャー

2 層アーキテクチャーでは、Instant Messaging サーバー配備をアクセス層とデータ層の 2 層に分割します。単純な 2 層配備では、アクセス層に 1 つまたは複数のマルチプレクサとサーバーを追加します。ユーザーにとってマルチプレクサはプロキシのように機能し、メッセージを Instant Messaging サーバーにリレーします。データ層には、Instant Messaging サーバーデータベースとディレクトリサーバーが保持されます。図 22–1 は、簡略化した 2 層 Instant Messaging アーキテクチャーを示しています。

図 22–1 簡略化した 2 層 Instant Messaging アーキテクチャー

この図は、簡略化した 2 層の Instant Messaging アーキテクチャーを示します。

1 層アーキテクチャーと比較して、2 層アーキテクチャーにはサイズ設定上の利点があります。2 層アーキテクチャーの特徴は、次のとおりです。

多重化サービスのサイズ決定

マルチプレクサのサイズを設定する場合、システムの負荷、特にマルチプレクサが処理する同時接続の数に基づいて計算を行います。

さらに、次のことを実行する必要があります。

  1. 必要であれば、SSL 用の CPU またはハードウェアアクセラレータを追加します。

  2. マルチプレクサを設定するマシンにメモリーを追加します。

  3. サービス拒否について考慮します。

  4. 必要に応じて、負荷分散と冗長性の能力を追加します。

配備に冗長性を持たせる場合、それぞれのマシンがスループットや応答時間を大きく損なわずにピーク負荷を処理できるようにする必要があります。

1 層 Instant Messaging アーキテクチャー

1 層アーキテクチャーは、アクセス層とデータ層に分割されません。Instant Messaging サーバー、マルチプレクサ、場合によってはディレクトリサーバーが 1 つの層にインストールされます。次の図は、この概念を示したものです。

図 22–2 簡略化した 1 層 Instant Messaging アーキテクチャー

この図は、Instant Messaging サーバー、ディレクトリサーバー、マルチプレクサ、エンドユーザーに対する単純な 1 層配備を示しています。

2 層アーキテクチャーと比較して、1 層アーキテクチャーはハードウェアへの初期投資が少なくて済みます。しかし、1 層アーキテクチャーを選択した場合は、保守のためにかなりの停止時間を見込んでおく必要があります。

1 層アーキテクチャーのサイズを設定するには、次の事項を考慮する必要があります。

  1. 必要に応じて SSL 用の CPU を追加します。

  2. サービス拒否攻撃について考慮します。

  3. クライアント接続数の増加に対応するためのディスクを追加します。

  4. 各マルチプレクサ用にディスクを追加します。

1 層アーキテクチャーおよび 2 層アーキテクチャーにおける Instant Messaging コンポーネントのサイズ決定に関する特別な手順については、ご購入先のクライアントサービス担当者に連絡してください。

Instant Messaging と共にロードバランサを使用する

Instant Messaging は、Instant Messaging マルチプレクサの前に配置されているロードバランサの使用をサポートしています。ただし、現在のところ、Instant Messaging マルチプレクサと Instant Messaging サーバーの間ではロードバランサを使用できません。

Instant Messaging を Portal Server/Secure Remote Access 配備の一部として配備する場合、Secure Remote Access ゲートウェイと Instant Messaging マルチプレクサの間にロードバランサを配置できます。

注 –

クライアント接続にセキュリティーが必要で、HTTP トンネリングには不要である場合、Secure Remote Access の代わりに SSL の使用を検討します。SSL をマルチプレクサで使用可能にして、ファイアウォールの外側に配置することにより、セキュリティー保護された Instant Messaging クライアント接続を構成できます。

Instant Messaging リソース要件の例

ここでは、次の 2 種類の Instant Messaging 配備に必要なリソース分散の例と推奨サイズに関する情報を紹介します。

小規模配備のリソース要件の具体例

サーバーとマルチプレクサが単一サーバーにインストールされ、次のプロファイルの 10,000 ユーザーを持つ小規模の Instant Messaging 配備の場合

メモリー要件として、1 つまたは 2 つの CPU で、それぞれについて 300 〜 500M バイトの RAM が必要です。

大規模配備のリソース要件の具体例

次のプロファイルの 1,000,000 ユーザーを持つ大規模の Instant Messaging 配備の場合

サーバーのメモリー要件として、2 つの CPU で、合計 4G バイトの RAM が必要です。マルチプレクサには、16 個の CPU で、合計 4G バイトの RAM が必要です。

第 23 章 Instant Messaging アーキテクチャーの開発

この章では、さまざまな Instant Messaging アーキテクチャーについて説明します。インストールする必要のあるコンポーネントは、個々の配備ごとに異なります。たとえば、電子メール通知をサポートする場合は、SMTP サーバーをインストールする必要があります。電子メール通知をサポートしない場合は、SMTP サーバーをインストールしないでください。

Instant Messaging と相互運用するコンポーネントの詳細については、「Instant Messaging の関連コンポーネント」を参照してください。

この章には、次の節があります。

注 –

現在、Solaris プラットフォームではすべての配備オプションが利用できます。Linux および Windows オペレーティングシステムでは一部の配備オプションが利用できません。

Instant Messaging の基本アーキテクチャー

図 23–1 は、Instant Messaging の基本アーキテクチャーを示したものです。

図 23–1 Instant Messaging の基本アーキテクチャー

この図は、Instant Messaging の基本配備におけるコンポーネント間の関係を示しています。

この Instant Messaging 基本アーキテクチャーでは、チャット、ニュースアラート、会議室などの機能が提供されます。この基本機能を利用するには、次のコンポーネントをインストールする必要があります。

この例では、次のようにします。

基本アーキテクチャーにおける認証

図 23–2 は、Instant Messaging の基本アーキテクチャーで行われる認証プロセスで、ソフトウェアコンポーネントがどのように連携するかを示しています。認証要求のフローに注目しています。このプロセスの各段階の説明は、図の後に記載しています。

図 23–2 Instant Messaging の基本アーキテクチャーにおける認証要求のフロー

この図は、LDAP のみの Instant Messaging サーバー構成の認証プロセスにおける認証要求のフローを示しています。

基本アーキテクチャーにおける認証プロセスは、次のように処理されます。

  1. エンドユーザーはブラウザから Instant Messenger アプレット URL にアクセスし、クライアントを呼び出すメソッドを選択します。

  2. ブラウザが Java Web Start または Java プラグインを起動します。

  3. Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。

  4. ログインウィンドウが表示され、エンドユーザーはログイン名とパスワードを入力します。ログインデータはマルチプレクサ経由で Instant Messaging サーバーに送信されます。

  5. Instant Messaging サーバーは LDAP サーバーと通信してエンドユーザーを認証し、連絡先リストやその登録情報などのエンドユーザー情報を要求します。

エンドユーザーの認証が完了すると、Instant Messaging のメインウィンドウが表示され、そのエンドユーザーの連絡先リストが表示されます。これにより、エンドユーザーは他のエンドユーザーとの Instant Messaging セッションに参加できるようになります。

Instant Messaging 電子メール通知 (カレンダアラート) アーキテクチャー

オフラインユーザーへの電子メール通知とユーザーへのカレンダの予定の Instant Messaging ベース通知をサポートするように、Instant Messaging を配備することができます。

電子メール通知とカレンダアラートをサポートする Instant Messaging アーキテクチャー は、「Instant Messaging の基本アーキテクチャー」と同じ機能を提供します。この機能を提供するには、「Instant Messaging の基本アーキテクチャー」に記載されたコンポーネントを含める必要があります。電子メールアラートをサポートするには、Sun Java System Messaging Server などの SMTP サーバーもインストールする必要があります。カレンダアラートをサポートするには、Sun Java System Calendar Server もインストールする必要があります。

電子メール通知を有効にする場合、Instant Messaging のインストール時に使用する SMTP サーバーの指定が必要となります。SMTP サーバーがインストールされていない場合は、Instant Messaging ソフトウェアのインストール前にインストールを完了する必要があります。図 23–3 は、ネットワーク経由の電子メール通知に対応した Instant Messaging を示しています。

Calendar Server がインストールされていない場合は、Instant Messaging ソフトウェアのインストール前にインストールを完了する必要があります。図 23–4 は、ネットワーク経由のカレンダ通知に対応した Instant Messaging を示しています。

このアーキテクチャーの認証フローは基本配備と同じです。詳細については、「基本アーキテクチャーにおける認証」を参照してください。

図 23–3 電子メール通知を使用する Instant Messaging アーキテクチャー

この図は、電子メール通知が有効な Instant Messaging の配備におけるコンポーネント間の関係を示しています。

この例では、次のようにします。

図 23–4 カレンダアラートを使用する Instant Messaging アーキテクチャー

この図は、カレンダの予定通知が有効な Instant Messaging の配備におけるコンポーネント間の関係を示しています。

この例では、次のように動作します。

Access Manager または SSO を使用する Instant Messaging アーキテクチャー

Access Manager のポリシー機能とシングルサインオン (SSO) を使用するように Instant Messaging を配備することができます。Access Manager を使用する Instant Messaging アーキテクチャーは、「Instant Messaging の基本アーキテクチャー」と同じ機能を提供します。この機能を利用するには、「Instant Messaging の基本アーキテクチャー」に記載されたコンポーネントのほかに、Access Manager もインストールする必要があります。さらに、Instant Messaging サーバーホスト上に Access Manager SDK をインストールする必要があります。

このアーキテクチャーの場合、Instant Messaging はユーザーの検索にディレクトリを使用しますが、ユーザーの認証または承認には使用しません。ユーザーの認証と承認は Access Manager 側で行われます。

Access Manager で SSO を使用する場合、Access Manager と Instant Messaging が同じ Web コンテナを使用するように構成する必要があります。

図 23–5 は、Access Manager を使用する Instant Messaging アーキテクチャーを示しています。

図 23–5 Access Manager ベースのサーバーポリシー管理またはシングルサインオンを使用する Instant Messaging アーキテクチャー

この図は、Access Manager を使用する Instant Messaging 配備におけるコンポーネント間の関係を示しています。

この例では、次のように動作します。

Access Manager のみを使用するアーキテクチャーにおける認証

図 23–6 は、シングルサインオン環境において、コンポーネント Portal Server および Access Manager と連携する Instant Messaging ソフトウェアによって使用される認証プロセスを示したものです。図 23–2 と同様に、この図も認証要求のフローを示しています。このプロセスの各段階の説明は、図の後に記載しています。

図 23–6 Access Manager を伴う構成での認証要求のフロー

この図は、Instant Messaging アーカイブコンポーネントとデータフローを示しています。

シングルサインオン環境において、この配備の Instant Messaging サーバーの認証プロセスは、次のように機能します。

  1. ユーザーは、Web ブラウザに適切な URL を入力し、Access Manager にログインします。

  2. Access Manager ソフトウェアはエンドユーザーを認証し、セッショントークンを返します。

    シングルサインオンが機能するには、セッショントークンが必要です。このトークンはアプレットパラメータとして提供され、認証プロセス全体で使用されます。セッショントークンがある限り、資格の再入力はエンドユーザーに求められません。

  3. エンドユーザーはブラウザから Instant Messenger アプレットにアクセスし、クライアントを呼び出すメソッドを選択します。

  4. ブラウザが Java Web Start または Java プラグインを起動します。

  5. Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。

  6. Instant Messenger は、セッショントークンを使用して Instant Messaging サーバーへの認証を要求します。

  7. Instant Messaging サーバーは、セッショントークンの検証を Access Manager に求めます。セッションが有効であれば、Instant Messenger はエンドユーザーの連絡先リストを表示し、エンドユーザーはチャット、アラート、ポーリングなどの Instant Messenger サービスを利用できるようになります。

  8. Instant Messaging サーバーは、連絡先リストやその登録情報などのエンドユーザー情報を取得または設定するときに、LDAP に直接照会する必要があります。

ポータルベースまたはアーカイブを使用する Instant Messaging アーキテクチャー

メッセージアーカイブをサポートするとともに Instant Messaging がセキュリティー保護されたモードで実行されるように、Instant Messaging を配備することができます。この機能を提供する Instant Messaging アーキテクチャーは、「Instant Messaging の基本アーキテクチャー」と同じ機能も提供します。また、Portal Server デスクトップによりエンドユーザーは Instant Messenger クライアントを利用することができます。この機能を利用するには、「Instant Messaging の基本アーキテクチャー」に記載されたコンポーネントのほかに、Portal Server と Access Manager もインストールする必要があります。

このアーキテクチャーでは、Access Manager がアクセスするディレクトリと Web サーバーが使用されます。これらのサーバーの追加インスタンスをインストールする必要はありません。また、Access Manager が必要となるこのアーキテクチャーでは、「Access Manager または SSO を使用する Instant Messaging アーキテクチャー」で説明したすべての機能も利用できます。

図 23–7 は、ポータルベース Instant Messaging アーキテクチャーを示したものです。

図 23–7 ポータルベースのセキュリティー保護されたモードまたはアーカイブを使用する Instant Messaging アーキテクチャー

この図は、Instant Messaging アーカイブコンポーネントとデータフローを示しています。

この例では、次のようにします。

Portal Server アーキテクチャーにおける認証

図 23–8 は、シングルサインオン環境において、Portal Server および Access Manager と連携する Instant Messaging ソフトウェアによって使用される認証プロセスを示したものです。図 23–2 と同様に、この図も認証要求のフローを示しています。このプロセスの各段階の説明は、図の後に記載しています。

図 23–8 Portal Server と Access Manager を伴う構成における認証要求のフロー

この図は、Portal Server を組み合わせた Instant Messaging の配備を示しています。

シングルサインオン環境において、この配備の Instant Messaging サーバーの認証プロセスは、次のように機能します。

  1. ユーザーは、Web ブラウザに適切な URL を入力し、Portal Server にログインします。

  2. Access Manager ソフトウェアはエンドユーザーを認証し、セッショントークンを返します。Portal Server によりエンドユーザーはデスクトップをダウンロードすることができます。Portal Server デスクトップは、エンドユーザーのブラウザに表示されます。セッショントークンの説明については、手順 6 を参照してください。

  3. エンドユーザーは、デスクトップの Instant Messaging チャネルで Instant Messenger URL リンクをクリックします。

  4. ブラウザが Java Web Start または Java プラグインを起動します。

  5. Java Web Start または Java プラグインは、適切な Instant Messenger リソースファイルをダウンロードし、Instant Messenger を起動します。

  6. Instant Messenger は、セッショントークンを使用して Instant Messaging サーバーへの認証を要求します。

    シングルサインオンが機能するには、セッショントークンが必要です。このトークンはアプレットパラメータとして提供され、認証プロセス全体で使用されます。セッショントークンがある限り、資格の再入力はエンドユーザーに求められません。

  7. Instant Messaging サーバーは、セッショントークンの検証を Access Manager に求めます。セッションが有効であれば、Instant Messenger はエンドユーザーの連絡先リストを表示し、エンドユーザーはチャット、アラート、ポーリングなどの Instant Messenger サービスを利用できるようになります。

  8. Instant Messaging サーバーは、連絡先リストやその登録情報などのエンドユーザー情報を取得または設定するときに、LDAP に直接照会する必要があります。

すべての機能が有効な Instant Messaging

Instant Messaging を配備し、この節で説明してきたすべての機能を有効にするには、次のようにします。

また、Access Manager ホスト上で Access Manager Instant Messaging サービスを設定する必要もあります。

Instant Messaging の物理的な配備例

ここでは、「Instant Messaging の基本アーキテクチャー」で説明した配備シナリオのバリエーションを説明します。たとえば、必要となる各種サーバーおよびコンポーネントを次の物理構成にインストールすることができます。

これらのバリエーションは、この章で説明したすべてのアーキテクチャーに適用できます。配備要件に合わせて選択してください。

Instant Messaging の物理的な配備例: Web Server を別ホストにインストール

図 23–9 は、Instant Messaging サーバーとマルチプレクサが同一ホスト上にインストールされる構成を示したものです。Web サーバーは別ホスト上にインストールされます。Web サーバーホストには、Instant Messaging リソースも格納されます。Web サーバーと LDAP サーバーのインスタンスがすでに存在し、これらのホストに他のアプリケーションをインストールしない場合は、この構成を採用します。

図 23–9 Web サーバーと Instant Messaging サーバーを別々のホストにインストール

この図は、Web サーバーと Instant Messenger が異なるホストにインストールされることを示しています。

Instant Messaging の物理的な配備例: マルチプレクサを別ホストにインストール

図 23–10 は、2 つのマルチプレクサが 2 つの異なるホスト上にインストールされる構成を示したものです。Instant Messaging サーバーは別のホスト上にインストールされます。この構成では、企業のファイアウォールの外にマルチプレクサを置くことができます。複数のホストにマルチプレクサをインストールすると、Instant Messaging サーバーの負荷は複数のシステムに分散されます。

注 –

マルチプレクサはリソースを大量に消費する場合があるので、別のホストに置くことでシステム全体のパフォーマンスを向上させることができます。

Windows 環境では、1 つのホストでサポートされるマルチプレクサは 1 つだけです。

図 23–10 Instant Messaging マルチプレクサの別ホストへのインストール

この図は、2 つのマルチプレクサが 2 つの異なるホスト上にインストールされ、Instant Messaging サーバーはさらに別のホスト上にインストールされる、複数サーバーの構成を示したものです。

Instant Messaging の物理的な配備例: 複数の Instant Messaging ホスト

図 23–11 は、2 つの Instant Messaging サーバーによる構成を示しています。この構成は、管理ドメインが複数ある場合に採用されます。Instant Messaging サーバーの各ホストでは、一方の Instant Messaging サーバーのエンドユーザーが、もう一方の Instant Messaging サーバーのエンドユーザーと通信できるようにサーバーを設定する必要があります。

図 23–11 複数の Instant Messaging サーバーホスト

この図は、2 つの管理ドメインが存在する環境を示しています。

第 24 章 Instant Messaging のインストール前の考慮事項について

この章では、Instant Messaging のインストール前に考慮が必要な事項について説明します。Java Enterprise System インストーラの実行手順については、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』を参照してください。

この章には、次の節があります。

Instant Messaging のインストールの概要

Solaris システム上で Instant Messaging をインストールするには、Java Enterprise System インストーラを使用します。Linux および Windows システム上では、それぞれのメディアキット CD に含まれるセットアッププログラムを使用します。また、このソフトウェアは、次のサイトからダウンロードすることもできます。

http://www.sun.com/software/download

Java Enterprise System と Instant Messaging のマニュアルには、インストールやアップグレード、サーバーの設定、クライアントの設定などに関する手順やツール情報が記載されています。そうした詳しいインストール手順や設定手順については、次のマニュアルを参照してください。

『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』

『Sun Java Enterprise System 2005Q4 アップグレードガイド』

『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』

インストールを始める前に、『Sun Java System Communications Services 2005Q4 リリースノート』の第 3 章「Sun Java System Instant Messaging 7 2005Q4 リリースノート」でハードウェア要件、ソフトウェア要件、およびサポートされているバージョンを確認してください。

Instant Messaging をインストールする前に、Directory Server、Web Server、および必要に応じて Messaging Server をインストールする必要があります。さらに、Solaris システム上で Access Manager と Portal Server が提供する機能を Instant Messaging から使用する場合には、それらのサーバーもインストールする必要があります。ほかのサーバーとの連携については、「Instant Messaging の関連コンポーネント」を参照してください。さらに、第 23 章「Instant Messaging アーキテクチャーの開発」では、Instant Messaging の各種機能を活用するうえで参考になるアーキテクチャーを、いくつか紹介しています。

Instant Messaging ワークシート

ユーザーは、インストールまたはアップグレード時に基本的な設定情報の入力を求められます。このような情報は事前に収集しておいてください。ユーザーはそうした情報の一部またはすべての入力を求められますが、そのどちらになるかは、ユーザーがどのコンポーネントをインストール対象として選択するかによります。

表 24–1 を印刷し、配備時の値を空白部分に記入してください。このインストール用ワークシートは、複数のインストールやアンインストール、アップグレードなどに再利用できます。この表にはパスワードなどの機密情報が含まれています。したがって、この情報を安全な場所に保管することをお勧めします。

表 24–1 Instant Messaging インストールパラメータ

パラメータ 

説明 

実際の設定値 

Installation Directory

instant-messaging-install-dir または installation directory。

Instant Messaging のインストール先ディレクトリ。 

デフォルト: 

Solaris システム: /opt/SUNWiim

Linux システム: /opt/sun/im

Windows システム: C:\Program Files\Sun\Instant Messaging

 

Instant Messaging Server Host and Domain Name

Instant Messaging のインストール先ホスト名と、そのホストに関連付けられたドメイン名。例: 

ホスト名: instantmessaging.siroe.com

ドメイン名: siroe.com

 

Instant Messaging Server Port Number

Instant Messenger クライアント以外から着信した要求に対する Instant Messaging サーバーの待機ポートの番号。 

デフォルト: 49999 

 

Multiplexor Port Number (マルチプレクサ構成のみ)

Instant Messenger クライアントから着信した要求に対する Instant Messaging サーバーの待機ポートの番号。 

デフォルト: 49909 

 

Disable Server

インストールしたインスタンスをサーバーとしてではなくマルチプレクサとして動作させる場合に、このオプションを選択します。このオプションを選択した場合、Remote Instant Messaging Server Host Name (マルチプレクサ構成のみ) の値を入力する必要があります。 

 

Remote Instant Messaging Server Host Name (マルチプレクサ構成のみ)

このマルチプレクサがメッセージをルーティングする Instant Messaging サーバーのホスト名。設定対象のインストール済みインスタンスが、マルチプレクサではなく Instant Messaging サーバーである場合には、このパラメータの値を入力しないでください。 

依存関係: Disable Server パラメータを選択し、サーバー機能を無効にする必要があります。 

 

Assign Instant Messaging Services to existing users (省略可能)

このオプションを選択した場合、既存の Access Manager ユーザーに対して Instant Messaging が有効になります。 

依存関係: Portal Server と Access Manager。 

 

Secure Mode (省略可能)

これを選択した場合、Portal Server Secure Remote Access との統合化が有効になります。 

Secure Remote Access は、イントラネット内のリモートユーザーにセキュアアクセスを提供します。ユーザーは、ポータルゲートウェイを介して Web ベースの Portal Server Desktop にログインすることで、Secure Remote Access にアクセスできます。

依存関係: 

Portal Server と Access Manager が必要です。 

Instant Messaging をセキュリティー保護されたモードで実行できるのは、Secure Remote Access が設定されている場合だけです。手順については、『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』および『Sun Java System Portal Server 6 2005Q4 Secure Remote Access 管理ガイド』を参照してください。

この機能を有効にした場合、次にパラメータの値を入力する必要があります。 

  • Netlet Instant Messaging Port Number (省略可能)

  • Messenger Secure Download Port (省略可能)

 

Netlet Instant Messaging Port Number (省略可能)

Secure Mode (省略可能) を有効にした場合、これが着信要求に対する Netlet の待機ポートの番号になります。 

デフォルト: 49917 

依存関係: Secure Mode (省略可能) の有効化、Portal Server、および Access Manager。 

 

Messenger Secure Download Port (省略可能) 

Secure Mode (省略可能) を有効にした場合、これが、 Instant Messenger リソースを Netlet 経由でダウンロードする際のポート番号になります。 

デフォルト: 49916 

依存関係: Secure Mode (省略可能) の有効化、Portal Server、および Access Manager。 

 

Enable Instant Messaging Archive (省略可能) 

これを選択した場合、Instant Messaging に対する Portal Server 検索ベースアーカイブが有効になります。 

依存関係: Portal Server と Access Manager。 

 

LDAP Host Name 

Instant Messaging に対するユーザーとグループの情報が格納された LDAP サーバーのホスト名。たとえば、directory.siroe.com など。

依存関係: Directory Server などの LDAP サーバー。 

 

LDAP Port Number 

着信した要求に対するディレクトリサーバーの待機ポート番号。たとえば、389 など。

依存関係: Directory Server などの LDAP サーバー。 

 

Base DN 

Instant Messaging のユーザーとグループの情報が格納されているディレクトリツリー内のベース識別名。たとえば、o=siroe.com など。

依存関係: Directory Server などの LDAP サーバー。 

 

Bind DN 

インストール中に、ディレクトリマネージャの バインド DN とパスワードを使用する必要があります。この情報に基づき、インスタントメッセージングと在席確認サービスのテンプレートと属性のみを使ってディレクトリスキーマが更新されます。これにはディレクトリマネージャのアクセス権が必要となります。インストールや初期設定の終了後に、ディレクトリマネージャのバインド DN とパスワードが保存または使用されることはありません。 

サーバー構成の場合、Instant Messaging はこのバインド DN を使ってディレクトリ内のユーザーとグループを検索します。匿名でのディレクトリ検索が可能である場合は、これを空白のままにしてください。 

依存関係: Directory Server などの LDAP サーバー。 

 

Bind Password 

Bind DN のパスワード。 

 

SMTP Server Host Name (省略可能) 

オフラインユーザーにメッセージ通知を電子メールで送信する際に使用する SMTP サーバーのホスト名。たとえば、mail.siroe.com など。SMTP サーバーが 25 以外のポートを使用する場合、ホスト名のほかにそのポートも指定します。たとえば、SMTP サーバーがポート 1025 を使用する場合、次のように指定します。

mail.siroe.com:1025

依存関係: Messaging Server などの SMTP サーバー。 

 

Database, Logs, and Runtime File Pathname 

実行時ファイル、データベース、およびログの格納先。 

デフォルト: 

Solaris システム: /var/opt/SUNWiim/default

Linux システム: /var/opt/sun/im

Windows システム: C:\Program Files\Sun\Instant Messaging

 

Resources and Help Files Pathname 

instant-messaging-resource-directory または resource directory

リソースファイルとオンラインヘルプファイルのインストール先ディレクトリ。 

デフォルト: 

Solaris システム: /opt/SUNWiim/html

Linux システム: /opt/sun/im/html

Windows システム: C:\Program Files\Sun\Instant Messaging\html

 

Code Base 

Instant Messenger がリソースをダウンロードする URL。

リソースは、Web サーバーのドキュメントルート内にインストールします。たとえば、Web サーバー www.example.com の待機ポートが 89、ドキュメントルートが /opt/web/ であり、Instant Messenger リソースを /opt/web/im にインストールする場合は、Instant Messenger リソースのコードベースは次のようになります。

http://www.example.com:89/im/

インストール時に正しい codebase を入力しなかった場合、Instant Messenger の起動ページ codebase /lang/im[ssl].html と codebase/lang /im[ssl].jnlp 内の URL を、正しい値に更新する必要があります。

UNIX の場合、リソースを任意のディレクトリにインストールし、シンボリックリンクを使ってそのリソースを Web サーバーから見えるようにする、といったことも可能です。 

たとえば、前述した例で、/opt/SUNWiim/html 内に Instant Messenger リソースをインストールした場合、そのリソースを Web サーバーから見えるようにするには、次のようなシンボリックリンクを作成します。

ln -s /opt/SUNWiim/html /opt/web/im

詳細については、『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』と Web サーバーのマニュアルを参照してください。