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

» 2017年06月29日 05時00分 公開
[堀内晨彦@IT]
前のページへ 1|2       

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

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

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

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

 まずは、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は主に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"で登録することで、自動的にフェイルオーバーや負荷分散を行うようになります。


{
  "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 画面1 Uchiwaに2台のsensu-apiが登録されていることが確認できる

終わりに

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

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

筆者紹介

堀内 晨彦(ほりうち あきひこ)

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

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


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。