Ceph PG count eines Pools muss verringert werden

[KaiS]

Hallo,

der autoscaler sagt mir, dass der pg count eines pools verringert werden sollte. Da ich schlimmes über den Automatismus gelesen habe, habe ich den Autoscaler nur auf "warn" stehen, d.h. es darf selbst nichts tun.

Nun frage ich mich, wie ich ich den PG Count verringern soll. Also die Befehle sind mir bekannt, die Frage lautet eher: In einem Rutsch oder in kleinen Schritten a 32PGs oder 128PGs.

Ich möchte Chaos und Systemausfall vermeiden, da das System in Produktion ist (gibt Backup) - Verlangsamung des Clusters wäre ok, aber kein Crash

Kann mir jemand mit einem Tipp weiterhelfen?

Danke,
Kai

 

[aaron]

Am einfachsten einfach in der GUI wenn du den Pool bearbeitest ("Advanced" Checkbox neben den OK Button aktivieren).

Die PG_num dann einfach auf den Zielwert setzen, dann kann Ceph sich dorthin vorarbeiten. Wenn du das in kleineren Schritten machst, hast du mehrmals den Aufwand, dass Ceph die Daten in den PGs herumschieben muss.

 

[KaiS]

Am einfachsten einfach in der GUI wenn du den Pool bearbeitest ("Advanced" Checkbox neben den OK Button aktivieren).

Die PG_num dann einfach auf den Zielwert setzen, dann kann Ceph sich dorthin vorarbeiten. Wenn du das in kleineren Schritten machst, hast du mehrmals den Aufwand, dass Ceph die Daten in den PGs herumschieben muss.

Hallo Aaron,
ich hab ein wenig Angst in die Situation zu geraten, die in einem anderen Thread beschrieben wurde:

The algorithm holds back flipping placement group numbers by only actioning a change when it's more than x 3 out by what it recommends. Whilst this sounds great it does mean that resulting changes are relatively massive (typically by a factor of 4). The unexpected consequence of large changes are that the cluster will be in a degraded state for a considerably amount of time and subsequently not trim the monitor database stores. This may lead to the /var/lib/ceph/mon/*/store.db directory growing to consume all available space and subsequently freeze all I/O. Attempting to compact the monitors and simply restarting them didn't help. Really annoying that Ceph doesn't trim the monitor databases after each incremental change...

Siehe: https://forum.proxmox.com/threads/c...think-twice-before-enabling-auto-scale.80105/


Hier geht es zwar um den Autoscaler, aber das ist ja das Selbe. Der Autoscaler hat hier massiv in einem Schritt die Anzahl der PG´s verändert, was dazu führte, dass die store.db ´s der Monitore übergelaufen sind und auf eine größe anwuchsen, die den freien Platz der jeweiligen Platte überstiegen.

So ein Szenario will/muss ich unbedingt vermeiden.

Grüße,
Kai

 

[aaron]

Wie groß ist die PG num jetzt und welche schlägt der Autoscaler vor?

Wie voll ist der Pool? Leere PGs sind schnell abgearbeitet.

Wie viel Platz hast du auf der OS Platte? Die MON DB liegt in /var/lib/ceph/mon/...

Wie schauen deine Pools eigentlich aus? Kannst du den Output von pveceph pool ls --noborder posten?

Wie viele OSDs hast du? ceph osd df tree

 

[KaiS]

Wie groß ist die PG num jetzt und welche schlägt der Autoscaler vor?

Wie voll ist der Pool? Leere PGs sind schnell abgearbeitet.

Wie viel Platz hast du auf der OS Platte? Die MON DB liegt in /var/lib/ceph/mon/...

Wie schauen deine Pools eigentlich aus? Kannst du den Output von pveceph pool ls --noborder posten?

Wie viele OSDs hast du? ceph osd df tree

Hallo Aaron,

Die Anzahl der PG ist aktuell 896. Ja ich weiss, es ist kein power_of_two. Was ja auch ein Grund ist, wieso das dringend angepasst werden muss.
Der Autoscaler schlägt 512 PG´s vor. Wir hatten damals erhöht, weil 512/18 <30PG/OSD ist und irgendwo stand man soll nicht unter die 30 fallen.

Ich denke es wurde damals in Steps erhöht und dann irgendwo auf dem Weg zu 1024 vergessen weiter zu machen.

Es sind 3 Nodes die 3/2 laufen. Auf jeder Node jeweils ein Monitor und Manager.

Ceph läuft insgesamt akuell mit 18 OSD´s (SSD´s). Diese haben allerdings unterschiedliche Größen (allerdings synchron je Node):

Je Node: 4 * 1TB + 2 * 2TB

Es existiert nur ein Pool der ausschließlich für die Disk Images der VM´s genutzt wird. Der ist leider auch bis zum Anschlag voll, d.h. bei gut 80%.
Ich bin dabei weitere OSD´s zu beschaffen um wieder für Entspannung zu sorgen.

Die Frage ist halt, ob ich jetzt aktuell auf 512PG´s gehen kann/soll/sollte oder erstmal mehr OSD´s rein. Oder auf 1024 hochgehen im Hinblick dass weitere OSD´s dazu kommen werden. Was ist belastender fürs System: PG hoch- oder runterschrauben?

Oder was sonst tun?

(exkurs:
Da ich am Wochenende von PVE5 auf PVE6 auf PVE7 migriert habe, gibt es aktuelle Backups von allem.
Da muss ich echt auch sagen, dass die Backups unter PVE7 um Lichtjahre besser laufen als unter PVE5.
Hat es mit PVE5 von Freitag Abend bis Montag Morgen gedauert alle VM´s in ein NFS Share zu backuppen, geht das jetzt innerhalb von 6 Stunden
)

Da ich von PVE4 komme wo es den Autoscaler nciht gab, hatten wir damals einen Cronjob eingerichtet:

 */15 * * * * /usr/bin/ceph osd reweight-by-utilization >/dev/null 2>&1

Der zu eine ausgewogenen Auslastung der OSD´s führt (wie man unten sehen kann). Nach dem Updae hatte ich diesen deaktiviert und auf den Auto-Balancer umgeschaltet, was zu einer ziemlichen "Unwucht" meiner OSD´s geführt hatte...

Jetzt zu Deinen Fragen im speziellen.

Platz auf den OS Platten

root@Prox3:/etc/pve/nodes/Prox3/qemu-server# df -h
Filesystem                                      Size  Used Avail Use% Mounted on
udev                                            126G     0  126G   0% /dev
tmpfs                                            26G  2.6M   26G   1% /run
/dev/mapper/pve-root                             55G  7.5G   45G  15% /
tmpfs                                           126G   66M  126G   1% /dev/shm
tmpfs                                           5.0M     0  5.0M   0% /run/lock

Hier die Pools:

root@Prox3:/etc/pve/nodes/Prox3/qemu-server# pveceph pool ls --noborder
Name                  Size Min Size PG Num min. PG Num Optimal PG Num PG Autoscale Mode PG Autoscale Target Size PG Autoscale Target Ratio Crush Rule Name               %-Used Used
ceph-vm                  3        2    896                        512 off                                                                  replicated_rule     0.84967428445816 18328659291424
device_health_metrics    3        2      2           1              1 warn                                                                 replicated_rule 1.73558109963778e-05 56281283

Und der OSD Tree
root@Prox3:/etc/pve/nodes/Prox3/qemu-server# ceph osd df tree ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME -1 20.95732 - 21 TiB 17 TiB 17 TiB 4.4 GiB 49 GiB 4.2 TiB 79.78 1.00 - root default -3 6.98576 - 7.0 TiB 5.6 TiB 5.6 TiB 1.5 GiB 17 GiB 1.4 TiB 79.84 1.00 - host Prox1 0 ssd 0.87318 0.87621 894 GiB 713 GiB 710 GiB 107 MiB 2.2 GiB 181 GiB 79.71 1.00 116 up osd.0 1 ssd 0.87320 0.90346 894 GiB 722 GiB 720 GiB 103 MiB 2.2 GiB 172 GiB 80.77 1.01 111 up osd.1 2 ssd 0.87320 0.90231 894 GiB 722 GiB 720 GiB 114 MiB 2.1 GiB 172 GiB 80.74 1.01 113 up osd.2 3 ssd 0.87320 1.00000 894 GiB 701 GiB 698 GiB 105 MiB 2.1 GiB 194 GiB 78.35 0.98 115 up osd.3 12 ssd 1.74649 0.92336 1.7 TiB 1.4 TiB 1.4 TiB 567 MiB 3.9 GiB 359 GiB 79.94 1.00 226 up osd.12 15 ssd 1.74649 0.90221 1.7 TiB 1.4 TiB 1.4 TiB 497 MiB 4.0 GiB 364 GiB 79.64 1.00 217 up osd.15 -5 6.98578 - 7.0 TiB 5.5 TiB 5.5 TiB 1.6 GiB 16 GiB 1.4 TiB 79.31 0.99 - host Prox2 4 ssd 0.87320 0.85182 894 GiB 715 GiB 712 GiB 144 MiB 2.1 GiB 180 GiB 79.92 1.00 109 up osd.4 5 ssd 0.87320 1.00000 894 GiB 683 GiB 681 GiB 162 MiB 2.0 GiB 211 GiB 76.44 0.96 110 up osd.5 6 ssd 0.87320 1.00000 894 GiB 688 GiB 686 GiB 162 MiB 2.0 GiB 206 GiB 76.94 0.96 111 up osd.6 7 ssd 0.87320 0.96857 894 GiB 714 GiB 712 GiB 112 MiB 2.2 GiB 180 GiB 79.84 1.00 115 up osd.7 13 ssd 1.74649 0.98405 1.7 TiB 1.4 TiB 1.4 TiB 538 MiB 3.8 GiB 354 GiB 80.20 1.01 224 up osd.13 16 ssd 1.74649 0.99385 1.7 TiB 1.4 TiB 1.4 TiB 523 MiB 3.8 GiB 349 GiB 80.48 1.01 229 up osd.16 -7 6.98578 - 7.0 TiB 5.6 TiB 5.6 TiB 1.3 GiB 17 GiB 1.4 TiB 80.19 1.01 - host Prox3 8 ssd 0.87320 0.97458 894 GiB 722 GiB 720 GiB 87 MiB 2.2 GiB 172 GiB 80.75 1.01 109 up osd.8 9 ssd 0.87320 0.98027 894 GiB 713 GiB 711 GiB 100 MiB 2.2 GiB 181 GiB 79.79 1.00 118 up osd.9 10 ssd 0.87320 0.93842 894 GiB 712 GiB 710 GiB 85 MiB 2.1 GiB 182 GiB 79.65 1.00 112 up osd.10 11 ssd 0.87320 0.86217 894 GiB 717 GiB 715 GiB 125 MiB 2.1 GiB 177 GiB 80.18 1.00 106 up osd.11 14 ssd 1.74649 1.00000 1.7 TiB 1.4 TiB 1.4 TiB 438 MiB 4.1 GiB 341 GiB 80.93 1.01 232 up osd.14 17 ssd 1.74649 0.96373 1.7 TiB 1.4 TiB 1.4 TiB 509 MiB 3.8 GiB 364 GiB 79.66 1.00 221 up osd.17 TOTAL 21 TiB 17 TiB 17 TiB 4.4 GiB 49 GiB 4.2 TiB 79.78 MIN/MAX VAR: 0.96/1.01 STDDEV: 1.24

 

[aaron]

Die 512 PGs die der Autoscaler vorschlägt sind in Ordnung: https://old.ceph.com/pgcalc/


Es schadet nicht, die "target_ratio" zu setzen. In dem Fall, weil es nur ein Pool ist, der Einfachheit halber, auf "1".


Auf dem root FS sind noch 45G frei, da sollte einiges an Mon DB Platz haben. Ich persönlich würde die PG num direkt auf 512 setzen und Ceph arbeiten lassen. Natürlich kann man das auch in kleineren Schritten machen, aber dann hast du mehrmals das ganze herumgeschiebe der Daten.


Wenn ich mir den ceph osd df tree Output ansehe, würde ich empfehlen, dass ihr dem Cluster mehr Speicherplatz gebt. Alle OSDs sind zu ~80% voll. Wenn da mal eine ausfällt könnte es auf der Node schon eng werden, wenn die Daten dieser OSD auf den anderen recovered wird.

Das Problem, bei unterschiedlich großen OSDs ist, dass die doppelt so großen auch circa doppelt soviel Daten abbekommen und somit auch mehr IO. Das kann dann durchaus ein Flaschenhals werden.

 

[KaiS]

Danke für Deinen Rat.
Wenn Du im Rechner jetzt aber mal 21 OSD eingibst - so wird es ja sein wenn ich jetzt noch 3 * 2 TB SSD einbaue, dann wird der PG Size von 1024 empfohlen.

Mittelfristig will ich alle 1TB durch 2 TB ersetzen.

Meinst Du es ist besser jetzt auf 512 zu gehen, dann die 3 neuen OSDs einzubauen um danach auf 1024 zu gehen?

Oder erst die 3 OSDs einbauen und danach direkt zu 1024 ? Was ist fürs System weniger belastend?

Mit meinen 896 PG´s fahre ich schon problemlos 4 Jahre - ich denke da machen 1 oder 2 Wochen jetzt auch kein Problem mehr.

OSD WearOut liegt durchgängig bei 1% - da hab ich erstmal keine Angst

 

[aaron]

Wenn du mittelfristig alle 1TB durch 2TB ersetzen willst, wirst du sowieso noch einiges an Rebalance haben, da hier das ideale Prozedere wie folgt ist:

1. OSD als out markieren
2. warten bis Ceph wieder Healthy ist da die Daten dieser OSD nun im restlichen Cluster verteilt werden
3. OSD entfernen / destroy
4. DIsk wechseln
5. neue OSD erstellen
6. warten bis Ceph Healthy und alles grün ist
7. nächste OSD

Oder erst die 3 OSDs einbauen und danach direkt zu 1024 ? Was ist fürs System weniger belastend?

Wenn die Frage "Was für das System weniger belastend ist" wirklich wichtig ist, insofern, als dass diese Änderungen einen Einfluss auf den Produktivbetrieb haben, würde ich mir gut überlegen, ob man nicht Last wegnehmen kann oder dem Cluster mehr Nodes / schnelleres Netz / ... geben kann, damit er das ohne Probleme abwickeln kann. Denn wenn eine Node oder OSD ausfällt, hast du genauso eine höhere Last, da Ceph sich davon erst mal erholen muss.

Diese Aufgaben sind grundsätzlich auch so in der Performance beschränkt, dass es wenig bis keinen merkbaren EInfluss auf den Produktivbetrieb geben sollte. Deshalb dauert sowas mitunter auch ein wenig, bis es fertig ist.

 

[KaiS]

Hi Aaron,

Danke für Deinen Ratschlag. Ich werde jetzt erstmal 3 * 2 TB SSD besorgen und damit 3 neue OSDs erzeugen. Dann PG auf 1024 setzen.

Da die 3 Server recht leistungsfähig sind, sehe ich kein Performance-Risiko beim Re-Balancing.

Ich berichte wenn ich den Vorgang abgeschlossen habe.

Vielen Dank,
Kai

 

[Ingo S]

Kurzer Hinweis noch:
Man kann, im Falle von Performance Problemen bei einem rebalance auch den rebalance bremsen, sowie die Priorität von IO Anweisungen verändern.

Anzahl gleichzeitiger Backfills reduzieren:
ceph tell osd.* injectargs '--osd-max-backfills 1'

Gleichzeitige recovery Threads auf 1 begrenzen
ceph tell osd.* injectargs '--osd-max-recovery-threads 1'

Recovery Priorität reduzieren (Damit Produktiv IO vorrang hat)
ceph tell osd.* injectargs '--osd-recovery-op-priority 1'
ceph tell osd.* injectargs '--osd-client-op-priority 63'

Anzahl aktiver recorvery Vorgänge pro OSD auf 1 beschränken
ceph tell osd.* injectargs '--osd-recovery-max-active 1'

Original stammt das von hier:
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2014-April/038989.html

Ich vermute, einige dieser Einstellungen sind in der Zwischenzeit zum Standard geworden, bzw. auf ganz gut passende Werte voreingestellt. Falls aber z.B. IO-Wait zum Problem werden sollte, hilft es ganz besonders, die Anzahl gleichzeitiger Backfills zu reduzieren. Bei Mailservern oder Datenbanken wird das schnell mal kritisch.
Wir fahren zur Zeit mit einem Wert von 12 ganz gut, auf einem 6 Node Cluster mit 24x 4TB HDDs (7200rpm SAS/SATA gemischt) und 10GBit Netz.
Kann man auch während der Arbeitszeiten reduzieren, und zum Feierabend dann hoch fahren...

 

[KaiS]

Ich wollte nur ein Feedback geben: Ich habe in jedem der 3 Nodes eine weitere OSD eingebaut und konnte problemlos auf 1024 PG gehen. Was ich mich nun aber frage:

Der Autoscaler sagt optimale PG wären 512, währen pgcalc 1024 sagt. Wem soll ich nun vertrauen.?