Communications Services 配備の論理アーキテクチャーの概要

Communications Services を単一層または 2 層論理アーキテクチャーのいずれかに配備することができます。論理アーキテクチャーの特定は、必要なマシンのタイプと台数を左右するため、非常に重要です。

通常、一般企業への配備では単一層アーキテクチャーが使用され、インターネットサービスプロバイダ (ISP) や電気通信会社への配備では 2 層アーキテクチャーが使用されます。ただし、一般的な場合と同じように例外が存在します。小規模な ISP が単一のマシンに配備することがあり、大規模な中央集中型の企業が、多くの場合 ISP が配備するのと同じ理由で 2 層アーキテクチャーに配備することもあります。遠隔地で働く社員のアクセスを容易にする企業が増えるほど、企業の配備も ISP と同様のものになっていきます。

この節では、次の Communications Services 論理アーキテクチャーについて説明します。

• 単一層アーキテクチャー:すべてのサービスが、十分なメモリーと CPU をプロビジョニングした単一のホストに配置されるか、または各サーバーが特定のコンポーネント製品のすべてのサービスをホストする複数のサーバーに配備されます。

• 2 層アーキテクチャー:コンポーネント製品のアクセス層とデータ層が別個のサーバーに分離されます。

• エッジアーキテクチャー: 2 層アーキテクチャー上に構築され、インターネットを介してモバイル通信を利用する社員にセキュリティー保護された接続を提供します。

Communications Services を単一層アーキテクチャーと複数層アーキテクチャーのどちらで配備するかにかかわらず、両方のモデルの長所と短所を理解する必要があります。

単一ホスト用の単一層論理アーキテクチャー

その名前が示すように、単一ホスト用の単一層論理アーキテクチャーは、すべてのサービスを単一のマシンに配置します。通常、このアーキテクチャーは次のような企業に最適です。

• ユーザー数が 500 人以下の場合

• 地理的に分散していない場合

• 少数の管理者によって管理される場合

• エントリレベルの構成が必要な場合

次の図は、単一ホスト用の単一層論理アーキテクチャーを示します。

図 5–1 単一ホスト用の単一層アーキテクチャー

Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。層 1 は、メッセージング、カレンダ、インスタントメッセージング、ディレクトリなどすべてのサービスを実行する単一のマシンです。Communications Express を配備する場合、Web サーバー (またはアプリケーションサーバー) も、この単一マシン上で実行されます。単一層配備の特徴は、エンドユーザーがプロキシやほかのエージェントを介さずに直接ストアと通信することです。

単一ホスト用の単一層論理アーキテクチャーでは、十分な CPU、メモリー、およびストレージを備えるマシンが必要になります。このタイプの配備に対する組織のニーズに最も適合したマシンを決定するには、Sun の販売代理店と共同で作業を行う必要があります。

単一ホスト用の単一層論理アーキテクチャーを実装する場合、サービスに論理名を割り当てることによって複数層アーキテクチャーに拡張できるように配備を構成することができます。この構成は、DNS マッピングを利用して、ユーザーが同一のフロントエンドプロセス (マシン) を使用するように指示します。将来、サービスを Tier (層) 方式に分割するなど、拡大に対応するための変更が必要になった場合、ユーザーはクライアントアプリケーションを再設定する必要がありません。詳細については、「論理サービス名の使用」を参照してください。

複数ホスト用の単一層論理アーキテクチャー

複数ホスト用の単一層論理アーキテクチャーは複数のサーバーから構成され、各サーバーがコンポーネント製品に特定のサービスを実行します。たとえば、Messaging Server ホストはすべての Messaging Server サービスを実行するようにインストールおよび設定され、Calendar Server ホストはすべての Calendar Server サービスを実行するようにインストールおよび設定されます。ほかのホストも同様になります。このアーキテクチャーは高可用性を確保するために設定される場合もあります。

単一層論理アーキテクチャーの特徴は、エンドユーザーがプロキシやほかのエージェントを介さずに直接データストアと通信することです。たとえば、Messaging Server では、ユーザーは MMP または MTA を経由せずにルーティングされます。単一層論理アーキテクチャーは、サーバー間のメールのルーティングまたは企業ネットワークへの出入りにスタンドアロン MTA ルーターを使用する場合がありますが、エンドユーザーはユーザーのメッセージストアの MTA にメールを送信します。MMP はメッセージストアへのイントラネット接続には関与しません。

同じ考え方が Calendar Server と Instant Messaging の両方に当てはまります。単一層論理アーキテクチャーでは、フロントエンドプロセスは別個のマシンには配置されません。

図 5–2 は、複数ホスト用の単一層論理アーキテクチャーを表しています。

図 5–2 複数ホスト用の単一層アーキテクチャー

この図では、Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。層 1 は 4 種類のサーバーのセットです。1 番目のサーバーは Calendar Server プロセスを実行し、2 番目は Messaging Server プロセスを実行し、3 番目は Instant Messaging プロセスを実行し、4 番目は Directory Server プロセスを実行します。Communications Express を配備する場合は、Messaging Server のホストに Web メール用の Web サーバー (Web Server または Application Server) も含まれます。

単一層分散論理アーキテクチャー

単一層分散論理アーキテクチャーは、単一層アーキテクチャーの変形で、2 つの層に Directory Server が配備されています。この形式の配備は、地理的に分散した小規模な部門または組織を持つ企業に適しています。各部門またはオフイスは、独自のサービス (メール、カレンダ、インスタントメッセージング) とローカルディレクトリインスタンス (コンシューマ) を持ちます。すべてのローカルディレクトリインスタンスがキャッシュされますが、集中化された企業マスターリポジトリとは同期します。この配備は、低帯域幅の接続を使用するオフイスでは一般的なシナリオです。ディレクトリは 2 層形式で設計され、データをローカルに保持するために低帯域幅を経由して複製されます。

図 5–3 は、単一層分散論理アーキテクチャーを表しています。

図 5–3 単一層分散アーキテクチャー

この図では、Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。層 0 は、層 1 を通じて負荷を分散するロードバランサを構成します。層 1 は、Communications Services プロセスの複数サーバーのセットです。複数のサーバーが Calendar Server サービスを実行し、複数のサーバーが Messaging Server サービスを実行し、複数のサーバーが Instant Messaging サービスを実行します。Directory Server は、ローカルの複製されたディレクトリのコピーを実行する層 1 のコンシューマサーバーとディレクトリのマスターコピーを持つ層 2 のもう 1 つのサーバーに分割されます。この配備形式では、クライアントの照会はマスターコピーではなく、ローカルのディレクトリコピーに送信されることに注意してください。ローカル Directory Server だけが、マスター Directory Server と通信します。

インターネット接続を使用する単一層アーキテクチャーを配備する場合は、別のアクセス層を使用します。たとえば、SSL を使用せずにイントラネット内部からデータストアにアクセスするように指示します。ただし、インターネットからデータストアにアクセスする場合は、SSL を介するアクセス層を経由するように指示します。これにより、インターネットから分離されたアクセス層に、データストアの SSL 負荷の大部分がオフロードされます。

この形式の配備の欠点は、企業のイントラネット上のサーバーを利用したり、インターネットからサーバーにアクセスしたりするユーザーが常時 SSL を使用するようにクライアントアプリケーションを設定する必要があることです。これは、SSL の有効、無効を切り替える手間が非常にかかるためです。このため、かなりの割合の SSL トラフィックがストアに直接接続されることになります。イントラネット内部のアクセス層を利用することによって、この問題を解消し、接続の方向を制限することによって、不正なアクセスからイントラネットを保護することができます。

2 層論理アーキテクチャー

2 層論理アーキテクチャーでは、データストアはフロントエンドプロセスを経由して通信します。つまり、Messaging Server の場合、MMP、MEM、および MTA がデータストアプロセスとは別のマシンに配置されることを意味します。2 層アーキテクチャーを使えば、メールストアは重要な共通タスクの負荷が軽減され、メールの受信と配信に集中することができます。Calendar Server の場合、HTTP サービスと管理サービスがストアプロセスと別のマシンに配置されることを意味します。Instant Messaging の場合、プロキシサービスがバックエンドプロセスと別のマシンに配置されることを意味します。

いくつかのレベルで、ほかのサーバーとの共存が可能です。たとえば、同一のマシンにカレンダストアとメッセージストアを配置することができます。同様に、MMP マシンにカレンダのフロントエンドを配置することができます。

2 層論理アーキテクチャーでは、Directory Server は通常、負荷分散された一連のコンシューマディレクトリに対するマルチマスターとレプリケーションを持つため、それ自体が複雑な配備となります。

図 5–4 は、2 層論理アーキテクチャーを表しています。

図 5–4 2 層アーキテクチャー

上図では、Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。ロードバランサが層 0 を形成します。Calendar Server、Messaging Server、Instant Messaging、Web プロキシ/MEM のフロントエンドが層 1 を形成します。最後に、Directory Server、Calendar Server、Messaging Server、Instant Messaging のバックエンドが層 2 を形成します。Communications Express を配備する場合は、Web サーバーも層 2 に配置できます。

2 層アーキテクチャーでは、層 1 と層 2 の要素を独立したインスタンスとして配備できるため、設計全体の柔軟性が高まります。さらに、個々のインスタンスに別々の機能を割り当てることにより、システムのセキュリティーを強化することができます。

通常の配備では、メッセージングとカレンダフロントエンドをネットワークの非武装地帯 (DMZ) に配置し、ファイアウォールを経由してメインのメッセージングとカレンダサービスに接続します。この構成により、層 1 の要素を個々にスケーリングすることができるため、システムの水平方向のスケーリングが可能になります。これらの要素に、バックエンドサーバーの容量を超えるようなスケーリングはしないでください。

フロントエンドの要素がバックエンドサーバーの容量に到達した場合、バックエンドの層 2 の要素を拡大して、より多くのユーザーをサポートすることができます。通常、フロントエンドはトラフィックの関数としてスケーリングします。バックエンドはユーザー数の関数としてスケーリングされます。

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

エッジ論理アーキテクチャー

エッジ論理アーキテクチャーは 2 層論理アーキテクチャーへのリモートアクセスに対するセキュリティーを向上させます。エッジ配備は、名前およびパスワード認証 (SMTPAuth ) のみを使用することにより、遠隔地のモバイル通信を利用する社員に公衆インターネットを経由するアクセスを許可します。メッセージは、公衆インターネットを介して企業ネットワークと通信されるので、SSL を使用して暗号化されます。仮想私設ネットワークは一切関与しません。通信の内部転送は、最大のパフォーマンスを発揮するために「平文」で行われます。アクセスは、配備の「エッジ」に含まれ、データストアを無許可の侵入から保護します。

エッジを配備するビジネス上の理由は次のとおりです。

• 社員がモバイル通信を利用する遠隔地の社員で構成されていること。

• すべてのリモートサイトに Communications Services サーバーをインストールし、維持することを避けたい場合。

図 5–5 は、エッジ論理アーキテクチャーを表しています。

図 5–5 エッジアーキテクチャー

この図では、データストアは「エッジ」および「内部」フロントエンドサーバーにのみ接続されるセキュリティー保護された私設ネットワークの層 2 に配置されています。リモートクライアントは SSL を使用してフロントエンドサーバーに接続します。内部アクセスは本質的に安全であるとみなされるので、内部クライアントは SSL を使用して接続する必要はありません。

エッジアーキテクチャー設計の推奨事項

• エッジ層の容量計画を一般化することは困難です。容量計画を開発するには、配備用の機器を供給するハードウェアベンダーおよびソフトウェアベンダーと共同で行う必要があります。ただし、サイトのエッジ層に RBL (Realtime Blackhole List) を実装する必要があります。RBL は、スパムの拡散を防止するために、所有者が認証を拒否する IP アドレスのリストです。

• 最小応答時間 (エッジ層全体を通じて 1 ミリ秒以下) のエッジ層を設計します。

• CPU の利用率、またはアクティブな接続数によって負荷を検知する負荷分散アルゴリズムを使用します。ラウンドロビンを負荷モデルとして使用することはできません。MTA (状態を持たない) の例外を除いて、スティッキビット負荷分散を使用します。

• Web メールインタフェースが Web メールサーバー全体で状態を共有しないため、Web メールクライアントにはスティッキビットを管理できる負荷分散が必要になります。

単一層アーキテクチャーの利点

単一層アーキテクチャーを使用する利点は、追加ハードウェアの購入と維持が不要になることによるコストの低減です。

単一層アーキテクチャーがその企業に最適かどうかを決定するには、次の質問に対する回答が役立ちます。

• サービス拒否の脅威は最小ですか。

• SSL は必要ありませんか。

• 保守のためにかなりの停止時間を見込むことができますか。

これらの質問に対する回答が「はい」である場合、その企業は単一層アーキテクチャーを使用することを示しています。

2 層アーキテクチャーの利点

Communications Services 製品内のすべてのサービスはネットワーク機能に依存します。2 層アーキテクチャーは、公衆 (ユーザー側) ネットワークと私設 (データセンター側) ネットワークの 2 つの独立したネットワークを持つネットワーク設計を提供します。

ネットワークを 2 層に分離することにより、次の利点が提供されます。

• 内部ネットワークの非表示: 公衆 (ユーザー側) ネットワークと私設 (データセンター側) ネットワークを分離して、データセンターの情報を非表示にすることにより、セキュリティーが確保されます。この情報には、IP アドレスおよびホスト名などのネットワーク情報とメールボックスおよびカレンダ情報などのユーザーデータが含まれます。

• ネットワーク情報の冗長性の提供:複数のフロントエンドマシンにわたるサービスへのアクセスをプロビジョニングすることで、システムの冗長性が実現されます。冗長性のあるメッセージングフロントエンドサーバーを追加して SMTP 要求を利用可能なメッセージングフロントエンドホストに負荷分散することにより、サービスの稼働時間を向上させることができます。

• アクセス層のホスト上の利用可能なデータの制限: アクセス層のホストが危険にさらされている場合も、攻撃者はアクセスホストから重要なデータを取得できません。

• タスクのアクセス層への軽減:アクセス層が数多くのタスクを完全に所有できるようにすることにより、メッセージストア上のユーザーメールボックスの数が増加します。この方法が役立つのは、アクセス層マシン (第 2 層) よりもストアサーバーの購入および保守費用の方がコストが高くなるためです。通常、アクセス層マシンは小規模で大量のディスクが不要であり (「MTA パフォーマンスの考慮事項」を参照)、ほとんどバックアップされることはありません。第 2 層によって軽減される機能の一部は次のとおりです。

  • サービス拒否の防護

  • SSL

  • 逆引き DNS

  • UBE (スパム) とウィルススキャン

  • 初期認証: メッセージストアの認証が常に成功し、ディレクトリサーバーが最近のエントリをキャッシュしやすくなります。

  • LMTP: MTA リレーとメッセージストア間の LMTP のサポートにより、SMTP 処理が軽減され、メッセージストア上の MTA キューへのメッセージの追加書き込みが不要になります。

• クライアントアプリケーションのエンドユーザー設定の簡素化:2 層アーキテクチャーの使用により、エンドユーザーはメッセージングとカレンダアプリケーションが接続するホストの物理名を記憶する必要がありません。アクセス層のアプリケーションホストは、割り当てられたメッセージングまたはカレンダデータセンターのホストにエンドユーザーを接続するプロキシを提供します。IMAP などのサービスは、ユーザーのメールボックスホストの名前を識別するために、LDAP 情報を使用してバックエンドサービスに接続されます。カレンダサービスの場合、カレンダのフロントエンドホストは割り当てられたユーザーのカレンダストアホストへのバックエンド接続を構築するために、Directory Server を使用してカレンダ検索を提供します。

  この機能は、すべてのエンドユーザーがクライアント設定に同じホスト名を使用できるようにします。たとえば、ユーザーはメッセージストアがhost-a であると記憶するのではなく、単に mail 設定を使用するだけで済みます。MMP は、ユーザーの割り当てられたメッセージストアへのプロキシサービスを提供します。すべてのメールの着信接続が 1 つ (または複数) の MMP をポイントするようにDNS と負荷分散設定を装備する必要があります。

  Calendar Server を 2 層に配置することにより、複数の Calendar Server バックエンドサーバーを使用できます。Calendar Server のグループスケジューリングエンジンにより、ユーザーは任意のバックエンド Calendar Server ホストのカレンダを使用するユーザーのアポイントメントを予定に入れることができます。

  このプロキシ機能の追加の利点は、地理的に分散したユーザーが、物理的な場所に関係なく同じクライアントアプリケーションを利用できることです。ヨーロッパのユーザーがカリフォルニアを訪問したと仮定した場合、ユーザーはカリフォルニアのアクセスサーバーに即座に接続することができます。ユーザーの LDAP 情報は、ユーザーの代わりにヨーロッパにあるユーザーのメッセージストアへの別個の接続を確立するようにアクセスサーバーに指示します。

  最後に、この機能は、ユーザーがブラウザを別に設定することなく、つまりユーザーのサポートを簡素化して大規模な環境の実行を可能にします。ユーザーに連絡せずに、あるいはデスクトップを変更せずに、ユーザーのメールボックスをあるメールボックスから別のメールボックスに移動することができます。

• データセンターのネットワーク HTTP トラフィックの削減:MEM (Messaging Express マルチプレクサ) と Calendar Server フロントエンドはデータセンターネットワークへの HTTP トラフィックを大幅に削減します。HTTP はコネクションレス型サービスです。各 HTTML の要素の場合、メールまたはカレンダサービスに別々の HTTP 要求を送信する必要があります。これらの要求は、イメージ、スタイルシート、JavaScript^TM ファイル、HTML ファイルなどの静的データに対するものであることがあります。これらの要素をエンドユーザーの近くに配置することにより、バックエンドデータセンターのネットワークトラフィックが削減されます。