[kea-dev] Lease File Compression Requirements

Marcin Siodelski marcin at isc.org
Tue Dec 16 13:32:01 UTC 2014



On 16/12/14 13:22, Stephen Morris wrote:
> On 16/12/14 12:02, Marcin Siodelski wrote:
> 
>> As a first step towards the implementation of this feature in Kea, 
>> I created a page with requirements:
>>
>> http://kea.isc.org/wiki/LeaseFileCompressionRequirements
>>
>> All input to this document is welcome.
>>
>> I am planning on creating an accompanying design document using the
>> requirements presented here.
>>
>> Again, please share your thoughts.
> 
> (Commenting on version 3 of the requirements.)
> 
> The requirements look OK, but the only one I question is 2.d "The LFC
> must not spread the lease information in multiple lease files. The only
> exception is the period before the start and end of LFC." This
> requirement seems to introduce extra complexity for little gain.
> 
> The emails in the thread:
> 
> https://lists.isc.org/pipermail/kea-dev/2014-November/000185.html
> 
> have suggested a method of LFC compression where the server renames
> the current lease file and opens a new one; compression then takes
> place asynchronously on the old file.  This would mean that for
> virtually all the time the server is operating there are two files -
> the current one and the compressed one. (I'm assuming that when LFC
> kicks in, it would combine any old files with the one it is processing.)
> 
> As the first email in the thread suggests, combining the compressed
> lease file with the current one means interrupting processing for a
> short while the server appends the latter to the former. I suggest
> that most operators are not too concerned about the contents of the
> file, so whether the lease information is in one file or split between
> two is of no concern to them.  If they do require a single file
> containing snapshot of all the leases, it is simple to concatenate the
> two files.
> 

In the aforementioned thread we have discussed two options: with and
without combining the currently used file with the compressed file
during LFC. See:
https://lists.isc.org/pipermail/kea-dev/2014-November/000190.html

In case of the option 1 the following sequence is followed:
- LFC1 kicks in
- Server ceases handling packets
- Lease file foo.leases is renamed to foo.leases.old
- Lease file foo.leases is recreated and is empty
- Server continues handling packets
- LFC compresses foo.leases.old (background)
- LFC1 ends
- Server continues using foo.leases
- LFC2 kicks in
- Server ceases handling packets
- Lease file foo.leI don't think that the other approach has a lot of
overheadases is appended to foo.leases.old
- Lease foo.leases is recreated and is empty
- Server continues handline packets
- LFC compresses foo.leases.old (background)
- LFC2 ends
- Server continues using foo.leases

In this case, yes, there are at least two files in use all the time and
the requirement doesn't make sense.

There is option 2:
- LFC1 kicks in
- Server ceases handling packets
- Lease file foo.leases.new is created and is empty
- Server uses foo.leases.new for recording current lease updates
- Server continues handling packets
- LFC compresses foo.leases (background)
- Server ceases handling packets
- LFC appends the contents of foo.leases.new to foo.leases
- Server uses foo.leases for recording current lease updates
- Server continues handling packets
- LFC1 ends
- etc.

In case of option 2 you'd have one lease file for most of the time and
the only situation when you'd have two is the LFC period. Here is where
the requirement comes from.

The option 2 has a downside that you'd need to perform additional IO
operation to append the contents of the foo.leases.new to foo.leases. It
also needs time to switch over from using the foo.leases to
foo.leases.new and back.

So, option 2 is a bit slower. Actually, the performance penalty depends
on the rate at which clients acquire/renew leases relative to the time
of LFC.

I thought it would be better from the administrative point of view to
have one lease file, instead of two. But, if we feel it is not
compelling reason given the performance penalty I am ok to go with option 1.

Marcin


More information about the kea-dev mailing list