[Kea-users] kea and ha modes

Philippe Maechler pmaechler-ml at glattnet.ch
Fri Oct 12 13:49:23 UTC 2018


Hello Marcin, 

Thank you for your reply.

Now it all makes sense to me 😊

After my message to the list I saw the post from Sven Roehrig ([Kea-users] HA Load Balancing not working) and your reply there already helped me. 
>From your answer I figured out, that my concerns are only valid when the servers are *not* in the partner-down state. But I didn't found out (or didn't read the manual) when the server goes to partner-down state or if an admin has to take it into that mode. 

Once again thank you for your replies

Best regards
Philippe

-----Original Message-----
From: Marcin Siodelski <marcin at isc.org> 
Sent: Monday, October 8, 2018 11:03 AM
To: Philippe Maechler <pmaechler-ml at glattnet.ch>; kea-users at lists.isc.org
Subject: Re: [Kea-users] kea and ha modes

Hello Philippe,

Thanks for your inquiry. Please see my answers inline.

Kind Regards,

Marcin Siodelski
ISC DHCP Engineering


On 05.10.2018 09:02, Philippe Maechler wrote:
> hello kea users
> 
>  
> 
> I’m once again looking for a way to make our dhcp setup more stable.
> Currently we use the isc dhcpd without failover. For each active dhcp
> server, there is an inactive one (cold standby?), which gets the
> configuration and lease file every few minutes. If something breaks, we
> have to manually take the broken server offline and activate the second
> one. This setup worked more or less stable for more than 10 years.
> 
>  
> 
> But still this setup has it’s disadvantages that I’d like to get rid of.
> Of we have a maintenance window and have to take the router, where the
> active server is connected to down, we don’t have a running dhcp setup.
> New clients won’t be able to get a lease and existing clients fail to
> renew their lease.
> 
>  
> 
> From the kea-user-guid
> (https://kea.isc.org/docs/kea-guide.html#high-availability-library)
> 
>  
> 
> The Kea HA hook library supports two configurations also known as HA
> modes: *load balancing* and *hot standby*…
> 
>  
> 
> In the *load balancing* mode…
> 
> When one of the servers allocates a lease for a client, it notifies the
> partner server over the control channel (RESTful API), so as the partner
> can save the lease information in its own database. *If the
> communication with the partner is unsuccessful, the DHCP query is
> dropped and the response is not returned to the DHCP client*. If the
> lease update is successful, the response is returned to the DHCP client
> by the server which has allocated the lease.
> 
>  
> 
>  
> 
> In the *hot standby* configuration…
> 
> The secodary server receives lease updates from the primary over the
> control channel…
> 
> When the secondary server detects the failure of the primary, it starts
> responding to all DHCP queries.
> 
>  
> 
> My question is:
> 
> In the load balancing mode, when one server dies, both servers won’t
> hand out leases, because the notification over the control channel
> fails, right?. If so, where is the HA part in here?
> 
> 

The doc describes the case when both servers are in "load-balancing"
state, i.e. both have been so far exchanging lease updates successfully.
When lease updates start to fail and the heartbeat messages start to
fail the surviving server still remains in the "load-balancing" state
until it "assures" that the other server is offline. This can take a
while, depending on the configuration. The surviving server continues to
send heartbeats to the partner and if the heartbeats fail longer than
configured amount of time (e.g. 1 minute) it may already consider the
partner do be down. It may also use additional failure detection
mechanism, which examines 'secs' time in the DHCP messages sent to the
partner. This latter mechanism can be disabled administratively.

When the surviving server eventually "assures" that the partner is down
(heartbeats plus optionally 'secs' values verification) it transitions
to the "partner-down" state, where it is going to respond to ALL DHCP
messages directed to the DHCP system.

So, there is a narrow window of time when the DHCP clients may fail to
get responses from the system when surviving server is verifying whether
the partner is alive or dead. In this case the server drops DHCP
messages for which it fails to send lease updates to the partner (which
is possibly down).

Hope that clarifies a bit.

 
> 
> In a hot standby configuration, what happens when the lease update
> fails? Will the “primary” server hand out the lease or not?
> 
>  

This is the same situation as in the "load-balancing" case described
above. The primary server doesn't respond as long as it remains in the
"hot-standby" state. When the primary sees that lease updates are
unsuccessful and the heartbeats fail etc. it will transition to the
"partner-down" state where it is going to respond to DHCP messages and
will stop sending lease updates to the partner until the partner wakes
up and the primary can see it.

> 
>  
> 
> Prior to 1.4 there were several messages on this list about a setup with
> multiple (two) kea instances accessing both the same database (cluster).
> Is such a setup supported/recommended or not? I guess not, because the
> initial text on the above url states, that “supports two configurations
> also known as HA modes”
> 
> 

The cited text refers to the use of HA hooks library when Kea servers
exchange lease updates directly, without the database being involved. It
is possible to use the database in your setup, even without the HA hooks
library. You can simply connect two servers to the same database
instance and let them independently process queries. However, in this
case you should expect conflicts, because the Kea instances may end up
trying to allocate the same address to two different clients (because
they don't coordinate the allocations between each other).

The HA hooks library may be useful in such case because it provides load
balancing and partner failure detection mechanisms. In this case, you
can disable lease updates in the HA hooks library configuration and
simply rely on the database to replicate the leases to its backup instance.

Please see "14.4.7.8. Lease Information Sharing" chapter of the User's
Guide for details.

 
> 
> Best regards
> 
>  
> 
> Philippe
> 
>  
> 
> 
> 
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> 




More information about the Kea-users mailing list