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

新たなクラウド監視ツールとして注目され始めている「Sensu」の活用方法を解説する本連載。今回は、Sensuを本番(プロダクション)環境で使うための冗長化について解説します。

» 2017年06月29日 05時00分 公開
[堀内晨彦@IT]
「Sensuで始めるクラウド時代のシステム監視」のインデックス

連載目次

Sensuの監視環境を冗長化するには

 前回は、「Sensu」でプラグインを使ってメトリクスを収集する方法と、その結果を「InfluxDB」に保存し、「Chronograf」で可視化するまでの流れを説明しました。

 今回は、Sensuを本番(プロダクション)環境で使うための冗長化について解説します。「sensu-server」「Redis」「RabbitMQ」をそれぞれ2系統ずつ構築することで、耐障害性を高めます。ここでは、Sensu、Redis、RabbitMQをインストールしたホストを2台用意し、SensuとRabbitMQはアクティブ−アクティブRedisはマスター(Master)−スレーブ(Slave)として構成します(図1)。

図1 図1 今回のSensuの冗長化構成。SensuとRabbitMQはアクティブ−アクティブ、Redisはマスター−スレーブで構成する

 なお、Sensu、Redis、RabbitMQをインストール方法については、以下の本連載の過去記事をご覧ください。

Redisのレプリケーションを構成する

 今回の構成では、Redisはマスター−スレーブ形式で冗長化されて、データがレプリケーションされるようになっています。スレーブはマスターから非同期でデータをコピーしており、マスターの“完全なコピー”となります。Redisのレプリケーションに関する細かい仕組みや設定は、以下の公式ドキュメントを参照してください。

 今回は、以下のSensuの公式ドキュメントに従って、2台のRedisでマスター−スレーブを構成します。

 まずは、マスター側(ここでは「sensu-one.hico.io」)の設定を行います。マスター側では複数のsensu-serverから接続できるように、ローカルホスト以外からの接続も受け入れるように設定します。併せて、接続時にはパスワード認証を行うようにします(「your_redis_password」は適宜ご自身の環境に置き換えてください)。


# ローカルホスト以外からの接続を受け入れる
$ sudo sed -i 's/^bind 127\.0\.0\.1$/# bind 127.0.0.1/g' /etc/redis/redis.conf
# パスワード認証を有効化(your_redis_passwordは適宜置き換えてください)
$ sudo sed -i 's/^# requirepass foobared$/requirepass your_redis_password/g' /etc/redis/redis.conf
# Redisのサービス(デーモン)を起動
$ sudo /etc/init.d/redis-server start
▲マスター(sensu-one.hico.io)の設定(bash)

 次に、スレーブ側(ここでは「sensu-two.hico.io」)の設定を行います。マスターと同様にローカルホスト以外からの接続の受け入れと、パスワード認証の設定を行います。自身が“マスターのスレーブであること”と、マスターのパスワードを設定すれば、スレーブとして動作します。


# ローカルホスト以外からの接続を受け入れる
$ sudo sed -i 's/^bind 127\.0\.0\.1$/# bind 127.0.0.1/g' /etc/redis/redis.conf
# パスワード認証を有効化(your_redis_passwordは適宜置き換えてください)
$ sudo sed -i 's/^# requirepass foobared$/requirepass your_redis_password/g' /etc/redis/redis.conf
# Master(sensu-one.hico.io)のレプリケーションを設定
$ sudo sed -i 's/^# slaveof <masterip> <masterport>$/slaveof sensu-one.hico.io 6379/g' /etc/redis/redis.conf
# Masterのパスワード認証を設定(requirepassと対応)
$ sudo sed -i 's/^# masterauth <master-password>$/masterauth your_redis_password/g' /etc/redis/redis.conf
# Redisのサービス(デーモン)を起動
$ sudo /etc/init.d/redis-server start
▲スレーブ(sensu-two.hico.io)の設定(bash)

 最後に、レプリケーションが構成されたことを「redis-cli」コマンドで確認します。マスターがスレーブに接続していること、スレーブがマスターに接続していることが確認できます。


# Masterでconnected_slaves:1であることを確認
$ redis-cli -h sensu-one.hico.io -a your_redis_password INFO | grep -A 2 role
role:master
connected_slaves:1
slave0:ip=150.95.150.153,port=6379,state=online,offset=603,lag=0
# Slaveでmaster_link_status:upであることを確認
$ redis-cli -h sensu-two.hico.io -a your_redis_password INFO | grep -A 3 role
role:slave
master_host:sensu-one.hico.io
master_port:6379
master_link_status:up
▲「redis-cli」コマンドでレプリケーション構成を確認する(bash)

 ここまでの設定で、Redisのレプリケーション(マスターとスレーブのデータ同期)が設定できました。

 ただ、この構成ではマスター側に障害が発生したときの「スレーブの昇格(フェイルオーバー)」まではサポートされていません。公式の監視およびフェイルオーバー用ツールとしては「Sentinel」が提供されています。SensuでもSentinelをサポートしているので、興味のある方は試してみてください。

 他にも、「Consul」などのサービスディスカバリ系ツールを使っている事例もあります。筆者の職場ではConsulを使っており、マスターの監視に失敗すると、スレーブでスクリプトを実行してマスターに昇格させるといった運用を行っています。ConsulはDNS(Domain Name System)の機能を持っており、常にマスターのIPアドレスを引けるようになっているので便利です。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

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

メールマガジン登録

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