RADOS & Daemons
RADOS (Reliable Autonomic Distributed Object Store) ist das Fundament; RBD, CephFS, RGW und librados setzen darauf auf.
MON: hält die Cluster-Maps (MonMap, MgrMap, OSDMap, CRUSH-Map, MDSMap) und die CephX-Auth-Datenbank, Konsens via Paxos. Ungerade Zahl ≥3, Mehrheit (Quorum) muss up sein. Nur State, keine Nutzdaten.
MGR: aktiv/standby, Module (Dashboard, Prometheus-Exporter, Balancer, Autoscaler, Orchestrator/cephadm). Genau ein active, mind. 2 für HA.
OSD: je einer pro Datenträger. Daten, Replikation, Recovery, Scrubbing, Rebalance. Backend BlueStore.
MDS: nur CephFS, hält POSIX-Metadaten; die Daten liegen in RADOS.
RGW: HTTP-Daemon mit S3- und Swift-API.
CRUSH & Placement
CRUSH (Controlled Replication Under Scalable Hashing) ist deterministisch: der Client rechnet Objekt → PG → OSD selbst, keine zentrale Lookup-Tabelle.
CRUSH-Map = Bucket-Baum (root
→ dc → rack →
host → osd) plus Rules plus
Device-Classes (hdd/ssd/nvme).
PG (Placement Group): Objekt →(Hash)→
PG → Acting-Set (OSDs). Der pg_autoscaler steuert
die PG-Zahl.
Pool: Replikation oder EC, CRUSH-Rule,
pg_num, size/min_size,
Quota, application-Tag
(rbd/cephfs/rgw).
Redundanz & BlueStore
Replikation size=3/min_size=2
(Default, empfohlen): 3-fach Overhead, einfaches Recovery.
Erasure Coding k+m (z. B.
k=4,m=2 → Faktor 1,5): zwei Ausfälle
(je Failure-Domain) ohne Datenverlust, Client-I/O mit dem Default
min_size=k+1 nur bis zu einem. Platzsparend, aber CPU-
und latenzintensiv.
RBD/CephFS brauchen allow_ec_overwrites, ab Tentacle
FastEC per allow_ec_optimizations. RBD-Images legen nur
die Daten in den EC-Pool:
rbd create --size 100G --data-pool ecpool data/vol1.
BlueStore: raw Device + RocksDB, kein Dateisystem dazwischen. FileStore ist seit Quincy (v17) deprecated und ab Reef (v18) nicht mehr unterstützt, also ab Reef BlueStore-only.