Windows Server 2016

Windows Server 2016 で実現する Hyper Converged Infrastructure

実践ガイド

Cloud Platform

Windows Server 2016 で実現する

Hyper Converged Infrastructure 実践ガイド

第 1.0 版

日本マイクロソフト株式会社

Published: 2017 年 6 月 30 日

概要

このドキュメントについて

このドキュメントは新機能や機能改善により実現可能になった、Windows Server 2016 による Hyper

Converged Infrastructure について、その構成するテクノロジーや要素について、概要からチューニング

事項、評価環境の構築方法に至るまで各種情報をとりまとめ、一つのガイドとしたものです。

このドキュメントを利用することで Windows Server 2016 による HCI に対する理解を深め、実際の構

築・運用に向けて有益な情報を得て頂くことを目的としています。

本ドキュメントに含まれる製品情報はドキュメント執筆時点のソフトウェアおよびサービスに基づいたも

のであり、製品の機能や仕様は今後の更新プログラムによって変更される可能性があります。

対象ユーザー

この評価ガイドは、企業やサービス プロバイダーにおいて IT インフラストラクチャの設計、導入、運用

を担当する管理者、担当者、および IT プロフェッショナルを対象としています。

最新情報

Windows Server 2016 および System Center 2016 の最新情報については、以下の製品サイトを参照

してください。

マイクロソフト クラウド プラットフォーム

https://www.microsoft.com/ja-jp/cloud-platform/

Windows Server 2016

https://www.microsoft.com/ja-jp/cloud-platform/windows-server

System Center 2016

https://www.microsoft.com/ja-jp/cloud-platform/system-center

著作権情報

このドキュメントは、 "現状のまま" 提供されます。このドキュメントに記載されている情報 (URL など

のインターネット Web サイトに関する情報を含む) は、将来予告なしに変更することがあります。

このドキュメントは、Microsoft 製品の知的財産権に関する権利をお客様に許諾するものではありません。

お客様は、内部的な参照目的に限り、ドキュメントを複製して使用することができます。

© 2017 Microsoft Corporation. All rights reserved.

Microsoft、Active Directory、Azure、Hyper-V、Internet Explorer、Office 365、SharePoint、Silverlight、

SQL Server、Visual Studio、Windows、Windows PowerShell、および Windows Server は、米国

Microsoft Corporation の米国およびその他の国における登録商標または商標です。

その他、記載されている会社名、製品名は、各社の登録商標または商標です。

※ この評価ガイドに含まれる参照先 URL は制作時点でのものであり、予告なく変更される場合があり

ます。

目次

概要 ................................................................................................................................ 1

このドキュメントについて .............................................................................................. 1

対象ユーザー ............................................................................................................... 1

最新情報 ..................................................................................................................... 1

著作権情報 .................................................................................................................. 2

改訂履歴 ..................................................................................................................... 5

はじめに ........................................................................................................................... 6

Hyper Converged Infrastructure (HCI) とは ...................................................................... 6

関連テクノロジーの機能強化 ................................................................................................. 8

Hyper-V ........................................................................................................................ 8

Windows Server フェールオーバークラスター .................................................................... 10

スケールアウトファイルサーバーと SMB 3.x ...................................................................... 13

記憶域スペースダイレクトの概要 .......................................................................................... 15

記憶域スペースダイレクト/S2D 登場の経緯 ........................................................................ 15

SAN を利用したストレージ構成 ..................................................................................... 15

Windows Server 2012 / 2012 R2 の記憶域スペース ........................................................ 16

記憶域スペースから記憶域スペースダイレクト/S2D へ ....................................................... 17

S2D の基礎 ................................................................................................................... 18

S2D のアーキテクチャ ................................................................................................ 18

ソフトウェア要件 ....................................................................................................... 21

ハードウェア要件 ....................................................................................................... 21

サポートする構成/ワークロード ..................................................................................... 23

S2D 関連ストレージ機能 ................................................................................................ 26

ヘルスサービス .......................................................................................................... 26

記憶域レプリカ .......................................................................................................... 27

記憶域 QoS ポリシー .................................................................................................. 28

S2D の設計 .................................................................................................................... 29

可用性設計とサイジング .................................................................................................. 29

ボリューム ................................................................................................................ 30

障害ドメイン (Fault Domain) ....................................................................................... 34

物理ディスク ............................................................................................................. 36

ネットワーク ............................................................................................................. 42

ネットワークオフロード関連設定 (参考情報) .................................................................... 46

S2D の運用設計 ............................................................................................................ 49

パフォーマンスカウンター ............................................................................................ 49

バックアップ ............................................................................................................. 53

System Center 2016 Operations Manager .................................................................... 53

S2D の構築 .................................................................................................................... 55

S2D の有効化 ............................................................................................................... 55

S2D の構築手順の概要 ................................................................................................ 55

物理ディスクのクリーンアップ ...................................................................................... 56

Enable-ClusterStorageSpacesDirect のオプション .......................................................... 56

ヘルスサービスの設定 ..................................................................................................... 57

キャッシュモードの確認/変更 ........................................................................................... 59

階層化ストレージ .......................................................................................................... 60

仮想ディスク チューニング ............................................................................................. 61

S2D の運用 .................................................................................................................... 64

ノード・ディスクの追加 .......................................................................................................... 64

ボリュームの拡張 ............................................................................................................... 64

ノードのメンテナンス ............................................................................................................ 66

サーバーの削除 ................................................................................................................. 66

ディスクのファームウェア更新 ................................................................................................... 67

状態の確認 ................................................................................................................... 67

StorageHealthReport ................................................................................................. 67

Get-SmbMultiChannelConnection ................................................................................ 68

障害発生時 ................................................................................................................... 68

ディスクの状態の確認・交換、障害時の動作 ..................................................................... 68

復旧の確認 ................................................................................................................ 69

ノードやディスクの追加、復旧作業のタイミング .................................................................. 69

まとめ ............................................................................................................................ 70

改訂履歴

版 発行日 内容

第 1 版 2017 年 6 月 30 日 初版発行

はじめに

マイクロソフトは Windows Server および System Center 製品の最新バージョンである Windows

Server 2016 および System Center 2016 を 2016 年 9 月 26 日に発表し、2016 年 10 月 12 日

（米国時間）より製品ソフトウェアの一般提供 (General Availability: GA) を開始しました。

Windows Server 2016 には記憶域スペースダイレクトをはじめとした Software Defined Storage 機能

や Software Defined Network 機能を含んでおり、Windows Server の機能だけで Hyper Converged

Infrastructure (HCI) を構成することが可能になりました。以前のバージョンから利用可能な Hyper-V や

Windows Server Failover Cluster、Scale-Out File Server といったプライベートクラウドを支える基盤

テクノロジーも大きく改善されており、Windows Server 2016 による HCI の競争力向上の大きな一因と

なっています。

本ドキュメントでは、HCI の中枢を成す記憶域スペースダイレクトに大きく比重を置きながらも、Windows

Server 2016 の HCI を構成する各機能について解説していきます。

Hyper Converged Infrastructure (HCI) とは

クラウドコンピューティングが普及する少し前に時計を戻します。2000 年代後半に仮想化テクノロジーの

普及は非常に迅速に進みました。それ以前は一つの物理サーバーが一つの役割を持つことが一般的であり、

サーバーはもちろん、ハブやスイッチといったネットワーク機材やストレージ機材も目に見える形で、比較

的、管理しやすい状態にありました。しかし、仮想化テクノロジーの普及とその集約率の向上により、例え

ば、ストレージエリアネットワーク (SAN) をベースにしたストレージ利用が一般的になったように、物理

的なインフラの構成要素は加速度的に複雑化しました。その結果として、ハードウェアレイヤ―の設計難度

が劇的に増加し、構築に高度な知識と経験が求められるようになりました。

こ の 状 況 に 対 し て 各 種 ベ ン ダ ー か ら 提 供 さ れ る よ う に な っ た ソ リ ュ ー シ ョ ン が "Converged

Infrastructure / コンバージド インフラストラクチャ / CI" でした。コンバージド インフラストラクチ

ャは、予め設計されたキャパシティに対して必要なサーバーやストレージ、ネットワーク機材に加え、それ

らの標準設定や管理ツールをパッケージ化したものであり、大きな変更を行うことは難しいものの、動作保

証された標準アーキテクチャを基にしたシステムの導入を容易にする効果がありました。

このコンバージド インフラストラクチャを更に推し進めたものが、"Hyper Converged Infrastructure /

ハイパー コンバージド インフラストラクチャ / HCI" になります。ハイパー コンバージド インフラスト

ラクチャではコンバージド インフラストラクチャの構成要素の内、大きな比重を占めていたストレージを

仮想化ソフトウェアの機能を利用し、サーバー側のローカルディスクを利用した Software Defined

Storage によるストレージに置き換えます。こうすることによって、SAN を構成するために必要だった多

数のハードウェアが不要になることに加え、ストレージの制御がソフトウェア寄りになることで柔軟性が増

し、管理性の向上や拡張性の向上が期待できます。

関連テクノロジーの機能強化

HCI は Software Defined Storage 機能の強化により実現可能となりましたが、それだけで構成されるわ

けではありません。当然ながら、Hyper-V やフェールオーバークラスター、スケールアウトファイルサー

バーといった、これまでの仮想化基盤を支えた技術を併せて利用しており、また、それらの技術も Windows

Server 2016 で多数の機能追加や強化が図られています。HCI に強くフォーカスする前に、これらの関連

技術の概要と、Windows Server 2016 での機能追加・強化のポイントについて簡単にまとめます。

Hyper-V

Hyper-V は Windows Server 2008 で追加された Windows Server の仮想化機能です。それ以前の

Virtual PC や Virtual Server と異なり、ハイパーバイザー型の仮想化形式を採用しており、オーバーヘッ

ドの少ない、パフォーマンスの高い仮想化を実現しています。

Virtual PC 時代の仮想化アーキテクチャ

Hypervisor 型の仮想化アーキテクチャ

また、ハイパーバイザーの形式として、ハイパーバイザーがドライバーを持つモノリシック型ではなく、ホ

スト OS (Parent Partition) のドライバーを利用するマイクロカーネル型としていることで、Windows

Server が動作可能なハードウェアであれば、Hyper-V も基本的に利用可能という汎用性も持ち合わせてい

ます。

この仮想化技術の根幹を担う Hyper-V そのものについても Windows Server 2016 で引き続き機能追

加・向上が図られています。例えば、インメモリー DB のようにワークロードの更なるスケールアップにも

対応するために、Windows Server 2016 で動作する Hyper-V でサポートする CPU 数やメモリサイズ

の上限が以下のように向上しています。

Windows Server 2012 R2 Windows Server 2016

Hyper-V ホストがサポートす

る物理メモリの上限

4TB 24TB

Hyper-V ホストがサポートす

る論理コア数の上限

320 512

仮想マシンでサポートされる

メモリサイズの上限

1TB 12TB

仮想マシンでサポートされる

仮想コア数の上限

64 240

その他にも仮想マシンのセキュリティ強化のため、仮想マシンのシステムドライブで Bitlocker を利用可

能とするための仮想 TPM 機能のサポートや、ホストガーディアンサービスを利用し、特定の許可した

Hyper-V ホスト以外での仮想マシンの起動を制限するシールド VM 機能が追加されている他、ゲスト内の

VSS と連携するチェックポイント機能の強化、仮想マシンの管理をより効率化する PowerShell Direct と

いった使い勝手の観点でも引き続き改善が図られています。

Windows Server 2016 の Hyper-V の新機能詳細については以下もご参考ください。

What's new in Hyper-V on Windows Server 2016

https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/what-s-new-in-

hyper-v-on-windows

Windows Server フェールオーバークラスター

Windows Server フェールオーバークラスターは Windows Server 標準の高可用性ソリューションです。

Windows Server フェールオーバークラスターでは複数の Windows Server 環境をクラスタリングし、

その上で、"クラスター化された役割" として対応した各種ワークロードを冗長化することが可能です。

Hyper-V 仮想マシンは Windows Server フェールオーバークラスターを利用し冗長化することが可能で

あるだけでなく、Windows Server 2008 R2 以降ではライブマイグレーション機能が追加され、仮想マシ

ンを止めずに Hyper-V ホストを移動することが可能になりました。

このライブマイグレーションはクラスター共有ボリューム(Cluster Shared Volume, CSV) と呼ばれる技

術をベースにしています。CSV が利用可能になる以前のバージョンではクラスターの共同ディスクはクラ

スターノードのいずれかが所有者になり、排他的に I/O を行っていました。そのため、仮想マシンの移動

と共有ディスクの移動は同時に行わざるを得ず、仮想マシンの管理性や、共有ディスクの LUN 設計に大き

な制限を生じていました。クラスター共有ボリュームは共有ディスクへの I/O 処理を所有ノードだけでな

く、他のノードからもダイレクト I/O 可能とする CSVFS というファイルシステムによって実現しており、

これによって LUN 設計の柔軟性が増すとともに、共同ディスクの所有ノードに左右されずに、仮想マシン

を稼働するホストを移動可能になりました。

このように仮想化技術とフェールオーバークラスターは密に結合され、バージョンを追うごとに機能強化が

図られており、Windows Server 2016 でも Hyper-V を強く意識した新機能や機能強化が多数行われて

います。

Windows Server 2016 のフェールオーバークラスターで最も大きな新機能はフォールトドメイン機能で

しょう。Windows Server フェールオーバークラスターでは Windows Server 2008 で実装された初期バ

ージョンから地理的に離れたサーバー間でのクラスタリング、通称、地理冗長クラスターを構築することは

サポートしていました。しかしながら、その実装は IP アドレスのセグメントを元にサイトを判別し動作す

るものであり、管理者視点では使い勝手に難があったことも事実です。

Windows Server 2016 で追加されたフォールトドメイン機能では、管理者による明示的なサイトの作成

や、各クラスターノードが所属するサイトの設定が可能になったことにより、マルチサイトクラスター環境

の構築・管理が飛躍的に行いやすくなりました。また、クラスター全体として優先するサイトや、仮想マシ

ン毎に優先するサイトの指定も可能になり、柔軟なマルチサイトクラスターの利用が可能になっています。

また、フォールトドメイン機能ではサイトだけではなく、ブレードサーバーのシャーシや、ラックマウント

サーバーがラッキングされているラックを設定することも可能となり、これらの設定を行うと記憶域スペー

スダイレクトでデータ配置の判断に利用され、シャーシ障害やラック障害に対応することが可能となります。

その他にも複数の仮想マシンをセットとしてまとめ、セット間で依存関係を付けることで、"DB 仮想マシ

ン群" → "バックロジック仮想マシン群" → "フロントエンド Web サーバー仮想マシン群" のように起

動順を制御する機能が追加された他、Hyper-V ホストの負荷状態を見て仮想マシンの配置を自動リバラン

スする機能、ネットワークの一時的な障害を考慮した仮想マシンのフェールオーバー等、Windows Server

2016 のフェールオーバークラスターには仮想化基盤としての最適化を狙った新機能が含まれています。

Windows Server 2016 のフェールオーバークラスターの新機能詳細については以下もご参考ください。

What's new in Failover Clustering in Windows Server 2016

https://docs.microsoft.com/en-us/windows-server/failover-clustering/whats-new-in-failover-

clustering

スケールアウトファイルサーバーと SMB 3.x

ここでは仮想化基盤との関連性の強いスケールアウトファイルサーバーと SMB 3.x についてその概要を

説明します。

スケールアウトファイルサーバーは Windows Server 2012 から利用可能になった新しいファイルサーバ

ーの形式です。ただし、ファイルサーバーといっても IT ワーカーが各種ファイルを保存し利用するもので

はなく、その実態は Hyper-V 仮想マシンあるいは SQL Server のデータベースのファイルを配置するた

めのアプリケーションが利用するファイルを配置するための専用ファイルサーバーであり、その認識を持っ

て頂く必要があります。

スケールアウトファイルサーバーが考え出された背景から説明しましょう。Windows Server 2008 R2 以

前の Hyper-V 環境では必然的に以下のように Hyper-V ホスト自体が共有ディスクに接続された構成で

ある必要がありました。

この構成の場合、OS 側でストレージの利用を最適化するために、例えばデータ重複除去機能やデータの In

Memory へのキャッシュ等の処理を行おうとした場合、 本来、Hyper-V 仮想マシンを動作するための

CPU やメモリといったリソースが、ストレージ側の処理に利用されるという矛盾が生じ得ます。HCI 構成

のようにインボックスにまとめる場合であれば問題ありませんが、大規模に展開しようとした場合、仮想マ

シンを稼働するためのコンピューティングリソースと、ストレージ関連処理を最適化するためのストレージ

リソースを異なるマシンで処理した方が、全体最適が行えると考えられ、そのために実装された役割がスケ

ールアウトファイルサーバーになります。

Hyper-V ホストとストレージを切り離すため、まずは Hyper-V Over SMB 機能が実装され、Hyper-V ホ

ストで仮想マシンをローカルディスクだけでなく、ファイル共有上に配置することをサポートしました。次

いで、仮想ハードディスクをはじめとした仮想マシンの構成ファイル群を配置する先が、以前からのファイ

ルサーバーでは、ファイルサーバーを冗長化したとしてもアクティブになるノードは 1 台だけであり、パフ

ォーマンスをスケールさせ難いことに加え、アクティブノードの障害発生時に接続復旧にラグが生じまるこ

とから、SMB マルチチャネル機能や SMB 等価フェールオーバーが実装され、これらの SMB 3.x の新機

能を利用したアクティブ・アクティブ構成のファイルサーバーとしてスケールアウトファイルサーバーが登

場しました。

スケールアウトファイルサーバーを利用することには、記憶域スペースダイレクトを含む、ストレージの最

適化機能や Software Defined Storage 機能の負荷を Hyper-V ホストから分離し、大規模な構成でも十

分なスケーラビリティが担保可能になっただけでなく、コンピューティングリソースの増強が必要になった

場合は Hyper-V ホストだけを追加する、ストレージリソースの増強に際してはスケールアウトファイルサ

ーバーのノードだけを追加する、といったように管理にも柔軟性が増すというメリットがあります。

記憶域スペースダイレクトの概要

本項では Windows Server 2016 による HCI の中核をなす、記憶域スペースダイレクトとその関連技術

について解説します。

記憶域スペースダイレクト/S2D 登場の経緯

先ず、記憶域スペースダイレクトに至るまでのこれまでの Windows Server のストレージに関する情報に

ついて言及し、記憶育スペースダイレクトが目指している方向性について説明します。

なお、記憶域スペースダイレクトは英語で Storage Spaces Direct と表記し、その略称を S2D としてい

ます。本ドキュメントでもこれ以降、記憶域スペースダイレクトを S2D と記載します。

SAN を利用したストレージ構成

今でも多くの環境で利用されている Windows Server を利用した高可用性構成として、Fibre-Channel や

iSCSI ベースの SAN を利用した構成があります。

この SAN 構成では SAN に接続されたすべてのサーバーが SAN 上の共有ディスクにアクセス可能であ

り、アプリケーションのデータや仮想マシンの仮想ハードディスクファイル等を SAN の共有ディスクに配

置することで、ワークロードの冗長性を担保できます。また、共有ディスク一般的にはストレージアレイ内

の RAID コントローラーで制御された複数の物理ハードディスクを利用した論理ディスクになります。

この SAN ベースの構成は Windows Server 2016 がリリースされた現時点においても、冗長構成のサー

バーのストレージとしては主流ではありますが、クラウド環境のような大規模で考えた場合にストレージリ

ソースのスケールアウトが難しいことや、SAS SSD や NVMe™ SSD が主流になるにあたり、RAID コン

トローラーの処理速度がディスクパフォーマンスと比較して遅く、パフォーマンスボトルネックになること

が問題視されるようになりました。それらの問題を解決するため、将来のストレージ技術として SAN 構成

ではない、Software Defined Storage 技術の開発が始まり、今では一般的に利用されるようになりつつあ

ります。

Windows Server 2012 / 2012 R2 の記憶域スペース

Windows Server で Software Defined Storage を実現する機能として最初に実装されたものは、

Windows Server 2012 で追加された記憶域スペースです。記憶域スペースの構成例を示すと以下のよう

になります。

SAN を利用した構成と比較した場合の変更点は、ストレージアレイやコントローラーを配し、Windows

Server がインターフェースとなっていること、物理ディスクが共有エンクロージャー経由の SAS 接続に

なっていることが大きなポイントです。特に物理ディスクについては、RAID コントローラーのような多機

能なコントローラーではなく、単純に SAS ディスクとして Windows 側に見せていることからも "Just

Bunch of Disks" = JBOD/JBODs = ただのディスクの束、とも呼ばれます。

記憶域スペースでは単純な SAS ディスクとして接続している多数の物理ディスクを Windows のソフト

ウェアレイヤーで管理し、SSD / HDD の階層化やミラー・パリティといった冗長化をサポートする、仮想

的な共有ディスクとして利用することをサポートします。これにより、RAID コントローラーの処理時間と

いうボトルネックを解消するとともに、ストレージを管理するノードの追加・削除や、物理ディスクの追加・

削除等の管理作業が容易になる効果がありました。

記憶域スペースから記憶域スペースダイレクト/S2D へ

記憶育スペースダイレクト/S2D はその名前の通り、Windows Server 2012 で実装された記憶域スペー

スを下敷きにした、Windows Server 2016 の新機能です。前述の記憶域スペースの構成例を S2D ベース

に置き換えた場合のイメージが以下となります。

S2D の "ダイレクト" は利用する物理ディスクが各サーバーに直接接続されているものを使うことを意味

します。記憶域スペースでは、以前の SAN と比較して専用機材が減りはしたものの、共有エンクロージャ

ーという専用のハードウェアが必要でした。S2D では更にそのコンパクト化を進め、共有エンクロージャ

ーを廃し各サーバーのローカルディスクが利用する形になったことで、更にコンパクトな構成を実現できる

だけでなく、よりスケールアップ・ダウンを行いやすくなることを狙っています。

また、S2D では記憶域スペースでサポートしていなかった、ストレージリソースとコンピューティングリ

ソースを同一サーバーで動作する構成、つまりは HCI 構成をサポートするようになりました。HCI 構成を

取った場合、以下の図の通り、さらにコンパクトな構成を実現することが可能になります。

S2D の基礎

本項では S2D のアーキテクチャやハードウェア・ソフトウェア要件等の基礎情報についてまとめます。

S2D のアーキテクチャ

S2D は既述の通り、記憶域スペースを下敷きにした Windows Server 2016 の Software Defined

Storage 機能です。S2D では物理ディスクは各サーバーのローカルに接続された物理ディスクを利用しま

す。

S2D は Windows Server フェールオーバークラスターを前提としており、S2D を構成する複数のサーバ

ーをフェールオーバークラスター機能でクラスタリングします。クラスタリングされた各サーバーに搭載さ

れた物理ディスクを Software Storage Bus を介してソフトウェアで横断的にプール化し、この作成した

プールから仮想ディスクを作成します。仮想ディスクはクラスター共有ボリュームとして作成され、クラス

ター共有ボリュームはファイル共有としてスケールアウトファイルサーバーとして機能を提供することも、

仮想マシンの各種ファイルや、SQL Server の DB ファイルを直接配置して利用することも可能です。

Software Storage Bus はクラスターを構成する全てのサーバーを横断した仮想ストレージバスとして動

作するコンポーネントで、この Software Storage Bus を利用することで、各サーバーのローカルディス

クを他のサーバーからアクセスすることを可能としています。 Software Storage Bus は ClusPort と

ClusBlft の 2 つを主コンポーネントとしています。ClusPort は仮想の HBA として他のサーバー上のロ

ーカルディスクへアクセスする際のインターフェースとして動作し、ClusBlft は仮想のエンクロージャー

として動作しており、他のサーバーからの ClusPort 経由のアクセスに対応します。

また、ClusPort と ClusBlft 間の通信、つまりは S2D に伴うサーバー間の通信は SMB プロトコルを利用

して行われます。この際の通信は SMB Direct や SMB Multi-Channel といった SMB 3 の各機能を利用

し、冗長性とパフォーマンスの実現が図られます。

S2D ではサーバーをクラスタリングし Software Storage Bus で全てのサーバーが他の各サーバーのロ

ーカルディスクへのアクセスを可能とした上でストレージプールを作成します。ストレージプールは記憶域

スペースの頃から存在した概念で、利用可能な物理ディスクをまとめたものです。ストレージプールは利用

可能な物理ディスクの集合であるだけであり、例えばストレージプールにはミラーやパリティといった冗長

性の概念はありません。

実際に利用する仮想ボリュームはストレージプールから作成する形になります。この仮想ボリューム作成時

に冗長化の種別や仮想ボリュームのサイズを指定します。仮想ボリュームはクラスター共有ボリュームとし

て作成されます。ファイルシステムは CSVFS_ReFS あるいは CSVFS_NTFS が選択可能ですが、

Windows Server 2016 の ReFS は S2D での利用に最適化された機能追加・強化が図れていることから、

何らかの理由がなければ、CSVFS_ReFS の利用をお勧めしています。

S2D では以上の通り、各ホストのローカル ディスクをソフトウェア ベースでネットワーク接続し、ホス

トを跨いでストレージプールを作成します。次いで、このストレージプールから仮想ボリュームを切り出し、

CSV として利用します。

ローカルディスクに利用可能なハードウェア要件の詳細は後述しますが、S2D では NVMe SSD、SAS SSD、

SAS HDD といった複数種別のドライブを組み合わせて利用することが可能です。複数種別のドライブを組

み合わせて利用する場合、S2D では既定の動作では、より高速なドライブをキャッシュ用ストレージとし

て利用します。このキャッシュは記憶域スペースで利用可能だった階層化ストレージとは同時利用可能な別

レイヤーでの動作となり、利用可能領域としてはカウントされない、純粋なキャッシュとして動作します。

既定の動作では、SSD と HDD の組み合わせの場合、SSD が読み取り/書き込みキャッシュとして利用さ

れます。NVMe SSD と SAS/SATA SSD の組み合わせの場合、NVMe SSD が書き込みキャッシュとして

利用されます。

ソフトウェア要件

S2D は Windows Server 2016 の Built-In 機能です。しかしながら利用可能な SKU に制限があり、

Windows Server 2016 Datacenter でのみ利用可能です。Windows Server 2016 Standard では利用で

きないことにご注意ください。

OS のインストール種別には制限がありません。GUI インストール、Server Core インストール、Nano

Server いずれの環境でも S2D を利用することが可能です。

ハードウェア要件

前提として利用するサーバーやデバイス、ドライバーが Windows Server Catalog で認定されており、

"Certified for Windows Server 2016" を得ていること、クラスター構成検証をパスしていることが必須

です。次いで、コンポーネント毎に以下に詳細をまとめます。

サーバー

• 最小 2 ノード、最大 16 ノードまで

• クラスターノードは全て同一モデルを利用することを推奨します

CPU

• Intel® Nehalem 世代以降、あるいは、それに相当するプロセッサーである必要があります

メモリ

• キャッシュに利用するドライブのサイズ 1TB 毎に 4GB のメタデータが S2D に利用されるため、

仮想マシンやホスト OS として利用するメモリサイズに追加してサイジングする必要があります

o 例えば、各サーバーが 1.6TB のキャッシュ用 SSD を 2 つ搭載している場合には、2 x

1.6 x 4096 = 13,107 MB (12.8 GB) がメタデータ格納用に必要です

ネットワーク

• クラスターノード間の通信に 10Gbps 以上の帯域が必須です

• 冗長性とパフォーマンス向上のため、2 つ以上の NIC を利用することを推奨します

• オーバーヘッド抑制と通信パフォーマンス向上の観点から iWARP あるいは RoCE のような

RDMA ベースの NIC を利用することを推奨します

物理ディスク

• SATA、SAS、NVMe のローカルに接続されたディスクが必要です

• 全てのディスクはそれぞれ一つのディスクのみに接続されている必要があります

• S2D のクラスターを構成するサーバーは全て同一のディスク構成である必要があります。例えば、

特定の 1 ノードでのみ NVMe を利用するような構成はサポートされません

• SSD はエンタープライズ用途のグレードのものを利用する必要があります。コンシューマー用途の

ものはサポートされません

• SSD の耐久性の指標として 3 DWPD (drive-writes-per-day) あるいは、4 TBW (terabytes

written per days) 以上のものの利用を推奨します

• キャパシティ用のディスクの数はキャッシュ用のディスクの数の倍数である必要があります

• ドライブは 512n、 512e、 4K ネイティブ いずれでも問題ありません

• ディスクへのマルチパスアクセスはサポートされません

• S2D 用とは別にホスト OS のシステムドライブ用に RAID1 構成のディスクの利用を推奨します

ホストバスアダプター

• SAS、SATA ディスクの接続にはパススルー形式の SAS Host Bus Adapter が必要です

• SAS、SATA ディスクには SCSI Enclosure Services (SES) のサポートが必要です

• 直接接続するエンクロージャーについてはそれぞれが一意の ID を持っている必要があります

• RAID コントローラー経由の接続や、FC / iSCSI のような SAN ボリュームはサポートしません

o PowerShell の Get-PhysicalDisk コマンドレットを実行した結果、BusType が RAID に

なっているディスクは S2D では利用できません

o 実環境での確認に際しては以下の PowerShell で確認可能です。

Get-PhysicalDisk |FT FriendlyName,PhysicalLocation,BusType -AutoSize

最新の情報は以下もご確認ください。

Storage Spaces Direct hardware requirements

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-

direct-hardware-requirements

Choosing drives for Storage Spaces Direct

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/choosing-drives

サポートする構成/ワークロード

S2D は以下の 2 パターンの構成での利用をサポートします。

Converged Infrastructure 構成

S2D により作成した CSV 上にファイル共有を作成し、スケールアウトファイルサーバー(SOFS) として

利用する構成です。仮想マシンを稼働する Hyper-V ホストは別サーバーとして存在し、コンピューティン

グ リソースとストレージ リソースのサーバーを分けて運用します。より規模の大きな構成に適しています。

仮想マシンの負荷とストレージの負荷を分けて管理可能になるため、サイジングやそれぞれのノードの増減

が行いやすいというメリットがあります。

Hyper Converged Infrastructure 構成

S2D により作成した CSV 上に仮想ハードディスク等の仮想マシン関連ファイルを直接配置し、S2D を構

成するノードで仮想マシンも稼働する構成です。集約率は上がるため、小中規模の構成や、コンピューティ

ングリソースとストレージリソースを分離せずスケールアウトする運用の場合に適します。ただし、仮想マ

シンの負荷とストレージの負荷が同一ホストにより処理されるため、一般的にサイジングの難度が上がるこ

とに加え、コンピューティングリソースだけやストレージリソースだけの増減が行い辛いというデメリット

があります。

また、S2D 上で利用するワークロードとしてサポートするシナリオについて言及すると以下となります。

• Hyper Converged Infrastructure 構成での Hyper-V 仮想マシンの利用

• Hyper Converged Infrastructure 構成での SQL Server Failover Cluster Instance の利用

• Converged Infrastructure 構成での SOFS として Hyper-V 仮想マシン関連ファイルの格納

• Converged Infrastructure 構成での SOFS として SQL Server のデータベースファイルの格納

• Converged Infrastructure 構成での SOFS として リモートデスクトップサービスのユーザープ

ロファイルディスクの格納

Azure IaaS VM で S2D を構成し SQL Server FCI 用のデータベースファイルを置くことや、RDS のユ

ーザープロファイルディスクを置くこともサポートされます。詳細は以下もご確認ください。

Configure SQL Server Failover Cluster Instance on Azure Virtual Machines

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-

windows-portal-sql-create-failover-cluster

Deploy a two-node S2D SOFS for UPD storage in Azure

https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-

storage-spaces-direct-deployment

なお、S2D により構成した仮想ディスクを利用し、通常のファイルサーバーとして利用することをサポー

トはしますが、推奨しません。これは、S2D により作成される仮想ディスクは CSV であり、CSV は

Hyper-V 仮想マシンや SQL Server のデータベースのように、長期間開き続ける大きなサイズのファイル

が配置・利用されることを想定して実装・最適化されており、S2D や CSV として SOFS でない通常のフ

ァイルサーバーとしての利用用途は厳密なテストが実施されていないことに起因します。

通常のファイルサーバーでは多数のユーザーにより大量のサイズの小さなファイルに対するオープン・クロ

ーズが短期間に繰り返される動作になるため、そのような利用用途には S2D や CSV は最適化されていま

せん。通常のファイルサーバーとして利用した場合でも、理論上は動作すると想定されるため、非サポート

ではないものの非推奨としております、S2D 上で通常のファイルサーバーとしての役割が必要となる場合

には、HCI 構成としてファイルサーバーの役割を持った仮想マシンを構築・利用することを推奨します。

S2D 関連ストレージ機能

S2D をより深く理解し、よりよく使うために関連するストレージ系機能についてもその概要をまとめます。

ヘルスサービス

ヘルスサービスは S2D を構築すると自動で有効化される機能で、フェールオーバークラスターのコアクラ

スターグループのリソースとして動作します。

ヘルスサービスは S2D の安定動作に大きな役割を担うコンポーネントです。ヘルスサービスは各種

Storage Subsystem のインターフェースとしての役割を持つ他、S2D の健全性の状態確認や自動復旧処

理の実施、交換されたディスクのリタイアといったタスクの実施も担います。

ヘルスサービスの利用例として、S2D の IOPS や CPU 使用率等を確認する Get-StorageHealthReport

コマンドレットがあります。

Get-StorageSubSystem Cluster* | Get-StorageHealthReport

記憶域レプリカ

記憶域レプリカは Windows Server 2016 で新たに追加された機能で Datacenter SKU でのみ利用可能

です。記憶域レプリカはボリューム単位の複製を実現する機能で、同期複製・非同期複製どちらもサポート

する他、マルチサイトクラスター環境でのサイト間の複製や、異なるクラスター間での複製、異なるサーバ

ー間での複製、同一サーバー内でのボリューム単位の複製をサポートします。記憶域レプリカはファイルシ

ステムより下位レイヤーで複製を実現しているため、ファイルシステムより上位で複製されているか否かを

意識する必要はありません。

記憶域レプリカを利用することにより、S2D で作成した仮想ボリュームに関してもボリューム単位で複製

を行い、ボリューム単位での DR を構成することが可能です。しかしながら、Windows Server 2016 時

点での制限事項として、マルチサイトクラスター環境でのサイト間の複製形式は S2D に関してはサポート

しません。そのため、S2D と記憶域レプリカを併用する場合には、異なる S2D クラスター間での同期あ

るいは非同期複製がサポートされるということにご注意ください。

記憶域レプリカの詳細は以下もご参考ください。

Storage Replica overview

https://docs.microsoft.com/en-us/windows-server/storage/storage-replica/storage-replica-

overview

記憶域 QoS ポリシー

Windows Server 2016 では各仮想マシンのストレージ I/O を制御する記憶域 QoS も改善され記憶域

QoS ポリシーが利用可能になりました。記憶域 QoS ポリシーはコアクラスターグループの記憶域 QoS

リソースとして動作する記憶域 QoS ポリシーマネージャーが CSV 上で管理・制御するため、仮想マシン

の仮想 SCSI コントローラー単位で制御していた以前のバージョンと比較して、管理性が大幅に向上して

います。

Windows Server 2016 の記憶域 QoS ポリシーでは最小 IOPS、最大 IOPS の設定が可能である他、ポ

リシー毎に Dedicated = ポリシーの対象に設定された仮想ハードディスク毎に最小・最大の値が反映する

設定と、Aggregated = ポリシーの対象に設定された仮想ハードディスク全てで最小・最大の値を共有する

設定のいずれとするかが設定可能です。これにより特定のサービスに紐づく仮想マシン群全体で IOPS を

制限あるいは保証するような設定も可能となり、ストレージのパフォーマンス制御の管理性が大きく向上し

ました。

Windows Server 2016 の記憶域 QoS ポリシーの特徴を簡単に以下にまとめます。IOPS の測定が正規化

されることに伴い、特に最小 IOPS に関しては実測が難しいことにご注意ください。

• IOPS の測定/制限対象は 8KB を一単位として正規化する

• IOPS の対象は Read / Write の合計を対象とする

• ポリシーマネージャーとしての認識状態はホスト側で Get-StorageQosFlow コマンドレット を

実行して確認する必要がある

• ゲスト内での IOPS の認識とポリシーマネージャー側の IOPS の認識では確認するポイントや計

測元が異なるため厳密には一致しない

• ポリシーマネージャー側では IOPS の認識は直近 5 分間の平均値になる

詳細については以下もご参考ください。

Storage Quality of Service

https://docs.microsoft.com/en-us/windows-server/storage/storage-qos/storage-qos-overview

S2D の設計

本項ではより詳細な S2D 構築・運用時のポイントやチューニング事項と検証環境でのベンチマーク結果も

合わせて紹介していきます。

今回利用している検証環境の機器構成は以下の通りです。

[S2D ノードサーバー (4 台)]

CPU: Intel® Xeon® E5-2690 v3 * 2 (合計 24 コア/ 48 スレッド)

メモリ: 192 GB

HDD: SAS (6G) 900 GB *16 (OS :4 枚, S2D: 12 枚)

SSD: 東芝メモリ株式会社 PX04SMB080 *4 (SAS 12G 対応の SSD を SAS 6G で接続)

SSD: 東芝メモリ株式会社 PX04PMC080 *2 (NVMe 接続)

NIC: 10Gbps 対応 NIC *2

NIC: InfiniBand アダプター * 2 (RDMA 対応, 56Gbps)

本ドキュメントで掲載するベンチマーク結果は、他の環境での性能を保証するものではありません。

また、これらのハードウェアの組み合わせでの動作を保証するものではありません。S2D を利用可能な構

成やパフォーマンス面を含めた設計はハードウェア ベンダーにもご相談いただくことをお勧めします。

可用性設計とサイジング

要件の検討・策定

S2D 環境で動作するワークロード、具体的には例えば想定される仮想マシンの数やサイズを先ず検討しま

す。これを踏まえ、環境の概要設計として、Converged Infrastructure 構成とするのか Hyper Converged

Infrastructure 構成とするのかの検討や 10GbE を利用するのか、RDMA を利用するのか等を検討してく

ださい。

要件を満たす構成の検討・設計

要件を満たす環境を実現するためのサイジングを進めます。物理ディスクの数やサイズと仮想ボリュームの

サイズに関する計算については、必要に応じて以下のサイトもご利用ください。

Storage Spaces Direct Calculator PREVIEW

http://cosmosdarwin.com/spacesdirect/

ボリューム

ボリューム回復性の種類と容量効率

S2D ではデータの冗長性担保のため、ミラーリングとパリティを利用することが可能です。また、単体障

害をカバーする単純なミラーリングやシングル パリティだけでなく、 3 方向ミラーやデュアルパリティを

サポートします。それぞれ毎に S2D を構成するサーバーの数 (あるいはフォールトドメインの数) に最小

要件があります。最大限の可用性を確保するのであれば 3 方向ミラー (3-Way Mirroring) かデュアルパ

リティ (Dual Parity) を選択することを推奨します。

3-Way Mirroring

一つのデータブロックに対し、2 つのコピーデータを持つミラーリングです。3 ノードから利用可能になり

ます。二重障害まで対応可能になるため、例えば、1 つのディスク障害が発生している状態で、S2D を構成

するクラスターノードの内、1 台を再起動しても仮想ディスクは問題なく動作を継続します。データの容量

効率は 33% になります。

Dual Parity

RAID-6 に相当する設定です。4 ノードから利用可能になります。分割されたデータと 2 つのパリティデ

ータによって管理しており、二重障害に対応可能です。4 ノードで構成した場合は容量効率が 50% になり

ますが、ノード数を増加することで容量効率は改善され、最大で 80% になります。

Dual Parity では Reed–Solomon Error Correction (RS) と Local Reconstruction Codes (LRC) と呼

ばれる 2 つのアルゴリズムが存在し、ノード数によって最適なものが自動で採択されます。Dual Parity の

場合のノード数と容量効率の情報をまとめると以下になります。

ノード数

SSD + HDD 構成の場合 All SSD 構成の場合

Layout Efficiency Layout Efficiency

4 RS 2+2 50% RS 2+2 50%

5 RS 2+2 50% RS 2+2 50%

6 RS 2+2 50% RS 2+2 50%

7 RS 4+2 66% RS 4+2 66%

8 RS 4+2 66% RS 4+2 66%

9 RS 4+2 66% RS 6+2 75%

10 RS 4+2 66% RS 6+2 75%

11 RS 4+2) 66% RS 6+2 75%

12 LRC (8,2,1) 72% RS 6+2 75%

13 LRC (8,2,1) 72% RS 6+2 75%

14 LRC (8,2,1) 72% RS 6+2 75%

15 LRC (8,2,1) 72% RS 6+2 75%

16 LRC (8,2,1) 72% LRC (12,2,1) 80%

2-Way Mirroring

RAID-1 と同等のミラーリングです。2 ノードから利用可能ですが、単体障害のみ対応可能となるため、3

ノード以上の構成であれば後述の 3-Way Mirroring 以上の設定を利用することを強く推奨します。データ

の容量効率は 50% になります。

Single Parity

RAID-5 に相当する設定です。3 ノードから利用可能ですが、基本的に利用を推奨しません。対応可能な障

害が単体障害のみであり、例えば、1 ノードを再起動中に 1 つのディスクで障害が発生した場合、仮想ディ

スクの健全性が保てずオフラインになるためです。3-Way Mirroring の利用、あるいは Dual Parity の利

用を推奨します。

ボリューム回復性の性能の違い

基本的には Mirror が I/O 性能に優れ、Parity が容量効率に優れます。特に Parity は 書き込み性能が低

くなり、CPU 負荷が高くなります。SQL Server や Hyper-V の仮想マシンなど、高い性能が必要とされる

場合や書き込みが多いワークロードでは Mirror を選択してください。

ここでは 4 Node, 各ノードに SAS HDD を 12 本ずつで構成した検証環境で 3-Way Mirror と Dual

Parity の I/O 性能を比較したデータをご紹介します。

ボリュームの数

S2D で作成した Cluster Shared Volume (CSV) では ReFS を使うことを推奨しています。しかし、ReFS

を使った場合は、CSV のオーナーノード以外からの I/O については ファイルシステム リダイレクトが発

生するため、CSV のオーナー ノード から I/O をした場合と、そのほかのノードから I/O した場合では

パフォーマンスに差が出てきます。

CSV オーナーノードからデータの読み込みをした場合、基本的にローカルのディスクからデータ読み込み

を行い、ローカルに無いデータを他のノードから取得します。

一方、オーナーノード以外からデータ読み込みを行った場合は、オーナーノードで完全なデータを生成した

後でデータ転送が行われます。

その結果、ネットワークのデータ転送量は大きく増加し、CPU の負荷も高くなります。

以上から、S2D 環境においては基本的に S2D クラスターを構成するノード数と同じ数以上の仮想ボリュ

ームを作成し、各 CSV の管理負荷を分散することをお勧めします。ノード数が多く、CSV 数=ノード数と

した場合に一つあたりのボリュームサイズが小さくなり過ぎる場合もありますので、その場合は、適宜、必

要となるボリュームサイズを踏まえてボリューム数を調整するように設計してください。

障害ドメイン (Fault Domain)

障害ドメインは可用性設計において重要です。 障害ドメインは同時に停止する可能性のあるグループとし

て考えることができます。デフォルトでは各サーバー (Node) を一番大きな障害ドメインとして設定され

ます。

障害ドメインの数

障害ドメインの最小数はボリュームの回復性によって決まります。例えば、サーバーを一番大きな障害ドメ

インとして設定する場合、3-Way Mirror のボリュームを作成するには最低でも３つのサーバーが必要にな

ります。回復性ごとの最小障害ドメイン数は以下の通りです。

3-Way Mirror : 3

Dual Parity : 4

2-Way Mirror : 2

Single Parity : 3

S2D ではディスクやノードの障害が発生した状態で一定期間経過すると正常に稼働しているノードやディ

スクで回復性を維持するようにデータを再配置します。例えば、3-Way Mirror で構築したボリュームでノ

ード障害が発生して３つのデータコピーのうち１つが失われた場合、再配置によって３つ目のデータコピー

を正常なノード常時再作成します。そのため、フォールト ドメインに障害が発生して復旧に時間がかかる

ことが予想される場合、上記の最小数よりも１つか２つ多くフォールトドメインを用意することをお勧めし

ます。

障害ドメインを手動で設定する

障害ドメインは Power Shell で設定、変更可能です。障害ドメインは Site, Rack, Chassis, Node の単位

を持ち、親子関係を作ることができます。詳細は以下の Web ページを確認してください。

Windows Server 2016 でフォールト ドメインの認識

https://docs.microsoft.com/ja-jp/windows-server/failover-clustering/fault-domains

物理ディスク

物理ディスクの種類と性能

S2D では SAS や SATA で接続された SSD、HDD だけではなく、NVMe 接続された SSD が利用可能

です。また、この中でも同じ SSD であっても、 SAS 接続と NVMe 接続を明確に認識し、パフォーマン

スを最適化する動作をするよう設計されています。

これらのディスクは価格とパフォーマンスのトレードオフになっており、パフォーマンスに関しては

NVMe SSD、SAS SSD、SAS HDD の順に高く、また、値段も一般的に同様の順になります。ただし、特に

NVMe SSD と SAS SSD を比較した場合に、以下に今回の検証環境での個別のディスク性能の計測結果に

示す通り、値段差以上にパフォーマンスに違いが生じるため、可能であれば NVMe SSD の利用を検討頂く

ことをお勧めします。

なお、NVMe SSD を推奨する理由は単純なストレージパフォーマンスだけではありません。一般的に HBA

に SAS 接続された SSD と NVMe 接続された SSD を比較した場合、同一 I/O を実施した場合に発生

する I/O に伴う CPU 処理量についても、NVMe SSD の方が低い傾向にあります。可能な限りディスク

I/O による CPU 処理を抑制し、仮想マシン等のワークロードで利用可能な CPU リソースを増やすという

観点からも、NVMe SSD に利点があると言えます。

また、SSD には書き込みの耐久性や速度によっても価格が異なるため、設計時に確認が必要です。

基本的に、別途キャッシュ（ジャーナル）ディスクを使用する場合は書き込みが遅くて安価な SSD を選択

することができますし、キャッシュディスクを使用しない場合は書き込みも高速な SSD を選択するべきで

す。

物理ディスクの数

S2D に必要なディスクの数を計算するためにはネットワークや CPU の性能、I/O コマンドの並列度など、

複数の要素を考慮する必要があります。そのため、性能要件に対するハードウェアサイジングは各ハードウ

ェアベンダーと相談してください。

仮にネットワークや CPU がボトルネックにならないと仮定した場合、必要なディスクの数はボリュームの

回復性と使用する物理ディスクの性能に依存します。

例えば、1000 IOPS の書き込み性能が必要でボリュームの回復性を 3-Way Mirror に設定する場合、デ

ータの書き込み時に３つのコピーを作成するため、最低でも合計 3000 IOPS の書き込み性能を持つ物理

ディスクを用意する必要があります。もし 150 IOPS の書き込み性能を持つ HDD で構成する場合、20 の

物理ディスクが最低必要です。（ただし、実際は様々なオーバーヘッドが発生するため、これよりも多くの

ディスクが必要になることに注意してください）

また、ノード障害時にも一定以上の性能を担保する必要がある場合はさらに多くのリソースが必要になりま

す。特にボリュームの回復性に Parity を選択した場合は、CPU を使ってパリティ情報から実際のデータを

計算するため、障害発生時の性能の低下は大きくなることに注意してください。

キャッシュ（ジャーナル）ディスクとデータディスク

SATA/SAS SSD や NVMe に対応したドライブはキャッシュ用ディスクとして利用することが可能です。

データディスクが HDD の場合は Read / Write キャッシュとして SSD や NVMe ディスクを利用し、

データディスクが SSD の場合は NVMe ディスクを Write キャッシュとして利用可能です。

また、SSD や HDD だけを利用する場合でも、書き込み速度の高速なモデルと低速なモデルが混在する場

合などは、手動設定で特定のモデルのディスクをキャッシュとして利用可能です。

ここでは検証環境にて HDD だけで S2D を構築した場合と HDD と NVMe 対応ディスクを組み合わせ

て構築した場合のベンチマークの結果をサンプルとして掲載します。

※このデータ採取のために実行したベンチマークは他と異なり、S2D ノード (4 ノード) それぞれで負荷

をかけて、処理できた I/O の総数を表示しています。また、HDD 領域は 3Way Mirror を設定し、データ

ファイルは各ノードで 100 GB と NVMe キャッシュに十分収まるサイズでテストしています。

SSD と NVMe キャッシュを組み合わせた場合でも性能の向上は期待できますが、SSD が十分に高速な場

合は効果を感じづらいかもしれません。特に今回の検証環境のように SSD の書き込み性能が高い場合は特

に差が出づらくなります。（今回の環境では合計 16 本の SAS SSD, 合計 8 本の NVMe 対応 SSD を使

用しています。）

しかし、読み込みと書き込みは混在するワークロードでは読み込みを SSD , 書き込みを NVMe に分離す

るため、差が大きくなります。ここに Read 70% , Write 30 % の混合ワークロードでテストした際の結

果を掲載します。

また、前述の “Enable-ClusterStorageSpacesDirect のオプション” の項でも説明した通り、キャッシュと

して利用するディスクは必ずしも NVMe に対応している必要はありません。ここでは HDD + NVMe (キ

ャッシュ), HDD + SSD (キャッシュ) の 2 パターンでベンチマークを実行した際の結果を参考として掲載

します。

今回の検証環境では読み込み、書き込みが比較的高速な 16 本の SAS (6G) SSD と 8 本の NVMe 対応

SSD で比較していますが、NVMe を使用したほうが良い結果になりました。SSD の本数が増えた場合や、

SAS (12G) SSD などを使用した場合は結果が異なる可能性もありますが、 一般的には NVMe 対応スト

レージを利用することで少ない本数で性能を稼ぐことが可能と言えます。実環境で構築する場合は、各メデ

ィアタイプのディスクの入手コストや性能を考慮してキャッシュの有無やメディアタイプを選択する必要

があります。

キャッシュディスクの数がどの程度必要かの見積もりは、S2D に対する要件によって変化します。S2D を

使用するシステムの瞬間的な I/O のピークがどの程度かによってキャッシュディスクに必要な性能が変化

し、ピークがどの程度続くかによって必要な容量が変わります。

また、キャッシュディスクに対する負荷を均等化するため、データディスクの数はキャッシュディスクの数

の倍数にすることをお勧めします。（例：キャッシュディスクが 3 つの場合、データディスクは３，６，９，

１２など）

※一般的に拡張カードタイプ(AIC) や M.2 のディスクはホット スワップができず、ディスク故障時はサ

ーバーの電源を切る必要があります。障害発生時の影響を最小限に抑える必要がある場合はホットスワップ

可能なハードウェアを選択することができます。

ネットワーク

S2D に必要な帯域

S2D で使用するネットワークの帯域はデータの I/O 量に依存します。3-Way Mirror のボリュームにデー

タを書き込みした場合、CSV オーナーノードから最大 3 つのノードに対してデータの転送が行われます。

そのためデータの書き込み時を想定する場合、CSV オーナーノードには 1 秒間にボリュームに書き込むデ

ータの 3 倍のデータ送信用の帯域を確保しなければボトルネックになります。また、ボリュームの項でも説

明した通り、 ファイルシステムリダイレクトにより、ボリュームに対して I/O コマンドを発行したノード

から CSV オーナーノードに対してデータ転送が行われるのでこれらの負荷も考慮するべきです。

さらに、ディスク障害やノード障害から復帰した場合にデータの再同期/再配置が行われ、大量のデータ転

送が行われる場合があります。この場合、障害時に更新された差分データのみ転送される場合もあれば、す

べてのデータを再同期する場合もあります。ですのでシステム障害時の復旧目標に応じて大きな帯域のネッ

トワークを用意する必要があるかもしれません。

RDMA 対応 NIC と 10 GbE

Remote Direct Memory Access (RDMA) は名称通り、リモートノードのメモリに高速アクセスすること

を目的に開発されたプロトコルで、RDMA を利用した通信規格としては InfiniBand や iWARP、RDMA

over Converged Ethernet (RoCE) などがあります。

Windows Server 2012 以降ではこの RDMA 利用可能なよう機能が実装されており、特にリモートストレ

ージへのアクセスの高速化のため、RDMA を利用した SMB 通信機能として SMB Direct が実装されてい

ます。

Improve Performance of a File Server with SMB Direct

https://msdn.microsoft.com/en-us/library/jj134210%28v=ws.11%29.aspx

S2D 環境では各ノードのローカルディスクを利用するため、S2D ノード間の通信量が大きくなります。仮

想ディスクの信頼性はノード間の通信の応答性の高さや、利用可能帯域幅の安定に大きく依存しているとも

いえるでしょう。そのため、S2D ではノード間の通信速度を 10 Gbps 以上をハードウェア要件として定

めています。現実的には、10GbE を利用するか、RDMA を利用するか、いずれかとなります。

今回、利用した評価環境において、RDMA 利用の有効/無効を切り替え、ベンチマークテストを実施した際

のパフォーマンスの差異は以下の通りです。特にストレージ性能の高い、SSD を利用している場合には、

RDMA の有無で大きく差が出ています。

また、10GbE と RDMA を比較した場合の考慮事項として、通信によって発生する処理による CPU 負荷

という観点があります。10GbE では通信によって発生する処理に起因した CPU ボトルネックが発生し、

NIC のカタログスペック分の速度が出ない、ということがままあります。そのため、パフォーマンスを最大

限発揮するためには、後述する RSS や VMQ といったオフロード、分散機能を利用するためのチューニン

グを必要とします。一方で、RDMA に関しては、その通信処理の大半を当初からハードウェアへオフロード

するため、そのようなチューニングは不要となります。以上から、S2D 環境においては可能であれば、RDMA

によるノード間通信を行うことをお勧めしております。

Intra-Node 通信の最適化

S2D 環境においてはクラスターを構成しているノード間の通信が高速で応答性が高く、安定していること

が仮想ボリュームの信頼性につながることは前述しました。そもそも論として Hyper-V ホスト環境でのネ

ットワーク設計においては、意図しない帯域占有により、他のワークロードの通信に予期しない問題が発生

することを避けることが重要です。具体的な障害例としては以下のようなものが挙げられます。

• 仮想マシンのライブマイグレーションを実施したことにより、物理 NIC の帯域が過度に利用され、

重要な仮想マシンの通信でタイムアウトが発生

• DB を稼働する仮想マシンでバックアップを実行したところ、ネットワーク帯域が占有され、他の

仮想マシンが一斉に応答しなくなった

特に S2D 環境においては S2D としての処理を行う通信に対して十分な通信帯域を常に確保できるよう、

ネットワーク設計・設定を行うことが非常に重要となります。具体的な項目として、最も代表的なものとし

て、ライブマイグレーションを実施するネットワークについて言及します。

ライブマイグレーションは仮想マシンを無停止で異なる Hyper-V ホストへ移動するための機能です。この

機能の実装としては、稼働中の仮想マシンのオンメモリのデータを移動先ホストへ転送し、データの転送が

ほぼ完了した時点で、仮想マシンの稼働ホストの切り替えと、最終的なデータの転送・整合性担保処理実施

するものになります。そのため、可能な限り高速に移動を実施するために、可能な限り通信帯域を利用して

データの転送を実施します。

つまり、S2D の通信とライブマイグレーションの通信とを同一インターフェースで利用する設定としてい

た場合、仮想マシンのライブマイグレーションを開始した時点で、S2D のストレージ処理に関する通信が

逼迫され、問題になる可能性が生じます。

この状態を避けるための設計例としては、ライブマイグレーション用のネットワークインターフェースを物

理的に別に準備する、あるいは、仮想 NIC をライブマイグレーション用に追加し、ネットワークの帯域制

限(QoS) を設定した上で、S2D のノード間通信に使うインターフェースと、ライブマイグレーション時の

通信に利用されるインターフェースを分けるというものがあります。

クラスターノード間の SMB 通信はデフォルトで SMB マルチチャネル通信が実施されますが、そのマル

チチャネル通信用のインターフェースはクラスターネットワークに設定されている物の中から、更にクラス

ター内部利用に設定されているものから優先して選択されます。

一方でライブマイグレーションの通信は通信に利用するプロトコルを既定値の圧縮、あるいは TCP/IP に

している場合にはフェールオーバークラスターマネージャーから設定できる "ライブマイグレーションの

設定" に従います。以上から、以下の各設定を行うことで、S2D 通信とライブマイグレーション通信のイ

ンターフェースを分離することが可能です。

• S2D 通信用のネットワークはクラスターで利用する、かつクラスターネットワークとしては外

部通信に利用しない設定

• ライブマイグレーション用ネットワークはクラスターネットワークとして利用しない設定

• ライブマイグレーションの設定としては以下のようにライブマイグレーション用ネットワ

ークを最優先に設定

以上の設定は一例であり、他にも NIC パーティショニングや、SMB マルチチャネルの経路固定 (SMB

Multi-Channel Constraint)、OS 標準のポリシーベースのネットワーク QoS 等、各種ネットワークの制御

関連機能・設定を組み合わせて、実際の環境のハードウェアやネットワーク要件に応じた設計を行う必要が

あることをご留意ください。

ネットワークオフロード関連設定 (参考情報)

S2D 通信用のインターフェースとして RDMA ではなく 10GbE を利用する場合、S2D による通信は通常

の SMB で実施されるため、TCP/IP の通信処理には割込み処理等の CPU 処理が相当量発生します。その

ため、通信処理に伴う CPU 負荷を抑制・分散するための各種オフロード関連機能を設定する必要がありま

す。本項で解説する各機能を適切にチューニングしなかったり、機能を無効化したりすると、一部の CPU

コアへ負荷の偏りが発生する可能性があります。その結果、通信速度が十分に出ない、CPU コア 0 のみに

負荷が集中しシステムが不安定になるといった弊害が発生する可能性があります。

ここで考慮するネットワーク関連オフロード機能の代表的なものとして、RSS、VMQ、vRSS について言及

します。

Receive Side Scaling (RSS)

RSS はネットワークドライバーにより、受信処理を複数 CPU コアに分散して処理させるオフロード機能

です。Windows Server 2003 SP1 時代に SNP 機能の一つとされていたことから、問答無用で無効化さ

れることも多い機能ですが、Windows Server 2012 以降では非常に重要な役割を担っていることから、有

効化した上でチューニングすることを強くお勧めします。RSS はホスト OS が物理 NIC を直接利用する

場合に、該当 NIC 毎に設定します。

詳細な設定や確認は PowerShell から実施します。主要な設定項目は以下になります。

• NumberOfReceiveQueues: RSS のキューの数。1, 2, 4, 8… と 2 の倍数を設定。NIC 側のサポ

ート上限や、割り当てるコア数との兼ね合いを考慮すること

• BaseProcessor: 利用する複数コアの内、先頭コアを指定

• MaxProcessor: 利用する複数コアの内、末端コアを指定

• MaxProcessors: 利用するコアの総数を指定

設定における推奨事項は以下になります。(優先度が高い順)

• Hyper Threading を認識し、論理コアでなく物理コアに割り振るので Hyper Threading 有効な

環境はそれを踏まえて割り振るコアを決定する

• コア 0 (Hyper Threading 有効の場合は 0 と 1）は既定のトラフィックに利用されるため割り当

てを避ける

• 重複したコアの割り当てはサポートされるが、CPU 数が十分な場合には可能な限り避ける

設定例 1: Hyper Threading 無効、8 コア環境、物理 NIC 2 つで全 CPU を利用する場合

Set-NetAdapterRss -Name "NIC1" -BaseProcessorGroup 0 -BaseProcessorNumber 1 -

MaxProcessorGroup 0 -MaxProcessorNumber 4 -MaxProcessors 4 -NumberOfReceiveQueues 4

Set-NetAdapterRss -Name "NIC2" -BaseProcessorGroup 0 -BaseProcessorNumber 4 -

MaxProcessorGroup 0 -MaxProcessorNumber 7 -MaxProcessors 4 -NumberOfReceiveQueues 4

設定例 2: Hyper Threading 有効、8 コア環境、物理 NIC 2 つで全 CPU を利用する場合

Set-NetAdapterRss -Name "NIC1" -BaseProcessorGroup 0 -BaseProcessorNumber 2 –

MaxProcessorGroup 0 –MaxProcessorNumber 8 -MaxProcessors 4 -NumberOfReceiveQueues 4

Set-NetAdapterRss -Name "NIC2" -BaseProcessorGroup 0 -BaseProcessorNumber 8 -

MaxProcessorGroup 0 -MaxProcessorNumber 14 -MaxProcessors 4 -NumberOfReceiveQueues 4

Virtual Machine Queue (VMQ)

VMQ は仮想マシンの通信処理用にキューを作成し、キュー事に分散した CPU で処理するオフロード・分

散機能です。VMQ は仮想スイッチに接続する物理 NIC に対して有効化し、設定を行います。

VMQ の利用要件は以下となります。

• NIC が RSS をサポートしていること

• NIC が VMQ をサポートしていること

• オペレーティング システムとドライバーのレベルで有効になっていること

• 仮想マシンのネットワーク アダプターの設定で有効になっていること

VMQ も RSS と同様に PowerShell で設定・確認を実施します。主要な設定項目は以下になります。

• BaseProcessorNumber:利用する複数コアの内、先頭コアを指定

• MaxProcessorNumber:利用する複数コアの内、末端コアを指定

• MaxProcessors: 負荷を分散するため使用できるプロセッサーの最大数

設定における推奨事項は以下になります。(優先度が高い順)

• CPU0 (HT 有効な場合は 0 と 1)はホストにより利用される比重が高いため、VMQ に割り当てない

• 異なるネットワークアダプターが異なるコアを利用し、重複しないように割り当てる

• 可能な限り多くの数の CPU に分散されるよう割り当てる

• キューから割り振られる CPU が NUMA ノードや物理コアを跨がないように割り当てる

VMQ が正常動作している場合、以下のように Hyper-V マネージャー上でも確認可能です。

設定を行う PowerShell の実行例は以下になります。

Set-NetAdapterVmq -Name VM-1 -BaseProcessorGroup 1 -BaseProcessorNumber 16 -

MaxProcessorNumber 22 -MaxProcessors 4

Set-NetAdapterVmq -Name VM0-2 -BaseProcessorGroup 1 -BaseProcessorNumber 24 -

MaxProcessorNumber 30 -MaxProcessors 4

仮想 RSS / vRSS

vRSS は Windows Server 2012 R2 で実装された機能で Hyper-V 仮想マシンが利用する仮想 NIC で

RSS を利用可能とするものです。これは、VMQ を利用して物理レイヤーでは分散したものの、仮想マシン

内部で高スループットを出そうとした場合、仮想マシン内部で CPU ボトルネックが生じて通信スループッ

トが出ない、という事態に対処するために追加されました。そのため、vRSS の利用の前提として、物理 NIC

側で VMQ を設定し動作していることが前提となります。

Windows Server 2016 からはホストが利用する仮想 NIC についても、仮想マシン内部と同様に vRSS

が利用可能になりました。これにより、物理 NIC を集約した、いわゆるコンバージドネットワーク構成で

の設計に幅が増えました。vRSS は端的には仮想 NIC で RSS の有効化と各種設定が可能になった、とい

うことと等しいため、RSS としての設定そのものは記述の内容と同様となります。

S2D の運用設計

S2D の運用や監視設計は、従来の Failover Cluster のものをベースに考えることができます。ここでは

S2D 特有の情報を記載します。

パフォーマンスカウンター

S2D でキャッシュディスク（ジャーナル）を利用している場合のパフォーマンス測定に有用なパフォーマ

ンスカウンターを紹介します

\\Cluster Storage Hybrid Disks

S2D でジャーナル (キャッシュ) ディスクを使用している場合に利用可能なパフォーマンス カウンター

です。このカウンターの名前の通り、Hybrid Disk 単位で測定するパフォーマンスカウンターです。 Hybrid

Disk は 物理データディスクとキャッシュディスクを組み合わせたもので、インスタンス名は 10:0 や

20:1 などという表記です。 10 や 20 はデータ物理ディスクの番号、 0 や 1 はキャッシュ用物理ディ

スクの番号です。

代表的なカウンターは以下の通りです。

Cache Hit Read Bytes/sec

Cache Hit Reads/sec

Cache Write Bytes/sec

Cache Writes/sec

1 秒間にキャッシュディスクにたいして読み書きしたデータの量、回数を表示します。

Cache Miss Read Bytes/sec

Cache Miss Reads/sec

キャッシュディスクから読み取ろうとしたものの、データが存在せず HDD や SSD から読み取った 1

秒間あたりのデータ量や回数を表示します。

Direct Read Bytes/sec

Direct Reads/sec

Direct Write Bytes/sec

Direct Writes/sec

キャッシュディスクを利用せず、HDD や SSD に対して読み書きした 1 秒当たりのデータの量や回数を

表示します。（Cache Miss Read Bytes/sec などとは違い、キャッシュ上のデータの有無に関係なく HDD

や SSD に読み書きしていることに注意してください。）

\\Cluster Storage Cache Stores

先の Hybrid Disk のパフォーマンスカウンターとは異なり、ノード毎にキャッシュの状態を収集します。

こちらのカウンターでは、 Page Hit/sec でキャッシュヒット回数を確認したり、 Destage Bytes/sec な

どで、キャッシュ領域から退避したデータ量などを確認したりすることができます。

\\Refs

CSV のファイルフォーマットで Refs を選択した場合はこちらのカウンターで情報を収集可能です。特に

SSD と HDD を使って階層化ストレージを構成している場合は、それらの状態も収集できます。

\\Storage Space Tier

\\Storage Spaces Virtual Disk

\\Storage Spaces Write Cache

これらのパフォーマンスカウンターは記憶域スペースとしての情報を収集します。Storage Space Tier で

は各階層の情報、 Storage Space Virtual Disk は文字通り Virtual Disk 単位、 Write Cache では書き

込みキャッシュに関するデータを収集します。

\\RDMA Activity

RDMA 対応 NIC を搭載し、使用している場合はこのパフォーマンスカウンターから情報を収集します。一

部の RDMA 対応 NIC では、RDMA を使った通信に関する情報は \\Network Interface などのカウン

ターでは情報を収集できないため、こちらのパフォーマンスカウンターも確認するようにしてください。

バックアップ

システム領域のバックアップ

システム領域のバックアップについては通常の Windows Server と変わりません。 Windows Server バ

ックアップなどを使用してバックアップを取得することができます。また、S2D の AutoConfig が有効な

場合はノード追加が容易なため、バックアップデータから復旧するのではなく、新規にサーバーを構築して

ノード追加の形で復旧させることができるかもしれません。

S2D で作成したボリュームのバックアップ

S2D で作成したボリュームのバックアップは、従来の Failover Cluster の Cluster Shared Volume

(CSV) のバックアップと同様と考えることが可能です。こちらも Windows Server バックアップなどを

利用することができます。

ただし、HCI など、S2D を仮想マシンのデータ保存先として利用している場合や、SQL Server のデータ

保存先として利用している場合、CSV 一括でバックアップを取得するほかに仮想マシンのゲスト上で個別

にバックアップを取得したり、SQL Server 上でバックアップを取得するほうが適している場合があります

ので、運用上どちらが最適かを検討してください。

また、 Hyper-V の仮想マシンや Azure の仮想マシンで S2D を構築している場合、仮想マシンのスナッ

プショットでバックアップを収集するとノード間のデータ整合性の問題が発生する可能性があるため推奨

しません。

System Center 2016 Operations Manager

System Center 2016 Operations Manager をご利用の場合には、ヘルスサービスから得た情報を元に監

視やダッシュボード表示を行える S2D 用の管理パックをリリースしておりますので、ご利用をご検討くだ

さい。

Microsoft System Center 2016 Management Pack for Windows Storage Spaces Direct

https://www.microsoft.com/en-

us/download/details.aspx?id=54700&WT.mc_id=rss_alldownloads_all&751be11f-ede8-5a0c-

058c-2ee190a24fa6=True

S2D の構築

ここでは S2D の構築方法の概要といくつかのオプションについて説明します。

S2D の有効化

S2D の構築手順の概要

S2D 構築ステップの概要は以下となります。なお、S2D の構築・管理に関しては GUI で行える操作は非

常に限定的になるため、PowerShell で行うことをお勧めします。

OS のインストール・設定

各サーバーに Windows Server 2016 をインストールし、S2D に利用する物理ディスクが正しく認識さ

れていることを確認します。また、Hyper-V やクラスターの構成に必要な設定を実施します。Hyper-V や

フェールオーバークラスター、ファイルサーバー、データセンターブリッジング等、必要な役割・機能を有

効化する他、詳細を後述するネットワークのオフロード関連の設定や帯域制御等の設定も行います。

クラスターの構成検証、構築

フェールオーバークラスターマネージャーを利用したクラスターの構成検証ウィザード、あるいは Test-

Cluster Cmdlet を利用し、クラスターの前提条件を満たしていることを確認します。なお、Test-Cluster

コマンドレットには S2D 用のテストオプションが存在します。例えば、以下のように実行してください。

$Nodes = "Server01","Server02","Server03","Server04"

Test-Cluster -Node $Nodes -Include "Storage Spaces Direct", インベントリ, ネットワーク, シ

ステムの構成

クラスターの構成検証をパスしたことを確認の上、フェールオーバークラスターマネージャーあるいは

New-Cluster Cmdlet でクラスターを構成します。

S2D の有効化

クラスター構築後、以下のコマンドレットを実行することで、クラスター全体で S2D が有効となります。

Enable-ClusterStorageSpacesDirect

Enable-ClusterStorageSpacesDirect コマンドレットのオプションの詳細は後述しますが、フォールトド

メインを構成していない場合は、既定で自動構成が有効となり、S2D のストレージプール作成まで自動で

実施されます。

仮想ボリュームの作成

S2D が有効化され、ストレージプールが作成されていることを確認後、New-Volume コマンドレットを利

用し、仮想ボリュームを作成します。以下の実行例では 1TB の 3-Way Mirror の仮想ボリュームを作成

しています。

New-Volume -FriendlyName "CSV01" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D*

-Size 1TB -PhysicalDiskRedundancy 2 -ResiliencySettingName Mirror

物理ディスクのクリーンアップ

S2D 環境の評価を行う場合等において、S2D 環境で利用されたことのある物理ディスクを再利用する際に

は、物理ディスクに含まれる各情報をクリーンアップする必要があります。以下の PowerShell を実行する

ことで、クラスター環境でストレージプールや仮想ボリュームの全削除と全クラスターノード上の全ての物

理ディスクのリセットを行うことが可能です。

Invoke-Command (Get-Cluster | Get-ClusterNode) {

Update-StorageProviderCache

Get-StoragePool | ? IsPrimordial -eq $false | Set-StoragePool -IsReadOnly:$false -

ErrorAction SilentlyContinue

Get-StoragePool | ? IsPrimordial -eq $false | Get-VirtualDisk | Remove-VirtualDisk

-Confirm:$false -ErrorAction SilentlyContinue

Get-StoragePool | ? IsPrimordial -eq $false | Remove-StoragePool -Confirm:$false -

ErrorAction SilentlyContinue

Get-PhysicalDisk | Reset-PhysicalDisk -ErrorAction SilentlyContinue

Get-Disk | ? Number -ne $null | ? IsBoot -ne $true | ? IsSystem -ne $true | ?

PartitionStyle -ne RAW | % {

$_ | Set-Disk -isoffline:$false

$_ | Set-Disk -isreadonly:$false

$_ | Clear-Disk -RemoveData -RemoveOEM -Confirm:$false

$_ | Set-Disk -isreadonly:$true

$_ | Set-Disk -isoffline:$true

}

Get-Disk |? Number -ne $null |? IsBoot -ne $true |? IsSystem -ne $true |?

PartitionStyle -eq RAW | Group -NoElement -Property FriendlyName

} | Sort -Property PsComputerName,Count

Enable-ClusterStorageSpacesDirect のオプション

S2D 構築時に使用する Enable-ClusterStorageSpaceDirect (Enable-ClusterS2D) コマンドには幾つか

のオプションが用意されています。これらのオプションを指定することで S2D の動作が変わりますので主

なオプションを紹介します。

-AutoConfig ${true | false}

S2D の運用時に発生するタスクの多くを自動化します。最初の構築時には記憶域プールの作成などを自動

的に行い、物理サーバーへ物理ディスクの追加を行った場合は自動的に記憶域プールへ登録します。また、

ディスク障害などで切断状態が一定時間継続した場合は自動的に記憶域プールから登録を解除します。 明

示的に指定しなかった場合は $true が設定されます。

-CacheState ${true | false}

後述の SSD を利用したキャッシュの有効/無効を制御します。デフォルトでは $true が設定され、キャッ

シュとして利用可能なディスクが存在する場合はそれらをキャッシュ デバイスとして登録します。

ヘルスサービスの設定

既述の通り Windows Server 2016 には S2D を含むストレージ プールの効率的な管理のため、フェール

オーバー クラスターに ヘルスサービス が実装されています。

ヘルスサービスは S2D に限定しないストレージサブシステムへのインターフェース役を担い、名称通りに

ストレージの健全性に関する情報の確認を可能としています。また、それだけではなく、S2D の各種自動

化処理を実施する役割も担っています。具体的な例としてはディスク故障時のプールからの自動切り離し

(AutoRetire) や、新しいディスクをサーバーへ追加した際のプールへの自動追加 (AutoPool) 等のタスク

はヘルスサービスによって実行されます。なお、S2D 構築時の Enable-ClusterS2D コマンドで -

Autoconfig オプションを $false で実行した場合にはこれらの処理は自動的に行われません。

ヘルスサービスの設定は以下のように Get-StorageHealthSetting コマンドレットを実行することで確認

可能です。

Get-StorageSubSystem Cluster* | Get-StorageHealthSetting

設定可能な項目とそれぞれの既定値については以下の公開情報をご確認ください。

Health Service in Windows Server 2016

https://docs.microsoft.com/en-us/windows-server/failover-clustering/health-service-overview

一例としてはディスクのライフサイクルに関する設定を抜粋すると、設定項目と既定値は以下となります。

"System.Storage.PhysicalDisk.AutoPool.Enabled” = True

"System.Storage.PhysicalDisk.AutoRetire.OnLostCommunication.Enabled” = True

"System.Storage.PhysicalDisk.AutoRetire.OnUnresponsive.Enabled” = True

"System.Storage.PhysicalDisk.AutoRetire.DelayMs” = 900000

"System.Storage.PhysicalDisk.Unresponsive.Reset.CountResetIntervalSeconds" = 360

"System.Storage.PhysicalDisk.Unresponsive.Reset.CountAllowed” = 3

設定変更は Set-StorageHealthSetting コマンドレットを利用します。具体例としては以下のようになり

ます。

Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name

"System.Storage.PhysicalDisk.AutoRetire.DelayMs" -Value 1800000

-CacheDeviceModel

キャッシュ用に使用するディスクのモデルを明示的に設定します。サーバーに接続されている SSD が複数

のモデルがある場合、指定する必要があります。読み込み性能や書き込み性能、書き込み耐久性など複数の

指標から設定するモデルを検討する必要があります。このオプションには複数のモデルを指定することが可

能です。尚、こちらのオプションでキャッシュ用に指定するディスクは NVMe 対応ディスクであることが

必須ではなく、SAS や SATA で接続して SSD を指定することも可能です。

Enable-ClusterStorageSpacesDirect

https://technet.microsoft.com/itpro/powershell/windows/failoverclusters/enable-

clusterstoragespacesdirect

キャッシュモードの確認/変更

既述の通り、S2D では複数種別のドライブを利用している場合、デフォルトではより高速な種別のディスク

をキャッシュディスクとして利用します。システムがどのディスクをキャッシュとして使用しているかの確

認は以下の PowerShell コマンドを実行し、 Usage の列を確認することで可能です。 Usage が Journal

と表示されているディスクがキャッシュ ディスクとして利用されています。

Get-StoragePool -FriendlyName S2D* | Get-PhysicalDisk

キャッシュ (Journal) ディスクが搭載されていて、データディスクが SSD の場合は Write キャッシュと

して、データディスクが HDD の場合は Read/Write キャッシュとして利用するのがデフォルトの動作で

す。S2D は Set-ClusterS2D コマンドを使用することでこれらの動作を変更することが可能です。データ

ディスクが HDD の場合に Write キャッシュとして利用するためのコマンド使用例はこちらです。

Set-ClusterS2D -CacheModeHDD WriteOnly

データディスクが SSD の場合に Read/Write キャッシュとして利用するためのコマンド使用例はこちら

です。

Set-ClusterS2D -CacheModeSSD ReadWrite

さらにキャッシュを無効にする場合は以下のコマンドを利用します。

Set-ClusterS2D -CacheState Disabled

キャッシュを有効にする場合は以下のコマンドを利用します。

Set-ClusterS2D -CacheState Enabled

現在の S2D のキャッシュの設定を確認するには Get-ClusterS2D コマンドを利用します。

Get-ClusterS2D

階層化ストレージ

階層化ストレージ機能も記憶域スペース時代から引き続き、S2D で利用可能です。そのため、手動構成は

必要になりますが、NVMe SSD キャッシュ + SAS SSD ミラー + SAS HDD パリティの構成を行うこと

も可能です。

New-StorageTier -StoragePoolFriendlyName S2D* -MediaType SSD -PhysicalDiskRedundancy

2 -ResiliencySettingName Mirror -FriendlyName Performance

New-StorageTier -StoragePoolFriendlyName S2D* -MediaType HDD -PhysicalDiskRedundancy

2 -ResiliencySettingName Parity -FriendlyName Capacity

New-Volume -FriendlyName 'Tierd-vDisk' -FileSystem CSVFS_ReFS -

StoragePoolFriendlyName S2D* -StorageTierFriendlyNames Performance, Capacity -

StorageTierSizes 200GB,600GB

詳細は以下をご確認ください。

Adding servers or drives to Storage Spaces Direct

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/add-nodes

仮想ディスク チューニング

S2D でストレージプールから仮想ディスクを作成するときは可用性オプションとして Mirror と Parity

のどちらかを選択することができます。基本的には Mirror のほうが I/O 性能が高く Parity は低くなりま

す。ただし、容量効率という観点では Parity の方が高く、Mirror の場合、作成可能な仮想ボリュームのサ

イズが小さくなります。前述の通り、Mirror と Parity を併せて利用する階層化構造を行うことも可能です

ので、要件やハードウェアスペックに応じて詳細を詰めていく必要があります。

また、New-Volume コマンドや New-VirtualDisk コマンドでは冗長化形式のみでなく、パフォーマンス

に関係するオプションを指定することが可能です。ここでは主なオプションを紹介します。

-NumberOfColmuns

3Way ミラーのボリュームを作成した場合は同じデータを (障害ドメインを跨いで) 3 つのディスクに保存

しますが、同時に単一のデータを複数のディスクに分散保存 (ストライピング) して I/O パフォーマンス

を向上させます。-NumberOfColmuns によって分散保存に利用するディスクの本数を指定します。

この値の最大値は物理ディスクの本数の 1/3 です。（物理ディスクが 18 本の場合は最大 6、 物理ディスク

が 48 本の場合は最大 16 です）通常物理ディスクが 24 本までの場合は自動的に最適な値が設定されます

が、それ以上の場合はデフォルトの値は 8 です。

S2D に登録している HDD が 48 本の検証環境で、NumberOfColmuns がデフォルトの 8 の場合と 16 に

設定した場合の I/O パフォーマンスの違いは以下の通りでした。

今回のベンチマークや SQL Server などのように、少数のファイルに対して負荷をかけるようなワーク

ロードでは NumberOfColmuns の値を大きくすることによってパフォーマンスが向上する可能性があり

ますが、多数の仮想マシンを実行するなど、多数のファイルに並列で負荷をかけるようなワークロードでは

逆にパフォーマンスが下がる可能性があります。そのため、運用環境で利用する場合はできるだけ実際のワ

ークロードに近い形で負荷試験を行い、効果を確認することをお勧めします。

-Interleave

S2D では複数の物理ディスクへデータをストライピングする際のストライプサイズを Interleave で設定

可能です。デフォルト値は 256k になっています。各 I/O で生じるデータサイズがインターリープサイズ

を超えた場合、複数のストライプに分割される関係でパフォーマンスが下がるため、利用用途で生じる の

データサイズを踏まえてインターリープサイズを検討する必要があります。

今回、インターリープサイズを変更し、仮想マシンからの I/O による性能の変化傾向を確認した結果が以

下となります。

S2D の運用

本項では運用に関する内容をまとめます。

ノード・ディスクの追加

以下の 2 条件を満たす場合、新しいクラスターノードや物理ディスクの S2D のプールへの追加は自動で行

われます。

• ヘルスサービスの設定で AutoPool.Enabled が有効であること

• S2D のプールが一つのみであること

Enable-ClusterStorageSpacesDirect コマンドレットを既定値で実行し、自動構成した場合にはどちらの

条件も満たします。クラスターノードの追加に際しては、クラスターノードの追加前に Test-Cluster コマ

ンドレットによりクラスターの構成検証をパスすることを事前に確認してください。

詳細は以下もご参考ください

Adding servers or drives to Storage Spaces Direct

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/add-nodes

ボリュームの拡張

作成済みの仮想ディスクのサイズ拡張は以下の流れで実行可能です。

• 対象仮想ディスク上で動作している仮想マシン・ワークロードの停止あるいは移動

• 仮想ディスクの I/O の停止

• 仮想ディスクのサイズの拡張

• 仮想ディスク上のパーティションサイズの拡張

• 仮想ディスクの I/O の再開

• 対象仮想ディスク上で動作している仮想マシン・ワークロードの再開あるいは移動

具体的な PowerShell での実行例は以下となります。注意事項として、サイズを変更する対象のパーティシ

ョンは 2 つ目のもので固定であり、1 つ目のパーティションはシステム利用に予約されていることに注意

してください。

Get-ClusterSharedVolume <Name> | Suspend-ClusterResource

Get-VirtualDisk <FriendlyName> | Resize-VirtualDisk -Size <Size>

$Partition = Get-VirtualDisk <FriendlyName> | Get-Disk | Get-Partition | Where

PartitionNumber -Eq 2

$Partition | Resize-Partition -Size ($Partition | Get-PartitionSupportedSize).SizeMax

Get-ClusterSharedVolume <Name> | Resume-ClusterResource

詳細は以下もご参考ください。

Extending volumes in Storage Spaces Direct

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/resize-volumes

ノードのメンテナンス

更新プログラムの適用や再起動等のメンテナンスに際し、S2D のノードを停止する際はクラスターノード

として一時停止することで、安全に作業を行うことができます。また、一時停止する際にドレイン実行を指

定することで、対象ノード上で動作している仮想マシンの他ノードへのライブマイグレーションと、復帰す

る際のフェイルバック指定により、復帰後に元々の仮想マシンを自ノード上に再ライブマイグレーションを

実行することが可能です。

Suspend-ClusterNode -Name "Node Name" -Drain

Resume-ClusterNode -Name "Node Name" –Failback

メンテナンス対象ノードの復帰後、S2D 仮想ディスクの再同期・修復ジョブの状態は Get-StorageJob コ

マンドレットで確認可能です。

Get-StorageJob

※完了したジョブは完了して一定時間経過すると非表示になりますので注意してください。

詳細は以下もご参考ください。

Taking a Storage Spaces Direct server offline for maintenance

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/maintain-servers

サーバーの削除

S2D を構成するクラスターからノードを削除する場合には、-CleanupDisk オプションを付与して実行す

ることで、ノード削除時に対象ノード上の物理ディスク情報をクリーンアップすることが可能です。

Remove-ClusterNode "Node Name" -CleanUpDisks

なお、当然ながら、ノード削除後も仮想ディスクの冗長設定や容量を維持できるだけのノード数・ディスク

数が担保されていることを確認してから実行する重要です。

詳細は以下もご参考ください。

Removing servers in Storage Spaces Direct

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/remove-servers

ディスクのファームウェア更新

S2D では個別の物理ディスク単位でファームウェアを更新する Update-StorageFirmware コマンドレ

ットの他、ディスク毎のファーム情報を XML にまとめ、ヘルスサービス経由で設定を行うことで、各物理

ディスクのファームウェアを自動でローリングアップデートする機能を有しています。

具体的な実行方法や注意事項等については以下の情報をご確認ください。

Updating drive firmware in Windows Server 2016

https://docs.microsoft.com/en-us/windows-server/storage/update-firmware

状態の確認

StorageHealthReport

S2D の監視としては後述するパフォーマンスカウンターの他、各 PowerShell コマンドレットで状況確認

が行えます。俯瞰的な情報としては記述の Get-StorageHealthReport が有効です。

Get-StorageSubSystem Cluster* | Get-StorageHealthReport

Get-SmbMultiChannelConnection

S2D のノード間通信で SMB を使用していることは前述の通りですが、SMB がノード間通信にどの NIC

を利用し、RDMA などの機能を使用しているかどうかは Get-SmbMultiChannelConnection コマンドを

使用します。

Get-SmbMultiChannelConnection コマンドを引数無しで実行した場合は S2D のノード間通信に関する

SMB セッション情報は表示されません。もし表示したい場合は -SmbInstance オプションに CSV を指定し

て実行する必要がありますので注意してください。

Get-SmbMultichannelConnection

https://technet.microsoft.com/en-us/itpro/powershell/windows/smbshare/get-

smbmultichannelconnection

障害発生時

ディスクの状態の確認・交換、障害時の動作

利用中の物理ディスクの状態は以下のように Get-StoragePool コマンドレットと Get-PhysicalDisk コ

マンドレットを利用することで確認が可能です。

Get-StoragePool S2D* | Get-PhysicalDisk

物理ディスクに問題がある例として、物理ディスクが接続されていない状態は Lost Communication、物

理ディスクが応答していない状態は Unresponsive と表示されます。各異常状態のディスクの自動リタイ

ア設定が有効化されている場合は、自動リタイアの設定間隔(既定値は 15 分) で対象物理ディスクは

Retire のステータスに自動で変更されます。Enable-ClusterStorageSpacesDirect コマンドレットで自動

構成した場合は自動リタイア機能が有効です。

問題のある物理ディスクを特定し、正常な物理ディスクを交換した場合、AutoPool が有効であれば物理デ

ィスクが認識され次第、プールに自動で追加されます。また、データの再配置・最適化は 30 分毎に自動で

行われるため、交換された物理ディスクへの実データの配置が必要であれば、そのまま自動で実施されます。

復旧の確認

前述のノードメンテナンスの項で説明した通り、ノードの復帰後、S2D 仮想ディスクの再同期・修復ジョ

ブの状態は Get-StorageJob コマンドレットで確認可能です。

Get-StorageJob

※完了したジョブは完了して一定時間経過すると非表示になりますので注意してください。

詳細は以下もご参考ください。

Taking a Storage Spaces Direct server offline for maintenance

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/maintain-servers

ノードやディスクの追加、復旧作業のタイミング

前述の通り、AutoPool が有効な状態で新しいディスクやノードを追加した場合、自動的にデータの再配置

が行われ、ディスクやネットワークに少なからず負荷がかかります。そのため、システムの負荷が高く、リ

ソースに余裕がない時間帯にノードやディスクの追加を避けるなどの運用が必要になるかもしれません。

また、必要に応じてシステム設計時にデータ再配置に伴う負荷を見越してサイジングを行う必要があるかも

しれません。

まとめ

本ドキュメントでは、Windows Server 2016 に新しく実装された Storage Spaces Direct (S2D) の情

報を記載してきました。

S2D の登場によって従来よりもシンプルなシステム構成が可能になりますが、S2D を実際の運用環境で利

用する場合は S2D 特有の機能だけではなく、フェールオーバー クラスターや スケールアウト ファイル

サーバー、SMB などの関連機能、RDMA や NVMe などのハードウェアが持つ機能や規格を理解すること

が正しい設計や運用に必要になります。

ぜひこの機会に最新の情報を収集して S2D をご利用ください。