I found this blog post informative, illustrating one way to setup
For the sensu-server part, yes, leader election is automatic and does
not need to be configured. As long as they are using the same redis
master, it will work:
RabbitMQ you can do whatever works best for your environment. To KISS
I put RabbitMQ on each sensu server and cluster them in mirror mode
per the failshell article. In my particular setup, it is not required
that a sensu-server us the local RMQ instance, but it can. In
practice it doesn’t matter as long as they are mirrored:
The Redis part is a little tricky, but the failshell article also
covers how he handles it. However you do it, all sensu servers / api /
dashboards need to talk to a redis master. If you use something
fancy to move that around, that is cool.
Again, I’m using the failshell approach with haproxy. Maybe someday
Sensu will be Sentinel-aware?
Not to spread FUD, but if you are going to setup a Redis cluster, you
should be at least aware of the potential failure modes during splits:
Welcome to the world of distributed systems!
On Sat, Feb 8, 2014 at 1:42 AM, lo...@spaceapegames.com wrote:
I am looking to improve on our single Sensu server installation. First port
of call is resiliency, and most immediate answer there is - multiple
However I am struggling to find information on this topic. I’ve read the
FAQs and the docs and various blog posts, I understand that there is some
sort of covert master/slave election between servers, but don’t see where
that would be configured : how do the servers know about eachother?
Also, is it mandatory to separate the RabbitMQ instances into a separate
tier, or can each server run RabbitMQ locally? Similarly, can they use a
local Redis instance or does one need to configure a shared Redis backend
(or Elasticache, whatever)?
Any assistance would be much appreciated, I’m a big fan of Sensu and just
want to take our use of it to the next level.