SQL Always On 3ノードWSFCのクォーラム設計：ウィットネス必要性とDR自動フェールオーバーの可否

本番DCに2ノード、DRに1ノードのSQL Server Always On（WSFC）では、クォーラム設計を誤ると災害時にDR側が起動できず停止することがあります。ウィットネスの必要性と自動フェールオーバーの条件、現場で失敗しない構成パターンを整理します。

結論：3ノード（本番2／DR1）で「ウィットネス不要」と言い切るのは危険

先に結論を整理します。

• 3ノード（WSFC）自体は奇数のため、理屈の上ではウィットネス無し（ノード多数決）でもクォーラムは構成できます。
• しかし「本番DCに2ノード／DR DCに1ノード」という2:1の偏った配置では、想定すべき故障は“ノード1台”ではなく“サイト（データセンター）単位で2台まとめて失う”ことが多く、ここでクォーラムを失いやすくなります。
• 本番DCが災害で喪失し2/3ノードが同時に停止した場合、DR側の1台だけで自動継続できるとは限りません。クォーラムを失うとクラスタは保護動作としてオフラインになり、SQLの役割（AG/FCI）も停止しやすく、復旧は手動介入が前提になります。
• ウィットネスは「票（投票）を補う仕組み」ですが、ウィットネスを置いた＝DRに自動フェールオーバーできるではありません。DR側に“多数派”が残るように、投票設計と配置（第三拠点/クラウド、ノード数、票の持ち方）をセットで考える必要があります。

そもそもクォーラムとは何か：スプリットブレインを避けるための「稼働許可証」

WSFCのクォーラム（Quorum）は、クラスタがネットワーク分断や障害で「複数の島」に分かれたときに、両方が同時にサービスを提供してしまう（スプリットブレイン）事態を防ぐための仕組みです。基本はシンプルで、投票要素（ノード＋ウィットネス）のうち“過半数”を確保できた側だけが稼働します。過半数を失った側は、データ破損などを避けるためにサービスを停止します。

用語	意味	現場での言い換え
投票（Vote）	クォーラム判定に使われる「票」。通常は各ノードが1票、構成によりウィットネスも1票。	多数決の投票権
クォーラム（Quorum）	クラスタが稼働を継続するために必要な“過半数”。	動き続けるための多数派
ウィットネス（Witness）	同票になりやすい状況を避けるための第三者的な1票。クラスタデータ/投票に関わるが、SQLデータを保持するものではない。	最後の1票（タイブレーカー）
スプリットブレイン	分断された両側が「自分が正」と誤認し、同じ名前/同じサービスを同時に提供してしまう状態。	二重稼働で壊れる事故

ここで重要なのは、クォーラムは“可用性を上げるためだけの機能”ではなく、データ一貫性を守るために、あえて止まる判断をする機能だという点です。つまり「DR側が1台残っているのに動かない」のは、仕様としては正しい動作です。

3ノード（本番2／DR1）を票で見る：ノード多数決の弱点がサイト障害で露呈する

例として、次のような配置を想定します。

• 本番DC（Site-A）：Node1、Node2
• DR DC（Site-B）：Node3

ウィットネス無しで「ノード多数決（Node Majority）」の場合、投票は3票で、稼働に必要な過半数は2票です。

状態	稼働ノード	有効票	必要票（過半数）	WSFCは稼働継続できるか
平常時	3/3	3	2	できる
ノード1台故障	2/3	2	2	できる（ギリギリ）
本番DC喪失（2台同時停止）	1/3	1	2	できない（クォーラム喪失）

この表だけ見ると「じゃあウィットネスを足せば？」となりますが、ここからが落とし穴です。ウィットネスは“追加の1票”であり、票の設計がサイト障害（2票同時消失）に耐える形になっていなければ、DR側の自動継続は保証できません。

動的クォーラムを過信しない：同時多発障害では止まる

Windows Server 2012以降のWSFCには、ノードが段階的に落ちていく状況でクォーラム要件を動的に調整し、最後の1台まで稼働を継続しやすくする仕組み（Dynamic Quorum）があります。ただし、ドキュメント上も「同時に多数の投票メンバーが失われる障害」には耐えられないことが明記されています。つまり、サイト障害のように“2台がまとめて落ちた”ケースでは、設計として自動継続を期待しない方が安全です。

同様に、ウィットネス側にもDynamic Witnessがあり、投票の総数が奇数になるようにウィットネス票を有効/無効に切り替える仕組みがあります。これは「ウィットネスが常に1票を持つ」と思い込んでいると設計ミスにつながるポイントです。

ウィットネスは必要か：おすすめは「置く」。ただし置き方が9割

3ノードが奇数だからといって、運用現場でウィットネスを完全に外す判断はあまりおすすめしません。理由は大きく3つです。

• ノード1台故障後は残り2ノードになり、そこでネットワーク揺れや再起動が重なると、同票や分断のリスクが急に上がるため
• クラスタの計画停止/メンテナンス時に、順序を誤るとクォーラムを落としやすいため
• 障害時の復旧手順（強制クォーラム等）を簡素化できることがあるため

ただし、重要なのは「作るか作らないか」よりもどこに置くか（どの障害で一緒に失われるか）です。たとえば、ウィットネスを本番DC内に置くと、本番DC喪失時にノード2台と一緒にウィットネスも失われ、DR側に残る票は増えません。ウィットネスは本番DCともDR DCとも運命共同体にならない場所（第三拠点やクラウド）に置くのが基本です。

なお、WSFCで設定するクォーラム・ウィットネスは、クラスタに対して通常1つ（クラウド／ディスク／ファイル共有のいずれか）を選ぶ形です。ウィットネス自体を二重化して“複数票”にする発想ではなく、まずは「どの1票を、どこに置くか」を設計します。

ウィットネスの種類と、SQL Always On（AG）での現実解

SQL Server Always On可用性グループ（AG）のように共有ディスクを前提にしない構成では、ファイル共有ウィットネス（File Share Witness）またはクラウドウィットネス（Cloud Witness）が選ばれることが多いです。

ウィットネス種別	向いているケース	注意点
ファイル共有ウィットネス	オンプレ中心で、SMB共有を安定して用意できる。AG/レプリケーション構成で共有ディスクが無い。	共有先サーバーの冗長化/保守が必要。クラスタノード上に置くのは避ける。
クラウドウィットネス	第三拠点を持たないが、外向きHTTPS通信が許容できる。運用負荷を軽くしたい。	インターネット到達性（FW/Proxy）に依存。資格情報（ストレージキー等）管理が必要。
ディスクウィットネス	全ノードから同一共有ディスクに到達できる（S2D/AGでは一般に前提が合わない）。	共有ディスク自体が設計要件。マルチサイトでの共有ディスクは難易度が高い。

本番DC喪失で「自動フェールオーバー」できるか：WSFCとSQLの2段階条件

「DR側の1台に自動で切り替わって動き続けるか？」は、実はWSFCだけで決まりません。少なくとも次の2段階を両方満たす必要があります。

条件1：WSFCがクォーラムを維持し、クラスタがオンラインである

WSFCは、ノード間のハートビート通信とクォーラム投票でクラスタ全体の健全性を判定します。クォーラムを失うとクラスタは保護動作としてオフラインになり、SQLのクラスタ登録リソースも停止します。ここで停止すると、SQL側の自動フェールオーバー以前の問題になります（手動介入が必要）。

条件2：SQL Always On（可用性グループ）が自動フェールオーバー可能な構成になっている

AGの自動フェールオーバーは、同期コミット（Synchronous commit）かつAUTOMATICに設定された「プライマリ＋セカンダリ」のペアが存在し、さらにセカンダリ側が健全に同期していることが前提です。一般にDRサイトは距離があり遅延も大きいため、RPO/RTOと性能を天秤にかけてDRは非同期＋手動切替にする設計も多く、その場合は当然ながら自動では切り替わりません。

なぜ2:1配置は「ノード故障には強いのに、サイト故障に弱い」のか

可用性設計の落とし穴は、障害を“独立事象”として数えてしまうことです。本番DCの2ノードは、次のような共通要因故障を持ちます。

• 同一受電/UPS/発電機、同一空調
• 同一のラック/スイッチ/ルータ、同一の回線収容
• 同一のストレージ装置・ストレージネットワーク
• 同一の運用オペレーション（パッチ適用ミス、設定投入ミス）

つまり「2ノードあるから大丈夫」ではなく、実際には“同時に2ノードが消える確率”が思ったより高いのが2:1配置です。ここにクォーラム設計が追いついていないと、DR側の1台が生きていても止まります。

現実的な構成パターン：目的別に「どこまで自動化するか」を決める

次の表は、よくある要求と、現実的に選ばれやすい構成を対応づけたものです。

やりたいこと	推奨パターン	ポイント
本番DC内のノード故障に対して自動で切り替えたい（HA重視）	本番DCに2ノード（同期コミット＋自動）、DRは1ノード（非同期＋手動）＋ウィットネスは第三拠点/クラウド	DR自動は狙わず、RPO/RTOを現実解に落とす。ウィットネスは「止まりにくさ」を上げる。
本番DC喪失でも“できるだけ早く”DRで復旧したい（手動は許容）	2+1＋第三拠点/クラウドにウィットネス、手順として強制クォーラム＋AGフェールオーバーを用意	「自動」ではなく「手順を短く・迷わない」設計。演習が重要。
本番DC喪失でも自動でDRへ切り替えたい（サイト自動フェールオーバー）	DR側にも2票を残せる設計（例：DRに2ノード、または第三拠点/クラウドの票＋投票設計をサイト障害向けに最適化）	クォーラムとAGの両方で自動条件を満たす必要。同期コミット要件が性能に影響。

特に3行目（サイト自動フェールオーバー）は難易度が一段上がります。クォーラム的にDR側が稼働できるだけでなく、SQL側も同期コミット＋自動フェールオーバー条件を満たす必要があるためです。

2+1で「DR自動」を狙うときに考えるべき投票設計

どうしてもノード数を増やせない事情があり、2+1でサイト障害時の自動継続を狙う場合、理屈としては「DR側に残る投票要素を過半数にする」必要があります。ただし、この設計はスプリットブレイン回避と表裏一体で、設定を誤ると“両サイトが動く”事故に直結します。

Microsoftのドキュメントでも、特定のDRシナリオではノード票を外すことを検討できる一方で、票のカスタマイズは慎重に扱うべきことが示されています。まずはウィットネスで奇数化し、必要性が明確な場合のみ投票設計に踏み込むのが現実的です。

また、動的クォーラムは「順番に落ちていく」状況に強い一方で、同時多発的に投票メンバーが落ちると維持できないことが前提です。災害時に“2台まとめて落ちる”前提で、確実に自動化したいなら、最終的にはDR側にもう1ノードを置く設計が最も堅実です。

設定の確認と最低限のコマンド：まず“今どうなっているか”を見える化する

議論が噛み合わない原因の多くは「いまの投票がどうなっているか」を誰も正確に見ていないことです。設計前に、次の2点を先に確認すると判断が早くなります。

• クォーラムの種類（ノード多数決か、ウィットネス付きか）
• 各ノード/ウィットネスが“いま何票として数えられているか”（Dynamic Quorum/Dynamic Witnessの影響）

PowerShellでの確認例です（実行は管理者権限）。

Get-ClusterQuorum
Get-ClusterNode | Format-Table Name, NodeWeight, DynamicWeight, State

DynamicWeightは動的に付与/剥奪された投票の有無を示し、0ならその時点では票が無い状態です。票を“固定で外す”ような調整（NodeWeight変更）は、DR手順や分断対策を含めて検討しないと事故につながるため、まずは現状把握を優先してください。

ウィットネス配置の実務ポイント：第三拠点が無いならクラウドが現実的

第三拠点（第3サイト）を持てないケースでは、クラウドウィットネスが現実解になりやすいです。クラウドウィットネスはAzure Blob Storageを利用し、クラスタが必要時に投票の参照として使います。導入時は、ネットワーク的にHTTPS（外向き）通信ができること、ファイアウォール/プロキシの設計、資格情報のローテーションなどを運用に組み込みます。

クラウドウィットネスをPowerShellで設定する場合は、次のようなコマンドになります（値は環境に合わせて置き換えます）。

Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey>
Get-ClusterQuorum

ファイル共有ウィットネスを使う場合は、SMB共有を用意したうえで次のように設定します。

Set-ClusterQuorum -FileShareWitness \\FileShareWitnessServer\WitnessShare
Get-ClusterQuorum

「ウィットネスをどこに置くか」判断表

置き場所	本番DC喪失時	DR DC喪失時	評価
本番DC内	ノード2台＋ウィットネスを一緒に失いがち	本番側で継続しやすい	DR視点では弱い（おすすめしにくい）
DR DC内	DR側の票を残しやすい	本番側で継続しやすい	“DR側を勝たせたい”意図があるなら検討余地。ただしサイト分断時の設計が重要。
第三拠点/クラウド	どちらのサイトが落ちても片側に票が残りやすい	同左	最も一般的な考え方。第三者の1票になりやすい。

SQL Always On（AG）側の設計メモ：自動フェールオーバーに必要な“近さ”

AGの自動フェールオーバーは、ドキュメント上も「WSFC上でプライマリと自動フェールオーバー先が近い（低遅延）環境が適する」と説明されています。遠距離DRで同期コミットを強制すると、コミット待ちが増えてアプリ性能に影響しやすい点に注意が必要です。

そのため、実務では次の二段構えがよく採られます。

• HA（高可用）：本番DC内で同期コミット＋自動フェールオーバー（ノード障害に強い）
• DR（災害対策）：遠隔DCへは非同期コミット＋手動フェールオーバー（データ損失ゼロを保証しない代わりに性能を守る）

運用で詰まりやすいポイント：復旧を「簡単にする」設計を入れておく

2+1構成を選ぶ理由の多くはコスト/ライセンス/運用負荷です。その場合、目標を「完全自動」から「迷わず復旧」に寄せると、現場の事故が減ります。具体的には次を用意します。

• サイト障害時の判断基準（本番DCが本当に戻らないのか、分断なのか）
• 本番側を確実に停止させる隔離手順（電源断、ネットワーク遮断など）
• DR側でクラスタを立ち上げる復旧手順（強制クォーラム等）と、実施権限
• AGの手動フェールオーバー手順と、アプリ接続先切替（DNS/Listener/ロードバランサ）の手順
• 年に1回以上の演習（机上＋実機）

WSFCがクォーラム喪失でオフラインになった場合は手動介入が必要になり得る点が明記されているため、「自動で何とかなる」という前提で手順を省略しないことが重要です。

チェックリスト：設計レビューで確認すべき項目

観点	確認ポイント	よくあるNG
障害モデル	「ノード故障」か「サイト故障」か、どちらを自動化したいかが明確	奇数ノードだからOK、とだけ判断
ウィットネス	第三拠点/クラウド等、両サイトと運命共同体にならない場所	本番DC内のファイルサーバに置いて満足
投票設計	動的クォーラム/動的ウィットネスを踏まえ、同時多発障害で止まる前提を理解	ウィットネスが常に1票と思い込む
AG構成	自動フェールオーバーは「同期コミット＋AUTOMATIC＋健全同期」が条件	DRを非同期のまま「自動で行くはず」と誤解
接続	マルチサブネットのListener/DNS/ロードバランサ切替を含めた復旧動線	DBだけ切替できればアプリが繋がると思う

まとめ：2+1のままなら“自動DR”ではなく“止まりにくさ＋復旧しやすさ”に寄せる

本番DCに2ノード、DRに1ノードという3ノード構成は、ノード故障に対する高可用性（HA）を比較的低コストで実現できます。一方で、災害で本番DCを失うと「2票が一度に消える」ため、クォーラムの観点ではDR側が自動継続できないケースが出ます。

ウィットネスは有効な選択肢ですが、万能薬ではありません。どこに置くか（第三者の1票になるか）と、どこまで自動化するか（WSFC＋SQL両面の条件）をセットで決め、2+1を採るなら「止まりにくい設計」と「速く復旧できる運用」を最優先にすると失敗しにくくなります。