test

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

第 10 章 Messaging Server サイズ決定戦略の計画

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

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

この章は、Messaging Server 配備のサイズ決定の基礎について説明し、正しいサイズ決定データを得て配備上の判断ができるようにすることを目的としています。また、Messaging Server のサイズ決定プロセスの背景と理論的根拠についても説明します。

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

注 –

配備にはそれぞれに固有の特徴があるため、この章では特定のサイトに関するサイズ決定情報の詳細な説明はしていません。代わりにここでは、サイズ決定計画を構築する場合には何を考慮しなければならないのかを説明します。配備のハードウェアとソフトウェアのニーズを決定する場合には、ご購入先のテクニカルサポート担当者とともに作業を行なってください。

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

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

メッセージングのピークボリュームの判断

「ピークボリューム」は、1 日の特定の時間帯でメッセージングシステムにトランザクションがもっとも集中したときのトランザクション数です。このボリュームは、サイト間やユーザークラスの違いにより大きく異なります。たとえば、ある中規模企業のマネージャークラスでは、朝の 9 時から 10 時の間、昼の 12 時から 1 時の間、夕方の 5 時から 6 時の間にピークボリュームが発生します。

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

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

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

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

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

メッセージングの使用率プロファイルの作成

正確なサイズ決定には、負荷の測定が不可欠です。「使用率プロファイル」により、Messaging Server ホスト上のプログラムとプロセスが実行する要素が決定されます。

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

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

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

    システムのユーザー数を数える時には、メールアカウントを持ちメールシステムにログインできるユーザーだけでなく、メールアカウントを持っているが、現在システムにはログインしていないユーザーも含めます。特に、次に示しているアクティブなユーザーとアクティブでないユーザーとの相違点に注意してください。

    ユーザー 

    説明 

    アクティブなユーザー 

    POP、IMAP、または HTTP のようなメールアクセスプロトコルを使用してメールシステムにログインしているユーザー。アクセスプロトコルの種類により、アクティブなユーザーはメールサーバーに接続していたり、接続していなかったりします。

    たとえば、POP ユーザーはメールアカウントを開きますが、メールクライアントからメールサーバーに対して確立される POP 接続は短時間で、断続的です。 

    ここで説明しているアクティブなユーザーは、mailuserstatus やinetuserstatus のような active ステータスを持ったメール属性ではありません。メール属性の詳細については、『Sun Java System Communications Services Schema Reference 』を参照してください。

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

    メールアカウントを持っているが、現在はメールシステムを使用していないユーザー。 

    ユーザー数が 300 以下のきわめて小規模な配備の場合は、サイズ決定戦略の計画でこのプロセスを実行する必要はありません。クライアントサービス担当者と作業を行い、個別のニーズについて判断します。

  2. POP、IMAP、および Messenger Express クライアントがサービスにアクセスするピークボリューム時に、システムへの接続数はどのくらいになりますか。

    特に、サポートするそれぞれのクライアントアクセスサービスの並行接続、アイドル接続、ビジー接続の数に注意します。

    接続 

    説明 

    並行接続 

    ある時間にメールシステム上で確立される、固有の TCP 接続またはセッション (HTTP、POP、または IMAP) の数。 

    アクティブなユーザーは複数の並行 IMAP セッションを行うことができます。一方、POP クライアントまたは Messenger Express クライアントを使用するユーザーは、クライアントごとに 1 つの接続しか確立できません。さらに、POP 接続と Messenger Express 接続は、サーバーに接続してデータを取得し、サーバーへの接続を切断して、データの表示、ユーザー入力の受け入れを行い、そしてメールサーバーへの再接続を行うため、POP および Messenger Express クライアントアクセスサービスのアクティブなユーザーは、ある時点においてはアクティブな接続を行わずにサービスにアクセスすることも可能です。

    アイドル接続 

    確立された IMAP 接続で、時々送信される check または noop コマンドを除き、メールクライアントと Messaging Server との間で情報送信を行わないもの。

    ビジー接続 

    進行中の接続。ビジー接続の例としては、メールクライアントが送信したばかりのコマンドを処理中、つまり、メールクライアントに応答を送り返している状態のメールサーバーがあります。 

    配備における「並行接続」の数は、次のいずれかの方法で決定します。

    1. UNIX プラットフォームで netstat コマンドを使用して、確立された TCP 接続数をカウントします。

    2. Messenger Express または IMAP のユーザーの、最後のログイン時刻とログアウト時刻を取得します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

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

    次の選択肢が考えられますが、これに限られません。

    • アクティブなユーザーとアクティブでないユーザーをそれぞれのマシンから集めて、アクティブユーザーを集めたマシンと非アクティブユーザーを集めたマシンとに分けます。

      アクティブでないユーザーがアクティブなユーザーになる場合は、そのユーザーをアクティブなユーザーのマシンに移動します。このアプローチを採用すると、アクティブなユーザーとアクティブでないユーザーを同じマシンに置いた場合よりも、必要なハードウェアを減らすことができます。

    • ユーザーをサービスのクラス別に分けます。

      コントリビュータ、マネージャ、エグゼクティブのユーザーを、それぞれのサービスのクラス、権限、専門サービスに応じたメールストレージ容量の割り当てを提供するマシンに分けます。

  4. それぞれのメールボックスで使用されるストレージの量はどのくらいですか。

    メールボックスあたりのストレージの容量を測定するときには、指定した割り当てではなくメールボックスの実際の使用率で見積もります。ごみ箱内のメッセージもディスク容量と割り当てを消費します。

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

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

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

    • メールシステムのエンドユーザーに対して送信される数

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

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

  7. 異なるサイズ範囲では、配信分布状態はどのようになっていますか。

    例:

    • 5K バイト未満

    • 5K バイト以上 10K バイト未満

    • 10K バイト以上 100K バイト未満

    • 100K バイト以上 500K バイト未満

    • 500K バイト以上 10M バイト未満

    • 10M バイト以上

    配信されるメッセージのサイズがわからない場合は、メールシステムの平均のメッセージサイズを使用しますが、これはサイズの範囲がわかる場合ほど有効ではありません。

    メッセージのサイズは、MTA の配信レート、メッセージストアへの配信レート、メッセージ取得のレート、およびウィルス対策用またはスパム防止用のフィルタの処理に影響を与えるため、特に重要なものです。

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

    たとえば、ある組織では、ピーク時間中に IMAP 接続の 20 パーセントで SSL が使用されます。

  9. 何らかの SSL 暗号化アクセラレータハードウェアを使用する予定がありますか。

  10. ウィルススキャニングまたはその他の専用のメッセージ処理を使用し、その処理をすべてのユーザーに適用しますか。

    Messaging Server の設定により、MTA は専用の処理で指定された基準に一致するすべてのメッセージをスキャンする必要があり、その結果システムの負荷が増大します。

  11. POP ユーザーに対し、メールへのアクセス可能頻度を制限するポリシーを適用しますか。適用する場合、どのくらいの頻度にしますか。

  12. IMAP ユーザーに対し、標準のクライアントを強制しますか。それとも、各ユーザーが選択できるようにしますか。

    IMAP クライアント数が増加するとサーバーへの同時接続数も増加します。したがって、多くのフォルダを開いているパワーユーザーは、多くの同時接続を使用している可能性があります。

  13. ユーザーがフォルダを共有できるようにしますか。共有できるようにする場合、すべてのユーザーに許可しますか。それとも一部のユーザーにだけ許可しますか。

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

その他の質問

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

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

    たとえば、高可用性の実現を考えている場合です。どれくらいの停止時間であれば許容範囲であるかを検討してください。また、クラスタリングテクノロジが必要かどうかも検討してください。

  2. どのようなバックアップ戦略と回復戦略 (障害回復、メールボックスの復元、サイトのフェイルオーバーなど) を実行しますか。回復タスクが完了するまでにどのくらいの時間を予想しますか。

  3. DMZ を使って内部ネットワークと外部ネットワークを分離する必要がありますか。すべてのユーザーが内部ネットワークを使用していますか。それとも、一部のユーザーはインターネットを使って接続しますか。

    プロキシサーバー (MMP、MEM) と独立した MTA 層が必要になる可能性があります。

  4. 応答時間の要件を記述してください。スループットの要件を記述してください。

  5. リソースの使用条件を具体的に記述してください。CPU 使用率は平均 80 % でかまいませんか。それとも、80 % はピーク時のみですか。

  6. メッセージングサーバーをいくつかの地理的に異なる場所に設置しますか。ユーザーのメールが地理的に分散配置される可能性はありますか。

  7. アーカイブを使ってメールメッセージをある一定期間保管しておく必要がありますか。

  8. すべてのメッセージをロギングする法律上の必要性がありますか。送受信されたすべてのメッセージのコピーを保存しておく必要がありますか。

メッセージングユーザーベースの定義

使用率プロファイルの作成が完了したら、次にそれをこの節で説明されている定義済みのユーザーベースの例と比較してみます。「ユーザーベース」は、ユーザーが送受信するメッセージサイズの範囲と、ユーザーが実行するメッセージング操作のタイプで構成されます。メッセージングユーザーは、5 つのユーザーベースに分類されます。

この節のユーザーベースの例では、ユーザーの行動を幅広く一般化しています。特定の使用率プロファイルは、このユーザーベースとは多少異なるかもしれません。これらの差異は、負荷シミュレータを実行するとき (「Messenger Express 負荷シミュレータの使用」を参照) に調整できます。

軽量級の POP ユーザー

軽量級の POP ユーザーベースは、一般に、簡単なメッセージング要件を持つ家庭のダイアルアップユーザーで構成されます。それぞれの並行クライアント接続は、1 時間あたり約 4 件のメッセージを送信します。これらのユーザーは、1 回のログインセッション中にすべてのメッセージの読み取りと削除を行います。さらに、これらのユーザーは 1 回の受信では、自分のメッセージの作成と送信をほとんど行いません。メッセージの約 80 パーセントが 5K バイト以下のサイズで、約 20 パーセントが 10K バイト以上です。

重量級の POP ユーザー

重量級の POP ユーザーベースは、高速ブロードバンドのユーザーか小規模な企業のアカウントであるのが一般的で、軽量級の POP ユーザーベースよりメッセージに関して高度な要件を持っています。このグループは、ケーブルモデムか DSL を使用してサービスプロバイダに接続します。それぞれの並行クライアント接続は、1 時間あたり約 6 件のメッセージを送信します。メッセージ受信者数の平均は 1 メッセージあたり約 2 人です。メッセージの 65 パーセントが、5K バイト以下のサイズです。このユーザーベースのメッセージの 30 パーセントが、5K バイトから 10K バイトの間のサイズです。5 パーセントのメッセージが 1M バイトを超えるサイズです。ユーザーのうち、85 パーセントが読んだ後ですべてのメッセージを削除しています。ただし、15 パーセントのユーザーは、メッセージをサーバー上に残したまま数回のログインを行なってから、メッセージを削除しています。メールは、これらのメールボックスのわずかな割合を占めるだけです。同じメッセージがサーバーから数回取得される場合もあります。

軽量級の IMAP ユーザー

軽量級の IMAP ユーザーベースは、高速なブロードバンドインターネットサービスを利用するユーザーに代表されます。このユーザーが利用するサービスには、メッセージ検索やクライアントフィルタのような高度なメッセージングシステム機能のほとんどが含まれます。このユーザーベースは、メッセージのサイズ、受信者の数、それぞれの並行接続別の送受信メッセージ数に関して、重量級の POP ユーザーベースに類似しています。軽量級の IMAP ユーザーは一般的に、一度のログインでセッションを数時間継続し、ログアウトする前にほとんどまたはすべてのメールを削除します。その結果、ログインセッション中にメールが蓄積されますが、通常はメールボックスに 20 から 30 件以上のメッセージが蓄積されることはありません。ほとんどの受信ボックスで、残っているメッセージの数は 10 件以下です。

標準的な IMAP ユーザー

標準的な IMAP ユーザーベースは、高度な企業ユーザーに代表され、営業日にはログインセッションがほぼ 8 時間継続します。これらのユーザーは、大量のメールの送受信と保管を行います。さらに、これらのユーザーの場合、メッセージの割り当ては無制限か、またはかなり大きなものとなります。受信ボックスには大量のメールが 1 日中蓄積されていき、溢れそうになったときにはすべて、または一部が消去されます。メッセージは定期的にフォルダに整理され、1 時間に何度かの割合で検索されます。それぞれの並行クライアント接続は、1 時間あたり約 8 件のメッセージを送信します。このカテゴリのユーザーの場合、送信する 1 件のメッセージの平均受信者数は 4 人で、同じメッセージサイズを重量級の POP および軽量級の IMAP のユーザーベースとして混在させます。

標準的な Messenger Express/Communications Express ユーザー

標準的な Messenger Express/Communications Express ユーザーベースは、標準的な IMAP に似ています。このユーザーベースのメッセージのサイズは、標準的な IMAP、軽量級の IMAP、および 重量級の POP ユーザーと同じです。メッセージの配信頻度も標準的な IMAP ユーザーと同じです。

組織内で、特に複数のクライアントアクセス手段を提供する場合は、おそらく複数のユーザーベースを持つことになります。ユーザーベースをこれらのカテゴリの中から決定したら、使用率プロファイルと「Messenger Express 負荷シミュレータの使用」で説明されている負荷シミュレータを使用して、そのユーザーベースのテストを行います。

Messenger Express 負荷シミュレータの使用

Messaging Server のパフォーマンスを測定するには、メッセージングユーザーベース (「メッセージングユーザーベースの定義」を参照) およびメッセージングの使用率プロファイル (「メッセージングの使用率プロファイルの作成」を参照) を負荷シミュレータへの入力として使用します。

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

Procedure負荷シミュレータを使用するには

手順

  1. テストするユーザーベース (軽量級の IMAP など) を定義します。

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

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

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

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

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

    注 –

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

Messaging Server システムパフォーマンスの評価

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

Messaging Server のメモリー使用率

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

少なくとも、1 つの CPU あたり 1G バイトのメモリーを用意してください。ほとんどの配備で、UltraSPARC® III システムの CPU 1 つにつき 2G バイトのメモリーが必要になります。

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

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

ディスク I/O を、帯域幅ではなく IOPS (1 秒あたりの I/O の合計) で測定することをお勧めします。システムがきわめて短い応答時間 (10 ミリ秒未満) で処理できる、個別のディスクトランザクションの数を測定する必要があります。

Messaging Server のディスク容量

サーバーシステムのディスク容量を計画する際には、環境ソフトウェア、Messaging Server ソフトウェア、およびメッセージの内容を運用するための容量、さらにトラッキングのための容量を確実に含める必要があります。可用性が要求される場合には、必ず外部ディスクアレイを使用します。ほとんどのシステムで、内部システムディスクでは 4 台までのディスクしかサポートされないため、パフォーマンスを向上させるには外部ディスクが必要となります。

メッセージストアパーティションでは、全メッセージの合計サイズに 30 % のオーバーヘッドを加えたストレージサイズが必要です。

さらに、ユーザーディスク容量を割り当てます。この容量は、通常、サイトのポリシーに従って決定されます。

注 –

配備計画には、障害回復のためのメッセージストアのバックアップ方法を含める必要があります。Messaging Server では、Solstice Backup (Legato Networker)、imsbackup ユーティリティ、およびファイルシステムスナップショットバックアップがサポートされています。バックアップメディアを遠隔地に格納した方がよい場合もあります。バックアップは、サーバーの処理に影響しない範囲で、できるだけ頻繁に実行することをお勧めします。

MTA メッセージキューのディスクサイズ決定

Messaging Server の MTA キューの動作は、配信されるのを待機しているメッセージ用の一時記憶域を提供することです。保証されたサービス提供を維持するために、メッセージは持続的方式でディスクに書き込まれます。メッセージを配信できない場合、MTA は最終的に断念してメッセージを送信者に戻すまで再試行します。

メッセージキューのパフォーマンス

MTA キューのディスクサイズ決定は、MTA のパフォーマンスを改善するための重要なステップです。MTA のパフォーマンスは、ほかのどのシステムリソースにもましてディスク I/O に直接影響されます。したがって、複数のディスクスピンドルで構成されるディスクボリュームを計画することをお勧めします。これらのディスクスピンドルは、ディスク RAID システムを使用して連結およびストライプ化されます。

MTA のパフォーマンスに問題があると、エンドユーザーはすぐにその影響を受けます。ユーザーが電子メールクライアントの「送信」ボタンを押すとき、MTA はメッセージがメッセージキューにコミットされるまで、メッセージの受信を完全には受理しません。したがって、メッセージキューのパフォーマンス改善は、エンドユーザーの立場から見ると応答時間の短縮につながります。

メッセージキューの可用性

SMTP サービスは、保証されたメッセージ配信サービスであると考えられます。これは、サービスが配信しようとしているメッセージを途中で失わないことを、メッセージングサーバーがエンドユーザーに対して保証するという意味です。MTA キューシステムを設計するときは、メッセージが失われないことを保証するためにあらゆる努力を払う必要があります。この保証は通常、さまざまな RAID 技術を使用して、冗長化されたディスクシステムを実装することによって達成されます。

メッセージキューの利用可能なディスクサイズの決定

次のいずれかの条件が発生した場合、キューのサイズは非常に大きくなります。

次節以降で、これらの問題について説明します。

ネットワーク接続の問題に備えた計画

ネットワーク接続の問題により、MTA がメッセージを配信できない場合があります。そのような場合、定義された再試行間隔に従って MTA が配信を再開できるようになるまで、メッセージはキューに格納されます。

そのような中断に備えたディスク領域の計画は、「メッセージキューのサイズ決定の一般則」という単純なルールに基づいて行います。

  1. 配信が予測される 1 分あたりの平均メッセージ数を決定します (N)。

  2. メッセージの平均サイズ (K バイト) を決定します (S)。

  3. 典型的なネットワーク接続障害の最大持続時間 (分) を決定します (T)。

ディスクキューサイズを見積もるための式は次のようになります。

ディスクキューサイズ (K バイト) = N x S x T

MTA の配信再試行設定の調整

システムがメッセージをまったく配信できなくなることがあります。この状態では、MTA は配信を再試行するまでの一定期間 (再試行間隔として定義された期間)、メッセージをメッセージキューに保留します。この状態は、MTA が配信を断念してメッセージを送信者に戻すまで続きます。メッセージが配信できなくなる理由の多くは予測不可能です。メッセージが配信できない理由には、ネットワーク接続の問題、送信先サーバーのビジー状態、ネットワークの混雑などさまざまなものがあります。

ビジー状態のサーバー上では、高ボリュームアクティビティの期間中、このような一時的に格納されるメッセージが大量に蓄積される可能性があります。大量の蓄積によって、ディスク容量の問題が発生する可能性があります。そのような蓄積を防ぐには、より短い間隔で配信を再試行するように MTA を調整します。

再試行間隔は、imta.cnf ファイルの「Channel Block」設定で設定します。このファイルの構造としては、書き換えルールとチャネルブロックの 2 つの部分から構成されています。チャネルブロックは、特定のディスクキューと、それに関連するプロセスの動作を定義します。ここでの説明に関係するのは tcp_local チャネルです。tcp_local チャネルは、企業のローカルネットワークの外部のサイト、すなわち、インターネットを経由した場所への配信を提供します。

tcp_local チャネルの再試行間隔は当初、デフォルトチャネルブロックによって設定されます。デフォルトチャネルブロックを使用すると、設定を複製することによって設定の繰り返しを防ぐことができます。

デフォルトチャネルブロックの例を次に示します。


defaults notices 1 2 4 7 copywarnpost copysendpost postheadonly
noswitchchannel immnonurgent maxjobs 7 defaulthost
red.siroe.com red.siroe.com

チャネルブロックの構造の先頭はチャネル名です。前述の例において、これは、これらの設定を持たないチャネルに適用されるデフォルトチャネルブロックです。2 番目の部分はチャネルキーワードのリストです。

notices キーワードは、メッセージ配信通知 (MDN) が送信者に返送されるまでに経過可能な時間を指定します。このキーワードは notices キーワードで始まり、それに続けて、再試行期間を設定する一連の数値を指定します。デフォルトでは、MTA は配信を再試行し、送信者に通知を返送します。これらの通知は「ポストマスター」からエンドユーザーの受信箱に送られます。

この例では、MTA は 1 日、2 日、および 4 日を経過するタイミングで配信を再試行します。7 日経過すると、MTA はメッセージを送信者に戻し、そのメッセージを配信失敗とみなします。

多くの場合、MTA のデフォルト設定で適切なパフォーマンスが得られます。場合によっては、メッセージキュー用のディスク領域不足などのリソース枯渇の可能性を回避するため、MTA を調整する必要があります。これは製品の制限ではなく、ハードウェアおよびネットワークリソースを含めた Messaging Server システム全体の制限です。

ディスクサイズに関して起こりうるこれらの問題を考慮すると、ユーザー数の多い配備では、あまり短い間隔でメッセージ配信を試みるのは好ましくない場合があります。そのような状況に該当する場合は、次に示すドキュメントを参考にしてください。

参考資料

詳細については、次のマニュアルを参照してください。

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

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

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

Messaging Server の CPU リソース

メッセージストア、MTA、および複合サービス (MMP および Messenger Express マルチプレクサ) だけを実行しているシステムに対して、十分な CPU を用意します。さらに、使用を計画している RAID システムにも十分な CPU を用意します。

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

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

以降の節で、2 層と 1 層のアーキテクチャーを配備する場合のサイズ決定で考慮しなければならないことについて説明します。

注 –

アーキテクチャー計画の詳細については、第 11 章「Messaging Server アーキテクチャーの開発」を参照してください。

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

2 層アーキテクチャーでは、Messaging Server 配備を 2 つの層に分割します。1 つはアクセス層、もう 1 つはデータ層です。簡略化した 2 層アーキテクチャーでは、MMP と MTA をアクセス層に追加します。MMP が POP と IMAP メールリーダーのプロキシとして機能し、MTA が送信されたメールのリレーを行います。データ層には、メッセージストアと Directory Server を配置します。図 10–1 は簡略化した 2 層アーキテクチャーを示しています。

図 10–1 簡略化した Messaging Server の 2 層アーキテクチャー

この図は、アクセス層とデータ層による 2 層アーキテクチャーの配備を示します。

1 層アーキテクチャーに対して、2 層アーキテクチャーには、サイズの決定に影響を与えるかもしれないいくつかのメリットがあります。2 層アーキテクチャーでは次のことが可能です。

次のいくつかの節で、2 層配備における特定のコンポーネントのサイズ決定方法について説明します。

Procedureメッセージストアのサイズ決定

メッセージストアのサイズ決定の目的は、ストアが処理可能な最大並行接続数を確認し、1 秒間にストアに配信されるメッセージの数を決定することです。

手順

  1. 負荷シミュレータを使って集めた数値をもとに、マシン 1 台あたりのストアマシン数と並行接続数を決定します。サイズ決定ツールの詳細については、「Messenger Express 負荷シミュレータの使用」を参照してください。

  2. それぞれのストアマシンに必要なストレージの容量を決定します。

  3. バックアップとファイルシステム回復時の復元で必要な場合は、複数のストアパーティションまたはストアマシンを使用します。

    ご購入先のクライアントサービス担当者に、メッセージストアのユーザーの推奨最大数を尋ねてください。推奨数値を得るには、次の点を理解しておく必要があります。

    • 使用率のパターン (「Messenger Express 負荷シミュレータの使用」を参照)。

    • 配備内のハードウェアすべてのアクティブなユーザーの最大数。

    • バックアップ、復元、回復に要する時間。これらの時間は、メッセージストアのサイズが大きくなるにつれて長くなります。

Procedureインバウンド MTA とアウトバウンド MTA のサイズを決定するには

一般的には、MTA サービスはインバウンドサービスとアウトバウンドサービスとに分けます。次に、同じ方法でそれぞれのサイズを決定できます。MTA のサイズ決定の目的は、1 秒間にリレーできるメッセージの最大数を決定することです。

インバウンド MTA のサイズを決定するには、実稼働環境でのインバウンド MTA の raw パフォーマンスを知る必要があります。

手順

  1. インバウンド MTA の raw パフォーマンスをもとに、SSL、ウィルススキャニングプロセス、その他の臨時のメッセージ処理を追加します。

  2. 1 日のピークボリューム時のサービス拒否攻撃についても考慮します。

  3. 十分な量の MTA を追加して、負荷分散と必要に応じた冗長性を確保します。

    冗長性を持たせることで、1 つ以上のタイプのマシンで、スループットや応答時間に実質的な影響を与えることなくピーク負荷を処理できます。

    さらに、一時的なメッセージの量に対して十分なディスク容量を計算して、ネットワーク上の問題やリモート MTA の機能停止に備えます。

Procedure複合サービスのサイズを決定するには

MMP と MEM のサイズを決定する場合には、システム負荷、特に MMP に対する POP と IMAP の並行接続数と、MEM に対する HTTP 接続数に基づいて計算を行います。

注 –

ここでの手順は、MEM と MMP が同じマシンにインストールされていることを前提にしています。

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

手順

  1. 必要に応じて、MMP と MMP のSSL 用に CPU またはハードウェアアクセラレータを追加します。

  2. マシンに MEM を設定している場合は、メモリを追加します。

  3. MMP の SMTP プロキシにディスクを追加します。

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

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

    インバウンド MTA ルーターの場合と同様に、配備に冗長性を持たせることでスループットや応答時間に実質的な影響を与えることなく、各タイプの 1 台以上のマシンでもピーク負荷を処理します。

単一層 Messaging Server アーキテクチャー

単一層アーキテクチャーは、アクセス層とデータ層に分割されていません。MTA、メッセージストア、そして場合によっては Directory Server が 1 つの層にインストールされます。図 10–2 は単一層アーキテクチャーを示します。

図 10–2 簡略化した Messaging Server の単一層アーキテクチャー

この図は、メッセージストア、Directory Server、MTA、およびメールクライアントによる簡略化した 1 層配備を示します。

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

ProcedureMessaging Server の単一層アーキテクチャーのサイズを決定するには

手順

  1. 「2 層 Messaging Server アーキテクチャー」でのサイズ決定と同様に、メッセージストアのサイズを決定します。

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

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

  4. SMTP 接続数の増加に対応してディスクを追加します。

  5. アウトバウンド MTA ルーター用のディスクを追加します。

    注 –

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