我们如何将700多台服务器迁移到Salt
长期以来，我们对具有2个Git存储库的复杂而繁琐的配置感到满意，其中部分数据存储在MySQL中，另一部分是Puppet 3.8。但是我们的需求逐渐增长，服务数量增加，配置性能下降。然后，我们为自己设定了改善配置，优化所有可用数据和工具的任务。
我们的团队分3个阶段为自己选择了合适的配置。我们分享我们在盐优化方面的经验，以及如何轻松应用和定制盐。
注意：在Habré上，我们从同事那里找到了不错的文章，因此我们将不再赘述已涉及的问题。我们强烈建议您阅读：
SaltStack有什么好处，以及可以解决的任务-来自的文章ptsecurity，积极技术。
安装，启动，第一个命令和熟悉功能-作者的文章zerghack007...
Salt是一个配置管理和远程执行系统。用Python编写的开源基础架构框架。
为什么加盐？
Salt，Ansible，Puppet和Chef是选择配置管理工具的不错的选择。我们选择Salt是因为我们优先考虑以下优点：
- 与Ansible不同，模块化，免费版本的API可用性。
- Python，这意味着您可以轻松理解任何组件并编写您缺少的功能。
- 高性能和可伸缩性。该向导使用ZeroMQ建立与各爪牙的永久连接，以实现最佳性能。
- 反应器是一种触发器，当某些消息出现在消息总线中时执行。
- 编排-建立复杂关系并按特定顺序执行操作的能力，例如，首先配置负载均衡器，然后再配置Web服务器群集。
- Puppet和Chef用Ruby编写。我们的团队没有胜任的专家来使用这种编程语言，但是Python是众所周知的，并且经常被我们使用。
- 对于以前使用Ansible的团队来说，使用Ansible剧本的能力至关重要。这将使您轻松迁移到Salt。
请注意：
我们已经使用Salt已有近两年了，建议您注意以下几点：
- Salt, , . , . , SaltStack .
- SaltStack . , . : , . , cmd.run file.managed, .
, , , .
. .
鉴于：
因此，我们的初始配置为：
- 2个Git存储库（一个用于工程师和管理员；第二个用于高度关键的服务器，仅对管理员可用）；
- MySQL中的一条数据；
- 另一部分-在Puppet 3.8中（继承继承，实际上不使用Hiera-键值存储）。
目标：将配置管理系统迁移到Salt，提高其性能，使服务器管理更加方便和易于理解。
解决方案：
首先，我们开始将原始配置从单独的非关键服务服务器迁移到Salt，同时摆脱过时的代码。
然后，我们为VDS服务器准备了配置。在我们的情况下，这些是服务服务器，开发服务器和客户端服务器的配置文件。
从Puppet切换到Salt时的主要问题是过时的操作系统（在2018年，存在Ubuntu 12.04和14.04）。在迁移之前，有必要更新操作系统且不影响服务/服务器的操作。否则，一切都变得很容易：同事逐渐参与了该过程。
团队指出，在主要优点中，例如，语法更易于理解。我和我的同事同意使用“盐最佳实践”技巧，但以我们自己的建议作为补充，以反映我们的特殊性。
该团队还评估了配置交付方法：推（主“推”）和拉（小兵“拉”）。如果您需要测试简单的东西，同时又不打乱Git存储库，那么无主模式可以为您提供帮助。在无主模式下运行小兵可以使您在一台计算机上使用Salt配置管理，而不必转到另一台计算机上的Salt主服务器。该配置完全是本地的。
采用这种解决方案的多达300个小兵，我们没有遇到任何重大问题。当时的主要配置是具有6个核心和4 GB内存的VDS。
但是，一旦小兵数量达到300，平均负载（平均系统负载）就会增加到3.5-4，并且系统的运行速度大大降低。以前，state.apply命令花费了30-40秒，但是现在花费了18分钟！
当然，这样的结果是我们无法接受的。此外，其他公司的专家也撰写了有关10,000个奴才的成功故事。我们开始弄清楚是怎么回事。
主人的观察并没有对这个问题给出明确的答案。有足够的内存，未加载网络，磁盘已使用10％。我们以为GitLab应该负责，但也不应负责。
似乎没有足够的处理器能力：添加内核时，平均负载自然下降，并且执行了state.apply命令，尽管速度更快，大约5至7分钟，但没有我们想要的速度快。
增加工作人员可以部分解决该问题，但会显着增加内存消耗。
然后，我们决定优化配置本身。
阶段1
由于支柱是受保护的存储，因此对存储的访问与加密操作相关联，因此您必须为使用CPU时间的访问付费。因此，我们减少了调用支柱的次数：同一数据仅获取一次；如果需要在其他地方使用它们，则可以通过导入（{％-来自“ defaults / column.sls”导入配置文件％}）进行访问。
该配置每小时应用一次，执行时间是随机选择的。在分析每分钟执行了多少任务以及在一小时的过程中它们平均分配的情况之后，我们发现：在小时的开始（从第1分钟到第8分钟），最多的任务通过，而在第34分钟，没有任务！我们编写了一个跑步者，每周运行一次所有小兵，并平均分配任务。由于这种方法，负载变得均匀，没有跳跃。
有建议迁移到铁服务器，但那时不存在，因此...我们以另一种方式解决了该问题。我们添加了一些内存，并将整个缓存放入其中。查看Grafana仪表板时，我们首先认为Salt-master无法正常工作，因为平均负载降至0.5。我们检查了state.apply的执行时间，也很惊讶-20-30秒。这是胜利！
第二阶段
六个月后，小兵人数增加到650，而...性能再次下降。“平均负载”图随仆从数量而增长。
我们要做的第一件事：启用支柱缓存，将生存期设置为1小时（pillar_cache_ttl：3600）。我们意识到，现在我们的提交将不再是瞬时的，而将不得不等待主服务器更新缓存。
由于我们根本不想等待，因此我们在GitLab中创建了钩子。在提交中，这可以指示您需要为哪个奴才更新缓存。支柱的缓存大大减少了负载，并缩短了应用配置的时间。
第三阶段
我们对调试日志进行了一些思考，并提出了一个假设：如果我们增加文件后端和文件列表缓存（gitfs_update_interval，fileserver_list_cache_time）的更新间隔，该怎么办？每分钟进行一次更新，有时最多需要15秒。通过将更新间隔从1分钟增加到10分钟，我们再次赢得了速度！洛杉矶指标从1.5降至0.5。应用配置的时间减少到所需的20秒。尽管LA会在一段时间后再次增长，但state.apply的执行速度并没有明显改变。这些缓存的强制更新已添加到git push的钩子上。
我们向Elasticsearch添加了分析功能：我们重写了内置的elasticsearch_return，现在我们可以监视state.apply的结果（平均执行时间，最长状态和错误数量）。
结果
现在，我们对Salt的性能完全满意。有计划使奴才数量增加一倍。我们的主人如何应对这样的负担仍然很难说。也许我们将转向水平缩放或找到一个魔术参数。时间会证明一切！
如果您使用gitfs作为后端，请给它五个！您可能会遇到与我们相同的问题。因此，我们很乐意在评论中讨论此主题。