... | ... | @@ -96,7 +96,7 @@ There is no standard way in which the pre-allocation could be triggered for all |
|
|
|
|
|
When the server is reloaded, the server should be able to compare the old and new configurations and detect which pools have been added. The `preallocateLeasesX` function should be executed as a final configuration step for all new pools. We could potentially make such checks during the commit() call on the `CfgMgr`, but a PoC would be needed to confirm whether it is a good idea.
|
|
|
|
|
|
The subnet_cmds and configuration backend add/modify subnets directly to the current config (not staging config), and that doesn't involve a commit phase. Therefore, we'd need to trigger `preallocateLeasesX` whenever they update the current config directly. Again, determining the best place to trigger pre-allocation is to be determined.
|
|
|
The subnet_cmds and configuration backend add/modify subnets directly to the current config (not staging config), and that doesn't involve a commit phase. Therefore, we'd need to trigger `preallocateLeasesX` whenever they update the current config directly. Again, the best place to trigger pre-allocation is to be determined.
|
|
|
|
|
|
# MySQL and Postgres
|
|
|
|
... | ... | @@ -206,6 +206,12 @@ Each server connected to the database is configured with a set of address pools. |
|
|
|
|
|
When the server terminates it must not delete any entries from the `leaseX_avail` tables because another server may be using them. The may obviously lead to a dirty database including extraneous data for the leases which belong to the address pools not configured on any server. If this is a concern, it is possible to introduce a configuration parameter which enables cleanup of the stale entries. The cleanup may only be enabled in deployments where a single server is connected to the database at a given time.
|
|
|
|
|
|
# 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.
|
|
|
|
|
|
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).
|
|
|
|
|
|
# Implementation Tasks
|
|
|
|
|
|
* [ ] Configuration knob: enable BALS on global, sn, subnet and pool level (2d)
|
... | ... | |