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

 

IPMI Einführung

, ,

IPMI  Einführung

IPMI (Intelligent Plattform Management Interface ) bietet die Möglichkeit per Web-GUI auf einen Server zuzugreifen, selbst wenn der Server ausgeschaltet ist.

Solange die IPMI-Netzwerkschnittstelle mit dem TCP-IP-Netzwerk verbunden ist und der Server im Standby am Stromnetz hängt, kann ein Server via IPMI fern gesteuert werden. Damit ist es etwa möglich, eine komplette Neu-Installation durchzuführen. Oft wird IPMI aber auch dazu genutzt, um einen Soft-Reset eines „hängenden“ Betriebssystems durchzuführen.

Die betreuenden Techniker ersparen sich so die Fahrt ins Rechenzentrum.

IPMI ist bei SuperMicro Mainboards in der Regel standardmäßig installiert. Bei ASUS Mainboards kann es mit Hilfe eines Chips dazu konfiguriert werden. Bei ASUS heißt das IPMI „BMC“.

IPMI einstellen / konfigurieren

Die Netzwerk-Einstellungen – konkret die IP-Adresse für IPMI– werden in der Regel im Bios des Rechners vorgenommen. Hier sind folgende Einstellungen vorzunehmen:

  • IP-Adresse
  • Netzwerkmaske
  • Gateway (Router)
  • DNS-Server

Das IPMI-Interface sollte nach Möglichkeit eine IP-Adresse im OOB (Out of band) Netzwerk des Rechenzentrums erhalten. IT-Administratoren sind gut beraten, dieses OOB-Netzwerk gut gegen äußere Angriffe abzusichern. Die IPMI-IP-Adresse sollte nach Möglichkeit nicht direkt aus dem Internet erreichbar sein.

Zugriff auf IPMI

Der Zugriff auf das Management von IPMI erfolgt über eine Web-Oberfläche. Unter der Adresse https://<IPMI-IP-Adresse/ kann der Server nach der Erst-Konfiguration erreicht werden.

Standard-Benutzer und Passwort

Der standardmäßig eingerichtete Zugang für IPMI lautet:

Username: admin

Passwort: admin

Das sollte man unbedingt nach der Inbetriebnahme ändern.

Wichtig: Die Änderung kann nicht im Bios sondern nur über die Weboberfläche durchgeführt werden.

Neu-Installation des Servers über IPMI

Prinzipiell kann unter IPMI ein CD oder DVD Medium von bis zu 4.7 GB Größe über das Netz gemounted werden und dem mit IPMI verwalteten Server als Boot-Medium zur Verfügung gestellt werden.

Auf diese Weise ist es möglich Betriebssystem-Installationen (Linux, Windows, VMWare) über das Netzwerk auszuführen. Ebenso ist es so möglich Treiber-Updates von eingebauter Hardware vorzunehmen.

IPMI zurücksetzen

Nicht selten wir das Passwort bei IPMI schlecht oder gar nicht gesichert. Was also tun, wenn „admin/admin“ nicht geht und auch das aktuelle Passwort für IPMI nicht (mehr) bekannt ist?

Für diesen Fall hat SuperMicro das kleine Tool IPMICFG erstellt.

Mit diesem kann man unter Linux und VMWare (was letztlich auch ein Linux ist) das Passwort kurz und schmerzlos neu setzen oder auch die Konfig des IPMI ändern.

 

Laden Sie sich dazu unter ftp://ftp.supermicro.com/utility/IPMICFG das dort gespeicherte Zip-File herunter und speichern es auf ihrem PC ab. Entpacken Sie die Zip-Datei mit IPMICFG in einen Unterordner. Kopieren Sie alle Dateien im passenden Unterverzeichnis auf den Linux bzw. VMWare Host.

Die Bits+Bytes für ein 64-bit Linux finden Sie unter „IPMICFG_1.27.1_build.170901\Linux\64bit“.

 

Bsp.: scp /<pfad>/IPMICFG_1.27.1_build.170901/Linux/64bit/* root@<esxi-host>:/tmp/

 

Verbinden Sie sich nun per ssh auf den VMWare oder Linux-Host und wechseln Sie ins Verzeichnis, in das Sie IPMICFG kopiert haben (hier /tmp). Zunächst müssen Sie die Datei „IPMICFG-Linux.x86_64“ ausführbar machen ( chmod +x)

 

Host# cd /tmp/
Host# chmod +x IPMICFG-Linux.x86_64

Hinweis: Mit dem Zusatz „—help“ erhalten Sie eine Übersicht aller Optionen und Befehlsteile von IPMICFG.

./IPMICFG-Linux.x86_64 –help

 

Konkret möchten wir zunächst wissen, welche Benutzer bereits in IPMI angelegt sind:

./IPMICFG-Linux.x86_64 -user list
[root@esxi01:/tmp/ipmicfg] ./IPMICFG-Linux.x86_64 -user list
Maximum number of Users          : 10
Count of currently enabled Users : 1

User ID | User Name        | Privilege Level | Enable

——- | ———–      | ————— | ——

2 | admin            | Administrator   | Yes

Wir sehen, dass der Benutzer „admin“ angelegt ist und die User-ID 2 aufweist. Die User-ID benötigen wir gleich um das Passwort zurück zu setzen.

Mit dem Befehl „-user setpasswd <user-id> <neues Passwort> können Sie nun das Passwort des Users „admin“ neu setzen.

./IPMICFG-Linux.x86_64 -user setpwd 2 <neues Passwort>

IPMI unter Windows

Die gerade beschriebene Vorgehensweise klappt übrigens auch unter Windows. Im Verzeichnis „\IPMICFG_1.27.1_build.170901\Windows\64bit“ finden Sie etwa die 64-Bit Variante der Software für einen Windows-Rechner bzw. Server. Ebenso ist unter „IPMICFG_1.27.1_build.170901\Windows\32bit“ eine 32-bit Version vorhanden.

Zur Benutzung von IPMICFG unter Windows kopieren Sie das entsprechende Verzeichnis auf ihren Windows-Rechner (auf dem IPMI installiert ist) und starten mit „cmd“ ein Kommandozeilen-Fenster.

Weitere Befehle von IPMI

Mit IPMICFG können Sie noch weit mehr als das Passwort zurücksetzen.

Factory default / Standard-Einstellungen setzen

Die Standard-Einstellungen für Netzwerk und Benutzer stellen Sie mit folgendem Befehl wieder her:

[root@esxi:/tmp/ipmicfg] ./IPMICFG-Linux.x86_64 -fd

IP-Adresse abfagen

[root@esxi:/tmp/ipmicfg] ./IPMICFG-Linux.x86_64 -m

Zusammenfassung / Übersicht von IPMI

[root@esxi:/tmp/ipmicfg] ./IPMICFG-Linux.x86_64 -summary
Summary
——————————————-
IP Address             : 10.10.10.20
BMC MAC Address        : 14:EE:A9:D7:B9:4E
Firmware Revision      : 1.07

 

Weiter Informationen und Downloads

Download IPMICFG

ftp://ftp.supermicro.com/utility/IPMICFG/

 

PDF-Handbuch zu IPMI-Konfig:

ftp://ftp.supermicro.com/utility/IPMICFG/Supermicro_Utility_User_Guide_IPMICFG.pdf