Ceph Backfill immer nur 1 aktiv

[Ingo S]

Hallo zusammen

Wir haben in unserem Ceph Cluster einen SSD Pool, den ich gerade erweitere, weil er langsam zu voll wird. Ich habe eine zusätzliche SSD eingesetzt und warte jetzt auf den Backfill.
Interessanterweise ist aber immer nur ein einziger Backfill aktiv, egal auf was ich "osd max backfills" setze.

Ich habe mit ceph tell osd.* injectargs '--osd-max-backfills 16' versucht, das zu erhöhen, aber es ändert sich leider gar nichts, auch nicht nach längerer Wartezeit. Und die Backfill Rate liegt bei 8-15MB/s.

Außerdem bekomme ich "too full" meldungen, obwohl die SSDs des Pools nur zwischen 55 und 63% gefüllt sind.

Spoiler: OSD Status

ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE  DATA     OMAP      META     AVAIL    %USE   VAR   PGS  STATUS
 0    ssd  1.45499   1.00000  1.5 TiB  798 GiB  794 GiB   3.0 MiB  3.6 GiB  692 GiB  53.57  1.19  121      up
 2    ssd  1.45499   0.85002  1.5 TiB  813 GiB  809 GiB   2.9 MiB  3.5 GiB  677 GiB  54.56  1.21  116      up
 3    ssd  1.45499   0.79999  1.5 TiB  872 GiB  869 GiB   3.1 MiB  3.8 GiB  618 GiB  58.55  1.30  132      up
 4    ssd  1.45499         0      0 B      0 B      0 B       0 B      0 B      0 B      0     0    0    down
 5    ssd  1.45499   0.95000  1.5 TiB  867 GiB  863 GiB   3.0 MiB  4.1 GiB  623 GiB  58.22  1.29  129      up
12    ssd  1.45549   1.00000  1.5 TiB  667 GiB  658 GiB   8.3 MiB  9.0 GiB  824 GiB  44.74  0.99  101      up
16    ssd  2.91100   1.00000  2.9 TiB  1.5 TiB  1.5 TiB   5.7 MiB  4.1 GiB  1.4 TiB  52.80  1.17  240      up
20    ssd  1.45499   0.85002  1.5 TiB  810 GiB  806 GiB   4.8 MiB  3.9 GiB  680 GiB  54.34  1.20  115      up
32    ssd  1.45549   0.85002  1.5 TiB  795 GiB  792 GiB   2.5 MiB  3.4 GiB  695 GiB  53.35  1.18  122      up
33    ssd  1.45549   0.95000  1.5 TiB  858 GiB  854 GiB   3.3 MiB  4.1 GiB  632 GiB  57.58  1.28  131      up
34    ssd  1.45549   0.95000  1.5 TiB  811 GiB  804 GiB   6.5 MiB  7.6 GiB  679 GiB  54.43  1.21  123      up
35    ssd  1.45549   0.89999  1.5 TiB  858 GiB  850 GiB   8.6 MiB  8.0 GiB  632 GiB  57.56  1.28  130      up
36    ssd  2.91049   1.00000  2.9 TiB  497 GiB  494 GiB   1.2 MiB  2.3 GiB  2.4 TiB  16.66  0.37   76      up

Spoiler: backfill too full Meldungen

HEALTH_WARN: Low space hindering backfill (add storage if this doesn't resolve itself): 16 pgs backfill_toofull
pg 7.2 is active+remapped+backfill_wait+backfill_toofull, acting [2,5,32]
pg 7.1a is active+remapped+backfill_wait+backfill_toofull, acting [16,0,35]
pg 7.2b is active+remapped+backfill_wait+backfill_toofull, acting [16,33,5]
pg 7.38 is active+remapped+backfill_wait+backfill_toofull, acting [0,32,16]
pg 7.3e is active+remapped+backfill_wait+backfill_toofull, acting [5,16,20]
pg 7.7b is active+remapped+backfill_wait+backfill_toofull, acting [5,16,34]
pg 7.96 is active+remapped+backfill_wait+backfill_toofull, acting [16,20,32]
pg 7.97 is active+remapped+backfill_wait+backfill_toofull, acting [35,2,12]
pg 7.d5 is active+remapped+backfill_wait+backfill_toofull, acting [2,16,34]
pg 7.115 is active+remapped+backfill_wait+backfill_toofull, acting [0,16,2]
pg 7.118 is active+remapped+backfill_wait+backfill_toofull, acting [16,34,33]
pg 7.160 is active+remapped+backfill_wait+backfill_toofull, acting [5,33,16]
pg 7.17d is active+remapped+backfill_wait+backfill_toofull, acting [5,12,32]
pg 7.191 is active+remapped+backfill_wait+backfill_toofull, acting [0,2,34]
pg 7.1ee is active+remapped+backfill_wait+backfill_toofull, acting [16,5,33]
pg 7.1f5 is active+remapped+backfill_wait+backfill_toofull, acting [16,32,34]

Ich bin gerade ein bisschen ratlos und bräuchte ein paar Ideen, was da los ist.

Edit: Wir nutzen keine Consumer SSDs, das sind Kioxia PM5V und PM7V angebunden via SAS.

 

[Falk R.]

Ich kenne das Problem nicht, aber du hast noch eine out OSD, eventuell hat es mit der zu tun?
Bisher hat er bei Ceph 17.2 alle Erweiterungen mit vernünftig Durchsatz gemacht bei mir.

 

[Ingo S]

Die SSD ist absichtlich out, die soll den Node wechseln. Die habe ich bereits leer geräumt und liegt bei mir auf dem Schreibtisch. Der Cluster war vor dem Einbau der neuen SSD healthy.

 

[jsterr]

Auf welchem Wert sind denn deine ratios?

root@PMX4:~#
ceph osd dump | grep ratio
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.6

Edit: und was sagt:

root@PMX4:/# ceph df
--- RAW STORAGE ---
CLASS    SIZE   AVAIL     USED  RAW USED  %RAW USED
nvme   13 TiB  12 TiB  1.0 TiB   1.0 TiB       8.23
TOTAL  13 TiB  12 TiB  1.0 TiB   1.0 TiB       8.23

--- POOLS ---
POOL             ID  PGS   STORED  OBJECTS     USED  %USED  MAX AVAIL
.mgr              1    1   12 MiB        4   35 MiB      0    3.7 TiB
vm_nvme           2  512  325 GiB    1.25M  955 GiB   7.84    3.7 TiB
cephfs_data       3   32   28 GiB    7.10k   83 GiB   0.73    3.7 TiB
cephfs_metadata   4   32  1.7 MiB       23  5.3 MiB      0    3.7 TiB

 

[Ingo S]

Auf welchem Wert sind denn deine ratios?

root@PMX4:~#
ceph osd dump | grep ratio
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.6

Die Ratios sind so:

root@vm-1:~# ceph osd dump | grep ratio
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.85

Edit: und was sagt:

root@PMX4:/# ceph df
[...]

Das wiederum sagt:

root@vm-1:~# ceph df
--- RAW STORAGE ---
CLASS     SIZE   AVAIL    USED  RAW USED  %RAW USED
hdd     88 TiB  51 TiB  38 TiB    38 TiB      42.73
ssd     20 TiB  10 TiB  10 TiB    10 TiB      48.92
TOTAL  109 TiB  61 TiB  48 TiB    48 TiB      43.89
 
--- POOLS ---
POOL         ID   PGS   STORED  OBJECTS     USED  %USED  MAX AVAIL
HDD_Storage   1  1024   12 TiB    3.45M   37 TiB  47.03     14 TiB
SSD_Storage   7   512  3.3 TiB    6.62M  9.9 TiB  54.71    2.7 TiB
.mgr          8     1   64 MiB       17  192 MiB      0     14 TiB

 

[jsterr]

Die ratios passen und die Pool ID passt auch zu den PGs. Was sagt ceph pg 7.2 query ?
Ein wenig verkürzt ggf. mit: ceph pg 7.2 query | grep -A 10 -B 10 recovery

Vll hilft dir: https://docs.ceph.com/en/quincy/rados/troubleshooting/troubleshooting-pg/ weiter. Sucht man im query nach blocked, könntest du vll herausfinden, ob die pg ggf. etwas am backfilling hindert.

 

[Ingo S]

Danke erstmal
Ich habe mit dem Query etwas rum gespielt, aber wirklich schlauer bin ich daraus nicht geworden.

Wenn ich nach recovery gucke finde ich nichts besonderes:

Spoiler: ceph pg 7.2 query | grep -A 10 -B 10 recovery

root@vm-1:~# ceph pg 7.2 query | grep -A 10 -B 10 recovery
        3
    ],
    "acting": [
        2,
        5,
        32
    ],
    "backfill_targets": [
        "3"
    ],
    "acting_recovery_backfill": [
        "2",
        "3",
        "5",
        "32"
    ],
    "info": {
        "pgid": "7.2",
        "last_update": "184243'34078694",
        "last_complete": "184243'34078694",
        "log_tail": "184232'34076144",
--
            "empty": 0,
            "dne": 0,
            "incomplete": 0,
            "last_epoch_started": 183868,
            "hit_set_history": {
                "current_last_update": "0'0",
                "history": []
            }
        }
    ],
    "recovery_state": [
        {
            "name": "Started/Primary/Active",
            "enter_time": "2023-12-11T17:37:23.202922+0100",
            "might_have_unfound": [],
            "recovery_progress": {
                "backfill_targets": [
                    "3"
                ],
                "waiting_on_backfill": [],
                "last_backfill_started": "MIN",
                "backfill_info": {
                    "begin": "MIN",
                    "end": "MIN",
                    "objects": []
                },

Und wenn ich nach blocked suche springt mir auch nichts ins Auge.

Spoiler: ceph pg 7.2 query | grep -A 10 -B 10 blocked

root@vm-1:~# ceph pg 7.2 query | grep -A 10 -B 10 blocked
                "2",
                "5",
                "32"
            ],
            "object_location_counts": [
                {
                    "shards": "2,5,32",
                    "objects": 12765
                }
            ],
            "blocked_by": [],
            "up_primary": 2,
            "acting_primary": 2,
            "purged_snaps": []
        },
        "empty": 0,
        "dne": 0,
        "incomplete": 0,
        "last_epoch_started": 183868,
        "hit_set_history": {
            "current_last_update": "0'0",
--
                    "num_large_omap_objects": 0,
                    "num_objects_manifest": 0,
                    "num_omap_bytes": 0,
                    "num_omap_keys": 0,
                    "num_objects_repaired": 0
                },
                "up": [],
                "acting": [],
                "avail_no_missing": [],
                "object_location_counts": [],
                "blocked_by": [],
                "up_primary": -1,
                "acting_primary": -1,
                "purged_snaps": []
            },
            "empty": 0,
            "dne": 0,
            "incomplete": 1,
            "last_epoch_started": 183868,
            "hit_set_history": {
                "current_last_update": "0'0",
--
                    5,
                    3
                ],
                "acting": [
                    2,
                    5,
                    32
                ],
                "avail_no_missing": [],
                "object_location_counts": [],
                "blocked_by": [],
                "up_primary": 2,
                "acting_primary": 2,
                "purged_snaps": []
            },
            "empty": 0,
            "dne": 0,
            "incomplete": 0,
            "last_epoch_started": 183868,
            "hit_set_history": {
                "current_last_update": "0'0",
--
                    5,
                    3
                ],
                "acting": [
                    2,
                    5,
                    32
                ],
                "avail_no_missing": [],
                "object_location_counts": [],
                "blocked_by": [],
                "up_primary": 2,
                "acting_primary": 2,
                "purged_snaps": []
            },
            "empty": 0,
            "dne": 0,
            "incomplete": 0,
            "last_epoch_started": 183868,
            "hit_set_history": {
                "current_last_update": "0'0",

Wir haben mit dem Ceph schon einiges erlebt, aber noch nie bin ich über sowas gestolpert.

 

[Damian83]

Ein alter Thread, ich weiss, da das Problem aber häufiger vorzukommen scheint, und wenig Lösungsansätze publiziert wurden, hier mein Ansatz als ich das Problem hatte.

• Ich bin min PVE & Ceph Version 18.2.4 reef (stable) unterwegs, mit dem default mclock_scheduler und default settings
• Dieser Teil der Docs hat mich darauf gebracht: https://docs.ceph.com/en/latest/rad...o-modify-mclock-max-backfills-recovery-limits
• Um Manuelle Eingriffe zu ermöglichen den 'manual override' aktiviert (default ist 'false'):

ceph config set osd osd_mclock_override_recovery_settings true

• 'osd_max_backfills' auf 10 gesetzt, default ist 1:

ceph config set osd osd_max_backfills 10

Dies erlaubt 10 OSD beim backfill mitzuwirken, hat bei mir den backfill von bis zu 20 PGs gleichzeitig ermöglicht, und je nachdem welche OSDs (bei mir in diesem Fall alles HDDs) beteiligt waren, so 100 bis 250 MB/s Transferraten ermöglicht. Von 45 Tagen prognostizierter recovery time bin ich nun bei weniger als 24h.
Es macht natürlich Sinn die Einstellung graduell zu erhöhen und nachdem das gräbste überstanden ist, die Einstellungen wieder auf default zu setzen:

ceph config rm osd osd_mclock_override_recovery_settings
ceph config rm osd osd_max_backfills

Ich hatte ebenfalls diese Config ausprobiert, das hat aber in meinem Fall keine nennenswerte Steigerung der backfills erwirkt:

ceph config set osd_mclock_profile high_recovery_ops

Ebenfalls hatte ich das Profil auf 'custom' gestellt:

ceph config set osd_mclock_profile custom

Und dann mit diesen Settings versucht die Gewichtung bei 'best_effort' zu erhöhen. Da ich aber schon die workload auf dem Cluster reduziert hatte, und per default keine limits gesetzt sind, hat das leider in meinem Fall auch nichts gebracht.

• osd_mclock_scheduler_client_res
• osd_mclock_scheduler_client_wgt
• osd_mclock_scheduler_client_lim
• osd_mclock_scheduler_background_recovery_res
• osd_mclock_scheduler_background_recovery_wgt
• osd_mclock_scheduler_background_recovery_lim
• osd_mclock_scheduler_background_best_effort_res
• osd_mclock_scheduler_background_best_effort_wgt
• osd_mclock_scheduler_background_best_effort_lim

Good Luck!

 

[Neutrino2072]

Hi Damian,

ich bin eben auf diesen Thread gestoßen und finde deine Antwort auf jeden Fall sehr interessant. Ich habe mit Ceph 11 angefangen vor ein paar Jahren und nun nutze ich Proxmox 8 mit Ceph 17.6.2.

Was mir bei Ceph schon immer aufgefallen ist, ist dass die Cluster Performance totale Grütze wird sobald das Cluster irgendwas macht. Also mein Problem ist eigentlich, dass zwar 20 gleichzeitige Backfills passieren, meine CPUs, RAM, Disks und mein Netzwerk (4x10G) dabei kaum belastet werden, aber meine VMs (etwa 70) haben einfach 250ms Latenz statt 2ms. Ich weiß nicht ob das mit diesem Problem zu tun hat, aber hier sind trotzdem meine Specs:

• 3x Dell R660XS (48x3.9GHz, 384GB RAM)
• 2x 10G VMs und FrontEnd
• 2x 10G Ceph Backend
• je 10x Samsung Datacenter 2TB SATA SSD

Im aktuellen Fall sind von 256 PGs gerade 10 am backfillen, Rebalance passiert mit gerade mal 2Gbit auf dem Backend Netz und steht bei 97%. Disk Latenzen laut Linux bei 2ms, Commit Latency bei max 45ms.

Im Normalfall, wenn man das Cluster in Ruhe lässt, habe ich einwandfreie Storage Performance. Aber es reicht schon wenn mal 5 backfilling Operationen aktiv sind, wodurch 97% des Clusters einwandfrei bleiben und der Status auch "Health OK" bleibt und direkt schmiert alles ab auf 5% Leistung.

Das ist sicher das zehnte Cluster was ich in der Hand hatte und alle hatten das Problem. In einem früheren Cluster mit Ceph 15 hatte ich mal einen deutschen Ceph Support mit drin, der mir nur gesagt hat "joar das ist halt Ceph". Bei dir klingt es als kennst du dich gut aus also: Ist das ernsthaft "einfach Ceph" oder übersehe ich hier irgendwas wichtiges?

Grüße

 

[Falk R.]

Hi Damian,

ich bin eben auf diesen Thread gestoßen und finde deine Antwort auf jeden Fall sehr interessant. Ich habe mit Ceph 11 angefangen vor ein paar Jahren und nun nutze ich Proxmox 8 mit Ceph 17.6.2.

Was mir bei Ceph schon immer aufgefallen ist, ist dass die Cluster Performance totale Grütze wird sobald das Cluster irgendwas macht. Also mein Problem ist eigentlich, dass zwar 20 gleichzeitige Backfills passieren, meine CPUs, RAM, Disks und mein Netzwerk (4x10G) dabei kaum belastet werden, aber meine VMs (etwa 70) haben einfach 250ms Latenz statt 2ms. Ich weiß nicht ob das mit diesem Problem zu tun hat, aber hier sind trotzdem meine Specs:

• 3x Dell R660XS (48x3.9GHz, 384GB RAM)
• 2x 10G VMs und FrontEnd
• 2x 10G Ceph Backend
• je 10x Samsung Datacenter 2TB SATA SSD

Im aktuellen Fall sind von 256 PGs gerade 10 am backfillen, Rebalance passiert mit gerade mal 2Gbit auf dem Backend Netz und steht bei 97%. Disk Latenzen laut Linux bei 2ms, Commit Latency bei max 45ms.

Im Normalfall, wenn man das Cluster in Ruhe lässt, habe ich einwandfreie Storage Performance. Aber es reicht schon wenn mal 5 backfilling Operationen aktiv sind, wodurch 97% des Clusters einwandfrei bleiben und der Status auch "Health OK" bleibt und direkt schmiert alles ab auf 5% Leistung.

Das ist sicher das zehnte Cluster was ich in der Hand hatte und alle hatten das Problem. In einem früheren Cluster mit Ceph 15 hatte ich mal einen deutschen Ceph Support mit drin, der mir nur gesagt hat "joar das ist halt Ceph". Bei dir klingt es als kennst du dich gut aus also: Ist das ernsthaft "einfach Ceph" oder übersehe ich hier irgendwas wichtiges?

Grüße

Hi,

mit 2x10G (hoffentlich LACP L3+4) und SATA SSDs kannst du keine Rakete erwarten. Das SATA Interface ist eh schon vom Durchsatz und I/O stärker limitiert und mit 2x10G kommt da auch nicht so viel rum. Wenn du Backfill machst, glaube ich nicht, dass dein Netzwerk nix tut. Ich habe auch Cluster bei Kunden mit HDDs, wo die 20G voll gesättigt werden.

 

[Neutrino2072]

Hi Falk,

danke für deine Antwort. Das mit der Hash Policy ist schonmal ein guter Hinweis, die ist nämlich Layer2. Dass ich mit SATA SSDs keine Rakete erwarten kann hörte ich auch vom Ceph Spezialisten damals. Ich erwarte aber mehr als 10MB/s und 50 IOPS von 3 Nodes mit 30 SSDs. Ein SATA Interface schafft 500MB/s und die Samsung PM883 hat 98k Read IOPS.

"Wenn du Backfill machst, glaube ich nicht, dass dein Netzwerk nix tut":

Okay, wenn es einen Beweis braucht, habe eben nochmal die nobackfill flag deaktiviert:


Das ist bei 6 backfill PGs. OSD commit latency nicht über 30ms. Die IOPS auf dem Pool sind direkt von 3500 auf 10 gebrochen.

 

[Falk R.]

Hi Falk,

danke für deine Antwort. Das mit der Hash Policy ist schonmal ein guter Hinweis, die ist nämlich Layer2. Dass ich mit SATA SSDs keine Rakete erwarten kann hörte ich auch vom Ceph Spezialisten damals. Ich erwarte aber mehr als 10MB/s und 50 IOPS von 3 Nodes mit 30 SSDs. Ein SATA Interface schafft 500MB/s und die Samsung PM883 hat 98k Read IOPS.

Ja SATA schafft 500MB/s bei 1MB Blöcken und die 98k Read I/O sind auch theoretisch bei 100% Read und nur 4k Blöcke.
Sobald da mixed Workload kommt bricht das ganze ein.

"Wenn du Backfill machst, glaube ich nicht, dass dein Netzwerk nix tut":

Okay, wenn es einen Beweis braucht, habe eben nochmal die nobackfill flag deaktiviert:
View attachment 79313

Das ist bei 6 backfill PGs. OSD commit latency nicht über 30ms. Die IOPS auf dem Pool sind direkt von 3500 auf 10 gebrochen.

30ms ist auch nicht doll.

Generell mit LACP Layer2 nutzt du nur eine Leitung für Ceph.
Ob bei dir die SATA Anbindung oder das Netzwerk bremst, müsste man mal genau untersuchen. Aber wenn die Latenzen so hoch gehen, ist da irgend jemand auf Anschlag.