vSAN vs Ceph w Proxmox VE

Co kupujesz w vSAN po Broadcomie

vSAN to programowo definiowany storage VMware: dyski lokalne hostów składają datastore widziany przez vSphere. Po wycofaniu licencji wieczystych nowy zakup to subskrypcja pakietu. vSphere Standard i Enterprise Plus (do 8 U3) nie zawierają vSAN. VVF dokłada ograniczony vSAN, pełny stos HCI z vSAN jest w VCF. Nie da się „dorzucić vSAN” do taniego vSphere tak, jak kiedyś.

Do tego dochodzi sprzęt zgodny z HCL, sieć 10/25 GbE i — w małych instalacjach — witness. To nie jest zarzut techniczny. To koszt i lock-in, który trzeba zestawić z Ceph, który w PVE nie ma osobnej pozycji cennikowej. vSAN ESA stawia na NVMe; OSA dzieli cache i capacity. Żadnego z tych SKU nie „dokleisz” do vSphere Standard po Broadcomie — HCI na VMware w praktyce oznacza VVF albo VCF.

Co jest wbudowane w Proxmox VE

Proxmox VE ma Ceph wbudowany: dyski VM na współdzielonym storage ze snapshotami, bez osobnej licencji. Klaster może być hyperkonwergentny — te same serwery trzymają maszyny i dane. Nie płacisz Proxmoxowi za „licencję Ceph”. Płacisz dyski, sieć i czas operatora. Subskrypcja PVE (opcjonalna, per socket) obejmuje wsparcie hiperwizora, nie osobny SKU storage.

Tabela: vSAN vs Ceph (RBD)

Live migration na współdzielonym storage kopiuje pamięć, nie dysk — to zdanie z podręcznika pvesm, nie slogan. Zarówno vSAN, jak i RBD dają ten efekt. Różnica jest w cenie wejścia i w tym, czy storage jest osobnym bytem licencyjnym.

Sieć, węzły i kworum storage

Produkcyjny Ceph stawia się na co najmniej trzech węzłach. Osobna sieć storage to standard operacyjny — nie wymysł oferty. vSAN też chce redundancję sieci i dysków. Dwa serwery z „świadkiem” vSAN to inna rozmowa niż dwa węzły Proxmox: kworum hiperwizora (artykuł Klaster i quorum) nie zastępuje trzeciego węzła storage. Przy zbyt małej liczbie serwerów Ceph przestaje serwować dane — niezależnie od tego, czy klaster Proxmox jeszcze ma głosy.

Kiedy vSAN zostaje, kiedy Ceph

• Ceph na PVE: migracja z VMware, chcesz HCI bez SKU storage, trzy i więcej węzłów, własny zespół albo partner do eksploatacji.
• NFS / SAN zamiast Ceph: macierz już jest, nie budujesz drugiego SDS. PVE to obsługuje (NFS, iSCSI, LVM na LUN) — patrz dobór storage.
• Zostaw vSAN: krótki horyzont, kontrakt VCF już zapłacony, zero apetytu na nowy SDS. To decyzja budżetowa, nie techniczna wyrocznia.

Pojemność vSAN w VVF i VCF

W analizie TCO VMware na tej stronie VVF ma ograniczony vSAN (0,25 TiB na rdzeń), VCF — 1 TiB na rdzeń. vSphere Standard i Enterprise Plus (do 8 U3) vSAN-u nie zawierają. „Dorzucimy vSAN do taniego vSphere” nie jest ścieżką zakupu po Broadcomie — to jest powód, dla którego HCI na VMware w praktyce oznacza VVF albo VCF, nie ESXi plus osobny SKU.

Ceph w PVE nie ma takiego licznika TiB/rdzeń. Płacicie dyski, sieć i czas operatora. Limit jest fizyczny (miejsce, sieć, czas odtworzenia), nie kontraktowy.

Sieć i domeny awarii

Sieć storage trzymamy osobno od sieci klastra i live migration. Mieszanie tego jest klasycznym sposobem na przestój w trakcie odtwarzania dysków albo na utratę kworum hiperwizora przy „niewinnej” migracji maszyny.

Domeny awarii (serwer, szafa) to odpowiednik polityk vSAN, nie checkbox FTT. Mapowanie 1:1 „FTT=1 → trzy kopie” jest uproszczeniem projektowym, nie specyfikacją VMware ani Ceph — sprawdzamy liczbę węzłów, zanim obiecamy ten sam poziom przeżycia. Dobór warstwy dyskowej: ZFS, LVM, NFS, Ceph.

HCI czy osobny storage

Proxmox VE pozwala na oba: dyski na tych samych serwerach co maszyny (mniej szaf, odtwarzanie dzieli moc z produkcją) albo osobna półka storage (drożej, ale odtworzenie nie dusi VM). W obu wariantach sieć storage zostaje osobna, a produkcja Ceph nadal liczy się od trzech węzłów — nie od dwóch z QDevice.

Ceph potrzebuje zapasu miejsca na odtworzenie. Zapełnienie „do ostatniego procenta” to ryzyko przestoju przy padzie dysku. vSAN ma własne progi zajętości; nie przenosimy ich 1:1. Strojenie klastra zostawiamy na wdrożenie — tu liczy się decyzja: HCI, osobny Ceph, czy macierz która już stoi.