Chuyển VMware sang Proxmox trên Supermicro BigTwin

1. Vì sao doanh nghiệp chuyển VMware sang Proxmox VE

Từ năm 2024, nhiều doanh nghiệp tại Việt Nam tính lại bài toán ảo hóa khi mô hình cấp phép và chi phí gia hạn thay đổi. Proxmox VE là một hướng đi được cân nhắc nhiều: nền tảng mã nguồn mở gồm KVM, container LXC, Ceph tích hợp và HA trong cùng một giao diện quản trị; subscription tính theo từng socket CPU vật lý, không chia phiên bản tính năng và không tính theo nhân.

Tuy vậy, rời một nền tảng đã chạy nhiều năm không chỉ là cài hypervisor mới. Bài rời bỏ VMware cần chuẩn bị gì đã nêu các rủi ro ở cấp chiến lược. Bài này đi vào phần thực thi: làm thế nào để chuyển từng máy ảo một cách có kiểm soát, và chuẩn bị phần cứng đích ra sao.

2. Lộ trình chuyển VMware sang Proxmox theo năm giai đoạn

Chia dự án thành các giai đoạn có điểm kiểm tra rõ ràng giúp giảm rủi ro hơn nhiều so với chuyển một lần (Hình 1). Mỗi giai đoạn có đầu ra cụ thể trước khi sang bước sau.

• Khảo sát: kiểm kê VM, hệ điều hành, chế độ khởi động BIOS hay UEFI, số đĩa, snapshot, vTPM, mã hóa, VM nằm trên vSAN hay datastore thường, và các phụ thuộc giữa ứng dụng. Đo CPU, RAM, IOPS thực dùng thay vì cấu hình cấp phát.
• Thiết kế cụm đích: số node, Ceph hay storage ngoài, mạng tách riêng, Proxmox Backup Server. Phần này có thể tham khảo bài thiết kế cụm Proxmox VE với Ceph.
• PoC: chuyển thử vài VM đại diện, ghi lại các bước sửa driver, mạng, khởi động. Đây là nguồn để viết runbook cho các đợt sau.
• Chuyển theo đợt: nhóm môi trường thử nghiệm và ứng dụng nội bộ trước, hệ thống lõi như cơ sở dữ liệu hay core nghiệp vụ sau, mỗi đợt có kế hoạch quay lui.
• Vận hành: giám sát, lịch sao lưu, cập nhật từ kho Enterprise, rồi mới thu hồi host ESXi cũ.

3. Chuẩn bị cụm đích trên máy chủ Supermicro BigTwin

Nhiều dự án tận dụng lúc rời VMware để làm mới phần cứng: host ESXi cũ thường đã hết khấu hao hoặc hết bảo hành, trong khi cụm mới cần chạy song song một thời gian để chuyển dần. Dòng máy chủ Supermicro BigTwin phù hợp với vai trò cụm đích vì đặt bốn node hai CPU trong 2U, mỗi node có khay NVMe riêng cho Ceph.

Model SYS-222BT-HNR theo trang Supermicro có, cho mỗi node: 2 socket Intel Xeon 6700/6500 (P-core tới 86 nhân), 16 khe DIMM với tối đa 4 TB DDR5-6400, 6 khay 2,5″ NVMe PCIe 5.0 hot-swap, 2 khe M.2 NVMe, 2 khe PCIe 5.0 x16 low-profile và 1 khe AIOM (OCP 3.0). Bốn node hot-plug dùng chung bộ nguồn 2× 3600 W dự phòng 1+1 chuẩn Titanium.

Hình 2 là kiến trúc chuyển đổi tham chiếu: cụm ESXi cũ và cụm Proxmox VE mới chạy song song, nối với nhau qua mạng di chuyển, sao lưu đặt riêng trên Proxmox Backup Server.

Vì sao nên tính từ ba khung

Bốn node trong một khung BigTwin dùng chung nguồn, nên sự cố ở khung có thể làm mất cả bốn node cùng lúc. Với cụm Proxmox VE dựng trên BigTwin, có hai điểm cần thiết kế từ đầu:

• Ceph: nếu muốn cụm chịu được mất cả một khung, quy tắc CRUSH cần đặt miền lỗi theo khung (chassis) thay vì theo host; với 3 bản sao, cần ít nhất ba khung, và ba Ceph MON cũng nên đặt trên ba khung khác nhau.
• Quorum corosync: cụm 8 node chia đều trên hai khung sẽ mất quorum khi một khung dừng, vì chỉ còn đúng một nửa số phiếu. Cần khung thứ ba, hoặc một phiếu bầu bên ngoài (QDevice) đặt ngoài hai khung.

Về subscription, Proxmox tính theo mỗi socket CPU vật lý đang lắp: một khung BigTwin đủ bốn node hai CPU là 8 socket. Nếu tải cho phép, chọn node một CPU sẽ giảm số socket cần subscription. Cách sizing CPU, RAM cho node chạy cả VM và Ceph đã có trong bài máy chủ Supermicro cho Proxmox VE và Ceph. Mỗi node có 16 khe DIMM (1DPC), nên dung lượng RAM tính theo bội số 16 thanh, ví dụ 16 × 48 GB = 768 GB.

4. Bốn cách chuyển máy ảo từ VMware sang Proxmox VE

Theo thông cáo của Proxmox, trình nhập ESXi có sẵn từ Proxmox VE 8.2 (tháng 4/2024) và vẫn được cải tiến ở các bản 9.x; bản hiện hành là 9.2 (xem bài Proxmox VE 9.2). Ngoài trình nhập, tài liệu Proxmox còn mô tả các cách thủ công cho những trường hợp đặc biệt.

Cách 1: Import Wizard từ ESXi

Quản trị viên thêm host ESXi như một storage (Datacenter → Storage → Add → ESXi), nhập địa chỉ và tài khoản quản trị, chọn VM rồi bấm Import. Trình nhập cho chọn storage và bridge mạng đích, đổi storage cho từng đĩa, đổi kiểu card mạng, bỏ bớt đĩa hay card, và xem trước cấu hình VM mới ở tab Resulting Config. Ảnh 2 là tab General của trình nhập. Tài liệu Proxmox ghi đã thử nghiệm với ESXi từ 6.5 đến 8.0; có thể nhập qua vCenter nhưng tốc độ giảm mạnh, nên kết nối thẳng vào host ESXi.

Cách 2: Live-import để rút ngắn thời gian dừng

Với tùy chọn live-import, VM mới được khởi động ngay khi quá trình nhập còn đang chạy: phần dữ liệu hệ điều hành cần được chép trước, phần còn lại chép nền (Hình 3). VM nguồn vẫn phải tắt nên vẫn có thời gian dừng, chỉ ngắn hơn. IO lúc đầu chậm hơn, và nếu quá trình nhập lỗi thì mọi dữ liệu ghi từ lúc bắt đầu sẽ mất. Proxmox khuyến nghị thử trên VM thử nghiệm trước và tránh dùng qua mạng chậm hoặc dễ lỗi.

Cách 3: Xuất OVF hoặc nhập đĩa thủ công

Khi không kết nối trực tiếp được tới host, có thể xuất VM ra OVF bằng ovftool rồi dùng lệnh qm importovf, hoặc tạo VM trống và nhập từng đĩa bằng qm disk import qua một thư mục chia sẻ. Cách này chậm hơn và cần thêm dung lượng tạm, nhưng hữu ích cho VM nằm ở site khác hoặc đã xuất sẵn.

Cách 4: Gắn đĩa rồi di chuyển (attach disk & move)

Nếu hai nền tảng cùng mount được một storage dạng file (ví dụ NFS hoặc SMB), VM trên Proxmox có thể khởi động từ file đĩa -flat.vmdk của VMware, sau đó di chuyển đĩa sang storage đích khi VM đang chạy. Thời gian dừng gồm tắt VM trên ESXi và khởi động lại trên Proxmox; việc chuyển đĩa diễn ra khi VM đang chạy. Tài liệu Proxmox cảnh báo không được chạy VM trên cả hai nền tảng cùng lúc vì có thể hỏng đĩa.

5. Checklist trước và sau khi chuyển từng VM

Phần lớn sự cố sau chuyển đổi đến từ driver, mạng và chế độ khởi động, không phải từ bước chép đĩa. Checklist dưới đây tổng hợp từ hướng dẫn chính thức của Proxmox; Hình 4 tóm tắt các quyết định chính.

Với kiểu CPU của VM, tài liệu Proxmox khuyến nghị chọn host nếu mọi node có cùng model CPU, ngược lại chọn một mẫu chung x86-64-v<X> để vẫn live migration được giữa các node. Đây là lý do nên mua các node BigTwin cùng cấu hình CPU ngay từ đầu.

6. Sáu rủi ro cần lường trước khi chuyển VMware sang Proxmox

1. VM trên vSAN: trình nhập không đọc được đĩa nằm trên vSAN; phải chuyển đĩa sang datastore khác trước.
2. Đĩa mã hóa và vTPM: đĩa mã hóa bằng Storage Policy không nhập được, và trạng thái vTPM hiện chưa chuyển được. Nếu khóa mã hóa ổ đĩa trong khách lưu ở vTPM, cần chuẩn bị sẵn khóa khôi phục trước khi chuyển.
3. Snapshot: VM còn snapshot nhập chậm hơn đáng kể; nên hợp nhất snapshot trước.
4. Chạy song song quá nhiều: dịch vụ đọc đĩa từ ESXi giới hạn 4 kết nối song song, nên không nhập quá 4 đĩa cùng lúc. Bộ đệm đọc trước của mỗi đĩa dùng 8 khối 128 MiB, nhập nhiều đĩa có thể gây thiếu RAM trên node.
5. Tên datastore có ký tự đặc biệt như dấu cộng có thể làm nhập lỗi; đổi tên datastore thường xử lý được.
6. Thiếu kế hoạch quay lui: giữ VM nguồn ở trạng thái tắt cho tới khi ứng dụng trên Proxmox được nghiệm thu, và không bao giờ bật cùng lúc ở hai nơi.

7. Giải pháp tham chiếu: chuyển VMware sang Proxmox trên máy chủ Supermicro