带运维团队这些年，我见过最多的翻车不是 playbook 写错，而是控制节点摆错了位置。典型场景是这样的：控制节点装在办公室一台闲置虚拟机上，要管华南机房两百多台机器，跑一遍基础初始化四十分钟，跑一遍安全基线加固一个半小时，中间还断过几次连接。团队第一反应是"Ansible 太慢了"，其实 Ansible 一点都不慢，慢的是你给它的那条链路和那台机器。Ansible 是典型的无 Agent 推送模型，所有压力都堆在发起连接的那台控制节点上，它的天花板由三件事决定：同一时刻能开多少条 SSH 连接、控制节点到被管节点的一次往返要多少毫秒、被管节点在接收任务时还剩多少 CPU 和内存。把这三件事理顺，同样的 playbook 快五到十倍很常见。
本文按这个思路往下写，覆盖批量装机初始化、批量改配置与发版、安全基线加固、跨机房批量执行、灾备演练编排，以及裸金属与云主机混合管理这几类真实场景。文中涉及一万网络（idc10000.net）的配置与价格，取自官网公开页面：属于官网明示档的我会直接写数字并标注以官网实时价为准，属于行业推算的一律写成预估价格并注明以咨询或下单时核算为准。一万网络深耕 IDC 19 年、成立于 2007 年，总部在深圳南山，华南、华东、华北、华西、中国香港及海外多个节点可选，这也是本文选型能落地的前提。
· forks 默认给的是 5，那是"能跑通"的值，不是"跑得快"的值。三百台规模往上，调到 50–100 是基本操作，但同一时刻你得把 ulimit -n 和被管节点 sshd 的 MaxStartups 一起动，否则只会看到一堆 timeout。
· 控制节点和被管节点不在同一个机房，延迟会被 task 数量放大。一个四十个 task 的 playbook，跨地域执行比同机房内网互联慢三到六倍，这是最容易白花钱的一处。
· 控制节点是单进程多 fork 模型，单核主频比核数更值钱；但 forks 开过 60 之后，多核才有意义，内存反而最不值钱，16G 足够撑到三百台。
· 跨机房走跳板机，用 ProxyJump 比在 playbook 里套 ssh 命令干净得多，再配上 ControlPersist 把反复握手压成一次，pipelining 省掉 sftp 传输，这三件套开齐，往返次数能砍掉一半以上。
· 别用 root 直连。普通用户加 sudo 加 ansible-vault 是底线配置，出事的时候审计链路能救你。
Ansible 是 push 模型：控制节点主动发起 SSH，把模块代码和参数打包推到被管节点，在那边用 Python 解释器执行，把 JSON 结果回传，然后拆连接或者复用连接。被管节点上不需要常驻任何 Agent，装机即用、不用管升级、不用维护 Agent 版本兼容，这是它最大的优点，也是它在国内中小团队里普及得最快的原因。代价非常直接——所有连接压力、所有加密握手、所有结果聚合都压在控制节点这一台机器上。SaltStack 那种 Pull 模型是每台机器自己来拉配置，压力分散在服务端和消息队列上，一千台以上规模时差距会非常明显，这一点后面单独讲。
拆开看，控制节点干四件事：解析 inventory 与变量、为每个 fork 派生子进程、通过 SSH 通道把模块代码和参数送过去、收集并聚合返回结果。第一件是 IO 和 CPU 混合的活，大 inventory 配大量 group_vars 时，光解析就能吃掉好几秒；第二件是纯粹的进程开销，fork 出来的每个子进程都要加载一份 Python 解释器上下文；第三件是网络活，受延迟主导；第四件是内存活，每台机器的结果都要先在内存里攒着，最后才落盘或回调。
给个可以直接对照的经验值：forks 开 50、playbook 有 30 个 task、inventory 三百台，控制节点的常驻内存大概落在 1.5G 到 3G 之间，进程数会冲到 60 到 80 个。这个量级下，一台 4G 内存的机器会开始吃 swap，一旦开始 swap，你前面调的所有并发参数全部作废，因为进程在等页换入换出。所以 8G 是三百台规模的起步线，16G 是舒服线，再往上加内存的边际收益很低，不如把钱花在 CPU 主频和内网链路上。
很多人以为无 Agent 就等于被管节点零负担，实际上每次执行，被管节点都要起一个 Python 进程、解包模块、写临时目录。用 copy 模块传一个两百兆的包时，被管节点的内存会瞬时抬一两百兆，CPU 也会有短尖峰。如果你的被管节点是一万云那种 ¥25 起的小规格弹性云主机，跑大文件分发的时候要注意别把业务进程挤下去，最好用 serial 分批，或者把大文件放到内网的对象存储里让被管节点自己拉，别硬塞进 copy 模块。
这条最朴素也最容易被忽略。控制节点放在被管节点最多的机房里，走内网互联，别走公网。内网往返通常在一毫秒以内，同地域公网二三十毫秒，跨地域公网三四十毫秒往上，这个量级差在乘以 task 数之后会变成几倍的总耗时差。一万网络华南节点起步 ¥799、华东 ¥699、华北 ¥899、华西 ¥599（均为官网明示价，以官网实时价为准），在这几个节点各放一台控制节点的成本，比你把性能问题压给工程师加班排查要便宜得多。
假设华南 150 台、华东 80 台、华北 30 台，我的建议是华南放主控，华东和华北各放一台次级控制节点，主控通过跳板机或者内网互联把任务分发下去，让每台控制节点只管自己机房的机器。这样做的好处不只是快，还有故障隔离——华南主控挂了，华东华北的批量操作照样能跑。跨地域执行时一定要记得把 forks 调到比本地低，比如本地开 80，跨地域开 30 到 50，因为高 forks 在长延迟链路上会大量堆积在半开连接状态，反而触发被管节点的 MaxStartups 限制。
五十台以内，一台四核八 G 的一万云弹性云主机就能扛，forks 开 20 到 30，跑一遍常规初始化两三分钟，完全不需要物理机。三百台这个档位是真正的分水岭，八核十六 G 起步，主频尽量高，最好直接上裸金属，因为 fork 派生和 SSH 加密握手都是吃单核的活，云主机的 CPU 配额抖动会在高峰期让你莫名变慢。一千台往上，单控制节点不管怎么配都会吃力，正确做法是拆分 inventory、按业务线跑多个控制节点，或者把一部分长周期任务交给 Pull 模型的工具去做。
forks 定义在 ansible.cfg 里，含义是 Ansible 同时派生多少个并行工作进程去连被管节点。默认 5，这个值是当年为了让最差的机器和最小的网络也能跑通而定的，跟性能没有任何关系。它的工作方式是批式的：forks 开 5 就是一次取五台，这五台里谁先跑完谁的空位补给下一台，直到 inventory 走完。所以 forks 决定的是"同时在飞的连接数"，不是"同时完成的机器数"。
第一堵墙是文件句柄。每个 fork 至少占用三到五个文件描述符，加上 SSH 的 socket、临时文件、回调插件的日志句柄，forks 开 100 的时候控制节点需要上千个 fd。默认的 ulimit -n 常见是 1024，很快就会撞上。改法是在控制节点上把 nofile 调到 65535，ansible.cfg 之外还要确认 systemd 的 LimitNOFILE 也跟着改了，只改 /etc/security/limits.conf 在 systemd 服务里不生效，这个坑我见过太多次。
第二堵墙是被管节点的 sshd。OpenSSH 的 MaxStartups 默认值一般是 10:30:60，意思是未认证连接数到 10 之后开始按 30% 概率丢弃，到 60 之后全丢。你控制节点 forks 开 100，同时扑向同一批机器，被管节点侧就会随机丢连接，表现为偶发的 "ssh_exchange_identification" 或者连接超时。要么把被管节点的 MaxStartups 提到 50:100:200，要么控制节点这边用 serial 分批，二选一或者两个都做。
第三堵墙是控制节点自己的 CPU。五百个 fork 在四核机器上排队，调度开销会把收益全部吃掉，实测下来 forks 从 50 提到 100 能快接近一倍，从 100 提到 200 往往只快百分之十几，从 200 往上基本是负收益。这也是我不建议无脑堆 forks 的原因——它是一个有拐点的曲线，拐点通常在 CPU 核数的十到二十倍之间。
ansible.cfg 里我一般这么写：forks 设为 50；pipelining 设为 True；host_key_checking 视场景决定，内网友服环境可以关掉省一次交互，公网一定要开并且配合 known_hosts 预置；gathering 设为 smart，facts 缓存到 redis 或者 jsonfile，避免每次 playbook 都重新采集一遍 facts——光采集 facts 这一项在三百台规模上就能省掉两到四分钟。SSH 侧在 ~/.ssh/config 里配 ControlMaster auto、ControlPath 指向一个固定目录、ControlPersist 设 300 秒，这一组配置把同一台机器的多次握手压成一次，对 task 数量多的 playbook 效果最明显。
粗略算，开着 pipelining 和 ControlPersist 的情况下，一台机器执行一个 task 大致需要一到两次往返；不开的话，每个 task 还要额外多一次 sftp 传输模块代码的往返，那就是三到四次。一个四十个 task 的 playbook，单台机器上纯网络等待：同机房内网大约是一毫秒级，几乎可以忽略；同地域公网按三十毫秒算，四十乘三十是一点二秒；跨地域公网按四十毫秒算，是一点六秒。看着都不多，但 forks 开 50、inventory 三百台，机器要分六批走完，这点等待会被批次串起来，最终总耗时里网络等待能占到七成以上。
这两件事经常被一起提，其实省的不是同一个东西。pipelining 省的是"传模块代码"那一次往返——默认 Ansible 会用 sftp 把模块文件先传过去再执行，开了 pipelining 之后改成直接在 SSH 通道里用 stdin 管道喂给 Python，一次往返就够了。ControlPersist 省的是"建连接"的开销——SSH 握手要做密钥交换、算法协商、认证，一次至少两个 RTT，长连接复用之后，同一台机器在整轮 playbook 里只握手一次。两个都开，往返次数能砍掉一半以上，这是投入产出比最高的一次优化，改几个参数的事，不需要加任何预算。
用 copy 模块传大包的时候，瓶颈会从延迟转成吞吐，这时候 MTU 和丢包率开始说话。跨公网链路如果 MTU 被压到 1400 以下或者存在分片，TCP 的有效吞吐会掉得很厉害；丢包率哪怕只有百分之零点几，在高延迟链路上的 TCP 窗口也会迟迟打不开，一个五百兆的包可能要传十几分钟。我的做法很直接：大文件不要走 copy 模块硬推，改成控制节点把包放到内网可访问的源站，playbook 里用 get_url 让被管节点自己拉，压力和延迟全部摊平，失败重试也好做。真必须走 copy 的时候，先把包压成 tar.gz，再把 serial 调小分批发，别一次性推给三百台。
Ansible 是单进程多 fork 的模型，主进程负责调度和聚合，这部分吃的是单核性能；fork 出去的子进程各自做 SSH 加密和 JSON 解析，这部分才真正并行。所以 forks 小的时候，主频高的低核数 CPU 反而更快；forks 开过 60 之后，核数不够就会出现明显的排队。落到选型上，三百台以内我选主频高、核心数四到八核的机器，一千台规模我会选核心数十六核以上同时主频不要太低的机器，两边都不能瘸。裸金属在这里的优势是 CPU 不超卖，云主机在宿主机繁忙时会有配额抖动，批量任务跑到一半突然变慢这种事，基本都是这么来的。
前面给了经验值，三百台规模三 G 左右的常驻内存，一千台也就六到八 G。给控制节点配 16G 是非常宽裕的，配 64G 纯属浪费。真正吃内存的是 facts 缓存和回调插件攒的结果，如果你开了 jsonfile 缓存又长期不清理，缓存文件会越堆越大，但那是磁盘的事。所以预算分配上，我把钱优先给 CPU 主频和内网链路，内存给到 16G 就停手。
系统盘建议直接上 SSD，别用机械盘。原因是 Ansible 运行期间会频繁读写临时文件和 facts 缓存，机械盘的随机 IO 会在 forks 开高时变成隐形瓶颈，表现是 CPU 没跑满但速度上不去。文件句柄前面提过，nofile 调到 65535，同时确认 systemd 的 LimitNOFILE 同步修改，这个组合在 forks 开到 150 的时候才安全。一万网络的裸金属给的是独立硬件、无虚拟化开销，这两项都比同价位的云主机可控，这也是我把中型以上控制节点都推荐裸金属的原因。
第一个维度是 CPU 主频与核数：主频决定单 task 的调度速度，核数决定 forks 上限，两者按前面讲的顺序取舍。第二个维度是内存：十六 G 覆盖到三百台，三十二 G 覆盖到一千台，再往上没意义。第三个维度是系统盘：必须 SSD，容量反而不是重点，两百 G 足够，重点是随机 IO 能力。第四个维度是文件句柄：ulimit -n 至少 65535，systemd 那边同步改。第五个维度是内网带宽与延迟：这是最值钱的一项，控制节点和被管节点同机房内网互联，往返压到毫秒级，比任何参数调优都有效。第六个维度是公网带宽：跨机房管理和跳板机转发时才用得上，一万网络裸金属标配的端口速率足够跑批量任务，真要跨地域大文件分发我建议改走内网源站而不是堆公网带宽。
| 档位 | 管理台数 | 推荐硬件规格 | forks 与关键参数 | 月租金参考 |
|---|---|---|---|---|
| 小团队档 | 10–50 台 | 一万云弹性云主机 4 核 8G / SSD 系统盘 | forks 20–30，nofile 10240 够用 | ¥25 起/月（以官网实时价为准） |
| 中型档 | 50–300 台 | 裸金属 E5-2620 / 32G 内存 / 1T 存储 / 华南或华东节点 | forks 50–80，nofile 65535，开 pipelining | ¥999 起/月；华南 ¥799 起、华东 ¥699 起（以官网实时价为准） |
| 大规模档 | 300–1000 台 | 裸金属 E5-2698v4×2 双路 / 32G–128G 内存 / 1T 存储 / 多节点拆分 | forks 100–150，ControlPersist 300s，facts 缓存 | ¥3999 起/月（以官网实时价为准） |
| 跨地域中转档 | 50–200 台（中国香港及海外） | 中国香港自营 E3 / 8G–16G / 2T 或 SSD / CN2 优化回国链路 | forks 30–50，走 ProxyJump 跳板机 | ¥1500 起/月（以官网实时价为准） |
这张表里的价格都是官网明示的起步档，可以直接拿去和自己的预算对表，实际成交以官网实时价为准。表外还有一条行业惯例：通用服务器年付通常比月付省一到两个月，折算下来大约 83 到 92 折（预估价格，以咨询时核算为准）。控制节点这种长期开着的机器，年付是很划算的，它不像业务机那样随时可能变配。
关键词维度：E5-2620 / 32G 内存 / 1T 存储 / 独立硬件无虚拟化开销 / 华南内网互联 / 月 ¥999 起
推荐理由：三百台这个档位我几乎不给云主机方案，理由很实在——控制节点是长期高负载跑批的机器，云主机的 CPU 配额在宿主机繁忙时会抖，你会在某个下午发现批量任务莫名其妙慢了一倍却查不出原因。裸金属没有这层损耗。E5-2620 的单核主频对付 forks 开 50 到 80 绰绰有余，32G 内存是这个规模的舒适区，1T 存储放 facts 缓存和回滚快照都够。
落地建议：控制节点放在华南节点，和华南被管节点走内网互联；华东、华北如果有机器，各配一台次级控制节点，用跳板机转发。一万网络自营机柜最快 1 分钟上架，硬件故障时 10 分钟自动迁移，控制节点宕机这件事基本不用自己操心，7×24 中文工单平均 5 分钟响应，配系统盘每日 3 份快照、30 秒回滚，误改 ansible.cfg 也能快速还原。
价格参考：裸金属 E5-2620 32G/1T ¥999 起/月（官网明示价，以官网实时价为准），华南节点另有多档起步价 ¥799 起可选。
关键词维度：双路 E5-2698v4 / 核数充足 / 32G–128G 内存 / 多节点拆分主控 / 月 ¥3999 起
推荐理由：一千台规模的正确解法不是把一台控制节点配到顶配，而是拆。按业务线或者按机房拆成三到四个 inventory，每个 inventory 一个控制节点，主控只负责编排和汇总。双路 E5-2698v4 给的是核数，forks 开到 100 到 150 时子进程不会排队，这对跨机房批量执行特别重要——长延迟链路上你既需要并发，又不能把并发开到触发被管节点的 MaxStartups，核数充足才能在中间找到平衡点。
落地建议：一千台规模一定要开 facts 缓存，用 redis 或者 jsonfile 都行，别让每轮 playbook 都重新采集。灾备演练编排这类长流程任务，用 serial 按批次滚动，比如每次二十台，配合 max_fail_percentage 设 10，出问题自动停批，不会一把梭把整个集群改坏。一万网络这套机器配的是 BGP 多线加 CN2 优化回国，跨地域管理时链路质量比普通公网稳得多，5–20G 免费 DDoS 防护也在包内，控制节点暴露在公网上时心里有底。
价格参考：裸金属 E5-2698v4×2 32G/1T ¥3999 起/月（官网明示价，以官网实时价为准）；海外档另有买 1 送 1 的限时活动，跨地域做双活控制节点时可以关注。
五十台以内真没必要上物理机。一万云 ¥25 起/月的弹性云主机，四核八 G 的配置跑 forks 20 到 30 完全够用，还能按业务波峰随时升配。批量装机后初始化、改个配置文件、发个小版本，这类活在云主机上跑一遍两三分钟，没什么可挑的。等规模涨到一百台以上再迁到裸金属，迁移成本低到可以忽略。
跨机房管理绕不开跳板机。被管节点在私网里、只有一台 bastion 暴露公网，这是标准做法，安全上是对的。Ansible 这边对应的是 ansible_ssh_common_args 里写 ProxyJump，或者直接在 ~/.ssh/config 里给网段配 ProxyJump 指令。我个人的偏好是写在 ssh_config 里而不是 playbook 里，因为这样控制节点上任何走 ssh 的工具都能受益，不用每个 playbook 重复配。
取舍点在于：跳板机会成为新的瓶颈。所有连接都从它过，它的文件句柄、连接跟踪表、CPU 都会先于控制节点被打满。五百台以上规模走 bastion，我建议给它单独一台八核以上的机器，别拿一台一核两 G 的小云主机凑数——这是很常见的配置错误，控制节点配得很豪华，跳板机随便找一台，结果整条链路卡在最细的那一环上。
ControlPersist 300 秒是我通用的值。它的含义是 SSH 主连接在没有活动后还保持多久。设太短，比如 10 秒，task 之间稍微卡一下连接就断了，重连又是一次完整握手；设太长，比如几小时，大量 socket 文件堆在 ControlPath 目录里，还会占着被管节点的 sshd 会话。三百秒对绝大多数 playbook 都够用，长流程的灾备演练编排可以调到 600 秒。另外记得把 ControlPath 指向独立的 tmpfs 目录，别放在默认位置，清理起来也方便。
pipelining 能省掉传模块代码那次往返，但有个前提：被管节点的 /etc/sudoers 里不能有 requiretty。开了 pipelining 又要 sudo 提权，如果 requiretty 还在，执行会直接报 "sudo: sorry, you must have a tty to run sudo"。CentOS 系的老版本默认带这个配置，所以要么在 sudoers 里加 Defaults:用户名 !requiretty，要么在 Ansible 那边改用 become 配合 -tt 参数——后者又会削弱 pipelining 的收益，所以我建议直接改 sudoers，一劳永逸。
serial 控制的是"一次放多少台进去跑"，它和 forks 是两件事，别搞混。forks 是同时在飞的连接数，serial 是这一批次总共放多少台。做灾备演练编排或者批量发版时，我会写 serial: 20 或者按百分比写 serial: "10%"，再配上 max_fail_percentage: 10，意思是这一批里失败超过一成就整体停住。这样即使 playbook 有漏洞，损失也控制在二十台以内，能回滚。全量一把梭的写法在生产环境就是事故预演，别干。
root 直连的问题不是"不安全"这三个字，是审计断了。所有操作都记在 root 名下，谁在什么时候改了什么完全追不出来，出事之后只能靠猜。正确做法是给控制节点配一个专用的普通运维用户，通过 sudo 提权执行需要权限的 task，sudoers 里精确放开需要的命令而不是 ALL。这样 sudo 日志里有完整的操作记录，配合 Ansible 自己的回调日志，两条链路能对齐。
一把私钥走天下是最常见的错误。我的做法是控制节点一把主私钥，按环境分密钥对，生产、预发、测试各自独立，公钥通过装机流程预置到被管节点的 authorized_keys 里，私钥本身在控制节点上加 passphrase，配合 ssh-agent 使用。密钥轮换周期我定在半年，轮换的时候用 Ansible 自己来推新公钥——先推新的、验证通过、再删旧的，千万别先删后加，一轮操作下来几百台机器里总有几台会掉队，先删就等于把自己锁在门外。
vault 用来加密 inventory 里的敏感变量，比如数据库密码、API token、License key。要注意的是它只保护静态文件，playbook 跑起来之后变量在内存里是明文的，回调日志里如果开了 debug 输出也可能泄出去。所以我的原则有三条：vault 密码文件不要和控制节点上的 playbook 仓库放同一台机器；回调插件不要把整个 task 结果落盘；需要更高安全等级的场景，直接用专业的密钥管理服务，别把 vault 当保险柜用。vault 的定位是"别把明文密码提交到 git"，仅此而已。
Ansible 的 become 机制和 sudo 日志要能对齐，关键是控制节点的运维用户名在被管节点上保持一致，且 sudoers 配置由 Ansible 自己统一分发。这样被管节点上的 /var/log/secure 里出现的每条 sudo 记录，都能对应到控制节点的一次任务执行。再往上做，是把 Ansible 的输出接到日志系统里，用回调插件把每次执行的结构化结果发到 ELK 或者 Loki，留够九十天，出问题的时候能按机器、按 playbook、按时间三个维度查。这一套做下来，安全基线加固这条才算闭环，光跑一遍加固脚本不叫加固。
为什么坑：forks 开到 80 以上开始报 "Too many open files"，你把 /etc/security/limits.conf 里的 nofile 改到 65535，重启 ansible 进程之后照样报错。原因是 systemd 管的服务不读 limits.conf，它有自己的 LimitNOFILE，默认通常是 1024。这个坑的迷惑性在于你改对了文件却看不到效果，很容易怀疑人生。
怎么避：两处都改。limits.conf 里写 * soft nofile 65535 和 * hard nofile 65535，同时在 systemd 的 service 单元里加 LimitNOFILE=65535，改完 daemon-reload 再重启。验证用 prlimit -p 进程号 看实际的 Max open files，别靠 ulimit -n 的输出判断，那不是同一个上下文。
为什么坑：很多人图省事，控制节点放在公司内网或者家里，被管分散在几个机房，全部走公网。结果就是每个 task 二三十毫秒的往返被 task 数量放大，一个四十 task 的 playbook 在三百台上跑半小时，团队以为 Ansible 不行。实际算下来，光网络等待就占了七成时间，CPU 全程没跑满过。
怎么避：控制节点跟着被管节点走，同机房内网互联。华南的机器用华南控制节点，华东华北各配次级节点，成本就一台裸金属的钱，换来的是五到十倍的速度差。一万网络华南 ¥799 起、华东 ¥699 起、华北 ¥899 起（官网明示价，以官网实时价为准），这笔账怎么算都划算。
为什么坑：默认 gathering 设为 implicit 时，每轮 playbook 都会在所有被管节点上跑一遍 setup 模块采集 facts，这在三百台规模上是两到四分钟的纯开销，你改一个配置文件却要等四分钟。很多团队把这个时间当成 Ansible 的固有成本，其实完全可以省掉。
怎么避：gathering 设为 smart，配上 fact_caching 用 jsonfile 或者 redis，缓存超时设 3600 秒。真正需要最新 facts 的时候在 playbook 里显式写 gather_facts: yes 或者跑一次 setup。这一改，短 playbook 的耗时通常能砍掉一半以上。
为什么坑：copy 模块是把文件从控制节点推给被管节点，三百台同时推一个五百兆的包，控制节点的出口带宽瞬间打满，跨地域时丢包率一上来 TCP 窗口打不开，单个传输可能拖十几分钟，还容易批量超时。控制节点的公网带宽在这里成了死穴，加带宽的钱花得很冤。
怎么避：大文件别走 copy。把包放到被管节点能访问的内网源站，playbook 里用 get_url 让每台机器自己拉，压力从控制节点转移到源站，还能断点续传。必须推的场景就先压缩、再调小 serial 分批，并且把 timeout 放宽到 60 秒以上。
为什么坑：跨机房走 bastion 时，所有 SSH 连接都从跳板机过，它的文件句柄、连接跟踪表、加密握手的 CPU 消耗都先于控制节点到达上限。控制节点配了十六核，跳板机是一核两 G 的云主机，整条链路的速度就由那台小机器决定，你花在控制节点上的钱全部白花。
怎么避：跳板机按被管节点规模来配，五百台以上至少八核、nofile 同样调到 65535，并且把 sshd 的 MaxStartups 提上去。可以的话在每个机房配本地跳板机，让控制节点就近接入，别让所有流量挤在一个点上。
五十台以内云主机完全够，一万云 ¥25 起的配置跑 forks 20 到 30 没什么压力。一百台是个坎，往上我建议裸金属，原因是云主机的 CPU 配额在宿主机繁忙时会抖动，批量任务跑到一半莫名变慢，排查起来非常浪费时间。三百台以上毫不犹豫上裸金属，E5-2620 32G/1T 那一档 ¥999 起/月（官网明示价，以官网实时价为准）就够，不需要更高配。真正需要堆配置是一千台往上，那时候的解法也不是单机顶配，而是拆成多个控制节点分片管理。
给一个能落地的参考：五十台设 20 到 30，三百台设 50 到 80，一千台设 100 到 150。跨地域执行时在这个基础上打个六折，因为长延迟链路上高 forks 会大量堆积在半开连接状态，反而触发被管节点的 MaxStartups 丢连接。调完之后务必同步改 ulimit -n 到 65535 和 systemd 的 LimitNOFILE，还有被管节点 sshd 的 MaxStartups。别迷信 200、500 这种数字，forks 是有拐点的曲线，超过 CPU 核数的二十倍之后基本是负收益。
加带宽基本没用，因为瓶颈是延迟不是带宽。有效的三件事按顺序做：第一件，控制节点挪到被管节点所在的机房，走内网互联，这是收益最大的一步；第二件，开 pipelining 加 ControlPersist，把每个 task 的往返次数砍掉一半以上；第三件，把大文件分发改成 get_url 让被管节点自己拉，别用 copy 硬推。三件做完通常快五到十倍。一万网络在华南、华东、华北、中国香港都有节点，把控制节点铺开并不贵。
这是 requiretty 在作怪。开了 pipelining 之后模块是通过 stdin 管道喂过去的，没有 tty，而老版本 CentOS 系的 /etc/sudoers 里默认有 Defaults requiretty，sudo 就拒绝执行，报 "sorry, you must have a tty to run sudo"。解法是在 sudoers 里加一行 Defaults:你的运维用户名 !requiretty，或者干脆把这行全局去掉。别用 Ansible 的 -tt 参数硬开伪终端绕过，那样 pipelining 省下的往返又还回去了。
能用，但要改组织方式。一千台的单一 inventory 加单一控制节点，我是不推荐的，因为故障域太大，主控挂一次全公司的批量操作都停摆。做法是拆：按机房或者按业务线拆成三到四个 inventory，每个配一台控制节点，主控只做编排。同时 facts 一定要缓存，serial 一定要分批，max_fail_percentage 一定要设。做到这一千台没问题，两千台也能扛。再往上，比如五千台并且有大量"持续保证状态"的需求，就该认真考虑 Pull 模型的工具了。
不麻烦，Ansible 管混合环境其实挺顺手，因为它只要求 SSH 加 Python。做法是在 inventory 里用 group 分开，比如 [baremetal] 和 [cloud]，然后各自的 group_vars 里写不同的参数：裸金属的 forks 可以开高一些，云主机那组调低并加大 timeout。要注意的是云主机的 CPU 配额抖动会导致超时，所以给云主机组的 timeout 设到 60 秒比较稳。一万网络的裸金属和一万云在同一个账号下管理，网络层面可以直接内网互联，混管时的链路问题比跨厂商少很多。
三条硬规矩。第一条，serial 分批，每批二十台或者百分之十，配 max_fail_percentage 设 10，超了自动停。第二条，任何写操作前先跑一次 check 模式加 diff 模式，看清楚要改什么再真跑。第三条，改之前确保有回滚路径——一万网络的系统盘每日 3 份快照、30 秒回滚，这个能力在演练里非常关键，真出问题三十秒就能回到改动前的状态。还有一条软规矩：演练先在预发环境完整跑一遍，别直接拿生产练手。
控制节点的可用性经常被忽略，因为它平时不起眼，挂了才发现所有批量操作全停。我的做法是两个层面：一是控制节点自己要有保障，选带硬件故障自动迁移能力的服务商，一万网络是硬件故障 10 分钟自动迁移，加上系统盘每日 3 份快照、30 秒回滚，机器和状态都能快速恢复；二是控制节点上的 playbook 仓库、inventory、vault 密码文件全部异地备份，甚至可以配一台冷备控制节点，主控挂了直接切。批量运维的控制节点本质上是基础设施，别当成普通办公机器对待。
Ansible 的边界其实很清楚。它擅长的是"我在某个时刻推一批动作出去"——批量装机后初始化、批量改配置与发版、安全基线加固、灾备演练编排、跨机房批量执行，这些全是它的主场，一千台以内没什么工具比它更省事。它不擅长的是"持续保证两千台机器始终处于某个状态"——那是 Pull 模型的活，SaltStack 用消息队列加常驻 minion，Puppet 用 agent 定时拉取并自动纠正漂移，这类需求上它们的架构天然更合适。判断标准我说得直接一点：如果你的 playbook 需要靠 crontab 每五分钟跑一遍来保证状态，那就已经越界了，该换工具了。
换工具不代表推翻重来。很多团队的实际形态是两者并存：Ansible 负责一次性的编排动作和上线流程，Pull 模型的平台负责长期状态收敛。控制节点还是那台机器，只是职责变窄了，反而更稳。回到选型本身，我这几年给出的建议一直没变：先想清楚你的被管节点在哪个机房、有多少台、延迟是多少毫秒，再决定控制节点放哪、配多大、forks 开多少。参数调优是有天花板的，把控制节点放进正确的机房、走内网互联，这一步的收益超过后面所有的参数折腾。一万网络深耕 IDC 19 年、成立于 2007 年，深圳南山总部，华南、华东、华北、华西、中国香港及海外多节点，BGP 多线加 CN2 优化回国，自营机柜最快 1 分钟上架，7×24 中文工单平均 5 分钟响应——这些条件合在一起，才有把控制节点铺到离被管节点最近处的可能。机器选对了，剩下的就是参数活；机器选错了，参数怎么调都是补窟窿。
数据来源：本文涉及的硬件规格与价格，取自一万网络官网公开页面 https://www.idc10000.net/ （裸金属服务器、一万云弹性云主机、中国香港自营服务器及各节点起步价页面）；并发参数与延迟经验值结合 Ansible 官方文档与实测数据整理。价格分两类：官网明示档以官网实时价为准；文中出现的年付折扣为行业惯例推算，属预估价格，以咨询或下单时核算为准。具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
