introduction of WalB
•
4 likes•6,992 views
WalB is a fast and low latency backup system for block devices
Recommended
More Related Content
What's hot
What's hot (20)
Similar to introduction of WalB
Similar to introduction of WalB (20)
More from MITSUNARI Shigeo
More from MITSUNARI Shigeo (20)
Recently uploaded
Recently uploaded (8)
introduction of WalB
- 2. • ブロックデバイスレベルのバックアップシステム • 高速でレイテンシが小さい • IOスパイクが無い • リアルタイムで逐次的 • デバイスドライバ、サービス、コマンド群を含む バックアップ中のデータread量のグラフ WalBとは dm-snapでfull scan中 WalB 2/33
- 3. • 障害に備えたデータの複製 • RAIDはシステムの多重化 • 壊れたらデータは復元できない • ある瞬間の状態（=snapshot）に戻せる • うっかりデータ消したのでなんとかして • cybozu.comでは14日間のデータを保持 バックアップとは 今日のデータ 1時間前 半日前 昨日... 3/33
- 4. • 常にほぼ最新の状態を別のサーバに反映 • サービスのダウンタイムを減らす • WalBは非同期（直近以外のデータは守る） 一方向遠隔レプリケーション 最新の状態 少しの遅れで ほぼ最新の状態に復元可能 東京 大阪 4/33
- 5. • 編集中のファイルはコピーできない • ある瞬間の状態には戻せない cp –aやxcopyじゃ駄目なの? 5/33
- 6. • 1TiBのHDDディスク • 1Gbpsだと数時間 • 200MiB/secでも1時間半 • 数十TBのデータだと… • その間データに触れないならサービスが止まる • ファイル変更を許容しながらのデータコピーが必要 データのコピーは時間がかかる 6/33
- 7. • データの先頭と最後でコピーした時刻が違う • ファイルコピー中に一部のデータが書き換えられる • 異なる時刻のデータが混在（一貫性無し=dirty） コピーしてる間にデータが変わる 12:00コピー開始 12:10コピー終了 AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABBAA 早い時刻に取得 後の時刻に取得 コピー中に変更 100GBのデータを先頭からコピーする ACCAAAAAAAAAAAAAABBAA データが混ざる 7/33
- 8. どうしよう
- 9. • LVMのsnapshot機能との合わせ技 • ある瞬間のdiskの全状態を取得できる • そのデータを転送する • 必要なら差分転送もする • 利点 • 実装が比較的簡単（ユーザランドですむ） • 欠点 • LVMのsnapshotに依存（データ化けのバグに悩む） • snapshotがあると遅い • 差分転送時にfull scanが必要 tbs（dm-snap）による解決 9/33
- 10. • logつきブロックデバイス • LVMへの依存を減らす • 差分更新時のfull scanが不要 • DRBDとの違い • 過去の（ほぼ）任意の時点を再現可能 • 低いオーバーヘッド WalBによる解決 10/33
- 11. • 100GiBボリュームの先頭5GiBに4KiBのランダムwrite • バックアップ時間（環境詳細はOSS Japan2017で） パフォーマンステスト IO spikeが無い 小さいoverhead WalB no-backup dm-snap 大きなoverhead dm-thin 大きなIO spike 11/33
- 12. • ブロックデバイスとして動作する • WalB = Write Ahead Logging Block device • その上に任意のファイルシステムを構築可能 • 全ての書き込みデータの情報をlogとして記録 WalBブロックデバイス（1/2） walb dev data用デバイスlog用デバイス write read どのブロックに 何を書いたかを記録 実際のデータを記録 元のブロックデバイスと同一 12/33
- 13. • 利点 • logさえあれば書き込み手順を正確に再現できる • いつHDDが故障しても安心 • レスポンスタイムも極力小さくなるように実装 • ほぼ任意の瞬間のsnapshotを再構成できる • 非同期一方向レプリケーションができる（後述） • 欠点 • log領域（リングバッファ）がいっぱいになると止まる • 随時データの読み出しが必要 • logとdata用で通常の2倍の書き込みが必要 WalBブロックデバイス（2/2） 13/33
- 14. • バックアップ対象サーバ（storage）から バックアップ用サーバ（archive）にデータを移動 • メインの負荷低減のため他のディスクに書き込む logを吸い出して転送 walb dev HDD storageプロセス archiveプロセス cybozu.com上の アプリケーション HDD 14/33
- 15. • 最初一度はFull backup（全部転送） • これは仕方がない • 得られたデータは一貫性がない（dirty snapshot） • 欲しいものは一貫性のあるclean snapshot Full backup Full backup開始 Full backup終了 AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABBBBBBBBBBB backup中に変更 データを先頭からコピーする BBBBBBBBBBBBBBBBBBBBBBB dirty snapshot 15/33
- 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. • 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. • 複数の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. • merge • 短期間に激しい書き込みで細かいlogが大量発生 • まとめて単一の効率のよいdiffへ • apply • archiveにはdiffとsnapshotがたまる • 任意の時間に戻れるがあまり古いのは不要 • snapshotにdiffをapplyして新しいsnapshotにする • applyが終わるとそのdiffを削除 • それらの操作はarchiveごとに非同期で • レプリケーション時に必要がdiffがないときがある • 現在の情報からHash backupと同様にdiffを生成 • やってる最中に落ちたら（略 mergeとapply 19/33
- 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. • 可用性（システムの継続稼働能力）を高める • proxyの冗長化 • 落ちたときすぐに別のものに切り替わる • proxyは複数storageからのデータを受け取れる proxy（2/2） storage2 archive proxy2 proxy1 storage1 proxy1がdownしたら proxy2に切り替える 21/33
- 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. • ユースケース • proxyで一時退避したデータが飛んだ • proxyが全て止まり復旧できずにlogが溢れる • archiveのデータが飛ぶとFull backupからやり直し • バックアップ対象を切り換えるとき（後述） • storageとarchive間でデータのhashを比較し 異なるものだけ転送 • データの転送量を削減する Hash backup diff Hash値のリスト archivestorage 23/33
- 24. • いろいろ冗長化 • storage • Target/Stanby • Targetが死んだら Stanbyに切り換える • proxy • スペアを用意 • archive • 遠隔レプリケーション 全体構成 proxy1 proxy2 archive1 archive2 raid storage1 storage2 Target Stanby cybozu.com 24/33
- 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. • WalBデバイスはブロックデバイスにつき1個 • 圧縮などCPUを食う処理は別スレッドで • それぞれのサービスは非同期に動く • 状態取得や命令は各サービスとやりとりする専用コマンド walbcで行う • walbcはstorage/proxy/archiveたちと話す • walbcを扱うためのPythonライブラリ サービスとツール 26/33
- 27. • テストするたびに新たなバグ • もちろんWalB自体のバグもあるが他にもいろいろ遭遇する • kernelのバグ • kernel driverのバグ • LVMのバグ • KVMのバグ • gdbのバグ • raid controllerのバグ • etc. バグがいっぱい 27/33
- 28. • log情報は順序が変わってはいけない • writeシステムコールの中でシリアライズ • log情報は歯抜けになってはいけない • 突然プロセスやハードが落ちても 再起動後正しく動かないといけない • トランザクション的な処理が多い • 最小限の情報を永続化 • ext4のお行儀のよくない挙動 • write(2)の後、完了前にバッファを書き換えることがある • storage/proxy/archiveの協調動作 • 殆どの操作が非同期 • 複数の登場人物の扱いがとても面倒 細かくてややこしい問題がたくさん 28/33
- 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. • 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. • 通常では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. 主な状態遷移 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. • 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