combining lease files

[Bob Harold]

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 (4.1.1.61)
> 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.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20180829/9720edd0/attachment.html>