クラスタ連続レプリケーション コピーをシードする方法
適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
トピックの最終更新日: 2007-10-24
シードは、現在のパッシブ ノードでデータベースのベースライン コピーを使用可能にするプロセスです。状況に応じて、シードを自動プロセスにしたり、管理者がシードを開始する手動プロセスにしたりすることができます。この手順は、シードが必要であると判断される状況で使用することができます。コピーするデータベースのサイズは、シード タスクの完了にかかる時間に直接関連します。
シードを行うには、次の条件を満たしている必要があります。
- クラスタ連続レプリケーション (CCR) 環境に新しいパッシブ ノードを導入し、運用ストレージ グループの最初のログ ファイルが使用できないとき
- 現在のパッシブ コピーに相違があり回復不能であるためにデータが失われてフェールオーバーが発生した後
- パッシブ コピーに対して再生できない破損したログ ファイルがシステムで検出されたとき
- いずれかのデータベース コピーに対するオフラインでのディスクの最適化が発生した後
- データベースのアクティブ コピーのページ除去が発生した後、パッシブ コピーに変更を反映する必要がある場合
- ストレージ グループのログ生成シーケンスがリセットされ、1 に戻った後
以下の方法を使用して、Microsoft Exchange Server 2007 のシードを実行できます。
- 自動シード 自動シードは、接続先にあるストレージ グループのデータベースのコピーを生成します。自動シードでは、移動元で log1 が使用可能であることが必要です。自動シードは、新しいサーバーの作成時、新しいストレージ グループおよびデータベースの作成時、またはバックアップされていないデータベース上にのみ実行します。
- Update-StorageGroupCopy コマンドレットを使用したシード Exchange 管理シェルで Update-StorageGroupCopy コマンドレットを使用すると、ストレージ グループのコピーをシードできます。
- オフライン データベースの手動によるコピー このプロセスによって、データベースはマウントを解除され、パッシブ ノード上の同じ場所にデータベース ファイルをコピーします。この方法を使用すると、データベースを解除する手順が必要になるためで、サービスが中断します。
.gif "note")
注 :一部のバックアップ アプリケーションでは、シード データベースのソースとしてバックアップを使用するための方法がサポートされる場合があります。パッシブ ノードへの復元はサポートされません。このオプションがサポートされる場合は、バックアップ アプリケーションによる明示的で完全なサポートが必要です。
Microsoft Exchange Server 2007 2007 Service Pack 1 (SP1) では、Update-StorageGroupCopy コマンドレットに、新しい DataHostNames というパラメータが含まれて拡張されています。DataHostNames パラメータは、シードまたは再シードに使用するネットワークの指定に使用されます。パラメータの値は、完全修飾ドメイン名 (FQDN) またはホスト名のいずれかから成る複数値の一覧です。これらの名前のいずれかで、アクティブ ノードを識別する必要があります。
Exchange 2007 SP1 では、Exchange 管理コンソールでストレージ グループのコピーの更新ウィザードを使用して (DataHostNames パラメータなしで) シードすることもできるようになりました。このウィザードは、パッシブ ノードの Exchange 管理コンソールからのみ使用可能です。
このトピックには 3 つの手順が含まれます。最初の手順では、Update-StorageGroupCopy コマンドレットを使用して、ストレージ グループ コピーをシードする方法を説明します。2 番目の手順では、Exchange 管理コンソールを使用して、CCR データベース フォルダへのオフライン コピーを行うためにデータベースのマウントを解除する方法について説明します。3 番目の手順では、ストレージ グループのコピーの更新ウィザードを使用する方法について説明します。
開始する前に
クラスタ化メールボックス サーバーがインストールされているコンピュータで以下の手順を実行するには、使用するアカウントに、Exchange サーバー管理者の役割および対象サーバーのローカルの Administrators グループが委任されている必要があります。Exchange 2007 を管理するために必要なアクセス許可、役割の委任、および権限の詳細については、「アクセス許可に関する考慮事項」を参照してください。
Update-StorageGroupCopy コマンドレットを使用したシードの操作は、アクティブなストレージ グループのボリュームに対する入出力 (I/O) 負荷の増大につながる可能性があります。結果として、クラスタのストレージ設計によっては、この方法がクライアント操作に影響し、クライアント アクセスを中断させる恐れがあります。クライアント アクセスへの潜在的な影響を最小限に抑えるために、可能な限り、Update-StorageGroupCopy コマンドレットを使用したシード操作はクライアントの動作の少ない期間にスケジュールすることをお勧めします。シードされていないパッシブ コピーによって生じる影響に加えて、遅延を考慮する必要があります。
アクティブ ノードから新しい CCR の対象を構成するときに、パッシブ ノード上にディレクトリとデータベース ファイルが存在しない場合には、シード操作により自動的にそれらが作成されます。データベースとログ ファイルの場所は、クラスタのサーバー間で同じである必要があります。ストレージが使用可能であり、データベースとログを十分に保存できる必要があります。
.gif "important") 重要 : |
|---|
| データベースまたはログ ファイルがパッシブ コピーの保存される場所に存在する場合、シード操作を開始する前にデータベースまたはログ ファイルを削除する必要があります。 |
| 重要 : |
|---|
| Update-StorageGroupCopy コマンドは、パッシブ ノードから実行する必要があります。 |
手順
Exchange 管理シェルを使用してパッシブ ノードをシードするには、次の操作を行います。
以下のコマンドを実行して、ストレージ グループのレプリケーションを中断します。
Suspend-StorageGroupCopy -Identity:<Server\StorageGroupName>パッシブ ノードからデータベース ファイル、すべてのログ ファイル、およびチェックポイント ファイルを削除します。構成されたディレクトリ (ログ ディレクトリ、システム ファイル ディレクトリ、データベース ファイルをホストしているディレクトリ) から *.log、*.jrs、*.chk, .edb ファイルを削除します。
以下のコマンドを実行して、パッシブ ノードにストレージ グループのコピーをシードします。
Update-StorageGroupCopy -Identity:<Server\StorageGroupName>注 :TargetPath パラメータは、データベースのパッシブ コピーに対して構成された場所とは異なるパスへのデータベースのシードに使用します。たとえば、各 CCR ノードがそれぞれ異なる物理的な場所に存在する場合、TargetPath パラメータを使用して、アクティブ ノードでローカルに更新を実行してから、コピーをネットワーク経由でパッシブ ノードに移動するためのデータ圧縮を行うコピー ユーティリティを使用します。Target Path パラメータを使用しない場合、パッシブ コピーが存在するコンピュータ上で Update-StorageGroupCopy コマンドレットを発行する必要があります。 注 :Update-StorageGroupCopy コマンド使用すると、ストレージ グループのコピーに対するレプリケーションが自動的に再開されます。Update-StorageGroupCopy コマンドでレプリケーションを自動的に再開しない場合は、ManualResume パラメータを設定してコマンドを実行してください。詳細については、「Update-StorageGroupCopy」を参照してください。Update-StorageGroupCopy コマンドの実行後にレプリケーションを手動で再開するには、以下のコマンドを実行してください。 Resume-StorageGroupCopy -Identity:<Server>\<StorageGroupName>注 :Update-StorageGroupCopy タスクの実行中にエラーが表示される場合は、「Update-StorageGroupCopy」に記載されているエラーの表を参照してください。 注 :シード操作に使用する冗長なネットワークを指定するには、次のコマンドを実行します。 Update-StorageGroupCopy -Identity:<Server\StorageGroupName> -DataHostNames:{Host1,Host2}Update-StorageGroupCopy コマンドが完了し、ストレージ グループのコピーが再開された後、Get-StorageGroupCopyStatus コマンドレットを使用して、レプリケーションが正しく機能していることを確認します。
重要 :実際にデータ フローが行われていない場合でも通常の処理が行われているように見えることがあるので、実際にデータ フローが行われていることを必ず確認してください。
Exchange 管理コンソールを使用して、オフライン データベース ファイルをコピーすることによってパッシブ ノードを手動でシードするには、次の操作を行います。
Exchange 管理コンソールを開きます。
[サーバーの構成] を拡張した後、[メールボックス] を選択します。
結果ウィンドウで、マウント解除するデータベースを含むメールボックス サーバーを選択します。
作業ウィンドウで、マウント解除するデータベースを右クリックし、[データベースのマウント解除] を選択します。
マウントが解除されたデータベースでレプリケーションを中断します。「クラスタ連続レプリケーション コピーでレプリケーションを中止する方法」に記載されている、レプリケーションを中断する手順に従ってください。
データベースのレプリケーションが中断されたら、運用データベース フォルダから CCR データベース フォルダにデータベース ファイル (.edb ファイル) をコピーします。
注 :運用データベース フォルダの場所は、[概要] ページまたは [プロパティ] ページのいずれかで参照できます。 運用データベース フォルダから CCR データベース フォルダにデータベース ファイルがコピーされた後で、マウントを解除されたデータベースを右クリックし、[データベースのマウント] を選択します。
注 :ファイルがコピーされたら、シードは完了です。運用データベースがマウントされると、クライアント アクセスが復元されます。 マウントが解除されている CCR データベースのレプリケーションを再開します。「クラスタ連続レプリケーション (CCR) コピーのレプリケーションを再開する方法」の、レプリケーションを再開する手順に従ってください。
注 :以上でシードは完了し、トランザクション ログのレプリケーションと再生が自動的に実行されます。
ストレージ グループのコピーの更新ウィザードを使用してパッシブ ノードをシードするには、次の操作を行います。
パッシブ ノードで Exchange 管理コンソールを開きます。
[サーバーの構成] を拡張した後、[メールボックス] を選択します。
結果ウィンドウで、更新するストレージ グループを含むメールボックス サーバーを選択します。
作業ウィンドウで、更新するストレージ グループを右クリックし、[ストレージ グループのコピーの更新] をクリックします。ストレージ グループのコピーの更新ウィザードが表示されます。
正しいストレージ グループが "ストレージ グループ名" フィールドに一覧表示されていることを確認します。間違ったストレージ グループが選択されている場合は [キャンセル] をクリックしてウィザードを終了させ、正しいストレージ グループを選択します。ストレージ グループのパッシブ コピーに、使用できないか、シード完了後のログ再生に必要な既存のログ ファイルがある場合、[対象のパスにあるすべての既存のログ ファイルを削除する] チェック ボックスをオンにします。続行するには、[次へ] をクリックします。
データベース コピーでパッシブ ノードのシードを行うには、[更新] をクリックします。
注 :更新処理中に、ストレージ グループのパッシブ コピーで見つかった古くなったチェックポイント ファイル、およびストレージ グループのパッシブ コピーで見つかった既存のデータベースの削除を求めるメッセージが表示されます。 シードの完了後、[終了] をクリックして、ウィザードを終了させます。
詳細情報
ここで説明した Exchange 管理シェル コマンドレットの詳細については、以下のトピックを参照してください。
CCR 環境の管理の詳細については、「クラスタ連続レプリケーションの管理」を参照してください。
参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。