[Kea-users] Kea 1.4 HA questions

[Zayer, Sebastian]

Hi Jason,

if …
| 2) Server1 sends DHCPOFFER to the Client via the relay.
| 3) Client sends DHCPREQUEST via the relay, but arrives on server2.
… that happens, you should have a look at the session-management on the HAproxy.

Just my thoughts.


With kind regards,

Sebastian



[http://www.takko.com/on/demandware.static/-/Sites/default/Logos/TakkoLogo_Curvy.png]<https://m.exactag.com/cl.aspx?tc=622d63de2c2dfa4e3133f6eff7f4a2cb&url=https://www.takko.com/de-de/?utm_source=mail&utm_medium=intern&utm_campaign=Takko_DE_Mailing_Signatur>

[http://www.takko.com/on/demandware.static/-/Sites/default/Logos/Facebook.png]<https://www.facebook.com/TakkoFashionDE>  [http://www.takko.com/on/demandware.static/-/Sites/default/Logos/YouTube.png] <https://www.youtube.com/user/TakkoFashion1>   [http://www.takko.com/on/demandware.static/-/Sites/default/Logos/Instgram.png] <https://instagram.com/takko_fashion>      Sebastian Zayer
Specialist IT Systems

T: +49 2504 923 865
F: +49 2504 923 797
M: +49 152 21811579

Takko Holding GmbH
Alfred-Krupp-Straße 21
48291 Telgte, Deutschland

Geschäftsführer: Ulrich Eickmann, Thomas Helmreich, Alexander Mattschull, Arnold Mattschull
Amtsgericht Münster HRB 8939 | Ust.-Id Nr. DE209094382 | takko.com<https://m.exactag.com/cl.aspx?tc=622d63de2c2dfa4e3133f6eff7f4a2cb&url=https://www.takko.com/de-de/?utm_source=mail&utm_medium=intern&utm_campaign=Takko_DE_Mailing_Signatur>

Bitte prüfen Sie der Umwelt zuliebe, ob der Ausdruck dieser Mail erforderlich ist.
From: Kea-users [mailto:kea-users-bounces at lists.isc.org] On Behalf Of Jason Guy
Sent: Wednesday, December 13, 2017 7:17 PM
To: KEA-Users (kea-users at lists.isc.org) <kea-users at lists.isc.org>
Subject: [Kea-users] Kea 1.4 HA questions

After reading the HA page http://kea.isc.org/wiki/HADesign, I realized that the mode for Load-balancing does not state if a separate device (load balancer) is used to direct the traffic to the servers. It would be good to indicate how the traffic is distributed across the servers.

There is a growing trend in networking, to utilize IP equal-cost multipath (ECMP) forwarding to reach services, rather than maintain a separate device (like an F5 or Linux HAproxy). This does not work for all services obviously, but I think it could work fine for DHCP, provided it is fully HA-aware.

How will the current HA design work in the scenario where the clients are reaching the load-balanced DHCP servers via dhcp-relay?
1) Client sends the DHCPDISCOVER, which is relayed and arrives on Server1
2) Server1 sends DHCPOFFER to the Client via the relay.
3) Client sends DHCPREQUEST via the relay, but arrives on server2.
4) Server2 should send a DHCPACK, but will it?
Is the state between the servers synchronized at each point in the overall transaction, such that server2 can complete the lease?

I think the answer is no, because it appears that the subnet definitions in the Kea configurations have to be manually partitioned, as explained in the section Subnets and Pools Configuration for HA. This implies that each server is still basically autonomous in the subnets they can allocate, while both servers are alive.

This seems like a cumbersome way to implement HA from the user point of view. It is much more intuitive to have a matching configuration (enforced when the HA communication is established), and either server can perform operations on the same resources. In openstack this is all handled via a message queue, so redundant nodes know the active state of transactions.

Anyhow, I think this is a really cool addition to Kea. I am curious how it will work for various data center environments I see every day, where the microservices concept is way things are moving. It may be I misunderstood the HAdesign page, but I would like to understand this better as I plan to test this as soon as possible.

Cheers,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20171213/32f61c31/attachment.htm>