[kea-dev] Lease File Compression Requirements

[Marcin Siodelski]

Being able to sync the lease files between the servers it is an
important requirement for the deployment using DHCP servers. But I am
afraid that it is a whole different feature. Note that there will be
more redundancy considerations once we come round to design and
implementation of the failover. But, this is currently out of scope.

One option for now would probably be to run rsync as a cron job to
populate lease files from one place to another.

Marcin

On 12/16/14 13:44, Alexis wrote:
> 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
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
>