Seeking advice on migratrating leases from 1.0.2 server to 3.0.3 servers
Simon Hobson
dhcp1 at thehobsons.co.uk
Tue Dec 2 07:46:43 UTC 2008
Shannon Cooper wrote:
>We are looking to decommission an old failing server that has dhcpd 1.0.2
>installed, and replace it with two newer servers, pre-built with 3.0.3.
>This old server services several large subnets, with large numbers of static
>assignments and leases (close to 4,000). Our desire is to split the subnets
>across the two newer servers, whilst retaining all current assignments and
>leases.
>
>One smaller subnet was migrated to one of the newer servers earlier this
>year, however, it was done one PC at a time. This was labour intensive. We
>do not believe that migrating the remaining leases in this fashion is
>plausible, simply due to the numbers. It has been discussed within our
>group that copying leases data from the old server to the new servers will
>be enough to retain all leases. This was tested in an isolated lab-like
>environment using one PC. It worked, but due to the scale of the test, it
>is unclear if this a reliable method.
>
>So, my question is: Can we simply copy leases data from the older server to
>the newer servers, and retain all current leases?
I was under the impression that the leases file format has changed at
least once - but if the new server will read the old leases file
without complaint then perhaps it's not changed too much.
For your statically defined hosts, you can simply copy the host
definitions over and all will be fine. For the rest there are several
strategies you could use (plus the one you've already tried).
1) The big bang. Simply turn off the old server and turn on the new
one(s). You may get a few abandoned leases, but in most cases (at
least with Windows) the client will come up and ask to renew it's
existing lease - the server will oblige as long as it hasn't given it
to anyone else. Where the client doesn't ask for an existing address,
or where the address has been given out to another client, then a new
address will be allocated.
2) An alternative is to shuffle clients over in a dribble - run both
servers on a subnet with non-overlapping pools. Keep reducing the
size of the pool on the old server, allow the leases to expire, and
then add this address space to the new server (it helps to reduce the
lease time in advance). As the old server won't have enough
addresses, clients will end up taking a new address from the new
server, and when this process is complete then you can turn off the
old server.
In both cases, there is a small chance that a client will change
address during the working day. If this happens then all IP
connections will be broken.
You mention running TWO new servers. Are these a failover pair ? If
so then I have two comments :
1) I would do the migration without failover - there's less to debug
if a problem occurs. Once the migration is complete, then add the
failover (I would test it on one subnet first !). You can run
failover on just selected subnets.
2) 3.0.3 is ancients, and this is especially important with failover.
Watching this list, it's clear that there have been many major
changes, improvements, and serious bug fixes in failover since that
was current - you would be well advised to run 3.1.
--
Simon Hobson
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
More information about the dhcp-users
mailing list