在大多数企业网络里，DHCP服务器是典型的平时没存在感、一旦挂掉全网受影响的基础服务。设备重启、新终端接入、租约到期续租都依赖DHCP，如果只有一台服务器承担全部地址分配，任何硬件故障、系统补丁重启或网络闪断都可能导致终端拿不到地址。要提升DHCP可用性，通常有两条路线：故障转移和负载均衡。很多人把这两个概念混在一起，实际上它们解决的问题不完全相同。故障转移侧重一台挂了另一台顶上，负载均衡侧重两台同时干活并分担压力。DHCP的特殊之处在于，它不是无状态的查询服务，不能简单用反向代理或多台DNS轮询的思路来做，因为地址池一旦同时由多台服务器分配，就可能出现两台服务器把同一个IP发给不同设备。理解这一点，是配置任何DHCP高可用方案的前提。
一、DHCP故障转移和负载均衡到底有什么区别
DHCP故障转移通常指主备模式，也叫热备用或冷备用。热备用模式下，主服务器正常响应客户端的地址请求，备服务器只负责同步租约数据库，不主动参与地址分配。一旦主服务器出现故障，备服务器会在检测到异常后接管地址池，继续为新设备提供地址，同时还能处理已有租约的续租请求。这种模式的优点是结构简单、配置容易，缺点是平时备机基本处于闲置状态，资源利用率不高。冷备用则更多依赖人工切换，已经不常见。
负载均衡模式则要求两台甚至多台DHCP服务器同时在线，并且都能响应客户端请求。但DHCP的负载均衡不是简单的请求分发，因为如果两台服务器从同一个地址段随机分配IP，极有可能出现重复地址。因此，负载均衡必须通过地址池拆分或哈希分片来保证每个IP只可能由一台服务器发出。Windows Server的DHCP负载均衡默认把可用地址按比例分成两部分，比如各50%，服务器A负责前一半地址，服务器B负责后一半地址，客户端请求随机落到某台服务器后，只会从它负责的地址段中分配，从而避免冲突。ISC DHCP则用split哈希的方式拆分地址池，原理类似，但控制粒度更细。
从故障恢复角度看，故障转移追求的是可用性优先，即使切换期间有短暂延迟，也要保证服务不中断。负载均衡追求的是性能与可用性兼顾，两台服务器同时工作，既能分担压力，也能在单台故障时由另一台继续提供部分地址分配能力。但要注意，负载均衡模式下如果一台服务器故障，另一台通常只能接管它负责的那部分地址，如果地址池拆分不合理，可能会造成新设备无法获取到故障服务器那部分地址，所以地址池规划比单纯的主备模式更复杂。
二、Windows Server DHCP故障转移的配置方法与关键参数
Windows Server从2012版本开始内置了DHCP故障转移功能，支持热备用和负载均衡两种模式。配置前提是至少有两台运行Windows Server的服务器，都安装DHCP服务器角色并完成授权，同时需要先创建并激活作用域。两台服务器之间的时间同步也很重要，因为租约过期、状态切换都依赖时间判断，建议使用NTP保持时间一致。
在DHCP管理控制台中，右键点击已有的作用域，选择配置故障转移，然后指定伙伴服务器，并选择模式。如果选择负载均衡模式，可以设置负载平衡百分比，默认是50%，表示两台服务器各负责一半地址。如果选择热备用模式，可以配置备用服务器在什么条件下接管，例如主服务器失去响应多少秒后切换。PowerShell方式更加适合批量配置，下面这条命令可以快速为一个作用域启用负载均衡故障转移：
Add-DhcpServerv4Failover -ComputerName dhcp1.contoso.com -PartnerServer dhcp2.contoso.com -Name "DHCP-Failover" -ScopeId 192.168.10.0 -LoadBalancePercent 50 -AutoStateTransition $true -MaxClientLeadTime 1:00:00 -StateSwitchInterval 60
命令中的 MaxClientLeadTime 参数就是常说的MCLT，它代表最大客户端提前期。这个值的含义是：当两台服务器之间失去联系后，备机必须等待MCLT时间，确认主机不会再把某个地址分配给客户端，然后才能从地址池中分配新地址。如果MCLT设置得太短，可能出现地址冲突；设置得太长，故障切换后新设备获取地址会明显变慢。通常在1小时左右比较平衡。
StateSwitchInterval 是状态切换间隔，用来控制自动故障转移的检测频率。AutoStateTransition 设为 $true 后，系统会在检测到伙伴服务器不可用时自动切换状态。需要注意的是，自动切换虽然方便，但在网络抖动频繁的环境中可能造成来回切换，导致租约数据库同步压力增大，甚至出现短暂的服务不稳定。对于核心业务网络，建议先使用手动切换，并结合监控告警确认故障后再切换。
三、基于ISC DHCP的failover实战：Linux环境下的双机热备
Linux和BSD环境中常用的ISC DHCP同样支持failover机制。与Windows Server的图形化配置不同，ISC DHCP需要直接编辑 dhcpd.conf 文件，通过failover peer块定义伙伴关系。两台服务器通过TCP 647端口同步租约信息，正常情况下主服务器负责响应请求，备服务器同步数据，但也可以通过split参数实现负载分担。
下面是一个比较完整的ISC DHCP failover配置片段。假设主服务器地址为192.168.10.1，备服务器地址为192.168.10.2，地址池为192.168.10.100到192.168.10.200：
failover peer "dhcp-failover" {
primary;
address 192.168.10.1;
port 647;
peer address 192.168.10.2;
peer port 647;
max-response-delay 60;
max-unacked-updates 10;
mclt 3600;
split 128;
load balance max seconds 3;
}
subnet 192.168.10.0 netmask 255.255.255.0 {
pool {
failover peer "dhcp-failover";
range 192.168.10.100 192.168.10.200;
}
option routers 192.168.10.1;
option domain-name-servers 223.5.5.5, 223.6.6.6;
}
配置中的 split 128 表示将地址池按照哈希值平均分成两部分，每台服务器各负责128个哈希桶，主服务器分配较低哈希值对应的地址，备服务器分配较高哈希值对应的地址。这样既能实现双活负载，又能避免重复分配。mclt 3600 和Windows Server中的MCLT作用一致，设置为3600秒。如果两台服务器之间的网络中断，备机会在MCLT时间内不分配新地址，之后如果仍无法联系主服务器，才会进入partner-down状态并接管全部地址池。
ISC DHCP的failover配置灵活度很高，适合对DHCP服务有精细化控制需求的场景。但它的缺点也很明显：没有官方图形界面，状态监控需要自己写脚本查看日志或使用第三方工具。另外，load balance max seconds 3 是DHCP负载均衡中的响应延迟参数，客户端广播请求时，两台服务器都会收到，主服务器可以立即响应，备服务器会根据这个值延迟响应，避免地址分配请求被两台服务器同时处理。
四、负载均衡模式下的坑与调优建议
负载均衡模式最容易踩的坑是把多台DHCP服务器放在同一个地址池上，却不做拆分。比如管理员以为两台服务器同时从一个192.168.1.100到192.168.1.200的地址段分配地址，DNS轮询一下请求就能实现负载均衡，结果很快就会出现IP地址冲突。DHCP协议本身没有跨服务器的地址协商机制，必须靠预先划分地址范围或哈希分片来保证唯一性。
另一个常见问题是切换后的地址池可用率不均衡。以Windows Server的50%负载均衡为例，如果一台服务器宕机，另一台服务器只能继续分配自己负责的那一半地址。如果这一半地址已经快用完，而故障服务器负责的那一半还有大量空闲地址，就会导致新设备拿不到地址，尽管整个作用域里还有可用地址。解决办法是适当加大负载均衡百分比中在线服务器的比例，或者提前规划更大的地址池，同时监控两台服务器各自的地址使用率。
状态切换抖动也值得关注。网络闪断、服务器重启维护、同步超时都可能触发自动切换，频繁切换会打乱租约数据库，甚至出现主备两边都认为自己是主服务器的脑裂情况。对于关键网络，建议保留自动切换，但要设置合理的状态切换间隔，比如60秒以上，并结合日志监控切换事件。在Windows Server中可以使用事件查看器查看DHCP故障转移相关日志，在ISC DHCP中则需要关注 dhcpd.log 中的peer状态变化。
最后，如果网络规模较大，可以考虑将DHCP服务与IP地址管理集中起来，使用专门的IPAM工具查看地址分配情况。规模较小的网络，一台主DHCP服务器加一台热备用服务器通常已经足够；规模较大或分支机构较多的网络，采用负载均衡模式并配合监控告警会更合适。无论选择哪种方案，都应该定期验证故障切换是否真的可用，而不是配置完成后就不再管。
