cephx
/var/lib/ceph
auf Ceph Monitor NodesIn 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.
So erkennen Sie mögliche bezuglose Journal/WAL/DB-Geräte:
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
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.
Entfernen Sie die bezuglosen Partitionen, die nicht zu Ceph gehören, mit Ihrem bevorzugten Kommando (beispielsweise fdisk
, parted
oder sgdisk
).
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
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
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.
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:
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.
Stoppen Sie alle Clients, die auf den Ceph Cluster zugreifen, insbesondere die Clients, die iSCSI verwenden.
Fahren Sie Ihren Ceph Cluster herunter. Führen Sie in jedem Node Folgendes aus:
root #
systemctl stop ceph.target
Wenn Sie Ceph und SUSE OpenStack Cloud verwenden, stoppen Sie auch die SUSE OpenStack Cloud.
Verifizieren Sie, dass Ihr NTP-Server korrekt eingerichtet ist. Alle chronyd
-Daemons müssen ihre Uhrzeit aus mindestens einer Quelle im lokalen Netzwerk beziehen.
Legen Sie die korrekte Uhrzeit auf Ihrem NTP-Server fest.
Verifizieren Sie, dass NTP ausgeführt wird und ordnungsgemäß funktioniert. Führen Sie in allen Nodes Folgendes aus:
root #
systemctl status chronyd.service
Starten Sie alle Überwachungs-Nodes und verifizieren Sie, dass kein Taktversatz besteht:
root #
systemctl start target
Starten Sie alle OSD Nodes.
Starten Sie sonstige Ceph-Services.
Starten Sie die SUSE OpenStack Cloud, falls vorhanden.
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
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.
/var/lib/ceph
auf Ceph Monitor Nodes #
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.
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.
Salt und DeepSea müssen ordnungsgemäß installiert und funktionsfähig sein.
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.
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_allroot@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.
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:
Wechseln Sie zum Verzeichnis in /var/lib
:
cephadm@mon >
cd /var/lib
Sichern Sie den aktuellen Inhalt des Unterverzeichnisses ceph
:
cephadm@mon >
sudo mv ceph ceph-
Erstellen Sie das Subvolume, hängen Sie es ein und aktualisieren Sie /etc/fstab
:
root@master #
salt 'MONITOR_NODES' state.apply ceph.subvolume
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 . ../cephcephadm@mon >
cd ..cephadm@mon >
rm -rf ./ceph-
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/btrfsroot #
mount -o subvol=@ ROOT_DEVICE /mnt/btrfsroot #
btrfs subvolume create /mnt/btrfs/var/lib/cephroot #
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.
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
:
Beenden Sie die Ausführung der Ceph-Prozesse.
Hängen Sie die OSDs im Node aus.
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 . ../cephcephadm@mon >
cd ..cephadm@mon >
rm -rf ./ceph-
Hängen Sie die OSDs wieder ein.
Starten Sie die Ceph Daemons neu.
Weitere Informationen zur manuellen Einrichtung finden Sie in der Datei /srv/salt/ceph/subvolume/README.md
auf dem Salt Master Node.
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.
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.
libvirt
-Datenträgern im Ceph Cluster #
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.
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:
Wenn Sie kein Festplatten-Image für Xen vorbereitet haben, erstellen sie ein neues Image:
cephadm@adm >
rbd create myimage --size 8000 --pool mypool
Listen Sie die Images im Pool mypool
auf und prüfen Sie, ob das neue Image vorhanden ist:
cephadm@adm >
rbd list mypool
Erstellen Sie ein neues Blockgerät, indem Sie das Image myimage
zum Kernel-Modul rbd
zuordnen:
cephadm@adm >
rbd map --pool mypool myimage
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
cephadm
rbd map --pool rbd myimage --id admin --keyfile /path/to/file
Listen Sie alle zugeordneten Geräte auf:
rbd showmapped
id pool image snap device
0 mypool myimage - /dev/rbd0
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' ]
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
› › › bearbeitet.Nachfolgend sehen Sie eine Liste der für Ceph relevanten Services und Nummern der Ports, die diese normalerweise verwenden:
Aktivieren Sie den
-Service oder Port 6789 (TCP).Aktivieren Sie den
-Service oder die Ports 6800-7300 (TCP).Öffnen Sie Port 3260 (TCP).
Ö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 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“.
Öffnen Sie Port 80 für HTTP und Port 443 für HTTPS (TCP).
Öffnen Sie Port 22 (TCP).
Öffnen Sie Port 123 (UDP).
Öffnen Sie Port 4505 und Port 4506 (TCP).
Öffnen Sie Port 3000 (TCP).
Öffnen Sie Port 9100 (TCP).
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
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
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:
Hersteller/Festplatten-Controller | Werkzeug |
---|---|
HPE SmartArray | hpssacli |
LSI MegaRAID | storcli |
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 onroot #
salt-run disk_led.device srv16.ceph sdd ident offroot #
salt-run disk_led.device srv16.ceph sdd fault onroot #
salt-run disk_led.device srv16.ceph sdd fault off
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:
Nehmen Sie die erforderlichen Änderungen an /srv/pillar/ceph/disk_led.sls
auf dem Salt Master Node vor.
Prüfen Sie, ob die Änderungen fehlerfrei in die Pillar-Daten übernommen wurden:
root #
salt 'SALT MASTER*' pillar.get disk_led
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