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

Hai node trên diagram tạo cảm giác yên tâm. Nhưng chỉ đến lúc mình tắt thành phần đang Active và nhìn xem traffic, session và application phản ứng thế nào thì HA mới bắt đầu được kiểm chứng.

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 và nhiều lớp dự phòng.

Điều đó có giá trị thật, vì ít nhất mình đã loại bỏ được một số single point of failure rõ ràng. Nhưng càng đi qua migration, failover và recovery, mình càng hay hỏi một câu khác:

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

Không phải theo tài liệu vendor. Mà là chuyện gì xảy ra với traffic, session, route, application connection và cuối cùng là service người dùng đang cần.

HA configuration chưa nói hết HA behavior

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, monitored interface và cơ chế giữ session state. Khi điều kiện failure xảy ra, node còn lại được kỳ vọng tiếp quản.

Nhìn ở mức configuration thì khá rõ. Nhưng phần troubleshooting mới là chỗ đáng chú ý: hai node có thể không đồng bộ, heartbeat path có thể lỗi, monitored interface có thể chọn chưa đúng, hoặc role transition không xảy ra như mong đợi.

Đó là lý do mình không còn thấy checkbox “HA Enabled” là đủ.

Với mình, một bài test HA cần đi qua đủ mấy bước rất thực tế: 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à service còn dùng được không.

Một bài test Database làm mình nhớ rất lâ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 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 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 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, rồi tiếp tục kiểm tra application, integration và reporting flow đang sử dụng Database đó.

Firewall có heartbeat và session state. Database có replication và role transition. Công nghệ khác nhau, nhưng cách kiểm tra cuối cùng lại khá giống nhau.

Nếu thứ đang được phụ thuộc biến mất, phần phía sau có tiếp tục hoạt động không?

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

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

Nhưng user không quan tâm Firewall nào đang Active. Application cũng không quan tâm cluster trông đẹp trên console. Chúng chỉ cần request đi qua, listener reachable, connection thành công và dependency phía sau phản hồi đúng.

Vì vậy trong bài test Database nói trên, sau khi Primary bị shutdown, team tiếp tục kiểm tra application nghiệp vụ, integration và reporting.

Mình rút ra một câu khá đơn giản: failover test nên kết thúc ở nơi user hoặc application bắt đầu.

Nếu business flow bắt đầu từ transaction, test transaction. Nếu bắt đầu từ API, test API. Nếu phụ thuộc reporting, kiểm tra data flow đến reporting.

Heartbeat cũng có thể hỏng

HA thường được thêm vào để giảm rủi ro của một thành phần. Nhưng chính HA cũng tạo thêm dependency: heartbeat, state synchronization, election logic, shared path, VIP hoặc listener.

Mỗi thứ đó đều có failure mode riêng.

Điều này không có nghĩa HA là không tốt. Nó chỉ nhắc mình rằng thêm redundancy cũng đồng nghĩa thêm thứ cần hiểu và cần test.

Giờ mình thường hỏi gì khi review một hệ thống HA?

Mình ít quan tâm hơn tới việc giao diện có hiện “Enabled” hay không. Mình muốn biết hai node có thật sự synchronized không, failure condition nào kích hoạt transition, transition mất bao lâu, session hiện hữu bị ảnh hưởng thế nào, dependency nào nằm ngoài HA domain, và lần gần nhất team thật sự test failure là khi nào.

Có một khoảng cách khá lớn giữa ba câu:

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

HA đã từng failover.

Team đã test failure và xác nhận service vẫn hoạt động như mong đợi.

Nghe gần giống nhau, nhưng mức độ mình dám tin vào hệ thống thì khác hẳn.

Sau cùng, HA vẫn phải được thử bằng failure thật

Architecture Diagram được vẽ khi mọi thứ đang bình thường. HA chỉ lộ ra khi có thứ không còn bình thường nữa.

Vì vậy mình không còn nhìn HA bằng số node. Mình nhìn vào cách hệ thống phản ứng khi một node, một link hoặc một dependency biến mất.

Hai thiết bị trên sơ đồ tạo cảm giác an toàn. Tắt một thiết bị đi rồi kiểm tra service mới cho mình biết cảm giác đó có cơ sở hay không.