1. Bối cảnh và mục tiêu
Trong kiến trúc hệ thống của mình, failover không nhằm đạt “zero downtime” bằng các cơ chế HA phức tạp, mà hướng đến khả năng duy trì dịch vụ ổn định với rủi ro thấp và khả năng kiểm soát cao.
Bối cảnh thực tế:
QMS là máy chủ chính, xử lý phần lớn tải và dữ liệu.
AI là máy chủ dự phòng, cấu hình mạnh, sẵn sàng tiếp nhận vai trò tạm thời.
Reverse Proxy là cổng vào duy nhất từ Internet.
Mục tiêu của cơ chế failover thủ công:
Chuyển toàn bộ traffic từ QMS sang AI trong thời gian ngắn.
Không ảnh hưởng đến HTTPS, DNS, Cloudflare.
Thao tác đơn giản, tránh sai sót trong tình huống khẩn cấp.
Có thể rollback nhanh khi QMS hồi phục.
2. Vì sao chọn failover thủ công thay vì HA tự động
Trước khi đi vào kỹ thuật, cần làm rõ vì sao failover thủ công là lựa chọn phù hợp trong giai đoạn này.
2.1. Hạn chế của HA tự động trong môi trường thực tế
Các giải pháp như:
Load balancer active–active,
Health check tự động,
VRRP / Keepalived,
tuy mạnh về lý thuyết nhưng thường gặp các vấn đề:
Khó triển khai đúng ngay từ đầu.
Dễ tạo “failover giả” do health check sai.
Khó debug khi sự cố xảy ra đồng thời nhiều lớp.
Phụ thuộc sâu vào kỹ năng đội vận hành.
2.2. Lợi thế của failover thủ công
Failover thủ công:
Đơn giản → ít lỗi cấu hình.
Minh bạch → người vận hành biết chính xác hệ thống đang ở trạng thái nào.
Phù hợp với quy mô và nguồn lực hiện tại.
Trong môi trường bệnh viện và quản trị chuyên ngành, ổn định và kiểm soát thường quan trọng hơn tự động hóa quá mức.
3. Nguyên tắc thiết kế failover thủ công an toàn
Cơ chế failover được thiết kế dựa trên 5 nguyên tắc:
Một điểm chuyển mạch duy nhất
Không phụ thuộc backend cho HTTPS
Không sửa hàng loạt file khi sự cố
Thao tác ngắn gọn, có thể ghi nhớ
Có khả năng rollback ngay lập tức
4. Điểm chuyển mạch duy nhất: backend-active
4.1. Khái niệm
Toàn bộ hệ thống reverse proxy không trỏ trực tiếp đến IP backend, mà trỏ thông qua một snippet duy nhất đại diện cho backend đang active.
4.2. Cấu trúc file
backend-qms.conf
backend-ai.conf
backend-active.conf
Là symlink trỏ đến một trong hai file trên.
5. Cách hệ thống sử dụng backend-active
Trong mọi website và web app:
Không có file nào khác được phép hard-code IP backend.
6. Quy trình failover thủ công (QMS → AI)
6.1. Khi nào cần kích hoạt failover
Failover chỉ nên thực hiện khi:
QMS không phản hồi trong thời gian dài.
Dịch vụ trên QMS gặp lỗi nghiêm trọng.
QMS cần bảo trì khẩn cấp.
Không dùng failover để xử lý lỗi cấu hình nhỏ.
6.2. Các bước failover
Bước 1: Xác minh QMS gặp sự cố
Nếu không phản hồi hoặc lỗi rõ ràng, tiếp tục.
Bước 2: Xác minh AI sẵn sàng
Bước 3: Chuyển backend-active
Bước 4: Kiểm tra và reload
Bước 5: Kiểm tra nhanh dịch vụ quan trọng
Truy cập một vài web app trọng điểm.
Kiểm tra response code và login cơ bản.
7. Quy trình rollback (AI → QMS)
Khi QMS hồi phục:
Bước 1: Xác minh QMS hoạt động
Bước 2: Chuyển backend-active về QMS
Bước 3: Reload an toàn
8. Các biện pháp giảm rủi ro khi failover
8.1. Không restart Nginx
Luôn dùng
reload.Tránh ngắt kết nối đang tồn tại.
8.2. Có checklist in sẵn
Để gần máy proxy hoặc trong SOP nội bộ.
Tránh thao tác thiếu bước khi căng thẳng.
8.3. Ghi log thao tác failover
Ví dụ:
9. Giới hạn của cơ chế failover thủ công
Không tự phát hiện sự cố.
Phụ thuộc người vận hành.
Không cân bằng tải.
Tuy nhiên, trong phạm vi mục tiêu đề ra, đây là giải pháp cân bằng tốt nhất giữa độ an toàn, đơn giản và khả năng kiểm soát.
Kết luận
Cơ chế failover thủ công đơn giản – an toàn dựa trên:
Một điểm chuyển mạch backend duy nhất,
Reverse Proxy làm trung tâm điều phối,
Thao tác ngắn gọn, rõ ràng,
giúp hệ thống:
Duy trì dịch vụ khi QMS gặp sự cố,
Tránh lan rộng sự cố sang HTTPS/DNS,
Dễ rollback và dễ vận hành lâu dài.
- Đăng nhập để gửi ý kiến
