Triển khai Proxmox VE với Ceph: thiết kế cụm 3 node trở lên

Cloud • Proxmox VE • Ceph HCI

Triển khai Proxmox VE với Ceph cho phép doanh nghiệp dựng cụm ảo hóa siêu hội tụ (HCI) mà không cần SAN riêng, nhưng cụm chạy ổn định hay không được quyết định ngay ở khâu thiết kế. Bài viết đi qua bốn quyết định quan trọng nhất: số node, cách tách mạng, phần cứng cho Ceph OSD và dư địa dung lượng, kèm cách tính minh họa để đội hạ tầng tự kiểm tra cấu hình trước khi mua. Nếu cần một đơn vị đồng hành, CSC cung cấp dịch vụ triển khai Proxmox với tư cách đối tác ủy quyền cao cấp của Proxmox.

IT ManagerSystem / InfraĐội vận hành ảo hóaCTO / CIOBFSI • Giáo dục • Sản xuất

1. Khi nào nên triển khai Proxmox VE với Ceph?

Proxmox VE tích hợp sẵn Ceph: cài, tạo monitor, OSD và pool ngay trên giao diện quản trị hoặc bằng lệnh pveceph. Mỗi node vừa chạy máy ảo vừa góp ổ đĩa vào một kho lưu trữ chung, dữ liệu được sao chép giữa các node. Mô hình này phù hợp khi:

Không SAN

Bỏ tủ đĩa trung tâm

Doanh nghiệp muốn rời mô hình máy chủ + SAN, mở rộng bằng cách thêm node thay vì nâng cấp tủ đĩa.

HA, live migration

Lưu trữ dùng chung

Ceph RBD cho phép di chuyển máy ảo giữa các node và tự khởi động lại máy ảo khi một node hỏng.

SDS

Không phụ thuộc hãng

Phần cứng x86 tiêu chuẩn, phần mềm mã nguồn mở, subscription theo socket CPU thay vì theo core.

Ngược lại, nếu chỉ có hai máy chủ, hoặc ứng dụng cần độ trễ lưu trữ cực thấp ở mức cơ sở dữ liệu giao dịch lớn, nên cân nhắc thêm phương án storage ngoài (NVMe/TCP, SAN sẵn có) gắn vào Proxmox. Phần còn lại của bài tập trung vào cụm HCI 3 node trở lên.

2. Kiến trúc tham chiếu một cụm Proxmox Ceph

Một cụm HCI điển hình gồm các node giống nhau. Trên mỗi node có máy ảo và container, các OSD (mỗi ổ đĩa một OSD), cùng các dịch vụ Ceph Monitor và Manager. Tài liệu Proxmox khuyến nghị tối thiểu 3 node, nên giống nhau, và ít nhất 12 OSD chia đều giữa các node (Hình 1).

Kiến trúc tham chiếu cụm Proxmox VE + Ceph 3 nodeNode 1Node 2Node 3Proxmox VE 9.2Proxmox VE 9.2Proxmox VE 9.2VM · ContainerVM · ContainerVM · ContainerOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDCeph MONCeph MGRCeph MONCeph MGRCeph MONCeph MGRHBA, NVMe/SSD doanh nghiệpHBA, NVMe/SSD doanh nghiệpHBA, NVMe/SSD doanh nghiệpCorosync (cluster)NIC riêng ≥ 1 Gbps · 2 link knet · độ trễ < 5 msCeph public≥ 10 Gbps riêng cho Ceph · NVMe nên ≥ 25 GbpsCeph clustersao chép và phục hồi dữ liệu giữa OSDMạng VM, người dùngbridge/VLAN cho máy ảo, có thể kèm migration
Hình 1. Kiến trúc tham chiếu cụm Proxmox VE + Ceph 3 node, mỗi node 4 OSD (tổng 12 OSD). Chấm xanh lá là dữ liệu sao chép giữa các node qua mạng Ceph cluster; chấm xám là nhịp tim corosync trên mạng riêng.

3. Cần bao nhiêu node cho cụm Proxmox Ceph?

Hai con số chi phối thiết kế là quorum của cụm Proxmox và số bản sao của Ceph.

  • 3 node là mức tối thiểu cho HA và Ceph. Tài liệu Proxmox yêu cầu ít nhất 3 node để có quorum tin cậy, và ít nhất 3 monitor để Ceph có tính sẵn sàng cao. Với cụm nhỏ và vừa, 3 monitor là đủ.
  • Cụm 2 node cần thêm QDevice (một máy nhỏ bên ngoài giữ phiếu thứ ba) để giữ quorum. Proxmox hỗ trợ QDevice cho cụm có số node chẵn và không khuyến nghị dùng cho cụm số node lẻ. Tuy vậy, Ceph với 3 bản sao vẫn cần 3 node chứa dữ liệu, nên cụm 2 node không phải là mô hình HCI Ceph đúng nghĩa.
  • 4–5 node trở lên giúp cụm chịu lỗi tốt hơn: khi một node hỏng, dữ liệu còn chỗ để tái tạo đủ 3 bản sao trên các node còn lại. Với cụm 3 node, khi mất một node, cụm vẫn chạy nhưng ở trạng thái thiếu bản sao cho tới khi node quay lại.
Gợi ý số node theo nhu cầu (tham khảo, cần sizing chi tiết)
Quy mô Mô hình Ưu điểm Lưu ý
Chi nhánh, môi trường thử nghiệm 2 node + QDevice, storage cục bộ hoặc ngoài Chi phí thấp, vẫn có quorum Không phải HCI Ceph; HA phụ thuộc storage dùng chung
Cụm production đầu tiên 3 node HCI, ≥ 12 OSD Mức tối thiểu khuyến nghị cho HA và Ceph Mất 1 node: chạy ở trạng thái thiếu bản sao
Hạ tầng ảo hóa chính của doanh nghiệp 4–7 node HCI Tự phục hồi đủ 3 bản sao khi mất 1 node, bảo trì luân phiên dễ hơn Cần dư địa dung lượng cho phục hồi (mục 6)

4. Thiết kế mạng: tách bốn luồng lưu lượng

Phần lớn sự cố của cụm Proxmox Ceph mà đội hạ tầng gặp phải bắt nguồn từ mạng. Tài liệu Proxmox nêu rõ các nguyên tắc sau:

  1. Corosync đi mạng riêng. Proxmox khuyến nghị một NIC vật lý riêng cho lưu lượng cluster, độ trễ giữa các node dưới 5 ms, và đặc biệt không dùng chung mạng cho corosync và storage. Corosync hỗ trợ nhiều link qua Kronosnet, nên cấu hình ít nhất 2 link trên hai mạng vật lý khác nhau; mạng storage chỉ nên là link dự phòng ưu tiên thấp.
  2. Ceph cần tối thiểu 10 Gbps dành riêng. Tài liệu Proxmox lưu ý một ổ NVMe hiện đại có thể làm bão hòa 10 Gbps, nên cụm NVMe nên dùng tối thiểu 25 Gbps, và có thể cần 40 Gbps hoặc 100 Gbps trở lên.
  3. Tách Ceph public và Ceph cluster. Mạng cluster riêng gánh lưu lượng sao chép và phục hồi giữa các OSD, giảm tải cho mạng public và mạng máy ảo.
  4. Mạng máy ảo và migration tách khỏi hai mạng Ceph bằng NIC hoặc VLAN riêng.

Benchmark Ceph chính thức của Proxmox (12/2023, Ceph Reef, SSD nhanh) cho thấy mạng 10 Gbit/s dễ bị quá tải, và 25 Gbit/s cũng có thể trở thành nút cổ chai. Ở 100 Gbit/s, một client đạt tới khoảng 6.000 MiB/s ghi và 7.000 MiB/s đọc. Nếu dùng jumbo frame (MTU 9000), Proxmox khuyên kiểm tra kỹ trên toàn bộ đường đi trước khi đưa vào sử dụng.

5. Phần cứng cho Ceph OSD: CPU, RAM và ổ đĩa

Trong HCI, Ceph dùng chung CPU và RAM với máy ảo, nên phần tài nguyên dành cho Ceph phải được trừ ra trước khi tính sức chứa máy ảo.

Khuyến nghị phần cứng cho Ceph trên Proxmox VE
Thành phần Khuyến nghị chính thức Ý nghĩa khi sizing
CPU Ít nhất 1 core/thread cho mỗi dịch vụ Ceph; OSD trên NVMe hiệu năng cao có thể dùng 4–6 thread Node 4 OSD NVMe có thể cần 16–24 thread chỉ cho Ceph
RAM OSD mặc định dùng 4 GiB; khuyến nghị cấu hình tối thiểu 8 GiB/OSD để có hiệu năng tốt, cộng dư địa cho lúc phục hồi 4 OSD ≈ 32 GiB, cộng MON/MGR và dư địa trước khi chia cho VM
Bộ điều khiển đĩa Tránh RAID controller, dùng HBA Ceph tự quản lý dư thừa; RAID controller không thiết kế cho tải Ceph
Ổ đĩa Ưu tiên SSD/NVMe trong cụm nhỏ để rút ngắn thời gian phục hồi; tránh phần cứng consumer Chọn SSD doanh nghiệp có PLP (bảo vệ khi mất điện) theo khuyến nghị của Ceph
DB/WAL Đặt DB/WAL trên ổ nhanh hơn chỉ khi tỷ lệ hợp lý Một ổ nhanh dùng chung cho quá nhiều OSD sẽ thành nút cổ chai

Ví dụ: node 2 socket, 64 core, 512 GiB RAM, 4 ổ NVMe. Sau khi dành khoảng 24 thread và 48–64 GiB RAM cho Ceph và hệ điều hành, phần còn lại mới là sức chứa cho máy ảo. Cách tính này giúp tránh tình trạng cụm chạy tốt lúc bình thường nhưng chậm hẳn khi Ceph phục hồi dữ liệu.

6. Tính dung lượng sử dụng thật của cụm Ceph

Pool Ceph trên Proxmox mặc định có size = 3 (3 bản sao) và min_size = 2: mỗi khối dữ liệu nằm trên 3 OSD ở các node khác nhau, và pool vẫn nhận I/O khi còn 2 bản. Proxmox cảnh báo không đặt min_size = 1, vì khi đó I/O vẫn được ghi khi chỉ còn một bản sao duy nhất (Hình 2).

Đường ghi trong pool Ceph size=3Máy ảoghi qua librbdOSD chính · Node 1nhận ghi, phân phối bản saoOSD · Node 2bản sao 2OSD · Node 3bản sao 31 · Ghi2 · Sao chép4 · Hoàn tất3 · Xác nhậnsize = 3: ba bản sao trên ba node khác nhau · min_size = 2: pool vẫn nhận I/O khi còn hai bản · không đặt min_size = 1
Hình 2. Đường ghi trong pool 3 bản sao. Máy ảo chỉ nhận xác nhận ghi xong khi dữ liệu đã nằm trên các bản sao ở node khác, vì vậy độ trễ và băng thông mạng Ceph ảnh hưởng trực tiếp tới hiệu năng ghi.

Từ đó, dung lượng sử dụng an toàn được tính theo bốn bước (Hình 3):

Dung lượng thô = số node × số ổ/node × dung lượng ổ
Dung lượng logic = dung lượng thô ÷ 3 (pool 3 bản sao)
Ngưỡng an toàn = dung lượng logic × 0,85 (nearfull_ratio mặc định)
Chịu mất 1 node = (dung lượng thô của N−1 node ÷ 3) × 0,85
Từ dung lượng thô tới dung lượng dùng an toànVÍ DỤ: 4 NODE × 4 NVMe 7,68 TBDung lượng thôChia 3 bản saoGiữ dưới ngưỡng nearfull 85%Chừa chỗ phục hồi khi mất 1 node122,88 TB≈ 40,96 TB≈ 34,8 TB≈ 26,1 TB dùng an toàn÷ 3× 0,85: tránh OSD đầy gây chặn I/O khi tái cân bằng(3 node × 4 × 7,68 TB) ÷ 3 × 0,85
Hình 3. Ví dụ tính dung lượng cho cụm 4 node, mỗi node 4 ổ NVMe 7,68 TB. Từ 122,88 TB thô, phần nên dùng cho dữ liệu chỉ khoảng 26 TB nếu muốn cụm tự phục hồi đủ 3 bản sao sau khi mất một node mà không chạm ngưỡng cảnh báo. Đây là phép tính minh họa; tỷ lệ cụ thể cần xác nhận khi sizing.

Khi gỡ hoặc mất OSD, tài liệu Proxmox khuyên các OSD còn lại phải ở mức thấp hơn nhiều so với ngưỡng nearfull 85%, vì quá trình tái cân bằng có thể làm OSD đầy và chặn I/O, và ở cụm nhỏ việc phục hồi có thể kéo dài. Erasure coding cho phép dùng được nhiều dung lượng hơn, nhưng đổi lại hiệu năng thấp hơn; tài liệu Proxmox dẫn khuyến nghị thận trọng min_size = k + 2 cho pool EC. Với cụm ảo hóa 3–5 node, pool replicated 3 bản sao vẫn là lựa chọn mặc định hợp lý.

7. HA khi một node gặp sự cố

Proxmox HA dùng cơ chế tự fence bằng watchdog. Khi một node rời khỏi quorum, nó không thể làm mới watchdog và sẽ tự khởi động lại sau khi watchdog hết hạn (60 giây). Sau đó, các máy ảo HA được khởi động lại trên node còn quorum. Thời gian phát hiện lỗi và chuyển đổi điển hình khoảng 2 phút (Hình 4).

Quorum và HA khi một node mất kết nốiCÒN QUORUM · 2/3 PHIẾUNode 11 phiếuNode 21 phiếuNode 31 phiếu: mất quorumwatchdog hết hạn sau 60 s→ tự khởi động lại (fence)VM-At = 0Node 3 mất kết nối corosync≈ 60 giâyWatchdog hết hạn, node 3tự khởi động lại≈ 2 phútVM HA chạy lại trên node 1 hoặc 2Dữ liệu VM nằm trên Ceph RBD dùng chung, nên node mới đọc được ổ đĩa của VM-A mà không cần sao chép.
Hình 4. Khi node 3 mất kết nối, node 1 và 2 vẫn giữ quorum (2/3 phiếu). Node 3 tự fence sau 60 giây để tránh hai node cùng chạy một máy ảo; máy ảo HA được khởi động lại trên node còn quorum, thường trong khoảng 2 phút.

Từ Proxmox VE 9.0, HA group được thay bằng HA rule: rule node affinity (ưu tiên node chạy máy ảo, mặc định không bắt buộc) và rule resource affinity (giữ các máy ảo chạy cùng nhau hoặc tách nhau, mặc định bắt buộc). Nên dùng rule tách nhau cho các cặp máy ảo dự phòng của nhau, ví dụ hai domain controller hoặc hai node cơ sở dữ liệu.

8. Vận hành và quản trị Proxmox sau triển khai

Thiết kế đúng mới là một nửa của dịch vụ triển khai Proxmox. Nửa còn lại là quản trị Proxmox hằng ngày: cập nhật đồng bộ giữa các node, theo dõi trạng thái Ceph, thay ổ hỏng, kiểm tra sao lưu và có kênh hỗ trợ khi sự cố xảy ra.

Các gói subscription Proxmox VE (giá tham khảo 10/2026, EUR/socket CPU/năm)
Gói Giá Hỗ trợ kỹ thuật từ Proxmox Phản hồi sự cố nghiêm trọng
Community 120 Không có ticket, hỗ trợ qua diễn đàn Không cam kết
Basic 370 3 ticket/năm 1 ngày làm việc
Standard 550 10 ticket/năm, hỗ trợ từ xa qua SSH 4 giờ
Premium 1.100 Không giới hạn ticket, hỗ trợ từ xa qua SSH 2 giờ

Mọi gói đều có quyền truy cập Enterprise Repository với các bản cập nhật đã qua kiểm thử. Theo Proxmox, gói Premium sẽ có hỗ trợ 24/7 từ 19/10/2026 và gói Standard trước cuối năm 2026. Bên cạnh đó:

  • Sao lưu: đặt Proxmox Backup Server trên phần cứng tách khỏi cụm Ceph là thực hành tốt, để một sự cố của cụm không kéo theo bản sao lưu. PBS hỗ trợ mã hóa phía client AES-256-GCM.
  • Giám sát Ceph: theo dõi trạng thái HEALTH, mức sử dụng từng OSD so với ngưỡng 85%, số PG không ở trạng thái active+clean và độ trễ OSD.
  • Bản quyền và cập nhật: tham khảo 10 rủi ro khi không dùng Proxmox license trước khi vận hành production chỉ với kho cộng đồng.

Với doanh nghiệp không có đội chuyên trách Linux và Ceph, managed service Proxmox là cách giảm rủi ro vận hành: CSC hỗ trợ từ khảo sát, thiết kế, triển khai, chuyển đổi máy ảo, tới vận hành và phân phối Proxmox (subscription chính hãng) với tư cách đối tác ủy quyền cao cấp của Proxmox tại Việt Nam.

9. Câu hỏi thường gặp

Cụm Proxmox Ceph cần tối thiểu bao nhiêu node?

Tối thiểu 3 node, nên giống nhau, với ít nhất 12 OSD chia đều. 3 node là mức tối thiểu cho quorum tin cậy và 3 Ceph monitor. Cụm 4–5 node trở lên tự tái tạo đủ 3 bản sao khi mất một node.

Ceph trên Proxmox cần mạng bao nhiêu Gbps?

Tối thiểu 10 Gbps dành riêng cho Ceph. Với ổ NVMe, Proxmox khuyến nghị tối thiểu 25 Gbps và có thể cần 40 hoặc 100 Gbps. Corosync nên có NIC riêng, độ trễ dưới 5 ms và không dùng chung với storage.

Dung lượng sử dụng thật của Ceph là bao nhiêu so với dung lượng thô?

Với pool 3 bản sao, dung lượng logic bằng một phần ba dung lượng thô. Nên giữ OSD dưới ngưỡng 85% và chừa chỗ để tái tạo dữ liệu khi mất một node. Ví dụ cụm 4 node × 4 ổ 7,68 TB có 122,88 TB thô nhưng chỉ nên dùng khoảng 26 TB.

Có nên dùng RAID controller cho Ceph không?

Không. Proxmox khuyến nghị tránh RAID controller và dùng HBA, vì Ceph tự quản lý dư thừa dữ liệu. Nên chọn SSD/NVMe doanh nghiệp có bảo vệ mất điện (PLP).

Khi một node hỏng, máy ảo chuyển sang node khác mất bao lâu?

Node mất quorum tự fence sau khi watchdog hết hạn 60 giây. Thời gian phát hiện lỗi và khởi động lại máy ảo HA trên node khác điển hình khoảng 2 phút.

Đọc thêm về Proxmox