Failover and config differences

[Phil Mayers]

On 12/12/2012 05:34 PM, Chris Buxton wrote:

> 1. Failover does not give significantly better performance than one
> server alone, or two servers using split scopes (as you currently
> have). In my experience, depending on a number of factors including
> configuration, performance might be +/- 30% or so compared to a
> single stand-alone server. With split scopes, you're likely to get
> better performance because the two servers aren't constantly
> notifying each other of lease changes.

I don't really understand what you mean by performance here. CPU/IO 
utilisation? If so, I'm not in the least concerned about that - even 
under peak load, the DHCP process consumes minimal resource (the 
pcap-based logging daemon running alongside it uses more - a whole 2%).

All I really want is a way for the partner server to keep serving 
existing leases for a short duration, which failover does (right?). That 
is, the only "performance" I am interested in is resilience.

> 2. When using failover, if a server has been down for a while, you
> should make sure the configs are synchronized before starting it back
> up again. (If you don't, you're just going to have to stop and
> restart it again after you do synchronize the changes.) After it
> starts up, it synchronizes with its peer before starting to answer
> requests.

I kind of assumed that, but I guess my question really is about how it 
works under the hood; what does a server consider "synchronised"? I see 
from tcpdump that simply restarting the server doesn't result in a bunch 
of failover data being streamed, so I'm assuming it's more sophisticated 
than "send entire lease database when failover connection comes up".

That being the case - how does a server decide what to replicate to its 
partner, and how does that interact with slight differences in the 
config file? I guess that's a more technical re-phrasing of my original 
question.