階層記憶域（ミラー高速パリティ）をやめて記憶域を単純にする
階層記憶域（ミラー高速パリティ）というのはAzureなどサーバー向けの記憶域管理の方法で、NASサーバーにある「SSDとHDDを組み込んで高速帯と低速帯のドライブを使いわけ、速度と容量を求める」システムをそのままWindows上で実行するものだ。
なのでソフトウェアRAIDと言えるわけだが、これの記録方法が普通のWindowsのNTFSではなくReFSとかいう新しい記録方式なので、階層記憶域をNTFSでやるのは通常の方法ではない。が私は最近までWin11の記憶域プールを階層記憶域にしていた。
階層記憶域のメリット
私の場合、「ミラー：SATAのSSD4TB*2」+「パリティ：18TBのHDD*3」という構成で運用してきた。
これによってだいたい3TB+32TBの35TBくらいの記憶域ができたのでそれを貯蔵庫にしてきたわけだが、昔ディスクエラーの修復を記憶域プールにかけたらエラー訂正と引き換えにすべてのファイルが消失するというとんでもないミスを犯したことがあるので、記憶域プールのデータは速度優先の使い方をするものとしてデータ自体はバックアップを別で設けてきた。
階層記憶域のメリットは
・HDDのパリティ単独よりアクセス速度が速い
・記憶域を解体することなくディスクの交換ができる
ことにある。
記憶域をHDDだけでパリティ構成すると、体感として「読み込み速度はHDD1/2*台数」「書き込み台数はHDD1/2」というところで、例えば読み書き250MB/sのHDDを３台使ったとすると、読み250/2*3＝375MB/s、書き250/2＝125MB/sという感じでかなり遅い。素材の性能を考えると記憶域なんぞに組まずにソロで運用した方が読み書きにストレスを感じないだろう。
これをミラー高速パリティで記憶域を作ると、SSDが読み書き500MB/sだとすると、ミラーと銘打ってるのにストライピングのような読み込み速度（500*2だが実際は900MB/sくらい）で読み込みし、書き込みはSSD帯を利用しているうちは同等の速度が出る。まあSSD帯が容量いっぱいになればパリティHDDの遅い書き込みになるわけだが。
まあSSDを2台使っているのに容量は1台分なので勿体ないのは間違いない。
しかしSSDはミラー、HDDはパリティなのでどちらもバックアップを取る記録方法だ。なので、HDDを例えば18TBから20TBに変えたいという故障対応以外での入れ替えも、記憶域をストライピング（記憶域プールでの呼び方は「シンプル」）でつくると
①一度内容のバックアップを取ってから記憶域プールを解体、②新しいディスクを取り込み、③古いディスクを除いたディスクを取り込んで記憶域プールを作る
ということが必要だ。これがミラー高速パリティだと、
①新しいディスクを追加、②古いディスクを外す(物理的に外すという意味ではない)、③古いディスクからデータ移動が終わったら記憶域からディスクが除去される
ということになる。実は簡単に書いているがこのミラー高速パリティのディスク入れ替えは派手に時間を喰う。18TBで言えば30時間くらいだ。
これは現状維持のやり方で、記憶域プールをシンプロビジョニング (Thin Provisioning) で作っていればそのままでいいがFIXで作っている場合は実容量依存になる。なので18TB*(3-1)でパリティを作っているなら、まずHDDを3台とも20TBに変える必要がある。維持を考えるならさっき書いたように一度プールに20TBHDDを入れて18TBHDDを外すという工程が必要なので、容量アップはまず18TBHDDを全部交換してからになる。そしてそれを1日半かけて終わらせたら、次はPowershellでいろいろ修正してようやく移行完了になるので、正直メリットと言い難い。
階層記憶域のデメリット
階層記憶域のデメリットは
・接続台数に対して容量がいまいち
・ディスク交換の修正が手間
・データが時々破損する
になる。
普通に考えたら上の運用しているディスクは4TB*2+18TB*3なので、素材の味を生かしたら60TB近い容量を得られるわけだが階層記憶域に組み込んでしまったら35TBくらいまで減る。さらにSATAポートも5台喰っているので他のSATAの接続を諦めたりPCIスロットに増設カードを買って刺したりする必要も出てくる。まずこれがとても勿体ない。
そしてメリットとして書いた記憶域プールを解体することなくディスク交換できるというのも、その前後でPowershellで記述を変えたり果てしなく時間をかけたりする必要があるのではっきり言って面倒くさい。
とどめは保管先としての信用がデータ破損で失われたことだ。これは「記憶域内の画像ファイルや動画ファイルのサムネイルが下半分真っ黒くなったりしていると、開こうとしたらエラーで開けなくなっているデータが断続的に発生するようになった」というもので、こうなるとそのデータはバックアップ元から再度コピーが必要になる。
階層記憶域がNTFS向きではないのもそこで、ReFSという記録方式はデータ訂正ができるらしいので運用中にエラーでデータが駄目になるということを減らせるようなのだ。しかしWindows11は現状ReFSで記憶域プールを作れないのでエラー訂正はできない、つまり階層記憶域のデータは壊れたら治せないということになる。
さらばミラー高速パリティ
当初900MB/sでデータ読み書き出来たら最高じゃん！と思っていたので構成したが、このSSD
は値段を考えたら仕方ないのだが、キャッシュがだいたい800GBくらいの書き込みで切れる。そうすると以降は100MB/sも行かないような鈍足でデータ書き込みが始まるので、もしかしたらミラー高速パリティが全然高速ではなかったのはパリティのせいではなくこいつの所為の可能性もあるわけだが、まあ今となっては些末なことだ。
そしてAVIデータの書き込みにこいつは使えなかった。キャッシュが切れる前後で録画を終わらせたとき、エクスプローラでは記録分数が録画通りでプレイヤー上でもその通りなのに、MediaInfoで開くと分数が短くなっていることがある。これはキャッシュ切れなどで記録が遅くなった時に特に起きて、このAVIをAviutlで取り込むと末端が縞模様のエラーになってAviutlがクラッシュする。
これを解消するためにはエラー前でカットしてエラー部分を読み込みさせないようにすればよいのだが無駄な手間なので、もっとまともなディスクに記録すればこんなことを考えなくていい。
元データは別のドライブで管理が基本なので、この階層記憶域をつくったものの全く触らないということも多かった。
しかしサーバー用HDD3台は有用性があるので、ミラー高速パリティは解散させ、HDDだけでストライピングの記憶域プールを作ることにした。
ちなみに記憶域プールに取り込んだディスクは記憶域を解体しても再接続したときに記憶域の仮想ディスクとして認識することがある。なにかしらのデータは残っているというわけだ。
これを完全に除去するためには、Powershellで該当のディスクを「Clear-Disk」「Reset-Physicaldisk」のコマンドでデータ除去する必要がある。「Clear-Disk」と「Reset-Physicaldisk」とでは引数が違う。Clear-DiskはNumber、Reset-PhysicaldiskはSerialNumberが私の場合は楽だったが、いずれにしても無関係のディスクデータを削除したらまずいので必ずGet-Physicaldiskで接続中のディスク情報を確認してから慎重に操作しよう。
こんにちはストライピング(シンプル)の記憶域
18TBのHDDはWindows上だと16.7TBくらいに目減りするが、それでも3台直列繋ぎだと49.1TBの超巨大ストレージに変貌する。これのメリットは容量がでかいことは勿論だが、読み込みも書き込みも全ディスクに分配されるのでアクセス速度が高速になることだ。
ディスクが均等に使われているか不明だが、270MB/sくらいのサーバーHDDが3台繋ぎともなればSATAのSSD1台より高速にデータ通信ができる。このためOBSでの録画データの書き込みもNVMeのSSDを使うことなく、こいつの書き込みで一切問題なくなった。
単純に録画先のディスクがよろしくないことの他に裏でファイルコピーしているなど負荷がかかっているとき「エンコードラグによりスキップされたフレーム」がじわじわ増え、黄色・赤色でやばさが表現されるが足掛け1時間近く録画して処理落ち0Fで録画できたのは最高というよりほかない。
「レンダリングにより逃したフレーム」はグラフィックカードが限界までいじめられているときに起きるようだが、ChromeやEdgeでハードウェアエンコードするようなものを操作してなければこれが危機に陥ることはないはずだ。
このシンプル記憶域プールのデメリットとしては1台HDDがおかしくなったらデータが全損することなので、ずっとデータを保管したいならバックアップ必須になる。そして上のように録画したデータもさっさとエンコードして別ドライブに保管するとか、別の貯蔵用HDDに移動させるとかの措置は必須になるだろう。
読み書き速度を考えれば一時記録先としてのストライピング構成は優秀だ。これも3台だから660～700MB/sの速度だが、4台なら900MB/sも行きそうな感じもする。
そして敢えて大容量のHDDを使わなくていいというメリットもあるので、新規に導入するなら1台あたりの容量より構成台数を増やすやり方がよさそうだ。
ありがとうミラー高速パリティ。また会う日まで。
