正確なサイズ決定には、負荷の測定が不可欠です。「使用率プロファイル」により、Messaging Server ホスト上のプログラムとプロセスが実行する要素が決定されます。
この節では、使用率プロファイルを作成して、配備で発生する負荷の量を測定する方法について説明します。
使用率プロファイルを作成するには、次の質問に答えてください。
システムのユーザー数は何人ですか。
システムのユーザー数を数える時には、メールアカウントを持ちメールシステムにログインできるユーザーだけでなく、メールアカウントを持っているが、現在システムにはログインしていないユーザーも含めます。特に、次に示しているアクティブなユーザーとアクティブでないユーザーとの相違点に注意してください。
ユーザー数が 300 以下のきわめて小規模な配備の場合は、サイズ決定戦略の計画でこのプロセスを実行する必要はありません。クライアントサービス担当者と作業を行い、個別のニーズについて判断します。
POP、IMAP、および Messenger Express クライアントがサービスにアクセスするピークボリューム時に、システムへの接続数はどのくらいになりますか。
特に、サポートするそれぞれのクライアントアクセスサービスの並行接続、アイドル接続、ビジー接続の数に注意します。
配備における「並行接続」の数は、次のいずれかの方法で決定します。
UNIX プラットフォームで netstat コマンドを使用して、確立された TCP 接続数をカウントします。
Messenger Express または IMAP のユーザーの、最後のログイン時刻とログアウト時刻を取得します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。
大規模な配備を行う場合には、ユーザーをどのように組織化しますか。
次の選択肢が考えられますが、これに限られません。
アクティブなユーザーとアクティブでないユーザーをそれぞれのマシンから集めて、アクティブユーザーを集めたマシンと非アクティブユーザーを集めたマシンとに分けます。
アクティブでないユーザーがアクティブなユーザーになる場合は、そのユーザーをアクティブなユーザーのマシンに移動します。このアプローチを採用すると、アクティブなユーザーとアクティブでないユーザーを同じマシンに置いた場合よりも、必要なハードウェアを減らすことができます。
ユーザーをサービスのクラス別に分けます。
コントリビュータ、マネージャ、エグゼクティブのユーザーを、それぞれのサービスのクラス、権限、専門サービスに応じたメールストレージ容量の割り当てを提供するマシンに分けます。
それぞれのメールボックスで使用されるストレージの量はどのくらいですか。
メールボックスあたりのストレージの容量を測定するときには、指定した割り当てではなくメールボックスの実際の使用率で見積もります。ごみ箱内のメッセージもディスク容量と割り当てを消費します。
インターネットからどれぐらいの数のメッセージがメッセージングシステムに送信されますか。
メッセージの数は、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。
ユーザー別ではどれぐらいの数のメッセージが送信されますか。
メールシステムのエンドユーザーに対して送信される数
インターネットに対して送信される数
このメッセージの数も、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。
異なるサイズ範囲では、配信分布状態はどのようになっていますか。
例:
5K バイト未満
5K バイト以上 10K バイト未満
10K バイト以上 100K バイト未満
100K バイト以上 500K バイト未満
500K バイト以上 10M バイト未満
10M バイト以上
配信されるメッセージのサイズがわからない場合は、メールシステムの平均のメッセージサイズを使用しますが、これはサイズの範囲がわかる場合ほど有効ではありません。
メッセージのサイズは、MTA の配信レート、メッセージストアへの配信レート、メッセージ取得のレート、およびウィルス対策用またはスパム防止用のフィルタの処理に影響を与えるため、特に重要なものです。
SSL/TLS を使用しますか。使用する場合は、ユーザーの何パーセントが、またどのようなタイプのユーザーが使用しますか。
たとえば、ある組織では、ピーク時間中に IMAP 接続の 20 パーセントで SSL が使用されます。
何らかの SSL 暗号化アクセラレータハードウェアを使用する予定がありますか。
ウィルススキャニングまたはその他の専用のメッセージ処理を使用し、その処理をすべてのユーザーに適用しますか。
Messaging Server の設定により、MTA は専用の処理で指定された基準に一致するすべてのメッセージをスキャンする必要があり、その結果システムの負荷が増大します。
POP ユーザーに対し、メールへのアクセス可能頻度を制限するポリシーを適用しますか。適用する場合、どのくらいの頻度にしますか。
IMAP ユーザーに対し、標準のクライアントを強制しますか。それとも、各ユーザーが選択できるようにしますか。
IMAP クライアント数が増加するとサーバーへの同時接続数も増加します。したがって、多くのフォルダを開いているパワーユーザーは、多くの同時接続を使用している可能性があります。
ユーザーがフォルダを共有できるようにしますか。共有できるようにする場合、すべてのユーザーに許可しますか。それとも一部のユーザーにだけ許可しますか。
これらの質問に答えることで、配備のための、準備段階としての使用率プロファイルが完成します。Messaging Server のニーズの変更に応じて、この使用率プロファイルにも修正を加えます。
次の質問は使用率プロファイルの作成に使用できるものではありませんが、配備のサイズ決定戦略には重要なものです。これらの質問にどのように答えるかによって、ハードウェアの追加を検討しなければならなくなる場合もあります。
配備にどの程度の冗長性を持たせますか。
たとえば、高可用性の実現を考えている場合です。どれくらいの停止時間であれば許容範囲であるかを検討してください。また、クラスタリングテクノロジが必要かどうかも検討してください。
どのようなバックアップ戦略と回復戦略 (障害回復、メールボックスの復元、サイトのフェイルオーバーなど) を実行しますか。回復タスクが完了するまでにどのくらいの時間を予想しますか。
DMZ を使って内部ネットワークと外部ネットワークを分離する必要がありますか。すべてのユーザーが内部ネットワークを使用していますか。それとも、一部のユーザーはインターネットを使って接続しますか。
プロキシサーバー (MMP、MEM) と独立した MTA 層が必要になる可能性があります。
応答時間の要件を記述してください。スループットの要件を記述してください。
リソースの使用条件を具体的に記述してください。CPU 使用率は平均 80 % でかまいませんか。それとも、80 % はピーク時のみですか。
メッセージングサーバーをいくつかの地理的に異なる場所に設置しますか。ユーザーのメールが地理的に分散配置される可能性はありますか。
アーカイブを使ってメールメッセージをある一定期間保管しておく必要がありますか。
すべてのメッセージをロギングする法律上の必要性がありますか。送受信されたすべてのメッセージのコピーを保存しておく必要がありますか。