DHCP Redundancy

[Matt Jenkins]

This is for a wireless ISP network built in a remote area where most of 
the systems are on solar power. It will not be unheard of for any given 
site to lose power for days or more. I need to be able to have dhcp 
servers at each location that all share the same leases information....

On 12/01/2010 02:44 PM, Bryan J Smith wrote:
> > 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
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users