Ceph w Proxmox VE: kiedy się opłaca i jak go wdrożyć w firmie krok po kroku

Ceph w Proxmox VE to rozproszony magazyn danych zbudowany z lokalnych dysków kilku serwerów, wbudowany bezpośrednio w platformę wirtualizacji. Dzięki niemu maszyny wirtualne mają wspólną przestrzeń dyskową na wszystkich węzłach klastra, mogą być migrowane na żywo i automatycznie restartowane na innym serwerze po awarii — bez kupowania zewnętrznej macierzy SAN.

Dla firmy oznacza to wysoką dostępność i skalowanie przez dokładanie kolejnych serwerów. Ceph ma jednak konkretne wymagania sprzętowe i nie opłaca się w każdym środowisku. Poniżej wyjaśniam, jak działa, kiedy ma sens i jak go wdrożyć krok po kroku.

Jak działa Ceph w klastrze Proxmox

Ceph dzieli dane na obiekty i rozkłada je między dyski wszystkich węzłów według algorytmu CRUSH. Każdy obiekt ma kilka kopii (domyślnie trzy), zawsze na różnych serwerach. Gdy jeden węzeł padnie, dane są dostępne z pozostałych, a Ceph sam odtwarza brakujące kopie.

Główne składniki, które zobaczysz w Proxmoxie:

Proxmox korzysta z Ceph na dwa sposoby. RBD (RADOS Block Device) to dyski blokowe dla maszyn wirtualnych i kontenerów — podstawowy tryb pracy. CephFS to współdzielony system plików, przydatny do przechowywania obrazów ISO, szablonów czy plików kopii zapasowych.

Jeśli dopiero zaczynasz z Proxmoxem, najpierw przeczytaj poradnik o instalacji i konfiguracji Proxmoxa, a o tym, czym jest sama maszyna wirtualna, w osobnym tekście.

Kiedy Ceph opłaca się w firmie, a kiedy nie

Ceph wnosi realną wartość, gdy:

• masz co najmniej 3 serwery i chcesz, by awaria jednego nie zatrzymywała usług (Proxmox HA),
• potrzebujesz migracji maszyn na żywo bez współdzielonej macierzy,
• planujesz wzrost — pojemność i wydajność zwiększasz, dokładając dyski lub węzły,
• chcesz uniezależnić się od jednego dostawcy macierzy dyskowych.

Ceph nie jest dobrym wyborem, gdy:

• masz jeden lub dwa serwery — tu lepiej sprawdzi się ZFS z replikacją między węzłami,
• dysponujesz tylko siecią 1 Gb/s i dyskami konsumenckimi — wydajność rozczaruje,
• nikt w zespole nie ma czasu, by poznać jego działanie — Ceph wybacza mniej niż lokalny RAID.

Jeśli wybierasz platformę wirtualizacji po zmianach w licencjonowaniu VMware, przyda się też porównanie Proxmox vs VMware ESXi — Ceph jest w nim jednym z argumentów po stronie Proxmoxa.

Wymagania sprzętowe Ceph w Proxmox

Większość problemów z wydajnością Ceph wynika ze sprzętu dobranego „na oko”. Kluczowe zasady:

• Węzły: minimum 3, najlepiej o zbliżonej konfiguracji. Stabilniej od 4–5, bo po awarii jednego serwera klaster ma gdzie odbudować trzecią kopię.
• Dyski: SSD/NVMe klasy enterprise z ochroną przed utratą zasilania (PLP). Konsumenckie SSD przy zapisach synchronicznych potrafią być wielokrotnie wolniejsze. HDD tylko do danych archiwalnych, z bazą RocksDB/WAL na szybkim SSD.
• Kontroler: dyski podłączone bezpośrednio lub przez HBA. Nie używaj sprzętowego RAID — Ceph sam zarządza redundancją.
• Sieć: osobna sieć dla Ceph, minimum 10 GbE, przy NVMe 25 GbE lub więcej. Najlepiej dwie sieci: publiczną (klienci, monitory) i klastrową (replikacja między OSD), połączone redundantnie (bonding).
• Pamięć RAM: każdy OSD domyślnie celuje w ok. 4 GB pamięci (osd_memory_target), do tego monitory, managery i maszyny wirtualne.
• CPU: przy szybkich dyskach NVMe Ceph potrafi zająć kilka rdzeni na każdy OSD — uwzględnij to przy planowaniu maszyn wirtualnych na tych samych węzłach.

Uwaga: Sieć korosync (komunikacja klastra Proxmox) powinna mieć własne, niezależne łącze. Jeśli replikacja Ceph „zatka” wspólną sieć, korosync może stracić kworum, a węzły z włączonym HA zaczną się restartować (fencing).

Ile miejsca zostanie do dyspozycji

Przy domyślnej replikacji size=3 każdy blok jest zapisany trzykrotnie. Z trzech węzłów po 4 dyski 2 TB (24 TB surowo) zostaje ok. 8 TB użytecznej przestrzeni. Ceph domyślnie zgłasza ostrzeżenie przy zapełnieniu OSD w 85% (nearfull), a przy 95% blokuje zapisy. W praktyce planuj tak, żeby po awarii całego węzła pozostałe miały miejsce na odbudowę danych — czyli celuj w zajętość wyraźnie poniżej tych progów.

Instalacja Ceph w Proxmox VE krok po kroku

Zakładam, że masz już klaster Proxmox z co najmniej trzema węzłami, skonfigurowaną sieć dla Ceph (np. 10.10.10.0/24) i wolne dyski na każdym węźle.

Krok 1: instalacja pakietów

1. W GUI wybierz pierwszy węzeł → Ceph. Proxmox zaproponuje instalację.
2. Wybierz wersję Ceph oferowaną przez instalator (w Proxmox VE 9 m.in. Squid 19.2) i repozytorium: Enterprise (z subskrypcją) lub No-Subscription.
3. Po instalacji kreator poprosi o wybór sieci publicznej i klastrowej oraz utworzy pierwszy monitor.

To samo z wiersza poleceń:

pveceph install --repository no-subscription
pveceph init --network 10.10.10.0/24 --cluster-network 10.10.20.0/24
pveceph mon create

Pakiety zainstaluj na każdym węźle (w GUI lub poleceniem pveceph install), ale pveceph init wykonujesz tylko raz.

Krok 2: monitory i managery na pozostałych węzłach

W GUI: węzeł → Ceph → Monitor → Create, wybierz kolejne węzły. Tak samo utwórz dodatkowe managery. W konsoli na każdym z węzłów:

pveceph mon create
pveceph mgr create

Krok 3: tworzenie OSD

Na każdym węźle: Ceph → OSD → Create: OSD, wybierz dysk, opcjonalnie osobny szybki dysk na DB/WAL (przy HDD). Z konsoli:

pveceph osd create /dev/nvme1n1
pveceph osd create /dev/sdb --db_dev /dev/nvme0n1

Dysk musi być pusty (bez partycji i sygnatur). Wyczyścisz go w GUI przyciskiem Wipe Disk w zakładce Disks lub poleceniem ceph-volume lvm zap /dev/sdX --destroy.

Ważne: Czyszczenie dysku bezpowrotnie usuwa z niego dane. Dwa razy sprawdź nazwę urządzenia — /dev/sdb na jednym węźle nie musi być tym samym dyskiem co /dev/sdb na innym.

Krok 4: pula dla maszyn wirtualnych

W GUI: Ceph → Pools → Create. Ustaw nazwę (np. vm-pool), Size: 3, Min. Size: 2 i zaznacz Add as Storage — Proxmox od razu doda pulę jako magazyn RBD w Datacenter → Storage. Z konsoli:

pveceph pool create vm-pool --size 3 --min_size 2 --add_storages

Liczbę placement groups (PG) dobiera domyślnie włączony autoskaler, więc nie musisz jej liczyć ręcznie.

Krok 5 (opcjonalnie): CephFS

Na dwóch–trzech węzłach utwórz serwery metadanych (Ceph → CephFS → Metadata Servers → Create), a potem sam system plików przyciskiem Create CephFS. Proxmox doda go jako magazyn na ISO, szablony kontenerów i kopie zapasowe.

pveceph mds create
pveceph fs create --name cephfs --add-storage

Codzienna obsługa i monitorowanie

Stan klastra widzisz w GUI na pulpicie Ceph każdego węzła. Najważniejsze polecenia:

ceph -s              # ogólny stan klastra (HEALTH_OK / WARN / ERR)
ceph health detail   # szczegóły ostrzeżeń
ceph osd tree        # rozkład OSD na węzłach, które są up/down
ceph osd df          # zajętość każdego dysku
ceph df              # zajętość pul

Dobre praktyki eksploatacji:

1. Przed restartem węzła (np. aktualizacją) ustaw flagę ceph osd set noout, żeby Ceph nie zaczął przebudowy danych, a po powrocie węzła zdejmij ją: ceph osd unset noout.
2. Aktualizuj węzły po kolei, czekając na HEALTH_OK przed przejściem do następnego.
3. Przy mieszanych dyskach (HDD i SSD) twórz osobne reguły CRUSH według klasy urządzenia, żeby wolne dyski nie spowalniały puli SSD:

ceph osd crush rule create-replicated replicated_ssd default host ssd
ceph osd pool set vm-pool crush_rule replicated_ssd

4. Monitoruj stan dysków (SMART) i wymieniaj te, które zgłaszają błędy, zanim całkiem padną.

Więcej ogólnych zasad utrzymania środowiska znajdziesz w zestawieniu 10 najlepszych praktyk w Proxmox.

Najczęstsze błędy przy wdrażaniu Ceph

• Dwa węzły „na próbę” — dwa węzły nie utrzymają kworum monitorów po awarii jednego z nich. Ceph od początku planuj na trzy lub więcej serwerów.
• min_size=1 dla „większej dostępności” — pozwala pisać dane w jednej kopii; awaria tego jednego dysku oznacza utratę danych. Zostaw 3/2.
• Konsumenckie SSD — szybkie w testach sekwencyjnych, bardzo wolne przy zapisach synchronicznych. Skutek: wysokie opóźnienia maszyn wirtualnych.
• Wspólna sieć dla wszystkiego — ruch maszyn, backupów, korosync i replikacji Ceph na jednym łączu 1 GbE to przepis na problemy przy pierwszej odbudowie danych.
• Zapełnienie pul pod korek — przy przekroczeniu progu full klaster blokuje zapisy, a maszyny wirtualne „zamarzają”.

Ceph to nie backup

Replikacja chroni przed awarią dysku lub serwera, ale nie przed usunięciem maszyny, ransomware czy błędem administratora — te zmiany natychmiast replikują się na wszystkie kopie. Snapshoty RBD też żyją w tym samym klastrze. Dlatego obok Ceph potrzebujesz niezależnych kopii zapasowych, najlepiej w Proxmox Backup Server na osobnym sprzęcie i dodatkowo poza siedzibą firmy. Różnicę między kopią a migawką szerzej wyjaśnia tekst czy snapshot to backup.

Dobrze zaplanowany Ceph w Proxmox VE daje firmie odporność na awarie, którą jeszcze niedawno oferowały tylko drogie macierze. Kluczem jest sprzęt dobrany pod jego wymagania, osobna szybka sieć i test awarii jednego węzła przed przeniesieniem produkcji.