Exchange メッセージング システムの統合を決定する

メッセージング システムの統合に関する決定は、組織に既存するインフラストラクチャの評価に基づいて行う必要があります。この評価には、個別に管理されるさまざまな地域に加え、メールボックスを格納し、メッセージング コネクタを実行し、受信ブラウザ接続を管理し、その他のタスクを実行するこれらの地域内のサーバーを示すため、環境を図式化することが含まれます。また、ネットワークの信頼性と利用可能な帯域幅が統合戦略に大きく影響を及ぼすため、評価には基本的なネットワーク分析も含める必要があります。

次の図は、統合の機会を識別するために推奨されるアプローチを示します。

次の順序で、サーバー統合戦略に関する質問に答える必要があります。

• 集中管理モデルを実装できるか。 Microsoft® Exchange Server 2003 の管理は、物理的なネットワーク構造に制限されないため、組織では、複数の地理的な場所にまたがって Exchange Server 2003 の集中管理モデルを実装できます。独立した管理を必要とする地域にまたがるサーバーを統合することは通常不可能であるため、集中管理モデルは分散化モデルよりもサーバー管理に適しています。完全な集中型管理を実装できない場合は、異なる IT 部門が組織内の個別の地理的な地域をそれぞれ担当する、ハイブリッド モデルを実装することを検討してください。その場合、各部門は、それぞれに割り当てられた地域に属する遠隔地すべてを集中的に管理します。そうすることにより、サーバーを地域的なデータ センターに統合することが可能になります。

• 遠隔地を 1 つのデータ センターに統合できるか。 クライアント/サーバー通信を、許容できる応答時間でサポートするのに十分なネットワーク帯域幅がある場合、同じ管理機関の下にある遠隔地は、サイト統合に適した候補となります。前述したように、Exchange キャッシュ モードの Outlook® 2003 は、低速または信頼性が低いネットワーク接続環境でも動作します。ただし、既存の帯域幅が十分であるかどうか確認するために、パフォーマンス テストとテスト プロジェクトを実施する必要があります。組織では、負荷を収容できないネットワーク接続をアップグレードするか、支社のメールボックス サーバーの廃止を見合わせる必要が生じる場合があります。

  注 :
  帯域幅の要件を見積もるために、ネットワーク リンク経由で Exchange 2003 に接続するユーザー数、メールボックスにアクセスするクライアントのタイプ (たとえば、Exchange キャッシュ モードの Outlook 2003 または Microsoft Office Outlook Web Access)、およびユーザーの習慣 (たとえば、頻繁に通信する電子メール ユーザーと頻繁に通信しない電子メール ユーザーの比較など) について検討します。また、ファイルとプリンタの共有または Active Directory レプリケーションなど、Exchange ベースのクライアント/サーバー通信に関連しないプロセスも考慮に入れる必要があります。

• 各場所においてサーバーを統合できるか。 データ センターまたは地理的な場所の内部で統合できるサーバーを識別するため、既存のサーバーが管理しているさまざまなタスクを分析する必要があります。一部の種類のサーバーは、他のサーバーに比べて実際の物理的な統合により適しています。たとえば、一部のサーバーはメールボックスの格納にのみ使用されている (メールボックス サーバー) のに対し、メッセージ転送の目的のみに使用されるサーバー (ブリッジヘッド サーバー) もあります。メールボックス サーバーは統合する必要がありますが、大規模な組織においてブリッジヘッド サーバーまたは Web サーバーを、メールボックス サーバーに統合することは、必ずしも良いアイデアではありません。ブリッジヘッド サーバーおよび Web サーバーは、高いネットワーク帯域幅が必要なため、Microsoft Application Center 2000 のような負荷分散テクノロジに基づくサーバー ファームにより適しています。

  注 :
  サーバー統合は、高度な記憶域サブシステムを使用することにより、ユーザー データを少数のサーバーに集中させるための主要な方法です。メールボックスとパブリック フォルダを保持するサーバーは、サーバー統合に最も適しています。

• 予測される負荷を管理するために既存のサーバー ハードウェアを置き換える必要があるか。 統合できるサーバーを識別した後、これらの各サーバーでサポートする必要のあるユーザーの最終的な数を計算します。この数に基づいて、各サーバーの大まかな負荷を見積もり、それによってサーバーのハードウェア要件を決定します。
  既存のサーバー ハードウェアが将来の需要に対応できるかどうかを検討します。既存のハードウェアを再利用することが、コストの削減に役立つ場合がありますが、既存の Pentium Pro または Pentium II マルチプロセッサ コンピュータを、Windows Server™ 2003 および Exchange 2003 にアップグレードしないでください。Intel では、2 つ以上の Pentium Pro または Pentium II プロセッサを持つサーバー上で Windows Server 2003 にアップグレードすると、動作が不安定になったり、データ破損や他の予期しない結果が生じる場合があることを検出しました。これらのプラットフォームをアップグレードすると、Windows Server 2003 は、サポートされる構成である単一プロセッサ モードに強制的に設定されます。しかし、200 MHz で動作する単一プロセッサは、サーバー統合には適していません。より少ないサーバーに統合する場合、既存のサーバー ハードウェアと格納テクノロジを置き換えることを検討してください。次の表は、メールボックス サーバーのプロセッサとメモリに関する基本的な推奨構成の一覧です。

  メールボックス サーバーのプロセッサおよびメモリの構成

  ユーザー数	CPU	メモリ
  500 人未満	1 - 2	512 MB ～ 1 GB
  500 – 1,000	2 - 4	1 GB ～ 2 GB
  1,000 – 2,500	4 - 8	2 GB ～ 4 GB
  2,500 人以上	4 - 8	4 GB

  注 :
  表 1 の数字は、最適な構成の推奨要件です。より多くのユーザーをサポートすると同時に、より少ないハードウェアを使用することも可能です。たとえば、Microsoft では、現在それぞれ 4,500 のメールボックスを持つ 4 つのプロセッサを搭載した Exchange 2003 サーバーを多数稼動しています。プロセッサを追加すればサーバーのパフォーマンスは向上しますが、4 つのプロセッサの構成でも動作します。

  次の要因は、Exchange サーバーのハードウェア設計に影響します。

  • 接続されるユーザー数対合計ユーザー数 サーバー ハードウェアの設計時には、サーバーに同時に接続するユーザーの数を見積もります。たとえば、すべてのユーザーが同時に接続しないのであれば、パフォーマンス要件がより低くなる可能性があります。たとえば、ユーザーがシフト制で働く場合があります。ただし、ユーザーがシステムにログオンしていなくても、メールボックスの数が増加するとサーバーのバックグラウンド活動が増加します。たとえば、数千ものメールボックスを格納しているサーバーでは、データベースの最適化活動が増加します。サーバー ハードウェアの設計時には、常にバックグラウンド活動を考慮に入れてください。

  • メッセージ ストアの場所と使用 Exchange ユーザーは、メッセージを、サーバー ベースのメールボックスか、またはローカル クライアント コンピュータかネットワーク ドライブ上の個人用フォルダ (.pst ファイル) に格納できます。ユーザーは、メッセージの既定の配信場所を個人用フォルダに設定することにより、サーバーの記憶域と処理の負荷を減らすことができます。たとえば、ユーザーが個人用フォルダ内でアイテムを開いたり保存したりしても、サーバー上の Microsoft Exchange Information Store サービスは関与しません。ただし、個人用フォルダをこのような方法で使用するかどうかを決定する際は、すべてのメッセージをローカル クライアント コンピュータ上の個人用フォルダ ストアに格納すると、メッセージを集中的にバックアップできなくなるという事実を考慮に入れてください。

    注 :
    ユーザーが各自のクライアント コンピュータ上の .pst ファイルにメッセージを格納するようにするには、メールボックス ストアに対するメールボックス クォータを構成します。メールボックスがサイズ制限を超える場合、ユーザーはメッセージを .pst ファイルにダウンロードするか、またはメッセージを削除することにより、データの量を減らす必要があります。そうしないと、ユーザーは電子メール メッセージの受信および送信を続行できません。

  • ユーザーの習慣とメッセージング クライアント サーバー ハードウェアを設計する際は、ユーザーが 1 日に送信および受信するメッセージの数を考慮します。また、ユーザーが使用するクライアントの種類についても考慮します。Outlook 2003 と Outlook Web Access 2003 は、サーバーに異なる負荷を与えます。ユーザーが主に Outlook Web Access 2003 を使用する場合は、インターネット インフォメーション サービス (IIS) のための追加の処理要件を考慮に入れる必要があります。

  • パブリック フォルダの使用とレプリケーション パブリック フォルダは、フォルダ サイズ、アクセスの頻度、各フォルダの異なるビューの数、レプリカの数、レプリケーション スケジュール、およびコンテンツの変更の頻度に応じて、サーバーのパフォーマンスに著しい影響を及ぼします。ユーザーのメールボックスは格納しない、専用の Exchange サーバーに、大容量のパブリック フォルダ リポジトリを配置します。パブリック フォルダを格納する Exchange サーバーは、パブリック サーバーと呼ばれることがあります。

  • コネクタとゲートウェイ コネクタとゲートウェイは、サーバーの負荷を大幅に増やす場合のあるメッセージング コンポーネントです。メッセージの転送には、サーバー間通信が含まれ、メッセージの変換が必要な場合もあります。前述したように、コネクタまたはゲートウェイを大規模なメールボックス サーバー上で構成しないでください。組織では、メッセージ転送専用に使用されるサーバーが役立ちます。別の方法としては、すべてのメッセージング システムを Exchange 2003 に移行することができます。そうすると、メッセージング ゲートウェイが不要になります。

  • サーバー ハードウェアがサービス レベル契約に基づいて適切に設計されているか。 テスト サーバー上で Exchange 2003 ストレスおよびパフォーマンス ツールを使用して、ハードウェアがサーバーに配置するメールボックスの数に対応するように設計されているかどうかを検証できます。たとえば、Exchange 2003 サーバーがどのように多数の Outlook 2003 クライアントに応答するかをテストするために、Load Simulator (LoadSim) (LoadSim.exe) を使用できます。別の便利なツールは、Jetstress (JetStress.exe) です。これを使用すると、ディスクの入出力 (I/O) 負荷をシミュレートして、ディスク サブシステムのパフォーマンスと安定性を検証できます。これらのツールは、Exchange Server 2003 のダウンロード Web サイトからダウンロードできます (このサイトは英語の場合があります)。指定されたクラスの Exchange 2003 サーバーでサポートできるメールボックスの数を決定するために、Exchange Server 2003 を実行するコンピュータのパフォーマンスのベンチマークについての Web サイトでパフォーマンス ベンチマーク テストに関する記事も参照できます (このサイトは英語の場合があります)。このトピックに関する別の情報源として、Microsoft Exchange Server 2003 のパフォーマンスに関するトラブルシューティングについての Web サイトがあります (このサイトは英語の場合があります)。