Multi-master configurations

295 views
Skip to first unread message

Aaron Tygart

unread,
Aug 16, 2012, 9:50:26 PM8/16/12
to salt-...@googlegroups.com
Hello All,

I'm looking to configure a multi-master setup for salt for
availability's sake. The message-passing that I'd be using Salt for is
very important and the minions need to be able to receive commands
from more than one master.

I've looked at Syndic, but it too seems limited to just one upstream
master. I can make a ring topology, but then comes the issue of
configuring the minons: which side do I point them at? I do have
load-balancers at my disposal, and if ZeroMQ is friendly to that I can
just share private keys among my masters.

I'm planning on replacing the file-backed public key infrastructure
with something that will talk to my MongoDB instance. So I've already
got a solution for the minion pubkey trading shenanigans. (If there's
an opportunity to make this pluggable as well, I'd love to publish it)
--
Aaron Tygart

Yann Malet

unread,
Aug 17, 2012, 3:07:46 AM8/17/12
to salt-...@googlegroups.com
There is a slightly related issue open #1500 that request the capability to allow for files to be progressively looked for from multiple sources.

Regards,
--yml

Thomas S Hatch

unread,
Aug 17, 2012, 1:15:53 PM8/17/12
to salt-...@googlegroups.com
PKI in mongo eh? That sounds interesting! The interface here is not to particularly pluggable, but that can of course be changed. As for multiple masters, you can use a vip for high availability so the minions fail over to a new master, btu as for minions listening to multiple masters this has not been ironed out yet.

Aaron Tygart

unread,
Aug 17, 2012, 1:44:15 PM8/17/12
to salt-...@googlegroups.com
Yeah, I can't imagine trying to intelligently synchronize public keys
for a couple thousand minions across several datacenters with rsync. I
already have a large-scale mongo cluster with a system inventory
collection. I figure I'll add another field to the collection for the
given system's public key and never have to worry about file-syncing
shenanigans.

The existing PKI system seems pretty straightforward and easy to
subclass. The private keys will still need to be file-based for
obvious reasons, but all the public stuff seems better off in mongo
for large scale installations. Especially when we consider future
cases like multi-master setups and transitioning minons between
datacenters (and thus between masters).

I guess that the PKI system doesn't necessarily have to be
'pluggable'. I'll just need to do more source diving to be sure I
understand how the auth is bootstrapped and the config is loaded.
--
Aaron Tygart

Thomas S Hatch

unread,
Aug 17, 2012, 1:46:40 PM8/17/12
to salt-...@googlegroups.com
Sounds good, any way about it, you should probably try to only store public keys on something like mongo
Reply all
Reply to author
Forward
0 new messages