Requirements for the Lease File Cleanup (LFC) in Kea

Kea supports switchable lease database backends. The default backend uses a CSV file as a persistent storage for the leases. On every lease creation or change, the backend synchronously appends the information about this change at the end of the lease file. For example: a client renews a lease multiple times during the lease lifetime and each renewal results in appending one new row to the lease file. This approach has a performance advantage over another possible approach, to update/rewrite the existing lease information in the lease file, because it avoids an overhead of locating the lease entry in the file, or re-writing the whole lease file on each update. The downside is that a single lease maps to multiple entries in a lease file and thus the file size may grow significantly (depending on the number of clients and the renew/rebind timers). It also adds an overhead for the server loading leases from the CSV file on server's startup.

This page describes requirements for a "Lease File Cleanup" in Kea, which is meant to reduce the lease file size by periodically removing the some of the redundant information from it. This page DOES NOT describe requirements for "Lease Expiration", which works by periodically checking the lease database for the expired leases and triggering appropriate actions, e.g. removal of the DNS records associated with the expired leases, executing the callouts and removing the expired leases from the lease database. Note that while "Lease File Cleanup" is specific to the Memfile lease database backend (and doesn't apply to SQL backends) the "Lease Expiration" is a generic feature applying to the use of any backend. In addition, while most of the lease file cleanup can be performed "in background", the lease expiration has much stricter requirements for synchronization of the expired leases processing and DHCP server operation.

Requirements List

This is preliminary and is subject to changes and additions!

  1. Performance
    1. The LFC must have a minimal impact on the performance of the DHCP server.
    2. The server must remain responsive while the LFC is in progress and the interruptions in its operation must be minimized.
  1. Functional
    1. The LFC must not require a server restart.
    2. The LFC must be triggered periodically and the interval must be configurable.
    3. It should be possible to start LFC on-demand, with a manual intervention. Note: this requirement depends on the "command control" feature which is not implemented in Kea yet. So, the initial version of LFC doesn't have to implement this requirement.
    4. The LFC should allow for using the same lease file name between subsequent LFC kickoffs. The file name alterations must be temporary and may only be performed during the LFC.
    5. The LFC must log the details of the LFC operation including: start time, end time, number of all entries, number of entries removed, details of invalid entries found.
  1. Robustness
    1. The LFC must recover from an unexpected interruption, e.g. being result of the server crash, and the lease file should be reconstructed with no loss of data.
    2. The LFC should process all correct lease entries in the lease file, even if errors occur for some of other entries.

Last modified 4 years ago Last modified on Jan 26, 2015, 10:32:47 AM