How does pool rebalance work between failover pairs?
- Updated on 27 Mar 2017
- 2 minutes to read
In 3.0.x, there was no min-balance parameter - it was introduced in 3.1.x when the mechanism for pool rebalancing was changed.
In 3.0.x, the server attempted to perform rebalance on a pool for every /successful/ allocation. if it could not rebalance the pool itself, it would send a 'POOLREQ' message to the peer. This resulted quite obviously in an awful lot of activity around pool rebalance events; the impact of this was very high on large installations. the server receiving a POOLREQ has no way to know which pool the peer is referring to, so it rebalances all pools.
From 3.1.x, ISC's DHCP moved to a schedule based system. The pool is rebalanced at a time that the server estimates it may be imbalanced (the estimate is based on the expiration time of the oldest lease). The min and max values govern that selection (by default 60/3600 seconds respectively), so rebalance events don't fire too often, nor too infrequently.
The server tries to estimate when the remote-system's pools are going to reach the "max lease misbalance" point at the current estimated rate of change (as measured by the oldest free and backup leases expiration times). It only reduces this estimation, but never below min-balance, so in practical terms it takes the "worst case" pool, the pool that indicates the most near term potential schedule for reaching max-misbalance.
Theoretically, the amount of time in between balance events should rise as the expiration times on your free/backup leases become more distant memories of the past, and it should dynamically become more frequent as recent activity makes them more fresh.
If your practice is that leases cycle owners so fast they never get to become memories of the distant past, you can simply raise the min-balance percentage as a workaround. The dhcpd.conf manpage has a section on min-balance and the other parameters that govern pool balance maintenance.
Pool Balance settings
The default settings are generally correct for most environments. If you think that tuning might help, make gradual changes and observe over a reasonable length of time. You may need to make multiple changes until you reach the optimal settings for your specific set-up.
© 2001-2018 Internet Systems Consortium For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership. ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.