<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFCC">
    <p>Just a thought, could the sync be done as part of the database
      records? That would give a couple of advantages:</p>
    <p>- granularity can be very fine if this is part of each record.</p>
    <p>- all information is available even when one server is down.</p>
    <p>- practically no delay for syncing as it is written at the same
      time as the new lease info.<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 13/12/2017 15:27, Jason Guy wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMii2zOkKSANU2HgEPTsRhA_XkJHxc=M4hJof-ZUvdjcGQBJ-g@mail.gmail.com">
      <div dir="ltr">Hi Tomek,
        <div><br>
        </div>
        <div>I too was entertaining the idea of deploying 3 Kea servers
          for HA/Load Balancing. I had not realized this would not work
          in 1.3, but your explanation certainly helps. I suppose there
          would need to be some type of sync done between instances
          (message queue, multicast, etc.). </div>
        <div><br>
        </div>
        <div>I wanted to share my design idea as it relates to this
          discussion, but I have not done any testing. I was thinking
          the easiest and most extensible way to create HA is to use IP
          "anycast". This requires the hosts are configured with the
          same loopback IP address on all servers, and advertise it out
          into the network using FRR (routing on the host). This allows
          the network to balance the traffic to the servers using ECMP
          Layer-3 routing. I would bind Kea to this "anycast" loopback
          address. Since we use DHCP-Relay on the ToR/Leaf switches, I
          would configure them to relay to the Kea servers' loopback
          address. All the Kea servers would access the same backend SQL
          database cluster. I have not figured out the database side of
          things yet either, but assume the backend database is
          clustered properly and everything is in sync.</div>
        <div><br>
        </div>
        <div>Cheers,</div>
        <div>Jason</div>
        <div> </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Dec 13, 2017 at 7:12 AM, Tomek
          Mrugalski <span dir="ltr"><<a href="mailto:tomasz@isc.org"
              target="_blank" moz-do-not-send="true">tomasz@isc.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">W dniu
            12.12.2017 o 15:48, Munroe Sollog pisze:<br>
            <span class="">> Let me know if this should be a bug, but
              I have noticed some weird stats<br>
              > when running two kea-1.3 DHCP servers from the same
              mysql database<br>
              > (using Galera).<br>
              ><br>
              > I have included a screen grab of the stats.<br>
              ><br>
              > Between noon and 2pm yesterday we when I migrated
              rogi from the memfile<br>
              > to the mysql database.  I migrated all of the
              existing leases from the<br>
              > CSV to mysql and started rogi.<br>
              ><br>
              > Igor from around 2:30pm until about 7:45am the next
              day it steadily<br>
              > declines all the way to -436 leases.  How can it
              possibly have<br>
              > *negative* leases?<br>
            </span>Rasmus is right. Running more than one Kea server
            using the same<br>
            database is not officially supported.<br>
            <br>
            Here's what is likely to happen: each Kea instance allocates
            leases to<br>
            clients. For each allocation, the statistic is increased.
            The statistic<br>
            is observed on each instance. It is likely to be incorrect
            as there is<br>
            another instance that also allocates leases.<br>
            <br>
            Now, unless you took extra steps to disable lease expiration
            on one<br>
            instance and keep it running on another, there are two
            instances<br>
            periodically looking for leases that are expired. Depending
            on how many<br>
            leases are expired during exact moment when the expiration
            triggers, one<br>
            server may get more expired leases to process than the
            other. Only that<br>
            server will decrease the statistic.<br>
            <br>
            Finally, I don't know how you set this up, but I presume
            that the server<br>
            that allocated a lease will send its own server-id and thus
            the release<br>
            messages will be processed only by that server. So this
            shouldn't<br>
            contribute to the confusion, unless you did some clever
            things with<br>
            server-id.<br>
            <br>
            You may perceive it as a bug. It's a valid point of view.
            But I see it<br>
            as Kea being run in a configuration that is not officially
            supported.<br>
            There's nothing wrong with it. We're happy it provides
            service and<br>
            generally works. It's just there are quirks like this.<br>
            <br>
            We do have recountLeaseStats4 and recountLeaseStats6 method,
            but it is<br>
            only used internally. I suppose we could expose it as a
            command that you<br>
            could call. Kea instance would then consult the database and
            recalculate<br>
            the values.<br>
            <br>
            As Rasmus mentioned, we do plan to improve the situation
            significantly<br>
            in 1.4. We want to provide a high availability solution, but
            also<br>
            improve many aspects of running multiple Kea servers at the
            same time.<br>
            <br>
            I don't have any specific solution for you right now, just
            some things<br>
            to consider. Kea doesn't have any notion (at least not yet)
            of a server<br>
            instance owning a lease. You could try generating the
            statistic by<br>
            pooling both servers and adding the values together.
            Consider it an<br>
            experiment. It may or may not work. I'd love to hear about
            the results.<br>
            <br>
            I'd like to ask you a favour. Can you describe how you did
            set up Galera<br>
            for MySQL on kea wiki? There are installation instructions
            here:<br>
            <a href="http://kea.isc.org/wiki/Install" rel="noreferrer"
              target="_blank" moz-do-not-send="true">http://kea.isc.org/wiki/<wbr>Install</a>
            I was thinking about something similar,<br>
            but with detailed instructions how to set up Galera cluster.
            This would<br>
            be useful for two reasons. First, other users could set it
            up in similar<br>
            fashion. Second, one of ISC engineers will get to look at
            this problem<br>
            one day. It will be very helpful to have an instruction to
            replicate<br>
            your environment.<br>
            <br>
            Finally, can you submit a bug for this? It would great if
            this bug<br>
            report had a link to the installation instruction.<br>
            <br>
            Hope that helps,<br>
            Tomek<br>
            <div class="HOEnZb">
              <div class="h5">______________________________<wbr>_________________<br>
                Kea-users mailing list<br>
                <a href="mailto:Kea-users@lists.isc.org"
                  moz-do-not-send="true">Kea-users@lists.isc.org</a><br>
                <a
                  href="https://lists.isc.org/mailman/listinfo/kea-users"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.isc.org/mailman/<wbr>listinfo/kea-users</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kea-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 
</pre>
  </body>
</html>