Multi Master Tutorial¶
As of Salt 0.16.0, the ability to connect minions to multiple masters has been made available. The multi-master system allows for redundancy of Salt masters and facilitates multiple points of communication out to minions. When using a multi-master setup, all masters are running hot, and any active master can be used to send commands out to the minions.
Note
If you need failover capabilities with multiple masters, there is also a MultiMaster-PKI setup available, that uses a different topology MultiMaster-PKI with Failover Tutorial
In 0.16.0, the masters do not share any information, keys need to be accepted
on both masters, and shared files need to be shared manually or use tools like
the git fileserver backend to ensure that the file_roots are
kept consistent.
Beginning with Salt 2016.11.0, the Pluggable Minion Data Cache
was introduced. The minion data cache contains the Salt Mine data, minion grains, and minion
pillar information cached on the Salt Master. By default, Salt uses the localfs cache
module, but other external data stores can be used instead.
Using a pluggable minion cache modules allows for the data stored on a Salt Master about Salt Minions to be replicated on other Salt Masters the Minion is connected to. Please see the Minion Data Cache documentation for more information and configuration examples.
Summary of Steps¶
Create a redundant master server
Copy primary master key to redundant master
Start redundant master
Configure minions to connect to redundant master
Restart minions
Accept keys on redundant master
Prepping a Redundant Master¶
The first task is to prepare the redundant master. If the redundant master is
already running, stop it. There is only one requirement when preparing a
redundant master, which is that masters share the same private key. When the
first master was created, the master's identifying key pair was generated and
placed in the master's pki_dir. The default location of the master's key
pair is /etc/salt/pki/master/. Take the private key, master.pem, and
copy it to the same location on the redundant master. Do the same for the
master's public key, master.pub. Assuming that no minions have yet been
connected to the new redundant master, it is safe to delete any existing key
in this location and replace it.
Note
There is no logical limit to the number of redundant masters that can be used.
Once the new key is in place, the redundant master can be safely started.
Configure Minions¶
Since minions need to be master-aware, the new master needs to be added to the minion configurations. Simply update the minion configurations to list all connected masters:
master:
- saltmaster1.example.com
- saltmaster2.example.com
Now the minion can be safely restarted.
Note
If the ipc_mode for the minion is set to TCP (default in Windows), then each minion in the multi-minion setup (one per master) needs its own tcp_pub_port and tcp_pull_port.
If these settings are left as the default 4510/4511, each minion object will receive a port 2 higher than the previous. Thus the first minion will get 4510/4511, the second will get 4512/4513, and so on. If these port decisions are unacceptable, you must configure tcp_pub_port and tcp_pull_port with lists of ports for each master. The length of these lists should match the number of masters, and there should not be overlap in the lists.
Now the minions will check into the original master and also check into the new redundant master. Both masters are first-class and have rights to the minions.
Note
Minions can automatically detect failed masters and attempt to reconnect to them quickly. To enable this functionality, set master_alive_interval in the minion config and specify a number of seconds to poll the masters for connection status.
If this option is not set, minions will still reconnect to failed masters but the first command sent after a master comes back up may be lost while the minion authenticates.
