WalB の紹介とプロトタイプの性能評価 WebDB Forum 2012 の技術報告セッションで発表．

1. ログ先行書き込みを用いた
ストレージ差分取得の一手法
サイボウズ・ラボ 星野 喬
2012-11-20(火)
WebDB Forum 2012

2. 自己紹介
• 星野 喬(@starpoz)
– サイボウズ・ラボ
• 昔やっていたこと
– データベース，ストレージ，分散アルゴリズ
ム
• 今の仕事
– Linux kernel の block device driver 書いてます
– 今日はその話をします
2

3. 発表概要
• 動機
• WalB
• 評価
• 開発の進捗
• まとめと今後の課題
3

4. 動機
• データのバックアップとレプリケーション
• 弊社クラウドインフラにおける現状
– コスト対効果を重視しコモディティを使用
– LVM snapshot + フルスキャンによる差分取得
• 課題
– フルスキャンが必要なため 1 日 1 回深夜実施
– RPO が十分小さいとはいえない (～1日)
– せめて数分前までのデータは復旧させたい
4

5. 対象レイヤー
• 上位層でやるメリット
アプリケーション – データ量が減る
ミドルウェア
• 下位層でやるメリット
ファイルシステム
– 汎用的
ブロックデバイス
(ストレージ)
• 最下層でやるメリット
– シーケンシャルアクセスが効く
5

6. 差分取得手法
• フルスキャン
a b c d e a b’ c d e’ 1 b’ 4 e’
• 差分ビットマップ使用
a b c d e a b’ c d e’ 1 b’ 4 e’
00000 01001
• WAL (Write-Ahead Log) 使用
a b c d e a b’ c d e’ 1 b’ 4 e’
1 b’ 4 e’
7

7. WalB
WAL on Block-devices
• 目的 • 機能
– 効率的な差分記録/取得 – 差分記録/取得
• 特徴 – スナップショット(*1)
– 性能オーバーヘッド – オンラインリサイズ
の低減を重視 – IO 処理一時停止
– 永続索引構造なし • 対象OS/アーキテク
– Undo ログ不要 チャ
– (Write IO の順序保証) – Linux Kernel 3.2 or later
– x86_64
(*1) 索引がなく古いデータはすぐに上書きされるため
WalB デバイス単体ではスナップショットイメージにアクセス出来ない 9

8. WalB Architecture
WalB Dev Any Application WalB Log
Controller (File System, DBMS, etc) Extractor
Control Read Write Log
Wrapper
Block Device
(WalB Dev)
Any Block Device Any Block Device
for Data (Data device) for Log (Log device)
Not special format An original format
10

9. Log Device Format
Address
Snapshot
Ring buffer
metadata
Log address = (log sequence id)
Superblock % (ring buffer size)
(512 or 4096 bytes) + (ring buffer start address)
Reserved (4096 bytes)
11

10. WalB が満たすべき性質
• Read the latest written data
– 上書きされたはずの古いデータを読んではいけない
• Storage state uniqueness
– 歴史が変わらないこと(Log と Data の IO 順序)
• Durability of flushed data
– 永続化保証 フラグの要求を満たす
• Crash recovery without undo
– Undo ログなし，redo ログのみで一貫性を確保
12

11. WalB アルゴリズム
• Easy
– 単純なアルゴリズム
• Fast
– Deferred-data-write によりレスポンス小
• Easy-ol, fast-ol
– 重複 write IO 実行の直列化制御を追加
13

12. IO 処理フロー (Easy)
Write
Submitted Completed
WalB write IO response
(Wait for overlapped IOs done)
Packed
Log IO response Data IO response
Time
Log submitted Log completed Data submitted Data completed
Read
Submitted Completed
Data IO response
Time
Data submitted Data completed
14

13. IO 処理フロー (Fast)
Write
Submitted Completed (Wait for overlapped IOs done)
WalB write IO response
Packed
Log IO response Data IO response
Time
Log submitted Log completed Data submitted Data completed
Pdata inserted Pdata deleted
Read
Submitted Completed
Data IO response
Time
(Data submitted) (Data completed)
Pdata copied 15

14. Pdata for Deferred Write
• Read the latest written data のため
– Fast algorithm のみ必要
• Read IO の挙動
– 重複する Write IO が pdata に存在したら
古い順に重複領域をコピー
– pdata に存在しない領域は data device から読む
16

15. 重複 IO 実行の直列化
Wait for overlapped IOs done
Data IO response
Time
Data submitted Data completed
Oldata inserted Got notice Oldata deleted Sent notice
• Storage State Uniqueness のために必要
• Oldata の insert/delete が FIFO であれば
IO につきカウンタひとつで制御可能
18

16. 永続化
IO completed 時の保証 WalB での挙動
対象 Write IO 以前の
該当 Log IO の FLUSH
FLUSH 全ての Write IO が
フラグ ON
永続化済み
対象 Write IO が 該当 Log IO の FLUSH|FUA
FUA
永続化済み フラグ ON
• Log の永続化条件
– (1) それ以前の全ての Log が永続化していること
– (2) 対象 Log そのものが永続化していること
• Data IO には FLUSH|FUA のいずれも必要ない
20

17. クラッシュリカバリ
• Log を data device に適用することで一貫性を回
復
– Redo ログしかないので Undo は実行不可能
• Write IO 実行時の制約
– Log が永続化されてから data IO を実行
• Log 永続化方法
– (1) 全ての log IO に FLUSH|FUA フラグをセット
– (2) 定期的に log device で FLUSH IO を実行
21

18. Pros and Cons
WalB Snapshot
Pdata/oldata
Read Index search
search/copy
Write twice (easy)
Index modification
Write
Pdata/oldata (+ old data copy)
modification (fast)
Get Index search and
diffs
Sequential read
Non-sequential read
Typical
Soft.
--- ZFS, BtrFS, (LVM)
WalB + Index ~= Block device with snapshot access 22

19. 評価
• 環境
• ベンチマークソフトウェア
• プロトタイプ不具合
• ストレージデバイス
• 比較対象
• 結果
23

20. 評価環境
• Experimental Host
– CPU: Intel core i7 3930K
– Memory: DDR3-10600 32GB (8GBx4)
– OS: Ubuntu 12.04 x86_64
– Kernel: Custom build 3.2.24
• Storage HBA
– Intel X79 Internal SATA controller
– Using SATA2 interfaces for the experiment
24

21. ストレージデバイス
• MEM
– Memory block device (self-implemented)
• HDD
– Hard disk drive
• SSD
– Solid state drive
25

22. ベンチマーク
• 自作ベンチマークプログラム使用
– https://github.com/starpos/ioreth
• パラメータ
– Pattern: Random/sequential
– Mode: Read/write/(mix)
– Block size: 512B, 4KB, 32KB, 256KB
– numThreads: 1-32
• 計測方法
– IO 負荷 10秒間 x 5 の平均レスポンス/スループット
(WalB の random write は 100秒間 x 3)
26

23. プロトタイプの不具合
• Data IO 開始条件を満たしていない
– 現在: log completion 後に data IO を開始
– 正解: Log を 永続化させた後に data IO を開始
• Read IO のデータコピー順が不正
– 現在: pdata 内重複 IO を見付かった順にコピー
– 正解: log sequence id 順にコピー
27

24. 比較対象
Baseline
• Baseline
– 生のデバイス Data
• Wrap Wrap
Wrapper
– 自作の単純なラッパーデバ
イスドライバ経由 Data
– Request/bio インターフェー
ス WalB
• WalB WalB driver
– Easy/easy-ol/fast/fast-ol Log Data
– Request/bio インターフェー
ス 29

25. MEM 512B Random Response
Read Write
• Request インターフェースより bio • WalB アルゴリズムの IO 直列化オー
インターフェースの方がオーバー バーヘッドが並列度が大きくなるに
ヘッド小 つれて顕在化
30

26. MEM 512B Random IOPS
Read Write
• Request インターフェースのオー • 並列度が上がるとWalB の性能が低
バーヘッドが大 下
• キャッシュヒット率が低下もしくは
spinlock 排他待ちが増加したからだ
と考えられる 31

27. HDD 4KB Random IOPS
Read Write
• オーバーヘッドは無視できる程度 • Pdata が埋まるまでの過渡状態が無
視できない
• 並列度大では data IO のスケジュー
リング効果が考えられる
32

28. HDD 256KB Sequential Bps
Read Write
• Request インターフェースの方が良 • Log header block の分 WalB のスルー
い プットは落ちる
• おそらく Bio インターフェースは一 • Log と Data が別デバイスで HBA の
度に 32KB までしかまとめられない 帯域がボトルネックにならないケー
ため ス 33

29. SSD 4KB Random IOPS
Read Write
• WalB は Request インターフェース • Easy よりも fast は高性能
とほぼ同じ性能 • Fast でも並列度が低いときはレスポ
ンスオーバーヘッドが影響する
34

30. SSD 4KB Random IOPS (Two partitions in a SSD)
Read Write
• SSDx2 とほぼ同じ結果 • 帯域がボトルネックなので Log と
Data を書き込む WalB は性能が約半
分に
35

31. SSD 256KB Sequential Bps
Read Write
• 並列度 1 のときはオーバーヘッドが • Easy よりも fast は高性能
無視できない • Fast でも並列度が低いときはオー
バーヘッドが無視できない
• Easy だと 並列度が低いときのオー
バーヘッド大 36

32. 評価まとめ
• WalB オーバーヘッド
– 並列度小/ブロックサイズ小では無視できない
• Request vs bio
– オーバーヘッドと IO まとめ効果のトレードオ
フ
• Easy vs Fast
– 特に並列度小の領域では Fast の方が良い
37

33. 開発の進捗
• アルゴリズム構築
• プロトタイプの実装と性能検証
• >>本実装
• テスト/テスト運用
• オープンソース (GPL v2 or later)
– https://github.com/starpos/walb
38

34. まとめと今後の課題
• WalB
– ブロック層での差分バックアップ/レプリケーション
– 永続索引構造なし，Redo ログのみ記録
– 性能オーバーヘッド低減を重視
• 今後の課題
– モデルの定式化
– 上位層ミドルウェアとの協調
39

35. ありがとうございました
• ご質問，コメント等はこちらまで
– @starpoz
– hoshino@labs.cybozu.co.jp
40