こんにちは。SCSKで全世界のZabbixが止まらない事を祈っている、小寺です。
Zabbixの6.0から新しくHA機能が実装されています。このHA機能はZabbixServerのサービスのみを冗長化する機能の為、データベースの冗長化が別途必要な状況になっています。
ZabbixにおいてデータベースのI/Oがボトルネックになることが多い点を踏まえ、MySQLを用いてどの冗長化方式がパフォーマンスに優れているか、実機検証を行いました。
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です。
性能劣化を過度に心配する必要はありません!「OSを含めた物理故障に備えたいならDRBD」、「DBの論理的な整合性や読み取り分散も考慮したいならMySQLレプリケーション」といったように、運用要件に合わせて柔軟に選択してOKです。
Zabbixを「止まらない監視システム」に育て上げるための参考になれば幸いです!
SCSK Plus サポート for Zabbix
★YouTubeに、SCSK Zabbixチャンネルを開設しました!★
★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★

