Ceph — distributed storage cluster na VPS i dedykach
Opublikowano: 9 kwietnia 2026 · Kategoria: VPS / Storage
Ceph to open source distributed storage, który skaluje się od 3 węzłów do tysięcy maszyn i petabajtów danych. Używają go OVH, DigitalOcean, CERN i Red Hat. Jednym klastrem obsłużysz bloki dla maszyn wirtualnych (RBD), S3-compatible object storage (RGW) i POSIX filesystem (CephFS). Ta elastyczność to największa zaleta, ale też największe wyzwanie — trzeba zrozumieć jak to działa.
Architektura — z czego składa się klaster
Ceph ma kilka typów demonów. Każdy robi coś innego i każdy można skalować niezależnie:
| Komponent | Funkcja | Zalecana ilość |
|---|---|---|
| MON (Monitor) | Trzyma mapę klastra, paxos quorum, autoryzacja | 3 lub 5 (zawsze nieparzysta) |
| MGR (Manager) | Dashboard, metryki, moduły (Prometheus, balancer) | 2 (active + standby) |
| OSD (Object Storage) | Przechowuje dane, obsługuje replikację i recovery | 1 per dysk fizyczny, min. 6 w klastrze |
| MDS (Metadata Server) | Metadane CephFS (tylko jeśli używasz filesystem) | 2 (active + standby) |
| RGW (Rados Gateway) | S3/Swift API — HTTP frontend do object storage | 2+ (za load balancerem) |
Pools, placement groups i CRUSH
Obiekty w Ceph nie trafiają bezpośrednio na konkretny dysk. Algorytm CRUSH (Controlled Replication Under Scalable Hashing) wylicza deterministycznie, gdzie obiekt ma być zapisany, na podstawie mapy klastra. Żadne metadane centralne nie są potrzebne — każdy klient może policzyć lokalizację sam.
- Pool — logiczny namespace z własną polityką replikacji. Typowe: rbd (dla bloków), cephfs_data, cephfs_metadata, default.rgw.buckets.data.
- PG (Placement Group) — mała grupa obiektów, która jest jednostką replikacji. Reguła kciuka: 100 PG per OSD. Klaster z 10 OSD powinien mieć ok. 1000 PG.
- CRUSH map — hierarchia (root -> rack -> host -> OSD), która pozwala Cephowi wybierać repliki na różnych szafach/hostach, a nie na tym samym serwerze.
Deployment z cephadm — krok po kroku
Od Ceph Octopus (15.x) zalecaną metodą jest cephadm — orchestrator oparty na Dockerze/Podmanie,
który rozstawia demony w kontenerach. Zastąpił starsze narzędzia (ceph-deploy, ceph-ansible).
# Na wszystkich węzłach — wymagania # Ubuntu 22.04+, min. 2 CPU, 8 GB RAM, dysk systemowy + dyski OSD sudo apt update sudo apt install -y podman lvm2 chrony python3 # Synchronizacja czasu (KRYTYCZNE — MONy wymagają < 50 ms skew) sudo systemctl enable --now chrony # Tylko na pierwszym węźle (admin/bootstrap) curl --silent --remote-name --location \ https://download.ceph.com/rpm-reef/el9/noarch/cephadm chmod +x cephadm sudo ./cephadm add-repo --release reef sudo ./cephadm install # Bootstrap klastra (jeden węzeł) sudo cephadm bootstrap --mon-ip 10.0.0.10 # Output: dashboard URL + hasło admin # Ceph Dashboard: https://10.0.0.10:8443/ # User: admin, Password: <wygenerowane> # Kopia klucza SSH na pozostałe węzły sudo ssh-copy-id -f -i /etc/ceph/ceph.pub [email protected] sudo ssh-copy-id -f -i /etc/ceph/ceph.pub [email protected] # Dodanie kolejnych węzłów sudo cephadm shell -- ceph orch host add node2 10.0.0.11 sudo cephadm shell -- ceph orch host add node3 10.0.0.12 # Automatyczne dodanie wszystkich dostępnych dysków jako OSD sudo cephadm shell -- ceph orch apply osd --all-available-devices
Podstawowa administracja
# Wejdź do shell cephadm (kontener z ceph CLI) sudo cephadm shell # Status klastra (HEALTH_OK = dobrze) ceph -s ceph health detail # Lista OSD i ich stan ceph osd tree ceph osd df # Tworzenie poola z replikacją 3x ceph osd pool create mypool 128 128 replicated ceph osd pool set mypool size 3 ceph osd pool set mypool min_size 2 # Pool z erasure coding (4 data + 2 parity) ceph osd erasure-code-profile set ec42 k=4 m=2 ceph osd pool create coldpool 128 128 erasure ec42 # Tworzenie bloku RBD i mapowanie na Linuxie ceph osd pool application enable mypool rbd rbd create mypool/myvolume --size 10G rbd map mypool/myvolume mkfs.xfs /dev/rbd0 mount /dev/rbd0 /mnt/ceph
Porównanie z GlusterFS
| Feature | Ceph | GlusterFS |
|---|---|---|
| Minimum węzłów | 3 (dla quorum) | 2 |
| Typy dostępu | Block (RBD), Object (S3), POSIX (CephFS) | POSIX (NFS/FUSE/SMB) |
| Skalowanie | Petabajty, tysiące węzłów | Terabajty, dziesiątki węzłów |
| Learning curve | Stroma — dni nauki | Łagodna — godzina startu |
| Erasure coding | Tak, konfigurowalne | Tak (ograniczone profile) |
| Self-healing | Automatyczne, CRUSH-based | Automatyczne, heal daemon |
| Metadane | Rozproszone (MONs) | Brak (hash na ścieżkę) |
Best practices produkcyjne
- Dedykowana sieć cluster — osobne VLAN-y dla public network (klienci) i cluster network (replikacja OSD). 10 Gbps minimum, 25/100 Gbps dla produkcji.
- NVMe dla journal/DB — przy HDD OSD używaj wydzielonych SSD/NVMe na BlueStore DB/WAL. Przyspiesza write 10x.
- NTP/chrony obowiązkowe — MONy wymagają zsynchronizowanego czasu. Dryf > 50 ms i klaster wchodzi w HEALTH_WARN.
- Nie zapełniaj ponad 80% — przy 85% Ceph blokuje zapisy (backfillfull). Planuj ekspansję z 2-3 miesięcznym buforem.
- Monitoring Prometheus + Grafana — cephadm ma wbudowany stack Prometheus/Grafana/Alertmanager.
Włącz przez
ceph mgr module enable prometheus.
Uwaga: Ceph w produkcji wymaga SRE lub dedykowanego admina. To nie jest system "set and forget" — recovery, rebalance i monitoring wymagają znajomości architektury. Dla małych projektów rozważ managed storage (AWS S3, Backblaze B2, Wasabi).