DHCP FAILOVER 细节

DHCP Failover的实现细节

RFC 2131的工作机制

RFC 2131定义了三种类型的服务器到服务器的信号：服务器租用同步信号、操作状态信号（问候包）及“我回来了”信号（主服务器从死机状态恢复）。

冗余DHCP服务器遵循RFC 2131 DHCP故障恢复草案通过服务器租用同步信号彼此交流租用信息。当两台服务器工作正常时，主、次服务器间会有连续的信息流。用来交流租用信息的信号有三种：

添加信号，当主服务器分发出一个新租约时，主服务器发送到次服务器的信号；刷新信号，当租约有变化时（如更新/扩充），每台服务器发送的信号；

删除信号，当租约期满，地址又成为可用的了，服务器发送的信号。

在所有情况下，接收方服务器以肯定或否定的认可信号来响应。这些信号只有在请求DHCP客户处理完毕后才发送给另一台服务器。

除了维护当前的租用信息数据库外，次服务器还必须留意主服务器，以便得知何时取代租用的分发。这一功能由监视两台服务器的TCP连接来实现。次服务器使用三个标准以确定它和主服务器的连接是否满意：

1.必须能建立TCP连接；

2.必须接收到主服务器发送的连接信号，并以连接认可响应；

3.必须接收到主服务器发出的状态信号，用它来确定自己的操作状态。

failover协议允许两台DHCP服务器（不能多于2台）共享一个公共的地址池。在任何时刻，每台服务器都拥有地址池中一半的可用地址用来分配给客户端。如果其中一台服务器失效，另一台服务器在与失效的服务器通讯之前会继续从池中renew地址，并且会从它拥有的那一半可用地址中分发新地址给客户端。

如果一台服务器启动时没有预先通知它的failover伙伴, 那么在它对外提供服务以前必须与failover伙伴建立通讯，并且进行同步。这个过程当你首次

为dhcp服务器配置failover功能的时候，以及其中一台failover服务器失效并丢失了它的租约数据库时都会发生。

初始化recovery过程被设计用来确保当一个failover节点丢失了它的租约数据库并且开始重新同步时，失效的服务器在它失效之前发放出去的所有租约都能得到履行。当一个失效的服务器启动时它会注意到它没有保存failover状态，并且会尝试联系它的failover伙伴。

当它建立了联系以后，它会向它的failover伙伴请求一份对方租约数据库的拷贝。它的failover伙伴会发送一份自己的租约数据库的拷贝和一条消息指示它已完成操作。失效的服务器会一直等待到MCLT (Maximum Client Lead Time)时间过去。一旦MCLT过去，两台服务器会开始正常的操作。这个等待周期确保了失效的服务器在与它的伙伴失去联系的时间内发放出去的租约已经失效。

在失效的服务器处于恢复状态的过程中，它的failover伙伴仍处于partner-down状态,这意味着是它的failover伙伴在为所有客户端提供服务。失效的服务器直到它恢复正常状态以前不为任何dhcp客户端提供服务。如果两台服务器都检测到自己没有与客户端进行过通讯的情况下，它们都会进入我们前面提到的recovery状态，此时两台服务器不会对外提供任何dhcp服务，直到MCLT过期。

DHCP负载均衡是由Master服务器上的"split"参数来控制的，split参数设置了一个阀值用来决定是由Master还是Slave服务器来响应一个地址请求。对于load-banlacning来说，一般设置split=128，用户的mac经过hash操作以后变成0-255间的数值，如果该值小于128则由Master对其进行响应，如果该值等于或大于128则由Slave对其进行响应。更多信息请参考RFC-3074和dhcpd.conf man。

用户的dhcp请求中包含了该用户的网卡MAC地址，dhcp服务器将这个

48bits的数值"hashes"成一个可以复验的8bit值。hash操作的目的是将MAC

地址变换成一个0到255之间的8bit的伪随机数。经过hash操作以后，一个给定的MAC地址将会变成一个0到255之间的数字，如果hash算法比较好，则所有请求中的50%会被hash成小于128的值，50%会被hash成大于128的值... 所

以"split 128"将会减少对Master 50%的请求，"split 192" 将会减少对Master 75%的请求. "split 255" 会包括所有的MAC地址并且减少对Master 100%的请求，也就是Master服务器不响应任何请求。两台服务器都保留一个split值的拷贝，并且知道何时该回应用户请求。以上是"split"的工作原理。