Lab: Test Failover có kiểm soát và Chẩn đoán trên HA Cluster FortiGate

1. Liên hệ thực tế

Tiếp nối cluster đã dựng ở Lab trước, anh Nam thực hành đúng quy trình chị Lan yêu cầu trước khi bàn giao: ép failover bằng lệnh thay vì rút cáp, đo thời gian gián đoạn thật bằng ping liên tục, rồi cố tình làm lệch cấu hình giữa 2 node để luyện tập quy trình chẩn đoán "not synchronized" — kỹ năng chị Lan nói là "sớm muộn cũng phải dùng, vì cluster chạy vài tháng kiểu gì cũng có lúc lệch checksum".

Lab này dùng lại đúng cluster đã dựng ở bài trước (group-id 10, priority 200/100, override enable), thực hành ép failover, đo gián đoạn, và luyện quy trình chẩn đoán khi cluster báo lỗi.

💡 Yêu cầu: đã hoàn thành Lab: Dựng HA Cluster Active-Passive trước đó, cluster đang ở trạng thái in-sync.

2. Kiến thức cốt lõi — Các bước thực hành

2.1 Bước 1 — Chuẩn bị: ping liên tục để đo gián đoạn

Từ PC test ở LAN, mở ping liên tục qua cluster trước khi thực hiện bất kỳ thao tác failover nào:

ping -t 8.8.8.8

(Windows: ping -t 8.8.8.8; Linux/macOS: ping 8.8.8.8)

Giữ cửa sổ này chạy song song trong suốt các bước tiếp theo để quan sát trực tiếp số gói bị mất tại từng thời điểm.

2.2 Bước 2 — Ép failover có kiểm soát bằng lệnh

Trên node đang là Primary (đã xác định ở Lab trước), chạy:

execute ha failover set 1

Xác nhận khi được hỏi (Do you want to continue? (y/n) → gõ y). Quan sát ngay lập tức trên cửa sổ ping — đếm số gói bị mất trước khi có phản hồi trở lại.

⚠️ Điểm dễ sai #1: Sau lệnh này, node vừa chạy lệnh sẽ bị khóa cứng ở trạng thái Secondary cho tới khi được gỡ thủ công — không giống như rút cáp (chỉ mất tạm thời), lệnh này giữ nguyên trạng thái đó vô thời hạn. Nếu quên gỡ, dễ nhầm tưởng cluster đang gặp sự cố thật.

2.3 Bước 3 — Kiểm tra kết quả failover và nguyên nhân

get system ha status

Đọc dòng "Primary selected using" trong kết quả — dòng này giải thích rõ vì sao node hiện tại được chọn làm Primary (ví dụ do cờ EXE_FAIL_OVER được set trên node kia). Đối chiếu thời gian mất gói quan sát được ở Bước 2 với lý thuyết: nếu session-pickup đang enable, số gói mất phải chỉ vài giây, không phải hàng chục giây.

2.4 Bước 4 — Gỡ trạng thái ép failover

execute ha failover unset 1

Xác nhận y khi được hỏi. Kiểm tra lại get system ha status — vì cluster đang override enable với priority 200/100 (theo Lab trước), node có priority cao hơn sẽ giành lại vai trò Primary, gây thêm một đợt gián đoạn ngắn nữa trên cửa sổ ping đang chạy.

⚠️ Điểm dễ sai #2: Nếu đã đổi override sang disable ở Lab trước (phần thử nghiệm mở rộng), hành vi ở bước này sẽ khác — node đang là Primary lúc đó (dù priority thấp hơn) sẽ tiếp tục giữ vai trò, không có đợt gián đoạn phụ nào xảy ra. Đây không phải lỗi, mà đúng theo cấu hình override đang có.

2.5 Bước 5 — Cố tình làm lệch cấu hình để luyện tập chẩn đoán "not synchronized"

Trên node đang là Secondary, tạm thời ngắt đồng bộ để có thể sửa cấu hình cục bộ (chỉ dùng cho mục đích luyện tập Lab):

execute ha synchronize stop

Sau đó tạo thử một Address Object mới chỉ trên node này (không có trên Primary) để giả lập tình huống lệch cấu hình:

config firewall address
    edit "Test-Lech-Cauhinh"
        set subnet 172.16.99.0 255.255.255.0
    next
end

2.6 Bước 6 — Phát hiện và khoanh vùng chỗ lệch

Chạy trên cả 2 node để so sánh:

diagnose sys ha checksum cluster

Quan sát checksum global/root/all giữa 2 node — sau khi tạo Address Object lệch ở Bước 5, checksum vùng root (nơi chứa Firewall Address) sẽ khác nhau giữa 2 node.

Khoanh vùng chi tiết hơn:

diagnose sys ha checksum show root

So sánh output giữa 2 node (copy ra file text, dùng công cụ diff) để xác nhận đúng là do vùng cấu hình liên quan tới Address Object đang lệch.

2.7 Bước 7 — Khôi phục đồng bộ

execute ha synchronize start

Chờ vài giây rồi kiểm tra lại:

diagnose sys ha checksum cluster
get system ha status

Kỳ vọng: checksum giữa 2 node khớp lại, Configuration Status trở về in-sync, và Address Object Test-Lech-Cauhinh (tạo thủ công ở node Secondary) biến mất khỏi node đó — vì khi đồng bộ lại, cấu hình của Primary luôn ghi đè lên Secondary, không phải ngược lại.

⚠️ Điểm dễ sai #3: Nếu sau khi execute ha synchronize start mà checksum vẫn lệch, dùng thêm:

diagnose sys ha checksum recalculate

để buộc tính lại checksum trên node đang gặp vấn đề, sau đó kiểm tra lại lần nữa. Không nên chạy lệnh này lặp đi lặp lại nhiều lần liên tiếp mà không quan sát kết quả từng lần.

2.8 Bước 8 — Đọc lịch sử failover và số liệu heartbeat

diagnose sys ha history read
diagnose sys ha hb-stat
diagnose sys ha interface-stats

Đối chiếu diagnose sys ha history read với các thao tác đã thực hiện ở Bước 2 và Bước 4 — phải thấy đúng 2 sự kiện failover tương ứng với thời điểm execute ha failover set 1 và unset 1 đã chạy, xác nhận log ghi nhận chính xác.

Kiểm tra diagnose sys ha hb-stat — bộ đếm lost phải ở mức thấp/ổn định (đã học ở bài lý thuyết: tăng liên tục mới là dấu hiệu đáng lo, vài gói lẻ tẻ không đáng ngại).

3. Hỏi & Đáp

Vì sao Lab yêu cầu execute ha synchronize stop trước khi tạo Address Object lệch ở Bước 5?

Vì mặc định cluster tự động đồng bộ cấu hình gần như ngay lập tức — nếu không tạm dừng đồng bộ trước, Address Object vừa tạo trên Secondary sẽ bị đồng bộ/ghi đè lại theo Primary chỉ sau vài giây, không kịp quan sát hiện tượng lệch checksum như mục đích của bước luyện tập này.

Trong tình huống thực tế (không phải Lab), nếu phát hiện not synchronized nhưng không cố ý tạo ra, có nên nghi ngờ ai đó đã sửa cấu hình trực tiếp trên node Secondary không?

Đây là một khả năng cần xem xét — về nguyên tắc, mọi thay đổi cấu hình chỉ nên thực hiện trên node đang là Primary; nếu có ai đó vô tình đăng nhập và sửa trực tiếp trên Secondary (ví dụ do nhầm địa chỉ quản lý), sẽ gây ra chính xác hiện tượng lệch checksum như Lab vừa mô phỏng. Đây là lý do nên luôn xác nhận rõ đang thao tác trên node nào trước khi sửa cấu hình.

Nếu quên gỡ execute ha failover set 1 (Bước 2) và để cluster chạy nhiều ngày như vậy có sao không?

Có vấn đề — node đó sẽ tiếp tục bị khóa ở trạng thái Secondary bất kể điều kiện thực tế, nghĩa là nếu node đang làm Primary gặp sự cố, node bị khóa này sẽ không thể tự động lên thay thế dù về lý thuyết nó vẫn hoạt động bình thường — làm mất hoàn toàn ý nghĩa dự phòng của cluster. Luôn kiểm tra lại bằng execute ha failover status sau khi test xong.

4. Quiz

Câu 1: Sau khi chạy execute ha failover set 1 mà không gỡ lại, điều gì xảy ra nếu node Primary còn lại gặp sự cố thật?

• A. Node bị khóa sẽ tự động lên thay thế bình thường
• B. Node bị khóa vẫn ở trạng thái Secondary, không thể lên thay thế, làm mất ý nghĩa dự phòng
• C. Cluster tự động tách thành 2 thiết bị độc lập
• D. Không có ảnh hưởng gì

Câu 2: Lệnh nào giúp xác nhận chính xác vùng cấu hình nào đang gây lệch checksum giữa 2 node?

• A. execute ha failover status
• B. diagnose sys ha checksum show root (hoặc global)
• C. diagnose sys ha hb-stat
• D. get system status

Câu 3: Trong Bước 7, sau khi đồng bộ lại thành công, Address Object tạo thủ công ở node Secondary sẽ ra sao?

• A. Được giữ nguyên và đồng bộ ngược lại sang Primary
• B. Biến mất, vì cấu hình Primary luôn ghi đè Secondary khi đồng bộ
• C. Gây lỗi không thể đồng bộ được nữa
• D. Tự động đổi tên để tránh trùng lặp

Câu 4: diagnose sys ha history read dùng để làm gì?

• A. Xem lịch sử các sự kiện failover đã xảy ra trên cluster
• B. Xóa toàn bộ lịch sử cấu hình
• C. Kiểm tra tốc độ đường truyền heartbeat
• D. Đổi priority của các node

👉 Đáp án

Câu 1: B Node đã bị execute ha failover set khóa cứng ở trạng thái Secondary bất kể điều kiện thực tế, nên nếu node Primary còn lại gặp sự cố, node bị khóa sẽ không thể tự động lên thay thế — làm mất hoàn toàn ý nghĩa dự phòng của cluster cho tới khi được gỡ thủ công.

Câu 2: B diagnose sys ha checksum show (kèm tên vùng như global hoặc root) hiển thị chi tiết checksum của từng vùng cấu hình trên mỗi node, giúp xác định chính xác nơi đang bị lệch.

Câu 3: B Khi đồng bộ lại, cấu hình của node Primary luôn được dùng làm chuẩn và ghi đè lên Secondary — Address Object chỉ tồn tại cục bộ trên Secondary sẽ bị loại bỏ khi đồng bộ hoàn tất.

Câu 4: A diagnose sys ha history read hiển thị lịch sử các sự kiện failover đã xảy ra trên cluster, giúp xác định nguyên nhân gây ra từng lần chuyển đổi vai trò Primary/Secondary.

📚 Bài Lab thuộc khóa học FortiGate của VNExperts

🧭 Điều hướng