Sensu、Uchiwa、Redis、RabbitMQを本番利用に向けて冗長化する：Sensuで始めるクラウド時代のシステム監視（7）（2/2 ページ）

[堀内晨彦，＠IT]

RabbitMQのクラスタリングとミラーリングを構成する

　今回の構成では、RabbitMQはアクティブ−アクティブの冗長構成をとり、キューの内容がミラーリングされるようになっています。クラスタリングすることでバーチャルホストやユーザーが共有され、ミラーリングすることでキューの内容が同期されます。

　RabbitMQをクラスタリングし、クラスタ内部でキューのミラーリングを設定するという流れになります。クラスタリングとミラーリングの仕組みについては、以下の公式ドキュメントを参照してください。

• RabbitMQ - Clustering Guide
• RabbitMQ - Highly Available（Mirrored）Queues

　今回はSensuのドキュメントに従って、2台のRabbitMQでクラスタリングとミラーリングを構成します。

• Sensu | RabbitMQ Configuration | High-availability configuration

　まずは、1台目（ここでは「sensu-one.hico.io」）の設定を行います。RabbitMQでクラスタリングを構成するには、「Erlang Cookie」の値が同じである必要があります（詳細はClustering Guideの「How Nodes Authenticate to Each Other：the Erlang Cookie」をご覧ください）。

　ここでは、例として「cookiemonster」に設定していますが、ハッシュ値などのランダムな文字列の方がよいと思います。クラスタリングするためには、一度RabbitMQのバーチャルホストやユーザーなどの情報をリセットする必要があります。

# クラスタリングのためにErlangのCookie値を統一
$ echo coookiemonster | sudo tee /var/lib/rabbitmq/.erlang.cookie
$ sudo /etc/init.d/rabbitmq-server restart
# クラスタリングのためにRabbitMQをリセット
$ sudo rabbitmqctl stop_app
$ sudo rabbitmqctl reset
$ sudo rabbitmqctl start_app

▲1台目のRedisの設定（bash）

　次に、2台目（ここでは「sensu-two.hico.io」）の設定を行います。1台目と同様に「Erlang Cookie」の設定を行った後、1台目のクラスタに参加します。

　「join_cluster」の引数の「@sensu-one」の箇所は、名前解決ができる必要があります。DNSにレコードを登録するか、「/etc/hosts」に記載してください（詳細はClustering Guideの「Hostname Resolution Requirements」をご覧ください）。

# クラスタリングのためにErlangのCookie値を統一
$ echo coookiemonster | sudo tee /var/lib/rabbitmq/.erlang.cookie
$ sudo /etc/init.d/rabbitmq-server restart
# sensu-one.hico.ioのクラスタに参加する
$ sudo rabbitmqctl stop_app
$ sudo rabbitmqctl join_cluster rabbit@sensu-one
$ sudo rabbitmqctl start_app

▲2台目のRedisの設定（bash）

　最後に、Sensu用のバーチャルホストとユーザーを作成し、権限とミラーリングを設定します。「ha-sensu」という名前のポリシーを作成し、「results」と「keepalives」のキューをミラーリングします。「ha-mode」と「ha-sync-mode」の設定内容は下記の通りです。

• "ha-mode": "all"：クラスタ内の全ノードでミラーリングする（新しいノードが参加したときも含む）
• "ha-sync-mode": "automatic"：新しいノードが参加したとき、操作をブロックして自動でミラーリングする

# クラスタリングできていることを確認
$ sudo rabbitmqctl cluster_status
# Sensu用のバーチャルホストとユーザーを作成し権限を設定
$ sudo rabbitmqctl add_vhost /sensu
$ sudo rabbitmqctl add_user sensu secret
$ sudo rabbitmqctl set_permissions -p /sensu sensu ".*" ".*" ".*"
# バーチャルホストのミラーリングを設定
$ sudo rabbitmqctl set_policy ha-sensu "^(results$|keepalives$)" '{"ha-mode":"all", "ha-sync-mode":"automatic"}' -p /sensu

▲Sensu用のバーチャルホストとユーザーを作成し、権限とミラーリングを設定する（bash）

　これで、片方のRabbitMQに障害が発生しても、メッセージング処理を継続できるようになりました。さらに可用性を向上させたい場合や、sensu-clientの台数が増えた場合などでも、クラスタのノードを増やすことで対応できるようになります。

Sensuを冗長化する

　Sensuでは、sensu-serverとsensu-apiを冗長化します。Sensuの場合は冗長化する2台で設定は共通なので、とてもシンプルです。

　Redisの設定では、IPアドレスをマスターのものに変更し、パスワードを追加します。RabbitMQの設定では、クラスタリングしているノードの情報を配列で設定します（ランダムに1台のノードを選択し、障害が発生した場合は自動で次のノードが選択されます）。作業が完了したら、sensu-server、sensu-api、sensu-clientを再起動して設定を反映します。

{
  "redis": {
    "host": "163.44.169.160",          // RedisマスターのIPアドレスに変更
    "port": 6379,
    "password": "your_redis_password"  // Redisのパスワードを追加
  }
}

▲/etc/sensu/conf.d/redis.json

{
  "rabbitmq": [                  // ハッシュ形式から配列形式に変更
    {
      "host": "163.44.169.160",  // RabbitMQ 1台目のIPアドレス
      "port": 5672,
      "vhost": "/sensu",
      "user": "sensu",
      "password": "secret"
    },
    {
      "host": "150.95.150.153",  // RabbitMQ 2台目のIPアドレス
      "port": 5672,
      "vhost": "/sensu",
      "user": "sensu",
      "password": "secret"
    }
  ]
}

▲/etc/sensu/conf.d/rabbitmq.json

　sensu-serverは追加の設定をせずに、ノードを追加するだけで自動でスケールアウトできるように設計されています。

• Sensu | Server | Automated Sensu server task election

　sensu-serverは主に3つのタスクを持っており、各タスクはクラスタ内のノードの1台で実行されます。

• check_request_publisher：sensu-clientに対してCheck（監視）の実行を依頼します
• client_monitor：新しいsensu-clientの「client_registry」や「keepalive」の監視を行います
• check_result_monitor：sensu-clientからの監視結果を受け取り、イベントを発火します

　各sensu-serverが担当しているタスクは、「Info API」で簡単に確認できます。試しにsensu-serverを1台停止すると、もう片方のsensu-serverにフェイルオーバーしました。

# sensu-serverが両系でタスクを分担している
$ curl sensu-two.hico.io:4567/info | jq -r '.servers[] | (.hostname, .tasks)'
sensu-one.hico.io
[
  "check_request_publisher"
]
sensu-two.hico.io
[
  "client_monitor",
  "check_result_monitor"
]
# 片系のsensu-serverを停止させる
$ ssh sensu-two.hico.io 'sudo systemctl stop sensu-server'
# もう片系のsensu-serverにフェイルオーバーした
$ curl sensu-one.hico.io:4567/info | jq -r '.servers[] | (.hostname, .tasks)'
sensu-one.hico.io
[
  "client_monitor",
  "check_result_monitor",
  "check_request_publisher"
]

▲各sensu-serverのタスクを確認する（bash）

Uchiwaを冗長化する

　最後に、冗長化した複数のsensu-apiに接続するように、Uchiwaの設定を変更します。"sensu"の配列で同じ"name"で登録することで、自動的にフェイルオーバーや負荷分散を行うようになります。

• High Availability - Uchiwa Documentation

{
  "sensu": [
    {
      "name": "sensu.hico.io",   // 冗長化しているsenus-apiでnameをそろえる
      "host": "163.44.169.160",
      "port": 4567
    },
    {
      "name": "sensu.hico.io",   // 冗長化しているsenus-apiでnameをそろえる
      "host": "150.95.150.153",
      "port": 4567
    }
  ],
  "uchiwa": {
    "host": "0.0.0.0",
    "port": 3000
  }
}

▲/etc/sensu/uchiwa.json

　Uchiwaの「Datacenters」メニューで「sensu.hico.io」を確認すると、2台のsensu-apiが登録されていることが確認できます（画面1）。

画面1　Uchiwaに2台のsensu-apiが登録されていることが確認できる

終わりに

　今回は、Sensu、Uchiwa、Redis、RabbitMQの冗長化構成について説明しました。Sensuは依存するミドルウェアも含めてアーキテクチャが複雑ですが、それぞれのソフトウェアは簡単にスケールアウトできるので、冗長化や可用性の向上という点ではメリットが大きいです。本稿の内容が、Sensuの導入の助けになれば幸いです。

　次回はヤフーの渡邉貴志氏より、大規模なプライベートクラウド環境におけるSensuの運用ノウハウを紹介していただきます。お楽しみに。

筆者紹介

堀内 晨彦（ほりうち あきひこ）

生まれも育ちも香川県。香川大学大学院 情報科出身。学生時代は研究の傍ら、勉強会やコミュニティー活動に積極的に参加し、「Sensu Deep Talks」などを主催。2016年4月からは上京し、ICT企業でベアメタルクラウドの開発に従事。趣味は料理とカメラ。

Webサイト：https://hico-horiuchi.github.io/