クラスタ連続レプリケーションに関する問題のトラブルシューティングを行う方法

  • [アーティクル]

 

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

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

ここでは、クラスタ連続レプリケーション (CCR) に関連する問題のトラブルシューティングについて説明します。CCR に関する問題のトラブルシューティングに役立つツールの詳細については、「高可用性展開の問題のトラブルシューティング ツール」を参照してください。

このトピックの手順は、CCR 環境における次の問題に対応しています。

  • Get-StorageGroupCopyStatus を実行すると、データベースが "Failed" であり、シードされていないと報告される。
  • Get-StorageGroupCopyStatus を実行すると、データベースが "Failed" だと報告される。FailedMessage 値は、ストレージ グループ コピーに相違が発生したことを示しています。
  • Get-StorageGroupCopyStatus を実行すると、データベースが "Failed" だと報告される。FailedMessage 値は、エラーの原因について具体的な情報を提供します。
  • 警告またはパフォーマンス カウンタに、あるいは Get-StorageGroupCopyStatus を実行すると、ストレージ グループ コピーのコピー キューまたは再生キューがバックアップされていると表示される。
  • Get-StorageGroupCopyStatus を実行すると、LastInspectedLogTime として古い時間が報告される。
  • フェールオーバーや Move-ClusteredMailboxServer は成功するが、データベースがマウントされない。
  • フェールオーバーは成功するが、自動的にマウントされないデータベースや手動でマウントされないデータベースがある。または、Get-ClusteredMailboxServerStatus を実行すると、1 つ以上のデータベースにエラーがあると報告される。
  • CCR 環境での起動時にデータベースがマウントされない。
  • Microsoft Exchange Replication Service でディレクトリが見つからないことを通知する MSExchangeRepl イベント 2073 がログに記録される。
  • レプリケーションに関する問題のため、スケジュールされた停止が Move-ClusteredMailboxServer によって開始されない。
  • 1 つ以上のストレージ グループでのフェールオーバー後に、レプリケーションによって再同期が行われない。
  • シード処理が失敗している。

上記以外のエラーが発生した場合は、両方のノードでイベント ログを調査して原因を特定し、ログの情報を利用して必要な回復処理を判断してください。障害が発生した時間が明確になると、他のイベント ログによって問題をより理解できる場合があります。この情報が不十分な場合は、問題が発生した時間を知ることによって、cluster.log 内で分析を絞り込み、確認する範囲を狭めることができます。クラスタ ログでは、クラスタ管理システムによって実行された処理のトレース レベルの情報が提供されます。

開始する前に

この手順を実行するには、使用するアカウントに Exchange Server 管理者の役割および対象サーバーのローカルの Administrators グループが委任されている必要があります。Microsoft Exchange Server 2007 を管理するために必要なアクセス許可、役割の委任、および権限の詳細については、「アクセス許可に関する考慮事項」を参照してください。

手順

Get-StorageGroupCopyStatus を実行すると、データベースが "Failed" であり、シードされていないと報告される。

  • 考えられる原因   構成の問題が発生しているか、またはレプリケーション コピーに有効なベースライン データベースがありません。この問題は、パッシブ ノードが追加されたときにストレージ グループ コピーのシードが行われていないことが原因で発生する可能性があります。

  • 解決方法

    • コピー元の記憶域が正しく構成され、使用できる状態にあることを確認します。エラーが見つかった場合は、ストレージ グループを中断してから再開することによって、コピーの確認を新しく開始できます。
    • ストレージ グループおよびデータベースのパスが、パッシブ サーバー上の記憶域を基準にして正しく構成されていることを確認します。このためには、Exchange 管理コンソールで Get-StorageGroup コマンドレットを使用します。
    • ストレージ グループ コピーをシードするには、Update-StorageGroupCopy コマンドレットを使用します。

Get-StorageGroupCopyStatus を実行すると、データベースが "Failed" だと報告される。FailedMessage 値は、ストレージ グループ コピーに相違が発生したことを示しています。

  • 考えられる原因   フェールオーバーが発生し、完全な再シードを行わないと、前にアクティブであったサーバー上のデータベースを、現在アクティブなデータベースと再同期できないほど多くのログが失われた場合に発生します。この状況は、LCR では発生しません。

  • 解決方法   Update-StorageGroupCopy コマンドレットを使用して、ストレージ グループ コピーをシードします。

Get-StorageGroupCopyStatus を実行すると、データベースが "Failed" だと報告される。FailedMessage 値は、エラーの原因について具体的な情報を提供します。

  • 考えられる原因   ストレージ グループ コピーが失敗したと判断される場合は、さまざまな原因が考えられます。例としては、上記の、シードが行われてない場合とストレージ グループ コピーに相違が生じた場合の 2 つが挙げられます。FailedMessage 値は、検出された問題を具体的に示します。

  • 解決方法   Get-StorageGroupCopyStatus コマンドレットを実行して、検出された具体的な問題を示す完全な FailedMessage 値を取得します。FailedMessage 値によって提供された情報を分析し、報告された状態を解決します。報告された状態がログの破損または不足である場合は、正しい世代番号を持つ、破損していないログを探します。正しいログが見つからない場合は、Update-StorageGroupCopy コマンドレットを使用して再シードを行います。メッセージが移動元のログが使用できないことを示している場合は、移動元のログ ディレクトリにある共有を削除し、そのノードでレプリケーション サービスを再起動します。

警告またはパフォーマンス カウンタに、あるいは Get-StorageGroupCopyStatus を実行すると、ストレージ グループ コピーのコピー キューまたは再生キューがバックアップされていると表示される。

  • 考えられる原因   ログのコピーまたは再生のバックログに、回復処理での問題または一時的な状況が示されることがあります。一時的な状況は、以前にオフラインになっていたパッシブ ノードがオンラインになったときや、ストレージ グループ コピーが長期間中断された後で最近再開された場合に発生します。パッシブ ノードで Microsoft Exchange Replication Service を停止すると、ノード上のすべてのストレージ グループ コピーを中断した場合と同様の影響があります。状況が一時的なものではない場合、問題の原因としては次のいずれかが考えられます。

    • 構成に問題がある。
    • ストレージ グループ コピーが中断されている。
    • 再生サービスが停止している。
    • 記憶域に障害が発生しているか、または記憶域がオフラインになっている。
    • パッシブ ノードがオフラインになっている。

  • 解決方法   実際に問題が発生しているのか、または一時的な状況なのかを判断します。

    • Microsoft Exchange Replication Service が両方のノードで実行中かどうかを判断します。このためには、サービス スナップインを使用します。どちらかのノードでサービスが停止している場合は、再起動する必要があります。
    • Exchange 管理シェル コマンドレットの Get-StorageGroupCopyStatus を fl (formatted list: 書式設定された一覧) オプションを指定して実行し、パッシブ コピーが中断されているかどうかを判断します。中断されている場合は、パッシブ コピーのファイルが間違いなく存在することを確認し、Resume-StorageGroupCopy コマンドレットを使用してストレージ グループ コピーを再開します。
    • Get-StorageGroupCopyStatus コマンドレットを fl オプションを指定して実行し、コピーが "Healthy" であるかどうかを判断します。コピーが "Failed" の場合は、状態フィールドの一覧を確認し、必要な修正操作を判断します。
    • レプリケーション パフォーマンス カウンタを数分間監視して、処理が進行しているかどうかを判断します。特に、再生世代番号と検査世代番号に注目します。コピー キューの長さは増大し続けているが、再生キューの長さが短かったり減少したりしている場合は、アクティブ サーバーのネットワーク ファイル共有またはアクティブ サーバー自体に問題がある可能性があります。"net share" コマンド、Windows エクスプローラ、またはコンピュータの管理スナップインを使用して、アクティブなストレージ グループ コピーのログ ディレクトリにネットワーク ファイル共有が定義されていることを確認します。ストレージ グループの GUID を特定するには、Exchange 管理シェルで fl オプションを指定して Get-StorageGroup コマンドレットを使用します。

Get-StorageGroupCopyStatus を実行すると、LastInspectedLogTime として古い時間が報告される。

  • 考えられる原因   この問題の原因としては、次の 3 つが考えられます。

    • アクティブなストレージ グループ コピーのデータベースのマウントが解除されている。
    • アクティブなストレージ グループ コピーはマウントされているが、長期間変更されていない。このため、アクティブなストレージ グループ コピーによってログが生成されていない。
    • パッシブ ノード上で Microsoft Exchange Replication Service が実行されていない。

  • 解決方法   以下の操作を実行して、この 3 つの原因のうち、どれに該当しているかを判断します。

    • Exchange 管理コンソールを使用して、または Exchange 管理シェルで Get-StorageGroupStatus コマンドレットを実行して、データベースのマウントが解除されているかどうかを判断します。マウントが解除されている場合は、データベースをマウントし、LastInspectedLogTime が変わる前にデータベースに対する変更 (データベース内の動作など) を行う必要があります。
    • パッシブ モード上で Microsoft Exchange Replication Service が実行されていることを確認します。サービスが停止している場合は、再起動する必要があります。
    • データベースがマウントされていることを確認したら、データベースによってログが生成されているかどうかを確認します。アクティブなデータベースのログ ディレクトリを調べ、世代番号が最も大きいログ ファイルを特定します。そのログのタイムスタンプを調べます。この値は LastInspectedLogTime に一致している必要があります。

フェールオーバーや Move-ClusteredMailboxServer は成功するが、データベースがマウントされない。

  • 考えられる原因   この問題は通常、クラスタ サービス アカウントがデータベースをマウントするために必要な権限を持っていないために発生します。または、フェールオーバーによって、自動マウントの構成設定で許容されている数より多くのログが失われています。フェールオーバーの場合の一般的な原因としては他に、エラーの発生時にパッシブ コピーが正常な状態ではなかったことが挙げられます。

  • 解決方法   クラスタ サービス アカウントに関するアクセス許可の問題は、通常はセットアップ中に発生します。セットアップの最後にデータベースがマウントされない場合は、通常、クラスタ サービス アカウントに適切なアクセス許可が付与されていないことを示しています。これを解決するには、クラスタ サービス アカウントに適切なアクセス許可を付与した後、正しい順序でシャットダウンを実行し、クラスタ全体を再起動します。それには、次の操作を行います。(1) クラスタ化メールボックス サーバーをオフラインにします。(2) パッシブ ノードをシャットダウンします。(3) アクティブ ノードをシャットダウンします。(4) アクティブ ノードを起動します。(5) パッシブ ノードを起動します。(6) クラスタ化メールボックス サーバーをオンラインにします。

    • イベント ログを確認し、フェールオーバーによって自動マウントの構成設定で許容されている数より多くのログが失われたかどうかを判断します。ストレージ グループ コピーのデータベースの状態を判断したら、Exchange 管理シェルで Restore-StorageGroupCopy コマンドレットを実行して、明示的にストレージ グループ コピーをマウントすることができます。最後に、Get-StorageGroupCopy コマンドレットを実行し、SummaryCopyStatus 値を確認して、前にアクティブであったコピーに、マウントを妨げている問題が存在するかどうかを確認します。問題がある場合は、イベント ログを確認して問題の原因を特定し、問題を解決するための手順を実行します。

フェールオーバーは成功するが、自動的にマウントされないデータベースや手動でマウントされないデータベースがある。または、Get-ClusteredMailboxServerStatus を実行すると、1 つ以上のデータベースにエラーがあると報告される。

  • 考えられる原因   最新のフェールオーバーによって、自動マウントの構成設定で許容されている数より多くのログが失われています。フェールオーバーの場合の一般的な原因としては他に、エラーの発生時にパッシブ コピーが正常な状態ではなかったことが挙げられます。

    note注 :
    データベースは、スケジュールされた停止やスケジュールされていない停止の間、一時的に失敗やオフラインの状態になることがあります。これは一時的な状態であり、レプリケーション サービスが使用可能なログの最終的なコピーを作成しようとしているときに発生します。

  • 解決方法   イベント ログを確認して、データベースをマウントできなかった理由を判断します。データベースは、ログまたはデータベース ファイルの破損のためにマウントできない場合があります。イベントがこの状況を示している場合は、アクティブ サーバーを他のノードに移動して、データベースへのアクセスを復元します。イベント ログを確認すると、データベースでエラーが発生したかどうかを判断できます。ストレージ グループ コピーのデータベースの状態を判断したら、Exchange 管理シェルで Restore-StorageGroupCopy コマンドレットを実行して、明示的にストレージ グループ コピーをマウントすることができます。次に、Get-StorageGroupCopyStatus コマンドレットを実行し、SummaryCopyStatus 値を確認して、前にアクティブであったコピーに、マウントを妨げている問題が存在するかどうかを確認します。状態に、ストレージ グループ コピーがアクティブ化するには古すぎることが示される場合は、エラーが発生したノードがサービスに復帰し、より多くのログが使用可能になったときにデータベースを復元できます。ログは自動的にコピーされるため、操作は必要ありません。

CCR 環境での起動時にデータベースがマウントされない。

  • 考えられる原因   データベースのマウント エラーは、管理者による明示的な操作の結果である可能性があります。データベースのマウントが明示的に解除され、クラスタ化メールボックス サーバーがオフライン状態になった場合、次の起動時にデータベースはオンライン状態になりません。また、他に、フェールオーバー中に許容される数より多くのログが失われたことも原因として考えられます。

  • 解決方法   Exchange 管理シェルで Get-ClusteredMailboxServerStatus コマンドレットを実行すると、ノードでストアが機能していることを確認できます。Exchange 管理コンソールまたは Exchange 管理シェルを使用して、影響を受けたデータベース コピーのマウント操作を試みます。データベース コピーのマウントの詳細については、「クラスタ連続レプリケーション環境でデータベースをマウントする方法」を参照してください。マウント操作後にイベント ログを確認し、エラーが報告されたかどうかを調べます。

Microsoft Exchange Replication Service で指定されたディレクトリが見つからないことを通知するクラスタ イベント MSExchangeRepl 2073 がログ出力される。

  • 考えられる原因   このエラー イベントは、Microsoft Exchange Replication Service がイベントで指定されているディレクトリを作成できなかったことを示します。Microsoft Exchange Replication Service は、必要とする複数のディレクトリが存在しない場合は、それらを作成しようとします。これらのディレクトリには、レプリケーション元ログ ファイルのディレクトリ パス、レプリケーション先ログ ファイルのディレクトリ パス、レプリケーション先システム ファイルのディレクトリ パス、およびログ ファイル検査用のパスがあります。

    アクセス許可の問題、ハードウェアの障害、または構成エラーのために、Microsoft Exchange Replication Service が指定されたディレクトリを作成できない場合があります。

  • 解決方法   イベントによって返されるエラー コードを調べます。ディレクトリの場所が使用可能であること、およびその場所にアクセスできることを確認します。ファイル システムのアクセス許可を確認します。記憶域が正しく構成されていること、およびハードウェアが正しく動作していることを確認します。

レプリケーションに関する問題のため、スケジュールされた停止が Move-ClusteredMailboxServer によって開始されない。

  • 考えられる原因   Exchange 管理シェルの Move-ClusteredMailboxServer コマンドレットには、すべてのストレージ グループ コピーでレプリケーションが完全に正常ではない場合に、パッシブ ノードに対するスケジュールされた停止を行わないようにする検証チェックの機能が含まれています。この動作によって、スケジュールされた停止が、適切でない時間まで延長されないようになっています。

  • 解決方法   問題がある特定のストレージ グループを識別し、問題を修正します。Move-ClusteredMailboxServer コマンドレットからのエラー メッセージを参考にして、問題のあるストレージ グループ コピーを識別します。移動を行い、検証チェックを無視する場合は、エラーが発生したストレージ グループ コピーのデータベースのみ、マウントが解除されていることを確認します。移動操作をやり直し、-IgnoreDismounted パラメータを使用します。IgnoreDismounted パラメータは、マウントが解除されているストレージ グループを、レプリケーションの状態確認の目的では無視することを示します。

1 つ以上のストレージ グループでのフェールオーバー後に、レプリケーションによって再同期が行われない。

  • 考えられる原因   Get-StorageGroupCopyStatus コマンドレットによって返されるエラー メッセージは、データベースに相違が発生していることを示しています。この状況は、フェールオーバーの前に古いアクティブ サーバーで十分なログがレプリケートされていなかった場合に、フェールオーバーが原因で発生します。

  • 解決方法   Exchange 管理シェルで Update-StorageGroupCopy コマンドレットを使用して、データベースを再シードします。

シード処理が失敗している。

  • 考えられる原因   アクティブ サーバー上でバックアップが進行中であるか、または通信に問題があります。

  • 解決方法   影響を受けるストレージ グループ コピーまたはデータベースのバックアップが進行中でないことを確認します。アクティブ ノードがオンラインになっていることを確認します。

詳細情報

ここで説明した Exchange 管理シェル コマンドレットの詳細については、以下のトピックを参照してください。

ローカル連続レプリケーションのトラブルシューティングの詳細については、「ローカル連続レプリケーションに関する問題のトラブルシューティングを行う方法」を参照してください。

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