ローカル連続レプリケーションの管理

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

トピックの最終更新日: 2007-08-20

Exchange 組織の日常的な管理タスクに加えて、ローカル連続レプリケーション (LCR) に固有のタスクもあります。一般に、LCR のための管理タスクには以下のものがあります。

• LCR のためのディスク格納域の構成とディスク ボリュームの管理。
• LCR の有効化と無効化。
• レプリケーション処理の監視。
• データベースのマウント、マウント解除、作成、および削除。
• ストレージ グループで LCR を有効にしている場合のストレージ グループ内の格納域またはデータベース ファイルの場所の移動。
• LCR が有効になっているストレージ グループまたはデータベースの状態と構成情報の表示。
• LCR データのアクティブ コピーとパッシブ コピーの状態の確認。
• レプリケーションと再生処理の管理。
• パッシブ コピーのアクティブ化。

ローカル連続レプリケーションのためのディスク格納域の構成

LCR には、特別に構成されたディスク格納域は必要ありません。実用的である限り、各コピーをお互いに分離することをお勧めします。LCR には、十分なパフォーマンスと格納域容量を提供する格納域が必要です。LCR が有効になったストレージ グループとデータベースの両方のコピーに同等のストレージ ソリューションを構成する必要があります。また、構成を完了させるためにストレージ ベンダにより提供された構成手順に従うことをお勧めします。

ディスク ボリュームの管理

LCR 環境の管理中は、Exchange サーバーに接続されたディスク ボリュームを管理することが必要になる場合があります。たとえば、保守やその他の理由で、ボリュームをシステムから一時的に切り離すことが必要になる場合があります。ストレージ グループのアクティブ コピーを含むディスク ボリュームに対して保守を実行する必要が生じた場合、ストレージ グループのアクティブ コピー内のデータベースをマウント解除する必要があります。ストレージ グループのパッシブ コピーを含むディスク ボリュームに対して保守を実行する必要が生じた場合、レプリケーションを停止して、そのボリュームに対するすべての入出力 (I/O) を停止する必要があります。ディスク ボリュームの管理の詳細については、「LCR コピー用ディスク管理処理の準備 (方法)」を参照してください。

ローカル連続レプリケーションの有効化

LCR を使用するには、まず、ストレージ グループで LCR を有効にします。このタスクは、Exchange 管理コンソールまたは Exchange 管理シェルを使用して実行できます。

注 :
ストレージ グループで LCR を有効にすると、ストレージ グループ内にデータベースの 2 番目のコピーが作成され、LCR コピー用に指定した場所で自動的に管理されます。

重要 :
LCR を有効にする前に、LCR コピーを格納するためのディスク領域が十分にあることを確認します。

LCR を使用するには、ストレージ グループで LCR を有効にする必要があります。既存のストレージ グループの LCR を有効にする方法の詳細については、「既存のストレージ グループのローカル連続レプリケーションを有効にする方法」を参照してください。LCR が有効になったストレージ グループを新しく作成する方法の詳細については、「新しいストレージ グループのローカル連続レプリケーションを有効にする方法」を参照してください。

ローカル連続レプリケーションの無効化

ストレージ グループの LCR の無効化は、Exchange 管理コンソールまたは Exchange 管理シェルを使用して行えます。LCR を無効にする方法の詳細については、「ローカル連続レプリケーションを無効にする方法」を参照してください。

重要 :
LCR コピーを含むストレージ グループを削除すると、LCR コピーおよび運用コピーが削除されます。

トランスポート収集に関する既定の構成の調整

トランスポート収集は、ハブ トランスポート サーバーの役割の機能で、予定されていない停止の後で最近配信されたメールを送信します。ハブ トランスポート サーバーは、次の場所のメールボックスに最近配信されたメールのキューを保持します。

• CCR 環境内のクラスタ化メールボックス サーバー内
• LCR が有効になっているストレージ グループ内

クラスタ連続レプリケーション (CCR) または LCR を使用する場合、トランスポート収集は常に有効にしておく必要があります。トランスポート収集は、ストレージ グループごとに使用できる記憶域の容量を設定し、メールをトランスポート収集内で保持する時間を設定することによって、組織全体で有効にすることができます。

Set-TransportConfig コマンドレットを使用すると、トランスポート収集の既定の構成設定を変更できます。この設定は、ストレージ グループのレベルで適用されます。

MaxDumpsterSizePerStorageGroup パラメータを構成することをお勧めします。このパラメータは、ストレージ グループごとにトランスポート収集キューの最大サイズを、送信できる最大メッセージ サイズの 1.5 倍のサイズまでで指定します。たとえば、メッセージの最大サイズが 10 MB の場合、MaxDumpsterSizePerStorageGroup パラメータは、15 MB の値に設定します。

また、MaxDumpsterTime パラメータを構成することもお勧めします。このパラメータは、電子メール メッセージがトランスポート収集キュー内で保持される期間を 7.00:00:00 (7 日間) までで指定します。MaxDumpsterSizePerStorageGroup で指定されたサイズに達すると、メッセージはトランスポート収集から削除されます。そうでない場合は、MaxDumpsterTime パラメータで指定された時間が経過したときに、メッセージがトランスポート収集から削除されます。これは、停止が延長されても電子メール メッセージを失うことのない、十分な時間です。

トランスポート収集機能を使用する場合、トランスポート収集キューをホストするには、ハブ トランスポート サーバー上に追加のディスク領域が必要です。必要な記憶域の容量は、MaxDumpsterSizePerStorageGroup の値と、CCR 環境内のすべてのクラスタ化メールボックス サーバー上にあるストレージ グループ、およびハブ トランスポート サーバーが含まれている Active Directory ディレクトリ サービス サイトの LCR が有効になっているすべてのストレージ グループの数を乗算した値にほぼ等しくなります。CCR 環境では、サイト内にあるすべてのハブ トランスポート サーバー上でトランスポート収集からの再配信要求は自動的に実行されます。LCR 環境では、サイト内にあるすべてのハブ トランスポート サーバーからの再配信要求は、Restore-StorageGroupCopy タスクの一部として発生します。

トランスポート収集を有効化して構成する方法の詳細については、「トランスポート収集を構成する方法」を参照してください。Restore-StorageGroupCopy コマンドレットの詳細については、「Restore-StorageGroupCopy」を参照してください。

レプリケーション処理の監視

データベースのパッシブ コピーは、最新の状態に保たれている場合にのみ役に立ちます。LCR では特別な監視は必要ありませんが、ログ ファイルが正しくレプリケートされていることを確認するために各ストレージ グループを定期的に監視することをお勧めします。Microsoft Operations Manager 2005 用 Microsoft Exchange Server 2007 管理パックには、次のような LCR 環境に関連するいくつかの重要な問題に対するアラートが含まれます。

• Microsoft Exchange Replication サービスが実行されていない。サービスを停止するとこのアラートを生成するイベントが繰り返し表示されなくなるため、この問題が解消されたかのように、関連付けられているアラートが表示されなくなることに注意してください。
• パッシブ コピーが失敗の状態にある。
• パッシブ コピーは正常な状態であるが、ログのコピーまたは再生が大幅に遅れている。

Exchange 2007 管理パックにより生成された上記のすべてのアラートについて、できるだけ早く調査および解決する必要があります。

Microsoft Operations Manager 2005 用 Exchange 2007 管理パックの別の使用方法として、Get-StorageGroupCopyStatus コマンドレットを実行するスクリプトを Exchange 管理シェルで定期的に実行する方法があります。Get-StorageGroupCopyStatus コマンドレットは、アクティブ コピーにより生成されたログの数を含めたキューの長さを示します。パフォーマンス上の理由により、キューの長さのパフォーマンス カウンタは Microsoft Exchange レプリケーション サービスで既知の情報のみを報告します。ごくまれに、この情報がアクティブ コピーの状態と一致しない場合があります。Get-StorageGroupCopyStatus コマンドレットの詳細については、後の「状態情報の表示」を参照してください。

データベースのマウント、マウント解除、作成、および削除

LCR 環境では、データベースのマウントまたはマウント解除が必要になる場合があります。ストレージ グループまたはデータベースの再構成または保守が必要になった場合は、作業が行われている間、両方と通信するサービスをブロックする必要があります。この作業が必要になるのは、再構成を実行する場合や、サーバーやデータベースに関する問題を修正する場合です。データベースのマウントが解除されると、それ以降の変更は停止されます。データベースのマウントが解除されている間は、データベースもログ ファイルも変更されません。

LCR が有効になったストレージ グループにデータベースを追加したくなる場合もあるでしょう。このプロセスは、追加パスを指定しなければならないという点以外は、スタンドアロン構成でデータベースを追加する場合に使用するプロセスとよく似ています。

LCR が有効になったストレージ グループからデータベースを削除したくなる場合もあるでしょう。このプロセスは、削除するデータベースのコピーがアクティブ コピーとパッシブ コピーとで 2 つあるという点以外は、スタンドアロン構成のデータベースを削除するために使用するプロセスとまったく同じです。LCR が有効になったストレージ グループからデータベースを削除する方法の詳細については、「ローカル連続レプリケーションが有効になっているストレージ グループからデータベースを削除する方法」を参照してください。

ストレージ グループとデータベース ファイルの場所の移動

LCR が有効になっているストレージ グループ内のデータベースの場所の変更には、Exchange 管理シェルおよび Exchange 管理コンソールの両方を使用できます。LCR 環境では、各コピーに 1 つずつ、2 つのデータベース ファイルがあります。両コピーの場所を個別に変更することも、まとめて変更することも可能です。

注 :
データベース ファイル名とファイル パスは、アクティブ コピーとパッシブ コピーで同じである必要があります。

ストレージ グループ ログおよびシステム ファイルの場所の再構成と LCR 環境でのデータベース ファイルの場所の再構成には、よく似た手順が使用されます。LCR が有効になっているストレージ グループでログ ファイルとシステム ファイルの場所を変更する方法の詳細については、「ローカル連続レプリケーション環境のストレージ グループを移動する方法」を参照してください。LCR 環境でのデータベース ファイルの場所を変更する方法の詳細については、「ローカル連続レプリケーション環境でデータベースを移動する方法」を参照してください。

重要 :
データベースをボリュームのルートに置くことはできません。

状態情報の表示

ストレージ グループの LCR を有効にした後は、Exchange 管理コンソールまたは Exchange 管理シェルを使用して、ストレージ グループおよびそのデータベースの LCR 固有の構成情報を表示することができます。

LCR の状態情報

Exchange 2007 は、LCR コピーについてさまざまな状態情報を公開します。次の表は、LCR が有効なストレージ グループで使用できる状態情報を示しています。状態情報を取得する方法の詳細については、「ローカル連続レプリケーション コピーの状態を表示する方法」を参照してください。次の表に、Get-StorageGroupCopyStatus Exchange 管理シェルのコマンドレットの完全な出力を表示した場合のプロパティの一覧を表示される順序で示します。

LCR が有効なストレージ グループで使用できる状態情報

SummaryCopyStatus、CopyQueueLength、ReplayQueueLength、および LastInspectedLogTime の値を調べると、LCR コピーが正常な状態にあるかどうかをすばやく評価できます。これらのプロパティは、LCR コピーが正常に機能しているかどうかと、LCR コピーがログのコピーと再生の両方において相対的に最新の状態にあるかどうかを示します。以下の条件が当てはまる場合は、問題の原因を特定して修正する必要があります。

• コピーが正常以外の状態になったまま長時間が経過している。
• コピー キューの長さが 5 を超えている。
• 再生キューの長さが 20 を超えている。
• 最後に検査されたログ時刻が現在の時間を示していない。これを引き起こす原因として考えられるのは、ストレージ グループに多くの変更が加えられていないか、Microsoft Exchange Replication Service が停止しているかの 2 つです。

再生キューの長さとコピー キューの長さの値は、パフォーマンス カウンタとして利用可能です。これらは、MSExchange Replication パフォーマンス オブジェクトの下にある、CopyQueueLength および ReplayQueueLength パフォーマンス カウンタです。LCR のパフォーマンス カウンタの監視の詳細については、「ローカル連続レプリケーションのパフォーマンス カウンタを表示する方法」を参照してください。

まれに、レプリケーションの状態によって、判断を誤りかねないような状況が生じることがあります。以下に、そのような状況を一覧で示します。

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

注 :
Exchange 2007 SP1 では、Test-ReplicationHealth という新しいコマンドレットを使用して、連続レプリケーションが有効なストレージ グループの稼働状態を検証することができます。Test-ReplicationHealth コマンドレットの詳細については、「Test-ReplicationHealth」および「連続レプリケーションの監視」の「Test-ReplicationHealth コマンドレット」を参照してください。

構成情報の表示

LCR が有効になっているストレージ グループとデータベースの構成情報は、Exchange 管理コンソールおよび Exchange 管理シェルを使用して表示できます。構成情報には、次のものがあります。

• ストレージ グループ   LCR トランザクション ログ ファイルと LCR システム ファイルの場所。
• データベース   LCR データベースのコピーの場所。

さらに、ストレージ グループまたはデータベースが LCR コピーを持つように構成されているかどうかも確認できます。LCR の構成設定を表示する方法の詳細については、「ローカル連続レプリケーションの構成設定を表示する方法」を参照してください。

パッシブ コピーの整合性の検証

LCR を使用する場合は、データベース ファイルおよびトランザクション ログ ファイルに対して物理的な整合性チェックを実行することにより、定期的にパッシブ コピーの整合性を検証することをお勧めします。物理的な整合性チェックでは、トランザクション ログ ファイルおよびデータベース ファイルが破損しているかどうかを検査します。このチェックは、Exchange Server データベース ユーティリティ ツール (Eseutil.exe) を使用して実行できます。Eseutil を使用して、トランザクション ログ ファイルおよびデータベース ファイルの物理的な破損をチェックする方法の詳細については、「Eseutil を使用してローカル連続レプリケーション コピーを確認する方法」を参照してください。

注 :
データベースに対して物理的な整合性チェックを実行する前に、ストレージ グループに対するすべてのレプリケーション処理を一時的に中断する必要があります。Exchange 管理シェルで Suspend-StorageGroupCopy コマンドレットを使用してレプリケーション処理を中断するか、または Exchange 管理コンソールを通じてレプリケーション処理を中断します。整合性チェックが完了したら、Resume-StorageGroupCopy コマンドレットを使用してトランザクション ログの再生処理を再開できます。検証は運用時間外に実行し、再生処理を中断する時間は可能な限り短くすることをお勧めします。これは、ストレージ グループのコピーを中断すると LCR コピーへのすべての更新が中断され、一部のコンテンツが障害に対して脆弱になるためです。

レプリケーションと再生の管理

LCR 環境でのログ ファイルのレプリケーションと再生の管理には、主に以下の作業が含まれます。

• ストレージ グループ コピーへのレプリケーションの中断
• ストレージ グループ コピーへのレプリケーションの再開

ストレージ グループ コピーとそのデータベースへの変更の中断と再開

トランザクション ログのレプリケーション処理の中断と再開を行う必要が生じる場合があります。トランザクション ログのレプリケーション (再生を含む) は、ストレージ グループ レベルで制御されます。ストレージ グループにはデータベースを 1 つしか格納できないため、レプリケーションは 1 つのデータベースに限定されます。トランザクション ログのレプリケーションは、Microsoft Exchange レプリケーション サービスが実行されており、ストレージ グループで LCR が有効になっており、アクティブ コピーとパッシブ コピーの両方が稼働している場合に発生します。アクティブ コピーとパッシブ コピーのいずれかが利用できなくなったら、レプリケーションを停止しなければなりません。さらに、シードなどの一部の管理作業を行うには、LCR が有効になっているストレージ グループのレプリケーションを中断する必要があります。パッシブ コピーのデータ ファイルへのすべてのアクセスを停止する必要がある場合は、レプリケーションを中断する必要があります。

パッシブ コピーの利用を制御する必要が生じることもあります。この作業が必要になるのは、再構成を実行する場合や、サーバーやデータベースに関する問題を修正する場合です。パッシブ コピーの物理的な整合性チェックを実行するには、ログ再生の中断も必要です。データベース コピーの更新を制御する必要がある場合は、ストレージ グループのコピーのためにレプリケーションを中断する必要があります。パッシブ コピーのログを操作する場合は、レプリケーションも中断する必要がある可能性があります。ストレージ グループにはデータベースを 1 つしか格納できないため、再生動作に影響する操作はストレージ グループ レベルで制御されます。

ストレージ グループまたはデータベースの場所を変更するときには、すべてのレプリケーション処理を中断することをお勧めします。

LCR コピーに対する変更のレプリケーションを中断する方法の詳細については、「ローカル連続レプリケーションが有効になっているストレージ グループのレプリケーションを停止する方法」を参照してください。LCR コピーに対する変更のレプリケーションを再開する方法の詳細については、「ローカル連続レプリケーションが有効になっているストレージ グループのレプリケーションを再開する方法」を参照してください。パッシブ コピーのトランザクション ログ ファイルおよびデータベース ファイルに整合性チェックを実行する方法の詳細については、「Eseutil を使用してローカル連続レプリケーション コピーを確認する方法」を参照してください。

パッシブ コピーのアクティブ化

LCR は、ストレージ グループのパッシブ コピーをアクティブ化することにより、ストレージ グループのアクティブ コピーの破損からの回復を可能にします。ストレージ グループのアクティブ コピー内のトランザクション ログが破損していない場合は、データの損失は一切発生しません。ストレージ グループのアクティブ コピーのトランザクション ログが使用できない場合、回復しても、そのパッシブ コピーが最後に受け取った破損していない変更内容と整合性がある時点までしかストレージ グループを戻せません。また、その時点より前に消失または破損した運用トランザクション ログ ファイルは存在できないという制約があります。

運用ストレージ グループの破損から最も簡単に回復するには、NTFS ファイル システム ボリュームのマウント ポイントを使用して LCR のコピーを保存します。ボリューム マウント ポイントを使用することで、別の物理ディスク上のフォルダ内に対象のパーティションを組み込んだり、マウントしたりすることができます。ボリューム マウント ポイントは、Exchange 2007 などのプログラムに対して透過的です。

LCR コピーの一部であるトランザクション ログ ファイルまたはデータベース ファイルの破損は、再生操作で生成されるエラーまたは整合性チェックによって検出することができます。修正処理を行う必要がある場合、その処理は破損の性質によって異なります。

• 既に再生済みのログ ファイルで破損が発生した場合は、破損したログ ファイルを無視しても問題ありません。ただし、ファイル システムに基づいて LCR コピーのバックアップを行っている場合は、まず、再生済みのログ ファイルをすべて削除する必要があります。
• アクティブ コピーのまだ再生されていないログ ファイルに破損が発生した場合は、LCR ストレージ グループを再シードする必要があります。Exchange は、破損を検出すると、ログ ファイルをもう一度コピーしようとします。自動コピーで破損が解決しなかった場合は、ストレージ グループを再シードする必要があります。さらに、ソース トランザクション ログとデータベース ファイルの整合性を確認することをお勧めします。Exchange データ ファイルを検証するには、ファイルをオフラインにし、ユーザーがアクセスできないようにする必要があります。
• データベースが破損している場合は、ストレージ グループを再シードする必要があります。

データベースのパッシブ コピーをアクティブ化する方法の詳細な手順については、「データベースのパッシブ コピーに切り替える方法」を参照してください。

破損時のレプリケーション状態の評価

データベース コピーに障害または破損が発生した後は、パッシブ コピーを使用して直ちに運用を続行するかどうかを評価する必要があります。LCR は、この決定を支援するための以下の重要情報を提供します。

• エラー発生時のコピーの状態
• エラー発生時の再生キューおよびコピー キュー
• エラー発生時点で検査された最後のログ時刻

情報は、Get-StorageGroupCopyStatus コマンドレットを使用して取得できます。この情報を取得する方法の詳細については、「ローカル連続レプリケーション コピーの状態を表示する方法」を参照してください。

注 :
ログが最後に検査された時刻は、アクティブ コピーの最後に行われた変更に関する情報を提供します。この情報は、Microsoft Exchange Replication Service の停止時にキューの長さが正確でないために Microsoft Exchange Replication Service が開始しなかった場合に、発生したエラーを検出するのに役立ちます。

コピー キューの長さには、エラー発生時のアクティブ コピーについて取得可能な最も優れた情報が含まれます。この情報とエラーの発生したデータベースの回復時間の評価に基づいて、利用可能なコピーをマウントするかどうかを以下のように決定する必要があります。

• 再生キューの長さが大きい場合、それは回復に時間がかかることを意味しますが、重大なデータ損失が発生するという指標ではありません。
• コピー キューの長さが大きい場合、それはかなりの数のログが失われていることを意味します。データベースがマウントされている場合は、ほぼ最後にログがコピーされたときのじょうたいにまで復元されます (Get-StorageGroupCopyStatus コマンドレットにより提供されます)。
• 検査された最後のログ時刻がエラーが発生した時刻よりかなり前の場合、Microsoft Exchange Replication Service が停止しており、その他のキュー情報が正確ではないと考えられます。

注 :
アクティブ コピーの現在の状態は最新の状態と同期が取れていないため、遅延と通信エラーが原因で、コピー キューの長さが不正確になる可能性があります。一般に、不正確さはエラーの発生前後の 1 分間程度の間の処理に限定されます。

注 :
エラーの発生したデータベースは、パッシブ コピーのシードに使用できません。

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