ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × Windowsの記憶域階層の挙動(SSD層が優先的に使われるよ) Windowsの記憶域階層について調べてたら、MSの中の人が書いたUnderstand Storage Space Tiering in Windows Server 2012 R2がとても分かりやすかった。Windows Server 2000 R2時代のものだけど、今でも通じる内容でしょう多分。記憶域階層使おうとしてる人は一読しといた方がいいと思う。 元記事の焼き直しでしかないが、気になったことをメモっておく。 書き込み時 記憶域階層に入ってくるデータは、まずはSSD層に満杯になるまで書き込まれる。 SSD層が満杯になると、ランダムライトはSSD層内に予め確保されているライトバックキャッシュの方に書き込まれる。 ライトバックキャッシュも一杯になると、HDD層の方に書き込まれると共にライトバックキャッシュのHDD層へのフラッシュが行われる。 ライトバックキャッシュが空けば、ランダムライトは再びキャッシュの方に書き込まれる。 ここでのライトバックキャッシュとは、記憶域階層が持っている機能を指している。仮想ディスク毎にSSD層に確保される領域で、標準では1GBだがNew-VirtualDiskコマンドレットの引数-WriteCacheSizeで任意の容量を指定できる。前述の通り、SSD層が埋まらないとライトバックキャッシュは使われないため、あまり大きな領域を確保しても無駄だと思われる。 自分はてっきり、ライトバックキャッシュという名前の通り、その領域分が書き込み全般のキャッシュとして使われると思っていた。Crystal Disk Markでキャッシュサイズを超えるテストサイズでベンチ回しても速度が全く落ちずに不思議だったが、なるほどSSD層全体がキャッシュとして使われてたとはね。 読み込み時 読み込みの方は明確な説明がないので間違ってるかも…。 SSD層にあるデータはSSD層から読まれる。 SSD層にないデータはHDD層から読まれる。 毎日の記憶域階層最適化によりSSD層とHDD層でデータの入れ替えが行われ、よく使われるデータはサブファイル単位でSSD層に配置される。 自分はZFSしか知らんのでZFSとの比較になっちゃうけど、読み込みキャッシュの方は割と慎ましい挙動のように思う。記憶域階層最適化のサブファイル単位というのは、1MBブロック単位らしい。 これらの挙動から分かる通り、記憶域階層ではSSD層が酷使されるため、相応のSSDと相応のデータ保護手段を用いた運用にしないとトラブりそう。SSD層が死んだ場合に、記憶域スペース/仮想ディスクがどうなるかは未確認&情報がない…。仕組み的にはSSD層にあるデータが死ぬだけで済みそうに思うんだけど、どうだかなー。現状、一旦記憶域階層として作ったが最後、後からSSD層を取り外す事もできないしなー。 参考サイト Understand Storage Space Tiering in Windows Server 2012 R2 – Larryexchange Blog The Effects Of WS2012 R2 Storage Spaces Write-Back Cache | Aidan Finn, IT Pro Windowsの記憶域階層な共有フォルダがプチフリする謎現象 Windows Storage Server 2016の記憶域階層から切り出したNTFSボリューム上に、CIFSで共有フォルダを作って別マシンからファイルを書き込むと、途中で処理が止まったようになり、当該フォルダを開くのですら超絶時間が掛かるようになる問題に遭遇中。なんとなく、SSD層が一杯になったタイミングで発生してるような気がするけど、有効な解決策は未だ見つけられず…。 記憶域階層は以下のような構成。 SSD層 Intel DC S3500 240GB×2 (RAID-0。記憶域に割り当ててるのは160GBほど) HDD層 8TB 7200RPM SATA×6(RAID-10。HDD×2のミラーリングが3セット。CMRなHDD) 記憶域プール全体を1ドライブに割り当てNTFSでフォーマット いずれもRAIDカードで仮想ドライブになってるので、記憶域からはSSDとHDDが1台ずつ見えてる感じ(ま、この構成自体がそもそも非推奨なんだけど。) そこに1KB~4GBの96ファイル計25.2GBをコピーすると、最初は順調なのに途中でパタリと処理が止まる。タスクマネージャを見ると「記憶域階層管理」なるものが動いているので、おそらくSSDが一杯になってHDDへのデータ移動が行われているのだろう。 でもって、リソースモニタでディスクの状態を見てみると、処理対象のファイルの応答時間がなんと1000ミリ秒を超えているじゃーありませんか。キューもめっちゃ溜まってるし(順調に処理が行われてる時は1未満。多くても3~4ってとこ。)データ移動待ちにしては、流石にレイテンシ長すぎじゃないですかね…。 実際の操作感としては、SSDに一定の空きができるまでファイルI/Oがブロックされてるような感じ。MSの中の人によれば、SSD層が一杯になるとIOPSが劇的に下がる──といってもHDD層相当の性能は出るんだけど(記事中のTest Case 1: Write to Used Storage Spaceらへん)、処理が完全に止まってしまうような感じにはならなさそう。 ネットに上がってる記憶域階層の使用例は殆どがHyper-Vがらみなので、ファイルサーバ向けに記憶域階層を使うってのがそもそもの間違いなのかしら?そうは言っても、使用頻度の高いデータをSSD層において高速化するって使い方はファイルサーバでもふつーにありそうな感じがするんだけどなぁ…。 Sambaだと大量のファイルの扱いに難あり、ってところからCIFSの純正実装なら安心だろうってことでWindows Serverを選択したのに、トホホですよ本当。僕たちの調査の旅はこれからだ…! (2018-08-16 追記) 何の役にも立たないと(僕の中で)名高いMSKKのフォーラムに同様の報告があった→記憶域スペースで階層化構築時における急激なパフォーマンス低下について。いつものごとく箸にも棒にもかからない回答で乾いた笑いしか出ないわけですが。 start.txt 最終更新: 2022-07-27 15:26by Decomo