クラスタ連続レプリケーション

  • [アーティクル]

 

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

トピックの最終更新日: 2008-03-21

クラスタ連続レプリケーション (CCR) は、Microsoft Exchange Server 2007 の高可用性機能であり、Exchange 2007 に組み込まれている非同期のログ配布および再生テクノロジと、クラスタ サービスが提供するフェールオーバーおよび管理機能を結合します。

CCR は、以下の特徴を備えたソリューションを提供することで、Exchange 2007 メールボックス サーバーの可用性を高めるように設計されています。

  • 単一障害点がない。
  • 特別なハードウェア要件がない。
  • 共有記憶域要件がない。
  • 1 または 2 データセンター構成に展開できる。
  • 完全バックアップの回数の削減、バックアップされるデータ量全体の削減、および最初の障害からの回復時間に関するサービス レベル契約 (SLA) の短縮が可能である。

CCR は Exchange 2007 のデータベース障害回復機能を使用して、データベースのアクティブなコピーに対する変更によるデータベースの 2 番目のコピーの連続的で非同期な更新を実現します。CCR 環境でのパッシブ ノードのインストール中、各ストレージ グループとそのデータベースはアクティブ ノードからパッシブ ノードにコピーされます。この処理はシードと呼ばれ、レプリケーションのためのデータベースのベースラインとなります。最初のシードが実行された後、ログのコピーと再生が続けて実行されます。

CCR 環境では、高可用性ソリューションを提供するためにレプリケーション機能がクラスタ サービスと統合されています。データとサービスの可用性の提供に加えて、CCR はスケジュールされた停止も提供します。更新プログラムのインストールや保守の実行が必要になった場合、管理者はクラスタ化メールボックス サーバー (以前のバージョンの Exchange Server では Exchange 仮想サーバーと呼ばれていました) を手動でパッシブ ノードに移動できます。移動操作が完了すると、管理者は必要な保守を実行できます。

移動操作は、Exchange 管理シェルの Move-ClusteredMailboxServer コマンドレットを使用して実行します。また、Microsoft Exchange Server 2007 Service Pack 1 (SP1) には、クラスタ化メールボックス サーバーの移動に使用できる、新しいクラスタ化メールボックス サーバーの管理ウィザードが Exchange 管理コンソールに搭載されています。これらのタスクにより使用されるロジックでは、メールボックス データが移動中に失われないようにするために必要な処理を実行します。また、これらのタスクは、パッシブ ノード上のレプリケーションをすぐにアクティブ化できるようにするために移動前にチェックを実行します。

CCR に関する重要な事実は次のとおりです。

  • 連続レプリケーションは非同期である   ログは、閉じられてメールボックス サーバーによって使用されなくなるまでコピーされません。これは、アクティブ ノード上に存在するすべてのログ ファイルのコピーを通常はパッシブ ノードが持たないことを意味します。1 つの例外は、管理者がアクティブ ノードのスケジュールされた停止を開始して、更新を適用したり、その他の保守を実行したりした場合です。
  • 連続レプリケーションでは、通常の処理中にアクティブ ノードで CPU 負荷や入出力 (I/O) 負荷が発生することはほとんどない   CCR はパッシブ ノードを使用してログのコピーと再生を行います。ログはセキュリティで保護されたファイル共有経由でパッシブ ノードからアクセスされます。
  • クラスタの有効期間全体にわたるアクティブ ノードとパッシブ ノードの変更は自動的に指定される   たとえば、フェールオーバーの後、アクティブとパッシブの指定が逆になります。これはレプリケーションの方向が逆になることを意味します。レプリケーションを逆にするための管理操作は不要です。システムはレプリケーションの反転を自動的に管理します。
  • フェールオーバーとスケジュールされた停止は機能面とパフォーマンス面で対称的である   たとえば、ノード 1 からノード 2 へのフェールオーバーには、ノード 2 からノード 1 へのフェールオーバーとちょうど同じ時間がかかります。一般に、これは 2 分以内です。大規模なサーバーでは、スケジュールされた停止は通常 4 分未満です。フェールオーバーとスケジュールされた停止の時間差は、スケジュールされた停止でアクティブ ノードの制御されたシャットダウンを実行するためにかかる時間に関連します。このパフォーマンスの差異は今後の Service Pack で小さくなる可能性があります。
  • パッシブ ノードでのボリューム シャドウ コピー サービス (VSS) バックアップがサポートされる   これによって、管理者はバックアップをアクティブ ノードからオフロードして、バックアップの時間枠を拡張できます。さらに、大規模な構成で、パフォーマンス要件によって、VSS バックアップ用のハードウェア VSS サポートを用意することが強制されません。パッシブ ノードの負荷は主にログのコピーと再生ですが、どちらにもアクティブ ノード上のクラスタ化メールボックス サーバーのようなリアルタイムの制約はありません。たとえば、アクティブ ノードは適切なタイミングでクライアント要求に応答する必要があります。パッシブ ノードにはリアルタイム応答の制約がないため、バックアップの時間枠を拡大でき、それによりデータベースやメールボックスのサイズを大きくすることができます。
  • バックアップ メディア上のデータ全体が削減される   CCR パッシブ コピーは、データの破損や損失に対する第一の対応策です。このため、障害が 2 回発生するまでバックアップは必要になりません。最初の障害からの回復は、復元を必要としないため SLA は比較的短くできます。2 番目の障害からの回復では、SLA は大幅に長くなる可能性があります。結果として、毎週の完全バックアップと毎日の増分バックアップを組み合わせた戦略でバックアップを実行できます。この方法により、バックアップ メディアに配置する必要があるデータの全体量が削減されます。
  • CCR はスタンバイ連続レプリケーション (SCR) と組み合わせることができる   CCR を SCR と組み合わせることができ、ストレージ グループのレプリケートをプライマリ データセンターでローカルに (高可用性のために CCR を使用して) 実行したり、セカンダリやバックアップ データセンターでリモートに (サイト復元性のために SCR を使用して) 実行したりすることができます。セカンダリ データセンターでは、SCR ターゲットをホストするパッシブ ノードをフェールオーバー クラスタ内に持ちます。この種のクラスタがスタンバイ クラスタと呼ばれるのは、クラスタ化メールボックス サーバーをメンバとして持たないからですが、回復シナリオにおいて代替クラスタ化メールボックス サーバーを持つクラスタとして迅速に準備することができます。障害発生などが原因でプライマリ データセンターが使用不可能になった場合は、このスタンバイ クラスタでホストされている SCR ターゲットをスタンバイ クラスタ上ですばやくアクティブ化できます。

CCR コア アーキテクチャ

CCR は以下の要素を結合します。

  • Microsoft フェールオーバー クラスタによって提供されるフェールオーバーと仮想化の機能
  • ファイル共有をクラスタ動作監視として使用する、マジョリティベースのフェールオーバー クラスタ クォーラム モデル
  • Exchange 2007 におけるトランザクション ログのレプリケーションと再生の機能
  • ハブ トランスポート サーバー上のトランスポート収集と呼ばれるメッセージ キュー機能

Windows フェールオーバー クラスタ

次の図に示すように、Exchange 2007 SP1 では、CCR は、1 つのフェールオーバー クラスタに参加した 2 台のコンピュータ (ノードと呼ばれます) を使用し、このクラスタでは Windows Server 2003 Service Pack 2 または Windows Server 2008 が実行されています。フェールオーバー クラスタのノードは 1 つのクラスタ化メールボックス サーバーをホストします。クラスタ化メールボックス サーバーを現在実行しているノードはアクティブ ノードと呼ばれます。クラスタ化メールボックス サーバーを実行していないがクラスタの一部であり、連続レプリケーションのターゲットであるノードはパッシブ ノードと呼ばれます。スケジュールされた保守とスケジュールされていない停止の結果として、ノードのアクティブまたはパッシブとしての割り当ては、フェールオーバー クラスタの有効期間内に何回か変化します。

クラスター連続レプリケーションのアーキテクチャ

フェールオーバー クラスタは、クラスタ サービスと、特定の種類のクラスタ クォーラム モデルを使用して構築されます。

ファイル共有監視

前に示したクォーラム モデルはいずれも、3 番目のコンピュータにあるファイル共有を監視として使用しています。これらのクォーラム モデルでは、3 番目のコンピュータにあるファイル共有を使用して、クラスタ内のネットワーク パーティション (スプリット ブレイン現象とも呼ばれます) の発生を回避します。スプリット ブレイン現象は、内部のクラスタ通信を伝達するよう設計されているすべてのネットワークに障害が発生し、ノードが相互にハートビート信号を受信できない場合に発生します。スプリット ブレイン現象は、クラスタ化メールボックス サーバーが運用可能なように、次のことを常に必須とすることで防止されます。つまり、2 つのノードの過半数とファイル共有が使用可能で通信を行っていることです。コンピュータの過半数が通信を行っている場合、そのクラスタはクォーラムを保持していると表現します。ファイル共有監視に使用するファイル共有は、Windows Server を実行している任意のコンピュータでホストできます。ファイル共有をホストする Windows Server オペレーティング システムのバージョンが、CCR 環境のオペレーティング システムと一致しなければならないという要件はありません。ただし、ファイル共有をホストするには、クラスタ化メールボックス サーバーを含む Active Directory ディレクトリ サービス サイトのハブ トランスポート サーバーを使用することをお勧めします。これによって、メッセージング管理者はファイル共有の制御を維持できます。

note注 :
ファイル共有監視には、分散ファイル システム (DFS) 環境でホストされているファイル共有は使用できません。

ファイル共有監視は、クラスタの外部にあるコンピュータ上のファイル共有を使用して、クラスタである 2 つのノードの動作に対する監視として機能します。監視は、2 つのノードでどちらのノードがクラスタを制御しているかを追跡するために使用されます。メモ ボードは、2 つのノードが互いに通信できない場合にのみ必要です。Node1 と Node2 で構成された 2 ノードのクラスタ化メールボックス サーバーを考えてみます。この場合、メモ ボードの制御権を獲得できるノードは Node1 であり、したがって Node1 はクラスタの制御権を獲得してクラスタ化メールボックス サーバーを起動できます。Node2 が動作可能であり、Node1 と通信できない場合、Node2 はメモ ボードの制御権を獲得しようとします。Node2 はメモ ボードを制御できず、したがってクラスタ化メールボックス サーバーを起動できません。

2 つのノードが相互に通信できる場合、メモ ボードは不要であり、オフラインにすることができます。しかし、その後いずれかのノードに障害が発生した場合、ファイル共有監視が使用できないとクラスタ化メールボックス サーバーをオンラインにすることはできません。

ファイル共有は、前に説明した状態しか維持しません。そのため、すべてのクラスタ構成情報は 2 つのノード自身の間で交換されます。この点を理解することが重要です。つまり、Node1 が使用可能で Node2 が使用可能でない場合、Node2 とファイル共有監視の通信が可能でも、Node2 と Node1 の通信が行われるまで、Node2 は使用可能になりません。

ファイル共有監視サポートは、定期的にファイル共有監視のアクセス チェックを行います。アクセス チェックが失敗すると、イベントが生成されます。イベントは、監視システムによって検出、収集、および報告できます。これによって運営スタッフは、問題と同時に発生する第 2 の障害によって停止が引き起こされる前に、問題を修正できます。

ファイル共有は以下の状況でアクセスされます。

  • クラスタ ノードが起動した時点で、使用可能なクラスタ ノードが 1 つだけであるとき。
  • ネットワーク接続に関する問題によって、それまで接続できたノードがクラスタと通信できなくなるとき。
  • クラスタ ノードがクラスタを離脱するとき。
  • 定期的な検証のため。この頻度は構成可能です。

これらの理由から、ファイル共有上の負荷は低くなります。そのため、単一のサーバーで、複数の CCR 環境に対してファイル共有を提供することができます。ただし、各 CCR 環境にはこのサーバー上に専用のフォルダと共有が必要です。

ファイル共有監視の考慮事項

CCR は 2 ノード環境で、ファイル共有監視を備えた MNS クォーラム、または従来の MNS クラスタで必要であったクラスタ内の 3 つ目のノード (またはそれ以上のノード) の代わりにノードおよびファイル共有マジョリティ クォーラムのいずれかを使用します。地理的に分散されている CCR 環境は、アクティブ ノードがプライマリ データセンターに展開され、パッシブ ノードがセカンダリ データセンターに展開されている、2 データセンター展開です。そのため、地理的に分散されている CCR 環境では、プライマリ データセンターへの配置または 3 つ目のデータセンターへの配置という、ファイル共有の配置に関して 2 つのオプションがあります。

第 1 のオプションでは、プライマリ データセンターのハブ トランスポート サーバー上でファイル共有を構成します。ハブ トランスポート サーバーにより、メッセージング管理者はファイル共有の停止を管理および監視できるため、ハブ トランスポート サーバーをお勧めします。マイクロソフトの経験と、顧客からのフィードバックにより、最も一般的な種類のネットワーク サービス中断は、ワイド エリア ネットワーク (WAN) トポロジで生じることが示されています。プライマリ データセンターにファイル共有を配置することが有効であるのは、2 つのデータセンター間でのネットワーク障害によるサービス中断が防止されるためです。この構成を使用することは、プライマリ データセンターで停止が発生した場合も、自動フェールオーバーが行われないことを意味します。ただし、フェールオーバー クラスタの大部分は、プライマリ データセンターとセカンダリ データセンター間のネットワーク障害の影響を受けなくなります。

第 2 のオプションでは、3 つ目の物理サイト内の管理サーバーの役割上でファイル共有を構成します。管理サーバーの役割は、メッセージング サービスの配信に重要なその他のサーバーと同じ程度までサポートおよび維持されるサーバーです。管理サーバーの役割の例には、プライマリ データセンター内のハブ トランスポート サーバーがあります。この第 3 の物理サイトは、支店または 3 つ目のデータセンターであることがあります。この構成の要件は、第 3 のサイトには、遅延が短く信頼性が高い、プライマリ データセンターとセカンダリ データセンターへのネットワーク インフラストラクチャが必要であることです。

トランザクション ログのレプリケーションと再生

トランザクション ログのレプリケーションと再生は、変更されたデータをコピーし、パッシブ コピーのデータベースを更新するために使用されます。レプリケーションは、Extensible Storage Engine (ESE) によって生成された変更履歴を利用します。この変更履歴は、1 MB (メガバイト) という一定のサイズを持つ一連のログ ファイルで表されます。レプリケーション機能は、それぞれのログ ファイルが生成されたときに、ログ ファイルをパッシブ ノードにコピーします。このレプリケーション メカニズムは、オンライン データベースとは同期していません。ログは、パッシブ ノードに到着すると、破損がないかチェックされてから、そのパッシブ ノードに格納されているデータベースのコピー内に再生されます。この再生処理によって、変更ログで説明されている変更がパッシブ ノードのデータベースに適用されるため、パッシブ ノードのデータベースはわずかな時間差で運用データベースと整合します。

ノード間でデータがレプリケートされるため、クラスタ化メールボックス サーバーはクラスタ内のいずれかのノードで動作できます。この機能により、1 つのノードでスケジュールされた停止やエラーが発生しても、クラスタ化メールボックス サーバーの停止時間は長くならないため、可用性が向上しています。さらに、1 つのノード上の記憶域のサービスが停止しても、他のノードおよびクラスタ化メールボックス サーバーの可用性には影響しません。ファイル共有がまだ利用でき、ファイル共有とパッシブ ノードとの通信が可能であれば、アクティブ ノードが停止するとクラスタ化メールボックス サーバーは残っているノードに移動し、継続して動作します。

CCR 環境では、アクティブ ノード上のトランザクション ログ ファイルのフォルダは標準的な Windows ファイル共有を使用して共有されます。ストレージ グループのオブジェクト グローバル一意識別子 (GUID) は共有名として使用され、共有の最後にドル記号 ($) が追加されます。パッシブ ノード上の Microsoft Exchange レプリケーション サービスは、アクティブ ノード上の共有に接続し、サーバー メッセージ ブロック (SMB) プロトコルを使用してログ ファイルをコピー (またはプル) します。次に、パッシブ ノードがログ ファイルを検証し、パッシブ ノード上のデータベースのコピー内に再生します。

note注 :
トランザクション ログのレプリケーションのための SMB トラフィックは暗号化されません。必要に応じて、インターネット プロトコル セキュリティ (IPSec) を使用してこのトラフィックを暗号化できます。SMB プロトコルを使用して行われるのはトランザクション ログ ファイルのレプリケーションのみです。パッシブ コピーの再シードは ESE バックアップ API (Application Programming Interface) を使用して行われます。これは暗号化されていない通信です。必要に応じて、IPSec を使用して、このデータを暗号化できます。

冗長化されたクラスタ ネットワーク上での連続レプリケーション

Microsoft Exchange Server 2007 の RTM (Release To Manufacturing) 版では、CCR 環境でのすべてのトランザクション ログ ファイルのコピーとシードは、パブリック ネットワーク上で行われます。この構成には次のような制限があります。

  • パッシブ ノードが数時間使用できない場合、転送する必要がある多数のログが作成される可能性があります。パッシブ ノードが使用可能になった時点で、これらのログの移動をできるだけ迅速に行う必要があります。パブリック ネットワーク上でログをコピーすることにより、ログの移動はクライアント トラフィックと競合します。これは、クライアント トラフィックに影響し、再同期を遅らせます。
  • パブリック ネットワークに障害が発生した場合、ログ データが使用できる場合であっても、フェールオーバーには損失が生じます。
  • ログ通信用に独立したネットワークを使用することで、暗号化の使用とそれに関連するパフォーマンスの不利益のない、メッセージング データ用のセキュリティを実現できます。
  • 状況によっては、ログ ストームが発生することがあります。ログ ストームが発生すると、システムには著しく高いレプリケーションの負荷が生じます。クライアントとの通信に使用される同じネットワーク上でログ データを通信する必要がある場合、これはクライアント スタベーションの原因になる可能性があります。

これらの問題がすべて同じ頻度で生じるわけではありません。ただし、パッシブ ノードは定期的な保守作業のためにオフラインにされるため、第 1 の問題は事実上数か月ごとに確実に発生します。

Exchange 2007 SP1 は、管理者がログ配布用にクラスタ内に 1 つ以上の混合ネットワーク (混合ネットワークは、内部クラスタ ハートビート トラフィックとクライアント トラフィックの両方をサポートするクラスタ ネットワークです) を作成できるようにすることで、上記の問題の影響を最小限にします。また、Exchange 2007 SP1 では、管理者はシードに使用される特定の混合ネットワークを指定することができます。

note注 :
ログ配布およびシードに使用されるクラスタ ネットワークは、混合ネットワークとして構成する必要があります。混合ネットワークは、クラスタ (ハートビート) およびクライアント アクセス トラフィックの両方に対して構成されているクラスタ ネットワークです。また、連続レプリケーション ホスト名を使用して構成されているネットワーク アダプタでは、管理者は "TCP/IP 詳細設定" プロパティ ダイアログ ボックスの [この接続のアドレスを DNS に登録する] チェック ボックスをオフにし、各ノードで静的 DNS エントリまたは Hosts ファイル エントリを使用して、新たに作成されたホスト名が各ノードで解決できるようにする必要があります。ネットワーク アダプタにより使用される DNS サーバーは、パブリックまたはプライベート ネットワーク上に配置できますが、その場所に関係なく、ホスト名解決を行えるよう、両方のノードによりアクセスできる必要があります。さらに、Windows Server 2008 では、ログ配布やシードに使用されるネットワーク アダプタで NetBIOS が有効になっている必要があります。

混合ネットワークでのログ ファイルのコピーのサポートは、Enable-ContinuousReplicationHostName と呼ばれる新しいコマンドレットを使用して構成します。また、この機能をオフにするには、Disable-ContinuousReplicationHostName コマンドレットを使用します。

CCR 環境にクラスタ化メールボックス サーバーが存在するようになった後、管理者はクラスタの両方のノードで Enable-ContinuousReplicationHostName を実行して、追加の IP アドレスとホスト名を指定することができますが、これらは、各ノードに関連付けられた専用のクラスタ グループに作成されます。この作業が完了してから、構成が成功した直後、および新しいネットワークが稼働していることを確認した時点で、Microsoft Exchange レプリケーション サービスは、ログ コピー用に新規作成されたネットワークの使用を開始します。新しい複数のネットワークが作成された場合、Microsoft Exchange レプリケーション サービスはそれらから 1 つをランダムに選択します。指定されたネットワークが使用できなくなった場合、Microsoft Exchange レプリケーション サービスは他のレプリケーション ネットワークの使用を自動的に開始します。また、使用できるネットワークがない場合は、5 分以内にログ配布用にパブリック ネットワークの使用を開始します (Microsoft Exchange レプリケーション サービスのネットワーク検出は 5 分ごとに行われます)。優先されるレプリケーション ネットワークが再び使用できるようになった場合、Microsoft Exchange レプリケーション サービスは自動的にログ配布にそのネットワークの使用に戻ります。

これらのコマンドレットの詳細については、「Enable-ContinuousReplicationHostName」および「Disable-ContinuousReplicationHostName」を参照してください。

冗長化されたクラスタ ネットワークでのシードのサポートは、Update-StorageGroupCopy コマンドレットを使用して構成します。このコマンドレットは Exchange 2007 SP1 で更新され、DataHostNames と呼ばれる新しいパラメータが追加されています。このパラメータは、シードにどのクラスタ ネットワークを使用するかを指定するために使用されます。Exchange 2007 SP1 での Update-StorageGroupCopy コマンドレットに対する変更の詳細については、「Update-StorageGroupCopy」を参照してください。

クラスタ ネットワークが連続レプリケーション用に作成された後、Get-ClusteredMailboxServerStatus コマンドレットを使用すると、連続レプリケーション処理で有効になったクラスタ ネットワークについて更新された情報を表示することができます。新しい出力の詳細には次のものがあります。

  • OperationalReplicationHostNames:{Host1,Host2,Host3}
  • FailedReplicationHostNames:{Host4}
  • InUseReplicationHostNames:{Host1,Host2}

Exchange 2007 SP1 での Get-ClusteredMailboxServerStatus コマンドレットに対する変更の詳細については、「Get-ClusteredMailboxServerStatus」を参照してください。

トランスポート収集

自動回復中に発生した消失データの大部分は、その後、トランスポート収集と呼ばれるハブ トランスポート サーバー機能によって自動的に回復されます。特定のデータベース用のトランスポート収集は、クラスタ化メールボックス サーバーを含む Active Directory サイトのハブ トランスポート サーバーに置かれている可能性があります。メッセージが CCR 環境のクラスタ化メールボックス サーバーに転送される途中でハブ トランスポート サーバーを経由すると、レプリケーション ウィンドウが経過するまで、トランスポート キュー (mail.que) にコピーが保存されます。トランスポート収集は、CCR 展開の必須コンポーネントです。トランスポート収集は、環境の冗長性を利用して、フェールオーバーの影響を受けたデータの一部を再利用します。具体的には、ハブ トランスポート サーバーは、最近配信されたメールのキューを維持しています。このキューは、メールの保存時間と合計の領域使用量によって制約されます。ロスレスでないフェールオーバーが発生すると、クラスタ化メールボックス サーバー上の CCR から Active Directory サイト内のすべてのハブ トランスポート サーバーに対し、トランスポート収集キューにあるメールの再送信が自動的に要求されます。インフォメーション ストアは自動的に複製を削除し、失われたメールを再度配信します。

トランスポート収集は、CCR で有効になっているほか、Exchange 2007 SP1 ではローカル連続レプリケーション (LCR) に対しても有効になっています。トランスポート収集は、SCR またはシングル コピー クラスタ (SCC) に対しては有効になっていません。CCR では、トランスポート収集で電子メール メッセージを維持するために必要な条件は、CCR 環境内のクラスタ化メールボックス サーバー上 (SP1 の場合は、LCR で有効になっているメールボックス データベースでもかまいません) にメールボックスがある受信者が 1 人以上存在することです。

トランスポート収集にはデータ消失に対する保護が設計されており、別のノード上のクラスタ化メールボックス サーバーを自動的にオンラインにし、データ消失の量を制限するように CCR を構成するオプションを管理者に提供しています。このオプションに従って処理が実行されると、システムは、これらの電子メール メッセージがまだ格納されているトランスポート収集を利用して、このサーバー上のユーザーに最近送信されたすべての電子メール メッセージを自動的に配信します。これは、ほとんどの状況でデータ消失の防止に役立ちます。CCR 環境では、サイト内にあるすべてのハブ トランスポート サーバー上でトランスポート収集からの再配信要求は自動的に実行されます。Exchange 2007 RTM では、再試行間隔は 7 日に固定されています。Exchange 2007 SP1 では、再試行間隔は MaxDumpsterTime に設定されている値と等しくなります。LCR 環境では、サイト内にあるすべてのハブ トランスポート サーバーからの再配信要求は、Restore-StorageGroupCopy タスクの一部として発生します。

トランスポート収集によってデータ消失が軽減されない状況として、以下の状況があります。

  • オンライン モードでの Microsoft Outlook クライアントの [下書き] フォルダ。
  • 予定、連絡先の更新、プロパティの更新、タスク、およびタスクの更新。
  • クライアントからハブ トランスポート サーバーに送信中の送信メール。電子メール メッセージが送信者のメールボックス サーバーのみに存在する期間があります。

クラスタ連続レプリケーションの展開

CCR の展開は、スタンドアロンの Exchange サーバーの展開に類似しており、SCC の展開に類似しています。SCC の詳細については、「シングル コピー クラスタ」を参照してください。ただし、CCR を展開する場合に留意しておく必要がある重要な違いがいくつかあります。CCR を設計して環境に展開する前に、以下のトピックを確認することをお勧めします。

CCR を展開する準備ができたら、次のいずれかのトピックで説明しているインストールの各段階の手順を実行して、展開処理を開始できます。

Exchange 2007 SP1 の CCR で強化された機能

Exchange 2007 SP1 には、CCR に対するいくつかの拡張機能が装備されています。これらには、追加された Exchange 管理コンソールのユーザー インターフェイスの要素、状態および監視の強化、およびパフォーマンスの強化が含まれます。

Exchange 管理コンソールの拡張機能

Exchange 2007 SP1 には、CCR を含め、高可用性機能用に管理の操作性を強化するいくつかの新しいユーザー インターフェイスの要素が追加されています。これらの改善点には次のものがあります。

  • トランスポート収集のユーザー インターフェイス**   [組織の構成]** 作業領域では、[ハブ トランスポート] ノードに新しい [グローバル設定] タブが追加されています。このタブには、組織のトランスポート収集の設定の構成に使用できる [トランスポート設定のプロパティ] ページが含まれます。
    • [ストレージ グループあたりの最大サイズ (MB)]   各ストレージ グループのトランスポート収集キューの最大サイズを指定します。
    • [最大保存期間 (日)]   トランスポート収集キューに電子メール メッセージを保持する期間を指定します。
  • [連続レプリケーション]   管理者が連続レプリケーションを中断、再開、更新、および復元できるようにする、追加のユーザー インターフェイス コントロールが Exchange 管理コンソールに追加されています。これらのコントロールは、次の Exchange 管理者シェル コマンドレットを使用することと同じです。
    • Suspend-StorageGroupCopy
    • Resume-StorageGroupCopy
    • Update-StorageGroupCopy
    • Restore-StoreGroupCopy
      これらのコマンドレットと、対応する Exchange 管理コンソールのタスクを使用すると、LCR 環境と CCR 環境の両方で連続レプリケーションを管理できます。

状態および監視の拡張機能

Exchange 2007 SP1 には、Exchange 2007 の管理性を強化するために設計されたいくつかの変更点も導入されています。これらの変更点は、Exchange 2007 RTM のクラスタ報告機能を改良し、また連続レプリケーション環境の予防的な監視用に設計された追加機能を含みます。具体的には、変更点と拡張機能は、Get-StorageGroupCopyStatus コマンドレットで判明していた弱点を修正し、Test-ReplicationHealth と呼ばれる新しいコマンドレットを導入し、トランスポート収集の対象である損失時間への可視性を改善しています。

Get-StorageGroupCopyStatus コマンドレットの強化

Exchange 2007 RTM では、Get-StorageGroupCopyStatus により報告される状態と連続レプリケーションのパフォーマンス カウンタが正確ではない、または誤ったものとなる、次のようないくつかの状態が存在します。

  • アクティブでない (たとえば、変更されていない) ストレージ グループが正常な状態ではない可能性があるときに、このストレージ グループの状態が Healthy と報告されることがあります。この状況は、ログが再生されるまで、正常ではない状態が検出されなかったために発生する場合があります。
  • レプリケーションの初期化中は、レプリケーションの状態が再評価されているために正確でないことがあります。初期化が完了すると、状態は更新されます。
  • ストレージ グループのデータベースのマウントが解除されている場合は、LastLogGenerated フィールドの値が間違っている可能性があります。
  • ログ ストリームの途中に足りないログが 1 つ以上ある場合、パッシブ コピーは引き続き回復を試み、これによりレプリケーションの状態が Failed と Healthy の間で切り替わります。これが発生すると、再生とコピーのキューは拡大し続けます。
  • まれに、ログの検証が正常に行われても、再生に失敗することがあります。この場合、システムは回復を試みるときに、状態を Failed と Healthy の間で切り替えます。これが発生すると、再生とコピーのキューは拡大し続けます。

Get-StorageGroupCopyStatus コマンドレットも、次のように、CCR 環境の新しい状態情報の追加によって強化されています。

  • Get-StorageGroupCopyStatus コマンドレットは、ターゲット コンピュータ上の Microsoft Exchange レプリケーション サービスがネットワーク経由でアクセスできない場合、ServiceDown という SummaryCopyStatus を報告します。
  • Get-StorageGroupCopyStatus コマンドレットは、ターゲット コンピュータ上の Microsoft Exchange レプリケーション サービスが起動時の初期確認を完了していない場合、Initializing という SummaryCopyStatus を報告します。また、この状態をブール値として表現するために、新しいパフォーマンス カウンタも作成されています。
  • 増分再シードを完了していない場合、Get-StorageGroupCopyStatus コマンドレットは Synchronizing という状態の SummaryCopyStatus 値を報告します。

SummaryCopyStatus の値の新しい状態が表示されるのは、Exchange 2007 SP1 バージョンの Exchange 管理ツールを使用する場合のみです。Exchange 2007 RTM 版の Exchange 管理ツールを使用する場合、上記のすべての状態は Failed として報告されます。

Test-ReplicationHealth コマンドレット

Exchange 2007 SP1 には、Test-ReplicationHealth と呼ばれる新しいコマンドレットが導入されています。このコマンドレットは、連続レプリケーションおよび連続レプリケーション パイプラインの予防的監視用に設計されています。Test-ReplicationHealth コマンドレットは、レプリケーション、クラスタ サービス、およびストレージ グループ レプリケーションのすべての側面をチェックし、状態を再生して、レプリケーション システムの詳細な概要を提供します。具体的には、クラスタ内のノード上で実行された場合、Test-ReplicationHealth コマンドレットは次の表で説明されるテストを実行します。

Test-ReplicationHealth コマンドレットにより実行されるテスト

テスト 説明

クラスタ ネットワークの状態

ローカル ノード上で検出された、クラスタにより管理されるすべてのネットワークが実行中であることを確認します。このテストは CCR 環境でのみ実行されます。

クォーラム グループの状態

クォーラム リソースを含むクラスタ グループが Healthy であることを確認します。このテストは CCR 環境でのみ実行されます。

ファイル共有クォーラムの状態

ファイル共有監視付きのマジョリティ ノード セット クォーラムにより使用されている FileSharePath の値が到達可能であることを確認します。このテストは CCR 環境でのみ実行されます。

クラスタ化メールボックス サーバー グループの状態

グループのすべてのリソースがオンラインであることを確認することにより、クラスタ化メールボックス サーバーが Healthy であることを確認します。このテストは CCR 環境でのみ実行されます。

ノードの状態

クラスタ内のノードで一時停止状態のものがないことを確認します。このテストは CCR 環境でのみ実行されます。

DNS 登録の状態

[続行する場合は DNS 登録を要求する] が設定されている、クラスタにより管理されるすべてのネットワーク インターフェイスが DNS 登録をパスしていることを確認します。このテストは CCR 環境でのみ実行されます。

レプリケーション サービスの状態

ローカル コンピュータ上の Microsoft Exchange レプリケーション サービスが Healthy であることを確認します。

ストレージ グループのコピーの中断

連続レプリケーションに対して有効になっているすべてのストレージ グループに対して連続レプリケーションが中断されているかどうかをチェックします。

ストレージ グループのコピーの失敗

すべてのストレージ グループのコピーが Failed 状態であるかどうかをチェックします。

ストレージ グループのレプリケーション キューの長さ

ストレージ グループが、ベスト プラクティスのしきい値よりも長いレプリケーション コピー キューの長さを持っているかどうかをチェックします。現在、これらのしきい値は以下のとおりです。

  • 警告   キューの長さは 3 ～ 5 ログです。
  • 失敗   キューの長さは 6 ログ以上です。

フェールオーバー後にマウントが解除されたデータベース

フェールオーバーの発生後、データベースがマウント解除されたか、障害が発生したかどうかをチェックします。このテストは、フェールオーバーの結果として障害が発生したデータベースのみをチェックします。

パフォーマンスの強化

Exchange 2007 SP1 では、高可用性展開の利益になる、パフォーマンスの改善が行われています。これらの改善点には次のものがあります。

  • 連続レプリケーション環境にストレージ グループのパッシブ コピーを含むディスクの I/O 削減   Exchange 2007 SP1 では、データベースのキャッシュがログ再生処理のバッチ間にあるパッシブ ノードで保持されるように連続レプリケーション アーキテクチャの設計が修正されました。ログ再生処理のバッチ間でデータベース キャッシュが保持されることにより、Microsoft Exchange レプリケーション サービスは ESE のデータベース キャッシュ機能を活用できるようになるため、パッシブ コピーの論理ユニット番号 (LUN) 上で発生するディスク I/O の量が削減されます。これに対して、Exchange 2007 RTM では、ログ再生処理の各バッチに対して新しいデータベース キャッシュが作成されていたため、場合によってはパッシブ ノード上のディスク I/O 処理が、アクティブ ノード上のディスク I/O の 2 ～ 3 倍にまでなっていました。
  • CCR 環境のノード間におけるクラスタ化メールボックス サーバーの迅速な移動   これらの改善によって、クラスタ化メールボックス サーバーは 2 分以下でノード間を移動できます。これには、(Move-ClusteredMailboxServer コマンドレットを使用した) 管理者により実行される移動と、クラスタ サービスにより管理されるフェールオーバーが含まれます。CCR 環境で高速な移動を実現するために、データベース キャッシュをフラッシュすることなく、データベースがオフラインになります。この動作により、クラスタ化メールボックス サーバーが別のノードに移動する場合に発生するダウンタイムの時間が短縮されます。

スタンバイ連続レプリケーションと CCR の併用

SCR は、Exchange 2007 SP1 で導入された新機能です。SCR は既存の連続レプリケーション機能を拡張し、Exchange 2007 メールボックス サーバーに対して、新しいデータ可用性シナリオを有効化します。SCR は、LCR および CCR で使用されるのと同じログ配布および再生テクノロジを使用して、追加の展開オプションと構成を提供します。

SCR では、連続レプリケーションを使用して、(LCR の有無に関係なく) スタンドアロン メールボックス サーバーから、または SCC あるいは CCR 環境のクラスタ化メールボックス サーバーから、メールボックス サーバー データをレプリケートすることができます。

SCR により作成および維持されるメールボックス サーバー データのコピーをアクティブ化する処理は、手動で行われ、重大な障害が発生した場合に使用されるように設計されています (再起動やその他の簡単な手段により回復できる単純なサーバーの停止用ではありません)。データベースの移植性、サーバー回復のオプション (Setup /m:RecoverServer)、またはメールボックス サーバーがクラスタ化されている場合はクラスタ化メールボックス サーバーの回復オプション (Setup /RecoverCMS) を使用すると、SCR ターゲットをアクティブ化することができます。ユーザーが選択するオプションは、使用する構成、および発生する障害の種類に基づきます。

SCR の詳細については、「スタンバイ連続レプリケーション」を参照してください。

詳細情報

以下のトピックでは、高可用性とサイトの復元計画の一部として CCR を使用する状況および方法について説明します。

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