bcache でお手軽階層型ストレージ

 

“第七回 カーネル/VM探検隊&懇親会” で bcache の紹介と簡単なベンチマーク結果についてしゃべってきたのでそのメモ。 “カーネル/VM探検隊” への参加は 2 回目ですが今回も非常にアレでした。もちろん良い意味で。

bcache とは

要は Linux で “高速だけど小容量なブロック・デバイスをキャッシュとして用いることで低速だけど大容量なブロック・デバイスをまるで高速かつ大容量なブロック・デバイスのようにみせちゃおう” というものです。

以下の URL がマスター・サイトのようです。

が、あまり更新されておらず(てか嘘になっちゃってる情報も…)確実な情報は下記 Linux カーネルの Git リポジトリに含まれる Documentation/bcache.txt になります。あとはソース読むしかない。

以下の Git リポジトリが公開されてます。

  • Linux カーネルの Git リポジトリ
    – git://evilpiepirate.org/~kent/linux-bcache.git
  • 設定ツールの Git リポジトリ
    – git://evilpiepirate.org/~kent/bcache-tools.git

bcache のようなストレージのキャッシュ機能を “階層型ストレージ” とか “ストレージの階層化” と呼ぶみたいです。有名なのは ZFS の ARC と ZIL でしょうか(実現方法は bcache とは全く異なるけど)。たぶん商用のストレージ製品ではふつうにやってることなんだと思います。たぶん。

ベンチマーク環境

以下のハードウェアでベンチマークを実行しました。

CPU Xeon E5620(12MB Cache, 2.40GHz) x 1
Memory PC3-10600 8GB x 3
M/B Supermicro X8DTU-6TF+
SAS/SATA Controller LSI MegaSAS 9260

OS は Debian 6 の素の backport kernel 3.2.12 とそれに bcache のパッチを当てたもので実行しています。

あとファイル・システムはすべて ext3 をデフォルトのパラメータで mkfs したものです。

iozone によるベンチマーク

まずはとりあえず iozone で基本的なベンチマークとってみました。

構成はこんな感じ。

HDD Seagate 2.5inch 750GB 7200rpm 3Gbps SATA x 1
SSD Intel SSD 520 120GB 6Gbps SATA(33.3%OP) x 1
RAID5 LSI MegaRAID RAID5 HDD x 5(4D+1P)
WriteThrouh RAID5 backing + SSD cache(WriteThrouh)
WriteBack RAID5 backing + SSD cache(WriteBack)

で、結果は以下の “グラフ 1.” から “グラフ 6.” の通りです。ちなみにファイル・サイズが 512MB のファイルをアクセスするサイズを変化させてどれくらいの転送速度が出たのかを示したグラフです。

グラフ 1.

グラフ 2.

グラフ 3.

グラフ 4.

グラフ 5.

グラフ 6.

見ての通り iozone の結果はあんまり面白くない結果になりました。いくつか線がかぶっちゃってどれがどれだかわかりにくくなってますけど、基本的に SSD と WriteThrouh と WriteBack の 3 つが同じ性能で、 HDD と RAID5 が同じ性能な感じです。HDD たちと比較して SSD の方はだいたい 5~10% 程度速くなってるみたいですけど “これだったらそんなに入れるメリットないかなー” って思っちゃうかも。

ということで別のベンチマークも試してみました。

KVM ディスク・イメージへのアクセス・シミュレーション

おしごとで管理している KVM で仮想化した共用ホスティングサーバのホスト側で qemu-kvm の vfs_read/vfs_write を SystemTap で追跡してそれと同じパターンの read/write を発生させてどんなレイテンシになるか測ってみました。

起動する仮想マシンが増えたときにディスク・アクセスが遅くなったりしないかが気になったので記録したアクセス・パターンをいくつか切り取って並行で走らせた際のレイテンシも測ってみました。

構成はこんな感じ。

w/o BCache LSI MegaRAID RAID5 HDD x 5(4D+1P)
WriteThrouh RAID5 backing + SSD cache(WriteThrouh)
WriteBack RAID5 backing + SSD cache(WriteBack)

“グラフ 7.” は bcache でキャッシュしない場合の結果です。

グラフ 7.

1 回の I/O アクセスにかかった時間(read/write の実行を開始してから帰ってくるまでの時間)を 1 つの点として描画しています。

横軸の単位は秒です。 300~600 になってますけど、これはベンチマークを開始してから 300 秒後から 600 秒後までのレイテンシをプロットしているという意味です。

“0 background procs” とか “4 background procs” はベンチマークとってる最中に並行に動作する同じように別のディスク・イメージにアクセスしているプロセスの数です。 “4 background procs” の場合は 4 つのプロセスが 4 つのディスク・イメージに並行でディスクアクセスしている状態でまた別のディスク・イメージにアクセスしてそのレイテンシを計ってるという意味です。

なんでかよくわかんないですけど 0~16 でそんなに違いはみられませんでした…もしかしたらサンプルしたアクセスパターンがそんなに負荷が高くなかったのかも…

“グラフ 8.” は WriteThrouh bcache の結果です。

グラフ 8.

“グラフ 9.” は WriteBack bcache の結果です。

グラフ 9.

WriteBack の結果はなぜか “0 background procs” が一番悪い結果になってしまいました。ちょっと考えにくい結果なのでなにか設定か構成ミスってたんじゃないかという気がしています。

それぞれの “16 background procs” を 3 つの構成で重ねたのが “グラフ 10.” です。

グラフ 10.


ご覧の通り bcache の方は WriteThrouh/WriteBack によらずアクセスにかかる時間はすべて 1ms 以内に収まってますが bcache でない方は最悪 100ms を超える時間がかかってます。逆に bcache でない方は 0.01ms よりもだいぶ小さいアクセス時間で実行が完了している場合もあるのですが bcache の方は最速で 0.01ms となってます。

まとめ?

iozone のような普通のベンチマークソフトで測った値はそんなに良さそうではなさそうでしたが KVM の仮想マシンがディスク・イメージへアクセスするようなケースでは遅延が小さくなり応答速度は良くなるんじゃないかと思います。あとなんとなく後者のベンチマーク中のロード・アベレージや I/O wait も bcache が有向の方が低かったような気がします。

レイテンシが小さくなるのはなかなか魅力的な気がするのでちょっとばかし仮想化環境のストレージとして使ってみようかなと思ってます。

Comments are closed.