[Kea-users] A couple of questions.

Fri Aug 7 15:10:39 UTC 2015

Thank you all for your answers. I am going to be testing HA using the shared DB backend (pgsql) and some ucarp magic.

I will report on how it turned out after I get some real-world data to share.

This really is a very nice project and I thank you all for your time.

________________________________
From: kea-users-bounces at lists.isc.org <kea-users-bounces at lists.isc.org> on behalf of Nicolas Chaigneau <nic.chaigne at gmail.com>
Sent: August 7, 2015 3:07 AM
To: Tomek Mrugalski
Cc: kea-users at lists.isc.org
Subject: Re: [Kea-users] A couple of questions.

> >> 2, Is there any documentation or plans for high availability within
> >> the kea environment?
> > I think you're asking about the failover specifically? Kea doesn't
> > have failover implementation at this point as it is a really huge
> > functionality. There are potential ways to achieve some failover-like
> > behavior by using the SQL database replication. Kea supports 3 lease
> > database backends, of which two are SQL-based:
> > MySQL and PostgreSQL. Enabling database replication allows for sharing
> > the lease information through the built-in SQL database mechanisms.
> > However, we're not aware of any deployment which does it at this
> > point.
> What Marcin said is certainly a potential solution. There is other one. It's possible to use memfile backend (which stores lease info in plain text files) with DRDB solution, available in RedHat. I'm not familiar with the exact details, but the general concept is that there are two machines with two Kea instances, with their lease file being synchronized over DRDB. That's hot stand-by model. The backup server is ready to serve traffic and, as soon as the primary failure is detected, it goes on-line. I'm aware of one customer who deployed Kea that way, tested it extensively and is happy with the setup.
>
> There may be small window of opportunity for problems (client gets a lease from server A, the host running server A crashes before the changes are picked by server B, server B starts and may try to assign the same lease to someone else), but the solution is said to be working very well.
>

This cannot happen, if you handle the lease file directory mount point as a RedHat cluster resource which belongs to the same service as Kea.
The resource is relocated in case of failure, so the lease file is necessarily available to server B before it is actually started.

However, before server B finishes starting up, there is a service outage as no new lease can be offered in the meantime.
Normally Kea is very quick to start up, unless there are many, many leases to load from the lease file(s).

2015-08-06 20:43 GMT+02:00 Tomek Mrugalski <tomasz at isc.org<mailto:tomasz at isc.org>>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06.08.2015 18:41, Marcin Siodelski wrote:
>> 1, I am curious about whether it is possible to separate subnet
>> declarations for kea's dhcp4 configuration file out of the main
>> conf and into a file of its own. I have _MANY_ subnets to
>> declare and maintaining them programatically in their own file
>> appeals to me a lot.
> We've had plans to do it, but as it happens with the large project
> like this, it always gets prioritized. I think it is worth to look
> into this at some point but have don't have it in scope for the
> next release, which is Kea 1.0 around November. Future plans are
> still being worked out.
As Marcin said, this sadly was pushed back. One of the reasons for
this pushback is that the configuration parsers are part of the code
we're least proud of :) There are multiple user-visible issues:
comments can only start in column 1, multi-line comments are not
supported and, as you found out, file inclusions are not possible. But
the biggest problem is that the internal parsers logic is just too
complex. That's why we'd like to rewrite then.

As we do hope to do it in not so distant future, it doesn't make much
sense to spend time on adding extra features like file inclusion, if
we plan to rewrite the whole parser code.

>> 2, Is there any documentation or plans for high availability
>> within the kea environment?
> I think you're asking about the failover specifically? Kea doesn't
> have failover implementation at this point as it is a really huge
> functionality. There are potential ways to achieve some
> failover-like behavior by using the SQL database replication. Kea
> supports 3 lease database backends, of which two are SQL-based:
> MySQL and PostgreSQL. Enabling database replication allows for
> sharing the lease information through the built-in SQL database
> mechanisms. However, we're not aware of any deployment which does
> it at this point.
What Marcin said is certainly a potential solution. There is other
one. It's possible to use memfile backend (which stores lease info in
plain text files) with DRDB solution, available in RedHat. I'm not
familiar with the exact details, but the general concept is that there
are two machines with two Kea instances, with their lease file being
synchronized over DRDB. That's hot stand-by model. The backup server
is ready to serve traffic and, as soon as the primary failure is
detected, it goes on-line. I'm aware of one customer who deployed Kea
that way, tested it extensively and is happy with the setup.

There may be small window of opportunity for problems (client gets a
lease from server A, the host running server A crashes before the
changes are picked by server B, server B starts and may try to assign
the same lease to someone else), but the solution is said to be
working very well.

>> Thank you all for your time, and for what is shaping out to be a
>> very nice suite of tools.
Thank you for your kind words and for using Kea.

Tomek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVw6rKAAoJEB99lszqrhlNV9IH/3WmFewE9XM9+Y+nI6RA7Ado
2f7+hZjFIQ3v26kdbEeEy4wGVSlzhO2IzVMV0ixc/RgpwRIleGzQA3ENJNwhsCPb
g+WepeGux+X8fxrs+mE4oJLir2OVBgG6QQ+4E6GOZTniRQ7tWFxnzvmrkZB4vJpR
feSrnyZJNGWsUve5xoHet2uJOcYn4XxWhp48dShTrg6e8y2UA9odhgPJxNJfH97C
0DIU08APTQL9qtdb8aUk3djHMDXOemV0QozojO85o5aJvzLWMHMswjP9weDI8J7d
p9fEgScQfC2tuTSuN0aOxPHEqIuRJszfpijFQ0oC3UmOvfN/tHyCw9dkM5tV7Q8=
=M39m
-----END PGP SIGNATURE-----
_______________________________________________
Kea-users mailing list
Kea-users at lists.isc.org<mailto: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/20150807/7d661ab9/attachment.htm>