Khi Backup thôi là chưa đủ
Nếu chỉ trông chờ vào backup truyền thống, anh em sẽ “toát mồ hôi hột” khi cả trung tâm dữ liệu sập nguồn. Mình từng chứng kiến một khu công nghiệp tại Bình Dương gặp sự cố trạm điện, khiến datacenter tê liệt hơn 12 tiếng. Lúc đó, dù có bản backup trong tay, việc khôi phục thủ công 200 máy ảo (VM) sang site dự phòng là nhiệm vụ bất khả thi. RTO vọt lên tận 24 giờ, vượt xa mức 4 giờ cam kết trong SLA. Đó là bài học đắt giá khiến mình phải triển khai ngay VMware Site Recovery Manager (SRM).
Hiện mình đang quản lý cụm 8 host ESXi chạy vSphere 7.0 U3. SRM không trực tiếp copy dữ liệu, nó giống như một “vị tổng chỉ huy” điều phối việc khôi phục. Thay vì phải thức đêm bật từng VM, sửa IP hay kiểm tra thứ tự khởi động, anh em chỉ cần một cú click chuột để SRM tự động hóa toàn bộ quy trình.
Các khái niệm cốt lõi cần nắm vững
Để không bị rối khi cấu hình, hãy nhớ nhanh 4 thành phần này:
- Protected & Recovery Site: Hiểu đơn giản là Site chính (đang chạy) và Site dự phòng (đợi sẵn).
- vSphere Replication (VR): “Cánh tay phải” giúp đẩy dữ liệu VM sang site kia. Nếu dùng SAN cao cấp, anh em có thể tận dụng Array-Based Replication.
- Protection Groups: Gom các VM liên quan lại một nhóm. Ví dụ: Cụm Database và App của phần mềm kế toán phải đi cùng nhau.
- Recovery Plans: Cuốn “kịch bản” chi tiết. Nó quyết định con nào lên trước, con nào lên sau và đổi IP thế nào.
Quy trình triển khai thực tế
1. Chuẩn bị hạ tầng
Anh em cần có vCenter ở cả hai đầu. Kinh nghiệm của mình là hãy cài phiên bản SRM tương đồng để tránh lỗi API ngớ ngẩn. Đừng quên mở sẵn các port quan trọng như 8123 (VR traffic), 44046 (VR management) và 636 (SRM communication). Nếu firewall chặn các port này, việc kết nối giữa hai site sẽ thất bại ngay lập tức.
2. Cài đặt và Pairing
SRM hiện nay chạy trên nền Appliance (Photon OS) nên cài rất nhanh, mất tầm 15 phút. Sau khi cài xong, anh em tiến hành “Site Pairing”. Đây là bước làm quen, thiết lập lòng tin giữa hai vCenter.
# Kiểm tra kết nối SRM nhanh qua PowerCLI
Connect-SrmServer -RemoteServer <IP_vCenter_Du_Phong>
$srmApi = $global:SrmConnection.Extension
$srmApi.Runtime.ConnectionStatus3. Cấu hình Inventory Mappings
Đây là bước dễ sai nhất. Mappings giúp SRM hiểu: “Nếu VM ở Site A dùng VLAN 10, thì sang Site B phải nhảy vào VLAN 110”. Hãy rà soát kỹ 4 mục: Network, Folder, Resource và Storage Policy. Chỉ cần lệch một mapping, VM khi bật lên ở site dự phòng sẽ bị “mồ côi” mạng hoặc thiếu tài nguyên.
4. Tạo Protection Groups và Recovery Plans
Khi dữ liệu đã đồng bộ xong, hãy đưa VM vào Protection Groups. Tại đây, mình thường chia theo mức độ ưu tiên (Priority Groups). Database phải được ưu tiên số 1, lên trước để sẵn sàng phục vụ. Sau đó mới đến Application (Priority 3) và cuối cùng là Web Server (Priority 5). Cách làm này giúp ứng dụng không bị lỗi “Connection Timeout” khi khởi động lại đồng loạt.
Thử nghiệm (Testing) – Đừng đợi đến lúc cháy mới tìm vòi nước
Một hệ thống DR không được test định kỳ chỉ là một hệ thống “nằm trên giấy”. Điểm sáng nhất của SRM là tính năng Test Recovery. Nó tạo ra một môi trường mạng cô lập (Bubble Network) ở site dự phòng. SRM sẽ clone các VM từ bản replica mới nhất để chạy thử mà không hề ảnh hưởng đến hệ thống thật ở site chính.
Tại công ty mình, mỗi quý cả team đều chạy Test một lần. Có lần test mới lòi ra việc license phần mềm bị khóa do ID phần cứng ảo thay đổi, hoặc DNS nội bộ chưa trỏ kịp. Nhờ phát hiện sớm, tụi mình đã bổ sung script xử lý vào Recovery Plan để mọi thứ trơn tru khi có sự cố thật.
Kinh nghiệm xương máu để tránh ‘mất ngủ’
Sau nhiều dự án, mình rút ra 3 lưu ý quan trọng:
- DNS là mấu chốt: VM đổi IP thì DNS phải đổi theo. Hãy dùng script cập nhật Dynamic DNS ngay trong bước hậu khôi phục (Post-power on steps).
- Băng thông Replication: Đừng chủ quan. Nếu tốc độ thay đổi dữ liệu (Churn rate) là 100GB/ngày mà đường truyền chỉ có 10Mbps, RPO của anh em sẽ bị trễ (Lag) hàng tiếng đồng hồ.
- License vCenter: Hãy cài đặt cảnh báo (Alarm) khi license SRM sắp hết hạn. Nếu license chết, toàn bộ việc bảo vệ các nhóm VM sẽ bị ngắt kết nối lập tức.
Kết luận
VMware SRM có thể khiến anh em hơi rối ở bước Mapping ban đầu. Tuy nhiên, khi đã làm chủ được nó, anh em sẽ nắm trong tay quyền năng cực lớn. Nó biến quy trình khôi phục thủ công đầy rủi ro thành một kịch bản tự động hóa chính xác. Đầu tư thời gian cho SRM hôm nay chính là cách tốt nhất để bảo vệ uy tín của team IT trước các sếp khi có sự cố ngặt nghèo xảy ra.
