Krakenturbo

von Martin Loschwitz

Ceph und sein Objektspeicher RADOS gelten als vielseitig und unverwüstlich. Entsprechend beliebt ist die verteilte Speicherplattform in Unternehmen. Nur in Sachen Performance finden Admins regelmäßig Grund zur Kritik – denn manche Elemente lassen sich sinnvoll tunen, andere nur schwerlich oder gar nicht. Welche Erwartungshaltung realistisch ist, wie sich Leistung sinnvoll erfassen lässt und was bei speziell Ceph zu bedenken ist, verrät dieser Artikel.

Für das Rechenzentrum der Gegenwart ist moderner, gut skalierbarer Speicher eine Notwendigkeit. Seit skalierbare Plattformen wie OpenStack oder Kubernetes den Ton angeben, müssen Administratoren sich regelmäßig mit der Frage befassen, wie sie ihren Storage so gestalten, dass er in Sachen Wachstum mit dem Thema Compute mithält.

Klassische NAS- oder SAN-Appliances sind in dieser Hinsicht eher schwierig: Sind sie voll, ist mehr Speicher nur durch die Anschaffung einer weiteren Appliance möglich. Die aber ist kostspielig und schafft zudem einen zusätzlichen "Point of Administration". Des Systemverwalters Alltag wird dadurch nicht einfacher.

Anders sieht das bei Ceph aus: Hier lautet ein explizites Versprechen des Herstellers, dass sich die Plattform nahezu beliebig in die Breite skalieren lässt. Erst bei mehreren Hundert Millionen Speicherlaufwerken ist laut offizieller Dokumentation Schluss – und wer die verwalten muss, hat ohnehin andere Probleme.

Robust, aber langsam

Neben seiner hohen Skalierbarkeit sprechen andere handfeste Argumente für Ceph und seinen Kern, den Objektspeicher RADOS. Die Technologie steht unter einer freien Lizenz und ist vollständig quelloffen. Ceph hat sich zudem den Ruf erarbeitet, praktisch unverwüstlich zu sein. Selbst das Anhalten eines OSDs per SIGSTOP, also eines Daemons, der ein Laufwerk für die Benutzung in Ceph freigibt, das Löschen seiner Daten und das Fortsetzen des Prozesses mit SIGCONT führen nicht zu Datenkorruption im Cluster. Lediglich eine Warnmeldung setzt das betroffene OSD stattdessen ab, bevor es sich selbst abschaltet, um die Datenintegrität des Clusters nicht zu gefährden. Das ist eine Art von Robustheit, die sich viele andere Speicher nicht auf die Fahnen schreiben dürfen.

Aber auch bei Ceph ist nicht alles Gold was glänzt. Seit jeher gibt es Beschwerden bezüglich seiner Performance. Bandbreite ist bei Ceph naturgemäß kein Problem: Je mehr Laufwerke im Cluster vorhanden sind, desto größer ist die insgesamt vorhandene Bandbreite. Schwieriger wird die Sache im Hinblick auf Latenz: Zwar lässt sich über mehr Speicherlaufwerke die Anzahl der IOPS erhöhen, die der Cluster insgesamt parallel abarbeiten kann. Über die Ausführdauer einer einzelnen Schreiboperation sagt das aber noch nichts aus. Typische Workloads nutzen aber eben genau dieses Pattern, beispielsweise Datenbanken wie MySQL. Wer sich in ein Ceph-Projekt für solche Workloads stürzt und nicht gut genug evaluiert und testet, schießt sich schlimmstenfalls selbst in den Fuß.

Die gute Nachricht ist: Praktisch alle Performanceschräubchen von Ceph lassen sich tunen, wenn auch in unterschiedlichem Umfang. Im Folgenden erläutern wir anhand einer eher kleinen Ceph-Installation am praktischen Beispiel, worauf in Sachen Leistung zu achten ist und mit welchen Herausforderungen Admins zu rechnen haben.

Leistungsdaten erfassen

Bevor es ins Bällebad der praktischen Tipps geht, sei das Hauptaugenmerk noch kurz auf das Thema Benchmarks gesetzt. Landauf und landab verzweifeln regelmäßig Administratoren, weil sie sich in ihren RADOS-Clustern die Finger wund messen, ohne zu verwertbaren Resultaten zu kommen. Wollen Sie einen Ceph-Cluster aber zielgerichtet tunen, geht das nur mit peniblem Nachmessen an den richtigen Stellen.

Am Anfang des Ceph-Tunings sollte deshalb stets das Erfassen der verfügbaren Performance stehen. Dabei sind im Grunde zwei Werte völlig ausreichend, um zumindest einen groben Eindruck von der Leistungsfähigkeit des Ceph-Clusters zu bekommen: Ein Bandbreitentest, der große Datensätze mit hoher Parallelität in den Cluster schreibt. Und ein Latenztest, der 4K-Operationen durchführt und erhebt, wie viele Operationen der Cluster davon parallel in welcher maximalen Zeit handzuhaben in der Lage ist.

Die beiden Datenerhebungen sind in Ceph sogar mittels Bordmitteln relativ leicht zu bewerkstelligen: Zunächst legt der Befehl ceph osd pool create benchmark einen Ceph-Pool namens "benchmark" an. Dann misst das Kommando

30 Sekunden lang sequenzielle Schreibvorgänge in einen RADOS-Cluster bei einer Blockgröße von 4 KByte und einer "Queue Depth" (QD), sprich einer Parallelität der Schreibvorgänge von 1 – also keiner Parallelität.

Im Hinblick auf Latenz sind kleine Writes in hoher Anzahl derjenige Einsatzzweck, der üblicherweise die größte Herausforderung darstellt. Realistische Werte ob der insgesamt verfügbaren Bandbreite des Clusters erhalten Sie auf diese Weise aber nicht. Hier hilft ein anderer Befehl weiter:

Dieser führt ebenfalls sequenzielle Writes aus, nutzt aber die Standardeinstellungen. Die Blockgröße liegt dann bei 4 MByte und die Queue Depth bei 16.

Wer ausreizen möchte, wieviel Bandbreite der Cluster liefert, hängt noch den Parameter "-t 32" oder "-t 64" an und erhöht dadurch die Parallelität. Nota bene: Die beiden Tests prüfen die Performance des Clusters auf der Ebene des Objektspeichers selbst. Wer wissen will, wie gut eines der RADOS-Frontends performt, also RBD, CephFS oder das RADOS-Gateway, der braucht separate Tests für die jeweilige Schnittstelle.

Die Frontends zu tunen ergibt in Ceph allerdings nur Sinn, wenn Sie sicher sind, auf der Ebene des Objektspeichers das Maximum herausgeholt zu haben. Dabei gilt: 4K-Schreibvorgänge mit einzelnem Thread in einer herkömmlichen Ethernet-Umgebung sind mit 1500 IOPS schon gut unterwegs. In Sachen Bandbreite lässt sich kein guter Standardwert angeben, eben weil diese stets mit der Anzahl der Laufwerke korreliert. Mehrere GByte pro Sekunde sollte ein Cluster aus drei Knoten mit jeweils 16 NVMe-Laufwerken allerdings beim sequenziellen Schreiben erreichen. Hier ist vermutlich eher das Netzwerk der Flaschenhals.

Erste Messungen vornehmen

Liegen Sie bei Ihren Messungen insbesondere im Hinblick auf Latenz deutlich unter den genannten Werten, beginnt eine oft mühsame Fehlersuche. Zunächst schließen Sie idealerweise die klassischen Gründe für schlechte Performance aus. Stretched Cluster etwa, also Installationen, die sich über mehrere Standorte erstrecken, haben meist signifikant geringere IOPS-Werte für 4K-Blöcke mit einem Thread. Denn hier müssen die Daten längere Distanzen überwinden, bis mindestens zwei der in RADOS ab Werk vorgegebenen drei Kopien der Daten im Cluster angelegt sind. Stretched Cluster sind praktisch nicht zu tunen. Gemäß Hersteller Red Hat sind sie auch kein valider Ansatz und sollten tunlichst nicht zur Anwendung kommen.

Haben Sie einen Stretched Cluster als Fehlerquelle ausgeschlossen, gestaltet sich das Debuggen und Messen schnell deutlich kleinteiliger. Hier hilft es, sich RADOS als einen Stack aus verschiedenen Komponenten mit Storage-Bezug vorzustellen, durch den Daten von oben nach unten wandern. Was an der Basis an Leistung nicht vorhanden ist, lässt sich weiter oben durch Nutzer nicht verwenden.

Glücklicherweise liefert Ceph hier mehrere hilfreiche Werkzeuge mit. So misst das Kommando

die Performance des Laufwerks hinter dem Object Storage Daemon (OSD) 0 in Ceph unter Verwendung von 4K-Blöcken. Ersetzen Sie "osd.0" im Kommando durch "osd.*", führt RADOS den Benchmark pro Laufwerk aus. Das ist problemlos im aktiven Betrieb möglich und bedingt keine Downtime. Das Kommando ceph tell osd.* bench ohne weitere Parameter schwenkt auf Blöcke mit 4 MByte Größe um.

Heraus kommt in beiden Fällen pro OSD eine Übersicht über den durchgeführten Schreibvorgang und die sich daraus ergebenden Leistungswerte. Insbesondere die angegebene IOPS-Nummer ist dabei ausschließlich im Kontext der übergebenen Parameter zu betrachten. Dass ein Cluster gut darin ist, besonders viele große parallele Schreiboperationen durchzuführen, heißt nicht automatisch, dass er auch eine gute Latenz in der Installation hat.

Unplausible Ergebnisse deuten

Insbesondere beim direkten Vergleich der Benchmarks einzelner OSDs und der Benchmarks von Writes in RADOS neigen Administratoren schnell dazu, die gelieferten Werte für unplausibel zu halten. Kein Wunder: Eine flotte NVMe steckt oft 200.000 und mehr 4K-IOPS pro Sekunde weg. Steht in der Ausgabe von "rados bench" mit einer Queue Depth von 1 und mit 4K-Blöcken hingegen ein Wert um die 1500, ist die Differenz so eklatant groß, dass viele Admins schnell glauben, einen Fehler gemacht zu haben.

Es ist an dieser Stelle aber unabdingbar, sich in Erinnerung zu rufen, dass Ceph so viel Parallelisierung wie möglich anstrebt. Ein Cluster, der in der Lage ist, viele Schreibvorgänge von 4K-Blöcken parallel abzuhandeln, kommt entweder mit sehr geringer impliziter Latenz daher oder hat sehr viele Laufwerke, auf die sich die Last verteilt. Der IOPS-Wert per se sagt also nicht viel aus, wenn Sie ihn losgelöst von den umgebenden Faktoren betrachten.

Erschwerend kommt bei Ceph hinzu, dass die Plattform notorisch verschrien dafür ist, in Sachen Latenz eher aus dem Vollen zu schöpfen. Das liegt an der Architektur unter der Haube: Hier werkelt der pseudo-zufällige Hash-Algorithmus CRUSH (Controlled Replication Under Scalable Hashing), der für die Verteilung von Objekten auf OSDs zuständig ist. CRUSH gilt im Vergleich mit anderen Algorithmen ähnlicher Machart als träge.

Obendrein nutzt Ceph Ethernet. Das ist insbesondere für jene Admins von Bedeutung, die bisher eher die Arbeit mit FibreChannel gewohnt sind und nun erstmals auf Ethernet zu tun haben: Der Netzwerkstandard hat eine viel höhere Latenz als FibreChannel. Und regelmäßig liefern sich CRUSH und Ethernet einen Wettkampf darum, wer zum Flaschenhals im RADOS-Cluster wird – die Physik lässt sich schließlich nicht austricksen.

Lokale Laufwerke im Fokus

Innerhalb der Ceph-Community haben sich fünf Maßnahmen herauskristallisiert, um sowohl in Sachen Bandbreite als auch hinsichtlich Latenz spürbare Verbesserungen herbeizuführen. Zunächst stehen dabei die lokalen Speicherlaufwerke im Fokus. Hier hängt schon viel davon ab, um welche Art Gerät es sich handelt: NVMe-Laufwerke funktionieren mit Ceph natürlich bestens und liefern üblicherweise deutlich mehr Leistung, als die verbaute Netzwerkhardware in den Systemen verarbeiten kann. Anders sieht die Sache beispielsweise bei SAS-Festplatten aus. Die sind bei kleinen Writes so langsam, dass sie das verfügbare Netz im Normalfall nicht saturieren können. Identifizieren Sie Hardware als die Ursache der Performancekrise im eigenen Setup, hilft alles Tuning auf der Softwareseite nicht: Dann muss – siehe Kasten – neue Hardware her, um spürbare Verbesserungen zu erreichen.

Meist ist das aber nicht der Fall. Gerade bei heute neu entstehenden Ceph-Clustern sind NVMes der Goldstandard und kommen entsprechend häufig auch zum Einsatz. Die Ethernet-Latenz lässt sich indes aus den beschriebenen Gründen kaum verbessern. Hier kann es helfen, die Dokumentation der Komponenten des Netzwerks zu studieren. Gelegentlich beschreiben Hersteller in ihren Unterlagen, wie die Konfiguration aussehen soll, wenn sie auf geringe Latenzen hin getrimmt ist.

Auch auf der Konfigurationsebene lassen sich bei passender Hardware einige Verbesserungen umsetzen, um mehr Performance aus der Installation zu kitzeln. Äußerst positiv sowohl auf Latenz als auch auf Bandbreite wirkt sich beispielsweise die Verwendung von Jumbo Frames aus, also die Konfiguration einer Netzwerk-MTU von 9000. Das sorgt dafür, dass die betroffenen Kernel der Linux-Server den Netzwerk-Traffic weniger stark fragmentieren müssen und dass es auch die Switches mit deutlich weniger Paketen zu tun haben als bei geringerer MTU. Ein Wort der Warnung darf an dieser Stelle aber nicht fehlen: Damit eine MTU-Größe von 9000 sinnvoll nutzbar ist, müssen sie alle beteiligten Netzwerkgeräte anbieten. Ansonsten kommt es schlimmstenfalls zu Instabilitäten.

Flash-Caching: Ja, aber...

Die zweite goldene Regel im Hinblick auf Ceph-Tuning betrifft die lokalen Caches der genutzten Speicherlaufwerke. Einige NVMe- oder SSD-Geräte haben diese zwar nicht mehr, bei Festplattenspeichern aber sind sie gang und gäbe. Hier kommt flotter Flash-Speicher zum Einsatz, um Daten zunächst zwischenzulagern, bevor sie dann auf die langsam rotierenden Scheiben wandern. Je nach Modell und Preisklasse sind aber auch Flash-basierte Laufwerke mit nochmal schnellerem Flash für das Zwischenlagern ausgestattet.

Die Krux: Diese Caches können die Performance eines einzelnen Laufwerks sehr positiv oder sehr negativ beeinflussen. Aus Administratorensicht ist im Vorfeld leider nicht sinnvoll vorherzusagen, welches der Szenarien zutrifft. Denn das hängt zum Teil von den genutzten Geräten und von der vor Ort zu findenden Kombination aus Geräten im jeweiligen Server ab. Noch vor einigen Jahren lautete die goldene Regel für Festplatten, den lokalen Cache des Gerätes zu deaktivieren und das Caching Ceph zu überlassen.

Für Festplatten ist das auch weiterhin zutreffend, zumal die Caches in Festplatten nicht batterie- oder puffergestützt sind und zur Gefahr für die Integrität der Daten bei einem Stromausfall werden können. Für Flash-basierte Laufwerke ist ohne Ausprobieren aber keine zuverlässige Aussage zu treffen. Admins tun insofern gut daran, etwa mittels hdparm -W0 /dev/sdd den Cache im Laufwerk testweise zu deaktivieren und anschließend mittels ceph tell osd.X bench zu prüfen, ob sich Durchsatz und Latenz verbessern. Stellt sich heraus, dass ein Speicherlaufwerk bei deaktiviertem lokalen Cache deutlich besser funktioniert, dann sollten Sie das auch so konfigurieren. Übrigens: Mittels ceph daemon osd.X perf dump lassen sich pro Daemon auch die aktuell vom OSD selbst gemessenen Performancewerte anzeigen.

Bloß kein Energiemanagement

Moderne Prozessoren sind darauf ausgelegt, Energie zu sparen. Im Falle von Ceph kann das allerdings zum Problem werden. Denn CRUSH-Kalkulationen brauchen Rechenleistung. Steckt ein Prozessor oder auch nur ein Kern im Stromsparmodus und muss erst aufgeweckt werden, wenn Ceph eine Berechnung benötigt, verstreichen wertvolle Millisekunden, bis die volle Leistung für CRUSH zur Verfügung steht.

Es hat sich deshalb als gängige Praxis etabliert, in Ceph-Clustern die Stromsparmodi der CPU ("Powersave Modes") komplett zu deaktivieren. Wer auf Nummer sicher gehen will, tut das per BIOS oder UEFI-Firmware. Hier lassen sich die Stromsparmodi im Normalfall vollständig abschalten. Wer eine Lösung auf Softwareebene bevorzugt, konfiguriert auf einem modernen Linux-System dazu den "CPU-Governor". Dieser sollte auf "performance" stehen. Leider unterscheidet sich die Einrichtung der Werkzeuge zum Konfigurieren des CPU-Governors zwischen den einzelnen Distributionen stark. Es ist deshalb hier nicht möglich, eine sinnvolle, generelle Anleitung zu liefern. Schon zwischen Ubuntu 24.04 und Ubuntu 22.04 etwa kommen andere Werkzeuge zum Einsatz.

Es sei an dieser Stelle deshalb die Empfehlung ausgesprochen, die Dokumentation der eigenen Linux-Distribution zu konsultieren, um herauszufinden, wie der CPU-Governor zu konfigurieren ist. Ergänzend sei weiterhin darauf hingewiesen, dass auch bei aktiviertem Governor-Modus die CPU nur Leistung liefern kann, die sie hat. Wer Ceph-Knoten anschafft, greift idealerweise nicht zu den kleinen EPYC- oder den Silver-Xeon-CPUs, sondern nimmt etwas leistungsfähigere Hardware.

Den I/O-Scheduler einhegen

Linux kommt ab Werk mit mehreren I/O-Schedulern. Deren Aufgabe besteht darin, Anfragen an Laufwerke (I/O Requests) so zu ordnen, dass sie möglichst flott vom jeweiligen Gerät abzuarbeiten sind. Auch Ceph hat im OSD-Daemon aber ein Scheduling für Schreibanfragen. Je nach Umgebung kommen sich der Mechanismus des Linux-Kernels und jener von Ceph in die Quere.

Die grundsätzliche Empfehlung lautet deshalb: Für OSDs, die Flash-Laufwerke sind, sollte der I/O-Scheduler in Linux grundsätzlich auf "none" stehen. Dann leitet der Kernel die I/O-Anfragen so an das Laufwerk weiter, wie er sie vom OSD empfängt. Für Festplatten empfiehlt sich hingegen der Scheduler "mq-deadline". Welcher Scheduler für ein Gerät eingestellt ist, erfahren Sie auf der Kommandozeile, mittels

hier exemplarisch für das Laufwerk "/dev/sda". Um den Scheduler umzustellen, greifen Sie auf das Kommando

für dasselbe Gerät zurück.

Sysctl-Tuning

Der letzte Tipp für das Tuning eines RADOS-Clusters bezieht sich auf die Netzwerkeinstellungen der Kernel der Systeme mit Ceph-Diensten. Hier lassen sich etwa die Puffer für Sende- und Empfangskanäle von Verbindungen ebenso optimieren wie die Latenz durch das Ausschalten einiger TCP/IP-Standards.

Linux hat viele Verifikations- und Absicherungsmechanismen an Bord, die die Stabilität des Setups garantieren sollen, im Ceph-Kontext allerdings wenig Sinn ergeben. Deren Steuerung geschieht über System-Kontrollvariablen. Das Listing im Kasten enthält die wichtigsten Parameter, die auf Ceph-Systemen gesetzt sein sollten.

Die Werte sind in einer Datei in "/etc/ sysctl.d" zu hinterlegen und anschließend mittels sysctl -a entsprechend anzuwenden. Im Gespann mit Jumbo-Frames führt das im Regelfall zu einer deutlich bemerkbaren Verbesserung, sowohl im Hinblick auf Latenz als auch bezüglich des Datendurchsatzes.

Fazit

Setzen Sie die beschriebenen Tuningmaßnahmen auf handelsüblichen Servern für Ceph um, sollte das im Normalfall zu einer spürbare Verbesserung der Bandbreite als auch der Latenz führen. Trotzdem ist aber immer auch Erwartungsmanagement in Richtung der eigenen Anwender und des eigenen Managements ein wichtiges Thema: Denn selbst mit dem besten Tuning wird aus Ceph im Hinblick auf Single-Thread-4k-Schreibvorgänge kein Rennpferd. Im Regelfall ist dann Ethernet die gläserne Decke, die zu durchstoßen unmöglich ist.

Ein gut eingestellter Ceph-Cluster unter Verwendung von Netzwerkgeräten mit Spectrum-1-ASIC, von NVIDIA beispielsweise, liefert unter Idealbedingungen knappe 2000 IOPS für einen einzelnen Thread bei 4K-Blockgröße. Wer von FibreChannel kommt und es gewohnt ist, mittels dessen Speicher Datenbanken zu betreiben, die 3500 IOPS und mehr liefern, findet das vermutlich zu langsam.

Im Einzelfall hilft es, die tatsächlichen Anforderungen mit dem technisch möglichen zu vergleichen. Auch wenn RADOS dabei schlechter wegkommt als die Bestandsplattform, kann die Leistung noch immer ausreichend sein. Wer hingegen weiß, dass die eigene Anwendung extrem hohe 4k-IOPS-Werte braucht, kann auch mit dieser Information etwas Sinnvolles anfangen: Dann ist nämlich klar, dass zumindest für einen Teil des Setups Ceph nicht die beste Wahl ist.

Performance-Tuning für Ceph