调优 Ansible Forks：平衡并发与资源消耗

Ansible 的优势在于其无代理特性以及同时管理大量主机的并发能力。这种并发性主要由 forks 设置控制。正确调优 forks 参数对于在自动化任务中实现最佳吞吐量至关重要。forks 太少，playbook 运行缓慢；太多，则可能使控制节点或受管节点不堪重负。

本文作为实用指南，帮助您理解 Ansible forks 是什么、它们如何影响性能，以及如何为特定环境设置最佳值。我们将探讨在何处定义此设置以及激进并发所带来的权衡。

理解 Ansible Forks

在 Ansible 术语中，fork 代表由 Ansible 控制节点生成的独立 Python 进程，用于同时管理与单个受管主机的连接。当您运行 playbook 时，Ansible 会启动最多由 forks 定义数量的进程，以并行方式在清单中执行任务。

为什么 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
ansible-playbook site.yml --forks 25

# 使用特定 fork 数量运行 ad-hoc 命令
ansible all -m ping -f 100

3. 环境变量

对于基于脚本的执行或 CI/CD 流水线，设置 ANSIBLE_FORKS 环境变量提供了一种无需修改配置文件即可控制并发性的灵活方式：

export ANSIBLE_FORKS=30
ansible-playbook site.yml

配置优先级： 命令行参数覆盖环境变量，而两者都覆盖 ansible.cfg 中的设置。

如何确定最佳 `forks` 值

找到完美的 forks 数量是一个基于经验测试的迭代过程。没有单一的魔法数字；它很大程度上取决于您的网络延迟、控制节点容量和目标节点能力。

第 1 步：评估控制节点容量

在调优之前，了解您的限制。一个拥有充足 CPU、内存和网络容量的专用控制节点通常可以处理比通过 VPN 运行 Ansible 的笔记本电脑更多的 forks。确切数字取决于工作负载、连接插件、受管主机上的 Python 启动开销以及每个任务返回的数据量。

最佳实践： 在运行中等规模的 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 并没有进一步节省时间，反而可能增加了不必要的开销。请将此视为一种测试模式，而非基准测试。您自己的结果可能会在 20 个 forks、75 个 forks 或其他某个值时趋于平稳。

与连接类型的交互

forks 设置与您选择的连接插件（最常见的是 ssh）协同工作。

SSH 连接延迟

如果您的连接延迟很高（例如，跨洲际或通过慢速 VPN），您可能会发现增加 forks 的收益递减，因为等待连接建立的时间主导了执行时间。在这种情况下，减少超时设置可能比增加 forks 更有益。

持久连接 (Async/ControlPersist)

对于使用现代 SSH 配置（例如 ControlPersist，它可以在 Ansible 运行之间保持 SSH 套接字打开）的环境，建立初始连接的开销被分摊了。这使您可以安全地使用更高的 fork 数量，而不会因初始连接建立时间而受到严重惩罚。

避免常见陷阱

将 forks 设置得过高是一个常见的性能错误。以下是一些关键警告：

警告： 小心将 forks 设置为与大型清单中的主机总数相等。在小型实验室中可能没问题，但在生产环境中应首先进行测试。对于大型清单，请将合理的 fork 数量与 serial、throttle、批处理或单独的清单组结合使用，以免一次 playbook 运行造成连接风暴。

如果在增加 forks 时观察到与 Cannot connect to host 或 Connection timed out 相关的错误，这强烈表明您已超出控制节点网络堆栈或受管节点 SSH 守护进程的容量。

实用调优演练

调优 Ansible forks 的最简单方法是使用一个看起来像您环境中正常工作的 playbook。ping 测试对于检查连接性很有用，但它太轻量，无法告诉您关于真实部署压力的太多信息。更好的测试是类似包元数据刷新、小型模板部署、服务状态检查或您最常运行角色的试运行。

首先记录当前行为。使用您现有的设置运行 playbook，并记录经过的时间、失败主机的数量以及控制节点上的任何异常情况。您不需要复杂的基准测试工具。time ansible-playbook -i inventory site.yml --limit web 对于初次尝试通常就足够了。在另一个终端中，使用 top、htop、vm_stat、iostat 或您的操作系统提供的任何工具监控控制节点。如果控制节点正在交换内存，向上调优 forks 将无济于事。

然后缓慢增加。如果当前值是 5，尝试 10、20 和 40。如果当前值是 50，在跳到几百之前尝试 75 和 100。每次运行后，问三个问题：

playbook 是否完成得更快？
是否出现失败或重试？
CPU、内存、文件描述符或网络使用率是否变得令人不适？

最佳值通常就在曲线变平之前。如果 20 个 forks 需要 12 分钟，50 个 forks 需要 6 分钟，而 100 个 forks 需要 5 分 40 秒，那么 100 个 forks 带来的额外压力可能不值得。在这种情况下，我通常会选择 50，除非节省的几秒钟很重要并且环境已经过负载测试。

对于重启服务、运行数据库迁移、重建缓存或接触共享存储的 play，要特别保守。高并发性可能使每个主机同时执行昂贵的操作。对于无害的文件检查来说，这可能正是您想要的，但如果所有应用程序节点同时重启或所有数据库副本同时开始压缩文件，那将是糟糕的一天。

也要注意输出量。一个从每个主机返回几行的任务，与一个从数百台机器流式传输大型命令输出、包管理器日志或 JSON 事实的任务行为不同。控制节点必须收集、解析和打印这些数据。如果即使受管主机空闲，运行也感觉缓慢，请尝试减少嘈杂的输出，只注册您需要的内容，或在再次增加 forks 之前缩小事实收集范围。

并发性还有人性化的一面。一个在 20 个主机中有 3 个失败的 playbook 很容易分析。一个在 800 个主机中有 47 个失败的 playbook 会产生一份冗长的报告，第一个有用的错误可能被埋没。更高的 forks 可以缩短运行时间，但会使故障分析更加拥挤。对于操作工作，我更喜欢一个保持输出可读性的 fork 设置，除非作业是完全自动化的并且已经围绕故障建立了良好的警报机制。

forks 也不是您拥有的唯一控制手段。当您希望分批滚动处理主机时，请使用 serial：

- name: 安全部署 Web 应用程序
  hosts: webservers
  serial: 10
  tasks:
    - name: 更新应用程序包
      ansible.builtin.package:
        name: myapp
        state: latest

使用 serial: 10，Ansible 在该 play 中一次处理十个主机，即使 forks 设置得更高。这为您提供了来自 forks 的全局并发上限和来自 serial 的部署策略。

当某个任务比 play 的其余部分更敏感时，请使用 throttle：

- name: 小批量重启 API 服务
  ansible.builtin.service:
    name: api
    state: restarted
  throttle: 3

这允许较早的任务广泛运行，同时限制风险任务。当只有一步需要约束时，这比降低整个运行的 forks 更简洁。

对于 CI 系统，将选定的值写在项目 ansible.cfg 或流水线配置中。隐藏的本地设置是常见的混淆来源。一位工程师从笔记本电脑运行 forks = 5，另一位从 CI 运行 ANSIBLE_FORKS=100，突然间同一个 playbook 的行为截然不同。保持默认值既平淡又明确，然后仅在已知情况下覆盖它。

一个效果不错的模式是在仓库中保留一个保守的默认值：

[defaults]
forks = 25

然后为已知安全的作业覆盖它：

ANSIBLE_FORKS=75 ansible-playbook -i inventory.ini facts-refresh.yml

这使得异常在调用点可见。跨健康主机的 facts 刷新可能比滚动部署或重启密集型维护 play 容忍更多的并发性。将 forks 视为一个具有合理默认值的按工作负载设置，而不是一个调优一次就忘记的全局数字。

如果您使用 Ansible Automation Platform、AWX 或其他运行器，请记住 playbook 进程之外可能还有额外的并发控制。作业切片、实例组容量、容器限制和执行环境资源都可能限制或放大 forks 的效果。当运行结果与您的预期不符时，请同时检查 Ansible 的设置和其周围的调度器。