To najczęstsza decyzja architektoniczna przy budowie klastra Proxmox i jedna z najtrudniejszych do odkręcenia po fakcie. Wybór storage determinuje liczbę węzłów, wymagania sieciowe, budżet i to, ile danych stracicie przy awarii. Poniżej kryteria, którymi kierujemy się w realnych wdrożeniach.
ZFS i Ceph często wrzuca się do jednego worka "storage pod Proxmox", a to fundamentalnie różne podejścia. ZFS jest lokalnym systemem plików: dane VM leżą na dyskach jednego węzła, a Proxmox potrafi replikować je asynchronicznie na inny węzeł zaplanowanymi snapshotami. Każdy węzeł ma własną, niezależną kopię.
Ceph to storage rozproszony: nie ma "dysku VM na węźle A", jest pula danych rozsmarowana po całym klastrze. Każdy zapis trafia synchronicznie na kilka węzłów jednocześnie i dopiero po potwierdzeniu przez replikę wraca do maszyny wirtualnej jako zakończony. Awaria węzła nie oznacza utraty ani jednego bloku danych.
Ta różnica, replikacja asynchroniczna kontra synchroniczna, przekłada się na wszystko: RPO, wymagania sprzętowe, złożoność i koszt wejścia.
W tym modelu każda VM działa na lokalnym poolu ZFS swojego węzła. Proxmox co zadany interwał (minimalnie około 1 minuty) robi snapshot i wysyła przyrost na wskazany węzeł zapasowy. Mechanizm jest wbudowany, konfiguruje się go w kilka minut z poziomu GUI.
Wady wynikają wprost z asynchroniczności. RPO liczy się w minutach: jeśli węzeł padnie, na replice są dane z ostatniego udanego cyklu replikacji, a wszystko od tego momentu przepada. Failover z HA działa, ale wymaga uwagi przy projektowaniu: trzeba świadomie zdecydować, które VM mają repliki, na których węzłach i z jakim interwałem, oraz przetestować scenariusz awarii zanim wydarzy się naprawdę.
Ceph rozwiązuje problem RPO u źródła: skoro każdy zapis od razu ląduje na kilku węzłach, awaria dowolnego z nich nie traci danych. RPO wynosi zero, a VM po failoverze startuje dokładnie w stanie sprzed awarii.
Za to płaci się progiem wejścia. Formalnie Ceph potrzebuje 3 węzłów do kworum monitorów, ale praktyczne minimum to 4: przy standardowej replice 3 klaster z 3 węzłów po awarii jednego nie ma gdzie odbudować trzeciej kopii i pracuje zdegradowany do czasu naprawy. Do tego dochodzi dedykowana, szybka sieć: minimum 10G, a przy NVMe realnie 25G, bo każdy zapis robi rundę po klastrze. Trzeba też doliczyć RAM, orientacyjnie 4-5 GB na każdy OSD, oraz zaakceptować większą złożoność operacyjną: monitory, mapy CRUSH, stany PG, procesy rebalancingu. To wszystko trzeba rozumieć i monitorować.
| Kryterium | ZFS + replikacja | Ceph |
|---|---|---|
| Minimalna liczba węzłów | 2 (+ QDevice dla kworum) | 3 formalnie, praktycznie 4 |
| RPO (utrata danych przy awarii) | Minuty (interwał replikacji, min. ~1 min) | Zero, zapis synchroniczny |
| Wymagania sieciowe | Umiarkowane, 10G z zapasem | Dedykowana sieć, min. 10G, przy NVMe realnie 25G |
| Dodatkowy RAM | Cache ARC (konfigurowalny) | Około 4-5 GB na każdy OSD |
| Złożoność operacyjna | Niska, jedna dojrzała technologia | Wyższa: monitory, OSD, PG, rebalancing |
| Wydajność pojedynczej VM | Bardzo dobra, lokalne NVMe bez sieci | Zależna od sieci i liczby węzłów |
| Skalowanie | W górę (mocniejsze węzły) | W szerz, pojemność i wydajność rosną z węzłami |
| Zachowanie po awarii węzła | Start z repliki, dane sprzed interwału | Samonaprawa, pełny stan danych |
| Koszt wejścia | Niski, 2 serwery i zwykła sieć | Wyższy, 4 serwery i szybka dedykowana sieć |
| Typowy przypadek | Małe klastry, budżetowe HA, aplikacje tolerujące RPO w minutach | Systemy krytyczne, większe klastry, wymóg zerowego RPO |
W praktyce decyzja sprowadza się do trzech pytań: ile węzłów mieści budżet, jakie RPO tolerują aplikacje i kto będzie to utrzymywał. Trzy typowe scenariusze z naszych wdrożeń:
Niezależnie od wyboru storage, backup projektujemy osobno, według zasady opisanej w artykule 3-2-1 z Proxmox Backup Server. Ani replika ZFS, ani replika Ceph nie jest backupem: skasowana albo zaszyfrowana VM znika ze wszystkich kopii jednocześnie.
Ceph na 3 węzłach bez zapasu. Replika 3 na 3 węzłach oznacza, że po awarii jednego serwera klaster nie ma gdzie odbudować redundancji i tygodniami pracuje w stanie zdegradowanym, bo "dysk już zamówiony". Czwarty węzeł nie jest luksusem, jest częścią projektu.
Ceph na sieci 1G. Każdy zapis robi rundę po węzłach, więc na 1G nawet szybkie dyski dają wydajność sprzed dekady, a rebalancing po awarii potrafi położyć ruch produkcyjny. Bez dedykowanej sieci 10G/25G Ceph nie ma sensu.
Mieszanie klas dysków w jednej puli. Pula wyrównuje do najwolniejszego elementu. NVMe wymieszane z dyskami talerzowymi w jednej puli daje wydajność talerzy przy cenie NVMe. Różne klasy dysków rozdzielamy na osobne pule.
Hardware RAID pod ZFS albo Ceph. Obie technologie chcą widzieć surowe dyski, bo same zarządzają redundancją i sumami kontrolnymi. Kontroler RAID ukrywa przed nimi stan dysków i potrafi cicho niszczyć integralność danych. Kontroler przełączamy w tryb HBA/IT.
Jeśli macie już działający klaster i nie jesteście pewni, czy uniknęliście tych pułapek, robimy Proxmox Health Check: przegląd konfiguracji storage, sieci i kworum z raportem rekomendacji, od 2 500 do 5 000 zł netto, 2-3 dni.
Technicznie tak, 3 węzły to minimum dla kworum monitorów. W praktyce rekomendujemy 4: przy replice 3 i awarii jednego węzła klaster z 3 węzłów nie ma gdzie odbudować trzeciej kopii danych i pracuje w stanie zdegradowanym do czasu naprawy sprzętu. Czwarty węzeł daje Ceph przestrzeń na automatyczną odbudowę pełnej redundancji.
Współpracuje z HA, ale trzeba zaakceptować RPO w minutach: po awarii węzła VM startuje na replice z danymi z ostatniego cyklu replikacji, więc zmiany z ostatnich minut przepadają. Dla wielu obciążeń to akceptowalne, dla transakcyjnych baz danych zwykle nie. Tam, gdzie utrata nawet minuty danych jest problemem, wybieramy Ceph albo dokładamy replikację na poziomie aplikacji.
Dedykowana sieć minimum 10G, a przy dyskach NVMe realnie 25G, żeby sieć nie była wąskim gardłem. Ceph zapisuje każdy blok synchronicznie na kilka węzłów, więc opóźnienie i przepustowość sieci bezpośrednio przekładają się na wydajność dysków widzianą przez VM. Sieci 1G nie należy rozważać pod Ceph produkcyjnie.
Porozmawiajcie z inżynierem, który projektuje i utrzymuje klastry na obu technologiach, w tym własną produkcję na 8 węzłach. Przejdziemy przez wasze aplikacje, wymagane RPO i budżet, i wskażemy architekturę, która ma sens. Rozmowa nie zobowiązuje.
Umów rozmowę techniczną o architekturze