スケジュールされた停止とスケジュールされていない停止
適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
トピックの最終更新日: 2007-10-29
スケジュールされた停止とスケジュールされていない停止は、クラスタ連続レプリケーション (CCR) 環境における 2 つの停止の形式です。スケジュールされた停止は、障害から回復したり、保守操作を実行したりするために、管理者によって明示的に開始されます。スケジュールされていない停止は、サービス、データ、またはサービスとデータの両方が使用できなくなる予期せぬ停止を表します。CCR は、スケジュールされた停止とスケジュールされていない停止の両方に対処するように設計されています。
スケジュールされた停止
CCR では、クラスタ化メールボックス サーバー (CMS) を長時間にわたって停止させることなく、特定のノードの長時間にわたるシステム停止をスケジュールすることができます。CCR のスケジュールされた停止機能は、アクティブ ノード上のすべてのログ データがパッシブ ノードに正常にコピーされるように設計されています。その結果、レプリケーションが非同期に発生するにもかかわらず、スケジュールされた停止は常に損失なしで行われます。障害や、その結果発生するフェールオーバーのため、パッシブ ノードがオンラインになったときに、ごく最近のログ データが利用できなくなる可能性があります。
CCR 環境では、一度に 1 つのノードしかオフラインにすることができません。複数のノードをオフラインにすると、サービスが中断します。任意の時点で、ファイル共有監視付きのマジョリティ ノード セット (MNS) クォーラムのファイル共有をホストしているコンピュータ、またはフェールオーバー クラスタのパッシブ ノードを、ハードウェアやソフトウェアの保守、更新、および修復のためオフラインにすることができます。ノードをダウンさせる前に、ノードがアクティブであるかどうか、またはリソースをホストしているかどうかを必ず確認することをお勧めします。リソースをホストしているかどうかは、クラスタ アドミニストレータを使用して識別できます。ノードの状態を調べるには、Exchange 管理シェルで Get-ClusteredMailboxServerStatus コマンドレットを実行します。CMS の状態の表示の詳細については、「クラスタ化メールボックス サーバーの状態を表示する方法」を参照してください。
.gif "note") 注 : |
|---|
| CCR のスケジュールされた停止は、Windows Server のシャットダウン プロセスと統合されていません。CMS を別のノードに移動してから、アクティブ ノードをシャットダウンする必要があります。CMS をあるノードから別のノードに移動する方法の詳細については、「CCR 環境のクラスタ化メールボックス サーバーを移動する方法」を参照してください。 |
管理タスク
スケジュールされた停止は、障害から回復したり、保守操作を実行したりするために、管理者によって明示的に開始されます。スケジュールされた停止により、システムは CMS をアクティブ ノードからパッシブ ノードに移動し (これによってパッシブ ノードが新しくアクティブ ノードになります)、レプリケートされたデータベースとストレージ グループをマウントすることができます。マウントされたデータベースは、以降のレプリケーションのための以降のすべての更新のソースになります。2 つのコピーは、レプリケーションの役割、つまりデータベースの変更を生成する側と、データベースの変更を受信して適用する側を入れ替えます。
CCR では非同期レプリケーションを使用するため、アクティブな CMS をクラスタ内のあるノードから別のノードへ移行するには、クラスタとレプリケーション サポートの間の調整が必要です。CCR は、この調整を実装します。管理者は、Exchange 管理シェルで Move-ClusteredMailboxServer コマンドレットを使用して、スケジュールされた停止を開始します。
| 注 : |
|---|
| この操作を実行すると、少しの間サービスが中断します。また、CMS 上のすべてのストレージ グループのすべてのバックアップは停止されます。 |
Move-ClusteredMailboxServer コマンドレットは、パッシブ ノードが有効かつ正常なコピーを保持していることを確認します。さらに、そのコピーが比較的最近のものであることを確認します。コピーが比較的最近のものではない場合、レプリケーションが完了するまで、停止が延長される可能性があります。これらのチェックが正常に終了した場合、移行が開始されます。移動中に障害が発生しなかった場合、選択したノードで CMS が実行されているときにタスクは完了し、すべてのデータベースがマウントされます。この処理中に、移行を妨げたり、すべてのデータベースが自動的にマウントされるかどうかに影響する障害が発生する可能性があります。そのような障害が発生した場合は、スケジュールされていない停止の動作が実行されます。
ある種の状況下では、部分的に障害が発生したサーバーを回復するために、スケジュールされた停止が使用されます。例として、サーバーのデータベースまたはログ ファイルが破損している場合があります。この場合、レプリケーション システムを通してログを送信するロジックにより、Move-ClusteredMailboxServer コマンドレットがブロックされます。このシナリオを管理するための簡単なオプションがあります。管理者は、問題のあるデータベースをマウント解除し、マウント解除したデータベースに関連付けられているログをコピーしつつ、すべてのログがコピーできない場合でも失敗しないオプションを使用して、Move-ClusteredMailboxServer コマンドを実行します。その結果、たとえ破損しているストレージ グループでも、Move-ClusteredMailboxServer コマンドレットによって回復を容易に完了することができます。
Move-ClusteredMailboxServer コマンドレットでは、移動を開始する理由を記録できます。この理由は、イベント ログに出力されます。このコマンドでは、管理者が CMS をホストするノードを指定する必要もあります。これにより、既に適切にホストされている CMS を誤って移動することがなくなります。
Cluster.exe コマンド ライン管理インターフェイスと、クラスタ アドミニストレータ グラフィカル ユーザー インターフェイス (GUI) は、いずれもクラスタ化 CMS を移動する機能を備えています。これらの方法を使用すると、レプリケーション フラッシュ ロジックが開始されます。ただし、以下の理由により、これらの方法は使用しないことをお勧めします。
- これらの方法では、パッシブ コピーの状態は検証されません。したがって、これらの方法を使用すると、ノードが必要な処理を実行してデータベースをマウント可能にする間に、停止が長時間に及ぶ可能性があります。
- これらの方法では、レプリケーションが破損状態で行われるため、データベースが無期限にオフラインになることがあります。
スケジュールされた停止後のレプリケーション処理の復元
アクティブ ノードのスケジュールされた停止後に CCR 環境を復元するための処理は、ノードを再起動することです。レプリケーションは、システム起動時に自動的に開始されます。2 つの状況を検討する必要があります。
- スケジュールされた停止が完全に成功し、スケジュールされた停止に関連する移行中に障害が発生せず、すべてのデータベースが自動的にオンラインになっている。この場合、管理者はスケジュールされた停止を、両方のノードのストレージ グループとデータベースが整合状態であることを確認できるような方法で実行しています。その結果、ノードは起動した後に直ちにレプリケーションを続行できます。ログの再生によって、コピーを最新の状態にすることができます。特別な操作は必要ありません。
- スケジュールされた停止が一部のみ成功したか、スケジュールされた停止の前にデータベースの一部が破損していた。この状況では、データベースをマウントする前にレプリケーション元のすべてのログがレプリケーション先で利用できることを、スケジュールされた停止によって確認できていません。通常、スケジュールされた停止の前またはスケジュールされた停止処理後の障害の結果としてこの状況が発生します。このため、レプリケーション元およびレプリケーション先のデータベースは一貫していません。場合によっては、CCR は不一致から自動的に回復できることがあります。その場合は、レプリケーションが開始され、使用可能なすべてのログが処理されます。レプリケーションが自動的に回復できない場合、コピーは破損しているとマークされ、問題を示すイベントが生成されます。ストレージが使用可能だと仮定すると、主要な回復処理はコピーを再シードすることです。これらの問題を修正する手順の詳細については、「クラスタ連続レプリケーション コピーをシードする方法」を参照してください。
スケジュールされていない停止
スケジュールされていない停止は、ある種の障害に対するシステムの自動的な応答として発生します。CCR の自動回復は、可用性が改善され、ほとんどの環境で自動回復が望まれるという高い確証がある障害が中心になっています。
スケジュールされていない停止により、システムはパッシブ ノードのメールボックス サーバーをアクティブにし、それによってパッシブ ノードをアクティブにして、レプリケートされたデータベースとストレージ グループをマウントすることができます。マウントされたデータベースは、以降のレプリケーションのための以降のすべての更新のソースになります。2 つのコピーは、レプリケーションの役割、つまりデータベースの変更を生成する側と、データベースの変更を受信して適用する側を入れ替えます。
CCR では非同期レプリケーションを使用するため、スケジュールされていない停止では、多少のデータ損失が発生します。少なくとも、アクティブ サーバーによって書き込まれている最中のログは、回復処理で使用できません。CCR では、フェールオーバー動作の管理用の制御機能を提供し、影響を受ける可能性があるデータの集まりの再生利用を支援する機能を提供することにより、この問題に対処しています。
フェールオーバーが発生すると、CCR は常に残りのパッシブ ノードでメールボックス サーバーをアクティブにします。システム制御は、この現在アクティブなノードにデータベースがマウントされるかどうかに関連します。CCR は、データベースがマウントされるかどうかを決める管理用の制御機能を提供します。既定の設定は、最良の可用性です。この設定では、システムは以前にアクティブだった運用データベースと同期されているすべてのデータベースを自動的にマウントします。最良の可用性では、2 つのコピー間の不一致において、より多くの変化量が許容されます。良好な可用性では、新しいログの生成にかかった時間内に、最後に生成されたログがレプリケートされた場合に、データベースがオンラインになります。ロスレスでは、データの損失が発生しないことが確認されない限り、コピーがオンラインにならないことが保証されます。ロスレスを使用した場合、自動回復は、元のサーバーが再び運用可能な状態になり、すべてのログ データが使用可能で破損していない場合に限り発生します。
| 注 : |
|---|
| ロスレス設定を使用すると、停止が長引く可能性があります。管理者は、ロスレス設定を使用し、データベースをマウントするかどうかを明示的に判断することができます。ロスレス設定は、ほとんど障害発生時の長時間の停止につながります。 |
1 つ以上のデータベースが、設定によって自動的にマウントされない状態の場合でも、管理者は使用可能な内容を含むコピーをマウントすることを明示的に判断することができます。管理者は、コピーの状態を確認してから、2 つのコマンドを実行する必要があります。最初のコマンドは、レプリケーション エンジンに対し、このコピーをレプリケーション元 (変更元) にする、つまりコピーをマウント可能にする必要があることを伝えます。2 つ目のコマンドは、データベースをマウントします。
CCR が有効な場合の破損または障害からの回復の詳細については、「クラスタ連続レプリケーションの管理」を参照してください。
管理用の制御機能
スケジュールされていない停止があった場合の動作を制御するため、管理用の制御機能が提供されます。CCR は、スケジュールされていない停止の回復動作を制御するために使用できるメールボックス サーバーの属性を提供します。この AutoDatabaseMountDial 属性には、ロスレス、良好な可用性、および最良の可用性の 3 つの値のいずれかを指定できます。
ロスレス ロスレスでは、どのログも消失しません。この属性をロスレスに設定すると、ほとんどの状況下で、システムは障害が発生したノードがオンラインに戻るのを待機してから、データベースをマウントします。さらに、障害が発生したシステムは、すべてのログがアクセス可能で、破損していない状態で回復する必要があります。障害が発生すると、パッシブ ノードがアクティブになり、Microsoft Exchange Information Store サービスがオンラインになります。インフォメーション ストアは、データを損失せずにデータベースをマウントできるか調べます。それが可能であれば、データベースがマウントされます。可能でなければ、システムはログのコピーを定期的に試みます。ログがそのままの状態でサーバーが回復する場合、この試みは最終的に成功し、データベースはマウントされます。ログが損傷した状態でサーバーが回復する場合、残りのログは使用できなくなり、影響を受けるデータベースはマウントされません。
注 :フェールオーバーが完了した後、いつでも管理者は介入し、以前のパッシブ ノードで使用可能なデータベースとログを使用してマウントを実行することを判断できます。このタスクは、2 つの手順からなる簡単なプロセスを使用して行われます。通常、介入を決定する管理者は、元のサーバーを運用可能な状態にするために必要な時間の分析に基づいて、決定を下します。障害発生時の 2 つのノード間でのレプリケーションの一貫性と、サーバーへアクセスすることについてのクライアントの緊急度は、この分析の要素の一部です。 良好な可用性 良好な可用性では、3 つのログが消失します。良好な可用性は、レプリケーションが正常に機能し、ログが生成されている速度でレプリケートしているときに、完全な自動回復を提供します。
最良の可用性 最良の可用性では、6 つのログが消失します。これは既定の設定です。最良の可用性は、良好な可用性と同じように機能しますが、レプリケーションで若干の遅れが生じているときに自動回復を可能にします。したがって、フェールオーバー後の新しいアクティブ ノードは、以前のアクティブ ノードの状態よりも若干遅れている場合があります。これにより、修正のために完全な再シードが必要になるデータベースの相違が発生する可能性が高まります。
停止の管理動作の詳細については、「クラスタ連続レプリケーションのフェールオーバーとマウントの設定をチューニングする方法」を参照してください。
参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。