CephFS: From Zero to Hero — Das verteilte Dateisystem, End-to-End
🇬🇧 Read in English~10 min read
DevOpsStoragecephcephfsdistributed-storageposixmdskubernetescsisnapshotsquotasreadwritemany
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Ein tiefer Einblick in OSISM – die Plattform, die OpenStack, Ceph und Kubernetes zu einer einheitlichen, souveränen Private Cloud orchestriert. Behandelt werden die Architektur, die Komponenten sowie der vollständige Installationsablauf.
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.
Die Architektur erklärt das Betriebsmodell auf einen Blick:
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.
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:
auth_cluster_required, auth_service_required, auth_client_required). Es gibt keinen Grund, sie zu deaktivieren.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.
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.
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.
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.
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.
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.
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.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.
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.
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.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.
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.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.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.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.| 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 %.
Ein produktionsreifes CephFS-Deployment, kompakt zusammengefasst:
min_size.ceph balancer on, ceph pg autoscaler on — lassen Sie den Cluster die langweilige Arbeit erledigen.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.