5月13日、7月14日開催のスマートスタイル様との共同セミナー「他山の石勉強会」でのスライド資料です。サポートの事例から3点をピックアップしてご紹介しています。

1. 「他山の石勉強会」
～DRBD編～

2. 監視サービス
Bacula
Enterprise
Edition
LINBIT クラ
スタスタックサ
ポート
株式会社サードウェア
設立 1997年2月7日
事業内容 インターネット/イントラネット活用のための総合的な支援サービス
Linux オープンソース・ソフトウェアのサポート
コンピュータ・セキュリティのコンサルテーション
DRBD開発元のLINBIT社の国内総代理店
Bacula 開発元のBacula Systems社の国内総代理店
2

3. 3
アプリケーション
ファイルシステム
ページキャッシュ
ディスクドライバ
Rawデバイス
ディスク
スケジューラ
ディスク
NICドライバ
TCP/IP
ネットワークカード
ディスク
NICドライバ
TCP/IP
ネットワークカード
DRBD
(セカンダリ)
ディスクドライバ
ディスク
スケジューラ
DRBD
(プライマリ)
DRBDは2010年にLinux
カーネルに取り込まれました。
動作はカーネルの一部として
行われます。
(管理ツールはユーザランド)
とは

4. 4
とデータベースのレプリケーション機能との違い
DRBD(8.4 系) DBレプリケーション
DBの高可用性 ○ ○
DB以外のデータの
高可用性
○ ×
マルチインスタンス × ○
スキル 共通 DBソフトごとに異なる

5. 5
https://speakerdeck.com/con_mame/amazon-aurora
某大手クラウドサービスも を使っています

6. 6
1. レプリケーションと同期の違い
2. 設定時にはバージョンに注意
3. 設定値が厳しすぎて不安定になって
いるシステム
お話しすること

7. 7
1. レプリケーションと同期の違い

8. 8
レプリケーションと同期は違う
DRBDでの「レプリケーション」と「同期」は別の概念
レプリケーション(Replication)
･･･ディスクへの新しい書込みをプライマリとセカンダリの両方に複製する
同期(Synchronization)
・・・ディスク全体の整合性の一致を行う。初期同期や復旧時など
レプリケーション
同期
同期中でも
書き込みできる

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
④
レプリケーションをしつつ、
セカンダリ側に再同期
再同期中にフェイルオーバーして
プライマリ・セカンダリが交代
再同期
レプリケーション
<レプリケーションと再同期が逆方向>

20. 20
同期中の潜在的な危険性
Primary Secondary
・同期はブロック単位で行われる
・書き込み順序はメディア先頭から行われる
同期途中で同期元(Sync Source)がクラッシュすると、
データ不整合が残ってしまう可能性がある
同期
管理情報
データ
管理情報
データ(一部)
管理情報があるので、
データも全部揃っていると
認識してしまうが、実際に
は一部しかない、という状
態になりうる。

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)スナップショットをとる

22. 22
2. 設定時にはバージョンに注意

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

25. 25
デフォルト値の違いが原因で起きた問題例①
突然DRBDのレプリケーションができなくなっていた。
DRBDの通信経路の疎通はできているのに。
Ping OK

26. 26
デフォルトでko-countの機能が有効になっているため
デフォルト値の違いが原因で起きた問題例①

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時間内に書込完了できな
いと・・・
！ログ出力

29. 29
そもそも、なぜko-countが有効なのか
ko-countが無効だと、セカンダリでディスク書き込みが完了しな
い時にハングアップ状態になる。
細いWAN環境やパフォーマンスの悪い仮想環境などではko-
countを変更するのも一考。

30. 30
再同期で設定どおりの速度が出ない。
syncer rate 90M;を指定しているのに
実際の同期速度が90MB/secよりかなり下回る。
デフォルト値の違いが原因で起きた問題例②

31. 31
DRBD8.3と8.4では再同期のデフォルト動作が異なる
から、同じ動作にはならない
デフォルト値の違いが原因で起きた問題例②

32. 32
8.3系では･･･
同期はデフォルトでは250KiB/秒に帯域幅が制限されている
(すごくおそい)
この制限値rateの変更は設定ファイルのsyncerセクションで行う。
例：
syncer {
rate 90M;
}
同期の速度調節が異なる

33. 33
8.4以降は･･･
・syncerセクションがなくなる
・同期がデフォルトで動的調節になる
→8.3の形式の設定ファイルでは、同期のrate設定に効果がない
同期の速度調節が異なる

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;
}

35. 35
同期が動的調節だと・・・
動的調節だと、
→レプリケーション量が大きい場合に同期用の帯域幅をレプリケーション用に明け渡す。
そのため、同期速度は低下してrateに指定した速度にならない
8.3
rate resync-rate resync-rate
同
期
レ
プ
リ
ケ
ー
シ
ョ
ン
レ
プ
リ
ケ
ー
シ
ョ
ン
同
期
同
期
レ
プ
リ
ケ
ー
シ
ョ
ン
レプリケーション量
の増減で使用帯
域を動的に調整
8.4

36. 36
そもそも、なぜ動的調整するのか
アプリケーションのI/O 同期のrate設定
固定rateの場合の全体のI/O
動的調節により、
レプリケーション用の帯域が増える
(同期に使える帯域が減る)
アプリケーションの性能劣化しない動的調整が機能した場合
帯域幅超過分はアプリケーションの
書き込み遅延となり、
アプリケーションの性能劣化が発生

37. 37
デフォルト値の確認方法
DRBD8.3
# drbdsetup /dev/<デバイス名> show
DRBD8.4
# drbdsetup show --show-defaults /dev/<デバイス名>
# drbdsetup show --show-defaults <リソース名>

38. 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. 39
異なるデフォルト値の確認方法
日本語版DRBD8.4マニュアル
付録A 最近の変更点 - 5. デフォルト値の変更点
http://www.drbd.org/en/doc/users-guide-84/ap-recent-
changes
変更点はマニュアルの「付録」
に載っています

40. 3. 設定値が厳しすぎて不安定
になっているシステム
(Pacemakerの)

41. 41
特に異常がないのに
フェイルオーバしました。
よくあるお問い合わせ

42. 42
主な犯人:
migration-threshold=1
※リソースの異常を検知してプロセス再起動を行った回数が、
この値を超えるとフェイルオーバする、というPacemakerのオプション
デフォルトは無効(INFINITY)

43. 43
migration-threshold=1で何が悪い？
→monitorがタイムアウトするとフェイルオーバー
ちょっと負荷が高いとすぐにフェイルオーバー

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の終了処理が遅れたことを示すログ。
だいたい負荷が高かった時に出力される。
処理のタイムアウト時に典型的なログ

46. 46
migration-threshold=1で困った事例2
仮想環境ではちょっとしたことでゲストOSに負荷がかかるので……
・仮想基盤のリソース不足
・ゲストOSのスナップショットを取得
したときにフェイルオーバが起こってしまう

47. 最後に
47
サードウェアではDRBD開発元のLINBITによる認定バイナリの提供と
サポートサービスを行っています。
運用に不安のある場合にはご利用をご検討ください。
・開発終了版へのサポートやパッチ提供
・DRBDのみやPacemakerのみのサポートパックetc
大規模環境にはディスカウントもあります。
お気軽に sales@3ware.co.jp にお問い合わせください。
※認定バイナリ
:DRBD、HeartbeatまたはCorosync、Pacemakerのテスト済推奨構成のパッケージ