Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

introduction of WalB

6.351 visualizaciones

Publicado el

WalB is a fast and low latency backup system for block devices

Publicado en: Tecnología
  • Sé el primero en comentar

introduction of WalB

  1. 1. WalB入門 update 2017/5/30 (1st 2014/10/29) 光成滋生
  2. 2. • ブロックデバイスレベルのバックアップシステム • 高速でレイテンシが小さい • IOスパイクが無い • リアルタイムで逐次的 • デバイスドライバ、サービス、コマンド群を含む バックアップ中のデータread量のグラフ WalBとは dm-snapでfull scan中 WalB 2/33
  3. 3. • 障害に備えたデータの複製 • RAIDはシステムの多重化 • 壊れたらデータは復元できない • ある瞬間の状態(=snapshot)に戻せる • うっかりデータ消したのでなんとかして • cybozu.comでは14日間のデータを保持 バックアップとは 今日のデータ 1時間前 半日前 昨日... 3/33
  4. 4. • 常にほぼ最新の状態を別のサーバに反映 • サービスのダウンタイムを減らす • WalBは非同期(直近以外のデータは守る) 一方向遠隔レプリケーション 最新の状態 少しの遅れで ほぼ最新の状態に復元可能 東京 大阪 4/33
  5. 5. • 編集中のファイルはコピーできない • ある瞬間の状態には戻せない cp –aやxcopyじゃ駄目なの? 5/33
  6. 6. • 1TiBのHDDディスク • 1Gbpsだと数時間 • 200MiB/secでも1時間半 • 数十TBのデータだと… • その間データに触れないならサービスが止まる • ファイル変更を許容しながらのデータコピーが必要 データのコピーは時間がかかる 6/33
  7. 7. • データの先頭と最後でコピーした時刻が違う • ファイルコピー中に一部のデータが書き換えられる • 異なる時刻のデータが混在(一貫性無し=dirty) コピーしてる間にデータが変わる 12:00コピー開始 12:10コピー終了 AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABBAA 早い時刻に取得 後の時刻に取得 コピー中に変更 100GBのデータを先頭からコピーする ACCAAAAAAAAAAAAAABBAA データが混ざる 7/33
  8. 8. どうしよう
  9. 9. • LVMのsnapshot機能との合わせ技 • ある瞬間のdiskの全状態を取得できる • そのデータを転送する • 必要なら差分転送もする • 利点 • 実装が比較的簡単(ユーザランドですむ) • 欠点 • LVMのsnapshotに依存(データ化けのバグに悩む) • snapshotがあると遅い • 差分転送時にfull scanが必要 tbs(dm-snap)による解決 9/33
  10. 10. • logつきブロックデバイス • LVMへの依存を減らす • 差分更新時のfull scanが不要 • DRBDとの違い • 過去の(ほぼ)任意の時点を再現可能 • 低いオーバーヘッド WalBによる解決 10/33
  11. 11. • 100GiBボリュームの先頭5GiBに4KiBのランダムwrite • バックアップ時間(環境詳細はOSS Japan2017で) パフォーマンステスト IO spikeが無い 小さいoverhead WalB no-backup dm-snap 大きなoverhead dm-thin 大きなIO spike 11/33
  12. 12. • ブロックデバイスとして動作する • WalB = Write Ahead Logging Block device • その上に任意のファイルシステムを構築可能 • 全ての書き込みデータの情報をlogとして記録 WalBブロックデバイス(1/2) walb dev data用デバイスlog用デバイス write read どのブロックに 何を書いたかを記録 実際のデータを記録 元のブロックデバイスと同一 12/33
  13. 13. • 利点 • logさえあれば書き込み手順を正確に再現できる • いつHDDが故障しても安心 • レスポンスタイムも極力小さくなるように実装 • ほぼ任意の瞬間のsnapshotを再構成できる • 非同期一方向レプリケーションができる(後述) • 欠点 • log領域(リングバッファ)がいっぱいになると止まる • 随時データの読み出しが必要 • logとdata用で通常の2倍の書き込みが必要 WalBブロックデバイス(2/2) 13/33
  14. 14. • バックアップ対象サーバ(storage)から バックアップ用サーバ(archive)にデータを移動 • メインの負荷低減のため他のディスクに書き込む logを吸い出して転送 walb dev HDD storageプロセス archiveプロセス cybozu.com上の アプリケーション HDD 14/33
  15. 15. • 最初一度はFull backup(全部転送) • これは仕方がない • 得られたデータは一貫性がない(dirty snapshot) • 欲しいものは一貫性のあるclean snapshot Full backup Full backup開始 Full backup終了 AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABBBBBBBBBBB backup中に変更 データを先頭からコピーする BBBBBBBBBBBBBBBBBBBBBBB dirty snapshot 15/33
  16. 16. • Full backup中の書き込みをlogとして全て記録 • backup後にlogを差分適用 • dirty snapshotにT1~T2間のlogを適用する(apply) • T2におけるclean snapshotを得る dirtyなものをcleanにする T1でのdisk image dirty snapshot Full backup終了後 T2でのdisk image 書き込みlogを保持 L1 L2 L4L3 L1 L2 L4L3 T1~T2間のlogを適用 T2でのclean snapshot コピー開始時刻T1 コピー終了時刻T2 16/33
  17. 17. • clean snapshotを作った後 • logをapplyすると任意の時刻のclean snapshotを構成可能 • これによりバックアップとレプリケーションが可能 継続的なclean snapshotの追加 L9 L10 L5 T2でのclean snapshot T3でのclean snapshot T2~T3間のlogを適用 T4でのclean snapshot L6 L7 L8 T3~T4間のlogを適用 17/33
  18. 18. • 複数のlogをまとめる(diff) • 任意の時刻のsnapshotが必要なわけではない • 冗長データの削除と圧縮 • 同じブロック番号への書き込みは古いものを除去可能 • ブロック番号でソートすることで書き込み性能向上 log形式からdiff形式へ log形式 : (1, W1) (10, W2) (3, W3) (10, W4) (8, W5) (10, W6) ... diff形式 : (1, W1) (3, W3) (8, W5) (10, W6) diskW1 W2W3 W4 W5 0 1 2 3 4 5 6 7 8 9 10 11ブロック番号 W6 merge & sort ディスクへの 書き込み 18/33
  19. 19. • merge • 短期間に激しい書き込みで細かいlogが大量発生 • まとめて単一の効率のよいdiffへ • apply • archiveにはdiffとsnapshotがたまる • 任意の時間に戻れるがあまり古いのは不要 • snapshotにdiffをapplyして新しいsnapshotにする • applyが終わるとそのdiffを削除 • それらの操作はarchiveごとに非同期で • レプリケーション時に必要がdiffがないときがある • 現在の情報からHash backupと同様にdiffを生成 • やってる最中に落ちたら(略 mergeとapply 19/33
  20. 20. • 生成されたlogは極力失いたくない • logを失うとfull scan(Hash backup)が必要 • log用領域(リングバッファ)はあまり大きくしたくない • proxyがlogを逐次吸い出して別の領域に退避する proxy(1/2) walb dev walb-storage app on cybozu.com walb-archivewalb-proxy 20/33
  21. 21. • 可用性(システムの継続稼働能力)を高める • proxyの冗長化 • 落ちたときすぐに別のものに切り替わる • proxyは複数storageからのデータを受け取れる proxy(2/2) storage2 archive proxy2 proxy1 storage1 proxy1がdownしたら proxy2に切り替える 21/33
  22. 22. • Full backupはstorage-archive間で行う • logはproxy経由してdiffに変換される • archive間はdiffの転送 storage-proxy-archive full backup diff diff archive2archive1 proxy2 proxy1 storage log 22/33
  23. 23. • ユースケース • proxyで一時退避したデータが飛んだ • proxyが全て止まり復旧できずにlogが溢れる • archiveのデータが飛ぶとFull backupからやり直し • バックアップ対象を切り換えるとき(後述) • storageとarchive間でデータのhashを比較し 異なるものだけ転送 • データの転送量を削減する Hash backup diff Hash値のリスト archivestorage 23/33
  24. 24. • いろいろ冗長化 • storage • Target/Stanby • Targetが死んだら Stanbyに切り換える • proxy • スペアを用意 • archive • 遠隔レプリケーション 全体構成 proxy1 proxy2 archive1 archive2 raid storage1 storage2 Target Stanby cybozu.com 24/33
  25. 25. • 普段はTarget-proxy間のみ転送 • Stanby-proxy間は転送しない • raidでつながってるので 殆ど同じデータのはず • 完全に同じというわけではない • Targetが落ちたとき • Stanbyに切り換える • Hash backupでstorage1とstorage2の差を埋める • やってる最中に落ちたらもう一度Hash backup Target/Stanbyの切り換え raid storage1 storage2 Target Stanby proxy ≈ 25/33
  26. 26. • WalBデバイスはブロックデバイスにつき1個 • 圧縮などCPUを食う処理は別スレッドで • それぞれのサービスは非同期に動く • 状態取得や命令は各サービスとやりとりする専用コマンド walbcで行う • walbcはstorage/proxy/archiveたちと話す • walbcを扱うためのPythonライブラリ サービスとツール 26/33
  27. 27. • テストするたびに新たなバグ • もちろんWalB自体のバグもあるが他にもいろいろ遭遇する • kernelのバグ • kernel driverのバグ • LVMのバグ • KVMのバグ • gdbのバグ • raid controllerのバグ • etc. バグがいっぱい 27/33
  28. 28. • log情報は順序が変わってはいけない • writeシステムコールの中でシリアライズ • log情報は歯抜けになってはいけない • 突然プロセスやハードが落ちても 再起動後正しく動かないといけない • トランザクション的な処理が多い • 最小限の情報を永続化 • ext4のお行儀のよくない挙動 • write(2)の後、完了前にバッファを書き換えることがある • storage/proxy/archiveの協調動作 • 殆どの操作が非同期 • 複数の登場人物の扱いがとても面倒 細かくてややこしい問題がたくさん 28/33
  29. 29. • 例)proxyの交換 • 止める順序が大事 煩雑な手順 storage proxy2proxy1 archive 1. storage~proxy1間を停止 2. storageはproxy2に転送開始 3. proxy1のデータが全て転送されるまで proxy1~archive間の転送を継続 4. 転送が終わったらproxy1を停止 5. proxy1を交換 6. proxy1をstart 7. storageがproxy1に接続を 自動切り替え 29/33
  30. 30. • resizeの手順 • システムの一時停止 • storage • HDDの増設 • LVMのresize • walbのresize • ext4のresize • archive • HDD/LVMのresize 例 : diskの拡張 HDD LVM walb ext4 storage archive HDD LVM 30/33
  31. 31. • 通常ではlogの重複はありえないが 例 : logが重複する可能性 storage proxy2proxy1 archive L L L L 1. storageはLをproxy1に転送 2. 転送中storage~proxy1間の ネットワークがダウン a. proxy1はLの受け取り完了 b. しかしstorageはackを受信できず → Lを送ってないと判断 3. storageはproxy2と通信開始 4. Lをproxy2へ転送 5. proxy1とproxy2からそれぞれLを archiveに転送 6. Lが重複した 31/33
  32. 32. 主な状態遷移 Proxy add archive info Clear Started Stopped start stop clear Archive SyncReady Clear Stopped Archived clearinit Full/Hash sync stopreset backup replication start Stopped Target Standby Storage SyncReady Clear clear init_storage Full/Hash sync backup start stop reset _go_standby stop 32/33
  33. 33. • Project page • https://walb-linux.github.io/ • Tutorial • Vagrantを使った仮想マシン上でのWalB体験 • https://github.com/walb-linux/walb- tools/tree/master/misc/vagrant • Vagrantfile for Ubuntu 16.04 and CentOS 7 GitHub 33/33

×