memo:test

差分

このページの2つのバージョン間の差分を表示します。

この比較画面にリンクする

両方とも前のリビジョン 前のリビジョン
次のリビジョン
前のリビジョン
memo:test [2020-12-07 18:00]
Decomo
memo:test [2020-12-09 09:21]
Decomo 削除
行 1: 行 1:
 ====== ZFSのヤバげな機能Special Allocation ClassがFreeBSD 12.2で対応されてた ====== ====== ZFSのヤバげな機能Special Allocation ClassがFreeBSD 12.2で対応されてた ======
  
-OpenZFS 2.0リリースの陰でひっそりと、FreeBSD 12.2-RELEASEのZFS実装にSpecial Allocation Classが追加されていた。+OpenZFS 2.0リリースの陰でひっそりと、FreeBSD 12.2-RELEASEのZFS実装にSpecial Allocation Class(以下、SACと略すことがある)が追加されていた。
  
-時系列的にはOpenZFS 2.0が2020年12月1日、FreeBSD 12.2Rが10月27日リリースなので、まったく陰ってはないんですけどね、インパクトありそうな機能の割にはリリースノートに記載がなく、''zpool status''したら「プールのアップグレードができるぜ!」と出たので調べてみたら追加されていたという。関連するコミットはこの辺→[[https://svnweb.freebsd.org/base?view=revision&revision=354382|Rev.354382]] [[https://svnweb.freebsd.org/base?view=revision&revision=354385|Rev.354385]] [[https://svnweb.freebsd.org/base?view=revision&revision=354941|354941]]+時系列的にはOpenZFS 2.0が2020年12月1日、FreeBSD 12.2Rが10月27日リリースなので、まったく陰ってはないんですけどね、インパクトありそうな機能の割にはリリースノートに記載がなく、''zpool status''したら「プールのアップグレードができるぜ!」と出たので調べてみたら追加されていたという。関連するコミットはこの辺→[[https://svnweb.freebsd.org/base?view=revision&revision=354382|Rev.354382]] [[https://svnweb.freebsd.org/base?view=revision&revision=354385|Rev.354385]] [[https://svnweb.freebsd.org/base?view=revision&revision=354941|Rev.354941]]
  
-機能自体は[[https://github.com/openzfs/zfs/releases/tag/zfs-0.8.0|ZoL 0.8.0]]で2019年5月24日にリリースされ、その後、illumosへのバックポートを経て、目出度くFreeBSDに取り込まれた模様。ZFS実装が新生OpenZFSベースに切り替わろうとしている中で、Legacy ZFSをきっちりメンテする姿勢には頭が下がります。+Special Allocation Class自体は[[https://github.com/openzfs/zfs/releases/tag/zfs-0.8.0|ZoL 0.8.0]]で2019年5月24日にリリースされ、その後、illumosへのバックポートを経て、めでたくFreeBSDに取り込まれた模様。ZFS実装が新生OpenZFSベースに切り替わろうとしている中で、Legacy ZFSをきっちりメンテする姿勢には頭が下がります。
  
-で、肝心のSpecial Allocation Classは何かというと、I/O性能に直結するデータを専用のvdevに格納して性能改善を図るもののようだ。+で、肝心のSpecial Allocation Classは何かというと、I/O性能に直結するデータを専用のvdevに格納して性能改善を図るもののようだ。多少正確さを欠く表現だが、階層化ストレージのZFS版といえる
  
-ZFSでは扱うデータの種類をAllocation Classという概念で分類しており、OpenZFS 2.0時点では以下の5種類となっている。そもそも、この概念自体がSpecial Allocation Class機能新設されたもののようだ。+ZFSでは扱うデータの種類に応じてvdevをAllocation Classという概念で分類しており、OpenZFS 2.0時点では以下の5種類となっている。ちなみにAllocation Classは、元は[[blog:2020:2020-10-07|dRAID]]導入されたもので、そ後、開発コミュニティにって汎用化され現在の形となったそうだ。
  
-^  クラス  ^  用途 +^  クラス   SAC   用途   専用vdevを割り当てた時の効果  ^ 
-| Normal | 通常のデータ(ユザーデータ) +| Normal |  ×  | 通常のデータを扱うvdev。ミラとかRAIDZとか。 | 
-| Log | ZILのレコード | +| Log |  ×  |ZILのレコード。いわゆるSLOG。 | 同期書き込みの高速化 
-| Dedup | 重複排除テーブル(DDT)のデータ | +| Dedup |  ○  |重複排除テーブル(DDT)のデータ | 重複排除パフォーマンスの向上とDDTのメモリ使用量の削減 
-| Metadata | プールとファイルシステムのメタデータ | +| Metadata |  ○  | プールとファイルシステムのメタデータ | メタデータ操作(ファイル一覧の取得など)パフォーマンスの向上 
-| Small Blocks | レコードサイズ以下のブロック |+| Small Blocks |  ○  | レコードサイズ以下のブロック | 小さなサイズの膨大なI/O性能の改善。詳細は後述 |
  
-https://github.com/openzfs/zfs/pull/5182+表で〇を付けたAllocation ClassがSpecial Allocation Classとされている。それぞれのSACの役割は名前のごとくで、専用vdev (Special vdev)を割り当てるとそれなりに効果がありそうだ。とりわけSmall Blocksは[[https://www.napp-it.org/doc/downloads/special-vdev.pdf|劇的な性能改善の可能性]](PDF)を秘めている。
  
-https://forums.servethehome.com/index.php?threads/zfs-allocation-classes-special-vdev.28862/+ZFSのファイルI/Oは原則的に128KiB単位((データセット毎にrecordsizeプロパティで変更可能))で行われ、それに満たないデータは、より小さなレコードが使われる。この小さなレコードがI/O性能にそれなりに影響するようで、Small Blocksは指定サイズ以下のブロックの読み書きをSpecial vdevにオフロードするようなイメージとなる。つまり、Special vdevとしてSSDを割り当てると、その特性を活かして膨大な小規模I/Oを捌けるようになる、というわけだ。
  
-https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954+ここで注意が必要なのは、Small Blocksの処理はファイルサイズベースではなく、あくまでブロックサイズベースで行われるということ。なので、小さなファイルの全体がSpecial vdevに格納される訳ではない((Small Blocksの閾値をレコードサイズと同値にして全データをSpecial vdevに送ることは可能))。そもそも、ZFSの書き込みは一旦メモリにキャッシュされ、トランザクショングループ(txg)にまとめられた上でレコードに書き出されるため、必ずしも小さいファイル=小さなレコードとは限らない。逆に、大きなファイルでもレコードサイズ以下の端数は必ず存在するわけで、これらのtxgでレコードサイズ未満となった分がSpecial vdev行きとなるようだ。この辺が一般的な階層化ストレージと大きく異なる部分である。
  
-https://zfs.datto.com/2017_slides/brady.pdf+Small Blocksの対象となるブロックサイズは、レコードサイズ以下の2の冪を任意に指定できる。128KiB以上のレコードサイズが使えるようになるlarge_blocksフィーチャーと合わせて使うと、よりパフォーマンスチューニングの幅が広がるだろう。なお、FreeBSDはレコードサイズが128KiBを超えるデータセットからの起動には対応してないので要注意。
  
-https://docs.google.com/presentation/d/17nYRgs-TAIOPODOMaq-VwuJ0LqJHEXBfM9sUDxJUJ54/edit#slide=id.g40f6b2f7d9_2_149+Special Allocation Classで性能向上が見込める一方で、その仕組み上、Special vdevが死ぬと一発でプール全体のデータが飛ぶ恐れがある、というかメタデータという極めて重要なデータが飛ぶんだから、ほぼ確実に死ぬと思われる。なので今まで以上に冗長性には留意する必要がある。信頼のおけるSSDで最低でもミラーリング、可能なら電源喪失保護付きSSDで3重ミラーにしたいところ。 
 + 
 +Special vdevの容量が一杯になった場合は、従来通り普通のvdevの方が使われるそうだ。 
 + 
 +そのうち試してみたい。 
 + 
 +===== 参考サイト ===== 
 + 
 +  * [[https://github.com/openzfs/zfs/pull/5182|Metadata Allocation Classes by don-brady · Pull Request #5182 · openzfs/zfs · GitHub]] 
 +  * [[https://docs.google.com/presentation/d/17nYRgs-TAIOPODOMaq-VwuJ0LqJHEXBfM9sUDxJUJ54|Pool Allocation Classes - 5182]] 
 +  * [[https://forums.servethehome.com/index.php?threads/zfs-allocation-classes-special-vdev.28862/|ZFS Allocation Classes / Special VDEV | ServeTheHome Forums]] 
 +  * [[https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954|ZFS Metadata Special Device: Z - Wikis & How-to Guides - Level1Techs Forums]] 
 +  * [[https://zfs.datto.com/2017_slides/brady.pdf|Using Allocation Class]](PDF) 
 +  * [[https://www.napp-it.org/doc/downloads/special-vdev.pdf|Allocation Classes Feature - Benchmarks and use case on OmniOS]]
  
-https://www.napp-it.org/doc/downloads/special-vdev.pdf