Máy A đầy, máy B rảnh: gom máy chủ lẻ thành một cụm mà không mua thêm máy

Máy chủ A dùng 90% RAM, máy chủ B kế bên dùng 20%, và không ai dời được VM từ A sang B vì đĩa của VM nằm trong máy A. Đề xuất mua thêm máy đã có trên bàn, dù tổng công suất phòng máy vẫn dư. Câu hỏi thật không phải “mua máy gì” mà là “ghép máy đang có thành một pool bằng cách nào”. Bài này đi qua năm triệu chứng của hạ tầng ốc đảo, điều kiện để gom, chọn Proxmox cụm hay OpenStack theo quy mô, và cách gom theo đợt bằng máy đang có.

Năm triệu chứng của hạ tầng ốc đảo

Hạ tầng ốc đảo không hình thành vì ai đó làm sai: mỗi dự án mới mua một máy, cài Proxmox hoặc ESXi, tạo VM trên đĩa cục bộ rồi bàn giao. Vài năm sau, phòng máy có 10–40 máy, mỗi máy một hệ thống riêng, với năm triệu chứng đi cùng nhau.

Triệu chứng	Nguyên nhân kỹ thuật	Hệ quả vận hành
Máy A đầy, máy B rảnh	Đĩa VM nằm trên ổ cục bộ từng máy	Mua máy mới khi tổng công suất còn dư
Hỏng một máy là mất một đêm	Không có bản sao đĩa ở máy khác	Dừng tính bằng giờ, phụ thuộc người trực
Dời VM phải hẹn giờ tắt	Máy đích không đọc được đĩa máy nguồn	Bảo trì phần cứng thành việc đêm cuối tuần
Tạo VM mất vài ngày	Chọn máy bằng tay, dò chỗ trống từng máy	Đội ứng dụng chờ hoặc xin máy riêng
Mỗi máy giám sát một kiểu	Mỗi máy là một hypervisor độc lập	Không biết “cả phòng máy còn bao nhiêu”

Nguyên nhân chung nằm ở cột giữa: đĩa của VM gắn chặt vào máy đang chạy nó.

Pool tài nguyên chung nghĩa là gì về mặt kỹ thuật

Cloud là cách vận hành, không phải nơi thuê. Về kỹ thuật, một pool chung khác máy lẻ ở bốn điểm:

• Đĩa tách khỏi máy. Đĩa VM nằm trên Ceph, compute chỉ còn là nơi mượn CPU và RAM. Theo tài liệu Ceph, VM boot được thẳng từ Ceph và mỗi volume được trải lên nhiều OSD.
• Chọn host không còn phụ thuộc vào đĩa. Trên OpenStack, Nova chọn host; trên Proxmox cụm, người vận hành chọn node, nhưng node nào cũng chạy được vì đĩa ở chung.
• VM chạy lại nơi khác khi host lỗi. Proxmox HA khởi động lại VM trên node khác, với thời gian phát hiện lỗi và failover điển hình khoảng 2 phút theo tài liệu. OpenStack có nova evacuate dựng lại instance trên host khác khi host nguồn đã dừng hẳn, giữ nguyên ID, tên và IP; dữ liệu đĩa chỉ giữ được khi có storage chung.
• Một chỗ nhìn toàn cụm. Một API, một câu trả lời cho “còn bao nhiêu”.

Cái giá phải trả: thêm một lớp phần mềm nằm dưới mọi VM, và đội phải học lớp đó.

Điều kiện phần cứng để gom

Gom máy đang có không cần máy mới, nhưng máy phải đạt vài điều kiện, theo tài liệu Ceph và Proxmox:

• Ít nhất ba máy. Ceph khuyến nghị cụm production có ít nhất ba monitor, vì quorum cần đa số (2 trên 3, 3 trên 5). Proxmox cũng cần ít nhất ba node để quorum tin cậy (mất quorum là cụm chuyển sang chỉ đọc), và khuyến nghị thêm ít nhất 12 OSD chia đều giữa các node cho Ceph.
• Mỗi ổ đĩa một OSD, bỏ RAID bên dưới. Tài liệu Ceph khuyến nghị một ổ riêng cho hệ điều hành và một ổ cho mỗi OSD, và không cần card RAID vì HBA chế độ IT/JBOD có độ trễ thấp hơn. Proxmox viết gọn: tránh RAID controller, dùng HBA.
• RAM dành riêng cho Ceph. Mỗi OSD BlueStore mặc định dùng 4 GB (osd_memory_target), tài liệu khuyên dự phòng khoảng 8 GB mỗi OSD. Máy có 8 ổ làm OSD cần ≈64 GB RAM cho Ceph trước khi tính RAM cho VM.
• Mạng 10 Gbps trở lên. Ceph khuyến nghị ít nhất 10 Gbps giữa các host Ceph và giữa client với cụm; Proxmox khuyến nghị 10 Gbps dành riêng cho Ceph. Băng thông này gánh cả traffic client lẫn replication và recovery, nên hai cổng 1 Gbps trên máy lẻ không đủ.
• Máy không đồng nhất vẫn gom được. Ceph tự gán class hdd, ssd hoặc nvme cho từng OSD và CRUSH rule giới hạn được một pool vào một class, nên máy SSD và máy HDD ở cùng một cụm nhưng phục vụ hai pool khác nhau. Về compute, OpenStack có host aggregate để nhóm host theo phần cứng.

Lưu ý Máy quá cũ không phải lúc nào cũng nên vào pool. Máy hết slot cho NIC 10 GbE, không gắn thêm được RAM, hoặc ổ đĩa không có power loss protection, thứ tài liệu Ceph khuyến nghị cho production, thường tốn công đưa vào nhiều hơn giá trị nó đóng góp. Để ngoài cụm làm máy test thì hơn.

Proxmox cụm với Ceph, hay OpenStack

Nếu máy của bạn đang chạy Proxmox, câu hỏi tự nhiên là: Proxmox có cụm, có Ceph tích hợp, có HA, cần gì OpenStack? Với nhiều đội, câu trả lời là chưa cần.

Vài mốc tại thời điểm viết: Proxmox VE 9.0 (5/8/2025, Debian 13) đóng gói Ceph Squid 19.2.3, còn dòng Ceph mới nhất là Tentacle 20.2.0 (18/11/2025); Proxmox Datacenter Manager 1.0 (4/12/2025) quản lý nhiều cụm từ một giao diện. Proxmox cụm với Ceph giải quyết được phần lớn năm triệu chứng: đĩa ở RBD nên dời VM là live migration, HA khởi động lại VM trên node khác, một giao diện cho cả cụm.

Triệu chứng còn lại, tạo VM mất vài ngày vì mọi yêu cầu qua tay đội hạ tầng, là chỗ OpenStack khác biệt: nó được thiết kế cho nhiều đội dùng chung một hạ tầng. Bộ tối thiểu theo install guide gồm Keystone, Glance, Placement, Nova, Neutron. Control plane cần số node lẻ: theo tài liệu kolla-ansible, hai node không cho HA vì quorum cần đa số, ba node chịu được một node hỏng.

Tiêu chí	Proxmox cụm + Ceph	OpenStack + Ceph
Quy mô bắt đầu	3 node	3 node control plane + compute + Ceph
Ai tạo VM	Đội hạ tầng tạo hộ	Mỗi đội tự tạo qua API trong project riêng, có quota theo project và user
Object storage S3	Ceph RGW, dựng thêm	Ceph RGW, tương thích S3 và Swift
Mạng theo đội	Quản trị viên cấu hình chung	Neutron: mạng, router, security group theo project
Phải học	Proxmox và Ceph	Ceph và control plane nhiều dịch vụ

Ngưỡng chúng tôi dùng khi rà soát: dưới ≈5 máy và một đội dùng, Proxmox cụm với Ceph thường là câu trả lời đúng, kể cả khi bạn hỏi CloudMaster. Từ hàng chục máy, nhiều đội dùng chung, cần S3 và API để đội ứng dụng tự tạo môi trường, OpenStack bắt đầu có lý. Cả hai đều đứng trên Ceph, nên bước gom đĩa vào Ceph đúng với cả hai hướng.

Giới hạn Ngưỡng ≈5 máy và “hàng chục máy” là kinh nghiệm dự án của CloudMaster, không phải quy tắc trong tài liệu. Bài chưa đo hiệu năng Ceph trên hai nền tảng với cùng một bộ máy, nên bảng trên so mô hình vận hành, không so tốc độ.

Gom theo đợt bằng máy đang có

Cụm không dựng trong một ngày, và không cần dừng hệ thống đang chạy:

1. Giải phóng ba máy đầu tiên. Dời tạm VM trên ba máy ít tải nhất sang các máy còn lại, rồi cài lại chúng thành ba node Ceph đầu tiên, monitor trên cả ba; đi OpenStack thì chúng chạy luôn control plane, đi Proxmox thì là ba node đầu của cụm. Với replica 3 (mặc định của Ceph lẫn Proxmox) và failure domain theo host, CRUSH đặt mỗi bản sao lên một host khác nhau; cái giá là dung lượng thô gấp ba dung lượng dùng được.
2. Chuyển nhóm VM dễ trước. VM không trạng thái, môi trường test. VM từ Proxmox đã chạy trên QEMU/KVM với driver virtio: tắt VM, chuyển đĩa sang raw bằng qemu-img convert (tài liệu Ceph cho OpenStack nói rõ không nên dùng QCOW2 trên Ceph), tạo volume, bật lên. VM từ ESXi cần virt-v2v hoặc công cụ chuyển ấm, đã so trong bài năm công cụ chuyển VM từ VMware.
3. Máy vừa trống thì cài lại, thêm vào cụm. Mỗi máy trống thành compute hoặc node Ceph tùy số ổ. Từ đây dời VM giữa host là live migration. Nova có ba dạng live migration: đĩa ephemeral trên storage chung, block migration khi đĩa không chia sẻ, và volume-backed; đĩa đã ở Ceph thì bạn rơi vào dạng đầu hoặc dạng cuối, không phải chép đĩa.
4. Nhóm khó để cuối. Database, VM Windows nhiều đĩa, VM gắn IP cố định hay license theo phần cứng, khi runbook đã chạy thật và đội đã quen Ceph.

Mỗi đợt thường kéo dài vài tuần, phần lớn là chờ cửa sổ bảo trì; chuyển đồng loạt lên cụm ba node chưa có tải thật là tự bỏ đường lùi. Đội 2–4 người giỏi Linux là đúng đội cho việc này: Linux, mạng, quy trình thay đổi vẫn dùng nguyên, học thêm Ceph và, nếu đi OpenStack, control plane nhiều dịch vụ. Vài đợt đầu nên có người từng làm đi cùng; trong ba mô hình của CloudMaster, đồng vận hành rồi chuyển giao là lộ trình hay gặp, xem ba mô hình vận hành.

Ví dụ: Pancake bắt đầu với 10 node

Pancake rời Google Cloud từ 2019, bắt đầu với 10 node: 2 controller, 3 compute, 5 node Ceph. Hiện cụm có 139 node vật lý và 5,6 PB. Từ 10 lên 139 là thêm node vào cùng một cụm, không dựng cụm mới. Theo CTO Pancake: “Năm 2019 chúng tôi bắt đầu với 10 node để thử, giờ là 139. Điều đáng giá nhất không chỉ là hóa đơn giảm khoảng 80%, mà là biết trước chi phí: người dùng tăng thì mình lên kế hoạch mua máy, không còn bất ngờ khi nhận hóa đơn.”

Giới hạn của ví dụ Pancake đi từ public cloud về, không từ máy lẻ, nên không có bước giải phóng ba máy đầu hay VM chuyển từ hypervisor cũ. Điểm giống là cùng bắt đầu nhỏ và thêm node vào một pool. Số liệu do khách hàng cung cấp, CloudMaster không đo độc lập.

Việc cần làm trước khi gom

1. Xuất danh sách máy chủ: model, CPU, RAM, số và loại ổ, cổng mạng, năm mua; từ vCenter dùng RVTools, từ Proxmox xuất danh sách node và VM.
2. Đo mức dùng thật trong 2 tuần: CPU, RAM, IOPS, băng thông, vì số cấp phát và số chạy thật thường khác xa.
3. Liệt kê VM và phụ thuộc: VM nào gọi VM nào, VM nào cần IP cố định, cửa sổ bảo trì dài bao lâu.
4. Kiểm tra switch: còn bao nhiêu port 10 GbE, máy nào còn slot cho NIC.
5. Chọn ba máy giải phóng đầu tiên và nhóm VM đợt 1; kiểm tra các máy còn lại đủ chỗ nhận VM dời tạm.
6. Chọn hướng nền tảng theo bảng trên; lựa chọn này đổi được về sau vì cả hai hướng cùng dùng Ceph.

Nếu muốn một góc nhìn từ ngoài, gửi danh sách máy chủ (CSV từ vCenter, RVTools hoặc Proxmox) qua form rà soát; kỹ sư CloudMaster trả lại nhận định sơ bộ về phần nên gom, phần nên để ngoài và hướng nền tảng phù hợp.