4
Ceph langsamer Rebuild
Hi,
wir haben in der Firma einen neuen Proxmox-Cluster angelegt. Zuerst mit nur einem Knoten als Test. Als Hardware dient ein Server mit mit 64(128) EPYC Kernen, 512GB RAM, und für die Daten 2x 16GB HDDs und 8x SSDs.
Angelegt wurden die Platten über 2 verschiedene CRUSH-Rules. Eine für die HDDs und eine für die SSDs. So ähnlich haben wir das schon bei einem anderen Cluster gemacht wo wir gute Erfahrung gesammelt hatten.
Nach einer Weile bekamen wir bei Ceph folgende Warnungen:
- XX pgs not deep-scrubbed in time
- XX pgs not scrubbed in time
Alle diese PGs verweisen auf die HDDs. Natürlich läuft da ein Recovery/Rebuild, aber mit ca 1MB/sec wo da steht das es ca 10 Jahre dauert bis der fertig ist. Die Pools die darauf liegen (cephfs_data und cephfs_metadata) sind aber ausreichend schnell und die Benchmarks der Platten zeigen auch ca 500 iops. Wenn ich mich auf die Hosts einlogge sind weder die CPUs noch iotop am Anschlag und dümpeln nur so vor sich hin.
Inzwischen ist ein 2. Knoten in den Cluster mit rein gekommen und die Pools laufen jetzt statt mit 1/1 mit 2/1. Es hat sich aber nichts geändert. Replica/Recovery wird bei den HDDs mit 1MB/sec durchgeführt. Ich hatte auch schon an den Parametern osd_max_backfills, osd_recovery_max_active, osd_recovery_op_priority gedreht. Es ändert sich kein bisschen was.
Ich bin ratlos. Hat vielleicht jemand eine Idee?
wir haben in der Firma einen neuen Proxmox-Cluster angelegt. Zuerst mit nur einem Knoten als Test. Als Hardware dient ein Server mit mit 64(128) EPYC Kernen, 512GB RAM, und für die Daten 2x 16GB HDDs und 8x SSDs.
Angelegt wurden die Platten über 2 verschiedene CRUSH-Rules. Eine für die HDDs und eine für die SSDs. So ähnlich haben wir das schon bei einem anderen Cluster gemacht wo wir gute Erfahrung gesammelt hatten.
Nach einer Weile bekamen wir bei Ceph folgende Warnungen:
- XX pgs not deep-scrubbed in time
- XX pgs not scrubbed in time
Alle diese PGs verweisen auf die HDDs. Natürlich läuft da ein Recovery/Rebuild, aber mit ca 1MB/sec wo da steht das es ca 10 Jahre dauert bis der fertig ist. Die Pools die darauf liegen (cephfs_data und cephfs_metadata) sind aber ausreichend schnell und die Benchmarks der Platten zeigen auch ca 500 iops. Wenn ich mich auf die Hosts einlogge sind weder die CPUs noch iotop am Anschlag und dümpeln nur so vor sich hin.
Inzwischen ist ein 2. Knoten in den Cluster mit rein gekommen und die Pools laufen jetzt statt mit 1/1 mit 2/1. Es hat sich aber nichts geändert. Replica/Recovery wird bei den HDDs mit 1MB/sec durchgeführt. Ich hatte auch schon an den Parametern osd_max_backfills, osd_recovery_max_active, osd_recovery_op_priority gedreht. Es ändert sich kein bisschen was.
Ich bin ratlos. Hat vielleicht jemand eine Idee?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6434822791
Url: https://administrator.de/contentid/6434822791
Printed on: April 28, 2024 at 01:04 o'clock
4 Comments
Latest comment
Du wirst niemals vernünftige Antworten auf so ungenau aussagen erhalten, vor allem nicht bei Ceph.
Fassen wir zusammen: ihr verwendet zwei Hosts mit einer Replica rule von erst 1/1 und dann 2/1, obwohl das absolute Minimum 3/2 mit drei Hosts ist? Zur Netzwerkkarte über keine Aussage.
Fassen wir zusammen: ihr verwendet zwei Hosts mit einer Replica rule von erst 1/1 und dann 2/1, obwohl das absolute Minimum 3/2 mit drei Hosts ist? Zur Netzwerkkarte über keine Aussage.
Nein, das empfohlene Minimum ist 3/2. Wie auch immer, die SSDs haben sich mit 1GB/sec ausbalanciert, und die waren auch erst 1/1 und dann 2/1. Daran liegts also nicht.
Netzwerk sind jeweils 2x 10GBit per LACP
Ein 3. Host kommt auch noch demnächst mit in den Cluster. Ich gehe aber nicht davon aus das dieser das Problem löst.
Du schreibst ich gebe zu wenig Informationen. Aber was wird denn gebraucht?
Nachtrag, die Platte sind natürlich jeweils 16TB, nicht 16GB ;)
Netzwerk sind jeweils 2x 10GBit per LACP
Ein 3. Host kommt auch noch demnächst mit in den Cluster. Ich gehe aber nicht davon aus das dieser das Problem löst.
Du schreibst ich gebe zu wenig Informationen. Aber was wird denn gebraucht?
Nachtrag, die Platte sind natürlich jeweils 16TB, nicht 16GB ;)
Infos wie zum Beispiel diverse PGs, Ceph Health Status, Ceph OSD Tree, Ceph Version, Rados Bench usw. Wie kann es deiner Meinung nach ein empfohlenes Minimum geben? Minimum ist Minimum und wird nicht umsonst angegeben.
Jeder weiss das ein 3/2 Cluster schon nicht performant ist, über HDDs brauchen wir gar nicht erst anfangen zu reden.
Wie sind deine HDDs genau angebunden, hast du das Bios und alles andere angepasst? HDD Cache an oder aus? Usw.. aber wie gesagt, keiner braucht sich über ein 1/1 oder 2/1 "Cluster" zu unterhalten. Frag im Proxmox Forum nach 1/1 oder 2/1, die werden dir was erzählen 😅
Ich meins nicht böse, aber kein Mensch, der Ceph nur ein wenig versteht (was wirklich nicht leicht ist), würde so ein Setup erstellen und Performance verlangen.
Jeder weiss das ein 3/2 Cluster schon nicht performant ist, über HDDs brauchen wir gar nicht erst anfangen zu reden.
Wie sind deine HDDs genau angebunden, hast du das Bios und alles andere angepasst? HDD Cache an oder aus? Usw.. aber wie gesagt, keiner braucht sich über ein 1/1 oder 2/1 "Cluster" zu unterhalten. Frag im Proxmox Forum nach 1/1 oder 2/1, die werden dir was erzählen 😅
Ich meins nicht böse, aber kein Mensch, der Ceph nur ein wenig versteht (was wirklich nicht leicht ist), würde so ein Setup erstellen und Performance verlangen.
Es kommt ja demnächst der 3. Host mit rein, dann wird das auch hoch geschraubt. Ich gehe aber nicht davon aus das sich was ändert außer das ein paar Jahre dazu kommen ;)
- Ceph Version: 17.2.5
- Ceph Health Status: HEALTH_WARN Degraded data redundancy: 107189376/242522094 objects degraded (44.198%), 64 pgs degraded, 64 pgs undersized; 87 pgs not deep-scrubbed in time; 87 pgs not scrubbed in time
- ceph osd tree
- rados bench
Die Platten und SSDs hängen an einem MegaRaid-Raidcontroller, der die Platten aber als HBA durchreicht. Das 2/1, auch wenn es nicht ideal ist, erklärt aber keine Geschwindigkeit von 1% der möglichen Plattengeschwindigkeit
- Ceph Version: 17.2.5
- Ceph Health Status: HEALTH_WARN Degraded data redundancy: 107189376/242522094 objects degraded (44.198%), 64 pgs degraded, 64 pgs undersized; 87 pgs not deep-scrubbed in time; 87 pgs not scrubbed in time
- ceph osd tree
...
-5 58.21075 root default
-1 29.10538 host pve-01
0 hdd 14.55269 osd.0 up 1.00000 1.00000
1 hdd 14.55269 osd.1 up 1.00000 1.00000
-13 29.10538 host pve-02
10 hdd 14.55269 osd.10 up 1.00000 1.00000
11 hdd 14.55269 osd.11 up 1.00000 1.00000rados bench -p test_pool 10 write
hints = 1
Maintaining 16 concurrent writes of 4194304 bytes to objects of size 4194304 for up to 10 seconds or 0 objects
Object prefix: benchmark_data_pve-01_1555247
sec Cur ops started finished avg MB/s cur MB/s last lat(s) avg lat(s)
0 0 0 0 0 0 - 0
1 16 34 18 71.9957 72 0.0485885 0.414548
2 16 60 44 87.992 104 1.31173 0.535718
3 16 82 66 87.9915 88 0.477073 0.606979
4 16 99 83 82.9917 68 0.667625 0.629572
5 16 117 101 80.7918 72 0.926883 0.673826
6 16 141 125 83.3249 96 0.123463 0.686341
7 16 156 140 79.9917 60 1.56854 0.726264
8 16 172 156 77.9918 64 0.588185 0.730772
9 16 177 161 71.5479 20 2.04395 0.761649
10 16 195 179 71.5924 72 2.39912 0.834418
11 4 195 191 69.4472 48 1.44185 0.864698
Total time run: 11.3335
Total writes made: 195
Write size: 4194304
Object size: 4194304
Bandwidth (MB/sec): 68.8225
Stddev Bandwidth: 22.9972
Max bandwidth (MB/sec): 104
Min bandwidth (MB/sec): 20
Average IOPS: 17
Stddev IOPS: 5.74931
Max IOPS: 26
Min IOPS: 5
Average Latency(s): 0.876413
Stddev Latency(s): 0.695166
Max latency(s): 2.96922
Min latency(s): 0.0421574
Cleaning up (deleting benchmark objects)
Removed 195 objects
Clean up completed and total clean up time :0.385347Die Platten und SSDs hängen an einem MegaRaid-Raidcontroller, der die Platten aber als HBA durchreicht. Das 2/1, auch wenn es nicht ideal ist, erklärt aber keine Geschwindigkeit von 1% der möglichen Plattengeschwindigkeit
