CentOS 7：カーネルアップデートで沈黙したDRBDを自前ビルドで復活させる

1. はじめに：延長サポート環境でDRBDが動かなくなる日

CentOS 7の公式サポート終了（EOL）後も、延長ライフサイクルサポート（ELS等）を利用してシステムを維持するケースは少なくありません。しかし、ELSによって提供されるカーネルのセキュリティアップデートを適用した際、予期せぬ落とし穴が待っています。

それは「既存のDRBDバイナリの互換性喪失」です。

高可用性（HA）クラスタの要であるDRBDは、カーネルに深く依存するモジュール（kmod-drbd）を持っています。カーネルがアップデートされると、それまで動いていたビルド済みのDRBDバイナリが読み込めなくなり、結果としてクラスタシステム全体が沈黙（動作不能）に陥るリスクがあります。（前回の記事に書いたkABIがうまく働けば動く可能性もあります。）

このためDRBDのパッケージもELSに合わせて更新しなければなりませんが、ELSの更新はコミュニティに反映されないため、DRBDの公開パッケージがELSに合わせて更新されることはありません。

本記事では、この危機的状況からシステムを復活させるため、LINBIT社の公式ソースコードからCentOS 7ネイティブ環境でDRBD（kmod-drbd および drbd-utils）のRPMパッケージを自社ビルドする手順を解説します。

2. 解決策：公式ソースコードからのクリーンビルド

外部の商用バイナリに依存せず、稼働中の最新カーネルに完全に適合したバイナリを自社で生成します。

まずはLINBIT社の公式サイトから、必要なバージョンのソースコード（今回は例として drbd-9.0.32 と drbd-utils-9.19.1）を入手します。

ここからダウンロードした tar.gz ファイルを使用して、ユーザー空間ツールとカーネルモジュールのRPMビルドを順番に行います。

3. drbd-utils ビルドに立ちはだかった3つの壁と突破口

ユーザー空間の管理ツール（drbd-utils）をクリーンビルドし、RPM化する過程で、CentOS 7環境ならではの3つの課題が発生しました。

課題1: マニュアル生成ツールの欠如によるビルド停止

  • 事象: make doc 実行時、asciidoctor などのドキュメント生成ツールがシステムに存在せずエラーが発生。これらのツールはEPELから入手できましたが、CentOS7(RHEL7)用のEPELは閉鎖されています。
  • 解決策: ELS環境下での外部リポジトリ（EPEL等）への不要な依存を避けるため、マニュアルの生成プロセスを完全に除外しました。configure 時に --without-manual オプションを付与し、主要ツールのコンパイルに特化させます。

課題2: Gitリポジトリ非依存によるアーカイブ生成エラー

  • 事象: ソースコードのアーカイブを展開した環境で make tarball を実行すると、.git ディレクトリが存在しないためエラー（Error 128）が発生。
  • 解決策: Makefile 内部のGit依存処理をバイパスするため、修正済みのソースディレクトリを手動でtar.gz形式に圧縮し、直接 rpmbuild/SOURCES/ 配下に配置する手法へと切り替えました。

課題3: RPMインストール時のディレクトリセルフ競合

  • 事象: テスト環境へ完成したRPMをインストールする際、/usr/sbin/drbdadm 等のファイルがパッケージ内で競合するエラーが発生。
  • 原因と解決策: CentOS 7における `/sbin` と `/usr/sbin` のディレクトリ統合（UsrMove）に起因するspecファイルの不整合が原因です。本来はspecファイルの修正が望ましいですが、今回は暫定処置として、インストール時に `–replacefiles` オプションを付与することで、強制上書きとして展開を完結させました。
  • 注意: `–replacefiles` は既存のシステムファイルを予期せず上書きするリスクがあるため、本番環境への適用時は、事前に影響範囲を十分に確認してください。

4. kmod-drbd ビルドにおける最大の罠

次に、カーネルモジュール（kmod-drbd）のビルドを行います。ここでも、見落としがちな重大な罠が存在します。

  • 最大の罠：事前の make 実行による環境汚染
    ソースを展開した後、「とりあえずビルドできるか確認しよう」と 一度でも単なる make を実行してしまうと、その後のRPM化（make kmp-rpm）が失敗します。事前の make で生成された中間ファイルや環境変数が、KMP（Kernel Module Package）のビルドプロセスが期待するクリーンな状態を汚染してしまうためです。
  • 解決策：一発勝負の make kmp-rpm
    ソースのtarボールを展開したら、途中で一切の make を挟まず、ディレクトリがクリーンな状態のまま一発で make kmp-rpm を実行してください。これにより、現在のカーネルに適合したRPMが生成されます。

5. 確立したビルド・インストール手順まとめ

これらを踏まえた最終的なビルド手順は以下の通りです。

【ビルド環境での作業】

# 1. 必須開発パッケージとカーネルヘッダーの導入
yum install -y rpm-build rpmdevtools glib2-devel make gcc gcc-c++ kernel-devel-$(uname -r)

# 2. drbd-utils のビルド
tar -xf drbd-utils-9.19.1.tar.gz
cd drbd-utils-9.19.1
./configure --with-distro=rhel --without-manual --enable-spec
cd ..
tar -czf /root/rpmbuild/SOURCES/drbd-utils-9.19.1.tar.gz drbd-utils-9.19.1
cd drbd-utils-9.19.1
rpmbuild -bb --without manual drbd.spec

# 3. kmod-drbd のビルド（展開後、即KMPビルド）
cd ..
tar -xzf drbd-9.0.32.tar.gz
cd drbd-9.0.32
make kmp-rpm

【ターゲット環境でのインストール】

生成されたRPM（~/rpmbuild/RPMS/x86_64/ 配下など）をターゲット機へ転送し、インストールします。

Bash

rpm -ivh --replacefiles drbd-utils-9.19.1-*.rpm
rpm -ivh kmod-drbd-9.0.32-*.rpm

インストール後、modprobe drbd を実行し、cat /proc/drbd （または drbdadm --version）で新しいバージョンがカーネルにロードされたことを確認すれば、システムの復活は完了です。

6. おわりに：自社ビルドがもたらすシステム延命策

ELS等を利用したシステムの長期延命において、カーネルアップデートに伴うミドルウェアの動作不良は避けて通れない道です。しかし、今回のように「ソースコードから自社でビルドし直す」というアプローチを持っていれば、OSのセキュリティを保ちながら、システムを安全に稼働させ続けることが可能です。