CephFS: From Zero to Hero — Das verteilte Dateisystem, End-to-End | DevOps

Back openDesk Edu for a sovereign, open-source education — every vote counts.

CephFS: From Zero to Hero — Das verteilte Dateisystem, End-to-End | DevOps | Tobias Weiss

Das Dateisystem auf dem Object Store

CephFS ist das POSIX-Dateisystem, das auf RADOS aufsetzt – demselben Object Store, der auch die Block- (RBD) und Object-Schnittstellen (RGW/S3) von Ceph antreibt. Während ein Dateisystem wie ext4 oder XFS auf einer einzelnen Festplatte liegt, existiert CephFS auf einem Cluster: Metadaten werden von dedizierten Metadata Servern (MDS) bereitgestellt, Daten werden über OSDs gestriped und Clients kommunizieren direkt mit beiden. Es gibt keinen einzelnen Knoten, der Ihre Dateien hält.

Loading diagram...

Die Architektur erklärt das Betriebsmodell auf einen Blick:

MONs verwalten die Cluster-Map (wer ist wer, was ist wo). Drei ist das Standardminimum für das Quorum.
OSDs speichern die eigentlichen Daten und die Dateisystem-Metadaten, verteilt durch CRUSH. Nichts an Ihren Dateien existiert außerhalb des Object Stores.
MDSs verwalten den Datei-Namespace – Verzeichnisse, Namen, Layouts, Locks – und journalisieren Änderungen. Sie halten keine Daten, sondern nur Metadaten, weshalb Sie das Dateisystem durch das Hinzufügen von MDS-Daemons statt durch größere Festplatten skalieren können.
Clients (Kernel, FUSE, CSI) rufen das Datei-Layout von einem MDS ab und lesen/schreiben Daten dann direkt von den OSDs – der MDS ist kein Daten-Flaschenhals.

CephFS ist das richtige Werkzeug, wenn Sie einen gemeinsamen POSIX-Namespace mit Locks benötigen: mehrere Schreiber auf denselben Dateien, Verzeichnisquoten, Snapshots und Unterverzeichnisse mit unabhängigen Lebenszyklen. Wenn Sie nur Single-Writer-Volumes benötigen, ist RBD einfacher; wenn Sie nur Buckets benötigen, ist RGW/S3 einfacher. CephFS ist die Wahl, wenn viele Maschinen gleichzeitig auf dieselben Dateien zugreifen müssen.

Teil 1 — Null: Ein Dateisystem bootstrappen

1.1 Der Cluster muss zuerst existieren

CephFS hat keinen Standalone-Modus – man beginnt mit einem RADOS-Cluster. Der schnellste produktionsreife Weg im Jahr 2026 ist cephadm (containerisierte Daemons, verwaltet durch systemd) oder Rook (dieselben Daemons als Kubernetes-Pods). Auf Bare Metal ist cephadm der Standard:

# Bootstrap a single-node cluster, then add hosts
cephadm bootstrap --mon-ip 10.0.0.10
ceph orch host add node-2
ceph orch host add node-3

# Deploy the monitor and manager quorum
ceph orch apply mon node-1,node-2,node-3
ceph orch apply mgr node-1,node-2,node-3

# Add OSDs — one per disk, never partition a disk for Ceph
ceph orch device zap node-1 /dev/sdb --force
ceph orch apply osd --all-available-devices

Zwei Konfigurationsentscheidungen sind wichtig, bevor Sie ein Dateisystem erstellen:

Getrennte Public- und Cluster-Netzwerke. Client-Traffic nutzt das Public-Netzwerk; Replikation, Heartbeats und Recovery nutzen das Cluster-Netzwerk. In dem Referenz-Deployment hinter diesem Artikel sind die beiden separate VLANs – die OSD-zu-OSD-Replikation konkurriert niemals mit dem Client-I/O.
cephx-Authentifizierung standardmäßig aktiviert für alle drei Ebenen (auth_cluster_required, auth_service_required, auth_client_required). Es gibt keinen Grund, sie zu deaktivieren.

1.2 Das Dateisystem erstellen

Ein CephFS benötigt zwei Pools: einen für Metadaten (kleine Objekte, viele Operationen, benötigt geringe Latenz) und einen für Daten. Im Daten-Pool liegen Ihre Dateien tatsächlich; der Metadaten-Pool enthält Verzeichniseinträge, Inode-Attribute und das MDS-Journal.

# Metadata pool — replicated, small
ceph osd pool create cephfs_metadata 32 replicated
ceph osd pool application enable cephfs_metadata cephfs

# Data pool — replicated (EC data pools work too, see Part 4)
ceph osd pool create cephfs_data 128 replicated
ceph osd pool application enable cephfs_data cephfs

# Create the filesystem (one MDS to start)
ceph fs new cephfs cephfs_metadata cephfs_data
ceph fs status

ceph fs status sollte einen MDS in active, den Daten-Pool und den Metadaten-Pool anzeigen. Das ist der gesamte Bootstrap – das Dateisystem existiert nun und kann gemountet werden.

1.3 Mounten

Der Kernel-Client ist die Wahl für die Produktion; ceph-fuse ist der Fallback, wenn Kernel-Module nicht geladen werden können (Container, macOS, ältere Kernel):

# Kernel client — needs the cephx key
mount -t ceph node-1:6789,node-2:6789,node-3:6789:/ /mnt/cephfs \
  -o name=admin,secretfile=/etc/ceph/admin.keyring

# FUSE client
ceph-fuse -m node-1:6789,node-2:6789,node-3:6789 /mnt/cephfs

Verwenden Sie alle MON-Adressen im Mount-String. Der Client muss beim Start einen Monitor erreichen können; eine einzelne, hartcodierte MON-Adresse ist ein Single Point of Failure für jeden Mount in Ihrer Flotte.

Teil 2 — Dateisystem-Superkräfte

2.1 Verzeichnisquoten

CephFS-Quoten sind Verzeichnisquoten: Sie werden auf einem Verzeichnis gesetzt und für alles darunter erzwungen. Zwei Dimensionen: Byte-Limit und Dateianzahl.

# 100 GiB and 100k files on /mnt/cephfs/projects/alpha
ceph fs set-quota /mnt/cephfs/projects/alpha 100G 100000
ceph fs get-quota /mnt/cephfs/projects/alpha

Quoten sind der Mechanismus, der Multi-Tenant-Dateisysteme sicher macht: Jedes Team erhält ein Verzeichnis mit einer Quote, und kein Team kann den Pool für alle anderen erschöpfen. Die Durchsetzung erfolgt nach dem Prinzip Best-Effort mit einer Grace Period – ein Client, der das Quotensignal ignoriert, kann kurzzeitig darüber schreiben, bevor er blockiert wird – lassen Sie daher Puffer im Pool, nicht in den Quoten.

2.2 Snapshots

CephFS-Snapshots sind asynchron, Copy-on-Write und kostenlos in der Erstellung, bis sich Daten tatsächlich ändern. Keine Pool-Bereitstellung, kein Agent, kein Quiescing:

# Snapshots befinden sich im versteckten .snap-Verzeichnis
mkdir /mnt/cephfs/projects/alpha/.snap/pre-migration
ls /mnt/cephfs/projects/alpha/.snap/
rmdir /mnt/cephfs/projects/alpha/.snap/pre-migration   # Snapshot löschen

Snapshots are per-directory and recursive. They are the native primitive behind backup tools (K8up and Velero both snapshot CephFS volumes through the CSI) and behind "oops, that migration deleted a directory" recovery.

2.3 Subvolume groups — the multi-tenant primitive

Subvolumes are the modern building block: a directory with its own inode, quota, and snapshot layout, addressable by name. Subvolume groups add a second level of organization, and the CSI driver creates one subvolume per PVC inside a group.

# Gruppe für Kubernetes-Volumes, ein Subvolume pro PVC
ceph fs subvolumegroup create cephfs k8s
ceph fs subvolume create cephfs pvc-workspace --group k8s --size 20G
ceph fs subvolume ls cephfs --group k8s
ceph fs subvolume snapshot create cephfs pvc-workspace --group k8s snap-1

Subvolumes matter operationally because they give you per-volume quotas, per-volume snapshots, and clean deletion — a plain directory tree with a thousand PVCs would be an unmanageable mess.

2.4 Scaling: multiple MDS daemons

One active MDS can serve a very large filesystem, but metadata throughput is finite. The fix is more MDS daemons — CephFS shards the namespace (by directory tree) across them:

# Bis zu 4 aktive MDS-Daemons (Ranks) zulassen
ceph fs set cephfs max_mds 4
ceph fs status        # Beobachten, wie die Ranks 0-3 hochfahren

# Standby-replay hält einen warmen Standby bereit, um sofort zu übernehmen
ceph fs set cephfs allow_standby_replay true

The balancer does the rest: CephFS automatically partitions the namespace into subtrees (by directory tree) and spreads them across the active ranks, migrating hot directories to less-loaded MDS daemons. Tune the aggression with mds_bal_* options (e.g. mds_bal_split_size) if a few directories dominate.

The MDS is memory- and CPU-bound, not disk-bound (metadata lives on OSDs). Sizing rule of thumb: start with one active MDS per ~10–20k files or per ~100k metadata operations per second, and let ceph fs status + the balancer tell you when to add more. Standby MDS daemons (one per active rank) fail over in seconds when an active MDS dies.

Part 3 — CephFS in Kubernetes: The CSI Path

The reason most teams meet CephFS in 2026 is Kubernetes. The ceph-csi-cephfs driver turns the filesystem into a dynamic provisioner with ReadWriteMany volumes — the only way to get true multi-pod, multi-node file storage without NFS.

# StorageClass — das fsName/pool-Paar wählt das Dateisystem aus
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cephfs-workspaces
provisioner: cephfs.csi.ceph.com
parameters:
  clusterID: <ceph-cluster-id>
  fsName: cephfs
  pool: cephfs_data
  csi.storage.k8s.io/snapshotter-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/snapshotter-secret-namespace: default
reclaimPolicy: Retain
allowVolumeExpansion: true

# Ein RWX-Workspace-Volume — genau das Muster, das von einem
# gemeinsam genutzten Nix-Builder im Referenzcluster verwendet wird
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nix-workspace
  namespace: nix-builder
spec:
  accessModes: [ReadWriteMany]
  storageClassName: cephfs-workspaces
  resources:
    requests:
      storage: 20Gi

Two details in that StorageClass are load-bearing:

fsName + pool pin the volume to a specific filesystem and data pool. The CSI driver creates one subvolume per PVC (with a size quota from the PVC's storage request) — the "subvolume group" from Part 2 is what keeps a hundred PVCs tidy.
allowVolumeExpansion: true lets you grow PVCs without recreating them; CephFS subvolume quotas are dynamic, so expansion is instant.
Snapshots work through the standard VolumeSnapshot API with the snapshotter secret referenced above — K8up, Velero, and plain kubectl snapshots all land as CephFS subvolume snapshots.

The real-world reference for this section: a three-node bare-metal cluster (Ceph Reef 18.2.8, cephadm under systemd) running K3s, where a Nix builder consumes a 50 GiB RBD volume for /nix and a 20 GiB CephFS RWX volume for /workspace — the filesystem being built is shared read-write between builder pods on different nodes. Storage classes for both (rbd and cephfs) are provisioned by ceph-csi with Retain reclaim policy and snapshotting wired up. That one workspace volume is the entire reason CephFS is on the cluster: RWX, no NFS, no single point of failure.

The killer feature pairing: CephFS RWX + subvolume snapshots gives you multi-writer storage and point-in-time recovery through the standard Kubernetes APIs — no storage-adjacent sidecar daemons to operate.

Part 4 — Hero: Operations and Performance

4.1 Monitoring — the five numbers that matter

ceph fs status                          # MDS-Ranks, aktiv/standby, laggy clients
ceph fs dump | head                     # Dateisystem-Konfiguration, max_mds, Session-Timeout
ceph mds stat                           # Status pro Rank, Laufzeit, Caps
ceph osd perf                           # Commit/Apply-Latenz pro OSD — Ihr Datenpfad
ceph pg stat                            # Health der Placement Groups — der Puls des Clusters

Besonders beobachten: MDS-Speicher (Metadaten-Cache; ein kleiner Standard-Cache bei einem ausgelasteten Dateisystem führt zu Thrashing), Client-Eviction (ceph tell mds.* client evict, wenn ein hängender Client ein Verzeichnis blockiert) und volle Pools — ein CephFS, dessen Daten-Pool full_ratio erreicht, stoppt die Annahme von Schreibvorgängen clusterweit, nicht nur in einem Verzeichnis.

4.2 Fehlerbehandlung

MDS stürzt ab → Standby übernimmt innerhalb von Sekunden. Clients verbinden sich neu; laufende Metadaten-Operationen schlagen fehl, Dateidaten hingegen nicht (da diese bereits auf den OSDs lagen).
OSD stürzt ab → der Cluster repliziert die Daten aus den verbleibenden Kopien; ceph health wird zu WARN (degraded) und kehrt zu HEALTH_OK zurück, sobald der Backfill abgeschlossen ist. Ein Dateisystem auf einem gesunden Pool bemerkt davon nichts.
Knoten stürzt ab → solange das MON-Quorum überlebt (2 von 3), bleibt das Dateisystem online. Deshalb besteht der minimale Cluster aus drei Knoten, auf denen die MONs verteilt sind.

Das Layout des Referenzclusters folgt exakt diesem Prinzip: drei Knoten, MON/MGR/MDS auf allen drei ko-lokalisiert, acht OSDs verteilt in 4/2/2. Der Ausfall eines beliebigen Knotens erhält das Quorum, hält den MDS aktiv (Standby auf einem anderen Knoten) und lässt die Daten lesbar.

4.3 Performance-Hebel

Pool-Größe und min_size. size 3 toleriert zwei gleichzeitige OSD-Ausfälle; min_size 2 stellt Schreibvorgänge während eines einzelnen Ausfalls weiterhin bereit. Setzen Sie min_size 1 niemals für einen Dateisystem-Pool — Sie würden nicht replizierte Schreibvorgänge bedienen und dies bereuen.
Erasure-coded Daten-Pools. CephFS- Daten-Pools können EC sein (Metadaten-Pools nicht — diese müssen repliziert bleiben). EC bietet RAID-ähnliche Effizienz (z. B. k=4,m=2 = 1,5× Rohkapazität bei einer Toleranz von 2 Ausfällen) auf Kosten von CPU und der Performance bei kleinen Schreibvorgängen. Aktivieren Sie dies nur, wenn die Kapazität und nicht die Latenz die einschränkende Variable ist.
Clientseitige Caches. Kernel-Client-Readahead und mount -o rsize/wsize sind wichtig für große sequentielle Workloads; die MDS-Cache-Größe (mds_cache_memory_limit) ist entscheidend für metadatenintensive Workloads wie Build-Trees — wie im Fall des Nix-Builders.
Netzwerktrennung. Der größte Performance-Fehler ist es, den Replikationsverkehr über das Client-Netzwerk laufen zu lassen. Der Referenzcluster trennt diese per VLAN, weshalb die OSD-commit/apply-Latenz im niedrigen einstelligen Millisekundenbereich bleibt.
ceph balancer. Lassen Sie den Balancer die PGs periodisch über die OSDs neu verteilen (ceph balancer mode crush-compat; ceph balancer on), um eine gleichmäßige Auslastung zu gewährleisten — ein unausgewogener Cluster macht eine einzelne "heiße" OSD zum Flaschenhals für alle.

4.4 Die Troubleshooting-Tabelle

Symptom	Zuerst zu prüfen	Wahrscheinliche Lösung
Mount hängt	`ceph -s` Quorum, MON-Erreichbarkeit	MON-Adressliste im Mount-String; Firewall im öffentlichen Netzwerk
Schreibvorgänge clusterweit stagnieren	`ceph df` Pool `FULL`	OSDs hinzufügen oder `mon_osd_full_ratio` (vorsichtig) erhöhen; Quotas auf Fehlkonfiguration prüfen
Ein Verzeichnis ist langsam	`ceph tell mds.<rank> client ls`	Ein Client mit einem nicht reagierenden Mount hält Caps; diesen evicten
`ls` ist langsam, Reads sind schnell	MDS-Speicher / `mds_cache_memory_limit`	Metadaten-Cache erhöhen; einen MDS-Rank hinzufügen
Replikation verbraucht gesamte Bandbreite	`ceph osd tree` + Node-NIC-Statistiken	Cluster-Netzwerk fehlt oder teilt sich das öffentliche VLAN
Snapshots nach Backup fehlen	CSI-Snapshotter-Secrets	`csi.storage.k8s.io/snapshotter-secret-*` in der StorageClass

Bevor Sie an irgendwelchen „Tuning“-Reglern drehen, prüfen Sie ceph health detail. Die meisten CephFS-Probleme in der Produktion sind keine Tuning-Probleme – es sind volle Pools, ausgefallene OSDs, die auf Backfill warten, oder Clock Skew, der das MON-Quorum stört. Beheben Sie diese zuerst; Tuning sind die letzten 10 %.

Die Hero-Checkliste

Ein produktionsreifes CephFS-Deployment, kompakt zusammengefasst:

Drei oder mehr Nodes, MONs verteilt für das Quorum, MDS-Standbys entsprechend der aktiven Ranks.
Öffentliche und Cluster-Netzwerke getrennt (VLANs oder dedizierte NICs).
cephx aktiviert; Dashboard und Prometheus-Exporter vom ersten Tag an enabled.
Metadaten-Pool repliziert; Daten-Pool repliziert oder EC mit bewusstem min_size.
Eine Subvolume-Gruppe pro Tenant/Workload; Quotas für jede Gruppe.
Snapshots im Backup-Workflow (K8up/Velero via CSI) – lassen Sie niemals ein Dateisystem aus, das Snapshots unterstützt.
ceph balancer on, ceph pg autoscaler on — lassen Sie den Cluster die langweilige Arbeit erledigen.
Dokumentieren Sie das OSD-Austauschverfahren, bevor Sie es benötigen.

CephFS ist die am wenigsten glamouröse der drei Ceph-Schnittstellen, aber diejenige, die den höchsten Wert pro Operator-Stunde liefert, sobald sie läuft: ein selbstheilendes, Snapshot-fähiges POSIX-Dateisystem mit Quota-Durchsetzung, das Ihren gesamten Cluster überspannt. Beginnen Sie mit einem Drei-Node-Cluster und einem Workspace-Volume; der Rest lässt sich von dort aus skalieren.

Cart

Wishlist

Your wishlist is empty

CephFS: From Zero to Hero — Das verteilte Dateisystem, End-to-End

Running a 27B Hybrid SSM Model with 128k Context on a 12 GB Laptop GPU

k3s Disaster Recovery Testing und Edge-Patterns

Ceph Deep Dive: RADOS, BlueStore, CRUSH, and Running a Sovereign Storage Cluster