ReFS・CSVとS2Dボリューム設計 — ミラー/パリティの選び方

Storage Spaces Direct(S2D)のボリューム設計は、ミラーとパリティのどちらを選ぶかで性能も容量も大きく変わります。Windows Server 2025での実構築を踏まえ、リサイリエンシ・ReFS・CSVキャッシュ・ボリュームサイズの勘所を一次情報つきで整理します。

Storage Spaces Direct(S2D)のボリューム設計は、「とりあえず3wayミラー」で済ませてしまいがちですが、そこにこそ性能と容量のトレードオフが凝縮されています。ミラーかパリティか、ReFSかNTFSか、CSVキャッシュをいくら積むか、ボリュームを何TBで切るか。どれも後から変えづらく、稼働後のIOPSと使用可能容量を直接左右します。本記事では、実際にWindows Server 2025 DatacenterでS2Dを構築した経験を踏まえ、Microsoft Learnの一次情報にあたりながら、現場でハマる勘所を整理します。です・ます調で、ただし濃く。

01リサイリエンシの全体像 — ミラーとパリティ

S2Dのフォールトトレランスは、RAIDに似ていますが、ドライブ単位ではなくサーバー(フォールトドメイン)をまたいで分散され、ソフトウェアで実装される点が本質的に異なります。方式は大きく「ミラー」と「パリティ(イレイジャーコーディング)」の2系統です。

2wayミラー：全データを2コピー。容量効率50%。最低2フォールトドメイン(=2サーバー)。1障害まで耐える。
3wayミラー：全データを3コピー。容量効率33.3%。最低3サーバー。2障害まで耐える。
デュアルパリティ：Reed-Solomonで2つのパリティを保持。3wayミラーと同じ2障害耐性を、より高い容量効率で実現。最低4サーバー。効率は4サーバーで50%、規模拡大とともに最大80%まで向上。

効率と障害耐性の関係は下表のとおりです(Microsoft Learn「Fault tolerance and storage efficiency」より)。

図1：S2Dリサイリエンシ別の容量効率・障害耐性・性能の位置づけ

現場のコツ：サーバーが3台以上あるなら、2wayミラーではなく3wayミラーを推奨、というのがMicrosoftの一貫した姿勢です。シングルパリティ(RAID-5相当)は3サーバーで使えますが、1障害しか耐えられず、同じ規模なら3wayミラーの方が耐性が高いため「サポートはされるが非推奨」。設計レビューでシングルパリティが出てきたら、まず理由を確認します。

02デュアルパリティの効率は「規模」と「ドライブ種別」で変わる

デュアルパリティの容量効率を「50%」と暗記していると足をすくわれます。効率はフォールトドメイン数と、ハイブリッド(HDD+SSD)か全フラッシュ(SSD)かで段階的に上がるためです。Microsoft Learnの表を抜き出すと、ハイブリッドでは4〜6サーバーでRS 2+2(50.0%)、7〜11サーバーでRS 4+2(66.7%)、12サーバー以上でLRC(8,2,1)の72.7%。全フラッシュはさらに効率がよく、9サーバーでRS 6+2(75.0%)、16サーバーでLRC(12,2,1)の80.0%に達します。

「LRC(ローカル再構成コード)」はMicrosoft Researchの技術で、大規模時にエンコード/デコードを小さなグループに分割し、書き込みや障害回復のオーバーヘッドを減らします。HDDはグループサイズ4シンボル、SSDは6シンボル。
つまり同じ台数でも全フラッシュの方が容量効率が高くなるケースがあります。容量見積もりでは「何台か」だけでなく「ドライブ構成は何か」まで固めてから計算してください。

現場のコツ：効率のパーセンテージやレイアウト(RS 2+2 / RS 4+2 / RS 6+2 / LRC)は台数境界で切り替わり、バージョンによっても細部が動きます。提案書に効率値を書くときは、必ずMicrosoft Learnの最新表で当該台数・ドライブ種別の値を確認する運用にしておくと、後の容量トラブルを防げます。

03ミラー加速パリティ — 速さと容量の「いいとこ取り」の実態

ミラー加速パリティ(Mirror-accelerated parity)は、1つのボリュームをミラー部分とパリティ部分に分ける方式です。書き込みはまず高速なミラー部に着地し、後からバックグラウンドでパリティ部へ移動されます。ReFSがボリュームを2つの論理ティア(パフォーマンスティア/キャパシティティア)に分割し、書き込みは常にパフォーマンスティアで受ける、という仕組みです。ミラー加速パリティを使うには最低4フォールトドメイン(4サーバー)が必要です。

ただし、これは万能ではありません。Microsoft Learnは明確に「ミラー加速パリティはアーカイブ・バックアップ用途にのみ推奨。仮想化やランダムIOの多い高性能ワークロードには3wayミラーを推奨」と述べています。性能はデュアルパリティの最大2倍にはなり得るものの、ミラーには遠く及びません。

設計のキモはミラー部のサイズです。「一度に発生する書き込み量(例：1日1回のバックアップ)がミラー部に余裕をもって収まる」よう見積もります。Microsoftの例では「1日100GBを取り込むなら、ミラーを150〜200GB、残りをデュアルパリティ」。
取り込み途中で書き込み性能が急落(例：400MB/s→40MB/s)したら、それはミラー部が枯渇したサイン。ミラー部を拡大するか、そもそも3wayミラーへ切り替える判断材料になります。

04ReFSを選ぶ理由 — 整合性ストリーム・ブロッククローン・Sparse VDL

S2DのボリュームはReFSでフォーマットするのが基本です。Microsoft Learnも「仮想化ワークロードやネットワーク接続ストレージにはReFSを推奨」としています。理由は、Hyper-V基盤で効いてくる次の3点です。

整合性ストリーム(Integrity-streams)：メタデータには常にチェックサム、ファイルデータにはオプションでチェックサムを付与し、破損を検出。ミラー/パリティスペースと組み合わせると、代替コピーからオンラインで自動修復します。加えて「スクラバー」が定期的にボリュームを走査し、潜在破損を先回りで修復します。
ブロッククローン(Block cloning)：コピー操作を高速化し、Hyper-Vのチェックポイントのマージを低負荷で瞬時に行えます。運用で地味に効きます。
Sparse VDL：ファイルの高速ゼロ化により、固定VHDの作成が「数十分から数秒へ」短縮されます。

現場のコツ：整合性ストリームは全ファイルデータに有効化するとオーバーヘッドがあります。VHDXのような高性能ランダムワークロードでは、ファイルデータの整合性ストリームをオフ(メタデータのみ保護)にする構成が現場では一般的です。ReFSはODX・重複排除の一部・トランザクション・ディスククォータなどNTFSにある機能を持たないため、SANでThin Provisioning/TRIM/ODXが要る場合はNTFSを選ぶ、という切り分けも押さえておきます。

05CSVとI/Oモード — ReFSは「リダイレクト」になる、という落とし穴

S2DのボリュームはCSV(Cluster Shared Volume)として全ノードから同時にRead/Writeアクセスされ、C:\ClusterStorage\配下に見えます。ここで実務上とても重要なのがI/Oモードです。

CSVには「Direct I/O」と「リダイレクトI/O」があり、後者はコーディネーターノード(所有ノード)経由でI/Oが流れます。Microsoft Learnは次のように整理しています。

SANボリューム：NTFSでフォーマットしてからCSV化する。NTFSはSAN接続でDirect I/Oが有効になり性能が良い。SAN上のReFSはリダイレクトI/Oになるため注意。
S2Dボリューム：ReFSでフォーマットしてからCSV化する。ReFSは整合性・ブロッククローン・S2D向け最適化を提供する。

つまり「ReFSが常に正解」ではなく、SAN上ではReFSがDirect I/Oを使わない点が落とし穴です。S2Dのローカル分散ストレージ上ではReFSが推奨ですが、フロントエンドのSAN LUNをCSVにする設計では、Direct I/Oの性能メリットを取りにNTFSを選ぶのが定石です。ちなみに、CSVの所有権はWindows Server 2012 R2以降、ノード間で自動的に均等分散され、フェイルオーバーやノード再参加時に再バランスされます。1ノードあたり最低1つのCSVを作るのは、この所有権を均等に散らすためでもあります。

06CSVキャッシュ — Hyper-Vなら必ず効かせる読み取りキャッシュ

CSVキャッシュは、システムメモリ(RAM)を使ってブロックレベルの読み取り専用・アンバッファードI/Oをキャッシュする機能です。VHD/VHDXはアンバッファードI/Oでアクセスされ、標準のキャッシュマネージャーを迂回するため、CSVキャッシュがそこを補います。読み取りは高速化するが書き込みはキャッシュしないのがポイント。MicrosoftはすべてのHyper-VおよびScale-Out File Server構成で有効化を推奨しています。

Windows Server 2019・Azure Local以降はデフォルトで有効、1GiB割り当て済み。Windows Server 2016ではデフォルト無効(0)で、有効化には手動設定が必要でした。
サイズはBlockCacheSize(クラスター共通プロパティ、単位MB)で調整します。設定例は(Get-Cluster).BlockCacheSize = 512。多くのクラスターでは512MBが推奨値とされます。
確認はGet-ClusterSharedVolume | Select Name, BlockCacheSize。Windows Server 2012 R2以降は割り当て変更後の再起動は不要です。
物理RAMに対する上限は、2012 R2以降で最大80%(2012では20%)。メモリに余裕のあるSOFSでは大きく積むと効果的です。

現場のコツ：読み取りが多いVDIや、ブートストームが起きる朝の一斉起動には、CSVキャッシュの増量が素直に効きます。ただしHyper-Vホストのメモリは仮想マシンに割り当てたい資源でもあるため、盲目的に増やさず、Cluster CSV Volume Cacheのパフォーマンスカウンター(ヒット/ミス)を見ながら調整するのが実務です。

07ボリュームサイズと本数、そしてリザーブ容量

ボリュームは「大きく1本」ではなく、設計の勘所があります。Microsoft Learnのガイダンスを整理します。

本数：最低でも1ノードあたり1ボリューム(所有権を均等分散するため)。総数はクラスターあたり64ボリュームまでに抑えることを推奨。
サイズ：各ボリュームは64TBまでに制限することを推奨(Azure Local)。VSS/Volsnapに依存するバックアップを使う場合は10TBまでに抑えると性能・信頼性が向上。Hyper-V RCT APIやReFSブロッククローン、ネイティブSQLバックアップAPIを使うなら32TB以上でも良好とされます。
フットプリント：ボリュームの「サイズ(使用可能容量)」と「フットプリント(プールを占有する物理容量)」は別物です。3wayミラーならフットプリントはサイズの3倍。プールに全ボリュームのフットプリントが収まる必要があります。
リザーブ容量：ドライブ障害後にその場(in-place)で並列修復できるよう、1サーバーあたりキャパシティドライブ1本分、最大4本までをプールに未割り当てで残すのが推奨。これで交換前でも即時修復が成立します。

図2：ボリュームのサイズとフットプリント、プール内のリザーブ容量の関係

08実務での使い分け — 1クラスターに複数の顔を持たせる

ファイルシステムとリサイリエンシは同一クラスター内でボリュームごとに混在させられます。これが設計の自由度の源です。Microsoft Learnの4サーバー例に沿うと、次のような割り当てが定石です。

高性能が最優先(SQL Server、レイテンシに厳しいHyper-V VM)：ReFS + 3wayミラー。ランダムIOPSを最大化。
容量が最優先(データウェアハウス、コールドストレージ、書き込みが稀なデータ)：NTFS(重複排除のため) + デュアルパリティ。
大きな連続書き込み(アーカイブ、バックアップターゲット)：ReFS + ミラー加速パリティ。ミラー部を日次取り込み量に合わせて確保。

2サーバー構成では、本番はネステッドリサイリエンシ(ネステッド2wayミラーで効率25%、ネステッドミラー加速パリティで約35〜40%)が推奨されます。2wayミラー単独よりも耐性が高く、1ノード再起動中の障害にも耐えられるためです。台数・ドライブ種別・現行バージョンで最適解は動くので、Azure Local(旧Azure Stack HCI)とWindows Serverのどちらで組むかも含め、Microsoft Learnで最新仕様を確認しながら詰めるのが安全です。

こうしたオンプレHyper-V/S2Dの物理層の理解は、そのままAWS移行の設計品質に直結します。ミラー/パリティの選定でやっているのは「性能・容量・耐障害性のどれを優先するか」の意思決定であり、これはEBSのボリュームタイプ選定やマルチAZ設計でも同じ判断軸になります。私たちがRAID構成からEBSへの移行やオンプレサーバーのEC2サイジングで外さないのは、オンプレの実装を最下層まで理解した上でクラウド側にマッピングしているからです。関連する設計判断はHyper-Vライブマイグレーション設計やフェイルオーバークラスタリングのクォーラムとCSVもあわせてご覧ください。

—まとめ

S2Dのボリューム設計は、「ミラーで速く/パリティで安く/ミラー加速パリティで大きな連続書き込みを吸収」という三択を、ワークロードごとに使い分ける作業です。ReFSは仮想化ワークロードで真価を発揮しますが、SAN上ではDirect I/Oを使わないという例外を忘れないこと。CSVキャッシュはHyper-Vで必ず効かせ、ボリュームは1ノード1本以上・64TBまで・リザーブは1サーバー1本を守る。数値やレイアウトはバージョンと構成で動くため、提案の前に必ずMicrosoft Learnの最新を当たる——これがハマらないための最短ルートです。EMWは、この物理層を実際に手で組んだ経験を土台に、オンプレ運用からAWS移行までを一気通貫でご支援します。導入事例もご参照ください。

—参考(一次情報)

S2DやHyper-V基盤の設計・移行でお困りの際は、実構築経験のあるEMWまでお問い合わせください。

相談する

← ブログ一覧へ戻る