はじめに
DRBD 9.3がリリースされ、Compound Pages対応による大容量I/Oのパフォーマンス向上など、内部アーキテクチャに魅力的なアップデートが施されました。しかし、エンタープライズ環境でDRBDを運用するインフラエンジニアにとって、バージョンアップの際に最も気になるのは「性能」よりも「既存のログ監視やステータス判定の仕組みが壊れないか」という点ではないでしょうか。
PacemakerやDRBD Reactorといった標準のクラスタスタックを使用している場合は、ツール側でバージョンの差異が吸収されます。しかし、Zabbixなどの統合監視ツールや、ログの文字列をトリガーとする独自のHAソフトを用いてDRBDを管理している環境では事情が異なります。
「drbdadm statusの出力フォーマットの空白が1つ増えた」「/var/log/messages に出力される警告文言が変わった」——たったこれだけのことで、監視ツールの正規表現（grepやawk）によるパースが失敗し、アラートの検知漏れや、予期せぬフェイルオーバーの失敗といった致命的な障害に繋がる恐れがあります。
本記事では、こうした「ログ・ステータス監視」を行っている環境が安心してDRBD 9.3系へ移行できるよう、旧バージョン（9.2系）とのインターフェース（CLI出力およびカーネルログ）の互換性を徹底的に検証した結果を解説します。
検証のアプローチ：徹底したブラックボックステスト
インターフェースの互換性を机上のChangelogだけで判断するのは危険です。そこで今回は、RHEL 8系環境にて DRBD 9.2.12 (drbd-utils 9.28.0) と DRBD 9.3.1 (drbd-utils 9.34.0) のクラスタを構築し、以下のシナリオで出力結果を比較するブラックボックステストを実施しました。
- 平常時のステータス確認（Primary / Secondaryでの稼働）
- ネットワーク遮断（ルーティングのブラックホール化による疑似的な通信断）
- スプリットブレインの発生（意図的にUUIDを分岐させてデータの競合を発生）
検証結果1：互換性が維持されている安心ポイント（🟢 変更なし）
結論から申し上げますと、ログ監視の要となる中核的な出力については、完全な下位互換性が維持されていることが確認できました。
1. 致命的なカーネルログ（Syslog）の文字列は完全一致
監視システムが異常を検知して管理者にアラートを飛ばす（あるいはフェンシングを発動させる）最大のトリガーとなるログは、9.2系と9.3.1で1文字も変わらず出力されます。
▼ スプリットブレイン検知時のログ出力（9.2 / 9.3共通）
kernel: drbd r0/0 drbd0 node2: uuid_compare()=split-brain-auto-recover by rule=bitmap-both
kernel: drbd r0/0 drbd0 node2: Split-Brain detected but unresolved, dropping connection!▼ ネットワーク切断検知時のログ出力（9.2 / 9.3共通）
kernel: drbd r0 node2: PingAck did not arrive in time.
kernel: drbd r0 node2: conn( Connected -> NetworkFailure ) peer( Secondary -> Unknown )
kernel: drbd r0/0 drbd0 node2: pdsk( UpToDate -> DUnknown ) repl( Established -> Off )Zabbix等のログ監視で Split-Brain detected や NetworkFailure などをキーワード指定している場合、9.3へアップデートしてもそのまま正確に検知できます。
2. 基本ステータス確認コマンドの出力結果
状態判定によく使われる以下のサブコマンドについても、出力文字列および正常終了時の戻り値（$? = 0）に変更はありませんでした。
# 接続ステータスの確認
$ drbdadm cstate r0
Connected （※切断時は StandAlone や Connecting など）
# ディスクステータスの確認
$ drbdadm dstate r0
UpToDate/UpToDate
# 現在のロール確認
$ drbdadm role r0
Primary （※セカンダリ時は Secondary）検証結果2：ログ監視で注意すべき変更点（⚠️ 要確認）
一方で、詳細な状態を取得するコマンドにおいては、新機能の実装に伴い「フィールドの追加」や「構造の変更」が確認されました。以下の出力を監視ツールで定期取得・パースしている場合は、誤動作しないか事前に確認が必要です。
注意点1：drbdadm status への open 属性の追加
デバイスが現在マウントされているか（ファイルシステム等からオープンされているか）を示す属性が、ディスク状態の直後に追加されました。
▼ 9.2.12 の出力
r0 role:Secondary
disk:UpToDate
node2 role:Secondary
peer-disk:UpToDate▼ 9.3.1 の出力（変更箇所）
r0 role:Secondary
disk:UpToDate open:no
node2 role:Secondary
peer-disk:UpToDate【想定されるリスク】
もし監視設定で grep "disk:UpToDate$" のように行末記号（$）を厳格に指定してパースしている場合、9.3.1では末尾に open:no (または open:yes) が付与されるためマッチしなくなります。また、awk '{print $2}' のように空白区切りで要素の位置を固定している場合、後続のインデックスがずれる可能性があるため注意が必要です。
注意点2：JSON出力（drbdsetup show –json）の構造変更
DRBD 9.3系のChangelogでも予告されていた通り、JSONの出力構造に破壊的変更（Breaking Change）が含まれています。
特にネットワークパスの構造が単数形（path）から複数形（paths の配列）に変更されたほか、ネットワークやディスクに関する詳細な設定パラメータが大量にJSON内へ出力されるようになりました。jq コマンド等でJSON形式から直接値を抽出して監視システムに連携している場合は、パスの指定変更など設定の改修がほぼ必須となります。
おわりに
今回の検証により、DRBD 9.3.1は内部的に大きな進化を遂げつつも、外部インターフェース（特に運用に直結するカーネルログや基本ステータス）の互換性を最大限に尊重して設計されていることが明らかになりました。
実際、この検証結果をLINBIT社のCEOでありDRBDのリード開発者でもあるPhilipp Reisner氏に報告したところ、「drbd-9.2と9.3間のインターフェースの差異は最小限であり、ほとんどのユーザーはスクリプトを変更せずに新しいバージョンへ移行できるはずだ」との公式な見解を得ています。
drbdadm status の新規フィールド追加や、JSONの構造変更といったポイントを事前に改修できれば、厳密な監視を行っているエンタープライズ環境においても、DRBD 9.3系へのアップデートは概ね安全に行えるものと考えます。
もちろん、本記事の検証結果はあくまで一例です。監視ソフトのトリガー条件や運用スクリプトは環境ごとに異なるため、本番適用前にはぜひ皆様の検証環境でも「意図的なネットワーク遮断」や「スプリットブレインの模擬」などを実施し、最終的な互換性をチェックしてみてください。
本検証結果が、皆様のシステムの安全なバージョンアップ計画の一助となれば幸いです。