调整 Ansible Forks：平衡并发性和资源消耗
Ansible 的优势在于其无代理特性以及同时管理大量主机的能力。这种并发性主要由 forks 设置控制。正确调整 forks 参数对于在自动化任务中实现最佳吞吐量至关重要。Forks 太少，您的 playbook 运行缓慢；Forks 太过，您则有可能会使控制节点或被管理节点本身不堪重负。
本文旨在提供一份实用指南，帮助您了解 Ansible forks 是什么、它们如何影响性能，以及为您的特定环境设置最佳值的基本方法。我们将探讨在哪里定义此设置以及激进并发所涉及的权衡。
了解 Ansible Forks
在 Ansible 术语中，一个 fork 代表 Ansible 控制节点生成的一个独立的 Python 进程，用于同时管理与单个被管理主机的连接。当您运行一个 playbook 时，Ansible 会启动多达由 forks 定义数量的进程，以便跨您的清单（inventory）并行执行任务。
为什么 Forks 对性能很重要
并发性是 Ansible 速度的关键。如果您有 100 台服务器需要更新，设置 forks = 100 意味着 Ansible 会尝试在完全相同的时间连接到所有这些服务器（受限于连接限制和超时）。然而，这种并行性是有代价的：
- 控制节点资源消耗： 每个 fork 都会消耗运行 Ansible 的机器（控制节点）上的 CPU 和内存。较高的 fork 计数可能会耗尽控制节点的资源，导致性能下降、延迟增加以及潜在的崩溃。
- 被管理节点负载： 快速的连接风暴可能会使网络交换机或被管理主机本身不堪重负，特别是当它们已经处于重负载或其处理传入 SSH 连接和任务执行的 CPU 资源有限时。
在哪里配置 forks 参数
forks 值可以在多个位置配置，并以级联顺序覆盖先前的设置。了解这种层次结构对于确保不同项目和环境中的行为一致至关重要。
1. Ansible 配置文件 (ansible.cfg)
设置系统范围默认值的首要、持久位置是 ansible.cfg 文件。该文件通常位于 /etc/ansible/ansible.cfg（系统范围）或您的项目根目录（项目特定）。
要设置默认并发级别，请修改 [defaults] 部分：
# ansible.cfg 片段
[defaults]
# 设置默认的并行进程数
forks = 50
2. 命令行覆盖 (-f 或 --forks)
您可以在执行 ansible 命令或运行 playbook 时，直接临时覆盖配置文件设置：
# 使用特定的 fork 计数运行 playbook（例如 25）
anible-playbook site.yml --forks 25
# 使用高并发性运行 ad-hoc 命令（例如 100）
anible all -m ping -f 100
3. 环境变量
对于基于脚本的执行或 CI/CD 管道，设置 ANSIBLE_FORKS 环境变量提供了一种灵活的方式来控制并发性，而无需修改配置文件：
export ANSIBLE_FORKS=30
anible-playbook site.yml
配置优先级： 命令行参数覆盖环境变量，而环境变量又覆盖
ansible.cfg中的设置。
如何确定最佳 forks 值
找到完美的 forks 数是一个基于经验测试的迭代过程。没有单一的万能数字；它在很大程度上取决于您的网络延迟、控制节点容量和目标节点的处理能力。
步骤 1：评估控制节点容量
在调整之前，请了解您的限制。现代、强大的控制节点（VM 或物理服务器）通常可以处理比在慢速 VPN 上通过笔记本电脑运行 Ansible 高得多的 fork 数量（例如 100-500）。
最佳实践： 在运行中等规模的 playbook 时，监控控制节点的 CPU 和内存使用情况。如果任务执行完成前 CPU 使用率持续达到 100%，那么您的 forks 计数可能对您的硬件来说太高了。
步骤 2：评估目标节点的容忍度
如果您的被管理节点正在运行关键服务或已经处于重负载下，设置过高的 forks 可能会导致这些服务器的性能下降（例如，SSH 响应缓慢，服务中断）。
提示： 如果您只需要运行非侵入性任务（如收集事实信息），您可以承受更高的 forks。如果您正在部署大型应用程序更新，请考虑减少 forks，以最大限度地减少对生产系统的同时负载。
步骤 3：经验性负载测试
从一个保守的值（例如 20 或 50）开始，然后逐步增加，同时测量一个标准、有代表性的 playbook 的总执行时间。
| 测试迭代 | Forks 设置 | 总执行时间（示例） |
|---|---|---|
| 1 | 20 | 450 秒 |
| 2 | 50 | 210 秒 |
| 3 | 100 | 185 秒 |
| 4 | 150 | 190 秒（略有增加） |
在上面的示例中，最佳平衡点似乎在 100 forks 左右，因为增加到 150 并没有带来进一步的时间节省，反而可能给控制节点带来了不必要的开销。
与连接类型的交互
forks 设置与您选择的连接插件（最常见的是 ssh）协同工作。
SSH 连接延迟
如果您的连接延迟很高（例如，跨越大陆或慢速 VPN），您可能会发现增加 forks 的边际效益递减，因为建立连接所需的时间占了执行时间的主导地位。在这些情况下，减少超时设置可能比增加 forks 更有益。
持久连接（异步/ControlPersist）
对于使用现代 SSH 配置（如 ControlPersist，它在 Ansible 运行之间保持 SSH 套接字打开）的环境，建立初始连接的开销会被分摊。这使得您可以安全地使用更高的 fork 计数，而不会因初始连接建立时间而受到严重惩罚。
避免常见的陷阱
将 forks 设置得过高是一个常见的性能错误。以下是关键警告：
警告：除非您已验证您的控制节点可以处理负载，否则切勿将
forks设置为等于或大于清单中主机总数的数量。 对于大型清单（数千台主机），默认的 forks 应保持相对较低（50-200），并且您应依赖 Ansible 的内部任务节流或delegate/serial关键字来进行工作负载划分。
如果在增加 forks 时观察到与 Cannot connect to host 或 Connection timed out 相关的错误，这有力地表明您已超过控制节点网络堆栈或被管理节点的 SSH 守护程序容量的限制。
结论
通过 forks 参数优化 Ansible 性能，在于在最大限度地提高并行执行与尊重控制节点和被管理基础设施的资源限制之间找到最佳点。保守地开始，系统地衡量性能，并利用配置层次结构（命令行 > 环境变量 > ansible.cfg）来针对不同的自动化需求有效地管理并发性。通过调整此设置，您可以确保自动化高效运行，从而实现更快的部署，而不会危及系统稳定性。