次の方法で共有

ローカル連続レプリケーションの計画

  • [アーティクル]

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2008-01-04

ローカル連続レプリケーション (LCR) の計画には、ストレージ グループおよびデータベース トポロジの設計、適切なストレージ ソリューションのサポートおよび適切な LCR の監視の確認を行うことが必要です。

LCR の記憶域の要件および推奨事項

LCR には、記憶域の要件および推奨事項が含まれます。LCR ストレージ ソリューションを設計する際は、LCR 環境にはアクティブ コピーによるログの更新と、パッシブ コピーの同じようなログの読み取りがあるため、LCR に対する追加の入出力 (I/O) の使用方法を含めます。パッシブ コピーがアクティブ コピーと同じような容量とパフォーマンス機能を持つように、記憶域を設計することをお勧めします。LCR を使用する場合、以下のベスト プラクティスに従うことをお勧めします。

  • 1 ストレージ グループあたり単一のデータベースを使用します。   LCR でストレージ グループが有効な場合、単一のデータベースしか含むことができません。また、既存のストレージ グループが複数のデータベースを持っている場合、1 つのデータベースを残して後のデータベースをすべて削除するまでは、そのストレージ グループに対して LCR を有効にすることはできません。この方法によって、より管理しやすい Microsoft Exchange ストレージのトポロジが作成され、回復性が向上します。
  • ボリューム マウント ポイントを使用します。   データベース ファイルやトランザクション ログ ファイルの格納場所を指定するために、Exchange データの論理ユニット番号 (LUN) またはディスクに対してドライブ文字またはボリューム マウント ポイントを使用することができます。Exchange Server ごとに存在する 26 個までというドライブ文字の制限を超えるには、NTFS ファイル システム ボリューム マウント ポイント機能を使用することをお勧めします。ボリューム マウント ポイントを使用することで、別の物理ディスク上のフォルダ内に対象のパーティションを組み込んだり、マウントしたりすることができます。ボリューム マウント ポイントは、Exchange Server などのプログラムに対して透過的です。ボリューム マウント ポイントを使用すると、運用トランザクション ログまたはデータベース ファイルで破損が検出された場合に、すばやくドライブ文字の割り当てとパスを変更することができるので、回復処理が簡単になります。運用トランザクション ログまたはデータベース ファイルの破損を回復する方法の詳細については、「ローカル連続レプリケーションの管理」を参照してください。
  • パフォーマンスと回復性を高めるためにデータをパーティション分割します。   通常、ハード ディスクを複数のパーティションに分割してデータを配置すると、パフォーマンスが向上し、回復が必要なデータ量を低減できます。エラーの種類によっても異なりますが、データベースとトランザクション ログ ファイルを別のディスクに配置すると、データの損失を最小限に抑えることができます。たとえば、Exchange データベースとトランザクション ログ ファイルを物理的に同じハード ディスク上に保存していて、そのディスクに障害が発生した場合、最新のバックアップに存在していたデータしか回復できません。または、ログ ファイルとデータベース ファイルを別のディスクに配置するとします。データベース ファイルを格納しているディスクに障害が発生した場合、別のディスクに存在するログ ファイルからデータを回復できます。パフォーマンスを最適化し、フォールト トレランスを向上させ、トラブルシューティングを簡単にするには、データをパーティション分割して、次のファイルを別々のディスクに配置します。
    • Microsoft Windows オペレーティング システム ファイル
    • Exchange Server のアプリケーション ファイル
    • アクティブ コピーの Exchange データベース ファイル
    • アクティブ コピーの Exchange トランザクション ログ ファイル
    • パッシブ コピーの Exchange データベース ファイル
    • パッシブ コピーの Exchange トランザクション ログ ファイル
      また、LCR が有効なストレージ グループのパッシブ コピーは、LCR が有効なストレージ グループ内のアクティブ コピーとは別のディスクに配置する必要があります。さらに、LCR ファイルを格納するディスクが、運用ストレージ グループを格納するディスクと同じパフォーマンス機能を備えていることを確認する必要があります。この同等性によって、LCR コピーはフェールオーバーの場合の負荷をサポートできます。
  • 十分なディスク領域があることを確認します。   LCR ファイルを含むディスクは、運用ボリュームと同等なサイズを確保する必要があります。パッシブ コピー用の記憶域は、アクティブ コピー用の記憶域と同等である必要があります。また、いずれのストレージ ソリューションでも、既存のデータベースのサイズに加えて、予想されるデータベースの拡張に対応できる十分な領域が必要です。
  • iSCSI 記憶域を LCR で使用する場合は、十分な帯域幅と少ない待ち時間を確保します。   お勧めできませんが、ローカル エリア ネットワーク (LAN) またはワイド エリア ネットワーク (WAN) リンクでメールボックス サーバーに接続されたインターネット SCSI (iSCSI) 記憶域を使用した LCR の構成はサポートされています。この構成では、ログ配布処理とログ再生処理の両方が同じ記憶域ネットワーク上で発生します。この構成が勧められない大きな理由は、ログ配布によって生成されるネットワーク トラフィックです。LCR が期待されるレベルの保護を提供するには、ログ配布が最新の状態に保たれ、ログ配布に関連するネットワーク トラフィックがログ再生処理に関連するネットワーク トラフィックに影響を及ぼすほど帯域幅を消費しないことが非常に重要です。レプリケーション トラフィックの優先度設定を行う方法はありません。また、いくつか検討する必要のある記憶域の要件があります。
    • Microsoft Exchange Server 2007 の RTM (Release To Manufacturing) 版では、データベースのパッシブ コピーの記憶域は、データベースのアクティブ コピーに使用される記憶域の 2 倍から 3 倍の I/O per second (IOPS) を提供する必要があります。
    • Microsoft Exchange Server 2007 Service Pack 1 (SP1) では、パッシブ コピーの記憶域は、アクティブ コピーと同じにできます。
note注 :
Microsoft Exchange Server Jetstress Tool を使用して、運用環境で使用する前に、ストレージ ソリューションを検証することができます。最初にデータベースのアクティブ コピーに使用する記憶域を検証してから、データベースのパッシブ コピーに使用する記憶域を検証することをお勧めします。Jetstress の詳細については、「記憶域の検証」の「記憶域関連のツール」を参照してください。

LCR のプロセッサおよびメモリの推奨事項

Microsoft Exchange Server 2007 メールボックス サーバーの役割のすべてのサービス、および Microsoft Exchange レプリケーション サービスが同一サーバー上で実行されている場合、このサーバー上で LCR が有効なメールボックス サーバーを動作させるには、この追加の負荷に対処するためのハードウェア リソースが必要です。新たなリソース消費の大部分は、LCR が有効なメールボックス サーバーでのログ ファイルの検証およびログ ファイルの再生によって生じます。この処理コストの追加分は約 20% (「プロセッサ構成の計画」に記載されているガイダンスに加えて) であり、これは LCR メールボックス サーバーの処理能力の決定の際に考慮する必要があります。さらに、Microsoft Exchange レプリケーション サービスは、既存のメモリ リソースに基づく LCR サーバー上で適切に動作します。ただし、LCR 環境で Extensible Storage Engine (ESE) データベース キャッシュが最適な効率を維持できるように、Exchange メールボックス サーバーおよび複数の役割を持つサーバーには、さらに 1 GB の物理 RAM を追加することをお勧めします (「メモリの構成の計画」に記載されているメモリ ガイダンスにこのメモリ量を追加します)。

LCR のデータベース サイズの推奨事項

LCR は、致命的なデータ損失から回復するための、より高い柔軟性を備えています。LCR で致命的なストレージ エラーまたはデータベースの物理的な破損が発生した場合の第一の対応策は、データのパッシブ コピーをアクティブにし、バックアップからは何も復元しないことです。LCR は迅速なデータ回復を提供しますが、バックアップ ソリューションではないことに注意してください。LCR により、アーカイブやテープからの復元に基づく目標回復時間 (RTO) を短縮することの重要性は低くなります。テープから復元する代わりに、パッシブ コピーをアクティブ化すると、クライアントは数分以内 (数時間ではなく) にデータを利用できます。この意味で LCR は高速回復機構と見なすことができます。Exchange Server 2003 のボリューム シャドウ コピー サービス (VSS) を使用して作成されたハードウェア ベースの複製と同じ位置付けになります。

バックアップ不良が原因の修復作業など、管理者がオフラインのデータベース操作を実行することはよくあります。(テープの不良や復元の失敗など)。ただし、修復が必要になる状況の割合は大幅に減るものの、実際には、修復が必要になるときは必ずあります。データベースのサイズを決定するときは、最悪の場合のダウンタイムをどれだけ許容できるかを考慮してください。

LCR ではストレージ グループのパッシブ コピーからバックアップを作成できるので、アクティブ コピーのオンライン保守ウィンドウを拡張できます。多くの場合、オンライン保守ウィンドウは 2 倍にすることができます。これにより、メールボックスやデータベースのサイズも拡張できるようになります。

ここまでの説明で、LCR を使用すれば、リスクを心配する必要なく、データベースを希望のサイズに拡張できるように見えますが、実際はそうではありません。データベースごとに妥当な時間内で完了するオンライン保守は、データベース サイズの制限要因になっています。LCR の場合は、データベースを再シードする必要が生じる可能性もデータベース サイズの制限要因になっています。LCR はデータベースの冗長性を提供します。したがって、データベースのアクティブ コピーが損失または破損した場合は、データベースのパッシブ コピーを手動でアクティブ化することで、短時間のうちにデータベースを回復できます。

アクティブ化が行われた後は、データベースの新しいアクティブ コピーが 1 つしか残りません。パッシブ コピーは存在しないので、データベースの復元ができなくなる可能性があります。ただし、バックアップは残っています。復元を再有効化するには、損失または破損したデータベースを削除し、データベースのアクティブ コピーから新しいパッシブ コピーを作成および再シードする必要があります。データベースのサイズによっては、この作業には長い時間がかかる場合があります。最悪のシナリオは、すべてのアクティブ コピーが損失または破損することです。その場合は、すべてのパッシブ コピーを再シードする必要があります。

連続レプリケーションを使用すると、最大データベース サイズがさらに拡大する可能性があります。Exchange 2007 では、次の最大データベース サイズを使用することをお勧めします。

  • LCR を使用しないメールボックス サーバーでホストされるデータベース : 100 GB
  • LCR を使用するメールボックス サーバーでホストされるデータベース : 200 GB
    important重要 :
    データベースの本来の最大サイズは、組織で導入されているサービス レベル アグリーメント (SLA) によって決まります。組織の SLA で指定された期間内にバックアップおよび復元できる最大のサイズを計算することで、データベースの最大サイズが決まります。

LCR およびパブリック フォルダ データベース

LCR およびパブリック フォルダ レプリケーションは、Exchange に組み込まれた 2 つのまったく異なるレプリケーション フォームです。連続レプリケーションとパブリック フォルダ レプリケーションの間には相互運用性に関して制限があります。Exchange 組織内の複数のメールボックス サーバーがパブリック フォルダ データベースを保持している場合、パブリック フォルダ レプリケーションが有効になるため、パブリック フォルダ データベースは LCR が有効なストレージ グループでホストしないでください。

Exchange 組織でパブリック フォルダ データベースと LCR を使用するための推奨構成を以下に示します。

  • Exchange 組織内に 1 つのメールボックス サーバーが存在し、そのメールボックス サーバーがスタンドアロン メールボックス サーバーである場合、このメールボックス サーバーは LCR が有効なストレージ グループ内のパブリック フォルダ データベースをホストできます。この構成では、Exchange 組織に単一のパブリック フォルダ データベースが存在しています。したがって、パブリック フォルダ レプリケーションは無効になります。
  • 複数のメールボックス サーバーが存在し、そのいずれかのメールボックス サーバーにのみパブリック フォルダ データベースが含まれる場合、このメールボックス サーバーは LCR が有効なストレージ グループ内のパブリック フォルダ データベースをホストできます。この構成では、Exchange 組織に単一のパブリック フォルダ データベースが存在しています。したがって、パブリック フォルダ レプリケーションは無効になります。
  • パブリック フォルダ データを LCR が有効なストレージ グループに移行している場合、パブリック フォルダ レプリケーションを使用して、パブリック フォルダ データベースのコンテンツを LCR が有効なストレージ グループ内のパブリック フォルダ データベースに移動できます。LCR が有効なストレージ グループでのパブリック フォルダ データベースの作成後、パブリック フォルダ データが LCR が有効なストレージ グループ内のパブリック フォルダ データベースに完全にレプリケートされるまでの間だけ、他のパブリック フォルダ データベースが存在する必要があります。レプリケーションが正常に完了したら、LCR が有効なストレージ グループ外にあるすべてのパブリック フォルダ データベースを削除し、Exchange 組織内では他のパブリック フォルダ データベースをホストしないでください。
  • パブリック フォルダ データを LCR が有効なストレージ グループ外に移行している場合、パブリック フォルダ レプリケーションを使用して、パブリック フォルダ データベースのコンテンツを LCR が有効なストレージ グループ内のパブリック フォルダ データベース以外の場所に移動できます。LCR が有効なストレージ グループ外での他のパブリック フォルダ データベースの作成後、パブリック フォルダ データが他のパブリック フォルダ データベースに完全にレプリケートされるまでの間だけ、LCR が有効なストレージ グループ内のパブリック フォルダ データベースが存在する必要があります。レプリケーションが正常に完了したら、LCR が有効なすべてのストレージ グループ内のすべてのパブリック フォルダ データベースを削除し、それ以降のパブリック フォルダ データベースは、連続レプリケーションが有効なストレージ グループではホストしないでください。

Exchange 組織内に複数のパブリック フォルダ データベースが存在し、LCR が有効なストレージ グループ内で 1 つ以上のパブリック フォルダ データベースがホストされている間に、LCR がアクティブなストレージ グループで障害が発生し、パブリック フォルダ データベースがあるストレージ グループのパッシブ コピーをアクティブにする必要がある場合、パブリック フォルダ データベースをホストしているストレージ グループのすべてのログを使用可能な場合にのみマウント可能にすることができます。アクティブ コピーの障害により、欠落しているログまたは使用できないログがある場合、パブリック フォルダ データベースのパッシブ コピーをアクティブにすることはできません。この場合、データ損失を防ぐためにアクティブ コピーをオンラインにするか、パブリック フォルダ データベースをストレージ グループのアクティブ コピーで再作成し、パッシブ コピー以外のパブリック フォルダ データベースからパブリック フォルダ レプリケーションを使用してそのコンテンツを回復する必要があります。

LCR の監視に関する推奨事項

LCR は、データ可用性を提供する適切なソリューションです。このソリューションは、予防的に監視する必要があります。Exchange 2007 は、LCR コピーについてさまざまな状態情報を公開します。ストレージ グループの LCR を有効にしたら、Exchange 管理コンソールまたは Exchange 管理シェルを使用して、LCR コピーの状態と構成設定を表示することができます。状態と構成の情報を表示する手順の詳細については、「ローカル連続レプリケーション コピーの状態を表示する方法」を参照してください。

予防的で自動化された監視を行うには、Microsoft Operations Manager (MOM) および MOM 用 Exchange 2007 管理パックを使用することをお勧めします。LCR を監視する方法の詳細については、「監視および運用管理」を参照してください。

Exchange 2007 SP1 では、Test-ReplicationHealth という新しいコマンドレットを使用して、LCR を有効にしたストレージ グループの状態を確認することもできます。Test-ReplicationHealth コマンドレットの詳細については、「Test-ReplicationHealth」を参照してください。

バックアップと復元および LCR

LCR では、ログ配布、ログの再生、およびデータのセカンダリ コピーへの手動による迅速な切り替えが可能です。これらの機能は、データ レベルの障害の回復に要する時間を短縮します。また、LCR により、十分なデータ保護に必要なバックアップの回数が減少します。LCR によってバックアップを作成する必要性がなくなるわけではありませんが、毎日の完全バックアップを作成する必要性は削減されます。さらに LCR により、アクティブなストレージ グループからパッシブなストレージ グループにボリューム シャドウ コピー サービス (VSS) バックアップの負荷を移動することができます。クライアントを処理するためにアクティブ コピーの LUN 上の貴重なディスク I/O を保持するパッシブ コピーの場所から、4 種類のバックアップ (完全、コピー、増分、および差分) をすべて取得できます。

全体的な総保有コスト (TCO) の削減以外にも、LCR には以前のバックアップ ソリューションと比べてより多くの利点があります。LCR では Exchange データベースの追加のコピーを持つことになるため、次のような利点がもたらされます。

  • データベース バックアップの頻度の低減   LCR コピーは、運用データベースのエラーに対する第一の対応策です。バックアップ コピーが必要になる前に、運用ストレージ グループおよびストレージ グループ コピーの両方にエラーが発生することがあります。したがって、このような場合のためにより長期にわたるサービス レベル契約 (SLA) をお勧めします。長期にわたる SLA では、毎週の完全バックアップと毎日の増分バックアップが推奨されます。
  • 障害からの迅速な回復   通常、回復は 10 分未満で行われ、データが失われることはほとんどありません。
  • より大きなメールボックス クォータのサポート   データベース サイズに左右されない迅速な回復の結果として実現されます。

バックアップおよび復元の詳細および具体的なガイダンスについては、「障害回復」を参照してください。

Exchange のバックアップと LCR

Exchange 対応のバックアップは、アクティブなストレージ グループやデータベース、およびパッシブなデータベースのコピーでサポートされます。

note注 :
Exchange 対応のバックアップ中に行われる一般的なタスクとして、バックアップが正常に完了した後でトランザクション ログ ファイルの切り詰めが実行されます。LCR のレプリケーション機能によって、レプリケートされていないログが削除されないことが保証されます。このため、ログを削除するモードでバックアップを実行する場合、レプリケーションがログのコピー操作において大きく遅れると、実際には領域が解放されない可能性があります。

この構成における Exchange 対応のバックアップは、ストリーミング ソリューションまたは VSS バックアップ ソリューションを使用して実行できます。ストリーミング バックアップはアクティブ コピーでのみ実行できますが、VSS バックアップはアクティブ コピーまたはパッシブ コピーのいずれからも実行できます。

Exchange の復元と LCR

Exchange 対応の復元は、ストリーミング ソリューションまたは VSS バックアップ ソリューションを使用して実行できます。アクティブ データベースとログ ファイルの場所を復元先にすることができます。Exchange 対応のパッシブ コピーの場所への直接的なデータベース バックアップの復元は、ネイティブではサポートされていません。パッシブ コピーの場所への復元は、ファイル レベルの復元によって手動で行うことができます。

LCR 用に構成されたストレージ グループからデータベースを復元する前に、そのストレージ グループの LCR を中断する必要があります。復元が完了したら、LCR を再開できます。復元しようとしているデータベースの LCR は中断される必要があります。

バックアップからデータベースを LCR が有効になっているストレージ グループに復元し、Suspend-StorageGroupCopy と Resume-StorageGroupCopy をそれぞれ使用して、ストレージ グループの連続レプリケーションを中断してから再開する必要があります。このプロセスは、正しいログ生成情報を持つ Microsoft Exchange Replication Service を更新するために必要になります。連続レプリケーションが中断されず、また再開されない場合、Microsoft Exchange Replication Service は古いログ生成情報を保持し、ログ ファイルのレプリケーションを停止します。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。