Re: Kea Experiment Update
On Mon, 4 Aug 2025 11:47:51 -0400
rhkramer@gmail.com wrote:
> On Saturday, August 02, 2025 11:19:23 PM Charles Curley wrote:
> > On Sat, 2 Aug 2025 21:56:34 -0400
> > rhkramer@gmail.com wrote:
> > > On Thursday, July 31, 2025 08:42:27 AM Charles Curley wrote:
> > > > * Set up high availability between the two kea servers.
> > >
> > > What do you mean by that?
> >
> > https://kea.readthedocs.io/en/stable/arm/hooks.html#libdhcp-ha-so-high-avai
> > lability-outage-resilience-for-kea-servers
>
> Ahh, ok, thanks!
>
> Aside: sometimes I like to (over?) simplify some things -- the
> referenced page is useful, it describes various forms of redundancy
> like:
>
> "The Kea HA hook library supports three configurations, also known as
> HA modes: load-balancing, hot-standby, and passive-backup. In the
> load-balancing mode, two servers respond to DHCP requests."
>
> Those are somewhat self descriptive, but I'd add a little bit:
>
> Aside: note that I'll say because DHCP leases are persisistent, that
> complicates things a little -- I try to address in these notes:
>
> * load-balancing / sharing with failover (in normal operation two
> (or more, iiuc) servers share the load, if one (and maybe more than
> one, as long as there is one left) fails, the other server(s) take
> over the full load with a possible cost in performance. Servers
> advise each other about the leases they open / create so that on
> failure of one server, the other has the information about open
> leases which it needs to continue.
That sounds correct to me. I haven't played with it.
As I understand it, if the two servers can't communicate with each
other, they will both reply to queries, and store up their leases for
communication to the other(s) when communications come back up. The
gotcha here is that the two servers may issue duplicate leases, which
they won't know about until communications are restored.
>
> * hot-standby: one server does the job, but sends information
> about the leases it opens / creates to a (hot) backup server so that
> if the "working" server fails, the hot-standby has the information it
> needs to continue to do the job
Right. And in my experiments so far, it works quite well.
>
> * passive-backup: not completely clear to me at the moment, so I
> won't try to describe
A passive-backup never issues leases or responds to other queries; it
is solely a backup for lease information. You could do the same thing
with failover databases, or, if you are using files to store leases,
synchthing. I haven't played with this either.
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
Reply to: