DHCP pair messed up, second one only running cant get primary up.

[Drew Derbyshire]

On 1/16/17 11:48 AM, Bob Harold wrote:
>
> On Mon, Jan 16, 2017 at 12:14 PM, Drew Derbyshire 
> <swhobbit at derbyshire.us <mailto:swhobbit at derbyshire.us>> wrote:
>
>     As an aside ...
>
>     The thought of putting recovery state/log files (i.e. the DHCP
>     leases file and its backup) on a RAM disk to make top look pretty
>     leaves me dismayed. That leaves zero local protection against a
>     system crash (or misguided deliberate reboot).
>
>     And yes, the server has been running 346 days -- Doesn't matter.
>     Services can be five nines reliable, but hardware won't be.
>
>     An SSD, or if you prefer multiple SSD units configured as a raid,
>     will give you the same order of performance without the premortem
>     fodder.
>
>     The machine should be audited for other critical files which are
>     written to volatile storage, and moved to the SSD or other storage
>     as well.
>
>     -ahd-
>
>
> I agree that putting state in ram is a concern, but with a failover 
> pair, there should be a duplicate copy on the other server of all but 
> the very latest changes. There is a risk when one server is rebooting, 
> so having a copy of the backup lease file on real disk would help.
> I think SSD (particularly write speed) is still orders of magnitude 
> slower than ram.
>
> That said, I would not ever want to have both servers rebooted at the 
> same time, or even restart DHCP at the same time.  Restart one, allow 
> it to sync data and get to normal-normal, then restart the other.
>
I would suggest the performance difference between RAM and SSD is 
meaningless to the client.  But the whole environment (like how much 
traffic the one DHCP server is handling) has a subtle strangeness about 
it which makes me nervous.

But Not my servers. Not my pager going off.

Good to hear both servers are back online.  We'll leave it at that.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170116/89cd1365/attachment.html>