DPTCloud
Quay lại danh sách
Tin tức công nghệ

Giải Pháp Sẵn Sàng Cao: Cấu Hình Thủ Công Failover IP Bằng Keepalived Giữa Hai Nhà Cung Cấp VPS Khác Nhau

30 tháng 5, 2026

1. Đặt vấn đề: Thách thức duy trì Uptime trong môi trường Đa đám mây (Multi-Cloud)

Trong kỷ nguyên số, việc đảm bảo hệ thống hoạt động liên tục 24/7 là yếu tố sống còn đối với mọi doanh nghiệp. Một phút downtime (thời gian chết) không chỉ gây thiệt hại về doanh thu mà còn làm tổn hại nghiêm trọng đến uy tín thương hiệu. Thông thường, các nhà cung cấp VPS (Virtual Private Server) đều hỗ trợ tính năng Failover IP (IP dự phòng) trong cùng một trung tâm dữ liệu. Tuy nhiên, chuyện gì sẽ xảy ra nếu toàn bộ hạ tầng của nhà cung cấp đó gặp sự cố nghiêm trọng?

Để đạt được độ sẵn sàng cao nhất (High Availability - HA), các kỹ sư hệ thống thường hướng tới giải pháp kết hợp giữa hai nhà cung cấp VPS độc lập (ví dụ: DigitalOcean và Linode, hoặc vultr và AWS). Tuy nhiên, cơ chế Failover IP tự động mặc định không thể hoạt động xuyên suốt giữa hai hệ thống mạng khác nhau. Bài viết này sẽ hướng dẫn bạn cách cấu hình thủ công cơ chế Failover IP bằng công cụ Keepalived kết hợp với kịch bản điều hướng API để giải quyết bài toán phức tạp này.

2. Kiến trúc giải pháp Failover IP liên nhà cung cấp

Do địa chỉ IP tĩnh không thể định tuyến vật lý từ hạ tầng của nhà cung cấp A sang nhà cung cấp B chỉ bằng giao thức VRRP (Virtual Router Redundancy Protocol) tiêu chuẩn, chúng ta cần một cơ chế linh hoạt hơn. Ở đây, chúng ta sử dụng một bên thứ ba để làm cổng điều hướng IP (ví dụ: Cloudflare API, DNS Failover, hoặc một IP định tuyến động được quản lý bằng API).

Mô hình hoạt động bao gồm:

  • Node Master (VPS tại Nhà cung cấp A): Máy chủ chính xử lý lưu lượng truy cập.
  • Node Backup (VPS tại Nhà cung cấp B): Máy chủ dự phòng, liên tục kiểm tra trạng thái của Node Master.
  • Keepalived: Công cụ chạy trên cả hai node, sử dụng giao thức VRRP để phát hiện trạng thái "sống/chết" của nhau qua môi trường mạng Internet (tận dụng tính năng unicast).
  • Kịch bản API (Trigger Scripts): Khi Master gặp sự cố, Keepalived trên Backup sẽ kích hoạt một đoạn mã (Bash/Python) để gọi API cập nhật lại bản ghi DNS hoặc chuyển hướng IP về phía mình.
Lưu ý quan trọng: Vì hai VPS nằm ở hai nhà cung cấp khác nhau, việc giao tiếp VRRP qua multicast thông thường sẽ bị chặn bởi tường lửa của nhà cung cấp. Do đó, cấu hình bắt buộc phải chuyển sang chế độ Unicast.

3. Hướng dẫn cấu hình chi tiết từng bước

Giả sử chúng ta có hai VPS chạy hệ điều hành Ubuntu Server với các thông tin sau:

  • VPS Master (Provider A): IP 1.2.3.4
  • VPS Backup (Provider B): IP 5.6.7.8
  • Virtual IP / DNS Endpoint: Được quản lý qua API (ví dụ: Cloudflare hoặc Cloud IP chuyên dụng).

Bước 1: Cài đặt Keepalived trên cả hai máy chủ

Cập nhật hệ thống và tiến hành cài đặt gói Keepalived bằng lệnh sau trên cả Node Master và Node Backup:

sudo apt update
sudo apt install keepalived mailutils -y

Bước 2: Cấu hình cấu trúc tệp tin Keepalived trên Node Master

Truy cập vào thư mục cấu hình và tạo file /etc/keepalived/keepalived.conf trên máy chủ Master:

vrrp_script chk_services {
    script "/usr/local/bin/check_app.sh"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1

    # Cấu hình Unicast vì khác nhà cung cấp
    unicast_src_ip 1.2.3.4
    unicast_peer {
        5.6.7.8
    }

    authentication {
        auth_type PASS
        auth_pass Secr3tPasswd
    }

    track_script {
        chk_services
    }

    notify_master "/usr/local/bin/failover_trigger.sh MASTER"
}

Bước 3: Cấu hình cấu trúc tệp tin Keepalived trên Node Backup

Tương tự, tạo file /etc/keepalived/keepalived.conf trên máy chủ Backup với các thông số điều chỉnh phù hợp:

vrrp_script chk_services {
    script "/usr/local/bin/check_app.sh"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1

    # Cấu hình Unicast
    unicast_src_ip 5.6.7.8
    unicast_peer {
        1.2.3.4
    }

    authentication {
        auth_type PASS
        auth_pass Secr3tPasswd
    }

    track_script {
        chk_services
    }

    notify_master "/usr/local/bin/failover_trigger.sh BACKUP"
}

Bước 4: Xây dựng Kịch bản Trigger API điều hướng dòng tiền dữ liệu

Điểm mấu chốt của giải pháp này nằm ở script /usr/local/bin/failover_trigger.sh. Khi trạng thái chuyển sang MASTER (tức là node hiện tại tiếp quản hệ thống), script này sẽ thực hiện một lệnh cURL gửi đến API của nhà cung cấp dịch vụ mạng/DNS để trỏ luồng traffic về IP của chính nó.

Dưới đây là ví dụ minh họa cấu trúc script cập nhật DNS qua Cloudflare API:

#!/bin/bash
TYPE=$1
if [ "$TYPE" == "MASTER" ] || [ "$TYPE" == "BACKUP" ]; then
    # Định nghĩa các biến API cần thiết
    ZONE_ID="your_zone_id"
    RECORD_ID="your_record_id"
    API_TOKEN="your_cloudflare_api_token"
    NEW_IP=$(curl -s [https://api.ipify.org](https://api.ipify.org))

    # Gọi API để cập nhật IP mới cho hệ thống
    curl -X PUT "[https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID](https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID)" \
         -H "Authorization: Bearer $API_TOKEN" \
         -H "Content-Type: application/json" \
         --data "{\"type\":\"A\",\"name\":\"api.yourdomain.com\",\"content\":\"$NEW_IP\",\"ttl\":120}"
fi

Cấp quyền thực thi cho các file script đã tạo:

sudo chmod +x /usr/local/bin/check_app.sh
sudo chmod +x /usr/local/bin/failover_trigger.sh
sudo systemctl restart keepalived

4. Đánh giá ưu điểm và nhược điểm của phương pháp

Bất kỳ giải pháp kiến trúc nào cũng có những sự đánh đổi về mặt kỹ thuật. Đối với mô hình Failover thủ công liên đám mây, chúng ta có thể nhìn nhận qua bảng so sánh dưới đây:

Ưu điểm (Pros) Nhược điểm & Thách thức (Cons)
Độ độc lập cao: Không bị phụ thuộc vào hạ tầng phần cứng của duy nhất một nhà cung cấp. Nếu một nhà cung cấp sập diện rộng, hệ thống vẫn an toàn. Độ trễ DNS (DNS TTL): Nếu sử dụng cơ chế cập nhật DNS API, việc chuyển hướng luồng traffic có thể mất từ vài chục giây đến vài phút tùy thuộc vào bộ nhớ đệm (cache) của nhà mạng ISP.
Tối ưu chi phí: Không cần thuê các đường truyền chuyên dụng đắt đỏ như MPLS hay thiết lập hệ thống BGP phức tạp. Đồng bộ dữ liệu: Việc đồng bộ hóa dữ liệu thời gian thực (Stateful data như MySQL, Session) giữa hai nhà cung cấp khác nhau qua Internet đòi hỏi giải pháp bảo mật và băng thông tốt.

5. Những lưu ý vận hành thực tế đối với Doanh nghiệp

Để đảm bảo kịch bản Failover hoạt động trơn tru khi có sự cố thật, doanh nghiệp cần tuân thủ nghiêm ngặt các nguyên tắc vận hành sau:

  1. Giám sát kiểm tra sức khỏe hệ thống (Health Check): Đảm bảo script check_app.sh không bị nhận diện sai (False Positive). Tránh tình trạng cả hai node liên tục tranh giành quyền Master (hiện tượng Split-Brain).
  2. Mã hóa lưu lượng Unicast VRRP: Vì gói tin VRRP gửi qua môi trường Internet công cộng giữa hai nhà cung cấp, bắt buộc phải sử dụng các cơ chế xác thực mạnh hoặc cấu hình một đường ống VPN (WireGuard/IPsec) bảo mật giữa hai máy chủ và chạy Keepalived bên trong đường ống đó.
  3. Kế hoạch phục hồi (Failback): Khi Node Master tại Nhà cung cấp A hoạt động trở lại, hãy đảm bảo dữ liệu mới nhất sinh ra trên Node Backup đã được đồng bộ ngược về trước khi Keepalived tự động chuyển quyền MASTER lại cho Node A.

6. Lời kết

Thiết lập cơ chế Failover IP bằng Keepalived giữa hai nhà cung cấp VPS khác nhau là giải pháp kiến trúc nâng cao giúp nâng cấp hệ thống từ mức độ an toàn thông thường lên mức độ thảm họa (Disaster Recovery) vững chắc. Mặc dù đòi hỏi sự tỉ mỉ trong cấu hình mạng Unicast và xử lý script API, nhưng giá trị mang lại về mặt Uptime hoàn toàn xứng đáng với công sức bỏ ra. Hãy bắt đầu thử nghiệm mô hình này trên môi trường Staging ngay hôm nay để bảo vệ hệ thống của bạn trước những kịch bản xấu nhất.

Giải Pháp Sẵn Sàng Cao: Cấu Hình Thủ Công Failover IP Bằng Keepalived Giữa Hai Nhà Cung Cấp VPS Khác Nhau | DPTCloud