他山の石勉強会 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

某大手クラウドサービスもを使っています

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のテスト済推奨構成のパッケージ

mailto:[email protected]

Software

他山の石勉強会 DRBD編