ISC DHCP から Kea DHCP への本番環境移行｜リース継承・HA フェイルオーバー設計・ロールバック検証

ISC DHCP（dhcpd）は2022年10月にメンテナンス終了を迎え、ISC（Internet Systems Consortium）自身がKea DHCPへの移行を推奨しています。セキュリティパッチの提供も事実上停止された現在、本番環境での継続運用はリスクとなっています。しかし「既存のリースをどう引き継ぐか」「フェイルオーバーの設計はどう変わるか」「万一の際にどう切り戻すか」という実務上の疑問が移行の障壁になっているケースが多く見受けられます。本記事では、これら3点を中心にした移行シナリオを1本で完結させます。

ISC DHCPとKea DHCPの本質的な違い

移行作業に入る前に、両者のアーキテクチャの差異を把握しておくことが重要です。ISC DHCPはフラットファイル（dhcpd.leases）でリースを管理し、設定もdhcpd.confという独自書式でした。これに対してKeaはJSONベースの設定ファイルを採用し、リースデータベースとしてメモリファイル・MySQL・PostgreSQL・Cassandraのいずれかを選択できます。

また、ISC DHCPのフェイルオーバーはDHCPプロトコル拡張（RFC 3074相当の独自実装）に依存していましたが、KeaのHA（High Availability）はHTTPベースのREST APIとリース同期によって実現されており、設計の自由度と可視性が大きく向上しています。REST APIの存在はCMDB連携や自動化にも恩恵をもたらします。

移行前の準備：設定変換とリースDB変換

dhcpd.conf からkea-dhcp4.conf への変換

ISCが提供するkeamaツール（Kea Migration Assistant）を使うと、既存のdhcpd.confをKeaのJSON設定に変換する出発点を得られます。ただし、変換結果は人手による確認が必須です。特にカスタムオプション（option space）やclass/subclassを多用している環境では、Keaの「クライアントクラス」モデルへの再設計が必要になる場合があります。

変換後のkea-dhcp4.confはkea-dhcp4 -tコマンドで構文チェックが行えます。本番適用前にステージング環境で実際にリース払い出しを確認するまで、このチェックを省略しないことが運用上の鉄則です。

リースファイルの変換とインポート

既存のリース情報を引き継がないと、移行直後にすべてのクライアントが新規割り当てとなり、固定IPを期待している機器との競合やDNS不整合が発生します。ISC DHCPのdhcpd.leasesはKeaのmemfileとは書式が異なるため、変換スクリプトを介してインポートする必要があります。

コミュニティ製の変換ツールやPythonスクリプトがGitHubに複数公開されています。変換の流れとしては、dhcpd.leasesを解析してクライアントMAC・IPアドレス・有効期限を抽出し、Keaのmemfile書式（address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_contextのCSV）に変換します。MySQLバックエンドを採用する場合は同様のデータをINSERTするSQLを生成します。

変換後はkea-lfc（Lease File Cleanup）でファイル整合性を確認してからkea-dhcp4を起動します。リース件数の多い環境では起動時のメモリロードに時間がかかることがあるため、メンテナンスウィンドウに十分な余裕を持たせてください。

KeaのHA（高可用性）フェイルオーバー設計

ISC DHCPのフェイルオーバーに慣れた運用担当者にとって、KeaのHAモードは概念の切り替えが必要な部分です。Keaではhot-standbyとload-balancingの2モードが用意されており、多くの本番環境ではhot-standby（プライマリが全リクエストを処理、スタンバイはリース同期のみ受け取る）が選択されています。

HA設定はkea-dhcp4.conf内のhooks-librariesにlibdhcp_ha.soを指定し、各ノードにピアのIPアドレス・ポート・証明書パスを記述します。通信はHTTP/HTTPSで行われるため、ファイアウォールのルールをTCP 8080（またはカスタムポート）で開けておく必要があります。

フェイルオーバー検出はハートビートのmax-response-delayとmax-unacked-clientsパラメータで制御します。デフォルト値のままでは検出が遅くなりすぎる場合があるため、SLAに応じてheartbeat-delay: 10000（ミリ秒）・max-response-delay: 30000程度から調整を始めるのが現場では一般的です。

スタンバイノードへの切り替えはKea 2.x以降では自動的に行われますが、切り替え後のステータスはkea-ctrl-agent経由のREST API（GET /v1/ha-maintenance）やKeaのControl-Agent CLIで確認できます。PrometheusエクスポーターもISC公式で提供されているため、Grafanaとの連携で可視化しておくと障害時の判断が迅速になります。

本番切り替えとカットオーバー手順

カットオーバーは段階的に行うことが推奨されます。典型的な手順は次の通りです。まずKeaをISC DHCPと同一ホスト（またはスタンバイホスト）に別ポートで起動し、特定サブネットのみを対象にした平行稼働期間を設けます。ルーターやL3スイッチのDHCPリレー先を一部セグメントだけKeaに向け、割り当て動作とリース継続を確認します。

問題がなければリレー先を全セグメントに切り替え、ISC DHCPのサービスを停止します。停止直前にdhcpd.leasesの最新スナップショットを保存しておくことが、ロールバック時の差分最小化につながります。切り替え後24〜48時間はリースログとkea-dhcp4.logを並走監視し、払い出し失敗や重複割り当てが出ていないかを確認してください。

ロールバック：Kea停止→ISC DHCP復旧の検証ポイント

ロールバックを確実に行うには、事前に手順を机上演習しておくことが不可欠です。切り戻し時の最大リスクは「Keaで払い出されたリースがISC DHCP側に反映されていない」ことです。Keaのmemfileから逆変換してdhcpd.leases形式に書き戻すスクリプトを準備しておき、ロールバック判断から数分以内に適用できる状態にしておきます。

手順の概略は以下の通りです。

• Keaのリースファイル（またはDBダンプ）を取得し、ISC DHCP形式に変換する
• 変換済みのdhcpd.leasesを所定のパスに配置し、ISC DHCPを起動する
• ルーターのリレー設定をISC DHCPのアドレスに戻す
• Keaを停止し、ログに二重起動の痕跡がないことを確認する

実際の障害訓練では、リース変換スクリプトのバグや書き込み権限不足でロールバックが遅延するケースが報告されています。本番移行前に非本番環境でロールバック全体を1サイクル実施し、所要時間を計測しておくことが重要です。RTO（目標復旧時間）を満たせるかどうかをこの段階で確認します。

2026年現在の環境差分と注意点

2026年時点でKea DHCPの最新安定版は2.6系（Long-Term Support）です。Kea 2.4以降ではHAのheartbeat実装が改善されており、ネットワーク瞬断時の誤フェイルオーバーが軽減されています。Kea 2.6では設定の再読み込みがSIGHUPなしにREST API経由（config-reloadコマンド）で行えるようになり、無停止での設定変更がより容易になっています。

ディストリビューション側の変化も注意が必要です。Ubuntu 24.04 LTSおよびDebian 12（Bookworm）ではisc-dhcp-serverパッケージが非推奨扱いとなっており、次のリリースサイクルでの削除が示唆されています。RHEL 9 / AlmaLinux 9・Rocky Linux 9ではISC DHCPはリポジトリから外れており、Keaはサードパーティリポジトリ（ISC公式RPMまたはEPEL）からの導入となります。自組織のディストリビューションのロードマップと照らし合わせて移行優先度を判断してください。

Kea Premiumサポート（ISC有償サポート）を契約しない場合、libdhcp_ha.soなどの一部フックライブラリはオープンソース版でも利用できますが、libdhcp_radius.soなどのプレミアムフックは別途ライセンスが必要です。OSS版で賄える機能の範囲を事前に確認し、ライセンスコストをTCOに組み込んでおくことが、予算計画の観点から現場では求められています。

ISC DHCPからKeaへの移行は、単なるパッケージ入れ替えではなく、アーキテクチャと運用フローの刷新です。リース変換・HA再設計・ロールバック検証の3点を事前に整備することで、本番カットオーバーのリスクを大幅に低減できます。