====== 冗長化構成(HA) ====== {{indexmenu_n>6}} [[ja:documentation:start|Pandora FMS ドキュメント一覧に戻る]] ===== 概要 ===== Pandora FMS はとても安定したアプリケーションになっています。(みなさんのテストのおかげで、それぞれのバージョンでは拡張が行われ、数百の不具合が報告され、修正されてきました。) しかし、クリティカルや高負荷な環境では、複数のサーバに処理を分散させることが可能です。Pandora FMS では、いずれかのコンポーネントで障害が発生しても、システム自体はダウンしません。 Pandora FMS は、細かいモジュールで設計されています。それぞれのモジュールは、独立して動作することができます。しかし、それぞれはまた、連携して動作することができ、負荷を分配することができます。 Pandora FMS の基本設計を以下に示します。 {{ :wiki:ha1.png }} もちろん、エージェントは冗長化構成ではありません。エージェントがダウンすると、モジュールの実行ができず、また、複数のエージェントを平行して実行することはできないため、またはシステム自体がダウンしているため、そのエージェントの全てのデータ収集はできなくなります。 重要なシステムに対する最良の解決策は、Pandora FMS エージェントのある無しに関わらず、冗長化しモニタリングすることです。 いくつかの場面において、次のような HA 構成が可能です。 * データサーバのバランシングと HA * ネットワーク、WMI、プラグイン、Web および予測サーバのバランシングと HA * データベースのロードバランシング * 自動検出サーバのバランシングと HA * Pandora FMS コンソールのバランシングと HA ===== データサーバの HA ===== 最も簡単な方法は、エージェントに実装されている HA を使用することです(プライマリが応答しない場合は代替サーバーに接続できます)。 ただし、データサーバはポート 41121 をサポートし、標準の TCP ポートであるため、通常の TCP サービスのバランシングまたはクラスタリングを可能にする商用ソリューションを使用することができます。 Pandora FMS データサーバでは、(異なるホスト名およびサーバ名で)設定された 2つの Pandora FMS データサーバを利用する必要があります。それぞれに tentacle サーバーを設定する必要があります。 各マシンは異なる IP アドレスを持ちます。 外部バランサを使用する場合、バランサにエージェントからのデータ送信用の接続 IP アドレス(VIP)を割り当てます。 外部バランサを使用していて、いずれかのサーバが故障した場合、アクティブなサーバにのみ接続するようになります。Pandora FMS エージェントは変更に気付くことなく、これまでと同様のアドレスへ接続します。しかし、この場合は、ロードバランサーは障害が発生したサーバにはデータを送信せず、アクティブな方にのみ送信します。 {{ :wiki:ha2.png?750 }} Pandora FMS データサーバの設定を変更する必要はありません。それぞれのサーバに別々の名前を設定してさえいえれば、サーバの状態ビューでいずれかがダウンしていることがわかり便利です。Pandora FMS データモジュールは、いずれかのサーバで処理することができます。事前のサーバ指定は不要です。簡単に HA 構成がとれるように設計されています。 エージェントの HA メカニズムを使用する場合は、データの送信にわずかな遅延があります。これは、エージェントの実行ごとにプライマリサーバとの接続を試みるためです。応答しない場合 セカンダリに対してこれを行います(設定されている場合)。これについては、次の "ソフトウエアエージェントでのバランシング" で説明します。 2つのデータサーバーを使用し、ポリシー、コレクション、およびリモート構成を管理する場合は、 [[:ja:documentation:07_technical_annexes:10_share_var_spool_directory_between_several_pandora_servers|サーバデータディレクトリの複数 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'' ===== ソフトウエアエージェントでのバランシング ===== ソフトウエアエージェントで、データサーバのバランシングを行うことができます。データサーバの一方をマスター、もう一方をバックアップとして設定することができます。 エージェントの設定ファイル 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 [[:en:documentation:02_installation:05_configuration_agents#general_agent_parameters|Agent configuration chapter]]). 次に示すオプションがあります。(詳細は、[[:ja:documentation:02_installation:05_configuration_agents#エージェントの一般的なパラメータ|エージェント設定の章]]を参照してください。) * **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、プラグイン、ウェブ、予測サーバのバランシングと HA ===== これは簡単です。複数のサーバに、ネットワーク、WMI、プラグイン、ウェブ、予測サーバを (モニタしたいシステムを見れるよう同じように) それぞれインストールします。複数のサーバは (ネットワーク遅延が同じになるように) 同一セグメントに置く必要があります。 それぞれのサーバはプライマリとして選択できます。それぞれのサーバは、他方がダウンした場合、そのサーバに割り当てられていた全てのモジュールデータの収集を自動的に引き継ぎます。Pandora FMS サーバには、最終接続時間 (サーバの threshold x 2) を確認して、他のサーバがダウンしていることを検知する仕組が実装されています。Pandora FMS サーバが 1台でも稼働していれば、他のサーバのダウンを検出することができます。すべての Pandora FMS サーバがダウンした場合は、検出する手段はありません。 2つのノードのシステムで HA およびロードバランシングを実装する簡単な方法は、それぞれのサーバに 50% ずつモジュールを割り当て、両方のサーバをマスターとして選択します。2つ以上のマスターサーバがあり、3台目がダウンした場合は、1台目のマスターサーバがダウンしたサーバに割り当てられていたモジュールの実行を自分自身に割り当てます。ダウンしたサーバが復旧した場合は、再度モジュールの実行が自動的にプライマリサーバに割り当てられます。 {{ wiki:ha3.png?550 }} ==== サーバの設定 ==== Pandora FMS サーバは、異なる 2つのモードで実行できます。 * マスターモード * 非マスターモード もしサーバがダウンすると、処理が止まらないように、そのサーバが持っていたモジュールはマスターサーバで実行されます。 ///etc/pandora/pandora_server.conf// で //master// の設定が 0 より大きい値になっているすべてのサーバから、一つのマスターサーバが選択されます。 master [1..7] もし現在のマスターサーバがダウンすると、新たなマスターサーバが選択されます。複数の候補がある場合は、//master// の値が最も高いものが選択されます。 サーバの無効化には注意してください。ネットワークモジュールを持つサーバがダウンした場合、他のマスターサーバでネットワークサーバが無効化されていると、モジュールは実行されません。 例えば、//master// を 1 に設定した 3台の Pandora FMS サーバがある場合、マスターサーバはランダムに選択され、他の 2台は非マスターモードで動作します。マスターサーバがダウンすると、新たなマスターがランダムに選択されます。 pandora_server.conf に以下のパラメータを設定できます。 * ''ha_file'': HA のテンポラリバイナリファイルの場所 * ''ha_pid_file'': HA の現在のプロセス ID ファイル * ''pandora_service_cmd'': Pandora サービスの状態制御 ==== Pandora FMS サーバの HA DB クラスタへの追加 ==== If [[:en:documentation:05_big_environments:06_ha#high_availability_database|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: [[:ja:documentation:05_big_environments:06_ha#高可用性データベース|データベースで高可用性が有効になっている]] 場合、より多くの 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 クラスタへアクセスするためのユーザ名を指定する必要があります。例: dbuser pandora * ''dbpass'': It must contain the user password to access the MySQL cluster. For example: * ''dbpass'': MySQL クラスタへアクセスするためのユーザのパスワードを指定する必要があります。例: 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 ===== Pandora FMS コンソールの HA ===== Just [[[:en:documentation:06_metaconsole:03_installation|install another console]] pointing to the database. Any of the consoles can be used simultaneously from different locations by different users. A [[https://pandorafms.com/guides/public/books/load-balancing-with-keepalived|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. 他のサーバに[[[:ja:documentation:06_metaconsole:03_installation|コンソールをインストール]]するだけです。それらのいずれからも、異なるユーザによって異なる場所から同時に使用することができます。 コンソールの前段で[[https://pandorafms.com/guides/public/books/load-balancing-with-keepalived|ロードバランサ]]を使用すると、セッションシステムが「クッキー」によって管理され、これがブラウザーに保管されるため、どちらがアクセスされているかを実際に知らなくてもアクセスできます。 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 [[:en:documentation:07_technical_annexes:15_security_architecture|"Security architecture"]]). リモート設定を使用する場合、双方のデータサーバとコンソールは、データ入力ディレクトリ (デフォルト: ''/var/spool/pandora/data_in'') 配下の configuration、collections その他を共有する必要があります。([[:ja:documentation:07_technical_annexes:15_security_architecture|"セキュリティアーキテクチャ"]] も参照ください。) It is important to only share subdirectories within ''data_in'' and not ''data_in'' itself as it will negatively affect server performance. サーバのパフォーマンスに影響するため、''data_in'' 以下のサブディレクトリのみ共有し、''data_in'' 自体は共有しないことが重要です。 ==== 更新 ==== 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** → [[:en:documentation:pandorafms:installation:02_anexo_upgrade|Update offline]]. The OUM package can downloaded from Pandora FMS support website. HA 環境で Pandora FMS コンソールを更新する場合、**管理(Management)** → **ワープアップデート(Warp update)** → [[:ja:documentation:pandorafms:installation:02_anexo_upgrade|オフラインアップデート]] を介して 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 main goal of this section is to offer a complete solution for HA in Pandora FMS environments. This is the only HA model with official support for Pandora FMS, **and it is provided from version 770 onwards**. This system replaces cluster configuration with **Corosync** and **Pacemaker** from previous versions. この章の主な目的は、Pandora FMS 環境での HA の完全なソリューションを提供することです。 これは、Pandora FMS で公式にサポートする唯一の HA モデルであり、**バージョン 770 以降で提供されています**。 このシステムは、クラスタ構成を以前のバージョンで利用していた Corosync と Pacemaker から置き換えます。 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 スプリットブレインが発生している場合は、システムは両方のノードが再びマージされるまで並行して機能します。 Starting with version 772, the HA was changed to make it simpler and less buggy. For this new HA, it is recommended to use SSD disks for a higher writing/reading speed (IOPS), minimum 500 Mb/s (or more, depending on the environment). The latency between servers must also be taken into account since with very high latencies it is difficult to synchronize both databases in time. バージョン 772 以降、HA はよりシンプルになり、バグが少なくなるように変更されました。 この新しい HA では、より高い書き込み/読み取り速度 (IOPS)、最低 500 Mb/s (環境によってはそれ以上) を実現する SSD ディスクを使用することをお勧めします。 待ち時間が非常に長いと、両方のデータベースを適時に同期することが困難になるため、サーバー間の待ち時間も考慮する必要があります。 The new proposal seeks to solve the current three problems: 新しい仕組では、現在の 3 つの問題を解決しようとしています。 - Complexity and maintainability of the current system (up to version NG 770). - Possibility of having an HA environment spread over different geographical locations with non-local network segmentation. - Data recovery procedure in case of split brain and secured system operation in case of communication breakdown between the two geographically separated sites. - 現在のシステムの複雑さと保守性 (バージョン NG 770 まで)。 - ローカル以外のネットワークセグメントの利用で、HA 環境が地理的に異なる場所に分散している場合。 - 地理的に離れた 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 の高可用性データベースクラスタにより、強力でフェイルセーフなアーキテクチャを簡単に展開できます。 This is an advanced feature that requires knowledge in GNU/Linux systems. It is important that all servers have the time synchronized with an NTP server (**chronyd** service in Rocky Linux 8). これは、GNU/Linux システムの知識を必要とする高度な機能です。 すべてのサーバの時刻が NTP サーバー (Rocky Linux 8 の **chronyd** サービス) で同期されていることが重要です。 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 [[http://dev.mysql.com/doc/refman/5.7/en/replication.html|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. アクティブ/スタンバイ[[http://dev.mysql.com/doc/refman/5.7/en/replication.html|レプリケーション]] は、単一のマスターノード (書き込み権限あり) から任意の数のセカンダリ (読み取りのみ）に対して行われます。マスターノードに障害が発生した場合、セカンダリの 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'' を含むサーバ。 {{ :wiki:pfms-database_cluster.png }} ==== Percona 8 のインストール ==== Version 770 or later. バージョン 770 以降 === RHEL 8 および Rocky Linux 8 への Percona 8 のインストール === 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 リポジトリをインストールする必要があります。 You must open a terminal window with **root** rights or as **root** user. You are solely responsible for this key. The following instructions indicate whether you should run instructions on all devices, on some devices or on one device in particular, please pay attention to the statements. **root** 権限で、または **root** ユーザとしてターミナルウィンドウを開く必要があります。各ユーザの責任において実行してください。次の手順には、すべてのデバイスで実行する必要があるもの、一部のデバイスで実行する必要があるもの、特定の 1 つのデバイスで実行する必要があものがあります。注釈に注意してください。 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 In case you install the Percona server together with the Web Console and the PFMS server, you will be able to use the deploy indicating the MySQL 8 version by means of the ''MYVER=80'' parameter: curl -Ls https://pfms.me/deploy-pandora-el8 | env MYVER=80 bash Percona サーバーを Web コンソールおよび Pandora FMS サーバと一緒にインストールする場合、''MYVER=80'' パラメーターを使用することで MySQL バージョン 8 デプロイするように指定できます。。 curl -Ls https://pfms.me/deploy-pandora-el8 | env MYVER=80 bash === Percona 8 の Ubuntu Server へのインストール === 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 ==== バイナリレプリケーション設定 ==== It is recommended that to store the //binlogs// generated by replication in an additional partition or external disk, its size must be the same as the one reserved for the database. See also the //token// ''log-bin'' and ''log-bin-index''. レプリケーションによって生成された //binlogs// を追加のパーティションまたは外部ディスクに保存することをお勧めします。そのサイズはデータベース用に予約されているサイズと同じである必要があります。 ''log-bin'' および ''log-bin-index'' //トークン//も参照してください。 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'' を設定して、バイナリレプリケーションが正しく機能するように準備します。 === ノード 1 === 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'' です。 //これらの値は、ユーザの入力無しに(自動化された)バックアップを実行するために **必要**です。// It is important that the ''server_id'' token is different in all nodes, in this example for node 1 this number is used. ''server_id'' トークンがすべてのノードで異なることが重要です。この例では、ノード 1 でこの番号が使用されています。 === ノード 2 === 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'' です。 //これらの値は、ユーザの入力無しに(自動化された)バックアップを実行するために **必要**です。// It is important that the ''server_id'' token is different in all nodes, in this example for node 2 this number is used. ''server_id'' トークンがすべてのノードで異なることが重要です。この例では、ノード 2 でこの番号が使用されています。 === マスターノード設定 === 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'' For the **source** command: As long as Pandora FMS console is installed in the same server, //otherwise send this file to the master server//. **source** コマンド: 同じサーバへ Pandora FMS コンソールをインストールしている場合。//そうでなければ、このファイルをマスターサーバへコピーします。// 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@'%';'' At this point you have the master server ready to start replicating Pandora FMS database. これで、Pandora FMS データベースのレプリケーションを開始するためのマスターサーバの準備が完了です。 === データベースの複製 === 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. この時点で、バイナリレプリケーションが有効になり、正しく動作していることを確認できます。 ==== pandora_server 設定 ==== Version 770 or later. バージョン 770 以降 It is necessary to configure inside [[:en:documentation:pandorafms:installation:04_configuration#server|the pandora_server.conf file]] a series of necessary parameters for the correct operation of the ''pandora_ha''. [[:ja:documentation:pandorafms:installation:04_configuration#サーバ|pandora_server.conf ファイル]] 内で、''pandora_ha'' が正しく動作するために必要な一連のパラメータを設定する必要があります。 The parameters to be added are the following: 追加するパラメータは次の通りです。 * **ha_hosts ,** : 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 ,** : 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_resync**''PATH_SCRIPT_RESYNC'' : By default the script to perform the resynchronization of the nodes, this is located at: * **ha_resync**''PATH_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 === サーバ間の SSH 鍵共有 === 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 * In case you have the installation on Ubuntu Server, enable the **root** user to connect via SSH. This is done by generating a password to the root user by executing the ''sudo passwd root'' command. * Then enable the SSH connection of the root user at least through shared keys "**PermitRootLogin without-password**" in the configuration file of the ''sshd'' service. * Ubuntu Server にインストールしている場合は、**root** ユーザが SSH 経由で接続できるようにします。 これは、''sudo passwd root'' コマンドを実行して root ユーザにパスワードを設定することによって行えます。 * 次に、''sshd'' サービスの設定ファイルにある "**PermitRootLogin without-password**" を使用して、root ユーザの SSH 接続を有効にします。 === 同期スクリプトの利用 === 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 [[#ks6_6|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. この処理は、開始、終了、およびそこでエラーが発生したかどうかを示すイベントをシステムで生成します。 ==== Pandora FMS コンソールの設定 ==== Version 770 or later. バージョン 770 以降 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 {{ :wiki:pfms-servers-manage_database_ha-view_nodes.png }} 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{{:wiki:pfms-servers-manage_database_ha-resync_node_icon.png?nolink&}}. 実行可能なアクションとしては、各ノードのラベルを設定することができ、{{:wiki:pfms-servers-manage_database_ha-resync_node_icon.png?nolink&}}アイコンにて **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. * **緑**: 正常、何の処理も実行されていない。 * **青**: 同期保留中。 * **黄**: 同期実行中。 * **赤**: //エラー//、同期失敗。 ==== Corosync-Pacemaker HA 環境マイグレーション ==== 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: "[[:en:documentation:07_technical_annexes:19_mysql_8|Installation and upgrade to MySQL 8]]". **1.-** **Percona** のバージョン 5.7 からバージョン 8.0 へのアップグレード: "[[:ja:documentation:07_technical_annexes:19_mysql_8|MySQL 8 のインストールとアップグレード]]" **2.-** Install **xtrabackup-80** on **all** devices: **2.-** **すべて**のデバイスで **xtrabackup-80** のインストール: yum install percona-xtrabackup-80 If you use Ubuntu server see section "[[:en:documentation:05_big_environments:06_ha#installing_percona_8_on_ubuntu_server|Percona 8 Installation for Ubuntu Server]]". Ubuntu server を利用している場合は、"[[:ja:documentation:05_big_environments:06_ha#percona_8_の_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.** **この問題を解決するには、次の手順でデータをマージすることができます。** This manual procedure **only** covers the retrieval of data and events between two dates. It assumes that it only recovers data from agents/modules that already exist in the node where a data merging is going to be performed. この手動手順は、2つの日付の間のデータおよびイベントの取得のみを対象としています。また、データマージが行われるノードに既に存在するエージェント/モジュールからデータを復旧することのみを想定しています。 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'' [[:en:documentation:05_big_environments:09_pandorafms_engineering#database_main_tables|tables]]. スプリットブレイン発生中に新しいエージェントが作成された場合、または新しい設定情報（アラート、ポリシーなど）がある場合、**これらは考慮されません**。取得されるのはデータとイベントのみです。つまり、''tagente_datos''、''tagente_datos_string''、''tevento'' [[:ja:documentation:05_big_environments:09_pandorafms_engineering#データベースのメインテーブル|テーブル]] に関するデータです。 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) At this point you can be sure that you have binary replication enabled and working properly again. この時点で、バイナリレプリケーションが有効になり、再び正しく動作していることを確認できます。 [[ja:documentation:start|Pandora FMS ドキュメント一覧に戻る]] ===== (OBSOLETE) データベース HA ===== これは、Pandora FMS 環境において完全な HA を提供するソリューションです。これは、Pandora FMS で唯一公式にサポートされた HA モデルです。このソリューションは OUM 724 からあらかじめインストールされた状態で提供されています。このシステムは、以前お勧めしていた DRBD およびその他 HA システムを置き換えるものです。 これは、最初の Pandora DB HA の実装であり、導入処理は Linux コンソールで root を使うことによる、ほぼ手動です。将来のバージョンでは、GUI から簡単に設定できるようにする予定です。 Pandora FMS は、設定とデータの保存のために MySQL データベースに依存しています。データベースの障害は、一時的に監視処理が停止することになります。Pandora FMS の高可用性データベースクラスタにより、冗長化、堅牢なアーキテクチャを実現します。 This is an advanced feature that requires knowledge of GNU/Linux systems. これは、GNU/Linux システムの知識を必要とする高度な機能です。 クラスタリソースは、高度でスケーラブルな HA クラスタリソースマネージャである [[https://github.com/ClusterLabs/pacemaker|Pacemaker]] によって管理されます。[[http://corosync.github.io/corosync/|Corosync]] は、複製された状態のマシンを作成するためのクローズドプロセスグループ通信モデルを提供します。スケーラビリティ、可用性、セキュリティおよびバックアップ機能のため、デフォルトの RDBMS としては [[https://www.percona.com/|Percona]] を選択しました。 アクティブ/スタンバイ [[https://dev.mysql.com/doc/refman/5.7/en/replication.html|レプリケーション]] では、一つのマスターノード(書き込み可)から、複数のスレーブ(読み出し専用)に同期します。仮想 IP アドレスは、常にマスターを示します。マスターノードが障害の場合は、スレーブのうちの 1つがマスターに昇格し、関連して仮想 IP が変更されます。 {{ wiki:ha_cluster_diagram.png }} Pandora FMS データベース HA ツール //pandora_ha// は、クラスタを監視し、Pandora FMS サーバが常に動作していることを確認します。必要な場合はそれを再起動します。//pandora_ha// 自身は systemd によって監視されます。 It is recommended to keep a maximum of 15 days of data and events, for longer storage a [[:en:documentation:05_big_environments:09_pandorafms_engineering#history_database|historical database should be set up]]. See also the topic "[[:en:documentation:05_big_environments:07_server_management#history_database|Management and administration of PFMS servers]]". データおよびイベントの保存は最大 15日をお勧めします。より長い期間の保存には、[[:ja:documentation:05_big_environments:09_pandorafms_engineering#ヒストリデータベース|ヒストリデータベースの設定]]をお勧めします。[[:ja:documentation:05_big_environments:07_server_management#ヒストリデータベース|Pandora FMS サーバの管理]]もご確認ください。 ==== RHEL 8 および Rocky Linux 8 へのインストール ==== Version 760 or later バージョン 760 およびそれ以降 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# Commands that **have to be executed on all nodes** will be preceded by the word **all**: **すてべのノードで実行する必要のある**コマンドは、**all** をつけています。 all# 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 \\ The Pandora FMS HA database tool will **not** work correctly if OpenSSH has a warning configured. \\ \\ OpenSSH で警告が出る設定されている場合、Pandora FMS HAデータベースツールは正しく機能しません。 Generate new SSH authentication keys for each host and copy the public key for each of the hosts. ホストごとに新しい SSH 認証キーを生成し、ホストごとに公開鍵をコピーします。 \\ You can generate keys for a user other than root for a later cluster installation with "non-root" user. \\ \\ "root 以外の" ユーザーを使用して後でクラスターをインストールするには、root 以外のユーザの鍵を生成できます。 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/ \\ The following steps are necessary only if the nodes run SSH on a non-standard port. \\ \\ 次の手順は、ノードが非標準ポートで 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 === Percona のインストール === 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 に関するより詳細なインストール処理は、公式ドキュメントを確認してください。 \\ [[https://www.percona.com/doc/percona-server/5.7/installation/yum_repo.html|https://www.percona.com/doc/percona-server/5.7/installation/yum_repo.html]] \\ \\ 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 \\ If the system service is not disabled, the cluster resource manager will **not** function correctly. \\ \\ システムのサービスが無効化されていないと、クラスタのリソースマネージャが正しく動作しません。 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 \\ Each node must have a unique identifier. \\ \\ 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. \\ それぞれのノードは、ユニークな ID を持つ必要があります。 \\ Percona 設定ファイルは ''/etc/my.cnf'' に書き込まれ、サーバ ID とデータベースレプリケーションの推奨設定が定義されます。 設定が正しく適用されていることを確認するには、mysqld サービスを再起動する必要があります。 all# systemctl restart mysqld === Pandora FMS のインストール === You can either perform a completely new installation or migrate the data you have from an existing instance. 完全に新規インストールを実行するか、既存のインスタンスからデータを移行することができます。 == 新規の Pandora FMS インストール == [[:en:documentation:02_installation:01_installing#installing|Install Pandora FMS]] in the newly created database. Stop the Pandora FMS server: 新規で作成するデータベースに [[:ja:documentation:02_installation:01_installing#pandora_fms_のインストール|Pandora FMS をインストール]]します。Pandora FMS サーバを停止します。 pandorafms# /etc/init.d/pandora_server stop From version NG 754 onwards you have [[:en:documentation:05_big_environments:07_server_management#manual_startupshutdown_for_pandora_fms_servers|additional options in the manual start and stop]] of High Availability Environments (HA). バージョン NG 754 以降では、高可用性(HA)環境に[[:ja:documentation:05_big_environments:07_server_management#pandora_fms_サーバの手動起動・停止|手動起動および停止のための追加のオプションがあります。]] == 既存の Pandora FMS へのインストール == 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: 次のような出力結果が得られます。 {{ :wiki:pfms-big_environments-ha-replication_configuration.png }} You must make sure that ''Slave_IO_Running'' and ''Slave_SQL_Running'' show **Yes**. //Other values may be different from the example//. ''Slave_IO_Running'' と ''Slave_SQL_Running'' が Yes であることを確認します。その他の値は例とは異なります。 If everything was correct exit the database interface: 全て正常であれば、データベースのインタフェースから抜けます。 #node2 mysql> QUIT === 2ノードクラスタ設定 === 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 \\ You may see an error message when trying to start the **corosync** service: this is because it is not yet configured, ignore it and continue with the following steps. \\ \\ **corosync** 開始時にエラーが表示される場合があります。それはまだ設定されていないためですので、無視して次のステップで設定します。 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: 次のような出力が得られます。 {{ :wiki:pfms-big_environments-ha-pcs_status.png }} \\ Both nodes should be online ( ''Online: [ node1 node2 ]'' ). //Other values may be different from the example.// \\ \\ 両方のノードがオンラインです。 ( ''Online: [ node1 node2 ]'' ). その他の値は例とは異なることがあります。 === Percona の Pacemaker レプリケーションエージェントのインストール === Pacemaker can be downloaded manually from the [[https://pandorafms.com/library/pacemaker-replication-agent-for-mysql/|PFMS library]]. Pacemaker は [[https://pandorafms.com/library/pacemaker-replication-agent-for-mysql/|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. クラスタリソースを設定します。 If the default password used in this guide for the database root user has been changed, it is advisable to update ''replication_passwd'' and ''test_passwd'' respectively. The names of the cluster resources must be exactly as indicated in this guide ( **pandoraip** and **pandoradb**) このガイドで利用しているデータベースの root ユーザのデフォルトパスワードを変更する場合は、それぞれ''replication_passwd'' と ''test_passwd'' を更新してください。クラスタリソースの名前は、このガイド(**pandoraip** および **pandoradb**)に示している通りである必要があります Replace **** with the preferred virtual IP address: **** は、好みの仮想 IP アドレスに置き換えます。 #node1 export VIP='' 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: 次のような出力が得られます。 {{ :wiki:pfms-big_environments-ha-pacemaker_status.png }} \\ Both nodes should be online ( ''Online: [ node1 node2 ]'' ). //Other values may be different from the example.// \\ \\ 両方のノードがオンラインになります。 ( ''Online: [ node1 node2 ]'' ). その他の値は例とは異なる場合があります。 === root 以外のユーザでの 2ノードクラスタの設定 === It will be done in a [[:en:documentation:05_big_environments:06_ha#two-node_cluster_configuration|similar way to the previous one]]. [[:ja:documentation:05_big_environments:06_ha#ノードクラスタ設定|前述の内容と同じように実施]]します。 The user's credentials must have been copied, previously explained, and the following steps must be carried out: すでに説明しているように、ログイン情報はコピーされている必要があり、以下のステップを実行する必要があります。 # All nodes: useradd passwd usermod -a -G haclient # Enable PCS ACL system pcs property set enable-acl=true --force # Create role pcs acl role create description="RW role" write xpath /cib # Create PCS user - Local user pcs acl user create # Login into PCS from ALL nodes su - pcs status Username: Password: ***** # Wait for 'Authorized' message, ignore output. Wait a second and retry 'pcs status' command ==== RedHat 7 および CentOS 7 へのインストール ==== Version 759 or earlier バージョン 759 およびそれ以前 Configure a two-node cluster, with hosts //node1// and //node2//. Change hostnames, passwords, etc. as needed to match your environment. //node1// および //node2// の 2つのノードのクラスタを設定します。環境に合わせて、ホスト名、パスワードなどを変更します。 一方のノードで実行するコマンドにについては、ノードのホスト名を前に表示します。例: node1# すべてのノードで実行するコマンドについては、**all** を前に表示します。例: all# さらに、Pandora FMS がインストールされているノードを **pandorafms** とします。 When referencing **all** it only refers to the Database nodes, the additional Pandora FMS node will always be referenced as **pandorafms** and is not part of **all**. **all** を参照した場合、それはデータベースノードのみです。追加の Pandora FMS ノードは常に **pandorafms** として参照され、 **all** の一部ではありません。 === 前提条件 === 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 Pandora FMS データベース HA ツールは、OpenSSH のバナーを調整していないと正しく動作しません。 それぞれのホストで SSH 認証鍵を生成し、公開鍵を他のホストへコピーします。 root 以外のユーザを使用した設定を行う場合は、root 以外のユーザで鍵を生成します。 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 === Percona のインストール === 必要なパッケージをインストールします。 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|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|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 each node must have a unique ID. それぞれのノードはユニークな ID を持つ必要があります。 Percona の設定ファイルは /etc/my.cnf に書き込まれ、サーバ ID とデータベースレプリケーションの推奨設定が定義されます。 mysqld サービスを再起動して、設定が正しく適用されていることを確認します。 all# systemctl restart mysqld === Pandora FMS のインストール === ==新規の Pandora FMS インストール== [[:en:documentation:02_installation:01_installing|Install Pandora FMS]] on the newly created database. For more information see: 新規で作成するデータベースに [[:ja:documentation:02_installation:01_installing|Pandora FMS をインストール]]します。詳細は以下を参照してください。 https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_ja:Installing Pandora FMS サーバを停止します。 pandorafms# /etc/init.d/pandora_server stop \\ From version NG 754 onwards, [[:en:documentation:05_big_environments:07_server_management#manual_startupshutdown_for_pandora_fms_servers|additional options are available for manual startup and shutdown]] of High Availability (HA) environments.\\ \\ バージョン NG 754 以降では、高可用性(HA)環境に[[:ja:documentation:05_big_environments:07_server_management#pandora_fms_サーバの手動起動・停止|手動起動および停止のための追加のオプションがあります。]]\\ ==既存の Pandora FMS へのインストール== 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 **Slave_IO_Running** と **Slave_SQL_Running** が **Yes** であることを確認します。その他の値は例とは異なります。 この処理を実行するのに **root** を **利用しない** ようにしてください。競合の可能性を回避するために、データベースの管理を担当するユーザにアクセス権限を付与することをお勧めします。 === 2ノードクラスタの設定 === 必要なパッケージをインストールします。 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 両方のノードがオンライン (**Online: [ node1 node2 ]**) である必要があります。その他の値は例とは異なります。 == Percona pacemake replication agent のインストール == これは、我々の [[https://pandorafms.com/library/pacemaker-replication-agent-for-mysql/|ライブラリ]] からダウンロードできます。 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 クラスタリソースを設定します。**** をあらかじめ決めておいた仮想 IP アドレスに置き換えます。 データベースの root ユーザのデフォルトパスワードを変更している場合は、関連して //replication_passwd// および //test_passwd// を更新してください。 クラスタのリソース名は、このガイドで示されているものと正確に一致する必要があります ("pandoraip" および "pandoradb") node1# export VIP= 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 両方のノードがオンライン (**Online: [ node1 node2 ]**) である必要があります。その他の値は例とは異なります。 === root 以外のユーザでの 2ノードクラスタの設定 === It will be done [[:en:documentation:05_big_environments:06_ha#two_node_cluster_configuration|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: [[:ja:documentation:05_big_environments:06_ha#ノードクラスタの設定|前述の内容と同じように実施]]します。すでに説明しているように、ログイン情報はコピーされている必要があり、以下のステップを実行する必要があります。 # 全ノード: useradd passwd usermod -a -G haclient # PCS ACL システムの有効化 pcs property set enable-acl=true --force # ロールの作成 pcs acl role create description="RW role" write xpath /cib # PCS ユーザの作成 - ローカルユーザ pcs acl user create # 全ノードから PCS へログイン su - pcs status Username: Password: ***** # 'Authorized' メッセージを待ち出力は無視します。数秒待ったのち、'pcs status' コマンドを実行します。 ==== Pandora FMS の設定 ==== 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 **** by the virtual IP address): Pandora FMS の DB 参照先をマスターの仮想 IP アドレスにします。(**** を仮想 IP アドレスに置き換えます。) pandorafms# export VIRT_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)// へ行きます。 {{ :wiki:manage_ha_menu.png }} Click on **Add new node** and create an entry for the first node: **新規ノード追加(Add new node)** をクリックし、1つ目のノードのエントリを作成します。 {{ :wiki:manage_ha_add_node.png }} Next, click **Register** and add an entry for the second node. You should see something similar to this: 次に、**登録(Register)** をクリックし、2つ目のノードのエントリを追加します。次のような画面が表示されます。 {{ :wiki:manage_ha_view.png }} ''Seconds behind master'' should be close to ''0''. **If it keeps increasing, replication is done at the wrong speed or it is nor working**. If you wish to learn more about database replication, [[http://pandorafms.com/blog/postgresql10/|check out our blog]] ''Seconds behind master'' は ''0'' に近い必要があります。**増加を続けている場合は、レプリケーションが遅いか動作していません。** データベースのレプリケーションについての詳細は、[[http://pandorafms.com/blog/postgresql10/|ブログ]](英語)も確認してください。 ==== スプリットブレーンからの自動復旧 ==== **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つのノード(実際にメインまたはマスターとして機能しているノード)にのみ存在します。 {{ :wiki:pfms-ha-view_nodes.png }} At this point, if the //token// [[:en:documentation:02_installation:04_configuration#splitbrain_autofix|splitbrain_autofix]] is set to 1, the node recovery process will be started at //splitbrain//. この時、//トークン// [[:ja:documentation:02_installation:04_configuration#splitbrain_autofix|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 マスター'' があるホストでの、権限のあるレプリケーションユーザの設定 {{ :wiki:pfms-servers-manage_database_ha-setup_values.png }} * 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**: 上記のすべてのポイントが正しく設定されている場合、**回復処理は次のようになります**： - Delete the previous //backups//. - Back up the ''datadir'' of the secondary node (//Slave)//. - Performs backup of the main node (//Master)//. - Sends backup of the main node to the secondary node (//Master// -> //Slave)//. - Starts the resource of the "secondary" ("Slave") node with the corresponding resynchronization parameters at the time of the backup. - Checks that the resource is active and correct. For this it will make use of the configuration indicated in the parameters [[:en:documentation:02_installation:04_configuration#ha_max_resync_wait_retries|ha_max_resync_wait_retries]] and [[:en:documentation:02_installation:04_configuration#ha_resync_sleep|ha_resync_sleep]] . - 以前の//バックアップ//を削除 - セカンダリノード(//スレーブ//)の ''datadir'' をバックアップ - メインノード(//マスター//) のバックアップ - メインノードのバックアップをセカンダリノードへ送信 (//マスター// -> //スレーブ//) - バックアップ時の再同期パラメータを使用して、"セカンダリ" ("スレーブ") ノードのリソースを開始 - リソースが有効で正しいか確認。これには、[[:ja:documentation:02_installation:04_configuration#ha_max_resync_wait_retries|ha_max_resync_wait_retries]] および [[:ja:documentation:02_installation:04_configuration#ha_resync_sleep|ha_resync_sleep]] のパラメータで示されている設定を利用します If at some point in the process it fails, it will repeat it again the times indicated through the parameter [[:en:documentation:02_installation:04_configuration#ha_max_splitbrain_retries|ha_max_splitbrain_retries]]. 処理のある時点で失敗した場合は、パラメータ [[:ja:documentation:02_installation:04_configuration#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**. それでも環境が自動的にリカバリされない場合は、セカンダリ(スレーブ)ノードがスタンバイのままになり、**イベント表示でリカバリを手動で実行する必要があることを示すイベントが表示されます**。 ==== クラスタへの新規ノードの追加 ==== Repeat the steps performed to install **node1** and **node2**, depending on the version to be used on the new node: [[:en:documentation:05_big_environments:06_ha#installation_for_rhel_8_and_rocky_linux_8|RHEL 8 o Rocky Linux 8 (PFMS version 760 or later)]]. [[:en:documentation:05_big_environments:06_ha#installation_on_redhat_7_and_centos_7|RedHat 7 or CentOS 7 (PFMS version 759 or earlier)]]. 新しいノードで使用するバージョンに応じて、**node1** と **node2** をインストールするために実行した手順を繰り返します。 [[:ja:documentation:05_big_environments:06_ha#rhel_8_および_rocky_linux_8_へのインストール|RHEL 8 または Rocky Linux 8 (Padnora FMS バージョン 760 以降)]] [[:ja:documentation:05_big_environments:06_ha#redhat_7_および_centos_7_へのインストール|RedHat 7 または CentOS 7 (Pandora FMS バージョン 759 以前)]] 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 認証キーを生成し、公開キーを他の各ホストにコピーします。 非 root ユーザを使用したクラスターインストールでは、非 root ユーザのキーを生成します。 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 を設定し、**** を各クラスタノード専用の番号に置き換えます。 2つのノードが同じ **SERVER_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 **Slave_IO_Running** および **Slave_SQL_Running** が **Yes** と表示される必要があります。他の値は例と異なる場合があります。 必要なパッケージをインストールします。 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 すべてのノードがオンラインである必要があります(''Online: [ node1 node2 node3 ]'')。他の値は例と異なる場合があります。 "サーバ(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 node2 がスタンバイ(**Node node2: standby**)である必要があります。他の値は例とは異なります。 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 双方のノードがオンライン(**Online: [ node1 node2 ]**)である必要があります。他の値は例とは異なります。 データベースのレプリケーション状態を確認します。 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) **Slave_IO_Running** および **Slave_SQL_Running** が **Yes** であることを確認します。他の値は例とは異なります。 ==== トラブルシューティング ==== === クラスタノードの一つが動作していない場合に何をすれば良いでしょうか? === {{ wiki:Manage_ha_failed.png }} マスターノードが動作している限り、サービスには影響がありません。もしマスターノードで障害が発生した場合は、スレーブが自動的にマスターに昇格します。詳細は、 [[ja:documentation:05_big_environments:06_ha#障害ノードの修正|障害ノードの修正]] を参照してください。 ===== (OBSOLETE) HA のサイジングとアーキテクチャ設計 ===== ==== サイジング ==== ニーズに依存します: 1. スタンドアローン(高可用性なし)で、最大 2500エージェント / 50000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースなし サーバ数: 1 (共有) メイン: ---------- CPU: 6 cores RAM: 8 GB Disk: 100GB {{ wiki:dim_std1.png?500 }} 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 {{ wiki:dim_std2.png?700 }} 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 {{ wiki:dim_std3.png?700 }} ==== HA のアーキテクチャ設計 ==== 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 {{ wiki:dim_ha1.png?700 }} 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 {{ wiki:dim_ha2.png?700 }} 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 {{ wiki:dim_ha3.png?700 }} 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台それぞれのサーバで(マスター・スレーブ構成で)設定します。 {{ wiki:dim_ha4.png?700 }} ** **For large environments, each of the configuration overviews previously described as computing nodes will be defined. 大規模環境では、前述の構成スキームを 1つのセットとして定義します。 ==== 例 ==== 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 To combine all the historical databases (4) in a single team, resize their characteristics to take on the extra load: 全ヒストリ DB (4台) を一つのサーバに集約するには、負荷を考慮してサイズを変更する必要があります。 集約したヒストリ DB: -------------------- CPU: 8 cores RAM: 12 GB Disk: 1200GB