ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × Proxmox VEで仮想ディスクを4Knデバイスとして扱う Proxmox VEの仮想ディスクは、仮想マシンから512バイトセクタのストレージとして見える。正確にはQEMUのデフォルト挙動で、仮想環境における極々一般的な挙動なので普通に使う分には困らないし、意識すらしないだろう。 じゃあどんな時に困るかというと、物理・論理セクタサイズの両方が4096バイトの、いわゆる4KnデバイスをRDMでVMにアタッチする場合に困る。同じ理屈で、4Kn環境をそのままP2Vした時のディスクイメージとかも。例えばパーティションテーブルはLBA(セクタ番号)で管理されているので、4kセクタ環境で1GiBのパーティションを確保した場合262144セクタとなるが、これを512Bセクタ環境で解釈すると128MiBしか確保されてないように見え、色々とマズいわけですよ(実際はGPTそのものが正しく認識されなくなる。) 仮想ディスクを4Knとして認識させるには、/etc/pve/qemu-server/VMID.confをエディタで直接編集し、args:に下記の設定を追加してやればよい。 args: -set device.scsi0.physical_block_size=4096 -set device.scsi0.logical_block_size=4096 scsi0の0の部分はSCSI IDなので任意に読み替え可能で、複数のデバイスも同様に設定が可能。SATAやvirtio-blkも行けると思うけど未確認。 説明するまでもないだろうが、物理と論理のセクタサイズをそれぞれ4096に指定してあげればよい。物理4096, 論理512にすれば512e扱いになるかも? 上記設定を行った4KnのSSD×3、512eのHDD×5をRDMしてる当方の仮想環境では、想定通りに認識されている。 $ dmesg | grep sectors da0: 2969600MB (760217600 4096 byte sectors) da1: 2969600MB (760217600 4096 byte sectors) da2: 2969600MB (760217600 4096 byte sectors) da3: 17166336MB (35156656128 512 byte sectors) da4: 17166336MB (35156656128 512 byte sectors) da5: 17166336MB (35156656128 512 byte sectors) da6: 17166336MB (35156656128 512 byte sectors) da7: 17166336MB (35156656128 512 byte sectors) cd0: 998MB (511254 2048 byte sectors) また一つ、どーでもよいノウハウがたまってしまった。 参考サイト Change of sectorsize | Proxmox Support Forum MN08ACA14TとST14000NM001Gのベンチマーク 東芝とSeagateの14TB SATA HDD、MN08ACA14TとExos X16 ST14000NM001G-2KJ103のベンチマーク。実家に設置しているサーバの6TB×4のRAID-Z2ストレージを置き換えようと購入し、1年近く死蔵しているという。なお、先日ようやく実家に持っていきはしたものの、未だ交換には至らず… 例によってUSB 3.0変換での計測なので参考程度に。 MN08ACA14T ST14000NM001G CrystalDiskInfo CrystalDiskMark ------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read] SEQ 1MiB (Q= 8, T= 1): 271.152 MB/s [ 258.6 IOPS] < 27833.35 us> SEQ 1MiB (Q= 1, T= 1): 270.276 MB/s [ 257.8 IOPS] < 3873.33 us> RND 4KiB (Q= 32, T= 1): 1.785 MB/s [ 435.8 IOPS] < 72642.48 us> RND 4KiB (Q= 1, T= 1): 0.658 MB/s [ 160.6 IOPS] < 6194.17 us> [Write] SEQ 1MiB (Q= 8, T= 1): 255.845 MB/s [ 244.0 IOPS] < 32572.05 us> SEQ 1MiB (Q= 1, T= 1): 83.587 MB/s [ 79.7 IOPS] < 12506.20 us> RND 4KiB (Q= 32, T= 1): 1.137 MB/s [ 277.6 IOPS] <112710.49 us> RND 4KiB (Q= 1, T= 1): 0.619 MB/s [ 151.1 IOPS] < 6603.23 us> Profile: Default Test: 4 GiB (x5) [D: 0% (0/49GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2022/11/03 12:07:56 OS: Windows 10 Professional [10.0 Build 19044] (x64) Comment: TOSHIBA MN08ACA14T (14TB/USB 3.0) ------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read] SEQ 1MiB (Q= 8, T= 1): 281.158 MB/s [ 268.1 IOPS] < 29734.37 us> SEQ 1MiB (Q= 1, T= 1): 279.057 MB/s [ 266.1 IOPS] < 3753.59 us> RND 4KiB (Q= 32, T= 1): 2.137 MB/s [ 521.7 IOPS] < 60793.95 us> RND 4KiB (Q= 1, T= 1): 0.721 MB/s [ 176.0 IOPS] < 5668.58 us> [Write] SEQ 1MiB (Q= 8, T= 1): 270.648 MB/s [ 258.1 IOPS] < 30823.96 us> SEQ 1MiB (Q= 1, T= 1): 274.467 MB/s [ 261.8 IOPS] < 3816.19 us> RND 4KiB (Q= 32, T= 1): 13.794 MB/s [ 3367.7 IOPS] < 9487.38 us> RND 4KiB (Q= 1, T= 1): 8.230 MB/s [ 2009.3 IOPS] < 496.55 us> Profile: Default Test: 4 GiB (x5) [D: 0% (0/49GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2022/11/03 20:48:46 OS: Windows 10 Professional [10.0 Build 19044] (x64) Comment: SEAGATE ST14000NM001G (14TB/USB 3.0) ゼロフィル(512kBブロック) 14000504438784 bytes (14 TB, 13 TiB) copied, 70020 s, 200 MB/s 14000490807296 bytes (14 TB, 13 TiB) copied, 71015 s, 197 MB/s MN08ACA14Tが電源投入2回、使用時間28時間にもかかわらず、代替セクタが計上されてるのが非常に嫌な感じなんですけど…。ネット上でも代替セクタでまくりとか、振動に弱いとかの報告が目につくので、然もありなんではある。が、NAS向けを謳ってるHDDで大丈夫なのこれ。 似たようなスペックの両HDDだけれども、全体的にST14000NM001Gの方が速いと言ってよさそう。この辺は流石のExosブランドってとこっすかね。Seagate絶対許さんマンのワタクシではありますが、Exosブランドに関してはだいぶ信頼している。いやまぁ、コンシューマ向けのラインを24/365で使って壊れて文句言ってる自分が悪いっちゃ悪いんですけども。 CDMのドライブ容量が50GBなのはクイックじゃないフォーマットで、ドライブ作ったためであり他意はない。 RAIDZプールに追加したスペシャルvdevは削除できない OpenZFS 2.1.4時点で、冗長性レベルを問わずRAID-Zプールに追加したスペシャルvdevを削除することは出来ないようだ。恐らく、トップレベルvdev削除の制限に起因する仕様と思われる。 次のようなRAID-Z1とスペシャルvdevから成るプールがあるとする。 # zpool status ztank pool: ztank state: ONLINE config: NAME STATE READ WRITE CKSUM zdata ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 special mirror-1 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 errors: No known data errors ここで、スペシャルvdevを削除しようとzpool removeすると、次のようにエラーとなる。 # zpool remove ztank mirror-1 cannot remove mirror-1: invalid config; all top-level vdevs must have the same sector size and not be raidz. トップレベルvdevのmirror-1を一気に削除するのがマズいのかと思い、次のように構成メンバを個別に削除してってもダメ。 # zpool detach ztank da5 # zpool remove ztank da4 cannot remove ..... なお、RAIDZ以外の構成なら特に制限なく削除可能で、同じトップレベルvdevであるslogやL2ARCの場合は、RAIDZでも(以前から)削除可能である。 家鯖でスペシャルvdevを本格運用すべく色々準備してたけど、削除できないのはちょっと厳しいなぁ…VMであらかじめ実験しといて良かったぜ……slog/L2ARCは削除できるんだから、将来的にできるようになるのかなぁ………スペシャルvdevの場合、明示的に本体プールの方にデータを書き戻す必要があって難しいのかなぁ………… 当面はpL2ARCを使うとするかー。 Special vdevが消失したプールとzpool -Fオプション プールのメタデータを丸っと引き受けるというZFSのSpecial vdevの特性から、対応する物理デバイスの故障などでSpecial vdevが死ぬと、プールそのものが使えなくなりそうってのは容易に想像ができる。 実際どうなるか仮想マシンベースで確認してみると、やはり使えなくなった。それもzpool listの結果にプール自体が出てこなくなるという、割と重篤な扱い。プール名を指定 or プール探索でインポートしようとすると、以下のようになってインポートできない。 # zpool import -a -N cannot import 'ztest': I/O error Destroy and re-create the pool from a backup source. 存在しないプールのインポートではcannot import 'znotexists': no such pool availableって感じなので、明らかに扱いが違う。 Special vdevが消失したプールの復旧は基本的に無理っぽい感じ。 一応man zpool-importを見てみると、(いつの間にか)プール回復に関するオプション-F, -X, -Tが追加されていた。それぞれの効果を抄訳してみた。 -F インポート不可能なプールのための回復モード。最後のわずかなトランザクションを破棄することで、プールがインポート可能状態への復帰を試みます。このオプションを使うことで、損傷を受けたすべてのプールが回復するとは限りません。成功した場合、破棄されたトランザクションに関連するデータは、回復不能なほどに失われます。プールがインポート可能またはインポート済みの場合、このオプションは無視されます。 -n 回復オプション(-F)と共に使用します。インポート不可能なプールが再びインポート可能になるかどうかを判定しますが、実際にプール回復は行いません。プール回復モードの詳細は、上記の-Fオプションをご覧ください。 -X 回復オプション(-F)と共に使用します。有効なtxgを見つけるための非常手段を取るか否かを指定します。これは、もはや一貫性が保証されていないtxgへ、プールがロールバックされることを許可します。矛盾したtxgでインポートされたプールは修復不能なチェックサムエラーを含むかもしれません。プール回復モードの詳細は、上記の-Fオプションをご覧ください。警告:このオプションはプールの健全性に対し極めて危険な可能性があり、最終手段として用いるべきです。 -T ロールバックに使用するtxgを指定します。暗黙的に-FXオプションを含みます。プール回復モードの詳細は、上記の-Xオプションをご覧ください。警告:このオプションはプールの健全性に対し極めて危険な可能性があり、最終手段として用いるべきです。 -F < -X < -Tの順で強力(危険)になる雰囲気。で、それぞれを指定して、先のSpecial vdevが無くなったプールのインポートを試みたのが以下。 # zpool import -F ztest cannot import 'ztest': I/O error Destroy and re-create the pool from a backup source. # zpool import -FX ztest cannot import 'ztest': one or more devices is currently unavailable # zpool import -T ztest invalid txg value usage: import [-d dir] [-D] import [-o mntopts] [-o property=value] ... [-d dir | -c cachefile] [-D] [-l] [-f] [-m] [-N] [-R root] [-F [-n]] -a import [-o mntopts] [-o property=value] ... [-d dir | -c cachefile] [-D] [-l] [-f] [-m] [-N] [-R root] [-F [-n]] [--rewind-to-checkpoint] <pool | id> [newpool] -Tはtxgを指定してやらないとダメな予感。usageにもmanにもそれらしいことは書いてないんだけど…実際にどんな値を指定したらいいのか皆目見当もつかない。 その後、Special vdev用の仮想ディスクを戻してみると、問題なくプールのインポートができた。ただし自動インポートはされず、手動で行う必要があるようだ。(上記の-Fとかでプールを操作したためかもしれないが未確認。)scrubで健全性に問題がないことも確認。 そんなわけでSpecial vdevの冗長性には十分気を付ける必要がありそうだ。 ZFSのSpecial vdevを試してみる 階層化ストレージのZFS版ともいえるSpecial vdevとSpecial Allocation Classについて、1年程前に当サイトでも解説した。いつか試そうと思いつつ延び延びになっていたが、いよいよ導入の機運が高まってきたので簡単にテストした。 コマンド まずはコマンドの確認から。以下、da0p1をノーマルvdev(プール本体のストレージ)、da6p1をスペシャルvdevとする。 スペシャルvdev付きプールを作る。vdevタイプとしてspecialを指定し、その後にスペシャルvdevに割り当てるデバイスを指定する。 # zpool create -O atime=off ztest da0p1 special da6p1 $ zpool status ztest pool: ztest state: ONLINE config: NAME STATE READ WRITE CKSUM ztest ONLINE 0 0 0 da0p1 ONLINE 0 0 0 special da6p1 ONLINE 0 0 0 既存のプールにスペシャルvdevを追加する場合はzpool addで同様に指定する。 # zpool add ztest special da6p1 スペシャルvdevの削除。これはL2ARCやslogの削除なんかと一緒。 # sudo zpool remove ztest da6p1 OpenZFS 2.1.4の時点において、RAIDZプールに追加したスペシャルvdevは削除できないので注意!!(トップレベルvdev削除の制限事項)。 スペシャルvdevデバイスの増減(zpool attach/detach)は可能だが、いざzpool removeしようとするとinvalid config; all top-level vdevs must have the same sector size and not be raidz.エラーとなり削除できない。 slogやL2ARCは削除できるのにどうして…… ただし、remove後にスペシャルvdevからノーマルvdevへ、データの退避が行われる。 $ zpool status ztest pool: ztest state: ONLINE remove: Evacuation of /dev/da6p1 in progress since Wed Feb 23 16:50:17 2022 2.77G copied out of 13.5G at 142M/s, 20.54% done, 0h1m to go config: NAME STATE READ WRITE CKSUM ztest ONLINE 0 0 0 da0p1 ONLINE 0 0 0 special da6p1 ONLINE 0 0 0 $ zpool iostat -v ztest capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- ztest 14.4G 9.13T 16 68 215M 220M da0p1 932M 9.09T 0 68 0 220M special - - - - - - da6p1 13.5G 36.0G 16 0 215M 0 ---------- ----- ----- ----- ----- ----- ----- 退避が完了するとプールからデバイスが除去される。 $ zpool status ztest pool: ztest state: ONLINE remove: Removal of vdev 1 copied 13.5G in 0h1m, completed on Wed Feb 23 16:51:31 2022 27.4K memory used for removed device mappings config: NAME STATE READ WRITE CKSUM ztest ONLINE 0 0 0 da0p1 ONLINE 0 0 0 スペシャルvdevは標準でメタデータのみを格納する設定となっている。小ブロックデータの格納を有効にするには、ファイルシステム毎のプロパティspecial_small_blocksを0以外の2の冪数に設定する。 # zfs set special_small_blocks=64k ztest/R/pictures $ zfs get -r special_small_blocks ztest NAME PROPERTY VALUE SOURCE ztest special_small_blocks 0 default ztest/R special_small_blocks 0 default ztest/R/pictures special_small_blocks 64K local スペシャルvdevが使われてるかどうかはzpool iostat -vで確認できる。書き込み中に見てみると、しっかりスペシャルvdevも使われていることがわかる。 capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- ztest 11.7G 9.13T 0 1.36K 0 213M da0p1 11.4G 9.08T 0 215 0 207M special - - - - - - da6p1 277M 49.2G 0 1.15K 0 6.22M ---------- ----- ----- ----- ----- ----- ----- テスト スペシャルvdevの有無、special_small_blocksのサイズ、レコードサイズの違いで簡単にテストを行う。 テスト環境 テストデータ 72208ファイル、10.3GiB(平均ファイルサイズ:150KiB) Special vdevの効果が出やすいであろう、大量の小サイズの画像ファイル群 テストマシン OS: FreeBSD 13.0-RELEASE-p6 on Proxmox VE 7.1 CPU: 4 vCPU (Xeon E5-2680v4. オーバーコミットなし) RAM: 32GB HDD: コピー元: 単体 (仮想ディスク50GB/実態はU.2 SSD) コピー先: 単体 (10TB 7200RPM SATA HDD×1) コピー先のプールのスペシャルvdevの有無によって、以下の項目を測定する。 コピー元→コピー先へのファイルコピー所要時間(rsync -aX src dst/) コピー先でファイルの全走査にかかる時間(find dst > /dev/null) コピー先でファイルの全読込にかかる時間(find dst -print0 | xargs -0 cat) ARCの影響を避けるため、プールは都度作成し、rsync後はマシンを再起動する。その後、ファイル走査→全読込の順で実行する。 テスト結果 仮想マシン上での実行のため、結果にはノイズが多く含まれていることに注意。 recsize special_small_blocks コピー時間(秒) ファイル走査時間(秒) ファイル読込時間(秒) スペシャルvdev使用量(MiB) 備考 128k - 284 17.8 539 - Special vdevなし 0 281 2.5 493 319 メタデータのみSpecial vdevを利用 4k - - - 320 sdev容量のみ測定 8k - - - 321 16k - - - 322 32k - - - 336 64k 279 2.6 433 684 128k 280 2.8 203 13824 全データがSpecial vdevに行く 1M - 280 17.6 400 - Special vdevなし 0 285 2.5 358 34 4k - - - 35 sdev容量のみ測定 8k - - - 36 16k - - - 37 32k - - - 52 64k 274 2.7 352 400 128k 276 2.8 286 3102 ※special_small_blocks=4k~32kは後から測定したため、スペシャルvdevの容量のみ。グラフには加えていない。1MBずつ増えてて本当かよ?と思ったが、再度試しても同じだったので間違ってるわけではなさそう。 スペシャルvdevの有無でファイルコピー(書き込み。赤線)時間に有意な差は見られなかった。ただし、これはコピー元の読み込みで律速してる可能性が否定できない。コピー先の書き込み状況をiostatを眺めてみると間欠動作となっていた。 ファイルの全走査はスペシャルvdevがあると劇的に高速化されるようだ。iostatを見てみると、スペシャルvdevで読み込み処理が走っており、SSD上のメタデータが使わているものと思われる。期待通りの挙動ですな。 ファイルの全読込も、スペシャルvdevに保存されているデータ量に応じて短縮されており、こちらも想定通り。recsize=128kでspecial_small_blocks=128kとすると、全データがスペシャルvdevに保存されるというのも期待通りの結果だった(special_small_blocksで指定されたサイズ以下のレコードのデータがスペシャルvdevに保存される仕様。)iostatを見てみると、見事に全てスペシャルvdevに書き込まれていることが分かる。 capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- ztest 13.2G 9.13T 0 2.21K 0 236M da0p1 0 9.09T 0 3 0 15.2K special - - - - - - da6p1 13.2G 36.3G 0 2.20K 0 235M ---------- ----- ----- ----- ----- ----- ----- 少し意外だったのは、special_small_blocksが0、すなわちメタデータのみをスペシャルvdevに保存した場合でも、ファイル読込性能が向上したという点。今回は小さな大量のファイルが対象だったため、読込み処理におけるメタデータの処理割合が多かったのが要因だろう。 また、スペシャルvdevと直接は関係ないが、レコードサイズでメタデータサイズが大きく変化するというのは新たな発見だった。全くの推測だが、おそらくレコードごとに生成されるチェックサムの総量が影響しているのだろう。10.3GiBを128kiBレコードで割ると約84000レコードで、それぞれにfletcher4(4バイト)のチェックサムが付くと、合計330MiBとなる。同様に1MiBレコードでは41MiBとなり、これらはメタデータのみをスペシャルvdevに保存した際の容量とおおむね一致する。 さらに1MiBレコードではファイル読込が明らかに速くなっており、圧縮率の観点等も考慮すると積極的に128KiB以上のレコードサイズを使っていくのが良さそう。 special_small_blocksの設定をどうするかは悩ましいところ。扱うデータの種類やワークフローはもとより、TXG関連の設定やその時々の負荷量などで、書き込みがスペシャルvdev行きとなるかどうかが変わってくると思われ、見積もるのが難しい。今回は64k/128kの2パターンしか見なかったが、運用においては、より小さな設定値も検討に値するだろう。むしろ、とりあえず4kあたりから始めて様子を見るのがいいのかもしれない。 → 気になったので4k~32kを追試したけど、32k以下は殆ど効果がなさそう。スペシャルvdevの運用としては、容量が見積もりやすいメタデータのみとするか、ある程度余裕を持たせて64kで始めるの2択になるかも。 メタデータだけでもスペシャルvdevの効果は期待できそうなので、SSDに余裕があるならL2ARCよりも優先的に割り当てて良さそうに思う。 start.txt 最終更新: 2022-07-27 15:26by Decomo