Alexander Clouter wrote: > Karl Auer <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
