発行 : 2003 年 1 月

概要
この資料の目的は、 クラスタ障害の事例を詳しく説明し、Microsoft Windows Server 2003 がそれらの事例に効果的に対処する方法の概説することです。 この資料では、 有効なバックアップ セーブセットがある場合の回復オプション、 およびバックアップ セーブセットも ASR と互換性のあるセーブセットも存在しない場合の回復オプションについて説明します。 また、クラスタを完全にバックアップするための推奨手順についても説明します。

トピック

 システムのバックアップを保持しているユーザー
 システムのバックアップを保持していないユーザー
 クラスタのバックアップに関する推奨事例

システムのバックアップを保持しているユーザー

MicrosoftWindows Server 2003 には、 可能なバックアップ方法が 2 種類あります。 クラスタの構成を含む Authoritative System Restore (ASR) (これをシステム状態のバックアップと呼びます) と純粋なローカル バックアップ (これをローカル バックアップと呼びます) です。 Authoritative Restore を行うには、 システム状態のバックアップが必要であることに注意してください。 あるノードで Authoritative Restore を実行する場合、 他のクラスタ ノードでは非 Authoritative Restore を行うことをお勧めします。

クラスタ ノードを起動できない

この場合、クォーラム ディスクは機能しており、 データもすべて損傷していないと仮定します。

クラスタ内のあるノードを起動できない
クラスタ内の他のノードは予想どおりに稼働しています。

推奨手順
非 Authoritative Restore を使用します。 これはシステム状態のバックアップまたはローカル バックアップのどちらでも機能します。

これによって、 損傷を受けたノード上のクラスタ データベースが回復し、 その後、影響を受けたノードをクラスタに再び参加させることができます。 この場合、クラスタ内の他のノードから、 クラスタ データベースの最新のコピーがダウンロードされます。

クラスタ内のすべてのノードを起動できない
クラスタ内で起動できるノードがありません。

推奨手順
1 つのノード上で非 Authoritative Restore を使用します。 クォーラム ディスクが損傷していないと仮定すれば、 そのノードは、 クォーラム ディスク上の状態を使用して、 クラスタを形成できます。 クラスタを形成できない場合は、 そのノード上で Authoritative Restore (これにはシステム状態のバックアップが必要です) を試してください。

他のすべてのノードに対して、非 Authoritative Restore を使用します。

すべてのノードが正常であるが、クォーラム ディスクが機能しない

クラスタ ノードは起動しますが、 クォーラム リソースがオンラインになっていないため、 どのノードでもクラスタ サービスを開始できません。 イベント ログのエントリに、 クォーラム ディスクをオンラインにできなかったことが記されています。

推奨手順
ドライブ自体が故障している場合は、 クォーラム ディスクを取り替えます。 物理ドライブが故障していない場合は、 クォーラム ディスクを再フォーマットします。 Authoritative Restore が存在する場合には、 それを使用してノードを回復します。

または

–fixquorum フラグを使用してクラスタ サービスを開始し (fixquorum は、 オンラインにできなかった破損したクォーラム リソースを使用してクラスタ サービスを開始できますが、 実際にはデータを修正しないことに注意してください)、 代替のクォーラム リソースを選択します (他のディスクがない場合には、 ローカル クォーラムを使用できます)。 新しいクォーラムを設定することにより、 そのクォーラム上に新しいクォーラム ログ ファイルが作成されますが、 古いクォーラムが使用できないので、レジストリ チェックポイント ファイルは回復されません。

この手順に役立てるために、Reskit ツールの "ClusterRecovery" が入手可能です。

チェックポイント ファイルの問題に関しては、 「チェックポイント ファイルが存在しないか、壊れている」の手順に従います。

クラスタ ノードの 1 つでクラスタ データベースが壊れている

ノードがクラスタに参加できず、 クラスタ ログ (既定では %windir%\cluster\cluster.log) のエントリに壊れているハイブが記されていることが分かります。

推奨手順
このノード上で非 Authoritative Restore を行い、そのノードをクラスタに参加させます。

または

クォーラム ディスクから最新のチェックポイント ファイル (chkXXX.tmp) をコピーし、 影響を受けたノードの %windir%\cluster\clusdb ファイルを上書きし、サービスを再開します。

または

稼働しているクラスタ ノードのサービスを停止します。 RegEdit を使用して、 クラスタ ハイブをアンロードします。

%windir%\cluster\clusdb ファイルを、 稼働しているノードから、影響を受けたノードの %windir%\cluster\clusdb にコピーします。 そして、すべてのノードでクラスタ サービスを再開します。

すべてのノードが正常に稼働しているが、クォーラム データベースが壊れている

この場合、クラスタを形成できるノードがなく、 イベント ログのエントリには壊れているクォーラム ログが問題点として記されています。

推奨手順
–resetquorumlogfile スイッチを使用して、クラスタ サービスを起動します。 すべてのリソースが正常に起動され、 構成に関して問題がなければ、何もする必要はありません。 クォーラムをリセットすることにより、 新しいクォーラム ログ ファイルがクォーラム ディスク上に作成されますが、 古いクォーラムを使用できないので、 レジストリ チェックポイント ファイルは回復されません。

チェックポイント ファイルの問題に関しては、 「チェックポイント ファイルが存在しないか、壊れている」の手順に従います。

失敗した場合は、1 つのノードで Authoritative Restore を使用して、 クラスタ サービスを再開し、 クラスタを形成します。 他のノードには非 Authoritative Restore を使用します。

チェックポイント ファイルが存在しないか、壊れている

レジストリ チェックポイント ファイルが見つからないか、 または壊れているので読み込めない場合、 オンラインになったとき、レジストリのリソースには最新の情報が存在しない可能性があります。 ただし、 影響度はリソースによって異なり、 リソースがオンラインにならない場合もあります。 また場合によっては、 構成の変更が失われることがあります。 チェックポイント ファイルが存在しない場合は、 クラスタ サービスはイベントをイベント ログに追加しません。 問題が発生していると思われる場合は、 クラスタ ログを参照する必要があります。

推奨手順
リソースがオンラインにならない場合、 リソース キット ツールの "ClusterRecovery" を使用して、 リソース チェックポイントを再作成します。

注意
オンラインにならないリソースのチェックポイント ファイルのみを回復してください。

それでも問題が解決しない場合は、 クラスタ ノードで Authoritative Restore を使用して、 クラスタ サービスを再開し、クラスタを形成します。 他のノードには非 Authoritative Restore を使用します。

クラスタ ディスクが壊れているか、または機能しない

このディスクに依存するリソースが、オンラインになりません。 ディスクがオンラインにならないか、 ディスク上のデータが壊れています。 この場合、 ディスクを交換する必要がある場合と、 交換する必要がない場合があります。

ディスク自体は壊れておらず、オンラインになる

推奨手順
データをディスクに回復します。

ディスクが壊れている

推奨手順
ディスクを交換し、1 つのノードで非 Authoritative Restore を使用します。 データをディスクに回復します。

または

既存の物理ディスク リソースを、 システム状態の復元を行わずに新しいディスクに交換できる、"ClusterRecovery" というツールを含むリソース キットを使用してください。 物理ディスクがオンラインになったら、 任意のデータを回復できます。

システムのバックアップを保持していないユーザー

この場合、 バックアップを使用しないで、 ある種の障害事例を解決する手順をお勧めします。 このソリューションは、明白な理由で、すべての事例では完了しない可能性があります。

複数のクラスタ ノード上で 1 つのシステムが壊れている

この場合、 クォーラム ディスクは機能しており、 データもすべて損傷していないと仮定します。

クラスタ内のノードが起動しない
他のクラスタ ノードは予想どおりに稼働しています。

推奨手順
そのノードを取り外して、代替を見つけます。

新しいノードをクラスタに参加させます。

クラスタ内のすべてのノードが機能しない

推奨手順
クラスタを最初から再構築する必要があります。

すべてのノードが正常であるが、クォーラム ディスクが機能しない

推奨手順–fixquorum フラグを使用してクラスタ サービスを開始し (fixquorum は、 オンラインにできなかった破損したクォーラム リソースを使用してクラスタ サービスを開始できますが、 実際にはデータを修正しないことに注意してください)、 代替のクォーラム リソースを選択します (他のディスクがない場合には、ローカル クォーラムを使用できます)。 新しいクォーラムを設定することにより、 そのクォーラム上に新しいクォーラム ログ ファイルが作成されますが、 古いクォーラムは使用できないので、 レジストリ チェックポイント ファイルは回復されません。

この手順に役立てるために、Reskit ツールの "ClusterRecovery" が入手可能です。

チェックポイント ファイルの問題に関しては、「チェックポイント ファイルが存在しないか、壊れている」の手順に従います。

クラスタ ノードのクラスタ データベースが壊れている

推奨手順
クォーラム ディスクから最新のチェックポイント ファイル (chkXXX.tmp) をコピーし、 影響を受けたノードの %windir%\cluster\clusdb ファイルを上書きし、サービスを再開します。

または

他のノードのサービスを停止します。 RegEdit を使用して、クラスタ ハイブをアンロードします。

%windir%\cluster\clusdb ファイルを、 クラスタで稼働しているノードから、 影響を受けたノードの %windir%\cluster\clusdb にコピーし、 すべてのノードでクラスタ サービスを再開します。

すべてのノードが正常に稼働していたが、クォーラム データベースが壊れた

推奨手順
–resetquorumlogfile スイッチを使用して、クラスタ サービスを開始します。 すべてのリソースが正常に起動され、 構成に関して問題なければ、 何もする必要はありません。 クォーラムをリセットすることにより、 新しいクォーラム ログ ファイルがクォーラム ディスク上に作成されますが、 古いクォーラムを使用できないので、 レジストリ チェックポイント ファイルは回復されません。

チェックポイント ファイルの問題に関しては、 「チェックポイント ファイルが存在しないか、壊れている」の手順に従います。

チェックポイント ファイルが存在しないか、壊れている

レジストリ チェックポイント ファイルが見つからないか、 または壊れているために読み込めない場合、 オンラインになったとき、レジストリのリソースには最新の情報が存在しない可能性があります。 ただし、 影響の度合いはリソースによって異なり、 リソースはオンラインにならない場合があります。 また場合によっては、 構成の変更が失われることがあります。 チェックポイント ファイルが存在しない場合は、 クラスタ サービスはイベントをイベント ログに追加しません。 問題が発生していると思われる場合は、 クラスタ ログを参照する必要があります。

推奨手順
リソースがオンラインにならない場合、 リソース キット ツールの "ClusterRecovery" を使用して、 リソース チェックポイントを再作成します。

注意
オンラインにならないリソースのチェックポイント ファイルのみを回復してください。

クラスタ ディスクが壊れているかまたは機能しない

推奨手順
ディスクのマウントを強制的に解除した場合、ディスクをオンラインにするためには、chkdsk を実行する必要があります。 ディスクがオンラインになる際に、 クラスタ サービスが chkdsk を自動的に実行します。 Windows Server 2003 では、chkdsk ログが保持されるので、 ディスクの状態や、 どのような問題が見つかったかを確認できます。 ディスク上のアプリケーション データが壊れたり、 または削除されたがバックアップが存在しない場合、 データを回復する方法はありません。 データを再生成する、またはアプリケーションを再構築する必要があります。 サーバー クラスタにはユーザー データの保護および冗長機能はありません。 冗長性のあるハードウェア (ミラー化したディスクまたは RAID ディスク) を使用するとともに、 頻繁にデータのバックアップを取る必要があります。

クラスタのバックアップに関する推奨事例

ここでは、一貫性のあるクラスタのバックアップを行うための推奨手順を概説します。

クラスタの構成に大幅な変更を加える前後に、 バックアップを取ることをお勧めします。 以下の手順すべてを一緒に実行してください。

1. ASR に対応したバックアップ機能を使用して、 各ノードのシステム状態を定期的にバックアップします。 クラスタ ディスクに関する適切なディスク情報を記録するために、 ノード上でクラスタ サービスが稼働している必要があります。

   これにより、基本的にノードのシステム状態のデータがバックアップされます。 すべての共有ディスク上のデータをバックアップすることはできませんが、 ローカルにホストされているデータだけはバックアップできます。

   回復操作を行うためには、 バックアップ ファイルがローカルに存在する必要があります。 または、PXE ブートを使用することにより回復操作を行います。 ネットワーク経由で ASR を行うことができます。 ASR の間に "ディスクの保守" を行う場合、 コンピュータを再起動してから ASR プロセスを再起動する必要があります。 再起動に関するメッセージは、ASR 操作を再起動する必要があると警告しません。 同梱されていないドライバを ASR の間にロードすることは、 バックアップによりサポートされています。 ただし、HCL に記載されているドライバまたはデバイスのみです。

2. ノードに個別にホストされているクラスタ ディスクをすべてバックアップします (所有しているディスクのみをバックアップできます)。

   バックアップしたすべてのクラスタ ディスクをネットワークの共有リソースに保存しておくと、 管理が容易になります。 それらのバックアップは完全なバックアップ セットである必要はありません。 既存のバックアップを追加することによってそのバックアップが壊れる場合は、 ノードごとに独立したバックアップとして保管することにより、 すべてを失う危険を減らすことができます。 バックアップのインフラストラクチャを使用する WINS、DHCP、他のサービスも完全にバックアップされるように、 それらのバックアップにはシステム状態とシステム ディスクも含める必要があります。 システム状態/システム ディスク/クォーラム デバイスのバックアップ セットは入手可能ですが、 ASR のフロッピー ディスクをそのバックアップ セットと稼働させるためには、 手作業で更新する必要があります。 または、ASR の実行後、 クラスタ ディスク バックアップ セットからシステム状態/システム ディスクを回復できます。

3. アプリケーションをバックアップするには、アプリケーション固有のバックアップの指示に従います。

このドキュメントに記載されている情報は、 このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。 変化する市場状況に対応する必要があるため、 このドキュメントは、 記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。 また、発行以降に発表される情報の正確性に関して、 マイクロソフトはいかなる保証もいたしません。

このドキュメントに記載された内容は情報提供のみを目的としており、 明示または黙示に関わらず、 これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

お客様ご自身の責任において、 適用されるすべての著作権関連法規に従ったご使用を願います。 このドキュメントのいかなる部分も、 米国 Microsoft Corporation の書面による許諾を受けることなく、 その目的を問わず、どのような形態であっても、 複製または譲渡、あるいは検索システムに格納または公開することは禁じられています。 ここでいう形態とは、複写や記録など、 電子的な、または物理的なすべての手段を含みます。 ただしこれは、著作権法上のお客様の権利を制限するものではありません。

マイクロソフトは、このドキュメントに記載されている内容に関し、 特許、特許申請、商標、著作権、 またはその他の無体財産権を有する場合があります。 別途マイクロソフトのライセンス契約上に明示の規定のない限り、 このドキュメントはこれらの特許、商標、著作権、 またはその他の無体財産権に関する権利をお客様に許諾するものではありません。

© 2002. Microsoft Corporation. All rights reserved. Microsoft、Windows、および Windows NT は米国 Microsoft Corporation の米国またはその他の国における登録商標または商標です。

このドキュメントに記載されている会社名、製品名には、各社の商標のものもあります。