Migrating subnets between failover peers
dhcp1 at thehobsons.co.uk
Sun Jul 7 21:32:12 UTC 2019
Andrew Bell <andrew at poscomp.ca> wrote:
> I have a legacy server, server A, which holds all of my wired subnets
> (around 200). I also have a new set of servers, B and C, which hold my
> wireless subnets and are configured for failover.
> What I would like to do is migrate all of the wired subnets from server A to
> servers B&C. I think this will work...
> Create a failover peer relationship between A&B.
> Add all subnets from A to B.
> Update pools on A&B to use failover.
> Update routers to point to both A&B.
> Wait a while (days?)
> Add all wired subnets to C (including failover)
> Update pools on B to use B/C failover peer
> Change routers to point to B&C
> Shutdown A
> Does this plan make sense?
Mostly - though I am no expert on failover.
Add the subnets to B with failover. When you add failover to A, it will then sync it's leases to B and they will enter normal state. This sync operation can take some time - watch the logs and/or query state (OMAPI ?).
Now point your routers (I assume you mean relay agents) to A&B.
You don't need to wait, the failover sync will have taken care of transferring leases. Waiting won't make clients switch from talking to A to talking to B.
You can now shut down A and put B into partner down state for this partner. B will now handle all clients when they broadcast requests - but not when they unicast to renew leases. When clients first try and renew leases, they will unicast a request to the server that originally gave them the lease. When they don't get a reply, they will eventually broadcast a renewal request and that will reach B which (because it is in partner down state for peer "A") renew the lease.
If you don't shutdown A at this point, it will still be answering unicast requests from clients when it shouldn't be.
Now add the subnets, with failover, to C; and change failover peer on B to C
Change routers (relay agents) to point to B & C.
Don't forget that you can do this a network (subnet or shared network) at a time. In place of "shutdown", change the subnet declaration to empty apart from "not authoritative". An empty subnet, especially if marked as not authoritative, is effectively "not there" as far as servicing clients.
If not directly connected, the subnet declaration can be missing altogether which achieves the same result.
More information about the dhcp-users