[kea-dev] Design for Kea Host Reservation

Marcin Siodelski marcin at isc.org
Wed Oct 8 13:50:21 UTC 2014



On 08/10/14 15:16, Tomek Mrugalski wrote:
> On 08.10.2014 14:35, Marcin Siodelski wrote:
>>>> I don't see a reason whye the reservation can't be out of the pool. So
>>>> you're proposing that when I define a reservation, the configuration
>>>> mechanism checks if this reservation happens to be in one of the pools
>>>> defined for a subnet? And if it is, reject the reservation? How would I
>>>> guarantee this for the HR configuration in the database? What about the
>>>> cases that someone reconfigured the server as we were discussing above?
>>> That's what I what thinking about. If the HR is defined in config, we
>>> could sanity check it during config reload. If the HR is in the database
>>> we could do two things. First, sanity check it during runtime when we
>>> happen to read it from the DB. Second, we could implement a command,
>>> something like host-reservation-check, that would go read all HRs and
>>> sanity check them. We may implement such a command anyway, regardless of
>>> what we decide for this particular case.
>>>
>>> The primary reason why in my opinion reservation shouldn't be out of the
>>> pool is performance. As I said before, if you allow in-pool
>>> reservations, lease select will become slower.
>>
>>
>> I see. Performance is a valid point here. I am afraid that without
>> actual performance data we're not really able to assess what that impact
>> would be.
>>
>> I think the in-pool reservations are in fact popular. For example, on my
>> home router I have a pool of addresses to be handed out to my home
>> devices. The router's administration panel lists the devices which were
>> handed out an addresses and for each of them I have a "Reserve" button
>> which makes a reservation of the address they are currently using. This
>> is the in-pool reservation.
>>
>> On the other hand, my home router doesn't have to support thousands of
>> leases per-second because I have a couple of devices at best. So the
>> performance is not critical. But, what precludes Kea from being a DHCP
>> server for small networks like my home network or any other networks
>> where performance is not a key requirement? This is honest question.
>>
>> Although the additional check for existing HRs during the dynamic
>> allocation will always cause performance penalty, I would like to
>> discuss the usefulness of caching here which could help mitigating the
>> problem of excessive queries to database. See this scenario:
>>
>> Client A has a reservation for address X. Client B doesn't have any
>> reservations but will get an address from the dynamic pool. Client A
>> requests an address first and will be allocated an address reserved for
>> him. The HostMgr will have to make a query to the database to obtain
>> reservations for client A. The caching layer stores this reservation in
>> server's memory. Client B requests an address and allocation engine
>> picks one from the pool. This address happens to be X. The server
>> doesn't have to make additional query to the HR database because the
>> reservation has been cached. Of course, lookup in memory for the
>> reservation has performance implications. But, the performance
>> assessment we made some time ago did not reveal that the server is CPU
>> bound.
>>
>> Assuming that the Client B is the first one to send a request, the
>> HostMgr will not have the reservation for Client A cached. Hence, the
>> server would need to query the database for the reservation of the
>> specific address. This would have a performance impact for the dynamic
>> allocation for the Client B. But, the caching layer would store this
>> reservation in memory and when Client A shows up, there is no need to
>> query HR database because the entry has been already cached.
> And what happens if there are no reservations at all? You can't cache
> negative HR responses (well, technically you could, but it's a very bad
> idea for other reasons). Assuming there are no reservations, every time
> you attempt to pick a lease, you'd first need if it's free and then
> check if it's reserved.
> 
> Depending on what your pool utilization and HR numbers are, this will in
> the most optimistic case add one extra query and in pessimistic case
> will double number of queries.
> 
> Adding one query may seem not much, but consider this. Our allocation
> engine is tuned to handle lots of new clients efficiently. In typical
> case, it requires just one query during lease selection phase. With HR
> implemented, that +1 actually doubles the number of queries in
> optimistic case. If we oversimplify and say that our performance is
> related only to number of queries, we just halved our performance.
> 

It is not my intent to neglect the performance implications of this
change. It very much depends on the specific use case. I just think we
should avoid making design decisions oriented to address one specific
use case, forgetting about other use cases (e.g. ease of management).
Again, when running a small network I often don't care much about
doubled number of queries to SQL database. Also, who said I need to use
SQL database in small deployment at all? I can keep my config-based
reservations in memory. I am after flexibility.

>> Thankfully, I believe that we can make a final decision on this after
>> doing some performance measurements as the change in the code to take
>> into account HR reservations during dynamic allocation would be straight
>> forward (both ways).
> I agree that any speculations about actual performance impact are
> useless. We need to implement this and then assess the damage by running
> tests. Whoever implements this, will have to keep in memory that we may
> change our mind later, so the code should be flexible enough to
> accommodate the change.
> 
>> When I was reading your use case for monitoring and the trigger, I had a
>> thought that the pool definition could come with an optional parameter
>> which defines whether the pool has a relaxed or strict policy, i.e.
>> whether host reservations are allowed or disallowed within this pool.
>> The allocation engine gets the pool for the client and checks this
>> property. If it finds that it is a relaxed pool it must use HostMgr to
>> check for existing reservations which has all the bad sides you
>> mentioned. If the pool has a strict policy the allocation engine doesn't
>> have to worry about HRs and proceeds as usual. Now that the pool is
>> defined as a map in the configuration file, adding this parameter would
>> be trivial. Of course, for each pool following a strict policy the
>> conflicts with HRs would need to be checked before configuration is
>> committed.
> I like that approach.

That makes me happy and my life has just become brighter. :)

> 
>> Having an additional switch always require some more code and some more
>> work. So, it doesn't have to be done from day one. Maybe we could use a
>> strict approach first and then introduce a relaxed one as an extension.
>> If we do opposite, someone using a relaxed approach (implemented first)
>> would be unhappy seeing his configuration invalidate with a next release
>> of Kea (assuming that the strict approach becomes a default). But, which
>> one should be a default is another discussion.
> Strict approach is also easier to do, because it doesn't require
> allocation engine modifications. I think relaxed could be the default
> once we have it implemented. It gives more flexibility and makes the
> software easier to do. If you're after performance, it is natural that
> you need to tweak some knobs.
> 

I think we have just reached a good consensus, which I will document in
the design. Once documented, I will assume our design discussions are
concluded for now, unless someone else jumps with more comments.

Marcin


More information about the kea-dev mailing list