[SOLVED] Gelöst: Ceph-Pool schrumpft schnell nach Erweiterung mit OSDs (wahrscheinlich morgen Cluster-Ausfall)

[Goro]

Hallo zusammen,

nachdem ich einen SSD-Pool zu meinem bestehenden HDD-Pool hinzugefügt habe schrumpft der HDD-Pool extrem schnell, so dass vermutlich morgen ein Produktionsausfall bevorsteht.

ursprüngliche Umgebung:

• 3-Node-Hyper-Converged-Cluster, (PVE Vers. 6.3-6) mit verteiltem Ceph (Vers. 14.2.16)
• 2 HDDs pro Node
• (natürlich plus einer System-Disk...)
• Ceph-Health: grün

Diese Umgebung lief in der Form das letzte Jahr lang relativ stabil. Die Performance war ausreichend für diverse Linux-VMs/CTs, jedoch nicht für Windows-VMs und spezielle IO-lastige CTs. Daher wurde zu den bestehenden sechs HDDs drei SSDs hinzugefügt:

Änderungen vorgestern:

• Pro Node wurde eine SSD hinzugefügt.
• Die OSDs wurden angelegt.
• Die Crushmap wurde angepasst: (Screenshot s.u.)
  • Die Rule, mit der der ursprüngliche HDD-Pool erstellt wurde, wurde um "step take default class hdd" erweitert.
  • Eine neue Rule mit "step take default class ssd" wurde angelegt.
  • Ein neuer SSD-Pool wurde auf Basis der neuen SSD-Rule angelegt.
• Die virtuellen Disks der VMs wurden von dem HDD- auf den SSD-Pool verschoben.

Zwischenfazit:

• Performance der VMs nun mehr als ausreichend.
• Ziel erreicht (dachte ich, das war vorgestern.)

Problem:

Heute stelle ich erschrocken fest, dass der ursprüngliche HDD-Pool extrem an Größe verliert:




Der neu hinzugefügte SSD-Pool verhält sich jedoch wie erwartet:




(Ach ja, ein Ceph-FS habe ich hier auch noch, das schrumpft genau so: )




Hier die OSD-Konfiguration:




Die Pools:




Der geänderte Teil der Crusmap:


--> Die Rule "replicated_rule" ist die ursprüngliche, mit der ich vor Monaten den Pool "CephPool01" und das "CephFS01" angelegt habe. Hier habe ich vorgestern nur "class hdd" ergänzt
--> Die Rule "replicated_rule_ssd" habe ich vorgestern neu angelegt, und dann den Pool "CephPool_SSD" erstellt.


Ceph-Dashboard:




Fragen:
Warum verringert sich der Speicherplatz im alten HDD-Pool ("CephPool01"), obwohl ich pro Node eine OSD hinzugefügt habe und diverse VMs aus dem HDD-Pool in den SSD-Pool verdschoben habe?
Wie kann ich verhindern, dass der Cluster im Kürze stehen bleibt?
Hätte ich, nachdem ich die Crusmap geändert habe, den alten HDD-Pool löschen und neu anlegen müssen? (Das wäre sehr aufwändig...)

Ich bedanke mich schon einmal für alle Tipps vorab!!!

LG
Goro

 

[gurubert]

Ich vermute, dass hier einfach nur die Werte falsch addiert werden in den Graphen.

Es scheinen ja Daten von den HDDs auf die SSDs verschoben zu werden, damit sinkt der Füllstand der HDDs.

Wenn jetzt für die Anzeige belegter Platz und freier Platz zusammengerechnet wurden, nimmt der Gesamtplatz halt ab. Interessant wäre hier, die Ausgabe von ceph df zu beobachten. Und der Füllstand der einzelnen OSDs.

Bevor der Ceph-Cluster voll läuft, wird eine nearfull Warning ausgegeben. Das passiert, sobald ein OSD zu 85% gefüllt ist.

 

[Goro]

Vielen Dank für die Antwort,

durch das Setzen des "nobackfill"-Flags konnte ich nun das Schrumpfen der Pools stoppen. Das verschafft mir Zeit...

Ceph-Status nun:



Für den Füllstand der OSDs wird es in ein paar Stunden einen RDD-Graphen geben. Ich bastel da mal was... Dann werde ich das Backfilling wieder aktivieren und bin gespannt was passiert.

 

[Goro]

Ich habe gegen 15:10 Uhr das "backfill" noch einmal für 20 Minuten aktiviert. In der Zeit wurden die OSD2 und die OSD10 mit "was auch immer" gefüllt.



Die Ausgabe von "ceph df" entspricht (leider) bist auf eine Nachkommastelle der Visualisierung in der Web-Gui:

root@S16PVE01:~# ceph df
RAW STORAGE:
    CLASS     SIZE        AVAIL       USED        RAW USED     %RAW USED
    hdd        55 TiB      14 TiB      41 TiB       41 TiB         75.13
    ssd       5.5 TiB     2.6 TiB     2.8 TiB      2.8 TiB         51.94
    TOTAL      60 TiB      16 TiB      44 TiB       44 TiB         73.02
 
POOLS:
    POOL                  ID     PGS     STORED      OBJECTS     USED        %USED     MAX AVAIL
    CephPool01             1     128     4.3 TiB       1.16M      13 TiB     82.63       928 GiB
    CephFS01_data          2     128     9.2 TiB       4.77M      28 TiB     91.14       928 GiB
    CephFS01_metadata      3      32     1.7 GiB     458.72k     2.5 GiB      0.09       928 GiB
    CephPool_SSD           5     128     965 GiB     250.63k     2.8 TiB     54.62       802 GiB
root@S16PVE01:~#

 

[Goro]

Der Vollständigkeit halber hänge ich nochmal ein
ceph pg dump
als Textdatei mit an.

Zumidest was die Verteilung der PGs auf die OSDs angeht, scheint alles korrekt zu sein:

- OSD 3 bis 5 sind die SSDs
- alle anderen sind HDDs

 

[gurubert]

Ich vermute, dass bei so wenigen OSDs der CRUSH-Algorithmus Probleme hat, die Daten gleichmäßig zu verteilen.
Ist der Balancer aktiv?
https://docs.ceph.com/en/pacific/rados/operations/balancer/

 

[aaron]

Die Anzeige wie viel Platz frei ist, ist eine Abschätzung, die von mehreren Faktoren abhängt. Unter anderem davon, wie voll die OSDs sind. Laut Screenshots sind da die HDD OSDs sehr ungleich verteilt mit manchen auf ~90% und anderen auf 70%.

Wie @gurubert schon angemerkt hat, schau ob der Balancer an ist, und ob du vorübergehend die HDD OSDs leerer bekommst. Zum Beispiel, indem du ein paar VM DIsk auf den SSD Pool schiebst.

Wenn sich die HDD OSDs soweit erholt haben und gleichmäßig voll sind (sollte innerhalb von ein paar % Unterschied möglich sein), kannst du diese wieder vom SSD Pool zurückschieben.


Noch ein Hinweis bezüglich des Ceph Cluster Layouts. Ein 3-Node Ceph Cluster ist ein bisschen ein Spezialfall, bei dem man auch gut aufpassen muss, wie viele OSDs von einem Typ eine Node hat.

In deinem Fall, mit 2 HDD OSDs pro Node, hast du ein Problem, sobald eine HDD ausfällt. Denn es gibt ja immer noch 3 Nodes mit OSDs vom richtigen Typ um die 3 Replicas zu speichern. Allerdings wird die eine noch verbleibende HDD sehr schnell zu voll werden, da sie nicht genug Platz hat, um alle Daten, die auf der ausgefallenen gespeichert waren, zu übernehmen -> Pool steht.
Deshalb sollte man in einem 3-Node Cluster entweder nur eine OSD oder mehrere haben. Wenn man z.B. 4 OSDs vom gleichen Typ hat und eine ausfällt, müssen die übrigen circa ein Drittel der Daten aufnehmen.
Bei 2 OSDs dürfte man diese nur zu ein bisschen über 40% voll machen, damit beim Ausfall die zweite die Daten aufnehmen kann und nicht zu voll wird, als dass Ceph warnings wirft wegen einer zu vollen OSD.


Bei den SSDs ist das egal, da hier im Moment dann nur noch 2 Nodes mit SSD OSDs da sind und der Pool degraded ist, bis die SSD ausgetauscht wurde.

 

[Goro]

Vielen Dank für die letzten beiden Antworten, das Problem ist gelöst, jedoch auf eine etwas unschöne Art und Weise:

Der Balancer war, warum auch immer, nicht aktiv. Laut diversen Dokus sollte er es aber per default sein. Ich habe ihn jedoch nicht (wissentlich) abgeschaltet. Nach ein paar Schwierigkeiten konnte ich ihn aktivieren, er hat jedoch den Dienst mit folgender Begründung verweigert:

Too many objects (....) are misplaced; try again later

Mir fiel daher nur noch folgender Ausweg ein:

Don't try this at work, dude!

Ich habe das Backfilling Dienstagabend wieder eingeschaltet. Die beiden vollsten OSDs haben sich weiterhin schnell gefüllt. Nun wollte ich erzwingen, dass die weniger vollen OSDs mehr PGs zugeteilt bekommen. (Mit "reweight" kenne ich mich noch nicht genug aus...) Daher habe ich einfach den vollsten OSD für 10 Minuten deaktivert, bis sich die Torte schön rot eingefärbt hat. Dann habe ich ihn wieder aktiviert. Per "Selbstheilung" wurden die PGs nun relativ gleichmäßig verteilt. Nach ein paar Tagen hat auch der Balancer seine Arbeit selbstständig aufgenommen, er arbeitet nun so wie er soll:



(Was da am Montagmittag passiert ist, weiß ich nicht, ich habe vielleicht ein paar GB gelöscht / verschoben aber das kann eigentlich nur ein Bruchteil eines Prozents ausgemacht haben.)

Zum Thema 3-Node Cluster:
Ich hätte natürlich darauf kommen können, dass sich in dieser Konstellation der Cluster bei dem Ausfall einer OSD per Selbstheilung selbst zerstört. Bin ich aber nicht :-/
Von daher werde ich bei Gelegenheit, wenn ich vor Ort bin, OSDs hinzufügen und zukünftige Konfigurationen entsprechend größer auslegen. Stand heute würde ich vielleicht per Fernwartung bei dem Ausfall eines OSDs den verbleibenden in dem selben Node deaktivieren, oder den Node komplett herunterfahren. (Vielleicht das Ganze automatisiert per Skript...)

Vielen Dank noch einmal !!!
LG Goro

 

[aaron]

Der Balancer war, warum auch immer, nicht aktiv. Laut diversen Dokus sollte er es aber per default sein.

Schau bei den Docs immer auf das kleine Kästchen rechts oder links unten ob du auch die docs für die richtige Version siehst. AFAIK läuft in dem Cluster noch Nautilus (v14)? Dort ist er IIRC nicht automatisch aktiv. Erst ab Ocotpus (15) glaub ich.

Vielen Dank jedenfalls für die Erläuterung wie du mit der "Hail Mary" Aktion doch gut ausgestiegen bist. Der Graph ist auch interessant anzuschauen