最典型的Salt组网拓扑结构是由一个Master节点控制一组Minion节点所组成的。 通过使用称为Syndic（字面原义为地方行政官）的中间节点类型，在构建Salt网络拓扑时，相比仅使用由Master和Minion节点类型构造的拓扑，提供了更大的结构上的灵活性和可伸缩性。
Syndic节点可以被认为是一个特殊的直通Minion节点。 Syndic节点由salt-syndic守护程序和在同一系统上运行的salt-master守护程序组成。 在Syndic节点上运行的salt-master守护程序控制一组较低级别的Minion节点，salt-syndic守护程序则连接更高级别的Master节点，有时称为Master of Masters。
salt-syndic守护程序为上级Master节点和本地salt-master守护程序提供发布和事件的中继服务。 这使Master节点也可以间接控制到连接到Syndic节点上运行的salt-master守护程序的那些Minions节点。
要设置Salt Syndic，需要让Syndic节点及它的上级Master节点互相知道对方的信息。 如果你的Master节点位于10.10.0.1，那么你需要按下面的方法进行配置。
在Syndic节点上面：
# /etc/salt/master
syndic_master: 10.10.0.1 # may be either an IP address or a hostname# /etc/salt/minion
# id is shared by the salt-syndic daemon and a possible salt-minion daemon
# on the Syndic node
id: my_syndic在Master节点上面：
# /etc/salt/master
order_masters: Truesyndic_master选项，告诉Syndic节点在哪里找到自己的上级Master节点，与我们使用master选项告诉Minion节点去哪里找到master节点的方式相似。
id选项，salt-syndic守护进程使用id选项来标识自己，如果未设置，则默认为Syndic的主机名或IP地址，就像使用Minion时的配置方法一样。
order_masters选项，配置该选项后会让Master节点在常规的事件和发布消息之外，额外发送与Syndic节点服务管理有关的消息。
注意
每个Syndic都必须使用和维护好自己的file_roots目录。发布操作使用的数据文件并不会自动地从上级Master节点传输过来。
New in version 2015.5.0.
使用Multimaster的Syndic可以连接到多个Masters服务器，为Syndic管理的minions节点提供了一个额外的冗余层次，提高了可用性水平。这需要首先把Syndic所使用的上级Masters配置为多主架构。 配置方法请参阅Multimaster配置教程。
在syndic上，使用syndic_master选项来定义更高级别的master的列表。
由于每个syndic都连接到每一个master，因此从任何master发送的job任务都会转发给连接到syndic的minions。 如果在更高级别Master服务器上的master config配置文件中设置了master_id这个选项值，则job的执行结果将会优先返回到发起这个job请求的那个Master服务器。 在没有设置master_id选项时，事件/作业的处理结果将返回给任何一个可用的master节点。
salt-syndic守护程序是一个单独的进程，除了在Syndic节点上运行salt-master守护程序之外，还需要启动salt-syndic程序。 启动salt-syndic守护程序的方法与启动其他Salt守护程序的方法相似。
Salt Master节点在许多方面将Syndic视为普通的Minion节点。 特别的是，Master也需要接受Syndic的Minion认证密钥，就像任何其他普通Minion一样。
在Syndic节点上面执行：
# salt-syndic
or
# service salt-syndic start在Master节点上面执行：
# salt-key -a my_syndic- 上面假定是你的Syndic节点设置id选项值为my_syndic
Master节点现在就可以控制连接到Syndic的Minions节点了。 只有Syndic节点的密钥才会列在Master节点的密钥注册表中，但这也意味着Syndic的Minions和Syndic之间的密钥认证管理不会成为Master节点的干扰。 通过这种方式，可以将Syndic在Master节点上的密钥视为其下方所有Minions节点和Syndic节点本身密钥的一个共同占位符，从而为 Salt Master 节点提供了一个清晰的高层级结构视图。
我们假定当前的测试环境中，有4个minions节点接入到了Salt Syndic服务中，而Syndic又接入到上级的Salt Master管理中。那么我们在Master节点上查看密钥列表信息，并执行一个test.ping的测试，会得到类似下面的输出结果。
在Master节点上执行：
# salt-key -L
Accepted Keys:
my_syndic
Denied Keys:
Unaccepted Keys:
Rejected Keys:
# salt '*' test.ping
minion_1:
True
minion_2:
True
minion_4:
True
minion_3:
True在Salt Master节点上（本身不是另一个更高级别Master节点的Syndic的节点）必须运行salt-master守护程序和可选的salt-minion守护程序。
Syndic节点则必须同时运行salt-syndic和salt-master守护进程以及可选的salt-minion守护进程。
Minion节点必须运行salt-minion守护程序。
当salt-master守护程序发出命令时，它将由直接连接到它的Syndic和Minion节点接收。 Minion节点将以通常的方式处理命令。 在Syndic节点上，salt-syndic守护程序将该命令中继到Syndic节点上运行的salt-master守护程序，然后该节点再将命令传播到与其连接的Minions和Syndics。Syndic支持级联。
当salt-minion守护进程生成事件和作业的返回数据时，会先由它们所连接的salt-master守护进程进行聚合，然后salt-master守护进程再通过其salt-syndic守护进程将数据中继回来，直到数据到达上级的Master节点 或发出命令的上级Syndic节点。
syndic_wait是一个Master配置文件中的配置选项，它指定了Salt Client在放弃之前应等待其他syndics检查其预期的minions列表的秒数。 该值默认为5秒。
syndic_wait选项的设置是有必要的，因为在更高级别的Master没有办法知道在syndic节点下面有哪些minions。 更高级别的Master有自己的预期minions列表，在他们下面的Masters也会有他们自己的预期连接的minions列表。所以Salt Client不会知道要等待所有的返回需要多少的时间。 syndic_wait选项定义了一个允许所有minions返回结果给Salt Client的超时时间。
注意
要减少CLI客户端等待Minions响应的时间，请在Syndic上安装Minion或调整syndic_wait配置的值。
虽然可以在不安装Minion的条件下运行Syndic服务，但为了得到更快的CLI响应，建议还是安装一个minion服务。 如果没有在Syndic节点上安装Minion，syndic_wait的超时值会显着增加（大约三倍）。 在Syndic上安装Minion后，CLI超时将保持在syndic_wait中定义的值。
注意： 如果你有一个非常大的基础设施或多层的Syndics，你可能会发现CLI没有等待足够长的时间，让所有Syndics返回其事件。 如果遇到了这种情况，则可以在执行命令的Master节点或Syndic节点上的Master配置中设置上syndic_wait选项的值。 默认值为5，应该适用于大多数的部署场景。
综上所述，为了使Master或Syndic节点从其Syndics下方的Minions返回信息，CLI需要等待一个较短的时间，以便允许Syndics收集来自其Minions的响应。 此值在syndic_wait配置选项中定义，默认值为五秒。
这些是可用于配置Syndic服务节点的选项。 请注意，除了id选项（在Minion配置文件中）之外，Syndic服务的配置选项都放在Syndic节点的Master配置文件中。
- id: Syndic id (由 salt-syndic daemon 和 salt-minion daemon 所共享)
- syndic_master: Master node IP address or hostname
- syndic_master_port: Master node ret_port
- syndic_log_file: 日志文件路径 (absolute or not)
- syndic_pidfile: pidfile文件路径 (absolute or not)
- syndic_wait: 该syndic服务节点等待minions返回结果的超时时间
从Salt 2016.11.0版本开始，引入了Pluggable Minion Data Cache的功能。 在Minion data cache中可以包含那些缓存在Salt Master上的Salt Mine data、minion grains和minion pillar信息。 默认情况下，Salt使用localfs缓存模块，但也可以使用其他外部数据存储。
使用可插拔的minion cache模块后，就可以允许存储在Salt Master上的关于Salt Minions的数据被复制到Minion所连接的其他Salt Masters上了。 有关更多信息和配置示例，请参阅Minion Data Cache文档。