Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 他山の石勉強会 DRBD編
Similar to 他山の石勉強会 DRBD編 (20)
他山の石勉強会 DRBD編
- 2. 監視サービス Bacula Enterprise Edition LINBIT クラ スタスタックサ ポート 株式会社サードウェア 設立 1997年2月7日 事業内容 インターネット/イントラネット活用のための総合的な支援サービス Linux オープンソース・ソフトウェアのサポート コンピュータ・セキュリティのコンサルテーション DRBD開発元のLINBIT社の国内総代理店 Bacula 開発元のBacula Systems社の国内総代理店 2
- 4. 4 とデータベースのレプリケーション機能との違い DRBD(8.4 系) DBレプリケーション DBの高可用性 ○ ○ DB以外のデータの 高可用性 ○ × マルチインスタンス × ○ スキル 共通 DBソフトごとに異なる
- 6. 6 1. レプリケーションと同期の違い 2. 設定時にはバージョンに注意 3. 設定値が厳しすぎて不安定になって いるシステム お話しすること
- 9. 9 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 メタデータを使用したデータの管理 Primary Secondary ディスクブロック ディスクブロック ビットマップ ビットマップ 書き込み (正確に言うと、クイック同期ビットマップ)
- 10. 10 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Primary Secondary ディスクブロック ディスクブロック ビットマップ ビットマップ レプリケーション メタデータを使用したデータの管理
- 11. 11 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Primary Secondary ディスクブロック ディスクブロック ビットマップ ビットマップ 完了通知 メタデータを使用したデータの管理
- 12. 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Primary Secondary ディスクブロック ディスクブロック ビットマップ ビットマップ 完了通知 メタデータを使用したデータの管理
- 13. 13 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Primary Secondary(停止) ディスクブロック ディスクブロック ビットマップ ビットマップ 書き込み セカンダリ停止時のメタデータによるデータ管理
- 14. 14 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Primary Secondary(停止) ディスクブロック ディスクブロック ビットマップ ビットマップ 完了通知 セカンダリ停止時のメタデータによるデータ管理
- 15. 15 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Primary Secondary(回復) ディスクブロック ディスクブロック ビットマップ ビットマップ 書き込み 同期 セカンダリ回復時のメタデータによるデータ管理
- 16. 16 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Primary Secondary ディスクブロック ディスクブロック ビットマップ ビットマップ レプリケーション完了通知 セカンダリ回復時のメタデータによるデータ管理
- 17. 17 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Primary Secondary ディスクブロック ディスクブロック ビットマップ ビットマップ 完了通知 セカンダリ回復時のメタデータによるデータ管理
- 18. 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Primary Secondary ディスクブロック ディスクブロック ビットマップ ビットマップ 完了通知 セカンダリ回復時のメタデータによるデータ管理
- 19. 19 レプリケーションと同期が逆になる状況もある Primary Secondary(ダウン) Primary Secondary Primary Secondary(再起動) ① ② ③ レプリケーション中にセカンダリがダウン (それでもプライマリで書き込みは続く) セカンダリが再起動 (プライマリで書き込みは続く) Secondary Primary ④ レプリケーションをしつつ、 セカンダリ側に再同期 再同期中にフェイルオーバーして プライマリ・セカンダリが交代 再同期 レプリケーション <レプリケーションと再同期が逆方向>
- 21. 21 同期中の潜在的な危険を回避 resource r0{ handlers{ before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh"; after-resync-target "/usr/lib/drbd/unsnapshot-resync-target-lvm.sh"; } } DRBDが論理ボリュームで作成されている場合には、以下のようにハンドラを設定することで 同期前後のLVMスナップショット取得を自動化することができます。 同期前にスナップショットを取得して、同期後にそのスナップショットを削除します。 対策 ①同期速度を速くしてできるだけ早く同期 ②同期前に(LVM)スナップショットをとる
- 23. 23 DRBDのライフサイクル DRBD 8.3 now 2013年9月 DRBD 8.3開発終了 2015年6月 DRBD 9リリース DRBD 8.3の延長サポート 最長2022年まで DRBD 9 DRBD 8.4DRBD 8.4 メンテナンス(機能追加なし)
- 24. DRBD8.3は2013年9月に開発終了 8.4では設定が少し変更されている にもかかわず、 ネット上の情報にはいまだにDRBD8.3のものが多い ↓ 8.3の情報を8.4でそのまま使ったため、 意図した動作にならないケースがある。 DRBD 8.3 と 8.4 の差異 24
- 27. 27 ko-count : 「ノックアウトカウント」。セカンダリノードで書き込みリクエス トがko-count×timeout時間内に完了しなかった場合に、そのノード を除外する。(コネクションをkillして再接続する) ko-count のデフォルト値が違う 除外 バージョン ko-count timeout DRBD 8.3 0(無効) 6秒 DRBD 8.4 7 6秒 デフォルト値
- 28. 28 以下のようなエラーログが出力されてDRBD間の接続が切れる Apr 10 13:13:37 test01 kernel: block drbd1: Remote failed to finish a request within ko-count * timeout Apr 10 13:13:37 test01 kernel: block drbd1: peer( Secondary -> Unknown ) conn( Connected -> Timeout ) pdsk( UpToDate -> DUnknown ) ko-count×timeout時間内に書込完了できな いと・・・ ！ログ出力
- 34. 34 設定ファイルの形式の違い syncer { rate 90M; } disk { resync-rate 90M; } しかし、同期の動的調節が有効(デフォルト)だと、上記設定は効果がない。 DRBD8.4で8.3と同じ動作にしたい場合は、動的調節を明示的に無効にする必 要がある。 DRBD 8.3と8.4では設定ファイルの互換性により、以下のように自動的に翻訳される syncer { rate 90M; } disk { c-plan-ahead 0; resync-rate 90M; }
- 37. 37 デフォルト値の確認方法 DRBD8.3 # drbdsetup /dev/<デバイス名> show DRBD8.4 # drbdsetup show --show-defaults /dev/<デバイス名> # drbdsetup show --show-defaults <リソース名>
- 39. 39 異なるデフォルト値の確認方法 日本語版DRBD8.4マニュアル 付録A 最近の変更点 - 5. デフォルト値の変更点 http://www.drbd.org/en/doc/users-guide-84/ap-recent- changes 変更点はマニュアルの「付録」 に載っています
- 44. 44 migration-threshold=1で困った事例1 • Postgresqlのバキュームを実行 ↓ • マシン負荷上昇、I/O低下 ↓ • pgsqlリソースのモニターがタイムアウト ↓ • fail-countに1がカウントされる ↓ • フェイルオーバ発生…
- 45. 45 こういったログが出ています： --------- WARN: G_SIG_dispatch: Dispatch function for SIGCHLD was delayed 1000 ms (> 100 ms) before being called (GSource: 0xbeba80) --------- monitorの終了処理が遅れたことを示すログ。 だいたい負荷が高かった時に出力される。 処理のタイムアウト時に典型的なログ