Windows Server 2022新機能「記憶域バスキャッシュ」を試してみた

Windows Server 2022から使用できるようになった「記憶域バスキャッシュ」機能の検証結果の紹介です。構成操作の手順は、MicrosoftのWebページに解説があり、それに沿ったものですが、構成後にIO性能の測定やストレージ障害テストを行っており、その結果を含めて共有します。

記憶域バスキャッシュとは？

記憶域バスキャッシュ（Storage Bus Cache）の詳しい解説は、MicrosoftのWebページに解説があります。

記憶域スペース上の記憶域バスキャッシュ

スタンドアロンサーバーで記憶域バスキャッシュを有効にして、読み取りおよび書き込みのパフォーマンスを向上させる方法について説明します。

一言でいうと、「HDDの低コストさ」と「SSDの高性能さ」のいいとこ取りができるというものです。HDDとSSDが複数混在するサーバーで記憶域バスキャッシュを使うと、HDDベースの容量が確保でき、SSDはキャッシュとして使います。もちろんSSDのみのオールフラッシュ構成が出来るならそれに越したことは無いですが、比較的低コストでこの性能に近づけることが（理論上）できるというものです。

この機能が、Windows Server 2022からスタンドアロンサーバーで構成できるようになりました。一応、2019以前でも似た機能（記憶域スペースダイレクト）がありましたが、こちらは複数台構成でかつDatacenterエディションが必要だったり、認証を受けたハードウェアが必要だったりと、要件がかなり厳しかったのです。

構成例

今回紹介するのは、下のようなストレージ構成としてみます。

240GBのSSDを3台、1TB 7,200rpmのHDDを3台の合計6台で記憶域バスキャッシュの構成を行います。いずれもSATA接続や7,200rpm HDDという、サーバー部品としては安価なものを選んでいます。

そのほか、OS用としてHDD2台（RAID1のミラー）を積んでいます。OS用のHDDは、記憶域バスキャッシュの構成に含めることはできないようですので独立させています。

合計ストレージ本数は8本となっています。6本くらいで構成できれば良いのですが、ある程度の信頼性を確保しつつ、ミラー高速パリティによるパフォーマンスを実現する構成はこのあたりではないでしょうか。これより少ない本数では、SSDを1本切断しただけでボリューム全体が見えなくなるなど、信頼性を確保することが出来ませんでした。このあたりの構成に関する考察は、下記の記事に別途まとめています。

OSはWindows Server 2022 Standardです。2021/11/16時点で最新の更新プログラムを適用しています。

操作例

仮想化環境（VMware Workstation Player の仮想マシン）を使って上記構成を再現し、記憶域バスキャッシュを構築してみましたので、その過程を紹介します。手順はもちろん、前述のMicrosoftのWebページを参考にしています。

機能のインストール

記憶域バスキャッシュを使用するには、「フェールオーバークラスタリング」機能の追加が必要です。

スタートメニューなどから「サーバーマネージャー」を起動し、ダッシュボードの「役割と機能の追加」を選択します。ウィザードを「次へ」ボタンで進めていき、「サーバーの役割の選択」では何も選択せず「次へ」を押します。

「機能の選択」画面に進んだら、一覧から「フェールオーバークラスタリング」にチェックを入れます（すでにチェックされていて「インストール済み」と表示されている場合は、機能のインストール作業は不要です）。このとき、「必要な機能を追加しますか？」の画面が出るので「機能の追加」を選択します。この状態で「次へ」を押します。

このあとはウィザードに従って、機能のインストール完了の表示が出るまで操作を進めます。

PowerShellプロンプトの起動と準備

ここからはPowerShellコマンドでの操作が主になります。スタートボタンを右クリックし「Windows PowerShell (管理者)」を選択するなどして、管理者としてPowerShellプロンプトを起動します。

最初に下のコマンドを実行して、必要なPowerShellのモジュールをインポートしておきます。不要なケースもあるかもしれませんが、MicrosoftのWebページに従って、一応やっておきます。

Import-Module StorageBusCache

PowerShellプロンプト画面が文字化けする場合は、こちらの記事を参照して下さい。

物理ディスク構成の確認

次に、下のコマンドを実行して物理ディスクを確認します。

Get-PhysicalDisk

物理ディスクの一覧が表示されます。信頼性を確保する構成のために、下のようにCanPoolがTrueのディスクのうち、MediaTypeが「HDD」のものが３つ以上、「SSD」（またはNVMe）のものが３つ以上あることを確認します。

記憶域バスキャッシュの有効化

物理ディスク構成に問題が無さそうであれば、下のコマンドを実行して、記憶域バスキャッシュを有効化します。ちなみに、対象の物理ディスクを選ぶような操作は無く、ブートドライブ以外で使用可能なドライブ全てが使われるようです。

Enable-StorageBusCache

コマンドを実行すると、下の画面のように、進捗状況が表示された後、何も結果は返りません。もしここでエラーが表示される場合は、構成に問題がある可能性があります。

記憶域バスキャッシュの確認

次のコマンドで、記憶域バスキャッシュが有効になっているかを確認します。

Get-StorageBusCache

有効になっていれば、下のようになります。Enabledが「True」になっていることを確認します。

続いて、次のコマンドで記憶域プールが作成されていることを確認します。

Get-StoragePool

正しく作成されていれば、下のように「Storage Bus Cache on {コンピューター名}」という名前の記憶域プールが表示されます。

ボリュームの作成

次はボリュームの作成のコマンドを実行します。下の例は、前述の操作で作られた記憶域プールに、1,000GBのボリュームを作成するコマンドです。

New-Volume –FriendlyName "TestVolume" -FileSystem ReFS -StoragePoolFriendlyName Storage* -StorageTierFriendlyNames MirrorOnSSD, ParityOnHDD -StorageTierSizes 200GB, 800GB

※改行せず１行として実行

上のコマンドの最後の部分がややこしいですが、合計1,000GBのうち、20%の200GBをSSD領域、80%の800GBをHDD領域に配置するイメージです。この20:80という比率は、Microsoftのページで「ほとんどのワークロードに推奨される構成」とのことですので、これに従いました。

コマンドを実行すると、下のように進捗が表示された後、作成されたボリュームの情報が表示されます。もしエラーが表示される場合は、構成やサイズ指定などに問題がある可能性があります。

ボリューム作成結果の確認

ボリュームの作成結果は、サーバーマネージャーから確認すると分かりやすいようです。サーバーマネージャーを起動し、「ファイルサービスと記憶域サービス」から「記憶域プール」を開きます。下のように記憶域プールやボリュームが表示されていることを確認します。ここで右下の「仮想ディスク」にあるボリューム名を右クリックして「プロパティ」を見てみます。

プロパティを開くと、下のようにSSDとHDDのそれぞれのサイズが表示されます。指定した通りになっていることを確認します。

ドライブ文字の設定

作成されたボリュームには、ドライブ文字（例：Eドライブ、Fドライブ）が割り当てられていません。ドライブとして使う場合はそれを設定します。サーバーマネージャーの「ファイルサービスと記憶域サービス」から「ボリューム」を開き、作成したボリュームを右クリックし「ドライブ文字およびアクセスパスの管理」から設定すると良いでしょう。

ここまでで、記憶域バスキャッシュを有効化したボリュームの作成は終了です。

性能測定

作成したボリュームで、IO性能を計測してみます。下が「CrystalDiskMark」でのベンチマークテスト結果です。

参考として、今回使用したHDD単体で測定した結果と、同じくSSD単体で測定した結果も載せています。「HDD3台のみのパリティ構成」とか「SSD3台のみのミラー構成」ではなく、それぞれ１台単体の結果です。そのため比較対象として厳密にはフェアではありませんので、あくまで参考です。

ちょうど分かりやすく「HDD以上SSD未満」の結果となっています。特にHDDの弱点と言えるランダムアクセスの値が10倍以上になっていますので、大幅な性能向上と言えるのではないでしょうか。

ベンチマーク結果

測定条件の補足

検証環境は「VMware Workstation Player」の仮想マシンであり、デフォルトだとホストマシンのディスクキャッシュが効いてしまい、正確なベンチマーク結果が出ません。そのため、こちらの記事で紹介している方法で、それを無効化した状態で計測しています。

また、仮想マシン上では複数のSSD,HDDに接続していると見せかけて構成していますが、物理的には１台のSSD,HDDで再現しています。そのため、特に書き込み処理では同じ装置に対して２重３重に書き込んでいると思われます。よって、上の結果のWrite性能は実際より低く計測されており、実際の構成ではさらに高い値になると考えられます。

信頼性の確認（ディスク障害時）

ボリュームの信頼性のテストため、構成するSSD,HDDが障害になったケースを実験してみます。下に示す通り、同時に１本までなら外しても継続稼働することが確認できました。サーバー機に求められる最低限の信頼性は、問題なく確保できそうです。

SSDを1つ切断した場合

検証環境は「VMware Workstation Player」の仮想マシンですので、稼働中にSSDの仮想ハードディスクを1つ削除してみました。しかし、ボリュームは失われず、問題なくアクセスできます（どのSSDを１つずつ削除しても同様）。サーバーマネージャーを確認すると、下のように警告マークが表示されていましたが、デスクトップに通知などは特にされませんでした。