クォーラムを構成および管理する

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

Azure Stack HCI および Windows Server クラスター上の記憶域スペース ダイレクトでのクラスターとストレージ プール クォーラムについては、「クラスターとプール クォーラムの概要」をご覧ください。

クォーラムについて

クラスターのクォーラムは、そのクラスターが正常に起動するか、または動作を継続するためにアクティブなクラスター メンバーシップに含まれる必要がある投票要素の数によって決定されます。 詳しくは、クラスターとプール クォーラムの概要に関するドキュメントをご覧ください。

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

Windows Server のクォーラム モデルは柔軟です。 クラスターのクォーラム構成を変更する必要がある場合は、クラスター クォーラム構成ウィザードまたは FailoverClusters Windows PowerShell コマンドレットを使用できます。 クォーラムを構成するための手順と考慮事項については、このトピックの「クラスター クォーラムを構成する」を参照してください。

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

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

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

モード 説明
ノード マジョリティ (監視なし) ノードのみが票を持ちます。 クォーラム監視は構成されません。 クラスター クォーラムは、アクティブなクラスター メンバーシップの投票ノードの過半数です。
ノード マジョリティと監視 (ディスクまたはファイル共有) ノードは票を持ちます。 さらに、クォーラム監視も票を持ちます。 クラスター クォーラムは、アクティブなクラスター メンバーシップの投票ノードの過半数と監視の投票です。 クォーラム監視は、指定されたディスク監視または指定されたファイル共有監視です。
非マジョリティ (ディスク監視のみ) ノードは票を持ちません。 票を持つのはディスク監視のみです。
クラスター クォーラムは、ディスク監視の状態によって決定されます。 一般に、このモデルは推奨されません。また、クラスターの単一障害点が生成されるため、選択しないでください。

以下のサブセクションでは、高度なクォーラム構成設定の詳細について説明します。

監視の構成

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

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

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

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

ファイル共有監視をホストするファイル サーバーに関する追加の考慮事項は次のとおりです。
  • 単一のファイル サーバーに複数のクラスター用のファイル共有監視を構成できます。
  • ファイル サーバーは、クラスター ワークロードとは別個のサイトに配置する必要があります。 このようにすると、サイト間ネットワーク通信が失われたときにどのクラスター サイトにも継続して動作する機会が平等に与えられます。 ファイル サーバーが同じサイトに存在する場合、そのサイトがプリマリ サイトになり、ファイル共有にアクセスできる唯一のサイトになります。
  • ファイル サーバーは、ファイル共有監視を使用するクラスターでホストされていない仮想マシン上でも実行できます。
  • 高可用性を保証するために、ファイル サーバーを別個のフェールオーバー クラスター上で構成できます。
クラウド監視
  • Azure Blob Storage に格納される監視ファイル
  • クラスター データベースのコピーを格納しません。
  • クラスター内のすべてのサーバーに確実なインターネット接続がある場合に推奨されます。
 クラウド監視のデプロイに関する記事をご覧ください。

Note

ファイル共有監視またはクラウド監視を構成した後、メンテナンスまたは何らかの理由ですべてのノードをシャットダウンする場合は、最新のクラスター データベースがそれらの監視に格納されていないので、最後まで残っていたノードからクラスター サービスを開始する必要があります。 こちらもご覧ください。

ノードの投票の割り当て

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

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

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

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

ノード投票の割り当てに関するその他の考慮事項

  • 投票ノードを奇数にするためにノードの投票を割り当てることは推奨されません。 代わりに、ディスク監視またはファイル共有監視を構成する必要があります。 詳細については、このトピックの前半の「監視の構成」を参照してください。
  • 動的なクォーラム管理を有効にした場合、ノードの投票が割り当てられるように構成されているノードに対してのみ、投票の割り当てまたは削除が動的に行われます。 詳細については、このトピックの後半の「動的なクォーラム管理」を参照してください。

動的なクォーラム管理

Windows Server 2012 では、高度なクォーラム構成オプションとして、クラスターによる動的なクォーラム管理を有効にできます。 動的クォーラムのしくみについて詳しくは、こちらの説明をご覧ください。

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

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

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

動的クォーラムの管理に関するその他の考慮事項

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

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

  • 記憶域スペース ダイレクトが有効になっていると、クラスターでサポートできるのは 2 ノードの障害のみです。 詳しくは、プール クォーラムに関するセクションをご覧ください

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

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

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

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

  • ノードを追加または削除する。
  • 記憶域を追加または削除する。
  • ノードまたは監視の障害が長期にわたっている。
  • マルチサイト障害回復シナリオでクラスターを回復する。

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

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

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

重要

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

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

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

注意

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

フェールオーバー クラスター マネージャーを使用してフェールオーバー クラスターのクォーラム構成を変更する

  1. フェールオーバー クラスター マネージャーで、変更するクラスターを選択または指定します。

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

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

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

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

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

        注意

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

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

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

      4. クラウド監視を構成するオプションを選択した場合は、[クラウド監視の構成] ページで、お使いの Azure ストレージ アカウント名、Azure ストレージ アカウント キー、Azure サービス エンドポイントを入力して、ウィザードを完了します。

        注意

        このオプションは、Windows Server 2016 以降で使用できます。

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

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

        注意

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

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

        注意

        このオプションは、Windows Server 2016 以降にはありません。

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

        注意

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

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

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

      6. クラウド監視を構成するオプションを選択した場合は、[クラウド監視の構成] ページで、お使いの Azure ストレージ アカウント名、Azure ストレージ アカウント キー、Azure サービス エンドポイントを入力して、ウィザードを完了します。

        注意

        このオプションは、Windows Server 2016 以降で使用できます。

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

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

注意

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

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-FC1 の DynamicQuorum プロパティを有効にします (以前に無効にされた場合)。

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

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

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

注意

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

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

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

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

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

重要

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

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

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

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

重要

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

フェールオーバー クラスター マネージャーを使用してクラスターを回復する方法を次に示します。

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

  2. クラスターを選んだ状態で、[操作] の [クラスターの強制起動] を選びます。

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

注意

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

Windows PowerShell の同等のコマンド (Start-Clusternode)

次の例では、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 が一時的な障害に耐えることができるか、または長期の障害に耐えることができるかによって異なります。

説明を見る