Skip to content

MS_MSCSWSFC

Jump to bottom
nishi_74322014 edited this page Aug 12, 2026 · 1 revision

MSCS/WSFC

概要

  • ステートレス・システム（複数インスタンス）の負荷分散が可能。

  • ステートフル・システムのフェイル・オーバーも可能になっている。

  • インスタンス間の状態共有はできないので、

    • 1 インスタンスの Active-Passive 構成（フェイル・オーバー）。
    • n インスタンスの Active-Active 構成（負荷分散）。

    が可能。

移行メモ（名称）: MSCS = Microsoft Cluster Service（Windows Server 2003 まで）、
WSFC = Windows Server Failover Clustering（Windows Server 2008 以降）。
名称が変わっただけで、同じ機能の系譜である。

クラスタとは、

  • ネットワーク的には単一のサーバとして見える複数のサーバであり、

    • SAN 上の「共有ディスク（クォーラム・ボリューム）」に接続されていて、
    • ステータス情報をネットワーク経由で常時共有している。

  • クラスタ・サービスのポイントには、

    • 複数のシステムでディスクを共有する。
    • 複数のシステムに仮想的な単一の名前とアドレス（IP アドレス）を付ける。
    • クライアントからこの仮想的な名前またはアドレスでアクセスする。

    などの点が上げられる。

クラスタ アプリケーション

アクティブ - パッシブ

  • アプリケーションの観点からすると、各アプリケーションは
    クラスタ内の 2 つ以上のサーバにインストールされている。
  • しかし、アプリケーションの 1 つのインスタンスだけが
    「アクティブ」サーバで稼働しており、
    これが「共有ディスク（データ・ボリューム）」に独占的にアクセスして
    すべてのクライアント・リクエストにサービスを提供する。
  • 他のサーバはアプリケーションのそのインスタンスに関して「パッシブ」であり、
    従ってクラスタは本質的には「負荷分散・拡張性」を提供しない。

アクティブ - アクティブ

  • しかし、クラスタ内の他のサーバは、同じアプリケーションの他のインスタンスや、
    別のアプリケーションに関しては「アクティブ」で、
    各「アクティブ・ノード」は別のディスクに独占的にアクセスできる構成もある。
  • この構成はしばしば「アクティブ－アクティブ」と呼ばれるが、
    「共有ディスク（データ・ボリューム）」に接続する 2 台以上のサーバが
    「負荷分散・拡張性」を提供することはない。

補足（この段落が最重要）: 「アクティブ－アクティブと呼ばれるが
負荷分散・拡張性を提供することはない」という指摘は、
WSFC を理解する上で最も重要な一点である。

WSFC の Active-Active は

  • 「同じサービスを 2 台で分担する」のではない
  • 「別々のサービス（別インスタンス）を、それぞれ別ノードで動かす」
    という意味である

つまり「ノード 1 で SQL インスタンス A、ノード 2 で SQL インスタンス B」
であって、インスタンス A の負荷が 2 台に分かれるわけではない。

「Active-Active」の意味
NLB 同一サービスへのリクエストを全ノードで分担（本当の負荷分散）
WSFC 異なるリソースを別ノードで担当（遊休ノードを減らすだけ）

見積もりや性能設計で取り違えると、
「クラスタにしたのに性能が上がらない」という話になる。

構成

  • 共有ディスクが必要になる。
  • n 物理ノード ＋ 1、n インスタンスの複雑な構成も取れる。

MSCSの構成図

共有ディスク

  • 共有ディスク

    • データ・ボリューム
    • クォーラム・ボリューム

  • 3 つの「物理サーバ」はいずれも、総合的なクラスタ構成と状態情報を格納する
    「共有ディスク（クォーラム・ボリューム）」にアクセスできる。

    • フェイル・オーバー（フェイル・バック）発生時に、MSCS は
      クォーラム・ボリュームを用いて、どの「物理サーバ」をアクティブにして
      データ・ボリュームに独占的にアクセスさせるかを決定する。
    • 「アクティブ・ノード」に障害が発生した場合、「パッシブ・ノード」が
      自動的に引き継いで新しい「アクティブ・ノード」となる。

補足（クォーラムの本質はスプリット ブレイン対策）: クォーラムは
「単なる設定置き場」ではなく、
ネットワーク分断時に「どちらが生き残るか」を決める仕組みである。

ネットワークが分断されると、両ノードが「相手が死んだ」と誤認し、
両方がデータ ボリュームに書き込む危険がある
（スプリット ブレイン。データが壊れる）。
これを防ぐため、過半数（quorum）の投票を得た側だけが動く。

クォーラム モード 投票者
ノードのみ ノードだけ（奇数ノード向け）
ノード + ディスク（従来） ノード + クォーラム ディスク
ノード + ファイル共有監視 ノード + 第三のサイトの共有フォルダ
ノード + クラウド監視 ノード + Azure Storage（現在の推奨）

2 ノード構成では投票が同数になり得るため、
必ず第 3 の監視（ディスク / ファイル共有 / クラウド）を置くのが鉄則である。
クラウド監視は Azure Storage アカウントを使うもので、
第 3 サイトの機器が不要なため現在よく使われる。

フェイル・オーバー時の動作

  • 「物理サーバ 1、2、3」はそれぞれネットワークで接続されており、
    これによってほかのサーバの状態を監視できる。
  • 3 つの「物理サーバ」はすべて SAN アダプタを備えており、
    SAN ストレージ・アレイに接続されている。

MSCSフェイル・オーバー処理の弱点

MSCS 方式には、次の弱点がある。

  • 「アクティブ・ノード」の CPU レジスタとメモリの内容は
    「パッシブ・ノード」に連続的にミラーリングされないため、
    アプリケーションやサービスは「パッシブ・ノード」上で起動する必要があり、
    ディスクに書き込まれた最後のトランザクションについてのみ最新の状態となる。

  • クライアントから見るとフェイル・オーバーは、一時的なネットワーク切断に見え、
    アプリケーションに再度接続し直す必要がある。

  • 「アクティブ・ノード」と「パッシブ・ノード」が共有ディスクを共有するので、
    完全に冗長ではない。
    しかしこの弱点は、RAID アレイに格納し、
    冗長なストレージ・コントローラとネットワーク接続を使用することで解決できる。

補足（アプリ側の設計が要る）: 2 番目の指摘は現在も重要で、
フェイル オーバーは無停止ではない（数十秒〜数分の断がある）。
アプリケーション側には

  • 接続の再試行（Polly等でリトライ + 指数バックオフ）
  • 冪等性（同じ処理が 2 回来ても壊れない）

が必要になる。SQL Serverなら
接続文字列に MultiSubnetFailover=True を指定すると
切り替えの検知が速くなる。

3 番目の「共有ディスクが単一障害点」という弱点は、
AlwaysOn 可用性グループ（共有ストレージ不要）で
構造的に解消された。

クラスタ対応アプリケーション

  • MSCS では、「ジェネリック・スクリプト」クラスタ・リソース・タイプにより、
    開発者はスクリプティング（VBScript や JScript）を用いて、
    いくつかの既存アプリケーションをクラスタ対応にすることができる。
    その際、C や C++ で特殊なアプリケーション・リソース DLL を書く必要はない。

  • 「アクティブ・ノード」の OS やハードウェアの障害が
    「パッシブ・ノード」へのフェイル・オーバーを引き起こすのと同様に、
    「クラスタ対応アプリケーション」の障害もフェイル・オーバーを引き起こせる。

  • クラスタ方式は、複製上の記録が同期しなくなることが許されない
    トランザクショナル・データベースに理想的である。
    SQL Serverと Exchange の各 Enterprise バージョンは
    「クラスタ対応アプリケーション」として設計されている。

その他

  • MSCS はサーバ・ファームよりも高価で SAN を必要とするが、
    業界標準のサーバを使用するため、ハードウェアにかかる費用が安価である。
  • Microsoft はハードウェア互換性リスト（HCL）に掲載された
    完全なクラスタ・ソリューションだけをサポートする。
  • MSCS では、クラスタを構成する各ノードに対し、順次 OS のアップグレードができる。
    これを「ローリング・アップグレード」（MS_RollingUpgrade.md）という。

変更点

なんとなく、フェイル・オーバー性能最優先ではなく、
クラウド環境でも動作するように、
仕組みが分散システムのような感じになってきている様に見える。

2003 → 2008

MSCS という名称が、WSFC に変更された以外は大きな変更点は見当たらない。

移行メモ（誤字）: 元ページの「フェイル・オーバー性能最優勢」は
「最優先」の誤記と解される。

補足（この見立ては当たっている）: 「分散システムのような感じに
なってきている」という観察は的確で、実際に次の方向へ進んだ。

世代 変化
2012 クラスターの共有ボリューム (CSV) で複数ノード同時アクセス
2012 R2 スケールアウト ファイル サーバー (SOFS)
2016 記憶域スペース ダイレクト (S2D) — 共有ストレージが不要に（HCI）
2016 クラウド監視（Azure Storage をクォーラムに）
2019 クラスター セット、AD 非依存クラスター

特に S2D（記憶域スペース ダイレクト） は本ページが弱点として挙げた
「共有ディスクが単一障害点」を解消するもので、
各ノードのローカル ディスクをソフトウェアで束ねて分散ストレージにする。
SAN が不要になるという点で、構成の前提が大きく変わっている。

参考

Tags: 移行, Windows, 冗長化

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally