test

Sun Java Communications Suite 5 配備計画ガイド

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 の機能停止に備えます。

ProcedureMMP のサイズを決定するには

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

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

  1. SSL 用に CPU またはハードウェアアクセラレータを追加します。

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

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

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

    インバウンド 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 層アーキテクチャーにおけるメッセージングコンポーネントのサイズ決定に関する特別な手順については、ご購入先のクライアントサービス担当者に連絡してください。