split scoping

[David W. Hankins]

On Tue, Nov 24, 2009 at 01:44:02PM -0800, Matt Causey wrote:
> On Tue, Nov 24, 2009 at 11:39 AM, Ausmus, Matt <mausmus at chapman.edu> wrote:
> > What are the pros and cons to using just split scoping between a couple of
> > ISC servers vs. using the draft fault tolerance mechanisms built into ISC
> > DHCPd?  1 obvious con is that DHCP leases would be split between 2 different
> > machines.  What are some others and are there any pros to this setup?

Split scopes require "N * 2" address space, where N is the maximum
number of clients.

Failover requires much less address space (not quite N), but requires
much more operator savvy.  Essentially it makes a time-versus-address-
space tradeoff.  If you can run without operator intervention for time
X, that implies allocating a number of leases Y.  So if the pool of
available/unallocated leases divided by two is greater than Y, then
you have enough leases for failover.  After operator intervention you
require only "N" leases - the surviving failover server in partner-
down can use all the leases (after STOS+MCLT).

This is complicated because the number of unallocated leases is very
large when a site is first installed, and fluctuates through the
service's runtime.  The rate at which the service will require new
addresses can also fluctuate.

Don't underestimate the complication of needing to learn some of
failover's intricacies when considering employing it.

> One thing about the failover design, is that there are scenarios which
> are engineered to require manual intervention.  For example, if a

Failover was designed to solve the problem where servers are not
co-resident, but may be in different datacenters on different
continents.

In this case, being out of communications may not mean the partner is
down, and the partner may still be in contact with the clients (the
network path between servers may be down, not the networks between
each server and the clients).

There's no way to sense the remote system's availability without an
operator's sure hand.

It is not engineered to require manual intervention, the requirement
for manual intervention produced the engineering.

But for those of you with more "HA" style deployments, heartbeat
cables and the like, where being out of comms does strongly imply a
down condition, note that committed for 4.2.0a1 there is now a
configuration parameter that moves the server to partner-down after
a timeout.

- A new failover configuration parameter has been introduced for those
  environments where DHCP servers can be reasonably guaranteed to be
  "down" when the failover TCP socket is severed, "auto-partner-down".
  This parameter is not generally safe, and by default is disabled, so
  please carefully review the documentation of this parameter in the
  dhcpd.conf(5) manpage before determining to use it yourself.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20091202/b04de8bc/attachment.bin>