Exchange Server 複数サイト データ レプリケーションに関する展開のガイドライン

  • [アーティクル]

 

レプリケーション テクノロジによって、Microsoft® Exchange Server データの可用性を高めることができます。このトピックは、レプリケーション ストレージ テクノロジおよび Exchange Server 環境でのレプリケーション ストレージ テクノロジの使用方法をより正確に理解することを目的としています。

レプリケーションは、複数のサイトに冗長データを維持することによって高い可用性をサポートしますが、データ破損の発生を防ぐことはできません。データベース破損の原因となる不良データがプライマリの記憶装置に書き込まれた場合、同じ不良データがリモート サイトへレプリケートされ、リモート サイトのデータベースが破損します。したがって、データ レプリケーションは、データベースの整合性を定期的に検証するデータベースのバックアップなどのデータベース保守作業に代わるものではありません。

このトピックで説明するデータの種類は、たとえば Exchange プロセスが行う書き込み I/O 要求などの Exchange サービスを実行することによってアクセスされるデータです。システムまたは OS のデータ レプリケーションについては、ここでは説明しません。

マイクロソフトは、さまざまな種類のレプリケーション ソリューションに対するサポートのポリシーを持っています。これらのサポート ポリシーの詳細については、マイクロソフト サポート技術情報の文書番号 895847「Exchange 2003 と Exchange 2000 の複数サイト データ レプリケーション サポート」を参照してください。

note注 :
Microsoft Exchange Server の複数サイト データ レプリケーションに関する展開のガイドラインについてのドキュメントをダウンロードして、印刷するか、またはオフラインで参照してください (このサイトは英語の場合があります)。

レプリケーション メカニズム

データ レプリケーションの目的は、リモート サイトにあるデータの最新のレプリカを維持することです。Exchange サーバーは、リモート サイトのレプリカを使用して、プライマリの場所でストレージまたはサイトが停止した場合の電子メール サービスの継続性を提供することができます。データ レプリケーションは、同期または非同期の方法で伝達できます。定義では、データが同期レプレケートされる場合、ホストはローカルの場所とリモートの場所の両方で I/O 書き込みがコミットされたときにのみ、ストレージから書き込み完了応答を受け取ります。つまり、書き込みが正常に終了したことがホストで確認されるには、その前にローカル ストレージおよびリモート ストレージの両方に変更が実装される必要があります。非同期モードでは、ホストは書き込みがローカル ストレージにコミットされたときに、ストレージから書き込み完了を受け取ります。レプリカも更新されたことを示すリモート ストレージからの確認を待つ必要はありません。

非同期レプリケーション

通常、非同期レプリケーションを使用する場合、ホスト アプリケーションは書き込みの待ち時間の増加に関して、同期レプリケーション モードを使用する場合ほどレプリケーション距離に影響されません。ただし、非同期レプリケーションを展開するときは次の問題に注意する必要があります。

  • データの損失   データ レプリケーションの頻度に応じて、リモート サイトでのデータ変更を、プライマリ サイトで行われた変更よりも遅らせることができます。プライマリ サイトが停止した場合、リモート サイトのレプリカは完全に最新ではなくなります。ほとんどのストレージ ソリューションでこの遅延を構成できますが、この動作によってデータの損失が生じる可能性があることに注意する必要があります。
  • データ整合性 (書き込み順序保持)   Exchange では、データベースと、データベースに関連付けられたトランザクション ログとの間に、書き込み順序の依存関係があります。Exchange は常に、最初にログ ファイルに変更を書き込んだ後、データベース ファイルに変更をコミットします。同期レプリケーション モードの場合、アプリケーションで書き込み順序を制御します。ただし、非同期モードでは、レプリケーション ソリューションによって、データをいつレプリケートするかが制御されます。レプリケーション ソリューションでレプリケーション時の書き込み順序が維持されないと、データベース ファイルが破損し、プライマリ サイトで障害が発生した場合にデータベースをマウントできない可能性があります。
  • パフォーマンスへの影響   多くのベンダは、自社の非同期ソリューションがストレージのパフォーマンスに影響しないと主張していますが、実際には、非同期レプリケーションの実行時はパフォーマンスが低下します。パフォーマンスの期待値はソリューションの実装によって異なるため、1 つの数字で表すことはできません。したがって、お客様は展開の前にソリューションを十分にテストする必要があります。その目標は、ソリューションが Exchange ユーザーに対して十分なストレージのパフォーマンスを提供できるかどうかを確認することです。

一部のソリューション プロバイダは、さまざまな技術を使用して書き込み順序保持の問題に取り組んでいます。非同期にレプリケートされたソリューションを正しく展開するには、お客様はベンダと協力して、非同期のテクノロジが次の要件を満たしていることを確認する必要があります。

  • ストレージ グループに属するすべてのデバイスの書き込み順序整合性を、継続的な相互の一貫性を含めて維持できること。
  • 望ましくはテスト環境と運用環境の両方で、回復可能であると証明されていること。
  • レプリケートされたデータのサポート計画を導入しているベンダによって提供されていること。

同期レプリケーション

Exchange の展開での同期レプリケーションの主な問題は、パフォーマンスに関連しています。クライアントの操作性が書き込みの待ち時間と密接に関連していることがテストによって示されています。同期レプリケーション ソリューションでは、Exchange サーバーあたりのホスト可能なメールボックスの数は少なくなります。パフォーマンスへの影響は、レプリケーションの距離、レプリケーション リンクの帯域幅、および使用率によって大きく異なります。同期レプリケーションは、メールボックスまたはサーバーのスケーラビリティに 75% もの低下を引き起こす可能性があります。Exchange 容量計画の方法論を使用して作業する場合、このスケーラビリティ低下の要因を考慮する必要があります。詳細については、このトピックの後半の「同期レプリケーションの展開計画」を参照してください。

同期レプリケーションは、プライマリ ストレージのデータ ファイルとレプリカを完全に同期するため、データの損失がないことを保証するソリューションであると一般に考えられてきました。ただし、この一般的な考えに反して、同期レプリケーション ソリューションでデータが失われるシナリオがあります。次の例に、このようなシナリオを示します。

通常、ストレージ データのレプリケーション ソリューションは次の 2 つの方法のいずれかでレプリケーション リンク エラーを処理します。

  • プライマリの記憶装置のみに書き込み I/O のコミットを続行し、そのレプリケーション リンクを使用するすべてのデバイスに対するすべての変更をログ ファイルに記録して、プライマリ ストレージにログを格納します。
  • 書き込み操作を失敗させ、ディスク障害が発生した場合と同様にアプリケーションでエラーを処理します。

レプリケーション ソリューションで最初の処理方法を使用した場合、データ損失の可能性があります。リンク エラー状態になった後間もなくプライマリ サイト障害が発生した場合、リンク エラー後にコミットしたデータはレプリケートされず、したがって、プライマリ ストレージの障害と共にデータは失われます。ストレージ レプリケーション ソリューションを設計するときは、これらの種類のエラー状態に注意し、このようなエラーの発生を減らすためにシステムを構築できるようにします。この例では、お客様はデータ損失の可能性を低くするために、冗長レプリケーション リンクを展開することを検討できます。

同期レプリケーション ソリューション

同期レプリケーション ソリューションは、レプリケーションが発生する場所によって、ホストベースのレプリケーションまたはストレージベースのレプリケーションに分類されます。ホストベースのレプリケーションでは、通常、ホストベースのソフトウェア (フィルタ ドライバ) を使用して I/O ストリームを中断し、レプリケーションを管理します。ストレージベースのレプリケーションは、ホストから離れた記憶装置レベルで発生します。両方のレプリケーション ソリューションを次のいずれかとして展開できます。

  • 地理的に分散したクラスタ (ジオクラスタ)   このカテゴリでは、同じクラスタに属するノードを異なるサイトに配置します。通常、Exchange サーバーはプライマリ サイトのノードでアクティブにホストされます。ソリューションによって、リモート サイトへの Exchange データの同期レプリケーションが提供されます。プライマリ サイトに障害が発生した場合は、Exchange 仮想サーバーをリモート サイトのパッシブ ノードにフェールオーバーし、レプリケートされた Exchange データを使用して仮想サーバーをオンラインにします。
    Microsoft Windows® Server Catalog には、地理的に分散したクラスタ ソリューションのカテゴリがあります。https://go.microsoft.com/fwlink/?LinkId=28572 で、Windows Hardware Qualified Lab (WHQL) によって確認された、地理的に分散したクラスタ ソリューションを検索できます (このサイトは英語の場合があります)。
  • その他   このカテゴリには、地理的に分散したクラスタを使用しない、その他すべての種類の同期レプリケーション展開が含まれます。これらのソリューションでは、プライマリ サイト障害時にレプリケートされたリモート サイトの Exchange データを使用するために、いくつかの他の手段を使用します (たとえば、スタンバイ ソリューション、レプリケーションと障害回復プロセスの組み合わせ)。

レプリケーション ソリューション ベンダから次の問題について確認を得ることを強くお勧めします。

  • 地理的に分散したクラスタのソリューションに分類されるソリューションですか。そうである場合、WHQL によって認定されていますか。このカテゴリのソリューションでない場合、記憶装置は、Windows Server Catalog の "Cluster Solutions, Geographically Dispersed Clustering Solution" にあるソリューションに含まれていますか。
  • レプリケーション ソリューションは、すべてのサイトで同時に停止した場合を除いて、考えられるすべてのデータ損失を防止しますか。
  • フェールオーバーおよびフェールバックを実行する手順はどのようなものですか。
  • レプリケーション ソリューションと予測した待ち時間によって、計画した Exchange のユーザー負荷を処理し、高品質なクライアントの操作性を提供できますか。

レプリケート対象の Exchange データ

Exchange は、データ中心のサーバー アプリケーションです。セカンダリ サイトに Exchange データをレプリケートすると、ストレージに関連した障害が発生した際の冗長性が実現されます。どのような種類のデータをレプリケートするかを正確に決めるのは、ビジネス上の決定です。ここで説明したさまざまな種類のデータを失うことに対するビジネス上の許容範囲を評価する必要があります。

レプリケート必須データ

次のデータをレプリケートする必要があります。

  • Exchange メールボックスのデータベース ファイルは、メッセージ データを格納します。各データベースは 2 つのファイルで構成されます。
    • メッセージと MAPI コンテンツを保持するデータベース ファイル (.edb)。
    • 非 MAPI のネイティブ コンテンツを保持するストリーミング ファイル (.stm)。
  • データベースにコミットされた各トランザクションを記録するトランザクション ログ ファイル (.log)。
  • ディスクに書き込まれたログ ファイル内のエントリに関する情報を含むチェックポイント ファイル (.chk)。

これらのすべてのファイルは、次のようなアクセスをクライアントに提供するために重要です。つまり、メールボックス サーバーへのアクセスと、メモリに保持されるデータベースの変更 (停電などのために Exchange サーバーのストアが正常にシャットダウンされない場合は失われる) のソフト リカバリへのアクセスです。これらのファイルには重要な側面があるため、このデータ セットは、レプリケートする必要があります。データベース ファイルのパスはデータベースのプロパティ ページで指定します。各データベースに独自のパスがあります。トランザクション ログ ファイルのパスとチェックポイント ファイルのパスは、ストレージ グループのプロパティ ページで指定し、ストレージ グループ内のすべてのデータベースによって使用されます。

パブリック フォルダ データベースをレプリケートする決定は、より複雑な決定です。レプリケートするかどうかは、部分的には展開の Exchange トポロジ設計に依存します。メールボックス データとは異なり、パブリック フォルダのデータは Exchange Server によって直接レプリケートできます。変更 (内容) をレプリケートするパブリック フォルダ ストアの複数のレプリカを作成できます。このデータ レプリケーションは、同期方式では実行されません。

ジオクラスタ ソリューションでは、クラスタ内のパブリック フォルダの同期レプリケーションを行う必要があります。これは、クラスタがセカンダリ サイトで完全に機能できるようになるために必要な要件です。クラスタ内のメールボックス データベースは、やはりクラスタ内にホストされるパブリック フォルダ ストア ("Default Public Store") をポイントしている必要があります。そうすることによって、クライアントは、セカンダリ サイトでクラスタが使用可能になった直後にログオンできます。エラー状態の際のメールボックスへのログオンを容易にするために、ジオクラスタ内のパブリック フォルダは階層のみをホストすればよく、必ずしも全部の内容をホストする必要はありません。パブリック フォルダの内容全部をホストし、ジオクラスタにホストされたパブリック フォルダ内で同期的にレプリケートするかどうかは、ビジネス上の決定です。パブリック フォルダのデータがコア ビジネスにとって重要であり、最小限の量のデータ損失しか許容できない場合は、Exchange Server パブリック フォルダ レプリケーション メカニズムの代わりに、ジオクラスタ ソリューションの使用を検討してください。パブリック フォルダのデータにこのレベルの可用性が必要でない場合は、メールボックス データ用にジオクラスタでない同期レプリケーション ソリューションを使用し、それに Exchange パブリック フォルダにあるレプリケーション メカニズムを組み合わせます。

レプリケート推奨データ

SMTP (Simple Mail Transfer Protocol) ローカル キュー データ (Mailroot ディレクトリ) が Exchange Server で処理されるとき、このデータは一時的に記憶装置に保持されます。この設計によって、サーバー障害時のデータ損失が防止されます。たとえば、送信先サーバーに到達できないとき、そのサーバーにルーティングされるメッセージは、配信できるようになるまでローカル サーバー キュー ディレクトリに格納されます。キュー データを格納したディスクに障害が発生した場合、キュー内のすべてのメッセージが失われます。キュー データは一時的という性質であるため、メール キューのバックアップについては、Exchange Server データベースのバックアップについて定義されているような定義済みのプロセスはありません。このキュー情報を保持するストレージにフォールト トレランス ソリューションまたは高可用性ソリューションを提供することによって、データ損失の可能性に対する保護策を講じることができます。また、サイト障害が原因で一時的なメッセージが失われることを許容できない環境においては、MTA キュー データ (MTADATA ディレクトリ) をレプリケートすることをお勧めします。

SMTP Mailroot (仮想サーバーのインスタンスごとに、Queue および Badmail の各ディレクトリを含む) のパスは、Exchange システム マネージャ (ESM) の SMTP 仮想サーバーのプロパティ ページの [メッセージ] タブ、および MTA キュー パスの X.400 プロパティ ページで指定します。Exchange キュー データをレプリケートすることが必要かどうかを決定するには、プロファイルを調べる必要があります。既存の Exchange トポロジがある場合、ローカル キュー内のデータ損失を許容できるかどうかを決定できます。パフォーマンス モニタ (Perfmon.msc) のローカル キューの長さを使って、または使用負荷のピーク時に ESM のキュー ビューアを使って、ローカル キュー内の予期されたデータの量を計測できます。キュー データのレプリケーションを行う必要がある場合、レプリケーションがもたらす待ち時間によってトランスポートにボトルネックが生じないように、レプリケーション環境でメッセージ処理のパフォーマンスをテストすることが重要です。Exchange Server Stress and Performance 2003 ツールを使用すると、キュー データをレプリケートする同期レプリケーション環境でトランスポートのスループットをテストできます。このツールは、Exchange Server Stress and Performance 2003 の Web サイトからダウンロードできます (このサイトは英語の場合があります)。

オプションのレプリケート対象データ

メッセージ追跡ログには、Exchange サーバーに転送されたすべてのメッセージ、Exchange サーバーから転送されたすべてのメッセージ、および Exchange サーバー内で転送されたすべてのメッセージに関する情報が含まれます。診断の目的のために、このデータが重要になることがあります。既定では、メッセージの追跡は有効になっていません。ただし、このデータがビジネスにとって重要である場合は、障害発生時の損失を防ぐためにレプリケートすることができます。メッセージ追跡ログのパスは、ESM の Exchange Server プロパティ ページで指定します。

レプリケーション メカニズムを構成するときのベスト プラクティス

各ベンダは、さまざまなレプリケーション オプションのために提供するレプリケーション メカニズムで、さまざまな独自の実装を行っています。特定のベンダとソリューションの詳細を話し合い、ベンダが提示しているソリューションが障害回復に関する組織の要件とサービス レベル アグリーメント (SLA) に合っているかどうかを確認する必要があります。以下の推奨事項は、特定のレプリケーション ソリューションにしか適用されない場合もあります。

note注 :
"レプリケーション ポイント" という用語は、レプリケーションが行われる場所として定義されます。ソリューションに応じて、この場所は、ホスト フィルタ ドライバ レベルまたはストレージ アレイ内のディスク スライスとすることができます。
  • 論理ボリューム レベルまたはマウント ポイント ボリューム レベルでレプリケーションを設定します。
    レプリケートする必要があるデータは、このトピックの「レプリケート対象の Exchange データ」のセクションに示したファイルに保持されていますが、論理ボリュームまたはマウント ポイント ボリュームの装置に対してレプリケーションが構成されていることを、ホスト レベルで確認する必要があります。たとえば、メールボックス データ パスが G:\MDB1\MDB1.EDB である場合は、ドライブ G がレプリケーションを実行する基本単位である必要があります。その結果、ドライブ G のすべてのデータがレプリケートされます。ファイル レベルまたはサブディレクトリ レベルでレプリケーションを行う設定は、人為的なミスが発生しやすいため、マイクロソフトではサポートしていません。
  • 多くのレプリケーション ポイントを作成します。
    同じレプリケーション ポイント宛ての複数の I/O をキューに入れる動作を少なくするには、できるだけ多くのレプリケーション ポイントを作成するようにストレージを構成します。多くのレプリケーション ポイント全体で I/O の負荷分散を行います。ストレージ ソリューションまたはレプリケーション ソリューションに応じて、この方法を使用するとキューに入れる I/O の数が減るため、全体的な I/O 読み取り/書き込みの待ち時間を削減できます。
  • トランザクション ログは異なる論理ボリュームに保持します。
    データをレプリケートするとき、各書き込み I/O 要求はレプリケーション ポイント レベルでキューに置かれます。Exchange のログはシーケンシャルなパターンで書き込まれ、それらの I/O が同じレプリケーション ポイント宛てである場合は、すべての I/O が書き込み待ちキューに入れられる可能性が大きくなります。この状況では、ログ書き込みの応答時間が長くなり、Exchange のパフォーマンスおよびスケーラビリティに関して大きなマイナス要因になることが考えられます。この理由により、異なるストレージ グループのトランザクション ログを、異なるレプリケーション ポイントを使用する異なる論理ボリュームに分割することをお勧めします。
  • 複数のレプリケーション リンクを使用します。
    多くの場合、プライマリ サイトとセカンダリ サイトの間に複数のレプリケーション リンクを構成することによって、レプリケーション ソリューションのパフォーマンスおよびスケーラビリティを改善できます。この方法は実装のコストが高く、Exchange データ レプリケーションには必要ありません。ただし、特定の Exchange データ レプリケーション ソリューションで目的のパフォーマンスおよびスケーラビリティを実現するために、複数のレプリケーション リンクを実装しなければならない展開環境もあります。また、レプリケーションの最適なスループットを得るために、利用可能なレプリケーション リンク全体でレプリケーション ポイントの負荷分散を行う必要もあります。
    Exchange では、データベースとデータベースに関連付けられたトランザクション ログとの間に書き込み順序の依存関係があるため、ストレージ グループの論理ボリュームを支援するレプリケーション ポイント グループ (データベースの論理ユニット番号 (LUN) とログ LUN を含む) を、同じレプリケーション リンクを使用するように構成することが重要です。この構成は、リンク障害などのエラー シナリオにおいてリモート サイトのデータ整合性の維持に不可欠な、ストレージ グループ レベルでの書き込み順序を維持するために必要です。
    複数のレプリケーション ポイントがある複数のレプリケーション リンクを使用することは、Exchange データ レプリケーション ソリューション拡張の効果的な方法になります。また、この方法によって、前に説明した「同期レプリケーション」のセクションで例に示したデータ損失の可能性を減らすことができます。

Exchange に同期レプリケーションを構成するときのベスト プラクティス

Exchange を同期レプリケーション環境に展開する場合、いくつかの構成変更によってサーバーのパフォーマンスおよびスケーラビリティを改善できます。これらの構成変更をストレージおよびレプリケーションの設計時に実装できるように、計画段階でこれらの構成変更について理解することが重要です。構成のベスト プラクティスに関する推奨事項は、次のとおりです。

  • Exchange サーバーごとに最大数のストレージ グループを作成します。
    同期的にレプリケートされる Exchange ソリューションでのストレージ グループ数を増やすと、複数の論理ボリューム全体 (したがって複数のレプリケーション ポイント全体) でログ書き込みトランザクションの負荷分散が行われ、展開のパフォーマンスおよびスケーラビリティに対して有利です。通常は、同時ログ書き込みプロセスが増え、同期レプリケーション環境での全体的なトランザクション ログ書き込み待ち時間を削減 (キューに入れる I/O を削減) できます。Exchange Server 2003 Enterprise Edition では、Exchange サーバーあたり 4 つのストレージ グループが許可されます。
  • トランザクション ログのバッファ サイズを増やします。
    Exchange ログ書き込み I/O の待ち時間は、同期レプリケーションの Exchange ソリューションでのスケーラビリティに大きく影響します。ログ書き込み I/O はシーケンシャルなシングルスレッド処理であるため、ログ I/O の待ち時間がシステムのボトルネックになる傾向があります。ログ I/O は最初にログ バッファに書き込まれ、次に即時コミットまたは遅延コミットによってバッファが消去されます。即時コミットは、ログ バッファがディスクにすぐ書き込まれることを意味します。遅延コミットは、バッファがいっぱいになったときに、ログ バッファがディスクに書き込まれることを意味します。
    ログ バッファのサイズを増やすと、容量到達時のフラッシュの頻度が減少し、ログ書き込みサイズが増加します。そのため、全体的なログ書き込み待ち時間が減少します。ログ I/O 書き込み待ち時間の削減は、Exchange 展開のパフォーマンスおよびスケーラビリティを向上させる重要な方法です。
    一般的な推奨事項として、ファイバ チャネルを介してレプリケーションを行う場合は、バッファ サイズを最大 9,000 に増やします。TCP/IP リンクなどの低帯域リンクの場合は、このパラメータの最適値を決定するのは容易ではありません。ログ書き込みサイズの増加に対してリンクが飽和状態になると、レプリケーションの処理速度が低下します。ログ書き込み待ち時間を最小限に抑える最適なログ バッファのサイズを決定するために、広範なテストを実行する必要があります。このパラメータを変更する方法については、マイクロソフト サポート技術情報の文書番号 328466「非常に低く設定された ESE ログ バッファは、Microsoft Exchange Information Store サービスが原因で応答を停止できます。」を参照してください。また、この設定についてソリューション プロバイダに相談してください。

同期レプリケーションの展開計画

同期レプリケーション ストレージ ソリューションで、この前に説明したすべての推奨事項に従ったとしても、展開の前にソリューションを十分にテストしない場合は、Exchange クライアントにパフォーマンスの問題が発生する可能性があります。Exchange に同期レプリケーションを実装した場合のスケーラビリティとパフォーマンスに対するマイナスの影響について、定義済みの規則はありません。各 Exchange レプリケーション ソリューションには、さまざまなパフォーマンス要因があります。たとえば、サイト間の距離、レプリケーション トランスポート メカニズム、レプリケーション リンクの数、レプリケーション ポイントの数、Exchange ストレージ グループの数、Exchange データベースまたはログの構成設定、ストレージとレプリケーション アーキテクチャ、Exchange クライアント プロファイルなどがありますが、他の要因がある場合もあります。各ソリューションには独自の特徴があり、展開を成功させるには徹底した計画とテストを行う必要があります。

同期レプリケーション ソリューションで生じる I/O 書き込み待ち時間は、Exchange のスケーラビリティを制限する重要な要因です。この増加した I/O 待ち時間によってサーバーに負荷が生じ、Exchange クライアントの操作性に多大な影響を及ぼします。特に、書き込み待ち時間が長いと RPC 待ち時間が増え、クライアントの操作性が遅くなります。同期レプリケーションは Exchange データの高い可用性を提供しますが、大幅な I/O パフォーマンスの低下を伴います。この I/O 書き込み (場合によっては読み取り) によるパフォーマンスの低下は、特定のプラットフォームでサポートできるユーザーの最大数を決定する際の重要な要因です。

計画段階で、設計を検証するために次の手順を実行します。

  1. Exchange でのストレージの最適な設計と実装の詳細については、「Exchange Server 2003 の記憶域の最適化」を参照してください。
  2. 同期レプリケーションを構成したストレージの生のスループットを検証するには、Jetstress テストを使用します。Jetstress ツールをダウンロードするには、Microsoft Exchange Server Jetstress Tool の Web サイトを参照してください (このサイトは英語の場合があります)。
  3. 使用する環境に合わせて調整した Exchange Server Load Simulator 2003 (LoadSim) テストを実行して、増加した書き込み待ち時間が電子メール クライアントに及ぼす影響を測定します。LoadSim をダウンロードするには、「Microsoft Exchange Server 2003 Load Simulator (LoadSim)」の Web サイトを参照してください (このサイトは英語の場合があります)。
  4. LoadSim を実行する際、平均ディスク スループットを測定します。ディスク スループットは、シミュレートしている運用環境 (IOPS/Mailbox) で予測されるピーク平均スループットに等しいか、それより高い必要があります。ピーク平均ディスク スループットを測定する方法の詳細については、「Exchange Server 2003 の記憶域の最適化
」を参照してください。
  5. LoadSim テストの実行後、サーバーおよびクライアント応答時間の RPC 平均待ち時間カウンタを注意して確認します。テスト結果を分析するときは、3 つのカウンタがすべて次に示す条件を満たしている必要があることに注意します。
    RPC 平均待ち時間
    このカウンタは、単一のリモート プロシージャ コール (RPC) 要求を処理するために必要な時間の長さの平均を示します。ユーザー負荷またはレプリケーション距離が増加すると、平均 RPC 待ち時間が増加します。平均の上限が 50 ミリ秒で、最大値が 100 ミリ秒である必要があります。テスト結果で 50 ミリ秒を超える平均が示されている場合、全体的なクライアントの操作性は遅いと予想されます。平均が 50 ミリ秒未満であっても、ときどき 100 ミリ秒を超える突出部状態がある場合、その突出状態の間クライアントの操作性は遅くなります。
    ディスク待ち時間のカウンタ
    Microsoft Exchange 製品チームでは、複数のハードウェア同期レプリケーション ソリューションをテストしました。結果は、RPC 平均待ち時間とディスク待ち時間の間の関連を示しています。一般的なガイドラインとして、データベース読み取り待ち時間の平均が 20 ミリ秒未満で、ログ読み取りおよび書き込み待ち時間の平均が 20 ミリ秒未満である場合は、ソリューションは与えられた負荷を処理できます。これらの待ち時間の最大値は、40 ミリ秒未満に維持される必要があります。これらのしきい値を上回ると、クライアントへの応答が遅くなる可能性が大きくなります。
    クライアントの応答時間
    すべてのクライアント コンピュータで lslog.exe を実行すると、全体的なクライアントの操作性を確認できます。この処理を実行すると、95% 計測法に従って処理した重み付け平均が返されます。返された値が 1,000 ミリ秒未満である必要があります。lslog.exe は LoadSim ツールの一部です。LoadSim のドキュメントで、Islog.exe の使用方法および返される結果の解釈方法について説明しています。
    パフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスに関するトラブルシューティングについてのページを参照してください (このサイトは英語の場合があります)。
  6. 予定されたレプリケーション距離に対してメールボックス プロファイルのソリューションをテストします。レプリケーション リンク距離には、物理的な制限があります。距離が延びた場合、距離を隔てた同期レプリケーションによって生じる書き込み待ち時間が増加し、その結果クライアントおよびサーバーの応答時間が遅くなります。通常、Exchange Server データの同期ストレージ レプリケーションでは 100 km がしきい値と見なされます。このしきい値はソリューションの実装に応じて異なります。
  7. 定期的にデータベースの整合性を検証するバックアップ計画を作成します。レプリケーションはバックアップ処理の代わりにはなりません。
  8. ソリューションのレプリケーション パフォーマンスとして十分テストされた包括的な障害復旧計画があることを確認します。Exchange のデータ、サーバー、およびサイトを回復するには、いくつかの方法があります。ビジネスの要件を満たす障害回復計画と、障害が発生した場合に迅速で効率的な回復フェーズを実施するための指針となるサービス レベル契約を実装する必要があります。Exchange を展開した環境で、負荷の高い状況下で同期レプリケーションを使用した複数種類のエラー状態をシミュレートすることによって、計画をテストおよび検証します。