Using KEA DHCP Webinar part 4

This blog is a study note of using KEA DHCP webinar 04. This webinar introduced backend database and DHCP HA. For DB part, I only took very basic notes. The details of backend database can be available form the slides.

Database backend support for Kea

Kea DHCP server can store information in a database, including lease info, host address and prefixes, host options, host names and host classification. Only MySQL supports to store configurations.

The supported database are Postgres, MySQL/MariaDB, Cassandra and Redis.

The configuration example to use postgresql as DB.

"lease-database": {
    "type": "postgresql",
    "name": "kea_lease_db",
    "user": "kea",
    "password": "secure-password",
    "host": "localhost"
}

Benefits of using a database backend

• Faster turn-around for configuration changes in large deployments.
• Easy access to DHCP info from scripts.
• High-Availability through database redundancy.
• Easier to integrate into existing backup systems.

Drawbacks of using a database backend.

When issuing a lease, Kea DHCP must wait for the storage backend to acknowledge the successful storage of lease information. Some databases cannot store lease information that reaches beyond the year 2038

High Availability

The HA hook offers different operation modes.

• load-balancing: all DHCP server are active and return leases.
• hot-standby: all DHCP server are in sync but only one is active and returns leases.
• passive-backup: one DHCP server is active and send lease database updates to a number of backup servers.

Load-balancing Mode

When operating in load-balancing mode, two KEA DHCP server are active and respond to lease requests. The lease information is synced between the KEA DHCP HA servers by TCP port 649. The pool are split 50/50 between the two DHCP servers. Every DHCP server can take over the full services if needed. Via the HA protocol, a DHCP HA node will detect if one partner node is down and takes over the service.

The configuration looks like

{
"library": "/usr/lib/kea/hooks/libdhcp_ha.so", "parameters": {
    "high-availability": [{
        "this-server-name": "server1",
        "mode": "load-balancing",
        "heartbeat-delay": 10000, "max-response-delay": 40000, "max-ack-delay": 5000,
        "max-unacked-clients": 5,
        "peers": [{
            "name": "server1",
            "url": "http://192.0.2.33:8000/",
            "role": "primary", "auto-failover": true
        }, {
            "name": "server2",
            "url": "http://192.0.2.66:8000/",
            "role": "secondary", "auto-failover": true
        }, {
            "name": "server3",
            "url": "http://192.0.2.99:8000/",
            "role": "backup",
            "basic-auth-user": "foo", "basic-auth-password": "bar",
            "auto-failover": false
}] }]
}

Hot-standby Mode

A KEA DHCP cluster configured for the hot-standby mode will have the primary node serving DHCP clients and another node only receiving the lease-database updates, but not serving clients.

The configuration looks like

{
"library": "/usr/lib/kea/hooks/libdhcp_ha.so", "parameters": {
   "high-availability": [      "this-server-name": "server1",
       "mode": "hot-standby",
       "heartbeat-delay": 10000, "max-response-delay": 40000,
       "max-ack-delay": 5000,    "max-unacked-clients": 5,
       "peers": [{
           "name": "server1",
           "url": "http://192.0.2.33:8000/",
           "role": "primary", "auto-failover": true
       }, {
           "name": "server2",
           "url": "http://192.0.2.66:8000/",
           "role": "standby", "auto-failover": true
       }, {
           "name": "server3",
           "url": "http://192.0.2.99:8000/",
           "basic-auth-user": "foo",  "basic-auth-password": "bar",
           "role": "backup",  "auto-failover": false
}] }]
}

Backup Servers Mode

KEA DHCP supports an number of backup servers. They receive lease database updates but are not an active part of an HA setup. Backup server can be deployed in addition to the other KEA HA modes.

Passive-backup Mode

Only one KEA server is active and is serving lease to the clients. In case of an failure of the active server, a backup server needs to be manually promoted to be active.

Load-balancing vs. Hot-standby

The hot-standby mode is simpler. Only one active server, one active log file, and no split pools required.

However, in the load-balancing mode, the load is distributed across both active DHCP servers, with complex client classing rules. The load-balancing mode requires a 50/50 split of the pools across both HA server nodes.

HA Configurations

The KEA HA configuration parts are symmetric, all HA peers can share an almost identical configuration file. The only difference in the HA configuration is the this-server-name parameter. The HA mode is selected with mode parameter.

Depending on the mode, the server role can be defined as primary, standby or backup.

Database synchronization

The ha-sync command triggers the server to sync lease database with the selected peer

{   "command": "ha-sync",
    "service": [ "dhcp4 "],
    "arguments": {
        "server-name": "server2",
        "max-period": 60
    }
}

Retrieving the HA status

The command ha-heartbeat can be used to check the current state of a KEA DHCP server HA node. The returned JSON structure describes the current DHCP server state.

Related Links

• Using KEA DHCP Webinar 01
• Using KEA DHCP Webinar 02
• Using KEA DHCP Webinar 03
• Using KEA DHCP Webinar 04
• Using KEA DHCP Webinar 05

• ← Previous Post
• Next Post →