... | @@ -208,10 +208,12 @@ When the server terminates it must not delete any entries from the `leaseX_avail |
... | @@ -208,10 +208,12 @@ When the server terminates it must not delete any entries from the `leaseX_avail |
|
|
|
|
|
# Tradeoffs
|
|
# Tradeoffs
|
|
|
|
|
|
Pre-allocation of leases should significantly reduce the time to find a next available lease in a situation when the pools are getting exhausted. However, that also has some tradeoffs. The server must go over all IP addresses within each configured pool and check if there is a valid lease for this address. This costs additional time upon server's startup and when new pools are added or existing pools are modified. The larger the pool the more time it takes to pre-allocate the leases in that pool. If there are many pools or the pools are large, this may lengthen the server's startup time. We currently have no data how much longer it would take for the server to startup as a function of the number of addresses in the pools. Appropriate experiments are to be done.
|
|
Pre-allocation of leases should significantly reduce the time to find a next available lease in a situation when the pools are getting exhausted. However, that also has some tradeoffs. The server must go over all IP addresses within each configured pool and check if there is a valid lease for this address. This costs additional time upon server's startup and when new pools are added or existing pools are modified via the server reload or when pools are updated from the Configuration Backend. The larger the pool the more time it takes to pre-allocate the leases in that pool. If there are many pools or the pools are large, this may lengthen the server's startup time. We currently have no data how much longer it would take for the server to startup as a function of the number of addresses in the pools. Appropriate experiments are to be done.
|
|
|
|
|
|
In many cases the problem of degrading performance in nearly exhausted pools appears for smaller pools, e.g. /24, /16, simply because they are smaller. Very often new subnets and shared networks are added to extend the address space in the particular network segment. The pre-allocation is mostly useful in such cases when there are many small pools from which an address is to be picked. Such problem is less common in larger pools, e.g. /8. At the same time, the pre-allocation in the large pools takes considerably more time. Therefore, it seems to be a good idea to be able to disable pre-allocation on the pool level. The appropriate configuration knob should be available at pool, subnet, shared network and global levels. The default value for that knob should be "off" (pre-allocation disabled).
|
|
In many cases the problem of degrading performance in nearly exhausted pools appears for smaller pools, e.g. /24, /16, simply because they are smaller. Very often new subnets and shared networks are added to extend the address space in the particular network segment. The pre-allocation is mostly useful in such cases when there are many small pools from which an address is to be picked. Such problem is less common in larger pools, e.g. /8. At the same time, the pre-allocation in the large pools takes considerably more time. Therefore, it seems to be a good idea to be able to disable pre-allocation on the pool level. The appropriate configuration knob should be available at pool, subnet, shared network and global levels. The default value for that knob should be "off" (pre-allocation disabled).
|
|
|
|
|
|
|
|
Creation of the new lease or deletion of the new lease (including lease updates via HA) will also have some additional overhead related to additional operations on the U-container. This, however, should not be visible as these operations are conducted in server's memory.
|
|
|
|
|
|
# Implementation Tasks
|
|
# Implementation Tasks
|
|
|
|
|
|
* [ ] Configuration knob: enable BALS on global, sn, subnet and pool level (2d)
|
|
* [ ] Configuration knob: enable BALS on global, sn, subnet and pool level (2d)
|
... | | ... | |