冗長化構成(HA)

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

Pandora FMS はとても安定したアプリケーションになっています。(みなさんのテストのおかげで、それぞれのバージョンでは拡張が行われ、数百の不具合が報告され、修正されてきました。) しかし、クリティカルや高負荷な環境では、複数のサーバに処理を分散させることが可能です。Pandora FMS では、いずれかのコンポーネントで障害が発生しても、システム自体はダウンしません。

Pandora FMS は、細かいモジュールで設計されています。それぞれのモジュールは、独立して動作することができます。しかし、それぞれはまた、連携して動作することができ、負荷を分配することができます。

Pandora FMS の基本設計を以下に示します。

もちろん、エージェントは冗長化構成ではありません。エージェントがダウンすると、モジュールの実行ができず、また、複数のエージェントを平行して実行することはできないため、またはシステム自体がダウンしているため、そのエージェントの全てのデータ収集はできなくなります。 重要なシステムに対する最良の解決策は、Pandora FMS エージェントのある無しに関わらず、冗長化しモニタリングすることです。

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

• データサーバのバランシングと HA
• ネットワーク、WMI、プラグイン、Web および予測サーバのバランシングと HA
• データベースのロードバランシング
• 自動検出サーバのバランシングと HA
• Pandora FMS コンソールのバランシングと HA

最も簡単な方法は、エージェントに実装されている HA を使用することです(プライマリが応答しない場合は代替サーバーに接続できます)。 ただし、データサーバはポート 41121 をサポートし、標準の TCP ポートであるため、通常の TCP サービスのバランシングまたはクラスタリングを可能にする商用ソリューションを使用することができます。

Pandora FMS データサーバでは、(異なるホスト名およびサーバ名で)設定された 2つの Pandora FMS データサーバを利用する必要があります。それぞれに tentacle サーバーを設定する必要があります。 各マシンは異なる IP アドレスを持ちます。 外部バランサを使用する場合、バランサにエージェントからのデータ送信用の接続 IP アドレス(VIP)を割り当てます。

外部バランサを使用していて、いずれかのサーバが故障した場合、アクティブなサーバにのみ接続するようになります。Pandora FMS エージェントは変更に気付くことなく、これまでと同様のアドレスへ接続します。しかし、この場合は、ロードバランサーは障害が発生したサーバにはデータを送信せず、アクティブな方にのみ送信します。

Pandora FMS データサーバの設定を変更する必要はありません。それぞれのサーバに別々の名前を設定してさえいえれば、サーバの状態ビューでいずれかがダウンしていることがわかり便利です。Pandora FMS データモジュールは、いずれかのサーバで処理することができます。事前のサーバ指定は不要です。簡単に HA 構成がとれるように設計されています。

エージェントの HA メカニズムを使用する場合は、データの送信にわずかな遅延があります。これは、エージェントの実行ごとにプライマリサーバとの接続を試みるためです。応答しない場合 セカンダリに対してこれを行います(設定されている場合)。これについては、次の “ソフトウエアエージェントでのバランシング” で説明します。

2つのデータサーバーを使用し、ポリシー、コレクション、およびリモート構成を管理する場合は、 サーバデータディレクトリの複数 Pandora サーバでの共有 に従って次のディレクトリを共有する必要があります。データサーバのすべてのインスタンスでこれらのディレクトリを読み書きします。 また、コンソールもこれらの共有ディレクトリにアクセスできる必要があります。

• /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 configuration
# ==============================
# If secondary_mode is set to on_error, data files are copied to the secondary
# server only if the primary server fails. If set to always, data files are
# always copied to the secondary server
secondary_mode on_error
secondary_server_ip localhost
secondary_server_path /var/spool/pandora/data_in
secondary_server_port 41121
secondary_transfer_mode tentacle
secondary_server_pwd mypassword
secondary_server_ssl no
secondary_server_opts

There are the following options (for more information, go to the Agent configuration chapter).

次に示すオプションがあります。(詳細は、エージェント設定の章を参照してください。)

• secondary_mode: セカンダリサーバのモードを設定します。次のいずれかが設定できます。
  • on_error: メインサーバにデータを送信できなかった場合のみセカンダリサーバにデータ送信します。
  • always: メインサーバに接続できるできないに関わらず、常にセカンダリサーバにもデータを送信します。
• 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: 転送に必要なその他オプションを設定します。

これは簡単です。複数のサーバに、ネットワーク、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 サービスの状態制御

If High Availability is enabled in the Database some extra configurations are needed to connect more Pandora FMS servers to the MySQL cluster. In the pandora_server.conf file (located by default at /etc/pandora), for each of the independent Pandora FMS servers to be added, the following parameters must be configured:

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

• dbuser: You must have the username to access the MySQL cluster. For example:

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

/etc/pandora/pandora_server.conf

dbuser pandora

• dbpass: It must contain the user password to access the MySQL cluster. For example:

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

/etc/pandora/pandora_server.conf

dbpass pandora

• ha_hosts: The ha_host parameter must be configured followed by the IP addresses or FQDN of the MySQL servers that make up the HA environment. Example:

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

ha_hosts 192.168.80.170,192.168.80.172

Just install another console pointing to the database. Any of the consoles can be used simultaneously from different locations by different users. A web load balancer can be used in front of the consoles in case horizontal growth is needed for console load sharing. The session system is managed through cookies and these are stored in the browser.

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

In the case of using remote configuration and to manage it from all consoles, both data servers and consoles must share the input data directory (default: /var/spool/pandora/data_in) for the remote configuration of agents, collections and other directories (see topic "Security architecture").

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

When updating Pandora FMS console in an HA environment, it is important to bear in mind the following points when updating by means of OUM through Management → Warp update → Update offline. The OUM package can downloaded from Pandora FMS support website.

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

When in a balanced environment with a shared database, updating the first console applies the corresponding changes to the database. This means that when updating the secondary console, Pandora FMS shows an error massage when finding the already entered information in the database. However, the console is still updated.

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

The new Pandora FMS HA solution is integrated into the product (inside the pandora_ha binary). It implements an HA that supports geographically isolated sites, with different IP ranges, which is not possible with Corosync/Pacemaker.

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

In the new HA model, the usual setup is in pairs of two, so the design does not implement a quorum system and simplifies the configuration and the necessary resources. That way the monitoring system will work as long as there is a DB node available and in case there is a DB Split Brain, the system will work in parallel until both nodes are merged again.

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

The new proposal seeks to solve the current three problems:

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

1. Complexity and maintainability of the current system (up to version NG 770).
2. Possibility of having an HA environment spread over different geographical locations with non-local network segmentation.
3. Data recovery procedure in case of split brain and secured system operation in case of communication breakdown between the two geographically separated sites.

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

The new HA system for DB is implemented on Percona8, although in future versions we will detail how to do so also on MySQL/MariaDB 8.

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

Pandora FMS is based on a MySQL database to configure and store data, so a failure in the database can temporarily paralyze the monitoring tool. The Pandora FMS high availability database cluster allows to easily deploy a strong and fail-safe architecture.

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

Binary replication MySQL cluster nodes are managed with the pandora_ha binary, starting with version 770. Percona was chosen as the default RDBMS for its scalability, availability, security and backup features.

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

Active/passive replication takes place from a single master node (with writing permissions) to any number of secondaries (read-only). If the master node fails, one of the secondaries is upgraded to master and pandora_ha takes care of updating the IP address of the master node.

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

The environment will consist of the following elements:

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

• MySQL8 servers with binary replication enabled (Active - Passive).
• Server with pandora_ha with the configuration of all MySQL servers to carry out ongoing monitoring and perform the slave-master and master-slave promotions necessary for the correct operation of the cluster.

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

First of all, it is necessary to have the Percona repository installed in all the nodes of the environment in order to be able to install the Percona server packages later on.

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

Execute on all devices involved:

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

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

Activate version 8 of the Percona repository on all devices:

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

percona-release setup ps80

Install the Percona server next to the backup tool with which the backups are to be performed for manual synchronization of both environments. Run on all devices involved:

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

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

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

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

Install Percona repository version 8 on all devices:

すべて のデバイスに 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

Activate Percona repository version 8 on all devices:

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

percona-release setup ps80

Install the Percona server next to the backup tool with which backups are to be performed for manual synchronization of both environments. On all devices run:

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

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

Once you have installed MySQL server in all the cluster nodes, proceed to configure both environments to have them replicated.

すべてのクラスタノードに MySQL サーバをインストールしたら、両方の環境をレプリケートするように設定します。

First of all, configure the configuration file my.cnf preparing it for the binary replication to work correctly.

まず、設定ファイル my.cnf を設定して、バイナリレプリケーションが正しく機能するように準備します。

Node 1 /etc/my.cnf ( /etc/mysql/my.cnf for Ubuntu server):

ノード 1 /etc/my.cnf ( Ubuntu server の場合は /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=MIXED
binlog_expire_logs_seconds=172800 # 2 DAYS
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

• The tokens after the OPTIMIZATION FOR PANDORA FMS comment perform the optimized configuration for Pandora FMS.
• After the comment SPECIFIC PARAMETERS FOR BINARY REPLICATION the specific parameters for the binary replication are configured.
• The token called binlog_expire_logs_seconds is configured for a period of two days.
• In the [client] subsection enter the user and password used for the database, by default when installing PFMS they are root and pandora respectively. These values are necessary to perform the backups without indicating user (automated).

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

Node 2 /etc/my.cnf ( /etc/mysql/my.cnf for Ubuntu server)

ノード 2 /etc/my.cnf ( Ubuntu server の場合は /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=MIXED
binlog_expire_logs_seconds=172800 # 2 DAYS
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

• The tokens after the OPTIMIZATION FOR PANDORA FMS comment perform the optimized configuration for Pandora FMS.
• After the comment SPECIFIC PARAMETERS FOR BINARY REPLICATION the specific parameters for the binary replication are configured.
• The token called binlog_expire_logs_seconds is configured for a period of two days.
• In the [client] subsection enter the user and password used for the database, by default when installing PFMS they are root and pandora respectively. These values are necessary to perform the backups without indicating user (automated).

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

Once you have the correct configuration on both nodes, start the configuration of the node that will take the role of master server.

両方のノードで正しい設定ができたら、マスターサーバの役割を果たすノードの設定を開始します。

1.- Start the mysqld service:

1.- mysqld サービスを開始します:

systemctl start mysqld

2.- Access with the temporary root password that will have been generated in the log, the file /var/log/mysqld.log:

2.- ログファイル /var/log/mysqld.log に書かれているテンポラリの root パスワードでアクセスします:

grep "temporary password" /var/log/mysqld.log

With the password that appears, access MySQL server:

見つけたパスワードで、MySQL サーバへアクセスします:

mysql -u root -p

Password: → Enter the password observed with the grep command.

Password: → grep コマンドで見つけたパスワードを入力します。

3.- Change the temporary password to pandora of the root user. Remember that the mysql > prompt corresponds to the MySQL command interpreter (MYSQL CLI):

3.- root ユーザのテンポラリパスワードを pandora に変更します。mysql > プロンプトは MySQL コマンドインタプリタ(MYSQL CLI)です。

mysql > ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'Pandor4!';

mysql > UNINSTALL COMPONENT “file:component_validate_password”;

mysql > ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'pandora';

4.- Create the binary replication user and root user for remote connections and cluster administration:

4.- バイナリレプリケーションユーザおよび、リモート接続とクラスタ管理のための root ユーザを作成します:

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

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

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

mysql > GRANT ALL PRIVILEGES ON *.* to root@'%';

5.- Create Pandora FMS database:

5.- Pandora FMS データベースを作成します:

mysql > create database pandora;

mysql > use pandora;

mysql > source /var/www/html/pandora_console/pandoradb.sql

mysql > source /var/www/html/pandora_console/pandoradb_data.sql

6.- Create the pandora user and give the access privileges to this user:

6.- pandora ユーザを作成し、このユーザにアクセス権限を与えます:

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

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

The next step is to make a clone of the master database (MASTER) in the slave node (SLAVE). To do so, follow the steps below:

次のステップは、スレーブノード (SLAVE) でマスターデータベース (MASTER) の複製を作成することです。これを行うには次の手順に従います。

1.- Make a complete download (dump) of the MASTER database:

1.- MASTER データベースの完全な複製(dump)を作成します:

MASTER # xtrabackup –backup –target-dir=/root/pandoradb.bak/

MASTER # xtrabackup –prepare –target-dir=/root/pandoradb.bak/

2.- Get the position of the backup binary log:

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

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

It will return something like the following:

次のような出力があります:

binlog.000003 157

Take note of these two values as they are needed for point number 6.

6 番目の手順で必要となるため、この 2つの値をメモしておきます。

3.- Make a copy using rsync with the SLAVE server to send the backup:

3.- rsync を使って SLAVE サーバにバックアップのコピーを送ります:

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

4.- On the SLAVE server, configure the permissions so that the MySQL server can access the files sent without any problem:

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

5.- Start the mysqld service on the SLAVE server:

5.- SLAVE サーバで、mysqld サービスを開始します:

systemctl start mysqld

6.- Start the SLAVE mode on this server (use the data noted in point 2):

6.- このサーバで SLAVE モードを開始します(手順 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;

Once you are done with all these steps, if you run the show slave status command inside the MySQL shell you will notice that the node is set as slave. If it has been configured correctly you should see an output like the following:

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

*************************** 1. row ***************************
Slave_IO_State: Waiting for source to send event
Master_Host: node1
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)

At this point you can be sure that you have binary replication enabled and working correctly.

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

It is necessary to configure inside the pandora_server.conf file a series of necessary parameters for the correct operation of the pandora_ha.

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

The parameters to be added are the following:

追加するパラメータは次の通りです。

• ha_hosts <IP_ADDRESS1>,<IP_ADDRESS2> :

Configure the ha_host parameter followed by the IP addresses or FQDN of the MySQL servers that make up the HA environment. The IP address you put first will have preference to be the MASTER server or at least have the master role when you first start the HA environment. Example:

• ha_hosts <IPアドレス1>,<IPアドレス2> :

HA 環境を構成する MySQL サーバの IP アドレスまたは FQDN を指定する ha_host パラメーターを設定します。 最初に入力した IP アドレスは、MASTER サーバになるか、HA 環境を最初に開始するときに少なくともマスターの役割を持つサーバです。 例：

ha_hosts 192.168.80.170,192.168.80.172

• ha_dbuser and ha_dbpass :

These are the parameters where you must indicate the user and password of root user or otherwise a MySQL user with the maximum privileges that will be in charge of performing all the master - slave promotion operations on the nodes. Example:

• ha_dbuser および ha_dbpass :

これらは、root ユーザのユーザとパスワードを指定する必要があるパラメータです。root 以外の場合は、各ノードで マスター - スレーブ 昇格操作を実行できる特権を持つ MySQL ユーザを指定する必要があります。 例：

ha_dbuser root
ha_dbpass pandora

• repl_dbuser and repl_dbpass :

Parameters to define the replication user that will use the SLAVE to connect to the MASTER. Example:

• repl_dbuser および repl_dbpass :

SLAVE から MASTER に接続するレプリケーションユーザを定義するパラメータです。 例：

repl_dbuser slaveuser
repl_dbpass pandora

• ha_sshuser and ha_sshport :

Parameters to define the user/port with which it is connected by ssh to the Percona/MySQL servers to perform the recovery operations. For the correct operation of this option, it is necessary to have the ssh keys shared between the user with which the pandora_ha service is executed and the user indicated in the ha_sshuser parameter. Example:

• ha_sshuser および ha_sshport :

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

ha_sshuser root
ha_sshport 22

• ha_resyncPATH_SCRIPT_RESYNC :

By default the script to perform the resynchronization of the nodes, this is located at:

• ha_resyncPATH_SCRIPT_RESYNC :

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

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

In the case of having a customized installation of the script, indicate in this parameter its location to perform the automatic or manual synchronization of the SLAVE node when needed.

スクリプトをカスタマイズしてインストールする場合は、必要に応じて SLAVE ノードの自動または手動同期を実行するスクリプトの場所をこのパラメータで指定します。

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

• ha_resync_log :

Log path where all the information related to the executions performed by the synchronization script configured in the previous token will be stored. Example:

• ha_resync_log :

前のトークンで設定された同期スクリプトの実行に関するすべての情報が格納されるログのパスです。 例：

ha_resync_log /var/log/pandoraha_resync.log

• ha_connect_retries :

Number of attempts it will perform on each check with each of the servers in the HA environment before making any changes to the environment. Example:

• ha_connect_retries :

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

ha_connect_retries 2

Once all these parameters are configured, you could start Pandora FMS server with the pandora_ha service. The server will get an image of the environment and it will know at that moment who is the MASTER server.

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

When it knows it, it will create the pandora_ha_hosts.conf file in the /var/spool/pandora/data_in/conf/ folder, where the Percona/MySQL server that has the MASTER role will be indicated at all times.

それを認識すると、/var/spool/pandora/data_in/conf/ フォルダに pandora_ha_hosts.conf ファイルが作成されます。これには、MASTER の役割を持つ Percona/MySQL サーバが常に示されています。

In case the incomingdir parameter of the pandora_server.conf file contains a different path (PATH), this file will be located at that PATH.

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

This file will be used as an interchange with the Pandora FMS Console to know at any time the IP address of the Percona/MySQL server with MASTER role.

このファイルは、MASTER の役割を持つ Percona/MySQL サーバの IP アドレスをいつでも知れるように、Pandora FMS コンソールでも使用されます。

• restart :

It will be indicated with a value of 0, since the pandora_ha daemon is the one in charge of restarting the service in case of failure, thus avoiding possible conflicts. Example:

pandora_ha デーモンは、競合を回避しながら障害時のサービスの再起動を行うため、通常は値は 0 です。 例：

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

An OpenSSH server must be installed and running on each host. Suppress the welcome message or banner that displays OpenSSH, run on all devices:

OpenSSH サーバがインストールされ、各ホストで動作している必要があります。OpenSSH を表示するウェルカムメッセージまたはバナーを抑制します。すべて のデバイスで以下を実行します:

[ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild
sed -i -e 's/^Banner.*//g' /etc/ssh/sshd_config
systemctl restart sshd

Share the SSH keys between pandora_ha and all the existing Percona/MySQL servers in the environment, run on Pandora FMS server:

pandora_ha と環境内に存在するすべての Percona/MySQL サーバ間で SSH 鍵を共有します。Pandora FMS サーバで以下を実行します:

printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 root@node1
ssh-copy-id -p22 root@node2

With Pandora FMS server a script is implemented that allows you to synchronize the SLAVE database in case it is out of sync.

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

The manual execution of this script is the following:

スクリプトの手動実行は次の通りです:

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

For example, to make a manual synchronization from node 1 to node 2 the execution would be the following:

例えば、ノード1 からノード2 へ手動で同期するには、次のように実行します:

/usr/share/pandora_server/util/pandora_ha_resync_slave.sh /etc/pandora/pandora_server.conf node1 node2

To configure the automatic recovery of the HA environment when there is any synchronization problem between MASTER and SLAVE, it is necessary to have the configuration token splitbrain_autofix configured to 1, inside the server configuration file (/etc/pandora/pandora_server.conf).

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

So, whenever a Split-Brain takes place (both servers have the master role) or there is any synchronization problem between MASTER and SLAVE node, pandora_ha will try to launch the pandora_ha_resync_slave.sh script to synchronize from that point the MASTER server status in the SLAVE server.

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

This process will generate events in the system indicating the start, the end and if any error took place in there.

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

A new parameter has been added to the config.php configuration indicating the path of the exchange directory that Pandora FMS uses by default /var/spool/pandora/data_in.

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

If it is configured, it will look for the file /var/spool/pandora/data_in/conf/pandora_ha_hosts.conf where it will get the IP address to make the connection.

設定されている場合、/var/spool/pandora/data_in/conf/pandora_ha_hosts.conf ファイルを探して、接続先の IP アドレスを取得します。

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

In Pandora FMS console you could see the cluster status accessing to the Manage HA view.

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

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

The data of this view is constantly updated thanks to pandora_ha, there is no need to do any previous configuration procedure to be able to see this section as long as the pandora_server.conf is correctly configured with the parameters mentioned in the previous section.

この画面のデータは、pandora_ha により常に更新されます。pandora_server.conf で前述のパラメータが正しく設定されている限り、このデータを表示するための特別な設定はありません。

Among the available actions, you may configure a label for each one of the nodes and you can perform the option to synchronize the SLAVE node through the icon.

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

This icon can have the following states:

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

• Green: Normal, no operation to be performed.
• Blue: Pending resynchronization.
• Yellow: Resynchronization is in progress.
• Red: Error, resynchronization failed.

• 緑: 正常、何の処理も実行されていない。
• 青: 同期保留中。
• 黄: 同期実行中。
• 赤: エラー、同期失敗。

The main difference between an HA environment used in MySQL/Percona Server version 5 and the current HA mode is that pandora_ha is now used to manage the cluster nodes to the detriment of Corosync-Pacemaker, which will no longer be used from now on.

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

The migration of the environment will consist of:

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

1.- Upgrading Percona from version 5.7 to version 8.0: “Installation and upgrade to MySQL 8”.

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

2.- Install xtrabackup-80 on all devices:

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

yum install percona-xtrabackup-80

If you use Ubuntu server see section “Percona 8 Installation for Ubuntu Server”.

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

3.- Create all users again with the token mysql_native_password in the MASTER node:

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

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

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

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

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

4.- Dump the database from the MASTER node to the SLAVE node:

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

4.1.- Make the full dump of the MASTER database:

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

MASTER #

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

MASTER #

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

4.2.- Get the position of the backup binary log:

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

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

binlog.000003 157

Take note of these two values as they are needed in point 4.6.

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

4.3.- Synchronize with rsync with the SLAVE server to send the backup.

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

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

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

4.4- On the SLAVE server, configure permissions so that MySQL server can access the sent files without any issues.

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.- Start mysqld service on the SLAVE server.

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

systemctl start mysqld

4.6.- Start the SLAVE mode on this server (use the data from point 4.2):

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;

In case you want to install from zero the environment in a new server, in the migration procedure you should only install from zero as the current procedure indicates in the new environment, and in the step of creating the Pandora FMS database you should import the data with a backup of the database of the old environment.

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

At the same time it will be necessary to save in the new environment the Pandora FMS Console and Server configuration indicated in previous sections.

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

Due to several factors, high latencies, network outages, etc., you may find that both MySQL servers have acquired the master role and we do not have the autoresync option enabled in pandora_ha so that the server itself chooses the server that is going to act as master and performs the synchronization from the master node to the slave, thus losing all the information that could be being collected in that server.

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

To solve this problem, the data can be merged following this procedure.

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

If new agents are created during Split-Brain time, or new configuration information (alerts, policies, etc.) these will not be taken into account. Only data and events will be retrieved. That is, the data related to the tagente_datos, tagente_datos_string and tevento tables.

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

The following commands will be executed in the node that was disconnected (the one to be promoted to SLAVE), where yyyy-mm-dd hh:mm:ss is the Split-Brain start date and time and yyyy2-mm2-dd2 hh2:mm2:ss2 its end date and time.

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

Run the mysqldump command with appropriate user rights to get a data dump (data dump or simply dump):

適切なユーザー権限で 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

Once the dumps of these tables have been obtained, the data will be loaded in the MASTER node:

これらのテーブルのダンプを取得したら、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

After loading the data you have retrieved from the node to be promoted to SLAVE, you will proceed to synchronize it using the following procedure:

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

1.- Make complete dump of the Master DB:

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

MASTER #

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

MASTER #

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

2.- Get the position of the binary log of the backed up data:

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

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

You will get something like the following (take due note of these values):

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

binlog.000003   157

3.- Do a task with the rsync command with the slave server to send the backup done.

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

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

4.- On the slave server, configure permissions so that the MySQL server can access the sent files without any problem.

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.- We start mysqld service in the slave server.

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

systemctl start mysqld

6.- Start slave mode on this server.

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;

Once all these steps have been completed, if you run the show slave status command inside the MySQL shell you will see that the node is in slave mode. If it has been configured correctly you should see an output like the following example:

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

*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: node1
                  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 ドキュメント一覧に戻る

Pandora FMS は、設定とデータの保存のために MySQL データベースに依存しています。データベースの障害は、一時的に監視処理が停止することになります。Pandora FMS の高可用性データベースクラスタにより、冗長化、堅牢なアーキテクチャを実現します。

クラスタリソースは、高度でスケーラブルな HA クラスタリソースマネージャである Pacemaker によって管理されます。Corosync は、複製された状態のマシンを作成するためのクローズドプロセスグループ通信モデルを提供します。スケーラビリティ、可用性、セキュリティおよびバックアップ機能のため、デフォルトの RDBMS としては Percona を選択しました。

アクティブ/スタンバイ レプリケーション では、一つのマスターノード(書き込み可)から、複数のスレーブ(読み出し専用)に同期します。仮想 IP アドレスは、常にマスターを示します。マスターノードが障害の場合は、スレーブのうちの 1つがマスターに昇格し、関連して仮想 IP が変更されます。

Pandora FMS データベース HA ツール pandora_ha は、クラスタを監視し、Pandora FMS サーバが常に動作していることを確認します。必要な場合はそれを再起動します。pandora_ha 自身は systemd によって監視されます。

In this example a two-node cluster will be configured, with hosts: node1 y node2.

この例では、node1 および node2 の 2ノードクラスタを設定します。

Change the host names, passwords, etcetera as needed to match the environment to be deployed.

展開する環境に合わせて、必要に応じてホスト名やパスワードなどを変更してください。

Commands that have to be executed on any node will have the following syntax (example for node1):

いずれかのノードで実行する必要のあるコマンドの構文は次のとおりです(node1 の例)。

node1#
<command>
<command>
<command>

Commands that have to be executed on all nodes will be preceded by the word all:

すてべのノードで実行する必要のあるコマンドは、all をつけています。

all#
<command>
<command>
<command>

There is also an additional host called pandorafms where Pandora FMS will be installed. When all is referenced it only refers to the database nodes, the additional Pandora FMS node will always be referenced as pandorafms and it is not part of all.

Pandora FMS がインストールされる pandorafms と呼ばれる追加のホストもあります。all が使われる場合、それはデータベースノードのみを指し、追加のPandora FMS ノードは常に pandorafms として表現され、all には含まれません。

RHEL version 8 or Rocky Linux version 8 must be installed on all hosts, and must be able to resolve the hostnames of the other hosts.

RHEL バージョン 8 または Rocky Linux バージョン 8 が全ホストでインストールされている必要があり、また、他のホストのホスト名の名前解決ができる必要があります。

An OpenSSH server must be installed and running on each host. Suppress the warning that OpenSSH displays:

OpenSSH サーバがインストールされており、それぞれのホストで起動している必要があります。OpenSSH が表示する警告を抑制します。

all#
[ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild
sed -i -e 's/^Banner.*//g' /etc/ssh/sshd_config
systemctl restart sshd

Generate new SSH authentication keys for each host and copy the public key for each of the hosts.

ホストごとに新しい SSH 認証キーを生成し、ホストごとに公開鍵をコピーします。

all#
printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 root@node1
ssh-copy-id -p22 root@node2

pandorafms#
printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 root@node1
ssh-copy-id -p22 root@node2

In the Pandora FMS node, copy the key pair to the following directories httpd and ssh. The Pandora FMS console (httpd) needs to retrieve the cluster status:

Pandora FMS ノードで、キーペアを次の httpd および ssh ディレクトリにコピーします。 Pandora FMS コンソール(httpd) は、クラスターステータスを取得する必要があります。

pandorafms#
cp -r /root/.ssh/ /usr/share/httpd/
chown -R apache:apache /usr/share/httpd/.ssh/

You must replace 22 with the port number you use:

22 を利用ポート番号に置き換える必要があります。

all#
echo -e "Host node1\n Port 22">> /root/.ssh/config
echo -e "Host node2\n Port 22">> /root/.ssh/config

You must test authentication without password from each node to the others:

それぞれのノードからパスワード無しで他のノードの認証が通るかを確認する必要があります。

all#
ssh node1
ssh node2

pandorafms#
ssh node1
ssh node2

Install the required package:

必要なパッケージをインストールします。

all#
dnf install dnf-utils \
 https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm \
 https://repo.percona.com/yum/percona-release-latest.noarch.rpm"

dnf module disable -y mysql

dnf install -y Percona-Server-server-57 percona-xtrabackup-24

For more information regarding the Percona installation process, you can consult the official product documentation:

ercona に関するより詳細なインストール処理は、公式ドキュメントを確認してください。

Once the packages are installed, make sure the Percona service is disabled, as it will be managed by the cluster:

パッケージをインストールしたら、Percona サービスが無効化されていることを確認します。これは、クラスタによって管理されるためです。

all#
systemctl disable mysqld

Next, start the Percona server:

次に、Percona サーバを起動します。

all#
systemctl start mysqld

A new temporary password will be generated connected to /var/log/mysqld.log. Connect to the Percona server and change the password for root:

新規のテンポラリパスワードが生成され、/var/log/mysqld.log に記録されます。Percona サーバへ接続し、root のパスワードを変更します。

all#
export MYSQL_PWD=$(grep "temporary password" /var/log/mysqld.log | rev | cut -d' ' -f1 | rev)

echo """
  SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
  UNINSTALL PLUGIN validate_password;
  SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
  """ | mysql --connect-expired-password -uroot

When carrying out the MySQL configuration, it can be done using the following autogenerator, which is already included in the Pandora FMS Enterprise server installation package and the Pandora FMS ISO by default.

MySQL 設定は次の自動生成機能を使用して実行できます。これは、Pandora FMS Enterprise サーバのインストールパッケージと Pandora FMS ISO にデフォルトで含まれています。

Once the server is installed, you will find the configuration builder for database replication at the path:

サーバをインストールしたら、次のパスにデータベースレプリケーション用の設定ビルダーをみつけます。

/usr/share/pandora_server/util/myconfig_ha_gen.sh

Example: ./myconfig_ha_gen.sh -i serverid [-l file_location] [-d database] [-b binlog] [-u dbuser] [-p dbpass] [-s poolsize] [-h help]
Mandatory parameters:
    -i --serverid Set the server id for the database (Mandatory)
Optional parameters:
    -l --location Set my.cnf custom location including filename. [ default value: /etc/my.cnf ] (optional)
    -d --database Set the database to be replicated. [ default value: pandora ] (optional)
    -b --binlog Set binlog file. [ default value: mysql-bin ] (optional)
    -u --dbuser Set dbuser for mysql connection and backups. [ default value: root ] (optional)
    -p --dbpass Set dbpassword for mysql connection and backups. [ default value: pandora ] (optional)
    -s --poolsize Set innodb_buffer_pool_size static size in M (Megabytes) or G (Gigabytes). [ default value: autocalculated ] (optional)
    -h --help Print help.

In the current case where the databases are not on the same server as the application, it will be necessary to copy the script to the nodes to be executed locally.

データベースがアプリケーションと同じサーバ上にない場合は、ローカルで実行するノードにスクリプトをコピーする必要があります。

pandorafms#
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node1:/root/
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node2:/root/

It will only be necessary to pass the parameter serverid (mandatory) in standard environments and some optional parameters for custom environments.

標準環境ではパラメータ serverid (必須)を渡す必要があります。また、カスタム環境ではいくつかのオプションパラメーターを使用します。

If the default or defined user does not connect to the database, the script will end with a connection error.

デフォルトまたは定義済みのユーザがデータベースに接続できない場合、スクリプトは接続エラーで終了します。

You also have the possibility of passing database name, user and password as arguments. Otherwise, the default settings will be used.

データベース名、ユーザ、パスワードを引数として渡すこともできます。 それ以外の場合は、デフォルト設定が使用されます。

In this case, it will execute the script on both nodes, only passing the server id if it has the default credentials, otherwise it must define the necessary parameters.

この場合、両方のノードでスクリプトを実行し、デフォルトの認証情報がある場合にのみ サーバ ID を渡します。それ以外の場合は、必要なパラメーターを定義する必要があります。

node1#
/root/myconfig_ha_gen.sh -i 1

node2#
/root/myconfig_ha_gen.sh -i 2

The Percona configuration file will be written in /etc/my.cnf where the server identifier and the recommended configuration for database replication will be defined. You must restart the mysqld service to verify that the configuration has been applied correctly.

Percona 設定ファイルは /etc/my.cnf に書き込まれ、サーバ ID とデータベースレプリケーションの推奨設定が定義されます。 設定が正しく適用されていることを確認するには、mysqld サービスを再起動する必要があります。

all#
systemctl restart mysqld

You can either perform a completely new installation or migrate the data you have from an existing instance.

完全に新規インストールを実行するか、既存のインスタンスからデータを移行することができます。

Install Pandora FMS in the newly created database. Stop the Pandora FMS server:

新規で作成するデータベースに Pandora FMS をインストールします。Pandora FMS サーバを停止します。

pandorafms#
/etc/init.d/pandora_server stop

From version NG 754 onwards you have additional options in the manual start and stop of High Availability Environments (HA).

バージョン NG 754 以降では、高可用性(HA)環境に手動起動および停止のための追加のオプションがあります。

Stop the Pandora FMS server:

Pandora FMS サーバを停止します。

pandorafms#
/etc/init.d/pandora_server stop

Backup the Pandora FMS database and transfer it to node 1:

Pandora FMS データベースをバックアップし、node1 へ転送します。

pandorafms# mysqldump -uroot -ppandora --databases pandora> /tmp/pandoradb.sql scp /tmp/pandoradb.sql node1:/tmp/

Now upload the information to the new database on the node (in case of not using the default credentials and database name, change it in the following command):

次に、ノード上の新しいデータベースに情報をアップロードします(デフォルトの認証情報とデータベース名を使用しない場合は該当部分を変更します)。

node1# mysql -uroot -ppandora pandora -e source "/tmp/pandoradb.sql"

Grant the necessary privileges for the replication in order to work in all the databases:

全データベースでレプリケーションが動作するのに必要な権限を設定します。

all#
mysql -uroot -ppandora
  GRANT ALL ON pandora.* TO 'root'@'%' IDENTIFIED BY 'pandora';
  GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'root'@'%' IDENTIFIED BY 'pandora';
  GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'pandora'@'%' IDENTIFIED BY 'pandora';
  GRANT REPLICATION CLIENT, REPLICATION SLAVE, SUPER, PROCESS, RELOAD ON *.* TO 'root'@'localhost' IDENTIFIED BY 'pandora';
  GRANT select ON mysql.user TO 'root'@'%' IDENTIFIED BY 'pandora'; FLUSH PRIVILEGES; quit;

Stop the node2 database:

node2 データベースを停止します。

node2#
systemctl stop mysqld

Backup the database of the first node (node1) and write the name and position of the master log file (in this example, mysql-bin.000001 and 785):

最初のノード (node1) のデータベースをバックアップし、マスターログファイルの名前と位置(この例では、mysql-bin.000001 と 785)を控えておきます。

node1#
[ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
innobackupex --no-timestamp /root/pandoradb.bak/
innobackupex --apply-log /root/pandoradb.bak/
rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/
cat /root/pandoradb.bak/xtrabackup_binlog_info

Load the database on the second node (node2) and configure to replicate from the first node (you must set MASTER_LOG_FILE and MASTER_LOG_POS to the values from the previous step):

2つ目のノード(node2)にデータベースをコピーし、1つ目のノードからレプリケーションをする設定をします。(上記のステップで記録しておいた MASTER_LOG_FILE と MASTER_LOG_POS を指定します。)

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

systemctl start mysqld

mysql -uroot -ppandora
  CHANGE MASTER TO MASTER_HOST='node1',
  MASTER_USER='root', MASTER_PASSWORD='pandora',
  MASTER_LOG_FILE ='mysql-bin.000001', MASTER_LOG_POS =785;
  START SLAVE;
  SHOW SLAVE STATUS \G

You will get an output similar to:

次のような出力結果が得られます。

If everything was correct exit the database interface:

全て正常であれば、データベースのインタフェースから抜けます。

#node2
mysql> QUIT

Install the necessary packages: For Rocky Linux™ it will only be necessary to execute the following command.

必要なパッケージをインストールします。Rocky Linux では、次のコマンドを実行する必要があるのみです。

all#
dnf install -y --enablerepo='ha' chrony epel-release corosync pacemaker pcs

In the case of RedHat it will be necessary to enable the rhel-8-for-x86_64-highavailability-rpms repository from the subscription manager before installing.

RedHat の場合、インストールする前に、サブスクリプションマネージャーから rhel-8-for-x86_64-highavailability-rpms リポジトリーを有効にする必要があります。

all#
subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
dnf install -y --enablerepo='rhel-8-for-x86_64-highavailability-rpms' chrony epel-release corosync pacemaker pcs

Now define the configuration file and enable the corosync, pscd and chrony services (substitute for the old ntpd).

設定を行い、corosync, pscd および chrony(旧 ntpd の置き換え) サービスを有効化します。

all#
cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf

systemctl enable chronyd --now

systemctl enable pcsd --now

systemctl enable corosync --now

Stop the Percona server:

Percona サーバを停止します。

all#
systemctl stop mysqld

Define the user password hacluster:

hacluster のユーザパスワードを設定します。

all#
echo hapass | passwd hacluster --stdin

Create and start the cluster, these steps will only be necessary to do it in node1:

クラスタを作成し開始します。これらのステップは、node1 でのみ実行する必要があります。

node1#
pcs host auth node1 node2 -u hacluster -p hapass

pcs cluster setup pandorafms node1 node2 --force

pcs cluster start --all
pcs cluster enable --all

pcs property set stonith-enabled=false

pcs property set no-quorum-policy=ignore

Check the status of the cluster:

クラスタの状態を確認します。

node1#
pcs status

You will see an output similar to:

次のような出力が得られます。

Pacemaker can be downloaded manually from the PFMS library.

Pacemaker は Pandora FMS ライブラリ から手動でダウンロードできます。

In case you have internet access you can install it by running:

インターネット接続があれば、以下を実行することでインストールできます。

all#
cd /usr/lib/ocf/resource.d/
mkdir percona
cd percona
curl -L -o pacemaker_mysql_replication.zip
https://pandorafms.com/library/wp-content/uploads/2019/12/pacemaker_mysq
l_replication.zip
unzip pacemaker_mysql_replication.zip
rm -f pacemaker_mysql_replication.zip
chmod u+x mysql
cd

Configure cluster resources.

クラスタリソースを設定します。

Replace <VIRT_IP> with the preferred virtual IP address:

<VIRT_IP> は、好みの仮想 IP アドレスに置き換えます。

#node1
export VIP='<VIRT_IP>'
pcs resource create pandoradb ocf:percona:mysql config="/etc/my.cnf" \
pid="/var/run/mysqld/mysqld.pid" socket="/var/lib/mysql/mysql.sock" \
replication_user="root" replication_passwd="pandora" max_slave_lag="60" \
evict_outdated_slaves="false" binary="/usr/sbin/mysqld" datadir="/var/lib/mysql" \
test_user="root" test_passwd="pandora" op start interval="0" timeout="60s" \
op stop interval="0" timeout="60s" op promote timeout="120" op demote timeout="120" \
op monitor role="Master" timeout="30" interval="5" on-fail="restart" op monitor role="Slave" \
timeout="30" interval="10"

pcs resource create pandoraip ocf:heartbeat:IPaddr2 ip=$VIP cidr_netmask=24 \
op monitor interval=20s

pcs resource promotable pandoradb meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true" \
globally-unique=" false" target-role="Master" is-managed="true"

pcs constraint colocation add master pandoradb-clone with pandoraip

pcs constraint order promote pandoradb-clone then start pandoraip

sleep 5 ; pcs resource cleanup

Check the cluster status:

クラスタの状態を確認します。

node1#
pcs status

You will see an output similar to:

次のような出力が得られます。

It will be done in a similar way to the previous one.

前述の内容と同じように実施します。

The user's credentials must have been copied, previously explained, and the following steps must be carried out:

すでに説明しているように、ログイン情報はコピーされている必要があり、以下のステップを実行する必要があります。

# All nodes:
useradd <usuario>
passwd <usuario>
usermod -a -G haclient <usuario>

# Enable PCS ACL system
pcs property set enable-acl=true --force

# Create role
pcs acl role create <rol> description="RW role" write xpath /cib

# Create PCS user - Local user
pcs acl user create <usuario> <rol>

# Login into PCS from ALL nodes
su - <usuario>
pcs status
Username: <usuario>
Password: *****

# Wait for 'Authorized' message, ignore output. Wait a second and retry 'pcs status' command

Configure a two-node cluster, with hosts node1 and node2. Change hostnames, passwords, etc. as needed to match your environment.

node1 および node2 の 2つのノードのクラスタを設定します。環境に合わせて、ホスト名、パスワードなどを変更します。

一方のノードで実行するコマンドにについては、ノードのホスト名を前に表示します。例:

node1# <command>

すべてのノードで実行するコマンドについては、all を前に表示します。例:

all# <command>

さらに、Pandora FMS がインストールされているノードを pandorafms とします。

CentOS バージョン 7 がすべてのノードにインストールされており、それぞれのホスト名の名前解決ができる必要があります。

 node1# ping node2
 PING node2 (192.168.0.2) 56(84) bytes of data.

 node2# ping node1
 PING node1 (192.168.0.1) 56(84) bytes of data.

 pandorafms# ping node1
 PING node1 (192.168.0.1) 56(84) bytes of data.

 pandorafms# ping node2
 PING node2 (192.168.0.2) 56(84) bytes of data.

OpenSSH サーバがインストールされており、各ホストで実行されている必要があります。OpenSSH が表示するバナーを削除します。

all# [ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild
all# sed -i -e 's/^Banner.*//g' /etc/ssh/sshd_config
all# systemctl restart sshd

それぞれのホストで SSH 認証鍵を生成し、公開鍵を他のホストへコピーします。

 node1# echo -e "\n\n\n" | ssh-keygen -t rsa
 node1# ssh-copy-id -p22 root@node2
 node1# ssh node2

 node2# echo -e "\n\n\n" | ssh-keygen -t rsa
 node2# ssh-copy-id -p22 root@node1
 node2# ssh node1

 pandorafms# echo -e "\n\n\n" | ssh-keygen -t rsa
 pandorafms# ssh-copy-id -p22 root@node1
 pandorafms# ssh-copy-id -p22 root@node2
 pandorafms# ssh node1
 pandorafms# ssh node2

Pandora FMS ノードで、鍵のペアを /usr/share/httpd/.ssh/ へコピーします。Pandora FMS コンソールが、クラスタの状態を取得するために必要です。

 pandorafms# cp -r /root/.ssh/ /usr/share/httpd/
 pandorafms# chown -R apache:apache /usr/share/httpd/.ssh/

SSH が標準以外のポートで動作しているノードでは、以下のステップが必要です。22 を正しいポート番号に置き換えます。

 all# echo -e "Host node1\n    Port 22">> /root/.ssh/config
 all# echo -e "Host node2\n    Port 22">> /root/.ssh/config

必要なパッケージをインストールします。

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

 all# yum install -y Percona-Server-server-57 percona-xtrabackup-24

For more information regarding the Percona installation process, check the official product documentation at: https://www.percona.com/doc/percona-server/5.7/installation/yum_repo.html

Percona に関するより詳細なインストール処理は、https://www.percona.com/doc/percona-server/5.7/installation/yum_repo.html にある公式ドキュメントを確認してください。

Once the packages have been installed, make sure the Percona service is disabled, since it will be managed by the cluster:

パッケージをインストールしたら、Percona サービスが無効化されていることを確認します。これは、クラスタによって管理されるためです。

all# systemctl disable mysqld

次に、Percona サーバを起動します。

all# systemctl start mysqld

新規のテンポラリパスワードが生成され、/var/log/mysqld.log に記録されます。Percona サーバへ接続し、root のパスワードを変更します。

 all# mysql -uroot -p$(grep "temporary password" /var/log/mysqld.log | \
 rev | cut -d' ' -f1 | rev)
 mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
 mysql> UNINSTALL PLUGIN validate_password;
 mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
 mysql> quit

Reinstall with the –ha flag.

-ha フラグを付けて再インストールします。

pandorafms# ./pandora_server_installer --install --ha

HA ツールを有効化してサーバをインストールしたら、データベースレプリケーションの設定ジェネレータを /usr/share/pandora_server/util/mycnf_gen.sh に見つけることができます。

Example: ./myconfig_ha_gen.sh -i serverid [-l file_location] [-d database] [-b binlog] [-u dbuser] [-p dbpass] [-s poolsize] [-h help]
Mandatory parameters:
      -i --serverid   Set the server id for the database (Mandatory)
Optional parameters:
      -l --location   Set my.cnf custom location including filename. [ default value: /etc/my.cnf ] (optional)
      -d --database   Set the database to be replicated. [ default value: pandora ] (optional)
      -b --binlog     Set binlog file. [ default value: mysql-bin ] (optional)
      -u --dbuser     Set dbuser for mysql connection and backups. [ default value: root ] (optional)
      -p --dbpass     Set dbpassword for mysql connection and backups. [ default value: pandora ] (optional)
      -s --poolsize   Set innodb_buffer_pool_size static size in M (Megabytes) or G (Gigabytes). [ default value: autocalculated ] (optional)
      -h --help       Print help.

データベースがアプリケーションと同じサーバ上にないケースでは、ローカルで実行するノードにスクリプトをコピーする必要があります。

 pandorafms# scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node1:/root/
 pandorafms# scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node2:/root/

As you see in the example, it will only be necessary to enter the parameter serverid (mandatory) in standard environments and some optional parameters for custom environments.

例でわかるように、標準環境でパラメーター serverid(必須)を渡すか、カスタム環境の場合はいくつかのオプションパラメータを展開するだけで済みます。

デフォルトのユーザまたは定義されたユーザがデータベースに接続できない場合、スクリプトは接続エラーとなります。

データベース、ユーザ、パスワードを引数として渡すこともできます。それ以外の場合は、デフォルト設定が使用されます。

この場合、両方のノードでスクリプトを実行し、デフォルトの資格情報がある場合にのみサーバ ID を渡します。それ以外の場合は、必要なパラメータを定義します。

 node1# /root/myconfig_ha_gen.sh -i 1
 node2# /root/myconfig_ha_gen.sh -i 2

Percona の設定ファイルは /etc/my.cnf に書き込まれ、サーバ ID とデータベースレプリケーションの推奨設定が定義されます。

mysqld サービスを再起動して、設定が正しく適用されていることを確認します。

all# systemctl restart mysqld

Install Pandora FMS on the newly created database. For more information see:

新規で作成するデータベースに Pandora FMS をインストールします。詳細は以下を参照してください。

https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_ja:Installing

Pandora FMS サーバを停止します。

pandorafms# /etc/init.d/pandora_server stop

Pandora FMS サーバを停止します。

pandorafms# /etc/init.d/pandora_server stop

Pandora FMS データベースをバックアップします。

pandorafms# mysqldump -uroot -ppandora --databases pandora> /tmp/pandoradb.sql
pandorafms# scp /tmp/pandoradb.sql node1:/tmp/

バックアップを新しいデータベースにリストアします。

node1# mysql -uroot -ppandora -e source "/tmp/pandoradb.sql"

全データベースでレプリケーションが動作するのに必要な権限を設定します。

 all# mysql -uroot -ppandora
 mysql> GRANT ALL ON pandora.* TO 'root'@'%' IDENTIFIED BY 'pandora';
 mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.*
 TO 'root'@'%' IDENTIFIED BY 'pandora';
 mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE, SUPER, PROCESS, RELOAD ON *.*
 TO 'root'@'localhost' IDENTIFIED BY 'pandora';
 mysql> GRANT select ON mysql.user TO 'root'@'%' IDENTIFIED BY 'pandora';
 mysql> FLUSH PRIVILEGES;
 mysql> quit

1つ目のノードのデータベースをバックアップし、マスターログファイル名とポジションを記録します。(以下の例では、それぞれ mysql-bin.000001 と 785 です)

node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# cat /root/pandoradb.bak/xtrabackup_binlog_info
mysql-bin.000001        785

2つ目のノードにデータベースをコピーし、1つ目のノードからレプリケーションをする設定をします。(上記のステップで記録しておいた MASTER_LOG_FILE と MASTER_LOG_POS を指定します。)

node2# systemctl stop mysqld

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

node2# chown -R mysql:mysql /var/lib/mysql
node2# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node2# systemctl start mysqld
node2# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000002
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node2-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000002
                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: 785
                 Relay_Log_Space: 1252
                 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: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave 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:
   1 row in set (0.00 sec)
mysql> QUIT

all# systemctl stop mysqld

必要なパッケージをインストールします。

 all# yum install -y epel-release corosync ntp pacemaker pcs

 all# systemctl enable ntpd
 all# systemctl enable corosync
 all# systemctl enable pcsd
 all# cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf

 all# systemctl start ntpd
 all# systemctl start corosync
 all# systemctl start pcsd

Percona サーバを停止します。

node1# systemctl stop mysqld

node2# systemctl stop mysqld

クラスタを作成し、開始します。

all# echo hapass | passwd hacluster --stdin

 node1# pcs cluster auth -u hacluster -p hapass --force node1 node2
 node1# pcs cluster setup --force --name pandoraha node1 node2
 node1# pcs cluster start --all
 node1# pcs cluster enable --all
 node1# pcs property set stonith-enabled=false
 node1# pcs property set no-quorum-policy=ignore

クラスタの状態を確認します。

node#1 pcs status
   Cluster name: pandoraha
   Stack: corosync
   Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
   Last updated: Fri Jun  8 12:53:49 2018
   Last change: Fri Jun  8 12:53:47 2018 by root via cibadmin on node1

   2 nodes configured
   0 resources configured

   Online: [ node1 node2 ]

   No resources

   Daemon Status:
     corosync: active/disabled
     pacemaker: active/disabled
     pcsd: active/enabled

これは、我々の ライブラリ からダウンロードできます。

all# cd /usr/lib/ocf/resource.d/
all# mkdir percona
all# cd percona
all# curl -L -o pacemaker_mysql_replication.zip https://pandorafms.com/library/wp-content/uploads/2019/12/pacemaker_mysql_replication.zip
all# unzip pacemaker_mysql_replication.zip
all# rm -f pacemaker_mysql_replication.zip
all# chmod u+x mysql

クラスタリソースを設定します。<VIRT_IP> をあらかじめ決めておいた仮想 IP アドレスに置き換えます。

node1# export VIP=<VIRT_IP>
node1# pcs resource create pandoradb ocf:percona:mysql config="/etc/my.cnf" \
pid="/var/run/mysqld/mysqld.pid" socket="/var/lib/mysql/mysql.sock" \
replication_user="root" replication_passwd="pandora" max_slave_lag="60" \
evict_outdated_slaves="false" binary="/usr/sbin/mysqld" datadir="/var/lib/mysql" \
test_user="root" test_passwd="pandora" op start interval="0" timeout="60s" \
op stop interval="0" timeout="60s" op promote timeout="120" op demote timeout="120" \
op monitor role="Master" timeout="30" interval="5" on-fail="restart" op monitor role="Slave" \
timeout="30" interval="10"
node1# pcs resource create pandoraip ocf:heartbeat:IPaddr2 ip=$VIP cidr_netmask=24\ 
op monitor interval=20s
node1# pcs resource master master_pandoradb pandoradb meta master-max="1" \
master-node-max="1" clone-max="2" clone-node-max="1" notify="true" \
globally-unique="false" target-role="Master" is-managed="true"
node1# pcs constraint colocation add master master_pandoradb with pandoraip
node1# pcs constraint order promote master_pandoradb then start pandoraip

クラスタの状態を確認します。

node1# pcs status
   Cluster name: pandoraha
   Stack: corosync
   Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
   Last updated: Fri Jun  8 13:02:21 2018
   Last change: Fri Jun  8 13:02:11 2018 by root via cibadmin on node1
   
   2 nodes configured
   3 resources configured
   
   Online: [ node1 node2 ]
   
   Full list of resources:
   
    Master/Slave Set: master_pandoradb [pandoradb]
        Masters: [ node1 ]
        Slaves: [ node2 ]
    pandoraip      (ocf::heartbeat:IPaddr2):       Started node1
   
   Daemon Status:
     corosync: active/disabled
     pacemaker: active/disabled
     pcsd: active/enabled

It will be done similarly to the previous one. The login information must have been copied, which has already been explained, and the following steps must be carried out:

前述の内容と同じように実施します。すでに説明しているように、ログイン情報はコピーされている必要があり、以下のステップを実行する必要があります。

# 全ノード:

 useradd <user>
 passwd <user>
 usermod -a -G haclient <user>

# PCS ACL システムの有効化
pcs property set enable-acl=true --force

# ロールの作成
pcs acl role create <rol> description="RW role"  write xpath /cib

# PCS ユーザの作成 - ローカルユーザ
pcs acl user create <user> <rol>

# 全ノードから PCS へログイン
su - <user>
pcs status
Username: <user>
Password: ***** 

# 'Authorized' メッセージを待ち出力は無視します。数秒待ったのち、'pcs status' コマンドを実行します。

Make sure that php-pecl-ssh2 is installed according to the OS and version you have installed:

インストールした OS とバージョンに従って php-pecl-ssh2 がインストールされていることを確認します。

RHEL 8

 pandorafms# dnf install --disablerepo=rhel-8-for-x86_64-appstream-rpms php-pecl-ssh2
 pandorafms# systemctl restart php-fpm
 pandorafms# systemctl restart httpd

Rocky Linux 8

 pandorafms# dnf install php-pecl-ssh2
 pandorafms# systemctl restart php-fpm
 pandorafms# systemctl restart httpd

CentOS 7

 pandorafms# yum install php-pecl-ssh2
 pandorafms# systemctl restart httpd

There are two parameters in /etc/pandora/pandora_server.conf that control the performance of the Pandora FMS Database HA Tool. Adjust them to suit your needs:

Pandora FMS データベース HA ツールの動作を制御する 2つのパラメータが /etc/pandora/pandora_server.conf にあります。これらを好みに応じて調整します。

# Pandora FMS Database HA Tool execution interval in seconds (PANDORA FMS ENTERPRISE ONLY).
ha_interval 30

# Pandora FMS Database HA Tool monitoring interval in seconds. Must be a multiple of ha_interval (PANDORA FMS ENTERPRISE ONLY).
ha_monitoring_interval 60

Point your Pandora FMS to the master's virtual IP address (replacing <IP> by the virtual IP address):

Pandora FMS の DB 参照先をマスターの仮想 IP アドレスにします。(<IP> を仮想 IP アドレスに置き換えます。)

pandorafms# export VIRT_IP=<IP>
pandorafms# sed -i -e "s/^dbhost .*/dbhost $VIRT_IP/" \
/etc/pandora/pandora_server.conf
pandorafms# sed -i -e "s/\$config\[\"dbhost\"\]=\".*\";/\$config[\"dbhost\"]=\"$VIRT_IP\";/" \
/var/www/html/pandora_console/include/config.php

Log in your Pandora FMS Console and go to Servers > Manage database HA:

Pandora FMS コンソールへログインし、サーバ(Servers) > データベース HA 管理(Manage database HA) へ行きます。

Click on Add new node and create an entry for the first node:

新規ノード追加(Add new node) をクリックし、1つ目のノードのエントリを作成します。

Next, click Register and add an entry for the second node. You should see something similar to this:

次に、登録(Register) をクリックし、2つ目のノードのエントリを追加します。次のような画面が表示されます。

Scenario.

シナリオ

Both servers are as main or master, in the HA console view both appear as main (Master) but the Virtual IP is only on one node (the one that is actually acting as main or Master).

両方のサーバはメインまたはマスターとして機能し、HA コンソール表示では両方ともメイン(マスター)として表示されますが、仮想 IP は 1つのノード(実際にメインまたはマスターとして機能しているノード)にのみ存在します。

At this point, if the token splitbrain_autofix is set to 1, the node recovery process will be started at splitbrain.

この時、トークン splitbrain_autofix が 1に設定されていると、スプリットプレーンからのノードのリカバリ処理が開始されます。

For the correct operation of this functionality the following components must be correctly configured::

この機能を正しく動作させるには、次のコンポーネントを正しく設定する必要があります。

• SSH root user keys shared between the server pandora_ha master and all database servers.
• Replicator user configured in the setup with rights or grants from the server where the server pandora_ha master is hosted.

• pandora_ha マスター および全データベースサーバの間で root ユーザの ssh 鍵を共有
• pandora_ha マスター があるホストでの、権限のあるレプリケーションユーザの設定

• Space available for database backup on both servers where the 2 databases are hosted (primary and secondary, Master/Slave).

• 2つのデータベースがある両方のサーバ(プライマリおよびセカンダリ、マスター/スレーブ)でデータベースのバックアップに使用できるスペースがある

In the case that the datadir and the path where the partition must be done are in the same partition, it is necessary that the free space is at least 50%.

datadir と path のパーティションが同じ場合、空き領域は少なくとも 50% である必要があります。

If all the above points are correctly configured, the recovery process is as follows:

上記のすべてのポイントが正しく設定されている場合、回復処理は次のようになります：

1. Delete the previous backups.
2. Back up the datadir of the secondary node (Slave).
3. Performs backup of the main node (Master).
4. Sends backup of the main node to the secondary node (Master → Slave).
5. Starts the resource of the “secondary” (“Slave”) node with the corresponding resynchronization parameters at the time of the backup.
6. Checks that the resource is active and correct. For this it will make use of the configuration indicated in the parameters ha_max_resync_wait_retries and ha_resync_sleep .

1. 以前のバックアップを削除
2. セカンダリノード(スレーブ)の datadir をバックアップ
3. メインノード(マスター) のバックアップ
4. メインノードのバックアップをセカンダリノードへ送信 (マスター → スレーブ)
5. バックアップ時の再同期パラメータを使用して、“セカンダリ” (“スレーブ”) ノードのリソースを開始
6. リソースが有効で正しいか確認。これには、ha_max_resync_wait_retries および ha_resync_sleep のパラメータで示されている設定を利用します

If at some point in the process it fails, it will repeat it again the times indicated through the parameter ha_max_splitbrain_retries.

処理のある時点で失敗した場合は、パラメータ ha_max_splitbrain_retries で示された回数だけ繰り返します。

Once the process is finished, an event will appear indicating that the process has been completed successfully in the event view.

処理が完了したら、イベント表示に処理が正常に完了したことを示すイベントが表示されます。

If the environment is still not recovered automatically, it will leave the secondary (Slave) node in standby and an event will appear indicating that the recovery must be performed manually in the event view.

それでも環境が自動的にリカバリされない場合は、セカンダリ(スレーブ)ノードがスタンバイのままになり、イベント表示でリカバリを手動で実行する必要があることを示すイベントが表示されます。

OpenSSH で表示されるバナーを削除します。

node3# [ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild
node3# sed -i -e 's/^Banner.*//g' /etc/ssh/sshd_config
node3# systemctl restart sshd

新しいホスト用の新しい SSH 認証キーを生成し、公開キーを他の各ホストにコピーします。

node1# ssh-copy-id -p22 root@node3
node1# ssh node3

node2# ssh-copy-id -p22 root@node3
node2# ssh node3

pandorafms# ssh-copy-id -p22 root@node3
pandorafms# ssh node3

node3# echo -e "\n\n\n" | ssh-keygen -t rsa
node3# ssh-copy-id -p22 root@node1
node3# ssh-copy-id -p22 root@node2
node3# ssh node1
node3# ssh node2

Pandora FMS ノードで、apache ユーザに “know_hosts” ファイルをコピーします。

pandorafms# yes | cp /root/.ssh/known_hosts /usr/share/httpd/.ssh/

次の手順は、ノードが非標準ポートで SSH を実行している場合にのみ必要です。 22 を正しいポート番号に置き換えます。

all# echo -e "Host node1\n    Port 22" >> /root/.ssh/config
all# echo -e "Host node2\n    Port 22" >> /root/.ssh/config
all# echo -e "Host node3\n    Port 22" >> /root/.ssh/config

必要なパッケージをインストールします。

node3# yum install -y http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
node3# yum install -y Percona-Server-server-57 percona-xtrabackup-24

Percona サービスはクラスタによって管理されるため、無効にしてください。

node3# systemctl stop mysqld
node3# systemctl disable mysqld

Percona を設定し、<ID> を各クラスタノード専用の番号に置き換えます。

Once the server is installed, you will find the configuration builder for database replication at the path:

サーバをインストールしたら、次のパスにデータベースレプリケーション用の設定ビルダーが見つかります。

/usr/share/pandora_server/util/myconfig_ha_gen.sh

Example: ./myconfig_ha_gen.sh -i serverid [-l file_location] [-d database] [-b binlog] [-u dbuser] [-p dbpass] [-s poolsize] [-h help]
Mandatory parameters:
    -i --serverid Set the server id for the database (Mandatory)
Optional parameters:
    -l --location Set my.cnf custom location including filename. [ default value: /etc/my.cnf ] (optional)
    -d --database Set the database to be replicated. [ default value: pandora ] (optional)
    -b --binlog Set binlog file. [ default value: mysql-bin ] (optional)
    -u --dbuser Set dbuser for mysql connection and backups. [ default value: root ] (optional)
    -p --dbpass Set dbpassword for mysql connection and backups. [ default value: pandora ] (optional)
    -s --poolsize Set innodb_buffer_pool_size static size in M (Megabytes) or G (Gigabytes). [ default value: autocalculated ] (optional)
    -h --help Print help.

In the current case where the databases are not on the same server as the application, it will be necessary to copy the script to the nodes to be executed locally.

データベースがアプリケーションと同じサーバ上にない現在のケースでは、スクリプトをノードにコピーしてローカルで実行する必要があります。

pandorafms#
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node3:/root/

It will only be necessary to pass the parameter serverid (mandatory) in standard environments and some optional parameters for custom environments.

標準環境ではパラメータ serverid (必須) を渡すだけでよく、カスタム環境ではいくつかのオプションのパラメーターを渡す必要があります。

If the default or defined user does not connect to the database, the script will end with a connection error.

デフォルトまたは定義されたユーザがデータベースに接続できない場合、スクリプトは接続エラーで終了します。

You also have the possibility of passing database name, user and password as arguments. Otherwise, the default settings will be used.

データベース名、ユーザ、およびパスワードを引数として渡すこともできます。 それ以外の場合は、デフォルト設定が使用されます。

In this case, it will execute the script on both nodes, only passing the server id if it has the default credentials, otherwise it must define the necessary parameters.

この場合、両方のノードでスクリプトを実行し、デフォルトの認証情報がある場合は server id のみを渡します。それ以外の場合は、必要なパラメーターを定義する必要があります。

node3#
/root/myconfig_ha_gen.sh -i 3

Percona サーバを起動します。

node3# systemctl start mysqld

新しい一時パスワードが生成され、/var/log/mysqld.log に書かれます。 Percona サーバにログインして、root パスワードを変更します。

node3# mysql -uroot -p$(grep "temporary password" /var/log/mysqld.log | \
rev | cut -d' ' -f1 | rev)
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
mysql> UNINSTALL PLUGIN validate_password;
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
mysql> quit

Back up the database of the master node (node1 in this example) connect to Percona server and type in the name and position of the master log file (in the example mysql - bin.00001 and 785:

マスターノード(この例では node1)のデータベースをバックアップし、マスターログファイルの名前と位置(この例では mysql-bin.000001 および 785)を書き留めます。

node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# cat /root/pandoradb.bak/xtrabackup_binlog_info 
mysql-bin.000001        785

Load the database on the new node, which we will call node3 and configure to replicate from node1 (configure MASTER_LOG_FILE and MASTER_LOG_POS to the values found in the previous step):

新規ノード node3 にデータベースをコピーし、node1 から複製するように設定します(MASTER_LOG_FILE およびMASTER_LOG_POS を前の手順で見つかった値に設定します)。

node3# systemctl stop mysqld

node1# rsync -avpP -e ssh /root/pandoradb.bak/ node3:/var/lib/mysql/

node3# chown -R mysql:mysql /var/lib/mysql
node3# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node3# systemctl start mysqld
node3# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000002
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node3-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000002
                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: 785
                 Relay_Log_Space: 1252
                 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: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave 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: 
   1 row in set (0.00 sec)
mysql> QUIT

node3# systemctl stop mysqld

必要なパッケージをインストールします。

node3# yum install -y epel-release corosync ntp pacemaker pcs

node3# systemctl enable ntpd
node3# systemctl enable corosync
node3# systemctl enable pcsd

node3# systemctl start ntpd

新たなノードをクラスタに追加します。

node3# echo -n hapass | passwd hacluster --stdin
node3# cd /usr/lib/ocf/resource.d/
node3# mkdir percona
node3# cd percona
node3# curl -L -o pacemaker_mysql_replication.zip https://pandorafms.com/library/wp-content/uploads/2019/12/pacemaker_mysql_replication.zip
node3# unzip pacemaker_mysql_replication.zip
node3# rm -f pacemaker_mysql_replication.zip
node3# chmod u+x mysql

node1# pcs cluster auth -u hacluster -p hapass --force node3
node1# pcs cluster node add --enable --start node3

clone-max をクラスタ内のノード数(この例では 3)に設定します。

node3# pcs resource update master_pandoradb meta master-max="1" \
master-node-max="1" clone-max="3" clone-node-max="1" notify="true" \
globally-unique="false" target-role="Master" is-managed="true"

ノードの状態を確認します。

node3# pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Fri Jun  1 10:55:47 2018
Last change: Fri Jun  1 10:55:09 2018 by root via crm_attribute on node3

3 nodes configured
3 resources configured

Online: [ node1 node2 node3 ]

Full list of resources:

pandoraip      (ocf::heartbeat:IPaddr2):       Started node1
Master/Slave Set: master_pandoradb [pandoradb]
    Masters: [ node1 ]
    Slaves: [ node2 node3 ]

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

“サーバ(Servers → データベース HA 管理(Manage database HA)” メニューから Pandora コンソールにクラスタノードを登録します。

例として node2 を用います。node2 をスタンバイモードにします。

node2# pcs node standby node2
node2# pcs status
    Cluster name: pandoraha
    Stack: corosync
    Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
    Last updated: Tue Jun 12 08:20:49 2018
    Last change: Tue Jun 12 08:20:34 2018 by root via cibadmin on node2
    
    2 nodes configured
    3 resources configured
    
    Node node2: standby
    Online: [ node1 ]
    
    Full list of resources:
    
     Master/Slave Set: master_pandoradb [pandoradb]
         Masters: [ node1 ]
         Stopped: [ node2 ]
     pandoraip      (ocf::heartbeat:IPaddr2):       Started node1
    
    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

Percona のデータディレクトリをバックアップします。

node2# systemctl stop mysqld
node2# [ -e /var/lib/mysql.bak ] && rm -rf /var/lib/mysql.bak
node2# mv /var/lib/mysql /var/lib/mysql.bak

マスターノード(この例では node1 です)のデータベースをバックアップし、マスターのログファイル名とポジションを記録します(この例では mysql-bin.000001 および 785 です)。

node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# binlog_info=$(cat /root/pandoradb.bak/xtrabackup_binlog_info)
node1# crm_attribute --type crm_config --name pandoradb_REPL_INFO -s mysql_replication \
-v "node1|$(echo $binlog_info | awk '{print $1}')|$(echo $binlog_info | awk '{print $2}')"

障害が発生したノードへデータベースをコピーします。

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

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

node2 のスタンバイモードを無効化します。

node2# pcs node unstandby node2
node2# pcs resource cleanup --node node2

クラスタの状態を確認します。

node2# pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Fri Jun  1 10:55:47 2018
Last change: Fri Jun  1 10:55:09 2018 by root via crm_attribute on node3

2 nodes configured
3 resources configured

Online: [ node1 node2 ]

Full list of resources:

pandoraip      (ocf::heartbeat:IPaddr2):       Started node1
Master/Slave Set: master_pandoradb [pandoradb]
    Masters: [ node1 ]
    Slaves: [ node2 ]

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

データベースのレプリケーション状態を確認します。

node2# mysql -uroot -ppandora
 mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000002
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node2-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000002
                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: 785
                 Relay_Log_Space: 1252
                 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: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave 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: 
   1 row in set (0.00 sec)

マスターノードが動作している限り、サービスには影響がありません。もしマスターノードで障害が発生した場合は、スレーブが自動的にマスターに昇格します。詳細は、 障害ノードの修正 を参照してください。

ニーズに依存します:

1. スタンドアローン(高可用性なし)で、最大 2500エージェント / 50000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースなし

サーバ数: 1 (共有)

メイン:
----------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

2. スタンドアローン(高可用性なし)で、最大 2500エージェント / 50000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり

サーバ数: 2 (1 共有, 1 ヒストリ DB)

メイン:
----------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

ヒストリDB:
----------
CPU: 2 cores
RAM: 4 GB
Disk: 200GB

3. スタンドアローン(高可用性無し)で、最大 5000エージェント / 100000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり(1年保存)

サーバ台数: 3 (1 サーバ + コンソール, 1 メイン DB, 1 ヒストリ DB)

サーバ + コンソール:
-------------------
CPU: 6 cores
RAM: 8 GB
Disk: 40GB

メイン DB:
------------------------
CPU: 4 cores
RAM: 8 GB
Disk: 100GB

ヒストリ DB:
----------
CPU: 2 cores
RAM: 4 GB
Disk: 200GB

1. データベースがシンプルな HA 構成、最大 7500エージェント / 125000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり(1年保存)

サーバ数: 4 (1 サーバ + コンソール, 2 DB, 1 ヒストリ DB)
 
 サーバ + コンソール:
 -------------------
 CPU: 6 cores
 RAM: 8 GB
 Disk: 40GB
 
 データベースノード 1:
 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disk: 100GB
 
 データベースノード 2:
 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disk: 100GB
 
 ヒストリ DB:
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disk: 300GB

2. データベースが完全な HA 構成(3台構成)、最大 7500エージェント / 125000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり(1年保存)

サーバ数: 5 (1 サーバ + コンソール, 3 DB, 1 ヒストリ DB)

サーバ + コンソール:
------------------
CPU: 6 cores
RAM: 8 GB
Disk: 40GB

データベースノード 1:
---------------------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

データベースノード 2: 
---------------------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

データベースノード 3:
---------------------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

ヒストリ DB:
----------
CPU: 2 cores
RAM: 4 GB
Disk: 200GB

3. データベースがシンプルな HA 構成、Pandora FMS が負荷分散 HA で、最大 7500エージェント / 125000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり(1年保存)

サーバ数: 5 (2 サーバ + コンソール, 2 DB, 1 ヒストリ DB)

サーバ + コンソール ノード1:
-------------------
CPU: 6 cores
RAM: 8 GB
Disk: 40GB

サーバ + コンソール ノード2:
-------------------
CPU: 6 cores
RAM: 8 GB
Disk: 40GB

データベースノード 1:
---------------------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

データベースノード 2:
---------------------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

ヒストリ DB:
----------
CPU: 2 cores
RAM: 4 GB
Disk: 200GB

4. サーバが基本的な負荷分散 HA、マスター・スレーブのデータベース、最大 4000エージェント / 90000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり(1年保存)

サーバ数: 3 (2 共有, 1 ヒストリ DB)

メイン: (コンソール + サーバ + データベース ノード 1)
----------
CPU: 8 cores
RAM: 12 GB
Disk: 100GB

セカンダリ: (コンソール + サーバ + データベース ノード 2)
----------
CPU: 8 cores
RAM: 12 GB
Disk: 100GB

ヒストリ DB:
----------
CPU: 2 cores
RAM: 4 GB
Disk: 200GB

このスキーマでは、Pandroa FMS データベースのノードは、2台それぞれのサーバで(マスター・スレーブ構成で)設定します。

30,000 エージェント、500,000 モジュールを監視する必要がある場合、要求を満たすために必要な数のノードを設定する必要があります。以下に例を示します。

HA #1 の設計を選択した場合(1 サーバ + コンソール, 2 HA構成のデータベースノード, ヒストリ DB)、30,000 / 7500 = 4 つのセットを設定します。

全体の環境を管理するには、全体を一元管理できるメタコンソールのインストールが必要です。

メタコンソールに必要なリソースは以下の通りです。

サーバ数: 1 (共有)

メイン:
----------
CPU: 8 cores
RAM: 12 GB
Disk: 100GB

ヒストリ DB を個別に用意した場合のサーバトータル数: 17

ヒストリ DB を集約した場合のサーバトータル数: 13

集約したヒストリ DB:
--------------------
CPU: 8 cores
RAM: 12 GB
Disk: 1200GB