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
- Über den Autor
- Aktuelle Beiträge
Matthias Böhmichen ist Geschäftsführer des IT-Dienstleisters Biteno GmbH. Neben seinem Job blogt und schreibt er auf den Webseiten der Biteno GmbH über technische und unternehmerische Themen.
