【ZabbixHA】MySQL高可用性構成 性能検証レポート

こんにちは。SCSKで全世界のZabbixが止まらない事を祈っている、小寺です。
Zabbixの6.0から新しくHA機能が実装されています。このHA機能はZabbixServerのサービスのみを冗長化する機能の為、データベースの冗長化が別途必要な状況になっています。
ZabbixにおいてデータベースのI/Oがボトルネックになることが多い点を踏まえ、MySQLを用いてどの冗長化方式がパフォーマンスに優れているか、実機検証を行いました。

1. DRBD 9.0 の構築・設定

DRBD 9系で、Protocol A(非同期)と Protocol C(同期)を検証しました。
それぞれの方式を構築し、fioというツールを用いて速度を計測しました。

DRBD インストール

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
dnf install -y https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm
dnf install -y kmod-drbd9x drbd9x-utils

DRBD 設定ファイル

/etc/drbd.d/res_async.res (非同期)

resource res_async {
    protocol A; 
    device /dev/drbd1;
    disk /dev/nvme1n1;
    meta-disk internal;
    on ip-10-0-2-127 { address 10.0.2.127:7788; }
    on ip-10-0-2-164 { address 10.0.2.164:7788; }
}

/etc/drbd.d/res_sync.res (同期)

resource res_sync {
    protocol C; 
    device /dev/drbd2;
    disk /dev/nvme2n1;
    meta-disk internal;
    on ip-10-0-2-127 { address 10.0.2.127:7789; }
    on ip-10-0-2-164 { address 10.0.2.164:7789; }
}

DRBDの初期化・有効化

# メタデータの作成
drbdadm create-md res_async
drbdadm create-md res_sync

# リソースの有効化
drbdadm up res_async
drbdadm up res_sync

# 片方(Primary側)でのみ実行
drbdadm primary --force res_async
drbdadm primary --force res_sync
mkfs.xfs /dev/drbd1
mkfs.xfs /dev/drbd2

# 両方で実行
mkdir /mnt/async_data
mkdir /mnt/sync_data

# 片方(Primary側)でのみ実行
mount /dev/drbd1 /mnt/async_data
mount /dev/drbd2 /mnt/sync_data

DRBD単体の性能検証 (fio結果)

計測対象 IOPS (Write) 帯域 (BW) 平均レイテンシ 標準比 (維持率)
標準ディスク 1,142 4,568 KiB/s 874.92 µs 100% (基準)
DRBD 非同期 (Prot A) 1,125 4,503 KiB/s 887.10 µs 98.5%(▲1.5%)
DRBD 同期 (Prot C) 1,037 4,150 KiB/s 962.66 µs 90.8%(▲9.2%)

 

2. MySQL 8.0 構築・設定

MySQL設定ファイル (/etc/my.cnf.d/mysql-server.cnf)

[mysqld-nomal]
port = 3306
socket = /tmp/mysql.sock3306
datadir = /var/lib/mysqld

[mysqld-drbd-sync]
port = 3307
socket = /tmp/mysql.sock3307
datadir = /mnt/sync_data/mysqld-drbd-sync

[mysqld-drbd-async]
port = 3308
socket = /tmp/mysql.sock3308
datadir = /mnt/async_data/mysqld-drbd-async

[mysqld-rep-sync]
port = 3309
socket = /tmp/mysql.sock3309
datadir = /var/lib/mysqld-req-sync
log-bin = mysql-bin
server-id = 1
rpl_semi_sync_source_enabled = 1
rpl_semi_sync_source_timeout = 10000

[mysqld-rep-async]
port = 3310
socket = /tmp/mysql.sock3310
datadir = /var/lib/mysqld-req-async
log-bin = mysql-bin
server-id = 1

同期レプリケーション構築 SQL

マスター側 で実行

-- 準同期用プラグインの有効化
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET GLOBAL rpl_semi_sync_source_enabled = 1;

-- レプリケーションユーザーの作成
CREATE USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

-- 現在のログファイル名とポジションを確認
SHOW MASTER STATUS;

スレーブ側 で実行

-- 準同期用プラグインの有効化
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET GLOBAL rpl_semi_sync_replica_enabled = 1;

-- マスターへの接続設定
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='10.0.2.127',
  SOURCE_PORT=3309,
  SOURCE_USER='repl_user',
  SOURCE_PASSWORD='password',
  SOURCE_LOG_FILE='mysql-bin.000001',  -- SHOW MASTER STATUSの結果に合わせる
  SOURCE_LOG_POS=157;                  -- SHOW MASTER STATUSの結果に合わせる

-- レプリケーション開始
START REPLICA;

-- ステータス確認
SHOW REPLICA STATUS\G

非同期レプリケーション構築 SQL

マスター側 で実行

-- レプリケーションユーザーの作成
CREATE USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

-- 現在のログファイル名とポジションを確認
SHOW MASTER STATUS;

スレーブ側 で実行

-- マスターへの接続設定
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='10.0.2.127',
  SOURCE_PORT=3310,
  SOURCE_USER='repl_user',
  SOURCE_PASSWORD='password',
  SOURCE_LOG_FILE='mysql-bin.000001',  -- SHOW MASTER STATUSの結果に合わせる
  SOURCE_LOG_POS=157;                  -- SHOW MASTER STATUSの結果に合わせる

-- レプリケーション開始
START REPLICA;

-- ステータス確認
SHOW REPLICA STATUS\G

3. 性能検証結果 (sysbenchによるTPS計測)

Zabbixのバックエンドとしての実用性を測るため、sysbenchを用いてスループット(TPS:1秒あたりのトランザクション数)を計測しました。さらに、実運用を想定した「DBチューニング後」の数値も比較しています。

構成案 デフォルト (TPS) チューニング後 (TPS) シングル比 (維持率)
シングル構成 637.4 1,505.4 100% (基準)
DRBD (同期) 597.6 1,439.4 95.6%
DRBD (非同期) 610.8 1,463.9 97.2%
MySQL同期(準同期) 521.7 1,384.7 92.0%
MySQL非同期 635.1 1,494.6 99.3%

※チューニングにより、全構成でTPSが約2.3倍〜2.6倍に向上しています。

4. 結論:Zabbix DB冗長化の最適解は?

検証の結果、「いずれの方式を選んでも、性能劣化は極めて軽微である」という心強い結果が得られました。

今回のポイント

  • DRBD同期モードの健闘: ストレージ層で完全に同期しているにもかかわらず、DBレベルでの劣化はわずか4.4%でした。ファイルシステムレベルでの冗長化が必要な場合に非常に有力です。
  • MySQLレプリケーションの安定性: 非同期であればシングル構成と遜色ない性能を発揮します。同期(準同期)でも8%減に留まっており、チューニング次第でさらに差を詰められる「伸び代」を感じさせます。
【小寺流・選定のアドバイス】
性能劣化を過度に心配する必要はありません!「OSを含めた物理故障に備えたいならDRBD」、「DBの論理的な整合性や読み取り分散も考慮したいならMySQLレプリケーション」といったように、運用要件に合わせて柔軟に選択してOKです。

Zabbixを「止まらない監視システム」に育て上げるための参考になれば幸いです!

 

SCSK Plus サポート for Zabbix

★YouTubeに、SCSK Zabbixチャンネルを開設しました!★

★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★

著者について

Zabbixの構築をメインに担当しています。
■資格
 Zabbix認定プロフェッショナル
 AWS Certified Solutions Architect - Professional
 Google Certified Professional - Cloud Architect
 LPIC 303,304 ORACLE MASTER Gold DBA 11g
 CCNA Oracle Certified Java Programmer, Silver SE 7

小寺崇仁をフォローする

クラウドに強いによるエンジニアブログです。

SCSKでは、自社クラウドと3大メガクラウドの強みを活かし、ハイブリッドクラウド/マルチクラウドのソリューションを展開しています。業界の深い理解をもとに、お客様の業務要件に最適なアーキテクチャをご提案いたします。サービスサイトでは、お客様のDX推進をワンストップで支援するサービスの詳細や導入事例を紹介しています。

Zabbixソリューションプロダクト運用・監視
シェアする
タイトルとURLをコピーしました