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

25 Hinweise und Tipps Edit source

In diesem Kapitel finden Sie Informationen, die Ihnen dabei helfen, die Leistung Ihres Ceph Clusters zu verbessern. Außerdem erhalten Sie Tipps zum Einrichten des Clusters.

25.1 Erkennen vom bezuglosen Partitionen Edit source

So erkennen Sie mögliche bezuglose Journal/WAL/DB-Geräte:

  1. Wählen Sie das Gerät, auf dem sich möglicherweise bezuglose Partitionen befinden, und speichern Sie die Liste dieser Partitionen in eine Datei:

    root@minion > ls /dev/sdd?* > /tmp/partitions
  2. Führen Sie readlink gegen alle "block.wal"-, "block.db"- und „journal“-Geräte aus und vergleichen Sie die Ausgabe mit der vorher gespeicherten Liste der Partitionen:

    root@minion > readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \
     | sort | comm -23 /tmp/partitions -

    Die Ausgabe stellt die Liste der Partitionen dar, die nicht von Ceph genutzt werden.

  3. Entfernen Sie die bezuglosen Partitionen, die nicht zu Ceph gehören, mit Ihrem bevorzugten Kommando (beispielsweise fdisk, parted oder sgdisk).

25.2 Anpassen des Scrubbings Edit source

Ceph führt standardmäßig täglich ein Light Scrubbing und wöchentlich ein Deep Scrubbing durch (Detailinformationen hierzu finden Sie in Abschnitt 9.6, „Scrubbing“). Beim Light Scrubbing werden die Objektgrößen und Prüfsummen geprüft, um sicherzustellen, dass Placement Groups dieselben Objektdaten speichern. Beim Deep Scrubbing wird der Inhalt eines Objekt mit dem Inhalt seiner Reproduktionen verglichen, um sicherzustellen, dass die tatsächlichen Inhalte identisch sind. Die Überprüfung der Datenintegrität führt zu einer höheren E/A-Last am Cluster während des Scrubbing-Vorgangs.

Mit den Standardeinstellungen könnten Ceph OSDs ein Scrubbing zu unpassenden Zeiten durchführen, wie zum Beispiel in Zeiten mit sehr hoher Last. Kunden erfahren Latenz und schlechte Leistung, wenn zwischen den Scrubbing-Operationen und den Operationen der Kunden ein Konflikt besteht. Ceph bietet verschiedene Scrubbing-Einstellungen, die das Scrubbing auf Zeiten mit geringerer Last außerhalb der Spitzenzeiten beschränken.

Wenn die Cluster-Last tagsüber hoch und nachts gering ist, sollten Sie das Scrubbing auf die Nachtstunden beschränken, wie zum Beispiel zwischen 23 Uhr und 6 Uhr:

[osd]
osd_scrub_begin_hour = 23
osd_scrub_end_hour = 6

Wenn die Zeitbeschränkung keine effiziente Methode zum Festlegen eines Scrubbing-Zeitplans ist, sollten Sie die Option osd_scrub_load_threshold verwenden. Der Standardwert ist 0,5, doch der Wert könnte für Bedingungen mit geringer Last geändert werden:

[osd]
osd_scrub_load_threshold = 0.25

25.3 Stoppen von OSDs ohne erneuten Ausgleich Edit source

Sie möchten möglicherweise die OSDS regelmäßig zur Wartung stoppen. Legen Sie den Cluster zunächst auf noout fest, wenn Sie nicht möchten, dass CRUSH automatisch den Cluster ausgleicht, um enorme Datenübertragungen zu vermeiden:

root@minion > ceph osd set noout

Wenn der Cluster auf noout festgelegt ist, können Sie zu Beginn die OSDs in der Fehlerdomäne stoppen, die gewartet werden muss:

root@minion > systemctl stop ceph-osd@OSD_NUMBER.service

Weitere Informationen finden Sie in Abschnitt 5.1.2, „Starten, Stoppen und Neustarten einzelner Services“.

Starten Sie die OSDs nach der Wartung erneut:

root@minion > systemctl start ceph-osd@OSD_NUMBER.service

Entfernen Sie die Cluster-Einstellung noout nach dem Starten der OSD Services:

cephadm@adm > ceph osd unset noout

25.4 Zeitsynchronisierung der Nodes Edit source

Für Ceph ist eine präzise Zeitsynchronisierung zwischen allen Nodes erforderlich.

Es wird empfohlen, alle Ceph Cluster Nodes mit mindestens drei zuverlässigen Zeitquellen zu synchronisieren, die sich im internen Netzwerk befinden. Die internen Zeitquellen können auf einen öffentlichen Zeitserver verweisen oder eine eigene Zeitquelle umfassen.

Wichtig
Wichtig: Öffentliche Zeitserver

Synchronisieren Sie nicht alle Ceph Cluster Nodes direkt mit öffentlichen Remote-Zeitservern. Bei einer derartigen Konfiguration hat jeder Node im Cluster einen eigenen NTP-Daemon. Diese kommunizieren kontinuierlich über das Internet mit drei oder vier Zeitservern, die unter Umständen leicht abweichende Zeitangaben zurückgeben. Bei dieser Lösung ist mit einem hohen Maß an Latenzschwankung zu rechnen, was es schwierig oder gar unmöglich macht, die Uhrenfehler unter 0,05 Sekunden zu halten (was wiederum für die Ceph Monitors erforderlich ist).

Detailinformationen zur Einrichtung der NTP-Server finden Sie im SUSE Linux Enterprise Server-Verwaltungshandbuch.

Gehen Sie folgendermaßen vor, um die Zeit an Ihrem Cluster zu ändern:

Wichtig
Wichtig: Einstellen der Uhrzeit

Sie kommen möglicherweise hin und wieder in eine Situation, in der Sie die Uhrzeit zurücksetzen müssen, beispielsweise wenn die Sommerzeit zur Standardzeit umgestellt wird. Es ist nicht empfehlenswert, die Uhrzeit für einen längeren Zeitraum als den Ausfall des Clusters zurückzustellen. Die Uhrzeit vorzustellen, verursacht dagegen keine Probleme.

Prozedur 25.1: Zeitsynchronisierung am Cluster
  1. Stoppen Sie alle Clients, die auf den Ceph Cluster zugreifen, insbesondere die Clients, die iSCSI verwenden.

  2. Fahren Sie Ihren Ceph Cluster herunter. Führen Sie in jedem Node Folgendes aus:

    root # systemctl stop ceph.target
    Anmerkung
    Anmerkung

    Wenn Sie Ceph und SUSE OpenStack Cloud verwenden, stoppen Sie auch die SUSE OpenStack Cloud.

  3. Verifizieren Sie, dass Ihr NTP-Server korrekt eingerichtet ist. Alle chronyd-Daemons müssen ihre Uhrzeit aus mindestens einer Quelle im lokalen Netzwerk beziehen.

  4. Legen Sie die korrekte Uhrzeit auf Ihrem NTP-Server fest.

  5. Verifizieren Sie, dass NTP ausgeführt wird und ordnungsgemäß funktioniert. Führen Sie in allen Nodes Folgendes aus:

    root # systemctl status chronyd.service
  6. Starten Sie alle Überwachungs-Nodes und verifizieren Sie, dass kein Taktversatz besteht:

    root # systemctl start target
  7. Starten Sie alle OSD Nodes.

  8. Starten Sie sonstige Ceph-Services.

  9. Starten Sie die SUSE OpenStack Cloud, falls vorhanden.

25.5 Prüfung auf nicht ausgeglichene Datenschreibvorgänge Edit source

Wenn Daten gleichmäßig verteilt an OSDs geschrieben werden, ist der Cluster ausgeglichen. Jedem OSD in einem Cluster ist ein eigenes Gewicht zugewiesen. Das Gewicht ist eine relative Zahl und informiert Ceph darüber, wie viele der Daten auf den jeweiligen OSD geschrieben werden sollten. Je höher das Gewicht, desto mehr Daten werden geschrieben. Wenn ein OSD kein Gewicht aufweist, werden keine Daten an ihn geschrieben. Wenn das Gewicht eines OSD relativ hoch ist im Vergleich zu anderen OSDs, wird ein Großteil der Daten an diesen OSD geschrieben, wodurch der Cluster unausgeglichen wird.

Unausgeglichene Cluster weisen eine schlechte Leistung auf. Falls ein OSD mit einem hohen Gewicht plötzlich abstürzt, müssen sehr viele Daten zu anderen OSDs verschoben werden, was den Cluster ebenfalls verlangsamt.

Um dies zu vermeiden, sollten sie regelmäßig die OSDs auf die Menge der geschriebenen Daten hin überprüfen. Wenn die Menge zwischen 30 und 50 Prozent der Kapazität einer Gruppe von OSDs, die durch einen Regelsatz angegeben ist, ausmacht, müssen Sie das Gewicht der OSDs neu festlegen. Prüfen Sie, welche der einzelnen Festplatten schneller gefüllt werden als andere (oder allgemein langsamer sind) und reduzieren Sie deren Gewicht. Das gleiche gilt für OSDs, an die nicht genug Daten geschrieben werden. Erhöhen Sie deren Gewicht, damit Ceph mehr Daten an sie schreibt. Im folgenden Beispiel ermitteln Sie das Gewicht eines OSDs mit ID 13 und ändern sein Gewicht von 3 auf 3,05:

$ ceph osd tree | grep osd.13
 13  3                   osd.13  up  1

 $ ceph osd crush reweight osd.13 3.05
 reweighted item id 13 name 'osd.13' to 3.05 in crush map

 $ ceph osd tree | grep osd.13
 13  3.05                osd.13  up  1
Tipp
Tipp: Ändern des OSD-Gewichts entsprechend der Auslastung

Mit dem Kommando ceph osd reweight-by-utilization threshold wird der Vorgang der Reduzierung des Gewichts von übermäßig ausgelasteten OSDs automatisiert. Standardmäßig wird das Gewicht von OSDs verringert, die 120 % der durchschnittlichen Auslastung erreicht haben. Wenn Sie jedoch einen Schwellwert („threshold“) hinzufügen, wird stattdessen dieser Prozentsatz verwendet.

25.6 Btrfs-Subvolume für /var/lib/ceph auf Ceph Monitor Nodes Edit source

SUSE Linux Enterprise wird standardmäßig auf einer Btrfs-Partition installiert. Ceph Monitors speichern ihren Status und ihre Datenbank im Verzeichnis /var/lib/ceph. Damit ein Ceph Monitor nicht durch ein System-Rollback eines früheren Snapshots beschädigt wird, erstellen Sie ein Btrfs-Subvolume für /var/lib/ceph. Mithilfe eines dedizierten Subvolumes werden die Monitor-Daten bei Snapshots des Root-Subvolumes ausgeschlossen.

Tipp
Tipp

Erstellen Sie das Subvolume /var/lib/ceph, bevor Sie DeepSea-Phase 0 ausführen, da in Phase 0 die Ceph-spezifischen Pakete installiert werden und das Verzeichnis /var/lib/ceph erstellt wird.

DeepSea-Phase 3 überprüft dann, ob @/var/lib/ceph ein Btrfs-Subvolume ist, und schlägt fehl, falls dies ein normales Verzeichnis ist.

25.6.1 Anforderungen Edit source

25.6.1.1 Neue Implementierungen Edit source

Salt und DeepSea müssen ordnungsgemäß installiert und funktionsfähig sein.

25.6.1.2 Vorhandene Implementierungen Edit source

Falls Ihr Cluster bereits installiert ist, müssen die folgenden Voraussetzungen erfüllt werden:

  • Die Nodes werden auf SUSE Enterprise Storage 6 aufgerüstet und der Cluster wird von DeepSea gesteuert.

  • Der Ceph Cluster ist aktiv und fehlerfrei.

  • Beim Upgrade wurden die Salt- und DeepSea-Module mit allen Minion Nodes synchronisiert.

25.6.2 Schritte bei einer neuen Cluster-Implementierung Edit source

25.6.2.1 Vor Ausführung der DeepSea-Phase 0 Edit source

Wenden Sie vor der Ausführung von DeepSea-Phase 0 die folgenden Kommandos auf jeden Salt Minion an, der als Ceph Monitor fungieren soll:

root@master # salt 'MONITOR_NODES' saltutil.sync_all
root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume

Mit dem Kommando ceph.subvolume wird:

  • /var/lib/ceph als ein Btrfs-Subvolume für @/var/lib/ceph erstellt.

  • das neue Subvolume eingehängt und /etc/fstab entsprechend aktualisiert.

25.6.2.2 Validierung in DeepSea-Phase 3 schlägt fehl Edit source

Falls Sie die in Abschnitt 25.6.2.1, „Vor Ausführung der DeepSea-Phase 0“ aufgeführten Kommandos nicht vor Ausführung der Phase 0 ausgeführt hatten, ist das Unterverzeichnis /var/lib/ceph bereits vorhanden, sodass die Validierung in DeepSea-Phase 3 fehlschlägt. So konvertieren Sie es in ein Subvolume:

  1. Wechseln Sie zum Verzeichnis in /var/lib:

    cephadm@mon > cd /var/lib
  2. Sichern Sie den aktuellen Inhalt des Unterverzeichnisses ceph:

    cephadm@mon > sudo mv ceph ceph-
  3. Erstellen Sie das Subvolume, hängen Sie es ein und aktualisieren Sie /etc/fstab:

    root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume
  4. Wechseln Sie zum Sicherungs-Unterverzeichnis, synchronisieren Sie dessen Inhalt mit dem neuen Subvolume und entfernen Sie es dann:

    cephadm@mon > cd /var/lib/ceph-
    cephadm@mon > rsync -av . ../ceph
    cephadm@mon > cd ..
    cephadm@mon > rm -rf ./ceph-

25.6.3 Schritte bei einem Cluster-Upgrade Edit source

In SUSE Enterprise Storage 5.5 befindet sich das Verzeichnis /var nicht in einem Btrfs-Subvolume, sondern dessen Unterordner (beispielsweise /var/log oder /var/cache) sind Btrfs-Subvolumes unter „@“. Beim Erstellen von @/var/lib/ceph-Subvolumes müssen Sie zunächst das Subvolume „@“ einhängen (es wird nicht standardmäßig eingehängt) und das Subvolume @/var/lib/ceph darunter erstellen.

Die folgenden Beispielkommandos verdeutlichen diesen Ablauf:

root # mkdir -p /mnt/btrfs
root # mount -o subvol=@ ROOT_DEVICE /mnt/btrfs
root # btrfs subvolume create /mnt/btrfs/var/lib/ceph
root # umount /mnt/btrfs

Zu diesem Zeitpunkt wird das Subvolume @/var/lib/ceph erstellt und Sie können den Vorgang gemäß den Anweisungen in Abschnitt 25.6.2, „Schritte bei einer neuen Cluster-Implementierung“ fortsetzen.

25.6.4 Manuelle Einrichtung Edit source

Die automatische Einrichtung des Btrfs-Subvolumes @/var/lib/ceph auf den Ceph Monitor Nodes eignet sich nicht für alle Situationen. So migrieren Sie Ihr Verzeichnis /var/lib/ceph zu einem Subvolume @/var/lib/ceph:

  1. Beenden Sie die Ausführung der Ceph-Prozesse.

  2. Hängen Sie die OSDs im Node aus.

  3. Wechseln Sie zum Sicherungs-Unterverzeichnis, synchronisieren Sie dessen Inhalt mit dem neuen Subvolume und entfernen Sie es dann:

    cephadm@mon > cd /var/lib/ceph-
    cephadm@mon > rsync -av . ../ceph
    cephadm@mon > cd ..
    cephadm@mon > rm -rf ./ceph-
  4. Hängen Sie die OSDs wieder ein.

  5. Starten Sie die Ceph Daemons neu.

25.6.5 Weiterführende Informationen Edit source

Weitere Informationen zur manuellen Einrichtung finden Sie in der Datei /srv/salt/ceph/subvolume/README.md auf dem Salt Master Node.

25.7 Erhöhen der Dateideskriptoren Edit source

Bei OSD-Daemons sind die Lese/Schreib-Operationen entscheidend für den Ausgleich im Ceph Cluster. Sie müssen oft viele Dateien gleichzeitig zum Lesen und Schreiben offen halten. Auf Betriebssystemebene wird die maximale Anzahl von gleichzeitig offenen Dateien als „maximale Anzahl der Dateideskriptoren“ bezeichnet.

Um zu verhindern, dass den OSDs die Dateideskriptoren ausgehen, überschreiben Sie den Standardwert des Betriebssystems und geben Sie die Anzahl in /etc/ceph/ceph.conf an. Beispiel:

max_open_files = 131072

Nach dem Ändern von max_open_files müssen Sie den OSD-Service im relevanten Ceph Node neu starten.

25.8 Integration in Virtualisierungssoftware Edit source

25.8.1 Speichern von KVM-Datenträgern im Ceph Cluster Edit source

Sie können ein Datenträger-Image für KVM-betriebene virtuelle Maschinen erstellen, diese in einem Ceph Pool speichern, optional den Inhalt eines bestehenden Image zu diesem Image konvertieren und dann die virtuelle Maschine mit qemu-kvm ausführen und das im Cluster gespeicherte Datenträger-Image dazu verwenden. Weitere Informationen hierzu finden Sie in Kapitel 24, Ceph als Back-End für die QEMU KVM-Instanz.

25.8.2 Speichern von libvirt-Datenträgern im Ceph Cluster Edit source

Auf ähnliche Weise wie KVM (Informationen hierzu finden Sie in Abschnitt 25.8.1, „Speichern von KVM-Datenträgern im Ceph Cluster“) können Sie Ceph zum Speichern virtueller Maschinen verwenden, die über libvirt betrieben werden. Der Vorteil besteht darin, dass Sie jede beliebige von libvirt unterstützte Virtualisierungslösung ausführen können, wie etwa KVM, Xen oder LXC. Weitere Informationen finden Sie in Kapitel 23, Verwenden von libvirt mit Ceph.

25.8.3 Speichern von Xen-Datenträgern im Ceph Cluster Edit source

Eine Methode zum Speichern von Xen-Datenträgern mit Ceph ist die Verwendung von libvirt wie in Kapitel 23, Verwenden von libvirt mit Ceph beschrieben.

Alternativ kann Xen zur direkten Kommunikation mit dem rbd-Blockgerät eingerichtet werden:

  1. Wenn Sie kein Festplatten-Image für Xen vorbereitet haben, erstellen sie ein neues Image:

    cephadm@adm > rbd create myimage --size 8000 --pool mypool
  2. Listen Sie die Images im Pool mypool auf und prüfen Sie, ob das neue Image vorhanden ist:

    cephadm@adm > rbd list mypool
  3. Erstellen Sie ein neues Blockgerät, indem Sie das Image myimage zum Kernel-Modul rbd zuordnen:

    cephadm@adm > rbd map --pool mypool myimage
    Tipp
    Tipp: Benutzername und -authentifizierung

    Geben Sie einen Benutzernamen mit --id user-name an. Wenn Sie die cephx-Authentifizierung nutzen, müssen Sie außerdem ein Geheimnis angeben. Es kann von einem Schlüsselbund stammen oder aus einer Datei, die das Geheimnis enthält:

    cephadm@adm > rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

    oder

    cephadmrbd map --pool rbd myimage --id admin --keyfile /path/to/file
  4. Listen Sie alle zugeordneten Geräte auf:

    rbd showmapped
     id pool   image   snap device
     0  mypool myimage -    /dev/rbd0
  5. Nun können Sie Xen so konfigurieren, dass es dieses Gerät als Festplatte zum Ausführen einer virtuellen Maschine verwendet. Beispielsweise kann die folgende Zeile zur Domänenkonfigurationsdatei vom Typ xl hinzugefügt werden:

    disk = [ '/dev/rbd0,,sda', '/dev/cdrom,,sdc,cdrom' ]

25.9 Firewall-Einstellungen für Ceph Edit source

Warnung
Warnung: DeepSea-Phasen werden bei aktiver Firewall nicht durchgeführt

Die DeepSea-Phasen zur Bereitstellung werden nicht ausgeführt, wenn die Firewall aktiv ist (und sogar konfiguriert). Um die Phasen korrekt abzuschließen, müssen Sie entweder die Firewall durch Ausführen von

root # systemctl stop SuSEfirewall2.service

ausschalten oder die Option FAIL_ON_WARNING in /srv/pillar/ceph/stack/global.yml auf „False“ festlegen:

FAIL_ON_WARNING: False

Wir empfehlen, die Netzwerk-Cluster-Kommunikation mit SUSE Firewall. Deren Konfiguration wird durch Auswahl von YaST › Sicherheit und Benutzer › Firewall › Zulässige Dienste bearbeitet.

Nachfolgend sehen Sie eine Liste der für Ceph relevanten Services und Nummern der Ports, die diese normalerweise verwenden:

Ceph Monitor

Aktivieren Sie den Ceph MON-Service oder Port 6789 (TCP).

Ceph OSD oder Metadata Server

Aktivieren Sie den Ceph OSD/MDS-Service oder die Ports 6800-7300 (TCP).

iSCSI Gateway

Öffnen Sie Port 3260 (TCP).

Object Gateway

Öffnen Sie den Port, an dem die Object Gateway-Kommunikation stattfindet. Er wird in /etc/ceph.conf in der Zeile beginnend mit rgw frontends = festgelegt. Die Standardeinstellung ist 80 für HTTP und 443 für HTTPS (TCP).

NFS Ganesha

NFS Ganesha verwendet standardmäßig die Ports 2049 (NFS-Service, TCP) und 875 (rquota-Unterstützung, TCP). Weitere Informationen zum Ändern der standardmäßigen Ports für NFS Ganesha finden Sie in Abschnitt 21.2.1.4, „Ändern der standardmäßigen NFS Ganesha Ports“.

Apache-basierte Services, wie SMT oder SUSE Manager

Öffnen Sie Port 80 für HTTP und Port 443 für HTTPS (TCP).

SSH

Öffnen Sie Port 22 (TCP).

NTP

Öffnen Sie Port 123 (UDP).

Salt

Öffnen Sie Port 4505 und Port 4506 (TCP).

Grafana

Öffnen Sie Port 3000 (TCP).

Prometheus

Öffnen Sie Port 9100 (TCP).

25.10 Testen der Netzwerkleistung Edit source

Zum Testen der Netzwerkleistung stellt das DeepSea net-Ausführungsprogramm die folgenden Kommandos zur Verfügung.

  • Ein einfaches Ping an alle Nodes:

    root@master # salt-run net.ping
    Succeeded: 9 addresses from 9 minions average rtt 1.35 ms
  • Ein Jumbo-Ping an alle Nodes:

    root@master # salt-run net.jumbo_ping
    Succeeded: 9 addresses from 9 minions average rtt 2.13 ms
  • Ein Bandbreitentest:

    root@master # salt-run net.iperf
    Fastest 2 hosts:
        |_
          - 192.168.58.106
          - 2981 Mbits/sec
        |_
          - 192.168.58.107
          - 2967 Mbits/sec
    Slowest 2 hosts:
        |_
          - 192.168.58.102
          - 2857 Mbits/sec
        |_
          - 192.168.58.103
          - 2842 Mbits/sec
    Tipp
    Tipp: „iperf3“-Prozesse manuell anhalten

    Wenn Sie einen Test mit dem net.iperf-Ausführungsprogramm durchführen, werden die gestarteten „iperf3“-Serverprozesse nach Abschluss eines Tests nicht automatisch angehalten. Mit folgendem Ausführungsprogramm halten Sie die Prozesse an:

    root@master # salt '*' multi.kill_iperf_cmd

25.11 Auffinden physischer Datenträger mithilfe von LED-Leuchten Edit source

In diesem Abschnitt wird die Anpassung der LED-Leuchten an physischen Datenträgern mit libstoragemgmt und/oder mit Drittanbieterwerkzeugen erläutert. Diese Funktion ist unter Umständen nicht für alle Hardwareplattformen verfügbar.

Die Zuordnung eines OSD-Datenträgers zu einem physischen Datenträger kann mit einigen Schwierigkeiten verbunden sein, insbesondere auf Nodes mit hoher Datenträgerdichte. Einige Hardwareumgebungen arbeiten mit LED-Leuchten, die per Software so angepasst werden können, dass sie zu Erkennungszwecken blinken oder eine andere Farbe zeigen. SUSE Enterprise Storage unterstützt diese Funktion über Salt, libstoragemgmt und spezielle Drittanbieterwerkzeuge für die verwendete Hardware. Die Konfiguration für diese Funktion ist im Salt-Pillar /srv/pillar/ceph/disk_led.sls definiert:

root #  cat /srv/pillar/ceph/disk_led.sls
# This is the default configuration for the storage enclosure LED blinking.
# The placeholder {device_file} will be replaced with the device file of
# the disk when the command is executed.
#
# Have a look into the /srv/pillar/ceph/README file to find out how to
# customize this configuration per minion/host.

disk_led:
  cmd:
    ident:
      'on': lsmcli local-disk-ident-led-on --path '{device_file}'
      'off': lsmcli local-disk-ident-led-off --path '{device_file}'
    fault:
      'on': lsmcli local-disk-fault-led-on --path '{device_file}'
      'off': lsmcli local-disk-fault-led-off --path '{device_file}'

Die Standardkonfiguration für disk_led.sls unterstützt die Datenträger-LEDs über die libstoragemgmt-Schicht. libstoragemgmt leistet diese Unterstützung dabei über ein hardwarespezifisches Plugin und über Drittanbieterwerkzeuge. libstoragemgmt kann die LEDs nur dann anpassen, wenn sowohl das libstoragemgmt-Plugin als auch die erforderlichen Drittanbieterwerkzeuge für die Hardware installiert sind.

Unabhängig davon, ob libstoragemgmt vorliegt, müssen die LED-Leuchten ggf. mithilfe von Drittanbieterwerkzeugen angepasst werden. Diese Drittanbieterwerkzeuge werden von verschiedenen Hardwareherstellern angeboten. Einige gängige Hersteller und Werkzeuge:

Tabelle 25.1: Drittanbieter-Speicherwerkzeuge
Hersteller/Festplatten-ControllerWerkzeug
HPE SmartArrayhpssacli
LSI MegaRAIDstorcli

SUSE Linux Enterprise Server umfasst außerdem das Paket ledmon und das Tool ledctl. Dieses Tool eignet sich auch für bestimmte Hardwareumgebungen mit Intel-Speichergehäusen. Die richtige Syntax für dieses Werkzeug lautet:

root #  cat /srv/pillar/ceph/disk_led.sls
disk_led:
  cmd:
    ident:
      'on': ledctl locate='{device_file}'
      'off': ledctl locate_off='{device_file}'
    fault:
      'on': ledctl locate='{device_file}'
      'off': ledctl locate_off='{device_file}'

Wenn Sie unterstützte Hardware nutzen und alle erforderlichen Drittanbieterwerkzeuge vorliegen, können die LEDs mit der folgenden Kommandosyntax auf dem Salt Master Node aktiviert oder deaktiviert werden:

root # salt-run disk_led.device NODE DISK fault|ident on|off

Mit folgendem Kommando aktivieren oder deaktivieren Sie beispielsweise die LED-Erkennung oder Fehlerleuchten unter /dev/sdd auf dem OSD-Node srv16.ceph:

root # salt-run disk_led.device srv16.ceph sdd ident on
root # salt-run disk_led.device srv16.ceph sdd ident off
root # salt-run disk_led.device srv16.ceph sdd fault on
root # salt-run disk_led.device srv16.ceph sdd fault off
Anmerkung
Anmerkung: Gerätebenennung

Der Gerätename im Kommando salt-run muss mit dem von Salt erkannten Namen übereinstimmen. Mit folgendem Kommando rufen Sie diese Namen ab:

root@master # salt 'minion_name' grains.get disks

In zahlreichen Umgebungen muss die Konfiguration /srv/pillar/ceph/disk_led.sls geändert werden, damit die LED-Leuchten für bestimmte Hardwareanforderungen angepasst werden können. Bei einfachen Änderungen reicht es, lsmcli durch ein anderes Werkzeug zu ersetzen oder die Kommandozeilenparameter anzupassen. Bei komplexen Änderungen kann ein externes Skript anstelle des Kommandos lsmcli aufgerufen werden. Sollen Änderungen an /srv/pillar/ceph/disk_led.sls vorgenommen werden, beachten Sie diese Schritte:

  1. Nehmen Sie die erforderlichen Änderungen an /srv/pillar/ceph/disk_led.sls auf dem Salt Master Node vor.

  2. Prüfen Sie, ob die Änderungen fehlerfrei in die Pillar-Daten übernommen wurden:

    root # salt 'SALT MASTER*' pillar.get disk_led
  3. Aktualisieren Sie die Pillar-Daten auf allen Knoten mit:

    root # salt '*' saltutil.pillar_refresh

Es ist möglich, mithilfe eines externen Skripts direkt auf Drittanbieterwerkzeuge zuzugreifen und damit die LED-Leuchten anzupassen. Die folgenden Beispiele zeigen, wie Sie /srv/pillar/ceph/disk_led.sls so anpassen, dass ein externes Skript unterstützt wird, sowie zwei Beispielskripte für HP- und LSI-Umgebungen.

Bearbeitete /srv/pillar/ceph/disk_led.sls, mit der ein externes Skript aufgerufen wird:

root # cat /srv/pillar/ceph/disk_led.sls
disk_led:
  cmd:
    ident:
      'on': /usr/local/bin/flash_led.sh '{device_file}' on
      'off': /usr/local/bin/flash_led.sh '{device_file}' off
    fault:
      'on': /usr/local/bin/flash_led.sh '{device_file}' on
      'off': /usr/local/bin/flash_led.sh '{device_file}' off

Beispielskript, mit dem die LED-Leuchten auf HP-Hardware mit den hpssacli-Dienstprogrammen zum Blinken gebracht werden:

root # cat /usr/local/bin/flash_led_hp.sh
#!/bin/bash
# params:
#   $1 device (e.g. /dev/sda)
#   $2 on|off

FOUND=0
MAX_CTRLS=10
MAX_DISKS=50

for i in $(seq 0 $MAX_CTRLS); do
  # Search for valid controllers
  if hpssacli ctrl slot=$i show summary >/dev/null; then
    # Search all disks on the current controller
    for j in $(seq 0 $MAX_DISKS); do
      if hpssacli ctrl slot=$i ld $j show | grep -q $1; then
        FOUND=1
        echo "Found $1 on ctrl=$i, ld=$j. Turning LED $2."
        hpssacli ctrl slot=$i ld $j modify led=$2
        break;
      fi
    done
    [[ "$FOUND" = "1" ]] && break
  fi
done

Beispielskript, mit dem die LED-Leuchten auf LSI-Hardware mit den storcli-Dienstprogrammen zum Blinken gebracht werden:

root # cat /usr/local/bin/flash_led_lsi.sh
#!/bin/bash
# params:
#   $1 device (e.g. /dev/sda)
#   $2 on|off

[[ "$2" = "on" ]] && ACTION="start" || ACTION="stop"

# Determine serial number for the disk
SERIAL=$(lshw -class disk | grep -A2 $1 | grep serial | awk '{print $NF}')
if [ ! -z "$SERIAL" ]; then
  # Search for disk serial number across all controllers and enclosures
  DEVICE=$(/opt/MegaRAID/storcli/storcli64 /call/eall/sall show all | grep -B6 $SERIAL | grep Drive | awk '{print $2}')
  if [ ! -z "$DEVICE" ]; then
    echo "Found $1 on device $DEVICE. Turning LED $2."
    /opt/MegaRAID/storcli/storcli64 $DEVICE $ACTION locate
  else
    echo "Device not found!"
    exit -1
  fi
else
  echo "Disk serial number not found!"
  exit -1
fi
Diese Seite drucken