2、DHCP服务器参数调优：地址池规划、租约时间设置、Option标签配置、性能与并发优化
DHCP 在网络启动场景里，说白了就是给客户端发“身份证”和“地图”的服务。参数调不好，轻则启动慢，重则设备直接拿不到 IP，整个网络启动就卡死了。我这些年处理过不少 DHCP 相关的故障，今天把核心经验拆开揉碎了讲给你听。
2.1 地址池规划：别让 IP 成为瓶颈
地址池规划是第一步，也是最容易被忽视的一步。很多人觉得“多分点 IP 就行了”，其实不然。
核心原则：地址池大小 = 最大并发客户端数 × 1.5（安全余量）。
举个例子。你有个机房，200 台机器同时 PXE 启动。如果地址池只给 200 个 IP，一旦有机器租约没释放，新机器就卡住了。我个人习惯至少留 50% 的余量。
规划时还要考虑这几点：
- 子网划分：把 PXE 客户端单独划一个 VLAN，地址池独立。别跟办公网混在一起，否则广播风暴够你受的。
- 排除地址：网关、DNS、TFTP 服务器这些固定 IP，一定要从地址池里排除掉。我见过有人忘了排除网关 IP，结果网关被 DHCP 分出去了，整个网络瘫痪。
- 静态绑定：对于关键设备（比如管理服务器），用 MAC 绑定固定 IP。这样既保证可达性，又不占用动态池。
| 场景 | 建议地址池大小 | 备注 |
|---|---|---|
| 小型实验室（<50 台） | 100 - 150 | 留足余量，方便扩展 |
| 中型机房（200 - 500 台） | 400 - 800 | 按峰值并发计算 |
| 大型数据中心（1000+ 台） | 1500 - 3000 | 建议分多个作用域 |
2.2 租约时间设置：长还是短？这是个问题
租约时间直接影响 IP 的周转效率。网络启动场景下，客户端通常是一次性使用 IP（启动完就进系统了），所以租约策略跟普通办公网完全不同。
我的建议：
- PXE 启动阶段：租约时间设短一点，比如 5 - 10 分钟。因为客户端只在启动时用一下 DHCP，拿到 IP 下载完启动文件后，这个 IP 就没用了。设短了能快速回收。
- 正常业务阶段：如果客户端启动后继续使用同一个 IP，那租约可以设长一些，比如 1 - 2 小时。避免频繁续约增加服务器压力。
小技巧：很多 DHCP 服务器支持“按类别”设置租约。你可以把 PXE 客户端的 User Class 设成 "PXEClient"，然后单独给这个类分配短租约。这样既不影响普通客户端，又能快速回收 PXE 用的 IP。
为什么会这样？你想想看，如果租约设成 24 小时，200 台机器启动完，IP 全被占着。第二天再来 200 台新机器，地址池就枯竭了。我曾经在一个项目中遇到过这种情况，排查了半天才发现是租约时间太长导致的。
2.3 Option 标签配置：给客户端指条明路
DHCP 不只是发 IP，更重要的是通过 Option 告诉客户端“下一步去哪”。网络启动场景下，有几个 Option 是必须配的。
必配 Option 清单：
| Option 编号 | 名称 | 作用 | 配置示例 |
|---|---|---|---|
| 66 | TFTP 服务器名 | 告诉客户端去哪个服务器下载启动文件 | 192.168.1.100 或 tftp.example.com |
| 67 | 启动文件名 | 指定要下载的引导文件（如 pxelinux.0） | pxelinux.0 |
| 3 | 默认网关 | 跨网段通信必须 | 192.168.1.1 |
| 6 | DNS 服务器 | 解析域名（如果用域名访问 TFTP） | 192.168.1.2 |
避坑指南：我曾经遇到过 Option 66 配了域名，但 DNS 没配 Option 6，结果客户端解析不了 TFTP 服务器地址，启动失败。这两个 Option 要么都配 IP，要么都配域名并确保 DNS 可用。
另外，有些场景还需要配 Option 43（厂商特定信息）或 Option 60（Vendor Class Identifier）。比如 Cisco 的 PXE 启动，就需要通过 Option 43 传递一些私有参数。具体配什么，得看你的启动方案要求。
2.4 性能与并发优化：扛住千人同时启动
大并发场景下，DHCP 服务器很容易成为瓶颈。我见过一个学校机房，300 台机器同时开机，DHCP 服务器直接宕机了。怎么优化？
几个关键点：
- DHCP 中继：如果客户端跨网段，一定要配 DHCP 中继（ip helper-address）。别让广播包跨 VLAN 乱窜，否则核心交换机 CPU 会爆。
- 多线程/多进程：主流的 DHCP 服务器（如 ISC DHCP、Kea）都支持多线程。记得根据 CPU 核心数调整 worker 数量。我一般设成 CPU 核心数 × 2。
- 数据库后端：如果租约数量很大（比如上万），建议把租约存储从文件换成数据库（MySQL/PostgreSQL）。文件读写在高并发下会锁死。
- 负载均衡：可以用多个 DHCP 服务器做 failover 或 split scope。比如 50% 的地址池分给服务器 A，50% 分给服务器 B，客户端随机请求，压力自然分散。
性能参考数据：一台 4 核 8G 的虚拟机，跑 Kea DHCP，优化后能扛住每秒 500 - 800 个 DHCP 请求。如果超过这个量，建议上负载均衡。
嗯，这里要注意一点：并发高的时候，DHCP 服务器的日志量会非常大。记得把日志级别调低，或者单独写到一个高性能磁盘上。否则日志写 I/O 会把服务器拖垮。
最后说一句，DHCP 调优没有银弹。你得根据实际场景去压测、去调整。我习惯在部署前先用工具模拟一下并发请求，看看服务器能不能扛住。发现问题再针对性优化，这样最稳妥。