スタンバイ連続レプリケーション : スタンバイ クラスタ化によるサイトの復元

  • [アーティクル]

 

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

トピックの最終更新日: 2008-11-18

ここでは、Contoso, Ltd. という組織におけるサイトの復元シナリオでのスタンバイ連続レプリケーション (SCR) の使用方法について詳しく説明します。このシナリオでは、プライマリ データセンターに障害が発生したため、Contoso, Ltd. ではセカンダリ データセンターをアクティブにすることにします。セカンダリ データセンターがアクティブになったら、プライマリ データセンターを再構成して、最終的には手動で切り替えてプライマリ データセンターとして復元します。Contoso, Ltd. には 2 つのデータセンターがあります。1 つは Active Directory SITEA と呼ばれるプライマリ データセンターで、もう 1 つは Active Directory SITEB と呼ばれるバックアップ データセンターです。SITEA はオレゴン州ポートランドにあり、SITEB はカリフォルニア州サンノゼにあります。

SITEA には、以下のインフラストラクチャ コンポーネントがあります。

  • ディレクトリ サーバー DC1 (セキュリティで保護された Active Directory 統合ドメイン ネーム システム (DNS) サービスも提供する)
  • クライアント アクセス サーバー CAS1
  • ハブ トランスポート サーバー HUB1
  • クラスタ化メールボックス サーバー EXCMS1 (NODEA と NODEB を含む 2 ノードのシングル コピー クラスタ (SCC) EXCLUS1 で実行されている)。次の点に注意してください。

    • フェールオーバー クラスタ内のノードは、Windows Server 2008 オペレーティング システムで実行され、フェールオーバー クラスタはノードおよびディスク マジョリティのクォーラムで構成されています。

    • クラスタ化メールボックス サーバーのネットワーク名リソースの DNS Time to Live (TTL) 値は、5 分間に構成されています。これは、以下のコマンドを実行してから、クラスタ化メールボックス サーバーを停止後に起動して構成されました。

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300
      note注 :
      HostRecordTTL プロパティは、Windows Server 2008 を実行しているフェールオーバー クラスタでのみ使用できます。このコマンドは、Windows Server 2003 オペレーティング システム上で実行されているフェールオーバー クラスタでは使用できません。

SITEB には、以下のインフラストラクチャ コンポーネントがあります。

  • ディレクトリ サーバー DC2 (セキュリティで保護された Active Directory 統合 DNS サービスも提供する)
  • クライアント アクセス サーバー CAS2
  • ハブ トランスポート サーバー HUB2
  • 単一ノード クラスタ DRCLUS1 (スタンバイ フェールオーバー クラスタとして使用される)。次の点に注意してください。

    • このクラスタ内のノード NODEC は、スタンバイ フェールオーバー クラスタのただ 1 つのノードで、Windows Server 2008 を実行しています。スタンバイ フェールオーバー クラスタは、ノード マジョリティ クォーラムで構成されています。

      note注 :
      Windows Server 2003 を実行しているフェールオーバー クラスタでは、単一ノードのスタンバイ フェールオーバー クラスタは、ローカル クォーラムで構成されています。

    • パッシブなメールボックス サーバーの役割は、EXCLUS1 と同じインストール パスを使用して NODEC 上にインストールされます。これは、SCR ターゲットのアクティブ化プロセスの一環として、Setup /RecoverCMS を使用してサーバー回復を実行できる必要があります。サーバー回復プロセスを使用するには、Exchange Server のインストール パスが、SCR ソース コンピュータと SCR ターゲット コンピュータとで同一であることが必要です。SCR ソース コンピュータで Exchange Server が %ProgramFiles%\Microsoft\Exchange Server にインストールされている場合は、この SCR ソース サーバーの SCR ターゲットとなるすべてのコンピュータでも %ProgramFiles%\Microsoft\Exchange Server にインストールされている必要があります。これらのインストール パスが一致しない場合、サーバー回復プロセスは失敗します。レジストリ内のインストール パスが、Active Directory 内のメールボックス サーバー オブジェクトの msExchInstallPath 属性値と一致しないためです。

    • DRCLUS1 のコンピュータ アカウントは、Active Directory ユーザーとコンピュータ スナップインを使用して、EXCMS1 コンピュータ オブジェクトに対する完全なアクセス許可で構成されています。これは、SITEA の障害により SITEB をアクティブ化した場合に、EXCMS1 のコンピュータ アカウントを DRCLUS1 でリセットできるようにするためです。

      note注 :
      この手順は、Windows Server 2008 を実行しているフェールオーバー クラスタでのみ使用されます。これは、クラスタ サービスがローカル システムのセキュリティ コンテキストで実行されるためです。両方のフェールオーバー クラスタに同じクラスタ サービス アカウントを使用している場合、Windows Server 2003 を実行しているフェールオーバー クラスタでは、この手順は不要です。

両方の Active Directory サイト内のすべてのサーバーは、Active Directory 統合 DNS サーバーを使用するように構成されています。両方の Active Directory サイトの Active Directory レプリケーション間隔は、15 分間に構成されています。

SCR は、トランザクション ログ ファイルが EXCMS1 上の 3 つのストレージ グループから NODEC 上の SCR ターゲットにレプリケートされるように構成されています。これは以下のコマンドを使用して構成されました。

Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC
note注 :
SCR 用に EXCMS1 上のすべてのストレージ グループを同時に有効にするには、以下のコマンドを実行します。 Get-StorageGroup -Server EXCMS1 | Enable-StorageGroupCopy -StandbyMachine NODEC

各ストレージ グループに対する SCR の稼働状態は、Exchange 管理シェルの Test-ReplicationHealth および Get-StorageGroupCopyStatus のコマンドレットを使用して確認されました。以下に例を示します。

Get-StorageGroupCopyStatus EXCMS1\SG1 -StandbyMachine NODEC

クラスタ化メールボックス サーバーの移動は、バックアップやログの切り詰めと同様、期待どおりに機能していることが確認されています。

プライマリ サイトの障害とバックアップ サイトのアクティブ化

ここで、突然、何の前触れもなくポートランドで大きな地震が発生したとします。重傷者はいませんが、SITEA にかなりの損害が発生し、電力、水、天然ガスなどの重要な公共サービスが切断される状態になっています。Contoso, Ltd. で SITEA を使用できるようになるまでに数か月かかるため、SITEB を手動でアクティブ化し、このサイトからすべてのメッセージング データとサービスを提供することになりました。

SITEB のアクティブ化は、ディレクトリ サービスと DNS 解決の検証から始まります。SITEB には Active Directory 統合 DNS もホストしているディレクトリ サーバーがあるため、これらのサービスは正常で、最新状態になっており、SITEA の停止であまり影響を受けていません。ディレクトリ サービスと DNS の検証後、次の手順として、SCR ターゲットのアクティブ化とクラスタ化メールボックス サーバーの回復を開始します。これには、以下の手順を順に実行します。

  1. NODEC 上で Exchange 管理シェルを開き、以下のコマンドを実行して SCR ターゲットのマウントの準備をします。

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Force
    important重要 :
    SCR ソースが使用できない場合、Force パラメータを常に指定する必要があります。
    note注 :
    手順 1. に示すような 3 つの別個の Restore-StorageGroupCopy コマンドを実行する代わりに、Microsoft Exchange Server 2007 Service Pack 1 (SP1) に付属の GetSCRSources.ps1 という名前の新しいスクリプトを使用して、次のようにスクリプトの出力を 1 つの Restore-StorageGroupCopy タスクにパイプライン処理できます。 GetSCRSources | Restore-StorageGroupCopy -StandbyMachine $env:ComputerName -Force

  2. DNS 管理スナップインを使用して、EXCMS1 の既存の DNS レコードを DNS から削除します。

    note注 :
    この手順は、Windows Server 2008 を実行しているフェールオーバー クラスタでのみ使用されます。これは、クラスタ サービスがローカル システムのセキュリティ コンテキストで実行されるためです。両方のフェールオーバー クラスタに同じクラスタ サービス アカウントを使用している場合、Windows Server 2003 を実行しているフェールオーバー クラスタでは、この手順は不要です。

  3. SCR は、/RecoverCMS プロセスに備えてすべてのストレージ グループに対して無効になっています。SCR がすべてのストレージ グループに対して無効になっていない場合、Setup /RecoverCMS は失敗します。SCR を無効するには、次のコマンドを使用します。

    Disable-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Confirm:$False

  4. Setup の /RecoverCMS オプションを使用して、クラスタ化メールボックス サーバー (EXCMS1) を回復します。NODEC 上で以下のコマンドを使用して回復を実行します。

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    次の点に注意してください。

    • 上記のコマンドの CMSIPAddress の値は、通常 EXCMS1 の元の IP アドレスとは異なる IP アドレスになります。EXCMS1 がサイト外で回復されるためです。つまり、当初 SITEA でホストされていたもので、これが SITEB に回復されます。

    • Setup /RecoverCMS は、DNS レプリケーションの実行後に正常に終了し、回復サーバー (NODEC) の DNS キャッシュがフラッシュされます。Setup が失敗した場合、プライマリ ドメイン コントローラ (PDC) と NODEC の両方の NSLookup を使用して、正しい IP アドレスが NODEC に解決されることを確認してから、Setup を再実行します。

    • Windows Server 2003 を実行しているフェールオーバー クラスタ上で、EXCMS1 のコンピュータ オブジェクトを Setup /RecoverCMS プロセス中にリセットします。このリセットは、Setup を正常終了するために、ローカル Active Directory サイトにレプリケートする必要があります。PDC がローカル Active Directory サイトにない場合は、PDC とローカル Active Directory サイト間に機能している Active Directory サイト リンクがあることを確認します。

    • Setup 回復プロセスが完了したら、EXCMS1 が SITEB に回復され、DRCLUS1 と呼ばれる単一ノードの SCC 内の NODEC 上でホストされるようになります。

    • クラスタ化メールボックス サーバーの回復操作の結果として、EXCMS1 の DNS TTL はデフォルト値の 20 分に戻されます。この値は、以下のコマンドを実行してから、クラスタ化メールボックス サーバーを停止後に起動して、5 分に設定し直す必要があります。

      Cluster.exe res EXCMS1 /priv HostRecordTTL=300

  5. 次に、Mount-Database タスクを使用して、3 つのストレージ グループ内のデータベースをマウントします。

  6. このシナリオでは、他のサーバーの役割 (具体的には、クライアント アクセスとハブ トランスポート) の回復操作を実行する必要はありません。CAS2 と HUB2 が既に SITEB に存在しているためです。

    note注 :
    クライアント アクセス サーバーの回復操作の一環として、外部 URL を SITEB 内のクライアント アクセス サーバーをポイントするように再構成する必要があります。
    note注 :
    このシナリオ例には、エッジ トランスポート サーバーの回復は含まれていません。エッジ トランスポート サーバーが SITEA に存在していて、サイトの障害時に失われた場合、新しいエッジ トランスポート サーバーを SITEB でオンラインにして、Contoso SMTP (簡易メール転送プロトコル) ドメインのメール エクスチェンジャ (MX) DNS レコードを更新して新しいエッジ トランスポート サーバーをポイントするようにする必要があります。

  7. Contoso 組織に追加の Active Directory サイトが含まれている場合、メッセージはプライマリ Active Directory サイトのキューに入れられます。EXCMS1 のサイト メンバシップ情報が他のすべての Active Directory サイトにレプリケートされたら、プライマリ サイト宛てのメッセージを保持している SMTP キューを手動で再試行できます(手動の再試行がない場合、トランスポート エンジンは、自動的にキューを再度 12 時間後に試行します)。これでメッセージが再分類されます。メッセージが再分類されたら、SITEB 内の EXCMS1 に配信されます。

この時点で、クライアントが使用する DNS サーバーと他のサーバーに EXCMS1 の正しい IP アドレスがある限り、すべてのクライアントは、元のアクセス方法 (Microsoft Outlook Web Access、Exchange ActiveSync、Microsoft Office Outlook など) を使用してメールボックスにアクセスできます。

プライマリ サイトの再構成

セカンダリ サイト (SITEB) が現在プライマリ データセンターとして動作しているため、元のプライマリ データセンター (SITEA) を再構成して、SITEB で現在ホストされているサービスが、SITEA を再度アクティブ化して使用できるようになった後に起動されるサービスと競合しないようにする必要があります。SITEA は、以下の手順を使用して管理者が制御しながらオンラインにする必要があります。

  1. 最初にディレクトリ サービスと DNS 名前解決サービスをオンラインにします。これを行うには、DC1 をオンラインにします。

  2. DC1 をオンラインにしたら、CAS1 と HUB1 をオンラインにします。
    HUB1 をオンラインにしたら、管理者はキュー内のメッセージが配信されていることを確認する必要があります。メッセージがキュー内に留まっている場合、以下のコマンドを使用して再度送信できます。

    Retry-queue [queue name] -Resubmit $True

  3. クラスタ EXCLUS1 をホストしているノードをオンラインにします。このシナリオの目的から、最初に NODEA をオンラインにし、次に NODEB をオンラインにします。

  4. 両方のノードがオンラインになり、クラスタ化メールボックス サーバーはオフライン状態のままになります。この中には、クラスタ化メールボックス サーバーを構成するすべてのリソースが含まれています。特にネットワーク名リソースがあります。このリソースは、EXCMS1 が既にオンラインになっていて同じネットワーク名を使用しているため、オンラインにすることはできません。NODEA または NODEB で EXCMS1 をオンラインにすると、ネットワーク上で名前の競合が発生します。

  5. クラスタ化メールボックス サーバーを含むリソース グループを現在所有しているノードでは、管理者は、フェールオーバー クラスタからクラスタ化メールボックス サーバーとそのリソースを消去する必要があります。これを行うには、管理者は最初に、クラスタ化メールボックス サーバーを含むクラスタ グループから Exchange 以外のリソースを削除します。次に、NODEA で以下のコマンドを実行します。

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

    次の点に注意してください。

    • クラスタ化メールボックス サーバーとそのリソースが EXCLUS1 から消去されたら、クラスタ アドミニストレータまたはフェールオーバー クラスタ管理のスナップインを使用して、クラスタ化メールボックス サーバーのすべてのリソースが削除されたことを確認することをお勧めします。
    • EXCLUS1 はこれで、NODEA と NODEB の 2 つのパッシブ ノードを持つフェールオーバー クラスタになります。これらのパッシブ ノードには、パッシブなメールボックス サーバーの役割がそれぞれインストールされています。この時点では、EXCLUS1 にクラスタ化メールボックス サーバーはありません。

  6. クラスタ ノードは Windows Server 2008 を実行しているので、Setup /ClearLocalCMS を実行すると、仮想コンピュータ オブジェクト (VCO) は無効になります。VCO を再度有効にするには、[スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[管理ツール] をポイントし、[Active Directory ユーザーとコンピュータ] をクリックします。ドメイン、[コンピュータ] の順に展開し、[EXCMS1 VCO] を右クリックして、次に [アカウントの有効化] をクリックします。

  7. SITEB から SITEA への手動での切り替えを準備するには、NODEA を SITEB 内の EXCMS1 でホストされているストレージ グループの SCR ターゲットにします。これを行うには、NODEC で以下のコマンドを使用します。

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEA
    note注 :
    元のフェールオーバー クラスタが使用していたストレージが SITEA の障害の影響を受けず、3 つのストレージ グループの元のデータベースとトランザクション ログがまだ NODEA に存在している場合、これらを連続レプリケーションに使用できます。この際、NODEA 上の各ストレージ グループに対して完全再シードを実行する必要はありません。既存のファイルが使用できないか、元のクラスタ化メールボックス サーバーに循環ログが構成されている場合は、Update-StorageGroupCopy コマンドレットを実行することで、各ストレージ グループに対して完全再シードを実行する必要があります。

このシナリオでは、SCC を例として使用しています。代わりに回復シナリオでクラスタ連続レプリケーション (CCR) 環境のクラスタ化メールボックス サーバーを使用する場合、データベースとログ ファイルを使用してステージングすることで、手動での切り替えにパッシブ ノードも準備する追加の手順をお勧めします。この手順は純粋に最適化のために行うもので、CCR 環境が SITEA に戻された後にパッシブなストレージ グループにシードする必要がなくなります。このタスクは、以下の 2 つのいずれかの方法で実行します。

  • 3 つの SCR ターゲットすべての連続レプリケーションを中断してから、ストレージ グループのファイルとデータベースを NODEA から NODEB 上の適切な場所にコピーする。
  • NODEB を EXCMS1 の SCR ターゲットとして有効にする。

元のプライマリ サイトへの手動での切り替え

SITEA の使用が承認されたら、データとサービスの SITEB から SITEA への手動の切り替えを実行できます。手動での切り替えを実現するための手順は、次に示すように SITEB をアクティブ化するために実行した手順のまさに逆です。

  1. 最初の手順は、EXCMS1 上ですべてのデータベースのマウントを解除することです。これは、トランザクション ログ ファイルの生成を停止し、NODEA 上で SCR ターゲットのアクティブ化の準備をするために行います。データベースのマウントを解除するには、Exchange 管理コンソールを使用するか、Exchange 管理シェルで Dismount-Database コマンドレットを使用します。

  2. NODEA 上で、管理者はすべてのストレージ グループをマウントする準備をします。このタスクは以下のコマンドを実行して行います。

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEA

    次の点に注意してください。

    • 上記の 3 つのコマンドでは、SCR ソース サーバーが使用可能なため、Force パラメータを使用していません。Force パラメータを使用していないため、このタスクでは、自動的にすべてのログ ファイルを SCR ソースからコピーしようとします。
    • 各タスクが完了したら、管理者は、各ストレージ グループのすべてのログ ファイルが NODEA にコピーされ、SCR が無効になっていることを確認する必要があります。
    • NODEB も SCR ターゲットとして構成している場合は、次の手順に進む前に、NODEB も無効にして復元する必要があります。このシナリオでは、Restore-StorageGroupCopy を NODEB、NODEA の順に実行してから、NODEA 上で Setup /RecoverCMS を実行することをお勧めします。

  3. DRCLUS1 上のクラスタ化メールボックス サーバー (EXCMS1) を停止する必要があります。このタスクを NODEC から実行するには、Exchange 管理コンソールでクラスタ化メールボックス サーバーの管理ウィザードを使用するか、Exchange 管理シェルで Stop-ClusteredMailboxServer コマンドレットを使用します。

  4. EXCMS1 の A レコードは、DNS 管理スナップインを使用して DNS から削除する必要があります。

    note注 :
    EXCMS1 の A レコードを削除する必要があるのは、フェールオーバー クラスタが Windows Server 2008 上で実行されている場合のみです。フェールオーバー クラスタが Windows Server 2003 上で実行されている場合は、この手順を実行する必要はありません。

  5. Setup の /RecoverCMS オプションを使用して、クラスタ化メールボックス サーバー (EXCMS1) を回復します。NODEA 上で以下のコマンドを使用して回復を実行します。

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    次の点に注意してください。

    • 上記のコマンドの CMSIPAddress の値は、通常 EXCMS1 の元の IP アドレスになります。これは、EXCLUS1 が元の場所に回復されるためです。
    • Setup 回復プロセスが完了したら、EXCMS1 が SITEA に回復され、EXCLUS1 と呼ばれる 2 ノードの SCC 内の NODEA 上でホストされるようになります。
    note注 :
    繰り返しますが、このシナリオでは、SCC を例として使用しています。代わりに回復シナリオで CCR 環境のクラスタ化メールボックス サーバーを使用する場合、追加手順を実行する必要があります。/RecoverCMS 操作は、連続レプリケーション、この場合 NODEA から NODEB への連続レプリケーションを中断します。レプリケーション操作と再生操作を再度確立するには、管理者はストレージ グループに対して Resume-StorageGroupCopy を実行する必要があります。次に、レプリケーション操作が再開されたことを確認する必要があります。前に説明した NODEB のステージングが失敗した場合、ストレージ グループのパッシブ コピーを再シードする必要があります。

    • クラスタ化メールボックス サーバーの回復操作の結果として、EXCMS1 の DNS TTL はデフォルト値の 20 分に戻されます。この値は、以下のコマンドを実行してから、クラスタ化メールボックス サーバーを停止後に起動して、5 分に設定し直す必要があります。

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300

  6. Mount-Database コマンドレットを使用して、3 つのストレージ グループ内のデータベースをマウントします。

  7. このシナリオでは、他のサーバーの役割 (つまり、クライアント アクセスとハブ トランスポート) の回復操作を実行する必要はありません。CAS1 と HUB1 が既に SITEA に存在しているためです。

    note注 :
    クライアント アクセス サーバーの回復操作の一環として、外部 URL を SITEA 内のクライアント アクセス サーバーをポイントするように再構成する必要があります。
    note注 :
    このシナリオ例には、エッジ トランスポート サーバーの回復は含まれていません。エッジ トランスポート サーバーが使用中の場合、Contoso SMTP ドメインのメール エクスチェンジャ (MX) DNS レコードを更新して正しいエッジ トランスポート サーバーをポイントするようにする必要があります。

  8. Contoso 組織に追加の Active Directory サイトが含まれている場合、メッセージはプライマリ Active Directory サイトのキューに入れられます。EXCMS1 のサイト メンバシップ情報が他のすべての Active Directory サイトにレプリケートされたら、プライマリ サイト宛てのメッセージを保持している SMTP キューを手動で再試行できます(手動の再試行がない場合、トランスポート エンジンは、自動的にキューを再度 12 時間後に試行します)。これでメッセージが再分類されます。メッセージが再分類されたら、SITEA 内の EXCMS1 に配信されます。

  9. この時点で、クライアントが使用する DNS サーバーと他のサーバーに EXCMS1 の正しい IP アドレスがある限り、すべてのクライアントは、元のアクセス方法 (Outlook Web Access、Exchange ActiveSync、Outlook など) を使用してメールボックスにアクセスできます。さらに、DNS の変更が SITEB にレプリケートされ、EXCMS1 のサイト メンバシップがレプリケートされると、ハブ トランスポート サーバーは、メッセージを正しい Active Directory サイトにルーティングします。管理者は、HUB1 または HUB2 の任意のキューにあるメッセージを手動で強制的に再送信させることもできます。このタスクは以下のコマンドを実行して行えます。

    Retry-queue [queue name] -Resubmit $True

バックアップ サイトの再構成

SITEB から SITEA への手動の切り替えが完了したら、SITEB をバックアップ データセンターとして動作状態に戻すことができます。この中には、SITEB 内のフェールオーバー クラスタからスタンバイ クラスタ化メールボックス サーバーを消去することと、NODEC を EXCMS1 の 3 つのストレージ グループの SCR ターゲットとして再度有効にすることが含まれています。これには、以下の手順を順に実行します。

  1. 手動での切り替え中に、SITEB 内の DRCLUS1 上で実行されていたクラスタ化メールボックス サーバーは、SITEA 内の EXCLUS1 で起動できるように停止されました。EXCMS1 が EXCLUS1 上で正常に運用状態に戻ったら、その構成情報を DRCLUS1 から削除する必要があります。クラスタ化メールボックス サーバーを含むクラスタ グループから Exchange 以外のリソースを削除し、次に以下のコマンドを実行すると、構成情報を消去し、EXCMS1 を DRCLUS1 から完全に削除できます。

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

  2. クラスタ ノードは Windows Server 2008 を実行しているので、Setup /ClearLocalCMS を実行すると、VCO は無効になります。VCO を再度有効にするには、[スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[管理ツール] をポイントし、[Active Directory ユーザーとコンピュータ] をクリックします。ドメイン、[コンピュータ] の順に展開し、[EXCMS1 VCO] を右クリックして、次に [アカウントの有効化] をクリックします。

  3. クラスタ化メールボックス サーバーとそのリソースが DRCLUS1 から消去されたら、管理者はクラスタ アドミニストレータまたはフェールオーバー クラスタ管理のスナップインを使用して、クラスタ化メールボックス サーバーのすべてのリソースが削除されたことを確認する必要があります。

  4. SCR は、トランザクション ログ ファイルが EXCMS1 上の 3 つのストレージ グループから NODEC 上の SCR ターゲットにレプリケートされるように構成されています。これは以下のコマンドを使用して構成します。

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC
    note注 :
    SCR を有効にして EXCMS1 から NODEC にストレージ グループをレプリケートする前に、競合するストレージ グループまたはデータベース パスがないことを確認する必要があります。また、以前の不要になったストレージ グループやデータベース ファイルが元のパスから削除されていることを確認する必要があります。

  5. 次に、各ストレージ グループに対する SCR の稼働状態を、Test-ReplicationHealth および Get-StorageGroupCopyStatus コマンドレットを使用して確認します。ノード間のクラスタ化メールボックス サーバーの移動、およびバックアップやログの切り詰め操作が、期待どおりに機能していることも確認する必要があります。すべての確認が完了したら、プライマリ データセンターとセカンダリ データセンターは、Exchange 2007 メッセージング システムの観点から元の運用モードに戻ったことになります。

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