Pandora: Documentation ja: HA

From Pandora FMS Wiki
Jump to: navigation, search

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

1 冗長化

1.1 概要

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

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

Ha1.png

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

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

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

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

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

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

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

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

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

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

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

Amazon であれば、インスタンス t2.large [1]

1.2.1 サイジング

ニーズに依存します:

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

サーバ数: 1 (共有)

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

Dim std1.png

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

Dim std2.png

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

Dim std3.png

1.2.2 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

Dim ha1.png

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

Dim ha2.png

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

Dim ha3.png

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台それぞれのサーバで(マスター・スレーブ構成で)設定します。

Dim ha4.png

注意: 大規模環境では、前述の構成スキームを1つのセットとして定義します。

1.2.3

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

1.3 データサーバの HA

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

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

外部バランサを使用していて、いずれかのサーバが故障した場合、アクティブなサーバにのみ接続するようになります。Pandora FMS エージェントは変更に気付くことなく、これまでと同様のアドレスへ接続します。しかし、この場合は、ロードバランサーは障害が発生したサーバにはデータを送信せず、アクティブな方にのみ送信します。Pandora FMS データサーバの設定を変更する必要はありません。それぞれのサーバに別々の名前を設定してさえいえれば、サーバの状態ビューでいずれかがダウンしていることがわかり便利です。Pandora FMS データモジュールは、いずれかのサーバで処理することができます。事前のサーバ指定は不要です。簡単に HA 構成がとれるように設計されています。

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

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

  • /var/spool/pandora/data_in/conf
  • /var/spool/pandora/data_in/collections
  • /var/spool/pandora/data_in/md5

Ha2.png

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

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

エージェントの設定ファイル 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: 転送に必要なその他オプションを設定します。

Template warning.png

エージェントのリモート設定が有効になっている場合、メインサーバでのみ操作できます。

 


1.5 ネットワーク、WMI、プラグイン、ウェブ、予測サーバのバランシングと HA

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

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

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



Ha3.png



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

Ha4.png


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

1.5.1 サーバの設定

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

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

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

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

master [1..7]

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

Template warning.png

サーバの無効化には注意してください。ネットワークモジュールを持つサーバがダウンした場合、他のマスターサーバでネットワークサーバが無効化されていると、モジュールは実行されません。

 


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

1.6 Pandora FMS コンソールのバランシングと HA

他のサーバにコンソールをインストールするだけです。それらのいずれからも、異なるユーザによって異なる場所から同時に使用することができます。 コンソールの前段でロードバランサを使用すると、セッションシステムが「クッキー」によって管理され、これがブラウザーに保管されるため、どちらがアクセスされているかを実際に知らなくてもアクセスできます。 リモート設定を使用する場合、双方のデータサーバとコンソールは、データ入力ディレクトリ(/var/spool/pandora/data_in)配下の configuration、collections その他を(NFSなどで)共有する必要があります。

1.7 データベース HA

Info.png

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

 


Template warning.png

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

 


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

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

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

Ha cluster diagram.png

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

Template warning.png

これは、Linux システムの知識が必要な高度な機能です。

 


1.7.1 インストール

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

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

node1# <command>

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

all# <command>

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

1.7.1.1 前提条件

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

Template warning.png

Pandora FMS データベース HA ツールは、OpenSSH のバナーを調整していないと正しく動作しません。

 


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

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

1.7.1.2 Percona のインストール

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

all# yum install -y http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm

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

Percona サービスが無効化されていることを確認します。これは、クラスタによって管理されます。

all# systemctl disable mysqld

Template warning.png

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

 


Percona の設定を行い、<ID> を各クラスタノードでユニークな番号にします。

Template warning.png

2つのノードが同一の SERVER_ID を持っていると、データベースレプリケーションが動作しません。

 


all# export SERVER_ID=<ID>
all# export POOL_SIZE=$(grep -i total /proc/meminfo | head -1 | \
awk '{print $(NF-1)*0.4/1024}' | sed s/\\..*$/M/g)
all# 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 = 256M
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
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 サーバを起動します。

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

1.7.1.3 Pandora FMS のインストール

1.7.1.3.1 新規の Pandora FMS インストール

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

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

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

pandorafms# /etc/init.d/pandora_server stop
1.7.1.3.2 既存の 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 < /tmp/pandoradb.sql
node1# systemctl stop mysqld

1.7.1.4 レプリケーション設定

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

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

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

Template warning.png

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

 


1.7.1.5 2ノードクラスタの設定

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

yum install -y epel-release corosync ntp pacemaker pcs

all# systemctl enable ntpd
all# systemctl enable corosync
all# systemctl enable pcsd

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

Percona サーバを停止します。

node1# systemctl stop mysqld

クラスタ内の全ノードを認証します。

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

all# echo hapass | passwd hacluster --stdin
all# cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf

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

Template warning.png

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

 


Percona pacemake replication agent をインストールします。

all# cd /usr/lib/ocf/resource.d/
all# mkdir percona
all# cd percona
all# curl -L -o mysql https://github.com/Percona-Lab/\
pacemaker-replication-agents/raw/1.0.0-stable/agents/mysql_prm
all# chmod u+x mysql

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

Template warning.png

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

 


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

Template warning.png

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

 


1.7.1.6 Pandora FMS の設定

php-pecl-ssh2 がインストールされていることを確認します。

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_ha サービスをインストールし、開始します。

pandorafms# cat > /etc/systemd/system/pandora_ha.service <<-EOF
[Unit]
Description=Pandora FMS Database HA Tool

[Service]
Type=forking

PIDFile=/var/run/pandora_ha.pid
Restart=always
ExecStart=/usr/bin/pandora_ha -d -p /var/run/pandora_ha.pid /etc/pandora/pandora_server.conf

[Install]
WantedBy=multi-user.target
EOF

pandorafms# systemctl enable pandora_ha
pandorafms# systemctl start pandora_ha

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

Manage ha menu.png

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

Manage ha add node.png

次に、スレーブの作成(Create slave) をクリックし、2つ目のノードのエントリを追加します。次のような画面が表示されます。

Manage ha view.png

Template warning.png

Seconds behind master は 0 に近い必要があります。増加を続けている場合は、レプリケーションが動作していません。

 


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

Percona をインストールします(Percona のインストール を参照) 。マスターノード(この例では 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

Template warning.png

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

 


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

node3# echo -n hapass | passwd hacluster --stdin
node3# cd /usr/lib/ocf/resource.d/
node3# mkdir percona
node3# cd percona
node3# curl -L -o mysql https://github.com/Percona-Lab/\
pacemaker-replication-agents/raw/master/agents/mysql_prm
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

Template warning.png

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

 


1.7.3 障害ノードの修正

例として 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

Template warning.png

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# cat /root/pandoradb.bak/xtrabackup_binlog_info 
mysql-bin.000001        785

障害が発生したノードへデータベースをコピーし、node1 からレプリケーションする設定を行います(MASTER_LOG_FILE および MASTER_LOG_POS を前述の手順で記録したものに設定します)。

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

node2# systemctl stop mysqld

Template warning.png

Slave_IO_Running および Slave_SQL_RunningYes であることを確認します。他の値は例とは異なります。

 


スタンバイモードから node2 を削除します。

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

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

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

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

Template warning.png

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

 


1.7.4 トラブルシューティング

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

Manage ha failed.png

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