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

第 11 章 Messaging Server アーキテクチャーの開発

この章では、Messaging Server のアーキテクチャーの設計方法について説明します。このアーキテクチャー設計により、ハードウェアリソースとソフトウェアリソースに Messaging Server コンポーネントをどのように配置するかが決定されます。

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

2 層メッセージングアーキテクチャーの理解

2 層アーキテクチャーにより、スケーラビリティーと信頼性のために最適化された設計が可能になります。単独のホストでメッセージングシステムのすべてのコンポーネントを実行する代わりに、2 層アーキテクチャーでは、コンポーネントを異なるマシンに分割します。このようなコンポーネントの分割により、特別な専用機能が実行されます。たとえば、追加のメッセージストレージが必要になったり、より多くのアウトバウンドリレーが必要になったりするなど、特定の機能コンポーネントの負荷が増大すると、サーバーを追加して増大する負荷に対応できます。

2 層アーキテクチャーは、「アクセス層」と 「データ層」で構成されます。アクセス層は、アーキテクチャーの中で、配信、メッセージアクセス、ユーザーログイン、および認証を処理する部分です。データ層は、すべてのデータを維持する部分です。これには、LDAP マスターサーバーと、ユーザーメッセージを格納するよう設定された Messaging Server マシンが含まれます。

図 11–1 は、2 層アーキテクチャーの例を示しています。

図 11–1 2 層 Messaging Server アーキテクチャー

この図は、2 層の Messaging Server アーキテクチャーを示します。

次でこれらの機能部分について説明します。

公衆アクセスネットワーク: Messaging Server を内部ユーザーとインターネットに接続するネットワークです。それぞれの配備で独自のネットワーク要件が定義されますが、基本的な Messaging Server の要件は、SMTP、POP、IMAP、および HTTP のような標準のプロトコルを使用したエンドユーザーとインターネットへの接続性です。

私設データネットワーク: このネットワークは、公衆アクセスネットワークと Messaging Server データの間で、セキュリティー保護された接続を提供します。セキュリティー保護されたアクセス層と、サービス全体のディレクトリ、メッセージデータセンター、および個人アドレス帳 (PAB) サーバーが含まれるデータ層で構成されます。

LDAP ディレクトリサーバー: ユーザーベースに関する情報の格納と取得に使用されるディレクトリサーバーです。ユーザーとグループエイリアス、メールホスト情報、配信設定などを格納します。設計の要件次第で、システムの同一ディレクトリを複数格納することも可能です。図 11–1 は、マスターディレクトリと 2 つのレプリカを示します。LDAP ディレクトリサーバーは、Messaging Server 製品の一部として提供されます。必要であれば、既存の Sun Java System Directory Server ディレクトリのデータを使用することも可能です。既存のディレクトリのデータ形式は、Messaging Server スキーマに準拠している必要があります。

メッセージストア: ユーザーメールを保持し、格納します。「バックエンド」と呼ばれることもあります。メッセージストアは、IMAP サーバー、POP サーバー、および Web メール (Messenger Express) サーバーのようなメッセージアクセスコンポーネントを指すこともあります。図 11–1 は、2 つのメッセージストアを持つ配備を示します。必要に応じて、さらにストアを追加することもできます。

個人アドレス帳 (PAB) サーバー: LDAP サーバー内のユーザーのアドレスを保存および取得します。このサーバーは、前述の LDAP サーバーと同一であってもなくてもかまいません。

DNS サーバー: ホスト名を IP アドレスにマップします。DNS サーバーは、メッセージを外部ドメインにルーティングするときに、どのホストに接続するかを判断します。内部的には、DNS は実際のサービスをマシン名にマップします。DNS サーバーは、Messaging Server 製品の一部ではありません。Messaging Server をインストールする前に、稼働状態の DNS サーバーをインストールする必要があります。

ロードバランサ: ネットワーク接続について、均一にバランスを取るか、複数のサーバーにアルゴリズムを適用してバランスを取ります。ロードバランサを使用すると、1 つのネットワークアドレスで多数のサーバーを表すことができるため、トラフィックのボトルネックを解消し、トラフィックフローの管理と高いレベルのサービス保証が可能になります。図 11–1 には、MMP 用、MTA 用、および MEM 用のロードバランサが含まれています。ロードバランサは Java Enterprise System 製品の一部ではありません。ロードバランサをメッセージストアまたはディレクトリマスター上で使用することはできません。ロードバランサは、MMP、MEM、Communications Express、MTA、ディレクトリコンシューマへの接続用として使用したり、Messaging Server の MTA が Brightmail 製品を使用する状況で使用したりします。

MTA インバウンドリレー: 外部 (インターネット) サイトからのメッセージを受信し、それを内部ホストおよびローカルのメッセージストアサーバーにルーティングする専用MTA です。この MTA は外部からの最初のコンタクトポイントとなるため、MTA インバウンドリレーには、権限のないリレーを防ぎ、スパムをフィルタリングし、サービス拒否攻撃に対抗する機能が追加されます。MX レコードを使えば、着信メールトラフィックの負荷を分散できます。詳細については、「MX (メール交換) レコード」を参照してください。

MTA アウトバウンドリレー: 内部または承認されたユーザーからのメールだけを受け取り、それをその他の内部ユーザーまたは外部 (インターネット) ドメインにルーティングする MTA です。単独のマシンをインバウンドリレーとアウトバウンドリレーとして使用できますが、インターネットに接続された大規模な配備では、これらの機能を 2 つの別のマシンに分割します。このようにすると、内部クライアントは、外部サイトからインバウンドするメールと競合することなく、メールを送信できます。

Delegated Administrator サーバー: 管理者に GUI 管理コンソールを提供し、管理者がユーザーの追加や削除など、より高度な管理作業を行えるようにします。

Messaging マルチプレクサ または MMP: ユーザーのメールボックスを含む特定のマシンと、関連付けられた DNS 名との結合を解除して、複数の物理マシンにわたるメッセージストアの拡大縮小を可能にします。クライアントソフトウェアは、メッセージストアのある物理的なマシンを知る必要はありません。このようにすると、ユーザーは、メールボックスが新しいマシンに移動されるたびにホストメッセージストアの名前を変更する必要がなくなります。POP クライアントまたは IMAP クライアントがメールボックスへのアクセスを要求すると、MMP はディレクトリサービスを参照してユーザーのメールボックスがある場所を検索し、そのメールボックスがある Messaging Server システムに要求を転送します。複数の MMP を使用する場合、それらをロードバランサの背後に配置する必要があります。

MEM (Messenger Express マルチプレクサ): Web メール用の HTTP アクセスサービスへの単一の接続ポイントとして機能する特別なサーバーです。すべてのユーザーがこのメッセージングプロキシサーバーに接続し、該当するメールボックスに導かれます。このため、メールユーザーには複数の Messaging Server が単一のホスト名であるかのように表示されます。Messaging Multiplexing Proxy (MMP) は POP および IMAP サーバーに接続しますが、Messenger Express マルチプレクサは HTTP サーバーに接続します。つまり、Messenger Express マルチプレクサと Messenger Express との関係は、MMP と POP や IMAP との関係と同じです。複数の MEM を使用する場合、それらをロードバランサと組み合わせて使用する必要があります。Communications Express 配備の場合、Communications Express ソフトウェアも、MEM を含む同じホストに配備されます。

2 層アーキテクチャー — メッセジングデータフロー

この節では、メッセージングシステム経由のメッセージフローについて説明します。メッセージフローがどのように機能するかは、実際のプロトコルとメッセージパス次第です。

メールの送信: 内部ユーザーから別の内部ユーザーへ

機能説明: 内部ユーザー > ロードバランサ > MTA アウトバウンドリレー 1 または 2 > MTA インバウンドリレー 1 または 2 > メッセージストア 1 または 2

注 –

アウトバウンドリレーからストアにメールを直接配信させるために、LMTP を使用するのが一般的になってきています。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) に要求を送信します。そしてアクセス層のマシンは、クライアントとサーバー間の残りの接続を仲介します。

メールの送信: 内部ユーザーから外部 (インターネット) ユーザーへ

機能説明: 内部ユーザー > ロードバランサ > MTA アウトバウンドリレー 1 または 2 > インターネット

内部ユーザーから外部ユーザー (すなわち異なる電子メールシステムのユーザー) へ宛てられたメッセージは、ロードバランサに送られます。ロードバランサは、電子メールユーザーを基盤となるサイトアーキテクチャーから切り離し、高可用性電子メールサービスを提供します。ロードバランサは、そのメッセージを MTA アウトバウンドリレー 1 または 2 のいずれかに送信します。アウトバウンドリレーはアドレスを読み取り、メッセージが外部ユーザー宛てのものかどうかを判断します。アウトバウンドリレーは、インターネット上の MTA にメッセージを送信します。

メールの送信: 外部 (インターネット) ユーザーから内部ユーザーへ

機能説明: 外部ユーザー > MTA インバウンドリレー 1 または 2 > メッセージストア 1 または 2

外部ユーザー (インターネット) から内部ユーザーへ宛てられたメッセージは、MTA インバウンドリレー 1 または 2 へ送られます (ロードバランサは不要)。インバウンドリレーはアドレスを読み取り、メッセージが内部ユーザー宛てのものかどうかを判断します。インバウンドリレーは LDAP 検索を使用してメッセージストア 1 または 2 のいずれに送信するかを判断し、それに従って配信します。メッセージストアはそのメッセージを受け取り、適切なメールボックスに配信します。

Messaging Server における水平スケーラビリティーと垂直スケーラビリティーの理解

「スケーラビリティー」は、メッセージングサービスの利用拡大に対応する配備の能力です。スケーラビリティーにより、ユーザー数の急激な拡大をシステムがどのくらいうまく受け入れられるかが決まります。またスケーラビリティーにより、たとえば 1 か月の間にユーザーの多くが SSL の使用を希望するなどというような、ユーザーの行動の大きな変化にシステムがどのくらいうまく適応できるかも決まります。

この節では、個別のサーバーとサーバー全体で、利用の拡大に対応するためにアーキテクチャーに追加する機能について確認します。次のトピックについて説明しています。

水平的スケーラビリティーの計画

水平スケーラビリティーは、アーキテクチャーにサーバーを追加することがどの程度容易であるかを示します。ユーザー数が拡大する、またはユーザーの行動が変化するにつれて、やがては既存の配備のリソースが過負荷状態になります。慎重に計画を立てて、配備のスケールを適切に拡張する方法を決めます。

配備の水平的拡張を行う場合には、リソースを複数のサーバーに分散します。水平スケーラビリティーでは、2 つの方法が使用されます。

複数サーバーへのメッセージングユーザーベースの分散

負荷を複数のサーバーに分散するには、クライアントのメールをいくつかのバックエンドメッセージストアに均等に分割します。ユーザーをアルファベット順に分けたり、サービスのクラス別、部門、または物理的な場所別に分けたりして、特定のバックエンドメッセージストアホストに割り当てます。

MMP と MEM は、管理を容易にする目的でしばしば同じマシンに置かれます。図 11–2 に、ユーザーが複数のバックエンドサーバーに分散され、着信クライアント接続の処理にマルチプレクサを使用するサンプルアーキテクチャーを示します。

図 11–2 複数サーバーへのユーザーベースの分散

この図は、ユーザーが複数のサーバーに分散された配備で、クライアントからの受信接続をマルチプレクサが管理する方法を示します。

ユーザーをバックエンドサーバーに分散することで、MMP または MEM を使用するかぎり、ユーザーの管理が簡単になります。ユーザーは、メールがある 1 つのバックエンドサーバーに接続するため、すべてのユーザーに対して設定を標準化できます。この設定により、複数のサーバーの管理も容易になります。また、Messaging Server ホストへの要求増加に対応して、ホストをシームレスに追加できます。

冗長コンポーネントへのメッセージングリソース分散

電子メールが日常業務に重要な地位を占める場合は、メッセージングシステムが常に運用可能な状態であることを確実にするために、ロードバランサ、MX (メール交換) レコード、リレーのような冗長コンポーネントが必要になります。

冗長 MTA を使用することで、あるコンポーネントが動作不能に陥っても、別のコンポーネントが使用可能になります。また、リソースを冗長 MTA に分散することで、負荷の分散も行われます。この冗長性により、Messaging Server システムにフォールトトレランスも提供されます。それぞれの MTA リレーが、他の MTA リレーの機能を受け持ちます。

冗長ネットワーク接続をサーバーと MTA にインストールすることで、ネットワークの問題に対するフォールトトレランスが実現します。メッセージング配備が組織にとってより重要なものであるほど、フォールトトレランスと冗長性の検討もより重要になります。

「MX (メール交換) レコード」および「インバウンド MTA とアウトバウンド MTA」の詳細については、次の節で説明します。

MX (メール交換) レコード

MX レコードは、1 つのホスト名を別のホスト名にマップする DNS レコードの一種です。等しい優先度の MX レコードにより、冗長化されたインバウンド MTA にメッセージがルーティングされます。たとえば、インターネットからの送信 MTA は、siroe.com に対する MX レコードが、MTAA.siroe.com および MTAB.siroe.com に対応していることを検出します。優先度が同じためにこれらの MTA の 1 つがランダムに選択され、SMTP 接続が開かれます。最初に選択された MTA が応答しなかった場合は、メールは別の MTA に送信されます。次の MX レコードの例を参照してください。

siroe.com in MX 10 MTAA.siroe.com
siroe.com in MX 10 MTAB.siroe.com

インバウンド MTA とアウトバウンド MTA

Messaging Server ホストがそれぞれ多数のユーザーをサポートしており、SMTP メールの送信負荷が高い場合、独立したインバウンド MTA とアウトバウンド MTA を使用することで Messaging Server ホストはルーティングタスクから開放されます。送信メッセージと受信メッセージの処理に異なる MTA を指定して、さらに負荷の分散を図ることもできます。

インバウンド MTA とアウトバウンド MTA の両方が、1 つの送受信 SMTP ホストとして組み合わされる場合もあります。1 つまたは複数の MTA ホストが必要であるかどうかを判断するには、アーキテクチャー全体のインバウンドおよびアウトバウンドメッセージのトラフィック特性を確認します。

ロードバランサ

負荷分散を使用すると、負荷を複数のサーバーに分散して、どれか 1 つのサーバーが過負荷状態にならないようにします。ロードバランサは、クライアントからの要求を受けて、各サーバーの CPU とメモリーの使用率を追跡するようなアルゴリズムを使用して、利用可能なサーバーに要求をリダイレクトします。ロードバランサは、共通サーバーで実行されるソフトウェアとして、純粋に外部のハードウェアソリューションとして、またはハードウェアとソフトウェアを組み合わせたパッケージとして使用可能です。

垂直スケーラビリティーの計画

垂直スケーラビリティーは、CPU の追加など、個々のサーバーマシンへのリソースの追加に関係があります。それぞれのマシンには、一定の負荷を処理できる能力があります。一般には、リソースに制限があるか、配備の拡大に応じて追加のハードウェアを購入できない場合に、配備における垂直スケーラビリティーを検討します。

配備の垂直的スケールを行うには、次のことが必要です。

各メッセージングコンポーネントのサイズを決定する

「Messaging Server アーキテクチャー戦略の構築」を参照してください。
システムのプロトタイプの負荷をテストする

「Messenger Express 負荷シミュレータの使用」を参照してください。
システムパフォーマンスを監視し、それに従って配備を調整する

高可用性の Messaging Server 配備の計画

高可用性は、計画された停止時間と予期しない停止時間を短時間にとどめるための配備の設計です。通常、高可用性設定は緩やかに結合された 2 つ以上のシステムで構成されたクラスタです。各システムがそれぞれのプロセッサ、メモリー、オペレーティングシステムを維持しています。ストレージはシステム間で共有されます。特別なソフトウェアがシステムをバインドし、単一点での障害からシステムが完全に自動的に回復できるようにします。Messaging Server には、Sun Cluster サービスと Veritas クラスタリングソリューションをサポートする高可用性のオプションが用意されています。

高可用性に向けた計画を作成する場合は、可用性とコストとのバランスを検討する必要があります。一般に、より可用性の高い配備では、設計と運用のコストも高くなります。

高可用性は、アプリケーションサービスの中断や停止時間によるデータアクセス機会の損失に対する保険です。アプリケーションサービスが利用不能になった場合、組織は収入、顧客、その他の機会を失うことになります。組織にとっての高可用性の価値は、停止時間のコストに直接関係します。停止時間のコストが高くなるほど、高可用性のための追加コストを正当化するのも容易になります。また、一定のレベルの可用性を保証するサービスレベル契約を組織が結んでいる場合もあります。可用性の目標を達成できない場合、財務的な打撃を直接受ける可能性があります。

詳細については、第 6 章「サービスの可用性の設計」を参照してください。

Messaging Server アーキテクチャーのパフォーマンスの考慮事項

この節では、Messaging Server コンポーネントのパフォーマンス特性を評価して、的確にアーキテクチャーを開発する方法について説明します。

この節では次の項目について説明します。

メッセージストアのパフォーマンスの考慮事項

メッセージストアのパフォーマンスは、次のようなさまざまな要素に影響を受けます。

ディスク入出力
インバウンドメッセージレート (メッセージ挿入レートとも呼ばれる)
メッセージサイズ
ログインレート (POP/IMAP/HTTP)
IMAP および HTTP のトランザクションレート
さまざまなプロトコルの並行接続数
ネットワーク入出力
SSL の使用

前の要素リストは、メッセージストアに影響を与えるおおよその順序で記載されています。メッセージストレージに関するパフォーマンス問題のほとんどは、ディスクの入出力能力が不十分なことに原因があります。さらに、物理ディスク上のストアのレイアウトもパフォーマンスに影響を与えます。より小規模のスタンドアロンシステムでは、単純なディスクのストライピングでも十分な入出力が得られます。ほとんどの大規模システムでは、ファイルシステムを分離し、ストアのさまざまな部分に入出力を提供します。

メッセージングサーバーのディレクトリ

Messaging Server は 6 つのディレクトリを使用して大量の入出力活動に対応しています。これらのディレクトリは高頻度でアクセスされるため、ディレクトリごとにディスクを用意するか、より理想的には、ディレクトリごとに RAID を用意します。次の表で、これらのディレクトリについて説明します。

表 11–1 アクセス頻度の高い Messaging Server ディレクトリ


高入出力ディレクトリ	説明とパラメータの定義
MTA キューディレクトリ	このディレクトリでは、MTA チャネルを通る各メッセージについて 1 つずつのファイルが、大量に作成されます。ファイルが次の目的地に送信されると、そのファイルは削除されます。ディレクトリの場所は、`imta_tailor` ファイルの `IMTA_QUEUE` オプションにより制御されます。MTA キューディレクトリを変更する前に、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』にあるこのオプションについての説明を参照してください。デフォルトの場所: `/var/opt/SUNWmsgrsr/queue`
Messaging Server ログディレクトリ	このディレクトリには、新しいログ情報が常に追加されるログファイルがあります。変更の回数は、ログレベルの設定によります。ディレクトリの場所は、`configutil` のパラメータ `logfile..logdir` によって制御されます。ここで「」は、admin、default、http、imap、pop など、ログを生成するコンポーネントを示します。MTA ログファイルは `imta_tailor` ファイルの IMTA_LOG オプションを使用して変更できます。デフォルトの場所: `/var/opt/SUNWmsgsr/log`
メールボックスデータベースファイル	これらのファイルはキャッシュの同期と継続的な更新を必要とします。このディレクトリは最も高速なディスクボリュームに配置します。これらのファイルは常に `/var/opt/SUNWmsgsr/store/mboxlist` ディレクトリに格納されます。
メッセージストアインデックスファイル	これらのファイルにはメールボックス、メッセージ、ユーザーに関するメタ情報が含まれます。デフォルトではこれらのファイルはメッセージファイルと共に格納されます。`configutil` パラメータの `store.partition..path` はディレクトリの場所を制御します。ここで「」はパーティション名です。リソースに余裕がある場合は、これらのファイルを 2 番目に高速なディスクボリュームに配置します。デフォルトの場所: `/var/opt/SUNWmsgsr/store/partition/primary`
メッセージファイル	これらのファイルにはメッセージが含まれており、メッセージごとに 1 つのファイルとなっています。ファイルは頻繁に作成され、変更されることはなく、最終的には削除されます。デフォルトでは、これらのファイルはメッセージストアインデックスファイルと同じディレクトリに格納されます。ディレクトリの場所は、`configutil` のパラメータ `store.partition.` `partition_name.messagepath` で制御されます。ここで `partition_name` はパーティション名です。サイトによっては、`store.partition.primary.path` によって指定される、`primary` と呼ばれる単独のメッセージストアパーティションがあります。大規模なサイトの中には、`store.partition.` `partition_name.messagepath` により指定される追加パーティションを持つものもあります。ここで `partition_name` はパーティション名です。デフォルトの場所: `/var/opt/SUNWmsgsr/store/partition/primary`
メールボックスリストデータベース一時ディレクトリ	すべての一時ファイル格納用としてメッセージストアによって使用されるディレクトリ。パフォーマンスを最大化するには、このディレクトリを最も高速なファイルシステムに配置する必要があります。Solaris の場合は、`configutil` コマンドを使用して `tmpfs` の下のディレクトリ (たとえば、 `/tmp/mboxlist`) に `store.dbtmpdir` 変数を設定します。デフォルトの場所: `/var/opt/SUNWmsgsr/store/mboxlist`

次の節では、Messaging Server の高頻度アクセスディレクトリについてさらに詳しく説明します。

MTA キューディレクトリ

LMTP 以外の環境では、メッセージストアシステム内の MTA キューディレクトリもかなりの頻度で使用されます。LMTP は、インバウンドメッセージが MTA キューに置かれず、ストアに直接挿入されるように機能します。このメッセージの挿入により、メッセージストアマシンの全体的な入出力要件が少なくなり、メッセージストアマシンの MTA キューディレクトリの使用頻度が大きく減少します。システムがスタンドアロンの場合、または Web メール送信のためのローカル MTA を使用する場合は、アウトバウンドメールトラフィックのためのこのディレクトリに、まだかなりの入出力が発生します。LMTP を使用した 2 層環境では、このディレクトリが使用されることがあったとしても、ごくまれです。Messaging Server の前のバージョンでは、大規模なシステムではこのディレクトリをそれ自身のストライプまたはボリューム上に設定する必要がありました。

MTA キューディレクトリは通常、専用のファイルシステム上に配置し、メッセージストア内のメッセージファイルから分離すべきです。メッセージストアには、ディスク容量がある定義済みのしきい値を下回った場合にメッセージの配信と追加を停止するメカニズムが備わっています。しかしながら、ログディレクトリとキューディレクトリがどちらも同一ファイルシステム上に存在しており、かつそれらのサイズが増大し続けた場合、ディスク容量不足によりメッセージストアの動作が停止する可能性があります。

ログファイルディレクトリ

ログファイルディレクトリでは、設定されているログのレベルにより、さまざまな量の入出力が要求されます。メッセージストアのその他の高入出力要求とは異なり、ログディレクトリへの入出力は非同期です。典型的な配備シナリオでは、LUN 全体をログ専用には使用しません。かなり規模の大きなストア配備、または大量のログが必要な環境では、専用の LUN を使用するのが理に適っています。

ほとんどすべての環境で、メッセージストアをデータ喪失から守る必要があります。要求される損失からの保護と継続的な可用性のレベルは、RAID5 のような単純なディスク保護から、ミラーリング、日常的なバックアップ、データのリアルタイムレプリケーション、リモートデータセンターまで、さまざまです。データの保護に関しても、Automatic System Recovery (ASR) が可能なマシンから、ローカル HA 機能、自動リモートサイトフェイルオーバーまで、さまざまなものがあります。これらの決定は、ハードウェアの量とサービスの提供に必要なサポート要員の数に影響します。

mboxlist ディレクトリ

mboxlist ディレクトリには入出力が非常に集中しますが、特にサイズが大きいというわけではありません。mboxlist ディレクトリには、ストアとトランザクションログで使用されるデータベースがあります。高頻度の入出力があり、データベースを構成する複数のファイルを複数のファイルシステム間で分割できないことから、大規模な配備では mboxlist ディレクトリをそれ自身のストライプかボリューム上に配置する必要があります。これは、メッセージストアの多くの操作がデータベースにアクセスするため、垂直的スケーラビリティーの喪失の原因にもつながります。アクセスが激しいシステムでは、これがボトルネックになります。mboxlist ディレクトリの入出力パフォーマンスのボトルネックによって、ストアの raw パフォーマンスと応答時間が悪くなるだけでなく、垂直的スケーラビリティーも減少します。バックアップから高速に復旧することが要求されるシステムでは、このディレクトリを Solid State Disks (SSD) 上に配置するか、パフォーマンスの高いキャッシングアレイを使って、ファイルシステム上でサービスを継続したまま復元処理を進行できるような高い書き込みレートを許可します。

複数のストアパーティション

メッセージストアは、複数のストアパーティションをサポートしています。各パーティションを、それ自身のストライプまたはボリューム上に配置します。ストア上に配置するパーティションの数は、さまざまな要素により決定されます。明確な要素としては、サーバーのピーク負荷時の入出力要件があります。追加のストアパーティションとしてファイルシステムを追加することで、メールの配信や取得のためにサーバーで可能な IOPS (1 秒あたりの総入出力) を引き上げます。ほとんどの環境で、大きくて数が少ないストライプあるいは LUN よりも、多数の小さなストライプあるいは LUN のほうが、より大きな IOPS が得られます。

いくつかのディスクアレイを使用すると、アレイを 2 つの異なる方法で設定できます。それぞれのアレイを LUN として設定し、それをファイルシステムにマウントします。または、それぞれのアレイを LUN として設定し、それをサーバー上でストライプします。どちらも有効な設定です。ただし、複数のストアパーティション (小さいアレイでは 1 つのパーティション、または LUN のストライプセットをサーバーボリュームにした大きなアレイ上の多数のパーティション) は最適化と管理が容易です。

ただし、通常は raw パフォーマンスは、ストアパーティションの数を決定する場合の優先事項とはなりません。企業環境では、IOPS よりも容量のほうが重要となる場合が多いでしょう。また、LUN をソフトウェアストライプで設定し、1 つの大きなストアパーティションとすることも可能です。ただし、複数の小さなパーティションのほうが、一般に管理は容易です。ストアパーティションの数を決定する際に適切な最優先事項は、一般的には回復時間です。

ストアパーティションの回復時間は、いくつかのカテゴリに分類されます。

最初に、電源、ハードウェア、またはオペレーティングシステムの障害によるクラッシュからの回復と並行して、fsck コマンドが複数のファイルシステム上で動作します。HA プラットフォームで強く推奨され、必須となっているジャーナリングファイルシステムを使用している場合は、この要素は小さなものとなります。
次に、バックアップおよび回復手順が複数のストアパーティション上で並行して実行されます。メッセージストアではすべてのストアパーティションで単独のデータベースが使用されているため、この並行動作は mboxlist ディレクトリの垂直的スケーラビリティーにより制限されます。ストアパーティションあたりの 1 つのスレッドの実行と並行して、ストアクリーンアップ手順 (expire および purge) が実行されます。
最後に、ミラーリングまたは RAID 再同期手順が、小さな LUN で高速に実行されます。ここでは厳密な規則はありませんが、ほとんどの場合はストアパーティションを構成するスピンドルを 10 個までにすることをお勧めします。

ストレージアレイで使用されるドライブのサイズは、容量要件に対する IOPS 要件という問題になります。ほとんどの家庭用 ISP POP 環境では、「より小さなドライブ」を使用します。大規模な割り当てによる企業配備では、「より大きな」ドライブを使用します。繰り返しになりますが、すべての配備は異なっており、一連の要件を個別に検討する必要があります。

メッセージストアのプロセッサスケーラビリティー

マルチプロセスとマルチスレッドにより、メッセージストアは良好なスケール化がなされています。実際には、メッセージストアは 1 つのプロセッサから 4 つのプロセッサまで、一次直線形の比率を上回るスケール化が行われています。これは、4 つのプロセッサシステムは、1 つのプロセッサシステムを 4 つ合わせたものよりも大きな負荷を処理できることを意味します。メッセージストアは 4 から 12 のプロセッサ数についてもかなり直線形でスケール化されます。12 から 16 のプロセッサ数では、能力は増強されますが、直線形ではなくなります。LMTP を使用すると、同じサイズのストアシステムでサポートされるユーザー数は大きく増加しますが、メッセージストアの垂直的スケーラビリティーはより制限されます。

メールボックスデータベースキャッシュサイズの設定

Messaging Server は、メールボックスデータベースの呼び出しを頻繁に行います。そのため、そのデータができるだけ迅速に返されることが重要です。メールボックスデータベースの部分をキャッシュ化すると、メッセージストアのパフォーマンスが改善されます。最適なキャッシュサイズを設定することで、メッセージストア全体のパフォーマンスを大きく向上させることができます。キャッシュのサイズは、configutil のパラメータ store.dbcachesize を使用して設定します。

メールボックスデータベースの場所を /tmp、つまり /tmp/mboxlist に定義し直すには、configutil のパラメータ store.dbtmpdir の使用をお勧めします。

メールボックスデータベースは、データページに格納されます。さまざまなデーモンにより stored、imapd、 popd などのデータベースが呼び出されると、指定されたページがキャッシュに格納されているかどうかが、システムによりチェックされます。ページがキャッシュ内に存在する場合は、それがデーモンに渡されます。存在しない場合は、システムは 1 ページをキャッシュからディスクに書き戻し、指定されたページを読み込んでそれをキャッシュに書き込む必要があります。ディスクの書き込みと読み取り回数を減らすことはパフォーマンスの向上につながりますが、それだけに、キャッシュサイズを最適に設定することが重要となります。

キャッシュサイズが小さすぎる場合は、指定されたデータをディスクから必要以上の頻度で読み込む必要があります。キャッシュサイズが大きすぎる場合は、ダイナミックメモリー (RAM) が浪費され、ディスクとキャッシュの同期に余計な時間がかかります。これら 2 つの状況の中では、キャッシュが大きすぎる場合よりも小さすぎる場合の方が、より大きなパフォーマンスの低下を招きます。

キャッシュ効率は、「ヒットレート」により測定されます。ヒットレートは、データベースがキャッシュにより処理される回数の割合のことです。最適化されたサイズのキャッシュでは、ヒットレートは 99 パーセントに達します。すなわち、要求されたデータベースページの 99 パーセントが、ディスクから取得されることなくデーモンに返されます。要求されたデータの 95 パーセント以上を返せるページ数をキャッシュが保持することを目標にしてキャッシュを設定します。キャッシュから返されるページが 95 パーセント未満の場合は、キャッシュサイズを大きくする必要があります。

キャッシュのヒットレートは、データベースコマンド db_stat を使用して測定できます。次の例では、configutil のパラメータ store.dbtmpdir を使用して、メールボックスデータベースの場所を /tmp、つまり /tmp/mboxlist に定義し直しています。db_stat コマンドは、次の場所に対して実行されます。

# /opt/SUNWmsgsr/lib/db_stat -m -h /tmp/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 パーセント以下になるまでキャッシュサイズを小さくしていきます。ヒットレートが 98 パーセントになったら、データベースキャッシュサイズが最適化されたことを意味します。逆に、db_stat が 95 パーセント未満のヒットレートを示した場合は、store.dbcachesize パラメータを使用してキャッシュサイズを大きくします。最大サイズは、store/mboxlist ディレクトリ内のすべての *.db ファイルを合計したものになります。キャッシュサイズは、store/mboxlist ディレクトリに格納されるすべての .db ファイルの合計サイズを超えてはいけません。

注 –

ユーザーベースが変化すると、ヒットレートも変化します。このパラメータを定期的にチェックして、必要に応じて調整します。このパラメータの上限はデータベースの制約による 2G バイトです。

ディスクストライプ幅の設定

ディスクストライピングを設定するときには、システムを通過するメッセージの平均サイズにストライプ幅を合わせます。128 ブロックのストライプ幅は、通常の使用には大きすぎて、パフォーマンスに悪影響を与えます。代わりに、8、16、32 ブロック (それぞれ 4、8、16K バイトのメッセージサイズの場合) の値を使用します。

MTA パフォーマンスの考慮事項

MTA のパフォーマンスは、次の項目を含む多くの要素に影響されます。

ディスクパフォーマンス
SSL の使用
インバウンドおよびアウトバウンドのメッセージ数および接続数
メッセージのサイズ
対象送信先数およびメッセージ数
MTA との接続スピードと接続待ち時間
スパムフィルタリングまたはウィルスフィルタリングの必要性
SIEVE 規則とその他のメッセージ解析 (変換チャネルの使用など) の使用

MTA は CPU と入出力を集中的に使用します。MTA は、キューディレクトリとロギングディレクトリという異なる 2 つのディレクトリに対し、読み書きを行います。MTA として機能する小規模なホスト (4 プロセッサ以下) では、これらのディレクトリを別のファイルシステムに分ける必要はありません。キューディレクトリでは、かなり大きい量で同期書き込みが行われます。ログディレクトリでは、小さな量の非同期書き込みが連続的に行われます。トラフィック量の多いシステム上では、これら 2 つのディレクトリを分離し、それぞれ異なるファイルシステム上に配置することを検討してください。

ほとんどのケースで、ディスクサブシステムの 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 は、マルチスレッドの単一プロセスとして動作し、CPU とネットワークに強く依存します。MMP がディスクリソースを使用するのは、ロギング時だけです。MMP のスケーラビリティーは、2 プロセッサマシンでもっとも効率がよく、2 プロセッサから 4 プロセッサまでは直線形を下回る比率になり、4 プロセッサを超えると大きく低下します。MMP には、2 つのプロセッサを備えたラックマウントのマシンが適しています。

その他のコンポーネントソフトウェア (MEM、Calendar Server フロントエンド、Communications Express Web コンテナ、LDAP プロキシなど) を MMP と同じマシンに配置する配備の場合は、大型の 4 プロセッサ SPARC マシンの配備を検討します。そのような構成を行うことにより、管理、パッチの導入、監視などが必要なマシンの総数を減らすことができます。

MMP のサイズは、接続レートとトランザクションレートにより決まります。POP のサイズ決定は、POP 接続がほとんどアイドル状態にならないため、きわめて明快です。POP 接続では、接続が行われ、作業が行われ、そして接続が遮断されます。IMAP のサイズ決定はより複雑です。IMAP では、ログインレート、並行レート、接続のビジー状態の起こり方について確認する必要があります。MMP も、接続の待ち時間と帯域幅に多少影響を受けます。MMP はメッセージストアからクライアントに送信されるデータのバッファとして機能するため、ダイアルアップ環境では、ブロードバンド環境の場合よりも並行して処理できるユーザーの数が少なくなります。

SSL の使用率が接続のかなりの割合を占める場合は、ハードウェアアクセラレータをインストールします。

MMP と高可用性

決して MMP を HA の制御のもとに配備しないでください。個別の MMP には静的データはありません。可用性の高い環境では、1 つ以上の MMP マシンを追加して、1 つ以上の MMP が停止してもピーク負荷に対して十分な能力を確保します。Sun Fire Blade^TM Server ハードウェアを使用する場合は、Blade ラックユニット全体が停止する可能性を考慮して、適切な冗長性の配備を計画します。

MEM パフォーマンスの考慮事項

MEM では、Web メール (Messenger Express) クライアントに対して中間層プロキシが提供されます。このクライアントを使用して、ユーザーはブラウザを通じてメールにアクセスし、メールを作成できます。MEM のメリットは、メールを格納しているのはバックエンドサーバーであるにもかかわらず、エンドユーザーは MEM にだけ接続して、自分の電子メールにアクセスできることです。MEM は、ユーザーの LDAP 情報を通じて HTTP セッション情報とユーザープロファイルを管理することで、この機能を実現しています。2 番目のメリットは、すべての静的ファイルと LDAP 認証の状態が Messaging Server のフロントエンドに存在することです。このメリットにより、メッセージストアバックエンドからの Web ページレンダリングに関連した、CPU の追加要件が相殺されます。

MMP と MEM は同じサーバーセット上に配置できます。そうすることのメリットとして、少数の MMP または MEM が必要な場合に、冗長性確保のために必要なハードウェアの追加を最小限に抑えることができます。MMP と MEM を同じサーバーセット上に配置することで生じる唯一のデメリットの可能性は、1 つのプロトコルに対するサービス拒否攻撃が別のプロトコルにも影響を与えることです。

Messaging Server と Directory Server のパフォーマンスの考慮事項

Access Manager、Messaging Server、および LDAP スキーマ 2 ディレクトリを使用した大規模なインストールでは、使用するディレクトリに ACI (アクセス制御命令) を統合した方がよい場合があります。

Messaging Server を使用して Access Manager をインストールするときには、多数の ACI がディレクトリに最初にインストールされます。デフォルトの ACI の多くは、Messaging Server では不要であり使用されません。ディレクトリ内のデフォルト ACI を統合して数を減らすことにより、Directory Server のパフォーマンス、ひいては Messaging Server ルックアップのパフォーマンスを向上させることができます。

使用されていない ACI を統合および破棄する方法については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』の付録 E「Directory Server パフォーマンスのための ACI 統合」を参照してください。