[Kea-users] Kea 1.4 HA questions

[Jason Guy]

Hi Jeffery,

I was thinking about that as a good way to achieve active/backup today.
Thanks for confirming that works.

Cheers,
Jason

On Wed, Dec 13, 2017 at 4:46 PM, Jeffery Harrell <sparky at charlietango.com>
wrote:

> Not for nothing, but what we’re currently doing is using *unequal*-cost
> multipath with Kea. We have two Kea servers (VMs) running OSPF, and the
> “primary” one advertises its route with a lower cost than the “secondary”
> one. Quotes because there’s absolutely no difference between the two
> servers except the route metrics. If server #1 goes down (or more
> realistically, is taken down for maintenance) routers just use the
> next-lowest-cost route to get to the other server.
>
>
> On December 13, 2017 at 1:07:22 PM, Zayer, Sebastian (
> sebastian.zayer at takko.de) wrote:
>
> 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
>
>
>
>
>
> <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>
>
> <https://www.facebook.com/TakkoFashionDE>
> <https://www.youtube.com/user/TakkoFashion1>
> <https://instagram.com/takko_fashion> *Sebastian Zayer*
> Specialist IT Systems
>
> T: +49 2504 923 865 <+49%202504%20923865>
> F: +49 2504 923 797 <+49%202504%20923797>
> M: +49 152 21811579 <+49%201522%201811579>
>
> 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
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
>
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20171214/7fe66ebc/attachment.htm>