update part of chapter 20.5

20.Architecture-SaltStack高可用架构.md

@@ -4,6 +4,6 @@
 
 - [High Availability Features in Salt - Salt中的高可用性功能](https://github.com/watermelonbig/SaltStack-Chinese-ManualBook/blob/master/chapter20/20-1.High-Availability-Features-in-Salt-Salt中的高可用性功能.md)
 - Salt Syndic - Salt分区管理
-- Using Salt at scale
+- Using Salt at scale - 在更大规模范围内使用Salt时会遇到的一些问题
 - Multi Master Tutorial - Multimaster架构的配置教程
 - Multi-Master-PKI Tutorial With Failover - 给合使用PKI和failover的Multimaster架构

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

@@ -0,0 +1,50 @@
+# 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](https://github.com/saltstack/salt/issues/11865), [Issue 5948](https://github.com/saltstack/salt/issues/5948), [Mail thread](https://groups.google.com/forum/#!searchin/salt-users/lots$20of$20minions/salt-users/WxothArv2Do/t12MigMQDFAJ))。
+
+要完全理解每个问题，了解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发布的下一个命令时，重新进行认证。这无疑也会导致另一个“惊群”效应。 这个问题是可以通过设置下面的参数来避免的：
+```yaml
+random_reauth_delay: 60
+```
+可以在minions配置文件中适当的设置这个选项值并在使用Salt的过程中有意错开可能引发重新认证尝试的minions数量。增加这个选项值，在一些场景下显然也会增加使用Salt命令管理所有minions时所需要等待的时间。
+
+## 有许多的minions同时在重新连接Master
+https://docs.saltstack.com/en/latest/topics/tutorials/intro_scale.html#too-many-minions-re-connecting