Bài 11.4. Thiết kế failover backend thủ công (QMS ↔ AI)

Bài này chỉ làm rõ hơn bài 11.3
Nếu bài 11.3 đã hiểu và đảm bảo chạy rồi thì không cần tham khảo thêm bài này.

1. Mục tiêu và phạm vi

Trong mô hình của anh, Reverse Proxy là cổng vào duy nhất từ Internet, còn backend chạy trong mạng riêng:

QMS (primary): 10.10.10.66
AI (standby): 10.10.10.88
Proxy: 192.168.1.88 (NAT 80/443 từ modem/router)

Mục tiêu của failover thủ công:

Chuyển toàn bộ traffic từ QMS sang AI trong thời gian ngắn.
Chỉ thao tác trên Reverse Proxy, không đụng cấu hình hàng trăm site.
Không ảnh hưởng SSL/Certbot (vì SSL terminate tại proxy).
Có thể rollback nhanh về QMS khi QMS hồi phục.

Giải pháp sử dụng: một “điểm chuyển mạch” duy nhất ở Nginx thông qua snippet backend-active.conf.

2. Thiết kế kiến trúc failover: “Single Switch File”

2.1. File backend active (điểm chuyển mạch duy nhất)

File:
/etc/nginx/snippets/backend/backend-active.conf

Nội dung (khi QMS active):

Khi cần failover sang AI, chỉ đổi thành:

2.2. Mọi site chỉ include file này

Trong tất cả website/webapp/ws template:

Kết quả: failover không phụ thuộc số lượng domain.

3. Điều kiện tiên quyết để failover “không rủi ro”

Trước khi coi failover là một quy trình vận hành chính thức, cần đảm bảo các điều kiện sau:

3.1. AI server phải sẵn sàng phục vụ (standby nóng)

Có đủ dữ liệu/ứng dụng giống QMS (tùy mức độ dự phòng anh thiết kế).
Dịch vụ web backend đã chạy.
Mở port nội bộ (80/443 hoặc port app) và proxy truy cập được.

3.2. Reverse Proxy truy cập được AI

Trên proxy:

Phải trả về 200/301/302/403 tùy ứng dụng, nhưng không được timeout.

3.3. ACME challenge độc lập backend

Đảm bảo Bài 11.1 đã hoàn tất:

/.well-known/acme-challenge/ trả trực tiếp từ proxy
Renew cert không phụ thuộc backend

4. Chuẩn hóa “trạng thái” và file cấu hình phục vụ failover

4.1. Khuyến nghị: tạo 2 file backend cố định và 1 file active

Files:

/etc/nginx/snippets/backend/backend-qms.conf
/etc/nginx/snippets/backend/backend-ai.conf
/etc/nginx/snippets/backend/backend-active.conf (symlink)

Nội dung:

backend-qms.conf

backend-ai.conf

Tạo symlink để “switch” nhanh, hạn chế sửa nội dung file:

Khi failover:

5. Quy trình failover thủ công: QMS → AI

5.1. Checklist nhận diện sự cố (khi nào failover)

Failover chỉ nên kích hoạt khi có một hoặc nhiều dấu hiệu sau:

QMS không phản hồi (timeout).
5xx tăng đột biến liên tục và xác minh nguyên nhân từ QMS.
QMS mất kết nối mạng nội bộ.
QMS phải bảo trì khẩn cấp / reboot dài.

5.2. Bước 1 — Xác minh QMS lỗi từ Reverse Proxy

Nếu timeout hoặc lỗi nghiêm trọng (không phải 301/302 bình thường), tiếp tục bước 2.

5.3. Bước 2 — Xác minh AI sẵn sàng

Đảm bảo có phản hồi.

5.4. Bước 3 — Switch backend-active sang AI

Nếu dùng symlink (khuyến nghị):

5.5. Bước 4 — Test cấu hình và reload Nginx an toàn

Tuyệt đối không reload khi nginx -t fail.

5.6. Bước 5 — Xác minh nhanh trên domain quan trọng

Kiểm tra một số web app trọng điểm:

Nếu có Cloudflare, kiểm tra cả đường đi qua Cloudflare.

6. Quy trình rollback: AI → QMS

Khi QMS đã khôi phục, rollback cũng theo đúng nguyên tắc “một điểm chuyển mạch”.

6.1. Xác minh QMS đã OK

6.2. Switch backend-active về QMS

6.3. Reload an toàn

7. Cơ chế giảm rủi ro khi failover

7.1. Luôn dùng reload thay vì restart

reload không ngắt kết nối hiện có như restart (đặc biệt hữu ích với webapp).

7.2. Có “domain kiểm tra” (health endpoint) để xác minh nhanh

Nên chuẩn hóa 1 endpoint nhẹ trên backend như:

/health
/status
/ping

Reverse Proxy chỉ cần curl endpoint đó.

7.3. Ghi log thao tác failover

Khuyến nghị tạo file log thao tác:

/var/log/failover.log

Ví dụ ghi:

8. Tích hợp failover vào vận hành hàng ngày

8.1. Đặt quy trình thành SOP (khuyến nghị)

Ai có quyền failover
Khi nào được phép
Checklist trước/sau
Truy vết sau sự cố

8.2. Diễn tập định kỳ

Ví dụ mỗi tháng 1 lần:

Switch sang AI 5–10 phút
Xác minh các webapp trọng điểm
Switch lại QMS

Mục tiêu: đảm bảo “standby” không bị bỏ quên và lỗi cấu hình không tích tụ.

9. Hạn chế của failover thủ công và hướng nâng cấp

Failover thủ công:

Phụ thuộc con người thao tác
Không có health-check tự động
Không tự load-balance

Hướng nâng cấp tương lai (khi cần):

upstream + nhiều backend
health-check (Nginx Plus hoặc giải pháp khác)
Keepalived/VRRP nếu cần HA cho chính reverse proxy

Tuy nhiên, với yêu cầu hiện tại của anh (ổn định, dễ vận hành, ít phức tạp), failover thủ công theo “single switch file” là tối ưu về tỷ lệ hiệu quả / rủi ro / công sức.

Kết luận

Thiết kế failover thủ công QMS ↔ AI hiệu quả nhất trong hệ thống của anh là:

Tập trung toàn bộ chuyển đổi backend vào một file duy nhất (backend-active.conf)
Mọi site chỉ include file đó
Khi sự cố xảy ra: switch → nginx -t → reload → kiểm tra domain trọng điểm
Khi hồi phục: rollback tương tự

Cách làm này giúp hệ thống:

Dễ vận hành ở quy mô hàng trăm domain
Failover nhanh, ít rủi ro
Không ảnh hưởng HTTPS/Certbot

Đăng nhập để gửi ý kiến