Ceph Backfill immer nur 1 aktiv

Ingo S

Ingo S

Renowned Member
Proxmox Subscriber
Oct 16, 2016
348
42
93
41
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.
1702372049843.png
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.
1702372108411.png
Außerdem bekomme ich "too full" meldungen, obwohl die SSDs des Pools nur zwischen 55 und 63% gefüllt sind.
Code: 
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
Code: 
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.
 
Last edited:
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.
 
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.
 
Auf welchem Wert sind denn deine ratios?

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

Edit: und was sagt:

Code: 
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
 
Last edited:
jsterr said:
Auf welchem Wert sind denn deine ratios?

Code: 
root@PMX4:~#
ceph osd dump | grep ratio
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.6
Click to expand...
Die Ratios sind so:
Code: 
root@vm-1:~# ceph osd dump | grep ratio
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.85

jsterr said:
Edit: und was sagt:

Code: 
root@PMX4:/# ceph df
[...]
Click to expand...
Das wiederum sagt:
Code: 
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
 
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.
 
Last edited:
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:
Code: 
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.
Code: 
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.
 
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.
Bash: 
ceph config set osd osd_mclock_override_recovery_settings true
  • 'osd_max_backfills' auf 10 gesetzt, default ist 1:
Bash: 
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:

Bash: 
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:

Bash: 
ceph config set osd_mclock_profile high_recovery_ops

Ebenfalls hatte ich das Profil auf 'custom' gestellt:

Bash: 
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.
Good Luck!
 
Last edited:
  • Like
Reactions: UdoB
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom