Linux 下 DHCP 服务器的灾难备份
概述
动态主机设置协议 (DHCP) 用于为用户提供网络参数配置,其最重要的功能就是动态分配 IP 地址。作为一种核心的网络服务,要求其具有高鲁棒性,高灵活性,简单说就是具有冗余备份功能。传统的简单冗余实现,往往会带来 IP 地址空间不足,无法实现在线切换等问题。目前由 ISC (Internet Software Consortium) 提供的开源 DHCP 软件实现了 Failover( 灾难备份 ) 的功能 , 很好地解决了传统方法带来的问题,在业界得到广泛地应用,特别是 Linux 平台,很早就采用了该实现方法。但实践中由于客户对该功能的理解不够深入,影响了工程中使用,本文归纳了灾难备份中的几个主要概念:服务器状态机转 移,IP 地址绑定状态的变更等 , 着重对灾备的原理进行详细介绍 , 有利于用户在工程中充分发挥灾备的强大功能,另外在文末也给出了灾备的简单配置。本文作者参与了 ISC DHCP 在 IBM 平台上的开发和测试工作,希望能够通过本文给读者一定的帮助。
灾备中 DHCP 服务器的状态机切换
IETF 的 draft-ietf-dhc-failover-07.txt 文档中描述了 DHCP 灾备协议,ISC DHCP 4.1 服务器对这一协议进行了实现,它允许两台服务器共享公共地址池,每个服务器可以分配地址池中一半的地址,这时候我们说两个服务器都处于 NOMAL 状态下。如果其中一台服务器 S1 出现故障,虽然两台机子的通信失败,但另外一台 S2 的 DHCP 服务不会有任何影响,他可以响应已分配地址客户端的 renew 消息,也可以接收新客户端的 discovery 消息,然后基于自己管理的一半地址池,分配给他们可用的地址,这种情况下 S2 会自动切换到 COMMUNICATION-INTERRUPTED 状态。
如果故障服务器 S1 长期无法恢复,我们就需要将 S1 宕机的消息告知 S2(通常是向 S2 发送 omshell 外部命令), 这时候 S2 会等待一个安全期(由配置文件中的 MCLT 定义),保证 S1 服务的 IP 地址都已过期,然后 S2 将会回收先前由 S1 管理的另外一半地址池,对整个地址池进行管理和分配,同时 S2 会自动切换到 PARTNER-DOWN 状态。之后当 S1 恢复时,它会自动检测网络,与 S1 进行通信,然后向 S1 发出同步地址数据库的请求,等同步完成后,两个服务器就会像以前一样各自管理一半的地址池,自动进入 NORMAL 状态。
总之,NORMAL, COMMUNICATION-INTERRUPTED, PARTNER-DOWN 是 DHCP 灾备机制中的三种主要状态机,事实上,灾备切换是一个复杂的过程,其中还包含很多中间状态,比如,RECOVER 状态、RECOVER-DONE 状态、 POTENTIAL-CONFLICT 状态,等等。下图是灾备中主要状态机的切换。
图 1. 灾备中的主要状态机切换
- NORMAL 状态下的 DHCP 服务操作 当 DHCP 服务器处于 NORMAL 状态时,每个服务器都会响应所有的 DISCOVERY 消息,响应来至于自己已分配地址客户端的 REQUEST 消息(REQUEST/RENEWAL 和 REQUEST/REBINDING 除外),而对于地址池中任何客户端的 REQUEST/RENEWAL 和 REQUEST/REBINDING 消息,每个服务器都可以响应。另外,一个服务器 S1 对客户端的消息响应可能会引起其地址数据库的数据更新,比如新分配了地址,时间戳发生变化,或客户端地址过期,这时 S1 会将更新消息(BNDUPD)及更新内容发送给它的 PARTNER 服务器 S2,S2 完成对自己的地址数据库更新后,会向 S1 回复消息(BNDACK);
- COMMUNICATIONS-INTERRUPTED 状态下的 DHCP 服务操作 当两个服务器处于 COMMUNICATIONS-INTERRUPTED 状态下时,每个服务器都独立地提供 DHCP 服务,而并不假定 PARTNER 服务器已经宕机。事实上,它的 PARTNER 服务器也许工作正常只是通信发生了问题,或者是真的不工作了。在这样的情形下,每个服务器都会响应来自任意客户端的请求消息,而当它们之间的通信恢复后, 双方服务器会自动地进行一个地址数据库的同步整合操作;
- PARTNER-DOWN 状态下的 DHCP 服务操作 当一个服务器处于 COMMUNICATIONS-INTERRUPTED 状态下时,该服务器假定它的 PARTNER 处于宕机状态,并基于整个地址池为所有的 DHCP 客户端提供服务。
DHCP 地址数据库中 IP 地址的状态切换
大多数 DHCP 服务器中,一个 IP 地址能呈现多种状态。灾备工作模式下,对于管辖范围内的所有 IP, 一个服务器和它的 PARTNER 需要共同维护了一份信息一致的地址池数据库,因此在两个服务器之间会进行很多的数据同步工作。一个服务器 S1 的任何地址状态发生变化,比如租约更新,地址过期,地址释放等,都需要 PARTNER S2 同步变化,具体的流程是:S1 将更新消息(BNDUPD)发送到 S2,S2 根据消息对数据库进行相应的更新,完成后再向 S1 回复确认消息(BNDACK)。以下是主要地址状态机的简介以及状态机切换。
- ACTIVE– 客户端已经获取了该 IP 的租约。
- EXPIRED– 意味着该 IP 的租约已经过期。在这种状态下,服务器会向 PARTNER 发送更新信息,当收到 PARTNER 端的确认消息(BNDACK)后,服务器把该 IP 的状态进一步置为 FREE,这样就可以对它重新分配了。
- RELEASED– 意味着客户端向服务器发送了 DHCPRELEASE 的消息。在这种状态下,服务器会向 PARTNER 发送更新信息,当收到 PARTNER 端的更新确认消息(BNDACK)后,服务器把该 IP 的状态进一步置为 FREE。
- FREE– 当 DHCP 服务器通过 ICMP 探测到某 IP 地址未被使用,并且也不是刚刚被释放或过期的地址,它就将该 IP 设置为 FREE,然后向 PARTNER 发送同步请求,这样该 IP 就可以重新分配了。(注意:如果在 PARTNER-DOWN 状态下,需要等待 MCLT (Maximum Client Lead Time, 该延迟确保其 PARTNER 上维护的地址租约已经过期 ),然后将其 PARTNER 所维护的地址置为 FREE)。
图 2. IP 地址的状态转换
(1) DHCP 服务器处于 PARTNER-DOWN 状态,并且经过了 MCLT 延迟,这时服务器将自动管理整个地址池的 IP,并把把先前由其 PARTNER 维护的地址置为 FREE 状态。
灾备的配置
配置灾备时,我们需要定义 peer, peer 的定义包含灾备协议所需的参数,同时也需要在实施灾备的 pool 中定义 peer 的引用,pool 的定义和使用如下所示:
pool { failover peer "foo"; pool specific parameters }; |
我们在 DHCP 服务器的配置文件(dhcpd.conf)中进行灾备配置,以下给出了一个基本的例子:
failover peer "foo" { /* 是主服务器还是辅助服务器 */ primary/secondary; address 192.168.1.1/vanilla.cn.ibm.com; port 519; /* PARTNER 服务器的 IP 或者 FQDN 名字 */ peer address 192.168.2.1/d60b85ae.cn.ibm.com; /* PARTNER 服务器的端口 */ peer port 520; /* 认定服务器间连接失败的最大时间延迟 */ max-response-delay 60; /* 在未收到 PARTNER 回复时,BNDUPD 消息的最多重发次数 */ max-unacked-updates 10; /* Maximum Client Lead Time. 在灾备方案中,该时间延迟保证 PARTNER 上的 IP 租约已经过期。 该参数只能定义在主服务器中。*/ mclt 3600; /* 主辅服务器的地址分割,通常是各一半 */ split 128; /* 关于负载均衡的参数 */ load balance max seconds 3; } |
以下是一个具体的灾备配置例子:
On Primary server:
failover peer "myfailover" { primary; # declare this to be the primary server address 192.168.1.1; port 647; peer address 192.168.1.2; peer port 647; max-response-delay 30; max-unacked-updates 10; load balance max seconds 3; mclt 1800; split 128; } subnet 192.168.2.0 netmask 255.255.255.0 { pool { failover peer "myfailover"; range 192.168.2.0 192.168.2.255; } } |
On Secondary server:
failover peer "myfailover" { secondary; # declare this to be the secondary server address 192.168.1.2; port 647; peer address 192.168.1.1; peer port 647; max-response-delay 30; max-unacked-updates 10; load balance max seconds 3; } subnet 192.168.2.0 netmask 255.255.255.0 { pool { failover peer "myfailover"; range 192.168.2.0 192.168.2.255; } } |
这样 primary server 和 secondary server 组成了一对 failover peer,其地址分别为 192.168.1.1 和 192.168.1.2,它们共同管理子网 192.168.2.0 的地址分配,由于 split 参数是 128,两个服务器各自负责一半的地址分配,primary server 管理 192.168.2.0~192.168.2.127 网段,secondary server 管理 192.168.2.128~192.168.2.255 网段。Normal 状态下,二者独立负责自己所辖的地址段,响应所有的 DHCP 消息,通过相互通信进行地址数据库信息更新,维护一致的地址池状态,当某个服务器 failover 时,另外一个将自动承担起整个 192.168.2.0~192.168.2.127 网段的分配管理工作,而当 failover 服务器重新恢复时,二者会进行一个地址数据库的同步,然后继续共同管理子网 192.168.2.0。整个过程都是系统自动切换,不需任何人工干预,对用户的网络使用不会造成任何影响。
结论
DHCP 服务器的灾备有效地保证了用户网络的稳定性,减少了网络的人工干预,减轻了网络管理员的负担,提高了 IP 资源的使用效率,将会得到更广泛地应用。
作者简介
张晓光,就职于 IBM CSTL,目前的工作主要是基于 IBM i 平台,从事 TCP/IP 应用的开发和测试,包括 DHCP、DNS、OSPF、SMTP、POP 等组件。
胡���波,就职于 IBM CSTL,目前的工作主要是基于 IBM i 平台,从事 TCP/IP 应用的开发和测试,包括 DHCP、DNS、OSPF、SMTP、POP 等组件。