© olegdudko, 123RF

Ceph ist mächtig und leistungsfähig, doch falsche Einstellungen oder defekte Hardware bringen den dezentralen Objektspeicher im schlimmsten Falle aus dem Tritt. Das Linux-Magazin verrät, welche Alarmzeichen es gibt.

Ceph hat sich in den vergangenen Jahren zum De-facto-Standard in Sachen Software Defined Storage (SDS) entwickelt, und mittlerweile geht die Lösung auch allgemein als Standard-Storage durch (Abbildung 1).

Baut ein Unternehmen heute eine große skalierbare Umgebung, landet es immer seltener bei klassischen NAS- oder SAN-Appliances; der verteilte Objektspeicher, der mittlerweile zu Red Hat gehört, kommt stattdessen immer häufiger zum Zug. Kein Wunder: Ceph lässt sich mit Hardware von der Stange problemlos nutzen und bietet durch diese Eigenschaft eine langfristige Perspektive. Unternehmen müssen also nicht nach ein paar Jahren damit rechnen, Ersatzteile nur noch für den Gegenwert von purem Gold direkt beim Hersteller beziehen zu können.

Abbildung 1: Ceph hat sich zum Standard in Sachen RZ-Storage gemausert und verbreitet sich weiterhin rasant. Quelle: Wikimedia

Obendrein ist Ceph anders als klassische Speicherlösungen ab Werk auf Skalierbarkeit und Langlebigkeit ausgelegt: Einen Ceph-Speicher muss man zum Beispiel nicht fünf Jahre nach Betriebsbeginn vollständig durch eine neue Lösung ersetzen, weil die Garantie der Hardware sich dem Ende zuneigt. Stattdessen entfernt der Admin, und zwar ohne Auswirkungen auf den laufenden Betrieb, die betroffenen Server aus dem System und fügt neue hinzu – fertig.

Die Kehrseite der Medaille: Die zentrale Rolle, die Ceph in Setups einnimmt, macht Performance-Probleme besonders kritisch. Dabei ist Ceph ausgesprochen komplex: Läuft der Objektspeicher langsam, gibt es eine Vielzahl involvierter Komponenten, von denen im besten Fall eine allein für die schlechte Performance verantwortlich ist. Hat der Admin weniger Glück, entsteht das Performance-Problem aus dem Zusammenspiel mehrerer Komponenten des Clusters, was sich entsprechend schwierig debuggen lässt.

Dieser Artikel enthält nach einer kurzen Auffrischung des Basiswissens rund um Ceph nützliche Tipps aus dem Rechenzentrumsalltag für die Überwachung von Ceph, gerade im Hinblick auf seine Performance. Neben präventiven Themen geht es auch um die Frage, wie der Admin hartnäckigen Problemen in Sachen Ceph-Performance mit Bordmitteln zu Leibe rückt.

Wie Ceph funktioniert

Manchem Admin mag das Problem bekannt vorkommen: Über Wochen und Monate hinweg hat man entlang aller aktuellen Best Practices einen neuen Ceph-Cluster konzipiert und implementiert. Auch bei der Hardware hat man sich nicht lumpen lassen: Ein flottes Netz mit 25 Gbit/s über redundante LACP-Links gilt fast schon als Standard – vielleicht auch angesichts der Tatsache, dass die ersten verfügbaren 400-Gbit/s-Switches in den Prospekten der Hersteller auftauchen. Auch sonst hat der Admin in Sachen Netzwerk nicht gekleckert: Für den Traffic zwischen den Laufwerken in Ceph existiert sogar ein dediziertes Netz mit eigener Ethernet-Hardware, sodass der Client-Datenverkehr und der Traffic für Cephs interne Replikation sich nicht gegenseitig ausbremsen.

Zwar sind im Ceph-Cluster langsame Festplatten verbaut, doch hat der Admin sich penibel an die Empfehlungen der Entwickler gehalten und diesen langsamen Laufwerken eine Art Cache auf SSD-Basis zur Verfügung gestellt. Sobald die Daten auf diesen Caches landen, gilt ein Write für den Client als abgeschlossen. Für ihn wirkt es dadurch so, als würde er in einen reinen SSD-Cluster schreiben.

Doch dann der Schreck: Eingangs lieferte der Cluster die gewünschte Performance, doch plötzlich kriechen Pakete auf dem Weg zu ihm nur noch so dahin. Die Zeit, die Ceph sich beim Arbeiten lässt, scheint im Gegensatz zur Geduld der Admins unendlich, und niemand weiß so recht, wo das Problem liegen könnte. Hier stellen sich zwei Fragen: Wie findet der Admin die Wurzel des Übels heraus? Und wie überwacht er seinen Cluster im Idealfall permanent so, dass er potenzielle Probleme identifiziert, noch bevor die Nutzer des Clusters sie überhaupt bemerken? Die Antwort auf beide Fragen bedingt ein grundlegendes Verständnis der Funktionsweise von Ceph.

RADOS und Backends

Zur Erinnerung: Unter der Produktbezeichnung Ceph vermarktet Red Hat eine Sammlung verschiedener Werkzeuge, die erst im Zusammenspiel eine komplexe Storage-Lösung ergeben. Im Kern steckt bei Ceph der verteilte Objektspeicher RADOS. Als Objektspeicher bezeichnet man RADOS, weil es jede eingehende Information grundsätzlich als binäre Datei behandelt.

Solche Dateien lassen sich an beliebigen Stellen zerteilen und später auch wieder zusammensetzen, wenn beide Vorgänge in der jeweils richtigen Reihenfolge passieren. Dadurch erreicht Ceph seine Kerneigenschaft als verteilter Speicher: Lädt der Benutzer eine Datei in RADOS hoch, zerlegt der Client diese vor dem Upload in etliche, 4 MByte große Objekte, die RADOS anschließend über alle seine Festplatten verteilt.

Logisch gliedert Ceph sich in RADOS einerseits und dessen Front-Ends andererseits (Abbildung 2). Clients steht ein Füllhorn von Optionen zur Verfügung, um Daten in einen Ceph-Cluster zu bekommen. Sie alle funktionieren aber nur, wenn der Objektspeicher RADOS funktioniert, und das hängt von mehreren Faktoren ab.

Abbildung 2: Clients greifen auf den Ceph-internen Objektspeicher RADOS wahlweise als Blockgerät, als Objekt oder als Dateisystem zu. Quelle: Inktank

Von OSDs und MONs

Zwei Komponenten sind für die absolute Basis-Funktionalität von RADOS notwendig. Einerseits gehören zur Lösung die Object Storage Daemons (OSDs). Sie dienen in einer Ceph-Installation als Datensilos. Klar: Wie jedem Storage-System müssen auch bei Ceph die Daten am Ende irgendwo auf Blockspeichern liegen. Das realisiert Ceph, indem jede OSD-Instanz sich an ein Gerät anhängt und dieses innerhalb des Clusters über das RADOS-Protokoll zur Verfügung stellt. Prinzipiell können hier Festplatten oder SSDs zum Einsatz kommen. OSDs führen jedoch ähnlich wie Dateisysteme ein Journal – den eingangs bereits erwähnten Cache. Und Ceph bietet grundsätzlich die Möglichkeit, diesen Cache auf flotte SSDs auszulagern, ohne gleich das ganze System mit SSDs zu bestücken.

Den OSDs stehen als Wachhunde die MONs zur Seite, also die Monitoring-Server. Hier geht es nicht um Performance-Monitoring, sondern um grundlegende Objektspeicherfunktionen. Wie jede verteilte Speicherlösung muss sich in Ceph jemand darum kümmern, dass stets nur jene Teile des Clusters zum Einsatz kommen, die Quorum haben – also die Mehrheit der MONs auf ihrer Seite. Zerbräche ein Cluster aufgrund eines Netzwerkproblems, könnte es andernfalls passieren, dass auf den nun existierenden mehreren Teilen des Clusters parallel divergierende Writes stattfinden – ein Split-Brain entstünde. Den zu vermeiden ist eine der wichtigsten Aufgaben jeder Storage-Lösung.

Obendrein schreiben die MONs mit, welche MON-Server existieren (MONmap) und welche OSDs es gibt (OSDmap). Beide Informationen braucht der Client, um binäre Objekte in RADOS zu platzieren.

Wie Writes funktionieren

Damit in Ceph nicht die gesamte Schreiblast an Clients hängt, haben die Entwickler sich für einen dezentralen Ansatz entschieden. Clients implementieren dazu den Crush-Algorithmus, der zwar zufällige Resultate liefert, jedoch auf Basis desselben Layouts des Ceph-Clusters immer dieselben zufälligen Resultate. Das ist möglich, weil der Client die Liste aller OSDs in Form der OSDmap kennt, die die MONs für sie pflegen.

Will ein Client also etwas in Ceph ablegen, unterteilt er die zu speichernde Information zunächst mit Crush in binäre Objekte. In der Standardkonfiguration sind diese maximal 4 MByte groß. Dann errechnet der Client ebenfalls per Crush für jedes dieser Objekte den zuständigen primären Object Storage Daemon und lädt es hoch.

Die OSDs werden von sich aus aktiv, sobald binäre Objekte eingehen: Sie benutzen ebenfalls Crush, um die sekundären OSDs für das Objekt zu errechnen, und kopieren es anschließend dorthin. Erst wenn das Objekt in den Journalen so vieler OSDs angekommen ist, wie der Wert »size« es für das jeweilige Objekt angibt (ab Werk liegt er bei 3), geht das Acknowledgement für den Write-Vorgang an den Client hinaus. Erst dann gilt der Write also als abgeschlossen.

Layer-Kuchen

Zwar hält Ceph sich im direkten Vergleich mit anderen Lösungen des Cloud-Zeitalters wie Software Defined Networking noch angenehm in Sachen Vielschichtigkeit (Layer Cake) zurück. Trotzdem wird aber deutlich: Lahmen Writes oder Reads aus einem Ceph-Cluster, so gibt es eine Vielzahl von Komponenten, die als mögliche Übeltäter infrage kommen. Deren Vielschichtigkeit spiegelt sich in der Komplexität wieder, die das Überwachen der verschiedenen Ebenen auf Geschwindigkeit hin erfordert.

Die Grundlagen

Sinnvolles Performance-Monitoring bei Ceph beginnt im Idealfall mit den klassischen Basics des Monitorings. Auch bei Ceph-Knoten will der Admin über den Zustand einzelner Festplatten informiert bleiben. Zwar erkennt Ceph ausgefallene Festplatten automatisch; es kommt aber gar nicht so selten vor, dass Festplatten oder SSDs nur kleinere Defekte entwickeln. Nach außen hin behaupten sie dann, noch immer zu funktionieren, doch Write-Vorgänge brauchen ewig, ohne mit einer Fehlermeldung abzubrechen.

Ceph selbst erkennt solche Slow Writes und zeigt sie auch an (dazu später mehr). Es schadet aber nicht, wenn dem Admin die verräterischen DriveReady-SeekComplete-Fehler auch schon im zentralen Logging-System auffallen. Regelmäßig wird bei Ceph heute eher moderne Monitoring-Software wie Prometheus zum Einsatz kommen, bei der der Admin die Überwachung anderer klassischer Vitalwerte aber nicht vernachlässigen sollte. Lokale Hardware-Probleme, etwa in Form kaputter RAMs oder schlichter Überhitzung, führen bei Ceph gern zu einer gemächlichen Arbeitsweise.

Netzwerkprobleme

Eine riesige Fehlerdomäne bei Ceph stellen naturgemäß Probleme mit dem Netz zwischen Client und RADOS sowie zwischen den Laufwerken in RADOS dar. Wer sich mit dem Thema Netzwerk etwas ausgiebiger beschäftigt hat, der weiß: Moderne Switches und Netzwerkkarten sind hochkomplex und verfügen über eine Vielzahl von Stellschrauben und Features, die die erzielbare Performance beeinflussen. Gleichzeitig hat Ceph selbst auf dieses Thema nahezu keinen Einfluss, denn sonderlich viel lässt sich bei ihm in Sachen Netz gar nicht tunen. Es nutzt den im Linux-Kernel vorhandenen TCP/IP-Stack und verlässt sich auch darüber hinaus darauf, dass die vorhandene Netzwerkinfrastruktur regulär funktioniert.

Für den Admin bedeutet das, dass er seine Hardware in Sachen Netzwerk penibel überwachen muss. Das gilt auch und gerade für die typischen Performance-Parameter. Allerdings ist das auch leichter gesagt als getan. Es gibt zwar eine einheitliche Schnittstelle, um an entsprechende Informationen zu kommen: Beinahe alle modernen Geräte liefern solche Details per SNMP aus. Jedoch kocht praktisch jeder Hersteller sein eigenes Süppchen, was das Erheben der entsprechenden Daten angeht.

Mellanox etwa verbaut in seine hauseigenen ASICs eine Funktion namens “What just happened”, die den Admin bei der Suche etwa nach verworfenen Frames oder anderen Problemen unterstützt. Andere Hersteller, wie Cisco und Juniper, haben ebenfalls Monitoring-Tools für die eigene Hardware an Bord. Ein Rundum-Sorglos-Paket gibt es aber nicht, und je nach lokalem Setup läuft es letztlich auf eine komplette Lösung der Marke Eigenbau hinaus. Wer darauf achtet, Switches mit Linux-Firmware zu nutzen, ist aber immerhin nicht darauf angewiesen, sich mit den von den Herstellern erfundenen Speziallösungen im Detail zu beschäftigen.

Kommt es zu Performance-Einbrüchen in Ceph, muss der Admin im ersten Schritt herausfinden, wo sie auftreten. Entstehen sie zwischen den Clients und dem Cluster, ist möglicherweise andere Netzwerk-Hardware zuständig als bei Problemen in der Kommunikation der OSDs untereinander. Hier hilft es im Zweifelsfall, dem Cluster mit Tools wie Iperf zuleibe zu rücken und händisch zu messen.

Probleme mit Ceph

Vorausgesetzt, die umgebende Infrastruktur funktioniert, hat ein Performance-Problem in Ceph vermutlich seine Wurzeln in einer der involvierten Software-Komponenten. Das kann RADOS selbst betreffen, aber auch der Kernel der Systeme, auf denen Ceph läuft, kommt als Übeltäter infrage.

Zum Glück ergeben sich gerade auf der Ceph-Ebene mannigfaltige Monitoring-Möglichkeiten. Die Ceph-Entwicklern wissen um die Komplexität des Performance-Monitorings in ihrer Lösung: Man muss ja im Falle eines Falles erst einmal pro Objekt den primären OSD sowie die sekundären OSDs identifizieren und anschließend darauf nachsehen, woran es hakt.

Wer Tausende OSDs im System hat, sieht sich einem mächtigen Feind gegenüber. Das ist der Grund dafür, dass in Ceph die OSDs Metrikdaten für die eigene Performance penibel mitschreiben. Das bedeutet ganz konkret: Fällt einem OSD auf, dass der Write eines binären Objekts zu lang dauert, schickt er an alle im Cluster befindlichen OSDs eine entsprechende Slow-Write-Notiz. Zumindest diese Information ist also dezentral an vielen Stellen im Cluster hinterlegt.

Zusätzlich bietet Ceph gleich mehrere Schnittstellen, um an diese Informationen zu gelangen. Die einfachste Variante besteht sicher darin, auf einem Knoten mit aktivem MON den Befehl »ceph -w« zu starten. Der liefert daraufhin eine Übersicht aller gerade im System vermerkten Probleme, etwa auch der Slow Writes. Allerdings lässt sich das nicht sinnvoll automatisieren.

Vor einiger Zeit haben die Ceph-Entwickler ihrer Software deshalb einen weiteren Dienst namens »mgr« (für Manager) zur Seite gestellt. Der sammelt einerseits die von den OSDs aufgezeichneten Metrikdaten ein und ermöglicht es auf der anderen Seite, sie für Monitoring-Werkzeuge wie Prometheus zu verwenden.

Dashboard oder Grafana

Die Möglichkeit zum schnellen Überblick liefern einerseits die Ceph-Entwickler selbst: Die Mgr-Komponente hielt zusammen mit dem Ceph-Dashboard [1] Einzug in den Objektspeicher. Letzteres geht im Kern auf das ehemalige OpenAttic-Projekt zurück und stellt den Zustand des Ceph-Clusters grafisch ansprechend dar (Abbildung 3). Auch Probleme, die Ceph selbst erkennt, zeigt das Dashboard grafisch auffällig an.

Abbildung 3: Das Ceph-Dashboard gehört seit einiger Zeit zum Standardlieferumfang von Ceph. Quelle: Inktank

Diese Lösung ist aber nicht ideal für Fälle, in denen bereits ein funktionierendes Monitoring-System etwa auf Basis von Prometheus läuft, denn daran ist dann in aller Regel auch das Alarming direkt angeschlossen. Dort lässt sich das Ceph-Dashboard meist nicht unmittelbar integrieren. Doch die Mgr-Komponente von Ceph bietet auch eine native Schnittstelle für Prometheus, an das sich so Metrikdaten aus Ceph weiterleiten lassen. Und weil Telegraf die Prometheus-API ebenfalls unterstützt, finden die Daten auf Wunsch ihren Weg auch in InfluxDB.

Mit im Boot sitzt daneben auch Grafana. Für die Labels, über die Prometheus seine Metrikdaten aus Ceph ausliest, finden sich im Grafana-Dashboard-Store gleich mehrere Dashboards. Sie stellen die wichtigsten Metrikwerte grafisch dar und ermöglichen so dem Admin, sich schnell einen Überblick zu verschaffen.

Genau hinsehen

Ganz gleich, ob die Metrikdaten über das Ceph-Dashboard oder per Prometheus und Grafana dargestellt werden: Es bleibt die zentrale Frage, auf welche Daten der Admin überhaupt achten soll. Bei der Performance spielen vier Werte eine zentrale Rolle: * »ceph.commit_latency_ms« gibt die Zeit an, die Ceph über sämtliche Operationen hinweg im Schnitt benötigt. Als Operation zählt dabei etwa das Schreiben auf ein Laufwerk oder das Initiieren des Schreibvorgangs auf einen sekundären OSD. * »ceph.apply_latency_ms« gibt an, wie lange es im Schnitt dauert, bis Daten die OSDs erreichen. * »ceph.read_bytes_sec« und »ceph.write_bytes_sec« geben einen ersten Überblick darüber, was im Cluster gerade los ist.

Dieselben Werte lassen sich übrigens auch für einzelne Pools auslesen. Als Pools bezeichnet man logische Bereiche innerhalb von RADOS. Allzu viel sollte man sich von diesen Werten aber nicht versprechen, wenn der eigene Ceph-Cluster den üblichen Standards entspricht und alle Pools im Hintergrund auf dieselben Laufwerke zeigen. Hat man hingegen unterschiedliche Pools für im Cluster vorhandene unterschiedliche Speicherlaufwerke in Nutzung, etwa HDDs und SSDs, sind die Infos pro Pool vermutlich nützlicher.

Aus der Praxis

Mit den beschriebenen Maßnahmen und Wegen lassen sich Probleme in Ceph zuverlässig erkennen. Damit ist das Ende der Fahnenstange aber längst noch nicht erreicht. Viele Parameter, die der Ceph-Manager an die Außenwelt liefert, generiert er aus den Metrikwerten der einzelnen OSDs im System. Die lassen sich von außen allerdings auch per Admin-Socket jedes einzelnen OSDs direkt auslesen. Wenn der Admin das möchte, kann er also Prometheus oder Grafana durchaus auch so konfigurieren, dass es jede Operation auf jedem OSD in der Installation an das Monitoring weitergibt. Wie üblich gilt hier aber, dass die Dosis das Gift macht – ein Wust aus Tausenden Werten wird schnell unübersichtlich.

Unter Umständen fällt es zudem nicht ganz leicht, die Ursachen für bestimmte Metrikwerte in Ceph schnell zu identifizieren. Das ist aber die andere Hälfte der Miete in Sachen Ceph: Zu wissen, dass es im Cluster langsame Schreibvorgänge gibt, ist gut und schön. Eigentlich benötigt der Admin jedoch die Information, worin deren Ursache liegt. Das folgende Beispiel aus der persönlichen Erfahrung des Autors vermittelt einen Eindruck davon, wie Monitoring-Details sich nutzen lassen, um einem Performance-Problem in Ceph auf die Schliche zu kommen. Allerdings lässt sich dieser Vorgang nicht sinnvoll automatisieren.

Die Ausgangssituation

Ein Ceph-Cluster mit ungefähr 2,5 Petabyte Bruttokapazität kam hauptsächlich für die Nutzung mit OpenStack zum Einsatz. Startete man eine virtuelle Maschine, die ein in Ceph liegendes RBD-Abbild als Festplatte für das Root-Dateisystem nutzte, stellte sich regelmäßig ein lästiger Effekt ein: Die VMs erlitten über mehrere Minuten einen I/O-Stall und waren über diesen Zeitraum hinweg nicht benutzbar. Danach normalisierte sich die Situation für einige Zeit, doch das Problem kehrte regelmäßig zurück. Während der Zeiträume, in denen das Problem nicht bestand, lieferten Write-Vorgänge auf die Volumes der VMs passable 1,5 GByte pro Sekunde.

Die genutzten Monitoring-Systeme zeigten zwar in der Tat die zuvor beschriebenen Slow Writes an, hier war aber kein Muster zu erkennen. Stattdessen verteilten sie sich quer über sämtliche OSDs im System. Schnell war klar, dass das Problem nicht spezifisch für OpenStack war, denn ein lokales RBD-Image ohne Zugriff durch die Cloud-Lösung führte zum selben Fehlerbild.

Ist es das Netz?

Bald geriet deshalb das Netz unter Verdacht, weil es die augenscheinlich einzige Infrastruktur war, die sich alle beteiligten Komponenten teilten. Ausgiebige Tests mit Iperf und ähnlichen Tools widerlegten diesen Verdacht jedoch. Zwischen den Clients des Ceph-Clusters war der duale 25-Gbit/s-LACP-Link bei Iperf-Tests tatsächlich mit 25 Gbit/s und mehr am Start, und zwar zuverlässig. Ratlosigkeit machte sich breit, als die Fehlerzähler aller beteiligten NICs und auch jene auf den Netzwerk-Switches stur bei 0 verharrten.

Ab dort wurde es mühsam, denn in solchen Situationen hilft nur eines: einzelne Writes nachzuverfolgen. Sobald im Monitoring also ein langsamer Schreibvorgang auftauchte, war genaueres Hinsehen angezeigt. Den primären OSD eines Slow Writes zeigt Ceph stets an. Auf dem Host, auf dem der OSD lief, kam im nächsten Schritt dessen Admin-Socket zum Einsatz – und erwies sich als sehr hilfreich.

Tatsächlich führt jeder OSD intern Buch über die vielen Operationen, die er vollzieht. Das Log eines primären OSDs für ein Objekt enthält auch einzelne Einträge, die Beginn und Ende der Kopieroperationen für dieses Objekt hin zu den sekundären OSDs enthalten. Mit »ceph daemon osd.Nummer dump_ops_in_flight« lassen sich alle Operationen anzeigen, die ein OSD in Ceph gerade vornimmt. Zurückliegende Slow Ops kramt man mit dem Parameter »dump_historic_slow_ops« (Abbildung 4) hervor. Über »dump_historic_ops« lassen sich zudem Log-Meldungen über sämtliche zurückliegenden Operationen anzeigen, allerdings nur über einen bestimmten Zeitraum.

Abbildung 4: Nicht weniger als 16 Minuten hat in diesem Beispiel der primäre OSD darauf gewartet, von den sekundären OSDs ein OK für den Schreibvorgang zu bekommen.

Mit diesen Werkzeugen ausgestattet, wurde weiteres Monitoring möglich: Für einzelne Slow Writes ließ sich nun der primäre OSD herausfinden, und dort wiederum gab der involvierte OSD die Info preis, welche sekundären OSDs er errechnet hatte. Deren Meldungen in den Logs zum selben Schreibvorgang wären geeignet, Auskunft beispielsweise über defekte Storage-Laufwerke zu geben.

Schnell stellt sich jedoch heraus: Den größten Teil der Zeit, den der primäre OSD mit dem Warten auf Antworten der sekundären OSDs verbrachte, wussten diese von ihrem Glück noch gar nichts. Sobald die Write Requests bei den sekundären OSDs tatsächlich ankamen, waren diese binnen weniger Millisekunden erledigt. Bis der Request bei den sekundären OSDs jedoch ankam, vergingen oft mehrere Minuten.

Doch das Netzwerk

Da die Netzwerk-Hardware aufgrund umfangreicher Tests zuvor als potenzielle Fehlerquelle bereits ausgeschlossen worden war, schien es sich um ein Ceph-Problem zu handeln. Nach viel Herumprobieren fiel das Schlaglicht auf den Paketfilter der involvierten Systeme. Zu guter Letzt entpuppte sich Der in CentOS 8 standardmäßig genutzte Iptables-Nachfolger Nftables als Verursacher des Problems. Es handelte sich keineswegs um eine Fehlkonfiguration: Stattdessen sorgte ein Bug im Linux-Kernel dafür, dass der Paketfilter auch eigentlich gewollte Kommunikation nach einem unklaren Muster unterband. Das wiederum erklärte, wieso das Problem in Ceph sehr sprunghaft auftrat. Ein Update auf einen neueren Kernel schuf schließlich Abhilfe.

Das Beispiel zeigt deutlich: Automatisiertes Performance-Monitoring von in Ceph ist die eine Sache. Handelt es sich allerdings um hartnäckige Performance-Probleme, steht dem Admin in der Regel eine langwierige Debugging-Session ins Haus. Es schadet an dieser Stelle zweifellos nicht, den Hersteller der verwendeten Distribution als Support-Partner im Boot zu haben.

Fazit

Performance-Monitoring in Ceph lässt sich über dessen Bordmittel für das Mitschreiben von Metrikdaten gut realisieren. Ob die Darstellung am Ende via Ceph-Dashboard oder Prometheus erfolgt, spielt dabei kaum eine Rolle. Das Monitoring klassischer Leistungsparameter der Systeme sollte allerdings nicht außen vor bleiben.

Zumindest ein Stück weit unbefriedigend ist, dass das alleinige Feststellen eines Problems im Cluster keine unmittelbaren Rückschlüsse auf dessen Lösung zulässt. Das bedeutet ganz konkret: Wenn der Admin weiß, dass es ein Problem gibt, fängt die richtige Arbeit gerade erst an. Und die lässt sich kaum wegautomatisieren. (jcb/jlu)