Cloud liên vùng Bắc - Nam: thiết kế dự phòng cho hệ thống doanh nghiệp

Doanh nghiệp Việt Nam giờ có thể đặt hệ thống trên đám mây nội địa ở cả miền Bắc và miền Nam, để khi một vùng gặp sự cố, vùng còn lại tiếp quản. Câu hỏi thực tế không phải "có nên dùng liên vùng không" mà là dự phòng tới mức nào: chỉ sao lưu dữ liệu sang vùng kia, giữ sẵn hạ tầng chờ, hay chạy song song cả hai. Lựa chọn phụ thuộc vào thời gian hệ thống được phép ngừng và lượng dữ liệu được phép mất. Bài viết giúp bạn trả lời hai câu đó và chọn mô hình phù hợp ngân sách.

Hạ tầng liên vùng trong nước đã sẵn sàng tới đâu

Từ giữa năm 2024, VNG Cloud công bố hạ tầng đám mây liên vùng mà doanh nghiệp này gọi là đầu tiên của Việt Nam, đặt tại Hà Nội và TP.HCM. Theo Báo Đầu tư (28/6/2024), hệ thống có băng thông riêng giữa hai vùng tối đa 50 Gbps, lưu trữ NVMe tối đa 60.000 IOPS, cam kết uptime SLA tới 99,99%, cùng các dịch vụ sao lưu bất biến (Immutable Backup) và Kubernetes.

Đến 2026, mật độ trung tâm dữ liệu ở hai đầu đất nước tiếp tục tăng. Báo cáo BMI được TNGlobal dẫn ngày 20/7/2026 ước tính Việt Nam có khoảng 148 MW công suất đang vận hành, tập trung ở Hà Nội và TP.HCM, thị trường do Viettel, VNPT, FPT dẫn dắt; AWS đã mở Local Zone tại Hà Nội. Riêng TP.HCM có hơn 15 trung tâm dữ liệu đang hoạt động và chiếm khoảng 40% thị phần điện toán đám mây cả nước năm 2025, theo VnEconomy.

Nói cách khác, cặp Hà Nội - TP.HCM đã đủ lựa chọn nhà cung cấp để doanh nghiệp tự thiết kế dự phòng, kể cả trộn nhiều nhà cung cấp.

Bắt đầu từ hai con số: RTO và RPO

RTO (Recovery Time Objective) là thời gian tối đa hệ thống được phép ngừng. RPO (Recovery Point Objective) là lượng dữ liệu tối đa được phép mất, tính theo thời gian. Ví dụ RPO 1 giờ nghĩa là chấp nhận mất tối đa một giờ giao dịch gần nhất.

Hai con số này phải do bộ phận kinh doanh quyết định, không phải đội IT. Cách hỏi hiệu quả: "Nếu hệ thống bán hàng ngừng 4 giờ vào ngày cao điểm cuối năm, công ty mất bao nhiêu?" Câu trả lời bằng tiền giúp so sánh với chi phí dự phòng.

Bốn mô hình dự phòng liên vùng

Các mức RTO trong bảng là khoảng tham khảo theo thực tiễn ngành, thay đổi tùy kiến trúc và mức độ tự động hóa của từng hệ thống.

Khi nào chọn sao lưu liên vùng

Phù hợp với hệ thống nội bộ như quản lý tài liệu, phần mềm nhân sự, nơi ngừng nửa ngày không gây thiệt hại lớn. Điều kiện là bản sao lưu ở vùng kia phải bất biến, tức không bị xóa hay mã hóa nếu tài khoản chính bị chiếm, để chống ransomware.

Khi nào chọn pilot light hoặc warm standby

Phù hợp với phần lớn hệ thống bán hàng, ERP của doanh nghiệp vừa. Dữ liệu được sao chép gần thời gian thực, nên RPO nhỏ; khi sự cố xảy ra, chỉ cần bật hoặc mở rộng máy chủ ứng dụng và chuyển DNS.

Khi nào cần active - active

Dành cho dịch vụ không được phép ngừng như cổng thanh toán, ứng dụng ngân hàng. Kiến trúc phức tạp hơn nhiều vì phải xử lý xung đột dữ liệu khi hai vùng cùng ghi. Doanh nghiệp vừa hiếm khi cần mức này cho toàn bộ hệ thống; thường chỉ một vài dịch vụ lõi.

Những lỗi thiết kế thường gặp

• Dự phòng hạ tầng nhưng quên phụ thuộc bên ngoài. Hệ thống chuyển vùng thành công nhưng cổng SMS, cổng thanh toán hay dịch vụ xác thực chỉ cho phép IP của vùng cũ.
• DNS có thời gian lưu đệm dài. Đổi bản ghi rồi nhưng người dùng vẫn bị trỏ về vùng hỏng hàng giờ.
• Không bao giờ diễn tập. Kịch bản chuyển vùng nằm trong tài liệu nhưng chưa từng chạy, nên lần đầu thực hiện chính là lúc sự cố thật.
• Cùng một tài khoản quản trị cho hai vùng. Kẻ gian chiếm một tài khoản là xóa được cả hai nơi.

Lộ trình triển khai gợi ý

1. Liệt kê hệ thống, gán RTO và RPO cho từng hệ thống cùng bộ phận kinh doanh.
2. Nhóm hệ thống theo mô hình dự phòng phù hợp, không áp một mô hình cho tất cả.
3. Bắt đầu bằng sao lưu bất biến liên vùng cho mọi hệ thống, vì đây là lớp rẻ nhất và chống được ransomware.
4. Nâng dần các hệ thống quan trọng lên pilot light hoặc warm standby.
5. Diễn tập chuyển vùng ít nhất mỗi năm hai lần, đo RTO thực tế và so với mục tiêu.

Bài khôi phục sau thảm họa với giải pháp cloud đi sâu hơn vào quy trình DR. Nếu một phần hệ thống vẫn chạy tại phòng máy công ty, mô hình trong bài Hybrid Cloud giúp kết hợp hạ tầng tại chỗ làm một đầu dự phòng.

Thời điểm nên diễn tập

Tránh diễn tập vào tháng 12 và tháng trước Tết, khi lưu lượng giao dịch cao và nhân sự bận. Cuối tháng 11 hoặc sau Tết là khoảng thời gian hợp lý: đủ sớm để sửa lỗi trước mùa cao điểm tiếp theo, đủ yên để chấp nhận vài giờ thử nghiệm ngoài giờ làm việc.

Một buổi diễn tập có ích cần chuẩn bị trước bốn thứ: kịch bản từng bước có người phụ trách, tiêu chí dừng nếu có rủi ro ảnh hưởng khách hàng thật, đồng hồ bấm giờ ghi lại thời điểm từng mốc, và một người ghi chép mọi chỗ phải làm thủ công hoặc phải hỏi ý kiến. Danh sách thao tác thủ công sau buổi diễn tập chính là danh sách việc cần tự động hóa. Lần diễn tập thứ hai nên đo lại để thấy RTO thực tế đã giảm bao nhiêu so với lần đầu.