HA Failover Testing & Troubleshooting trên FortiGate — Quy trình chẩn đoán chuẩn

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

Cluster HA của khách hàng mà anh Nam triển khai ở bài trước — Cấu hình HA cluster, heartbeat interface — đã lên in-sync trên cả 2 node. Nhưng chị Lan không cho phép bàn giao ngay: "Cluster lên xanh trên GUI mới chỉ là điều kiện cần. Em phải chủ động ép nó failover thử, đo thời gian gián đoạn thực tế, rồi mới báo khách là xong."

Anh Nam rút cáp port WAN của node Primary để test — traffic chuyển sang node Secondary sau vài giây, đúng như kỳ vọng. Nhưng khi cắm lại cáp, anh Nam nhận ra một chi tiết đáng chú ý: node vừa mất kết nối kia lại lập tức giành lại vai trò Primary, gây thêm một đợt gián đoạn nhỏ nữa dù không mong muốn — hệ quả trực tiếp của việc cluster đang bật override enable với priority chênh lệch, đúng như quy tắc đã học ở bài trước. Chị Lan nhân dịp này hướng dẫn anh Nam bộ lệnh test failover "sạch" (không cần rút cáp vật lý) và quy trình chẩn đoán khi cluster báo not synchronized.

2. Kiến thức cốt lõi

2.1 Ép failover có kiểm soát bằng lệnh, không cần rút cáp

Thay vì rút cáp vật lý (rủi ro và khó lặp lại), Fortinet cung cấp lệnh ép failover trực tiếp trên node đang là Primary:

execute ha failover set 1

Lệnh này sẽ hỏi xác nhận (Do you want to continue? (y/n)) trước khi thực thi vì đây là thao tác có chủ đích gây gián đoạn dịch vụ. Sau khi chạy, node hiện tại sẽ giữ nguyên trạng thái Secondary bất kể điều kiện thực tế cho đến khi được gỡ thủ công bằng:

execute ha failover unset 1

⚠️ Lưu ý: Đây là lệnh chỉ dùng cho test/demo/bảo trì có kế hoạch — tuyệt đối không chạy trên hệ thống production ngoài cửa sổ bảo trì đã thông báo trước, vì thiết bị sẽ bị khóa cứng ở trạng thái Secondary cho đến khi người quản trị tự tay unset.

Sau khi failover, kiểm tra ai đang là Primary và lý do được chọn bằng:

get system ha status

Kết quả sẽ có dòng "Primary selected using" giải thích rõ nguyên nhân — ví dụ do cờ EXE_FAIL_OVER được set trên node kia, hoặc do override priority lớn hơn. Đọc kỹ dòng này giúp phân biệt failover do lệnh test, do override, hay do lỗi thật sự.

2.2 Đo thời gian gián đoạn và kiểm tra session-pickup

Với session-pickup enable đã cấu hình ở bài trước, các session đang mở sẽ được đồng bộ sang Secondary nên khi failover xảy ra, phần lớn kết nối TCP không bị rớt (client thường chỉ thấy độ trễ ngắn, không phải kết nối lại từ đầu). Để kiểm chứng thực tế trong lúc test, anh Nam thường mở song song một ping -t liên tục qua cluster và theo dõi số gói rớt — với cluster cấu hình đúng, chỉ mất khoảng vài giây (thời gian phụ thuộc hb-interval và hb-lost-threshold), không phải hàng chục giây.

Nếu số gói rớt lớn bất thường, nguyên nhân thường nằm ở việc session-pickup chưa bật, hoặc traffic không đi qua đúng interface được giám sát failover (xem mục 2.4 bên dưới).

2.3 Chẩn đoán khi cluster báo "not synchronized"

Đây là lỗi thường gặp nhất sau khi vừa dựng cluster hoặc sau khi sửa cấu hình trên 1 node mà quên đồng bộ. Quy trình xử lý theo đúng thứ tự:

Bước 1 — Xác nhận thật sự out-of-sync và checksum lệch ở đâu:

diagnose sys ha checksum cluster

Lệnh này in ra checksum theo từng vùng cấu hình (global, root, và các VDOM nếu có) trên từng thành viên. Nếu checksum của 2 node khác nhau ở vùng nào, vùng đó chính là nơi cấu hình bị lệch.

Bước 2 — Khoanh vùng chi tiết hơn nếu cần:

diagnose sys ha checksum show global
diagnose sys ha checksum show root

So sánh output giữa 2 node (copy ra file text và dùng công cụ diff) để xác định chính xác mục cấu hình nào (ví dụ: interface, firewall policy, SSL-SSH profile...) đang gây lệch checksum. Vấn đề thường gặp thực tế là sự khác biệt ở firewall ssl-ssh-profile hoặc cấu hình interface/VLAN không khớp giữa 2 node.

Bước 3 — Ép đồng bộ lại thủ công:

execute ha synchronize start
diagnose sys ha checksum recalculate

Nếu vẫn không tự khớp, cần vào phần cấu hình bị lệch (xác định ở Bước 2) trên node đang out-of-sync và sửa/xóa thủ công cho khớp với Primary.

🔄 Khác biệt version FortiOS: Từ FortiOS 8.0, GUI đã hỗ trợ nút Force resync ngay trong màn hình System > HA (chọn thành viên → Diagnostics and Tools → Force resync), giúp thao tác Bước 3 mà không cần vào CLI. Trên FortiOS 7.0, thao tác này chỉ thực hiện được qua CLI như hướng dẫn trên.

2.4 Chẩn đoán split-brain và sự cố heartbeat

Nhắc lại từ bài trước: split-brain là tình huống cả 2 node cùng tự nhận là Primary do mất liên lạc heartbeat. Các lệnh chẩn đoán heartbeat hữu ích:

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

• diagnose sys ha history read: xem lịch sử các lần failover đã xảy ra, giúp xác định nguyên nhân là do mất interface, mất heartbeat, hay do thao tác thủ công.
• diagnose sys ha hb-stat: theo dõi bộ đếm gói heartbeat bị mất (lost) — nếu con số này tăng liên tục, dấu hiệu của link heartbeat chập chờn (cáp lỏng, lỗi port, hoặc do heartbeat vẫn đang đi qua switch trung gian thay vì đấu trực tiếp).
• diagnose sys ha interface-stats: theo dõi các interface đang được HA giám sát (monitor), bộ đếm fail_cnt tăng cho biết interface đó đang flap.

Nếu xác nhận split-brain đang xảy ra, chạy get system ha status trên cả 2 node cùng lúc — chỉ nên có đúng 1 node báo Primary; nếu cả 2 cùng báo Primary, cần khôi phục lại kết nối heartbeat trước (kiểm tra lại cáp/port theo đúng sơ đồ ở bài trước), sau đó reboot node phụ (không phải node đang phục vụ traffic chính) để nó join lại cluster đúng vai trò Secondary.

3. Hỏi & Đáp

Lệnh execute ha failover set 1 có gây mất session đang chạy không?

Không, nếu session-pickup đã được bật — vì đây là failover có kiểm soát (graceful), khác với trường hợp node bị mất điện đột ngột. Các session TCP đang mở phần lớn được giữ nguyên, người dùng cuối chỉ cảm nhận độ trễ ngắn trong lúc chuyển đổi.

Vì sao sau khi execute ha failover unset 1, node vẫn chưa giành lại vai trò Primary ngay?

Vì việc node nào là Primary sau khi unset còn phụ thuộc vào cấu hình override: nếu override disable (khuyến nghị production), node đang phục vụ tốt sẽ tiếp tục giữ vai trò Primary dù node kia có priority cao hơn — đây là hành vi đúng, không phải lỗi.

diagnose sys ha checksum cluster báo khớp nhưng GUI vẫn hiển thị "not synchronized" thì sao?

Tình huống này từng gặp thực tế trên một số dòng chassis lớn (7K/6K series) — GUI đôi khi hiển thị chậm hoặc chưa cập nhật kịp trạng thái thật. Luôn ưu tiên tin vào kết quả CLI (diagnose sys ha checksum cluster và get system ha status) hơn là chỉ dựa vào icon trạng thái trên GUI, đặc biệt trong lúc vừa thao tác cấu hình.

Có cần lo lắng khi thấy hb-stat báo vài gói lost lẻ tẻ không?

Vài gói mất lẻ tẻ, không liên tục tăng, thường không đáng ngại (có thể do nhiễu tức thời). Điều cần quan tâm là xu hướng tăng liên tục theo thời gian — đó mới là dấu hiệu link heartbeat có vấn đề thực sự cần kiểm tra lại phần cứng/cáp.

4. Quiz

Câu 1: Lệnh nào dùng để ép một node Primary chuyển sang Secondary phục vụ mục đích kiểm thử?

• A. diagnose sys ha checksum recalculate
• B. execute ha failover set 1
• C. execute ha synchronize start
• D. diagnose sys ha history read

Câu 2: Sau khi chạy execute ha failover set 1, muốn gỡ trạng thái ép failover đó, dùng lệnh nào?

• A. execute reboot
• B. execute ha failover unset 1
• C. diagnose sys ha hb-stat reset
• D. execute ha synchronize stop

Câu 3: Lệnh nào giúp xác định chính xác vùng cấu hình (global/root/VDOM) đang bị lệch khi cluster báo "not synchronized"?

• A. get system ha status
• B. diagnose sys ha checksum cluster
• C. execute ha failover set 1
• D. diagnose sys ha interface-stats

Câu 4: Bộ đếm nào trong diagnose sys ha hb-stat là dấu hiệu cảnh báo link heartbeat đang chập chờn nếu tăng liên tục?

• A. sessions
• B. lost
• C. checksum
• D. override

👉 Đáp án

Câu 1: B execute ha failover set 1 chạy trên node Primary sẽ ép nó chuyển sang trạng thái Secondary có kiểm soát, phục vụ mục đích test/demo, và yêu cầu xác nhận trước khi thực thi vì gây gián đoạn dịch vụ.

Câu 2: B execute ha failover unset 1 là lệnh gỡ trạng thái ép failover đã đặt trước đó, vì node bị ép sẽ giữ nguyên trạng thái Secondary cho đến khi được gỡ thủ công.

Câu 3: B diagnose sys ha checksum cluster in checksum theo từng vùng cấu hình (global, root, VDOM) trên mỗi thành viên, giúp khoanh vùng chính xác nơi cấu hình bị lệch giữa các node.

Câu 4: B Bộ đếm lost trong diagnose sys ha hb-stat phản ánh số gói heartbeat bị mất; nếu con số này tăng liên tục, đó là dấu hiệu link heartbeat đang gặp vấn đề chập chờn cần kiểm tra lại cáp/port.

📚 Bài viết thuộc khóa học FortiGate của VNExperts

🧭 Điều hướng