MENU

Storage Spaces DirectでSSDとHDD混在の2ノード構成は可能？SBCとの違いとS2Dキャッシュの仕組みを徹底解説

Hyper-V

vSAN から Hyper-V＋Storage Spaces Direct（S2D）へ移行する際、「SSD と HDD を混在させた 2 ノード構成は本当にできるのか」「キャッシュはどう動くのか」でつまずきがちです。結論から言うと、その構成は実現可能で、混乱の原因は “Storage Bus Cache（SBC）” と “S2D のキャッシュ” を同一視してしまう点にあります。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

想定している構成は、S2D でよくある 2 ノード設計

今回の前提は、各ノードに「HDD 3 本＋SSD 3 本」を搭載した 2 ノードの Hyper-V クラスタを作り、別途 3 台目のサーバーをクォーラム（Witness）兼 管理用にする、というものです。これは S2D で現実的かつ一般的な設計パターンです。

要素今回の案設計上のポイント
クラスタ構成2 ノード冗長化は基本的に 2-way mirror（2 方向ミラー）で考える
ディスク構成SSD＋HDD 混在（ハイブリッド）SSD がキャッシュ、HDD が容量、という役割分担が自然
クォーラム別サーバーで Witness2 ノードは Witness が実質必須（後述）

混乱の正体：Storage Spaces と Storage Spaces Direct（S2D）は “似て非なるもの”

名前が似ているため混同されやすいのですが、キャッシュの話はここを切り分けると一気に整理できます。

項目記憶域スペース（Storage Spaces）記憶域スペース ダイレクト（S2D）
前提基本は単一サーバー内で完結フェールオーバー クラスター前提（複数ノード）
用途単体サーバーのソフトウェア RAID 的な使い方HCI（Hyper-V など）向けの分散ストレージ
“SBC” の位置づけ使う（条件付き）使わない（S2D は別の仕組みを持つ）

Storage Bus Cache（SBC）は “クラスター向けの機能” ではない

ドキュメントに出てくる「SSD＋HDD 混在では SBC が必要」という文脈は、“単体サーバーの Storage Spaces（非 S2D）”側の話として読むのがポイントです。実際、Microsoft Learn の SBC の説明では、SBC はフェールオーバー クラスター機能のインストールは前提になり得る一方で、サーバー自体がフェールオーバー クラスターのメンバーである場合は使用できないことが明記されています。

つまり、S2D を組む場面で「SBC を有効化しなきゃいけないのでは？」と悩む必要はありません。S2D では SBC を使わず、S2D 側のキャッシュ／階層化機構に任せる、という整理になります。

S2D のキャッシュはどう動く？（SSD＋HDD 混在の挙動を具体化）

S2D には、パフォーマンスを上げるための組み込みのサーバー側キャッシュがあり、デプロイ時に自動構成されることが基本です。さらに、複数種類のドライブがある場合は、最速の種類のドライブがキャッシュとして自動選択され、残りが容量側になります。

まず押さえるべき “役割分担”

層今回（SSD＋HDD）での典型主な役割
キャッシュ層SSD読み取り／書き込みの高速化、HDD へのランダム I/O を吸収
容量層HDDデータの主な格納先（実効容量の大半）

Microsoft Learn の説明でも、SSD＋HDD の場合は “SSD が HDD のキャッシュとして機能する” こと、そしてハイブリッド（HDD をキャッシュする）ケースでは読み取りと書き込みの両方がキャッシュされることが示されています。

書き込みの流れ（2 ノードの 2-way mirror を前提）

  1. VM から書き込みが発生すると、まず各ノード側でキャッシュ（SSD）に着地します。
  2. 2-way mirror の場合、同じデータが別ノード側にも複製されるため、結果として “両ノードの SSD 側に書き込みが入る” イメージになります（どちらかが落ちても整合性が取れるようにするため）。
  3. その後、S2D がバックグラウンドで “容量層（HDD）へ移す（デステージ）” を進め、SSD 側の空きを作ります。

ここで重要なのは、S2D のキャッシュはストレージの冗長性（ミラー等）と矛盾しない形で動くことです。S2D のキャッシュはドライブレベルで実装され、S2D の回復性（サーバーを跨いでコピーを保持する考え方）と整合するよう設計されています。

読み取りの流れ（“よく読むものほど SSD に寄る”）

  • 最近よく読まれるデータは SSD キャッシュ側に残りやすく、読み取り遅延を下げます。
  • HDD のランダムアクセス（シーク／回転待ち）がボトルネックになりやすいワークロードほど、体感が出やすいです。

「SSD 3 本＋HDD 3 本」をどう使うのが現実的？（設計パターン）

同じ “SSD＋HDD 混在” でも、SSD の使い方には温度差があります。まずは運用のシンプルさを優先して設計し、性能が足りない場合にチューニングするのが失敗しにくいです。

パターンSSD の役割HDD の役割向いているケース注意点
シンプル運用（おすすめ）キャッシュ（自動選択）容量まず堅実に動かしたい／運用人数が少ない実効容量はほぼ HDD 合計がベースになる
性能寄り（SSD も容量に混ぜる）キャッシュ＋（一部）容量容量ホットデータを SSD 側に寄せたい設計が難しく、期待値調整が必要

なお、S2D のドライブ選択では「複数種類のドライブがある場合、最速の種類がキャッシュ、残りが容量」という基本原則があります。SSD＋HDD の場合は SSD がキャッシュ、HDD が容量、という分かりやすい分担になりやすいです。

容量見積もりの考え方（2 ノード 2-way mirror の “現実”）

vSAN から移行する場合に見積もりでズレやすいのが “実効容量” です。2 ノードで 2-way mirror を選ぶと、基本的に生容量の約 1/2 が実効容量になります（メタデータや予約領域などのオーバーヘッドも加味して、少し目減りします）。

例（各ノード）生容量（合計）2 ノード合計 生容量2-way mirror 実効容量の目安
HDD 8TB × 3 本24TB48TB約 24TB から開始（＋オーバーヘッド考慮）
SSD 1.92TB × 3 本（キャッシュ運用）5.76TB11.52TBキャッシュ用途が主なら “実効容量” としては見込まない考え方が安全

Microsoft Learn でも、複数種類ドライブ構成では最速ドライブがキャッシュに使われ、残りが容量になり、キャッシュ内のデータは別途保持またはデステージされるため、キャッシュ自体は “容量を増やすもの” ではないという趣旨が説明されています。

2 ノード構成で Witness が重要な理由（3 台目サーバー案の妥当性）

2 ノードはノード数が偶数のため、障害時に「どちら側が正しいクラスターか」を判断する票（Vote）が不足しがちです。Microsoft Learn でも、投票ノードが偶数のクラスターでは Witness を構成すべきであり、Witness の票によって “半数が落ちても継続できる” ことが説明されています。

さらに S2D のデプロイ手順では、2 サーバー（2 ノード）構成は Witness が必須で、片方がオフラインになると残りも利用不可になり得る旨が明記され、Witness としてはファイル共有 Witness または Cloud Witness を利用できる、とされています。

“3 台目サーバーをクォーラム兼管理用” はあり？

設計としては十分ありです。特にオンプレ中心で、Cloud Witness を使わない方針なら、管理用サーバーにファイル共有 Witness を持たせるのはよくある落としどころです。

Witness 方式メリット注意点今回との相性
ファイル共有 Witnessオンプレだけで完結、構成が分かりやすいWitness 用の SMB 共有は “専用” にするのが推奨◎（3 台目サーバーで実現しやすい）
Cloud Witnessサーバー追加不要、拠点分離しやすいインターネット到達性と運用ポリシー次第○（ポリシーが許せば強い）

参考：ファイル共有 Witness 設定の最小イメージ

GUI（Failover Cluster Manager）でもできますが、作業標準化のために PowerShell 例も置いておきます。

# 例：ファイル共有 Witness を設定
Set-ClusterQuorum -Cluster <ClusterName> -FileShareWitness \\<WitnessServer>\<ShareName>

ファイル共有 Witness は SMB 共有を使ってクラスター情報を保持する方式であることが Microsoft Learn に説明されています。

“S2D のキャッシュ” と “SBC” を比較すると腹落ちが早い

観点Storage Bus Cache（SBC）S2D の組み込みキャッシュ（記憶域プール キャッシュ）
主戦場単体サーバーの Storage Spacesクラスター前提の S2D
フェールオーバー クラスタークラスター“メンバー”では使用不可クラスターで使うための仕組み（自動構成が基本）
混在（SSD＋HDD）の扱い構成条件に依存SSD がキャッシュ、HDD が容量になりやすい（自動選択）
運用の考え方有効化・設定を意識する場面があるまずは “任せる” が基本。必要時に設計・チューニング

構築・移行前に押さえるチェックポイント（ハマりどころ回避）

SSD＋HDD 混在の S2D は成立しますが、検証不足だと「思ったより遅い」「ディスクが想定の役割にならない」などで時間を溶かしがちです。移行前に、次の観点だけは押さえておくと安全です。

チェック項目見るべきポイントなぜ重要か
ディスクの接続モードHBA / パススルー前提（不要な RAID 構成を外す）S2D が物理ディスクを直接制御できないと設計どおりに動かない
SSD の “役割”キャッシュとして認識されるか、混在時の自動選択が効いているか最速ドライブがキャッシュ、残りが容量という前提で性能が決まる
Witness の配置クラスターノードと同一障害ドメインに置かない2 ノードでは Witness が可用性の分岐点になる
容量計画2-way mirror の実効容量（約 1/2）＋余裕移行後に “容量が足りない” は最も痛い

2 ノードで “もう一段” 守りたいなら Nested resiliency も選択肢

2 ノードの 2-way mirror は「ノード障害」には強い一方で、同時多発（例：片ノード障害＋別のディスク障害）のようなケースでは、要件によって不安が残ることがあります。そこで候補になるのが Nested resiliency です。

Microsoft Learn では Nested resiliency を「2 サーバークラスターで、複数のハードウェア障害が同時に起きてもストレージ可用性を失いにくくする機能」と説明しており、適用条件として “2 ノードであること” などが示されています。

ただし、Nested resiliency は設計・運用が少し複雑になります。最初の移行では 2-way mirror＋適切な Witness で堅実に立ち上げ、障害要件（許容停止時間／許容データ損失／ディスク本数の余裕）を見ながら段階的に検討すると現実的です。

よくある質問（この相談で詰まりやすい点だけ）

「SSD＋HDD 混在だと SBC が必要」って結局どういう意味？

それは主に “単体サーバーの Storage Spaces” 文脈で語られることが多く、S2D クラスターの話にそのまま当てはめると混乱します。SBC 自体は “フェールオーバー クラスターのメンバーでは使えない” と明記されています。

S2D のキャッシュは自分で設計しないとダメ？

まずは不要です。S2D はデプロイ時にキャッシュを自動構成し、複数種類ドライブがある場合は最速ドライブをキャッシュに選ぶことが説明されています。最初は “設計しすぎない” 方が成功率が上がります。

2 ノードで 3 台目サーバーを置くのは必須？

“3 台目サーバー” が必須というより、Witness が必須に近いです。2 サーバー構成は Witness がないと片側停止で全体が不安定になり得ることがデプロイ手順に書かれています。実現手段として「管理用サーバーにファイル共有 Witness を置く」でも、「Cloud Witness」でも成立します。

まとめ：今回の構成案は成立する。悩むべきは SBC ではなく “S2D 前提の設計”

  • 「SSD 3 本＋HDD 3 本 × 2 ノード」の S2D（ハイブリッド）構成は実現可能で、設計としても一般的です。
  • 混乱の原因になりがちな Storage Bus Cache（SBC）は、S2D クラスターで使う前提の機能ではありません（クラスターのメンバーでは使用不可と明記）。
  • S2D は組み込みキャッシュを自動構成し、混在時は最速ドライブ（SSD）がキャッシュ、残り（HDD）が容量になりやすい、という設計思想です。
  • 2 ノードは Witness の設計が可用性の肝。ファイル共有 Witness または Cloud Witness を早い段階で設計に入れるのが安全です。
  • より強い耐障害性が必要なら、2 ノード向けの Nested resiliency も選択肢になります。
Hyper-V
Hyper-V フェールオーバークラスター Storage Spaces Direct Storage Bus Cache Witness

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次