Metadaten, DB & WAL einfach erklärt

Die Ebenen auseinanderhalten
Komponente	Aufgabe	Platzierung
CephFS-Metadatenpool	Dateisystem-Namensraum: Verzeichnisse, Namen, Rechte	Replizierter RADOS-Pool über mehrere OSDs; koordiniert durch MDS-Dienste
BlueStore block.db	Interne OSD-Metadaten in RocksDB	Lokal je OSD; optional auf einem separaten schnelleren Gerät
BlueStore block.wal	Write-Ahead-Log für interne Vorgänge	Lokal je OSD; ohne separates WAL normalerweise zusammen mit der externen DB

Was macht der MDS?

Ein CephFS Metadata Server koordiniert Dateisystem-Metadaten und hält aktive Zustände im RAM. Persistentes Journal und Metadaten liegen in RADOS, nicht ausschließlich auf der Bootplatte des MDS-Servers. Dateiinhalte nutzen Datenpools. Ein MDS-Standby hilft beim Dienst-Failover; er ersetzt nicht den Schutz des Metadatenpools.

Wo liegen DB und WAL?

Ein BlueStore-OSD kann Daten, DB und WAL auf einem Gerät halten. Bei HDD-Datenspeicher kann block.db auf schnellerem SSD/NVMe-Speicher Metadaten-I/O beschleunigen. Ohne separates block.wal liegt WAL dann ebenfalls dort. WAL protokolliert interne Änderungen für eine konsistente Wiederherstellung nach einer Unterbrechung. Es ist kein allgemeiner Cache für sämtliche Anwendungsschreibvorgänge und kein Backup.

Beispiel: vier HDD-OSDs, eine gemeinsame NVMe

Stellen Sie sich vier HDD-OSDs auf einem Host vor, deren DB-Bereiche auf einer NVMe liegen. Der Verlust dieser NVMe kann alle vier abhängigen OSDs außer Betrieb setzen, obwohl die HDDs intakt sind. DB/WAL ist wesentlicher Zustand und kein entbehrlicher Cache. Cluster-Redundanz und erfolgreiche Recovery müssen diesen gemeinsamen Ausfall abdecken.

Das bedeutet nicht automatisch clusterweiten Datenverlust. Bei Host-Platzierung bleibt der Verlust innerhalb eines Host-Ausfallbereichs – Recovery muss aber alle betroffenen OSDs berücksichtigen. Mehrere Partitionen auf einer SSD erzeugen keine unabhängigen physischen Ausfallbereiche.

Welchen Engpass möchten Sie lösen?

Bei langsamen Verzeichnisoperationen lohnt sich ein Blick auf MDS-Ressourcen und die Latenz des Metadatenpools. Bei langsamen OSD-Metadatenoperationen sind DB-Platzierung und Auslastung zu prüfen. Das sind Untersuchungsansätze, keine Diagnosen. Messen Sie den realen Workload: Schnellere DB/WAL beschleunigt nicht automatisch große sequenzielle Transfers oder beseitigt einen Netzwerkengpass.

Metadaten genauso sorgfältig schützen wie Dateiinhalte

CephFS-Metadaten benötigen einen replizierten Pool; Erasure Coding wird für diesen Pool nicht unterstützt. Ceph empfiehlt mindestens drei Kopien und schnelle OSDs mit niedriger Latenz. Die CRUSH-Regel muss Kopien über die vorgesehenen Ausfallbereiche verteilen. Intakte Dateidaten-Objekte allein garantieren nach Metadatenverlust kein nutzbares Dateisystem.

Jede Ebene getrennt dimensionieren

Es gibt keinen universellen DB-Prozentsatz für alle Versionen und Workloads. Berücksichtigen Sie Objektanzahl, Objektgröße, omap-Nutzung, Wachstum und Compaction; überwachen Sie anschließend DB-Auslastung und Spillover. Bei voller externer DB können Metadaten auf das langsamere Datengerät ausweichen. Das kann Leistung kosten und ist etwas anderes als ein Ausfall des DB-Geräts.

Was gehört in den Kapazitätsrechner?

Tragen Sie nur die Datenlaufwerke des betrachteten Pools ein. Dedizierte DB/WAL-Geräte und ein separater CephFS-Metadatenpool benötigen ein eigenes Budget. Beispiel: Vier DB-Bereiche mit je 80 GB benötigen zusammen 320 GB zugewiesenen DB-Platz vor zusätzlichen Planungsreserven. Das zeigt die Kapazitätsrechnung, keine empfohlene DB-Größe.

Kapazitätsrechner öffnen →

Technische Quellen

Prüfen Sie die Dokumentation Ihrer eingesetzten Ceph-Version; Standardwerte und Größenempfehlungen ändern sich.