|
| |
| Sun Java System Messaging Server 6 2004Q2 配備計画ガイド | |
第 3 章
メッセージングアーキテクチャの開発この章では、Messaging Server 配備のアーキテクチャの設計方法について説明します。
この章には、以下の節があります。
メッセージングシステムアーキテクチャの目的すぐれたメールシステムアーキテクチャでは、電子メールが埋め込まれたサウンド、画像、ビデオファイル、HTML 形式、Java アプレット、デスクトップアプリケーションと共に迅速に配信され、将来のアップグレードへの対応とスケーラビリティを提供します。単純化すると、Messaging Server アーキテクチャは以下の機能を備える必要があります。
電子メールシステムの中心は Messaging Server で、これはメッセージの送信と配信に使用されるコンポーネントの集合体です。Messaging Server のコンポーネントとは別に、電子メールシステムでは LDAP サーバーと DNS サーバーも必要となります。多くの企業には既存の LDAP サーバーとデータベースが存在し、それらは Messaging Server と共に利用できます。そうでない場合、Java Enterprise System が提供する LDAP サーバー (Sun Java System Directory Server) を利用することができます。DNS サーバーは、電子メールシステムを配備する前に配置しておく必要があります。
この章の後半では、効率的でスケーラブルなメッセージングシステムの設計に使われた Messaging Server のコンポーネントと Messaging Server ソフトウェアアーキテクチャについて説明します。
効率性とスケーラビリティ以外にも、いくつかの要素が Messaging Server アーキテクチャに影響を与えます。これらの要素を次に示します。
これらについては、後の節で説明します。
Messaging Server のソフトウェアアーキテクチャ図 3-1 は、スタンドアロンな Messaging Server を簡略化して示しています。この特別な配備は、サイズの都合でサーバーの個別のコンポーネントが省略されていますので、そのまま使うことはお勧めできません。
図 3-1 スタンドアロンな Messaging Server の簡略化したコンポーネント表示
前の図は、以下の Messaging Server ソフトウェアコンポーネントを示します。
- メッセージ転送エージェントまたは MTA: SMTP プロトコルを使用して、メールメッセージの受信、ルーティング、転送、および配信を行う。MTA は電子メール配信者のように、メッセージを電子メールボックスまたは別の MTA に配信する
- メッセージストア: メールクライアントのメッセージの保管、取得、および操作を行うコンポーネントで構成される。メールは POP クライアント、IMAP クライアント、または HTTP クライアントにより取得される。POP クライアントは、メッセージをクライアントマシンにダウンロードして、読み出しと保管を行う。IMAP クライアントと HTTP クライアントは、サーバー上でメッセージの読み出しと保管を行う。メッセージストアは、電子メールボックスのようにユーザーのためのメールの保管と取得を行う
- LDAP ディレクトリ: Messaging Server のメールディレクトリ情報の保管、取得、および配信を行う。これには、ユーザーのルーティング情報、配信リスト、設定データ、および電子メールの配信とアクセスのサポートに必要なその他の情報などがある。LDAP ディレクトリは、電子メールアドレス、エイリアス、ルーティング情報、パスワード、および MTA または メッセージストアがメッセージの配信と取得を行うのに必要なその他の情報のディレクトリである
- DNS サーバー: ドメイン名を IP アドレスに変換する。このコンポーネントは Messaging Server をインストールする前に必要となる
簡略化した Messaging Server システムをパススルーするメッセージ
インターネットまたはローカルクライアントからの受信メッセージは、Simple Mail Transport Protocol (SMTP) を通じて MTA によって受信されます。内部アドレスの場合、すなわち Messaging Server ドメイン内の場合は、MTA はメッセージをメッセージストアに配信します。外部アドレスの場合、すなわち Messaging Server ドメイン外の場合は、MTA はメッセージをインターネット上の別の MTA にリレーします。
Messaging Server の前のバージョンのように、メールを UNIX システムでのみ使用される /var/mail ファイルシステムに送信することは可能ですが、ローカルメッセージは通常、より最適化された Messaging Server メッセージストアに配信されます。次に、IMAP4、POP3、または HTTP メールクライアントプログラムがメッセージを取得します。
ディレクトリサーバーは、アドレス、代替メールアドレス、メールホストのようなローカルユーザーとグループの配信情報の格納と取得を行います。MTA はメッセージを受信すると、このアドレス情報を使用してメッセージの配信先と配信方法を決定します。
メッセージを格納するだけでなく、メッセージストアはディレクトリサーバーを使用して、メールクライアントがメールにアクセスする場合のユーザーのログイン名とパスワードの検証も行います。ディレクトリには、割り当て制限、デフォルトのメッセージストアタイプなどの情報も格納されます。
メールクライアントからの送信メッセージは MTA に直接送られ、そこでインターネット上の適切なサーバーに送信されます。アドレスがローカルの場合は、MTA はメッセージをメッセージストアに送信します。
新規ユーザーとグループは、ディレクトリにユーザーとグループを追加することで作成されます。エントリは、ユーザー管理ユーティリティを使用するか、LDAP を使用してディレクトリを変更することで作成および変更できます。
Messaging Server コンポーネントは、管理サーバーコンソールによって管理されています。さらに、Messaging Server にはコマンド行インタフェースと設定ファイルも用意されています。Messaging Server ホストに接続されたマシンで、管理者が適切なアクセスを行った場合には、管理タスクを実行できます。より一般的な管理タスクとしては、メールシステムへのユーザーやグループの追加、変更、削除や、MTA、ディレクトリサーバー、およびメッセージングストアの操作の設定があります。
メッセージ転送エージェント (MTA)
MTA は、Messaging Server に宛てられたインターネットメールメッセージのルーティング、転送、および配信を行います。メールフローは、チャネルと呼ばれるインタフェースを通じて行われます。チャネルは、チャネルプログラムのペアと一連の設定情報とで構成されます。図 3-2 にそのプロセスを示します。チャネルを個別に設定し、アドレスに基づいてメールを特定のチャネルに送ることもできます。
図 3-2 チャネルアーキテクチャ
それぞれのチャネルは、最大 2 つまでのスレーブプログラムと呼ばれるチャネルプログラムで構成されます。このプログラムは、チャネルに送信されてくるメールを処理します。マスタープログラムは、チャネルから送信されるメールを処理します。チャネルに関連付けられた 1 つ以上のインタフェースに送られるメッセージを格納するための送信メッセージキューもあります。チャネルプログラムは、以下の 2 つの機能の 1 つを実行します。
チャネルの設定は、imta.cnf 設定テキストファイルを使用して行います。チャネル設定を通じて、さまざまなチャネルキーワードを設定してメッセージの処理方法を制御できます。チャネルキーワードは、パフォーマンスの調整とシステムのレポーティング面に影響を与えます。たとえば、複数のチャネルを定義してトラフィックをグループ別または部門別に分類し、メッセージサイズを制限してトラフィックを制限し、業務のニーズに応じて配信ステータス通知ルールを定義します。診断属性もチャネル単位で設定可能です。かなりの数の設定パラメータが、チャネルベースで設定可能です。詳細は、『Sun Java System Messaging Server 管理ガイド』を参照してください。
Messaging Server には、以下のような数多くのチャネルがデフォルトで用意されています。
- SMTP チャネル : TCP/IP ベースのメッセージ配信と受信を有効にする。マスターチャネルとスレーブチャネルが用意される
- LMTP チャネル : MTA から メッセージストアへのメッセージの直接ルーティングを有効にする。これらのチャネルは、SMTP ではなく LMTP を使用してメッセージストアと通信を行う
- パイプチャネル : 代替メッセージ配信プログラムで使用する。メッセージをユーザーの受信ボックスに直接送るのではなく、メールソーターのようなプログラムへの配信を行う
- ローカルチャネル : メールを /var/mail に配信する。古い UNIX メールクライアントとの互換性を提供する
- 再処理チャネル : 再送信されたメッセージの処理に便利に使われる
- 再組立チャネル : メッセージの一部を再度組み立てて、MIME message/partial content type をサポートする元の完全なメッセージにする
- 変換チャネル : メッセージを本文ごとに変換する。アドレスの再書き込みまたはメッセージの再フォーマットに便利に使われる
MTA の概念の詳細については、『Sun Java System Messaging Server 管理ガイド』を参照してください。
ダイレクト LDAP 検索
バージョン 5.2 以前の Messaging Server は、dirsync モードで実行されていました。dirsync モードでは、MTA が使用するユーザーとグループに関するディレクトリ情報は、ディレクトリキャッシュと総称される数多くのファイルとデータベースを通じてアクセスされていました。データそのものは LDAP ディレクトリに格納されていましたが、実際の情報はキャッシュからアクセスされていました。キャッシュ内のデータは、LDAP ディレクトリへの変更を監視してそれに伴ってファイルとデータベースを更新する dirsync プログラムにより更新されていました。
Messaging Server 5.2 からは、MTA を設定して LDAP サーバーから情報を直接検索できるようになりました。このダイレクト検索により、LDAP が予想する通常のクエリのタイプを使用することで、LDAP を有効に利用できます。ダイレクト検索により MTA と LDAP サーバー間の関係が、よりスケーラブルで、若干高速で、より自由に設定できるようになります。LDAP クエリの結果は設定可能なサイズと時間でプロセスにキャッシュされるため、パフォーマンスの調整が可能です。詳細は、『Sun Java System Messaging Server 管理ガイド』を参照してください。
Messaging Server 6.0 の導入に伴い、dirsync のサポートは終了し、削除されています。
書き換えルール
メールは、ドメイン書き換えルール または省略用の書き換えルールが適用された宛先アドレスに基づいて、チャネルにルーティングされます。書き換えルールは、アドレスを真のドメインアドレスに変換し、それに対応するチャネルを決定するのに使用されます。これらのルールは、トランスポートレイヤーとメッセージヘッダーの両方に表示されるアドレスを書き換えるのに使用されます。トランスポートレイヤーは、メッセージのエンベロープです。ルーティング情報はユーザーには見えない形で含まれていますが、実際の情報はメッセージを適切な受信者に配信するのに使用されます。
書き換えルールとチャネルのテーブルは、協力してそれぞれのアドレスの処置を決定します。書き換えプロセスの結果により、アドレスとルーティングシステム、すなわちメッセージが送信されるシステム (チャネル) が書き換えられます。ネットワークのトポロジ次第で、ルーティングシステムはメッセージが宛先までにたどるパスの最初のステップである場合もあれば、最終の宛先システムである場合もあります。
書き換えプロセスが終了すると、imta.cnf ファイルのチャネル部分に対してルーティングシステムの検索が行われます。それぞれのチャネルには、チャネルに関連付けられた 1 つ以上のホスト名があります。ルーティングシステム名がそれぞれのホスト名と比較されて、メッセージがどのチャネルのキューに入れられるかが決定されます。次に簡単な書き換えルールを示します。
example.com $U%example.com@tcp_siroe-daemon
このルールは、ドメイン example.com のアドレスにだけ一致します。一致したアドレスは、以下に示すテンプレート $U%$D を使用して、に書き換えることができます。
このように、wallaby@thor.example.com の形式のメッセージが wallaby@example.com に書き換えられ、tcp_siroe-daemon と呼ばれるチャネルに送信されます。
書き換えルールは、マッピングテーブル、LDAP ディレクトリ検索、およびデータベース参照に基づいて、高度な置換を行うこともできます。暗号のようなわかりにくいものになる場合もありますが、書き換えルールが低レベルで動作し、処理サイクルへの直接のオーバーヘッドがほとんどない点が便利です。書き換えルールの詳細と書き換えプロセスで利用できる機能については、『Sun Java System Messaging Server 管理ガイド』を参照してください。
ジョブコントローラ
ジョブコントローラは、マスター、ジョブコントローラ、送信側の制御と、チャネルプログラムのキューからの削除を行います。ジョブコントローラは、メッセージキューを制御し、実際のメッセージ配信を行うプログラムを実行するプログラムです。ジョブコントローラは、マルチスレッドプロセスとして実行され、Messaging Server システムで常に実行されている数少ないプロセスの 1 つです。チャネル処理ジョブ自体は、ジョブコントローラにより作成されますが、一時的なジョブで、実行する作業がない場合は存在しなくなります。
ジョブコントローラを設定して、チャネル処理プログラムのインスタンスが少なくとも 1 つ常駐するかどうかを決めることができます。多くの場合、すぐに実行する作業がない場合でも、ジョブコントローラは少なくとも 1 つのサービスプログラムのインスタンスが常に存在するように設定されます。それ以外の場合は、行う作業がなくなるまで何らかの作業の実行を継続する期間を設定するインスタンスがあります。
スレーブチャネルは、外部の誘発要因に応答し、ジョブコントローラに新しく作成されたメッセージファイルを通知します。ジョブコントローラは、この情報を内部データ構造に入力し、必要に応じてそのメッセージを処理するマスターチャネルジョブを作成します。ジョブコントローラで、現存しているチャネルジョブが新しく作成されたメッセージファイルを処理できるように設定されている場合は、このジョブを作成する必要はありません。マスターチャネルジョブは、ジョブが開始されると、ジョブコントローラからメッセージ割り当てを取得します。メッセージの処理を終了すると、マスターチャネルはその処理のステータスに応じてジョブコントローラを更新します。そのステータスは、メッセージが正常にキューから削除されたか、メッセージの再配信スケジュールが組まれたかのいずれかになります。ジョブコントローラは、メッセージの優先度と失敗した配信に関する情報を維持し、チャネルジョブに優先的なスケジュールを許可します。ジョブコントローラは、各ジョブの状態の追跡も行います。ジョブの状態は、アイドル、アイドルの時間、ジョブがビジーであるかどうかです。状態の追跡により、ジョブコントローラはチャネルジョブの最適なプールを維持できます。
Local Mail Transfer Protocol (LMTP)
Sun ONE Messaging Server 6.0 リリースでは、複数階層配備におけるメッセージストアに配信を行う LMTP 設定が可能になりました。受信リレーとバックエンドメッセージストアが使用されるこのような環境では、アドレス拡張、自動返信や転送などの配信方法、およびメーリングリストの拡張などに関してリレーが重要な役割を果たします。バックエンドストアへの配信はこれまで SMTP 上で行われてきました。SMTP では、バックエンドシステムで LDAP ディレクトリの受取人アドレスを再度調べる必要があるため、MTA の全機能が使用されます。速度と効率性を向上するために、MTA では SMTP ではなく LMTP を使用してバックエンドストアにメッセージを配信できます。詳細は、『Sun Java System Messaging Server 管理ガイド』を参照してください。
注
Messaging Server への LMTP の実装は、汎用的な目的で行います。Messaging Server の LMTP は、2 階層アーキテクチャの Messaging Server MTA と メッセージストアコンポーネントとの間でだけ使用できます。1 つのマシンで構成される 1 階層アーキテクチャでは、LMTP は使用できません。
メッセージストア
メッセージストアは、インターネットメールメッセージの配信、取得、および操作のための専用のデータストアです。メッセージストアは IMAP4 および POP3 クライアントアクセスサーバーと共に動作し、サーバーにアクセスしてメッセージへの柔軟で容易なアクセスを提供します。メッセージストアは Webmail サーバーでも動作し、Web ブラウザにメッセージング機能を提供します。詳細については、この節のほかに、『Sun Java System Messaging Server 管理ガイド』を参照してください。
メッセージストアは、フォルダのセットまたはユーザーのメールボックスとして構成されます。フォルダまたはメールボックスは、メッセージのコンテナです。それぞれのユーザーには、新しく受信したメールが入る INBOX があります。それぞれのユーザーには、メールを格納できる 1 つ以上のフォルダがあります。フォルダには、他のフォルダを階層構造で含めることができます。個別のユーザーが所有するメールボックスは非公開フォルダです。非公開フォルダは、所有者の意志で、同じメッセージストア内の他のユーザーと共有できます。6.0 リリースでは、Messaging Server は複数のストア間でのフォルダの共有をサポートしています。
メッセージストアには、ユーザーファイルとシステムファイルの 2 つの一般領域があります。ユーザー領域では、それぞれのユーザーの INBOX の位置が 2 階層ハッシングアルゴリズムを使用して決定されます。それぞれのユーザーのメールボックスまたはフォルダは、その親フォルダ内の別のディレクトリとして表されます。それぞれのメッセージは、MIME 形式標準を使用してプレーンテキストで保存されます。フォルダ内に大量のメッセージがある場合は、システムによりフォルダのハッシュディレクトリが作成されます。ハッシュディレクトリを使用することで、フォルダに大量のメッセージがある場合にファイルシステムが抱える負担が軽減されます。メッセージストアでは、メッセージ自体のほかに、メッセージヘッダー情報の索引とキャッシュ、およびその他の頻繁に使用されるデータが維持されるため、クライアントはメールボックスの情報を迅速に取得し、個別のメッセージファイルにアクセスすることなく一般的な検索を実行できます。
メッセージストアには、多くのメッセージストアパーティションを含めることができます。メッセージストアパーティションは、ファイルシステムボリュームに格納されます。ファイルシステムがいっぱいになると、それらのファイルシステムボリューム上に、追加のファイルシステムボリュームとメッセージストアパーティションを作成できます。
メッセージストアは、パーティションごとにメッセージそれぞれのコピーを 1つずつだけ維持します。これは、シングルコピーメッセージストアとも呼ばれます。メッセージストアが複数のユーザー、グループ、または配信リストに宛てられたメッセージを受信した場合、それぞれのユーザーの INBOX にそのメッセージへの参照を追加します。メッセージのコピーをそれぞれのユーザーの INBOX に保存しないというより、メッセージストアでは同じデータの複製を保存しないようにしています。既読、返信済み、削除などの個別メッセージステータスのフラグは、それぞれのユーザーのフォルダごとに維持されます。
システム領域には、メッセージストア全体の情報が Berkeley データベース形式で格納されており、高速なアクセスを実現しています。システム領域内の情報は、ユーザー領域から再構築できます。Sun ONE Messaging Server 5.2 以降の製品には、データベーススナップショット機能があります。必要な場合には、データベースを元の状態に迅速に回復できます。現在の Messaging Server には、高速回復機能も追加されており、データベースが破損した場合には、データベース再構築のために長い時間待つことなく、メッセージストアをシャットダウンして、すぐに元の状態に戻すことができます。
メッセージストアは、IMAP 割り当て (QUOTA) 拡張 (RFC2087) をサポートしています。割り当ての拡張は有効にすることも無効にすることもできます。ユーザー割り当ては、バイト数またはメッセージ数を使用して設定できます。しきい値を設定して、割り当てがしきい値に達した場合には、ユーザーに警告を出すこともできます。ユーザーが割り当てを超過した場合は、猶予期間中の新規メッセージは保留され、再試行されます。猶予期間の後で、割り当てを超過したユーザーに送信されたメッセージは、未送信通知と共に送信者に返されます。
割り当てを使用する特別なアプリケーションで、ユーザーの割り当てステータスに関係なくメッセージが配信されなければならない場合には、保証メッセージ配信チャネルがあります。このチャネルは、割り当てステータスに関係なくすべてのメッセージを配信するのに使用できます。割り当て使用率のレポートと割り当て警告の送信を行うユーティリティも用意されています。
Directory サービス
Messaging Server は、Sun Java System Directory Server にバンドルされています。Directory Server は、Lightweight Directory Access Protocol (LDAP) ディレクトリサービスです。Directory Server は、Messaging Server の運用に不可欠な情報のための中央リポジトリを提供します。この情報には、ユーザープロファイル、配信リスト、およびその他のシステムリソースなどが含まれます。
ディレクトリ情報ツリー
ディレクトリは、ディレクトリ情報ツリー (DIT) として知られるツリー形式でデータを格納します。DIT は、ツリーの最上部に 1 つの主要ブランチがあり、その下にブランチおよびサブブランチがある階層構造です。DIT は、組織のニーズに合わせた配備の設計を可能にする柔軟性を備えています。たとえば、実際の業務組織構造に従った DTI の配置を選択することも、業務の地理的なレイアウトに従って選択することもできます。また、使用する DNS レイヤーに 1 対 1 でマッピングした DIT を設計することもできます。実稼動後の DIT の変更は大変な作業となるため、DIT の設計は慎重に行ってください。
DIT は、幅広い管理シナリオに適応する柔軟性も備えています。DIT は、集中型でも分散型でも管理できます。集中型の管理では、1 つの権限で DIT 全体を管理します。集中型管理の場合は、DIT 全体を 1 つのメールサーバー上に配置して使用します。分散型管理では、複数の権限で DIT を管理します。通常は、DIT がいくつかの部分、サブツリー、または異なるメールサーバーに分割された場合に分散型管理を用います。
DIT が大規模な場合、またはメールサーバーが地理的に分散されている場合は、DIT の一部の管理を委託することも検討します。通常は、DIT のそれぞれのサブツリーを管理する権限を割り当てます。Messaging Server では、1 つの権限で複数のサブツリーの管理が可能です。ただしセキュリティ上の理由で、権限は、その権限が所有する DIT のサブツリーの変更だけが可能となっています。
Identity Server が使用されない場合に Messaging Server が使用するデフォルトのスキーマは、Identity Server が使用するスキーマとは異なります。Messaging Server は、Sun Java System LDAP スキーマ 1 および 2 をサポートしており、スキーマの切り替えと移行も可能です。詳細は、第 7 章「Messaging Server スキーマとプロビジョニングオプションの理解」を参照してください。
ディレクトリのレプリケーション
Directory Server は、レプリケーションをサポートしており、冗長性と効率性を実現するさまざまな設定が可能です。1 つのホストから別のホストへの DIT の全部または一部をレプリケーションすることで、以下の設定機能が利用できます。
ディレクトリのレプリケーション、ディレクトリパフォーマンスの調整、DIT 構造と設計の詳細については、以下の場所にある Sun Java System Directory Server のマニュアルを参照してください。
2 階層アーキテクチャの理解2 階層アーキテクチャにより、スケーラビリティと信頼性のために最適化された設計が可能になります。単独のホストでメッセージングシステムのすべてのコンポーネントを実行する代わりに、2 階層アーキテクチャでは、コンポーネントを異なるマシンに分割します。このようなコンポーネントの分割により、特別な専用機能が実行されます。たとえば、追加のメッセージストレージが必要になるとか、より多くの送信リレーが必要になるなど、特定の機能コンポーネントの負荷が増大すると、サーバーを追加して増大する負荷に対応できます。
2 階層アーキテクチャは、アクセスレイヤーとデータレイヤーで構成されます。アクセスレイヤーは、配備の中で配信、メッセージアクセス、ユーザーログイン、および認証を処理する部分です。データレイヤーは、すべてのデータを維持する部分です。これには、LDAP マスターサーバーと、ユーザーメッセージを格納するよう設定された Messaging Server マシンが含まれます。
図 3-3 は、簡略化した 2 階層アーキテクチャの説明です。
図 3-3 2 階層 Messaging Server アーキテクチャ
以下でこれらの機能部分について説明します。
公衆アクセスネットワーク : Messaging Server を内部ユーザーとインターネットに接続するネットワークです。それぞれの配備で独自のネットワーク要件が定義されますが、基本的な Messaging Server の要件は、SMTP、POP、IMAP、および HTTP のような標準のプロトコルを使用したエンドユーザーとインターネットへの接続性です。
プライベートデータネットワーク : このネットワークは、公衆アクセスネットワークと Messaging Server データの間で、セキュリティで保護された接続を提供します。セキュリティで保護されたアクセスレイヤーと、サービス全体のディレクトリ、メッセージデータセンター、および個人アドレスブック (PAB) サーバーが含まれるデータレイヤーで構成されます。
LDAP ディレクトリサーバー : ユーザーベースに関する情報の格納と取得に使用されるディレクトリサーバーです。ユーザーとグループエイリアス、メールホスト情報、配信設定などを格納します。設計の要件次第で、システムの同一ディレクトリを複数格納することも可能です。図 3-3 は、マスターディレクトリと 2 つのレプリカを示します。LDAP ディレクトリサーバーは、Messaging Server 製品の一部として提供されます。希望する場合は、既存のディレクトリのデータも使用できます。この例では、ユーザーとグループのデータを既存のディレクトリから取得し、それを Sun Java System Directory Server ディレクトリ内に置きます。既存のディレクトリのデータ形式は、Messaging Server スキーマに準拠している必要があります。
メッセージストア : ユーザーメールを保持し、格納します。「バックエンド」とも呼ばれます。メッセージストアは、IMAP サーバー、POP サーバー、および Messenger Express (Webmail) サーバーのような Message Access Component も参照します。図 3-3 は、2 つのメッセージストアを持つ配備を示します。必要に応じて、さらにストアを追加することもできます。
個人アドレスブック (PAB) サーバー : Messenger Express のユーザーアドレスの格納と取得を行います。
DNS サーバー : ホスト名を IP アドレスにマップします。DNS サーバーは、メッセージを外部ホストにルーティングする時に、どのホストに接続するかを判断します。内部的には、DNS は実際のサービスをマシン名にマップします。DNS サーバーは、Messaging Server 製品ラインの一部ではありません。Messaging Server をインストールする前に、稼働状態の DNS サーバーをインストールする必要があります。
サーバーロードバランサ : ネットワーク接続について、均一にバランスを取るか、複数のサーバーにアルゴリズムを適用してバランスを取ります。ロードバランサを使用すると、1 つのネットワークアドレスで多数のサーバーを表すことができるため、トラフィックのボトルネックを解消し、トラフィックフローの管理と高いレベルのサービス保証が可能になります。図 3-3 では、2 つのロードバランサを使用しています。1 つのバランサは MMP に接続され、もう 1 つは MTA 送信リレーに接続されています。ロードバランサは Java Enterprise System 製品ラインの一部ではありません。ロードバランサをメッセージストアまたはディレクトリマスター上で使用することはできません。ロードバランサは、MMP、MEM、Communications Express、受信 MTA または送信 MTA、ディレクトリコンシューマ、Messaging Server の MTA を使用しない Brightmail 製品、Brightmail サーバーに接続して使用します。
MTA 受信リレー : 外部 (インターネット) サイトからのメッセージを受信し、それをローカルのメッセージストアサーバーにルーティングする専用 MTA です。この MTA は外部からの最初のコンタクトポイントとなるため、MTA 受信リレーには、権限のないリレーを防ぎ、スパムをフィルタリングし、サービス拒否攻撃に対抗する機能が追加されます。
MTA 送信リレー : 内部または認証されたユーザーからのメールだけを受け取り、それをその他の内部ユーザーまたは外部 (インターネット) ドメインにルーティングする MTA です。単独のマシンを受信リレーと送信リレーとして使用できますが、インターネットに接続された大規模な配備では、これらの機能を 2 つの別のマシンに分割します。このようにすると、内部クライアントは、外部サイトから受信するメールと競合することなく、メールを送信できます。
送信リレーに内部配信をさせないようにする、別のルーティングオプションもあります。送信リレーは、ユーザーベースからの内部宛てのメールを単にルーティングのインスタンスとして認識し、そのようなメッセージをすべて受信 MTA に送信します。
Delegated Administrator サーバー : ユーザーと管理者のための GUI 管理コンソールを提供します。Delegated Administrator を使用して、ユーザーはパスワードの変更、休暇通知メールの設定などを行うことができます。管理者は、ユーザーの追加や削除など、より高度な管理タスクを行うことができます。Delegated Administrator は、現在スキーマ 1 の環境でのみ動作します。
Messaging Multiplexor または Mail Message Proxy または MMP : ユーザーのメールボックスを含む特定のマシンと、関連付けられた DNS 名との結合を解除して、複数の物理マシンにわたるメッセージストアの拡張を可能にします。クライアントソフトウェアは、メッセージストアのある物理的なマシンを知る必要はありません。このようにすると、ユーザーは、メールボックスが新しいマシンに移動されるたびにホストメッセージストアの DNS 名を変更する必要がなくなります。POP クライアントまたは IMAP クライアントがメールボックスへのアクセスを要求すると、プロキシはディレクトリサービスを参照してユーザーのメールボックスがある場所を検索し、そのメールボックスがある Messaging Server システムに要求を転送します。
Messenger Express Multiplexor : Webmail 用の HTTP アクセスサービスへの単一の接続ポイントとして機能する特別なサーバーです。すべてのユーザーがこのメッセージングプロキシサーバーに接続し、ここで該当するメールボックスに転送されます。このため、メールユーザーには複数の Messaging Server が単一のホスト名であるかのように表示されます。Messaging Multiplexor (MMP) は POP および IMAP サーバーに接続しますが、Messenger Express Multiplexor は HTTP サーバーに接続します。つまり、Messenger Express Multiplexor と Messenger Express との関係は、MMP と POP や IMAP との関係と同じです。
2 階層アーキテクチャメッセジングデータフロー
この節では、メッセージングシステム経由のメッセージフローについて説明します。メッセージフローがどのように機能するかは、実際のプロトコルとメッセージパス次第です。
メールの送信 : 内部ユーザーから別の内部ユーザーへ
概要 : 内部ユーザー -> ロードバランサ -> MTA 送信リレー 1 または 2 -> MTA 受信リレー 1 または 2 -> メッセージストア 1 または 2
内部ユーザーから別の内部ユーザー (すなわち同じ電子メールシステムのユーザー) へ宛てられたメッセージは、最初にロードバランサに送られます。ロードバランサは、基盤となるサイトアーキテクチャから電子メールユーザーを切り離し、高可用性電子メールサービスを提供します。ロードバランサは、その接続を MTA 送信リレー 1 または 2 のいずれかに送信します。送信リレーはアドレスを読み取り、メッセージが外部ユーザー宛てのものか内部ユーザー宛てのものかを判断します。外部ユーザー宛ての場合は、そのメッセージをインターネットに送信します。内部ユーザー宛ての場合は、MTA 受信リレー 1 または 2 に送信するか、設定によっては適切なメッセージストアに直接送信します。MTA 受信リレーは、そのメッセージを適切なメッセージストアに配信します。メッセージストアはそのメッセージを受け取り、メールボックスに配信します。
メールの取得 : 内部ユーザー
概要 : 内部ユーザー -> ロードバランサ -> MMP/MEM/Communications Express Proxy Server 1 または 2 -> メッセージストア 1 または 2
メールは POP、HTTP、または IMAP のいずれかを使用して取得されます。ユーザー接続がロードバランサに受信され、MMP、MEM、または Communications Express サーバーのいずれかに転送されます。次にユーザーは、接続したアクセスマシンにログイン要求を送信します。アクセスレイヤーのマシンは、ログイン要求とパスワードを検証し、ユーザー接続で指定されたものと同じプロトコルを使用して、適切なメッセージストア (1 または 2) に要求を送信します。そしてアクセスレイヤーのマシンは、クライアントとサーバー間の残りの接続を仲介します。例外は、進行中のユーザー要求を処理しているレベルの Communications Express にブラウザのレンダリングを処理させる場合です。
メールの送信 : 内部ユーザーから外部 (インターネット) ユーザーへ
概要 : 内部ユーザー -> ロードバランサ -> MTA 送信リレー 1 または 2 -> インターネット
内部ユーザーから外部ユーザー (すなわち異なる電子メールシステムのユーザー) へ宛てられたメッセージは、最初にロードバランサに送られます。ロードバランサは、電子メールユーザーを基盤となるサイトアーキテクチャから切り離し、高可用性電子メールサービスを提供します。ロードバランサは、メッセージを MTA 送信リレー 1 または 2 に送信するか、設定によっては適切なメッセージストアに直接送信します。送信リレーはアドレスを読み取り、メッセージが外部ユーザー宛てのものか内部ユーザー宛てのものかを判断します。外部ユーザー宛ての場合は、そのメッセージをインターネット上の MTA に送信します。内部ユーザー宛ての場合は、MTA 受信リレー 1 または 2 に送信します。MTA 受信リレーは、そのメッセージを適切なメッセージストアに配信します。メッセージストアはそのメッセージを受け取り、適切なメールボックスに配信します。
メールの送信 : 外部 (インターネット) ユーザーから内部ユーザーへ
概要 : 外部ユーザー -> MTA 受信リレー 1 または 2 -> メッセージストア 1 または 2
外部ユーザー (インターネット) から内部ユーザーへのメッセージは、MTA 受信リレー 1 または 2 (ロードバランサは不要) に送られます。受信リレーはアドレスを読み取り、メッセージが外部ユーザー宛てのものか (インターネットリレーが許可されている場合) 内部ユーザー宛てのものかを判断します。外部ユーザー宛ての場合は、受信リレーはそのメッセージをインターネット上の別の MTA に送信します。内部ユーザー宛ての場合は、受信リレーは LDAP 検索を使用して メッセージストア 1 または 2 のいずれに送信するかを判断し、それに従って配信します。メッセージストアはそのメッセージを受け取り、適切なメールボックスに配信します。
水平スケーラビリティと垂直スケーラビリティの理解スケーラビリティは、メッセージングサービスの利用拡大に対応する配備の能力です。スケーラビリティにより、ユーザー数の急激な拡大をシステムがどのように受け入れられるかが決まります。またスケーラビリティにより、たとえば 1 か月の間にユーザーの多くが SSL の使用を希望するなどというような、ユーザーの行動の大きな変化にシステムがどのようにうまく適応できるかも決まります。
この節では、個別のサーバーとサーバー全体でサービスの拡大を吸収するために、アーキテクチャに追加する機能について確認します。以下のトピックについて説明しています。
水平的スケーラビリティの計画
水平スケーラビリティは、アーキテクチャにサーバーを追加することがどの程度容易であるかを示します。ユーザー数が拡大する、またはユーザーの行動が変化するにつれて、やがては既存のアーキテクチャのリソースを最大化しなければならなくなります。慎重に計画を立てて、アーキテクチャのスケールを適切に拡張する方法を決めます。
アーキテクチャの水平的拡張を行う場合には、リソースを複数のサーバーに分散します。水平スケーラビリティでは、2 つの方法が使用されます。
複数サーバーへのユーザーベースの分散
負荷を複数のサーバーに分散するには、クライアントのメールをいくつかのバックエンドメッセージストアに均等に分割します。ユーザーをアルファベット順に分けたり、サービスのクラス別、部門、または物理的な場所別に分けたりして、特定のバックエンドメッセージストアホストに割り当てます。
Messaging Multiplexor (MMP) は、複数のサーバーの受信クライアント接続を処理するマルチスレッドサーバーです。MMP は POP 接続または IMAP 接続を受け入れ、LDAP 検索を実行して認証を行い、その接続を適切なメッセージングサーバーにルーティングします。HTTP 接続では、Messenger Express Multiplexor (MEM) を有効にして、複数のサーバーの受信クライアント接続を処理します。Communications Express も同様に機能します。
MMP と Messenger Express Multiplexor は、管理を容易にする目的でしばしば同じマシンに置かれます。図 3-4 は、ユーザーが複数のバックエンドサーバーに分割され、受信クライアント接続の処理に Multiplexor を使用するサンプルアーキテクチャを示します。
図 3-4 複数サーバーへのユーザーベースの分散
ユーザーをバックエンドサーバーに分散することで、MMP または MEM を使用するかぎり、ユーザーの管理が簡単になります。ユーザーは、メールがある 1 つのバックエンドサーバーに接続するため、すべてのユーザーに対して設定を標準化できます。この設定により、複数のサーバーの管理も容易になります。また、Messaging Server ホストへの要求増加に対応して、ホストをシームレスに追加できます。
冗長コンポーネントへのリソース分散
電子メールが、組織の日々の運営上、重要な地位を占める場合は、メッセージングシステムが常に運用可能な状態であることを確実にするために、ロードバランサ、MX レコードのような冗長コンポーネントとリレーが必要になります。
以下の図は、リソースを冗長 MTA リレーに分散した例です。インターネットリレー、受信 MTA、送信 MTA のような同じコンポーネントのセットが、図 3-4 で使用されています。ただしこのケースでは、それぞれ 2 つずつが配備されています。
図 3-5 冗長コンポーネントへのリソース分散
冗長 MTA リレーを使用することで、あるコンポーネントが動作不能に陥っても、別のコンポーネントが常に使用可能な状態にあります。また、リソースを冗長 MTA リレーに分散することで、負荷の分散も行われます。たとえば、以前は 1 つのリレーが管理していた負荷が、2 つのインターネットリレーに分散されます。この冗長性により、Messaging Server システムにフォールトトレランスも提供されます。それぞれの MTA リレーが、他の MTA リレーの機能を受け持ちます。
冗長ネットワーク接続をサーバーとメールリレーにインストールすることで、ネットワークの問題に対するフォールトトレランスが実現します。メッセージング配備が組織にとってより重要なものであるほど、フォールトトレランスと冗長性の検討もより重要になります。
MX レコード、リレー、およびロードバランサの詳細については、以下の節で説明します。
MX レコード
等しい優先度の MX レコードにより、メッセージが冗長化されたインターネットリレーと受信 MTA、送信 MTA にルーティングされます。たとえば、送信 MTA は、relayA.siroe.com と relayB.siroe.com に対応する siroe.com の MX レコードを検索します。優先度が同じためにこれらのリレーの 1 つがランダムに選択され、SMTP 接続が開かれます。最初に選択されたリレーが応答しなかった場合は、メールは別のリレーに送信されます。以下の MX レコードの例を参照してください。
リレー
Messaging Server ホストがそれぞれ多数のユーザーをサポートしており、SMTP メールの送信負荷が高い場合、メールリレーを使用することで Messaging Server ホストはルーティングタスクから開放されます。異なるリレーを指定して、それぞれにメッセージの送信と受信を処理させることで、さらに負荷の分散を図ることもできます。
受信リレーと送信リレーの両方が、1 つの In/Out SMTP リレーホストとして組み合わされる場合もあります。1 つまたは複数のリレーホストが必要であるかどうかを判断するには、アーキテクチャ全体の受信および送信メッセージのトラフィック特性を確認します。
ロードバランサ
ロードバランサを使用すると、負荷を複数のサーバーに分散して、どれか 1 つのサーバーでも過負荷状態にならないようにします。ロードバランサは、クライアントからの要求を受けて、各サーバーの CPU とメモリの使用率を追跡するようなアルゴリズムを使用して、利用可能なサーバーに要求をリダイレクトします。ロードバランサは、共通サーバーで実行されるソフトウェアとして、純粋に外部のハードウェアソリューションとして、またはハードウェアとソフトウェアを組み合わせたパッケージとして使用可能です。
垂直スケーラビリティの計画
垂直スケーラビリティは、CPU の追加など、個々のサーバーマシンへのリソースの追加に関係があります。それぞれのマシンには、一定の負荷を処理できる能力があります。一般には、リソースに制限があるか、配備の拡大に応じて追加のハードウェアを購入できない場合に、配備における垂直スケーラビリティを検討します。
配備の垂直的スケールを行うには、以下のことが必要です。
高可用性に向けた計画高可用性は、計画された停止時間と予期しない停止時間を短時間にとどめるための配備の設計です。通常、高可用性設定は緩やかに結合された 2 つ以上のシステムで構成されたクラスタです。各システムがそれぞれのプロセッサ、メモリ、オペレーティングシステムを持っています。ストレージはシステム間で共有されます。特別なソフトウェアがシステムをバインドし、単一点での障害からシステムが完全に自動的に回復できるようにします。Messaging Server には、SunTM Cluster サービスと Veritas® クラスタリングソリューションをサポートする高可用性のオプションが用意されています。
高可用性に向けた計画を作成する場合は、可用性とコストとのバランスを検討する必要があります。一般に、より可用性の高い配備では、設計と運用のコストも高くなります。
高可用性は、アプリケーションサービスの中断や停止時間によるデータアクセス機会の損失に対する保険です。アプリケーションサービスが利用不能になった場合、組織は収入、顧客、その他の機会を失うことになります。組織にとっての高可用性の価値は、停止時間のコストに直接関係します。停止時間のコストが高くなるほど、高可用性のための追加コストを正当化するのも容易になります。また、一定のレベルの可用性を保証するサービスレベル契約を組織が結んでいる場合もあります。可用性の目標を達成できない場合、財務的な打撃を直接受ける可能性があります。
詳細は、第 10 章「サービス可用性に向けた計画」を参照してください。
Messaging Server アーキテクチャのパフォーマンスの考慮事項この節では、Messaging Server コンポーネントのパフォーマンス特性を評価して、正確なアーキテクチャの開発を行う方法について説明します。
この節では以下の内容について説明します。
メッセージストアのパフォーマンスの考慮事項
メッセージストアのパフォーマンスは、以下のようなさまざまな要素に影響を受けます。
前の要素リストは、メッセージストアに影響を与えるおおよその順序で記載されています。メッセージストレージに関するパフォーマンス問題のほとんどは、ディスクの入出力能力が不十分なことに原因があります。さらに、物理ディスク上のストアのレイアウトもパフォーマンスに影響を与えます。より小規模のスタンドアロンシステムでは、単純なディスクのストライピングでも十分な入出力が得られます。ほとんどの大規模システムでは、ファイルシステムを分離し、ストアのさまざまな部分に入出力を提供します。
メッセージングサーバーのディレクトリ
Messaging Server は 5 つのディレクトリを使用して大量の入出力活動に対応しています。これらのディレクトリは高頻度でアクセスされるため、ディレクトリごとにディスクを用意するか、より理想的には、ディレクトリごとに RAID を用意します。以下の表で、これらのディレクトリについて説明します。
以下の節では、Messaging Server の高頻度アクセスディレクトリについてさらに詳しく説明します。
MTA キューディレクトリ
非 LMTP 環境では、MTA キューディレクトリは高頻度で使用されます。LMTP は、受信メッセージが MTA キューに置かれず、ストアに直接挿入されるように機能します。このメッセージの挿入により、メッセージストアマシンの全体的な入出力要件が少なくなり、メッセージストアマシンの MTA キューディレクトリの使用頻度が大きく減少します。システムがスタンドアロンの場合、または Webmail 送信のためのローカル MTA を使用する場合は、送信メールトラフィックのために、まだかなりの入出力が発生します。LMTP を使用した適切な 2 階層環境では、このディレクトリは軽い頻度で使用される程度です。Messaging Server の前のバージョンでは、大規模なシステムではこのディレクトリをそれ自身のストライプまたはボリューム上に設定する必要がありました。
ログファイルディレクトリ
ログファイルディレクトリでは、設定されているログのレベルにより、さまざまな量の入出力が要求されます。メッセージストアのその他の高入出力要求とは異なり、ログディレクトリへの入出力は非同期です。典型的な配備シナリオでは、LUN 全体をログ専用には使用しません。かなり規模の大きなストア配備、または大量のログが必要な環境では、専用の LUN を使用するのが理に適っています。
ほとんどすべての環境で、メッセージストアをデータ喪失から守る必要があります。要求される喪失からの保護と継続的な可用性のレベルは、RAID5 のような単純なディスク保護から、ミラーリング、日常的なバックアップ、リアルタイムのデータ複製、リモートデータセンターまで、さまざまです。データの保護に関しても、Automatic System Recovery (ASR) が可能なマシンから、ローカル HA 機能、自動リモートサイトフェイルオーバーまで、さまざまなものがあります。これらの決定は、ハードウェアの量とサービスの提供に必要なサポート要員の数に影響します。
mboxlist ディレクトリ
mboxlist ディレクトリには入出力が非常に集中しますが、特にサイズが大きいというわけではありません。mboxlist には、ストアとトランザクションログで使用される Sleepycat (Berkeley) データベースがあります。高頻度の入出力があり、それを分割できないことから、大規模な配備では mboxlist ディレクトリをそれ自身のストライプかボリューム上に配置する必要があります。これは、メッセージストアの多くの操作が Sleepycat データベースにアクセスするため、垂直的スケーラビリティの喪失の原因にもつながります。アクセスが激しいシステムでは、これがボトルネックになります。mboxlist ディレクトリの入出力パフォーマンスのボトルネックによって、ストアの raw パフォーマンスと応答時間が悪くなるだけでなく、垂直的スケーラビリティも減少します。バックアップから高速に回復することが要求されるシステムでは、このディレクトリを Solid State Disks (SSD) 上に配置するか、パフォーマンスの高いキャッシングアレイを使って、ファイルシステム上でサービスを継続したまま障害回復処理を進行できるような高い書き込みレートを許可します。
複数のストアパーティション
メッセージストアは、複数のストアパーティションをサポートしています。各パーティションを、それ自身のストライプまたはボリューム上に配置します。ストア上に配置するパーティションの数は、さまざまな要素により決定されます。明確な要素としては、サーバーのピーク負荷時の入出力要件があります。追加のストアパーティションとしてファイルシステムを追加することで、メールの配信や取得のためにサーバーで可能な IOPS (1 秒あたりの総入出力) を引き上げます。ほとんどの環境で、大きくて数が少ないストライプあるいは LUNS よりも、多数の小さなストライプあるいは LUNS のほうが、より大きな IOPS が得られます。
いくつかのディスクアレイを使用すると、アレイを 2 つの異なる方法で設定できます。それぞれのアレイを LUN として設定し、それをファイルシステムにマウントします。または、それぞれのアレイを LUN として設定し、それをサーバー上でストライプします。どちらも有効な設定です。ただし、複数のストアパーティション (小さいアレイでは 1 つのパーティション、または LUN のストライプセットをサーバーボリュームにした大きなアレイ上の複数のパーティション) は最適化と管理が容易です。
ただし、通常は raw パフォーマンスは、ストアパーティションの数を決定する場合の優先事項とはなりません。企業環境では、IOPS よりも容量のほうが重要となる場合が多いでしょう。また、LUN をソフトウェアストライプで設定し、1 つの大きなストアパーティションとすることも可能です。ただし、複数の小さなパーティションのほうが、一般に管理は容易です。ストアパーティションの数を決定する際に適切な最優先事項は、一般的には回復時間です。
ストアパーティションの回復時間は、いくつかのカテゴリに分類されます。
- 最初に、電源、ハードウェア、またはオペレーティングシステムの障害によるクラッシュからの回復と並行して、fsck が複数のファイルシステム上で動作する。HA プラットフォームで強く推奨され、要求されるジャーナリングファイルシステムを使用している場合は、この要素は小さなものとなる
- 2 番目に、バックアップおよび回復プロシージャが複数のストアパーティション上で並行して実行される。メッセージストアではすべてのストアパーティションで単独のデータベースが使用されているため、この並行動作は mboxlist ディレクトリの垂直的スケーラビリティにより制限される。ストアパーティションあたりの 1 つのスレッドの実行と並行して、ストアクリーンアッププロシージャ (expire および purge) が実行される
- 最後に、再ミラーリングまたは RAID 再同期プロシージャが、小さな LUN で高速に実行される。ここでは厳密なルールはないが、多くのケースでの推奨事項として、ストアパーティションは 10 個以上のディスクで構成すべきではない
ストレージアレイで使用されるドライブのサイズは、容量要件に対する IOPS 要件という問題になります。ほとんどの住居用 ISP POP 環境では、「より小さなドライブ」を使用します。大規模な割り当てによる企業配備では、「より大きな」ドライブを使用します (比較として、Sun ディスクアレイにおける小さなドライブは 36G バイト、大きなドライブは 73G バイト以上)。繰り返しになりますが、すべての配備は異なっており、一連の要件を個別に検討する必要があります。
メッセージストアのスケーラビリティ
マルチプロセスとマルチスレッドにより、メッセージストアは良好なスケール化がなされています。実際には、メッセージストアは 1 つのプロセッサから 4 つのプロセッサまで、一次直線形の比率を上回るスケール化が行われています。これは、4 つのプロセッサシステムは、1 つのプロセッサシステムを 4 つ合わせたものよりも大きな負荷を処理できることを意味します。メッセージストアは 4 から 12 のプロセッサ数についてもかなり直線形でスケール化されます。12 から 16 のプロセッサ数では、能力は増強されますが、直線形ではなくなります。LMTP を使用すると、同じサイズのストアシステムでサポートされるユーザー数は大きく増加しますが、メッセージストアの垂直的スケーラビリティはより制限されます。
MTA パフォーマンスの考慮事項
MTA のパフォーマンスは多くの要素に影響されます。影響を及ぼす要素には以下の項目が含まれますが、これらに限定されません。
MTA ルーターは CPU と入出力を集中的に使用します。MTA では、キューディレクトリ用とログディレクトリ用の 2 つの異なるファイルシステムが使用されます。小規模なホスト (4 プロセッサ以下) では、MTA ルーターとして機能し、これらのディレクトリを別のファイルシステムに分ける必要はありません。キューディレクトリでは、かなり大きい量で同期書き込みが行われます。ログディレクトリでは、小さな量の非同期書き込みが連続的に行われます。
ほとんどのケースで、ディスクサブシステムの MTA で冗長性を導入して、ディスクの障害時にメールデータが永久に失われることを回避したいと考えるでしょう。ディスクの障害は、ハードウェアの障害で最も起こる可能性の高いものです。これは、多くの内部ディスクを持つ外部ディスクアレイやシステムが最適だということを意味します。
MTA RAID のトレードオフ
外部 RAID コントローラデバイスとソフトウェアミラーによる JBOD アレイの使用との間にはトレードオフの関係があります。JBOD によるアプローチは、ハードウェアの購入という点では安価な場合がありますが、より多くのラックスペースと電力を必要とします。JBOD アプローチは、ソフトウェアによるミラーリングを行うことでサーバーのパフォーマンスを少し低下させ、一般的には保守コストも高くなります。ソフトウェア RAID5 は、パフォーマンスへの影響が非常に大きいため、代わりに使うことができません。そのため、RAID5 を使用する場合は、RAID5 キャッシングコントローラアレイを使用します。
MTA のスケーラビリティ
MTA ルーターでは、8 つを超えるプロセッサを使用できません。また、1 つから 4 つまでのプロセッサ数では、メッセージストアのように直線形以上の比率でスケール化されます。
MTA と高可用性
MTA ルーターを HA の制御のもとに置くのはあまりお勧めできません。しかし、それが保証されている環境では例外です。ハードウェアの障害時にも、メールの配信を短時間で指定した時間枠内で実行しなければならないという要件がある場合は、MTA を HA のソフトウェア制御のもとに配置します。ほとんどの環境では、ピーク負荷要件に対応できるように MTA の数を単純にいくつか増やします。これにより、1 つの MTA で障害が発生した場合でも、または大規模な配備環境で何らかの理由で複数の MTA ルーターの接続が遮断された場合でも、適切なトラフィックフローが生み出されます。
さらに、MTA の配置に関しては、MTA を常にファイアウォールに配置するよう配慮します。
メールメッセージプロキシ (MMP) パフォーマンスの考慮事項
MMP では、ログ以外の目的でディスク入出力が使用されることはありません。MMP は、CPU とネットワークに完全に結合されています。その他の Messaging Server コンポーネントとは異なり、MMP はマルチプロセスマルチスレッドの機能を備えていません。主要な実行コードは、シングルプロセスマルチスレッドです。したがって、MMP は十分にマルチプロセス化されていないため、その他のコンポーネントのようなスケール化はできません。
MMP では、5 つ以上のプロセッサは使用できません。また、2 つから 4 つのプロセッサ数でも直線形以下のスケール化となります。MMP には、2 つのプロセッサを備えたラックマウントのマシンが適しています。
その他のコンポーネントソフトウェア (MEM、Calendar Server フロントエンド、Communications Express Web Client、LDAP プロキシなど) を MMP と同じマシンに配置する配備を選択した場合は、4 つのプロセッサによる SPARC マシンによる配備の拡張を検討します。そのような構成を行うことにより、管理、パッチの導入、監視などが必要なマシンの総数を減らすことができます。
MMP のサイズは、接続レートとトランザクションレートにより決まります。POP のサイズ決定は、POP 接続がほとんどアイドル状態にならないため、きわめて明快です。POP 接続では、接続が行われ、作業が行われ、そして接続が遮断されます。IMAP のサイズ決定はより複雑です。IMAP では、ログインレート、並行レート、接続のビジー状態の起こり方について確認する必要があります。MMP も、接続の待ち時間と帯域幅に多少影響を受けます。MMP はメッセージストアからクライアントに送信されるデータのバッファとして機能するため、ダイアルアップ環境では、ブロードバンド環境の場合よりも並行して処理できるユーザーの数が少なくなります。
SSL の使用率が接続のかなりの割合を占める場合は、ハードウェアアクセラレータをインストールします。
MMP と高可用性
MMP は HA の制御のもとに配置してはなりません。個別の MMP には静的データはありません。可用性の高い環境では、1 つ以上の MMP マシンを追加して、1 つ以上の MMP が停止してもピーク負荷に対して十分な能力を確保します。Sun Fire BladeTM Server ハードウェアを使用する場合は、Blade ラックユニット全体が停止する可能性を考慮して、適切な冗長性の配備を計画します。
Messenger Express Multiplexor (MEM) パフォーマンスの考慮事項
MEM では、Webmail クライアントに対して中階層のプロキシが提供されます。このクライアントを使用して、ユーザーはブラウザを通じてメールにアクセスし、メールを作成できます。MEM のメリットは、メールを格納しているのはバックエンドサーバーであるにもかかわらず、エンドユーザーは MEM にだけ接続して、自分の電子メールにアクセスできることです。MEM は、ユーザーの LDAP 情報を通じて HTTP セッション情報とユーザープロファイルを管理することで、この機能を実現しています。2 番目のメリットは、すべての静的ファイルと LDAP 認証の状態が Messaging Server のフロントエンドに存在することです。このメリットにより、メッセージストアバックエンドからの Web ページレンダリングに関連した、CPU の追加要件が相殺されます。
MEM には、MMP と同じ特性が数多くあります。MEM は、5 つ以上のプロセッサでもスケール化を図ることができますが、ほとんどの環境では、そうしてもそれほどメリットはありません。また、将来的には、Webmail コンポーネントがメッセージストアから外され、Web サーバーのもとで Java サーブレットとして XML レンダリングを実行するアクセスレイヤーマシンに移されます。Java サーブレットは、現在 3 つ以上のプロセッサによるスケール化には対応していません。したがって、MEM 用には SPARC または Intel の 2 プロセッサマシンから選択するか、次世代のソリューションが利用可能になった時には、現在の 2 プロセッサによる MEM ハードウェアを別の用途に振り向けて小規模なマシンに交換することを想定します。
MMP と MEM は同じサーバーセット上に配置できます。そうすることのメリットとして、少数の MMP または MEM が必要な場合に、冗長性確保のために必要なハードウェアの追加を最小限に抑えることができます。MMP と MEM を同じサーバーセット上に配置することで生じる唯一のデメリットの可能性は、1 つのプロトコルに対するサービス拒否攻撃が別のプロトコルにも影響を与えることです。
ディスクストライプ幅の設定
ディスクストライピングを設定するときには、システムを通過するメッセージの平均サイズにストライプ幅を合わせます。128 ブロックのストライプ幅は、通常の使用には大きすぎて、パフォーマンスに悪影響を与えます。代わりに、8、16、32 ブロック (それぞれ 4、8、16K バイトのメッセージサイズの場合) の値を使用します。
メールボックスデータベースキャッシュサイズの設定
Messaging Server は、メールボックスデータベースの呼び出しを頻繁に行います。そのため、そのデータができるだけ迅速に返されることが重要です。メールボックスデータベースの部分をキャッシュ化すると、メッセージストアのパフォーマンスが改善されます。最適なキャッシュサイズを設定することで、メッセージストア全体のパフォーマンスを大きく向上させることができます。キャッシュのサイズは、configutil のパラメータ store.dbcachesize を使用して設定します。
メールボックスデータベースは、データページに格納されます。さまざまなデーモンにより stored、imapd、popd などのデータベースが呼び出されると、指定されたページがキャッシュに格納されているかどうかが、システムによりチェックされます。ページがキャッシュ内に存在する場合は、それがデーモンに渡されます。存在しない場合は、システムは 1 ページをキャッシュからディスクに書き戻し、指定されたページを読み込んでそれをキャッシュに書き込む必要があります。ディスクの書き込みと読み取り回数を減らすことはパフォーマンスの向上につながりますが、それだけに、キャッシュサイズを最適に設定することが重要となります。
キャッシュサイズが小さすぎる場合は、指定されたデータをディスクから必要以上の頻度で読み込む必要があります。キャッシュサイズが大きすぎる場合は、ダイナミックメモリ (RAM) が浪費され、ディスクとキャッシュの同期に余計な時間がかかります。これら 2 つの状況の中では、キャッシュが大きすぎる場合よりも小さすぎる場合の方が、より大きなパフォーマンスの低下を招きます。
キャッシュの効率性は、ヒットレートにより測定されます。ヒットレートは、データベースがキャッシュにより処理される時間の割合のことです。最適化されたサイズのキャッシュでは、ヒットレートは 99 パーセントに達します。すなわち、要求されたデータベースページの 99 パーセントが、ディスクから取得されることなくデーモンに返されます。設定の目標値は、要求されたデータの少なくとも 95 パーセントがキャッシュにより返されるページを、キャッシュが相当数保持できるようにすることです。キャッシュから返されるページが 95 パーセント未満の場合は、キャッシュサイズを大きくする必要があります。
キャッシュのヒットレートは、Sleepycat データベースコマンド db_stat を使用して測定できます。
例:
# /opt/SUNWmsgsr/lib/db_stat -m -h /var/opt/SUNWmsgsr/store/mboxlist
2MB 513KB 604B Total cache size.
1 Number of caches.
2MB 520KB Pool individual cache size.
0 Requested pages mapped into the process' address space.
55339 Requested pages found in the cache (99%).この例では、ヒットレートは 99 パーセントです。これは、キャッシュサイズが最適であるか、大きすぎることを示します。キャッシュサイズが大きすぎる場合は常に 99 パーセントとなります。これをテストするには、ヒットレートが 99 パーセント以下になるまでキャッシュサイズを小さくしていきます。ヒットレートが 98 パーセントになったら、データベースキャッシュサイズが最適化されたことを意味します。逆に、db_stat が 95 パーセント未満のヒットレートを示した場合は、store.dbcachesize を使用してキャッシュサイズを大きくします。
注
ユーザーベースが変化すると、ヒットレートも変化します。このパラメータを定期的にチェックして、必要に応じて調整します。このパラメータの上限は Sleepycat データベースの制約による 2G バイトです。
