クラスタ連続レプリケーションの管理
適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
トピックの最終更新日: 2009-06-10
Exchange 組織の日常的な管理タスクに加えて、クラスタ連続レプリケーション (CCR) 環境に固有の管理タスクがあります。一般に、CCR の管理タスクは 2 つのカテゴリに分けられます。
- クラスタ化メールボックス サーバーに関連するタスク
- クラスタ化メールボックス サーバーのストレージ グループとデータベースに関連するタスク
クラスタ化メールボックス サーバーに関連するタスク
CCR 環境内のクラスタ化メールボックス サーバーに関連する管理タスクには、以下のものがあります。
- ディスク ボリュームの管理
- 構成設定の表示
- レプリケーション処理の監視
- パフォーマンス データの表示と収集
- クラスタ化メールボックス サーバーの管理。これには、クラスタ化メールボックス サーバーのオンライン化とオフライン化、およびノード間でのクラスタ化メールボックス サーバーの移動などがあります。
- ログ ファイルのレプリケーションと再生の管理
ディスク ボリュームの管理
CCR 環境を管理しているときに、CCR クラスタに関連付けられているディスク ボリュームの管理が必要になることがあります。たとえば、保守やその他の理由で、ボリュームをシステムから一時的に切り離すことが必要になる場合があります。アクティブなストレージ グループやデータベースに対してこの操作が必要な場合は、ストレージ グループ内のデータベースのマウントを解除する必要があります。ストレージ グループやデータベースのパッシブ コピーに対してこのような操作を行う場合は、レプリケーションを停止して、ボリュームへのレプリケーション入出力 (I/O) をすべて停止する必要があります。
ディスク ボリュームの管理の詳細については、「CCR コピー用のディスク ボリューム管理作業に備える方法」を参照してください。
構成設定の表示
サーバーの CCR を有効にしたら、Exchange 管理コンソールおよび Exchange 管理シェルを使用して、サーバー上のストレージ グループおよびデータベースの構成設定を表示することができます。
構成情報には、ストレージ グループとデータベース ファイルの場所が含まれています。さらに、Exchange 管理シェルを使用して、クラスタ化メールボックス サーバーに関連する構成を確認できます。
CCR フェールオーバー制御の構成情報を表示する方法の詳細については、「フェールオーバー制御の構成を表示する方法」を参照してください。
レプリケーション処理の監視
データベースのパッシブ コピーは、最新の状態に保たれている場合にのみ役に立ちます。CCR には特殊な監視は必要ありませんが、各ストレージ グループを定期的に監視して、ログ ファイルが正しくレプリケートされていることを確認することをお勧めします。Microsoft Operations Manager 2005 用 Microsoft Exchange Server 2007 管理パックには、CCR 環境に関連したいくつかの重大な問題の警告が含まれています。
- パッシブ ノード上で Microsoft Exchange Replication Service が実行されていない。サービスを停止するとこのアラートを生成するイベントが繰り返し表示されなくなるため、この問題が解消されたかのように、関連付けられているアラートが表示されなくなります。
- パッシブ コピーが失敗の状態にある。
- パッシブ コピーは正常な状態であるが、ログのコピーまたは再生が大幅に遅れている。
また、パッシブ ノードが実行中かつアクティブ ノードを含むクラスタの一部であることが検出されない場合にトリガされるカスタム イベント ルールを Microsoft Operations Manager に追加することをお勧めします。この条件が発生すると、クラスタ サービスはシステム イベント ログにイベントを記録します。イベント ルールとして、次の条件を使用することをお勧めします。これは、クラスタ サービスによって記録されるイベントの一部になります。
イベント ソース : ClusSvc
イベント ID : 1135
Microsoft Operations Manager でのイベント ルールの作成の詳細については、MOM によるセキュリティ イベントの監視についてのページを参照してください (このサイトは英語の場合があります)。
Exchange 2007 管理パックまたはカスタム イベント ルールによって生成された上記のいずれの警告も、できる限り迅速に調査して解決してください。
Microsoft Operations Manager 2005 用 Exchange 2007 管理パックの別の使用方法として、Get-StorageGroupCopyStatus コマンドレットを実行するスクリプトを Exchange 管理シェルで定期的に実行する方法があります。Get-StorageGroupCopyStatus コマンドレットを実行すると、アクティブ ノードによって生成されるログの数が組み込まれたキューの長さを取得できます。パフォーマンス上の理由により、キューの長さのパフォーマンス カウンタは Microsoft Exchange レプリケーション サービスで既知の情報のみを報告します。まれに、この情報がアクティブ ノードの状態と矛盾している場合があります。Get-StorageGroupCopyStatus コマンドレットの詳細については、後の「ストレージ グループ コピーの状態の表示」を参照してください。
パフォーマンス データの表示と収集
パフォーマンス カウンタを使用して、レプリケーションの進行状況を確認できます。CCR に関するパフォーマンス カウンタの使用の詳細については、「クラスタ連続レプリケーションのパフォーマンス カウンタを表示する方法」を参照してください。
クラスタ化メールボックス サーバーの管理
クラスタ化メールボックス サーバーを管理するための主要な管理タスクには、クラスタ化メールボックス サーバーのオンライン化、オフライン化、およびクラスタ化メールボックス サーバーのクラスタ内のノード間での移動の 3 つがあります。クラスタ内のノードのシャットダウンや再起動も、更新管理やその他の保守操作の一部として含まれます。
クラスタ化メールボックス サーバーの起動と停止
フェールオーバー クラスタ管理ツール (Windows Server 2008)、クラスタ アドミニストレータ (Windows Server 2003)、および Cluster.exe コマンドライン ツール (両方のオペレーティング システム内) には、リソースをオンラインまたはオフラインにする機能があります。クラスタ化メールボックス サーバーをオフラインにすることを停止、クラスタ化メールボックス サーバーをオンラインにすることを起動と呼びます。クラスタ化メールボックス サーバーは、Start-ClusteredMailboxServer コマンドレットを使用して起動することをお勧めします。また、Stop-ClusteredMailboxServer コマンドレットを使用して停止することをお勧めします。Exchange 2007 Service Pack 1 (SP1) では、Exchange 管理コンソールのクラスタ化メールボックス サーバーの管理ウィザードを使用して、クラスタ化メールボックス サーバーを起動または停止することもできます。
クラスタ化メールボックス サーバーをオンラインにする方法の詳細については、「クラスタ化メールボックス サーバーを起動する方法」を参照してください。クラスタ化メールボックス サーバーをオフラインにする方法の詳細については、「クラスタ化メールボックス サーバーを停止する方法」を参照してください。
ノード間でのクラスタ化メールボックス サーバーの移動
ノードからノードへクラスタ化メールボックス サーバーを手動で移動することは、ハンドオフ、またはスケジュールされた停止と呼ばれます。クラスタ化メールボックス サーバーを移動するには、Move-ClusteredMailboxServer コマンドレットを使用します。Exchange 2007 SP1 では、Exchange 管理コンソールでクラスタ化メールボックス サーバーの管理ウィザードを使用して、クラスタ化メールボックス サーバーのハンドオフを行うこともできます。フェールオーバー クラスタ管理ツール (Windows Server 2008)、クラスタ アドミニストレータ (Windows Server 2003)、および Cluster.exe コマンドライン ツール (両方のオペレーティング システム内) を使用してノード間でクラスタ化メールボックス サーバーを移動することもできますが、クラスタ化メールボックス サーバーをアクティブ ノードからパッシブ ノードに移動するには、Exchange 管理ツールの 1 つを使用することをお勧めします。これは、この方法ではハンドオフの理由を指定できるためです。さらに、以下のことに注意してください。
- クラスタ ツールを使用すると、Exchange 管理ツールでは実行される、パッシブ コピーの状態の確認がスキップされます。したがって、これらの方法を使用すると、ノードが必要な処理を実行してデータベースをマウント可能にする間に、停止が長時間に及ぶ可能性があります。
- また、クラスタ ツールを使用すると、レプリケーションが正常に行われなかった場合にデータベースが無期限にオフラインのままになる可能性があります。Exchange 管理ツールとは異なり、クラスタ ツールではリソース グループの移動前にレプリケーションの状態を判断することはできません。
.gif "note")
注 :ノード間でクラスタ化メールボックス サーバーを移動すると、短時間ですがサービスが中断されます。さらに、クラスタ化メールボックス サーバー上のすべてのストレージ グループに対するバックアップは取り消されます。
レプリケーションが正常に行われていない場合、またはこれらのチェックにより、パッシブ ノードがハンドオフに適切な状態ではないと判断された場合、Exchange 管理ツールはハンドオフを実行しません。この場合、CMS をパッシブ ノードに移動する必要があれば、クラスタ管理ツールを使用して移動することができます。
ネットワークの遅延があるフェールオーバー クラスタで、クラスタ化メールボックス サーバーをノード間で移動するときには、パッシブ ノードから移動操作を行うことをお勧めします。
クラスタ化メールボックス サーバーをノード間で移動する方法の詳細については、「CCR 環境のクラスタ化メールボックス サーバーを移動する方法」を参照してください。
クラスタでの保守の実行
保守作業は、常にクラスタ内のパッシブ ノードで実行する必要があります。更新プログラム、修正プログラム、およびその他のアプリケーションは一般に、アクティブ ノード (現在クラスタ化メールボックス サーバーを所有しているノード) にはインストールされません。CCR 環境に Exchange の更新プログラムのロールアップをインストールする方法の詳細については、「クラスタ化メールボックス サーバーへの Exchange 2007 更新プログラムのロールアップの適用」を参照してください。
アクティブ ノードで保守を実行する必要がある場合は、最初に Move-ClusteredMailboxServer コマンドレットを使用して、クラスタ化メールボックス サーバーをパッシブ ノードに移動する必要があります。クラスタ化メールボックス サーバーを移動すると、以前のアクティブ ノードがパッシブ ノードになり、以前のパッシブ ノードがアクティブ ノードになります。その後、保守が完了したら、クラスタ化メールボックス サーバーを逆方向に移動するハンドオフを実行できます。
CCR 環境では、クラスタ化メールボックス サーバーを停止させることなく、特定のノードのシステム停止をスケジュールすることができます。CCR 環境では、一度に 1 つのノードしかオフラインにすることができません。複数のノードをオフラインにすると、サービスが中断します。
スケジュールされた停止を開始するには、Exchange 管理シェルの Move-ClusteredMailboxServer コマンドレットを使用します。スケジュールされた停止を実行する手順については、「CCR 環境のクラスタ化メールボックス サーバーを移動する方法」を参照してください。
CCR 環境内のノードをシャットダウンして再起動する前に、現在クラスタ化メールボックス サーバーをホストしているノードを確認することをお勧めします。この情報は、Get-ClusteredMailboxServerStatus コマンドレットを使用して取得できます。
クラスタでの保守の実行
保守作業は、常にクラスタ内のパッシブ ノードで実行する必要があります。更新プログラム、修正プログラム、およびその他のアプリケーションは一般に、アクティブ ノード (現在クラスタ化メールボックス サーバーを所有しているノード) にはインストールされません。CCR 環境に Exchange の更新プログラムのロールアップをインストールする方法の詳細については、「クラスタ化メールボックス サーバーへの Exchange 2007 更新プログラムのロールアップの適用」を参照してください。
アクティブ ノードで保守を実行する必要がある場合は、最初に Move-ClusteredMailboxServer コマンドレットを使用して、クラスタ化メールボックス サーバーをパッシブ ノードに移動する必要があります。クラスタ化メールボックス サーバーを移動すると、以前のアクティブ ノードがパッシブ ノードになり、以前のパッシブ ノードがアクティブ ノードになります。その後、保守が完了したら、クラスタ化メールボックス サーバーを逆方向に移動するハンドオフを実行できます。
クラスタ内のノードのシャットダウン
アクティブ ノードを含むクラスタ内のすべてのノードをシャットダウンする必要がある場合は、最初にクラスタ化メールボックス サーバーを停止する必要があります。Windows のシャットダウン プロセスは、Exchange に対応していません。したがって、パッシブ ノードのみをシャットダウンすることをお勧めします。アクティブ ノードのシャットダウンまたは再起動が必要な場合は、クラスタ化メールボックス サーバーを利用可能な別のノードに移動することをお勧めします。クラスタ化メールボックス サーバーを別のノードに移動する方法の詳細については、「CCR 環境のクラスタ化メールボックス サーバーを移動する方法」を参照してください。
クラスタ化メールボックス サーバーを (パッシブ ノードが既にシャットダウンされているなどの理由のために) パッシブ ノードに移動できない場合は、アクティブ ノードを停止してからシャットダウンする必要があります。
アクティブ ノードを再起動またはシャットダウンする必要があり、クラスタ化メールボックス サーバーをパッシブ ノードに移動できない場合は、グループ ポリシーを使用してクラスタ化メールボックス サーバーが停止したことを確認してから、アクティブ ノードを再起動またはシャットダウンすることをお勧めします。Windows Server には、ポリシーを基に実行される一連のコンピュータ シャットダウン用のスクリプトが用意されています。これらのスクリプトは、グループ ポリシー スナップインを使用して管理できます。グループ ポリシー スナップインには、コンピュータのシャットダウン時に実行されるスクリプトを指定できる拡張機能が含まれています。
たとえば、Move-ClusteredMailboxServer コマンドレットまたは Stop-ClusteredMailboxServer コマンドレットに適切なパラメータを指定して実行するシャットダウン スクリプトを作成することができます。アクティブ ノードをシャットダウンする前にクラスタ化メールボックス サーバーを移動または停止する必要があることを理解していない管理者によってシステムがシャットダウンまたは再起動される可能性を最小限に抑えることができるという理由からも、シャットダウン スクリプトの使用をお勧めします。
.gif "important") 重要 : |
|---|
| これらのスクリプトは、ローカル システム アカウントで実行されます。これらのスクリプトを正常に実行するには、Local System アカウント (ローカル ノードのコンピュータ アカウント) にクラスタ化メールボックス サーバーを管理するためのアクセス許可を付与する必要があります。 |
ログ ファイルのレプリケーションと再生の管理
CCR 環境でレプリケーションを管理する際に行う必要がある主な処理は、次のとおりです。
- レプリケーションが停止したときのフェールオーバーの処理
- ストレージ グループ コピーに対するレプリケーションの停止と再開
- レプリケーションに使用する 1 つ以上の冗長ネットワークの構成
レプリケーションが停止したときのフェールオーバーの処理
レプリケーションを停止すると、中断されている間はアクティブなストレージ グループからコピーへの変更の適用がすべて停止します。この間にフェールオーバーが発生すると、ストレージ グループ コピーには最新の変更が適用されません。アクティブ ノードで発生した変更の量によっては、最新の変更が適用されないと、システムがパッシブ コンピュータにコピーをマウントできなくなる可能性があります。この場合、パッシブ ノード上の使用可能なバージョンのストレージ グループを使用するか、または元のサーバーが回復するまで待つことになります。この影響を最小限に抑えるために、レプリケーションの停止時間を最小限にすることが重要です。
元のコンピュータが使用可能になったときに、パッシブ ノード上にあるバージョンのデータをマウントしない場合は、レプリケーション システムは消失したログをコピーし、新しいアクティブ ノードにデータベースのコピーを自動的にマウントします。
レプリケーションが再開された後に実行されるフェールオーバーは、パッシブ コピーに一部のログが欠けている場合、またはすべてのログが揃っていてもそれが再生される前に発生する可能性があります。ログはコピーされたが、まだ再生されていない場合は、フェールオーバーによって未処理のログのデータベースへの再生が行われます。このため、フェールオーバーの一部としてのこのストレージ グループの回復時間は延長されますが、他のストレージ グループは影響を受けません。ただし、構成されている自動マウントの条件を満たすだけの十分なログが利用可能な場合、システムは最終的に最新の使用可能なデータを使用してデータベースをマウントします。この処理には 1 つのリスクがあります。再生されるログのいずれかが破損していて、正常に再生できない可能性があります。この場合は、再生はエラーで終了し、それ以降の再生処理はすべてブロックされます。この状態が発生すると、ストレージ グループ コピーは "失敗" と呼ばれるエラー状態になります。このエラー状態では、その時点までのバージョンのデータベースを使用して回復できる可能性があります。それ以外の場合は、元のサーバーが使用可能になり、破損していないログが再度コピーされるまで待つ必要があります。
ストレージ グループ コピーに対するレプリケーションの停止と再開
パッシブ コピーの利用を制御する必要が生じることもあります。その際に、レプリケーション処理の停止および再開が必要になる場合があります。レプリケーションは、ストレージ グループ レベルで制御されます。ストレージ グループにはデータベースを 1 つしか格納できないため、レプリケーションは 1 つのデータベースに限定されます。
レプリケーションは、クラスタの両方のノードが稼働していて、レプリケート先のノードで Microsoft Exchange レプリケーション サービスが実行されており、ストレージ グループ コピーのコピーが有効になっている場合に発生します。CCR のレプリケート元またはレプリケート先のいずれかが利用できなくなった場合、レプリケーションを停止する必要があります。さらに、シード、整合性チェックの実行、記憶域の再構成などの一部の CCR 管理タスクでは、ストレージ グループ コピーのレプリケーションが停止している必要があります。レプリケート先のログ ファイルおよびログ ディレクトリへのアクセスをすべて停止する必要がある場合は、レプリケーションを停止する必要があります。
Exchange 2007 では、ストレージ グループまたはデータベースの場所を変更しているときには、すべてのレプリケーション処理を停止する必要があります。
データベース コピーの更新を停止する方法の詳細については、「クラスタ連続レプリケーション コピーでレプリケーションを中止する方法」を参照してください。データベース コピーの更新を再開する方法の詳細については、「クラスタ連続レプリケーション (CCR) コピーのレプリケーションを再開する方法」を参照してください。
CCR トランザクション ログとデータベース ファイルに対して整合性チェックを行う方法の詳細については、「Eseutil を使用してクラスタ連続レプリケーション コピーを確認する方法」を参照してください。
レプリケーションに使用する 1 つ以上の冗長ネットワークの構成
Exchange 2007 SP1 では、CCR 環境でのログ配布とシードに使用される冗長クラスタ ネットワークを構成できます。冗長ネットワークは、混在したクラスタ ネットワークとして構成する必要があります。混在したクラスタ ネットワークとは、クラスタ (ハートビート) とクライアント アクセス トラフィックの両方の目的に構成されているクラスタ ネットワークを指します。
混在したクラスタ ネットワークに連続レプリケーションのホスト名と IP アドレスが構成されている場合、Exchange 2007 はこのネットワークを使用してログ配布を行います。また、そのように構成されたネットワークは、管理者が Update-StorageGroupCopy コマンドレットで開始するシードにも利用されます。複数の混在したネットワークを指定することもできます。複数のネットワークが利用可能な場合、Exchange 2007 によっていずれかのネットワークがランダムに選択されます。現在使用しているネットワークが利用できなくなった場合、Exchange 2007 は利用可能な別のネットワークを自動的に選択します。
混合ネットワークを介したログ配布のサポートは、Enable-ContinuousReplicationHostName コマンドレットを使用して構成します。また、この機能をオフにするには、Disable-ContinuousReplicationHostName コマンドレットを使用します。管理者は、CCR 環境にクラスタ化メールボックス サーバーが存在するようになった後、クラスタの両方のノードで Enable-ContinuousReplicationHostName を実行し、2 つの IP アドレスとホスト名を指定することができます。この指定後、構成が正常に完了し、混合ネットワークが機能していることが確認されると、システムによってログのコピー用の混合ネットワークがランダムに選択されます。
CCR 環境でのシードおよび再シードは、Update-StorageGroupCopy コマンドレットを使用して行われます。Exchange 2007 SP1 では、このコマンドレットは拡張され、DataHostNames という新しいパラメータが含まれています。このパラメータは、シードまたは再シードに使用するネットワークを指定するために使用されます。この値は、完全修飾ドメイン名 (FQDN) またはホスト名の 2 つの名前による複数値の一覧です。この中のいずれかの名前にはパッシブ ノードを指定する必要があります。
ログ配布とシードに使用する冗長ネットワークを構成する方法の詳細については、以下のトピックを参照してください。
- Windows Server 2008 の CCR について
- Windows Server 2003 の CCR について
クラスタ化メールボックス サーバーのストレージ グループとデータベースに関連するタスク
CCR 環境内のクラスタ化メールボックス サーバーのストレージ グループとデータベースに関連する管理タスクには、以下のものがあります。
- ストレージ グループ ファイルまたはデータベースの場所の移動
- ストレージ グループ コピーの状態の表示
- データベースのマウントとマウントの解除
- ストレージ グループ コピーの整合性の検証
- 運用ストレージ グループまたはストレージ グループ コピーの破損からの回復
- エラーまたは何らかのデータ破損が発生した後の CCR の復元
特別な種類のストレージ グループである回復用ストレージ グループを除き、CCR 環境内のすべてのストレージ グループとデータベースでは自動的に連続レプリケーションが有効になります。レプリケーションや再生を中断することはできますが、CCR 環境内の 1 つまたは複数のストレージ グループについて連続レプリケーションを無効にすることはできません。これは、無効にすることによって、停止が発生した場合に特定のデータベースにアクセスできなくなるためです。
CCR 環境内に新しいストレージ グループを作成すると、パッシブ ノード上のデータベースのコピーのシードが自動的に実行されます。何らかの理由でシードが自動的に実行されない場合、手動でデータベース コピーをシードする必要があります。データベース コピーをシードする方法の詳細については、「クラスタ連続レプリケーション コピーをシードする方法」を参照してください。
ストレージ グループ ファイルまたはデータベースの場所の移動
CCR 環境内で、ストレージ グループ ファイルの場所やデータベースの場所の移動が必要となる場合があります。ファイルの場所を移動するためにかかる時間は、移動するデータベースのサイズ、移動するトランザクション ログ ファイルの数、および記憶域のパフォーマンス特性によって異なります。移動時には、データベースのマウントが解除されます。
CCR 環境でストレージ グループを再配置する場合は、アクティブ ノードとパッシブ ノードのファイルの場所が同じである必要があるため、両方のコピーを整合性のある方法で再配置する必要があります。ストレージ グループ、またはそのデータベースを移動する前に、データベースのマウントを解除し、レプリケーションを中断する必要があります。アクティブ コピーの場合、この操作は Exchange 管理シェルで Dismount-Database コマンドレットを使用して実行できます。Microsoft Exchange レプリケーション サービスの場合は、Suspend-StorageGroupCopy コマンドレットおよび Resume-StorageGroupCopy コマンドレットを使用します。
| 注 : |
|---|
| Microsoft Exchange レプリケーション サービスは、コピーの場所とアクティブ ノード上のログの両方にあるファイルを常時監視しています。そのため、アクティブ ログに何らかの操作を行う場合は、そのストレージ グループの処理を中断する必要があります。これを行うには、Suspend-StorageGroupCopy コマンドレットを使用して、レプリケーションを停止します。 |
CCR 環境内でストレージ グループ ファイルの場所を移動する方法の詳細については、「CCR 環境でストレージ グループを移動する方法」を参照してください。CCR 環境内でデータベースの場所を移動する方法の詳細については、「CCR 環境のデータベースを移動する方法」を参照してください。
ストレージ グループ コピーの状態の表示
Microsoft Exchange 2007 の RTM (Release To Manufacturing) 版では、CCR の状態情報は、Exchange 管理シェルでのみ表示できます。Exchange 2007 SP1 では、次の表に示されている一部の状態情報を Exchange 管理コンソールで確認できます。
Exchange 2007 は、ストレージ グループ コピーについてさまざまな状態情報を公開します。次の表は、利用可能な状態情報の説明です。この表では、Get-StorageGroupCopyStatus コマンドレットの完全な出力に表示される順で属性の一覧を示しています。状態情報を表示する手順の詳細については、「Exchange 管理シェルを使用してクラスタ連続レプリケーション コピーの状態を表示する方法」を参照してください。
CCR が有効になっているストレージ グループで使用できる状態情報
| 属性 | 説明 |
|---|---|
Identity |
クエリの対象となるストレージ グループの ID。この属性は <サーバー名>\<ストレージグループ名> を指定します。 |
StorageGroupName |
クエリの対象となるストレージ グループの名前です。この属性はストレージ グループ名を指定します。 |
SummaryCopyStatus |
パッシブ コピーの現在の全体的な状態です。使用可能な値は次のいずれかです。
Exchange 2007 SP1 では、次の状態値が追加されています。
|
Failed |
データベースまたはログの検証で、レプリケーションを妨げるような矛盾が識別されました。または、アクティブ コピーかパッシブ コピーに構成またはアクセスの問題があります。値は True または False です。 |
FailedMessage |
レプリケーションを失敗させた条件を識別するテキスト メッセージです。レプリケーションで問題のある部分は、このメッセージで示されたものだけとは限りません。 |
Seeding |
シードが進行中であることを示します。値は True または False です。 |
Suspend |
パッシブ コピーについてレプリケーションが停止されたことを示します。この状態ではデータベースの処理は続行されず、ログもコピーされません。値は True または False です。 |
SuspendComment |
省略可能なコメント領域で、管理者はレプリケーション処理が停止した理由や注記をここに入力できます。 |
CopySuspend |
パッシブ コピーについてログのコピーが停止されたことを示しています。この場合、ログのコピー ディレクトリは変更されません。値は True または False です。 |
CopySuspendComment |
管理者による省略可能なコメントで、ログのコピー処理が停止した理由または注記を示します。 |
CopyQueueLength |
パッシブ コピー ログ ファイル フォルダにコピーされるのを待っているトランザクション ログ ファイルの数です。コピーは、破損の検査が終了するまで完了したと見なされません。 |
ReplayQueueLength |
パッシブ コピーに作成されるのを待っているトランザクション ログ ファイルの数です。 |
LatestAvailableLogTime |
最後に検出された新しいトランザクション ログ ファイルのソース ストレージ グループのタイムスタンプです。 |
LastCopyNotificationedLogTime |
アクティブ ストレージ グループによって生成された最新のログに関連付けられており、コピーから認識されている日時です。 |
LastCopiedLogTime |
最後に正常にコピーされたトランザクション ログ ファイルのソース ストレージ グループのタイムスタンプです。 |
LastInspectedLogTime |
最後に正常に検査されたトランザクション ログ ファイルのターゲット ストレージ グループのタイムスタンプです。 |
LastReplayedLogTime |
最後に正常に再生されたトランザクション ログ ファイルのターゲット ストレージ グループのタイムスタンプです。 |
LastLogGenerated |
ストレージ グループのアクティブ コピーに生成されたことがわかっている最後のログ生成番号です。 |
LastLogCopied |
パッシブ コピー ログ フォルダに正常にコピーされた最後のログ生成番号です。 |
LastLogNotified |
アクティブ ストレージ グループによって生成され、コピーから認識されている最後のログ生成番号です。 |
LastLogInspected |
一貫性と破損について検査された最後のログ生成番号です。 |
LastLogReplayed |
データベースのパッシブ コピーに正しく再生された最後のログ世代番号です。 |
LatestFullBackupTime |
最後の完全バックアップの日時です。 |
LastestIncrementalBackupTime |
最後の増分バックアップの日時です。 |
SnapshotBackup |
前回行われた完全バックアップが従来のストリーミング バックアップであるか、ボリューム シャドウ コピー サービス (VSS) のバックアップ スナップショットであるかを示します。 |
SnapshotLatestFullBackup |
最後のスナップショット完全バックアップの日時です。 |
SnapshotLatestIncrementalBackup |
最後のスナップショット増分バックアップの日時です。 |
SnapshotLatestDifferentialBackup |
最後のスナップショット差分バックアップの日時です。 |
SnapshotLatestCopyBackup |
最後のスナップショット コピー バックアップの日時です。 |
OutstandingDumpsterRequests |
未処理の要求と、未処理の要求の時間的な範囲 (開始 - 終了) です。 |
DumpsterStatistics |
アクセスできるすべてのハブ トランスポート サーバーから得られたトランスポート収集の統計です。この値は、Get-StorageGroupCopyStatus コマンドで DumpsterStatistics パラメータが使用された場合のみ表示されます。 |
DumpsterStatisticsNotAvailable |
アクセスできないハブ トランスポート サーバーの一覧です。 |
SummaryCopyStatus、CopyQueueLength、ReplayQueueLength、および LastInspectedLogTime の値を調べると、ストレージ グループのコピーが正常な状態にあるかどうかをすばやく評価できます。これらの属性は、ストレージ グループのコピーが正しく機能しているかどうかと、ストレージ グループのコピーがログのコピーと再生の両方において相対的に最新の状態にあるかどうかを示します。以下の条件が当てはまる場合は、問題の原因を特定して修正する必要があります。
- コピーが正常な状態にない。
- コピー キューの長さが 5 を超えている。
- 再生キューの長さが 20 を超えている。
- 最後に検査されたログの時刻が最近でない。この状況はストレージ グループの休止状態によって発生することもありますが、Microsoft Exchange レプリケーション サービスが停止していることを示している場合もあります。
2 つのキューの数値は、時間単位で次のように計算できます。
- コピー キュー (時間) = LatestAvailableLogTime – LastCopiedLogTime
- 再生キュー (時間) = LatestCopiedLogTime – LastInspectedLogTime
再生キューの長さとコピー キューの長さの値は、パフォーマンス カウンタとして利用可能です。これらは、Microsoft Exchange レプリケーション サービスのパフォーマンス オブジェクトの下にある、CopyQueueLength および ReplayQueueLength パフォーマンス カウンタです。
まれに、レプリケーションの状態によって、判断を誤りかねないような状況が生じることがあります。以下に、そのような状況を一覧で示します。
- アクティブでない (つまり、変更されていない) ストレージ グループが正常な状態ではない可能性があるときに、このストレージ グループが Healthy と報告されることがあります。この状況は、ログが再生されるまで、正常ではない状態にあることを検出できなかったために発生する場合があります。
- レプリケーションの初期化中は、レプリケーションの状態が評価されているために正確でないことがあります。初期化が完了すると、状態は更新されます。
- データベースのマウントが解除されている場合は、LastLogGenerated フィールドの値が間違っている可能性があります。ただし、ストレージ グループ コピーのレプリケーションが行われている場合は、エンド ユーザーのコンテンツがあるログはすべてレプリケートされます。
- ログ ストリームの途中に足りないログが 1 つ以上ある場合、パッシブ コピーは引き続き回復を試みます。その際に、レプリケーションの状態は Failed と Healthy の間で切り替わります。再生とコピーのキューは拡大し続けます。
- ごくまれに、ログの検証が正常に行われても、再生に失敗することがあります。この場合、システムは回復を試みるときに、状態を Failed と Healthy の間で切り替えます。再生とコピーのキューは拡大し続けます。注 :
Exchange 2007 SP1 では、Test-ReplicationHealth という新しいコマンドレットを使用して、連続レプリケーションが有効なストレージ グループの稼働状態を検証することができます。Test-ReplicationHealth コマンドレットの詳細については、「Test-ReplicationHealth」を参照してください。
データベースのマウントとマウントの解除
CCR 環境でデータベースのマウントまたはマウントの解除が必要になる場合があります。この作業が必要になるのは、再構成を実行する場合や、サーバーやデータベースに関する問題を修正する場合です。データベースのマウントが解除されると、それ以降の変更は停止されます。データベースのマウントが解除されている間は、データベースもログ ファイルも変更されません。
CCR 環境でのデータベースのマウントの詳細については、「クラスタ連続レプリケーション環境でデータベースをマウントする方法」を参照してください。CCR 環境でのデータベースのマウント解除の詳細については、「クラスタ連続レプリケーション環境でデータベースのマウントを解除する方法」を参照してください。
ストレージ グループ コピーの整合性の検証
CCR を使用する場合は、データベース ファイルおよびトランザクション ログ ファイルに対して物理的な整合性チェックを実行することにより、定期的にパッシブ コピーの整合性を検証することをお勧めします。物理的な整合性チェックでは、トランザクション ログ ファイルおよびデータベース ファイルが破損しているかどうかを検査します。このチェックは、Exchange Server データベース ユーティリティ (Eseutil.exe) を使用して実行できます。Eseutil を使用して、トランザクション ログ ファイルおよびデータベース ファイルの物理的な破損をチェックする方法の詳細については、「Eseutil を使用してクラスタ連続レプリケーション コピーを確認する方法」を参照してください。
| 注 : |
|---|
| データベースに対して物理的な整合性チェックを実行する前に、ストレージ グループ コピーに対するレプリケーション処理を一時的に中断する必要があります。トランザクション ログの再生処理を中断するには、Exchange 管理シェルで Suspend-StorageGroupCopy コマンドレットを使用します。整合性チェックが完了したら、Resume-StorageGroupCopy コマンドレットを使用してトランザクション ログの再生処理を再開できます。 |
CCR 環境での破損からの回復
CCR を使用すると、スケジュールされた停止を開始して、運用ストレージ グループでの破損またはエラーから回復することができます。ログ ファイルが破損していない場合、回復によってデータが消失することはありません。ただし、ログ ファイルが使用できない場合、回復により可能なのは、ストレージ グループを、そのコピーが最後に受け取った破損していない変更内容と整合性がある時点まで戻すことだけです。また、その時点より前に消失または破損した変更データは存在できないという制約があります。
CCR 環境の破損またはエラーから回復する詳細については、以下のトピックを参照してください。
エラーまたは破損の発生後の CCR の復元
CCR では、エラーの後で自動的に回復する機能が提供されています。ただし、以下の例のように手動での回復が必要となる場合もあります。
- パッシブ コピー上でデータベース ファイルが破損している場合 データベースの破損が発生した後で CCR を復元する手順の詳細については、「データベースの破損が発生した後の復元の方法」を参照してください。
- パッシブ コピー上でデータベースまたはログ ボリュームにエラーが発生した場合 ボリュームのエラーが発生した後で CCR を復元する手順の詳細については、「ボリューム障害後の復元方法」を参照してください。
- データベースにエラーまたは相違が発生している場合 エラーの結果としてデータベースの相違が発生した場合は、CCR によって検出され、報告されます。通常この状態は、データベース コピーが利用可能になったときに、エラーの発生したデータベース コピーに自動マウントの基準で許容されるよりも多くの変更が存在する場合に発生します。データベースのエラーまたは相違が発生した後で CCR を復元する手順の詳細については、「障害または分岐の後に CCR 機能を復元する方法」を参照してください。
参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。