cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平（@inokara）です。

はじめに

Sensu をプロダクション環境で運用しようとすると、その中核となる RabbitMQ はどう見ても SPOF になるんでは？という疑問から HA Proxy や Route 53 を使って HA 構成がとれないか検証してみた。


参考


構成

下記のように Sensu クライアント及び Sensu サーバーが HA Proxy の IP アドレスにアクセスするような構成を構築して検証する。

ha-proxy-sensu-rabbitmq-high-availability_01

尚、今回は ElastiCache for Redis は用いずに Sensu サーバー上に構築した Redis サーバーを利用した。


HA Proxy のうんちくとセットアップ


うんちく

  • L7 ロードバランサ
  • L4 でのロードバランスも出来る
  • 負荷分散、フェイルオーバーの機能も実装されている（バックエンドのアプリケーションで意識する必要は無い）
  • SPOF を作ってしまうことになる…（結局は HA Proxy も 2 台必要になる）

メリット・デメリットを理解して使いましょうということですな…。


セットアップ


環境

基本的な環境は以下のとおり。

  • CentOS 6.5
  • EC2 インスタンス


インストール

簡単。

yum -y install haproxy

以上。


HA Proxy と RabbitMQ の連携


RabbitMQ の設定

  • 事前にクラスタ化しておく
  • HA モードは all にしておいてキューはミラーリングさせておく


HA Proxy の設定

以下のような設定ファイルで保存しておく。

global
        log 127.0.0.1   local0
        log 127.0.0.1   local1 notice
        maxconn 4096
        user haproxy
        group haproxy
        daemon

defaults
        log     global
        mode    tcp
        option  tcplog
        option  dontlognull

listen  rabbitmq_local_cluster 0.0.0.0:5672
        mode tcp
        balance roundrobin
        server  ip-xxx-xxx-xxx-xx1 ip-xxx-xxx-xxx-xx1:5672 check inter 5000 rise 2 fall 3
        server  ip-xxx-xxx-xxx-xx2 ip-xxx-xxx-xxx-xx2:5672 backup check inter 5000 rise 2 fall 3

listen  private_monitoring :8101
        mode http
        option httplog
        stats enable
        stats uri /stats
        stats refresh 5s

こんだけ。


HA Proxy を起動する

sudo /etc/init.d/haproxy restart


HA Proxy の管理コンソール

以下のようなコンソールが稼働しているので便利。

ha-proxy-sensu-rabbitmq-high-availability_02


実際のところどう？


検証


パターン

  1. RabbitMQ クラスタの 1 台が停止した（rabbitmqctl stop_app にて再現）
  2. RabbitMQ クラスタの 2 台が停止した（rabbitmqctl stop_app にて再現）後で 1 台復旧させた
  3. RabbitMQ の vhost を意図的に削除


確認手順

  • Sensu Dashboard にて目視による監視継続の確認
  • /var/log/sensu/sensu-server.log の監視
  • /var/log/sensu/sensu-client.log の監視

上記のlogを監視して RabbitMQ への接続エラーが発生しないかを目視にて監視。また、合わせて Redis 内の history データベースの目視による監視も行った。


検証メモ（パターン 1）


結果

  • 監視は継続された
  • 以下のような log が出力された

    {“timestamp”:”2014-06-04T03:12:36.159371+0000″,”level”:”warn”,”message”:”reconnecting to rabbitmq”}

    HA Proxy でアプリケーションの停止を検知してフェイルオーバーして接続が再開すると…

    {“timestamp”:”2014-06-04T03:15:33.008918+0000″,”level”:”info”,”message”:”reconnected to rabbitmq”}

    上記のようなログが記録される。


検証メモ（パターン 2）


結果

  • 双方の RabbitMQ を stop_app した際には RabbitMQ への reconnecting がひたすら実行される
  • 1 ノードを RabbitMQ を start_app すると…

    {“timestamp”:”2014-06-04T03:15:33.008918+0000″,”level”:”info”,”message”:”reconnected to rabbitmq”}

    上記のようなログが出力され、監視が再開された。


検証メモ（パターン 3）

  • RabbitMQ との接続を切らない限りは監視は継続された
  • 但し、RabbitMQ との接続をリセットしたり、新しいクライアント（Sensu クライアント、サーバー）は監視が出来なくなってしまう


考察


Sensu において RabbitMQ の HA を HA Proxy で担保する使うメリット

  • RabbitMQ が HA 構成で稼働することになるので Sensu による監視の信頼性が向上する
  • RabbitMQ のキューは enqueue や dequeue は自動で同期されるのようなので監視キューのロストはや重複等は無いと思われる
  • HA Proxy のセットップは簡単なのでカジュアルに導入することが出来る
  • 設定次第ではあるが、一瞬で異常を検知して正常系への切り替えが行われる


HA Proxy を使うデメリット

  • HA Proxy が単一障害ポイントになる

元記事は、こちら