Case 05 — 設計判断の記録
S2D×Hyper-Vで「止めない基盤」を作るまで
大手SIer二次請け（設計・構築）
Windows Server 2025 / S2D / Hyper-V
HCIプライベートクラウド
正直に書きます。この案件は難産でした。大手SIerの二次請けとして、Storage Spaces Direct（S2D）と Hyper-V で「ノードを止めずにメンテできる」基盤を設計から作る——机上の構成図はきれいでも、現場は落とし穴だらけです。どこで迷い、どこで何日も溶かし、最後にどう決着させたか。きれいごとを抜いて、設計判断のリアルをそのまま残します。
守秘義務のため、お客様名・拠点・具体的な数値・製品固有名は伏せています。以下は当社が設計・構築を担当した範囲での判断と、そこで実際にぶつかった事象に基づく記録です。技術的な落とし穴は、S2D／Hyper-V を設計から組む人なら誰もが通る道です。これから同じ構成に挑む方の地図になれば、と思って公開しています。
00いちばん重いのは「手を動かす前」
最初に断言しておきます。この手の基盤で本当に時間を食うのは、ケーブルを挿す前の工程です。既存構成の事前調査、SIer・エンドユーザー・ハードウェアベンダーとの調整、そして要件を設計に落とし込む工程。ここを詰め切れないまま手を動かすと、あとで必ず全部跳ね返ってきます。
判断停止許容時間・保守窓・障害時の切り戻し条件・RPO/RTO を「紙で」確定してから、ハードとネットワークの設計に入る。関係者の合意を、口頭ではなくドキュメントで固定する。
つまずき早くモノを触りたくて、要件が固まる前にハード仕様を先に走らせた。後から S2D の認定要件（対応NIC・ドライバ・ファーム）と衝突し、選定をやり直す羽目に。調整のやり直しは、作業のやり直しよりずっと高くつきました。
教訓設計を紙で固める時間をケチらない。事前調査と関係者調整こそが、この案件の実質的な山場だった。
01ハードとファーム — S2Dは「認定」が命
S2D はソフトウェアでストレージを束ねる仕組みですが、その土台は徹底的にハードウェア依存です。NIC・ドライバ・ファームウェアの組み合わせが認定構成から外れると、平常時は動いても負荷時や障害時に牙をむきます。
判断認定済み（Windows Server SDDC / Azure Stack HCI 相当）の構成に寄せ、NIC ファーム・ドライバのバージョンを「設計項目」として固定・記録する。
つまずきドライバとファームの版が一部ノードでずれており、仮想ディスクが忙しい時間帯だけ不安定になった。ハードなのかOSなのかS2Dなのか、切り分けだけで相当溶かしました。
教訓ファーム・ドライバの版管理は「運用の話」ではなく「設計の話」。全ノードで揃っていることを構築前提に組み込む。
02ネットワーク — ここで一番溶かした
断言します。S2D で最も時間を吸われるのはネットワークです。RDMA（RoCEv2 なら DCB／PFC／ETS が前提）、SET によるチーミング、そしてストレージ・ライブマイグレーション・管理のトラフィック分離。どれか一つ設計を外すと、負荷がかかった瞬間に牙をむきます。
ネットワーク設計（簡略化）。RDMAはOS内で完結せず、物理スイッチの設定まで含めて一つの設計になる。
判断ストレージ RDMA は二系統に分離し、SET でチーミング。管理・ライブマイグレーション・ストレージをトラフィッククラスで分け、RoCEv2 のために DCB（PFC／ETS）をスイッチ側と揃える。
つまずき負荷をかけた瞬間に CSV が瞬断する。原因を追うと、PFC の優先度設定がスイッチ側とホスト側で食い違い、輻輳時にストレージのフレームが落ちていた。さらにジャンボフレームが end-to-end で揃っておらず断片化。OS・NIC・スイッチのどこが悪いのか分からず、切り分けに何日も費やしました。
教訓RDMA は「スイッチまで含めて」設計する。Test-RDMA と NIC/スイッチのカウンタで実測し、PFC が本当に効いているかを目で確認する。MTU と PFC 優先度は経路全体で一致させる。ここを妥協すると、平常時は動くのに本番の高負荷で必ず刺されます。
03ストレージ — ミラーか、パリティか、加速パリティか
S2D のレジリエンシ選択は、性能と容量のトレードオフそのものです。容量が惜しくてパリティに寄せると、書き込み性能と再構築（repair）中の劣化で泣くことになります。
| レジリエンシ | 容量効率 | 性能 | 向いているワークロード |
|---|
| 3-way ミラー | 低（約33%） | 高い・安定 | VM・DB など I/O 重視。3ノード以上の既定解 |
| 2-way ミラー | 中（約50%） | 高い | 2ノード構成。障害耐性は1に限定される点に注意 |
| デュアルパリティ | 高い | 書き込みが重い | アーカイブ・バックアップなど順次書き込み中心 |
| ミラー加速パリティ | 高め | 可変（設計次第） | 容量と性能の折衷。ミラー層のサイジングが肝 |
判断VM を載せる本番ボリュームは 3-way ミラー＋ReFS／CSV を基本線に。キャッシュ用 NVMe を確保し、フォールトドメインはノード単位で構成する。
つまずき一部のボリュームで容量を惜しんでパリティ寄りにしたところ、想定より書き込みが落ちた。加えて、ノード障害からの再構築中に性能が大きく劣化することを甘く見ていて、運用イメージと乖離した。
教訓レジリエンシは机上のカタログ値ではなく、実ワークロードでベンチしてから決める。再構築のための予備容量（reserve）を必ず残す。repair が走っている最中こそが本当の性能。
04クォーラム — 偶数ノードとスプリットブレイン
クラスタは「過半数が生きているか」で自分の生死を決めます。ここを軽く見ると、ネットワーク分断のときに両側が「自分が正」と主張するスプリットブレインに近づきます。
判断ノード数の偶奇に応じて、ファイル共有ウィットネス（またはクラウドウィットネス）で票を補い、分断時の生存条件を明確にする。
つまずきウィットネスの「置き場所」を最初は軽く考えていた。クラスタと同じ障害ドメインに置いたら、そのドメインごと落ちたときにウィットネスも一緒に死ぬ——票の意味がない。
教訓ウィットネスは独立した故障ドメインに置く。クォーラムは「動的クォーラム任せ」にせず、想定する分断シナリオごとに生存を机上で追う。
05ライブマイグレーションの認証 — CredSSPで詰んだ
ノードを無停止で退避する——この要件の心臓部が、実は「認証」でした。既定の CredSSP のままだと、運用と自動化で確実に詰まります。
ライブマイグレーションの認証フロー（簡略化）。鍵は「移行元がKDCから移行先向けのチケットを取れること」。
判断認証方式は既定の CredSSP ではなく Kerberos 制約付き委任を採用。移行用 AD に各ノードの SPN を登録し、ノード間の委任を明示的に構成する。
つまずきCredSSP だと「今ログオンしているノードからしかライブマイグレーションを開始できない」。リモートや自動化から叩くと二重ホップで弾かれ、運用フローが成立しない。要件を満たせないと気づいたときの冷や汗は忘れません。
教訓ライブマイグレーションは最初から Kerberos 委任前提で設計する。SPN 登録と委任設定は「Hyper-V の設定」ではなく「AD 設計の一部」。後付けだと SPN の重複や委任漏れであちこち刺さる。
06移行用AD — クラスタの土台を甘く見た
フェイルオーバークラスタも Hyper-V のライブマイグレーションも、足元は Active Directory です。ここが緩いと、上物がどれだけきれいでも崩れます。
判断クラスタ名オブジェクト（CNO）と仮想コンピュータオブジェクト（VCO）を事前作成（prestage）し、権限を委任。DNS と時刻同期（w32time）を設計に含める。
つまずきCNO の権限が足りず、VCO の自動作成に失敗してクラスタ作成でコケた。さらに時刻が数分ずれていて Kerberos が断続的に不安定に。「ADのちょっとした設定」で上位のクラスタが丸ごと止まる怖さを味わいました。
教訓AD はクラスタの前提条件。prestage・権限委任・DNS・時刻同期をチェックリスト化して、構築前に潰しておく。
07運用・保守 — 作って終わりじゃない
基盤は「動いた」がゴールではありません。パッチ、監視、修復ジョブの扱い——ここを手順化しておかないと、無停止どころか自分で二重障害を作りかねません。
判断更新は CAU（Cluster-Aware Updating）で一台ずつ。監視・容量アラートを整備し、修復ジョブの完了を待つ運用ルールを明文化する。
つまずき修復ジョブ（storage repair）が完了する前に、次のノードを保守で落としかけた。もし実行していたら、冗長度が足りずデータの可用性を割るところだった。ヒヤリとしました。
教訓メンテは「CAU ＋ 修復完了待ち」を必ずワンセットで手順化する。無停止は仕組みだけでなく、手順に埋め込んで初めて守られる。
08総括 — 傷が、そのまま資産になった
ここまで読んでいただければ分かる通り、この案件はスマートな成功譚ではありません。ネットワークで溶かし、認証で詰まり、AD の足元で転びました。でも——だからこそ、S2D・Hyper-V・AD・Kerberos の勘所が身体に入っています。カタログではなく、失敗して覚えた知識です。
この経験が、いま何に効くか：AWS へ移行する案件でも、「オンプレ側で本当は何が起きているのか」を理解したうえで設計できます。Windows・AD・仮想化・Kerberos がからむ移行は、表面のクラウド知識だけでは必ずどこかで刺さる。私たちは、その刺さるポイントを実体験で知っています。だから、御社には同じ轍を踏ませません。
オンプレの Windows／Hyper-V 基盤の刷新、AWS への移行、あるいは「止めない」要件の設計でお困りなら、まずは現状の構成図と困りごとを共有ください。落とし穴の在り処からお話しします。
相談する
＋関連する技術記事
この案件で踏んだ論点は、ブログでさらに掘り下げています。
← 導入事例一覧へ戻る
