個人用ツール

Pandora:Documentation ja:HA

提供: Pandora FMS Wiki JP

移動先: 案内, 検索

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

冗長化

概要

Pandora FMS is a very stable application (thanks to the test and improvements included in each version and to the correction of hundred of fails discovered by users.In spite of this, in critical environments and/or with much load, it is possible that it would be necessary to distribute the load in several machines, being sure that if any component of Pandora FMS fails, the system will not be down. Pandora FMS has been designed to it would be very modular. Any of its modules could work in an independent way. But it has also been designed to work with other components and for being able to take the load from those components that have been down.

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

The Pandora FMS standar design could be this one:

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

550px

Obviously, the agents are not redundants. If an agent is down,it makes no sense to execute another one, so the only cause for than an agent downs is that data could not be obtained because the execution of any module is failing, and this could not be solved with another agent running in parallel, or because the system is isolated or fails. The best solution is to make redundancy of the critical systems- regardless if they have Pandora FMS agents or not- and so to make redundancy or these systems monitoring.

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

It is possible to use HA in several scenaries:

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

  • Data Server Balancing and HA.
  • データサーバのバランシングと HA
  • Network Servers,WMI, Plugin, Web and Prediction Balancing and HA
  • ネットワーク、WMI、プラグイン、Web および予測サーバのバランシングと HA
  • DDBB Load Balancing.
  • データベースのロードバランシング
  • Recon Servers Balancing and HA.
  • 自動検出サーバのバランシングと HA
  • Pandora FMS Console Balancing and HA.
  • Pandora FMS コンソールのバランシングと HA

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

The most important components of Pandora FMS are:

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

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

Each of the components can be replicated to protect the monitoring system from any catastrophe.

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

To designate the number of nodes needed to balance the load, we will study the number of objectives to be monitored and the quantity, type and frequency of capture of the metrics to be collected.

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

Depending on the monitoring needs we will define the different architectures.

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

Note: The tests carried out to define the architectures have been carried out using different equipment:

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

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

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

Instance t2.large from Amazon [1]

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

サイジング

Depending on the needs:

ニーズに依存します:

1. Standalone (without high availability) up to 2500 agents / 50000 modules every 5 minutes, uniform data, no historical data

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

Servers: 1 (shared)

サーバ数: 1 (共有)

Main:
----------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

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

500px

2. Standalone (without high availability) up to 2500 agents / 50000 modules every 5 minutes, uniform data, with historical data (1 year)

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

Servers: 2 (1 shared, 1 historical)

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

Main:
----------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

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

Historical:
----------
CPU: 2 cores
RAM: 4 GB
Disk: 200GB

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

700px

3. Standalone (without high availability) up to 5000 agents / 100000 modules every 5 minutes, uniform data, with historical data (1 year)

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

Servers: 3 (1 server + console, 1 main database, 1 historical)
サーバ台数: 3 (1 サーバ + コンソール, 1 メイン DB, 1 ヒストリ DB)

Server + console:
-------------------
CPU: 6 cores
RAM: 8 GB
Disk: 40GB

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

Main database:
------------------------
CPU: 4 cores
RAM: 8 GB
Disk: 100GB

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

Historical:
----------
CPU: 2 cores
RAM: 4 GB
Disk: 200GB

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

700px

HA のアーキテクチャ設計

1. Database in simple HA, up to 7500 agents / 125000 modules every 5 minutes, uniform data, with historical data (1 year)

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

 Servers: 4 (1 server + console, 2 database, 1 historical)

 サーバ数: 4 (1 サーバ + コンソール, 2 DB, 1 ヒストリ DB)
 
 Server + console:
 -------------------
 CPU: 6 cores
 RAM: 8 GB
 Disk: 40GB

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

700px

2. Database in complete HA (with quorum), up to 7500 agents / 125000 modules every 5 minutes, uniform data, with historical data (1 year)

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

Servers: 5 (1 server + console, 3 database, 1 historical)

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

Server + console:
------------------
CPU: 6 cores
RAM: 8 GB
Disk: 40GB

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

Database node 1:
---------------------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

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

Database node 2: 
---------------------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

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

Database node 3:
---------------------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

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

Historical:
----------
CPU: 2 cores
RAM: 4 GB
Disk: 200GB

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

700px

3. Database in HA simple and Pandora FMS in HA balanced, up to 7500 agents / 125000 modules every 5 minutes, uniform data, with historical data (1 year)

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

Servers: 5 (2 server + console, 2 database, 1 historical)

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

Server + console:
-------------------
CPU: 6 cores
RAM: 8 GB
Disk: 40GB

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

Server + console:
-------------------
CPU: 6 cores
RAM: 8 GB
Disk: 40GB

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

Database node 1:
---------------------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

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

Database node 2:
---------------------
CPU: 6 cores
RAM: 8 GB
Disk: 100GB

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

Historical:
----------
CPU: 2 cores
RAM: 4 GB
Disk: 200GB

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

700px

4. Basic HA balanced on server, main and replica database, up to 4000 agents / 90000 modules every 5 minutes, uniform data, with historical data (1 year)

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

Servers: 3 (2 shared, 1 historical)

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

Main: (console + server + database node 1)
----------
CPU: 8 cores
RAM: 12 GB
Disk: 100GB

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

Secondary: (console + server + database node 2)
----------
CPU: 8 cores
RAM: 12 GB
Disk: 100GB

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

Historical:
----------
CPU: 2 cores
RAM: 4 GB
Disk: 200GB

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

In this scheme the nodes of the Pandora FMS database are configured in each of the two available servers (main and secondary).

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

700px

Note: For large environments, we will define each of the configuration schemes previously described as compute nodes .

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

If you need to monitor 30,000 agents with 500,000 modules, you must configure as many nodes as necessary to cover these requirements. Following the example:

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

If we choose the HA # 1 design (1 server + console, 2 database nodes in HA, and a historical database), we will have to configure 30,000 / 7500 = 4 nodes.

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

To manage the entire environment, it will be necessary to have an installed Metaconsole, from which to configure the entire monitoring infrastructure.

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

The Metaconsole will require:

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

Servers: 1 (shared)

サーバ数: 1 (共有)

Main:
----------
CPU: 8 cores
RAM: 12 GB
Disk: 100GB

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


Total servers with independent historical databases: 17

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

Total servers with combined historical databases: 13

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

Note : To combine all the historical databases (4) in a single team, you must resize their characteristics to assume the extra load:

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

Historical combined:
--------------------
CPU: 8 cores
RAM: 12 GB
Disk: 1200GB

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

データサーバの HA

The easiest way is to use the HA implemented in the agents (which allow you to contact an alternative server if the principal does not reply). However, since the data server supports port 41121 and is a standard TCP port, it is possible to use any commercial solution that allows balancing or clustering an ordinary TCP service.

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

For Pandora FMS data server you will need to mount two machines with a configured Pandora FMS data server (and different hostname and server name). You will have to configure a Tentacle server in each of them. Each machine will have a different IP address. If we are going to use an external balancer, it will provide a unique IP address to which the agents will connect to send their data.

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

If we are using an external balancer, and one of the servers fails, the HA mechanism "promotes" one of the available active servers and Pandora FMS agents will continue to connect with the same address as before, without noticing the change, but in this case, the load balancer will no longer send the data to the server that has failed, but to another active server. There is no need to change anything in every Pandora FMS data server, even each server can keep its own name, useful to know if any has fallen in the server status view. Pandora FMS data modules can be processed by any server without a preassignment being necessary. It is designed precisely this way so that HA can be implemented more easily.

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

In the case of using the HA mechanism of the agents, there will be a small delay in the sending of data, since at each execution of the agent, it will try to connect with the primary server, and if it does not answer, it will do so against the secondary one (if it has been configured this way). This is described below as "Balancing in Software Agents".

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

If you want to use two data servers and both manage policies, collections, and remote configurations, you will need to share the following directories by NFS so that all instances of the data server can read and write over these directories. Consoles should also have access to these shared directories shared by NFS.

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

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

550px

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

From the software agents it is possible to do a balancing of Data servers so it is possible to configure a Data server master and another one for backup.

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

In the agent configuration file pandora_agent.conf, you should configure and uncomment the following part of the agent configuration file:

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

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

  • secondary_mode: Mode in which the secondary server should be. It could have two values:
  • secondary_mode: セカンダリサーバのモードを設定します。次のいずれかが設定できます。
    • on_error: Send data to the secondary server only if it could not send them to the main server.
    • on_error: メインサーバにデータを送信できなかった場合のみセカンダリサーバにデータ送信します。
    • always: Always sends data to the secondary server not regarding if it could or not connect with the main server.
    • always: メインサーバに接続できるできないに関わらず、常にセカンダリサーバにもデータを送信します。
  • secondary_server_ip: Secondary server IP
  • secondary_server_ip: セカンダリサーバの IP アドレスを指定します。
  • secondary_server_path: Path where the XML are copied in the secondary server,usually /var/spoo//pandora/data_in
  • secondary_server_path: セカンダリサーバの XML ファイルを置く場所を指定します。通常は、/var/spool/pandora/data_in です。
  • secondary_server_port: Port through the XML will be copy to the secondary server in tentacle 41121, in ssh 22 are in ftp 21.
  • secondary_server_port: セカンダリサーバに XML ファイルを置くためのポート番号を指定します。tentacle では 41121、ssh は 22、ftp は 21 です。
  • secondary_transfer_mode: transfer mode that will be used to copy the XML to the sercondary server, tentacle, ssh, ttp etc
  • secondary_transfer_mode: セカンダリサーバに XML を送信するモード (tentacle, ssh, ftp など) を設定します。
  • secondary_server_pwd: Password option for the transfer through FTP
  • secondary_server_pwd: FTP で送信するためのパスワードを設定します。
  • secondary_server_ssl: Yes or not should be put depending if you want to use ssl to transfer data through Tentacle or not.
  • secondary_server_ssl: Tentacle その他でデータを送信するときに、ssl を使うかどうかを yes または no で指定します。
  • secondary_server_opts: This field is for other options that are necessaries for the transfer.
  • secondary_server_opts: 転送に必要なその他オプションを設定します。

Template warning.png

Only the remote configuration of the agent is operative, if it is enabled, in the main server.


Template warning.png

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


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

This is easier. You need to install several servers, network,WMI, Plugin, Web or Prediction, in several machines of the network (all with the same visibility for the systems that you want monitor). All these machines should be in the same segment (so as the network latency data whould be coherents)

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

The servers could be selected as primaries.These servers will automatically collect the data form all the modules assigned to a server that is selected as «down».Pandora FMS own servers implement a mechanism to detect that one of them has down thorugh a verification of its last date of contact (server threshold x 2).It will be enough if only one Pandora FMS server would be active for that it could detect the collapse of the other ones. If all Pandora FMS are down, there is no way to detect or to implement HA.

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

The obvious way to implement HA and a load balancing in a system of two nodes is to asign the 50% of the modules to each server and select both servers as masters (Master. In case that there would be more than two master servers and a third server down with modules expecting to be executed, the first of the master server that would execute the module will "self-assign" the module of the down server. In case of the recovering of one of the down servers, the modules that have been assigned to the primary server would automatically be assigned again.

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



550px



The load balancing between the different servers is done in the Agent Administration section in the "setup" menu.

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

800px


In the field "server" there is a combo where you can choose the server that will do the checking.

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

サーバの設定

A Pandora FMS Server can be running in two different modes:

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

  • Master mode.
  • Non-master mode.
  • マスターモード
  • 非マスターモード

If a server goes down, its modules will be executed by the master server so that no data is lost.

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

At any given time there can only be one master server, which is chosen from all the servers with the master configuration token in /etc/pandora/pandora_server.conf set to a value greater than 0:

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

master [1..7]

If the current master server goes down, a new master server is chosen. If there is more than one candidate, the one with the highest master value is chosen.

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

Template warning.png

Be careful about disabling servers. If a server with Network modules goes down and the Network Server is disabled in the master server, those modules will not be executed.


Template warning.png

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


For example, if you have three Pandora FMS Servers with master set to 1, a master server will be randomly chosen and the other two will run in non-master mode. If the master server goes down, a new master will be randomly chosen.

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

The following parameters have been introduced in pandora_server.conf:

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

  • ha_file: HA temporary binary file address.
  • ha_pid_file: HA current process.
  • pandora_service_cmd: Pandora service status control.
  • ha_file: HA のテンポラリバイナリファイルの場所
  • ha_pid_file: HA の現在のプロセス ID ファイル
  • pandora_service_cmd: Pandora サービスの状態制御

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

Just install another console. Any of them can be used simultaneously from different locations by different users. Using a web balancer in front of the consoles, will make possible to access them without really knowing which one is being accessed since the session system is managed by "cookies" and this is stored in the browser. In the case of using remote configuration, both data servers and consoles must share (NFS) the entry data directory (/var/spool/pandora/data_in) for remote configuration of agents, collections and other directories.

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

データベース HA

Info.png

This solution is provided to offer a fully-featured solution for HA in Pandora FMS environments. This is the only officially-supported HA model for Pandora FMS. This solution is provided -preinstalled- since OUM 724. This system replaces DRBD and other HA systems we recommended in the past.


Info.png

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


Template warning.png

This is the first Pandora DB HA implementation, and the install process is almost manual, by using linux console as Root. In future versions we will easy the setup and configuration from the GUI


Template warning.png

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


Pandora FMS relies on a MySQL database for configuration and data storage. A database failure can temporarily bring your monitoring solution to a halt. The Pandora FMS high-availability database cluster allows you to easily deploy a fault-tolerant, robust architecture.

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

Cluster resources are managed by Pacemaker, an advanced, scalable High-Availability cluster resource manager. Corosync provides a closed process group communication model for creating replicated state machines. Percona was chosen as the default RDBMS for its scalability, availability, security and backup features.

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

Active/passive replication takes place from a single master node (writable) to any number of slaves (read only). A virtual IP address always points to the current master. If the master node fails, one of the slaves is promoted to master and the virtual IP address is updated accordingly.

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

ファイル:Ha cluster diagram.png

The Pandora FMS Database HA Tool, pandora_ha, monitors the cluster and makes sure the Pandora FMS Server is always running, restarting it when needed. pandora_ha itself is monitored by systemd.

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

Template warning.png

This is an advanced feature that requires knowledge of Linux systems.


Template warning.png

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


インストール

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

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

Commands that should be run on one node will be preceded by that node's hostname. For example:

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

node1# <command>

Commands that should be run on all nodes will be preceded by the word all. For example:

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

all# <command>

There is an additional host, which will be referred to as pandorafms, where Pandora FMS is or will be installed.

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

前提条件

CentOS version 7 must be installed on all hosts, and they must be able to resolve each other's hostnames.

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.

An Open SSH server must be installed and running on every host. Remove the banner displayed by Open SSH:

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

The Pandora FMS Database HA Tool will not work properly if a banner is configured for Open SSH.


Template warning.png

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


Generate new SSH authentication keys for each host and copy the public key to each of the other hosts:

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

Template warning.png

Passwords can be generated for a non-root user for a later clusted installation with a non-root user.


Template warning.png

root 以外のユーザを使用した設定を行う場合は、root 以外のユーザで鍵を生成します。


node1# echo -e "\n\n\n" | ssh-keygen -t rsa
node1# ssh-copy-id -p22 root@node2
node2# 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

On the Pandora FMS node, copy the key pair to /usr/share/httpd/.ssh/. The Pandora FMS Console needs it to retrieve the status of the cluster:

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/

The following steps are only necessary if the nodes are running SSH on a non-standard port. Replace 22 with the right port number:

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

Install the required packages:

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

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

Make sure the Percona service is disabled, since it will be managed by the cluster:

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

all# systemctl disable mysqld

Template warning.png

If the system service is not disabled, the cluster's resource manager will not function properly.


Template warning.png

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


Configure Percona, replacing <ID> with a number that must be unique for each cluster node:

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

Template warning.png

Database replication will not work if two nodes have the same SERVER_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 = $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
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

Start the Percona server:

Percona サーバを起動します。

all# systemctl start mysqld

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

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

Pandora FMS のインストール

新規の Pandora FMS インストール

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

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

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

Stop the Pandora FMS server:

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

pandorafms# /etc/init.d/pandora_server stop
既存の Pandora FMS へのインストール

Stop your Pandora FMS Server:

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

pandorafms# /etc/init.d/pandora_server stop

Backup the Pandora FMS database:

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

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

Load it into the new database:

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

node1# mysql -uroot -ppandora < /tmp/pandoradb.sql
node1# systemctl stop mysqld

レプリケーション設定

Grant the required privileges for replication to work on all databases:

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

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

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

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

Load the database on the second node and configure it to replicate from the first node (set MASTER_LOG_FILE and MASTER_LOG_POS to the values found in the previous step):

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

Make sure Slave_IO_Running and Slave_SQL_Running read Yes. Other values may differ from the example.


Template warning.png

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


2ノードクラスタの設定

Install the required packages:

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

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

Stop the Percona server:

Percona サーバを停止します。

node1# systemctl stop mysqld

Authenticate all the nodes in the cluster:

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

Create and start the cluster:

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

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

Check the status of the cluster:

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

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

Both nodes should be online (Online: [ node1 node2 ]). Other values may differ from the example.


Template warning.png

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


Install the Percona pacemaker replication agent:

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

Configure the cluster resources. Replace <VIRT_IP> with the virtual IP address of your choice:

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

Template warning.png

If you have changed the default password used in this guide for the database's root user, update replication_passwd and test_passwd accordingly.


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

Check the status of the cluster:

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

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

Both nodes should be online (Online: [ node1 node2 ]). Other values may differ from the example.


Template warning.png

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


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

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

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

# 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
# 全ノード:
useradd <usuario>
passwd <usuario>
usermod -a -G haclient <usuario>
# 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 <usuario> <rol>
# 全ノードから PCS へログイン
su - <usuario>
pcs status
Username: <usuario>
Password: ***** 
# 'Authorized' メッセージを待ち出力は無視します。数秒待ったのち、'pcs status' コマンドを実行します。

Pandora FMS の設定

Make sure php-pecl-ssh2 is installed:

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

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

There are two parameters in /etc/pandora/pandora_server.conf that control the behavior 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 (replace <IP> with the virtual IP address):

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

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

Install and start the pandora_ha service:

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

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

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

ファイル:Manage ha menu.png

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

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

ファイル:Manage ha add node.png

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

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

ファイル:Manage ha view.png

Template warning.png

Seconds behind master should be close to 0. If it keeps increasing, replication is nor working.


Template warning.png

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


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

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

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

Load the database on the new node, which we will call node3, and configure it to replicate from node1 (set 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

Template warning.png

Make sure Slave_IO_Running and Slave_SQL_Running read Yes. Other values may differ from the example.


Template warning.png

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


Add the new node to the cluster:

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

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

Set clone-max to the number of nodes in your cluster (3 in this example):

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"

Check the status of the cluster:

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

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

All nodes should be online (Online: [ node1 node2 node3 ]). Other values may differ from the example.


Template warning.png

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


障害ノードの修正

We will use node2 as an example. Put node2 into standby mode:

例として 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 should be on standby (Node node2: standby). Other values may differ from the example.


Template warning.png

node2 がスタンバイ(Node node2: standby)である必要があります。他の値は例とは異なります。


Backup Percona's data directory:

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

Backup the database of the master node (node1 in this example) and write down the master log file name and position (in the example, mysql-bin.000001 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 broken node and configure it to replicate from node1 (set MASTER_LOG_FILE and MASTER_LOG_POS to the values found in the previous step):

障害が発生したノードへデータベースをコピーし、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

Make sure Slave_IO_Running and Slave_SQL_Running read Yes. Other values may differ from the example.


Template warning.png

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


Remove node2 from standby mode:

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

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

Check the status of the cluster:

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

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

Both nodes should be online (Online: [ node1 node2 ]). Other values may differ from the example.


Template warning.png

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


トラブルシューティング

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

ファイル:Manage ha failed.png

The service will not be affected as long as the master node is running. If the master node fails, a slave node will be automatically promoted to master. See Fixing a broken node.

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

(OBSOLETE)

データベースのロードバランシング

The Database is the most critical component of Pandora, and therefore, the issue is more complex. We are currently proposing a software solution based on DRBD that allows MySQL to cluster via software, and Pandora FMS can also work with different hardware or virtualized solutions that allow clustering any standard application such as MySQL.

データベースは Pandora の最も重要なコンポーネントなので、問題はより複雑です。 現在、DRBD に基づいたソフトウェアソリューションを提案しており、MySQL をソフトウェアでクラスタリングすることができます。Pandora FMS はまた、MySQL などの標準アプリケーションをクラスタリングできるさまざまなハードウェアまたは仮想化ソリューションでも動作します。

We are working to offer an integrated solution in Pandora FMS that allows to implement a native HA tool in Pandora, based on MySQL.

私たちは、MySQL をベースにしたネイティブな HA ツールの実装を可能にする、Pandora FMS の統合ソリューションを提供しています。

You can consult the documentation available on DRBD and MySQL

DRBD および MySQL のドキュメントを確認してください。

自動検出サーバのバランシングと HA

In the Recon Server the redundancy is very easy to apply. You only need to install two recon servers with alternate tasks.So is one of them is down, the other one will continue executing the same task.

自動検出サーバにおいても、冗長化はとても簡単です。それぞれに自動検出サーバをインストールし、それぞれのタスクを設定するだけです。一方がダウンした場合、もう一方がタスクを引き継ぎます。

補足 1: LVS と keepalived を用いた HA およびロードバランシングの実装

For the load balancing we advise to use Linux Virtual Server (LVS). To manage the High Availability (HA) between the services, we advise to use Keepalived.

ロードバランシングには、Linux Virtual Server (LVS) の利用をお勧めします。サーバ間の HA 構成を管理するには、Keepalived の利用をお勧めします。

LVS

LVS

At present, the main function of the LVS project is to develop an advanced IP system of load balancing through software (IPVS), load balancing through software at application level and components for the management of a services cluster.

LVS プロジェクトの主な役割は、アプリケーションレベルのソフトウエアとクラスタ管理のコンポーネントを利用して、ソフトウエア (IPVS) でロードバランシングを行う拡張 IP システムを開発することです。

IPVS

IPVS

Advanced IP system of load balancing through software implemented in the Linux own kernel and that has been already included in versions 2.4 and 2.6.

ソフトウエアでのロードバランシングを行う拡張 IP システムは Linux カーネルに実装されており、すでにバージョン 2.4 および 2.6 カーネルに含まれています。

Keepalived

Keepalived

It is used to manage the LVS. Keepalived is being used in the cluster to make sure that the SSH servers, both Nodo -1 and Nodo-2 are alive, if any of them falls, Keepalive show to the LVS that one of the two nodes is down and it should to readdress the petitions to the node that is alive.

これは、LVS を管理するために利用します。 Keepalived は、2台のサーバをクラスタ構成にするために利用します。Keepalive は、一方の LVS がダウンした場合、もう一方の稼働しているノードにアドレスを割り当てます。

We have chosen Keepalived as HA service so it allows to keep a persistence of session between the servers. This is, if any of the modules falls, the users that are working on this node will be conduced to the other module that is alive, but these will be exactly in the same place that they were before, doing that the fall will be fully transparent to its work and sessions ( in the case of SSH it will not work due to the SSH encrypting logic, but in simple TCP sessions, such as Tentacle without SSL or FTP, they will work without problem).With Tentacle/SSH the communication should be try again and this way the information of the data packet will not be lost.

我々は、HA 構成のために Keepalived を選択しました。サーバ間でセッションを維持することができるためです。 ある機能で障害が発生した場合、利用していた機能は正常なサーバへ移ります。処理が完全に移るため、これまで処理していたのと同じ状態になります。(SSH は暗号化ロジックがあるため動作しませんが、SSL 無しの Tentacle や FTP など、単純な TCP セッションであれば問題なく継続することができます。) Tentacle/SSH では、接続のリトライを行いますので、データパケットの情報は失われることはありません。

The configuration file and the orders for use of KeepAlived are in the Annex 2.

KeepAlived を利用するための設定ファイルと記載については、補足 3 に示します。

Load Balancing Algorithm Algorithm

ロードバランシングアルゴリズム

The two more used algorithms nowadays are:«Round Robin» and «Weight Round Robin». They are very similar and they are based on an assignment of work by turns.

最も使われる 2つのアルゴリズムは、「ラウンドロビン」と「ウエイトラウンドロビン」です。これらは非常に似ており、順番に処理を割り当てる動作を基本にしています。

In the case of the «Round Robin»,it is one of the process planning algorithms more simple in an Operative System that assigns to each proccess an equitable and ordered time share, considering all processes with the same priority.

「ラウンドロビン」は、最も簡単な処理の割り当てアルゴリズムで、それぞれの処理を順番に割り当てます。すべての処理は同じ優先順位です。

On the other hand, the «Weight Round Robin» algorithm allows to assign load to the machines inside the cluster so as a number of specific petitions will go to one or other node, depending on its weight inside the cluster.

もう一方の「ウエイトラウンドロビン」は、クラスタを構成するサーバの負荷を考慮して割り当てることができるアルゴリズムです。ある特定の数の処理をウエイトに応じて一方のノードに割り当てます。

This has no sense in the topology that we consider here, so both machines have exactly the same hardware features. For all these we have decided to use «Round Robin» as load balancing algorithm.

ここではトポロジに関しては言及していません。双方のマシンは、同じハードウエア構成であることを想定しています。我々は、ロードバランシングアルゴリズムとして、「ラウンドロビン」を利用することにしました。

ノードダウン時の動作

Keepalived will detect is one of the services is down. So, if it happens it will eliminated the module that have failed from the LVS active modules to the node that has failed, so all the petitions to the node that have failed will be readdressed to the active node.

Keepalived は、サービスのダウンを検出します。その場合、ダウンした LVS をアクティブノードから外し、ダウンしたノードに対するリクエストを、アクティブなノードへリダイレクトします。

Once the possible problem will be solved with the service that has fallen, you should restart keeoalived:

ダウン状態から復旧した場合は、keepalived を次のように再起動します。

/etc/init.d/keepalived restart

With this restart of the service, the nodes will be inserted again in the LVS available nodes list.

これによりサービスが再起動し、LVS の稼働ノードリストに再び追加されます。

If one of the nodes falls, it would be not necessary to do a manual insertion of the nodes using ipvsadm, so Keepalived will do it once it would restart and check that the services that are supposed to do an HA service are running and are accessibles by its «HealthCheckers».

一つのノードがダウンした場合、ipvsadm を使って手動でノードを登録する必要はありません。それは、HealthCheckers によって HA を構成するサービスを再起動しチェックする Keepalived によって実行されます。

補足 2. LVS バランサー設定

Use of ipvsadm:

ipvsadm の利用方法:

Installing of the manager Linux with ipvsadm:

Linux に ipvsadm を設定します。

ipvsadm -A -t ip_cluster:22 -s rr

The options are:

オプションは次の通りです。

  • A Add service
  • A サービスの追加
  • t TCP service with Ip format
  • t TCP サービス
  • s Sheduler, in this case you should use the "rr" parameter (round robin)
  • s 負荷分散手法 この例では、"rr" (ラウンドロビン) を指定しています。

Install the nodes (real servers) to which the petitions to the 22 port will be readdress.

22番ポートへのアクセスを振り分けるノード (実サーバ) を設定します。

ipvsadm-a -t ip_cluster:22 -r 192.168.1.10:22 -m ipvsadm -a -t ip_cluster:22 -r 192.168.1.11:22 -m

The ipvsadm situation without active connections is the following:

アクティブな接続が無い時の、ipvsadm の状態は次のようになります。

Prot LocalAddress:Port Scheduler Flags 
 -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP cluster:www rr 
 -> nodo-2:ssh                    Masq    1         0        0
 -> nodo-1:ssh                    Masq    1         0        0

Using the «Round Robin» algorithm, both machines have the same weight in the cluster. So the connexions will be shared. Here you can see an example of LVS balancing connexions against the cluster:

「ラウンドロビン」アルゴリズムを利用することにより、クラスタ内で双方のマシンは同じ優先度になります。接続は共有されます。ここで、LVS バランシングのクラスタに接続がある場合の例を以下に示します。

Prot LocalAddress:Port Scheduler Flags 
 -> RemoteAddress:Port      Forward Weight ActiveConn InActConn
TCP cluster:ssh rr 
 -> nodo-2:ssh              Masq     1         12        161
 -> nodo-1:ssh              Masq     1         11        162

補足 3. KeepAlived 設定

Keepalived is the one that verifies that the files selected in its configuration file (/etc/keepalived/keepalived.conf)are empty, and keep the different host in the balancing cluster. If any of these services falls, get out the host of the balancing cluster.

Keepalived は、設定ファイル (/etc/keepalived/keepalived.conf) に書かれているサービスが稼働しているかどうかをチェックし、バランシングクラスタの別のホストを保持します。稼働中のホストがダウンした場合は、バランシングクラスタ内の他方のホストに処理を移します。

To start Keepalived:

Keepalived の起動は次の通りです。

/etc/init.d/keepalived start

To stop Keepalived:

Keepalived を停止するには次のようにします。

/etc/init.d/keepalived stop

The configuration file used for the cluster is the following one:

クラスタに使う設定ファイル例を以下に示します。

 # Configuration File for keepalived
  global_defs {
      notification_email {
          email@valido.com
      }
      notification_email_from keepalived@domain
      smtp_server 127.0.0.1
      smtp_connect_timeout 30
      lvs_id LVS_MAIN
 }
 
 virtual_server 192.168.1.1 22 {
        delay_loop 30
        lb_algo rr
        lb_kind NAT
        protocol TCP
        real_server 192.168.1.10 22 {
              weight 1
               TCP_CHECK {
                        connect_port 22
                        connect_timeout 3
                        nb_get_retry 3
                        delay_before_retry 1
                }
        }
        real_server 192.168.1.11 22 {
              weight 1
              TCP_CHECK {
                        connect_port 22
                        connect_timeout 3
                        nb_get_retry 3
                        delay_before_retry 1
              }
        }
 }