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

18 Hinweise und Tipps

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.

18.1 Anpassen des Scrubbings

Ceph führt standardmäßig täglich ein Light Scrubbing und wöchentlich ein Deep Scrubbing durch (Detailinformationen hierzu finden Sie in Abschnitt 6.5, „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

18.2 Stoppen von OSDs ohne erneuten Ausgleich

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

root@minion > ceph osd unset noout

18.3 Zeitsynchronisierung der Nodes

Für Ceph ist eine präzise Zeitsynchronisierung zwischen bestimmten Nodes erforderlich. Sie sollten einen Node mit Ihrem NTP-Server einrichten. Auch wenn es möglich ist, alle ntpd-Instanzen auf einen öffentlichen Remote-Zeitserver zu verweisen, ist dies bei Ceph nicht zu empfehlen. 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 alle ziemlich weit entfernt sind. 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).

Verwenden Sie daher einen einzelnen Rechner als NTP-Server für den gesamten Cluster. Die ntpd-Instanz Ihres NTP-Servers kann dann auf den (öffentlichen) Remote-NTP-Server verweisen oder eine eigene Zeitquelle heranziehen. Die ntpd-Instanzen in allen Nodes werden dann zu diesem lokalen Server verwiesen. Diese Lösung bietet einige Vorteile, wie die Eliminierung von unnötigem Netzwerkdatenverkehr und Taktversatz sowie die Reduzierung der Last für öffentliche NTP-Server. 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 18.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:

    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 ntpd-Daemons müssen Ihre Uhrzeit aus einer oder mehreren Quellen 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:

    status ntpd.service

    oder

    ntpq -p
  6. Starten Sie alle Überwachungs-Nodes und verifizieren Sie, dass kein Taktversatz besteht:

    systemctl start target
  7. Starten Sie alle OSD Nodes.

  8. Starten Sie sonstige Ceph-Services.

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

18.4 Prüfung auf nicht ausgeglichene Datenschreibvorgänge

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.

18.5 Btrfs Sub-Volume für /var/lib/ceph

SUSE Linux Enterprise wird standardmäßig auf einer Btrfs-Partition installiert. Das Verzeichnis /var/lib/ceph sollte von Btrfs-Snapshots und Rollbacks ausgeschlossen werden, insbesondere wenn ein MON im Node ausgeführt wird. DeepSea bietet fs-Ausführungsprogramme, die ein Sub-Volume für diesen Pfad einrichten.

18.5.1 Anforderungen für die neue Installation

Wenn Sie den Cluster zum ersten Mal einrichten, müssen vor Verwendung des DeepSea-Ausführungsprogramms die folgenden Anforderungen erfüllt sein:

  • Salt und DeepSea sind ordnungsgemäß installiert und funktionieren entsprechend der Vorgaben in dieser Dokumentation.

  • salt-run state.orch ceph.stage.0 wurde aufgerufen, um alle Salt- und DeepSea-Module mit den Minions zu synchronisieren.

  • Ceph ist noch nicht installiert, daher wurde "ceph.stage.3" noch nicht ausgeführt und /var/lib/ceph ist noch nicht vorhanden.

18.5.2 Anforderungen für die bestehende Installation

Wenn Ihr Cluster bereits installiert ist, müssen vor Verwendung des DeepSea-Ausführungsprogramms die folgenden Anforderungen erfüllt sein:

  • Die Nodes werden auf SUSE Enterprise Storage 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.

18.5.3 Automatische Einrichtung

  • Führen Sie am Salt Master Folgendes aus:

    root@master # salt-run state.orch ceph.migrate.subvolume

    In Nodes ohne Verzeichnis /var/lib/ceph wird dadurch bei jeweils einem Node:

    • /var/lib/ceph als ein @/var/lib/ceph Btrfs-Sub-Volume erstellt.

    • das neue Sub-Volume eingehängt und /etc/fstab entsprechend aktualisiert.

    • eine Kopie beim Schreibvorgang für /ceph deaktiviert.

    In Nodes mit Ceph-Installation wird/werden dadurch bei jeweils einem Node:

    • die Ausführung der Ceph-Vorgänge beendet.

    • die OSDs im Node ausgehängt.

    • das @/var/lib/ceph Btrfs-Sub-Volume erstellt und die bestehenden /var/lib/ceph Daten migriert.

    • das neue Sub-Volume eingehängt und /etc/fstab entsprechend aktualisiert.

    • eine Kopie beim Schreibvorgang für /var/lib/ceph/* deaktiviert und /var/lib/ceph/osd/* weggelassen.

    • die OSDs neu eingehängt.

    • die Ceph-Daemons neu gestartet.

18.5.4 Manuelle Einrichtung

Hierzu wird das neue fs-Ausführungsprogramm verwendet.

  1. Es prüft den Zustand von /var/lib/ceph in allen Nodes und gibt Vorschläge zur weiteren Vorgehensweise aus:

    root@master # salt-run fs.inspect_var

    Dadurch wird eines der folgenden Kommandos ausgegeben:

    salt-run fs.create_var
    salt-run fs.migrate_var
    salt-run fs.correct_var_attrs
  2. Führen Sie das Kommando aus, das im vorigen Schritt ausgegeben wurde.

    Falls in einem der Nodes ein Fehler auftritt, wird die Ausführung für andere Nodes ebenfalls gestoppt und das Ausführungsprogramm versucht, die vorgenommenen Änderungen zurückzusetzen. Sehen Sie in den Protokolldateien zu den Minions nach, welches Problem aufgetreten ist. Das Ausführungsprogramm kann erneut ausgeführt werden, nachdem das Problem behoben wurde.

Das Kommando salt-run fs.help erstellt eine Liste aller Ausführungsprogramm- und Modulkommandos für das fs-Modul.

18.6 Erhöhen der Dateideskriptoren

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.

18.7 Wie die bestehenden Partitionen für OSDs und OSD-Journale verwendet werden

Wichtig
Wichtig

In diesem Abschnitt wird ein anspruchsvolles Thema beschrieben, mit dem sich nur Speicherexperten und Entwickler befassen sollten. Es wird hauptsächlich dann relevant, wenn vom Standard abweichende OSD-Journalgrößen verwendet werden. Wenn die Größe der Partition kleiner als 10 GB beträgt, wird das anfängliche Gewicht auf 0 gerundet. Da aus diesem Grund keine Daten darauf platziert werden, sollten Sie deren Gewicht erhöhen. Wir übernehmen keine Verantwortung für überfüllte Journale.

Wenn Sie bestehende Festplattenpartitionen als OSD Node verwenden müssen, müssen die Partitionen für das OSD-Journal und die Daten in einer GPT-Partitionstabelle vorhanden sein.

Sie müssen für die OSD-Partitionen den korrekten Partitionstyp festlegen, sodass udev sie korrekt erkennt und ihre Eigentümerschaft auf ceph:ceph festlegt.

Führen Sie beispielsweise Folgendes aus, um den Partitionstyp für die Journalpartition /dev/vdb1 und die Datenpartition /dev/vdb2 festzulegen:

sudo sgdisk --typecode=1:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/vdb
sudo sgdisk --typecode=2:4fbd7e29-9d25-41b8-afd0-062c0ceff05d /dev/vdb
Tipp
Tipp

Die Typen der Ceph-Partitionstabellen sind in /usr/lib/udev/rules.d/95-ceph-osd.rules aufgeführt:

cat /usr/lib/udev/rules.d/95-ceph-osd.rules
# OSD_UUID
ACTION=="add", SUBSYSTEM=="block", \
  ENV{DEVTYPE}=="partition", \
  ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \
  OWNER:="ceph", GROUP:="ceph", MODE:="660", \
  RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name"
ACTION=="change", SUBSYSTEM=="block", \
  ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \
  OWNER="ceph", GROUP="ceph", MODE="660"

# JOURNAL_UUID
ACTION=="add", SUBSYSTEM=="block", \
  ENV{DEVTYPE}=="partition", \
  ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \
  OWNER:="ceph", GROUP:="ceph", MODE:="660", \
  RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name"
ACTION=="change", SUBSYSTEM=="block", \
  ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \
  OWNER="ceph", GROUP="ceph", MODE="660"
[...]

18.8 Integration in Virtualisierungssoftware

18.8.1 Speichern von KVM-Datenträgern im Ceph Cluster

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 17, Ceph als Back-End für die QEMU KVM-Instanz.

18.8.2 Speichern von libvirt-Datenträgern im Ceph Cluster

Auf ähnliche Weise wie KVM (Informationen hierzu finden Sie in Abschnitt 18.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 16, Verwenden von libvirt mit Ceph.

18.8.3 Speichern von Xen-Datenträgern im Ceph Cluster

Eine Methode zum Speichern von Xen-Datenträgern mit Ceph ist die Verwendung von libvirt wie in Kapitel 16, 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:

    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:

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

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

    sudo rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

    oder

    sudo rbd 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' ]

18.9 Firewall-Einstellungen für Ceph

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@master # 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 14.2.3, „Ändern der standardmäßigen NFS Ganesha Ports“.

Apache-basierte Services, wie openATTIC, 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).

18.10 Testen der Netzwerkleistung

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

18.11 Austauschen der Speicherfestplatte

Der Austausch einer Speicherfestplatte in einem Ceph Cluster ist während des Betriebs des Clusters möglich. Durch den Austausch wird vorübergehend die Datenübertragung erhöht.

Wenn die Festplatte vollständig ausfällt, muss Ceph mindestens dieselbe Anzahl von Daten erneut schreiben, wie es die Kapazität der ausgefallenen Festplatte zulässt. Wenn die Festplatte vollständig evakuiert und dann erneut hinzugefügt wird, um einen Verlust der Redundanz während des Vorgangs zu vermeiden, wird die Anzahl der neu geschriebenen Daten doppelt so hoch. Wenn die neue Festplatte eine andere Größe aufweist als die ersetzte Festplatte, dann werden einige zusätzliche Daten erneut verteilt, um die Auslastung auf alle OSDs auszugleichen.

Diese Seite drucken