AWS Active-Active và Active-Passive Failover
Giới thiệu
Trong môi trường điện toán đám mây ngày nay, việc đảm bảo tính khả dụng cao cho ứng dụng là rất quan trọng. Hai chiến lược phổ biến để thực hiện điều này trên AWS là Active-Active và Active-Passive Failover. Trong bài viết này, chúng ta sẽ tìm hiểu chi tiết về cả hai phương pháp, lợi ích và nhược điểm của chúng, cũng như cách triển khai chúng một cách hiệu quả.
🔄 Active-Passive Failover
Cấu hình
- Hệ thống chính (Active): Xử lý tất cả lưu lượng truy cập.
- Hệ thống phụ (Passive): Chạy ở chế độ chờ, sẵn sàng tiếp nhận lưu lượng nếu hệ thống chính gặp sự cố.
Quy trình Failover
- Khi hệ thống chính gặp sự cố, DNS hoặc bộ cân bằng tải sẽ chuyển hướng lưu lượng đến hệ thống phụ.
- Ví dụ trên AWS: Hai EC2 instances được đặt sau một Elastic IP. Thông thường chỉ có một EC2 phục vụ lưu lượng.
- Các kiểm tra sức khỏe của Route 53 phát hiện sự cố → chuyển lưu lượng đến hệ thống dự phòng.
Ưu điểm
- Dễ thiết lập hơn.
- Chi phí thấp hơn, vì hệ thống phụ có thể chạy ở công suất giảm.
Nhược điểm
- Failover có thể gây thời gian chết (vài giây đến vài phút) trong quá trình chuyển đổi.
- Hệ thống phụ có thể không được sử dụng đầy đủ cho đến khi xảy ra failover.
🔄 Active-Active Failover
Cấu hình
- Nhiều hệ thống đều hoạt động và xử lý lưu lượng đồng thời.
- Lưu lượng được phân phối qua các vùng/instaces bằng cách sử dụng bộ cân bằng tải hoặc chính sách Route 53.
Quy trình Failover
- Nếu một hệ thống gặp sự cố, lưu lượng sẽ tự động được chuyển hướng đến các hệ thống hoạt động còn lại.
- Ví dụ trên AWS: Kiến trúc đa vùng với định tuyến theo độ trễ của Route 53.
- Cả hai vùng (ví dụ: us-east-1 và eu-west-1) đều phục vụ lưu lượng đồng thời.
Ưu điểm
- Không có thời gian chết — failover diễn ra một cách liền mạch vì các hệ thống khác đã phục vụ lưu lượng.
- Hiệu suất tốt hơn (người dùng được phục vụ từ vùng gần nhất).
Nhược điểm
- Thiết kế phức tạp hơn (cần đồng bộ dữ liệu toàn cầu, giải quyết xung đột).
- Đắt hơn (tất cả các hệ thống chạy ở công suất tối đa).
✅ Sự khác biệt chính
| Tính năng | Active-Passive | Active-Active |
|---|---|---|
| Lưu lượng trong hoạt động bình thường | Chỉ hệ thống chính xử lý yêu cầu | Tất cả các nút xử lý yêu cầu |
| Thời gian failover | Vài giây đến vài phút | Gần như ngay lập tức (liền mạch) |
| Sử dụng tài nguyên | Hệ thống phụ chủ yếu không hoạt động | Tất cả tài nguyên được sử dụng |
| Chi phí | Thấp hơn | Cao hơn |
| Độ phức tạp | Đơn giản hơn | Phức tạp hơn (đồng bộ, định tuyến, xung đột) |
| Ví dụ trên AWS | Chính sách failover của Route 53 với vùng dự phòng | Chính sách độ trễ/địa lý của Route 53 với nhiều vùng |
📝 Ví dụ thực tế
Khối lượng công việc
- Ứng dụng thương mại điện tử → Nhóm EC2 Auto Scaling sau một ALB.
- Cơ sở dữ liệu → Cụm Aurora PostgreSQL.
Mục tiêu
- Chuẩn bị cho các sự cố toàn vùng.
- RTO = 30 phút.
- Hạ tầng DR không cần chạy trừ khi cần failover (do đó, hiệu quả chi phí rất quan trọng).
✅ Giải pháp DR được khuyến nghị (Active-Passive)
1. Hạ tầng vùng phụ
-
Lớp máy tính (EC2 + ALB)
- Triển khai cùng một cấu trúc (ALB + Nhóm Auto Scaling) trong một vùng AWS phụ, nhưng đặt:
- Công suất mong muốn =
0 - Công suất tối đa =
0 - Điều này đảm bảo không có phiên bản nào đang chạy trừ khi bạn kích hoạt failover, giúp giữ chi phí thấp.
-
Tăng cường trong sự kiện DR:
- Trong một sự kiện DR, bạn có thể điều chỉnh nhóm Auto Scaling để khởi chạy các máy chủ ứng dụng.
2. Lớp cơ sở dữ liệu (Aurora)
-
Chuyển cụm Aurora PostgreSQL chính thành Aurora Global Database:
- Vùng chính = cụm đọc/ghi.
- Vùng phụ = cụm chỉ đọc (tái tạo với độ trễ ~1 giây).
-
Trong kịch bản failover:
- Nâng cấp cụm DB phụ thành đọc/ghi.
- Chuyển hướng ứng dụng đến nó.
3. Failover DNS
- Sử dụng Amazon Route 53 với chính sách định tuyến failover active-passive:
- Điểm cuối chính = ALB trong vùng chính.
- Điểm cuối phụ = ALB trong vùng phụ.
- Cấu hình kiểm tra sức khỏe để Route 53 chỉ chuyển hướng lưu lượng đến ALB phụ khi vùng chính gặp sự cố.
4. Cân nhắc về RTO và RPO
-
RTO (Mục tiêu thời gian phục hồi)
- 30 phút có thể đạt được vì:
- Failover Route 53 = vài phút.
- Tăng cường ASG + khởi động ứng dụng = trong vài phút.
- Nâng cấp Aurora Global DB = vài phút.
-
RPO (Mục tiêu điểm phục hồi)
- Aurora Global Database cung cấp tái tạo độ trễ thấp, do đó mất dữ liệu là tối thiểu (vài giây).
🎯 Kiến trúc cuối cùng
-
Vùng chính:
- Nhóm EC2 ASG hoạt động + ALB.
- Aurora PostgreSQL (ghi).
-
Vùng phụ:
- Nhóm EC2 ASG dự phòng + ALB (công suất=0).
- Aurora Global Database (đọc, nâng cấp khi failover).
-
Failover:
- Kích hoạt Route 53 để chuyển DNS đến ALB phụ.
- Tăng cường nhóm EC2 ASG trong vùng phụ.
- Nâng cấp Aurora Global Database thành ghi.
✅ Giải pháp này đáp ứng các yêu cầu:
- RTO 30 phút → có thể đạt được.
- Chi phí vận hành thấp → hạ tầng DR chủ yếu không hoạt động cho đến khi cần.
- Tối ưu hóa chi phí → chỉ việc tái tạo Aurora chạy liên tục.
