Thoughts on Lease Database

[Shane Kerr]

Stephen,

On Friday, 2012-09-14 15:05:38 +0100, 
Stephen Morris <stephen at isc.org> wrote:
> 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.

In principle I think pre-allocation makes a lot of sense, as far as
address allocation is concerned.

> 1) Pre-Allocation of Leases

> 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.

Do we need to refuse? I think we can "promote" such a lease from
"possibly allocated, don't reuse" to "allocated" if we receive a
renewal request, in most cases. At least in the IPv4 case, this seems
better, since we avoid renumbering and all the associated annoyances
for the user...

> 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.

We may also want to consider an API where we can pre-allocate
non-address resources. This may avoid expensive operations for other
resources that can't collide (ports? licenses? whatever...).


> 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.

I guess it doesn't really matter so much. The basic housecleaning
functionality will look something like:

wait until next lease expiration or lease allocated/allocated
if lease allocated or freed:
   update next lease expiration time
else:
   collect all expired leases
   free them

Reasons to put this into a separate process/thread:

* Maximize throughput of lease assignment, by de-prioritizing this
  thread
* Cleaner separation of tasks

Reasons to put it into the same process/thread:

* Slightly less lock contention (if applicable for lease storage)
* One less process/thread
* Avoid "starvation" scenarios

--
Shane