Pandora: Documentation ja: HA

From Pandora FMS Wiki
Revision as of 03:35, 14 June 2012 by Junichi (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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.1.1 データサーバのバランシングと HA

これは、Pandora FMS のサーバのインストール面では特別な知識は必要ありませんが、複雑な設定になります。別途、商用の HA やバランシングを実現するハードウエアや、vrrpd, LVS, keepalive などのオープンソースの HA やロードバランシングツールを利用する必要があります。

Pandora FMS データサーバでは、2つのマシンに (ホスト名とサーバ名を変えて) 同様の設定のデータサーバをインストールする必要があります。それぞれのサーバに、Tentacle サーバや、必要に応じて SSH/FTP サーバも設定する必要があります。それぞれのマシンの鍵 (SSH) をコピーする必要がある点にも注意してください。設定をコピーすれば良いだけなので、Tentacle を利用するのがより簡単です。それぞれのマシンは、別々の IP アドレスを持っており、エージェントがデータを送信するために接続する 1つの IP アドレスはバランサーがもちます。バランサは、対応するサーバにデータを送信します。

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

HA を組む別の方法として、2つのサーバをアクティブ/スタンバイで設定する方法があります。エージェントからのデータ送信を異なる 2つのサーバに行います。これについては、次の "ソフトウエアエージェントでのバランシング" で説明します。

章の終わりでは、HA および、LVS と、keepalive を利用した Tentacle (41121) や SSH、FTP などのロードバランシングの実装の仕組について説明します。同じ手法は、2台以上のシステムに適用できます。この場合、Pandora FMS のウェブは、apache を使うと便利です。

Ha2.png

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

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

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

1.1.2 ネットワーク、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.1.2.1 サーバの設定

サーバには、次の 2つのモードがあります。

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

これらの違いは、同じ種類の Pandora サーバ (ネットワークサーバなど) がそれぞれのサーバにある場合に、HA モードで動作させるかどうかです。サーバがダウンした場合、マスターサーバは、ダウンしたサーバが受け持っていたネットワークモジュールの実行を引き継ぎます。非マスターサーバはこの動作を行いません。

このオプションは、/etc/pandora/pandora_server.conf にて master 1 という記述で設定します。

1 を設定するとマスターモードが有効になり、0 を設定すると無効になります。

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

HA とロードバランシングを同時に実現するために、データベースクラスタを設定することができます。データベースは、全ての環境において重要なコンポーネントです。そのため、クラスタリングが最良のオプションとなります。データベースを MySQL のクラスタ構成にするだけです。この設定は十分にテストされ問題なく動作します。しかし、MySQL 5 のクラスタ管理の知識は必要です。また、多くのメモリを必要とします。最大 5000モジュールを 2つのノードで対応するには、最低でも 2GB 必要です。

この場合、Pandora FMS 側には特別な設定は必要ありません。

Ha5.png

MySQL で HA 構成を組む例は、補足資料にも示しています。(MySQL クラスタ、レプリケーションによる MySQL の HA構成および、DRBD)

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

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

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

この場合は、Pandora FMS に特別な設定は必要ありません。非常に簡単で、それぞれのマシンにコンソールをインストールすれば良いだけです。異なる場所から異なるユーザで同時に、それぞれを利用することができます。コンソールの上に Web のロードバランサを置くことによって、どちらにアクセスしているかを認識することなく利用することができます。セッションはクッキーで管理されており、ブラウザに保存されます。LVSKeepAlived を用いた HA 構成については後述します。

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

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

LVS

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

IPVS

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

Keepalived

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

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

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

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

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

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

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

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

1.2.1 ノードダウン時の動作

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

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

/etc/init.d/keepalived restart

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

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

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

ipvsadm の利用方法:

Linux に ipvsadm を設定します。

ipvsadm -A -t ip_cluster:22 -s rr

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

  • A サービスの追加
  • t TCP サービス
  • s 負荷分散手法 この例では、"rr" (ラウンドロビン) を指定しています。

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

アクティブな接続が無い時の、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

「ラウンドロビン」アルゴリズムを利用することにより、クラスタ内で双方のマシンは同じ優先度になります。接続は共有されます。ここで、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

1.4 補足 3. KeepAlived 設定

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

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

/etc/init.d/keepalived start

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

/etc/init.d/keepalived stop

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

 # Configuration File for keepalived
  global_defs {
      notification_email {
          [email protected]
      }
      notification_email_from [email protected]
      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
              }
        }
 }