Watching performance on a DHCP Server

[Enrique Perez-Terron]

On Wed, 2008-02-13 at 08:04 +0000, Simon Hobson wrote:
> Now consider the case (the normal case for a server that's been 
> installed for a while on a busy network) that there are NO unused 
> leases at all. 

What happens if somebody connects a new PC to such a network?

> Also consider that in the situations mentioned (long 
> term power outage), nearly all the clients will have had prior leases.

Don't the leases expire?

> In both these cases, there is no list of unused leases to 
> pre-allocate - if you go ahead and pre-allocate expired leases, then 
> you risk violating the protocol by pre-allocating an address that a 
> client later wants to come back and use. 

ISPs use DHCP to assign addresses to N computers from a pool of M
addresses with M < N. When a client comes back and wants an address, it
gets a different address because the previous address has been
reassigned to a different client.

Corporate networks are not like that, because they need to have all
computers running at once, during office hours. But then they have more
addresses than computers, in order to have flexibility.

> But the main issue is that 
> when these clients with expired leases come back online - do you a) 
> give them their old lease back (your method has gained nothing),

I fail to see the connection. Why has my method gained nothing?
The point was to avoid fsync for each transaction.

When all the clients come back online they request renewal of their
lease for the address they have been using. Not all these leases will
have been given out in the milliseconds between the last sync of the log
file and the crash. Most will have their leases in the log file and the
server should do exactly as before. 

>  or 
> b) give them a new pre-allocated lease (which brings loads of churn, 
> a rush of DNS updates, AND violates the RFC) ?

Only the the clients that got new leases for new addresses after the
last fsync, would be a problem.
They will be requesting to renew the lease for the new address, but the
server would have lost the information about their allocation.

The server will have to give them new, different addresses, just like it
has to when a lease has expired and the address has been reused for
another client.

Yes, this violates the RFC. If the outage lasts less than the expiry
time, the client will be given a different address when it should not
have been.

The total should be, that in the event of a outage, i.e. once or twice
per decade, a handfull, at most the pre-commit list size (eg.20), often
far fewer, computers have to do DNS updates.  For important servers,
where this is undesirable, let them have fixed addresses - like
one-address pools. Or let them have addresses from a pool that is
flagged not to employ the method.

In return for that the DHCP server only executes fsync() once every 20
leases or so, meaning the service can answer 10-20 times as many clients
per second. The datacenter can adapt its hardware to normal loads, and
still recover with only small delays after an outage.

The advantage of my proposed scheme over turning off fsync alltogether,
is that after a crash you know that the addresses in the lost leases -
if any - belong to a small set that you can dispense with, having a few
more addresses than computers. If you just turn off fsync, and there is
a crash, the addresses of the lost leases will be available and risk
being given to a different computer, even the holder of the lost lease
may still be running and using this address.

If you want absolute adherence, you should probably stick with fsync()
for every lease offer.

Or, perhaps there is yet another way: delay responses to the clients,
process other incoming request, and upon timeout (a few milliseconds),
send all the offers to the log in a single transaction, fsync(), then
send out all the offers to the clients. However, this may require a far
bigger rewrite of the server.

> DHCP is far from being as simple as it looks !

An I am no expert.