クラスタ連続レプリケーションの回復動作
適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
トピックの最終更新日: 2007-10-29
クラスタ連続レプリケーション (CCR) は、データと、データへのアクセスを提供するサービスの両方に完全な冗長性を提供します。完全な冗長性により、メールボックス データの共有コピーでは迅速な回復を行うことができない場合に、迅速な回復が可能になります。
CCR の回復動作は、2 種類の停止に分けることができます。
- スケジュールされた停止 スケジュールされた停止は管理者によって開始されます。スケジュールされた停止は、監視システムによって検出された障害から回復するとき、あるいはハードウェアの保守、ソフトウェアのインストール、またはソフトウェア更新プログラムのインストールなどの管理タスクを実行するときに利用できます。
- 計画されていないダウンタイム 計画されていないダウンタイムは、検出された障害に対する回復処理として、システムによって開始されます。計画されていないダウンタイムの検出、および計画されていないダウンタイムからの回復の開始は、Windows クラスタ サービスによって行われます。
次の表では、さまざまな障害の際に予期される回復処理について説明します。管理者が回復を開始する必要がある障害もあれば、Exchange クラスタ化ソリューションによって自動的に処理される障害もあります。
障害に対する回復処理
| 説明 | 処理 | コメント |
|---|---|---|
オペレーティング システムの停止エラー、オペレーティング システムのハング (応答停止) の検出、ノードの全面的な電源障害、プロセッサ チップ、マザーボード、またはバックプレーンの回復不能な障害、あるいはノードの全面的な通信障害 |
可能な場合はパッシブ ノードへの自動フェールオーバーを利用します。構成した時間内に回復が行われていない場合、管理者はデータの損失とは無関係に、強制的に自動マウントを行うこともできます。フェールオーバー後にマウントされたデータベースがなく、元のアクティブ ノードがオンラインに戻ってすべての記憶域が動作可能である場合、消失したログがコピーされ、データベースが自動的にマウントされます。 |
パッシブ ノードを使用できるようにするためには、障害後にクォーラムを確立できる必要があります。これは、残りのノードがファイル共有クォーラムにアクセスできる必要があることを意味します。または、クラスタ内の大多数のノードが動作可能で、相互に通信できる必要があります。 |
アクティブ サーバー全体のストレージ エラー |
ストレージ エラーは、監視システムを通じて報告されます。管理者は、記憶域を回復するか、パッシブ ノードに対してスケジュールされた停止を開始できます。 |
この障害は、すべてのデータベースの障害として報告されます。 |
データ センターの障害 |
プライマリ データ センターのアクティブ ノードに障害が発生すると、クラスタ化メールボックス サーバーは第 2 のデータ センター内のパッシブ ノードに自動的にフェールオーバーされます。 |
メール アクセスを継続して提供するためには、他の Exchange、ディレクトリ サービス、ネットワーク サービス、およびサーバーを回復する必要があります。メール データは数分以内に使用可能で最新の状態になります。 |
オペレーティング システム ドライブの障害 |
自動回復処理は行われません。オペレーティング システム障害が発生しない限り、Exchange では検出されません。根本的な原因ではなく、表面的な障害に基づいて検出されます。 |
オペレーティング システム ドライブの障害は、オペレーティング システム監視サービスによって報告され、オペレーティング システム障害を発生させる場合があります。 |
オペレーティング システム ドライブの容量不足 |
可能な場合はパッシブ ノードへの自動フェールオーバーを利用します。 |
この障害は、監視サービスを通して報告されます。自動回復が行われない、または行うことができない場合、このシナリオの回復処理については管理者が判断します。 |
クラスタのパブリック ネットワークの全面的な障害 |
自動回復処理は行われません。 |
パブリック ネットワークが失われた場合、IP アドレス リソースはエラー状態になります。パブリック ネットワークの問題が解決された後で、リソースをオンラインに戻すことができます。 |
クラスタ クォーラムの消失 |
クラスタ化メールボックス サーバーおよびクラスタ クォーラムがオフラインです。 |
このシナリオでは、クォーラムが形成できない場合はサービスが提供されません。 |
インフォメーション ストアの障害 |
インフォメーション ストアのリソースが自動的に再起動されます。再起動中にインフォメーション ストア リソースの障害が発生すると、フェールオーバーが発生します。 |
障害が繰り返し発生する場合、管理者は、クラスタ化メールボックス サーバーを手動でパッシブ ノードに移動して、オンラインにすることができます。 |
アプリケーション (バイナリ ファイル) ドライブの障害 |
自動回復処理は行われません。 |
通常、このシナリオでは別の障害が発生し、その障害が監視サービスを通して報告され、管理者によって回復処理が行われます。このシナリオの回復処理については、管理者が判断します。 |
アプリケーション (バイナリ ファイル) ドライブの容量不足 |
自動回復処理は行われません。 |
監視サービスを通してこのサービスに報告されます。このシナリオの回復処理については、管理者が判断します。 |
データベースやストレージ グループの完全な損失、またはデータベースの全面的な障害 |
影響を受けたデータベースの再マウントが自動的に試行されます。この試行が失敗した場合、データベースはエラー状態のままとなりますが、クラスタ化メールボックス サーバーのフェールオーバーは行われません。 |
ストレージ グループまたはデータベースが、ソフトウェアの障害または破損によってマウントを解除されたか、ハードウェアの障害のために失敗しました。たとえば、ストレージ グループは、ログ ディレクトリを使用できない場合はすべてのデータベースのマウントを強制的に解除します。管理者が修正処理を決定します。 |
ストレージ グループやデータベースの部分的な障害、使用できないデータの存在、またはデータベースの初期マウント エラー |
自動回復処理は行われません。 |
部分的な障害とは、多少の破損が報告されていても、破損のためにストレージ グループやデータベースのマウントが強制的に解除されなかった状況を指します。データベースが起動時にマウントされなかった場合、処理は行われず、監視機能によって障害が報告されます。この状態が検出されると、メールボックス サーバーによって、監視サービスで報告可能なイベントが生成されます。監視機能も、マウント解除されたデータベースを検出して報告します。 |
ストレージ グループの破損したログの検出 |
自動回復処理は行われません。コピーは破損状態になるので、再シードする必要があります。 |
監視機能によってこの状態が報告されます。 |
データベースまたはトランザクション ログ ドライブの空き容量の不足 |
自動回復処理は行われません。ストレージ グループのデータベースがマウント解除されます。 |
ドライブの空き領域が不足している状態が、監視システムによって報告されます。管理者が修正処理を決定します。 |
管理者は、計画されていないダウンタイムの障害回復についての構成を制御できます。スケジュールされた停止と計画されていないダウンタイムの詳細については、「スケジュールされた停止とスケジュールされていない停止」を参照してください。
参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。