差分

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

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

次のリビジョン
前のリビジョン
次のリビジョン 両方とも次のリビジョン
blog:2020:2020-12-08 [2020-12-08 18:42]
Decomo 作成
blog:2020:2020-12-08 [2021-08-27 15:56]
Decomo
行 22: 行 22:
 ZFSのファイルI/Oは原則的に128KiB単位((データセット毎にrecordsizeプロパティで変更可能))で行われ、それに満たないデータは、より小さなレコードが使われる。この小さなレコードがI/O性能にそれなりに影響するようで、Small Blocksは指定サイズ以下のブロックの読み書きをSpecial vdevにオフロードするようなイメージとなる。つまり、Special vdevとしてSSDを割り当てると、その特性を活かして膨大な小規模I/Oを捌けるようになる、というわけだ。 ZFSのファイルI/Oは原則的に128KiB単位((データセット毎にrecordsizeプロパティで変更可能))で行われ、それに満たないデータは、より小さなレコードが使われる。この小さなレコードがI/O性能にそれなりに影響するようで、Small Blocksは指定サイズ以下のブロックの読み書きをSpecial vdevにオフロードするようなイメージとなる。つまり、Special vdevとしてSSDを割り当てると、その特性を活かして膨大な小規模I/Oを捌けるようになる、というわけだ。
  
-ここで注意が必要なのは、Small Blocksの処理はファイルサイズベースではなく、あくまでブロックサイズベースで行われるということ。なので、小さなファイルの全体がSpecial vdevに格納される訳ではない((Small Blocksの閾値をレコードサイズと同値にして全データをSpecial vdevに送ることは可能))。そもそも、ZFSの書き込みは一旦メモリにキャッシュされ、トランザクショングループ(txg)にまとめられた上でレコードに書き出されるため、必ずしも小さいファイル=小さなレコードとは限らない。逆に、大きなファイルでもレコードサイズ以下の端数は必ず存在するわけで、これらのtxgでレコードサイズ未満となった分がSpecial vdev行きとなるようだ。この辺が一般的な階層化ストレージと大きく異なる部分である。+ここで注意が必要なのは、Small Blocksの処理はファイルサイズベースではなく、ブロックサイズベースで行われるということ。つまり、小さなファイルの全体がSpecial vdevに格納される訳ではない((Small Blocksの閾値をレコードサイズと同値にして全データをSpecial vdevに送ることは可能))。そもそも、ZFSの書き込みは一旦キャッシュされ、トランザクショングループ(txg)にまとめられた上でレコードに書き出されるため、必ずしも小さいファイル=小さなレコードとは限らない。逆に、大きなファイルでもレコードサイズ以下の端数は必ず存在するわけで、こうしたtxgでまとめてなおレコードサイズ未満となった分がSpecial vdev行きとなるようだ。この辺が一般的な階層化ストレージと大きく異なる部分である。
  
-Small Blocksの対象となるブロックサイズは、レコードサイズ以下の2の冪を任意に指定できる。128KiB以上のレコードサイズが使えるようになるlarge_blocksフィーチャーと合わせて使うと、よりパフォーマンスチューニングの幅が広がるだろう。なお、FreeBSDはレコードサイズが128KiBを超えるデータセットからの起動には対応してないので要注意。+Small Blocksの対象となるブロックサイズは、レコードサイズ以下の2の冪を任意に指定できる。128KiB以上のレコードサイズが使えるようになるlarge_blocksフィーチャーと合わせと、よりパフォーマンスチューニングの幅が広がるだろう。なお、FreeBSDはレコードサイズが128KiBを超えるデータセットからの起動には対応してないので要注意。
  
 Special Allocation Classで性能向上が見込める一方で、その仕組み上、Special vdevが死ぬと一発でプール全体のデータが飛ぶ恐れがある、というかメタデータという極めて重要なデータが飛ぶんだから、ほぼ確実に死ぬと思われる。なので今まで以上に冗長性には留意する必要がある。信頼のおけるSSDで最低でもミラーリング、可能なら電源喪失保護付きSSDで3重ミラーにしたいところ。 Special Allocation Classで性能向上が見込める一方で、その仕組み上、Special vdevが死ぬと一発でプール全体のデータが飛ぶ恐れがある、というかメタデータという極めて重要なデータが飛ぶんだから、ほぼ確実に死ぬと思われる。なので今まで以上に冗長性には留意する必要がある。信頼のおけるSSDで最低でもミラーリング、可能なら電源喪失保護付きSSDで3重ミラーにしたいところ。
  
-Special vdevの容量が一杯になった場合は、従来通り普通のvdevの方が使われるそう+Special vdevの容量が一杯になった場合は、従来通り普通のvdevの方が使われるそうなので、その辺は特に気にしなくてもよい模様
  
-のうち試してみたい。+もし試す場合は、プール(普通vdev)とSpecial vdevのashift量を一致させること。も修正済みかもしれないが、異なるashiftでプールに追加するとSpecial vdevの取り外せなくなる[[https://github.com/openzfs/zfs/pull/11053|バグ]]があるっぽい。ashift量はvdevごとに独立してて、プール作成時は気にするものの[[blog:2015:2015-05-20|vdev追加時はつつい忘れちゃう]]んだよね…
  
 ===== 参考サイト ===== ===== 参考サイト =====
行 40: 行 40:
   * [[https://zfs.datto.com/2017_slides/brady.pdf|Using Allocation Class]](PDF)   * [[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|Allocation Classes Feature - Benchmarks and use case on OmniOS]]
 +  * [[https://github.com/openzfs/zfs/pull/11053|Ignore special vdev ashift for spa ashift min/max by don-brady · Pull Request #11053 · openzfs/zfs · GitHub]]
 +  * [[https://www.illumos.org/issues/11840|Bug #11840: Remove of a special vdev with different ashift than the pool vdevs results in an OmniOS panic/pool corrupt - illumos gate - illumos]]
  
  • blog/2020/2020-12-08.txt
  • 最終更新: 2022-03-04 11:37
  • by Decomo