[kea-dev] Lease File Compression Requirements

Alexis alzrck at gmail.com
Tue Dec 16 12:44:47 UTC 2014

will this ensure a way to keep the file/s synced (rsync maybe) to other 'standby' servers and able to assume in case of a switchover?

nowadays it's near requirement to have redundancy (active/active if possible)

just a note.

actually I'm deploying 2 servers right now, both active using a database backend to serve around 60k leases for telephony devices and having 2 or 3 servers was a requirement from my customer

Enviado desde mi iPhone

> El dic 16, 2014, a las 9:22, Stephen Morris <stephen at isc.org> escribió:
>> 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.
> Stephen
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev

More information about the kea-dev mailing list