1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@hiroyuki_onodera(小野寺 洋之)inIBM

Db2 Pacemakerクラスターの引き継ぎ時にユーザーアプリケーションも引き継ぐ例

1
Posted at

概要

db2cmコマンドを用いて構築する IBM Db2 Pacemakerクラスター構成では、Db2およびサービスアドレス(仮想IP)、関連ディスク資源以外を引き継ぐことができません。
そのため、Db2の引き継ぎ時に、他のユーザーアプリケーションも同時に引き継ぎを行なう要件がある場合には、対応方法を検討する必要があります。
ここでは、ip コマンドの監視機能を用いて、リアルタイムでサービスアドレスの付け替えを監視し、ユーザーアプリケーションの自動起動・停止を実現する例を説明します。

システム構成

前提条件

  • Linux上で db2cm（Db2 Cluster Manager）により構成された Pacemaker構成 (HADR構成、もしくはディスク引き継ぎ構成)
  • サービスアドレス（仮想IP）がフェイルオーバー時に移動
  • iproute (RHEL), iproute2 (SUSE)パッケージ

動作フロー

通常運用時（Node 1がPrimary）

1. Node 1: Db2 Primary + VIP (192.168.1.100)
   └─ IP Event Handler: VIP検知 → Application起動

2. Node 2: Db2 Standby
   └─ IP Event Handler: VIP未検知 → Application停止

フェイルオーバー時

1. db2cmがフェイルオーバーを検知
   ↓
2. Node 1からVIPを削除
   └─ IP Event Handler: VIP削除検知 → Application停止
   ↓
3. Node 2にVIPを追加
   └─ IP Event Handler: VIP追加検知 → Application起動
   ↓
4. Node 2がPrimaryに昇格完了

デプロイされるシステム構成

IP Event Handler構成

各ノードには以下をデプロイします：

コンポーネント パス 説明
systemdサービス /etc/systemd/system/ip-event-handler.service
メイン監視スクリプト /usr/local/bin/ip_event_handler.sh VIP変更を監視
設定ファイル /etc/ip_event_handler.conf 監視設定
ログファイル /var/log/ip_event_handler.log 動作ログ

構成手順

以下の手順で、両ノードにIP Event Handlerを構成します。

1. メイン監視スクリプトの配置

/usr/local/bin/ip_event_handler.shを作成します：

sudo vi /usr/local/bin/ip_event_handler.sh

スクリプトの内容は後述の「メイン監視スクリプト」セクションを参照してください。

実行権限を付与：

sudo chmod 755 /usr/local/bin/ip_event_handler.sh

2. 設定ファイルの作成

/etc/ip_event_handler.confを作成します：

sudo vi /etc/ip_event_handler.conf

設定内容（後述の「設定ファイルの内容」セクションを参照）：

INTERFACE="eth0"
TARGET_IP="192.168.1.100"
LOG_FILE="/var/log/ip_event_handler.log"
START_SCRIPT="systemctl start myapp.service"
STOP_SCRIPT="systemctl stop myapp.service"

権限設定：

sudo chmod 600 /etc/ip_event_handler.conf
sudo chown root:root /etc/ip_event_handler.conf

3. systemdサービスの登録

/etc/systemd/system/ip-event-handler.serviceを作成します：

sudo vi /etc/systemd/system/ip-event-handler.service

サービス定義の内容は後述の「systemdサービス定義」セクションを参照してください。

4. systemdサービスの有効化と起動

# systemdに新しいサービスを認識させる
sudo systemctl daemon-reload

# サービスを有効化（システム起動時に自動起動）
sudo systemctl enable ip-event-handler

# サービスを起動
sudo systemctl start ip-event-handler

# サービスの状態確認
sudo systemctl status ip-event-handler

期待される出力:

● ip-event-handler.service - IP Event Handler Service
   Loaded: loaded (/etc/systemd/system/ip-event-handler.service; enabled; vendor preset: disabled)
   Active: active (running) since ...
   Main PID: 12345 (ip_event_handle)

5. ログファイルの確認

# ログファイルの作成を確認
sudo tail -f /var/log/ip_event_handler.log

期待されるログ出力:

2026-06-06 21:33:55 [INFO] === IP Event Handler Script 起動 ===
2026-06-06 21:33:55 [INFO] 設定ファイルを読み込みました: /etc/ip_event_handler.conf
2026-06-06 21:33:55 [INFO] 監視対象: インターフェース=eth0, IP=192.168.1.100
2026-06-06 21:33:55 [INFO] 使用するスクリプト/コマンド: START=systemctl start myapp.service, STOP=systemctl stop myapp.service
2026-06-06 21:33:55 [INFO] IPアドレスの監視を開始します...

6. 両ノードでの構成

重要: 上記の手順1〜5を両方のノードで実行してください。

各ノードで同じ設定を使用しますが、以下の点に注意：

  • INTERFACE: 各ノードのネットワークインターフェース名を確認（ip addr show）
  • TARGET_IP: 両ノードで同じVIPを指定
  • START_SCRIPT/STOP_SCRIPT: 両ノードで同じコマンドを指定

7. 構成の確認

両ノードで以下を確認：

# サービスが起動していることを確認
sudo systemctl is-active ip-event-handler

# サービスが有効化されていることを確認
sudo systemctl is-enabled ip-event-handler

# ログが出力されていることを確認
sudo tail -5 /var/log/ip_event_handler.log

ファイル詳細

設定ファイルの内容

systemdサービス定義

/etc/systemd/system/ip-event-handler.service:

[Unit]
Description=IP Event Handler Service
Documentation=file:///etc/ip_event_handler.conf
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/ip_event_handler.sh /etc/ip_event_handler.conf
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal

# セキュリティ設定
NoNewPrivileges=true
PrivateTmp=true

# 環境変数
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

[Install]
WantedBy=multi-user.target

重要な設定項目:

  • Restart=always: サービスが停止した場合、常に再起動
  • RestartSec=10: 再起動までの待機時間（10秒）
  • After=network-online.target: ネットワーク起動後にサービスを開始
  • 実行ユーザー: User=の指定がないため、デフォルトでroot権限で実行されます

/etc/ip_event_handler.conf:

# 監視対象のネットワークインターフェース
INTERFACE="eth0"

# 監視対象のIPアドレス（仮想IP）
TARGET_IP="192.168.1.100"

# ログファイルのパス
LOG_FILE="/var/log/ip_event_handler.log"

# コマンドを直接指定
START_SCRIPT="systemctl start myapp.service"
STOP_SCRIPT="systemctl stop myapp.service"

START_SCRIPT/STOP_SCRIPTには、スクリプトファイルのパスまたはコマンドラインを直接指定できます。コマンドを直接指定する場合、スクリプトファイルを作成する必要はありません。

この例では、シンプルに、ユーザーアプリケーションはsystemctl管理下で制御される様に設定済みという想定です。
他との連携処理タイミングなど複雑な処理要件がある場合には、スクリプトの利用をご検討ください。

メイン監視スクリプト

/usr/local/bin/ip_event_handler.sh（抜粋）:

#!/bin/bash

# 設定ファイルの読み込み
CONFIG_FILE="${1:-/etc/ip_event_handler.conf}"
source "$CONFIG_FILE"

# IPアドレス変更の監視
monitor_ip_changes() {
    log "IPアドレスの監視を開始します..."
  
    # ip monitorでアドレス変更を監視
    ip monitor address | while read -r line; do
        # 対象のインターフェースとIPアドレスが含まれているか確認
        if echo "$line" | grep -wq "$INTERFACE" && echo "$line" | grep -wq "$TARGET_IP"; then
            if echo "$line" | grep -q "Deleted"; then
                # IP削除時
                log "IPアドレスが削除されました: $TARGET_IP"
                bash -c "$STOP_SCRIPT"
            else
                # IP追加時
                log "IPアドレスが追加されました: $TARGET_IP"
                bash -c "$START_SCRIPT"
            fi
        fi
    done
}

動作の仕組み:

  1. ip monitor addressコマンドでカーネルからIPアドレス変更イベントをリアルタイムで受信
  2. 対象インターフェース（INTERFACE）と対象IP（TARGET_IP）の変更を検知
  3. IP追加時: START_SCRIPTを実行
  4. IP削除時: STOP_SCRIPTを実行

ip monitor addressコマンドについて

ip monitor addressは、Linuxカーネルのnetlinkソケットを使用してIPアドレスの変更をリアルタイムで監視するコマンドです。

特徴:

  • リアルタイム検知: ポーリング不要で、IPアドレスの追加・削除を即座に検知
  • 低オーバーヘッド: カーネルからのイベント通知を受信するだけなので、CPU使用率が極めて低い
  • 信頼性: カーネルレベルの通知なので、イベントの取りこぼしがない

出力例:

# IPアドレス追加時
3: eth0    inet 192.168.1.100/24 scope global eth0
       valid_lft forever preferred_lft forever

# IPアドレス削除時
Deleted 3: eth0    inet 192.168.1.100/24 scope global eth0
       valid_lft forever preferred_lft forever

従来のポーリング方式との比較:

方式 検知速度 CPU使用率 信頼性
ip monitor address < 100ms < 1% 高（イベント駆動）
ポーリング（ip addr show） 1-5秒 5-10% 中（ポーリング間隔に依存）

このため、IP Event Handlerはip monitor addressを使用することで、高速かつ効率的なVIP変更検知を実現しています。

root権限での実行について:

IP Event Handlerサービスは、以下の理由からroot権限で実行されます：

  1. ip monitorコマンドの実行: カーネルのnetlinkソケットへのアクセスにroot権限が必要
  2. systemctl start/stopの実行: 他のサービスを制御するためroot権限が必要
  3. ログファイルへの書き込み: /var/log/ip_event_handler.logへの書き込み権限

このため、ip_event_handler_start.shとip_event_handler_stop.shもroot権限で実行されます。

動作確認

1. IP Event Handlerの状態確認

# 両ノードで実行
sudo systemctl status ip-event-handler

期待される出力:

● ip-event-handler.service - IP Event Handler Service
   Loaded: loaded (/etc/systemd/system/ip-event-handler.service; enabled)
   Active: active (running) since ...

2. 現在のVIP所有者確認

# Node 1で実行
ip addr show eth0 | grep 192.168.1.100

# Node 2で実行
ip addr show eth0 | grep 192.168.1.100

3. アプリケーションサービスの状態確認

# VIPを持つノードで実行
sudo systemctl status myapp.service

4. ログ確認

# IP Event Handlerのログ
sudo tail -f /var/log/ip_event_handler.log

# systemdジャーナル
sudo journalctl -u ip-event-handler -f

# アプリケーションのログ
sudo journalctl -u myapp.service -f

フェイルオーバーテスト

手動フェイルオーバー

# Node 1（Primary）で実行
su - db2inst1
db2 takeover hadr on db MYDB

期待される動作

  1. Node 1（旧Primary）:

    2026-06-06 21:18:28 [INFO] IPアドレスが削除されました: 192.168.1.100
2026-06-06 21:18:28 [INFO] STOP_SCRIPTを実行します
2026-06-06 21:18:28 [STOP] === STOP Script 実行 ===
2026-06-06 21:18:28 [STOP] アプリケーションサービスを停止: myapp.service
2026-06-06 21:18:29 [STOP] SUCCESS: myapp.service が正常に停止しました
2026-06-06 21:18:29 [STOP] STOP処理が完了しました
2026-06-06 21:18:29 [INFO] STOP_SCRIPTの実行に成功しました

  2. Node 2（新Primary）:

    2026-06-06 21:18:30 [INFO] IPアドレスが追加されました: 192.168.1.100
2026-06-06 21:18:30 [INFO] START_SCRIPTを実行します
2026-06-06 21:18:30 [START] === START Script 実行 ===
2026-06-06 21:18:30 [START] アプリケーションサービスを起動: myapp.service
2026-06-06 21:18:31 [START] SUCCESS: myapp.service が正常に起動しました
2026-06-06 21:18:31 [START] START処理が完了しました
2026-06-06 21:18:31 [INFO] START_SCRIPTの実行に成功しました

まとめ

IP コマンドによるアドレス監視により、Db2 HADRクラスタのフェイルオーバーに連動したアプリケーションの自動起動・停止が実現できます。

主な利点:

  • ✅ 自動化されたアプリケーション制御
  • ✅ フェイルオーバー時のダウンタイム最小化
  • ✅ 手動介入不要
  • ✅ systemdによる堅牢なサービス管理
  • ✅ 詳細なログとトラブルシューティング

次のステップ:

  1. 本番環境へのデプロイ前に十分なテストを実施
  2. フェイルオーバーシナリオの検証
  3. 監視とアラートの設定
  4. 運用手順書の作成
1
0
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?