一百台机器同时装机为什么卡在第二步：PXE 这段链路里，瓶颈不在镜像大小

镜像只有几个 G，理论上很快就该传完，但一百台一起上电的时候，真正开始排队的往往不是传镜像那一步，而是它前面那一步。现场最常见的反应是去换交换机、去压镜像、去怀疑存储慢，折腾一圈回来，机器还是停在同一个位置。要解释这件事，得先把"装机"这个词拆开，因为它底下压着两段资源特征完全不同的传输。

把交付拆成两段：引导段与镜像段

一台裸金属从上电到能登录，中间大致可以切成两截。第一截叫引导段：机器上电，网卡里那段固件向外发请求，先拿到一个网络身份，再拿到引导服务器的地址和引导文件的名字，把引导程序取回本地执行，接着由引导程序把内核和初始化内存盘也拉下来，把控制权交给安装器。第二截叫镜像段：安装器接管之后的活，拉取完整镜像或者成百上千个软件包，落盘、校验、写引导记录、重启。

这两截对基础设施的要求几乎相反。引导段传输的数据量并不大，通常是几十兆这个量级，但它要求的是"同时能响应多少个客户端的小文件请求"，考验的是协议交互效率和服务端的并发状态处理能力。镜像段的数据量是引导段的几十倍甚至上百倍，但它考验的是另一件事：出口能不能扛住持续的大流量，存储能不能在多个客户端同时读的时候不拖后腿。

数据量差距和时间差距不是一回事，这是整套问题里最容易搞混的地方。一个几十兆的文件和一个几个 G 的文件，在带宽充足的前提下后者未必更慢；但如果前者的传输协议要求"发一块、等一个确认、再发下一块"，那一百个客户端同时索取这几十兆时，花费的往返次数会被放大到非常可观。相反，后者走的是成熟的拥塞控制与流式传输，只要带宽给够，它反而线性可控。

把两段混在一起看，会带来一类典型的误判：运维在监控上看到装机整体变慢，第一反应是镜像太大，于是去裁剪镜像、去上更快的网卡，钱和工时都投进去了，卡住的位置一步没动。因为真正排队的地方在引导段，而引导段根本不吃这一套优化。

判断卡在哪一段，方法其实很朴素：看机器停在哪个画面，或者看服务端日志停在哪一步。停在拿不到地址，是地址分配那一段；停在引导程序下载进度不动或者反复重来，是引导段；进度条已经进了安装器界面，那就是镜像段。三段的现象差别很明显，只要现场有人愿意蹲在屏幕前看一眼，比对着监控猜要快得多。

还有一个容易被忽略的点：两段之间的衔接并不总是自动的。引导段结束的标志是安装器起来，安装器起来之后是否还能继续从网络取东西，取决于初始化内存盘里带没带对应的网络配置与驱动。有些机型在这一步会掉链子，表现为引导段一切正常，进安装器之后突然找不到网络，看起来像镜像段的问题，实际是衔接处的问题。

PXE 这一段依赖 DHCP 加 TFTP，都是广播域里的事

传统的网络引导流程是这样的：网卡里的 PXE 固件发 DHCP 请求，服务器除了分配地址，还会在响应里带上两个关键信息——引导服务器的地址（next-server）和引导文件的名字（filename）；固件拿到之后，用简单的文件传输协议去那台服务器上把引导程序取下来，然后执行它。整个流程里没有复杂的协商，也没有重试策略可言，固件能做的事情非常有限。

这段话里的关键词是"广播域"。最初的 DHCP 请求是广播发出的，它天然只在同一个二层域里传播。一旦待装机器和引导服务器不在同一个网段，就必须靠中继设备把广播转成单播送到服务器，同时在中继报文里填上 giaddr 字段，告诉服务器"这个请求是从哪个网段来的"，服务器才能挑对地址池、挑对引导文件。这一跳配置错了，最常见的现象不是报错，而是机器安安静静地停在"找不到引导"上，看不出任何线索。

所以 PXE 服务器和待装机器之间的位置关系，不是"能连通就行"。它要求的是中继路径上每一台设备都正确地转发了请求、都正确地填了标识字段、都保留了服务器需要的选项。这和普通的业务连通性是两套检查标准，很多网络验收里压根没有覆盖到这一项，等到要批量交付了才第一次踩上去。

同网段里存在多个 DHCP 服务，是另一类高频故障源。DHCP 的应答逻辑本质上是"谁先到听谁的"，一个测试用的小服务、一台交换机自带的地址分配功能、某个虚拟化平台残留的服务，都可能抢在正牌服务器前面应答。被抢走的机器会拿到错误的 next-server 或者错误的 filename，然后去一台根本不提供引导文件的服务器上下东西，表现形式同样是"卡住"，而且因为每台机器抢到的应答不一样，会出现"有的机器能装、有的不能"这种最消耗排查时间的结果。

交换机侧的配置也会掺和进来。端口隔离会让同交换机下的机器互相不通，广播抑制会削掉一部分请求，MAC 地址表的学习与老化、生成树的收敛时间，都会影响机器从上电到真正能发出第一个有效报文之间的间隔。这些参数平时是为业务流量调的，没人会站在批量装机的角度复核一遍。

还有一层是网卡固件本身的能力差异。不同厂商、不同代次的网卡，其内置引导固件的实现质量参差，对选项的支持程度、对异常的容忍度、超时之后的回退行为都不一样。同一批机器里混着几张不同型号的网卡，就可能出现同一套配置下表现不一致的情况，这种差异在只有几台机器时根本看不出来，到了几十台上百台才会集中暴露。

TFTP 的块大小与窗口，决定引导阶段的并发上限

引导段用的那个文件传输协议基于 UDP，工作方式是最朴素的停止等待：服务端发一块数据，停下来等客户端确认，收到确认再发下一块。块大小可以通过选项协商调大，窗口大小也可以协商，允许连着发若干块再统一确认，这两个机制分别对应公开的协议扩展。问题在于，协商是要两端都认的，一端不支持就退回保守参数。

保守参数下的代价是可以算出来的。块大小停在最小值时，一个几兆的引导文件要被切成上万块，每一块都要一次完整的发与等。单台机器做这件事也许还能接受，一百台机器同时做，服务端要维护的状态机数量和每秒要处理的确认报文数量就变成了一个完全不同的量级。

更关键的是服务端实现的特点。很多 TFTP 服务是单线程或者少量线程在处理块确认，本质上是一个串行的循环。它不吃多核，也不吃大带宽——你给它一台配置很好的机器，它可能仍然只用满一个核，其余资源闲置。这就是为什么"服务器看着一点都不忙，但装机就是慢"会成为一个反复被问到的现象：忙的是那个串行循环，不是整台机器。

基于 UDP 还带来重传与超时的麻烦。丢一个块就重传，连续丢几个块，客户端可能直接放弃，回退到引导项列表里的下一个条目，或者干脆退出网络引导。丢包的来源可能只是交换机一个端口的瞬时拥塞，也可能是服务端处理不过来导致的超时，两者从现象上看不出来，得靠服务端日志与端口统计对起来才能分清。

这里要特别说清楚一件事：提高块大小和窗口确实能缓解，但它只是把天花板抬高，没有改变停止等待这个模型。天花板抬到一定程度之后，遇到的下一堵墙会是服务端的随机读能力和状态处理上限。所以在规模化场景里，单纯调参数是治标，真正的出路是换掉这一段所依赖的协议。

另外，引导文件的种类数量也是个变量。如果一批机器只有一种机型，所有客户端都在读同一批文件，文件系统的页缓存能把随机读变成顺序读，服务端压力小很多；如果一批里混着多种机型、多种引导模式，每个机型对应不同的内核与初始化内存盘，服务端就得在多个文件之间跳来跳去，随机读的比例直线上升。同样的机器数量，后者的服务端压力可以高出一大截。

一百台同时请求时，谁先被打满

把上电开关一起按下之后，最先被冲的是地址分配那一环。所有机器几乎在同一时刻完成自检、初始化网卡、发出请求，形成一次密集的请求风暴。这一环的特点是短促而尖峰：请求报文本身很小，但数量集中，而且对服务端来说每个请求都要做一次地址查表与分配决策。如果服务端开启了地址冲突探测，每分配一个地址之前还要先去探测一次，处理时间会被拉长，风暴就被顶在门口。

接下来才是引导下载。这一步最容易被误判成带宽问题，因为大家习惯性认为"文件小就应该快"。实际上带宽利用率在这一步通常相当低，大量时间花在等待确认上。真正被打满的是另外三个东西：服务端的状态处理循环、磁盘的随机读、以及网络设备的每秒报文处理能力。这三者里任何一项先到顶，都会表现为进度变慢，但监控上看带宽曲线却是一条平线。

机器上电的时序本身也是个可利用的变量。分批上电把尖峰削平成一段持续的请求流，是最便宜也最有效的缓解手段，不需要改任何架构。麻烦的是有些交付场景里上电时序不由你控制——比如机器上架后由机房统一送电，或者带外管理只能批量下发开机指令。这种情况下就得在服务端侧做准入控制，用排队代替自由竞争。

磁盘这一侧还有个隐蔽问题：一百台机器读同一个文件，理论上第一次读进页缓存之后就都是内存命中了；但如果引导文件不止一份、或者文件系统缓存被其他负载冲掉，服务端就会反复去读盘。而这一层和镜像段的存储 IO 是共用同一套磁盘的，如果安装镜像和引导文件放在同一块盘上，两边的读会互相干扰，出现"引导慢的时候镜像下载也跟着慢"的连带效应。

网络设备侧也要留一份注意力。机器刚上电时端口会集中起来，交换机的 MAC 学习表会短时间内涌入大量条目，如果端口配置了生成树的非边缘模式，还要经历一段收敛等待期才能正常转发。这段等待期内发出的请求有的会被丢掉，客户端只能靠重传来补，退避之后的到达时间又被拉开，无形中把尖峰拖成了长尾。

所以"谁先被打满"这个问题，答案是分层的：地址分配先被请求数量打满，引导下载接着被交互次数打满，镜像下载才轮到被带宽打满，最后写盘阶段被本地磁盘打满。每一层的资源属性不同，对应的应对手段也就不同，指望用同一个办法解决四层问题，是这类项目最容易走的弯路。

iPXE 把引导段换成 HTTP 之后解决了什么

开源的网引导固件与脚本环境提供了另一条路：它本身可以被链式加载，也支持直接用 HTTP、HTTPS 等协议加载后续内容。链式加载的意思是，让网卡原生的引导固件只做它擅长的最小一件事——把这份固件拉下来执行，之后的所有下载都交给它，走 HTTP。

这个转换带来的第一个变化是协议模型。TCP 有成熟的拥塞控制和可靠传输，不需要应用层去做停止等待；服务端可以用现成的、经过大规模验证的并发服务来承担下载，能横向扩展，能加缓存，能放在反向代理后面。原来那个串行循环的限制，被一整套成熟的工程体系替换掉了。

第二个变化是可缓存。引导文件和镜像文件都能落到标准的对象缓存里，靠近客户端的位置放一份，重复的请求不再回到源站。这在多机房、多楼层交付的场景里收益尤其明显，因为它把"跨地域重复拉取"变成了"就近命中"。

第三个变化是脚本能力带来的差异化下发。它可以根据机器的标识信息拼出不同的下载地址和内核参数，同一套入口服务一百台机器，每台拿到的却是可以各不相同的配置。这对混装机型、混装用途的批次特别有用——原来要么维护多套配置文件、要么人工逐台指定，现在是一段脚本里的分支逻辑。

第四个变化是传输的健壮性。基于范围请求的断点续传、失败重试、并发连接，都可以直接使用，不用再靠整个文件重传来兜底。对大文件来说，这一条往往比带宽本身更能决定总耗时。

代价也要说清楚。改用 HTTPS 就要处理证书与信任链，而证书校验依赖时钟；裸金属的实时时钟不准是常态，时间偏差大到一定程度，校验会直接失败，表现为"明明地址对、文件也在，就是下不来"。另外，把引导逻辑放到脚本里，脚本本身就成了新的故障面，语法错误、变量拼错、分支覆盖不到，都会让机器卡在某个不直观的位置。

还有一种用法是直接把远端的块设备当本地盘来引导，适合无盘或者集中存储的架构。这条路对网络与后端存储是持续依赖的，不像下载式引导那样"取完就断"，所以它对接入层网络质量的要求是长期性的，不适合放在网络条件不稳定的位置。

DHCP 地址池、租约与选项配置里最容易踩的坑

地址池容量是最基础也最常被算错的一项。池子给小了，先到的机器把地址占完，后到的拿不到，现象是"前几十台正常，后面的全卡住"。更麻烦的是装完之后地址不会立刻释放，如果租约时长设得偏长，这批地址会被空占着，下一批机器上电时又是一场争抢。租约设得太短也不行，会导致续约请求频繁，形成另一类背景噪声。

引导相关的两个选项是核心：一个告诉客户端引导服务器是谁，一个告诉客户端引导文件叫什么。填主机名还是填地址，这里有个实际差别——填主机名意味着客户端还要再做一次名字解析，等于在链路里又加了一个依赖点，而这个依赖点出问题时同样不报明显的错。现场更稳的做法是直接填地址，把不必要的解析环节去掉。

客户端架构类型决定了引导文件要用哪一份。传统 BIOS 和 UEFI 走的引导文件路径不同，服务端需要根据客户端在请求报文里带上的架构标识，返回对应的文件名。标识识别写错或者干脆没有做区分，就会出现"部分机器能引导、部分不能"，而且分界线正好落在机型代次上，很容易被误判成硬件兼容性问题。

安全启动开启之后，引导程序必须具备相应的签名，签名链对不上，机器会拒绝执行。这在采购新机型时尤其容易踩：出厂默认开了安全启动，而内部的引导程序还是按老流程准备的，两边对不上，现场表现为"文件下载完了但就是不启动"，日志里也未必有明显提示。

跨三层场景里，中继设备填的源网段标识是关键。服务器靠这个字段决定从哪个地址池分配、返回哪套引导配置。标识填错或者被中间设备改写，请求会落到默认池里，拿到一套完全不对应的参数。另外，部分中继设备默认不透传某些自定义选项，需要显式打开，否则服务端精心配置的字段根本送不到客户端。

同网段存在多个应答源的问题前面提过，这里补一条应对：在接入交换机上启用DHCP监听类功能，把合法服务端口标记为可信，其余端口的应答直接丢弃。这是从网络侧根治的办法，比事后逐个排查服务来源要省事得多，而且一旦配好就是长期有效的。

排查时最有用的是服务端日志里的四步交互：发现、提供、请求、确认。缺哪一步，问题就定位在哪一层——没有发现说明请求没到服务端，要查中继与广播域；有发现没提供，要查地址池与策略；有提供没请求，可能是客户端收到了别的应答源；有请求没确认，多半是服务端状态或者租约记录出了问题。这四步比任何猜测都可靠。

规模化交付各阶段的瓶颈与应对

把整条链路按时间排开，瓶颈出现的顺序是有规律的：先是地址分配的请求风暴，接着是引导程序下载，然后才是镜像与软件包的下载（受出口带宽与存储读写能力限制），最后是目标机自身的写入与校验。这个顺序的意义在于，它规定了优化必须自上而下做——跳过前面直接优化后面，投入换不来效果。

第一层的应对围绕削峰与容量。扩大地址池、缩短租约、必要时关闭分配前的冲突探测，都是直接有效的手段；能控制上电时序就分批放行，不能控制就在服务端做准入排队。这一层的目标不是让每台都快，而是让整个批次的完成时间可预期。

第二层的应对是换协议。把引导段从停止等待的文件传输换成基于 HTTP 的下载，是这一层收益最大的改动，因为它改变的是模型而不是参数。改完之后，服务端可以横向扩展，可以加缓存，可以复用现有的 Web 基础设施，原来那个只能靠堆单机配置的天花板就不存在了。

第三层的应对围绕带宽与存储。镜像源要靠近客户端，最好每个交付区域都有一份；存储要能撑住多客户端并发读，必要时候把引导文件和镜像文件分开放在不同的存储上，避免互相干扰。这一层是唯一真正吃带宽的一层，前面省下来的带宽在这里才能发挥作用。

第四层的应对落在目标机自己身上。磁盘的写入能力、分区方案、安装过程中的校验与压缩策略，都决定最后这一截的时长。这一层的特点是它和并发无关——每台机器的写入是独立的，一百台同时写不会互相拖慢，但单台写不快就是写不快，只能从硬件与安装配置上解决。

这张表还有一个用法：它可以当成交付前的检查清单。每一次批量交付之前，按顺序走一遍六行，确认每一行的应对都还在生效——因为这些东西会因为一次网络调整、一次系统升级、一次机房搬迁而悄悄失效，等到现场才发现就已经晚了。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源；批量交付支持哪些引导方式与镜像，下单前建议与服务商逐项核对。批量交付支持哪些引导方式与镜像，下单前建议与服务商逐项核对。

装机之后的第二阶段：初始化与配置下发

安装器退出并不等于这台机器可以交付。真正决定交付质量的是后面那一截：分区与文件系统是否符合预期，网络配置是否从临时的自动获取切换成了长期配置，主机名与解析是否正确，登录凭据是否到位，监控与日志组件是否装上并连上了，时间同步是否生效。这些事情任何一件漏掉，机器都得重新拉回来返工。

分区这一步有个隐蔽陷阱：磁盘的设备命名在不同机型、不同启动顺序、不同内核版本下可能不一致。按固定的设备名写分区脚本，在某些机器上会写到错误的盘上，轻则装机失败，重则把不该动的数据抹掉。稳妥的做法是按磁盘的标识信息来定位，而不是按枚举顺序。

网络配置的切换是失联高发区。装机过程中机器用的是自动分配的地址，装完之后要么改成静态配置，要么依赖于服务端给它保留同一个地址。这一步没处理好，机器重启之后网络不通，而它此时已经不处于可交互状态，只能靠带外管理或者现场接显示器去救，成本远高于装机本身。

初始化脚本的幂等性是另一个要点。批量交付中难免有机器中途失败需要重跑，如果脚本不具备重复执行不产生副作用的能力，重跑一次就会留下两份配置、两个定时任务、或者互相覆盖的网络配置。把每一步都写成"先检查当前状态，再决定是否修改"，比写成一串无条件执行的命令要可靠得多。

后校验应当做成强制环节而不是可选环节。检查项不必复杂，能远程登录、关键软件包齐全、分区与文件系统正确、时间与时间源一致、必要的服务进程起来了，这几条就能筛掉绝大多数不合格的交付。判定标准也要明确：以"自检通过"作为这台装完了的标志，而不是以"安装器退出了"为标志，这两者之间的差距就是返工率的来源。

还要留意一点：如果初始化阶段需要从远端再拉一批大文件，那它在本质上还是镜像段的延续，前面那些关于带宽与缓存的分析全部适用。很多团队把配置下发想得很轻，等到里面塞了容器镜像、模型文件、离线包之后，才发现它才是整条链路里传输量最大的一段。

关于批量装机，现场最常被问的几件事

换更快的网卡能不能解决？只对镜像段有用。引导段的瓶颈是交互次数和服务端串行处理，不是带宽，把接入层全换成高带宽网卡之后，那一层的现象不会有任何变化。判断依据很简单：如果监控上带宽曲线一直很平，那问题一定不在带宽上。

能不能全部走 HTTP？网卡原生的引导固件一般不具备这个能力，它只认简单的文件传输协议。常见的做法是让它只负责把支持 HTTP 的引导固件拉下来，后续全部交给后者。所以"全部走 HTTP"在技术上是成立的，但需要一个链式加载的中间步骤，不是改个配置就能切过去。

传统 BIOS 和 UEFI 混在一起怎么办？服务端需要读取客户端在请求报文里携带的架构标识，按标识返回对应的引导文件。没有做区分的服务器会对所有客户端返回同一个文件名，于是某一种模式的机器必然失败。这不是硬件兼容性问题，是配置项漏了。

同一个批次里有的能装有的不能，怎么查？优先怀疑三类原因：同网段存在多个应答源导致不同机器拿到了不同参数；机型混杂导致引导文件不匹配；个别机器的安全启动状态与其余不一致。这三类都会产生"随机性"的假象，而排查的抓手是逐台对比它们拿到的地址、文件名和启动模式。

要不要给每台机器做静态绑定？取决于管理成本与规模。绑定能让每一台的地址与引导配置完全确定，排障非常方便，代价是要维护一份机器标识与地址的对应表，机器数量上去之后这份表本身就是负担。折中的做法是给引导服务的地址与文件名做统一配置，只在地址分配上按需做保留。

镜像要放几份？每个有交付需求的区域放一份是最省事的原则。重复拉取同一份大文件是最容易被优化掉的浪费，而缓存与就近分发都是成熟手段，不需要自己造。判断放几份的依据是交付区域的分布，不是机器数量。

装完重启又走回网络引导，是什么问题？绝大多数是引导顺序没有调整。机器在装机时靠网卡引导，装完之后系统已经写好了本地引导记录，但如果固件里的启动顺序仍然把网络引导排在本地磁盘前面，它每次开机都会先去网络上找一遍。这是一项需要在交付流程里显式处理的动作，不能指望它自动发生。

什么时候不该走 PXE 这条路线

先说最现实的一类：机器分散在多个广播域、多个地域，而每个地方的机器数量都不多。这种情况下，为了支撑网络引导要在每个位置部署中继、部署服务、维护地址池与引导配置，投入的建设与维护成本超过了它带来的收益。零散交付更适合用带外管理挂载安装介质，一次一清，不留长期设施。

第二类是对引导链路有强约束的环境。某些机器的固件对网络引导的支持不完整，或者安全启动的签名链条无法在内部打通，硬要走这条路就要么放宽安全策略、要么投入去做签名，两者都不是批量交付项目该承担的代价。评估阶段就应该把这一项作为前置检查，而不是等到了现场才发现。

第三类是镜像体量极大而网络条件受限的场景。当单次传输量已经大到让网络成为主要风险时，把镜像预先落到本地介质上，或者采用出厂预装的方式，往往比现场拉取更可靠。网络引导的优势在于一致性与免介质，当"免介质"这个前提本身不成立时，优势也就消失了。

第四类是已经有成熟镜像模板体系的场景。如果交付对象本身可以被模板化、被克隆，那走模板路线通常比走网络安装更短，也更不容易出现安装过程中的差异化问题。网络引导适合的是"从裸机开始、需要标准化重建"的场景，不是"复制一台既有机器"的场景。

第五类是把远端块设备当本地盘来引导的用法。它对网络与后端存储是持续依赖的，装完之后每时每刻都在走网络，网络质量波动会直接反映成机器的可用性问题。这种架构适合网络条件可控、存储后端可靠的集中式场景，不适合放在接入条件不稳定的位置。

最后说一句边界：网络引导的价值不在于让单台机器装得更快，而在于让一百台机器装得一模一样。如果一批机器的一致性不重要、装机窗口也不紧张、后续还有大量人工配置，那建这条链路的收益就非常有限。反过来，只要"一致性"是硬要求，前面那些关于广播域、协议与瓶颈顺序的分析，就都变成了必须提前想清楚的事。