Re: [dhcwg] Call for adoption: draft-kostur-dhc-loadbv6

[Bud Millwood <[e-mail]>]

>> When we did DHCPv4 failover I argued in favor of this exact point.   However, in retrospect I'm not sure my argument was correct.   The problem is that failover with load balancing actually doesn't reduce server load: both servers still have to process all the leases, either directly or as binding updates.   So you get a bunch of added complexity with no performance payoff.    You _only_ get the performance payoff with two independent DHCP servers doing load balancing.   Which is actually a very practical configuration in DHCPv6, because address scarcity is so much less of a problem.
>>
>
> We are going to implement it, and there is server load reduction in a
> load balancing case.  If your DHCP server is doing some heavy lifting
> when considering incoming requests, the load balanced partner only has
> to decide that it won't answer the request vs the "primary" partner
> which has to do the expensive stuff (consult external systems,
> perhaps?).  In our internal testing, it did increase the total
> throughput of the DHCP system when comparing a single DHCP server vs.
> a load balanced pair.

Complicated subject.

We can parse about 2k packets per second, but only run about 200
transactions/s per engine thread, so avoiding the transaction really
makes a difference as far as the ability of two servers to process an
inbound load. That said, I think Ted meant that with failover, you're
replicating bindings sideways between servers, so each server has to
stuff the other's bindings into its storage, which means you end up
with the same database I/O rate as if you didn't have load balancing.

However... if sideways replication with your failover system requires
less overhead than processing the same lease as a transaction in the
DHCP in the engine, then load balancing with failover is a win.

Another thing to consider is the regularity of the inbound load. If it
varies over time, lazy-update failover may help to even out the
resource usage on each system by deferring part of the storage I/O
load to a later point in time.

- Bud