ログ先行书き込みを用いたストレージ差分取得の一手法
Download as pptx, pdf15 likes3,191 views
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