お問い合わせ
資料請求

MySQLの双方向レプリケーションを利用した冗長化監視サーバーの構築

0. はじめに

今回の記事は、Pandora FMS と MySQL を使ってサーバー2台でアクティブ-スタンバイ構成の監視サーバーを構築したという話です。

Pandora FMS は、バックエンドのデータベースを共有するだけで簡単にスケールアウトが行えるわけですが、今回はそのデータベースを双方向レプリケーションを使って冗長化しました。この構成だと、フェールオーバー/フェールバックは Pandora Server の停止/起動で制御できます。

構成上の制約から VIP も使っていないので、Pandora FMS と MySQL のみでの実装となりました。制約や注意点もありますが、道具が少ない分、構成はシンプルです。

この記事が、一つのケーススタディとして皆様の運用のヒントになれば幸いです。

1. 構成

はじめに構成を図示します。1台は通常稼動用のアクティブサーバー、もう1台はDR 対策用のホットスタンバイサーバーです (以降、前者を「プライマリサーバー」、後者を「スタンバイサーバー」と呼びます)。

blog-figure-1

図:  監視サーバーの構成

ご覧の通り、Pandora FMS に MySQL の双方向レプリケーションを組み合わせただけです。使用したバージョンは、 MySQL が 5.5、Pandora FMS が 5.1 です。どちらも最新版ではありませんが、事情は大きく変わってはいないのでいずれの最新版でも適用可能です (MySQL 5.6 で導入された GTID を使えばレプリケーション管理は楽できるかもしれません)。

この構成の肝は、次の 2点です。

  • Pandora FMS はそれぞれのサーバーのローカル DB (MySQL) を参照する
  • MySQL は、2台で双方向のレプリケーションを組む

サーバーローカルなデータベースを参照することで、監視サーバー 2台はどちらも単独で動作可能ですし、双方向のレプリケーションを組むことで、1つのデータベースを 2台で(擬似的に)共有している状態になります。
スタンバイサーバーは DR 対策用なので、プライマリサーバーとは異なるネットワーク上に構築しています(サービスベンダーは同じです)。このため、フロント側で VIP を共有するという手段は使えませんでしたが、 Pandora FMS の機能で対策をしています。

2. 双方向レプリケーションについて

双方向レプリケーションにはどういうメリットがあるのでしょう。2台はお互いのスレーブなので、どちらでクエリを実行しても両機ともに反映されます。利用する側はどちらを参照しているのか意識する必要はありませんし、「マスター昇格」等の特別な手続きも不要です。

MySQL の双方向レプリケーションは設定自体は難しくありません。片方向のレプリケーション設定ができれば、それを同時に逆向きにも行うだけです。具体的な手順は割愛しますが、レプリケーション設定を行うタイミングで両サーバーのデータは同期が取れてるはずなので、お互いに相手のサーバーのポジション情報を与えれば、双方向に設定できます。

しかし、これだけでは、両サーバーでデータの不整合が起きる可能性があります。最も重大な問題は、主キー重複の可能性があることです。本来レコードごとに一意であるはずの主キーですが、同一テーブルに対するデータ追加が 2台同時に起きると、それぞれが単独でレコード追加をしてしまうので、ID が重複してしまう可能性があります。

Pandora FMS のテーブルを確認すると、主キーが自動インクリメントのものが殆ど(少なくとも監視に直接関連するテーブルはすべて)なので、主キー重複問題は MySQL の設定で回避できます。具体的には下記のような設定を両サーバーに追加します。

1台目 (プライマリサーバー)

[mysqld]
auto_increment_increment = 2
auto_increment_offset = 1

2台目 (スタンバイサーバー)

[mysqld]
auto_increment_increment = 2
auto_increment_offset = 2

この設定は、自動インクリメントで割当てられる数値を、1台目は奇数のみ、2台目は偶数に制限します。こうしておけば、2台で同じIDを割り当てることはありません。(※ レプリケーション設定を行うには、server-id や bin-log など上記以外の設定も必要です。詳しくは MySQL のドキュメント等を参照して下さい)

主キーの重複以外にも問題はあります。例えば、DB のロック(テーブルロック/レコードロック)もレプリケーション越しには効きませんし、同じレコードに対する更新や削除が 2台同時に起きるような場合は、対処できません。

しかし、データベースを利用するのが Pandora FMS のみであれば、 Pandora Server が同じ監視項目のデータを 2台同時に更新することは無いので、ここは容認することにしました (詳細を見るとリスクはゼロではないのですが、それも実用上容認できるとの判断です)。

3. Pandora FMS

Pandora FMS は、それぞれのサーバーで動作する MySQL を参照するようにします。それぞれのサーバー内で監視サーバーに必要なコンポーネントが揃うので、2台は DB のデータを共有しつつ単独でも動作可能な状態になります。

Pandora FMS インストール時に登録される DBメンテナンス用の定期実行ジョブは注意が必要です (例えば、Linux の場合は /etc/cron.hourly/pandora_db です)。保存期限を過ぎたデータの削除処理などをおこなうので、2台で(同じタイミングで)実行するのは避けるべきです。スタンバイサーバーの当該ジョブを無効にして、プライマリサーバーだけで実行するようにします。

あとは、プライマリサーバーの管理コンソール (Pandora Console) から監視設定を行います。ICMP や SNMP といったリモート監視は、それだけでプライマリサーバー側から実行されるようになります。

VIP を利用しないので、ソフトウェアエージェント(Pandora Agent)のデータ送信先にプライマリサーバーを指定するだけでは不十分です。Pandora Agent はデータ送信先を 2つ指定できるので、2番目の送信先にスタンバイサーバーを指定しておきます (セカンダリサーバ設定)。

SNMP trap については問題があります。この構成だと、SNMP trap は常に 2台の監視サーバーに送るよう送信側で調整する必要があります。両サーバーで受け取るので、受信通知も重複して送信されます。カスタムスクリプトを用意して、サーバーが稼動系として動作している場合にのみ通知を実施することも可能でしたが、今回は、重複通知を容認しました。

緊急度/優先度の低いタスクはプライマリサーバーのみで実行すればよいでしょう。自動検出やインベントリ管理(エンタープライズ版の機能です)といった機能を使う場合がそうです。これらの有効/無効の指定は、それぞれのサーバーの pandora_server.conf の recon_server や inventory_server  といった項目で制御します。

4. フェールオーバー

プライマリサーバーからスタンバイサーバーに監視を切り替えるのは簡単です。プライマリサーバーで動作している Pandora Server を停止するだけです。スタンバイサーバーの Pandora Server は、プライマリサーバーの Pandora Server の停止を検知し監視を引き継ぎます。Pandora Server の参照 DB の変更や MySQL のレプリケーション設定の調整といった操作は不要です。もちろん VIP の移動もありません (使ってないので :)。

Pandora Agent を使っている場合は、事前にプライマリサーバーの tentacle server も停止します。これを止めないと、プライマリサーバーは、データを受け取り続けてしまいます (Pandora Server が停止してるので、受け取ったデータは処理されないまま放置されます)。

プライマリサーバーに切り戻すには、止めておいたプロセスを起動するだけです。簡単ですね。

なお、スタンバイサーバーは、普段は監視には参加しないので、サービスに影響を与えずいつでも止めることができます。

このフェールオーバーの様子を詳しく見ると次のようなことが起きています。

  1. プライマリサーバーの Pandora Server が停止時に、その旨のメッセージをローカル DB に書き込む
  2. スタンバイサーバーの DB に情報が反映される (レプリケーション経由)
  3. スタンバイサーバーの Pandora server がプライマリサーバーの停止を検知し、監視を引き継ぐ

いわば Pandora Server はダイイングメッセージによってお互いの状態を監視しているのです。これは逆に、ダイイングメッセージが届かない限り、監視も引き継がれないことを意味します。例えば、レプリケーションが停止しただけではフェールオーバーは起きないということになります。これは Pandora Server の仕様ですが、場合によってはこの動作を変えたくなるかもしれません。実際、相手サーバーへの疎通監視を利用すれば実装できます。

5. 監視サーバーの監視

2台のサーバーは単独で動作可能なので、お互いを監視することもできます。今回構築したケースでは監視主体が異なったため、両サーバーとは別に監視サーバーをもう1台用意したのですが、要件次第では相互監視で十分かもしれません。

ICMPによる死活監視や特定ポートの接続性の監視などのリモート監視だけではなく、Pandora Agent を使うこともできます。データ送信先はもちろん相手サーバーです。Pandora Agent を使うと、障害検知を契機にコマンドを起動することもできるので、プロセス監視などでは自動復旧処理も簡単に行えます。なお、Pandora Agent で Pandora Agent プロセスの監視は出来ないので、適当な項目に対して「不明」監視を入れることをお薦めします(Panodora Agent プロセスがダウンして情報収集が止まった項目は「不明」状態になります)。

では、プライマリサーバーとの通信が途絶えた場合にフェールオーバーしたいという前出のケースはどうすればいいでしょうか。スタンバイサーバーがプライマリサーバーとの通信断を検知したら、プライマリサーバーのダイイングメッセージをローカル DB に書き込むようにします。通信が復旧すればプライマリサーバーからのデータが流れてくるので、ダイイングメッセージはキャンセルされ、自動的にフェールバックします。

6. おわりに

MySQL の双方向レプリケーションと Pandora FMS の相性は悪くなさそうです。今回は、稼動系と待機系という想定での構築でしたが、両サーバーを稼動系として使うことも可能かもしれません。機会があれば試してみたいと思います。

ご相談・お問い合わせはこちらから

サービスについてのご相談、資料のご請求など、お気軽にお問い合わせください。

03-5946-8400 平日 10:00 - 18:00
page top