<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 1/16/17 11:48 AM, Bob Harold wrote:<br>
    </div>
    <blockquote
cite="mid:CA+nkc8A6BL07pQv_OnRwmc3B7ZeJR43V2CbY3LBP_W0ngPOmVA@mail.gmail.com"
      type="cite">
      <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
                moz-do-not-send="true"
                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>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    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. <br>
    <br>
    But Not my servers. Not my pager going off.<br>
    <br>
    Good to hear both servers are back online.  We'll leave it at that.<br>
    <p><br>
    </p>
  </body>
</html>