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

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.

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: 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.

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: Ä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.

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

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.

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

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

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.

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:

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

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:

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: 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:

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