This page covers the general design concepts and mechanisms of AHRI.

Cluster Design

The AHRI cluster consists of one or more Kea DHCP servers with AHRI running. All nodes in the cluster pull their host reservation updates from a read-only AdminDB server. At least one node is responsible for cleaning up processed updates from the AdminDB server according to a locally configured cleanup policy.

Node Design

A single node in an AHRI cluster consists of a Kea DHCP server with AHRI running as a hooks library as well as a local database server (“localdb”) for storing host reservations. The node has a permanent connection to a read-only AdminDB server, listening for notifications on the dhcp channel. Upon receiving a notification, the node triggers an update of its local host reservation database fetching all host reservation updates from the AdminDB server which haven't been processed yet (this is indicated by a serial number which is given to every update by the AdminDB and stored locally in the node). The incremental update mechanism then applies all updates in order, resulting in the local host reservation database converging against the actual host reservation database in the AdminDB, ultimately reaching the exact same state after all updates have been processed.

Upon startup or if failures happen, a node can run a full-sync against an AdminDB server. A full sync fetches all host reservations which are currently in the AdminDB server and makes the local host reservation database contain the exact same host reservations.

Furthermore, the node can run a consistency check, by running a full sync into a temporary host reservation table and comparing the contents of the table against the locally stored host reservation table. The consistency check returns the difference between both tables, ideally consisting of 0 entries. If, however, there is indeed an entry, this means that there were inconsistencies. The result of the consistency check is stored and (optionally) directly applied to the local host reservation database. After applying the check result, the local database must be consistent with the AdminDB. Stored results of the consistency check are made available through an API.