Thoughts on Lease Database

[Stephen Morris]

I've been giving some thought to the interaction of BIND 10 DHCP with
the proposed SQL database, and would like to air a couple of ideas for
comment.


1) Pre-Allocation of Leases
The limitation of ISC DHCP4 appears to be due to disk access - DHCP4
stores lease information to "persistent storage" (i.e. disk) before the
lease is handed out.  The delayed-ack feature reduces the number of
accesses by holding back the sending out of responses until a number are
outstanding, then committing all the relevant leases to disk in one
operation before replying.

We could do this for Kea, but for performance we need to do asynchronous
I/O and not commit before sending a reply.  As Tomasz has shown with the
micro-benchmarks, this speeds things up enormously.  However, there is
then the possibility of double-allocation of an address if the "ack" is
sent out before the lease is written to disk, and the server fails in
that interval: when the server restarts, there is no record of the lease
allocation.

To avoid this, we could try pre-allocating leases of leases.  In this
approach, during startup the server process identifies addresses that
are free and writes to disk dummy lease entries to cover them (setting
the lease time to some value greater than or equal to the maximum lease
time).  The addresses are then cached in memory.

When an address is allocated, it is allocated with the time remaining in
the dummy lease entry (subject to the maximum configured lease time),
and the lease entry on disk is updated.  In this approach, if the system
fails between the "ack" and the update, the worst that will happen when
the system restarts is that the address will not be allocated until the
dummy lease entry expires.  Should the client that received the "ack"
attempt to renew, the renewal is refused and the client would have to
request a new lease.

The complication of this is that periodically the system needs to update
dummy entries where the remaining lease time is less than some multiple
of maximum lease time.  In addition, when there are no more dummy
leases, the system will need to pre-allocate some more.  But against
that are the benefits of increased performance without possibility of
duplication address allocation.


2) Housekeeper for Lease Expiration
If a lease is not renewed, it expires. In this case, the lease entry
should be removed from the database.

It would be possible to have the DHCP server process do this, but in the
case of a multi-process environment, which process?  Also, would it be a
separate thread within a process?

Suggested here is the use of a separate "housekeeper" (or "janitor")
process to handle such chores.  Running independently, it periodically
scans the database and removes expired lease entries.  As well as being
easier to test, it simplifies the construction of the server process.


Stephen