Windows Serverのファイル共有監視(File Share Witness)とは?クォーラムシステムの仕組みと設定方法を解説

高負荷なサービスやWebサイトをサーバーでホストする場合、通常は複数の負荷分散ノードで構成される冗長設計が採用されます。これにより、1つのノードに障害が発生しても、他のノードが処理を引き継ぎ、サービスを継続できます。Windows Server 2019/2016では、このノード間のバランシングはクォーラム(過半数)システムによって実現されています。本記事では、ファイル共有監視(File Share Witness)機能について詳しく解説します。

ファイル共有監視とクォーラムシステムの関係

クォーラムシステムは投票ベースの仕組みで、障害発生時にもクラスタが正常に動作し続けるために、一定数のノードの存在が必要となります。しかし、総票数が「偶数」になると、投票が膠着して判断できなくなるケースがあります。投票の目的はシンプルで、特定のノードに過剰な負荷がかからないようにすることです。

ここでファイル共有監視を導入すると、タイブレーカー(決定打)として機能します。必要に応じて追加のクォーラム票を供給できるため、サイト全体に障害が発生した場合でも、クラスタの稼働を継続させることが可能になります。

例えば、4つのノードが2対2で分散している構成を想定してみましょう。1つのノードに障害が発生した場合、残りの2ノードでバランスを取る必要があります。しかし、2対2の形式では投票が停滞してしまいます。ここでIT管理者がファイル共有監視を展開し、既存の2ノード側に票を追加できれば、クォーラムに達し、クラスタは問題なく動作を続けられます。

Windows Server 2019/2016におけるファイル共有監視機能の概要

ファイル共有監視(FSW)が機能するための重要な要件のひとつは、ドメインに参加しており、同じフォレストに属していることでした。これは、フェールオーバークラスタがクラスタ名オブジェクト(CNO)を利用して、Kerberos認証経由で共有に接続・認証するためです。しかし、以下のような理由により、この条件を満たせない場合があります。

• インターネット接続が不安定、または利用できない
• ドメインコントローラーが利用できない
• Active DirectoryにCNOオブジェクトが存在しない
• ディスク監視用の共有ドライブがない

こうした状況を考慮し、MicrosoftはWindows Server 2019において、ドメインに属していなくてもクォーラムシステムが機能する新機能を追加しました。これは、FSWが接続されるサーバー上のローカルユーザーアカウントを使用することで実現されています。

IT管理者は、ローカル(管理者権限を持たない)ユーザーアカウントを作成し、そのアカウントに共有への完全な権限を付与したうえで、クラスタをその共有に接続できます。具体的な手順は以下の通りです。

• サーバー(SERVER)にログオンし、ローカルユーザーアカウントを作成します(例:FSW-ACCT)
• サーバー上にフォルダを作成し、共有として公開します
• ローカルユーザーアカウント(FSW-ACCT)に、共有への完全な権限を付与します
• クラスタノードのいずれかにログインし、以下のPowerShellコマンドを実行します

Set-ClusterQuorum -FileShareWitness \\SERVER\\SHARE -Credential $(Get-Credential)

• アカウントとパスワードの入力を求められるので、「SERVER\FSW-ACCT」と対応するパスワードを入力します。

さらに、予備のサーバーを用意できない環境では、ルーターに接続したUSBドライブを代用することも可能です。接続後、共有名、ユーザー名、アクセス用パスワードを設定すれば利用できます。なお、この方法はSMB 2.0以降に対応しています。