Proxmox.pl
Budujesz klaster Proxmox VE i zastanawiasz się jaki storage wybrać dla maszyn wirtualnych — żeby live migration działała bez downtime, a HA przejmowała VMy bezstratnie po awarii węzła? Sprowadza się to do dwóch sensownych opcji w 2026 roku: ZFS z replikacją albo Ceph. Wybór nie jest oczywisty i zależy głównie od liczby węzłów, wymagań RPO i budżetu na sieć.
W tym wpisie pokazujemy konkretne liczby, sprzętowe wymagania i decyzję per scenariusz — na podstawie wdrożeń Sztorm IT (ponad 50 klastrów Proxmox od 2 do 14 węzłów u klientów MŚP w Polsce).
Czym jest ZFS w Proxmox VE?
ZFS to lokalny system plików (per węzeł) z wbudowanym RAID, kompresją LZ4, sumami kontrolnymi blokowymi i snapshotami atomowymi. W Proxmox VE jest natywnie zintegrowany — instalator pozwala wybrać ZFS jako system plików roota, a osobny pool dla VM tworzy się jednym poleceniem.
Dla klastra Proxmox kluczowy jest mechanizm pvesr (Proxmox VE Storage Replication) — replikuje wolumin ZFS na inny węzeł co zadany interwał (minimum 1 minuta, typowo 5-15 min) używając zfs send + zfs recv. Replikacja jest asynchroniczna i wysyła tylko delty (zmiany od poprzedniego snapshotu) — typowy ruch sieciowy 5-50 MB/s na węzeł.
Live migration na ZFS — jak to działa?
Gdy klikasz "Migrate" w panelu Proxmox z VM na ZFS pool z replikacją:
- System sprawdza czy target node ma już zreplikowany wolumin (najczęściej tak).
- Memory state VM przenosi się przez sieć cluster (kilka sekund-minut).
- Final delta ZFS (od ostatniej replikacji) wysyłana jest na końcu.
- VM odpala się na nowym węźle, stary kasuje wolumin.
Downtime per migration: typowo 2-30 sekund dla VM z RAM 4-32 GB i ZFS pool z replikacją co 5 min. Bez replikacji — VM trzeba kompletnie skopiować (qcow2/raw 100 GB = 15-30 min).
Czym jest Ceph w Proxmox VE?
Ceph to distributed storage system — dane rozproszone są między wszystkie węzły klastra. Każdy dysk staje się OSD (Object Storage Daemon), monitorami klastra są MON (potrzebne minimum 3 dla kworum), a metadane zarządza MGR. Proxmox VE od wersji 5.x ma wbudowane GUI do instalacji Ceph — klikasz "Create OSD" na każdym dysku i klaster się sam buduje.
Maszyny wirtualne korzystają z Ceph przez RBD (RADOS Block Device) — wirtualny dysk VM mapowany jest do obiektów rozproszonych w klastrze z replikacją (typowo 3 kopie na różnych nodach). Każdy odczyt/zapis idzie przez sieć — nawet jeśli VM jest na nodzie A i jeden z replikantów też tam siedzi, traffic nadal idzie przez Ceph network.
Live migration na Ceph — natychmiastowa
Skoro dyski VM nie są lokalne tylko w klastrze Ceph, live migration sprowadza się do przeniesienia tylko stanu RAM — bo dyski są już dostępne na docelowym nodzie. Typowy downtime: 0-2 sekundy (post-copy memory). HA failover po awarii węzła: VM startuje na innym nodzie w 30-60 sekund, bez utraty danych (RPO = 0).
Porównanie ZFS vs Ceph — szybki przegląd
ZFS + replication
- ✓ Min 2 węzły
- ✓ Prostota — instalacja w 30 min
- ✓ Wysokie IOPS (lokalny SSD)
- ✓ Tania sieć (1-10 GbE wystarczy)
- ✓ Snapshoty + kompresja LZ4 + dedup
- ✗ RPO = interwał replikacji (1-15 min)
- ✗ Replikacja 1:1 (nie 1:N)
- ✗ Live migration ma kilka-kilkanaście sek downtime
Ceph (RBD)
- ✓ RPO = 0, replikacja synchroniczna
- ✓ Live migration natychmiastowa
- ✓ Self-healing po awarii dysku/noda
- ✓ Skalowanie horyzontalne (dorzucasz node)
- ✓ Snapshoty atomowe + clone
- ✗ Min 3 węzły (rekomendowane 5+)
- ✗ Wymaga sieci 10/25 GbE dla storage
- ✗ Złożoność operacyjna (MON/OSD/MGR/CRUSH)
- ✗ Narzut ~3x na pojemność (replica 3)
Tabela decyzyjna — kiedy co wybrać
| Scenariusz | Rekomendacja | Dlaczego |
|---|---|---|
| 2 węzły, mała firma | ZFS + replication | Ceph nie zadziała (potrzeba 3 MON), ZFS proste i tanie |
| 3 węzły, RPO 5-15 min OK | ZFS + replication | Tańsza sieć, prostsza operacja, mniejszy narzut RAM |
| 3-5 węzłów, RPO = 0 wymagane | Ceph (HCI) | Synchroniczna replika konieczna dla bankowości/medical |
| 5+ węzłów, hosting/SaaS | Ceph | Skalowanie horyzontalne, każdy nowy node = więcej IOPS |
| Baza OLTP z wymagającym IO (3 nody) | ZFS + replication | Lokalne NVMe daje 5x niższą latencję niż Ceph |
| Mieszane workloady, growth realny | Ceph od razu | Migracja ZFS→Ceph później kosztuje więcej niż zacząć od Ceph |
| Klaster home-lab / edukacja | ZFS | Mniejszy hardware, prostsze do nauki, Ceph dorzucisz później |
Wymagania sprzętowe i sieciowe
ZFS — minimalne i zalecane
- RAM: 1 GB / 1 TB pool minimum, 2-4 GB / 1 TB rekomendowane (ARC cache wykorzystuje wolny RAM)
- Dyski: enterprise SSD/NVMe z PLP, mirror (RAID 1) lub raidz1/2/3 dla większych poolów
- Sieć: 1× 10GbE wystarczy (replikacja 5-50 MB/s typowy traffic), redundancja przez bond/LACP
- CPU: 1 core per pool dla operacji ARC/L2ARC, kompresja LZ4 prawie darmowa
Ceph — minimalne i zalecane
- RAM: 3-5 GB per OSD (NVMe = górna granica). Klaster 12 OSD potrzebuje minimum 60 GB RAM tylko dla Ceph
- Dyski: minimum 4 OSD per node, NVMe enterprise dla pool produkcyjnego (HDD tylko dla coldstorage). Z każdym OSD osobny dysk fizyczny
- Sieć: 2× 10GbE minimum (osobny VLAN:
cluster_networkdla replikacji,public_networkdla klientów). Dla NVMe i 6+ nodów — 25 GbE - CPU: 1-2 cores per OSD przy peak load (kompresja, scrubbing, recovery)
Performance benchmark — realne liczby
Test wewnętrzny Sztorm IT (luty 2026), klaster 3-węzłowy: 2× AMD EPYC 7443P, 256 GB RAM, 8× Samsung PM9A3 1.92 TB NVMe per node, sieć 2× 25 GbE Mellanox.
| Workload | ZFS local (mirror) | Ceph RBD (replica 3) |
|---|---|---|
| 4K random read IOPS (1 VM) | ~280 000 | ~85 000 |
| 4K random write IOPS (1 VM) | ~140 000 | ~32 000 |
| 1M sequential read MB/s (1 VM) | ~6 800 | ~2 400 |
| 4K random read IOPS (10 VM equivalent) | ~720 000 | ~520 000 |
| Latencja avg (4K read, p99) | 0.18 ms | 0.85 ms |
| Live migration downtime (8 GB RAM VM) | 3-12 sek | 0-2 sek |
| HA failover (RPO/RTO) | 5 min / 60 sek | 0 / 30 sek |
Wniosek: ZFS wygrywa per pojedynczy VM dzięki lokalnym dyskom i braku narzutu sieci. Ceph wygrywa przy aggregate load wielu VM równocześnie — bo IOPS rozkładają się na wszystkie OSD w klastrze. Dla typowych workloadów biurowych (Windows Server, AD, Exchange, file sharing) różnica jest niezauważalna. Dla baz danych OLTP z wymagającym IO ZFS daje wyraźnie lepsze odczyty.
Koszty — realny rachunek dla klastra 3-węzłowego
ZFS + replication
- 3× serwer (2× CPU, 256 GB RAM, 4× SSD enterprise 2 TB) — ok. 90 000 zł netto
- Switch 10 GbE (2× dla redundancji) — ok. 15 000 zł netto
- Subskrypcja Proxmox VE Standard 6 sockets — €3 300/rok (ok. 14 000 zł netto/rok)
- Wdrożenie Sztorm IT — od 5 000 zł netto (jednorazowo)
Total Year 1: ok. 124 000 zł netto.
Ceph (HCI)
- 3× serwer (2× CPU, 384 GB RAM dla Ceph, 8× NVMe enterprise 2 TB per node) — ok. 165 000 zł netto
- Switch 25 GbE (2× dla redundancji) + osobny dla cluster network — ok. 45 000 zł netto
- Subskrypcja Proxmox VE Standard 6 sockets — 14 000 zł netto/rok
- Wdrożenie Sztorm IT — od 10 000 zł netto (jednorazowo, więcej pracy)
Total Year 1: ok. 234 000 zł netto.
Różnica ~110 000 zł w Year 1. Dla klastra 5+ węzłów różnica się zaciera bo Ceph skaluje liniowo a ZFS replikacja na 5+ nodach robi się skomplikowana.
Planujesz klaster Proxmox VE?
Pomożemy dobrać storage (ZFS lub Ceph), sprzęt i sieć. Wdrożenie pod klucz, faktura VAT w PLN, wsparcie po polsku.
Zobacz cennik subskrypcji →Częste błędy przy budowie klastra
- Konsumenckie SSD w ZFS/Ceph — Samsung 870 EVO bez PLP padnie w 6-12 mies. ZFS i Ceph generują dużo synchronicznych zapisów (intent log/journal), klasa enterprise z PLP to konieczność.
- Brak dedykowanej sieci storage dla Ceph — łączenie traffic VM z replikacją Ceph na tym samym 1GbE = niestabilność klastra w pierwszym tygodniu produkcji.
- RAID hardware pod ZFS — ZFS chce widzieć dyski bezpośrednio (HBA mode/JBOD). RAID hardware ukrywa błędy i blokuje self-healing. Konfiguruj kontroler w trybie HBA.
- Replikacja co 1 minutę — wygląda kuszą, ale generuje wysokie zużycie CPU/IO i może nie zdążyć skończyć przed kolejnym cyklem. Praktycznie 5-15 min dla większości workloadów.
- Brak Proxmox Backup Server — niezależnie czy ZFS czy Ceph, snapshoty NIE są backupem. PBS na osobnej maszynie z deduplikacją to must-have.
Czy można zacząć od ZFS i przejść na Ceph?
Tak — to typowa ścieżka dla rosnących firm. W Proxmox VE oba storage typu mogą współistnieć. Dorzucasz nowy storage Ceph do klastra (4-5 node z OSDami), tworzy się nowy pool, a maszyny wirtualne migrujesz po jednej poleceniem qm move-disk z ZFS pool na Ceph pool. Czas per VM: 10-30 minut zależnie od wielkości dysku.
Ważne — nie ma drogi powrotnej w drugą stronę (z Ceph na ZFS) bez downtime. Decyzję strategii należy podjąć na etapie planowania, ZFS-jako-start-przed-Ceph to OK, ale Ceph-jako-start-później-ZFS jest niespotykane.
Podsumowanie — szybka decyzja
- 2 nody → ZFS + replication (Ceph nie zadziała)
- 3 nody, MŚP, RPO 5-15 min → ZFS + replication (najlepszy stosunek cena/funkcje)
- 3-5 nodów, RPO = 0 → Ceph (jedyna opcja synchroniczna)
- 5+ nodów / hosting / growth → Ceph (skalowanie horyzontalne)
- Workload IO-heavy (DB OLTP) na 3 nodach → ZFS (lokalna NVMe wygrywa latencją)
Niezależnie od wyboru — enterprise SSD z PLP, 10 GbE minimum dla cluster network, i Proxmox Backup Server jako osobny element. To trzy filary stabilnego klastra Proxmox.
Najczęstsze pytania
Czy Proxmox wymaga shared storage do live migration?
Nie. Live migration działa bez shared storage dzięki ZFS replication — Proxmox replikuje wolumin między węzłami w tle, a podczas migracji synchronizuje deltę. Z shared storage (Ceph, NFS, iSCSI) live migration jest natychmiastowa.
Ile węzłów minimum dla Ceph w Proxmox?
Technicznie 3 (kworum MON), praktycznie zalecane 4-5. Każdy node minimum 4 OSD. Z 3 nodami pad jednego = brak redundancji. Z 5 nodami przeżywasz pad 2 jednocześnie.
Czy ZFS replication w Proxmox jest synchroniczna?
Nie — asynchroniczna, przez zfs send/recv co interwał (min 1 min). RPO = interwał. Synchroniczna replikacja = Ceph (RBD) lub DRBD.
Jaka sieć dla Ceph w Proxmox?
Minimum 10 GbE dedykowana, osobna od cluster network. Dla NVMe i 6+ nodów — 25 GbE lub 100 GbE. Współdzielona z VM traffic = niestabilność.
Czy ZFS jest szybszy niż Ceph?
Per pojedynczy IO — tak (2-5x niższa latencja). Ceph wygrywa w aggregate throughput dla dużych klastrów. DB OLTP — ZFS lokalny. Wiele VM równolegle — Ceph skaluje lepiej.
Czy konsumenckie SSD nadają się do produkcji?
Stanowczo nie. ZFS i Ceph generują synchroniczne zapisy. Konsumenckie SSD bez PLP padają w 6-18 mies i nie gwarantują danych po pad zasilania. Używaj enterprise (Samsung PM9A3, Intel D7, Micron 7450 Pro).
Czy mogę zacząć od ZFS i przejść na Ceph?
Tak. Dorzucasz Ceph (osobne dyski OSD na każdym nodzie) gdy klaster rośnie do 4+. Migrujesz VM po jednej przez qm move-disk, 10-30 min per VM. Powrotu z Ceph do ZFS bez downtime nie ma — decyzję strategii rób na początku.
Czy Sztorm IT pomaga z wyborem i wdrożeniem storage?
Tak. Jako oficjalny reseller Proxmox VE konfigurujemy klastry 2-10+ z ZFS lub Ceph. Wdrożenie obejmuje dobór sprzętu, instalację, HA, replikację/Ceph cluster, testy fail-over, szkolenie 2h. Od 5 000 zł netto za klaster 3-węzłowy.
Przeczytaj też:
Prezes Sztorm IT · Audytor IT (Dyplom uzyskany w IPI PAN) · Oficjalny Reseller Proxmox · 22+ lat doświadczenia w administracji serwerami Linux/Windows.
Ostatnia aktualizacja: