冗長化構成(HA)

Pandora FMS ドキュメント一覧に戻る

クリティカルな環境や高負荷の環境では、負荷を複数のマシンに分散し、Pandora FMS コンポーネントのいずれかに障害が発生した場合でもシステムの稼働状態を維持できるようにする必要があります。

Pandora FMS はモジュール形式で設計されており、他のコンポーネントと連携して動作し、障害が発生したコンポーネントの動作を引き受けられるように設計されています。

明らかにエージェントは冗長化されていません。解決策は、Pandora FMS エージェントが実行中であるかどうかに関係なく重要なシステムを冗長化し、これらのシステムの監視を冗長化することです。

いくつかの場面において、次のような高可用性 (HA) 構成が可能です。

• データサーバ
• ネットワークサーバ、WMI、プラグイン、Web、予測、自動検出など
• データベース
• Pandora FMS Web コンソール

• Pandora FMS データサーバの場合は、Pandora FMS データサーバが設定された (ホスト名とサーバ名が異なる) マシンを 2 台構築する必要があります。
• それぞれのマシンに Tentacle サーバを設定する必要があります。
• 各マシンには異なる IP アドレスがあります。
• 外部バランサーを使用する場合は、エージェントがデータを送信するために接続するための単一の IP アドレスが提供されます。
• エージェントの HA メカニズムを使用する場合は、エージェントの実行ごとにプライマリサーバに接続しようとし、応答がない場合はセカンダリサーバに接続しようとするため (そのように設定されている場合)、データの送信に若干の遅延が発生します。

2 つのデータサーバを使用し、両方でリモートポリシー、コレクション、および設定を処理する場合は、データサーバのすべてのインスタンスがこれらのディレクトリの読み取りと書き込みを行えるように、キーディレクトリを共有する必要があります。コンソールもこれらの共有ディレクトリにアクセスできる必要があります。

• /var/spool/pandora/data_in/conf
• /var/spool/pandora/data_in/collections
• /var/spool/pandora/data_in/md5
• /var/spool/pandora/data_in/netflow
• /var/www/html/pandora_console/attachment
• /var/spool/pandora/data_in/discovery

エンドポイントからは、マスター (メイン) およびバックアップ (運用バックアップ) データサーバを設定でき、データサーバのバランス調整を実行できます。エンドポイント設定ファイル pandora_agent.conf で 次の部分を設定しコメントを外す必要があります。

• secondary_server_ip: セカンダリサーバの IP アドレスを指定します。
• secondary_server_path: セカンダリサーバの XML ファイルを置く場所を指定します。通常は、/var/spool/pandora/data_in です。
• secondary_server_port: セカンダリサーバに XML ファイルを置くためのポート番号を指定します。tentacle では 41121、ssh は 22、ftp は 21 です。
• secondary_transfer_mode: セカンダリサーバに XML を送信するモード (tentacle, ssh, ftp など) を設定します。
• secondary_server_pwd: FTP で送信するためのパスワードを設定します。
• secondary_server_ssl: Tentacle その他でデータを送信するときに、ssl を使うかどうかを yes または no で指定します。
• secondary_server_opts: 転送に必要なその他オプションを設定します。
• secondary_mode: セカンダリサーバのモードを設定します。次のいずれかが設定できます。

1. on_error: メインサーバにデータを送信できなかった場合のみセカンダリサーバにデータ送信します。
2. always: メインサーバに接続できるできないに関わらず、常にセカンダリサーバにもデータを送信します。

複数のサーバに、ネットワーク、WMI、プラグイン、ウェブ、予測サーバを (モニタしたいシステムを見れるよう同じように) それぞれインストールします。複数のサーバは (ネットワーク遅延が同じになるように) 同一セグメントに置く必要があります。

それぞれのサーバはプライマリとして選択できます。それぞれのサーバは、他方がダウンした場合、そのサーバに割り当てられていた全てのモジュールデータの収集を自動的に引き継ぎます。Pandora FMS サーバには、最終接続時間 (サーバの threshold x 2) を確認して、他のサーバがダウンしていることを検知する仕組が実装されています。Pandora FMS サーバが 1台でも稼働していれば、他のサーバのダウンを検出することができます。すべての Pandora FMS サーバがダウンした場合は、検出する手段はありません。

2つのノードのシステムで HA およびロードバランシングを実装する簡単な方法は、それぞれのサーバに 50% ずつモジュールを割り当て、両方のサーバをマスターとして選択します。2つ以上のマスターサーバがあり、3台目がダウンした場合は、1台目のマスターサーバがダウンしたサーバに割り当てられていたモジュールの実行を自分自身に割り当てます。ダウンしたサーバが復旧した場合は、再度モジュールの実行が自動的にプライマリサーバに割り当てられます。

Pandora FMS サーバは、異なる 2つのモードで実行できます。

• マスターモード
• 非マスターモード

もしサーバがダウンすると、処理が止まらないように、そのサーバが持っていたモジュールはマスターサーバで実行されます。

/etc/pandora/pandora_server.conf で master の設定が 0 より大きい値になっているすべてのサーバから、一つのマスターサーバが選択されます。

master [1..7]

もし現在のマスターサーバがダウンすると、新たなマスターサーバが選択されます。複数の候補がある場合は、master の値が最も高いものが選択されます。

例えば、master を 1 に設定した 3台の Pandora FMS サーバがある場合、マスターサーバはランダムに選択され、他の 2台は非マスターモードで動作します。マスターサーバがダウンすると、新たなマスターがランダムに選択されます。

pandora_server.conf に以下のパラメータを設定できます。

• ha_file: HA のテンポラリバイナリファイルの場所
• ha_pid_file: HA の現在のプロセス ID ファイル
• pandora_service_cmd: Pandora サービスの状態制御

データベースで高可用性が有効になっている 場合、より多くの Pandora FMS サーバを MySQL クラスタに接続するには、いくつかの追加設定が必要です。pandora_server.conf ファイル (デフォルトでは /etc/pandora にあります) で、追加する独立した Pandora FMS サーバごとに、次のパラメータを設定する必要があります。

• dbuser: MySQL クラスタへアクセスするためのユーザ名を指定する必要があります。例:

/etc/pandora/pandora_server.conf

dbuser pandora

• dbpass: MySQL クラスタへアクセスするためのユーザのパスワードを指定する必要があります。例:

/etc/pandora/pandora_server.conf

dbpass pandora

• ha_hosts: ha_host パラメータの後に、HA 環境を構成する MySQL サーバの IP アドレスまたは FQDN を設定する必要があります。例:

ha_hosts 192.168.80.170,192.168.80.172

他のサーバにコンソールをインストールするだけです。それらのいずれからも、異なるユーザによって異なる場所から同時に使用することができます。 コンソールの前段でロードバランサを使用すると、セッションシステムが「クッキー」によって管理され、これがブラウザーに保管されるため、どちらがアクセスされているかを実際に知らなくてもアクセスできます。

リモート設定を使用する場合、双方のデータサーバとコンソールは、データ入力ディレクトリ (デフォルト: /var/spool/pandora/data_in) 配下の configuration、collections その他を共有する必要があります。("セキュリティアーキテクチャ" も参照ください。)

• /var/spool/pandora/data_in/conf
• /var/spool/pandora/data_in/collections
• /var/spool/pandora/data_in/md5
• /var/spool/pandora/data_in/netflow
• /var/www/html/pandora_console/attachment
• /var/spool/pandora/data_in/discovery

HA 環境で Pandora FMS コンソールを更新する場合、管理(Management) → ワープアップデート(Warp update) → オフラインアップデート を介して OUM を使用して更新するときは、次の点に留意する必要があります。

共有データベースを使用するバランシング環境では、最初のコンソールを更新すると、対応する変更がデータベースに適用されます。 これは、セカンダリのコンソールを更新しようとすると、データベースがすでに更新されているため、Pandora FMS がエラーメッセージを表示することになります。 ただし、コンソールの更新は引き続き実行されます。

新しい Pandora FMS HA ソリューションは、製品 (pandora_ha バイナリ内) に統合されています。 Corosync/Pacemaker では実現不可能な、異なる IP 範囲を持つ地理的に分離されたサイトをサポートする HA を実装しています。

新しい HA モデルでは、通常のセットアップは 2 つのペアであり、クォーラムシステムを実装しない設計となっており、設定と必要なリソースが簡素化されています。 これにより、監視システムは利用可能な DB ノードがある限り機能し、DB スプリットブレインが発生している場合は、システムは両方のノードが再びマージされるまで並行して機能します。

新しい仕組では、現在の 3 つの問題を解決しようとしています。

1. 現在のシステムの複雑さと保守性 (バージョン NG 770 まで)。
2. ローカル以外のネットワークセグメントの利用で、HA 環境が地理的に異なる場所に分散している場合。
3. 地理的に離れた 2 つのサイト間で通信障害が発生した場合のスプリットブレインおよび安全なシステム運用のデータ復旧。

DB 用の新しい HA システムは Percona8 を用いて実装されていますが、将来のバージョンでは MySQL/MariaDB 8 でも実装する方法を詳しく説明します。

Pandora FMS は、MySQL データベースを用いて設定およびデータを保存するため、データベースに障害が発生すると監視ツールが一時的に麻痺する可能性があります。 Pandora FMS の高可用性データベースクラスタにより、強力でフェイルセーフなアーキテクチャを簡単に展開できます。

バイナリレプリケーション MySQL クラスタノードは、バージョン 770 以降、pandora_ha バイナリで管理されます。 Percona は、そのスケーラビリティ、可用性、セキュリティ、およびバックアップ機能により、デフォルトの RDBMS として選択されました。

アクティブ/スタンバイレプリケーション は、単一のマスターノード (書き込み権限あり) から任意の数のセカンダリ (読み取りのみ）に対して行われます。マスターノードに障害が発生した場合、セカンダリの 1 つがマスターにアップグレードされ、pandora_ha がマスターノードの IP アドレスを更新します。

環境は次の要素で構成されます。

• バイナリレプリケーションが有効になっている MySQL8 サーバ (アクティブ - スタンバイ)。
• クラスタの正しい動作に必要なスレーブ - マスターおよびマスター - スレーブの継続的な監視の実施および昇格を実行するための、すべての MySQL サーバの設定を持つ pandora_ha を含むサーバ。

最初に、後で Percona サーバパッケージをインストールできるように、環境のすべてのノードに Percona リポジトリをインストールする必要があります。

関連するすべてのデバイスで実行します:

yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm

すべてのデバイスで Percona リポジトリのバージョン 8 を有効にします:

percona-release setup ps80

両方の環境を手動で同期するためのバックアップツールと Percona サーバをインストールします。 関連する すべて のデバイスで実行します:

yum install percona-server-server percona-xtrabackup-80

curl -Ls https://pfms.me/deploy-pandora-el8 | env MYVER=80 bash

すべて のデバイスに Percona リポジトリ バージョン 8 をインストールします。

curl -O https://repo.percona.com/apt/percona-release_latest.generic_all.deb
apt install -y gnupg2 lsb-release ./percona-release_latest.generic_all.deb

すべて のデバイスで Percona リポジトリ バージョン 8 を有効化します:

percona-release setup ps80

両方の環境を手動で同期するためのバックアップツールと Percona サーバをインストールします。 すべて のデバイスで以下を実行します:

apt install -y percona-server-server percona-xtrabackup-80

このガイドの手順を両方の HA ノードで実行する必要があるユーザはシステム rootユーザであるため、対応する権限昇格が実行されていることを必ず確認してください。

HA を構成するノード間には、SSH（ポート番号 22）による接続が必要であり、また、それらの MySQL サーバ間（3306）にも接続が必要です。

同様に、マシン間では分かりやすいホスト名と DNS 解決を使用することが推奨されます。

2台のデータサーバを使用し、両方でポリシー、コレクション、リモート設定を処理する場合は、すべてのデータサーバインスタンスがこれらのディレクトリを読み書きできるように、キーディレクトリを共有する必要があります。コンソールもこれらの共有ディレクトリにアクセスできる必要があります。たとえば、NFS 経由で共有する場合：

/var/spool/pandora/data_in/conf
/var/spool/pandora/data_in/collections
/var/spool/pandora/data_in/md5
/var/spool/pandora/data_in/netflow
/var/www/html/pandora_console/attachment
/var/spool/pandora/data_in/discovery

MOTD およびバナーのクリーンアップ。

Rocky Linux 9 の場合:

[ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild
cp -a /etc/ssh/sshd_config{,.bak-$(date +%F)}
sed -i -e 's/^Banner.*/#Banner none/g' /etc/ssh/sshd_config
sed -i 's/^\s*session\s\+optional\s\+pam_motd\.so/#&/' /etc/pam.d/sshd
systemctl restart sshd

Ubuntu 22.04 の場合:

cp -a /etc/pam.d/sshd{,.bak-$(date +%F)}
sed -i 's/^session\s\+optional\s\+pam_motd.so/# &/' /etc/pam.d/sshd
chmod -x /etc/update-motd.d/*
systemctl restart sshd

a) パスフレーズなしの RSA 鍵生成:

printf "\n\n\n" | ssh-keygen -t rsa -P ''

b) アイデンティティコピー（双方向）：

ssh-copy-id -p22 root@pandoraha1
ssh-copy-id -p22 root@pandoraha2

c) SSH接続（双方向）でパスワードを要求されないことを確認します。

ssh pandoraha1
ssh pandoraha2

MySQL コンソールにアクセスします。

mysql -u root -p pandora
# Password by default: Pandor4!

以下の SQL クエリを実行します。

UNINSTALL COMPONENT 'file://component_validate_password';
CREATE USER replicationuser@'%' IDENTIFIED WITH mysql_native_password BY 'pandora';
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO replicationuser@'%';
CREATE USER root@'%' IDENTIFIED WITH mysql_native_password BY 'Pandor4!';
GRANT ALL PRIVILEGES ON *.* TO root@'%';
CREATE USER pandora@'%' IDENTIFIED WITH mysql_native_password BY 'pandora';
GRANT ALL PRIVILEGES ON pandora.* TO pandora@'%';
FLUSH PRIVILEGES;
EXIT;

バイナリレプリケーション設定

クラスター内のすべてのノードに MySQL サーバがインストールされたら、両方の環境で設定を行い、それらが複製されるようにします。

まず最初に、my.cnf ファイルを設定し、バイナリレプリケーションが正しく動作するように準備する必要があります。

ノード 1

ノード 1 /etc/my.cnf (Ubuntu サーバでは /etc/mysql/my.cnf):

[mysqld]
server_id=1 # It is important that it is different in all nodes.
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
# OPTIMIZATION FOR PANDORA FMS
innodb_buffer_pool_size = 4096M
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
thread_cache_size = 8
max_connections = 200
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
sql_mode=""
# SPECIFIC PARAMETERS FOR BINARY REPLICATION
binlog-do-db=pandora
replicate-do-db=pandora
max_binlog_size = 100M
binlog-format=ROW
binlog_expire_logs_seconds=172800 # 2 DAYS
#log-bin=/path                     # Uncomment for adding an additional storage path for binlogs and setting a new path
#log-bin-index=/path/archive.index # Uncomment for adding an additional storage path for binlogs and setting a new path
sync_source_info=1
sync_binlog=1
port=3306
report-port=3306
report-host=master
gtid-mode=off
enforce-gtid-consistency=off
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync_relay_log = 0
replica_compressed_protocol = 1
replica_parallel_workers = 1
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 1800

[client]
user=root
password=pandora

• OPTIMIZATION FOR PANDORA FMS コメントに続く トークン は、Pandora FMS の最適化された設定を実行します。
• SPECIFIC PARAMETERS FOR BINARY REPLICATION コメントの後には、バイナリレプリケーションの特定パラメータが設定されます。
• binlog_expire_logs_seconds という トークン は、2 日間有効です。
• [client] サブセクションには、データベースで使用するユーザー名とパスワードを入力します。デフォルトでは、PFMS のインストール時にそれぞれ root と pandora になります。これらの値は、ユーザを指定せずにバックアップを作成する (自動) ために 必要 です。

ノード 2

ノード 2 /etc/my.cnf (Ubuntu サーバでは /etc/mysql/my.cnf):

[mysqld]
server_id=2 # It is important that it is different in all nodes.
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
# OPTIMIZATION FOR PANDORA FMS
innodb_buffer_pool_size = 4096M
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
thread_cache_size = 8
max_connections = 200
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
sql_mode=""
# SPECIFIC PARAMETERS FOR BINARY REPLICATION
binlog-do-db=pandora
replicate-do-db=pandora
max_binlog_size = 100M
binlog-format=ROW
binlog_expire_logs_seconds=172800 # 2 DAYS
#log-bin=/path                     # Uncomment for adding an additional storage path for binlogs and setting a new path
#log-bin-index=/path/archive.index # Uncomment for adding an additional storage path for binlogs and setting a new path
sync_source_info=1
sync_binlog=1
port=3306
report-port=3306
report-host=master
gtid-mode=off
enforce-gtid-consistency=off
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync_relay_log = 0
replica_compressed_protocol = 1
replica_parallel_workers = 1
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 1800

[client]
user=root
password=pandora

• OPTIMIZATION FOR PANDORA FMS コメントに続く トークン は、Pandora FMS の最適化された設定を実行します。
• SPECIFIC PARAMETERS FOR BINARY REPLICATION コメントの後には、バイナリレプリケーションの特定パラメータが設定されます。
• binlog_expire_logs_seconds という トークン は、2 日間有効です。
• [client] サブセクションには、データベースで使用するユーザー名とパスワードを入力します。デフォルトでは、PFMS のインストール時にそれぞれ root と pandora になります。これらの値は、ユーザを指定せずにバックアップを作成する (自動) ために 必要 です。

変更を有効にするには、MySQL を再起動する必要があります。

両方のノードで実行

Rocky Linux 9 の場合:

systemctl restart mysqld

Ubuntu Server 22.04 の場合:

systemctl restart mysql

データベースの複製作成：次のステップは、マスターデータベース（MASTER）をスレーブノード（SLAVE）に複製することです。これを行うには、次の手順に従ってください。

1.- MASTER データベースの完全ダウンロード（dump）を実行します。

MASTER #

xtrabackup --backup --target-dir=/root/pandoradb.bak/

MASTER #

xtrabackup --prepare --target-dir=/root/pandoradb.bak/

2.- バックアップからバイナリ log の位置を取得します。

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

以下のような結果が返されます。

binlog.000003 157

これらの 2つの値はステップ 6で必要となるため、メモしておいてください。

スレーブサーバ上の MySQL サービスを停止します。

Rocky Linux 9 の場合:

systemctl stop mysqld

Ubuntu Server 22.04 の場合:

systemctl stop mysql

すべてのコンテンツを削除（デフォルトDBを削除）：

rm -rf /var/lib/mysql/*

問題を回避するため、両方のノードで pandora_ha サービスも停止します。

systemctl stop pandora_ha

3.- rsync を使用して SLAVE サーバにバックアップを送信するためのコピーを作成します。

MASTER # rsync -avpP -e ssh /root/pandoradb.bak/ pandoraha2:/var/lib/mysql/

4.- スレーブサーバで、MySQL サーバが送信されたファイルにシームレスにアクセスできるように権限を設定します。

SLAVE # chown -R mysql:mysql /var/lib/mysql

SLAVE # chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql

5.- スレーブサーバで mysql サービスを開始します。

systemctl start mysqld

6.- このサーバでスレーブモードを開始します（手順2でメモしたデータを使用します）。

SLAVE # mysql -u root -ppandora

SLAVE # mysql > reset slave all;

SLAVE # mysql >

CHANGE MASTER TO MASTER_HOST='pandoraha1',
 MASTER_USER='replicationuser',
 MASTER_PASSWORD='pandora',
 MASTER_LOG_FILE='binlog.000003',
 MASTER_LOG_POS=157;

SLAVE # mysql > start slave;

SLAVE # mysql > SET GLOBAL read_only=1;

これらの手順をすべて完了したら、MySQL シェル内で show slave status コマンドを実行すると、ノードがスレーブモードになっていることがわかります。正しく設定されていれば、次のような出力が表示されます。

*************************** 1. row ***************************
Slave_IO_State: Waiting for source to send event
Master_Host: pandoraha1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000018
Read_Master_Log_Pos: 1135140
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 1135306
Relay_Master_Log_File: binlog.000018
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: pandora
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1135140
Relay_Log_Space: 1135519
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: fa99f1d6-b76a-11ed-9bc1-000c29cbc108
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Replica has read all relay log; waiting for more
updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set, 1 warning (0,00 sec)

MySQL 8.4 の場合、コマンドは若干異なります。

sudo mysql -u root

CHANGE REPLICATION SOURCE TO
SOURCE_HOST='pandoraha1', -- Enter the IP or dns address of your MASTER MySQL server
SOURCE_USER='replicationuser', -- Enter the replication username
SOURCE_PASSWORD='pandora', -- Enter the replication password
SOURCE_LOG_FILE='binlog.000003', -- Update to the values retrieved on previous step
SOURCE_LOG_POS=157 -- Update to the values retrieved on previous step
;

レプリカを起動し、すべてが正しいことを確認します。

STOP REPLICA;
 
START REPLICA;
SHOW REPLICA STATUS\G

show slave status コマンドを実行し、その出力を確認することで、レプリカが正しいことを検証します。

      Replica_IO_Running: Yes
      Replica_SQL_Running: Yes

両方とも Yes になっている必要があります。

この時点から、バイナリレプリケーションが有効になり、正しく動作していると想定できます。

pandora_ha が正しく機能するために必要な一連のパラメータを、pandora_server.conf ファイル内で設定する必要があります。

追加するパラメータは以下のとおりです。

• ha_hosts <IP_ADDRESS1>,<IP_ADDRESS2>:

ha_host パラメータを設定した後、HA 環境を構成する MySQL サーバの IP アドレスまたは FQDN を指定する必要があります。最初に指定された IP アドレスが MASTER サーバとして優先的に使用されるか、少なくとも HA 環境が最初に起動されたときにマスターの役割を持ちます。例：

ha_hosts 192.168.80.170,192.168.80.172

• ha_dbuser および ha_dbpass:

これらは、root ユーザとパスワードを指定するパラメータです。それができない場合は、ノード上のすべてのマスター/スレーブ昇格操作の実行を監視する最大権限を持つ MySQL ユーザを指定します。例:

ha_dbuser root
ha_dbpass pandora

• repl_dbuser および repl_dbpass:

SLAVE が MASTER に接続するために使用するレプリケーションユーザを定義するパラメータ。例：

repl_dbuser replicationuser
repl_dbpass pandora

• ha_sshuser および ha_sshport:

リカバリ操作を実行するために、ssh 経由で Percona/MySQL サーバに接続するユーザ/ポートを定義するパラメータ。このオプションが正しく機能するには、pandora_ha サービスを実行しているユーザと ha_sshuser パラメータで指定されたユーザの間で ssh キーを共有する必要があります。例:

ha_sshuser root
ha_sshport 22

• ha_resyncPATH_SCRIPT_RESYNC:

デフォルトでは、ノードを再同期するためのスクリプトは次の場所にあります。

/usr/share/pandora_server/util/pandora_ha_resync_slave.sh

スクリプト をカスタムインストールしている場合は、このパラメーターでその場所を指定してください。そうすることで、SLAVE ノードの自動または手動同期が必要に応じて実行されます。

ha_resync /usr/share/pandora_server/util/pandora_ha_resync_slave.sh

• ha_resync_log:

前のトークンで設定されたスクリプトによって実行されたすべての情報を保存するログファイルのパス。例:

ha_resync_log /var/log/pandoraha_resync.log

• ha_connect_retries:

環境に変更を加える前に、各 HA 環境サーバでの各チェックで実行される再試行の数。例：

ha_connect_retries 2

これらのパラメータをすべて設定したら、pandora_ha サービスを使用してPandora FMS サーバを起動できます。サーバは環境イメージを取得し、その時点でどのサーバが MASTER サーバであるかを認識します。

システムがそれを認識すると、/var/spool/pandora/data_in/conf/ フォルダーに pandora_ha_hosts.conf ファイルを作成し、常に MASTER ロールを持つ Percona/MySQL サーバを指定します。

pandora_server.conf ファイルの incomingdir パラメータに別のパス（PATH）が指定されている場合、このファイルはそのパスに配置されます。

このファイルは、Pandora FMS Console とのやり取りに使用され、MASTER ロールを持つ Percona/MySQL サーバの IP アドレスを常に把握できるようにします。

• restart:

pandora_ha デーモン が障害発生時にサービスを再起動する役割を担っているため、競合が発生する可能性があり、その場合は 0 という値で示されます。例:

# Pandora FMS will restart after restart_delay seconds on critical errors.
restart 0

• ha_backup_source_dir:

HA バックアップデータが格納されるディレクトリ。デフォルト値: /var/tmp。

• ha_mysql_source_dir:

MySQL データが格納されているディレクトリ。デフォルト値: /var/lib。

設定ファイルに変更を加えたら、両方のノードで pandora_ha を起動します。

systemctl start pandora_ha

コンソールの config.php ファイルは、以下にあります。

/var/www/html/pandora_console/include/

以下の値を追加して設定する必要があります。

$config["remote_config"] = "/var/spool/pandora/data_in";

見た目は以下のようになります。

これにより、Pandora FMS はファイルを読み込みます。

/var/spool/pandora/data_in/conf/pandora_ha_hosts.conf

接続に必要な IP アドレスはそこから取得されます。

Pandora FMS がデフォルトで使用する交換ディレクトリのパスを示す新しいパラメータが config.php 設定に追加されました。デフォルトでは /var/spool/pandora/data_in です。

設定されている場合、接続に必要な IP アドレスを取得するために、ファイル /var/spool/pandora/data_in/conf/pandora_ha_hosts.conf を検索します。

$config["remote_config"] = "/var/spool/pandora/data_in";

Pandora FMS コンソールでは、HA 管理画面にアクセスすることでクラスタの状態を確認できます。

https://PANDORA_IP/pandora_console/index.php?sec=gservers&sec2=enterprise/godmode/servers/HA_cluster

この画面のデータは pandora_ha により常に更新されます。前のセクションで説明したパラメータを使用して pandora_server.conf が正しく設定されていれば、このセクションを表示するために事前の設定手順は必要ありません。

利用可能なアクションの中には、各ノードのラベルを設定したり、アイコンを使用して SLAVE ノードを同期するオプションを実行したりすることができます。

このアイコンには、以下の状態があります。

• 緑: 正常、実行すべき操作はありません。
• 青: 再同期待ち。
• 黄: 再同期を実行中。
• 赤: エラー、再同期に失敗。

上記の手順を完了したら、HA 管理画面にアクセスしてクラスタの状態を確認できます。

https://PANDORA_IP/pandora_console/index.php?sec=gservers&sec2=enterprise/godmode/servers/new_HA_cluster

そこには、接続とレプリケーションのステータスに関する情報が表示されます。

• IP: クラスタを構成するノードのIPアドレス。
• ノードラベル(Node label): ノードに設定可能な識別ラベル。
• SQL ノードステータス(SQL Node status): MySQLサービスのステータス。
• SSH: SSH接続ステータス。
• レプリケーションステータス(Replication Status): レプリケーションステータス。
• DB ロール(DB Role): クラスタを構成するノードにおけるマスターを識別するためのロール。
• 遅延(Delay): 遅延時間 マスター以外のノードがDBの変更を受信するまでの時間。
• 最終更新(Last Update): 最終更新時刻。
• SQL バージョン(SQL version): インストールされている MySQL のバージョン。
• DB バージョン(DB version): Pandora FMS データベースにインストールされているスキーマのバージョン。

HA 画面の最後の列には、実行可能なさまざまなアクションが表示されます。

• ノードラベル(Node label) フィールドを編集するために使用します。
• スレーブノードを無効化/有効化するために使用します。
• コンソールから再同期を開始するために使用し、以下のステータスを持つことができます。

1. 緑: 正常、実行すべき操作はありません。
2. 青: 再同期待ち。
3. 黄: 再同期を実行中。
4. 赤: エラー、再同期に失敗。

同期スクリプトの使用: Pandora FMS サーバでは、SLAVE データベースが同期されていない場合に同期できるようにするスクリプトが実装されています。

このスクリプトの手動実行方法は以下のとおりです。

./pandora_ha_resync_slave.sh "pandora_server.conf file" MASTER SLAVE

たとえば、ノード 1 をノード 2 に手動で同期するには、実行は次のようになります。

/usr/share/pandora_server/util/pandora_ha_resync_slave.sh \ 
 /etc/pandora/pandora_server.conf \ 
 pandoraha1 \ 
 pandoraha2

MASTER と SLAVE 間で同期の問題が発生した場合にHA環境の自動復旧を設定するには、サーバ設定ファイル（/etc/pandora/pandora_server.conf）内の splitbrain_autofix 設定トークンを 1 に設定する必要があります。

したがって、スプリットブレインが発生するたび（両方のサーバがマスターの役割を持っている場合）、または MASTERノードと SLAVE ノード間で同期の問題が発生するたびに、pandora_ha は pandora_ha_resync_slave.sh スクリプトを起動して、その時点からスレーブサーバ上で MASTER サーバの状態を同期しようとします。

この処理は、開始、終了、およびエラーが発生したかどうかを示すイベントをシステム内に生成します。

MySQL/Percona サーババージョン 5 で使用されている HA 環境と現在の HA モードの主な違いは、pandora_ha がクラスタノードの管理に使用されるようになったため、Corosync-Pacemaker は使用されなくなった点です。

環境の移行は次のようにできます。

1.- Percona のバージョン 5.7 からバージョン 8.0 へのアップグレード: “MySQL 8 のインストールとアップグレード”

2.- すべてのデバイスで xtrabackup-80 のインストール:

yum install percona-xtrabackup-80

Ubuntu server を利用している場合は、“Ubuntu server への Percona 8 のインストール” を参照してください。

3.- MASTER ノードで mysql_native_password トークンを指定しての全ユーザの再作成:

mysql > CREATE USER replicationuser@% IDENTIFIED WITH mysql_native_password BY 'pandora';

mysql > GRANT REPLICATION CLIENT, REPLICATION SLAVE on *.* to replicationuser@%;

mysql > CREATE USER pandora@% IDENTIFIED WITH mysql_native_password BY 'pandora';

mysql > grant all privileges on pandora.* to pandora@%;

4.- MASTER ノードでのデータベースのダンプと SLAVE ノードへの適用:

4.1.- MASTER データベースのフルダンプの取得:

MASTER #

xtrabackup --backup --target-dir=/root/pandoradb.bak/

MASTER #

xtrabackup --prepare --target-dir=/root/pandoradb.bak/

4.2.- バイナリログポジションの取得:

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

binlog.000003 157

4.6 の手順で必要になるため、この値はメモしておきます。

4.3.- バックアップを SLAVE サーバへ送るための rsync を使った同期。

SLAVE # rm -rf /var/lib/mysql/*

MASTER # rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/

4.4- SLAVE サーバにて、MySQL サーバが送信したファイルに問題なくアクセスできるようにするためのパーミッションの設定。

SLAVE # chown -R mysql:mysql /var/lib/mysql

SLAVE # chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql

4.5.- SLAVE サーバでの mysqld サービスの開始。

systemctl start mysqld

4.6.- このサーバで SLAVE モードを開始(4.2 の手順のデータを使います)。

SLAVE # mysql -u root -ppandora

SLAVE # mysql > reset slave all;

SLAVE # mysql >

CHANGE MASTER TO MASTER_HOST='nodo1',
MASTER_USER='slaveuser', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='binlog.000003', MASTER_LOG_POS=157;

SLAVE # mysql > start slave;

SLAVE # mysql > SET GLOBAL read_only=1;

新しいサーバにゼロから環境を構築して移行したい場合は、新しい環境を構築したあとに Pandora FMS データベースを作成するステップで古い環境のデータベースのバックアップをインポートする必要があります。

同時に、前述の Pandora FMS コンソールとサーバの設定を新しい環境に行う必要があります。

高いレイテンシー、ネットワークの停止など、いくつかの要因により、両方の MySQL サーバがマスターになり、かつ、サーバ自体がマスターとして機能するサーバを選択してマスターノードからスレーブへ同期を行う pandora_ha での autoresync オプションが有効になっていない場合があります。その際、サーバで収集されるデータをすべて失う可能性があります。

この問題を解決するには、次の手順でデータをマージすることができます。

スプリットブレイン発生中に新しいエージェントが作成された場合、または新しい設定情報（アラート、ポリシーなど）がある場合、これらは考慮されません。取得されるのはデータとイベントのみです。つまり、tagente_datos、tagente_datos_string、tevento テーブル に関するデータです。

以下のコマンドは、切断されたノード（SLAVE に変更するノード）で実行します。yyyy-mm-dd hh:mm:ss はスプリットブレイン開始日時、 yyyy2-mm2-dd2 hh2:mm2:ss2 は終了日時です。

適切なユーザー権限で mysqldump コマンドを実行し、データダンプ（データダンプまたは単にダンプ）を取得します：

mysqldump -u root -p -n -t --skip-create-options --databases pandora --tables tagente_datos --where='FROM_UNIXTIME(utimestamp)> "yyyy-mm-dd hh:mm:ss" AND FROM_UNIXTIME(utimestamp) <"yyyy2-mm2-dd2 hh2:mm2:ss2"'> tagente_datos.dump.sql

mysqldump -u root -p -n -t --skip-create-options --databases pandora --tables tagente_datos_string --where='FROM_UNIXTIME(utimestamp)> "yyyy-mm-dd hh:mm:ss" AND FROM_UNIXTIME(utimestamp) <"yyyy2-mm2-dd2 hh2:mm2:ss2"'> tagente_datos_string.dump.sql

mysqldump -u root -p -n -t --skip-create-options --databases pandora --tables tevento --where='FROM_UNIXTIME(utimestamp)> "yyyy-mm-dd hh:mm:ss" AND FROM_UNIXTIME(utimestamp) <"yyyy2-mm2-dd2 hh2:mm2:ss2"' | sed -e "s/([0-9]*,/(NULL,/gi"> tevento.dump.sql

これらのテーブルのダンプを取得したら、MASTER ノードにデータをロードします。

MASTER # cat tagente_datos.dump.sql | mysql -u root -p pandora

MASTER # cat tagente_datos_string.dump.sql | mysql -u root -p pandora

MASTER # cat tagente_evento.dump.sql | mysql -u root -p pandora

SLAVE へ変更するノードから取得したデータをロードした後、以下の手順で同期を進めていきます：

1.- マスター DB の全体のダンプを取得します:

MASTER #

xtrabackup --backup --target-dir=/root/pandoradb.bak/

MASTER #

xtrabackup --prepare --target-dir=/root/pandoradb.bak/

2.- バックアップデータのバイナリログポジションを取得します:

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

次のような出力があります(値はメモしておきます):

binlog.000003   157

3.- rsync コマンドで、バックアップをスレーブサーバへ送ります:

MASTER # rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/

4.- スレーブサーバでは、MySQL サーバが正しくファイルにアクセスできるようにパーミッションを調整します。

SLAVE # chown -R mysql:mysql /var/lib/mysql

SLAVE # chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql

5.- スレーブサーバで mysqld サービスを開始します。

systemctl start mysqld

6.- このサーバでスレーブモードを開始します。

SLAVE # mysql -u root -ppandora

SLAVE # mysql > reset slave all;

SLAVE # mysql > CHANGE MASTER TO MASTER_HOST='nodo1', MASTER_USER='slaveuser', MASTER_PASSWORD='pandora', MASTER_LOG_FILE='binlog.000003', MASTER_LOG_POS=157;

SLAVE # mysql > start slave;

SLAVE # mysql > SET GLOBAL read_only=1;

これらの手順がすべて完了したら、MySQL シェル内で show slave status コマンドを実行すると、ノードがスレーブモードであることが確認できます。正しく設定されていれば、次の例のような出力が表示されるはずです：

*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: pandoraha1
                  Master_User: root
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000018
          Read_Master_Log_Pos: 1135140
               Relay_Log_File: relay-bin.000002
                Relay_Log_Pos: 1135306
        Relay_Master_Log_File: binlog.000018
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: pandora
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1135140
              Relay_Log_Space: 1135519
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
                  Master_UUID: fa99f1d6-b76a-11ed-9bc1-000c29cbc108
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
       Master_public_key_path:
        Get_master_public_key: 0
            Network_Namespace:
1 row in set, 1 warning (0,00 sec)

Pandora FMS ドキュメント一覧に戻る