Tại sao mình chọn vSphere Replication thay vì SRM?
Nếu anh em đang quản lý cụm 8-10 host ESXi như mình, bài toán khó nhất luôn là dự phòng thảm họa (Disaster Recovery – DR). Khi một Datacenter (DC) gặp sự cố, làm sao để hệ thống hoạt động lại nhanh nhất? VMware Site Recovery Manager (SRM) là cái tên đầu bảng, nhưng chi phí license vài nghìn USD mỗi năm là rào cản cực lớn với doanh nghiệp tầm trung.
Sau 6 tháng chạy thực tế trên môi trường production, mình nhận ra vSphere Replication (VR) là phương án thực dụng hơn hẳn. Nó đi kèm sẵn trong gói vSphere Essentials Plus trở lên. VR hỗ trợ đồng bộ máy ảo (VM) giữa hai site với chu kỳ từ 5 phút đến 24 giờ. Đặc biệt, anh em không cần đầu tư hệ thống lưu trữ (Storage) đồng nhất hay đắt tiền ở hai đầu.
Cơ chế của VR nằm ở tầng Hypervisor. Nó không quan tâm bên dưới là SAN, NAS hay Local Disk. Chỉ cần hai vCenter nhìn thấy nhau qua network là triển khai được ngay.
Quy trình triển khai Appliance vSphere Replication
Đầu tiên, anh em tải file OVF của VR Appliance từ Portal Broadcom (VMware cũ). Hãy kiểm tra kỹ ma trận tương thích (Interoperability Matrix) để đảm bảo bản VR khớp với bản vCenter hiện có.
Bước 1: Deploy Appliance
Tại vCenter site chính, hãy chuột phải vào Cluster và chọn Deploy OVF Template. Quá trình này tương tự như tạo một VM mới. Tuy nhiên, có 3 thông số anh em tuyệt đối không được cấu hình sai:
- IP Address: Phải đặt IP tĩnh. Nếu dùng DHCP, sau này Appliance đổi IP sẽ làm đứt toàn bộ kết nối đồng bộ.
- Password: Dùng cho tài khoản admin tại trang quản trị port 5480.
- Tài nguyên: Cấu hình mặc định 2 vCPU/4GB RAM có thể quản lý tới 2000 VM (trên bản 8.0). Nếu hệ thống nhỏ, mức này là quá đủ.
Bước 2: Kết nối (Pairing) hai Site
Sau khi dựng Appliance ở cả hai đầu, hãy truy cập vSphere Client, vào Site Recovery -> Open Site Recovery. Chọn New Site Pair để kết nối vCenter Site A và Site B.
# Đừng quên mở port firewall trước khi pair
# Port 8043: Quản trị VR
# Port 31031, 44046: Truyền nhận dữ liệu replication
telnet <Remote_VR_IP> 8043Khi thấy dấu tích xanh kèm trạng thái “Connected”, nghĩa là hai site đã bắt tay thành công.
Cấu hình chi tiết Replication cho máy ảo
Thực tế, không phải VM nào cũng cần đồng bộ 5 phút một lần. Mình thường phân loại như sau:
- Chuột phải vào VM cần bảo vệ -> Site Recovery -> Configure Replication.
- Target Site: Trỏ về site dự phòng đã kết nối.
- Replication Settings:
- RPO (Recovery Point Objective): Với Database quan trọng, mình để 15 phút. Với File Server hoặc Web tĩnh, 1 giờ đến 4 giờ là hợp lý để tiết kiệm băng thông.
- Point in Time (PIT) Instances: Tính năng này cực kỳ đáng tiền. Nó lưu lại các “mốc thời gian” cũ (tối đa 24 mốc). Nếu VM chính bị dính Ransomware, anh em có thể quay ngược thời gian về bản sạch trước đó.
- Network Compression: Hãy bật tính năng này nếu đường truyền WAN giữa 2 site yếu. Nó giúp giảm tới 30-50% lượng dữ liệu truyền tải.
Mẹo nhỏ: Nếu VM nặng vài TB, đừng dại mà đồng bộ qua mạng ngay từ đầu. Hãy dùng tính năng Seed. Bạn copy file vmdk sang site dự phòng trước bằng ổ cứng rời, sau đó cấu hình VR trỏ vào file đó để nó chỉ đồng bộ phần dữ liệu thay đổi (Delta).
Giám sát hệ thống bằng PowerCLI
Thay vì ngồi click từng VM để kiểm tra, mình dùng script PowerCLI để tự động gửi báo cáo mỗi sáng. Việc này giúp đảm bảo không có VM nào bị lỗi đồng bộ mà mình không biết.
# Kết nối vCenter
Connect-VIServer -Server vcenter.yourdomain.com
# Kiểm tra trạng thái replication
Get-VDXReplication | Select-Object Name, State, LastSyncTime, RPOStatus | Format-Table
# Ngắt kết nối
Disconnect-VIServer -Confirm:$falseNhững lưu ý “xương máu” khi vận hành
Sau nhiều lần diễn tập DR, mình rút ra 3 bài học quan trọng:
- Xử lý xung đột IP: Khi bật VM tại site dự phòng, nó vẫn giữ IP cũ. Nếu hai site khác lớp mạng, bạn phải vào phần IP Customization để cấu hình đổi IP tự động. Nếu không, VM lên nhưng dịch vụ vẫn chết vì không ai truy cập được.
- Dọn dẹp Snapshot: VR rất ghét các VM có snapshot tồn tại quá lâu. Hãy commit snapshot trước khi bật replication để tránh lỗi “Generic Error” khó chịu.
- Băng thông: Một VM Database có tốc độ ghi 10MB/s sẽ cần đường truyền cực lớn. Hãy tính toán kỹ chỉ số Change Rate của dữ liệu trước khi đặt RPO quá thấp.
Chốt lại, vSphere Replication không thay thế hoàn toàn cho Backup, nhưng nó là lớp bảo vệ cuối cùng cực kỳ tin cậy. Với doanh nghiệp không có ngân sách lớn cho SRM, VR chính là cứu cánh để đảm bảo hệ thống luôn sẵn sàng trước mọi thảm họa.
