DHCP Redundancy

[Bryan J Smith]

>From everything I've seen, these services do re-read the existing leases file.  
But how do you coordinate multiple DHCP services sharing the same leases file 
without stomping on each other when they update it?  Even if the service only 
briefly opens and closes a write lock, and you can mitigate write lock 
contention when the leases file is updated, how do you force all of the other 
services to re-read the file?

For these levels of high availability, I would highly recommend you consider 
configuring Red Hat Cluster Suite (RHCS) solutions in each subnet, for providing 
your DHCP service.  That way you have a single DHCP service for the range 
defined (multiple per subnet if you wish), it is highly available, possibly 
through even networking equipment failures (depending on the design and 
topology).

I haven't kept up with ISC's latest DHCP service configuration, but I wasn't 
aware of a native, clustering service that can exchange updates and maintains 
their own DBs.  Has this been implemented?  I looked at developing such with the 
Spread API many years ago (along with RADIUS and other authentication), and it's 
quite an undertaking.




----- Original Message ----
From: Matt Jenkins <matt at smarterbroadband.net>
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Sent: Wed, December 1, 2010 5:14:21 PM
Subject: Re: DHCP Redundancy

Would it be possible to have a distributed NFS directory and have many dhcp 
daemons read the same leases and configuration files? Does the DHCP Server 
re-read the leases file when it starts up so it knows about all existing leases?

On 11/30/2010 02:21 AM, Simon Hobson wrote:
> Matt Jenkins wrote:
>> So is it possible to maintain a central or distributed leases file for multiple 
>>(unknown quantity) of servers?
>> 
>> I ask because I am working on a design to change over all of my wireless 
>>clients to dhcp. With the wide spread nature of the network, ALL services are 
>>distributed so that any single point can fail and everything else stays active. 
>>This assumes that the point of failure will never recover. The system MUST be 
>>able to handle this automatically. I definitely do not have 2x the address space 
>>as others suggested. I kind of assumed that the dhcp servers maintained 
>>synchronised information regarding leases.
>> 
>> I estimate the need for 17 dhcp servers (right now) distributed across the 
>>system handling multiple /18's (in total) of address space. Can this be handled?
> 
> Failover is only supported between two servers, but you can have different 
>pairings for different subnets. Eg, you can have A&B for one subnet, A&C for 
>another, A&D for another, C&E for another - whatever you want.
> I think you can do this by pools, but that sounds like a recipe for confusion 
>myself !
> 
> In your situation, a hub and spoke arrangement might make sense (it depends to 
>a certain extent on your network topology). Have one central DHCP server that 
>serves all networks, and a partner for each network.
> 
> Obviously the central server will need to be big enough to handle all the 
>traffic, but each satellite system can be much smaller.
> 
> There was an interesting idea put up a while ago (that was in the context of an 
>ISP setup). In that suggestion, the remotes could keep their lease database in a 
>ram disk - good for performance on a low spec machine. Should the remote site 
>have a power failure, then on startup, the DHCP server can load it's lease 
>database from the central server. Obviously, since the central machine is the 
>only one with non-volatile storage, then it will need to be reasonably reliable 
>(not too hard with server grade hardware).
> 
> 
> As already said, if you wish to do so, then you can script your own checks to 
>detect a partner failure, and automatically put the remaining server into 
>partner down state. What checks you do is up to you - it's your network and only 
>you will have the knowledge to differentiate between failure modes and determine 
>if "can't talk to remote server" really means that it is either down or at least 
>unable to communicate with clients.
> 
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users