<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>