2025.10.28 プラットフォーム

Kea DHCP Serverとは？インストール・設定・Control Agent(kea-ctrl-agent)・HA構成まで解説

Kea DHCP Server（読み方は「キア」）は、ISC（Internet Systems Consortium）が開発を続けるDHCPv4/DHCPv6サーバーです。開発を終了したISC DHCP（dhcpd）の後継として設計され、JSON形式の設定ファイル、サーバーを止めずに設定を変更できるREST API、データベース連携、Hot-StandbyによるHA（高可用性）構成を備えています。この記事では、Keaとは何かという基礎から、Ubuntu/CentOSでのインストール、設定ファイルの書き方、REST APIを担うControl Agent（kea-ctrl-agent）、HA構成、StorkとGrafanaによる監視までを、設定例つきでまとめます。

まとめ：Kea DHCP Serverの要点

Kea DHCP Serverは、開発を終了したISC DHCP（dhcpd）の後継となるDHCPサーバーです。要点は次のとおりです。

  • 位置づけ：ISC DHCP（dhcpd）の後継。DHCPv4/DHCPv6を単一プラットフォームで提供し、マルチスレッド処理で数万規模のクライアントにも対応する。
  • 設定と操作：設定ファイルはJSON形式。Control Agent（kea-ctrl-agent）のREST APIから、サーバー再起動なしでサブネット追加や固定IP予約を反映できる。Kea 3.0以降はサーバーが直接HTTP APIを提供する方式が推奨で、Control Agentは非推奨（deprecated）だが後方互換で引き続き利用できる。
  • インストール：ISC公式のCloudsmithリポジトリを登録し、Ubuntu/Debianはapt install isc-kea、CentOS/RHELはyum install isc-keaで導入する。対応OSはLinux/UNIX系とmacOSで、Windowsネイティブ版はない。
  • 高可用性（HA）：HAフック（libdhcp_ha.so）でHot-Standby・Load-Balancing・Passive-Backupを構成でき、DHCPv6のHAにも対応する。
  • 監視：Stork AgentがKeaの統計をPrometheus形式で出力し、Stork Web UIやGrafanaでプール使用率・リース数・HA状態を可視化できる。

Kea DHCP Serverの基本概要: 多彩なプロトコル対応と主要機能および拡張機能の説明について

Kea DHCP Serverは、Keaソフトウェアの中心となるDHCPサービスです。Kea自体が複数のコンポーネントから成り立つ中でも、DHCPサーバー本体を指します。具体的には、kea-dhcp4（IPv4用）およびkea-dhcp6（IPv6用）という2種類のプロセスが存在し、それぞれ独立して起動させることができます。また、DHCP-DDNS機能を提供するkea-dhcp-ddnsや、設定APIを提供するkea-ctrl-agentなどもあり、用途に応じて組み合わせて利用します。

DHCPプロトコルに関しては、KeaはIETF準拠のDHCPv4およびDHCPv6をサポートします。例えばIPv6では、クライアントへプレフィックスを委譲するPD機能、ルータ通知(RA)との連携なども可能です。RFCで規定された各種オプション（DNSサーバーやドメイン名、MTU等）の設定も豊富に用意されており、企業ネットワークに必要なオプションを自在に組み込めます。さらに動的DNS (RFC2136 DDNS) を実現するためのDDNSサーバーコンポーネントも統合されており、DHCPによるIP払い出しと同時にDNSの登録・更新を自動化できます。

Kea DHCP Serverの概要と対応プロトコル（DHCPv4/v6、ダイナミックDNS）

Kea DHCP Server自体は、主に2つの実行バイナリで構成されています。kea-dhcp4-serverはIPv4ネットワーク向けのDHCPサービスを、kea-dhcp6-serverはIPv6ネットワーク向けのサービスを提供します。両者は設定ファイルで分けて管理でき、IPv4とIPv6を同一ホストで個別に運用することが可能です。さらに必要に応じて、これらとは別に動作するDDNSサーバー機能を有するkea-dhcp-ddns-serverも導入できます。

対応プロトコルとして、Kea DHCPv4は従来型のIPv4 DHCPの機能をすべてカバーします。IPv6版では、IPv6アドレスの払い出しだけでなく、Prefix Delegation (PD)機能もサポートしており、ISP向けのサブネット委譲にも対応しています。加えてダイナミックDNS (RFC2136) によるDNS登録機能を実装しており、これによりDHCPとDNSを連携した運用が可能です。たとえば新規のDHCPリースが発行されると、対応するDNSゾーンにA/AAAAレコードが自動登録されます。

Kea DHCPv4サーバーとKea DHCPv6サーバーの違い

KeaではDHCPv4とDHCPv6が別プロセスで動作する設計となっていますが、基本的な設定項目の構造や機能は共通化されています。例えば、どちらのサーバーもinterfaces-configでリッスンするインターフェースを指定し、subnet4やsubnet6でサブネット・プールを定義します。ただし、IPv6版固有の機能としては、Prefix Delegation用のpool設定や、DHCPv6オプション（DNS Recursive Name Server、Domain Search Listなど）があります。

なお、設定ファイルはそれぞれkea-dhcp4.confとkea-dhcp6.confという別ファイルに分かれます。操作方法としては両者でほぼ同一ですが、起動コマンドは別々になります。Keaのサービス名も、バージョンやディストリビューションによっては異なる場合がありますが、メタパッケージisc-keaを利用すれば必要なすべてのバイナリがインストールされ、それぞれisc-kea-dhcp4-server、isc-kea-dhcp6-server等の実行環境が整います。

Kea Control AgentによるREST APIを使ったリモート管理機能の設定例

KeaのControl Agent (kea-ctrl-agent) は、Keaサーバーの設定を外部から変更・監視するためのRESTful APIを提供します。これにより、専用の管理ツールやカスタムスクリプトからHTTPリクエストでKea設定を更新でき、設定変更の自動化や他システム連携が可能になります。例えばサブネット追加や固定IP予約の追加を、サーバ再起動なしで実行できます。

Control Agentの有効化は設定ファイルkea-ctrl-agent.confで行い、APIポートやTLS設定を指定します。起動後は/config, /statistics, /leasesなどのエンドポイントを通じて、Keaサーバーのデータを取得・更新できます。多くのケースでKeaサーバーとは別の管理用ホストにControl Agentを置くか、同一ホスト内で別ポートで待ち受けさせる構成を採用します。これによりCI/CD連携や自動化ツールからKea設定をAPI経由で操作できます。

Keaのデータベース連携機能: MySQL/PostgreSQL保存の利点

Keaはリース情報を内部メモリファイル(CSV)だけでなく、MySQLやPostgreSQLに保存する機能を持っています。設定ファイルのlease-databaseセクションでデータベースの種類を選べば、自動的にそのDBへリース情報が書き込まれます。この仕組みを利用すると、大量のリース情報を効率的に検索・参照できるほか、他システム（例えばIPAMシステム）からもSQLクエリでリースデータを容易に参照できます。

具体的には、postgresqlやmysqlの設定を行い、ホスト名・ユーザー名・パスワードを指定することでKeaがDBに接続します。データベースに保存されたリースは、kea-admin lease-dumpコマンドや独自のアプリケーションで簡単に抽出・分析できます。ISP規模での運用では、このDB連携による可視化やバックアップのしやすさが大きなメリットです。

Kea Hooksライブラリの仕組みと利用可能なフック一覧

Keaでは「Hooks」というプラグイン機構により、動作中に任意の処理を挿入できます。フックはイベント駆動型で、例えばDHCP DiscoverやRequest時、リース発行時などに独自コードを呼び出せます。OSSとして提供されているフックライブラリには、BOOTP対応、IP割り当て制御、統計取得、REST API拡張などがあります。組み込みは設定ファイルにフックライブラリのパスを指定するだけで簡単です。

また、KeaのHA機能もかつては有償フックでしたが、現在はオープンソースのフックとして提供されています。これにより、HA設定なしでフェイルオーバー構成が組めるようになりました。さらに有償サポート向けのフック（Flex-IDやGSS-TSIG連携など）もありますが、基本機能を使う分にはOSSフックのみで充足するケースが多いです。いずれもhooks-librariesセクションで有効化し、ライブラリ名とフック名を指定して利用します。

ISC DHCPとの違い: 設定方式・可用性・サポート体制など主要な比較ポイント

ISC DHCP（dhcpd）は長年Linuxディストリビューションに搭載されていた標準DHCPサーバーですが、2022年にサポート終了が予定されています。Keaはこの後継として設計されており、複数の面で大きく異なります。まず設定ファイルですが、ISC DHCPはテキスト形式のグループファイル（dhcpd.conf）、KeaはJSON形式を採用しています。KeaのJSONは厳密に構造化されており、自動生成やプログラムによる操作が容易です。

また、設定の反映方法も異なります。ISC DHCPでは設定変更時にサーバを再起動・リロードする必要がありますが、KeaではControl Agent APIや構成ファイルの変更をサーバに通知することで、サービスを止めずに設定更新できます（サービスの再起動なしでオンライン設定可能）。これにより大規模環境でも計画停電なしで設定変更が行えます。

設定方式の違い: ISC DHCPd（dhcpd.conf）とKea（JSON）の比較

ISC DHCPdの設定は従来型のキーワードベースで記述するテキストファイル（例: subnet 10.0.0.0 netmask 255.255.255.0 { … }）でした。一方でKeaはJSON形式です。JSON形式では{ }でセクションを括り、”subnet4″や”pools”などをキーにします。階層が明確でパーサーによる読み書きがしやすいのが特徴です。JSON形式は構文チェックも自動的に行われ、ミスを防ぎやすい利点があります。

加えて、Keaでは複数ファイルに設定を分割してincludeディレクトリから読み込む構造も可能です。これにより、大規模な設定をモジュール化して管理しやすくなります。ISC DHCPdの場合はinclude機能が限定的であったため、Keaの方が柔軟な構成管理が可能です。

設定変更時の動作: Keaはリアルタイム反映、ISC DHCPは再起動が必要

ISC DHCPdで設定を変更する場合、dhcpd.confを更新した後にサーバーの再起動またはリロードを行う必要があります。この間DHCPサービスが一時停止する可能性があります。一方、KeaではControl Agent API経由で変更を送ると即時反映が可能で、さらにJSON設定ファイル自体を動的にリロードする機構も備えています。つまり、無停止で設定を更新できる点が大きな違いです。

具体的には、例えばサブネットを追加したい場合、KeaではREST APIに新サブネットをPOSTするだけで即座に適用されます。対してISCではdhcpd.confに追加し、再起動して新設定を読み込ませる必要があります。サービス停止を伴わないKeas側の動的設定は、ISPなど常にDHCP提供が必要な環境で大きなメリットになります。

高可用性機能の違い: ISC DHCPのフェイルオーバー vs KeaのHAフック

ISC DHCPdには、RFCベースのフェイルオーバープロトコル（ロードバランシングモード）があります。これは両方のサーバーが並行して稼働し、互いにリース情報を共有していました。Keaではこの仕組みとは異なり、「Hot-Standby」や「Load-Balancing」「Passive-Backup」など複数のHAモードを提供します。Hot-Standbyではプライマリだけがクライアントに応答し、障害時にスタンバイが引き継ぎます。

またKeaではDHCPv6にもHAサポートがある点も違いです。ISC DHCPdはDHCPv6フェイルオーバーに対応していませんでした。Kea HAフックは成熟した設計で、障害復旧時の同期や整合性も自動で行われます。要するに、KeaのHAはISCに比べて信頼性が高く柔軟であると言えます。

対応プロトコルとサポート: KeaのIPv6対応 vs ISC DHCPのサポート終了

KeaはIPv6にフル対応しており、IPv4/IPv6両方のDHCPサーバーを単一プラットフォームで提供します。ISC DHCPdもIPv6対応でしたが、開発終了に伴いその先行きは不透明です。特に2022年以降はセキュリティ対応の更新も不明瞭となっており、長期的な利用には不安があります。

一方、Keaは現在もISCが積極的に開発を継続しており、新機能やバグ修正がアップデートされています。最新バージョンではDHCPv6の仕様拡張にも追随しており、IPv4/IPv6どちらの先行きも保証されています。このため新規構築やアップグレードを検討する際に、Keaは安心して選択できるDHCPサーバーです。

性能とスケーラビリティの比較: 大規模環境での動作の差異

Keaは名前の通り高性能を意識して開発されており、マルチスレッド処理に対応しています。複数CPUを活用できるため、数万クライアント規模の環境でも高いスループットを確保できます。ISC DHCPdもシングルプロセスで安定していましたが、マルチスレッド化はなされていませんでした。

また、Keaではデータベース連携によるリース管理で巨大なリース情報にもスケールできる点も特徴です。さらに経過ログや統計データも豊富に出力できるため、大規模ネットワークのモニタリング用途にも適しています。結果的に、数千ユーザー以上の環境やプロバイダ向けネットワークではKeaが優れた性能を発揮します。

Keaのインストール方法: クラウドスミスリポジトリと手動ビルドによる導入手順（Ubuntu/CentOS対応）

Keaは主要なLinuxディストリビューション向けに公式パッケージが提供されており、簡単に導入できます。ISCのCloudsmithリポジトリを登録しておけば、aptやyum（dnf）コマンドでパッケージをインストールできます。たとえばDebian/Ubuntuでは apt update && apt install isc-kea、CentOS/RHELでは yum install isc-kea とするだけで、Keaの各コンポーネントがまとめて導入されます。

個別にインストールする場合は、isc-kea-dhcp4-server（DHCPv4）、isc-kea-dhcp6-server（DHCPv6）、isc-kea-ctrl-agent などのパッケージがあり、必要に応じて選択できます。また、最新バージョンを使いたい場合はCloudsmithの手順に従いリポジトリを追加します。公式リポジトリが使えない環境ではソースからビルドする方法もありますが、通常はパッケージインストールで十分です。

Keaパッケージリポジトリの設定: ISC公式Cloudsmith登録方法

ISCはCloudsmithプラットフォームにKeaの公式リポジトリを設置しています。まずCloudsmith上で自分のディストリビューションに対応するKeaリポジトリを「Set Me Up」ボタンから選択し、表示された手順に従ってリポジトリ設定ファイルを登録します。これによりaptやyumからKeaパッケージを取得可能になります。クラウドスミスのリポジトリを使うと、Keaの安定版リリースがリポジトリに追加され、継続的なアップデートが容易になります。

具体的には、Debian/Ubuntu系ではリポジトリ用の.listファイルを/etc/apt/sources.list.d/に配置し、GPGキーを登録します。CentOS/RHEL系では.repoファイルを/etc/yum.repos.d/に配置します。いずれも公式サイトで手順が案内されているので参照しながら作業すれば確実です。なおパッケージ名が変更された履歴（2.3.2以前）もあるため、導入時には最新のパッケージ名を確認しましょう。

Debian/UbuntuでのKeaパッケージインストール手順

UbuntuやDebianでは、isc-keaメタパッケージをインストールするのが簡便です。例えばUbuntuであれば以下のように実行します：
sudo apt update
sudo apt install isc-kea
これによりisc-kea-dhcp4-serverやisc-kea-ctrl-agent、isc-kea-hooksなど必要なパッケージが一括で導入されます。個別にインストールする場合はisc-kea-dhcp4-serverなどのパッケージ名で指定します。

注意点として、Debian/Ubuntuではsystemdのサービス名がisc-kea-dhcp4-server.serviceのようにプレフィックス付きになっています。サービス起動時にはsudo systemctl start isc-kea-dhcp4-serverのように、完全な名前を使って操作します。また、初回起動前に設定ファイル（/etc/kea/kea-dhcp4.confなど）のテンプレートを編集してサブネット情報を入力しておく必要があります。

CentOS/RHELでのKeaインストール手順とyum/dnfコマンド

CentOSやRHELの場合、ISCが用意したYUMリポジトリを設定後、yumまたはdnfでインストールします。CentOS Streamでは以下のように実行できます：
sudo yum install isc-kea
（またはDNF）これでKea関連のサービス群がインストールされます。個別に入れる場合はisc-kea-dhcp4-serverやisc-kea-ctrl-agentを選択します。

CentOS/RHELでは、EPELなどの追加リポジトリが不要で、ISCの公式リポジトリを直接利用できます。インストール後はsystemctlでサービスを起動し、設定ファイルを配置することで運用を開始します。ログは/var/log/kea/以下に出力されるため、sudo mkdir /var/log/kea && chown _kea:_kea /var/log/keaのようにディレクトリを準備しておくと良いでしょう。

ソースコードからのKeaビルド方法: 依存ライブラリとconfigureオプション

公式パッケージが使用できない環境や最新版を自分でビルドしたい場合、ソースからKeaをビルドできます。必要なライブラリはC++ビルドツール（gcc/g++、CMakeなど）に加え、オプションでMySQLやPostgreSQLを使う場合はそれぞれの開発用ライブラリ（mysql_config, pg_config）が必要です。GitHubからソースをクローンし、CMakeでビルドディレクトリを作ってコンパイルします。

典型的な手順は以下の通りです：
git clone https://github.com/isc-projects/kea.git cd kea mkdir build && cd build cmake .. -DENABLE_LINUX_CAPABILITIES=YES make sudo make install
この際、cmakeコマンドで-DWITH_MYSQL=yesや-DWITH_PGSQL=yesなどを指定すると、それぞれのデータベース対応が有効化されます。インストール後は設定ファイルを/etc/kea/に配置し、systemctl登録する手順が必要です。ビルド手順はKeaの管理者マニュアルに詳述されています。

インストール後の確認: kea-dhcp4/serverのバージョンとサービス起動

インストールが完了したら、まずパッケージのバージョンを確認します。kea-dhcp4 –versionやkea-dhcp6 –versionでKeaのバージョン情報が表示されれば成功です。またsystemctl status isc-kea-dhcp4-serverでサービスの状態を確認できます。ログレベルはデフォルトでINFOになっているので、起動エラーがあれば/var/log/kea/以下のログファイルを調べると原因が分かります。

さらにkea-dhcp4 –helpやkea-ctrl-agent –helpを実行し、各コマンドが動作するかテストしてください。正常に動作する場合、「Listening on interfaces」などの起動メッセージが出力されます。これでインストール後の基本的な動作確認が完了です。次は設定ファイルの作成に進み、実際の運用環境に合わせたサブネット定義などを行います。

設定ファイルの解説: KeaのJSON形式設定と主要セクションの記述方法（例付き）

Keaの設定はJSON形式で記述され、デフォルトでは/etc/kea/kea-dhcp4.confやkea-dhcp6.confに保存されます。基本的に、最上位のキーがサービス名（”Dhcp4″または”Dhcp6″）で、その中に設定項目がまとめられています。設定ファイル全体は1つの大きなJSONオブジェクトで、コメントはサポートされないため、予めコメントアウトした設定例が各パラメータと共に示されています。

設定ディレクトリにはincludeサブディレクトリを設けることもでき、includes-configセクションを使って外部ファイルを読み込ませることが可能です。これにより設定を複数ファイルに分割し、複雑な構成でも管理しやすくなります。基本的なJSON構造とキーに慣れれば、Kea設定は非常に明快になります。以下では主要なセクションの書き方を解説します。

Kea設定ファイルの基本構造と配置ディレクトリ（JSONフォーマット解説）

Keaの設定ファイルはJSON形式のテキストで、ブレース{}で囲まれた構造になっています。例としてkea-dhcp4.confの場合、最外層は{ “Dhcp4”: { … } }のようになります。”Dhcp4″キーの配下に、インターフェース設定やサブネット設定、フックやログなどの各種設定オプションを定義していきます。設定ファイルは通常/etc/kea/以下に配置されますが、ドキュメントルート外で任意の場所に置くこともできます。

設定ファイルの書き方で重要なのは、各セクションが入れ子になっている点です。例えば”Dhcp4″: { “interfaces-config”: { … }, “subnet4”: [ … ], … }のように、トップレベルの”Dhcp4″キー内に複数のセクションを定義します。それぞれのセクションはJSONオブジェクト（{ }）または配列（[ ]）で構成され、オプションやプールの設定はオブジェクト内のリスト（”option-data”など）で指定します。各キー名や構造は公式マニュアルの「Configuration File Syntax」に従います。

インターフェース設定 (interfaces-config) の書き方

インターフェース設定は”interfaces-config”セクションで行います。ここではKeaがDHCPリクエストを受け付けるネットワークインターフェースを指定します。例："interfaces-config": { "interfaces": [ "eth0", "eth1" ] } のように、”interfaces”キーにリスト形式でインターフェース名を書きます。指定したインターフェース上でKeaがリッスンするようになり、指定外のNICではDHCPパケットを無視します。

また、DHCPv6の場合はIPv6通信を扱うため、必要に応じてUDPポート設定やSocketの種類を追加できます。基本的にはIPv4/IPv6で同様の設定方式です。複数のNICでDHCPを提供する場合は、全ての必要なインターフェースを列挙してください。”interfaces”: [ “eth0”, “eth0:10” ]のように、サブインターフェースを指定することも可能です。

サブネットとプール設定 (subnet4/subnet6) の記述例

サブネット設定は”subnet4″または”subnet6″の配列で行います。各サブネットはオブジェクト形式で定義し、”subnet”と”netmask” (またはIPv6の場合は”address”/”prefix-length”)でネットワークアドレスを指定します。例：{ "id":1, "subnet": "192.168.1.0/24", "pools": [ { "pool": "192.168.1.100 - 192.168.1.150" } ], "option-data": [ { "name": "routers", "data": "192.168.1.1" } ] } のように書きます。

プール設定(“pools”)では使用可能なアドレス範囲を指定し、オプション(“option-data”)ではDNSサーバーやドメイン、ゲートウェイなどを定義します。IPv6の場合も同様に、サブネットに「払い出すアドレス範囲」を指定し、必要に応じてIPv6オプション(例：”domain-search”,”dns-recursive-name-servers”)を設定します。複数サブネットを設定する場合は各ネットワークごとにオブジェクトを追加します。

固定IPアドレス割り当ての設定 (reservations/host-reservations)

ホスト予約（固定IP割当）は通常”reservations”セクションで行います。各予約エントリにユニークID、MACアドレス、および割当希望IPを指定します。例：{ "hw-address": "00:11:22:33:44:55", "ip-address": "192.168.1.10", "hostname": "printer01" } のように、”hw-address”にMAC、”ip-address”に割当IPを設定できます。IPv6では同様にDUIDやIAIDを使った予約設定も可能です。

別の方法として、データベース連携を活用するケースも多いです。”reservations-database”セクションでMySQL/PostgreSQLを指定すると、テーブルから固定IPエントリを読み込んで適用できます。これにより、ホスト情報をデータベースで一元管理し、新規ホスト追加時はデータベースに登録するだけでKea側で有効になります。いずれも定義後はサーバーに適用してDHCP要求時に固定IPが割り当てられます。

フックとログ設定: Hooksライブラリ指定とログ記録の設定

フック設定は”hook-libraries”セクションで行います。利用したいフックライブラリ（.soまたは.dllファイル）を列挙し、必要なフックを有効化します。例："hook-libraries": [ { "library": "libdhcp_lease_cmds.so" } ] と指定すると、そのライブラリが起動時にロードされます。ロードされたフックは様々な処理（パケットログ、API連携など）を行います。個別にフックのパラメータをJSONで指定することも可能です。

ログ設定は”loggers”セクションで行い、出力ファイルやログレベルを設定します。デフォルトでは/var/log/kea/kea-dhcp4.logなどにINFOレベルで出力されます。例："loggers": [ { "name": "kea-dhcp4", "severity": "INFO", "output_options": [ { "output": "/var/log/kea/kea-dhcp4.log" } ] } ]。ログファイルのパスやフォーマットを変更したり、複数ファイルに出力したりもできます。ログはトラブルシューティングや統計収集に有用です。

基本的な設定例: IPv4/IPv6対応サブネット設定と主要オプション・ホスト固定設定（サンプル付き）

ここではKeaの設定例を示します。まずIPv4環境の例です。以下は単一サブネットでアドレスプールを指定した基本設定です：
{ "Dhcp4": { "interfaces-config": { "interfaces": [ "eth0" ] }, "subnet4": [ { "id": 1, "subnet": "10.0.0.0/24", "pools": [ { "pool": "10.0.0.100 - 10.0.0.200" } ], "option-data": [ { "name": "routers", "data": "10.0.0.1" }, { "name": "domain-name-servers", "data": "10.0.0.5,10.0.0.6" } ] } ] } }

この例では、10.0.0.0/24ネットワークに対し.100～.200をプールとして割り当て、ルータとDNSサーバーのオプションを設定しています。このように、”pools”でプールレンジ、”option-data”でDHCPオプションを指定できます。

IPv4 DHCP基本設定例: 単一サブネットとIPプール指定の例

上記のJSONは実際に/etc/kea/kea-dhcp4.confに設定します。これを保存後、Keaサービスを起動することでクライアントにIPを配布開始します。設定例ではルータ(10.0.0.1)とDNSサーバー(10.0.0.5,10.0.0.6)を指定しており、クライアントはこれらを利用してネットワークに接続します。サブネットIDは任意の整数で、内部管理用に使われます。複数サブネットがある場合は、同様のオブジェクトを”subnet4″配列に追加します。

IPv6 DHCP基本設定例: IPv6プレフィックス委譲(PD)の構成例

IPv6の基本設定例として、/64プレフィックスを委譲する環境を考えます。kea-dhcp6.confでは次のように設定します：
{ "Dhcp6": { "interfaces-config": { "interfaces": [ "eth0" ] }, "prefixes": [ { "id": 1, "prefix": "2001:db8:abcd:1000::/56", "delegated-prefix-length": 64 } ], "pools": [ { "pool": "2001:db8:abcd:2000::/64" } ] } }

この例では、2001:db8:abcd:1000::/56のレンジから/64プレフィックスを委譲します。”prefixes”で管理可能なプレフィックスを定義し、”pools”で個々の/64範囲を指定します。Keaはクライアント要求に応じて自動的に/64アドレスを割り振ります。またIPv6ではオプション形式が異なるものもあるため、必要に応じて”option-data”にIPv6オプション名（例: domain-search）を指定します。

ホスト予約(固定IP)設定例: MACアドレスによる割り当て

特定ホストに固定IPを払い出したい場合、”reservations”セクションを使います。例：
{ "Dhcp4": { "reservations": [ { "hw-address": "00:11:22:33:44:55", "ip-address": "10.0.0.50", "hostname": "host01" } ] } }

この設定では、MACアドレス00:11:22:33:44:55のクライアントには常に10.0.0.50を割り当てます。”hostname”を指定すると、DNS DDNSを使った場合にFQDNが登録されます。同様にIPv6ではDUIDベースの予約が可能です。データベース連携を使用する場合は、これらの情報をDBテーブルに保存してKeaに参照させることもできます。

PXEブート設定例: DHCPオプションとブートファイル指定

PXEクライアントがネットワークブートする場合、DHCPオプションでTFTPサーバの情報とブートファイル名を通知する必要があります。Keaでは”option-data”で上書きまたは追加します。例としてIPv4設定中に以下のオプションを追加：
{ "name": "boot-file-name", "data": "pxelinux.0" }, { "name": "next-server", "data": "192.168.1.100" }
これによりクライアントはTFTPサーバ(192.168.1.100)からpxelinux.0を取得して起動します。IPv6版でも同様のPXEオプションがあります（例: option 211など）。Keaのオプション名はIANAに準拠しており、既定で主要なPXEオプションがサポートされています。

ダイナミックDNS (DDNS) 設定例: ホスト名登録の設定

DDNSを有効にするには、kea-dhcp4.confでDDNSサービスを指定します。以下のようにDDNS設定セクションを追加します：
{ "Dhcp4": { "ddns-send-updates": true, "ddns-ddns-domain": "example.com", "ddns-override-no-update": true } }

この設定でKeaはリース割当時にDHCP-DDNSエージェントに更新依頼を送り、ホスト名をDNSサーバーに登録します。クライアントが送るFQDN情報を優先する場合や、静的ホスト名を使う場合などオプションは細かく制御可能です。一般的には社内LAN環境でホスト名管理を容易にするために利用されます。

DHCPリース管理: リース情報の保存先と固定アドレス管理・統計/監視方法（データベース連携）

KeaではDHCPリース情報の保存先を柔軟に選べます。デフォルトはメモリ上のCSVファイル（kea-leases4.csvなど）ですが、データベース（MySQL/PostgreSQL）も選択可能です。設定ファイルの”lease-database”セクションでバックエンドを指定すると、すべてのリースデータがテーブルに格納されます。大規模環境ではデータベース保存を採用するケースが多く、複数サーバー間での共有や分析が容易です。

リース管理では、期限切れリースの処理設定も重要です。”expired-leases-processing”セクションでreclaim-timer-wait-timeやmax-reclaim-leasesなどを調整できます。これにより期限切れアドレスの再利用タイミングを制御可能です。また、”stats-leases-client-classification” などの統計設定で、クライアント種別ごとの利用状況が収集できます。運用に合わせてこれらのパラメータを調整し、リース枯渇やリークを防ぎます。

リースデータ保存の選択肢: CSVファイル vs MySQL/PostgreSQL

Keaのリース情報はデフォルトではCSVファイルに保存されます。例えばIPv4なら/var/lib/kea/kea-leases4.csvにテキスト形式でリース履歴が記録されます。CSVは設定が簡単ですが、検索性は限定的です。一方でDB保存を選ぶと、リース情報がSQLテーブルに格納され、SELECTクエリで過去のリース履歴を自在に参照できるようになります。

設定例として、PostgreSQL保存を使う場合、kea-dhcp4.confに以下を追加します：
{ "lease-database": { "type": "postgresql", "host": "localhost", "name": "keadb", "user": "keauser", "password": "keapass" } }
これによりKeaは新規リースをPostgreSQLに保存します。MySQLでも同様に”mysql”タイプに設定できます。DB保存は信頼性と可用性が向上し、管理ツールと連携しやすいため推奨される方式です。

リース情報の確認方法: ファイル閲覧とSQLクエリ

CSV保存時は、リースファイルを直接テキスト閲覧します。cat /var/lib/kea/kea-leases4.csvでIP, MAC,状態などが一覧表示されます。PostgreSQLの場合はデータベースに接続してSELECT * FROM leases4;などのクエリで同様の情報を取得できます。Keaには管理コマンドkea-lease4-dump（または5以降ではkea-admin lease-dump4）もあり、リース情報を標準出力にJSON形式で出力する機能があります。これを使えばプログラムから容易にリース情報を利用できます。

どちらの方法でもアクティブなリースだけでなく、古いリースの履歴も得られます。DBの場合は必要に応じてクライアントID、MAC、サブネットIDなどで検索できるため、特定のホストが過去にどのアドレスを割り当てられたか調査することが容易です。

リース期限切れ処理: reclaimedパラメータとリースフラッシュ

リース期限管理では”expired-leases-processing”セクションにパラメータがあります。たとえば”reclaim-timer-wait-time”は期限切れ後どれだけ待ってからアドレスを再利用可能にするか秒数で指定し、”flush-reclaimed-timer-wait-time”は再利用開始後に再度チェックを行うタイミングです。デフォルト値でも動作しますが、大規模環境ではmax-reclaim-leasesなどの値調整でパフォーマンスを最適化することがあります。

また”hold-reclaimed-time”を設定すると、期限切れになってからしばらくはアドレスを保留状態にできます。これらの設定により、一時的なリース切れ増加に対して安全マージンを持たせたり、急に大量解放された場合の負荷を分散できます。運用状況に応じてこれらのパラメータをチューニングすると、より安定したIP管理が可能になります。

リース統計とログ: keactrl 統計コマンドやKeashell活用

Keaには統計情報を収集する機能があり、リアルタイムや累積のリース統計を出力できます。kea-ctrl-agentのREST APIに/statisticsエンドポイントや、CLIツールkeactrl5 show statistics（新バージョン）を使うと、サブネットごとの割当数やクライアント数、リース要求数などを取得できます。これらはモニタリングやレポート作成に利用できます。

ログファイルにも情報は豊富に出ており、/var/log/kea/kea-dhcp4.log（例）にはリースの割当イベントがINFOレベルで記録されます。必要に応じてログレベルをDEBUGに上げると、より詳細なリース動作を追跡できます。定期的にこれらの統計とログをチェックすることで、リースプールの使用状況や異常なリクエストの検出が可能になります。

固定IP割当(Reservation)の管理: ホスト予約とDB同期設定

固定IP割り当ては、先に示した”reservations”の設定やデータベース連携で行います。データベース連携を利用する場合、”reservations-database”セクションでDB接続情報を指定し、ホストのMACとIPをテーブルで管理します。この場合、Keaを再起動することなくDB内のエントリを更新するだけでホスト予約を反映できる利点があります。

運用では、新しいホストがネットワークに接続した際に自動でDBへ登録する仕組み（例えば管理スクリプトやUI）を用意することが多いです。これにより長期的なIP資源管理が簡単になります。固定IP管理のルールを明確にし、DBを活用すれば大規模環境でも効率的なIP管理が行えます。

High Availability（HA）構成: KeaのHAフックを利用した冗長DHCPサーバー構築手順（例: Hot-Standby構成）

KeaのHA（高可用性）構成は、専用のHooksライブラリ(libdhcp_ha.so)を使って実現します。最も一般的なのがホットスタンバイモード（Hot-Standby）です。これは2台のKeaサーバーをペアにし、一方をプライマリ（Active）、もう一方をスタンバイとします。通常はプライマリだけがDHCPリクエストに応答し、スタンバイはパケットを監視して待機します。プライマリからリース情報を逐次スタンバイに送信し、データベースやファイルを同期する仕組みです。

HA構成では設定ファイルに”ha”セクションを追加します。例ではIPアドレスやポート、パートナーサーバー名を指定して、両者の役割と通信方式(UDP/TCP)を定義します。設定後、プライマリを起動してからスタンバイを起動すれば、冗長化構成が有効になります。Kea HAモードでは、プライマリに障害が発生するとスタンバイが自動でアクティブ化し、サービスが継続されます。

Kea HAフックの基本概念: Hot-Standbyとその他モードの違い

Kea HAフックにはいくつかのモードがあります。Hot-Standbyモードでは、1台が常時アクティブで、もう1台が待機状態になります。負荷分散モード(Load-Balancing)では、プールを半分ずつ分担して両者が並行稼働し、相互に同期します。Passive-Backupモードは、待機サーバーがクライアント要求を見ているだけで、自動切替なしに手動で切替える形式です。

Hot-Standbyは手軽で強力な方式です。スタンバイサーバーは通常はDHCP応答を返しませんが、プライマリが応答しなくなると自動で応答するようになります。ロスレスな状態移行を目指しており、最大の閾値(max-unacked-clients)を超えるリクエスト遅延が発生するとスタンバイ側がアクティブになります。

Hot-Standbyモード構成例: プライマリ/スタンバイサーバーの設定

Hot-Standbyでは、例えば以下のような設定例が考えられます。プライマリ側kea-dhcp4.confに
{ "Dhcp4": { "interfaces-config": { "interfaces": [ "eth0" ] }, "subnet4": [ ... ], "ha": { "mode": "hot-standby", "primary": true, "name": "Kea1", "control-socket": { "address": "127.0.0.1", "port": 8001 }, "socket": { "address": "10.0.0.1", "port": 8000 }, "heartbeat-delay": 5, "max-unacked-clients": 3 } } }

スタンバイ側では”primary”: falseとし、”name”: “Kea2″のようにして異なる名前にします。重要なのは、”interfaces-config”やサブネット定義を両者で一致させることです。これにより、Kea1が応答しない場合にKea2がプール全域を引き継いで動作します。HA構成ではポート番号やIPの設定に注意し、ファイアウォールでHAポート(デフォルト8000/8001)を開放しておく必要があります。

Load-Balancingモード構成例: プール分割とHAクラス設定

Load-Balancingモードでは、アドレスプールを均等に分割し、各Keaサーバーが別々に一部のクライアントに応答します。設定例として”ha”: { “mode”: “load-balancing”, “name”: “Kea1”, “another-params”: … }とし、プールを50/50に分けます。両者とも”primary”: trueのように設定し、プライマリ/スタンバイを明示しません。

この場合、各サブネットのプールを手動で分割設定し、”ha-virtual-routers”やクラス(Class)でトラフィックを制御する必要があります。ロードバランシングは設定が複雑で、適切にクライアントのトークンを振り分ける設計が求められます。ホットスタンバイと異なり、両者が並行動作するためリースの公平分散が可能ですが、設定ミスすると一方のサーバーに負荷が偏りがちになります。

HA構成の動作: フェイルオーバー時のクライアント応答

HA構成では、フェイルオーバーが発生するとスタンバイサーバーがアクティブ化します。ホットスタンバイの場合、プライマリが応答しなくなるとスタンバイがリースデータを同期した上で即座にリクエストを処理し始めます。プライマリが復旧すると、スタンバイからプライマリへリース同期を返してプライマリが再びアクティブに戻ります。

これにより、クライアントからはほとんどサービス断を感じさせずに継続してDHCPが利用できます。設定パラメータ（例：heartbeat-delay, max-ack-delay）を調整すると、切り替えまでのタイミングを制御できます。ISC DHCPdと異なり、Kea HAは同期の信頼性が高く、切り替え中のロスが少ない点が評価されています。

HA構成の検証: keactrlステータス情報と動作確認方法

HA構成時は、keactrlコマンドやControl Agentのエンドポイントで状態を確認します。例えば、keactrl5 –control-socket 127.0.0.1:8001 ha-reloadで設定を反映したり、haステータスを問い合わせたりできます。ステータスでは”PARTNER_UP”や”PARTNER_DOWN”、”SERVER_ID”等のHA状態が表示されます。

また、サービス開始後にsystemctl status isc-kea-dhcp4-serverでエラーログが出ていないか確認し、両サーバー間でリース情報が同期されているかを実際にクライアントに接続させるなどして検証します。スタンバイサーバーを先に起動すると警告が出るため、必ずプライマリを先に起動しましょう。監視下では、HAの挙動を定期的にテストして動作を検証しておくことが推奨されます。

スタートアップ＆サービス設定: Keaサービスの自動起動と管理方法（systemd環境での設定例）

Keaサービスはsystemdで管理できます。インストール後に、systemctl enableコマンドで自動起動設定を行います。Debian/Ubuntuでは次のように実行します：
sudo systemctl enable isc-kea-dhcp4-server
sudo systemctl enable isc-kea-ctrl-agent
これにより、システム起動時にKeaのサービスが自動的に立ち上がるようになります。CentOS/RHELでも同様に、インストール後に各サービスをsystemctl enableします。

サービス名には注意が必要です。古い名前がisc-kea-dhcp4-serverのようになっており、systemdエイリアスによって短い名前（kea-dhcp4）で扱えるようになっていますが、実際にenableやstartする際は正式名称を指定します。またsystemdのジャーナルにkea-dhcp4といった出力が出るため、journalctl -u isc-kea-dhcp4-serverでログを参照できます。

Keaサービスの登録と自動起動設定 (systemctl enable)

インストール後、Keaの各サービスをsystemdに登録して自動起動するには次のコマンドを実行します：sudo systemctl enable isc-kea-dhcp4-server isc-kea-dhcp6-server isc-kea-ctrl-agent。これで次回以降のブート時に自動的にKeaが起動するようになります。不要なサービスはdisableで外せます。設定後はsystemctl statusで有効になっていることを確認してください。

各サービス起動時は/etc/systemd/system以下にリンクが作成されます。起動後はsystemctl status isc-kea-dhcp4-serverで実行状態を確認し、Active: active (running)と表示されていれば正常です。また自動起動がONか確認するにはsystemctl is-enabled isc-kea-dhcp4-serverを使います。

Debian/Ubuntuのサービス名: 古いパッケージ名とエイリアス対応

Debian/Ubuntuでは、Keaのサービス名がisc-kea-dhcp4-serverなどになっている点に注意が必要です。これは以前のパッケージ名との互換性を保つためです。同等に、kea-dhcp4など短い名前もエイリアスとして使えますが、enableやstartコマンドでは正式名称を指定しましょう。例えばUbuntuでは次のいずれかで操作できます：systemctl enable isc-kea-dhcp4-serverまたはsystemctl enable kea-dhcp4（ただし後者はエイリアス扱いです）。

CentOS/RHELではパッケージ名にisc-が付かないことが多いですが、使い慣れたdistrosではsystemctl list-units | grep keaで実際のサービス名を確認できます。一度サービス名を認識すれば、以降はstart/stop操作が可能になります。

サービスの起動/停止/再起動方法 (systemctlコマンド例)

Keaサービスの起動や停止はsystemdコマンドで行います。代表例を以下に示します：
sudo systemctl start isc-kea-dhcp4-server
sudo systemctl stop isc-kea-dhcp4-server
sudo systemctl restart isc-kea-dhcp4-server
再起動すれば設定ファイルの変更が反映されます（Keaでは一部リアルタイム更新可）。statusで動作中のログも確認できます。複数のサービスを同時に操作するには、kea-dhcp6-serverやkea-ctrl-agentも同様に実行してください。

エラーが起こった場合は、journalctl -u isc-kea-dhcp4-server –no-pagerで詳細ログを確認できます。よくあるトラブルとしては設定ファイルのJSON構文エラーや、インターフェース指定ミスがあります。ログから原因を特定し、設定を修正して再起動します。systemdに依存するため、正常起動後もStatus表示やログを定期的にチェックする習慣をつけておくと安心です。

Keaサービス動作確認: statusとログファイルの確認

サービス起動後はsystemctl statusコマンドで「active (running)」になっているか確認します。Keaのログは通常/var/log/kea/下に格納されます。例えば/var/log/kea/kea-dhcp4.logをtail -fで見ると、起動直後に「listening on interfaces」などのメッセージが出力されます。ログレベルを上げておくと、クライアントへの割当状況など詳細な動作記録も得られます。

またkea-leases4.csvファイルが正常に作成されているかも確認します。リースの払い出しを受けたらこのCSVに記録されるので、ls -l /var/lib/kea/kea-leases4.csvで存在を確認し、内容をcatなどで中身を確認してみましょう。これらの確認作業で、サービスが想定通り動いているか検証できます。

ログ管理とローテーション: Keaログファイルの保存場所

Keaのログは標準では/var/log/kea/以下に出力されます（例: kea-dhcp4.log）。ログローテートはシステム側で対応する必要があります。Debian系では/etc/logrotate.d/isc-keaの設定がパッケージに含まれている場合があります。ログが溜まりすぎないよう、日付やファイルサイズでローテーションする設定を追加しましょう。

例えば、1週間ごとまたは100MBごとにローテートし、7世代分を保存する設定が推奨されます。古いログは圧縮して保存することでディスク使用量を抑えられます。また、障害時の調査用にログを長期保存しておく場合は、専用ログサーバーへの転送設定も検討するとよいでしょう。

Stork/Grafanaによる監視: Keaを可視化するStorkエージェントとGrafana監視環境の設定例

StorkはISCが開発したKea管理用ツールで、Keaサーバー上で動作するエージェントです。Stork AgentはKeaと統合され、DHCPメトリクスをPrometheus形式でエクスポートします。これをGrafanaで可視化することで、複数Keaサーバーのステータスやリース統計を一元管理できます。StorkにはWeb UIもあり、サーバー一覧やプール利用率、HA状況などグラフィカルに表示します。

StorkのセットアップはまずKeaサーバーにStork Agentをインストールし、Keaの設定ファイルにエージェントセクションを追加します。起動後、Prometheusからkea_api_requests_totalやpools_usedなどのメトリクスが取得できるようになります。Grafanaでは公式のKeaダッシュボードが提供されており、テンプレートをImportしてリンクすることで簡単に監視パネルを構築できます。

Storkエージェントの概要と機能: Kea管理への導入方法

Stork AgentはGo言語で書かれており、Keaサーバー上でシステムサービスとして動作します。Agentを稼働させると、Keaサーバーから収集した統計情報（リースプールの使用率、クライアント数、HAステータスなど）がPrometheus形式で出力されます。またSSHベースで各Keaサーバーに接続し、ログレベル変更やStatisticsの取得を行う機能もあります。

インストールはパッケージ（.deb/.rpm）またはバイナリを使用します。設定ファイルstorkd.confには管理対象サーバーの情報を書き込みます。導入後はStorkのWeb UI（デフォルトhttp://localhost:8080）にアクセスし、管理対象のKeaサーバーを登録します。これでブラウザ上で複数サーバーの統計を比較したり、障害を検出できるようになります。

Storkを使ったKea監視: Prometheusエクスポート設定

Stork Agentが提供するPrometheusエクスポートには、Keaの内部状態を示す多くのメトリクスがあります。具体的には「lease_count_by_pool」「subnet_uptime_seconds」「dhcp4_renew_count」などがあり、Prometheusのスクレイプ設定でStorkエージェントにアクセスします（通常HTTPポート: 8001など）。設定例：scrape_configs: - job_name: 'kea' static_configs: - targets: ['kea-server1:8001']。

スクレイプ後はPromQLで集計やアラートが作成できます。例えばプールの使用率が高くなっている場合に通知したり、ノードの心拍に異常があればアラートを設定することができます。このようにKea自体のステータスを可視化することで、問題発生前に先回りした対応が可能になります。

Grafanaダッシュボードの設定例: テンプレート活用とクエリ例

GrafanaにはKea用の公式ダッシュボードJSONテンプレートがあり、Importするだけで即時に視覚化できます。これには「Pools Usage」「Leases Allocated」「HA Status」などの複数のパネルが含まれています。例えば「pools_used{server=’kea-server1′,pool=’1′} / pools_total{…} *100」などのPromQLクエリでプール利用率を表示できます。

自前でダッシュボードを作成する場合、Prometheusで収集したメトリクス名を使ってパネルを設定します。緑や黄色の閾値をつけることで、閾値超過時に色が変わるようにし、警告状態を一目で把握できます。Grafanaのアラート機能を使ってメール通知やSlack連携させることもでき、監視体制を強化できます。

監視対象メトリクスの例: リース数、プール使用率、HAステータス

主な監視対象には、現在割り当て中のリース数（leases_used）、サブネットプールの利用率（pools_used/pools_total）、HAフラグ（ha_active, ha_standby状態）などがあります。これらのデータはStork経由でリアルタイム収集でき、Grafanaでグラフ化します。例えば「leases_requested_per_second」メトリクスで瞬間的なDHCPリクエスト量を監視することで、負荷変動を捉えられます。

また、「subnet_mean_v4_lease_time」や「subnet_mean_v6_lease_time」でリース時間の統計を監視することも有効です。これらを監視することで、思わぬ短期再起動などクライアント側の挙動異常も検知できます。定期的な確認項目として「lease_count_total」などもダッシュボードで見ておくと良いでしょう。

Stork Web GUI活用: サーバー一覧と統計情報の閲覧方法

StorkのWebインターフェースでは、管理対象に登録したKeaサーバーが一覧表示されます。それぞれのステータス（Up/Down）、アクティブサーバー数、サブネットごとの利用率などがGUI上で確認できます。例えばDHCPプールごとにバーグラフで使用率を表示したり、接続障害が起きた際には警告アイコンで通知してくれます。

またGUIでは各サーバーのシェルコマンド実行も可能です。例えば「Statistics」ボタンで統計値を呼び出したり、設定変更を適用したりすることができます。複数サーバーを連携させた場合でも、1画面で全体像を把握できるため、運用管理の効率が格段に向上します。

実際に構築してみた事例: Kea導入事例と得られた知見の紹介（ユーザー約2500規模の企業ネットワーク）

ここでは実際の導入事例を紹介します。ある企業ネットワーク（ユーザー約2500人）では、従来ISC DHCPサーバーを運用していましたが、開発終了と運用課題によりKeaへの移行を検討しました。主な課題は「固定IPアドレスの設定が煩雑」「IPアドレス残数管理ができない」「サーバ停止時間の確保が難しい」などでした。これらを解決するためKeaを導入し、無停止での設定変更やデータベース連携によるIP管理を実現しました。

導入はUbuntu 20.04 LTS環境で行われ、ISC DHCPから設定データを移行してKeaに適用しました。IPプールとホスト予約をMySQLに保存し、Kea Keeper管理ツールも併用して設定をGUI化しました。結果として、設定変更時に再起動不要になったほか、管理画面でIP利用状況が見える化され、運用管理が大幅に効率化しました。

構築事例概要: 企業ネットワークにおけるKea導入背景

この事例では、企業の内部ネットワークにおいてISC DHCPサーバーが利用されていましたが、2022年にISCがDHCPサーバーの開発終了を発表しました。加えて、既存のシステムでは固定IPの管理が手作業で煩雑になり、利用可能IPの把握も難しい状況でした。そこで、Keaを導入してこれらの問題を解決する計画を立てました。

具体的には「サーバーの無停止運用」「固定IPのDB管理」「アドレス使用率の可視化」が求められました。Keaならば、Control Agentによるオンライン設定やデータベース連携機能でこれらに対応可能であり、最新のコミュニティサポートも期待できるため採用が決まりました。

移行課題と解決策: ISC DHCPからKeaへの切り替え事例

移行にあたって、既存のISC DHCPの設定をKea形式に変換する必要がありました。サブネットやプール、ホスト予約の情報を手動でJSONに書き換えつつ、LDAPと連携していたユーザー情報はKeaのデータベースにマッピングしました。固定IP予約はデータベース化し、顧客ごとのIP配付状況を容易に更新可能にしました。

また、スクリプトを使って既存CSVからKeaのDBテーブルに一括インポートする作業を行いました。移行後はテスト環境で充分に検証し、問題なく動作することを確認。最終的に本番環境でKeaを起動したところ、クライアントへのアドレス払い出しがスムーズに行われ、移行後もネットワーク停止は発生しませんでした。

運用事例: データベース連携で実現したIP管理効率化

導入後の運用では、MySQLをリースDBとして利用しました。これにより、WebアプリケーションからIP使用状況をリアルタイムで参照できるようになりました。たとえば社内ツールからSQLクエリで「サブネット1の使用率」や「次に空くIPアドレス」を簡単に問い合わせ可能です。またホスト登録情報もデータベースで一元管理し、新規デバイス追加時はDBにレコードを追加するのみで自動反映されるようにしました。

従来手作業だった固定IPの割り当てとその追跡が自動化され、アドレス管理者の負担が大きく減少しました。さらに、定期的なレポートもPrometheus/Grafanaで自動生成し、ネットワーク部門が常に最新のIP利用状況を把握できるようになりました。

冗長構成事例: Kea HAモードを使ったフェイルオーバー運用

可用性強化のため、Keaを2台構成のホットスタンバイ冗長化を導入しました。2台のKeaサーバーを設定して片方をActive、もう片方をStandbyにし、HAフックで同期させています。ファイアウォール設定もHA用ポートを許可するように変更しました。

運用試験ではActiveサーバーを停止すると、すぐにStandbyに切り替わることを確認しました。切り替え時にはクライアントに影響はほとんどなく、サービス継続性が担保されました。これにより、メンテナンス時に片方を停止してもサービス停止が発生せず、業務への影響を最小限に抑えられています。

導入の学び: Kea運用で得られた知見と注意点まとめ

この構築で得られた知見として、まずKeaは設定変更の自由度が非常に高い反面、初期設定がJSON形式で手間になる点があります。そこで手間を軽減するために、設定ファイルはテンプレート化し管理ツールから生成する仕組みを導入しました。また、HA構成ではネットワーク設計（同期用ポートの確保）に注意が必要であることを確認しました。

全体としてKeaへの移行は成功し、サービスの継続性と管理性が向上しました。今後は、さらにStorkやGrafanaを活用して運用監視を強化し、運用自動化やトラブルシュートの高速化を図っていく予定です。この事例から、Keaは大規模・高可用環境にも耐えうる次世代DHCPサーバーとして有効であるという結論が得られました。

よくある質問（FAQ）

Kea（DHCP）の読み方は？

「キア」と読みます（英語圏の発音は “KEE-ah”）。名称はニュージーランドの高山に生息するオウム「kea」に由来します。DHCPの文脈では、ISCが開発するDHCPv4/DHCPv6サーバー製品「Kea」を指します。

kea-ctrl-agent（Control Agent）とは何ですか？

kea-ctrl-agentは、Keaサーバー群をHTTP/REST経由で操作するためのAPIフロントエンド（Control Agent、KCA）です。受け取ったコマンドをコントロールソケット経由で kea-dhcp4 や kea-dhcp6 などのデーモンへ転送し、サーバーを再起動せずに設定変更・統計取得・リース操作を行えます。なお Kea 3.0 以降は各サーバーが直接HTTP APIを提供する方式が推奨となり、Control Agentは非推奨（deprecated）扱いですが、後方互換のため引き続き利用できます。

KeaはWindowsで使えますか？

いいえ。Keaが公式に対応するのはLinux/UNIX系OSとmacOSで、Windowsネイティブ版は提供されていません。Windows環境で利用する場合は、WSL2やLinux仮想マシン上でKeaを動作させます。

KeaにGUIやWeb管理画面はありますか？

Kea本体にWeb UIは付属しませんが、ISCが提供する管理ツール「Stork」のWeb UIから、複数のKeaサーバーのステータス、サブネット/プールの使用率、HA状態をブラウザで確認・管理できます。メトリクスはPrometheus形式で出力されるため、Grafanaでの可視化にも対応します。

Keaの最新バージョンは？

2026年時点の安定版はKea 3.2.0系で、Kea 3.0がKea初のLTS（長期サポート、3年）リリースです。バージョンの更新は速いため、導入時はISC公式サイトで最新のリリース情報を確認してください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る