Xây dựng Disaster Recovery cho Proxmox VE với LINSTOR & DRBD Proxy – Giải pháp “bọc thép” cho hạ tầng multi-site

Giới thiệu

Trong kỷ nguyên số, dữ liệu chính là mạch máu của doanh nghiệp. Việc triển khai một cụm Proxmox VE có tính sẵn sàng cao (High Availability – HA) trong cùng một Data Center (DC) gần như đã trở thành tiêu chuẩn. Tuy nhiên, HA chỉ giúp bạn chịu lỗi ở mức node hoặc storage, chứ không bảo vệ được khi toàn bộ DC gặp sự cố như: cháy nổ, thiên tai, mất điện diện rộng hay đứt kết nối backbone.

Khi đó, bài toán Disaster Recovery (DR) – khôi phục hệ thống ở một site vật lý khác – trở nên bắt buộc.

Trong cộng đồng Proxmox, nhiều quản trị viên thường nghĩ ngay đến Ceph Mirroring. Đây là một tính năng mạnh, nhưng trong thực tế triển khai DR đa site, Ceph vẫn tồn tại nhiều hạn chế:

• Độ trễ (Latency): Ceph yêu cầu băng thông lớn và độ trễ rất thấp để duy trì trạng thái ổn định.
• Failback phức tạp: Failover có thể thực hiện được, nhưng quá trình failback (quay lại site chính) thường rủi ro, dễ phát sinh split-brain hoặc phải cấu hình lại thủ công.
• Thiếu tối ưu WAN: Ceph không có cơ chế nén, buffer hay tối ưu luồng dữ liệu cho khoảng cách xa như DRBD Proxy.

Trong bài viết này, tôi sẽ chia sẻ cách xây dựng một giải pháp DR “bọc thép” cho Proxmox VE bằng cách kết hợp LINSTOR + DRBD Proxy, giúp quá trình Failover và Failback trở nên mượt mà, kiểm soát được và an toàn hơn rất nhiều.

Kiến trúc & Prerequisites

Để triển khai đúng kịch bản DR, bạn cần chuẩn bị:

• Hạ tầng

  • 02 Site vật lý độc lập (DC-A và DC-B)
  • Mỗi site gồm 01 cụm Proxmox VE gồm 3 node

• Phần mềm

  • 01 LINSTOR Controller dùng chung cho cả 2 site

• Kết nối

  • Đường truyền WAN ổn định giữa 2 site, đủ cho replication (có thể latency cao)

Cấu hình LINSTOR cho Disaster Recovery

Bước 1: Định danh Site bằng Auxiliary Properties

Trước tiên, chúng ta cần cho LINSTOR biết node nào thuộc site nào. Việc này được thực hiện bằng cách gán Auxiliary Properties cho từng node.

• Site chính: site=dc-a
• Site DR: site=dc-b

Cách làm này giúp LINSTOR phân biệt ranh giới vật lý giữa các DC, thay vì coi toàn bộ cluster là một vùng đồng nhất.

Bước 2: Quản lý vị trí dữ liệu với Resource Groups

Tiếp theo, chúng ta tạo Resource Group riêng cho từng DC, ví dụ:

• thinpool-dc-a
• thinpool-dc-b

Với cách này:

• Khi VM được tạo ở Site A, LINSTOR sẽ chỉ tạo replica trên các node thuộc DC-A
• Đảm bảo hiệu năng đọc/ghi nội bộ tốt nhất
• Tránh việc dữ liệu “vô tình” bị phân tán sang site DR

Bước 3: Tắt Auto-Tiebreaker và Auto Balancing

Trong mô hình DR đa site, tự động không phải lúc nào cũng tốt.

Vì vậy, cần:

• Tắt Auto-Tiebreaker
• Tắt BalanceResourcesEnabled

Điều này giúp:

• Tránh việc LINSTOR tự ý di chuyển replica giữa 2 site khi mạng WAN chập chờn
• Đảm bảo toàn bộ luồng DR đều nằm trong tầm kiểm soát của người vận hành

Bước 4: Cấu hình DRBD Proxy & Site-aware Replication

Sau khi đã định danh site cho từng node, ta cấu hình để:

• Tự động bật DRBD Proxy khi replica nằm ở 2 site khác nhau
• Sử dụng replication asynchronous để chịu được latency cao

Bước 5: Cấu hình DRBD Options cho DR

Với các resource dùng cho DR:

• Bắt buộc tắt allow-two-primaries
• Phù hợp với replication async + DRBD Proxy
• Tránh split-brain trong kịch bản WAN

Bước 6: Gán replica DR thủ công

Cuối cùng, để tạo bản sao DR cho disk của VM:

• Thực hiện manual assign replica sang node ở site DR

LINSTOR sẽ bắt đầu quá trình resync nền. Khi hoàn tất, VM đã sẵn sàng để failover sang site DR.

Cấu hình Proxmox VE cho DR

Bước 1: Cấu hình Storage theo từng Site

Mỗi Proxmox cluster:

• Chỉ sử dụng Resource Group tương ứng với site
• Cấu hình khác nhau trong /etc/pve/storage.cfg

Bước 2: Phân chia dải VM ID

Để tránh trùng VM ID giữa 2 site:

• DC-A: VM ID 100–199
• DC-B: VM ID 200–299

Bước 3: Đồng bộ file cấu hình VM sang site DR

Proxmox không tự đồng bộ file cấu hình VM, vì vậy cần:

• Dùng rsync để copy file config từ site primary sang DR
• Ở ví dụ này tôi sẽ manual copy file config của VM sang cụm Proxmox DR, các cấu hình VM trong proxmox được lưu trữ tại thư mục /etc/pve/qemu-server/104.conf

Bước 4: Điều chỉnh Network & Storage mapping

Sau khi copy file cấu hình vào dr-node ta tiến hành điều chỉnh lại 1 số thông số mapping với cấu hình của cụm DR

• Nếu bridge khác tên → chỉnh lại bridge=vmbrX
• Nếu storage plugin khác tên → chỉnh lại scsiX

Test Failover & Failback

• Tạo file test tại Site A

• Shutdown VM tại Site A

• Kiểm tra LINSTOR không còn primary

• Bật VM tại site DR, kiểm tra primary mới, thực hiện switch DR thành công

• Kiểm tra dữ liệu, tạo thêm file test failback

• Shutdown VM tại DR và bật lại site primary → dữ liệu sync đầy đủ

Kết luận

Với LINSTOR + DRBD Proxy, chúng ta có được:

• DR đa site thực thụ cho Proxmox VE
• Replication chịu được latency cao
• Failover & Failback chủ động, kiểm soát được
• Tránh được nhiều rủi ro mà Ceph Mirroring gặp phải

Nếu bạn đang vận hành Proxmox ở quy mô production và DR là yêu cầu bắt buộc, đây là một kiến trúc rất đáng để cân nhắc. Bài viết này mô tả và chứng minh quá trình DR cơ bản nhất, trong thực tế, tùy thuộc vào độ phức tạp ứng dụng của tổ chức mà kịch bản DR sẽ phức tạp hơn rất nhiều bao gồm cả các yếu tố về network, DNS,... Hy vọng với phương pháp mà bài viết mang lại, các bạn có thể xây dựng được một hệ thống DR hoàn chỉnh cho hệ thống IT doanh nghiệp của mình trên mã nguồn mở Promox và LINSTOR.