Der Hot-Standby Mode des KEA DHCP Servers ist eine von vielen Möglichkeiten, um eine High Availability (HA) im Netzwerk zu erreichen. Beim Hot-Standby Mode ist nur ein Server aktiv, während der andere oder die anderen im Standby sind. Sie erhalten zwar dennoch lease-updates, aber verteilen keine. Sobald der primäre DHCP-Server ausfällt, übernimmt ein anderer und kann weiterhin die Aufgabe wahrnehmen. DHCP gehört zu den esentiellen Diensten in einem Netzwerk und gerade in großen Netzwerken sollte unbedingt ein HA-Verbund eingesetzt werden. in diesem Artikel zeige ich dir, wie du zwei KEA DHCP-Server im Hot-Standby Mode betreiben kannst.
Attention: For the english version, click here!
Vorbereitungen
Für den Aufbau bentöigst du mindestens drei VM’s oder Hosts. Zwei dienen als DHCP-Server im HA-Verbund. Der dritte Host ist der Client, der dann eine Lease von den Servern beziehen soll, um so auch den Verbund testen zu können.
Meine Server bekommen zwei Netzwerkkarten, eine auf Netzwerkbrücke, eine auf internes Netzwerk eingestellt. Der Client kommt mit einer Karte, auf internes Netzwerk gesetzt, aus.
Das interne Netz für das Tutorial lautet 10.0.0.0/24
Konfiguration
In meinem letzten Tutorial zum KEA DHCP-Server war lediglich ein DHCP-Server im Einsatz, also quasi das grundlegende Konzept. Jetzt geht es darum mindestens zwei Server zu installieren und konfigurieren. Wie du dir schon vorstellen kannst, müssen also alle Schritte nahezu zweimal durchgeführt werden. Beim zweiten Server musst du in der Konfiguration natürlich Name und gegebenenfalls das Interface entsprechend abändern.
Los geht’s!
Wie immer, erstmal das Package Repo updaten und gegebenenfalls gleich upgraden (optional):
su
pkg update && pkg upgrade -yDanach das KEA Package installieren:
pkg install keaIst das getan, kannst du schon die Konfiguration des DHCP-Servers anpassen. Bearbeite dazu folgende Datei:
vi /usr/local/etc/kea/kea-dhcp4.confZiel ist es, dass ein Server aktiv Leases verteilt, während der andere oder die anderen Server sich im Standby befinden. Wenn man sich die Dokumenation zum Hot-Standby Mode anschaut, sind ein paar Anpassungen notwendig. Ich möchte zum Beispiel kein Relay Agent einsetzen. Ein Relay Agent leitet DHCP-Anfragen über einzelne Broadcastdomänen hinweg weiter, um somit entfernte Netze erreichen zu können. Meine beiden Server und die HA-Kommunikation sollen aber im gleichen Netzwerk verlaufen.
Weiterhin ist es wichtig für FreeBSD den korrekten Pfad der libraries anzugeben. An Stelle von /usr/lib/kea/hooks/, wie in der Dokumentation beschrieben, befinden sich die Bibliotheken unter /usr/local/lib/kea/hooks/. Andernfalls wirst du mit Fehlermeldungen überschüttet.
Zu Testzwecken habe ich max-unacked-clients auf 0 gesetzt. Somit übernimmt direkt Server2 die Aufgabe des aktiven DHCP-Servers, wenn auch nur ein Client kein gültiges Lease erhält.
Jetzt kannst du natürlich deine Konfiguration des Subnets weiter anpassen.
- Server 1
- Server 2
{
"Dhcp4": {
"hooks-libraries": [{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so",
"parameters": { }
}, {
"library": "/usr/local/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [{
"this-server-name": "server1",
"mode": "hot-standby",
"heartbeat-delay": 10000,
"max-response-delay": 10000,
"max-ack-delay": 5000,
"max-unacked-clients": 0,
"peers": [{
"name": "server1",
"url": "http://10.0.0.1:8000/",
"role": "primary",
"auto-failover": true
}, {
"name": "server2",
"url": "http://10.0.0.2:8000/",
"role": "standby",
"auto-failover": true
}]
}]
}
}],
"interfaces-config": {
"interfaces": [ "em1" ]
},
"subnet4": [{
"subnet": "10.0.0.0/24",
"pools": [{
"pool": "10.0.0.10 - 10.0.0.110",
}],
"option-data": [{
"name": "routers",
"data": "10.0.0.1"
}]
}]
}
}{
"Dhcp4": {
"hooks-libraries": [{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so",
"parameters": { }
}, {
"library": "/usr/local/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [{
"this-server-name": "server2",
"mode": "hot-standby",
"heartbeat-delay": 10000,
"max-response-delay": 10000,
"max-ack-delay": 5000,
"max-unacked-clients": 0,
"peers": [{
"name": "server1",
"url": "http://10.0.0.1:8000/",
"role": "primary",
"auto-failover": true
}, {
"name": "server2",
"url": "http://10.0.0.2:8000/",
"role": "standby",
"auto-failover": true
}]
}]
}
}],
"interfaces-config": {
"interfaces": [ "em1" ]
},
"subnet4": [{
"subnet": "10.0.0.0/24",
"pools": [{
"pool": "10.0.0.10 - 10.0.0.110",
}],
"option-data": [{
"name": "routers",
"data": "10.0.0.1"
}]
}]
}
}KEA im Hot-Standby Mode starten und testen
Um deine Hot-Standby Konfiguration erfolgreich zu testen, solltest du Schritt für Schritt vorgehen.
Als Erstes, sofern du das möchtest, soll der KEA DHCP auch nach einem Neustart wieder automatisch starten. Die nachfolgenden Schritte sind natürlich auf all deinen Servern durchzuführen!
service kea enableDanach solltest du den Dienst starten:
service kea startSind beide Server erfolgreich gestartet, erhälst du in Kürze folgende Meldungen:
2024-01-24 13:00:55.450 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'ha-heartbeat'
2024-01-24 13:00:55.456 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'dhcp-disable'
2024-01-24 13:00:55.457 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'lease4-get-page'
2024-01-24 13:00:55.458 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'ha-sync-complete-notify'
2024-01-24 13:01:04.010 INFO [kea-dhcp4.ha-hooks/1528.0x801c15f00] HA_STATE_TRANSITION server transitions from READY to HOT-STANDBY state, partner state is READY
2024-01-24 13:01:04.010 INFO [kea-dhcp4.ha-hooks/1528.0x801c15f00] HA_LEASE_UPDATES_ENABLED lease updates will be sent to the partner while in HOT-STANDBY state
2024-01-24 13:01:05.985 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'ha-heartbeat'
2024-01-24 13:01:16.492 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'ha-heartbeat'
2024-01-24 13:01:26.970 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'ha-heartbeatStartest du jetzt einen Client, wirst du auf dem primären Server folgende Meldung sehen:
2024-01-24 13:06:43.066 INFO [kea-dhcp4.leases/1528.0x801c15800] DHCP4_INIT_REBOOT [hwtype=1 08:00:27:c4:0f:d1], cid=[01:08:00:27:c4:0f:d1], tid=0x1d4e6eaa: client is in INIT-REBOOT state and requests address 10.0.0.10
2024-01-24 13:06:43.066 INFO [kea-dhcp4.leases/1528.0x801c15800] DHCP4_LEASE_ALLOC [hwtype=1 08:00:27:c4:0f:d1], cid=[01:08:00:27:c4:0f:d1], tid=0x1d4e6eaa: lease 10.0.0.10 has been allocated for 7200 secondsDer Client hat also erfolgreich die 10.0.0.10 als IP-Adresse bezogen.
Um die HA-Fähigkeit zu testen, beende ich jetzt Server1. Nachfolgende Meldungen stammen von Server2, nachdem Server1 nicht mehr erreicht werden kann:
2024-01-24 13:08:57.268 WARN [kea-dhcp4.ha-hooks/3276.0x837bf7f00] HA_HEARTBEAT_COMMUNICATIONS_FAILED failed to send heartbeat to server1 (http://10.0.0.1:8000/): Connection refused
2024-01-24 13:08:57.268 WARN [kea-dhcp4.ha-hooks/3276.0x837bf7f00] HA_COMMUNICATION_INTERRUPTED communication with server1 is interruptedWie zu erwarten war, schlägt die Heartbeat-Kommunikation, also die Kommunikation zwischen den beiden Servern, fehl.
Kommt jetzt ein weiterer Client hinzu, wird Server2 die Anfragen beantworten. Ist Server1 wieder erreichbar werden die Lease-Updates ausgetauscht und er übernimmt wieder die Rolle als primären DHCP-Server.
Zusammenfassung
In diesem erweiterten Tutorial zum KEA DHCP hast du gelernt, wie man den Hot-Standby Mode konfiguriert, um eine High Availability (HA) im Netzwerk zu erreichen. FreeBSD bringt an der Stelle, abweichend zur Dokumentation von KEA, eine kleine Herausforderung mit sich, da die benötigten Bibliotheken unter einem anderen Pfad abgelegt sind. Anonsten, denke ich, ist es eine wirklich einfache Möglichkeit sein Netzwerk performanter auszurichten, indem man den DHCP-Dienst hochverfügbar konfiguriert.
Set up Hot-Standby Mode with KEA DHCP on FreeBSD
The Hot-Standby mode of the KEA DHCP server is one of many ways to achieve High Availability (HA) in a network. In Hot-Standby mode, only one server is active while the others remain in standby. Although they still receive lease updates, they do not distribute them. Once the primary DHCP server fails, another server takes over and can continue to perform the task. DHCP is among the essential services in a network, and especially in large networks, an HA cluster should be implemented. In this article, I will show you how to operate two KEA DHCP servers in Hot-Standby mode.
Preparations
To set up, you need at least three VMs or hosts. Two of them serve as DHCP servers in the HA cluster, and the third host acts as the client, which will obtain a lease from the servers to test the cluster.
My servers have two network cards, one set to a network bridge, and the other set to an internal network. The client has one card set to the internal network.
The internal network for this tutorial is 10.0.0.0/24
Configuration
In my last tutorial on the KEA DHCP server, only one DHCP server was in use, essentially covering the basic concept. Now, the goal is to install and configure at least two servers. As you can imagine, almost all steps need to be repeated twice. For the second server, you need to modify the configuration, including the name and possibly the interface.
Let’s get started!
As always, first update the package repository and optionally upgrade (optional):
su pkg update && pkg upgrade -y
After that, install the KEA package:
pkg install kea
Once that’s done, you can adjust the configuration of the DHCP server. Edit the following file:
vi /usr/local/etc/kea/kea-dhcp4.conf
The goal is to have one server actively distributing leases while the other server(s) are in standby. When looking at the documentation for the Hot-Standby mode, some adjustments are necessary. For example, I don’t want to use a Relay Agent. A Relay Agent forwards DHCP requests across individual broadcast domains to reach remote networks. However, I want both servers and the HA communication to occur in the same network.
It’s also crucial to specify the correct path for libraries on FreeBSD. Instead of /usr/lib/kea/hooks/ as described in the documentation, the libraries are located under /usr/local/lib/kea/hooks/. Otherwise, you’ll encounter error messages.
For testing purposes, I’ve set max-unacked-clients to 0. This way, Server2 directly takes over the role of the active DHCP server if even one client doesn’t receive a valid lease.
Now you can further adjust the configuration of your subnet for testing.
- Server 1
- Server 2
{
"Dhcp4": {
"hooks-libraries": [{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so",
"parameters": { }
}, {
"library": "/usr/local/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [{
"this-server-name": "server1",
"mode": "hot-standby",
"heartbeat-delay": 10000,
"max-response-delay": 10000,
"max-ack-delay": 5000,
"max-unacked-clients": 0,
"peers": [{
"name": "server1",
"url": "http://10.0.0.1:8000/",
"role": "primary",
"auto-failover": true
}, {
"name": "server2",
"url": "http://10.0.0.2:8000/",
"role": "standby",
"auto-failover": true
}]
}]
}
}],
"interfaces-config": {
"interfaces": [ "em1" ]
},
"subnet4": [{
"subnet": "10.0.0.0/24",
"pools": [{
"pool": "10.0.0.10 - 10.0.0.110",
}],
"option-data": [{
"name": "routers",
"data": "10.0.0.1"
}]
}]
}
}{
"Dhcp4": {
"hooks-libraries": [{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so",
"parameters": { }
}, {
"library": "/usr/local/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [{
"this-server-name": "server2",
"mode": "hot-standby",
"heartbeat-delay": 10000,
"max-response-delay": 10000,
"max-ack-delay": 5000,
"max-unacked-clients": 0,
"peers": [{
"name": "server1",
"url": "http://10.0.0.1:8000/",
"role": "primary",
"auto-failover": true
}, {
"name": "server2",
"url": "http://10.0.0.2:8000/",
"role": "standby",
"auto-failover": true
}]
}]
}
}],
"interfaces-config": {
"interfaces": [ "em1" ]
},
"subnet4": [{
"subnet": "10.0.0.0/24",
"pools": [{
"pool": "10.0.0.10 - 10.0.0.110",
}],
"option-data": [{
"name": "routers",
"data": "10.0.0.1"
}]
}]
}
}Start and test KEA in Hot-Standby mode
To start and test your Hot-Standby configuration successfully, follow these steps. Note that the following steps should be performed on all your servers.
If you wish, enable the KEA DHCP service to start automatically after a reboot:
service kea enable
Start the service:
service kea start
If both servers start successfully, you should soon see the following messages:
2024-01-24 13:00:55.450 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'ha-heartbeat' 2024-01-24 13:00:55.456 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'dhcp-disable' 2024-01-24 13:00:55.457 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'lease4-get-page' 2024-01-24 13:00:55.458 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'ha-sync-complete-notify' 2024-01-24 13:01:04.010 INFO [kea-dhcp4.ha-hooks/1528.0x801c15f00] HA_STATE_TRANSITION server transitions from READY to HOT-STANDBY state, partner state is READY 2024-01-24 13:01:04.010 INFO [kea-dhcp4.ha-hooks/1528.0x801c15f00] HA_LEASE_UPDATES_ENABLED lease updates will be sent to the partner while in HOT-STANDBY state 2024-01-24 13:01:05.985 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'ha-heartbeat' 2024-01-24 13:01:16.492 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'ha-heartbeat' 2024-01-24 13:01:26.970 INFO [kea-dhcp4.commands/1528.0x801c16600] COMMAND_RECEIVED Received command 'ha-heartbeat'
If you start a client now, you should see the following message on the primary server:
2024-01-24 13:06:43.066 INFO [kea-dhcp4.leases/1528.0x801c15800] DHCP4_INIT_REBOOT [hwtype=1 08:00:27:c4:0f:d1], cid=[01:08:00:27:c4:0f:d1], tid=0x1d4e6eaa: client is in INIT-REBOOT state and requests address 10.0.0.10 2024-01-24 13:06:43.066 INFO [kea-dhcp4.leases/1528.0x801c15800] DHCP4_LEASE_ALLOC [hwtype=1 08:00:27:c4:0f:d1], cid=[01:08:00:27:c4:0f:d1], tid=0x1d4e6eaa: lease 10.0.0.10 has been allocated for 7200 seconds
This indicates that the client has successfully obtained the IP address 10.0.0.10.
To test the HA capability, stop Server1. The following messages are from Server2 after Server1 is no longer reachable:
2024-01-24 13:08:57.268 WARN [kea-dhcp4.ha-hooks/3276.0x837bf7f00] HA_HEARTBEAT_COMMUNICATIONS_FAILED failed to send heartbeat to server1 (http://10.0.0.1:8000/): Connection refused 2024-01-24 13:08:57.268 WARN [kea-dhcp4.ha-hooks/3276.0x837bf7f00] HA_COMMUNICATION_INTERRUPTED communication with server1 is interrupted
As expected, the heartbeat communication, which is the communication between the two servers, fails.
If you now add another client, Server2 will respond to the requests. When Server1 becomes reachable again, lease updates are exchanged, and it takes back the role as the primary DHCP server.
Summary
In this advanced tutorial on KEA DHCP, you’ve learned how to configure the Hot-Standby mode to achieve High Availability (HA) in the network. FreeBSD presents a slight challenge in this regard, deviating from KEA’s documentation, as the required libraries are stored in a different path. Nevertheless, I believe it is a straightforward way to enhance network performance by configuring the DHCP service to be highly available.
Start the discussion