クラスター サービスのスタートアップ オプション
この記事では、クラスター サービスを開始するためのスタートアップ パラメーターとして使用できる使用可能なすべてのスイッチの一覧を示します。
適用対象: Windows Server 2012 R2
元の KB 番号: 258078
概要
これは、クラスター サービスを開始するためのスタートアップ パラメーターとして使用できる使用可能なすべてのスイッチの一覧です。
これを行うには、サービスのプロパティに移動し、[開始パラメーター] ボックスに適切なスイッチを配置し、[開始] をクリックします。
コマンド ラインからクラスター サービスを開始するときにスイッチを使用することもできます。 例:
net start clussvc.exe / switch
注:
Microsoft Windows 2000 Server 以前のバージョンのスイッチの前にダッシュ (-) を含めます。
デバッグ スイッチには、特別なスタートアップ パラメーターがあります。 正しい使用方法については、この記事の後半の 「デバッグ 」セクションを参照してください。
Windows Server 2003 には、各スイッチの省略形が含まれています。 これにより、クラスター サービスのスタートアップ スイッチの使用が簡略化されます。 たとえば、スイッチまたはスイッチを使用してサービスを/FixQuorum
/FQ
開始できます。
有効なオプション スイッチは次のとおりです。
スイッチ | 機能 | Windows 2003 の略語 |
---|---|---|
FixQuorum | クォーラム デバイスをマウントせず、クォーラム ログがオフになっています。 | Fq |
NoQuorumLogging | クォーラム ログ記録がオフになっています。 | Nq |
デバッグ | クラスター サービスの開始時にイベントを表示します。 特別な構文については、この記事の後半の「デバッグ」セクションを参照してください。 | |
LogLevel N | デバッグ モードのログ レベルを設定します。 | |
DebugResMon | クラスター サービスは、デバッガーが開始時にすべての Resource Monitor プロセスにアタッチされるのを待ちます。 | 博士 |
Windows 2000 以降のスイッチには、次のものが含まれます。
スイッチ | 機能 | Windows 2003 の略語 |
---|---|---|
ResetQuorumLog | クォーラム ログ ファイルとチェックポイント ファイルを動的に再作成します (この機能は Microsoft Windows NT 4.0 では自動です)。 | Rq |
NoRepEvtLogging | イベント ログ エントリのレプリケーションはありません。 |
Windows Server 2003 以降のスイッチには、次のものが含まれます。
スイッチ | 機能 | Windows 2003 の略語 |
---|---|---|
ForceQuorum または <N1,N2,...> | ノード リスト N1、N2 などを使用して、マジョリティ ノード セットを強制します。 (マジョリティ ノード セット クォーラムにのみ適用されます)。 | FO |
NoGroupInfoEvtLogging | オンラインとオフラインのグループに関連するイベント ログにイベントをログに記録しないでください。 | Ng |
スイッチの説明
一部のスイッチの説明を次に示します。
デバッグ
関数: クラスター ログには、クラスター サービスを診断してエラーを開始する場合に役立つ情報が含まれていない可能性があります。 これは、Cluster.logが開始される前にクラスター サービスが失敗する可能性があるためです。 このスイッチを使用してクラスター サービスを開始すると、クラスター サービスの初期化が表示され、これらの初期発生の問題を特定するのに役立ちます。
要件: このスイッチは、一時的な診断目的でのみ使用します。 サービス アカウントのログオン エラー、または別のシステム関連エラーが原因でクラスター サービスの起動に失敗した場合、サービスを実行できない可能性があります。 その結果、cluster.log ファイルが作成されない可能性があります。 このメソッドは、Service Control Manager によって指定された通常の環境の外部でサービスを実行します。 このスイッチを使用するには、管理者権限でローカルにログオンし、コマンド プロンプトからコマンドを開始する必要があります。 デバッグ スイッチは、通常の使用や任意の長さの時間には使用しないでください。 サービスは、オプション セットを使用して効率的に実行されません。
使用シナリオ: このスイッチは、クラスター サービスの起動に失敗した場合にのみ使用する必要があります。 このスイッチは、クラスター サービスの起動を試みると、その操作が画面に表示されます。 このスイッチは、コマンド プロンプトからサービスを開始する場合にのみ使用でき、クラスター サービスがインストールされているフォルダーに存在する必要があります。 既定では、%SystemRoot%\Cluster です。 これは、net start コマンドでサービスを開始するために使用しない唯一のスイッチでもあります。
操作: コマンド プロンプトを開き、%SystemRoot%\cluster フォルダーに変更し、次のように clussvc /debug [loglevel#] "
入力します。
ここで、loglevel# は次のいずれかです。
# | 説明 |
---|---|
0 | ログ記録は行われません。 |
1 | エラーのみがログに記録されます。 |
2 | エラーと警告がログに記録されます。 |
3 | イベント ログに書き込まれていないイベントを含むすべてのイベントがログに記録されます。 |
または、デバッグ スイッチを使用するときに set コマンドを使用してクラスター ログ レベルを制御することもできます。 コマンド プロンプトから、次の set clusterloglevel= x を入力します。 ここで、x は前の表に示した値の 1 つです。
クラスター サービスは、cluster.logに表示されるのと同様の出力をウィンドウに送信します。 または、次のコマンド構文を使用して、この情報をファイルにキャプチャすることもできます。
clussvc /debug > c:\debug.log
クラスター サービスが正しく実行されたら、Ctrl キーを押しながら C キーを押してサービスを停止します。
注:
ClusterLogLevel 環境変数を使用して、デバッグ スイッチを使用するときに出力レベルを制御できます。
FixQuorum
関数: クォーラム デバイスに問題があるにもかかわらず、クラスター サービスを起動できます。 サービスの開始後にオンラインになるリソースは、クラスター IP アドレスとクラスター名だけです。 クラスター管理者を開き、他のリソースを手動でオンラインにすることができます。
要件: このスイッチは、通常の操作中ではなく、非常に一時的な診断モードでのみ使用する必要があります。 このスイッチを使用して起動するノードは 1 つだけであり、このスイッチを使用して起動したノードに 2 つ目のノードを参加させる必要はありません。 通常、このスイッチは単独で使用されます。
使用シナリオ: クォーラム リソースの障害が原因でクラスター サービスを正常な方法で起動できない場合、ユーザーはこのモードでクラスター サービスを起動し、エラーの診断を試みることができます。
操作: クラスター サービスの起動後、クォーラム リソースを含むすべてのリソースはオフラインのままです。 その後、ユーザーは手動でクォーラム リソースをオンラインにして、クラスター ログ エントリと新しいイベント ログ エントリを監視し、クォーラム リソースに関する問題の診断を試みることができます。 構文は 次のとおりです。 net start clussvc /fixquorum
ResetQuorumLog
関数: クォーラム ログとチェックポイント ファイルが見つからない場合、または破損している場合は、ローカル ノードの %SystemRoot%\Cluster\CLUSDB レジストリ ハイブの情報に基づいてファイルを作成するために使用できます。 クォーラム ログ ファイルが適切な順序で検出された場合、このスイッチは無効です。
要件: 通常、このスイッチを使用して起動されるノードは 1 つだけで、このスイッチは単独で使用されます。 新しいクォーラム ログ ファイルを作成するには、古くなっている可能性のある情報を使用した結果を理解している経験豊富なユーザーのみが使用する必要があります。
使用シナリオ: このスイッチは、クォーラム ログ (Quolog.log) が見つからないか破損しているために、クラスター サービスが Windows 2000 以降のコンピューターで起動に失敗し、ファイルがChkxxx.tmpされた場合にのみ使用する必要があります。 Windows NT 4.0 は、これらのファイルが存在しない場合に自動的に再作成されます。 この機能は、クラスター サービスの開始をより詳細に制御するために、Windows 2000 で追加されました。
注:
クラスターで Windows 2000 Service Pack 4 (SP4) が実行されていて、修正プログラム 872970 が以前にインストールされている場合は、 /resetquorumlog
不要になります。 既定の動作では、古いログ ファイルが見つからないか破損している場合、起動時に新しいログ ファイルを作成します。
操作: クラスター サービスは、ファイル %systemroot%\Cluster\CLUSDB を使用して、現在読み込まれているクラスター ハイブの情報を使用してクォーラム ログ ファイルが見つからないか破損していることが判明した場合に、クォーラム ログ ファイルの自動リセットを実行します。 構文は次のようになります。
net start clussvc /resetquorumlog
DebugResMon
関数: リソース モニター プロセスをデバッグするのに役立ちます。そのため、リソース モニターによって読み込まれるリソース ダイナミック リンク ライブラリ (DLL) をデバッグできます。 任意の標準の Windows ベースのデバッガーを使用できます。
要件: クラスター サービスがコマンド プロンプトから開始され、デバッグ スイッチを使用する場合にのみ使用できます。 クラスター サービスをサービスとして実行するときに使用できる同等のレジストリ設定はありません。 デバッガーは、起動時にリソース モニターにアタッチするために使用できる必要があります。 通常、このスイッチは単独で使用されます。
使用シナリオ: 開発者はこのスイッチを使用して、リソース モニター プロセスとそのカスタム リソース DLL をデバッグできます。 このオプションは、リソース DLL のバグによって、クラスター サービスによって起動された直後にリソース モニター プロセスが予期せず終了し、ユーザーがリソース モニター プロセスにデバッガーを手動でアタッチできるようになる前に、非常に便利です。
操作: リソース モニター プロセスが開始される直前に、クラスター サービス プロセスはメッセージ (デバッガーが resmon プロセス X に接続するのを待機しています) で待機します。ここで 、X はリソース モニター プロセスのプロセス ID (PID) です。 クラスター サービスは、このサービスによって作成されたすべてのリソース モニター プロセスを待機します。 ユーザーがリソース モニター プロセスにデバッガーをアタッチし、リソース モニター プロセスが起動すると、クラスター サービスは初期化を続行します。
NoRepEvtLogging
関数: norepevtlogging スイッチは、イベント ログに記録されたイベントのレプリケーションを防止します。 このスイッチは、イベント ログに既に記録されているイベントを除外することで、コマンド ウィンドウに表示される情報の量を減らすのに役立ちます。 イベント ログ レプリケーションは、Windows 2000 で追加された機能です。
使用シナリオ: このスイッチは、イベント ログのレプリケーションを防ぐために使用されます。 多数のイベント ログ エントリがある場合、クラスター サービスによってこれらのエントリがレプリケートされ、cluster.logにログが記録されます。 これにより、cluster.logがすばやくラップされる可能性があります。 スイッチを使用してクラスター サービスを開始し、イベント ログに記録されていないイベントをローカル ファイルDebugnorep.logに記録することもできます。 構文は次のようになります。
clussvc /debug /norepevtlogging > c:\debugnorep.log\
操作: コンピューター管理コンソールからクラスター サービスを開始するときに、norepevtlogging コマンドを開始パラメーターとして設定できます。
コマンド ライン構文は次のとおりです。
net start clussvc /norepevtlogging
このコマンドは、このスイッチで開始されたノードがその情報を他のノードにレプリケートすることを防ぎますが、正常に開始された他のノードから引き続き情報を受け取ります。
NoQuorumLogging
関数: クォーラム ディスクに対するクラスター レジストリの変更のログ記録をすべてオフにします。 レジストリ チェックポインティングは、他のリソースには影響しません。
要件: このスイッチは、クォーラム ドライブ上の \MSCS ディレクトリ内のクォーラム ログ ファイル (Quolog.log) またはクラスター ハイブ チェックポイント ファイル (Chkxxx.tmp) に関する問題を診断するために、診断モードでのみ使用する必要があります。 このスイッチを使用して 1 つのノードを起動する場合は、このスイッチを使用して他のノードも起動する必要があります。 通常、このスイッチは 1 つのノードだけで使用されます。
使用シナリオ: クォーラム ログ ファイルまたはチェックポイント ファイルが破損し、これらのファイルをバックアップ コピーに手動で置き換える場合は、このスイッチを使用します。
操作: この場合、クラスター サービスはログ機能を完全にバイパスします。 このモードで実行すると、"パーティションインタイム" シナリオが発生する可能性があります。 この場合、クラスター ノード のレジストリ エントリが同期から外れ、新しい変更が失われる可能性があります。 構文は 次のとおりです。 net start clussvc /noquorumlogging
ForceQuorum
関数: Windows Server 2003 クラスターでマジョリティ ノード セット (MNS) クォーラム モデルを使用する場合、場合によっては、クォーラム (マジョリティ) がない場合でもクラスターの実行を許可する必要があります。 プライマリ サイトに 4 つのノードがあり、セカンダリ サイトに 3 つのノードがある地理的に分散したクラスターの場合を考えてみましょう。 障害は発生しませんが、クラスターは 7 ノードのクラスターであり、どのノードでも、どのサイトでもリソースをホストできます。 サイト間で通信エラーが発生した場合、またはセカンダリ サイトがオフラインになっている (または失敗した) 場合、プライマリ サイトはクォーラムを保持するため続行できます。 すべてのリソースが再ホストされ、プライマリ サイトでオンラインになります。
ただし、プライマリ サイトの致命的な障害が発生した場合、セカンダリ サイトはクォーラムを失い、そのため、すべてのリソースがそのサイトで終了します。 マルチサイト クラスターを使用する主な目的の 1 つは、プライマリ サイトでの災害を生き残る方法です。ただし、クラスター ソフトウェア自体は、プライマリ サイトの状態に関する決定を行うことはできません。 クラスター ソフトウェアは、サイト間の通信エラーとプライマリ サイトでの障害を区別できません。 これは手動による介入によって行う必要があります。 つまり、クラスター サービスがクォーラムを持っていないと判断した場合でも、セカンダリ サイトを強制的に続行できます。 これは強制クォーラムと呼ばれます。
このメカニズムは、クォーラム レプリカ セットに関連付けられているセマンティクスを効果的に壊しているため、制御された条件下でのみ実行する必要があります。 上の例では、セカンダリ サイトとプライマリ サイトが通信を失い、管理者がセカンダリ サイトでクォーラムを強制した場合、リソースは両方のサイトでオンラインになるため、クラスター内のデータやデータの破損に一貫性がない可能性があります。
要件: クォーラムの強制は、残りのすべてのノードでクラスター サービスを停止する必要がある手動プロセスです。 クラスター サービスには、クォーラムを持つと見なすノードを指定する必要があります。
使用シナリオ: ノードがクラスターの一部として構成されているため、プライマリ サイトが復帰した場合は、特別な注意が必要です。 クラスターが強制クォーラム状態で実行されている間は、完全に機能します。 たとえば、ノードをクラスターに追加したり、クラスターから削除したりできます。新しいリソース、グループなどを定義できます。
注:
強制クォーラム ノード の一覧に含まれていないすべてのノードのクラスター サービスは、強制クォーラム情報が削除されるまで停止したままにする必要があります。 そうしないと、データの不整合やデータの破損につながる可能性があります。
操作: クラスター内の残りのすべてのノードでクラスター サービスのスタートアップ パラメーターを設定します。 これを行うには、[サービス] コントロール パネルを起動し、[クラスター サービス] を選択し、[ パラメーターの開始 ] オプションに次のように入力します。
net start clussvc /forcequorum node_list
たとえば、セカンダリ サイトに Node5、Node6、Node7 が含まれており、クラスター サービスを開始し、クラスター内の唯一のノードにする必要がある場合は、次のコマンドを使用します。
net start clussvc /forcequorum /forcequorum node5,node6,node7
注:
キーにはスペースを含めてはいけません (ノード名自体にスペースがある場合を除きます)。
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示