摘要：
DHCP故障恢复（热备用）此版本的ISCDHCP服务器支持DHCP故障恢复协议。确保每台无法恢复的计算机都运行相同版本的ISCDHCP服务器。故障恢复协议允许两个DHCP服务器（最多两个）共享一个公共地址池。另一个有效服务器将请求分配由另一个服务器管理的地址。它应该自动检测到它已经离线，并请求服务器设置为PARTNER-DOWN状态以传输完整的更新数据。
DHCP 失败恢复（热备机）
这个版本的ISC DHCP服务器支持DHCP失败恢复协议，它在draft-ietf-dhc-failover-07.txt中描述，这不是最终的协议文档，而且没有与其它产品进行交互兼容性操作，这样，你就不能假定产品适合标准。如果你想使用这个失败恢复协议，一定要确定失败恢复的每台机器都运行相同版本的ISC DHCP服务器。
失败恢复协议允许两台DHCP 服务器 (并且不超过2台)共享一个通用的地址池，在任何指定的时间上每台服务器都有池中一半的可分配地址，如果一台服务器失效了，另一台服务器一旦查觉到两台服务器间的通讯丢失，它将会继续更新不在自己范围地址的租约，并且分配不属于自己地址范围的地址。在一台服务器较长时间失效后，另一台有效的服务器将会要求分配另一台服务器管理的地址，并开始使用这些地址。这种状态是将服务器置于PARTNER-DOWN（伙伴机失效）状态。
可以使用命令omshell (1)把服务器设置成PARTNER-DOWN状态。或者设置成失效状态，在租约文件中编辑最后服务器（peer）状态，然后重启服务器，如果用这种方法，一定要确定开始状态的日期和时间留空。
failover peer name state {
my state partner-down;
peer state state at date;
}
当失效的服务器启动完成并在线工作时，它应当自动侦测到它曾经掉线并且会请求设置为PARTNER-DOWN 状态的服务器传送完整的更新数据，然后两台服务器就又恢复到共同处理数据的状态。
有可能进入到一个危险的失败状态：如果你把一台服务器A设置成PARTNER-DOWN状态，接着，另一台服务器B关机，当另一台服务器B恢复时，B不知道A处于PARTNER-DOWN状态，此时B会分配地址，这些地址中部分是A正在分配的，也就是说，一个地址可能分配给了两台不同的客户端，这就造成了IP地址冲突。因此，把一台服务器设置成PARTNER-DOWN 状态，一定确定另一台服务器不是自动重启的。
失败恢复协议定义了主服务器角色和次服务器角色，两着工作有一些不同，大部分区别在与对方通讯的方法上。这样，一台服务器必须配置成主服务器，而另一台服务器必须配置成次服务器，它并不在意哪台机器失败恢复（FAILOVER STARTUP）多少次。
当一个服务器开始工作时，如果它还没有与它的失败恢复备机通讯，它就必须先建立与失败恢复备机建立通讯，然后同步数据，之后才能提供服务。这可能发生在你刚配置完你的DHCP服务器成为失败恢复备机中的一台时，或者其中一台失败恢复伴侣服务器挂掉，并且丢失了它全部的数据。初始化恢复的过程设计要求确定伴侣服务器中的一台丢失了它的数据并且需要重新同步。失效的服务器在失效前分配的所有租约都将被认为有效，当它启动完成后，它发现它没有保存失败恢复数据，它就会尝试与它的伴侣通讯。当它们建立通讯后，它会要求伴侣服务器提供全部的租约数据库的拷贝，接着伴侣服务器发送完整的数据库，发送完成后，再发送一个信息，表示传送完成，失败的服务器接下来就等待，直到MCLT信息到达，一旦MCLT到达，两台服务器就转换到正常状态操作。这个等待时间由两台服务器设置的MCLT时长决定。
当一个服务器从失效状态恢复后，它的伴侣仍就保持partner-down 状态，这表示它为所有客户端提供服务，失效的服务器不会提供任何服务，直到它转换到正常状态。
当两台服务器都发现它们从未与伴侣进行通讯，它们会都按照前面描写的过程进入恢复状态。这种情况下，直到MCLT过期，客户端才能得到DHCP服务。
配置失败恢复
为了配置失败恢复，需要配置失败恢复协议的声明语句，并且在每个需要失败恢复的地址池中配置推荐服务器。在一个指定的网络中，不需要为每个池都配置失败恢复。不能配置其中一个服务器在某个地址池上执行失败恢复，而另一个服务器不在这个地址池上执行失败恢复，对于一个指定的地址池，是否执行失败恢复的配置应该是相同的。一个使用失败恢复的地址池的语句像下面的样子：
pool {
failover peer "foo";
deny dynamic bootp clients;
pool specific parameters
};
动态BOOTP租约不适合失败恢复，并且，如上，应该不允许失败恢复的地址池中有BOOTP客户。
服务器当前对配置文件只做很少的检查，因此，如果你配置有错，服务器就会表现的很奇怪。我想推荐你要么就做失败恢复，要么就别做，不要在服务器上混合做。而且，为两台服务器使用相同的主配置文件，引用各自使用自己独立的失败恢复相关的文件。这会帮助减少很多配置错误。
随着使用的增加，失败恢复服务器的问题会变得越来越少。一个基本的主服务器的dhcpd.conf文件如下
failover peer "foo" {
primary;
address anthrax.rc.vix.com;
port 519;
peer address trantor.rc.vix.com;
peer port 520;
max-response-delay 60;
max-unacked-updates 10;
mclt 3600;
split 128;
load balance max seconds 3;
}
include "/etc/dhcpd.master";
上面用到的语句声明意义如下：
primary 、secondary主、次服务器声明语句：
[ primary | secondary ];
它决定服务器的角色是主还是次，描述在前面DHCP FAILOVER部分。
address 语句
address address;
address 语句声明了服务器应该侦听或者连接的失败恢复伴侣的IP地址或域名，同时也是DHCP失败恢复协议服务器的标识。因为这个值用来标识DHCP服务器在失败恢复伙伴中的地位，它不能被省略。（这里应该是本机的IP地址或域名，因为下面的peer address语句里面言定义的是对端的IP地址或域名，如果按照字面的解释，这两个语句实际是冲突的，再看上面的例子，也应该是本机的IP或域名，需要实验确定一下）
peer address语句
peer address address;
表示失败恢复伴侣的IP地址或域名。
port语句
port port-number;
本机监听的TCP端口号，用来监听伴侣服务器的信息。当前这个选项不能被省略，因为失败恢复协议还没有保留的TCP 端口号。
peer port 语句
peer port port-number;
指定要连接的伴侣服务器的TCP端口号。当前这个选项不能被省略，因为失败恢复协议还没有保留的TCP 端口号。它可以和port 语句的端口号是一个端口号。
max-response-delay 最大回应延时语句
max-response-delay seconds;
最大回应延时语句说明多少秒后DHCP服务器没有收到伴侣的信息，它会认为伴侣已经失效。这个值应该足够小，如果一个短暂的网络失效打断伴侣之间的连接不会影响服务器间的通讯太长时间，但是也要足够大，让服务器可以建立中断的连接。这个参数必须指定。（这里的解释也有问题，可以按例子来设置，具体可能会依靠环境作优化）
max-unacked-updates语句
max-unacked-updates count;
max-unacked-updates 语句告诉DHCP服务器在接收到从伴侣服务器收到BNDACK信息之前可以发送多少个BNDUPD信息。我没有足够的操作经验来说明这个值多大为好，但是10看起来能工作，这个值必须指定。
mclt语句
mclt seconds;
mclt 语句定义了客户端最大引导时间（Maximum Client Lead Time），它一定要在主服务器上指定，不需要在次服务器上指定。这是伴侣服务器双方不通讯而分配的租约更新的时长。设置的越长，运行的服务器恢复转到PARTNER-DOWN 的时间就越长;设置的越短，服务器不能通讯时的负载就越大。设置为3600或许比较好，但是我们并没有真正实际的经验。
split 语句
split index;
split 语句指定主、次服务器之间的负载平衡，当一个客户端发送一个DHCP请求，DHCP服务器按哈希算法为客户机设定地址，如果哈希算法得出的值小于分隔值，主服务器应答，如果值大于或等于分隔值，次服务器应答。唯一有意义的值是128，并且只能配置在主服务器上。
hba语句
hba colon-separated-hex-list;
hba 语句指定主次服务器之间的分隔作为位图而不是中断（as a bitmap rather than a cutoff）, 这理论上允许了更精细的控制。在实践中，一般不需要如此精细的控制。一个hba 语句的例子如下：
hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;
这等价于“split 128”，只能有一个split 或者hba定义，不能两个都有。大多数情况下，更精细的控制hba 并不需要，一般都使用split，很少使用hba。
load balance max seconds语句
load balance max seconds seconds;
这个语句允许配置一个界限，过了这个界限后负载平衡就被关闭。这个界限基于客户端发送DHCPDISCOVER 或者 DHCPREQUEST之后的秒数，并且需要客户端装配secs字段――幸运的是，大多数客户端都这样。我们推荐设置这个值为3 或 5。这个语句的作用是：如果一个失败恢复的伴侣进入一种状态，它对另一个伴侣有应答，但对客户端没有应答，正常的一台将会接管另一台的负载。
这个版本的ISC DHCP服务器支持DHCP失败恢复协议，它在draft-ietf-dhc-failover-07.txt中描述，这不是最终的协议文档，而且没有与其它产品进行交互兼容性操作，这样，你就不能假定产品适合标准。如果你想使用这个失败恢复协议，一定要确定失败恢复的每台机器都运行相同版本的ISC DHCP服务器。
失败恢复协议允许两台DHCP 服务器 (并且不超过2台)共享一个通用的地址池，在任何指定的时间上每台服务器都有池中一半的可分配地址，如果一台服务器失效了，另一台服务器一旦查觉到两台服务器间的通讯丢失，它将会继续更新不在自己范围地址的租约，并且分配不属于自己地址范围的地址。在一台服务器较长时间失效后，另一台有效的服务器将会要求分配另一台服务器管理的地址，并开始使用这些地址。这种状态是将服务器置于PARTNER-DOWN（伙伴机失效）状态。
可以使用命令omshell (1)把服务器设置成PARTNER-DOWN状态。或者设置成失效状态，在租约文件中编辑最后服务器（peer）状态，然后重启服务器，如果用这种方法，一定要确定开始状态的日期和时间留空。
failover peer name state {
my state partner-down;
peer state state at date;
}
当失效的服务器启动完成并在线工作时，它应当自动侦测到它曾经掉线并且会请求设置为PARTNER-DOWN 状态的服务器传送完整的更新数据，然后两台服务器就又恢复到共同处理数据的状态。
有可能进入到一个危险的失败状态：如果你把一台服务器A设置成PARTNER-DOWN状态，接着，另一台服务器B关机，当另一台服务器B恢复时，B不知道A处于PARTNER-DOWN状态，此时B会分配地址，这些地址中部分是A正在分配的，也就是说，一个地址可能分配给了两台不同的客户端，这就造成了IP地址冲突。因此，把一台服务器设置成PARTNER-DOWN 状态，一定确定另一台服务器不是自动重启的。
失败恢复协议定义了主服务器角色和次服务器角色，两着工作有一些不同，大部分区别在与对方通讯的方法上。这样，一台服务器必须配置成主服务器，而另一台服务器必须配置成次服务器，它并不在意哪台机器失败恢复（FAILOVER STARTUP）多少次。
当一个服务器开始工作时，如果它还没有与它的失败恢复备机通讯，它就必须先建立与失败恢复备机建立通讯，然后同步数据，之后才能提供服务。这可能发生在你刚配置完你的DHCP服务器成为失败恢复备机中的一台时，或者其中一台失败恢复伴侣服务器挂掉，并且丢失了它全部的数据。初始化恢复的过程设计要求确定伴侣服务器中的一台丢失了它的数据并且需要重新同步。失效的服务器在失效前分配的所有租约都将被认为有效，当它启动完成后，它发现它没有保存失败恢复数据，它就会尝试与它的伴侣通讯。当它们建立通讯后，它会要求伴侣服务器提供全部的租约数据库的拷贝，接着伴侣服务器发送完整的数据库，发送完成后，再发送一个信息，表示传送完成，失败的服务器接下来就等待，直到MCLT信息到达，一旦MCLT到达，两台服务器就转换到正常状态操作。这个等待时间由两台服务器设置的MCLT时长决定。
当一个服务器从失效状态恢复后，它的伴侣仍就保持partner-down 状态，这表示它为所有客户端提供服务，失效的服务器不会提供任何服务，直到它转换到正常状态。
当两台服务器都发现它们从未与伴侣进行通讯，它们会都按照前面描写的过程进入恢复状态。这种情况下，直到MCLT过期，客户端才能得到DHCP服务。
配置失败恢复
为了配置失败恢复，需要配置失败恢复协议的声明语句，并且在每个需要失败恢复的地址池中配置推荐服务器。在一个指定的网络中，不需要为每个池都配置失败恢复。不能配置其中一个服务器在某个地址池上执行失败恢复，而另一个服务器不在这个地址池上执行失败恢复，对于一个指定的地址池，是否执行失败恢复的配置应该是相同的。一个使用失败恢复的地址池的语句像下面的样子：
pool {
failover peer "foo";
deny dynamic bootp clients;
pool specific parameters
};
动态BOOTP租约不适合失败恢复，并且，如上，应该不允许失败恢复的地址池中有BOOTP客户。
服务器当前对配置文件只做很少的检查，因此，如果你配置有错，服务器就会表现的很奇怪。我想推荐你要么就做失败恢复，要么就别做，不要在服务器上混合做。而且，为两台服务器使用相同的主配置文件，引用各自使用自己独立的失败恢复相关的文件。这会帮助减少很多配置错误。
随着使用的增加，失败恢复服务器的问题会变得越来越少。一个基本的主服务器的dhcpd.conf文件如下
failover peer "foo" {
primary;
address anthrax.rc.vix.com;
port 519;
peer address trantor.rc.vix.com;
peer port 520;
max-response-delay 60;
max-unacked-updates 10;
mclt 3600;
split 128;
load balance max seconds 3;
}
include "/etc/dhcpd.master";
上面用到的语句声明意义如下：
primary 、secondary主、次服务器声明语句：
[ primary | secondary ];
它决定服务器的角色是主还是次，描述在前面DHCP FAILOVER部分。
address 语句
address address;
address 语句声明了服务器应该侦听或者连接的失败恢复伴侣的IP地址或域名，同时也是DHCP失败恢复协议服务器的标识。因为这个值用来标识DHCP服务器在失败恢复伙伴中的地位，它不能被省略。（这里应该是本机的IP地址或域名，因为下面的peer address语句里面言定义的是对端的IP地址或域名，如果按照字面的解释，这两个语句实际是冲突的，再看上面的例子，也应该是本机的IP或域名，需要实验确定一下）
peer address语句
peer address address;
表示失败恢复伴侣的IP地址或域名。
port语句
port port-number;
本机监听的TCP端口号，用来监听伴侣服务器的信息。当前这个选项不能被省略，因为失败恢复协议还没有保留的TCP 端口号。
peer port 语句
peer port port-number;
指定要连接的伴侣服务器的TCP端口号。当前这个选项不能被省略，因为失败恢复协议还没有保留的TCP 端口号。它可以和port 语句的端口号是一个端口号。
max-response-delay 最大回应延时语句
max-response-delay seconds;
最大回应延时语句说明多少秒后DHCP服务器没有收到伴侣的信息，它会认为伴侣已经失效。这个值应该足够小，如果一个短暂的网络失效打断伴侣之间的连接不会影响服务器间的通讯太长时间，但是也要足够大，让服务器可以建立中断的连接。这个参数必须指定。（这里的解释也有问题，可以按例子来设置，具体可能会依靠环境作优化）
max-unacked-updates语句
max-unacked-updates count;
max-unacked-updates 语句告诉DHCP服务器在接收到从伴侣服务器收到BNDACK信息之前可以发送多少个BNDUPD信息。我没有足够的操作经验来说明这个值多大为好，但是10看起来能工作，这个值必须指定。
mclt语句
mclt seconds;
mclt 语句定义了客户端最大引导时间（Maximum Client Lead Time），它一定要在主服务器上指定，不需要在次服务器上指定。这是伴侣服务器双方不通讯而分配的租约更新的时长。设置的越长，运行的服务器恢复转到PARTNER-DOWN 的时间就越长;设置的越短，服务器不能通讯时的负载就越大。设置为3600或许比较好，但是我们并没有真正实际的经验。
split 语句
split index;
split 语句指定主、次服务器之间的负载平衡，当一个客户端发送一个DHCP请求，DHCP服务器按哈希算法为客户机设定地址，如果哈希算法得出的值小于分隔值，主服务器应答，如果值大于或等于分隔值，次服务器应答。唯一有意义的值是128，并且只能配置在主服务器上。
hba语句
hba colon-separated-hex-list;
hba 语句指定主次服务器之间的分隔作为位图而不是中断（as a bitmap rather than a cutoff）, 这理论上允许了更精细的控制。在实践中，一般不需要如此精细的控制。一个hba 语句的例子如下：
hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;
这等价于“split 128”，只能有一个split 或者hba定义，不能两个都有。大多数情况下，更精细的控制hba 并不需要，一般都使用split，很少使用hba。
load balance max seconds语句
load balance max seconds seconds;
这个语句允许配置一个界限，过了这个界限后负载平衡就被关闭。这个界限基于客户端发送DHCPDISCOVER 或者 DHCPREQUEST之后的秒数，并且需要客户端装配secs字段――幸运的是，大多数客户端都这样。我们推荐设置这个值为3 或 5。这个语句的作用是：如果一个失败恢复的伴侣进入一种状态，它对另一个伴侣有应答，但对客户端没有应答，正常的一台将会接管另一台的负载。