Ceph deep scrub error beheben

, ,

Ceph deep scrub error beheben

Wer Ceph produktiv betreibt, wird im Laufe der Zeit immer mal wieder einen „unhealthy“ Zustand des Clusters erleben. Solange es sich dabei um eine noch harmlose „Ceph Warning“ geht, ist der gesunde Zustand des Clusters oft schnell wieder erreicht. Oft sogar ganz von alleine ohne ein Zutun des Linux-Administrators.

Doch was tun wenn „plötzlich“ ein echter Fehler auftritt? Mit „ceph health detail“ erfahren wir auf einen Blick, was das Cluster macht. In unserem konkreten Fall war Ceph ohne Vorwarnung auf unserem frisch installierten Proxmox Cluster in einen „Health Error“ gewechselt.

root@pve02:/var/log/ceph# ceph health detail
HEALTH_ERR 129254/2436848 objects misplaced (5.304%); 1 scrub errors; Possible data damage: 1 pg inconsistent
OBJECT_MISPLACED 129254/2436848 objects misplaced (5.304%)
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent
pg 4.41 is active+remapped+inconsistent+backfill_wait, acting [0,10]

In Folge einer neu eingebauten Platte ergaben sich eine überschaubare Menge (5,3%) von Placement Groups (pg), die nun nicht mehr richtig verteilt waren. In einer normalen Ceph Umgebung wäre das Thema in wenigen Stunden von alleine erledigt gewesen.

Im konkreten Fall haben wir aber eine Placement Group, die ein echtes Problem hat: PG 4.41.

Diese PG liegt sowohl auf OSD.0 als auch OSD.10 – zu erkennen an [0,10] -> hier werden die OSD Nummern aufgelistet.

Ceph deep scrub error analysieren

Um das Problem genauer zu analysieren loggen wir uns also per ssh auf den jeweiligen ceph hosts an auf  denen die osds liegen bzw. die OSD-Prozesse laufen. Pro Ceph-OSD liegt unter /var/log/ceph ein einzelnes Log-File. Wir schauen uns nun genau das Logfile des OSD-Prozesses an, der von Ceph selbst in der obigen Meldung ausgegeben wird.

Pve02# cd /var/log/ceph
(host mit osd.10)
cat ceph-osd.0.log | grep -i 4.41
-> viel output -> suche nach „error“ oder „fail“
=> kein Ergebnis

Da der erste Host keinen Fehler anzeigt, muss also die andere potentielle OSD, auf der die Placement Group liegt, ein Problem haben. Wie loggen uns also auf dem Host ein  auf dem die OSD.0 liegt

root@pve01# cd /var/log/ceph
root@pve01:/var/log/ceph# cat ceph-osd.10.log | grep -i 4.41
(…)
2018-06-21 20:05:48.793010 7fc78b0f3700  0 log_channel(cluster) log [DBG] : 4.41 deep-scrub starts
2018-06-21 20:06:23.380373 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 shard 0: soid 4:823a7476:::rbd_data.2862f74b0dc51.0000000000006060:head candidate had a read error <== Hier beginnt das Problem
2018-06-21 20:07:04.032674 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 deep-scrub 0 missing, 1 inconsistent objects
2018-06-21 20:07:04.032681 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 deep-scrub 1 errors
2018-06-21 20:18:38.424228 7fc7830e3700  4 rocksdb: (Original Log Time 2018/06/21-20:18:38.424147) [/home/builder/source/ceph-12.2.5/src/rocksdb/db/memtable_list.cc:383] [default] Level-0 commit table #451: memtable #1 done

Dem Logfile nach liegt also auf der OSD.10 vermutlich das Problem.

 

Lösungsansatz zur Behebung des Deep Scrub Error

Wir entfernen temporär die OSD.10 aus dem Cluster und „zwingen“ Ceph die Placement Groups neu zu verteilen. Die Lösung dabei ist höchst einfach:

Befehl: ceph osd out osd.<OSD_ID>

 

root@pve01:/var/log/ceph# ceph osd out osd.10
root@pve01:/var/log/ceph# ceph osd df
ID CLASS WEIGHT  REWEIGHT SIZE   USE   AVAIL  %USE  VAR  PGS
8   hdd 1.81929  1.00000  1862G  485G  1377G 26.05 0.80  51
9   hdd 1.81929  1.00000  1862G  677G  1185G 36.38 1.12  72
10   hdd 1.63730        0      0     0      0     0    0  52
11   hdd 1.63730  1.00000  1676G  534G  1142G 31.86 0.98  57
12   hdd 1.81929  1.00000  1862G  479G  1383G 25.76 0.79  51

 

Nun ist die OSD 10 ist raus und 52 Placement Groups müssen verschoben bzw. neu auf die restlichen Platten verteilt werden. Mit „ceph –w“ können wir den laufenden Status des Ceph Clusters permanent überwachen. Dort kann man nach einigen Minuten auch anhand der sich verkleinernden Prozentzahl hochrechnen, wie lange der Umverteilungs-Vorgang noch dauern wird.

Weitere Infos zum Deep Scrub Error