Update procedure

[Ben Wiechman]

Ben Wiechman

> -----Original Message-----
> From: dhcp-users-bounces at lists.isc.org [mailto:dhcp-users-
> bounces at lists.isc.org] On Behalf Of Glenn Satchell
> Sent: Friday, March 27, 2009 9:58 AM
> To: dhcp-users at lists.isc.org
> Subject: Re: Update procedure
> 
> 
> >From: David Coulthart <davec at columbia.edu>
> >To: Users of ISC DHCP <dhcp-users at lists.isc.org>
> >Subject: Re: Update procedure
> >Date: Fri, 27 Mar 2009 08:54:54 -0400
> >
> >On Mar 26, 2009, at 5:33 PM, David W. Hankins wrote:
> >> On Thu, Mar 26, 2009 at 04:18:36PM -0400, David Coulthart wrote:
> >>> What would the update procedure look like if you need to do an
> >>> upgrade from
> >>> 3.0.x to 4.1.x?  If I upgrade one server to 4.1.x without taking
> >>> down the
> >>> second one still running 3.0.x (so I don't cause an outage for my
> >>> users)
> >>> will dhcpd recognize that they're trying to speak incompatible
> >>> versions of
> >>> the failover protocol and just refuse to talk to one another?  Or
> >>> could
> >>> this result in some form of lease file corruption so I have to take
> >>> both
> >>> servers down before bringing them up on 4.1.x (causing a brief
> >>> outage for
> >>> users)?
> >>
> >> There's no risk to the lease database.  Older versions would log very
> >> odd looking errors, newer versions more gently explain the problem.
> >>
> >> I usually recommend faulting the lease database with the 3.0->3.1+
> >> upgrade (because a lot of bugs throughout development would cause
> >> lease database inconsistency) "just to be sure," but that's up to
> you.
> >
> >Based on this message:
> >
> >https://lists.isc.org/pipermail/dhcp-users/2008-September/007051.html
> >
> >faulting the lease database seems to mean moving the existing
> >dhcpd.leases file out of the way and allowing it to re-sync using the
> >failover protocol.
> >
> >Are you suggesting the same thing as you did in that message -- to
> >fault just the secondary's database?  So the procedure to upgrade
> >would look something like:
> >
> >1) Stop old dhcpd on primary (secondary continues answering users)
> >2) Start new dhcpd on primary w/existing dhcpd.leases (no failover
> >sync will take place b/c of protocol mismatch)
> >3) Stop old dhcpd on secondary
> >4) Move dhcpd.leases on secondary out of the way
> >5) Start up new dhcpd on secondary w/empty dhcpd.leases (relying on
> >failover to sync w/primary)
> >
> >If this is what you are suggesting, won't that mean that any leases
> >given out by the secondary b/w steps 1 & 3 are lost?  If planned
> >properly the time b/w steps 1 & 3 should be minimal, but I just want
> >to make sure I'm understanding the full picture.
> >
> >Thanks,
> >Dave Coulthart
> 
> You're right, so you probably want to stop it on the secondary first,
> then stop the primary and go from there. Remember it's only clients
> that are doing DHCPDISCOVER that will be impacted, any client renewing
> will just keep on retrying.
> 
> regards,
> -glenn
> 
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>