他山の石勉強会 DRBD編
Transcript of 他山の石勉強会 DRBD編
「他山の石勉強会」~DRBD編~
監視サービスBacula
Enterprise Edition
LINBIT クラスタスタックサポート
株式会社サードウェア設立 1997年2月7日
事業内容 インターネット/イントラネット活用のための総合的な支援サービス
Linux オープンソース・ソフトウェアのサポート
コンピュータ・セキュリティのコンサルテーション
DRBD開発元のLINBIT社の国内総代理店
Bacula 開発元のBacula Systems社の国内総代理店
2
3
アプリケーション
ファイルシステム
ページキャッシュ
ディスクドライバ
Rawデバイス
ディスクスケジューラ
ディスク
NICドライバ
TCP/IP
ネットワークカード
ディスク
NICドライバ
TCP/IP
ネットワークカード
DRBD(セカンダリ)
ディスクドライバ
ディスクスケジューラ
DRBD(プライマリ)
DRBDは2010年にLinuxカーネルに取り込まれました。
動作はカーネルの一部として行われます。
(管理ツールはユーザランド)
とは
4
とデータベースのレプリケーション機能との違い
DRBD(8.4 系) DBレプリケーション
DBの高可用性 ○ ○
DB以外のデータの高可用性
○ ×
マルチインスタンス × ○
スキル 共通 DBソフトごとに異なる
5
https://speakerdeck.com/con_mame/amazon-aurora
某大手クラウドサービスも を使っています
6
1. レプリケーションと同期の違い
2. 設定時にはバージョンに注意
3. 設定値が厳しすぎて不安定になっているシステム
お話しすること
7
1. レプリケーションと同期の違い
8
レプリケーションと同期は違う
DRBDでの「レプリケーション」と「同期」は別の概念
レプリケーション(Replication)・・・ディスクへの新しい書込みをプライマリとセカンダリの両方に複製する
同期(Synchronization)・・・ディスク全体の整合性の一致を行う。初期同期や復旧時など
レプリケーション
同期
同期中でも書き込みできる
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
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
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
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
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
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
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
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
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
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
レプリケーションと同期が逆になる状況もある
Primary Secondary(ダウン)
Primary Secondary
Primary Secondary(再起動)
① ②
③
レプリケーション中にセカンダリがダウン(それでもプライマリで書き込みは続く)
セカンダリが再起動(プライマリで書き込みは続く)
Secondary Primary
④
レプリケーションをしつつ、セカンダリ側に再同期
再同期中にフェイルオーバーしてプライマリ・セカンダリが交代
再同期
レプリケーション
<レプリケーションと再同期が逆方向>
20
同期中の潜在的な危険性
Primary Secondary
・同期はブロック単位で行われる・書き込み順序はメディア先頭から行われる
同期途中で同期元(Sync Source)がクラッシュすると、データ不整合が残ってしまう可能性がある
同期
管理情報
データ
管理情報
データ(一部)
管理情報があるので、データも全部揃っていると認識してしまうが、実際には一部しかない、という状態になりうる。
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)スナップショットをとる
22
2. 設定時にはバージョンに注意
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
メンテナンス(機能追加なし)
DRBD8.3は2013年9月に開発終了8.4では設定が少し変更されている
にもかかわず、ネット上の情報にはいまだにDRBD8.3のものが多い
↓8.3の情報を8.4でそのまま使ったため、意図した動作にならないケースがある。
DRBD 8.3 と 8.4 の差異
24
25
デフォルト値の違いが原因で起きた問題例①
突然DRBDのレプリケーションができなくなっていた。DRBDの通信経路の疎通はできているのに。
Ping OK
26
デフォルトでko-countの機能が有効になっているため
デフォルト値の違いが原因で起きた問題例①
27
ko-count : 「ノックアウトカウント」。セカンダリノードで書き込みリクエストがko-count×timeout時間内に完了しなかった場合に、そのノードを除外する。(コネクションをkillして再接続する)
ko-count のデフォルト値が違う
除外
バージョン ko-count timeout
DRBD 8.3 0(無効) 6秒
DRBD 8.4 7 6秒
デフォルト値
28
以下のようなエラーログが出力されてDRBD間の接続が切れる
Apr 10 13:13:37 test01 kernel: block drbd1: Remote failed to finish a request within ko-count * timeoutApr 10 13:13:37 test01 kernel: block drbd1: peer( Secondary -> Unknown ) conn( Connected -> Timeout ) pdsk( UpToDate -> DUnknown )
ko-count×timeout時間内に書込完了できないと・・・
!ログ出力
29
そもそも、なぜko-countが有効なのか
ko-countが無効だと、セカンダリでディスク書き込みが完了しない時にハングアップ状態になる。
細いWAN環境やパフォーマンスの悪い仮想環境などではko-countを変更するのも一考。
30
再同期で設定どおりの速度が出ない。
syncer rate 90M;を指定しているのに実際の同期速度が90MB/secよりかなり下回る。
デフォルト値の違いが原因で起きた問題例②
31
DRBD8.3と8.4では再同期のデフォルト動作が異なるから、同じ動作にはならない
デフォルト値の違いが原因で起きた問題例②
32
8.3系では・・・同期はデフォルトでは250KiB/秒に帯域幅が制限されている(すごくおそい)
この制限値rateの変更は設定ファイルのsyncerセクションで行う。
例:syncer {
rate 90M;}
同期の速度調節が異なる
33
8.4以降は・・・・syncerセクションがなくなる
・同期がデフォルトで動的調節になる
→8.3の形式の設定ファイルでは、同期のrate設定に効果がない
同期の速度調節が異なる
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;
}
35
同期が動的調節だと・・・
動的調節だと、→レプリケーション量が大きい場合に同期用の帯域幅をレプリケーション用に明け渡す。
そのため、同期速度は低下してrateに指定した速度にならない
8.3
rate resync-rate resync-rate
同期
レプリケーション
レプリケーション
同期
同期
レプリケーション
レプリケーション量の増減で使用帯域を動的に調整
8.4
36
そもそも、なぜ動的調整するのか
アプリケーションのI/O 同期のrate設定
固定rateの場合の全体のI/O
動的調節により、レプリケーション用の帯域が増える(同期に使える帯域が減る)アプリケーションの性能劣化しない動的調整が機能した場合
帯域幅超過分はアプリケーションの書き込み遅延となり、アプリケーションの性能劣化が発生
37
デフォルト値の確認方法
DRBD8.3# drbdsetup /dev/<デバイス名> show
DRBD8.4# drbdsetup show --show-defaults /dev/<デバイス名> # drbdsetup show --show-defaults <リソース名>
38
DRBDのマニュアル情報
・DRBD8.3日本語版マニュアルhttps://www.drbd.jp/users-guide/users-guide.html
・DRBD8.4日本語版マニュアルhttps://blog.3ware.co.jp/drbd-users-guide-8.4/drbd-users-guide.html
39
異なるデフォルト値の確認方法
日本語版DRBD8.4マニュアル付録A 最近の変更点 - 5. デフォルト値の変更点http://www.drbd.org/en/doc/users-guide-84/ap-recent-changes
変更点はマニュアルの「付録」に載っています
3. 設定値が厳しすぎて不安定になっているシステム
(Pacemakerの)
41
特に異常がないのにフェイルオーバしました。
よくあるお問い合わせ
42
主な犯人:
migration-threshold=1
※リソースの異常を検知してプロセス再起動を行った回数が、この値を超えるとフェイルオーバする、というPacemakerのオプション
デフォルトは無効(INFINITY)
43
migration-threshold=1で何が悪い?
→monitorがタイムアウトするとフェイルオーバーちょっと負荷が高いとすぐにフェイルオーバー
44
migration-threshold=1で困った事例1
• Postgresqlのバキュームを実行↓
• マシン負荷上昇、I/O低下↓
• pgsqlリソースのモニターがタイムアウト↓
• fail-countに1がカウントされる↓
• フェイルオーバ発生…
45
こういったログが出ています:
---------WARN: G_SIG_dispatch: Dispatch function for SIGCHLD was delayed 1000 ms (> 100 ms) beforebeing called (GSource: 0xbeba80)---------
monitorの終了処理が遅れたことを示すログ。だいたい負荷が高かった時に出力される。
処理のタイムアウト時に典型的なログ
46
migration-threshold=1で困った事例2
仮想環境ではちょっとしたことでゲストOSに負荷がかかるので……
・仮想基盤のリソース不足・ゲストOSのスナップショットを取得
したときにフェイルオーバが起こってしまう
最後に
47
サードウェアではDRBD開発元のLINBITによる認定バイナリの提供とサポートサービスを行っています。
運用に不安のある場合にはご利用をご検討ください。・開発終了版へのサポートやパッチ提供・DRBDのみやPacemakerのみのサポートパックetc
大規模環境にはディスカウントもあります。
お気軽に [email protected] にお問い合わせください。
※認定バイナリ:DRBD、HeartbeatまたはCorosync、Pacemakerのテスト済推奨構成のパッケージ