combining lease files
rharolde at umich.edu
Wed Aug 29 13:36:16 UTC 2018
On Wed, Aug 29, 2018 at 9:33 AM Sten Carlsen <stenc at s-carlsen.dk> wrote:
> On 29/08/2018 14.28, project722 wrote:
> Hey All,
> We are consolidating all subnets on server B and moving to an exisitng
> failover pair we have, In order to decom server B. I'll need to take the
> leases file from server B and combine whats there with the leases file on
> both servers in the failover pair. (doing this to make the failover pair
> aware of what leases are already out there that were assigned by server B)
> I am not sure, but I think one other way could be to make server B part of
> a failover pair with one of the existing failover servers for a period of
> time. That way the remaining server will have all the information
> transferred from server B. Later that configuration could be changed to
> have the other remaining failover server act as the peer, that way the
> servers would transfer the data, probably with less risk.
> Others should confirm or reject this idea.
> I'm thinking just a simple cat on both files should be fine to combine the
> data. And, all 3 servers are running the same verison of dhcp (184.108.40.206)
> and RHEL so I don't expect and formatting problems.
> However, since failover pairs have more transitional states with the
> "binding state" variable, is it possible I will run into any issues doing
> this? Is there a better, more preferred way of doing this instead of
> merging the leases file?
The benefit of a failover pair is that we can upgrade/repair/replace one
server at a time without any interruption in service.
Let's call the failover pair A-master and A-failover.
The recommended method is to configure server B as master and the
A-failover server as failover for server B's subnets also. Give it some
time (watch the failover messages in the logs) to sync the data from B to
A-failover. Then move the subnets from B to A-master, and A-master will
sync the data from A-failover.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users