[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