本教程的重点是帮助构建一个Salt基础设施架构来有效地管理大量的minions。 这将包括性能调优、拓扑设计和一些最佳实践。
注意
本教程提供的一些建议更适用于大型的技术系统安装部署，虽然这些相同的设置不会带来什么不良的影响，但在小规模的技术系统部署中，可能并不值得增加这些复杂性。
在我们这里，当与minions一起使用时，术语“许多”指的是至少一千个，而“少数”则是意味着500个或更少。
为简单起见，本教程将默认使用Salt使用的标准端口。
在大规模范围内使用时， 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进行连接。
当Minion服务首次启动时，它将通过端口4505连接到Master的发布者。如果同时启动太多的minions，这可能会导致“惊群”效应。 这可以通过避免立即启动太多的minions来避免。
连接本身通常不是罪魁祸首，主要问题的原因更可能是Master必须对Minions进行的身份验证。 如果Master服务器负载过重而无法处理身份验证请求，则会将其计时并让其等待。 然后Minion将在等acceptance_wait_time后进行重试。 如果设置了acceptance_wait_time_max，那么Minion将在每次后续的重试操作之前通过acceptance_wait_time增加其等待时间，直到达到acceptance_wait_time_max为止。
这比较容易发生在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时所需要等待的时间。
默认情况下，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都被立即的执行一个管理命令：
$ salt * disk.usage它可能导致成千上万的minions试图将他们的数据返回到Salt Master的开放端口4506.如果Master无法立即处理那么多返回数据，也会导致大量的syn-flood风暴。
使用Salt的批处理模式就可以轻松避免这种情况：
$ salt * disk.usage -b 50这将通过循环的方式处理所有的minions，每次只同时处理50个minions。
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