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 <[email protected]> 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 ( > [email protected]) 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:[email protected]] *On Behalf Of > *Jason > Guy > *Sent:* Wednesday, December 13, 2017 7:17 PM > *To:* KEA-Users ([email protected]) <[email protected]> > *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 > [email protected] > https://lists.isc.org/mailman/listinfo/kea-users > > > _______________________________________________ > Kea-users mailing list > [email protected] > https://lists.isc.org/mailman/listinfo/kea-users > >
_______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
