Ceph w Kubernetes i OpenStack – jeden backend storage dla całej infrastruktury IT

Współczesne działy IT często wpadają w pułapkę silosów: osobny storage dla maszyn wirtualnych, osobny dla kontenerów i jeszcze inny dla obiektów S3. Efektem jest chaos kompetencyjny, dublowanie systemów backupu i marnotrawstwo zasobów sprzętowych. Ceph to rozproszony system storage typu Software-Defined Storage (SDS), który umożliwia jednoczesne udostępnianie bloków, plików i obiektów w jednym klastrze. To rozwiązanie unifikujące, w którym jeden klaster staje się wspólną warstwą danych dla całej infrastruktury IT on-premises, niezależnie od tego, czy korzystasz z klasycznej wirtualizacji OpenStack, czy nowoczesnej orkiestracji Kubernetes.

Konfiguracja klastra storage w środowisku produkcyjnym. Klaster Ceph eliminuje silosy danych – jeden backend obsługuje wolumeny blokowe (RBD), system plików (CephFS) i pamięć obiektową (S3 RGW) dla całej infrastruktury IT.

W SparkSome Venture udowadniamy, że unifikacja backendu to nie tylko wygoda administratorów, ale przede wszystkim optymalizacja TCO. Zamiast zarządzać trzema różnymi ekosystemami, budujemy jeden skalowalny ekosystem, który „mówi” natywnie wieloma protokołami, pozwalając na płynne przechodzenie między światem maszyn wirtualnych a kontenerami.

To jest czwarta część naszej serii o suwerennej i odpornej infrastrukturze. Sprawdź również:

1. Dlaczego klasyczna macierz SAN przestaje mieć sens w 2026 roku?
2. Deep Dive: Architektura Ceph, CRUSH i RADOS bez tajemnic.
3. Replikacja 3x czy Erasure Coding 4+2? Realny koszt storage.

Porównanie: Ceph vs tradycyjna macierz SAN vs chmurowy storage

Zanim zagłębimy się w szczegóły integracji, warto zobaczyć, jak Ceph wypada na tle tradycyjnych rozwiązań storage:

Parametr	Macierz SAN (np. Dell PowerStore, HPE)	Ceph (Software-Defined Storage)	Cloud Storage (AWS EBS/S3)
Typ rozwiązania	Sprzętowe (appliance)	Programowe (SDS)	Usługa (as-a-Service)
Skalowalność	Ograniczona (shelf expansion)	Liniowa (dodajesz węzły)	Praktycznie nieograniczona
Vendor Lock-in	Silny (firmware, dyski, wsparcie)	Brak (open source, commodity hardware)	Średni (API kompatybilne, egress fees)
Protokoły	iSCSI, FC, NFS	RBD, CephFS, S3 (RGW) – jednocześnie	EBS (blok), S3 (obiekt), EFS (plik)
Redundancja	RAID, dual-controller	Replikacja 3× lub Erasure Coding	Wbudowana (multi-AZ)
SPOF (Single Point of Failure)	Kontroler (mimo dual)	Brak – architektura rozproszona	Brak (odpowiedzialność providera)
Koszt wejścia	50 000–500 000+ PLN	Commodity serwery + dyski (~30 000–100 000 PLN)	0 PLN CapEx (OpEx)
Koszt na TB (5 lat)	Wysoki (licencje, wsparcie, dyski dedykowane)	Niski (open source, standardowe dyski)	Średni–Wysoki (egress + IOPS)
Integracja z Kubernetes	Ograniczona (CSI plugin, nie natywna)	Natywna (Rook, CSI)	Natywna (EBS CSI)
Integracja z OpenStack	Plugin Cinder	Natywna (Cinder, Glance, Nova)	N/A (nie on-premises)
Samonaprawa	Brak (rebuild RAID)	Automatyczna (CRUSH rebalancing)	Automatyczna (provider)

Ceph w Kubernetes: Rook, RBD i dynamiczny storage dla aplikacji stanowych

W świecie cloud-native storage musi być tak samo elastyczny jak same kontenery. Kluczowym narzędziem w tej integracji jest Rook – otwartoźródłowy operator Kubernetes, który automatyzuje wdrażanie, zarządzanie i skalowanie klastra Ceph bezpośrednio wewnątrz ekosystemu kontenerowego. Dzięki Rook, Ceph przestaje być zewnętrznym „pudełkiem”, a staje się natywną częścią orkiestracji.

Dla zespołów DevOps oznacza to koniec czekania na przydzielenie zasobów. Wykorzystując interfejs CSI (Container Storage Interface) oraz zasoby Ceph RBD (Block Device), system realizuje dynamic provisioning – aplikacja sama „zamawia” potrzebną przestrzeń poprzez StorageClasses i PVC (Persistent Volume Claims). Ceph w Kubernetes to także zaawansowana obsługa snapshotów i klonów, co pozwala na błyskawiczne testowanie baz danych na realnych zbiorach danych bez wpływu na produkcję. Inteligencja systemu opiera się na algorytmie CRUSH, który rozprasza dane w domenach awarii bez potrzeby posiadania centralnego kontrolera.

Jak wygląda provisioning storage w Kubernetes z Ceph?

Poniższy przykład pokazuje, jak prosto aplikacja zamawia sobie wolumen blokowy Ceph:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph-block
provisioner: rook-ceph.rbd.csi.ceph.com
parameters:
  pool: replicapool
  clusterID: rook-ceph
  csi.storage.k8s.io/fstype: ext4
reclaimPolicy: Delete
allowVolumeExpansion: true  # <- można rozszerzać wolumen online
---
# PVC – aplikacja "zamawia" 50 GB storage
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: ceph-block
  resources:
    requests:
      storage: 50Gi

Kluczowe cechy tego podejścia:

• Dynamic provisioning – wolumen tworzony automatycznie, bez interwencji admina
• Volume expansion – allowVolumeExpansion: true pozwala rozszerzać wolumen online
• Snapshoty – VolumeSnapshot API umożliwia tworzenie spójnych snapshotów bazy danych
• Klonowanie – szybkie tworzenie kopii wolumenu produkcyjnego do testów (Copy-on-Write)

Ceph w OpenStack: Fundament dla suwerennej chmury prywatnej (IaaS)

Podczas gdy Kubernetes dominuje w świecie mikrousług, OpenStack (platforma do budowy chmur prywatnych IaaS) pozostaje najpotężniejszym wyborem do zarządzania klasyczną infrastrukturą. W takich środowiskach Ceph RBD pełni rolę „układu krwionośnego”, integrując się natywnie z usługami Cinder (wolumeny blokowe) oraz Glance (obrazy systemów operacyjnych).

Największą przewagą tej integracji jest mechanizm Copy-on-Write. Pozwala on na niemal natychmiastowe uruchomienie setek maszyn wirtualnych, ponieważ system nie kopiuje całego obrazu systemu, a jedynie zapisuje zmiany (deltę) względem wzorca. To sprawia, że provisioning w chmurze opartej o OpenStack i Ceph jest o rzędy wielkości szybszy niż w tradycyjnych macierzach SAN, przy jednoczesnym zachowaniu inżynierskiego rygoru i bezpieczeństwa danych.

Integracja Ceph z komponentami OpenStack

Komponent OpenStack	Funkcja	Integracja z Ceph
Cinder	Wolumeny blokowe dla VM	Ceph RBD jako backend – tworzenie, snapshoty, klony
Glance	Obrazy systemów operacyjnych	Przechowywanie image’ów w pool RBD – Copy-on-Write boot
Nova	Hypervisor / compute	Bezpośredni boot z RBD (ephemeral disks)
Manila	Shared File System	CephFS jako backend POSIX
Swift (alternatywa)	Object Storage	Ceph RGW jako zamiennik kompatybilny z S3

W środowisku Proxmox VE integracja jest równie natywna – Proxmox obsługuje Ceph RBD jako storage dla VM i kontenerów LXC, a od wersji 7.x umożliwia nawet zarządzanie klastrem Ceph bezpośrednio z GUI. Więcej o wyborze platformy wirtualizacyjnej piszemy w artykule o wyborze serwera do firmy.

Dlaczego jeden backend Ceph dla VM i kontenerów zmienia architekturę IT?

Prawdziwa rewolucja następuje w punkcie styku tych dwóch światów. Posiadanie jednego backendu Ceph dla maszyn wirtualnych (VM) i kontenerów drastycznie upraszcza architekturę IT:

• Brak duplikacji danych: obrazy systemów, bazy danych i pliki S3 znajdują się w jednej puli. Nie musisz migrować terabajtów między „wyspami” storage’u.
• Spójny model Disaster Recovery: jeden mechanizm replikacji i backupu (np. przy użyciu Ceph RBD Mirroring) chroni całą firmę, niezależnie od technologii warstwy wyższej. Więcej o strategiach DR w artykule o Disaster Recovery Plan.
• Redukcja silosów kompetencyjnych: jeden zespół inżynierski zarządza jednym spójnym stosem technologicznym. Wspólny monitoring (Prometheus/Grafana) i ujednolicony model operacyjny to „święty spokój” dla CTO.

Zunifikowany backend Ceph może jednocześnie obsługiwać:

• Wolumeny blokowe (RBD): idealne dla maszyn wirtualnych i baz danych.
• System plików (CephFS): rozproszone zasoby plikowe zgodne z POSIX.
• Pamięć obiektową (RGW S3): kompatybilną z AWS S3, dla aplikacji i backupów.

Jeden backend – wiele zastosowań w praktyce

Workload	Komponent Ceph	Główna korzyść
Kubernetes	RBD / CephFS	Dynamiczny storage dla kontenerów (CSI)
OpenStack / Proxmox	RBD	Błyskawiczne wolumeny i obrazy VM
Backup / Archiwum	RGW (S3)	Tania i trwała pamięć obiektowa kompatybilna z AWS
Dane współdzielone	CephFS	Rozproszony system plików dla klastrów obliczeniowych

Minimalne wymagania sprzętowe klastra Ceph

Planując wdrożenie Ceph, warto znać minimalne i rekomendowane wymagania sprzętowe:

Klaster produkcyjny – minimalna konfiguracja (3 węzły OSD + 3 MON)

Komponent	Minimum (pilotaż)	Rekomendacja (produkcja)	Uwagi
Węzły OSD (storage)	3	5–7+	Więcej węzłów = lepsza redundancja i wydajność
CPU per węzeł OSD	4 rdzenie	16–32 rdzeni	~1 rdzeń na OSD daemon + overhead
RAM per węzeł OSD	16 GB	64–128 GB	~5 GB per OSD + cache
Dyski OSD	3× HDD/SSD per węzeł	8–12× NVMe/SSD per węzeł	Erasure Coding wymaga min. k+m dysków
Dyski WAL/DB	Opcjonalne	Dedykowane NVMe (1 per 4–6 OSD)	Przyspieszenie metadanych dla HDD
Sieć OSD ↔ OSD (Cluster)	10 GbE	25 GbE	Oddzielna sieć replikacyjna!
Sieć OSD ↔ Client (Public)	10 GbE	10–25 GbE	Ruch aplikacyjny
Węzły MON/MGR	3 (kolokacja z OSD)	3–5 (dedykowane)	Quorum wymaga nieparzystej liczby

Wskazówka SparkSome: Najczęstszym błędem jest oszczędzanie na sieci. Ceph replikuje dane między węzłami – jeśli ruch replikacyjny współdzieli sieć z ruchem klientów, latencja rośnie dramatycznie. Zawsze separuj sieć Cluster od Public. Problemy sieciowe w Ceph diagnozujemy na warstwie L1/L2.

Architektura produkcyjna – inżynierski rygor SparkSome Venture

W SparkSome nie wdrażamy technologii „pudełkowych”. Projektujemy systemy zgodnie z rygorem, który wybacza awarie sprzętowe. Projektowaliśmy klastry, które obsługują jednocześnie środowiska produkcyjne, testowe i backupowe bez separacji fizycznych macierzy, co drastycznie obniża koszty wejścia i upraszcza zarządzanie. Kluczowe aspekty naszych wdrożeń to:

• Separacja sieci (Cluster vs Public): izolujemy ruch replikacyjny klastra od ruchu użytkowników. Dzięki temu procesy samonaprawy danych nie powodują wzrostu latencji w aplikacjach biznesowych.
• Zarządzanie cyklem życia (Lifecycle): realizujemy rolling upgrades oraz wymianę całych węzłów bez sekundy przestoju dla systemów produkcyjnych. Twoja chmura rośnie i modernizuje się „w locie”.
• Obserwowalność: klaster Ceph jest w pełni opomiarowany. Wiemy o potencjalnej awarii dysku, zanim system zgłosi błąd, co pozwala na prewencyjną wymianę podzespołów. Monitorujemy kluczowe metryki: latencję OSD, IOPS per pool, wykorzystanie capacity, stan health klastra – więcej o naszym podejściu do monitoringu w artykule o Zabbixie i bezawaryjnym IT.

Checklist wdrożenia Ceph – co weryfikujemy przed deployment’em

• Topologia CRUSH – mapowanie domen awarii (rack, host, datacenter)
• Separacja sieci – dedykowana sieć Cluster (replikacja) ≠ Public (klienty)
• Profil ochrony danych – replikacja 3× (niska latencja) lub EC 4+2 (duża pojemność)
• Rozmiar PG – auto-PG tuner od Ceph Quincy+ lub ręczna kalkulacja
• WAL/DB na NVMe – dla klastrów z HDD (kluczowe dla write latency)
• Monitoring – Prometheus + Grafana z dashboardami Ceph
• Testy wydajności – benchmarki rados bench, fio, rbd bench
• Plan DR – RBD Mirroring do drugiej lokalizacji lub backup w chmurze
• Dokumentacja As-built – topologia, hasła, CRUSH rules, pool policies

Kiedy zunifikowany storage Ceph ma sens biznesowy?

Inwestycja w jeden backend dla całej infrastruktury to decyzja strategiczna, która najlepiej sprawdza się w trzech scenariuszach:

1. Software House’y i SaaS: Gdzie szybkość powoływania środowisk testowych i produkcyjnych decyduje o czasie wprowadzenia produktu na rynek (Time-to-Market).
2. Przemysł i Industry 4.0: Gdzie systemy sterowania i ERP (maszyny wirtualne) muszą współpracować z nowoczesną analityką danych i AI działającą w kontenerach. W takich środowiskach Edge Computing na brzegu sieci współpracuje z centralnym klastrem Ceph.
3. Sektor medyczny i Gov: Gdzie suwerenność technologiczna i kontrola nad fizycznym miejscem składowania danych (on-premises) są wymogiem prawnym i etycznym.

Kiedy Ceph NIE jest optymalnym wyborem?

• Infrastruktura <3 serwerów – Ceph wymaga minimum 3 węzłów. Dla 1–2 serwerów lepszy jest ZFS + replikacja.
• Tylko NAS / file sharing – jeśli jedynym wymaganiem jest serwer plików, Synology lub TrueNAS będzie prostsze.
• Wyłącznie bazy danych z ekstremalnym IOPS – dla workloadów wymagających <100 μs latencji lokalny NVMe (bez warstwy sieciowej) będzie szybszy.
• Brak kompetencji zespołu – Ceph wymaga wiedzy inżynierskiej. Bez doświadczonego zespołu lub partnera operacyjnego wdrożenie może grozić przestojami.