階層化ストレージの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
のサイズ、レコードサイズの違いで簡単にテストを行う。
コピー先のプールのスペシャル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よりも優先的に割り当てて良さそうに思う。