Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Enterprise Storage 5

20 Fehlersuche

In diesem Kapitel werden verschiedene Probleme erläutert, die möglicherweise bei Ihrer Arbeit mit einem Ceph Cluster auftreten.

20.1 Melden von Softwareproblemen

Falls bei der Ausführung von SUSE Enterprise Storage bei einigen der Komponenten wie Ceph oder Object Gateway ein Problem auftritt, melden Sie es bitte dem Technischen Support von SUSE. Die dazu empfohlene Methode ist das Dienstprogramm supportconfig.

Tipp
Tipp

Da es sich bei supportconfig um eine modulare Software handelt, sollten Sie sicherstellen, dass das Paket supportutils-plugin-ses installiert ist.

rpm -q supportutils-plugin-ses

Falls es am Ceph Server fehlt, installieren Sie es mit

zypper ref && zypper in supportutils-plugin-ses

Auch wenn Sie supportconfig in der Kommandozeile verwenden können, empfehlen wir doch das entsprechende YaST-Modul. Weitere Informationen zu supportconfig finden Sie unter https://www.suse.com/documentation/sles-12/singlehtml/book_sle_admin/book_sle_admin.html#sec.admsupport.supportconfig.

20.2 Fehler beim Senden großer Objekte mit rados bei vollem OSD

rados ist ein Kommandozeilenprogramm zur Verwaltung des RADOS-Objektspeichers. Weitere Informationen finden Sie unter man 8 rados.

Wenn Sie mit dem rados-Dienstprogramm ein großes Objekt an einen Ceph Cluster senden, wie zum Beispiel

rados -p mypool put myobject /file/to/send

füllt das Objekt möglicherweise den gesamten OSD-Speicherplatz aus und verursacht erhebliche Probleme bei der Cluster-Leistung.

20.3 Beschädigtes XFS-Dateisystem

Unter seltenen Umständen wie zum Beispiel einem Kernel-Fehler oder fehlerhafter/falsch konfigurierter Hardware könnte das zugrundeliegende Dateisystem (XFS), in dem ein OSD seine Daten speichert, beschädigt werden oder nicht mehr einhängbar sein.

Wenn Sie sicher wissen, dass es keine Probleme mit der Hardware gibt und das System ordnungsgemäß konfiguriert ist, melden Sie einen Fehler am XFS-Teilsystem des SUSE Linux Enterprise Server-Kernels und kennzeichnen Sie den betreffenden OSD als ausgefallen:

ceph osd down OSD identification
Warnung
Warnung: Das beschädigte Gerät darf nicht formatiert oder anderweitig bearbeitet werden

Es mag vielleicht vernünftig erscheinen, das Problem im Dateisystem mit xfs_repair zu beheben, doch das Kommando ändert das Dateisystem und darf daher nicht verwendet werden. Der OSD startet zwar möglicherweise, doch seine Funktionsweise könnte beeinträchtigt sein.

Nun löschen Sie die zugrundeliegende Festplatte und erstellen den OSD mit folgendem Kommando neu:

ceph-disk prepare --zap $OSD_DISK_DEVICE $OSD_JOURNAL_DEVICE"

Beispiel:

ceph-disk prepare --zap /dev/sdb /dev/sdd2

20.4 Statusmeldung "Too Many PGs per OSD" (Zu viele PGs pro OSD)

Wenn Sie die Nachricht Too Many PGs per OSD (Zu viele PGs pro OSD) erhalten, nachdem Sie ceph status ausgeführt haben, bedeutet dies, dass der Wert mon_pg_warn_max_per_osd (standardmäßig 300) überschritten wurde. Dieser Wert wird mit der Anzahl der PGs pro OSD-Kontingent verglichen. Dies bedeutet, dass die Cluster-Einrichtung nicht optimal ist.

Die Anzahl der PGs kann nach Erstellung des Pools nicht verringert werden. Pools, die noch keine Daten enthalten, können sicher gelöscht und dann mit einer kleineren Anzahl von PGs neu erstellt werden. Im Fall, dass Pools bereits Daten enthalten, besteht die einzige Lösung darin, OSDs zum Cluster hinzuzufügen, sodass das Kontingent von PGs pro OSD verkleinert wird.

20.5 Statusmeldung "nn pg stuck inactive" (NN PG hängen geblieben und inaktiv)

Wenn Sie eine Statusmeldung stuck inactive (hängen geblieben und inaktiv) erhalten, nachdem Sie ceph status ausgeführt haben, bedeutet es, dass Ceph nicht weiß, wo die gespeicherten Daten reproduziert werden sollen, um die Reproduktionsregeln zu erfüllen. Dies kann kurz nach der Ersteinrichtung von Ceph vorkommen und wird automatisch repariert. In anderen Fällen ist möglicherweise ein manuelles Eingreifen nötig, wie zum Beispiel Aktivieren eines fehlerhaften OSDs oder Hinzufügen eines neuen OSDs zum Cluster. In sehr seltenen Fällen mag es helfen, die Reproduktionsstufe zu reduzieren.

Wenn die Placement Groups permanent hängen bleiben, müssen Sie die Ausgabe von ceph osd tree überprüfen. Die Ausgabe sollte eine Baumstruktur aufweisen, ähnlich dem Beispiel in Abschnitt 20.7, „OSD is Down (OSD ist inaktiv)“.

Wenn die Ausgabe von ceph osd tree eher flach ist wie im folgenden Beispiel

ceph osd tree
ID WEIGHT TYPE NAME    UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1      0 root default
 0      0 osd.0             up  1.00000          1.00000
 1      0 osd.1             up  1.00000          1.00000
 2      0 osd.2             up  1.00000          1.00000

dann sollten Sie prüfen, ob die entsprechende CRUSH Map eine Baumstruktur aufweist. Wenn diese ebenfalls flach ist oder keine Hosts enthält wie im obigen Beispiel, dann könnte dies bedeuten, dass die Hostnamenauflösung im Cluster nicht korrekt funktioniert.

Wenn die Hierarchie inkorrekt ist (beispielsweise wenn der Stamm zwar Hosts enthält, doch die OSDs sich auf der obersten Ebene befinden und keinen Hosts zugewiesen sind), dann müssen Sie die OSDs an die korrekte Stelle in der Hierarchie verschieben. Dies kann mit den Kommandos ceph osd crush move und/oder ceph osd crush set erfolgen. Weitere Detailinformationen hierzu finden Sie in Abschnitt 6.4, „Umgang mit der CRUSH Map“.

20.6 OSD Weight is 0 (OSD-Gewicht ist 0)

Einem OSD wird beim Starten ein Gewicht zugewiesen. Je höher das Gewicht, desto größer ist die Chance, dass der Cluster Daten an den OSD schreibt. Das Gewicht wird entweder in einer Cluster CRUSH Map angegeben oder vom Startskript des OSDs berechnet.

In einigen Fällen kann der berechnete Wert für das Gewicht des OSDs auf Null abgerundet werden. Dies bedeutet, dass der OSD nicht zum Speichern von Daten geplant ist und keine Daten an ihn geschrieben werden. Normalerweise besteht der Grund dafür darin, dass die Festplatte zu klein ist (kleiner als 15 GB) und durch eine größere ersetzt werden sollte.

20.7 OSD is Down (OSD ist inaktiv)

Der OSD-Daemon wird entweder ausgeführt oder ist gestoppt/inaktiv. Es gibt drei allgemeine Gründe dafür, dass ein OSD inaktiv ist:

  • Festplattenfehler.

  • Der OSD ist abgestürzt.

  • Der Server ist abgestürzt.

Den detaillierten Status von OSDs sehen Sie durch Ausführen von

ceph osd tree
# id  weight  type name up/down reweight
 -1    0.02998  root default
 -2    0.009995   host doc-ceph1
 0     0.009995      osd.0 up  1
 -3    0.009995   host doc-ceph2
 1     0.009995      osd.1 up  1
 -4    0.009995   host doc-ceph3
 2     0.009995      osd.2 down  1

Die Beispielauflistung zeigt, dass osd.2 inaktiv ist. Prüfen Sie dann, ob die Festplatte, auf der sich der OSD befindet, eingehängt ist:

lsblk -f
 [...]
 vdb
 ├─vdb1               /var/lib/ceph/osd/ceph-2
 └─vdb2

Den Grund für die Inaktivität des OSDs finden Sie in der Protokolldatei /var/log/ceph/ceph-osd.2.log. Nachdem Sie den Grund dafür, dass der OSD nicht ausgeführt wird, gefunden und beseitigt haben, starten Sie ihn mit

sudo systemctl start ceph-osd@2.service

Vergessen Sie nicht, 2 durch die tatsächliche Nummer Ihres gestoppten OSDs zu ersetzen.

20.8 Suchen langsamer OSDs

Beim Abstimmen der Cluster-Leistung ist es sehr wichtig, langsame Speicher/OSDs im Cluster zu erkennen. Wenn die Daten nämlich an die langsam(st)e Festplatte geschrieben werden, verlangsamt sich der gesamte Schreibvorgang, da immer gewartet wird, bis der Vorgang auf allen entsprechenden Festplatten beendet ist.

Es ist nicht unbedeutend, den Speicherengpass zu finden. Sie müssen jeden einzelnen OSD untersuchen, um herauszufinden, welche OSDs den Schreibvorgang verlangsamen. Führen Sie zum Ausführen eines Vergleichs auf einem einzelnen OSD Folgendes aus:

ceph tell osd.OSD_ID_NUMBER bench

Beispiel:

root # ceph tell osd.0 bench
 { "bytes_written": 1073741824,
   "blocksize": 4194304,
   "bytes_per_sec": "19377779.000000"}

Dann müssen Sie dieses Kommando auf jedem OSD ausführen und den Wert bytes_per_sec vergleichen, um die langsam(st)en OSDs zu erkennen.

20.9 Beheben von Taktversatzwarnungen

Die Zeitinformationen in allen Cluster Nodes müssen synchronisiert werden. Wenn die Uhrzeit eines Nodes nicht vollständig synchronisiert ist, erhalten Sie möglicherweise Taktversatzwarnungen, wenn Sie den Zustand des Clusters überprüfen.

Die Zeitsynchronisierung wird mit NTP verwaltet (weitere Informationen hierzu finden Sie unter http://en.wikipedia.org/wiki/Network_Time_Protocol). Legen Sie jeden Node so fest, dass seine Uhrzeit mit einem oder mehreren NTP-Servern synchronisiert wird, vorzugsweise für dieselbe Gruppe von NTP-Servern. Wenn der Zeitversatz an einem Node weiterhin besteht, führen Sie die folgenden Schritte aus, um das Problem zu beheben:

systemctl stop ntpd.service
systemctl stop ceph-mon.target
systemctl start ntpd.service
systemctl start ceph-mon.target

Fragen Sie dann die NTP-Peers ab und prüfen Sie den Zeitversatz mit sudo ntpq -p.

Die Uhren der Ceph Monitors müssen untereinander auf 0,05 Sekunden synchronisiert sein. Weitere Informationen finden Sie in Abschnitt 18.3, „Zeitsynchronisierung der Nodes“.

20.10 Schlechte Cluster-Leistung durch Netzwerkprobleme

Es kann mehrere Gründe dafür geben, dass sich die Cluster-Leistung verschlechtert. Einer davon können Netzwerkprobleme sein. In diesem Fall bemerken Sie möglicherweise, dass der Cluster sein Quorum erreicht, der OSD und die Monitor Nodes offline gehen, die Datenübertragungen lange dauern oder oft versucht wird, die Verbindung neu herzustellen.

Sehen Sie sich die Protokolldateien im Verzeichnis /var/log/ceph an, um zu prüfen, ob sich die Cluster-Leistung aufgrund von Netzwerkproblemen verschlechtert hat.

Konzentrieren Sie sich auf die folgenden Punkte, um Netzwerkprobleme am Cluster zu beheben:

  • Allgemeine Netzwerkdiagnose. Versuchen Sie, mit der Diagnose-Tool-Ausführung net.ping von DeepSea zwischen den Cluster Nodes zu pingen und dadurch zu sehen, ob einzelne Schnittstellen spezifische Schnittstellen erreichen und wie die durchschnittliche Antwortzeit ist. Eine spezifische Antwortzeit, die viel länger ist als die durchschnittliche, wird ebenfalls gemeldet. Beispiel:

    root@master # salt-run net.ping
      Succeeded: 8 addresses from 7 minions average rtt 0.15 ms

    Versuchen Sie, alle Schnittstellen mit der JumboFrame-Aktivierung zu validieren:

    root@master # salt-run net.jumbo_ping
      Succeeded: 8 addresses from 7 minions average rtt 0.26 ms
  • Netzwerkleistungsvergleich. Versuchen Sie, mit der Netzwerkleistungsausführung net.iperf von DeepSee die Node-interne Netzwerkbandbreite zu testen. In einem vorliegenden Cluster Node werden einige iperf-Prozesse (entsprechend der Anzahl von CPU-Kernen) als Server gestartet. Die restlichen Cluster Nodes werden als Clients verwendet, um Netzwerkdatenverkehr zu generieren. Die akkumulierte Bandbreite aller iperf-Prozesse pro Node wird gemeldet. Dies sollte den maximal erreichbaren Netzwerkdurchsatz in allen Cluster Nodes widerspiegeln. Beispiel:

    root@master # salt-run net.iperf cluster=ceph output=full
    192.168.128.1:
        8644.0 Mbits/sec
    192.168.128.2:
        10360.0 Mbits/sec
    192.168.128.3:
        9336.0 Mbits/sec
    192.168.128.4:
        9588.56 Mbits/sec
    192.168.128.5:
        10187.0 Mbits/sec
    192.168.128.6:
        10465.0 Mbits/sec
  • Prüfen Sie die Firewalleinstellungen in den Cluster Nodes. Stellen Sie sicher, dass die von Ceph benötigten Ports/Protokolle nicht blockiert werden. In Abschnitt 18.9, „Firewall-Einstellungen für Ceph“ finden Sie weitere Informationen zu Firewalleinstellungen.

  • Prüfen Sie, ob die Netzwerkhardware wie Netzwerkkarten, Kabel oder Schalter ordnungsgemäß funktionieren.

Tipp
Tipp: Separates Netzwerk

Richten Sie ein separates Netzwerk exklusiv für die Cluster OSD und Monitor Nodes ein, um eine schnelle und sichere Netzwerkkommunikation sicherzustellen.

20.11 /var überfüllt

Der Salt Master speichert standardmäßig die Rückgabe aller Minions für jeden Auftrag in seinem Auftrags-Cache. Im Cache können dann später die Ergebnisse zu früheren Aufträgen nachgesehen werden. Das Cache-Verzeichnis ist standardmäßig /var/cache/salt/master/jobs/.

Jede Auftragsrückgabe von jedem Minion wird in einer einzelnen Datei gespeichert. Im Lauf der Zeit kann dieses Verzeichnis sehr groß werden, abhängig von der Anzahl der veröffentlichten Aufträge und des Werts der Option keep_jobs in der Datei /etc/salt/master. Mit keep_jobs wird festgelegt, wie lange in Stunden (standardmäßig 24) Informationen zu früheren Minion-Aufträgen beibehalten werden.

keep_jobs: 24
Wichtig
Wichtig: keep_jobs nicht auf 0 festlegen

Wenn keep_jobs auf "0" festgelegt wird, dann wird die Auftrags-Cache-Bereinigung niemals durchgeführt, was möglicherweise zu einer vollen Partition führt.

Wenn Sie den Auftrags-Cache deaktivieren möchten, legen Sie job_cache auf "False" fest:

job_cache: False
Tipp
Tipp: Wiederherstellen einer Partition, die aufgrund des Auftrags-Cache voll ist

Wenn die Partition mit Auftrags-Cache-Dateien aufgrund einer falschen keep_jobs-Einstellung voll wird, führen Sie die folgenden Schritte aus, um Speicherplatz freizugeben und die Einstellungen für den Auftrags-Cache zu verbessern:

  1. Stoppen Sie das Salt Master-Gerät:

    root@master # systemctl stop salt-master
  2. Ändern Sie die Salt Master-Konfiguration in Bezug auf den Auftrags-Cache, indem Sie /etc/salt/master bearbeiten:

    job_cache: False
    keep_jobs: 1
  3. Löschen Sie den Salt Master-Auftrags-Cache

    rm -rfv /var/cache/salt/master/jobs/*
  4. Starten Sie den Salt Master-Service:

    root@master # systemctl start salt-master
Diese Seite drucken