<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><br></div></div><div class="gmail_quote">On Mon, Jan 16, 2017 at 12:14 PM, Drew Derbyshire <span dir="ltr"><<a href="mailto:swhobbit@derbyshire.us" target="_blank">swhobbit@derbyshire.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As an aside ...<br>
<br>
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).<br>
<br>
And yes, the server has been running 346 days -- Doesn't matter. Services can be five nines reliable, but hardware won't be.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-ahd-<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>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.</div><div>I think SSD (particularly write speed) is still orders of magnitude slower than ram.</div><div><br></div><div>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.</div><div><br></div><div>-- </div><div>Bob Harold</div><div><br></div></div><br></div></div>