Ceph & BLUESTORE_SLOW_OP_ERROR

unter Online ▸ Stichwort Storage

Diesen Beitrag schrieb ich 1 Jahr und 4 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.

Geschätzte Lesezeit: 3 Minuten

Zu Testzwecken betreue ich einen Ceph-Stage-Cluster. Ceph war in Version 18.2.4 darauf installiert, und alles lief unauffällig vor sich hin und tat seinen Dienst. Dann spielte ich regulär Updates ein, und die brachten Ceph in Version 18.2.6 mit sich. Und seither spuckte mein Stage-Cluster Bluestore-Meldungen.

Das Fehlerbild

Plötzlich meldete sich das Monitoring immer wieder mit einem BLUESTORE_SLOW_OP_ALERT: mal war ein einzelner OSD betroffen, mal mehrere. Und dadurch gerät der gesamte Cluster in den WARNING-Zustand.

ceph health detail
HEALTH_WARN 1 OSD(s) experiencing slow operations in BlueStore
[WRN] BLUESTORE_SLOW_OP_ALERT: 1 OSD(s) experiencing slow operations in BlueStore
     osd.1 observed slow operation indications in BlueStore

Das war schon merkwürdig. Mir sagte die Meldung nicht viel, und was die Sache nicht einfacher machte: auch Google & Co. zeigten sich relativ ratlos. Ich versuchte, nähere Informationen zusammenzutragen, kam aber nicht so richtig voran.

ceph tell osd.1 bluefs stats
1 : device size 0x4ffc00000 : using 0x3ff99000(1024 MiB)
wal_total:0, db_total:20397110067, slow_total:0

Was ich sagen konnte, war:

  • es waren alle OSD-Server betroffenen, nicht nur einzelne
  • es waren mit jeder Meldung andere OSDs betroffen, nicht immer die selben
  • ein Restart eines betroffenen einzelnen OSDs ließ die Meldung verschwinden
  • mit hoher Wahrscheinlichkeit tauchte sie aber einige Tage später wieder auf
  • Und nicht ganz unwichtig: der Betrieb lief weiterhin reibungslos, keine Leistungseinbußen oder Probleme im Vergleich zur Zeit vor dem Update! 
mon1.example.com [INF] Health check cleared: BLUESTORE_SLOW_OP_ALERT (was: 1 OSD(s) experiencing slow operations in BlueStore)
mon1.example.com [INF] Health check cleared: OSD_DOWN (was: 1 osds down)
mon1.example.com [INF] osd.1 [v2:10.11.16.224:6804/3955295071,v1:10.11.16.224:6805/3955295071] boot
mon1.example.com [WRN] Health check update: Degraded data redundancy: 131/2154 objects degraded (6.082%), 6 pgs degraded (PG_DEGRADED)
mon1.example.com [INF] Health check cleared: PG_DEGRADED (was: Degraded data redundancy: 131/2154 objects degraded (6.082%), 6 pgs degraded)
mon1.example.com [INF] Cluster is now healthy

Die Ursache

Wie gesagt – ich hatte die Meldung vorher nie zur Kenntnis genommen. Und das konnte ich auch gar nicht, weil für Ceph Reef diese Funktionalität im November 2024 neu dazu kam. Die von mir verwendete 18.2.4 ist laut Projektwebseite von Juli 2024, das erste Release, das die Änderung beinhaltete, war 18.2.5 im April 2025. Da auch 18.2.6 sowie 18.2.7 im April 2025 released wurden ist im Nachhinein nun klar, dass mein April-Update die Änderung mitgebracht hat.
Soweit ich es für Ceph Squid überblicken kann, wurde die Änderung im September 2024 gemerged, so dass 19.2.1 die erste Version war, die den Code enthielt.

Gut zu wissen: auch wenn der Cluster in den Status WARNING fällt, ist das allenfalls etwas, das man aufmerksam betrachten sollte. In Panik verfallen braucht man aber erst einmal nicht! Die Logik dahinter ist folgende:

  • Ceph beobachtet, inwiefern es in Sachen Bluestore zu Slow Ops kommt
  • übersteigt deren Anzahl innerhalb eines bestimmten Zeitfensters einen festgelegten Wert, so geht der Cluster in den Zustand WARNING
  • kommen keine weiteren Slow Ops hinzu, „altert“ dies mit fortschreitender Zeit raus, und der Cluster springt entsprechend irgendwann wieder auf HEALTHY um
  • … was dann auch erklärte, warum ein Restart des OSDs die Sache, zumindest temporär, bereinigte bzw. warum manche Cluster sich übers Wochenende (AKA „weniger Last“) beruhigten, aber in der Folgewoche wieder losmaulten

Die Behebung

Problematisch sehe ich an der Stelle die Defaults: ist nichts anderes angegeben (und das Feature ist ja neu, niemand hat hier zuvor was angegeben), gelten bluestore_slow_ops_warn_lifetime als das definierte Zeitfenster und bluestore_slow_ops_warn_threshold als die Anzahl der Slow Ops:

ceph config get osd.1 bluestore_slow_ops_warn_lifetime
86400
ceph config get osd.1 bluestore_slow_ops_warn_threshold
1

Kommt es also innerhalb von 86400 Sekunden (AKA in den letzten 24 Stunden, Wert von bluestore_slow_ops_warn_lifetime) zu zwei oder mehr Slow Ops (Wert in bluestore_slow_ops_warn_threshold), wird dies in ceph health detail aufgegriffen, es kommt zu der Meldung osd.1 observed slow operation indications in BlueStore und der Gesamt-Cluster-Status geht auf WARNING. Das kann man so machen, ist aber nicht in jeder Umgebung (und auf meinem Stage-Cluster schon grad gar nicht) praxistauglich 😎

Kommen über die Zeit keine weiteren Slow Ops hinzu, verschwindet diese Warnung automatisch. Sollte sie jedoch mehr oder minder dauerhaft bestehen, dann liegt das daran, dass innerhalb des in bluestore_slow_ops_warn_lifetime definierten Zeitraums immer mal wieder Slow Ops hinzukommen. Dann kann es helfen,

  • entweder den beobachteten Zeitraum zu verkürzen (AKA bluestore_slow_ops_warn_lifetime verkleinern) oder
  • die Zahl der erlaubten Slow Ops innerhalb dieses Zeitraums zu erhöhen (AKA bluestore_slow_ops_warn_threshold vergrößern)

Will ich nun diese Werte für den gesamten Cluster ändern, beispielsweise den Zeitraum auf sechs Stunden nach unten und die Zahl erlaubter Slow Ops auf fünf nach oben korrigieren, mache ich das folgendermaßen:

ceph config set global bluestore_slow_ops_warn_lifetime 21600
ceph config set global bluestore_slow_ops_warn_threshold 5

Allerdings kann man es auch mehr eingrenzen: zum Beispiel, indem man es auf bestimmte OSDs einschränkt. Wenn ich also weiß, dass es immer mein osd.1 ist, der mir Stress macht, modifiziere ich nur seine Werte:

ceph config set osd.1 bluestore_slow_ops_warn_lifetime 21600
ceph config set osd.1 bluestore_slow_ops_warn_threshold 5

Oder ich schränke es auf bestimmte Klassen ein:

ceph config set class:hdd bluestore_slow_ops_warn_lifetime 21600
ceph config set class:hdd bluestore_slow_ops_warn_threshold 5

Ich nähere mich dem schrittweise, denn diese Art Meldungen hat ja durchaus ihre Berechtigung. Auch modifiziere ich nicht notwendigerweise beide Werte gleichzeitig – und schon gar nicht so gravierend, wie in der offiziellen Doku zum Thema dargestellt, denn da setzen sie die lifetime-Variable auf 10 Sekunden und die Anzahl der Slow Ops auf fünf… Das ist dann so ein bisschen „von einem Extrem ins andere“ 🤭

Zusammenfassend

Es handelt sich hier glücklicherweise nicht um einen Fehler, es ist nicht funktionseinschränkend, kein Ceph-Admin muss in Panik verfallen. Es liefert allerdings Anhaltspunkte, vor allem, wenn zugleich doch auch Performance-Probleme vorliegen. Und durch passendes Setzen der Variablen bluestore_slow_ops_warn_lifetime und bluestore_slow_ops_warn_threshold können wir uns eine Menge unnötigen Monitoring-Lärms und Grundrauschen ersparen.

Hintergrundbild © Marianne Spiller · Alle Rechte vorbehalten

3 Kommentare

Hinterlasse einen Kommentar

Ich freue mich über jeden Kommentar, es sei denn, er ist blöd.
Deshalb sind die Kommentare auf dieser Seite auch generell moderiert.

(Nick)Name: (erforderlich)
E-Mail: (erforderlich, wird nicht veröffentlicht)
Website: (optional)