CephFS: From Zero to Hero — The Distributed Filesystem, End to End

CephFS in production: MDS architecture, pool design, quotas, snapshots, subvolume groups, multi-MDS scaling, Kubernetes CSI, and operations.

Teaser: Ceph ist das Storage-Backbone hinter OpenStack, dem Sovereign Cloud Stack und tausenden selbstgehosteten Clustern – dennoch behandeln die meisten Engineers es wie eine Blackbox. Dieser Deep Dive analysiert den RADOS Object Store, das On-Disk-Design von BlueStore und das CRUSH-Placement, damit Sie einen Cluster mit Zuversicht designen, deployen und debuggen können – einschließlich der Änderungen, die Squid 19.2 und das kommende Tentacle 20.2 für den Produktiveinsatz mit sich bringen.

Ceph verwandelt eine Ansammlung von Commodity-Disks in einen elastischen Storage-Pool mit drei Protokollen: RBD (Block), RGW (S3-kompatible Objekte) und CephFS (POSIX-Dateisystem). Der Clou ist, dass alle drei lediglich dünne Frontends über demselben verteilten Object Store, RADOS, sind. Wenn Sie RADOS verstehen, verstehen Sie Ceph – und 90 % der Ausfälle in der Produktion werden vorhersehbar.

Der RADOS-Kern: Alles ist ein Objekt

RADOS (Reliable Autonomic Distributed Object Store) ist ein selbstheilender, selbstverwaltender Key-Value Object Store. Jedes Objekt wird durch einen 128-Bit-Namen identifiziert, und Objekte befinden sich in Pools, die Replikation, Erasure Coding und Placement-Regeln definieren.

Die entscheidende Design-Entscheidung: Clients berechnen das Data Placement selbst. Es gibt keinen zentralen Metadaten-Server im I/O-Pfad. Ein Client nimmt einen Objektnamen, hasht diesen in eine Placement Group (PG) und fragt den CRUSH-Algorithmus, welche OSDs diese PG halten sollten. Aus diesem Grund skaliert Ceph linear – die OSDs sind die einzigen Komponenten, die Daten bewegen, und die Cluster-Map ist der einzige gemeinsame Status.

Die Cluster-Map

Jeder Client und jeder Daemon hält eine Kopie der Cluster-Map, die wie eine verteilte Datenbank versioniert wird. Sie enthält:

• Die Monitor-Map (wer sind die MONs, wie sieht das Quorum aus)
• Die OSD-Map (jede OSD, ihr Status, ihr Gewicht, ihre Device-Klasse)
• Die PG-Map (jede PG, ihr Status, ihr Acting Set)
• Die CRUSH-Map (die physische Topologie – Hosts, Racks, Failure Domains)

Wenn sich eine dieser Maps ändert, erhöht sich die Map-Epoch und die Änderung wird per Gossip-Protokoll verbreitet. Veraltete Maps sind die Hauptursache für die meisten Vorfälle mit „misdirected I/O“ und „slow requests“ – weshalb das Tuning der Monitore und die ceph osd pool application-Hygiene wichtiger sind als der reine Durchsatz.

Pools, Replikation und Erasure Coding

Ein Pool ist der Ort, an dem die Policies definiert werden:

• Replicated Pools – jedes Objekt wird N-mal auf N OSDs in verschiedenen Failure Domains gespeichert. Standard ist size=3, min_size=2. Einfach, geringe CPU-Last, höherer Speicherbedarf.
• Erasure-coded Pools – Objekte werden in K Daten-Chunks + M Paritäts-Chunks aufgeteilt. EC 2+1 speichert das 1,5-fache der Daten (gegenüber dem 3-fachen bei Replikaten), kostet aber bei jedem Schreib- und Read-Modify-Write-Vorgang CPU-Leistung. EC ist ideal für Cold Data, RGW-Buckets und große Objekte.

CRUSH: Data Placement ohne Koordinator

CRUSH (Controlled Replication Under Scalable Hashing) ist das, was Ceph von jedem System mit einem Metadaten-Broker unterscheidet. Es ist eine deterministische pseudo-zufällige Funktion über:

CRUSH(object, PG, cluster_map, rule) → ordered list of OSDs

Die Rule kodiert Ihre Failure-Domain-Policy. Eine gängige Regel: „Wähle 3 verschiedene Hosts, dann 1 OSD pro Host“ – dies garantiert, dass ein Host-Ausfall niemals alle Replikate eines Objekts vernichtet.

Die Bucketing-Hierarchie ist die physische Realität, die Sie kodieren: root → datacenter → room → row → rack → host → OSD. Jeder Bucket hat ein Gewicht; OSD-Gewichte sind proportional zur Disk-Kapazität (eine 4-TB-OSD wiegt 4-mal so viel wie eine 1-TB-OSD).

CRUSH Weight vs. OSD Usage – die klassische Falle

Hier scheitern viele Produktionscluster: CRUSH-Gewichte beschreiben die Zielverteilung, nicht die aktuelle Nutzung. Wenn Sie eine neue OSD hinzufügen, rebalanciert CRUSH einen Teil der PGs darauf, aber die Menge hängt vom Gewicht und der PG-Anzahl ab – und ist pro PG-Movement begrenzt. Das balancer-Modul (seit Pacific standardmäßig aktiviert) gewichtet und optimiert periodisch neu, aber bei großen Clustern sollten Sie dennoch:

1. Die PG-Anzahl pro OSD in etwa gleich halten (ceph pg dump $\rightarrow$ prüfen Sie, ob pg_num pro Pool eine Zweierpotenz ist)
2. osd_crush_update_on_start: true verwenden und osd_recovery_max_active für ein kontrolliertes Backfill tunen
3. recovery_rate überwachen und die Recovery während der Geschäftszeiten drosseln

BlueStore: Das moderne OSD-Backend

Seit Luminous übernimmt BlueStore den Datenpfad. Es ersetzt das alte FileStore (ein POSIX-Dateisystem auf einem Dateisystem) durch ein direktes Block-Device-Layout:

• Daten werden als Raw Extents auf dem Block-Device geschrieben – kein Double-Filesystem-Overhead.
• Metadaten liegen in RocksDB, gespeichert auf einem kleinen Fast Device (NVMe/SSD), sofern verfügbar.
• BlueFS ist das minimale Dateisystem, das RocksDB seine Dateien bereitstellt.
• WAL (Write-Ahead Log) absorbiert kleine Schreibvorgänge, bevor sie die Datenregion erreichen.

Diese Trennung von „Fast Device für Metadaten, große HDDs für Daten“ ist der Grund, warum Ceph-HDD-Cluster weitaus besser performen, als man erwarten würde: Der Hot Path der Metadaten liegt auf SSD/NVMe, während die Massendaten auf die Disks streamen.

Wichtige Änderungen in Squid 19.2

Squid (v19.2.x), veröffentlicht am 26. September 2024, ist die aktuelle Long-Term-Stable-Serie. Die Release Notes heben hervor:

• BlueStore optimiert für Snapshot-intensive Workloads – RocksDB LZ4-Kompression standardmäßig aktiviert, was sowohl die durchschnittliche Performance als auch die Belegung des Fast-Devices verbessert.
• Flexiblere Erasure-Code-Konfigurationen und besseres Scrub-Scheduling.
• Crimson Tech Preview – die Next-Generation OSD in Seastar (nur für RBD auf replizierten Pools).
• CephFS Subvolume Quiesce – Pausieren von Schreib-I/O auf einem Subtree für Crash-konsistente Snapshots von verteilten Apps.
• RGW User Accounts + IAM APIs – Self-Service-User, Keys, Gruppen, Rollen und Policies für AWS-Kompatibilität.
• rbd-wnbd Multiplexing – ein Daemon pro Windows-Host statt eines pro Image.
• ceph tell --daemon-output-file – Streaming großer Command-Outputs in eine daemon-lokale Datei, um Memory-Spikes bei den Monitoren zu vermeiden.

cephadm: Die einzige Deployment-Methode, die zählt

Seit Octopus ist cephadm (containerisiert, systemd-verwaltet, SSH-orchestriert) der unterstützte Deployment-Pfad. Manuelle ceph-deploy-Cluster sind Legacy. Wichtige Operationen:

# Bootstrap eines Single-Node-Clusters (erkennt den Host, deployt MON+MGR+OSD)
cephadm bootstrap --mon-ip 192.168.42.10

# Hinzufügen einer OSD auf einem spezifischen Device
ceph orch device zap <host> /dev/sdb --force
ceph orch daemon add osd <host>:/dev/sdb

# Deployment von RGW mit einem Realm+Zone (später für Multisite benötigt)
ceph orch apply rgw rgw.site1 --placement "3 host1 host2 host3" --port 7480

MDS für CephFS bereitstellen

ceph fs volume create cephfs --placement="2 host1 host2"

NVMe/TCP-Gateway für hochperformantes RBD

ceph orch apply nvmeof nvmeof.gw1 --placement "2 host1 host2"

The `ceph orch` layer manages **daemon placement as a desired state**, which is the single biggest quality-of-life improvement in Ceph history: no more hand-edited systemd units or manual config distribution.

### Upgrade Discipline

Ceph requires **upgrading one daemon type at a time**, in order: MONs first, then MGR, then OSDs (by default), then MDS/RGW/clients. `ceph orch upgrade start --image quay.io/ceph/ceph:v19.2.5` handles it, but verify:

- `ceph versions` — all daemons on the same version before proceeding
- `ceph health detail` — no `PG_AVAILABILITY` or `OSD_*` warnings
- Back up the `ceph.conf`, client keys, and the MON store before starting

## Day-2 Operations: The Metrics That Predict Outages

The MGR hosts the Prometheus endpoint (`<mgr-ip>:9283/metrics`). The alerts that actually catch real incidents:

| Metric                          | Threshold       | What it means                           |
| ------------------------------- | --------------- | --------------------------------------- |
| `ceph_osd_down`                 | > 0 for > 5 min | OSD crash or network partition          |
| `ceph_pg_inactive`              | > 0             | PGs stuck — data unavailable            |
| `ceph_pg_degraded`              | > 0 persistent  | Replicas missing, recovery stuck        |
| `ceph_osd_apply_latency`        | > 1s            | Slow OSD — often disk or network issue  |
| `ceph_osd_commit_latency`       | > 1s            | fsync path saturated                    |
| `ceph_cluster_total_used_bytes` | > 85%           | Full cluster — recovery/backfill stalls |
| `ceph_mon_quorum`               | < 3             | Quorum loss = cluster unavailable       |

**The "full" cliff is non-linear.** Ceph blocks writes at `mon_osd_full_ratio` (default 0.95) but degrades _much_ earlier: recovery and rebalancing slow down as free space shrinks, and `nearfull` warnings (0.85) should trigger a capacity plan, not a "wait and see".

## RBD, RGW, and CephFS in Production

### RBD (Block)

The bread and butter for OpenStack/K8s. Key concepts: **image** (thin-provisioned block device), **snapshot** (instant, copy-on-write), **clone** (snapshot-based COW image), and **rbd-mirror** (async replication to a second cluster — the standard DR pattern, with a journal or snapshot-based sync).

Squid's `diff-iterate` improvement makes QEMU live disk sync dramatically faster — this is what powers consistent VM backups without agent-in-VM.

### RGW (Object / S3)

The S3 gateway runs as a stateless frontend over RADOS. For production:

- **Multisite** requires realm → zonegroup → zone structure; one zone per site, sync agents replicate buckets asynchronously
- The Squid fix for the `RGWBucketFullSyncCR` infinite loop (source bucket deleted mid-sync) matters if you do active bucket deletions across sites
- **IAM user accounts** (Squid) replace the legacy S3-style key management for self-service tenants
- TLS 1.3 ciphersuites config (`ssl_ciphersuites`) for the Beast frontend

### CephFS (File)

MDS is the metadata service; **one active MDS per filesystem** is the normal mode, with standbys for failover. Squid's **quiesce API** is the notable new tool: pause I/O on a subtree so distributed apps get crash-consistent snapshots — think databases or job queues on CephFS.

## What Tentacle (v20.2) Brings — Released 2026

**Tentacle is the 20th stable release** (v20.2.2, June 16, 2026). The headline features for operators:

- **Native SMB support** — a new `smb` MGR module deploys Samba-backed SMB shares on CephFS, with CTDB clustering and a `cephfs-proxy` daemon for scale. This finally makes Ceph a credible replacement for Windows file servers and NAS appliances.
- **CephFS case-insensitive / normalized directory entries** — configurable per-directory
- **NVMe/TCP gateway groups and multiple namespaces** — dashboard-managed, with DHCHAP controller keys, namespace encryption, and secure listeners
- **Dashboard overhaul** — multi-cluster management, OAuth 2.0, RGW multisite automation, tiering, notifications, granular replication policy
- **Fast EC restrictions** — non-4K-aligned EC chunk sizes are rejected, closing a class of silent performance bugs
- **NVMeoF fast failover** — beacon grace reduced from 10s to 7s
- **Rocky 10 package-based installs** supported from v20.2.2

For the digital-sovereignty crowd this matters: Ceph + OSISM remains the reference backend for the **Sovereign Cloud Stack**, and the SMB/NVMeoF work widens the "leave the hyperscaler" envelope considerably.

## Design Checklist for a New Cluster

1. **Failure domains**: encode racks (`crush rule` with `rack` as failure domain) or accept host-level only. Never put 3 replicas on one host.
2. **Network separation**: a dedicated **cluster network** for OSD↔OSD replication/backfill; public network for clients. One 10GbE NIC for both is a latency accident waiting to happen.
3. **PG sizing**: total PGs ≈ `(OSDs × 100) / replication_factor`, spread across pools as powers of two. `pg_autoscaler` (default on) helps, but set `target_size_ratio` per pool.
4. **BlueStore fast devices**: give every OSD an NVMe/SSD for `block.db`/`block.wal` if you can't afford all-flash — it's the highest-ROI upgrade for HDD clusters.
5. **Monitors**: odd count, min 3, on separate hosts, **never** alongside heavy OSDs or in the same failure domain. `mon_clock_drift` warnings mean NTP is broken.
6. **Capacity discipline**: alert at 70% used, plan at 80%, panic at 85%. Autoscaler plus `ceph osd reweight-by-utilization` are your friends.
7. **Auth**: CephX everywhere; rotate client keys; scope keys per tenant/application (`mon caps`, `osd caps`, `mgr caps`).
8. **Backup**: RBD images → `rbd export` or mirroring; RGW → bucket replication or `s3 sync` to another cluster; CephFS → snapshots + `cephfs-mirror` (since Pacific).

## Debugging in the Trenches

```bash
# Die drei Befehle, die 90 % der Fragen beantworten
ceph health detail
ceph pg dump_stuck inactive,unclean,undersized
ceph osd tree   # + ceph osd perf für Latenzen pro OSD

# Langsame Anfragen — wo bleibt die Zeit hängen?
ceph daemon osd.<id> dump_historic_ops
ceph daemon osd.<id> dump_ops_in_flight

# Erledigt der Balancer seinen Job?
ceph balancer status
ceph osd df tree

# Inspektion der CRUSH-Map
ceph osd crush rule dump
ceph osd crush tree

Wenn eine OSD langsam ist, prüfen Sie in dieser Reihenfolge: Disk-Health (smartctl), BlueStore-Compaction (ceph daemon osd.N compact), Sättigung des RocksDB-WAL-Devices und schließlich das Cluster-Netzwerk — ceph osd perf plus dump_ops_in_flight helfen dabei, eine sterbende Festplatte von einer gesättigten NIC zu unterscheiden.

Ceph belohnt den Engineer, der seine eine große Kernidee versteht: Placement ohne Koordination. Beherrschen Sie die Cluster-Map, die CRUSH-Rule und das Device-Layout von BlueStore, und der Rest ist operational Hygiene — die richtigen Metriken überwachen, die Recovery drosseln und den Full-Ratio-Cliff respektieren. Mit dem stabilen Release von Squid und den SMB- sowie NVMeoF-Optimierungen in Tentacle gab es noch nie einen besseren Zeitpunkt, den eigenen Storage im eigenen Rechenzentrum zu betreiben.