Loading...

FGCP HA: Active-Passive, Active-Active — nguyên lý bầu chọn Master

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

Kết thúc nhóm VPN, anh Nam chuyển sang nhiệm vụ mới: dựng cụm HA (High Availability) hai FortiGate cho một khách hàng tài chính — yêu cầu tuyệt đối không được để mất kết nối quá vài giây nếu một thiết bị gặp sự cố. Anh Nam mua hai FortiGate cùng model, cùng cấu hình, cắm cáp heartbeat, bật HA — nhưng băn khoăn: "Nếu cả hai thiết bị đều 'ngang tài ngang sức', làm sao cụm tự quyết định ai là chính (Master), ai là dự phòng?"

Chị Lan giải thích: "Đây chính là việc của FGCP (FortiGate Clustering Protocol) — giao thức riêng của Fortinet điều phối toàn bộ cụm HA. Nó không chỉ bầu Master mà còn đồng bộ cấu hình, đồng bộ session, và quyết định failover khi cần. Việc bầu Master không phải ngẫu nhiên — có hẳn một thứ tự tiêu chí rõ ràng."

Bài này mở đầu nhóm High Availability & Quản lý tập trung — giới thiệu FGCP, hai chế độ Active-Passive và Active-Active, và nguyên lý bầu chọn Master.


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

2.1 FGCP là gì

FGCP (FortiGate Clustering Protocol) là giao thức độc quyền của Fortinet, chịu trách nhiệm cho toàn bộ hoạt động của cụm HA: bầu chọn thiết bị chính (Primary/Master), đồng bộ cấu hình giữa các thành viên, trao đổi trạng thái session, và ra quyết định failover khi phát hiện sự cố. Đây là nền tảng cho mọi cấu hình HA truyền thống trên FortiGate (khác với FGSP — FortiGate Session Life Support Protocol, một cơ chế đồng bộ session độc lập hơn, không thuộc phạm vi bài này).

2.2 Hai chế độ hoạt động: Active-Passive và Active-Active

Active-Passive (A-P) — chỉ có đúng một thiết bị (Primary) xử lý toàn bộ traffic tại một thời điểm; thiết bị còn lại (Secondary) ở trạng thái chờ, đồng bộ cấu hình và session liên tục, sẵn sàng tiếp quản ngay khi Primary gặp sự cố.

config system ha
    set group-name "FGT-HA"
    set mode a-p
    set password "MatKhauHA"
    set hbdev "ha1" 50 "ha2" 20
    set session-pickup enable
    set priority 200
end

Active-Active (A-A) — nhiều thiết bị cùng tham gia xử lý traffic đồng thời, phân tải xử lý Security Profile (proxy-based) giữa các thành viên trong cụm, giúp tăng tổng công suất xử lý.

config system ha
    set group-name "FGT-HA"
    set mode a-a
    set password "MatKhauHA"
    set hbdev "ha1" 50 "ha2" 20
    set session-pickup enable
    set priority 200
end

⚠️ Lưu ý: Active-Active phân tải chủ yếu cho việc xử lý proxy-based Security Profile (đã học ở bài Antivirus Profile) — CPU và bộ nhớ dùng cho proxy-based inspection vốn tốn tài nguyên, nên load balancing kiểu này giúp tận dụng công suất dư của các thành viên phụ. Tuy nhiên cần cân nhắc: nếu một thành viên trong cụm A-A gặp sự cố, phần tải nó đang xử lý sẽ dồn lên các thành viên còn lại — cần tính toán công suất dự phòng hợp lý, tránh tình trạng cụm hoạt động ở mức tải cao (ví dụ 70% mỗi máy) khiến một máy chết sẽ làm máy còn lại quá tải.

2.3 Bốn tiêu chí bầu chọn Master theo thứ tự ưu tiên

Khi FGCP cần xác định thiết bị nào đóng vai trò Master (Primary) trong cụm, nó xét lần lượt theo đúng thứ tự sau — chỉ chuyển sang tiêu chí tiếp theo khi tiêu chí trước đó hòa nhau:

FGCP: Thứ Tự 4 Tiêu Chí Bầu Chọn Master / Primary Device 1. Số lượng Monitored Interface đang "Up" — Nhiều hơn thắng 2. HA Uptime — Chạy lâu hơn (chênh lệch > 5 phút / 300s) mới thắng 3. Priority (Device Priority) — Giá trị lớn hơn thắng (default: 128) 4. Serial Number — Chuỗi cao hơn thắng (Tiebreaker cuối cùng) 📌 Lưu ý quan trọng về chế độ Override: • Mặc định (override disable): Áp dụng đúng thứ tự 1 ➔ 2 ➔ 3 ➔ 4 như trên. • Khi bật (override enable): Tiêu chí Priority (3) được ưu tiên đưa lên trước HA Uptime (2).

1. Số lượng monitored interface đang hoạt động — thiết bị có nhiều cổng đang giám sát (port monitor) còn "up" hơn sẽ thắng ngay ở bước đầu tiên, bất kể priority cấu hình cao hay thấp. Nguyên tắc này đảm bảo thiết bị có kết nối mạng khỏe mạnh hơn được ưu tiên làm Master.

2. HA Uptime (thời gian đã chạy trong cụm) — nếu hòa ở tiêu chí 1, thiết bị đã chạy ổn định lâu hơn (vượt quá một ngưỡng chênh lệch nhất định) được xem là "senior" hơn và thắng. Đây là lý do một thiết bị vừa khởi động lại thường không giành lại vai trò Master ngay lập tức dù cấu hình priority cao hơn — tránh hiện tượng "giật" vai trò Master liên tục mỗi khi thiết bị cũ khởi động lại xong.

3. Priority (device priority) — chỉ khi hai tiêu chí trên hòa nhau, giá trị priority cấu hình thủ công (mặc định 128, có thể chỉnh 0–255) mới được xét — số cao hơn thắng.

config system ha
    ...
    set priority 200
    set override disable
end

4. Serial Number — tiêu chí cuối cùng, chỉ dùng khi cả ba tiêu chí trên đều hòa tuyệt đối (trường hợp gần như không xảy ra trong thực tế với thiết bị khác serial) — số serial cao hơn thắng.

⚠️ Lưu ý quan trọng: Tham số override quyết định liệu Priority có được xét trước HA Uptime hay không. Mặc định override disable — nghĩa là Uptime luôn được ưu tiên xét trước Priority (đúng thứ tự đã liệt kê ở trên), giúp cụm ổn định, tránh chuyển đổi Master qua lại không cần thiết. Nếu bật override enable, Priority sẽ được xét trước Uptime — thiết bị priority cao sẽ giành lại Master ngay khi nó trở lại, dù thời gian chạy ngắn hơn. Cách này phù hợp khi muốn đảm bảo một thiết bị cụ thể (ví dụ thiết bị công suất mạnh hơn) luôn là Master bất cứ khi nào nó khả dụng, nhưng đánh đổi bằng việc cụm dễ "giật" vai trò Master hơn.

2.4 Heartbeat Interface — kênh giao tiếp sống còn của cụm

Các thành viên trong cụm HA giao tiếp với nhau qua heartbeat interface — kênh riêng biệt (không phải interface xử lý traffic thông thường) dùng để trao đổi trạng thái, đồng bộ session, và phát hiện sự cố lẫn nhau.

config system ha
    ...
    set hbdev "ha1" 50 "ha2" 20
end

Có thể khai báo nhiều heartbeat interface với mức ưu tiên khác nhau (số càng cao càng được ưu tiên) — dự phòng cho trường hợp một đường heartbeat bị đứt, cụm vẫn còn đường khác để duy trì liên lạc, tránh tình huống nguy hiểm gọi là split-brain (cả hai thiết bị đều tự nhận mình là Master do mất liên lạc heartbeat hoàn toàn).

⚠️ Lưu ý: Nên dùng ít nhất hai heartbeat interface vật lý riêng biệt, cắm qua hai đường cáp/switch khác nhau nếu có thể — chỉ dùng một heartbeat duy nhất tạo ra điểm lỗi đơn (single point of failure) nguy hiểm cho toàn bộ cơ chế bầu chọn Master của cụm.


3. Hỏi & Đáp

Active-Active có luôn cho hiệu năng tốt hơn Active-Passive không?

Không hẳn — Active-Active giúp tăng công suất xử lý (đặc biệt cho proxy-based Security Profile), nhưng đánh đổi bằng độ phức tạp vận hành cao hơn và rủi ro quá tải khi một thành viên gặp sự cố. Nhiều triển khai thực tế vẫn ưu tiên Active-Passive vì đơn giản, dễ dự đoán hành vi, đặc biệt khi công suất một thiết bị đã đủ đáp ứng nhu cầu tải thông thường.

Nếu hai thiết bị có priority giống hệt nhau, HA có báo lỗi không?

Không — vẫn hoạt động bình thường, FGCP sẽ tiếp tục xét tới tiêu chí Serial Number để phân định, đảm bảo luôn có kết quả bầu chọn rõ ràng dù các tiêu chí phía trước hòa nhau.

Vì sao mặc định override lại là disable thay vì enable?

Vì mục tiêu chính của HA là sự ổn định — mặc định ưu tiên Uptime trước Priority giúp tránh tình trạng vai trò Master bị "giật" qua lại liên tục mỗi khi một thiết bị khởi động lại xong (dù priority của nó cao hơn), gây gián đoạn không cần thiết cho traffic đang chạy ổn định trên Master hiện tại.

Split-brain trong HA là gì và vì sao nguy hiểm?

Split-brain xảy ra khi cả hai thiết bị trong cụm đồng thời tự nhận mình là Master (thường do mất toàn bộ liên lạc heartbeat) — dẫn tới xung đột cấu hình, xung đột địa chỉ IP/MAC ảo, và có thể gây gián đoạn nghiêm trọng hơn cả việc không có HA. Đây là lý do cần dự phòng nhiều đường heartbeat riêng biệt như đã nêu ở mục 2.4.


4. Quiz

Câu 1: FGCP chịu trách nhiệm cho những hoạt động nào trong cụm HA?

  • A. Chỉ riêng việc mã hóa VPN
  • B. Bầu chọn Master, đồng bộ cấu hình, trao đổi trạng thái session, và quyết định failover
  • C. Chỉ quản lý DNS
  • D. Không có vai trò gì cụ thể

Câu 2: Trong chế độ Active-Active, cơ chế load balancing chủ yếu áp dụng cho loại xử lý nào?

  • A. Routing tĩnh
  • B. Proxy-based Security Profile (Antivirus, Web Filter proxy-based...)
  • C. DHCP
  • D. DNS Filter

Câu 3: Tiêu chí nào được FGCP xét đầu tiên khi bầu chọn Master?

  • A. Priority
  • B. Serial Number
  • C. Số lượng monitored interface đang hoạt động
  • D. Tên hostname

Câu 4: Theo mặc định (override disable), tiêu chí nào được xét trước giữa HA Uptime và Priority?

  • A. Priority luôn được xét trước Uptime
  • B. HA Uptime được xét trước Priority
  • C. Cả hai được xét đồng thời
  • D. Không tiêu chí nào được xét, chỉ dùng Serial Number

Câu 5: Vì sao nên dùng ít nhất hai heartbeat interface riêng biệt cho cụm HA?

  • A. Để tăng tốc độ xử lý traffic thông thường
  • B. Để tránh điểm lỗi đơn (single point of failure), giảm nguy cơ split-brain nếu một đường heartbeat bị đứt
  • C. Vì FortiOS yêu cầu bắt buộc phải có 2 heartbeat
  • D. Không có lý do kỹ thuật cụ thể

👉 Đáp án

Câu 1: B FGCP chịu trách nhiệm cho toàn bộ hoạt động cốt lõi của cụm HA: bầu chọn Master, đồng bộ cấu hình giữa các thành viên, trao đổi trạng thái session, và ra quyết định failover khi có sự cố.

Câu 2: B Active-Active chủ yếu phân tải cho việc xử lý Security Profile dạng proxy-based (Antivirus, Web Filter...), vốn tốn nhiều tài nguyên CPU/bộ nhớ hơn flow-based.

Câu 3: C FGCP xét đầu tiên số lượng monitored interface đang hoạt động — thiết bị có nhiều cổng giám sát còn "up" hơn sẽ thắng ngay ở bước này, trước cả khi xét tới Priority hay Uptime.

Câu 4: B Theo mặc định (override disable), HA Uptime được xét trước Priority — giúp cụm ổn định, tránh vai trò Master bị chuyển đổi qua lại không cần thiết mỗi khi một thiết bị khởi động lại.

Câu 5: B Dùng ít nhất hai heartbeat interface riêng biệt giúp tránh điểm lỗi đơn — nếu một đường heartbeat bị đứt, cụm vẫn còn đường khác để duy trì liên lạc, giảm nguy cơ xảy ra tình huống split-brain nguy hiểm.


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

🧭 Điều hướng

⬅️ Bài trước🏠 Mục lục khóa họcBài kế tiếp ➡️
FortiClient Integration: quản lý endpoint tập trung Mục lục khóa học FortiGate Cấu hình HA Cluster & Heartbeat Interface