<div dir="ltr"><div>Hi, </div><div><br></div><div>Thanks for getting back to me. My assumptions about the in-memory state was largely based on this conversation:</div><div><a href="https://lists.isc.org/pipermail/kea-users/2017-December/001528.html">https://lists.isc.org/pipermail/kea-users/2017-December/001528.html</a></div><div><br></div><div>Also point 4 on this page states: (<a href="https://kb.isc.org/docs/kea-performance-optimization">https://kb.isc.org/docs/kea-performance-optimization</a>)<br><br><i>"<span style="color:rgb(26,26,27);font-family:Nunito,sans-serif;letter-spacing:0.85px">Avoid shared lease backends. When multiple Kea servers share a single lease backend (e.g. with a cluster of databases serving as the lease backend with multiple Kea instances sharing the same pools of addresses for allocation), they will run into contention for assigning addresses. Multiple Kea instances will attempt to assign the next available address; only the first one will succeed and the others will have to retry."</span><br></i><br></div><div>The design I'm trying to achieve:</div><div><br>1. Multiple KEA instances (AWS ECS Fargate) sitting behind an AWS Network Load Balancer, sharing a single mysql backend</div><div>2. Horizontal scaling of these instances up and down to accommodate load<br></div><div>3. All instances are provisioned with the same configuration file (pools, subnets .etc)<br>4. Zero downtime deployments by removing instances and having the load balancer redirect traffic to remaining instances</div><div><br>My concerns are mainly around race conditions and the iterator to find the next available IP to hand out.<br>Does it sound like the above could be achieved? <br></div><div><br></div><div>Regards,</div><div>Emile</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 11, 2020 at 7:11 PM Tomek Mrugalski <<a href="mailto:tomek@isc.org">tomek@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11.12.2020 18:12, Emile Swarts wrote:<br>
> I've looked at implementing multiple KEA instances with a shared database.<br>
> I realise that this current setup will hand out overlapping IPs because<br>
> the leases are stored in memory not in the database.<br>
Where did you get this impression from? This is mostly incorrect. If you<br>
configure Kea to use a database to store leases, Kea will never cache<br>
anything in memory and will always do a DB lookup before assigning<br>
anything. The only way I can think of making Kea to keep the leases<br>
"stored in memory" would be using memfile as lease backend, but then Kea<br>
would never look up leases in a DB.<br>
<br>
> I'm in the process of adding KEA HA, but just wanted to confirm that<br>
> there is no way to force a lookup in the database to find the next<br>
> available IP before committing to this approach.<br>
Kea doesn't work the way you think it is. Kea always looks up the lease<br>
database and never keeps any memory cache of it.<br>
<br>
Tomek<br>
_______________________________________________<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
To unsubscribe visit <a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/kea-users</a>.<br>
<br>
Kea-users mailing list<br>
<a href="mailto:Kea-users@lists.isc.org" target="_blank">Kea-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/kea-users</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-weight:bold">Emile Swarts</td></tr><tr><td style="color:rgb(136,136,136);line-height:1">Software Engineer </td></tr><tr><td style="font-size:0px;height:12px"> </td></tr><tr><td valign="top"><a href="https://www.madetech.com?utm_source=signaturesatori&utm_medium=email&utm_campaign=general_signature" rel="nofollow" target="_blank"><img alt="" height="19" src="https://s3-eu-west-1.amazonaws.com/made-assets/logo-small.png" width="155"></a></td></tr><tr><td style="font-size:0px;height:10px"> </td></tr><tr><td><a href="https://www.madetech.com?utm_source=signaturesatori&utm_medium=email&utm_campaign=general_signature" style="color:rgb(67,154,99)" rel="nofollow" target="_blank">www.madetech.com</a></td></tr><tr><td style="font-size:0px;height:2px"> </td></tr><tr><td><a href="https://twitter.com/madetech" style="color:rgb(67,154,99)" rel="nofollow" target="_blank">twitter.com/madetech</a></td></tr><tr><td>
                <img src="https://pixel-geo.prfct.co/sseg?add=9818841&source=js_tag&a_id=75017" width="1" height="1" border="0">
            </td></tr></tbody></table>
</div></div>