Wer sehr viele Daten über einen langen Zeitraum speichern muss, steht vor einem Problem: Die Bauart vieler kommerzieller Storage-Systeme lässt zum einen keine beliebigen Kapazitätserweiterungen zu. Zudem laufen diese irgendwann aus der Wartung und der Anwender muss nicht nur ein neues Storage anschaffen, sondern auch die bestehenden Daten aus dem alten migrieren. Hier hilft ein Software-defined Scale-out-Storage wie Ceph gleich mehrfach. Als Speicherknoten dienen reguläre Server mit Platten wie auch SSDs.

Dabei spielt es keine Rolle, wenn unterschiedliche Server zum Einsatz kommen. Das betrifft sowohl die Ausstattung wie CPU oder Arbeitsspeicher als auch die Anzahl oder den Typ der Platten. Zudem benötigt Ceph keine Downtime für Umbau, Updates oder sonstige Änderungen. Der Administrator kann im laufenden Betrieb einfach neue Speicherknoten nachrüsten und alte entfernen. Der Zugriff zu den Daten erfolgt zudem nicht durch den Flaschenhals eines zentralen Kontrollknotens. In Teil 1 erfahren Sie, wie Ceph funktioniert und in Teil 2 des Workshops bauen wir einen Ceph-Cluster auf.

Ceph ist ein verteilter Objektspeicher, der seine Kerntechnik als "Rados" (Reliable Autonomic Distributed Object Store) bezeichnet. Das Speichersystem zerlegt ankommende Objekte in Blöcke, die es mit der passenden Redundanz dann auf den Cluster-Knoten und Platten verteilt. Die Verteilung der Objekte erfolgt dabei "pseudozufällig". Das bedeutet, Ceph verteilt die Daten so gleichmäßig wie möglich, folgt dabei aber einem Algorithmus.

Im Unterschied zu anderen Speichersystemen gibt es bei Ceph nämlich keinen Kontrollknoten, der die Verteilung koordiniert und über den die Kommunikation mit den Clients stattfindet. Vielmehr übermittelt Ceph seinen angebundenen Clientsystemen den aktuellen Algorithmus, sodass diese für Lese- und Schreiboperationen direkt auf die betroffenen Knoten zugreifen. Damit gibt es keinen Flaschenhals und auch keinen Single-Point-of-Failure mehr im Ceph-Cluster. Ferner braucht Ceph keine Metadaten, um die gesicherten Objekte im Cluster wiederzufinden, wie das bei anderen verteilten Speichersystemen der Fall ist. Wie die Daten verteilt werden, bestimmt die sogenannte "Crush"-Map (controlled replication under scalable hashing). Diese berechnet aus Objekteigenschaften wie dem Namen einen Hash, der dann passend zum aktuellen Regelwerk die Verteilung bestimmt, dazu später mehr.

Für den Grundbetrieb benötigt Ceph erst einmal zwei verschiedene Knotentypen: Einen Monitor "Mon" und einen Object-Storage-Daemon "Osd". Ein Monitor speichert keine Daten. Er überwacht den Cluster und hält die aktuelle Crush-Map bereit. Clients authentisieren sich am Monitor und bekommen im Gegenzug die Map ausgehändigt. Bei Ausfällen oder Änderungen an OSDs stößt der Monitor die Rebuild-Prozesse mit den verbleibenden OSDs an.

In produktiven Speicherumgebungen gibt es immer eine ungerade Zahl bei mindestens drei Monitoren, um Ausfälle und Split-Brain-Situationen zu vermeiden. Pro Festplatte oder SSD betreibt Ceph einen eigenen OSD. Ein Server mit sechs Festplatten stellt entsprechend sechs OSDs zur Verfügung. RAID-Controller braucht es bei Ceph nicht, denn die Redundanz der Daten gewährt das SDS selbst. Im Gegenteil: Wer Speichersysteme mit RAID-Controllern als OSD-Knoten verwenden möchte, muss expilzit die HW-RAID-Funktionen abschalten und dem Betriebssystem alle Platten einzeln zur Verfügung stellen.

Ältere Versionen von Ceph (vor 2018) formatierten die Datenträger mit dem XFS-Dateisystem und plazierten die Objekte in Unterverzeichnissen. Doch ein vollständiges Dateisystem wie XFS bringt zu viel unnötigen Ballast mit sich. Daher setzt Ceph seit Version 12 auf Bluestor. Anstelle eines komplexen Dateisystems mit Attributen, Rechten, Verzeichnissen und Journalen schreibt Bluestor eine Key/Value-Datenbank namens "RocksDB" direkt auf den Datenträger und legt die Objekte dort ab. Das funktioniert in etwa doppelt so schnell wie OSDs unter einem XFS-Dateisystem. Auf Wunsch arbeitet Bluestor auch mit Datenkompression.

Ältere Ceph-Implementierungen forderten dezidierte Mon-Knoten getrennt von OSD-Knoten. Zudem mussten Administratoren die verschiedenen Dienste händisch auf den Zielsystemen installieren und mit dem Cluster verbinden. Um die Installation und Konfiguration zu vereinfachen, setzt Ceph in der Zwischenzeit gänzlich auf Container. Das physische OS der angebundenen Knoten braucht jetzt nur noch eine Docker- oder Podman-Runtime und jegliche Ceph-Dienste laufen darauf containerisiert.

Fügen Sie beispielsweise einen Storage-Knoten mit sechs Platten für OSDs in einen Cluster ein, erkennt Ceph die freien Disks und startet entsprechend sechs OSD-Container. Der Zugriff zu den OSDs erfolgt dann über gemappte Ports auf der IP-Adresse des Host-Systems. Daher laufen die meisten Ceph-Cluster heute auch mit hybriden Knoten, die Mon und OSD-Dienste parallel in Containern betreiben.

Sobald ein Ceph-Cluster über mindestens einen Monitor und drei oder mehr OSDs verfügt, kann er den Betrieb aufnehmen. Im ersten Schritt generiert Ceph eine Reihe sogenannter "Placement Groups" (PG). Das sind logische Speicherblöcke, auf die Crush die Objekte verteilt. Die PGs wiederum sichert Ceph dann auf die OSDs. Ändert sich die Zahl der OSDs, verschiebt Ceph die PGs je nach Bedarf zwischen den ODSs hin und her. Anders als bei anderen verteilten Speichersystemen muss der Administrator bei Ceph keinen Rebuild manuell anstoßen, falls es zu Änderungen oder Ausfällen bei OSDs kommt.

Ceph überwacht alle Knoten und OSDs permanent und leitet Rebuilds immer autmatisch ein. Erweitert der Administrator seinen Ceph-Speicher, braucht er auch eine größere Anzahl von PGs. Das übernimmt der Autoscaler von Ceph, sodass hier auch kein manuelles Eingreifen nötig wird. Auf den PGs wiederum arbeiten die Speicherpools von Ceph. Diese legen die "Replication Poly" fest. Üblich sind dabei "Size 2", "Size 3" oder "Erasure Coding". Bei Size 2 erstellt Ceph von jedem Datenblock zwei, bei Size 3 entsprechend drei Kopien. Die Crush-Map sorgt dafür, dass die Kopien nicht nur auf verschiedenen OSDs, sondern auch auf unterschiedlichen Hosts lagern.

Das "Erasure Coding" (EC) fungiert derweil als blockbasiertes RAID. Hierbei gibt der Anwender eine passende EC-Regel an, wie beispielsweise "k=5 m=2". Dabei verteilt Ceph die Daten auf fünf Teile mit zwei Parity-Blöcken. EC-Pools verbrauchen weniger Platz, arbeiten aber deutlich langsamer. Ein Size-3-Pool greift pro Schreibzugriff auf drei, pro Lesezugriff aber nur auf einen OSD zu. Bei einem EC-Pool nach dem beschriebenen Schema entstehen hingegen sieben OSD-Zugriffe beim Schreiben und fünf beim Lesen. Daher schränkt Ceph die Funktionen für EC-Pools deutlich ein. Sie dürfen beispielsweise nicht für RBD-Pools (RADOS Block Device) oder Ceph-FS genutzt werden. Der Administrator kann mehrere Pools mittels Tiering zusammenlegen. So lässt sich beispielsweise ein Cache-Pool mit SSDs vor einen Pool aus regulären Festplatten schalten, um die Zugriffe zu beschleunigen.

Mit der Grundausstattung von Mons und OSDs stellt Ceph seine Speicherdienste über zwei mögliche Protokolle bereit: RADOS und das erwähnte RBD. Prinzipiell offeriert RADOS den schnellsten und besten Zugang zu Ceph. Allerdings muss der Anwendungsentwickler die RADOS-Funktionen direkt in seinen Code einbinden. Das RBD funktioniert im Grunde genommen wie ein SAN-Storage mit Fibre-Channel oder iSCSI.

So legt der Administrator auf dem Ceph-Storage RBD-Volumes mit einer definierten Größe an. Clients erhalten via "rbd map" Zugang zu den Volumes und behandeln diese via "/dev/rbdX" wie reguläre Laufwerke mit einem Dateisystem. Der RBD-Client läuft auf allen Linux-Versionen. In der Zwischenzeit gibt es aber auch einen RBD-Dienst für Windows ab Server 2016. Das RBD kommt häufig in Verbindung mit Virtual Machine Hosts zum Einsatz und dank des Windows-Treibers funktioniert das neben KVM auch mit Hyper-V.

Neben Block- und Objektdiensten stellt Ceph mit CephFS auch ein Netzwerkdateisystem bereit. Das braucht dann aber weitere Dienste auf dem Ceph-Cluster in Form von Metadata-Servern. Diese stellen dem Client die "Umrechnung" von Dateien und Verzeichnissen zu Ceph-Objekten im Cluster bereit, sodass die CephFS-Clients ebenfalls direkt auf die verteilten Datenblöcke zugreifen können, anstatt den Umweg durch ein Dateisystem-Gateway nehmen zu müssen. Linux-Nutzer haben die Wahl zwischen einem Kernel- und einem Fuse-CephFS-Client (File System in Userspace). Der Kernel-Treiber arbeitet etwas schneller, muss aber die selbe Versionsnummer wie der Ceph-Storage-Cluster einsetzen. Der Fuse-Client hingegen toleriert Versionsdifferenzen.

Für Windows-Nuzter gibt es mit "Dokany" eine Fuse-Implementierung für Windows, die dabei auch CephFS unterstützt. Wer primär ein Netzwerk-Dateisystem benötigt, ist wahrscheinlich mit einem nativen Scale-Out-Filesystem wie GlusterFS besser beraten, da sich dieses einfacher installieren und warten lässt. Wer jedoch einen zentralen Multiprotokoll-Speicher nutzen möchte, der neben Block- und Objektdiensten auf den gleichen Knoten auch ein Dateisystem beherrscht, kann auf CephFS setzen.

Ceph Storage arbeitet mit seinen nativen Protokollen schnell und effizient. Doch leider können das in der Regel nur Linux-Systeme mit ihren integrierten Ceph-Clients nutzen. Für die Windows-Clients gibt es zwar Open-Source-Agenten für RBD und CephFS, aber keinen offiziellen Support dafür. Auch programmieren nur wenige Unternehmen ihre Software selbst, sodass sie das RADOS-Protokoll nativ nutzen könnten. Hier hilft nur der Umweg über Gateways.

Der Weg über Gateways hat den großen Nachteil, dass die Clients nicht direkt auf die verteilten Speicherknoten zugreifen. Das bringt einen potenziellen Flaschenhals ins Spiel. Doch auch hier kann Ceph die Gateway-Dienste im Cluster verteilen und parallel auf mehreren Knoten betreiben. Wer Ceph als Multiprotokoll-Storage verwendet, lässt die verschiedenen Gateways dann einfach auf getrennten Hosts laufen und verteilt damit zumindest den Frontend Traffic statisch.

Das RADOS-Gateway ermöglicht den Zugriff zu Ceph-Objekten via S3-Protokoll. In der Praxis verteilt der Administrator mehrere Gateways im Cluster hinter einen leistungsstarken HTTPS-Loadbalancer. Das iSCSI-Gateway nutzt das LIO-Target (siehe auch [1]) .

Anstelle eines Block- oder File-IO-Backends greift das iSCSI-Target dabei jedoch auf die konfigurierten RBDs zurück. Auch hier lässt der Administrator mehrere iSCSI-Gateways auf seinen Ceph-Knoten laufen. Einen Load­balancer braucht es hier nicht, da das iSCSI-Protokoll selbst das Multipathing übernimmt.

Zu guter Letzt gibt es natürlich für das CephFS-Dateisystem ein NFS-Frontend, das die Ceph-Installation direkt mitliefert. Auch ein SMB/CIFS-Gateway funktioniert. Die nötigen Tools liefert der Ceph-Client jedoch nicht mit aus. Hier muss der Administrator selbst einen Samba-Knoten oder -Cluster konfigurieren, der seine Shares einfach auf einem gemounteten CephFS-Volume anlegt. Wer Ceph-Speicher in einer Kubernetes-Umgebung verwenden möchte, nutzt dazu den "Rook"-Operator. Der generiert nicht nur eine Kubernetes-Storage-Klasse, sondern kann auch die freien Disks der angebundenen Kubernetes-Knoten in einem Ceph-Cluster organisieren. Zusammen mit Rook ist hier dann auch "NooBaa" als Multiprotokoll-Gateway auf Kubernetes die Alternative zum RADOS-Gateway. Aus Platzgründen können wir Rook und NooBaa jedoch nicht an dieser Stelle ausführlich beschreiben.

Ceph ist ein leistungsstarker aber auch komplexer Storage. Nach einer Einführung in den Grundbetrieb von Ceph, das Clustering sowie CephFS beleuchten wir im zweiten Teil unserer Workshopserie die Ceph-Installation und die Sicherung über Snapshots.