High Availability không bắt đầu từ thiết bị thứ hai

Có một cách khá dễ để làm cho Architecture Diagram trông đáng tin cậy hơn: vẽ thêm một thiết bị thứ hai. Nhưng hai node chỉ chứng minh rằng chúng ta có redundancy. Chúng chưa chứng minh điều gì sẽ xảy ra khi failure thật sự đến.

Mình từng làm với những hệ thống nhìn trên sơ đồ rất “đẹp”: hai Firewall chạy HA, hai Database Node, nhiều đường truyền, nhiều lớp dự phòng.

Cảm giác an tâm là có thật. Vì ít nhất, chúng ta đã loại bỏ được một số single point of failure rất rõ ràng.

Nhưng càng làm nhiều với migration, failover và recovery, mình càng thấy một câu hỏi khó chịu hơn:

Nếu mình tắt thành phần đang Active ngay lúc này, chuyện gì sẽ xảy ra tiếp theo?

Không phải chuyện gì nên xảy ra theo tài liệu vendor. Mà chuyện gì thực sự xảy ra với traffic, session, route, application connection và cuối cùng là business service.

Đó là lúc mình bắt đầu nhìn High Availability khác đi.

Redundancy chỉ mới là điều kiện cần

Trong một dự án Firewall migration mà mình tham gia, HA được thiết kế theo mô hình Active-Passive. Hai node có heartbeat riêng, có monitored interface và bật session pickup. Khi interface được theo dõi gặp vấn đề, node đang Active được kỳ vọng chuyển vai trò cho node còn lại.

Nhìn ở mức configuration, mọi thứ rất hợp lý.

Nhưng điều làm mình chú ý hơn lại nằm ở phần vận hành và troubleshooting của tài liệu: phải tính tới trường hợp hai node không đồng bộ, failover không hoạt động, hoặc thiết bị không chuyển sang vai trò master khi cần.

Chỉ riêng việc những tình huống đó cần một mục troubleshooting riêng đã nói lên một điều khá quan trọng:

HA configuration không đồng nghĩa HA behavior.

Một cluster có thể được cấu hình đúng trên GUI nhưng heartbeat path lại có vấn đề. Monitor interface có thể chọn sai. Priority có thể không đúng. Hai node có thể lệch firmware hoặc configuration state.

Architecture Diagram không thể hiện những thứ đó.

Vì vậy, với mình, High Availability nên được nhìn như một chuỗi hành vi thay vì một feature bật trong thiết bị.

Failure có được phát hiện đúng không?

Role có chuyển đúng không?

Traffic có đi đúng path mới không?

Và cuối cùng: service mà người dùng thật sự cần có còn dùng được không?

Network và Database khác công nghệ, nhưng failure lại hỏi cùng một câu

Một dự án khác mình tham gia là migration các Database cũ sang nền tảng SQL Server mới có Always On. Phần mình phụ trách trong dự án là Network connectivity giữa các vùng hệ thống và cụm SQL mới; mình không phải người thiết kế Database HA.

Nhưng chính vì đứng ở giao điểm giữa Network và Application dependency, mình thấy bài test cuối rất đáng nhớ.

Team không dừng ở việc nhìn cluster status rồi xác nhận hai node đang healthy.

Kịch bản validation chủ động shutdown node đang giữ vai trò Primary, kiểm tra node còn lại tiếp quản vai trò, rồi tiếp tục kiểm tra các application, integration và reporting flow đang dùng Database đó.

Đây là điểm mình thấy Network HA và Database HA gặp nhau.

Firewall có heartbeat, monitored interface và session state.

Database có replication, cluster health và role transition.

Công nghệ rất khác.

Nhưng câu hỏi Engineering lại giống nhau:

“Nếu thứ mình đang phụ thuộc biến mất, dependency phía sau có tiếp tục hoạt động không?”

Mình nghĩ đây là một cách nhìn hữu ích vì nó kéo HA ra khỏi phạm vi của từng vendor.

HA không phải chuyện riêng của Fortinet.

Cũng không phải chuyện riêng của SQL Server.

Nó là một pattern về failure management.

Role đã đổi chưa có nghĩa Service đã sống

Một lỗi tư duy khá dễ gặp là xem việc “node B đã thành Active” hay “secondary đã thành Primary” như bằng chứng cuối cùng của một bài test HA.

Theo mình, đó mới chỉ là bằng chứng rằng control plane đã làm đúng một phần công việc.

Business không sử dụng chữ “Primary”. Business sử dụng application.

User không quan tâm Firewall nào đang Active. Họ quan tâm request có đi qua không.

Application không quan tâm cluster trông healthy trên console. Nó cần listener reachable, connection thành công, transaction chạy được và dependency phía sau phản hồi đúng.

Đó là lý do trong bài test Database nói trên, sau khi Primary Node bị shutdown, validation không dừng ở cluster. Team kiểm tra lại application nghiệp vụ, luồng integration và reporting.

Điều mình rút ra từ đó khá đơn giản:

Failover test nên kết thúc ở nơi business bắt đầu.

Nếu business bắt đầu từ một transaction, hãy test transaction.

Nếu business bắt đầu từ một API, hãy test API.

Nếu business bắt đầu từ một dashboard báo cáo, hãy kiểm tra data flow tới dashboard đó.

Đi càng xa khỏi console kỹ thuật, bài test càng tiến gần hơn tới availability thật.

Heartbeat cũng là một dependency

Khi nói về HA, chúng ta thường xem heartbeat như thứ giúp hai node “biết nhau”. Nhưng heartbeat cũng là một dependency và dependency nào cũng có thể fail.

Trong Firewall HA, troubleshooting guide của dự án mình từng tham gia liệt kê heartbeat connectivity và monitored interface như những nguyên nhân trực tiếp khiến failover không hoạt động.

Điều đó làm mình nhớ rằng một thiết kế HA luôn tạo thêm một vài thành phần mới để bảo vệ thành phần cũ.

Ta thêm node thứ hai để giảm rủi ro node thứ nhất.

Nhưng rồi ta có heartbeat.

Có state synchronization.

Có election logic.

Có shared network path.

Có VIP hoặc listener.

Mỗi thứ lại mang theo failure mode riêng.

Vì vậy HA không làm hệ thống đơn giản hơn. Nó thường làm hệ thống phức tạp hơn để đổi lấy khả năng chịu lỗi tốt hơn.

Và complexity đó phải được hiểu, không chỉ được cấu hình.

Điều mình muốn thấy không phải là “HA Enabled”

Nếu phải review một hệ thống có HA, bây giờ mình ít bị thuyết phục bởi checkbox “Enabled” hơn trước.

Mình muốn biết thêm:

Hai node có thật sự synchronized không?

Failure condition nào sẽ kích hoạt transition?

Transition mất bao lâu?

Session hay connection hiện hữu sẽ bị ảnh hưởng thế nào?

Dependency nào không nằm trong HA domain?

Ai xác nhận application đã usable trở lại?

Và quan trọng nhất: lần gần nhất team thật sự test failure là khi nào?

Mình thấy có một khoảng cách khá lớn giữa các trạng thái:

HA đã được cấu hình.

HA đã từng failover.

và

Team hiểu rõ hệ thống sẽ cư xử thế nào khi failure xảy ra, đã kiểm thử định kỳ và có bằng chứng service vẫn hoạt động.

Ba câu nghe gần giống nhau, nhưng mức độ tin cậy hoàn toàn khác.

High Availability cuối cùng là một lời hứa phải được kiểm chứng

Architecture thường được thiết kế trong điều kiện bình thường.

Nhưng High Availability chỉ thật sự lộ diện trong điều kiện bất thường.

Vì thế, mình không còn xem HA là chuyện “có bao nhiêu node” nữa.

Mình xem nó như một lời hứa:

“Khi một phần hệ thống thất bại, phần còn lại đủ khả năng tiếp tục duy trì service trong giới hạn mà business chấp nhận.”

Mà lời hứa kỹ thuật thì không nên được giữ bằng niềm tin.

Nó nên được giữ bằng failure test, validation và evidence.

Hai thiết bị trên sơ đồ có thể làm chúng ta cảm thấy an toàn.

Nhưng chỉ khi dám tắt một thiết bị đi và quan sát điều gì xảy ra tiếp theo, chúng ta mới bắt đầu biết hệ thống có thật sự High Availability hay không.