Alexander Clouter wrote:
Karl Auer <kauer@biplane.com.au> wrote:
On Sun, 2009-06-07 at 14:09 +0100, Arran Cudbard-Bell wrote:
Karl Auer wrote:
DHCP failover and load-balancing are not simple *at all*.
They're trivial once you're storing leases in a transactional database.
With all due respect, Arran, no, they are not.
Two DHCP servers in a failover relationship must communicate with each other, each maintaining information about the state of leases that the other has. If they do so via a shared database (which seems to be what you are suggesting, apologies if not) then the entire point of failover is lost.
The state lives in the database. ISC's DHCP has it's own 'database' which is just a flat text file...FreeRADIUS just puts everything in SQL.
I think Alan's great example is shutdown one of your DHCP servers, scrub the dhcpd.leases file and fire it up again and watch what happens. Also if I see one more damn "peer owns all the leases" message in my logs, I'm likely to cause someone harm :)
And that is quite apart from the carefully timed state management that must occur during takeover or recovery in the case where a server drops out, is not reachable by its peer or is deliberately taken offline. Not to mention the possibility of having several servers participating in various failover relationships.
This is all solved by *load-balancing*. If your load-balancer cannot detect that a DHCP/RADIUS server is dead then you need to get a better load-balancer.
There are also very intelligent ways to achieve load balancing between peers. One option is to calculate a skew time based on the difference between the leases allocated by the local server and the maximum number of leases allocated by a peer in the cluster. When a discover packet is received, the peer with the lowest number of leases allocated, responds immediately. The others wait skew_time to see if a DHCP Offer is broadcast by one of the other peers. If the local server receives no such offer after skew_time, it sends a DHCP offer. Problems with network latency... and it might not work as the code is currently... but still not incredibly hard to implement. Arran