Darren, That is a relief. Nearly everything I've read about Kea seems to be fixated on the database solution - to the point that it sounds like that's the only solution. I'm glad I had the wrong impression. I can now look forward to prototyping a conversion to Kea.
(BTW, nothing against databases. I just shy away from unnecessary complexity.) Thanks. -Dave -- Dave Hall Binghamton University kdh...@binghamton.edu On Tue, Apr 22, 2025 at 5:26 AM Darren Ankney <darren.ank...@gmail.com> wrote: > Hi Dave, > > Usage of a database server with Kea is completely optional. You are > free to use the configuration file for all of your configuration > needs. Leases may be stored in a file on the disk as well. Database > is not required for redundancy either (see the HA hook). The only > situation I can think of where database server usage would be required > is if you wanted to manage host reservations with the Stork GUI, which > does indeed require this as it is not able to manage host reservations > that are stored in the configuration file. Most of the time, it is > better, if possible in your environment, to not use a database server > with Kea as the database queries that Kea must make actually decrease > performance. > > Thank you, > Darren Ankney > > On Mon, Apr 21, 2025 at 2:07 PM Dave Hall via Kea-users > <kea-users@lists.isc.org> wrote: > > > > Hello, > > > > As we are starting to plan for an eventual migration from ISC DHCP to > Kea, we have some concerns about how we will map our current usage and > procedures. > > > > (If this has been discussed elsewhere, my apologies. I tried to search > the archives, but perhaps not with the correct terminology.) > > > > In our current practice we rely extensively on DHCP Static Leases (Host > Reservations?) for network management in a data center setting with a large > number of servers. Further, we use DNS names rather than IP addresses in > our DHCP config file, which allows us to reconfigure IP addressing > completely within BIND. > > > > This strategy allows us to avoid static host configurations and to be > able to swap new hardware into a given position simply by changing the MAC > address in the DHCP config file. We also use this mechanism to configure > the BMC for our servers so that the BMC DNS name is consistent with the > host DNS name. Further, we tend assign IP addresses based on physical > location - the row number, rack number, and position in the rack are > encoded in the IP. > > > > Thus, I am a bit concerned about how we will manage this with Kea, which > appears to be based on the use of a database server. Is there any utility > or tool that can translate back and forth between a flat, human readable > file and the database representation, or perhaps that provides a virtual > file representation of the database table containing static leases? > > > > Overall, while I understand how DHCP redundancy and failover are > facilitated by using a database, especially in a predominately > dynamic-lease environment. However, I also see a potential loss of > capability in the shift away from flat configuration files, particularly in > terms of scripting DNS and Static DHCP entries for large deployments. > > > > I am also somewhat concerned that Kea relies on an external service with > non-trivial management requirements. In my mind this adds significant > complexity to what has always been a light and crucially fundamental > network service. > > > > For what it's worth, in my ideal world a restart of the 'primary' Kea > server would cause the static lease table to be dropped and reloaded from > flat files similar to those used with the current DHCP server. Also, an > optimized replication-capable database would be embedded within the Kea > binary. (Replication could be packaged as an add-on.) This would keep it > simple for the small users and yet seamlessly scale for the really large > users. > > > > Thanks. > > > > -Dave > > > > -- > > Dave Hall > > Binghamton University > > kdh...@binghamton.edu > > > > -- > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > > > Kea-users mailing list > > Kea-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/kea-users >
-- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
