SaltStack中的服务高可用设计

本文是翻译自SaltStack官网文档中的Architecture部分，若有不准确之处还请直接参考下官网原文。

High Availability Features in Salt - Salt中的服务高可用设计

Salt支持多种可实现高可用性和容错性的功能。 这些功能的简要文档与配置参数一起在配置文件的示例中有列出。

MULTIMASTER

通过将master配置参数配置为一个包含所有可用master设备的YAML列表，Salt minions可以一次连接到多个master设备。 默认情况下，这些masters是多活的，这意味着任何master服务器都可以将命令发送给Salt基础设施。

在多master架构配置中，每个master都必须具有相同的加密密钥，并且必须分别在所有master上接受minions的密钥。 file_roots和pillar_roots下的内容也需要保持数据的同步，这一般是通过Salt外部的其他系统进程或方法来实现。

一篇设置多master体系架构的配置教程如下：Multimaster配置教程

MULTIMASTER WITH FAILOVER

将master_type参数从str更改为failover将导致minions连接到master服务器列表中的第一个返回响应的master服务器。 每隔master_alive_interval秒minions都会检查当前master是否还在响应。 如果master设备没有响应，则minions将尝试连接到列表中的下一个master设备。 如果列表中提供的masters都尝试过了，那么将重新从头尝试，以识别和连接到那些已经恢复了的master设备上。 请注意，master_alive_interval必须存在于minion配置中，否则将无法调度检查master状态的定期作业。

故障转移可以与PKI-style的加密密钥结合使用，但PKI对使用failover功能并没有要求。

本教程中讨论了给合使用PKI和failover的Multimaster架构。

master_type：failover可以与master_shuffle：True结合使用，这将会打乱原有的master与minions的连接关系，将minions的连接打散到所有的master设备上去，变为每个minion分别去连接某一个master。 再将Salt Syndics添加到该混合架构中就可以创建一个具有负载均衡功能的Salt基础架构了。 如果一个master失败，minions会注意到并从可用列表中选择另一个master。

SYNDIC

Salt的Syndic功能提供了一种创建不同基础架构拓扑的方法。 它虽然不是严格意义上的HA功能，但可以这样使用。

使用syndic，可以对Salt基础设施进行分区管理，指定某些master服务器控制基础设施的某些分区，而一个“Master of Masters”的设备节点则可以控制它们下面的多个基础设施分区。

Syndics在Salt Syndic中有详细介绍。

SYNDIC WITH MULTIMASTER

New in version 2015.5.0.
给合使用Multimaster与Syndic，允许您将syndic连接到多个master服务器，以在syndic配置中提供额外的冗余层。

Syndics在Salt Syndic中有详细介绍。

MULTI MASTER TUTORIAL - Multimaster架构的配置教程

从Salt 0.16.0开始，已经提供了将minions连接到多个masters的功能。 multi-master系统允许Salt masters节点的冗余部署，并提供了通过多个通信节点管理到minions的便利。 当使用一个多主的系统时，所有的master都在运行，并且都可用于向minions发送命令。

注意

如果你希望按照故障转移的方式来使用多个masters服务器，则还可以使用MultiMaster-PKI功能设置，该功能通过使用了不同的拓扑，实现了一种给合使用PKI和failover的Multi-master部署架构，详见：MultiMaster-PKI with Failover Tutorial

在0.16.0中，masters服务器之间不共享任何信息，需要在两个主服务器上分别接受密钥，并且需要手动共享共享文件或使用git fileserver后端等工具来确保file_roots保持一致。

从Salt 2016.11.0开始，引入了Pluggable Minion Data Cache。 minion数据缓存包含Salt Master数据，minion grain和缓存在Salt Master上的minion pillar信息。 默认情况下，Salt使用localfs缓存模块，但也支持使用其他外部数据存储。

使用可插拔的minion缓存模块，允许存储在Salt Master上的关于Salt Minions的数据被复制到Minion所连接的其他Salt Masters上。 有关更多信息和配置示例，请参阅相关文档。

步骤

1. 创建出一个冗余的master server；
2. 拷贝primary master的密钥信息到冗余的master server上；
3. 启动冗余的master server；
4. 配置minions也同时连接到这个冗余的master server；
5. 重启minions服务进程；
6. 在冗余master上接受minions发来的密钥认证消息；

准备一个冗余的master

第一项任务是准备冗余mater。 如果冗余master已在运行，请先将其停止。 准备冗余master服务器时只有一个要求，即要与primary master服务器共享相同的私钥。 在创建的第一个master服务器时，会生成主服务器的标识密钥对并将其放在master服务器的pki_dir中。 存放master密钥对的默认位置是/etc/salt/pki/master/。 获取私钥master.pem，并将其复制到冗余master服务器上的相同位置。 对master的公钥master.pub也执行相同的操作。 我们假定尚未将任何新的minions连接到我们的冗余master主机，可以安全地删除此位置中的任何现有密钥并替换它。

注意

在我们最多可以使用的冗余master服务器的数量这一点上，并不存在任何的限制。

当我们将新的密钥放置妥当后，即可以通过重启冗余master服务来生效。

配置minions

由于minions需要掌握master的相关信息，因此需要将新的master信息也添加到minion的配置中。 只需更新minion配置，以列出所有需要连接的masters，像下面这样：

master:
  - saltmaster1.example.com
  - saltmaster2.example.com

然后，重启minon服务进程。

注意

如果minion的ipc_mode设置为TCP（Windows中为默认值），那么在multi-minion设置中的每个minion（每个master分配一个）都需要有自己专用的tcp_pub_port和tcp_pull_port。

如果这些设置保留为默认值4510/4511，则每个minion对象将收到比前一个更高的端口2。 因此，第一个minion将获得4510/4511，第二个将获得4512/4513，依此类推。 如果这些端口决策是未授权访问的，则必须为每个master服务器配置好tcp_pub_port和tcp_pull_port以及需要放行的端口列表。 这些端口列表的长度应与master数量相匹配，列表中不应有重复。

现在，minions将检查原始的master服务并检查新的冗余master服务。 两位master都是相同级别的，对连接的minions拥有相同的权利。

注意

Minions可以自动检测服务失败的master并尝试重新连接以快速重连。 要启用此功能，需要在minion配置中设置master_alive_interval参数，指定轮询master服务器的连接状态的秒数。

如果未设置此选项，minions仍将重新连接到失败了的master服务器，但在主服务器重新启动后发送的第一个命令可能会在处理minion身份验证时被丢失。

在多个masters服务器之间共享文件

Salt不会自动在多个masters服务器之间共享文件。 在使用多主架构时，推荐在多masters间共享下面这些文件。

MINION KEYS

可以使用两个master服务器上的salt-key命令以正常方式接受Minion密钥。 在一个master设备上接受、删除或拒绝的密钥不会在冗余master设备上自动地做出相同的配置管理; 这需要同时通过在两个master服务器上运行salt-key或在master服务器之间共享/etc/salt/pki/master/{minions，minions_pre，minions_rejected}目录来实现。

注意

虽然共享/etc/salt/pki/master目录将有效解决多masters间的数据共享问题，但强烈建议不要这样做，因为允许访问Salt之外的主机访问master.pem密钥会产生严重的安全风险。

FILE_ROOTS

file_roots内容应在masters服务器之间保持一致。 否则，会由于一个master管理的指令与其他master不一致，导致state runs在minions上并不总是一致的。

同步这些文件的推荐方法是使用像gitfs这样的文件服务器后端，或者将这些文件保存在共享存储上。

重要

如果使用gitfs/git_pillar与使用GlusterFS、nfs或其他网络文件系统的masters服务器之间共享cachedir，并且masters服务器正在运行Salt 2015.5.9或更高版本时，强烈建议不要关闭gitfs_global_lock/git_pillar_global_lock。因为这样做会导致锁文件被删除，如果它是由其他masters服务所创建的。

PILLAR_ROOTS

Pillar root应该与file_roots一样考虑。

MASTER CONFIGURATIONS

虽然可能存在一些原因，会维护一些单master服务独有的配置信息，但是一定要记住的是每个master设备都对minions保持着相互独立的控制权限。 因此，应该在masters服务器之间保持访问控制信息上的同步，除非存在其他特殊的原因以保持它们的不一致。

这些特殊的访问控制选项包括但不限于：

• external_auth
• publisher_acl
• peer
• peer_run

Multi-Master-PKI Tutorial With Failover - 给合使用PKI和failover的Multimaster架构

本教程将解释如何运行一套salt-environment，其中单个minion可以拥有多个master服务器，并且如果当前master服务器失败了，则在它们之间进行故障转移。

配置步骤是：

• 配置master(s)，签署其auth-reply
• 设置minion(s)，以验证master-public-keys
• 在minion(s)上启用对多masters的支持
• 在minion(s)上启用master-check功能

请注意，建议你事先对salt身份验证和通信过程进行了解，以理解本教程的内容。 此处描述的所有设置都在salt默认的身份验证/通信过程之上实现的。

起因

salt-minion的默认行为是连接到一个master服务器并接受master服务器的公钥。 随着每个发布管理命令，master发送他的public-key供minion检查，如果这个public-key发生了变化，则minion会报错并退出。 实际上，这意味着在任何给定时间只能有一个master。

如果当前的master因网络或硬件故障而失联了，但minion可以拥有任意数量的masters（1：n），那么会不会更好？

注意

另外还有一个MultiMaster-Tutorial的部署方案，它具有与此不同的方法和拓扑，显然也更加简单，可能也能满足你的需求，甚至可能更适合，请参见Multi-Master Tutorial

我们还希望在一个minion从master那里收到的第一个公钥信息的过程中添加一些真实性检查。 目前，minion将接受第一个master的公钥视为理所当然的行为。

目标

设置master设备以签署它发送给minions的公钥，并使minions能够验证此签名的真实性。

配置master以签署公钥

要使用签名功能，master和minion都必须启用签名和/或验证的设置。 如果master签署了公钥但是minion没有核实，那么minion就会报错并退出。 同样的情况也发生在，当master没有签名但是minion试图验证时。

让master签名其公钥的最简单方法是设置:

master_sign_pubkey: True

在重新启动salt-master服务后，master服务器将自动生成新的用于签名服务的密钥对:

master_sign.pem
master_sign.pub

可以指定一个自定义的密钥对的名称：

master_sign_key_name: <name_without_suffix>

然后，master服务器将在重新启动时生成该密钥对，并使用它来创建附加到auth-reply的公钥签名。

这种计算是针对一个minion的每个auth-request完成的。 如果有许多minions频繁做授权，建议使用下面描述的conf_master：master_pubkey_signature和conf_master：master_use_pubkey_signature设置。

如果正在使用多个masters服务器且启用了签署其auth-reply的功能，则必须将用于签名的密钥对master_sign.*文件复制到每一个master服务器上。 否则，当连接到不同的master时，minion将会因为公钥签名是使用不同的签名密钥对创建的，而无法验证master的公钥信息。

配置minion来验证收到的公钥

Minion需要拥有签名使用的公钥（并且只能是正确的那个！）才能验证它收到的签名。 我们需要将该公钥（默认为master_sign.pub）从master服务器复制到minions节点的pki-directory中一份。

/etc/salt/pki/minion/master_sign.pub

千万不要把 master_sign.pem文件也复制走了，这个私钥文件只能存放在master上

当准备好上面的公钥文件后，在minions的配置中启动签名检查的功能：

verify_master_pubkey_sign: True

以debug模式重启下salt minion服务，这样便于观察下上面配置的功能是否正常：

salt-minion -l debug

启动后，你应该能看到类似下面这样的debug日志信息：

[DEBUG   ] Attempting to authenticate with the Salt Master at 172.16.0.10
[DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG   ] salt.crypt.verify_signature: Loading public key
[DEBUG   ] salt.crypt.verify_signature: Verifying signature
[DEBUG   ] Successfully verified signature of master public key with verification public key master_sign.pub
[INFO    ] Received signed and verified master pubkey from master 172.16.0.10
[DEBUG   ] Decrypting the current master AES key

或者，运气不好的话，也许看到的是类似下面这样的报错信息：

[DEBUG   ] Attempting to authenticate with the Salt Master at 172.16.0.10
[DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG   ] salt.crypt.verify_signature: Loading public key
[DEBUG   ] salt.crypt.verify_signature: Verifying signature
[DEBUG   ] Failed to verify signature of public key
[CRITICAL] The Salt Master server's public key did not authenticate!

在这种情况下，应该检查，minion上的验证pubkey（master_sign.pub）与master上的验证pubkey（master_sign.pub）是否相同。

确认可以验证成功后，再把minion改为使用守护进程模式启动。

对于信息安全有近乎偏执得严格要求的人，也可以配置为对从master收到的所有数据做签名校验。

always_verify_signature: True

配置minion(s)启用对多masters的支持

通过设置以下两个参数的来完成在minion上配置多个master服务器：

• 指定一个masters服务器的列表
• 定义master的类型

master:
    - 172.16.0.10
    - 172.16.0.11
    - 172.16.0.12

master_type: failover

这告诉minion上面的所有master都可以连接。 使用此配置启动minion服务时，它将按照定义的顺序尝试连接master服务器。

如果希望minion随机连接到上面列表中的某一个master，请设置：

master_shuffle: True

于是，在minion第一次连接尝试之前会先对master列表的内容打乱原有的顺序。

接受minion的第一个master会被minion所使用。

为了使minion能够检测它是否仍然连接到其当前的master设备，可以启用它的健康检查功能：

master_alive_interval: <seconds>

如果检测到连接已经丢失了，则minion将临时从列表中删除失败的master服务器并尝试连接到其他已经定义了的一个master服务器上（如果启用了shuffle参数，则还会再次对master列表内容进行洗牌）。

测试设置

至少需要准备好两个masters来测试多masters的故障转移功能。

两个salt masters都需要运行起来，然后为了便于观察测试数据，我们使用debug模式运行salt minion：

salt-minion -l debug

启动minion后，会连接至master列表中的第一个master服务器上面：

[DEBUG   ] Attempting to authenticate with the Salt Master at 172.16.0.10
[DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG   ] salt.crypt.verify_signature: Loading public key
[DEBUG   ] salt.crypt.verify_signature: Verifying signature
[DEBUG   ] Successfully verified signature of master public key with verification public key master_sign.pub
[INFO    ] Received signed and verified master pubkey from master 172.16.0.10
[DEBUG   ] Decrypting the current master AES key

我们可以登录到master列表中的第一个master服务器上，执行下test.ping命令，来验证测试下这个minion访问master服务的连通性。

如果上面的测试通过了，那我们可以把minion连接上的这个master服务先关闭掉，或者通过系统防火墙屏蔽下服务端口的访问。然后观测下salt多masters架构的故障转移功能。

根据在minion配置文件中设置的master_alive_interval参数所指定的健康检查时间间隔，minion会探测到自己已经不能再正常连接到当前的salt master服务，它会把这个信息也在日志中写入一份，像下面这样。

[INFO    ] Connection to master 172.16.0.10 lost
[INFO    ] Trying to tune in to next master from master-list

然后，minion将从列表中删除当前的master，并尝试连接到下一个master

[INFO    ] Removing possibly failed master 172.16.0.10 from list of masters
[WARNING ] Master ip address changed from 172.16.0.10 to 172.16.0.11
[DEBUG   ] Attempting to authenticate with the Salt Master at 172.16.0.11

如果一切配置正确，将成功验证新的master的密钥公钥：

[DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG   ] salt.crypt.verify_signature: Loading public key
[DEBUG   ] salt.crypt.verify_signature: Verifying signature
[DEBUG   ] Successfully verified signature of master public key with verification public key master_sign.pub

使用新master服务器身份验证成功：

[INFO    ] Received signed and verified master pubkey from master 172.16.0.11
[DEBUG   ] Decrypting the current master AES key
[DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[INFO    ] Authentication with master successful!

这时，在新的master服务器上执行针对这个minion的test.ping测试，可以成功返回结果。

性能调优

通过上述设置，master设备会为每个minion的auth-request请求计算签名。 在有许多minions和频繁的auth请求时，这可以消耗掉master服务器上相当多的CPU资源。

为了避免这种情况，master设备可以使用其公钥预先创建好一个签名。 将签名保存为base64编码的字符串，由master服务在启动时读取一次，并仅将该字符串附加到auth-reply中。

可以使用下面的命令创建该签名：

salt-key --gen-signature

这将在master的 pki-directory目录中创建一个默认的签名文件。

/etc/salt/pki/master/master_pubkey_signature

它是一个简单的文本文件，内容是二进制签名转换为base64格式。

如果在此之前还没有生成过签名密钥对，则可以在同一次的调用中自动创建签名密钥对和签名文件：

salt-key --gen-signature --auto-create

设置下面的参数告诉master服务使用预先创建的签名文件：

master_use_pubkey_signature: True

注意这要求’master_pubkey_signature’文件已经放在master服务器的pki目录中，且具有正确的签名信息。

可以使用下面的参数自定义签名文件的文件名：

master_pubkey_signature: <filename>

对于同时部署和使用了很多master服务器的情况，会有多个公钥（默认和签名），建议使用salt-masters的主机名作为签名的文件名。 因为签名很容易混淆，单单从这个文件的内容上看不出任何有关创建签名的密钥的信息。

在使用这些功能时，请验证你配置的服务是否一切正常，且是按照与上面相同的方式完成的。

签名和验证是如何运作的

salt-master的默认密钥对是：

/etc/salt/pki/master/master.pem
/etc/salt/pki/master/master.pub

为了能够创建对消息的签名（在这种情况下主要是指的公钥），必须将另一个密钥对添加到salt master服务的设置中。 它的默认名称是：

master_sign.pem
master_sign.pub

master.*和master_sign.*密钥对的组合使用，提供了生成（公钥）签名的可能性。 如果签名密钥对所使用的公钥对接收者（minion）是可用的，则给定消息的签名就可以确定是唯一并且可以被验证的。

使用下面的方法计算master服务器公钥master.pub的签名：

master_sign.pem
master.pub
M2Crypto.EVP.sign_update()

这会导致把二进制签名转换为base64格式并附加到aution-reply中发送给minion。

minion因为是可以使用本地存放好的签名对公钥文件的，所以可以用下面的方法对签名的真实性做验证：

master_sign.pub
master.pub
M2Crypto.EVP.verify_update()

在运行了多个master服务器时，必须在所有master服务器上都存放好用于签名的密钥对，或者必须为每个master服务器单独预先计算master_pubkey_signature（因为它们都具有不同的公钥）。

SALT SYNDIC - Salt分区管理

最典型的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节点。

配置SYNDIC

要设置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: True

syndic_master选项，告诉Syndic节点在哪里找到自己的上级Master节点，与我们使用master选项告诉Minion节点去哪里找到master节点的方式相似。

id选项，salt-syndic守护进程使用id选项来标识自己，如果未设置，则默认为Syndic的主机名或IP地址，就像使用Minion时的配置方法一样。

order_masters选项，配置该选项后会让Master节点在常规的事件和发布消息之外，额外发送与Syndic节点服务管理有关的消息。

注意

每个Syndic都必须使用和维护好自己的file_roots目录。发布操作使用的数据文件并不会自动地从上级Master节点传输过来。

在MULTIMASTER架构中配置SYNDIC服务

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节点。

运行SYNDIC

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选项

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 服务的配置选项

这些是可用于配置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返回结果的超时时间

MINION DATA CACHE

从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文档。

Using Salt at scale - 在更大规模范围内使用Salt时会遇到的一些问题

本教程的重点是帮助构建一个Salt基础设施架构来有效地管理大量的minions。 这将包括性能调优、拓扑设计和一些最佳实践。

注意

本教程提供的一些建议更适用于大型的技术系统安装部署，虽然这些相同的设置不会带来什么不良的影响，但在小规模的技术系统部署中，可能并不值得增加这些复杂性。

在我们这里，当与minions一起使用时，术语“许多”指的是至少一千个，而“少数”则是意味着500个或更少。

为简单起见，本教程将默认使用Salt使用的标准端口。

关于Master服务

在大规模范围内使用时， Salt Master 经常遇到下面这些挑战：

• 有许多的minions同时在进行密钥认证
• 有许多的minions同时在进行重新认证
• 有许多的minions同时在重新连接Master
• 有许多的minions同时在返回数据
• 资源严重不足（CPU/HDD）

前三个都属于“惊群”问题。 为了缓解这些问题，我们必须将minions配置为在Master节点负载较重时可以适当地退回。

第四个问题则是由拥有少量硬件资源的Master设备和ZeroMQ中可能存在的错误引起的。 至少到目前为止它看起来像是因为这个原因(Issue 118651, Issue 5948, Mail thread)。

要完全理解每个问题，了解Salt的工作原理是非常重要的。

简而言之，Salt Master为minions提供两种服务。

• 一个默认运行在4505端口的job发布服务
• 一个默认运行在4506端口的用于接收minions返回结果的服务

所有的minions始终都是在端口4505上连接到job publisher服务，并且如果有需要，也会连接到打开的结果返回端口4506。 在一个负载比较空闲的Master上，只会使用端口4505进行连接。

有许多的minions同时在进行密钥认证

当Minion服务首次启动时，它将通过端口4505连接到Master的发布者。如果同时启动太多的minions，这可能会导致“惊群”效应。 这可以通过避免立即启动太多的minions来避免。

连接本身通常不是罪魁祸首，主要问题的原因更可能是Master必须对Minions进行的身份验证。 如果Master服务器负载过重而无法处理身份验证请求，则会将其计时并让其等待。 然后Minion将在等acceptance_wait_time后进行重试。 如果设置了acceptance_wait_time_max，那么Minion将在每次后续的重试操作之前通过acceptance_wait_time增加其等待时间，直到达到acceptance_wait_time_max为止。

有许多的minions同时在进行重新认证

这比较容易发生在Salt部署的测试阶段，当所有Minion密钥都已被接受时，但框架却还在测试，并且在Salt Master的配置文件中的参数也经常更改。

Salt Master在某些事件（例如Master重启或删除Minion密钥）时会生成一个新的AES密钥，用于加密其发布任务。 如果你遇到许多minions对Master服务器做重新认证操作的问题，那么你需要重新调整下你的安装配置任务以降低触发这类事件的频率，如Master重启或Minion密钥删除等事件（salt-key -d）。

当Master生成新的AES密钥时，不会主动通知minions，但会在他们收到的下一个pub job任务中，携带上这一重新认证的消息。 当Minion收到这样的job后，它将与Master重新认证。 由于Salt执行管理命令时，经常会使用minions端的过滤规则，这意味着许多的minions都会在Master发布的下一个命令时，重新进行认证。这无疑也会导致另一个“惊群”效应。 这个问题是可以通过设置下面的参数来避免的：

random_reauth_delay: 60

可以在minions配置文件中适当的设置这个选项值并在使用Salt的过程中有意错开可能引发重新认证尝试的minions数量。增加这个选项值，在一些场景下显然也会增加使用Salt命令管理所有minions时所需要等待的时间。

有许多的minions同时在重新连接Master

默认情况下，zmq socket套接字将每100毫秒重新连接一次，对于某些较大规模的部署来说可能太频繁了。 这可以控制重新建立TCP会话的速度，不过这与认证的负载无关。

要调整minions套接字重新连接的尝试，在配置文件中有一些选项可以使用（默认值）：

recon_default: 1000
recon_max: 5000
recon_randomize: True

• recon_default：套接字应使用的默认值，即1000.此值以毫秒为单位。 （1000ms = 1秒）
• recon_max：套接字在尝试重新连接之前应该用作延迟的最大值，此值以毫秒为单位。 （5000毫秒= 5秒）
• recon_randomize：启用该选项后，会在recon_default和recon_max之间随机得选取一个值。

要将这些值配置到你的现有环境，必须做出一些决定：

• 在minions在线并通过Salt可以管理到之前，你可以等待多长时间？
• Master服务器可以同时处理多少的重新连接的请求，才不致于导致syn flood的问题？

这些问题一般都不容易回答。 他们的答案取决于设备硬件和管理员的要求。

这是一个示例场景，目标是让所有minions在Salt Master服务重启时，在60秒的时间范围内重新连接上来。

recon_default: 1000
recon_max: 60000
recon_randomize: True

每个Minion将在’recon_default’和’recon_default + recon_max’之间随机选择一个重新连接的等待时间值，在此示例中意味着是在1000ms和60000ms之间（或在1到60秒之间）。 每次尝试重新连接后，生成的随机值将加倍（ZeroMQ默认行为）。

假设生成的随机值是11秒（或11000ms），那么其后续再尝试连接时的等待时间会是：

reconnect 1: wait 11 seconds
reconnect 2: wait 22 seconds
reconnect 3: wait 33 seconds
reconnect 4: wait 44 seconds
reconnect 5: wait 55 seconds
reconnect 6: wait time is bigger than 60 seconds (recon_default + recon_max)
reconnect 7: wait 11 seconds
reconnect 8: wait 22 seconds
reconnect 9: wait 33 seconds
reconnect x: etc.

当有1000个minions时，意味着：

1000/60 = ~16

每秒会收到16次的连接尝试。 应将这些值更改为与你的环境匹配的值。 但请记住，它可能会随着时间的推移而增长，而且更多数量的minions也可能会再次触发这个问题。

有许多的minions同时在返回数据

这种场景也可以在测试阶段发生，如果所有的minions都被立即的执行一个管理命令：

$ salt * disk.usage

它可能导致成千上万的minions试图将他们的数据返回到Salt Master的开放端口4506.如果Master无法立即处理那么多返回数据，也会导致大量的syn-flood风暴。

使用Salt的批处理模式就可以轻松避免这种情况：

$ salt * disk.usage -b 50

这将通过循环的方式处理所有的minions，每次只同时处理50个minions。

资源严重不足（CPU/HDD）

Master设备的资源总是需要与所管理的环境相匹配。 如果不了解Master所运行的环境，就无法给出好的建议。但是这里有一些针对不同情况下都适用的一般调整技巧：

THE MASTER 的CPU资源挑战

Salt在masters和minions两端通信时使用RSA-Key-Pairs。 两者都在第一次启动时生成4096位的密钥对。 Master的密钥大小目前不可配置，但是minions的密钥大小是可以配置不同的密钥大小。 例如，使用2048位密钥：

keysize: 2048

通过数千次解密，masters端可以节省的时间已经是不可忽略的了。 请参阅此处以供参考：Pull Request 9235密钥大小可以产生多大影响。

相反的，缩小Salt Master的密钥大小并不是那么重要，因为minions不会像Master那样加密尽可能多的消息。

在具有大型或具有复杂pillar文件的部署环境中，由于必须一次渲染很多个pillar文件，因此master可能表现出较差的性能。 这类问题可以通过多种方式展现出来，既可以表现为master的高负荷，也可以增加交付pillar数据的延时。

为了减少pillar渲染时间，可以在master设备上缓存pillars数据。 要执行此操作，请参阅master配置选项集中那些以pillar_cache为前缀的配置选项。

注意

在Master服务器上缓存pillars数据可能会引入安全性考虑因素。 请务必阅读Master配置文件中有关的警告，以了解pillar缓存会如何影响master保护敏感数据的能力！

THE MASTER 的磁盘I/O资源挑战

默认情况下，Master会为其作业缓存中的每个作业保存每个Minion的返回值。 然后可以稍后使用缓存来查找先前作业的结果。 默认存储目录是：

cachedir: /var/cache/salt

也会使用到/proc目录。

每个Minion的每个作业返回都保存在一个文件中。 随着时间的推移，此目录可能会变得非常大，具体取决于已发布作业的数量。 文件和目录的数量将随发布的作业数量和定义的保留时间而变化。

keep_jobs: 24

假定有2000个minions，每天发布250个jobs管理任务，意味着一天至少会有500000个文件产生。

使用外部job cache服务

外部作业缓存允许将作业数据存储到外部系统（例如数据库）上。

• ext_job_cache：这将使minions将他们的作业返回数据直接存储到指定的returner服务（不经过Master发送）。
• master_job_cache（2014.7.0中新增）：这将使Master使用returner（而不是磁盘上的本地job cache）存储作业数据。

如果Master服务器有许多已接受的密钥，则发布作业时可能需要很长时间，因为master服务器首先要确定匹配的minions并在发布作业之前将该信息传递回等待的Salt Client。

为了缓解这种情况，可以启用密钥缓存的功能。 这会将Master服务器上的负载减少到打开单个文件而不是数千或数万。

但是，这个缓存由维护进程负责更新，这意味着在默认情况下，最多可能会有60秒内刚刚被接受了密钥的minions，是不能被Master识别并管理的。

要启用主密钥缓存，请在Master的配置文件中设置 key_cache：‘sched’。

禁用工作缓存的方法

为了减少Master的负载，这并不是一个特别推荐的方法。作业缓存是Salt Master的核心组件，如果没有正在运行的作业缓存，Salt Master的许多方面将无法正常运行。

job_cache: False