Storage Spaces Direct(S2D)は「構築して終わり」ではなく、ドライブは必ず壊れ、更新は毎月やってきます。この記事では、実際にWindows Server 2025 DatacenterでS2Dを構築・運用してきた経験を土台に、ドライブ交換・修復ジョブ・CAU更新・容量計画といった運用の勘所を、Microsoft Learnの一次情報とともに整理します。
S2Dは、ドライブが壊れることを前提に設計された分散ストレージです。だからこそ「壊れた後にどう振る舞うか」を理解していないと、健全な自己修復を人間が邪魔してしまいます。ここでは日常運用で本当にハマるポイントを、コマンドと一次情報つきで整理します。なお本記事の値・仕様はバージョン依存のものを含むため、実機投入前に必ずMicrosoft Learnで最新を確認してください。Azure Local(旧Azure Stack HCI)とWindows Server版のS2Dはドキュメントが統合されつつあり、コマンド体系はほぼ共通ですが、サポート境界や既定値が異なる場合があります。
01ドライブが壊れたとき、S2Dは何を自動でやるか
まず押さえるべきは、S2Dはドライブ故障を自動でリタイア(Retire)・退避(Evacuate)するという事実です。Microsoft Learnの「Replace failed drives」は明快で、故障ドライブは自動的にRetiredステータスになり、容量バーが空になります。管理者がまずやるのは、コマンドを叩くことではなく、Windows Admin Centerのアラートで物理位置を確認し、対応するドライブのLight Onで場所を光らせ、物理交換することです。
交換後の流れも自動化されています。新しいドライブがプールに追加され、時間とともにアラートが消え、ボリュームはOKへ修復され、データが新ドライブへ自動的にリバランスされます。ここで人間が焦って手を出す必要は、基本的にありません。
AutoPoolが無効の可能性があります。Get-StorageSubsystem Cluster* | Get-StorageHealthSetting で System.Storage.PhysicalDisk.AutoPool.Enabled を確認し、False なら手動で Add-PhysicalDisk するか、Set-StorageHealthSetting -Value True で有効化します。ここを知らないと「交換したのに容量が増えない」で数時間溶かします。02手動でリタイアする — 計画的なドライブ入れ替え
予兆のあるドライブや、更新プログラムのある型番を計画的に抜きたいときは、自動故障を待たずに手動でリタイアします。Set-PhysicalDisk -FriendlyName <name> -Usage Retired でドライブに「新規割り当てを受けない」意図を設定し、退避が済んでから Remove-PhysicalDisk でプールから外します。
ここで絶対に守るべき前提があります。Remove-PhysicalDisk は、プールにこの削除を許容できる十分な空き容量がないと、データ損失を引き起こす可能性があります。つまりリザーブ容量(後述)が確保されていない状態での抜き取りは危険です。退避が完了して容量バーが空になったことを Get-PhysicalDisk で確認してから物理的に抜くのが鉄則です。
Remove-PhysicalDisk を呼んだ後、HealthStatus が Healthy なのに OperationalStatus が Removing from Pool, OK のまま張り付くことがあります。これは削除意図がHealthに保存されているためで、Microsoft提供の Clear-PhysicalDiskHealthData.ps1 でintentをクリアできます。「抜いたはずのディスクが幽霊のように残る」あるあるです。03ストレージジョブ — 修復とリバランスを読む
S2Dの自己修復・リバランスは「ストレージジョブ」として走ります。可視化の主役は Get-StorageJob です。ノードをメンテナンスから戻したときや、ドライブ交換後には、他ノードから足りないミラー/パリティのコピーを再同期するリペアジョブが自動的に始まります。次のノードを落とす前に、必ずこのジョブの完了を待つのが運用の基本動作です。
Get-StorageJob… 実行中の修復・リバランス・再同期の進捗を確認する。Get-VirtualDisk… 各ボリュームのHealthStatusがHealthyに戻ったかを確認する。- ジョブは
Suspended(一時停止)になってから再開することがあり、これは異常ではありません。
リバランス(最適化)は、スラブとそのコピーをドライブ間で移動させ、使用率を均等化する処理です。ノード追加やドライブ交換の後に走り、これも Get-StorageJob で見えます。注意したいのは、「Data Integrity Scan for Crash Recovery」はストレージジョブとして表示されない点です。進捗インジケータもないため、Get-ScheduledTask | ? State -eq running で走っているかを確認します。ここを知らないと「ジョブが空だから終わった」と誤判断して次の作業に進み、事故ります。
04Health ServiceとFaultで健全性を掴む
S2DにはHealth Serviceが組み込まれており、クラスタ全体の異常を「Fault(障害)」として集約します。個別ノードにSSHして回るのではなく、まず全体像を掴むのが正解です。PowerShellでは Get-StorageSubSystem Cluster* | Debug-StorageSubSystem を実行すると、S2Dクラスタ全体に影響する現在のFaultが返ります。「どのドライブが」「どのノードが」「なぜ」不健全なのかを、人間可読なメッセージで教えてくれます。
あわせて覚えておきたいのが、無視してよいイベントの見分けです。ノード再起動中に他ノードで Event ID 205 / 203(physical diskとの通信喪失)が出るのは正常な挙動で、Microsoft Learnも「安全に無視できる」と明記しています。逆に、Event 5120(CSVがSTATUS_IO_TIMEOUT c00000b5でpaused)が頻発する場合は、古い累積更新に起因する既知問題の可能性があり、対処が必要です。正常なノイズと本物の異常を切り分けられることが、S2D運用者の実力差になります。
05CAUによるローリング更新 — S2Dを止めずに毎月当てる
Windows更新は避けられませんが、S2Dで一台ずつ手で当てるのは危険です。Microsoftが推奨するのはCluster-Aware Updating(CAU)です。CAUは1ノードずつ、(1)メンテナンスモード投入 →(2)クラスタ役割の退避 →(3)更新適用 →(4)必要なら再起動 →(5)メンテナンス解除 →(6)役割の復帰 →(7)次ノードへ、という一連を自動でオーケストレーションします。
Hyper-Vのライブマイグレーションや、SMB透過フェールオーバーを使う継続的可用性ワークロードと組み合わせれば、CAUはクライアントへの可用性影響ゼロでクラスタ更新を完遂できます。ここがS2D + Hyper-Vの真骨頂です。Windows Server 2016以降のCAUはS2Dを認識し(ハイパーコンバージド/コンバージドいずれのデプロイでも対応)、各ノードのサスペンド時に基盤のクラスター化ストレージスペースがhealthyに戻るまで待ってから次のノードを止めます。人間が Get-StorageJob を睨みながら手動で回す必要がないのは、この協調のおかげです。
Get-CauRun。いきなり本番でなく、まずプレビュー(Invoke-CauScan相当)で対象更新を確認してから流すのが安全です。06リザーブ容量 — 修復の「置き場所」を必ず残す
S2D運用でもっとも設計思想が問われるのがリザーブ容量(予備容量)です。プールに未割り当ての空きを残しておくと、ドライブ故障後にボリュームが「その場(in-place)」で修復でき、故障ドライブを交換する前に、即座に・並列に・完全な冗長性まで復元できます。これが自動で走るのが、S2Dが堅牢たる理由です。
Microsoft Learnの推奨は具体的で、サーバーあたり容量ドライブ1本分、最大4本までをリザーブとして残すこと。例えば1TBの容量ドライブなら、2サーバーで2TB、3サーバーで3TB、4サーバー以上で4TBを予備に確保します。NVMe+SSD+HDDの3種混在クラスタでは、サーバーあたりSSD1本+HDD1本分(各最大4本)を推奨とされています。この最小推奨を満たしておけば、任意の1ドライブ故障後の即時in-place並列修復が保証されます。
07遅い・詰まる時の切り分け
「S2Dが遅い」と言われたとき、原因の大半はいくつかの定番に収束します。順に切り分けます。
- キャッシュが効いていない：クラスタログの
[=== SBL Disks ===]を見て、キャッシュドライブがCacheDiskStateInitializedAndBound(GUIDあり)になっているか確認します。CacheDiskStateNonHybridならキャッシュ未構成です。全ドライブが同種の場合、キャッシュは既定で無効です。 - 修復・リバランス中：
Get-StorageJobで大量の再同期が走っていれば、その間の性能低下は想定内です。ジョブ完了を待ちます。 - コピー方法が間違っている：大きなVHDをエクスプローラーやRobocopy/Xcopyでコピーすると遅くなります。これらはS2Dスタックを通らずローカルコピーのように振る舞うため、性能検証には
VMFleetとDISKPDを使うのが正解です。 - ファームウェア問題:特定NVMe(例:Intel P3x00系の旧ファーム)は「Lost Communication」「Detached」等を引き起こす既知問題があります。ドライブ/HBA/NICのファームは常に最新へ。
08よくある落とし穴
- メンテナンス手順を飛ばす:ノード再起動時は
Suspend-ClusterNode -Drainでドレインし、Enable-StorageMaintenanceModeでそのノードのディスクをストレージメンテナンスモードに入れます。Get-PhysicalDiskでOperationalStatusがIn Maintenance Modeを確認してからRestart-Computer。戻すときはDisable-StorageMaintenanceMode→Resume-ClusterNodeの順です。この手順を飛ばすと不要な修復ジョブが走ります。 - 「No Redundancy」で慌てる:再起動やクラッシュ後に仮想ディスクが
No Redundancyで上がらないことがあります。復旧にはDiskRecoveryActionを一時的に1にして起動し、修復完了後に0へ戻す、という正規手順があります。闇雲にディスクをオフライン/オンラインさせないこと。 - 「Detached」= DRTログ満杯:仮想ディスクが
Detachedになるのは、Dirty Region Tracking(DRT)ログが満杯のサインです。「Data Integrity Scan for Crash Recovery」スケジュールタスクの実行が必要で、数時間かかることもあります。途中でノードを再起動すると最初からやり直しになるため、走らせたら待ちます。 - HBAがRAIDモード:
Enable-ClusterS2Dが「unsupported media type」で失敗する典型が、HBAのRAIDモード設定です。S2DはHBAモード(パススルー)必須です。
こうしたオンプレS2D/Hyper-Vの「壊れ方と直り方」を体で知っていることは、実はAWS移行でも効きます。冗長性・修復・容量設計の勘所が分かっていれば、導入事例のようなEC2/EBSやFSxへの移行時に、オンプレ側の実性能・実冗長を正しく評価してサイジングできるからです。関連してRAID構成からEBSへの移行やオンプレサーバーのEC2サイジングもご覧ください。
—まとめ
S2D運用の要点は、「自動修復を信じて、邪魔しない」ことに尽きます。ドライブは自動でリタイア・退避され、リザーブ容量があれば交換を待たずin-placeで並列修復されます。人間がやるべきは、Get-StorageJob と Health ServiceのFaultで健全性を掴み、CAUで無停止のローリング更新を回し、リザーブ容量を設計時から死守すること。そして「No Redundancy」「Detached」「In Maintenance Mode」といったステータスの意味を正しく読み、正常なノイズと本物の異常を切り分けることです。EMWは実際にWindows Server 2025 DatacenterでS2Dを構築・運用し、Hyper-Vライブマイグレーション移行まで手掛けてきました。設計から運用、その先のAWS移行まで、手を動かすコンサルとして伴走します。
—参考(一次情報)
- Replace failed drives on Azure Local — Microsoft Learn
- Plan volumes on Azure Local and Windows Server clusters(リザーブ容量) — Microsoft Learn
- Storage Spaces Direct troubleshooting — Microsoft Learn
- Cluster-Aware Updating overview — Microsoft Learn
- Cluster-Aware Updating frequently asked questions(S2D対応・待機挙動) — Microsoft Learn
- Get-StorageJob(Storage)— Microsoft Learn