Windows Server 2012 フェールオーバー クラスターでクォーラムを構成および管理する

 

対象: Windows Server 2012

このトピックでは、Windows Server 2012 フェールオーバー クラスターのクォーラムを構成および管理するための基本情報と手順について説明します。

このトピックの内容

フェールオーバー クラスターのクォーラムの概要

クォーラム構成オプションの概要

クォーラム構成に関する一般的な推奨事項

クラスター クォーラムを構成する

クォーラムなしでクラスターを起動して回復する

障害回復構成で使用するクォーラムに関する考慮事項

クラスターのクォーラムは、そのクラスターが正常に起動するか、または動作を継続するためにアクティブなクラスター メンバーシップに含まれる必要がある投票要素の数によって決定されます。 既定では、クラスターの各ノードが 1 つのクォーラム投票を持ちます。 また、クォーラム監視 (構成されている場合) も 1 つのクォーラム投票を持ちます。 クォーラム監視は、クラスターごとに 1 つ構成できます。 クォーラム監視は、指定されたディスク リソース、またはファイル共有リソースです。 各要素は、クラスターが実行可能かどうかを決定するために “1 票” を投じることができます。 クラスターが正常に動作するために必要なクォーラムを満たしているかどうかは、アクティブなクラスター メンバーシップに属する投票要素の過半数によって決定されます。

クォーラムを構成する理由

クラスター、およびそのクラスターでホストされている役割の高可用性をさらに高めるには、クラスター クォーラム構成を適切に設定することが重要です。

次の理由により、クラスター クォーラム構成は、クラスターの高可用性に直接的な影響を与えます。

  • アクティブなクラスター メンバーシップが変更された場合でも、フェールオーバー クラスターが正常に起動または動作を継続できるようになります。 メンバーシップの変更は、計画済みまたは計画外のノードのシャットダウン、またはノード間またはクラスター記憶域との接続が切断されたときに発生します。

  • 一部のノード群が別のノード群と通信できなくなった場合 (分割クラスター)、クラスター クォーラムが構成されていれば、いずれかのノード群だけをクラスターとして継続して動作させることができます。 十分なクォーラム投票を持たないノード群は、クラスターとしての動作を停止します。 クォーラム投票の過半数を獲得しているノード群は、クラスター化された役割を引き続きホストします。 これにより、クラスターの分割を防ぐことができ、同じアプリケーションが複数のパーティションでホストされることがなくなります。

  • 監視の投票を構成すると、クラスターは特定の構成でさらに 1 つのノードの障害に耐えることができます。 クォーラム監視の構成の詳細については、このトピックの「監視の構成」を参照してください。

クラスターが完全に機能するかどうかは、クォーラムに加えて次の要素に依存します。

  • クラスター ノード間のネットワーク接続

  • 各ノードがそのノードに配置されたクラスター化された役割をホストする能力

  • クラスター化された役割に対して構成される優先順位の設定

たとば、5 つのノードを持つクラスターは、2 つのノードで障害が発生した後でもクォーラムを満たすことができます。 しかし、残りの各ノードは、フェールオーバーされたクラスター化された役割をサポートする十分な能力を持ち、役割の設定で最も重要なワークロードが優先付けられている場合にのみクライアントにサービスを提供できます。

クォーラム構成オプションの概要

Windows Server 2012 のクォーラム モデルは柔軟です。 クラスターのクォーラム構成を変更する必要がある場合は、クラスター クォーラム構成ウィザードまたはフェールオーバー クラスター Windows PowerShell コマンドレットを使用できます。 クォーラム構成オプションは、Windows Server 2008 R2 で選択可能なオプションよりシンプルです。 クォーラムを構成するための手順と考慮事項については、このトピックの「クラスター クォーラムを構成する」を参照してください。

次の表に、クラスター クォーラム構成ウィザードに用意されている 3 つのクォーラム構成オプションを示します。

オプション説明
標準設定を使用するクラスターは、自動的に各ノードに投票を割り当て、ノードの投票を動的に管理します。 このオプションがクラスターに適しており、クラスターの共有記憶域が使用可能な場合、クラスターはディスク監視を選択します。 ほとんどの場合はこのオプションお勧めします。クラスターの可用性を最大限に引き出すクォーラムと監視の構成がクラスター ソフトウェアによって自動的に選択されるためです。
クォーラム監視を追加または変更する監視リソースを追加、変更、または削除できます。 ファイル共有またはディスク監視を構成できます。 クラスターは、自動的に各ノードに投票を割り当て、ノードの投票を動的に管理します。
高度なクォーラム構成および監視の選択このオプションは、クォーラムの構成にアプリケーション固有またはサイト固有の要件がある場合にのみ選択します。 クォーラム監視の変更、ノードの投票の追加または削除、およびクラスターがノードの投票を動的に管理するかどうかの選択が可能です。 既定では、投票はすべてのノードに割り当てられ、ノードの投票は動的に管理されます。

選択したクォーラム構成オプションと固有の設定に応じて、クラスターは次のいずれかのクォーラム モードで構成されます。

モード説明
ノード マジョリティ (監視なし)ノードのみが票を持ちます。 クォーラム監視は構成されません。 クラスター クォーラムは、アクティブなクラスター メンバーシップの投票ノードの過半数です。
ノード マジョリティと監視 (ディスクまたはファイル共有)ノードは票を持ちます。 さらに、クォーラム監視も票を持ちます。 クラスター クォーラムは、アクティブなクラスター メンバーシップの投票ノードの過半数と監視の投票です。

クォーラム監視は、指定されたディスク監視または指定されたファイル共有監視です。
非マジョリティ (ディスク監視のみ)ノードは票を持ちません。 票を持つのはディスク監視のみです。 クラスター クォーラムは、ディスク監視の状態によって決定されます。

1 つのノードが使用可能であり、クラスター記憶域内の特定のディスクと通信していれば、クラスターはクォーラムを獲得します。 一般に、このモデルは推奨されません。また、クラスターの単一障害点が生成されるため、選択しないでください。

高度なクォーラム構成設定の詳細については、次のサブセクションを参照してください。

監視の構成

一般に、クォーラムを構成する場合は、クラスター内の投票要素は奇数である必要があります。 そのため、クラスターに含まれている投票ノードが偶数の場合は、ディスク監視またはファイル共有監視を構成する必要があります。 これにより、クラスターはさらに 1 つのノードの障害に耐えることができるようになります。 さらに、監視の投票を追加すると、クラスター ノードの半数が同時にダウンまたは切断状態になった場合でも、クラスターは実行を継続できます。

ディスク監視は通常、すべてのノードでそのディスクを表示できる場合に推奨されます。 ファイル共有監視は、レプリケートされた記憶域を使用するマルチサイト障害回復を検討する必要がある場合に推奨されます。 レプリケートされた記憶域を使用するディスク監視は、記憶域のベンダーがすべてのサイトからレプリケートされた記憶域への読み取り/書き込みアクセスをサポートしている場合にのみ構成できます。

次の表に、クォーラム監視の種類に関する追加情報と考慮事項を示します。

監視の種類説明要件と推奨事項
ディスク監視- クラスター データベースのコピーを格納する専用の LUN です。
- 共有 (レプリケートされない) 記憶域を持つクラスターに最適です。
- LUN の最小サイズは 512 MB です。
- クラスター専用とし、クラスター化された役割には割り当てないようにする必要があります。
- クラスター化された記憶域に含まれ、記憶域検証テストに合格する必要があります。
- クラスターの共有ボリューム (CSV) ディスクにすることはできません。
- 単一のボリュームを持つベーシック ディスクです。
- ドライブ文字を持つ必要はありません。
- NTFS または ReFS でフォーマットできます。
- 必要に応じてハードウェア RAID 構成にしてフォールト トレランスを実現できます。
- バックアップおよびウイルス対策スキャンから除外する必要があります。
ファイル共有監視- Windows Server を実行しているファイル サーバー上で構成される SMB ファイル共有です。
- クラスター データベースのコピーを格納しません。
- クラスター情報を witness.log ファイルにのみ保持します。
- レプリケートされた記憶域を使用するマルチサイト クラスターに最適です。
- 最低 5 MB の空き容量が必要です。
- 単一のクラスター専用とし、ユーザーまたはアプリケーション データを格納するために使用しないようにする必要があります。
- クラスター名のコンピューター オブジェクトに対する書き込み権限を有効にする必要があります。

ファイル共有監視をホストするファイル サーバーに関する追加の考慮事項は次のとおりです。

- 単一のファイル サーバーに複数のクラスター用のファイル共有監視を構成できます。
- ファイル サーバーは、クラスター ワークロードとは別個のサイトに配置する必要があります。 このようにすると、サイト間ネットワーク通信が失われたときにどのクラスター サイトにも継続して動作する機会が平等に与えられます。 ファイル サーバーが同じサイトに存在する場合、そのサイトがプリマリ サイトになり、ファイル共有にアクセスできる唯一のサイトになります。
- ファイル サーバーは、ファイル共有監視を使用するクラスターでホストされていない仮想マシン上でも実行できます。
- 高可用性を保証するために、ファイル サーバーを別個のフェールオーバー クラスター上で構成できます。

ノードの投票の割り当て

Windows Server 2012 では、高度なクォーラム構成オプションとして、ノード単位でクォーラム投票を割り当てるか、または削除することを選択できます。 既定では、すべてのノードに投票が割り当てられます。 投票の割り当てに関係なく、クラスター内のすべてのノードは引き続き正常に動作し、クラスター データベース更新を受信し、アプリケーションをホストできます。

特定の障害回復構成では、ノードから投票を削除できます。 たとえば、マルチサイト クラスターでは、バックアップ サイトのノードから投票を削除して、それらのノードがクォーラムの計算に影響しないようにできます。 この構成は、サイト間の手動のフェールオーバーでのみ推奨されます。 詳細については、後述する「障害回復構成で使用するクォーラムに関する考慮事項」を参照してください。

構成されたノードの投票は、Get-ClusterNodeWindows PowerShell コマンドレットを使用して、クラスター ノードの NodeWeight 共通プロパティを参照することによって検証できます。 0 の値は、ノードにクォーラム投票が構成されていないことを示しています。 1 の値は、ノードのクォーラム投票が割り当てられ、クラスターによって管理されていることを示しています。 ノードの投票の管理については、このトピックの後半の「動的なクォーラム管理」を参照してください。

すべてのクラスター ノードに対する投票の割り当ては、クラスター クォーラムの検証テストによって検証できます。

その他の考慮事項

  • 投票ノードを奇数にするためにノードの投票を割り当てることは推奨されません。 代わりに、ディスク監視またはファイル共有監視を構成する必要があります。 詳細については、「監視の構成」を参照してください。

  • 動的なクォーラム管理を有効にした場合、ノードの投票が割り当てられるように構成されているノードに対してのみ、投票の割り当てまたは削除が動的に行われます。 詳細については、後述する「動的なクォーラム管理」を参照してください。

動的なクォーラム管理

Windows Server 2012 では、高度なクォーラム構成オプションとして、クラスターによる動的なクォーラム管理を有効にできます。 このオプションを有効にすると、クラスターは各ノードの状態に基づいてノードへの投票の割り当てを動的に管理します。 投票は、アクティブなクラスター メンバーシップを失ったノードから自動的に削除され、ノードがクラスターに再度参加すると自動的に割り当てられます。 動的なクォーラム管理は既定で有効になっています。

System_CAPS_ICON_note.jpg メモ

動的なクォーラム管理を使用すると、クラスター クォーラムの過半数は、任意の時点でのクラスターのアクティブなメンバーであるノード数によって決定されます。 これは、初期クラスター構成に基づいてクォーラムの過半数が固定されている Windows Server 2008 R2 のクラスター クォーラムとの重要な相違点です。

動的なクォーラム管理では、クラスターは正常に動作している最後のクラスター ノードで動作できます。 クォーラムの過半数の要件を動的に調整することによって、クラスターは連続的なノードのシャットダウンに最後の 1 つのノードまで耐えることができます。

クラスターによって動的に割り当てられるノードの投票は、Get-ClusterNodeWindows PowerShell コマンドレットを使用して、クラスター ノードの DynamicWeight 共通プロパティで検証できます。 0 の値は、ノードにクォーラム投票が割り当てられていないことを示しています。 1 の値は、ノードにクォーラム投票が割り当てられていることを示しています。

すべてのクラスター ノードに対する投票の割り当ては、クラスター クォーラムの検証テストによって検証できます。

その他の考慮事項

  • 動的なクォーラム管理では、クラスターは投票メンバーの過半数の同時障害に耐えることができません。 動作を継続するには、クラスターはノードのシャットダウンまたは障害時にクォーラムの過半数を常に満たしている必要があります。

  • ノードの投票を明示的に削除した場合、クラスターは動的にその投票を追加または削除することはできません。

クラスター ソフトウェアは、構成されているノードの数と共有記憶域の可用性に基づいて、新しいクラスターのクォーラムを自動的に構成します。 これは通常、そのクラスターに最適なクォーラム構成です。 しかし、クラスターが作成されたら、そのクラスターを運用環境に展開する前にクォーラム構成を確認することをお勧めします。 クラスター クォーラム構成の詳細を確認するには、構成の検証ウィザード、または Test-ClusterWindows PowerShellコマンドレットを使用して、クォーラム構成の検証テストを実行します。 フェールオーバー クラスター マネージャーでは、基本クォーラム構成は選択したクラスターの要約情報に表示されます。または、Get-ClusterQuorumWindows PowerShellコマンドレットを実行して、返されるクォーラム リソースに関する情報を確認できます。

クォーラム構成の検証テストを実行すると、クォーラム構成がクラスターに最適であることをいつでも検証できます。 テストの出力は、クォーラム構成の変更が推奨されるかどうか、および設定が最適かどうかを示します。 変更が推奨される場合は、クラスター クォーラム構成ウィザードを使用して推奨設定を適用できます。

クラスターを運用環境に展開したら、変更がクラスターに適していると判断した場合を除いて、クォーラム構成を変更しないでください。 クォーラム構成の変更を検討する必要があるのは、次のような場合です。

  • ノードを追加または削除する。

  • 記憶域を追加または削除する。

  • ノードまたは監視の障害が長期にわたっている。

  • マルチサイト障害回復シナリオでクラスターを回復する。

フェールオーバー クラスターの検証の詳細については、「フェールオーバー クラスター用ハードウェアを検証する」を参照してください。

クラスター クォーラム設定を構成するには、フェールオーバー クラスター マネージャーまたはフェールオーバー クラスター Windows PowerShell コマンドレットを使用します。

System_CAPS_ICON_important.jpg 重要

通常、最適な結果を得るには、クラスター クォーラム構成ウィザードによって推奨されるクォーラム構成を使用します。 変更することによってクラスターに適した構成になる場合にのみ、クォーラム構成をカスタマイズしてください。 詳細については、「クォーラム構成に関する一般的な推奨事項」を参照してください。

クラスター クォーラム設定を構成する

この手順を完了するには、少なくともクラスター化された各サーバーでローカルの Administrators グループ、またはそれと同等のメンバーシップが必要です。 また、使用するアカウントはドメイン ユーザー アカウントである必要があります。

System_CAPS_ICON_note.jpg メモ

クラスター クォーラム構成の変更は、クラスターを停止したり、クラスター リソースをオフラインにしたりせずに実行できます。

フェールオーバー クラスター マネージャーを使用してフェールオーバー クラスターのクォーラム構成を変更するには
  1. フェールオーバー クラスター マネージャーで、変更するクラスターを選択または指定します。

  2. クラスターを選択した状態で、[操作][他の操作][クラスター クォーラム設定の構成] の順にクリックします。 クラスター クォーラム構成ウィザードが表示されます。[次へ] をクリックします。

  3. [クォーラム構成オプションの選択] ページで、3 つの構成オプションの 1 つを選択し、そのオプションの手順を完了します。 クォーラム設定を構成する前に、選択内容を確認できます。 オプションの詳細については、このトピックで前述した「フェールオーバー クラスターのクォーラムの概要」を参照してください。

    • クラスターが現在のクラスター構成に最適なクォーラム設定を自動的にリセットできるようにするには、[標準設定を使用する] をクリックし、ウィザードを完了します。

    • クォーラム監視を追加または変更するには、[クォーラム監視を追加または変更する] をクリックし、次の手順に従います。 クォーラム監視に関する情報と考慮事項については、このトピックで前述した「監視の構成」を参照してください。

      1. [クォーラム監視の選択] ページで、ディスク監視またはファイル共有監視を構成するオプションを選択します。 ウィザードには、対象のクラスターに対して推奨される監視選択オプションが示されます。

        System_CAPS_ICON_note.jpg メモ

        [クォーラム監視を構成しない] をクリックしてウィザードを完了することもできます。 クラスター内の投票ノード数が偶数の場合、この構成は推奨されません。

      2. ディスク監視を構成するオプションを選択した場合は、[記憶域監視の構成] ページで、ディスク監視として割り当てる記憶域ボリュームを選択してウィザードを完了します。

      3. ファイル共有監視を構成するオプションを選択した場合は、[ファイル共有監視の構成] ページで、監視リソースとして使用されるファイル共有を入力または指定してウィザードを完了します。

    • クォーラム管理設定を構成し、クォーラム監視を追加または削除するには、[高度なクォーラム構成および監視の選択] をクリックし、次の手順に従います。 高度なクォーラム構成設定に関する情報と考慮事項については、このトピックで前述した「ノードの投票の割り当て」および「動的なクォーラム管理」を参照してください。

      1. [投票構成の選択] ページで、投票をノードに割り当てるオプションを選択します。 既定では、すべてのノードに投票が割り当てられます。 しかし、特定のシナリオでは、一部のノードにのみ投票を割り当てることができます。

        System_CAPS_ICON_note.jpg メモ

        また、[ノードなし] を選択することもできます。 通常、これは推奨されません。この構成にすると、ノードがクォーラム投票に参加できず、ディスク監視を構成する必要があるからです。 このディスク監視は、クラスターの単一障害点になります。

      2. [クォーラム管理の構成] ページで、[クラスターがノードの投票の割り当てを動的に管理できるようにする] オプションを有効または無効にできます。 このオプションを選択すると、通常クラスターの可用性が向上します。 このオプションは既定で有効にされており、無効にしないことを強くお勧めします。 このオプションを選択すると、クラスターはこのオプションが無効になっている場合では不可能な障害シナリオでも動作を継続できます。

      3. [クォーラム監視の選択] ページで、ディスク監視またはファイル共有監視を構成するオプションを選択します。 ウィザードには、対象のクラスターに対して推奨される監視選択オプションが示されます。

        System_CAPS_ICON_note.jpg メモ

        [クォーラム監視を構成しない] をクリックしてウィザードを完了することもできます。 クラスター内の投票ノード数が偶数の場合、この構成は推奨されません。

      4. ディスク監視を構成するオプションを選択した場合は、[記憶域監視の構成] ページで、ディスク監視として割り当てる記憶域ボリュームを選択してウィザードを完了します。

      5. ファイル共有監視を構成するオプションを選択した場合は、[ファイル共有監視の構成] ページで、監視リソースとして使用されるファイル共有を入力または指定してウィザードを完了します。

  4. [次へ] をクリックします。 確認ページが表示されたら、選択内容を確認して、[次へ] をクリックします。

ウィザードを実行し、[概要] ページが表示された時点で、ウィザードによって実行されたタスクのレポートを表示する場合は、[レポートの表示] をクリックします。 最新のレポートは、systemroot\Cluster\Reports フォルダーに QuorumConfiguration.mht という名前で保持されます。

System_CAPS_ICON_note.jpg メモ

クラスター クォーラムを構成したら、クォーラム構成の検証 テストを実行して、更新されたクォーラム設定を検証することをお勧めします。

PowerShell ロゴ  Windows PowerShell の同等のコマンド

次のいくつかの例では、Set-ClusterQuorum コマンドレットとその他の Windows PowerShell コマンドレットを使用してクラスター クォーラムを構成する方法を示します。

次の例では、クラスター CONTOSO-FC1 のクォーラム構成を、クォーラム監視がない単純なノード マジョリティ構成に変更します。

Set-ClusterQuorum –Cluster CONTOSO-FC1 -NodeMajority  

次の例では、ローカル クラスターのクォーラム構成をノード マジョリティと監視構成に変更します。Cluster Disk 2 という名前のディスク リソースがディスク監視として構成されます。

Set-ClusterQuorum -NodeAndDiskMajority "Cluster Disk 2"  
  

次の例では、ローカル クラスターのクォーラム構成をノード マジョリティと監視構成に変更します。\\CONTOSO-FS\fsw という名前のファイル共有リソースがファイル共有監視として構成されます。

Set-ClusterQuorum -NodeAndFileShareMajority "\\fileserver\fsw"  
  

次の例では、ローカル クラスターのノード ContosoFCNode1 からクォーラム投票を削除します。

(Get-ClusterNode ContosoFCNode1).NodeWeight=0  

次の例では、ローカル クラスターのノード ContosoFCNode1 にクォーラム投票を追加します。

(Get-ClusterNode ContosoFCNode1).NodeWeight=1  

次の例では、クラスター CONTOSO-FC1DynamicQuorum プロパティを有効にします (以前に無効にされた場合)。

(Get-Cluster CONTOSO-FC1).DynamicQuorum=1  

十分なクォーラム投票を持たないクラスターは起動しません。 最初の手順として、クラスター クォーラム構成を常に確認し、クラスターがクォーラムを失った理由を調べる必要があります。 これは、応答を停止したノードが存在するか、またはマルチサイト クラスターでプライマリ サイトにアクセスできない場合に発生する可能性があります。 クラスター障害の根本原因を特定したら、このセクションで説明する回復手順を実行できます。

System_CAPS_ICON_note.jpg メモ

  • クォーラムが失われたためクラスター サービスが停止した場合は、イベント ID 1177 がシステム ログに表示されます。
  • クラスター クォーラムが失われた理由を常に調べる必要があります。
  • クォーラムなしでクラスターを起動するより、ノードまたはクォーラム監視を正常な状態に戻す (クラスターに参加させる) ことが常に推奨されます。

クラスター ノードを強制的に起動する

ノードまたはクォーラム監視を正常な状態に戻すことによってクラスターを回復できない場合は、クラスターを強制的に起動することが必要になります。 クラスターを強制的に起動すると、クラスターのクォーラム構成設定が無効になり、クラスターは ForceQuorum モードで起動します。

クォーラムを持たないクラスターを強制的に起動する方法は、特にマルチサイト クラスターで役立ちます。 異なる場所に配置されているプライマリ サイト SiteA とバックアップ サイト SiteB が含まれるクラスターで障害回復を行うシナリオを考えてみましょう。SiteA で本当の障害が発生した場合、このサイトがオンラインに復帰するまで非常に長い時間がかかる可能性があります。 このような場合、クォーラムを持たない SiteB を強制的にオンラインにすることを検討します。

クラスターが ForceQuorum モードで起動し、十分なクォーラム投票を再び獲得すると、クラスターは強制された状態を自動的に終了して正常な状態で動作します。 そのため、クラスターを正常に再起動する必要はありません。 クラスターは強制された状態ではなくなったため、クラスターがノードを失い、さらにクォーラムを失うと、再びオフラインに戻ります。 クォーラムを失ったクラスターをオンラインに戻すには、クォーラムなしでクラスターを起動する必要があります。

System_CAPS_ICON_important.jpg 重要

  • クラスターが強制的に起動したら、管理者はクラスターに対する完全な制御権限を持ちます。
  • クラスターは、強制的に起動したノードのクラスター構成を使用し、使用可能なその他のすべてのノードにその構成をレプリケートします。
  • クラスターをクォーラムなしで強制的に起動すると、クラスターが ForceQuorum モードの間、すべてのクォーラム構成が無視されます。 これには、特定のノードの投票の割り当てと動的なクォーラム管理の設定が含まれます。

残りのクラスター ノードがクォーラムに準拠しないようにする

ノードでクラスターを強制的に起動したら、クラスター内の残りのノードをクォーラムに準拠しない設定で起動する必要があります。 クォーラムに準拠しない設定で起動したノードは、クラスター サービスに対して、新しいクラスター インスタンスを形成する代わりに、既存の実行中のクラスターに参加するように指示します。 このようにすることで、残りのノードによって 2 つの競合するインスタンスから成る分割クラスターが形成されるのを防ぎます。

これが必要になるのは、バックアップ サイト SiteB でクラスターを強制的に起動した後に、一部のマルチサイト障害回復シナリオでクラスターを回復する必要がある場合です。SiteB で強制的に再起動したクラスターに参加するには、プライマリ サイト SiteA のノードをクォーラムに準拠しない設定で起動する必要があります。

System_CAPS_ICON_important.jpg 重要

クラスターがノードで強制的に再起動したら、残りのノードを常にクォーラム非準拠で起動することをお勧めします。

フェールオーバー クラスター マネージャーを使用してクラスターを回復するには
  1. フェールオーバー クラスター マネージャーで、回復するクラスターを選択または指定します。

  2. クラスターを選択した状態で、[操作][クラスターの強制起動] をクリックします。

    フェールオーバー クラスター マネージャーは、アクセスできるすべてのノードでクラスターを強制的に起動します。 クラスターは、起動時に現在のクラスター構成を使用します。

    System_CAPS_ICON_note.jpg メモ

    • 使用する必要があるクラスター構成が存在する特定のノードでクラスターを強制的に起動するには、この手順の後に示す Windows PowerShell コマンドレットか、またはこれに相当するコマンドライン ツールを使用する必要があります。
    • フェールオーバー クラスター マネージャーを使用して強制的に起動したクラスターに接続し、[クラスター サービスの開始] アクションを使用してノードを起動した場合、ノードは自動的に非準拠クォーラム設定を使用して起動します。

PowerShell ロゴ  Windows PowerShell の同等のコマンド

次の例では、Start-ClusterNode コマンドレットを使用してノード ContosoFCNode1 でクラスターを強制的に起動する方法を示します。

Start-ClusterNode –Node ContosoFCNode1 –FQ  

代わりに、ノードで次のコマンドをローカルに実行することもできます。

Net Start ClusSvc /FQ  

次の例では、Start-ClusterNode コマンドレットを使用して、ノード ContosoFCNode1 でクラスター サービスをクォーラム非準拠で起動する方法を示します。

Start-ClusterNode –Node ContosoFCNode1 –PQ  

代わりに、ノードで次のコマンドをローカルに実行することもできます。

Net Start ClusSvc /PQ  

このセクションでは、障害回復を展開する際の 2 つのマルチサイト クラスター構成の特性とクォーラム構成をまとめます。 クォーラム構成のガイドラインは、サイト間でワークロードの自動フェールオーバーが必要なのか、または手動フェールオーバーが必要なのかによって異なります。 構成は通常、サイトで障害が発生したときにクラスター化されたワークロードを提供およびサポートするために組織で規定されるサービス レベル アグリーメント (SLA) によって決まります。

自動フェールオーバー

この構成では、クラスターはクラスター化された役割をホストできる 2 つ以上のサイトから構成されています。 いずれかのサイトで障害が発生した場合、クラスター化された役割は残りのサイトに自動的にフェールオーバーされます。 したがって、クラスター クォーラムは、どのサイトもサイト全体の障害に耐えることができるように構成する必要があります。

次の表に、この構成に関する考慮事項と推奨事項をまとめます。

Item説明
各サイトのノード数同数にする必要があります。
ノードの投票の割り当てすべてのノードが等しく重要なので、ノードの投票は削除してはなりません。
動的なクォーラム管理有効にする必要があります。
監視の構成ファイル共有監視が推奨されます。これはクラスター サイトとは別個のサイトに配置します。
ワークロードワークロードは任意のサイトで構成できます。

その他の考慮事項

  • 各サイトに継続して動作する機会を平等に与えるために、ファイル共有監視を別個のサイトに構成する必要があります。 詳細については、このトピックで前述した「監視の構成」を参照してください。

手動フェールオーバー

この構成では、クラスターはプライマリ サイト SiteA およびバックアップ (回復) サイト SiteB から構成されます。 クラスター化された役割は、SiteA でホストされます。 クラスター クォーラム構成のため、障害が SiteA 内のすべてのノードで発生した場合、クラスターは動作を停止します。 このシナリオでは、管理者はクラスター サービスを SiteB に手動でフェールオーバーし、追加の手順を実行してクラスターを回復する必要があります。

次の表に、この構成に関する考慮事項と推奨事項をまとめます。

Item説明
各サイトのノード数異なっていてもかまいません。
ノードの投票の割り当て- ノードの投票をプライマリ サイト SiteA のノードから削除してはなりません。
- ノードの投票をバックアップ サイト SiteB のノードから削除する必要があります。
- SiteA で長期の停止が発生した場合、投票を SiteB のノードに割り当てて、回復の一部としてこのサイトでクォーラム マジョリティを有効にする必要があります。
動的なクォーラム管理有効にする必要があります。
監視の構成- SiteA に存在するノード数が偶数の場合は監視を構成します。
- 監視が必要な場合、SiteA のノードからのみアクセスできるファイル共有監視またはディスク監視 (非対称ディスク監視とも呼ぶ) を構成します。
ワークロード優先所有者を使用して、SiteA のノードでワークロードの動作を維持します。

その他の考慮事項

  • クォーラム投票が最初に構成されるのは、SiteA のノードのみです。 これは、SiteB のノードの状態がクラスター クォーラムに影響を与えないようにするために必要です。

  • 回復手順は、SiteA が一時的な障害に耐えることができるか、または長期の障害に耐えることができるかによって異なります。

フェールオーバー クラスタリング
フェールオーバー クラスター Windows PowerShell コマンドレット

表示: