[Kea-users] A couple of questions.

Fri Aug 7 07:07:00 UTC 2015

> >> 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>:

> -----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
> 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/a5e8888b/attachment.htm>