Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WalBの紹介

4,349 views

Published on

Published in: Technology, Business
  • Sex in your area is here: ❤❤❤ http://bit.ly/39sFWPG ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Follow the link, new dating source: ❶❶❶ http://bit.ly/39sFWPG ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

WalBの紹介

  1. 1. WalB の紹介 星野  喬 サイボウズ・ラボ 2014-01-30
  2. 2. 内容 •  •  •  •  •  •  WalB 開発の動機 アーキテクチャ 代替⼿手法との⽐比較 アルゴリズム 性能評価 まとめ 2
  3. 3. 動機 •  バックアップとレプリケーションで顧客データを守る •  ⾼高機能/⾼高コストなストレージは使えない •  OpenSolaris の ZFS が仮採⽤用されたが 安定しなかったので Linux 採⽤用が決定 •  dm-snap は full-scan しないといけない&遅い Primary DC Secondary DC Operating data Replicated data Backup data 3
  4. 4. 要件 •  機能 –  ⼀一貫性のあるデータ差分をバックアップ/レプリケー ションのために取得できる •  性能 –  フルスキャンを⽤用いない(初期バックアップを除く) –  オーバーヘッド⼩小 •  様々なデータをサポート –  Databases –  Blob data –  Full-text-search indexes –  ... 4
  5. 5. WalB 概要 •  Linux ブロックデバイスドライバ + 周辺ツール •  ⼀一貫性のある差分データを記録/取得し, バックアップ/レプリケーションに利利⽤用可能 •  “WalB” の意味は  “Block-level WAL” Diffs WalB storage Backup storage Replicated storage 5
  6. 6. WAL (Write-Ahead Logging) Ordinary Storage Time WAL Storage Write at 0 0 Write at 2 0 2 Read at 2 0 2 Write at 2 0 2 2 6
  7. 7. How to get diffs •  Full-scan and compare a b c d e a Data at t0 b’ c d e’ Data at t1 1 b’ 4 e’ Diffs from t0 to t1 •  Partial-scan with bitmaps (or indexes) a b c d e 00000 a b’ c d e’ 1 b’ 4 e’ 01001 •  Scan logs directly from WAL storages a b c d e a b’ c d e’ 1 b’ 4 e’ 1 b’ 4 e’ 7
  8. 8. WalB  アーキテクチャ Any application (File system, DBMS, etc) Walb dev controller Control Read A walb device as a wrapper A block device for data (Data device) Not special format Write Walb log Extractor Logs A walb log device A block device for logs (Log device) An original format 8
  9. 9. Log device format Address Metadata Superblock (physical block size) Ring buffer Log address = (log sequence id) % (ring buffer size) + (ring buffer start address) Unused (4KiB) 9
  10. 10. Ring buffer inside The oldest logpack The latest logpack Ring buffer Log pack Logpack header block Log pack header block Checksum Logpack lsid Num of records Total IO size 1st written data 2nd written data … 1st log record 2nd log record IO address IO size ... IO address IO size ... ... 10
  11. 11. Redo/undo ログ •  Redo ログ –  時間を進める •  Undo  ログ –  時間を逆に進める Redo logs Data at t0 0 2 Data at t1 Undo logs 0 2 11
  12. 12. WalB は redo log のみ記録 Generating redo logs Generating undo logs (1) write IOs submitted (1) write IOs submitted WalB (2) write redo logs Data Log (2) read current data Data (3) write undo logs Log •  Undo log を作るためには追加の read が必要 •  Undo log を作ると性能低下は避けられない 12
  13. 13. フルバックアップ/レプリケーション アーカイブホスト 運⽤用ホスト データデバイス ログデバイス フルスキャンして dirty イメージ取得 t0 (A) (B) フルイメージ 適⽤用 ログ t0〜~t1 間の ログ取得 (A) (C) t1 (B) t1  時点での clean イメージ完成 (C) Time t2 •  t0〜~t1 間のログを貯めておくのに⼗十分なリングバッファ を⽤用意する必要がある 13
  14. 14. 増分バックアップ/レプリケーション アーカイブホスト 運⽤用ホスト フルイメージ データデバイス ログデバイス バックアップ済み タイムスタンプ t0 (A) t0〜~t1の ログ取得 t1 適⽤用 (B) ログ 転送完了了 適⽤用 Time (A) t2 (B) •  複数世代を保持したい場合は, ログの適⽤用を遅らせるか,undo ログを⽣生成 14
  15. 15. バックアップ+レプリケーション バックアップホスト リモートホスト フルイメージ 運⽤用ホスト フルイメージ 適⽤用 適⽤用 データデバイス ログデバイス (A) t1 (B) ログ バックアップ 完了了 t0〜~t1の ログ取得 t0 (A’) (A) t2 (B) (B’) ログ レプリケーション 完了了 Time t3 レプリケーション遅延 •  カスケード接続が可能 15
  16. 16. 代替⼿手段 •  DRBD –  レプリケーションに特化 –  ⻑⾧長距離離間では有償の DRBD Proxy が必要 •  Dm-snap –  COW を⽤用いたスナップショット作成が可能 –  差分取得にフルスキャンが必要 •  Dm-thinp –  リファレンスカウンタを⽤用いた thin provisioning –  フラグメンテーションが避けられない 16
  17. 17. 代替⼿手段との⽐比較 Capability Async replication Read response overhead Write response overhead Fragmentation Negligible Write log instead data Never DRBD Negligible Send IOs to slaves (async repl.) Never dm-snap Search idx Modify idx (+COW) Never (original lv) dm-thinp Search idx Modify idx Inevitable Incr. backup WalB Sync replication Performance 17
  18. 18. WalB の利利点と⽋欠点 •  利利点 –  レスポンスオーバーヘッドが⼩小さい –  フラグメンテーションが起きない –  シーケンシャルリードでログを取り出せる •  ⽋欠点 –  Write に  2  倍強の帯域が必要 18
  19. 19. WalB source code statistics Block device wrappers File systems 19
  20. 20. ブロックデバイスとして満たすべき性質 •  読み書きの⼀一貫性 –  最後に書かれたデータを読む •  ⼀一意な状態を保持 –  ログをリプレイしたときと同じ状態となる •  Flush 済みデータの永続化 –  クラッシュしてもデータが失われない •  クラッシュ後の⼀一貫性保持 –  Redo ログのみ使⽤用してログ適⽤用する 20
  21. 21. WalB アルゴリズム •  •  •  •  IO  処理理フロー 重複 IO の直列列化 データの永続化 クラッシュリカバリと チェックポインティング 21
  22. 22. IO processing flow (Naive) Write Submitted Completed WalB write IO response Wait for log flushed and 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 22
  23. 23. IO processing flow (WalB) Write Submitted Completed WalB write IO response Packed Wait for log flushed and overlapped IOs done Log IO response Log submitted Data IO response Log completed Data submitted Data completed Pdata inserted Time Pdata deleted Read Submitted Completed Data IO response Pdata copied (Data submitted) (Data completed) Pdata: Pending Data Time 23
  24. 24. Pending data •  A red-black tree –  カーネルが提供 –  重複 IO を発⾒見見しやすく するためアドレス順に ソート ... Node0 Node1 addr size data addr size data ... NodeN addr size data •  A spinlock –  複数コアからのアクセ スを排他 24
  25. 25. Pdata pseudo code Insert_to_pdata(pdata,  io):      (delete  fully  overwritten  io(s)  by  the  io  from  the  pdata)      insert  the  io  to  pdata.         Delete_from_pdata(pdata,  io):      (if  not  deleted  yet)      delete  the  io  from  pdata.     Copy_overlapped_area(pdata,  io):      get  overlapped  io  list  from  pdata.      sort  the  list  by  log  sequence  id.      for  each  io  (as  iox)  in  the  sorted  list:          copy  overlapped  area  of  iox  to  the  io.     Each  function  must  be  executed  atomically  (with  spinlock).   25
  26. 26. Overlapped IO serialization Wait for overlapped IOs done Data IO response Data submitted Oldata inserted Got notice Time Data completed Oldata deleted Sent notice •  ⼀一意な状態を実現するため重複 IO のみを直列列化 •  Oldata: overlapped data –  pdata と構造は類似 –  IO につきカウンタひとつで重複 IO の存在を管理理可能 –  FIFO 制約 26
  27. 27. Overlapped IO serialization –cont. Address Queued Submitted A C B Completed D Time A 0 Oldata A B C D AB 00 ABC 002 ABCD 0022 a=0 ABCD 0022 CD 01 D 0 c-c--,d-- b=0 c=2 d-d=2 Wait for completion of previously inserted overlapped IOs Wait for completion of the IO Wait for completion of previously inserted IOs 27
  28. 28. Oldata pseudo code Insert_to_oldata(oldata,  io):      io.ol_count  =  number  of  overlapped  io(s)  in  oldata      insert  the  io  to  oldata.      if  io.ol_count  ==  0:  submit  the  io.      else:  the  io  should  wait  for  notification.     Delete_from_oldata(oldata,  io):      delete  the  io  from  oldata.      for  each  io  (as  iox)  in  the  all  overlapped  io(s)  in  oldata:          iox.io_count  -­‐=  1          if  iox.io_count  ==  0:              notify  to  iox  that  it  can  be  submitted.     Each  function  must  be  executed  atomically  (with  spinlock).   The  order  of  insertion/deletion  IOs  must  be  the  same  (FIFO).   28
  29. 29. データの永続化: FLUSH Write IO リクエスト列列 ... FLUSH ... 永続化対象 WalB における対応  Log IO リクエスト列列 ... FLUSH ... 永続化対象 •  Data デバイスへの対応 IO の永続化はチェックポイン ティングで別途保証するため  FLUSH/FUA は外す 29
  30. 30. データの永続化: FUA Write IO リクエスト列列 ... FUA ... 永続化対象 WalB における対応  Log IO リクエスト列列 ... FLUSH FUA ... 永続化対象 •  ログの永続化条件は,それを含む以前のログが全て永続 化されること 30
  31. 31. チェックポインティングとクラッシュリカバリ •  チェックポインティング –  データデバイスに FLUSH リクエストを発⾏行行し, 対応するログ  ID をスーパーブロックに記録 –  定期的に実⾏行行 (〜~10秒) •  クラッシュリカバリ –  アセンブル時にチェックポイント以降降のログをデー タデバイスに適⽤用して⼀一貫性を回復復 –  Undo ログはないため,データデバイスで write IO を 実⾏行行する前に対応するログを永続化する必要あり 31
  32. 32. 評価実験環境 •  Host –  CPU: Intel core i7 3930K (6c12t) –  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 32
  33. 33. ベンチマーク •  ⾃自作ソフトウェア  ioreth –  https://github.com/starpos/ioreth –  libaio 使⽤用 •  パラメータ –  Pattern: Random/sequential –  Mode: Read/write –  IO size: 512B, 4KB, 32KB, 256KB –  # of threads/queue size: 1-32 33
  34. 34. 対象ストレージデバイス •  MEM –  Memory block devices (self-implemented) •  HDD –  Seagate Barracuda 500GB (ST500DM002) –  Up to 140MB/s •  SSD –  Intel 330 60GB (SSDSC2CT060A3) –  Up to 250MB/s with SATA2 34
  35. 35. Storage settings •  Baseline Baseline –  ⽣生のストレージデバイス •  Wrap –  単にリクエストを転送する ラッパーデバイス –  Request/bio インターフェース •  WalB –  Naive/walb algorithm –  Request/bio インターフェース Data Wrap Wrap driver Data WalB WalB driver Log Data 35
  36. 36. WalB parameters •  Log-flush-disabled experiments –  Target storage: MEMs/HDDs/SSDs –  Pdata size: 4-128MiB •  Log-flush-enabled experiments –  Target storage: HDDs/SSDs –  Pdata size: 4-64MiB –  Flush interval size: 4-32MiB –  Flush interval period: 10ms, 100ms, 1s 36
  37. 37. MEM 512B random: response Read (IO size: 512 bytes) •  Request インターフェースは bio イン ターフェースに⽐比べて遅い •  並列列度度  1  のオーバーヘッドが 3〜~4us •  Pdata 検索索が多くを占めると考えられ る Write (IO size: 512 bytes) •  Write IO を内部的に直列列化する   WalB は並列列度度が⾼高くなるとレスポ ンスタイムがより増⼤大 37
  38. 38. MEM 512B random: IOPS Read (IO size: 512 bytes) •  Request インターフェースはオー バーヘッド⼤大 •  WalB のオーバーヘッドは  Pdata 検 索索によるものと考えられる Write (IO size: 512 bytes) •  並列列度度増加で  WalB の IOPS が低下 するのは  spinlock 待ちが増えたた め,もしくはキャッシュヒット率率率が 低下したためと考えられる 38
  39. 39. Pdata and oldata overhead Overhead of pdata easy: Naive algo. fast: WalB Kernel 3.2.24, walb req prototype algo. Overhead of oldata ol: overlapped IO serialization 39
  40. 40. HDD 4KiB random: IOPS Read •  オーバーヘッドは無視できる程度度 Write •  walb の⽅方が IOPS ⼤大きい •  スケジューリングの効果だと推察 40
  41. 41. HDD 256KiB sequential: Bps Read Write Queue length •  Request インターフェースの⽅方が bio よりも良良い結果 •  bio インターフェースでは IO 分割 される (kernel 3.2 だと  32KiB) Queue length •  WalB はログヘッダブロックを追加 するオーバーヘッドがあるが,計算 上は 4KiB/256KiB = 1.5% なので他 要因がメイン 41
  42. 42. SSD 4KiB random: IOPS Read Write Queue length •  Wrap-req と  Naive と  WalB  がほぼ 同じ性能 •  overlapped IO serialization のオー バーヘッドも無視できる程度度 Queue length •  Naive よりも  WalB の⽅方が良良い •  並列列度度が⼩小さい領領域で  WalB のオー バーヘッドが⼤大 42
  43. 43. SSD 4KiB random: IOPS (two partitions in a SSD) Read Write Queue length •  ほぼ SSDx2 と同じ Queue length •  スループットがほぼ半分 •  log + data が  1  つの SSD に書き込 まれるため 43
  44. 44. SSD 256KiB sequential: Bps Read Write Queue length •  並列列度度  1  の場合を除いてオーバー ヘッドは無視できる程度度 Queue length •  Naive よりも  WalB が良良い,特に並 列列度度⼩小の領領域 •  WalB のオーバーヘッドは  15% 以 下 44
  45. 45. Log-flush effects with HDDs IOPS (4KB random write) Queue length •  pending data での⼀一時的なlog-flush 待ちを利利⽤用して  data device に対す る  wirte IO をアドレス順に sort す ると HDD においては効果アリ Bps (32KB sequential write) Queue length •  特に sequential write  時に  log-flush オーバーヘッドを⼩小さくするために は pending data に⼗十分なメモリが 必要 45
  46. 46. Log-flush effects with SSDs IOPS (4KB random write) Queue length •  Log-flush 間隔は⼩小さい⽅方が良良い Bps (32KB sequential write) Queue length •  Log-flush の影響は無視出来る程度度 46
  47. 47. 評価まとめ •  WalB オーバーヘッド –  並列列度度が⼩小さい場合は無視できない –  Log-flush は HDD を⽤用いた sequential write 時に 無視できない •  Request vs bio interface –  IO サイズが⼤大きい場合を除いて bio の性能が⾼高い 47
  48. 48. WalB まとめ •  Linux ブロックデバイスドライバ –  増分バックアップ –  ⾮非同期レプリケーション •  オーバーヘッド⼩小 –  No persistent indexes –  No undo-logs –  No fragmentation 48
  49. 49. 開発進捗と今後 •  Version 1.0 –  For Linux kernel 3.2+ and x86_64 architecture –  Userland tools are minimal •  Improve userland tools –  Faster extraction/application of logs –  Logical/physical compression –  Backup/replication managers •  Submit kernel patches 49
  50. 50. Future work •  Add all-zero flag to the log record format –  to avoid all-zero blocks storing to the log device •  Add bitmap management –  to avoid full-scans in ring buffer overflow •  (Support snapshot access) –  by implementing pluggable persistent address indexes •  (Support thin provisioning) –  if a clever defragmentation algorithm was available 50
  51. 51. Thank you for your attention! •  GitHub repository: –  https://github.com/starpos/walb/ •  Contact to me: –  Email: hoshino AT labs.cybozu.co.jp –  Twitter: @starpoz (hashtag: #walbdev) 51

×