単一障害点（SPOF）の問題
月曜日の朝 9 時。Wi-Fi が「繋がらない」という電話がヘルプデスクに殺到します。20 分間の必死のトラブルシューティングの末、真の原因が見つかります。DHCP サーバーサービスのクラッシュです。これがないと、ネットワークは IP アドレスを待ち続ける、切断されたデバイスの集まりにすぎません。
私は、たった 1 つのリースファイルの破損によって、オフィスビル全体の業務が停止するのを何度も見てきました. 1 台の DHCP サーバーだけに頼ることは大きなリスクです。これを解決するために、高可用性（HA）を使用します。このガイドでは、レガシーな ISC DHCP の現代的でモジュール化された後継である Kea DHCP を設定し、サーバーが予期せずオフラインになってもネットワークを維持する方法を解説します。
Kea DHCP HA の仕組み
複雑なハートビートプロトコルに依存していた古いシステムとは異なり、Kea は libdhcp_ha.so という専用のフックライブラリを使用します。これにより、REST API を介して異なる Kea インスタンス間でリースデータベースをほぼリアルタイムで同期できます。
通常、次の 2 つの動作モードから選択します。
- ロードバランシング（Load Balancing）: 両方のサーバーがアクティブな状態を維持します。クライアントのリクエストを分散します（例：サーバー A が 50%、サーバー B が 50% を担当）。一方が故障すると、生き残ったサーバーが即座に 100% のトラフィックを引き継ぎます。
- ホットスタンバイ（Hot Standby）: プライマリサーバーがすべての処理を行い、セカンダリサーバーが監視します。セカンダリは、プライマリが応答を停止した場合にのみ処理を引き継ぎます。
このチュートリアルでは、ロードバランシングを実装します。これは、両方のサーバーが健全であることを確認し、ネットワークのピーク時の需要に対応できる最も効率的な方法です。
コントロールエージェントの役割
Kea インスタンス同士は DHCP サービスを通じて直接通信するのではなく、kea-ctrl-agent を使用します。このサイドカーサービスは HTTP 経由でコマンドをリッスンします。HA が機能するためには、サーバー A がポート 8000 でサーバー B のコントロールエージェントにアクセスでき、その逆も可能である必要があります。ファイアウォールでこれがブロックされていると、HA ペアは同期されません。
前提条件
2 台の Linux インスタンスが必要です。Ubuntu 22.04 または Debian 12 がこのセットアップでは一般的です。この例では、以下の IP を使用します。
- サーバー 1 (プライマリ): 192.168.1.10
- サーバー 2 (セカンダリ): 192.168.1.11
固定 IP アドレスは必須です。作業を進める前に、サーバー間で互いに ping が通ることを確認してください。
ステップ 1：Kea DHCP のインストール
両方のマシンに DHCP サーバーとコントロールエージェントをインストールします。多くのディストリビューションのデフォルトリポジトリに Kea が含まれていますが、最新のセキュリティパッチを適用するために公式の ISC リポジトリを使用することをお勧めします。
sudo apt update
sudo apt install kea-dhcp4-server kea-ctrl-agent -yインストール後、すぐにサービスを停止します。アクティブなリースを管理しようとしていない状態で設定を行う方が簡単だからです。
sudo systemctl stop kea-dhcp4-server kea-ctrl-agentステップ 2：コントロールエージェントの設定
コントロールエージェントは 2 つのノード間の架け橋となります。両方のサーバーで /etc/kea/kea-ctrl-agent.conf を編集します。パートナーからのリクエストを受信できるように、http-host を 127.0.0.1 から 0.0.0.0 に変更する必要があります。
{
"Control-agent": {
"http-host": "0.0.0.0",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
}
},
"loggers": [
{
"name": "kea-ctrl-agent",
"output_options": [
{ "output": "/var/log/kea-ctrl-agent.log" }
],
"severity": "INFO"
}
]
}
}変更を適用するために、両方のノードでエージェントを再起動します。
sudo systemctl start kea-ctrl-agentステップ 3：サーバー 1 での HA フックの設定
最初のサーバーで /etc/kea/kea-dhcp4.conf を開きます。Kea に HA ライブラリをロードさせ、パートナーが誰であるかを定義する必要があります。この例では、101 個のアドレスプールを持つ 192.168.1.0/24 サブネットを管理します。
{
"Dhcp4": {
"interfaces-config": { "interfaces": [ "eth0" ] },
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [{
"this-server-name": "server1",
"mode": "load-balancing",
"heartbeat-delay": 1000,
"max-response-delay": 2000,
"peers": [
{
"name": "server1",
"url": "http://192.168.1.10:8000/",
"role": "primary"
},
{
"name": "server2",
"url": "http://192.168.1.11:8000/",
"role": "secondary"
}
]
}]
}
}
],
"subnet4": [
{
"id": 1,
"subnet": "192.168.1.0/24",
"pools": [ { "pool": "192.168.1.100 - 192.168.1.200" } ],
"option-data": [
{ "name": "routers", "data": "192.168.1.1" },
{ "name": "domain-name-servers", "data": "8.8.8.8, 8.8.4.4" }
]
}
]
}
}ステップ 4：サーバー 2 の同期
設定をサーバー 2 にコピーしますが、this-server-name フィールドには細心の注意を払ってください。これは変更が必要な唯一の行です。2 台目のマシンで “server1” のままにしておくと、HA 同期は即座に失敗します。
サーバー 2 で /etc/kea/kea-dhcp4.conf を更新します。
"high-availability": [{
"this-server-name": "server2",
"mode": "load-balancing",
...
}]peers リストと subnet4 設定は両方のノードで同一に保ちます。Kea はこれらを使用して、両方のサーバーが同じネットワークを管理しようとしていることを検証します。
ステップ 5：動作確認とフェイルオーバーテスト
両方のマシンで DHCP サービスを起動します。
sudo systemctl start kea-dhcp4-serverログを監視して、ハンドシェイクが成功したことを確認します。「load-balancing」状態への遷移を探してください。
journalctl -u kea-dhcp4-server -fもし “communication-interrupted” と表示される場合は、ファイアウォールでポート 8000 が開放されているか再確認してください。curl http://192.168.1.10:8000 を実行することで、素早くテストできます。
「プラグを抜く」テスト
冗長性を検証するために、サーバー 1 のサービスを停止してみます。2 秒以内（設定した max-response-delay）に、サーバー 2 が無応答を検知します。状態の変化がログに記録され、すべての DHCP Discover パケットへの応答を開始します。サーバー 1 を再起動すると、2 つのノードは「一括リース更新（bulk lease update）」を実行し、ダウンタイム中に割り当てられた新しい IP を同期します。
最後に
Kea DHCP HA の構成は、インフラを強化するための最も効果的な方法の 1 つです。単一サーバー構成から脱却することで、一般的なボトルネックと危険な障害点を取り除くことができます。ここではシンプルなファイルベースのデータベースを使用しましたが、数千のクライアントがいる大規模な環境では、さらなるスケーラビリティのために MySQL や PostgreSQL の共有バックエンドの使用を検討してください。
