次の方法で共有


スタンバイ連続レプリケーション

 

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

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

スタンバイ連続レプリケーション (SCR) は、Microsoft Exchange Server 2007 Service Pack 1 (SP1) で導入された新機能です。名前が示すとおり、SCR は、待機している (スタンバイ) 回復用サーバーを使用する、またはその使用を可能にするシナリオのために設計されています。SCR は、Exchange Server 2007 の RTM (Release To Manufacturing) 版が持つ既存の連続レプリケーション機能を拡張するものであり、SP1 を実行するメールボックス サーバーのデータ可用性に関する新たなシナリオを実現します。ローカル連続レプリケーション (LCR) およびクラスタ連続レプリケーション (CCR) で使用されているものと同じログ配布および再生のテクノロジが SCR でも使用され、展開のオプションと構成の幅が広がります。

SCR によって、高可用性 (サービス可用性とデータ可用性で構成される) とサイト復元との分離が可能になります。たとえば、SCR を CCR と組み合わせることで、ストレージ グループをプライマリ データセンターにはローカルにレプリケートし (CCR による高可用性の実現)、セカンダリ データセンターまたはバックアップ データセンターにはリモートでレプリケートします (SCR によるサイト復元の実現)。セカンダリ データセンターでは、SCR ターゲットをホストするパッシブ ノードをフェールオーバー クラスタ内に持ちます。この種のクラスタがスタンバイ クラスタと呼ばれるのは、クラスタ化メールボックス サーバーをメンバとして持たないからですが、回復シナリオにおいて代替クラスタ化メールボックス サーバーを持つクラスタとして迅速に準備することができます。障害発生などが原因でプライマリ データセンターが使用不可能になった場合は、このスタンバイ クラスタでホストされている SCR ターゲットをスタンバイ クラスタ上ですばやくアクティブ化できます。

ソースとターゲット

LCR や CCR と同様に、SCR でもストレージ グループのアクティブ コピーとパッシブ コピーという概念が使用されますが、SCR ではこれらをソースおよびターゲットという名前で呼びます。また、CCR と同様に SCR でも、データベースおよびログ ファイルのパスが、ソースとターゲットとで同一であることが必要です。

SCR の起点をソースと呼びます。これは、次のいずれかに存在する任意のストレージ グループです。

  • スタンドアロン メールボックス サーバー
  • シングル コピー クラスタ (SCC) 内のクラスタ化メールボックス サーバー
  • CCR 環境内のクラスタ化メールボックス サーバー
    note注 :
    回復用ストレージ グループに対して SCR を有効にすることはできません。

LCR および CCR と同様に、SCR が有効になっているストレージ グループが複数のデータベースを持っていてはなりません。複数のデータベースを持つストレージ グループに対して SCR を有効にすることはできません。また、SCR が有効になっているストレージ グループに 2 番目以降のデータベースを追加することはできません。

SCR のソース コンピュータがクラスタ化されていない場合は、ハブ トランスポート、クライアント アクセス、ユニファイド メッセージング サーバーの役割など、他のサーバーの役割をホストすることもできます。

SCR の終点をターゲットと呼びます。ターゲットとなることができるのは、次のいずれかです。

  • どのストレージ グループに対しても LCR が有効化されていないスタンドアロン メールボックス サーバー
  • パッシブ クラスタ化メールボックスの役割はインストールされているが、クラスタ化メールボックス サーバー (たとえばアクティブ クラスタ化メールボックスの役割) はクラスタにインストールされていないフェールオーバー クラスタである、スタンバイ クラスタ

SCR のターゲット コンピュータは、運用中メールボックスをホストしていなくても、メールボックス サーバーの役割がインストールされていることが必要です。メールボックス サーバーの役割が必要とされるのは、SCR の機能に必要な Microsoft Exchange Replication Service などのコンポーネントがこの役割に含まれているからです。SCR のターゲット コンピュータがクラスタ化されていない場合は、ハブ トランスポート、クライアント アクセス、ユニファイド メッセージング サーバーの役割など、他のサーバーの役割をホストすることもできます。

SCR は、Exchange 2007 SP1 の Standard Edition で利用できます。SCC 環境または CCR 環境のメールボックス サーバーを SCR のソースとして使用する場合は、Exchange 2007 SP1 の Enterprise Edition が必要です。Exchange 2007 をクラスタ化するときは Enterprise Edition が必要になるからです。スタンバイ クラスタを SCR ターゲットとして使用する場合も、Exchange 2007 SP1 の Enterprise Edition が必要です。

SCR と LCR および CCR との比較

SCR は LCR および CCR に似ていますが、以下の特性は SCR に固有のものです。

  • SCR では、1 つのストレージ グループに対して複数のレプリケーション ターゲットがサポートされます。LCR および CCR では、レプリケーション ターゲットはストレージ グループ 1 つにつき 1 つだけです (パッシブ コピー)。
  • SCR には再生処理の遅延が組み込まれており、さらに管理者が遅延を指定することができます。これはさまざまなシナリオで役に立ちます。たとえば、アクティブなデータベースに論理的な破損が生じても、組み込みの遅延および管理者が指定した追加の遅延を使用することで、SCR ターゲット データベースの論理的な破損を防ぎます。LCR と CCR には、このような遅延はありません。
  • SCR の機能は、すべて Exchange 管理シェルを使用して管理します。Exchange 管理コンソールでは、LCR および CCR をさまざまな面から管理できますが、SCR の有効化や管理を行うことはできません。

SCR コピーのアクティブ化

SCR のターゲット データベースを使用するプロセスをアクティブ化と呼びます。データベースをアクティブ化する方法は、障害の性質によって異なります。SCR ソースの 1 つまたは複数のデータベースが影響を受ける場合は、SCR のターゲット データベースのアクティブ化プロセスの一部として、Exchange 2007 のデータベースの移植性機能を使用することができます。SCR ソース サーバーのすべてのデータベースが影響を受ける場合、またはサーバー全体あるいはクラスタ化メールボックス サーバー全体を回復する場合は、アクティブ化プロセスの一部として、セットアップのサーバー回復機能 (スタンドアロン サーバーの場合は Setup /m:RecoverServer、クラスタ化メールボックス サーバーの場合は Setup /RecoverCMS) を使用することができます。

note注 :
回復計画に基づいて、Setup /RecoverCMS を使用して、SCR が有効な 1 つ以上のストレージ グループがあるクラスタ化メールボックス サーバー (CCR または SCC) を回復する場合は、Setup /RecoverCMS を実行する前に、ストレージ グループの SCR を無効にする必要があります。

SCR 環境でのアクティブ化と回復の詳細については、「スタンバイ連続レプリケーション対象のアクティブ化」を参照してください。

SCR の展開シナリオ

SCR を利用すると、スタンドアロン メールボックス サーバーから、あるいは SCC または CCR 環境内のクラスタ化メールボックス サーバーから、連続レプリケーションを使用してメールボックス サーバーのデータをレプリケートすることができます。以下の図に、SCR 構成オプションの例を示します。

あるスタンドアロン サーバーから別のサーバーへの SCR

これは、SCR を使用して 1 つのメールボックス サーバーから別のメールボックス サーバーに複数のストレージ グループをレプリケートするシナリオの図です。この例では、メールボックス サーバーはクラスタ化されず、どちらも SCR のソースおよびターゲットとして動作します。この例では、サーバーはそれぞれ別のデータセンターおよび別の Active Directory サイトに配置されています。障害の性質に応じて、いずれかのサーバーにおけるストレージ グループの回復が、データベースの移植性機能または /RecoverServer セットアップ オプションを使用して実行されます。

リモート SCR を使用するローカル CCR

これは、1 対 1 の CCR-to-SCR モデルの図です。この例で、EXCLUS1 は、Active Directory サイト REDMOND に存在する CCR 環境内のクラスタ化メールボックス サーバーです。EXCLUS1DR は、Active Directory サイト QUINCY 内に存在するスタンバイ クラスタです。この例では、SCR ターゲット上のすべてのストレージ グループを回復するには Setup の /RecoverCMS スイッチを使用します。一部のストレージ グループのみの回復が必要な場合は、データベースの移植性機能を使用して 1 つまたは複数のストレージ グループを回復します。

ローカルおよび複数の SCR ターゲットに対する CCR のレプリケート

これは、1 対多の CCR-to-SCR モデルの図です。左側のコンピュータは、同じデータセンター内にある 2 つの物理 CCR ノードを表しています。右側のコンピュータは、第 2 のデータセンター内にある 2 つの SCR ターゲットを表しています。この例では、1 つのストレージ グループが、2 つの異なるコンピュータ上の複数の SCR ターゲットにレプリケートされています。いずれかの SCR ターゲット上のストレージ グループを回復する方法には、次の 2 つがあります。

  • /RecoverCMS は、単一の CCR ソースのみからストレージ グループを回復する場合に使用します。
  • データベースの移植性機能は、複数の CCR ソースからストレージ グループを回復する場合に使用します。

リモート SCR ターゲットによる SCC

これは、1 対多の SCC-to-SCR モデルの図です。左側のコンピュータは、1 つのデータセンター内にある 2 つの物理 SCC ノードを表しています。右側のコンピュータは、別のデータセンター内にある SCR ターゲットを表しています。この例では、1 つのストレージ グループが、第 2 のデータセンター内にある 2 つのスタンドアロン ターゲットにレプリケートされています。この SCR ターゲット上のストレージ グループを回復するには、Setup の /RecoverCMS スイッチを使用します。

SCR に関するコマンドレットの更新

SCR の管理には、Exchange 管理シェルを使用します。SP1 では、連続レプリケーションの管理および構成に使用する Exchange 管理シェル コマンドレットのいくつかに、新しいパラメータ StandbyMachine が追加されています。具体的には、以下のコマンドレットに SCR のサポートと StandbyMachine パラメータが追加されています。

  • Suspend-StorageGroupCopy
  • Resume-StorageGroupCopy
  • Update-StorageGroupCopy
  • Restore-StorageGroupCopy
  • Get-StorageGroup
  • Get-StorageGroupCopyStatus

これらのコマンドレットの更新に加えて、New-StorageGroup コマンドレットと Enable-StorageGroupCopy コマンドレットが、SCR をサポートするように更新されています。Exchange 2007 SP1 では、SCR が有効な新しいストレージ グループを New-StorageGroup を使用して作成できます。また、Enable-StorageGroupCopy を使用して、既存のストレージ グループに対する SCR の有効化を実行できます。これらのコマンドレットでは、以下のパラメータが更新されています。

  • -StandbyMachine   SCR ターゲット コンピュータの名前を指定します。
  • -ReplayLagTime   SCR ターゲット コンピュータにコピーされたログ ファイルを再生する前に Microsoft Exchange レプリケーション サービスが待つ時間の長さを指定します。このパラメータの形式は、(日数.時間:分:秒) です。この値の既定の設定は 24 時間 (1.0:0:0) です。この値に設定できる最大値は 7 日です。設定可能な最小値は 0 秒ですが、この値を 0 秒に設定すると、ログ再生処理における遅延は実質的に、既定の遅延である 50 ログ ファイルだけとなります。このパラメータの値を設定した後で変更するには、SCR を無効にしてから有効にする必要があります。
  • -TruncationLagTime   SCR ターゲット コンピュータにコピーされて再生されデータベースのコピーに反映されたログ ファイルを切り詰める前に Microsoft Exchange レプリケーション サービスが待つ時間の長さを指定します。この時間のカウントは、ログが再生されてデータベースのコピーに正常に反映されたときから開始します。このパラメータの形式は、(日数.時間:分:秒) です。この値に設定できる最大値は 7 日です。設定可能な最小値は 0 秒ですが、この値を 0 秒に設定すると、実質的にログ切り詰め処理における遅延はなくなります。このパラメータの値を設定した後で変更するには、SCR を無効にしてから有効にする必要があります。

ReplayLagTime パラメータを使用して管理者が設定する再生遅延に加えて、Exchange には、一定数のログ ファイルを SCR ターゲット上で再生させないでおく機能があります。これは ReplayLagTime の値に関係なく行われ、「ReplayLagTime の値とログ ファイル X 個のいずれか大きい方 (X=50)」という基準が使用されます。これは、連続レプリケーション環境 (たとえば LCR または CCR) で SCR ソースに対して損失を伴うフェールオーバーが発生し、Restore-StorageGroupCopy コマンドレットを使用して SCR ソースをオンラインにした場合にストレージ グループの再シードが必要になることに対する追加の予防手段です。SCR ターゲットでの再生処理を遅延させることで、SCR ソースに対する損失を伴うフェールオーバーの発生時に SCR コピーの再シードが必要となる可能性を最小限に抑えることができます。SCR ソースでのデータ損失の性質上、2 つのコピーの時間差が短くなるためです。

important重要 :
ログ ファイル 50 個という組み込みの再生遅延と、既定の 24 時間という設定は、SCR ターゲット データベースの新規作成に影響を及ぼします。SCR ターゲット データベースが作成されるのは、50 個のトランザクション ログ ファイルが SCR ターゲット コンピュータにレプリケートされ、かつ ReplayLagTime で指定された時間 (既定値は 24 時間) が経過した後となります。

SCR に関する Setup の更新

SCR は、主として、サイトがまったく機能しなくなった場合などの重大な障害に備えて設計されています。この種の障害シナリオには、バックアップ データセンターのアクティブ化やプライマリ データセンターへの復帰などの、手作業による処理も含まれます。

ここでは、前に示した図「1 つの SCC に対する複数のリモート SCR ターゲットの使用」を例として使用し、プライマリ データセンター (SCC が存在するサイト) で障害が発生したために第 2 のデータセンターを代替プライマリ サイトとしてアクティブ化する場合に、どのようなことが行われるのかを説明します。第 2 のデータセンターをアクティブ化したときに、元のデータセンターの構成は Active Directory 内に残っており、この構成が、アクティブ化された第 2 のデータセンターによって使用されます。SCC のクラスタ化メールボックス サーバーの構成も、元のクラスタに残っています。元のクラスタを再びオンラインにするには、Active Directory のクラスタ化メールボックス サーバーの構成 (第 2 のデータセンターによって使用されている) に影響を与えずにクラスタ化メールボックス サーバーの構成をクラスタ ノードから削除する必要があります。

このようなサイト復元シナリオの実現を容易にするために、Exchange 2007 SP1 では Setup が変更されています。具体的には、Setup に新しいコマンド ライン オプション /ClearLocalCMS が追加されています。このオプションを使用すると、Active Directory に格納されている構成情報に影響を与えることなく、元のクラスタ ノードからクラスタ化メールボックス サーバーの構成情報を消去することができます。たとえば、EXCLUS1 という名前のクラスタ化メールボックス サーバーのローカル構成データを消去するには、クラスタ化メールボックス サーバーを削除する元のクラスタの各ノードで、次のコマンドをローカルに実行します。

Setup /ClearLocalCMS

/ClearLocalCMS オプションを使用するときは、以下の要件と制限に留意してください。

  • このオプションは、ローカルでの使用のみが可能です。リモートでは使用できません。
  • このオプションは、クラスタ化メールボックス サーバーをホストするノード (アクティブ ノードなど) 上でのみ使用されますが、パッシブ ノード上では使用されません。
  • このオプションを指定しても、Microsoft Exchange のプログラム ファイルが削除されることはありません。また、Active Directory 内の構成情報が更新されることはありません。
  • このオプションは、ローカルのクラスタ化メールボックス サーバーがオフラインになっていて、ローカルのクラスタ化メールボックス サーバーに対する RedundantMachines リストにローカル ノードが含まれていない場合にのみ使用できます。
  • ローカルのクラスタ化メールボックス サーバーの構成を消去するときに使用するアカウントには、クラスタ化メールボックス サーバーに対する Exchange Server Administrator のアクセス許可が委任されている必要があります。
  • クラスタ ノードが Windows Server 2008 上で実行されている場合は、Setup /ClearLocalCMS を実行した後、仮想コンピュータ オブジェクト (VCO) は無効になります。VCO を再度有効にする必要があります。

詳細情報

SCR の計画の詳細については、「スタンバイ連続レプリケーションの計画」を参照してください。ストレージ グループに対して SCR を有効または無効にする詳細な手順など、SCR の管理に関する詳細については、「スタンバイ連続レプリケーションの管理」を参照してください。

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