PXE 批量装机服务端架构：DHCP/TFTP/HTTP 高可用设计
说明：本篇为综述/无第一手实验数据，采用公开文档与常见生产实践路线。
实验目标
上一批补的装机文章（PXE 无盘启动、Golden Image 流水线）解决了"客户端怎么装"，本篇回答服务端那一半：一个集群 512 台机器同时 PXE 装机时，DHCP/TFTP/HTTP 三个服务谁最容易被压垮？怎么让装机服务端不成为交付瓶颈？ 目标是给出一个生产可用的 PXE 服务端架构：三服务职责与参数、并发吞吐模型、高可用与失败重试，以及装机现场的排查路径。
代码逐段拆解
第一段：DHCP 配置（pxe 客户端引导的关键）
text
# /etc/dhcp/dhcpd.conf 片段：PXE 关键选项
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.100 10.0.0.250; # 装机地址池
option routers 10.0.0.1;
option domain-name-servers 10.0.0.1;
next-server 10.0.0.2; # TFTP 服务器地址
filename "pxelinux.0"; # 引导文件名
option arch code 93 = unsigned integer 16; # 按架构选引导
class "pxeclients" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
option vendor-encapsulated-options 06:01:01:0a:00:00:02; # PXE 服务 IP
}
}要点：
next-server与filename是 PXE 引导的"入口"：客户端 DHCP 拿到这两项后，才会去 TFTP 拉pxelinux.0。它们指错了，机器会卡在"no boot filename received"。option arch区分 UEFI/BIOS：UEFI 客户端要grubx64.efi，BIOS 客户端要pxelinux.0；混装机房不区分架构会导一半失败。class "pxeclients"只对 PXE 请求给引导参数：普通 DHCP 客户端（办公网）不下载引导文件，避免误装机。- 地址池要与装机并发量匹配：
range大小决定"同时能发出去多少 IP"，512 台并发装机至少要 512 个以上可用地址。
第二段：TFTP 与 HTTP 分层
yaml
# 服务拓扑：小文件走 TFTP，大文件走 HTTP
# tftp-hpa: /srv/tftp/{pxelinux.0, grubx64.efi, 内核 initrd}
# nginx: /srv/pxe/{vmlinuz, initrd.img, kickstart/autoinstall 配置, 系统镜像}
# nginx 片段：装机镜像只对装机网段开放
server {
listen 80;
root /srv/pxe;
allow 10.0.0.0/8;
deny all; # 装机资源只服务内网
client_max_body_size 4g; # 大镜像
location /images/ {
alias /srv/pxe/images/;
sendfile on; # 零拷贝，高并发吞吐
aio on;
}
}要点：
- TFTP 只放引导小文件，大文件走 HTTP：TFTP 是"一请求一包 + 确认"协议，单连接吞吐极低（几十 KB/s），并发上百台就崩；而引导阶段后内核和系统镜像都通过 HTTP 拉取（PXELINUX 支持
http://路径），吞吐提升几个数量级。 sendfile on + aio on：镜像文件是顺序大读，零拷贝直接把文件从磁盘送进网卡，nginx 的 CPU 占用极低，能支撑数百台并发下载。allow 10.0.0.0/8; deny all;：装机镜像包含 kickstart 配置（可能含 root 密码、分区脚本），只允许装机网段访问是安全底线。
原理讲解
三个服务的负载模型
| 服务 | 协议特征 | 并发瓶颈 | 扩容手段 |
|---|---|---|---|
| DHCP | UDP 广播/单播，瞬时高频 | 并发很高但单请求开销小；瓶颈在地址池与响应速度 | 地址池扩容、DHCP failover 双机 |
| TFTP | UDP 一包一确认，吞吐极低 | 最容易崩：每客户端一个会话，百级并发即拥塞 | 只留小文件；大文件转 HTTP |
| HTTP | TCP 长连接、高吞吐 | 吞吐高，瓶颈在磁盘 IO 与网卡 | nginx + 本地盘/SSD + 多网卡 |
设计原则：把流量从 TFTP 挪到 HTTP，是 PXE 服务端高可用的第一课。真实装机现场"卡在引导"十有八九是 TFTP 拥塞——客户端反复重试 TFTP 下载，表现为"一直 PXE 转圈"。
并发装机吞吐模型
单台服务端 1Gbps 网卡理论 ~110MB/s，一台最小化系统镜像约 1-2GB（含驱动/工具）——理论上一小时能喂 200-400 台；实际受磁盘与协议开销影响打 5-7 折。512 台全量并发装机的时间瓶颈不在服务端，而在每台机器的磁盘写入速度（SSD 装系统 5-10 分钟）。因此服务端只要保证"不成为更慢的那一环"，即 HTTP 带宽 ≥ Σ 各节点磁盘写速。
高可用与失败重试
- DHCP failover：两台 DHCP 做
failover peer，主挂备顶，避免"装机一半地址服务没了"。 - TFTP/HTTP 服务冗余：nginx 前面可加 LVS/keepalived 虚 IP；TFTP 与 HTTP 指向同一虚 IP，客户端无感切换。
- 装机日志集中化：PXE 引导失败要能看到"卡在哪一步"——DHCP 日志（did not receive boot filename）、TFTP 日志（文件不存在/超时）、HTTP 日志（404/断流）。三份日志对齐时间线就是排查入口。
- 失败自动重试：PXE 客户端本身会重试；服务端要保证幂等——重复装机不会破坏已有配置（分区脚本用
clearpart --all前加%include判断），否则重试反而造成连环失败。
实验结果
（估算口径，供容量设计参考）
| 指标 | 单机估算 | 说明 |
|---|---|---|
| DHCP 单机吞吐 | 数千请求/秒 | 非瓶颈，重点在地址池 |
| TFTP 并发上限 | 50-100 客户端 | 超过即拥塞，引导卡死 |
| HTTP 并发下载 | 200-400 客户端（1Gbps） | sendfile 零拷贝下近线性 |
| 512 台全量装机 | 1-2 小时 | 瓶颈在节点磁盘写速 |
| 双机 HA 切换 | 秒级 | DHCP failover + 虚 IP |
工程启示
- 先挪流量再谈高可用：把 TFTP 压到"只服务引导小文件"、镜像全走 HTTP，装机服务端的可靠性问题直接少掉一半。
- 装机网段与生产网段隔离：PXE 服务只开给装机网（VLAN），防误装机、防镜像泄露，也让装机流量不挤占生产网络。
- 三份日志一起看：DHCP/TFTP/HTTP 日志按时间对齐，装机排查从"猜"变成"定位到协议层"。
- 与 Golden Image 流水线配套：服务端架构定了，镜像本身的质量由 05 章的 golden-image-pipeline 负责——服务端只保证"镜像能顺利发到每台机器"。
下一篇预告：装机这块补齐后，回到算力获取的另一条路——"云上 GPU 算力：成本模型与弹性架构"。