Vấn đề Điểm lỗi Duy nhất (Single Point of Failure)
Sáng thứ Hai, 9 giờ đúng. Điện thoại hỗ trợ của bạn bắt đầu reo liên hồi vì Wi-Fi bị “hỏng”. Sau hai mươi phút xử lý sự cố điên cuồng, bạn tìm ra thủ phạm thực sự: dịch vụ máy chủ DHCP bị treo. Không có nó, mạng của bạn chỉ là một tập hợp các thiết bị bị ngắt kết nối đang chờ đợi một địa chỉ IP không bao giờ tới.
Tôi đã từng thấy toàn bộ các tòa nhà văn phòng bị đình trệ chỉ vì một tệp lease bị hỏng. Phụ thuộc vào một máy chủ DHCP duy nhất là một rủi ro rất lớn. Để khắc phục điều này, chúng ta sử dụng High Availability (HA). Hướng dẫn này sẽ đi sâu vào việc thiết lập Kea DHCP—phiên bản kế nhiệm hiện đại, dạng mô-đun cho ISC DHCP cũ—để đảm bảo mạng của bạn luôn hoạt động ngay cả khi một máy chủ ngoại tuyến đột ngột.
Cơ chế hoạt động thực tế của Kea DHCP HA
Không giống như các hệ thống cũ dựa trên các giao thức heartbeat phức tạp, Kea sử dụng một thư viện hook chuyên dụng có tên là libdhcp_ha.so. Điều này cho phép các instance Kea khác nhau đồng bộ hóa cơ sở dữ liệu lease của chúng gần như theo thời gian thực thông qua REST API.
Bạn thường có thể chọn giữa hai chế độ vận hành:
- Load Balancing (Cân bằng tải): Cả hai máy chủ đều hoạt động. Chúng chia sẻ các yêu cầu từ client (ví dụ: Máy chủ A xử lý 50%, Máy chủ B xử lý 50%). Nếu một máy chủ gặp sự cố, máy chủ còn lại sẽ ngay lập tức tiếp nhận 100% lưu lượng.
- Hot Standby (Dự phòng nóng): Máy chủ Chính (Primary) thực hiện tất cả các công việc nặng nhọc trong khi Máy chủ Phụ (Secondary) theo dõi. Máy chủ Phụ chỉ tiếp quản nếu Máy chủ Chính ngừng phản hồi.
Chúng ta sẽ triển khai Load Balancing trong bài hướng dẫn này. Đây là cách hiệu quả nhất để đảm bảo cả hai máy chủ đều khỏe mạnh và có khả năng xử lý nhu cầu cao điểm của mạng.
Vai trò của Control Agent
Các instance Kea không giao tiếp trực tiếp với nhau thông qua dịch vụ DHCP. Thay vào đó, chúng sử dụng kea-ctrl-agent. Dịch vụ sidecar này lắng nghe các lệnh qua HTTP. Để HA hoạt động, Máy chủ A phải có thể kết nối tới Control Agent của Máy chủ B trên cổng 8000 và ngược lại. Nếu tường lửa của bạn chặn cổng này, cặp HA sẽ không bao giờ đồng bộ được.
Điều kiện tiên quyết
Bạn sẽ cần hai instance Linux. Ubuntu 22.04 hoặc Debian 12 là những lựa chọn phổ biến nhất cho thiết lập này. Trong ví dụ của chúng ta, chúng ta sử dụng các IP sau:
- Máy chủ 1 (Primary): 192.168.1.10
- Máy chủ 2 (Secondary): 192.168.1.11
Địa chỉ IP tĩnh là bắt buộc. Hãy đảm bảo các máy chủ có thể ping thấy nhau trước khi tiếp tục.
Bước 1: Cài đặt Kea DHCP
Cài đặt DHCP server và Control Agent trên cả hai máy. Mặc dù nhiều bản phân phối có sẵn Kea trong kho lưu trữ mặc định, tôi khuyên bạn nên sử dụng kho lưu trữ ISC chính thức để có các bản vá bảo mật mới nhất.
sudo apt update
sudo apt install kea-dhcp4-server kea-ctrl-agent -yDừng các dịch vụ ngay lập tức. Việc cấu hình sẽ dễ dàng hơn khi chúng không cố gắng quản lý các lease đang hoạt động.
sudo systemctl stop kea-dhcp4-server kea-ctrl-agentBước 2: Cấu hình Control Agent
Control Agent là cầu nối giữa hai node của bạn. Chỉnh sửa tệp /etc/kea/kea-ctrl-agent.conf trên cả hai máy chủ. Bạn phải thay đổi http-host từ 127.0.0.1 thành 0.0.0.0 để nó có thể nhận yêu cầu từ đối tác.
{
"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"
}
]
}
}Khởi động lại agent trên cả hai node để áp dụng các thay đổi:
sudo systemctl start kea-ctrl-agentBước 3: Thiết lập HA Hook trên Máy chủ 1
Mở tệp /etc/kea/kea-dhcp4.conf trên máy chủ đầu tiên. Chúng ta cần yêu cầu Kea tải thư viện HA và xác định đối tác của nó là ai. Trong ví dụ này, chúng ta đang quản lý một subnet 192.168.1.0/24 với một pool gồm 101 địa chỉ.
{
"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" }
]
}
]
}
}Bước 4: Đồng bộ hóa Máy chủ 2
Sao chép cấu hình sang Máy chủ 2, nhưng hãy chú ý kỹ đến trường this-server-name. Đây là dòng duy nhất phải thay đổi. Nếu bạn để nguyên là “server1” trên máy thứ hai, việc đồng bộ HA sẽ thất bại ngay lập tức.
Trên Máy chủ 2, cập nhật /etc/kea/kea-dhcp4.conf:
"high-availability": [{
"this-server-name": "server2",
"mode": "load-balancing",
...
}]Giữ nguyên danh sách peers và các cài đặt subnet4 giống hệt nhau trên cả hai node. Kea sử dụng các thông tin này để xác minh rằng cả hai máy chủ đang cố gắng quản lý cùng một mạng.
Bước 5: Xác minh và Kiểm tra Failover
Khởi chạy dịch vụ DHCP trên cả hai máy:
sudo systemctl start kea-dhcp4-serverTheo dõi nhật ký để xác nhận quá trình bắt tay (handshake) thành công. Bạn cần tìm dòng thông báo chuyển sang trạng thái “load-balancing”.
journalctl -u kea-dhcp4-server -fNếu bạn thấy thông báo “communication-interrupted”, hãy kiểm tra lại xem cổng 8000 đã được mở trong tường lửa chưa. Bạn có thể kiểm tra nhanh bằng lệnh curl http://192.168.1.10:8000.
Bài kiểm tra “Rút phích cắm”
Để xác minh tính dự phòng, hãy dừng dịch vụ trên Máy chủ 1. Trong vòng hai giây (giá trị max-response-delay mà chúng ta đã thiết lập), Máy chủ 2 sẽ nhận thấy sự im lặng. Nó sẽ ghi lại một thay đổi trạng thái và bắt đầu phản hồi tất cả các gói DHCP Discover. Sau khi bạn khởi động lại Máy chủ 1, hai node sẽ thực hiện “cập nhật lease hàng loạt” (bulk lease update) để đồng bộ hóa bất kỳ IP mới nào được cấp phát trong thời gian ngoại tuyến.
Lời kết
Cấu hình Kea DHCP HA là một trong những cách hiệu quả nhất để tăng cường hạ tầng của bạn. Bằng cách loại bỏ thiết lập máy chủ đơn lẻ, bạn loại bỏ được một nút thắt cổ chai phổ biến và một điểm lỗi nguy hiểm. Mặc dù chúng ta đã sử dụng cơ sở dữ liệu dạng tệp đơn giản ở đây, các môi trường lớn hơn với hàng nghìn client nên xem xét sử dụng backend MySQL hoặc PostgreSQL dùng chung để có khả năng mở rộng tốt hơn.
