冗長化構成(HA)

概要

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

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

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

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

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

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

HA のサイジングとアーキテクチャ設計

Pandora FMS における最も重要なコンポーネントは次の通りです。

  1. データベース
  2. サーバ
  3. コンソール

各コンポーネントは、あらゆる障害から監視システムを保護するために冗長構成を組むことができます。

負荷をバランシングするために必要なノード数を決定するためには、監視対象の数と監視間隔を知る必要があります。

監視のニーズによって、異なるアーキテクチャを決定します。

注意: アーキテクチャを決めるためのテストは、以下の複数の環境を使用して行っています。

Intel (R) Core (TM) i5-8600K CPU @ 3.60GHz

Amazon であれば、インスタンス <i> t2.large </i> https://aws.amazon.com/en/ec2/instance-types/t2/

サイジング

ニーズに依存します:

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

サーバ数: 1 (共有)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大規模環境では、前述の構成スキームを 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

全ヒストリ DB (4台) を一つのサーバに集約するには、負荷を考慮してサイズを変更する必要があります。

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

データサーバの HA

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

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

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

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

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

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

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

ソフトウエアエージェントでのバランシング

ソフトウエアエージェントで、データサーバのバランシングを行うことができます。データサーバの一方をマスター、もう一方をバックアップとして設定することができます。

エージェントの設定ファイル 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

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

  • 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台目のマスターサーバがダウンしたサーバに割り当てられていたモジュールの実行を自分自身に割り当てます。ダウンしたサーバが復旧した場合は、再度モジュールの実行が自動的にプライマリサーバに割り当てられます。

異なるサーバ間でのロードバランシングは、エージェント管理(Agent Administration) の設定メニューで実施します。

“サーバ(server)” フィールドにて、監視を実行するサーバを選択することができます。

サーバの設定

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

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

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

/etc/pandora/pandora_server.confmaster の設定が 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

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

リモート設定を使用する場合、双方のデータサーバとコンソールは、データ入力ディレクトリ(/var/spool/pandora/data_in)配下の configuration、collections その他を共有する必要があります。

こちらのガイドで、必要なフォルダを NFS または GlusterFS で共有する方法を確認できます。

サーバのパフォーマンスに影響するため、data_in 以下のサブディレクトリのみ共有し、data_in 自体は共有しないことが重要です。

更新

HA 環境で Pandora FMS コンソールを更新する際に、アップデートマネージャ https://pandorafms.com/docs/index.php?title = Pandora:Documentation_ja:Anexo_Upgrade を介して OUM を使用して更新する場合は、次の点に考慮することが必要です。

Enterprise 版のユーザは、Pandora FMS サポートサイトから OUM パッケージをダウンロードできます。

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

oum1.jpg

oum2.jpg

データベース HA

これは、Pandora FMS 環境において完全な HA を提供するソリューションです。これは、Pandora FMS で唯一公式にサポートされた HA モデルです。このソリューションは OUM 724 からあらかじめインストールされた状態で提供されています。このシステムは、以前お勧めしていた DRBD およびその他 HA システムを置き換えるものです。

これは、最初の Pandora DB HA の実装であり、導入処理は Linux コンソールで root を使うことによる、ほぼ手動です。将来のバージョンでは、GUI から簡単に設定できるようにする予定です。

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

これは、GNU/Linux システムの知識を必要とする高度な機能です。

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

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

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

データおよびイベントの保存は最大 15日をお勧めします。より長い期間の保存には、ヒストリデータベースの設定をお勧めします。Pandora FMS サーバの管理もご確認ください。

RHEL 8 および Rocky Linux 8 へのインストール

バージョン 760 およびそれ以降

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

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

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

node1#
<command>
<command>
<command>

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

all#
<command>
<command>
<command>

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

前提条件

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

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


OpenSSH で警告が出る設定されている場合、Pandora FMS HAデータベースツールは正しく機能しません。

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


“root 以外の” ユーザーを使用して後でクラスターをインストールするには、root 以外のユーザの鍵を生成できます。

all#
printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 [email protected]
ssh-copy-id -p22 [email protected]
pandorafms#
printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 [email protected]
ssh-copy-id -p22 [email protected]

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

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


次の手順は、ノードが非標準ポートで SSH を実行している場合にのみ必要です。

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

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

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

all#
ssh node1
ssh node2
pandorafms#
ssh node1
ssh node2

Percona のインストール

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

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

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


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

all#
systemctl disable mysqld


システムのサービスが無効化されていないと、クラスタのリソースマネージャが正しく動作しません。

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

all#
systemctl start mysqld

新規のテンポラリパスワードが生成され、/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

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

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

/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.

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

pandorafms#
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/

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

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

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

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

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


それぞれのノードは、ユニークな ID を持つ必要があります。


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

all#
systemctl restart mysqld

Pandora FMS のインストール

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

新規の Pandora FMS インストール

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

pandorafms#
/etc/init.d/pandora_server stop

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

既存の Pandora FMS へのインストール

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

pandorafms#
/etc/init.d/pandora_server stop

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

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

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

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

レプリケーション設定

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

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;

Pandora FMS のインストールを ISO イメージを利用してデータベースのインストールを行った場合、ノード2 から元のデータベースを削除します。両方のマシンからの情報を保存する node1 のデータベースのみが必要です。そうすることにより、バランシングが正しく行われます。

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

node2#
systemctl stop mysqld

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

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

2つ目のノード(node2)にデータベースをコピーし、1つ目のノードからレプリケーションをする設定をします。(上記のステップで記録しておいた MASTER_LOG_FILEMASTER_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

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

Slave_IO_RunningSlave_SQL_Running が Yes であることを確認します。その他の値は例とは異なります。

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

#node2
mysql> QUIT

2ノードクラスタ設定

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

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

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

設定を行い、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


corosync 開始時にエラーが表示される場合があります。それはまだ設定されていないためですので、無視して次のステップで設定します。

Percona サーバを停止します。

all#
systemctl stop mysqld

クラスタ内の全ノードの認証

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

all#
echo hapass | passwd hacluster --stdin

クラスタを作成し開始します。これらのステップは、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

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

node1#
pcs status

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


両方のノードがオンラインです。

( Online: [ node1 node2 ] ).

その他の値は例とは異なることがあります。

Percona の Pacemaker レプリケーションエージェントのインストール

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

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

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

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

このガイドで利用しているデータベースの root ユーザのデフォルトパスワードを変更する場合は、それぞれreplication_passwdtest_passwd を更新してください。クラスタリソースの名前は、このガイド(pandoraip および pandoradb)に示している通りである必要があります

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

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

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

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

pcs constraint colocation add master pandoradb-clone with pandoraip

pcs constraint order promote pandoradb-clone then start pandoraip

sleep 5 ; pcs resource cleanup

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

node1#
pcs status

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


両方のノードがオンラインになります。

( Online: [ node1 node2 ] ).

その他の値は例とは異なる場合があります。

root 以外のユーザでの 2ノードクラスタの設定

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

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

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

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

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

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

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

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

RedHat 7 および CentOS 7 へのインストール

バージョン 759 およびそれ以前

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

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

node1# <command>

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

all# <command>

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

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 [email protected]
 node1# ssh node2

 node2# echo -e "\n\n\n" | ssh-keygen -t rsa
 node2# ssh-copy-id -p22 [email protected]
 node2# ssh node1

 pandorafms# echo -e "\n\n\n" | ssh-keygen -t rsa
 pandorafms# ssh-copy-id -p22 [email protected]
 pandorafms# ssh-copy-id -p22 [email protected]
 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

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

パッケージをインストールしたら、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

MySQL 設定を実行するときに、デフォルトの Pandora FMS ISO で -ha をつけてインストールされている場合は、Pandora FMS Enteprise サーバのインストールパッケージに既に含まれている以下の自動生成を介してそれを行うことができます。

ISO を使用せずにサーバパッケージを手動でインストールした場合、HA サーバツールにアクセスするには、 -ha パラメーターを渡す必要があることに注意してください。

そのようにしていない場合は、-ha パラメーターを指定してサーバパッケージのみを再インストールする必要があります。サンプル環境では、2つのデータベースノード(node1 と node2)と 1つのアプリケーションノード(Pandorafms)があるため、pandora サーバパッケージは アプリケーションノードにのみインストールします。アプリケーションノードを Pandora iso(推奨オプション)からインストールする場合、この手順は必要ありません。それ以外の場合は、サーバパッケージを–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 [email protected]:/root/
 pandorafms# scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/

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

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

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

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

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

それぞれのノードはユニークな ID を持つ必要があります。

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

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

all# systemctl restart mysqld

Pandora FMS のインストール

新規の Pandora FMS インストール

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

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

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

pandorafms# /etc/init.d/pandora_server stop


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

既存の 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.000001785 です)

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 を指定します。)

Pandora FMS のインストールを ISO イメージを利用して行った場合、ノード2 から元のデータベースを削除します。両方のマシンからの情報を保存するノード1 のデータベースのみが必要です。そうすることにより、バランシングが正しく行われます。

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_RunningSlave_SQL_RunningYes であることを確認します。その他の値は例とは異なります。

この処理を実行するのに 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 のインストール

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

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

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

データベースの root ユーザのデフォルトパスワードを変更している場合は、関連して replication_passwd および test_passwd を更新してください。

クラスタのリソース名は、このガイドで示されているものと正確に一致する必要があります (“pandoraip” および “pandoradb”)

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

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

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

両方のノードがオンライン (Online: [ node1 node2 ]) である必要があります。その他の値は例とは異なります。

root 以外のユーザでの 2ノードクラスタの設定

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

# 全ノード:
 useradd <user>
 passwd <user>
 usermod -a -G haclient <user>
# PCS ACL システムの有効化
pcs property set enable-acl=true --force
# ロールの作成
pcs acl role create <rol> description="RW role"  write xpath /cib
# PCS ユーザの作成 - ローカルユーザ
pcs acl user create <user> <rol>
# 全ノードから PCS へログイン
su - <user>
pcs status
Username: <user>
Password: ***** 
# 'Authorized' メッセージを待ち出力は無視します。数秒待ったのち、'pcs status' コマンドを実行します。

Pandora FMS の設定

インストールした 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

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

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

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

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

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

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

Seconds behind master は 0 に近い必要があります。増加を続けている場合は、レプリケーションが遅いか動作していません。 データベースのレプリケーションについての詳細は、ブログ(英語)も確認してください。

スプリットブレーンからの自動復旧

シナリオ

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

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

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

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

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

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

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

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

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

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

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

クラスタへの新規ノードの追加

新しいノードで使用するバージョンに応じて、node1node2 をインストールするために実行した手順を繰り返します。

RHEL 8 または Rocky Linux 8 (Padnora FMS バージョン 760 以降)

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 [email protected]
node1# ssh node3
node2# ssh-copy-id -p22 [email protected]
node2# ssh node3
pandorafms# ssh-copy-id -p22 [email protected]
pandorafms# ssh node3
node3# echo -e "\n\n\n" | ssh-keygen -t rsa
node3# ssh-copy-id -p22 [email protected]
node3# ssh-copy-id -p22 [email protected]
node3# ssh node1
node3# ssh node2

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

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

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

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

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

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

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

node3# systemctl stop mysqld
node3# systemctl disable mysqld

システムサービスが無効になっていない場合、クラスタのリソースマネージャーは正常に動作しません。

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

2つのノードが同じ SERVER_ID を持っていると、レプリケーションが正しく動作しません。

node3# export SERVER_ID=<ID>
node3# export POOL_SIZE=$(grep -i total /proc/meminfo | head -1 | \
awk '{print $(NF-1)*0.4/1024}' | sed s/\\..*$/M/g)
node3# cat <<EOF> /etc/my.cnf
[mysqld]
server_id=$SERVER_ID

datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
log-error=/var/log/mysqld.log
show_compatibility_56=on

max_allowed_packet = 64M
# Recommendation: not to assign a value greater than 35% of available RAM memory
innodb_buffer_pool_size = $POOL_SIZE
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
wait_timeout = 900
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
log-bin=mysql-bin
query_cache_type = 1
query_cache_size = 32M
query_cache_limit = 8M
sql_mode=""
expire_logs_days=3

binlog-format=ROW
log-slave-updates=true
sync-master-info=1
sync_binlog=1
max_binlog_size = 100M
replicate-do-db=pandora
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 = 10
sync_relay_log_info = 10
slave_compressed_protocol = 1
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 10
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 1800

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[client]
user=root
password=pandora
EOF

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

マスターノード(この例では 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

新規ノード 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_RunningYes と表示される必要があります。他の値は例と異なる場合があります。

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

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_RunningYes であることを確認します。他の値は例とは異なります。

トラブルシューティング

クラスタノードの一つが動作していない場合に何をすれば良いでしょうか?

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