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

2 Cluster-Verwaltung mit Salt Edit source

Nach der Bereitstellung eines Ceph Clusters müssen Sie wahrscheinlich gelegentlich einige Änderungen daran vornehmen. Dazu gehört das Hinzufügen oder Entfernen neuer Nodes, Festplatten oder Services. In diesem Kapitel wird erläutert, wie Sie diese Verwaltungsaufgaben erledigen.

2.1 Hinzufügen neuer Cluster Nodes Edit source

Das Verfahren zum Hinzufügen neuer Nodes zum Cluster ist in etwa identisch mit der ersten Bereitstellung eines Cluster Nodes, die im Kapitel 5, Bereitstellen mit DeepSea/Salt erläutert wird:

Tipp
Tipp: Verhindern eines Ausgleichs

Denken Sie beim Hinzufügen eines OSD zum bestehenden Cluster daran, dass der Cluster danach einige Zeit zum Ausgleich benötigt. Fügen Sie alle gewünschten OSDs zur selben Zeit hinzu, um den Zeitraum für den Ausgleich so kurz wie möglich zu halten.

Alternativ können Sie die Option osd crush initial weight = 0 in der ceph.conf-Datei festlegen, bevor Sie die OSDs hinzufügen:

  1. Fügen Sie osd crush initial weight = 0 in /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf ein.

  2. Erstellen Sie die neue Konfiguration auf dem Salt Master Node:

    root@master # salt 'SALT_MASTER_NODE' state.apply ceph.configuration.create
  3. Wenden Sie die neue Konfiguration auf die adressierten OSD-Minions an:

    root@master # salt 'OSD_MINIONS' state.apply ceph.configuration
  4. Sobald die neuen OSDs hinzugefügt wurden, passen Sie deren Gewicht je nach Bedarf mit dem Kommando ceph osd crush reweight an.

  1. Installieren Sie SUSE Linux Enterprise Server 15 SP1 auf dem neuen Node und konfigurieren Sie dessen Netzwerkeinstellung, sodass der Hostname des Salt Masters korrekt aufgelöst wird. Prüfen Sie, ob eine fehlerfreie Verbindung sowohl zu öffentlichen Netzwerken als auch zu Cluster-Netzwerken vorliegt und ob die Zeitsynchronisation ordnungsgemäß konfiguriert ist. Installieren Sie dann das Paket salt-minion:

    root@minion > zypper in salt-minion

    Wenn der Hostname des Salt Masters nicht salt lautet, bearbeiten Sie /etc/salt/minion und fügen Sie Folgendes hinzu:

    master: DNS_name_of_your_salt_master

    Wenn Sie an den oben genannten Konfigurationsdateien Änderungen vorgenommen haben, starten Sie den Service salt.minion neu:

    root@minion > systemctl restart salt-minion.service
  2. Akzeptieren Sie auf dem Salt Master den Salt-Schlüssel des neuen Knotens:

    root@master # salt-key --accept NEW_NODE_KEY
  3. Prüfen Sie, ob /srv/pillar/ceph/deepsea_minions.sls den neuen Salt Minion adressiert, und/oder legen Sie das richtige DeepSea Grain fest. Einzelheiten finden Sie in Abschnitt 5.2.2.1, „Abgleichen des Minion-Namens“ oder Prozedur 5.1, „Ausführen von Bereitstellungsphasen“.

  4. Führen Sie die Vorbereitungsphase durch. In dieser Phase werden die Module und Grains synchronisiert, sodass der neue Minion alle Informationen zur Verfügung stellen kann, die von DeepSea erwartet werden.

    root@master # salt-run state.orch ceph.stage.0
    Wichtig
    Wichtig: Möglicher Neustart der DeepSea-Phase 0

    Wenn der Salt Master nach dem Kernel-Update neu gestartet wurde, müssen Sie die DeepSea-Phase 0 neu starten.

  5. Führen Sie die Ermittlungsphase durch. In dieser Phase werden neue Dateieinträge im Verzeichnis /srv/pillar/ceph/proposals geschrieben, wo Sie relevante YML-Dateien bearbeiten können:

    root@master # salt-run state.orch ceph.stage.1
  6. Ändern Sie optional /srv/pillar/ceph/proposals/policy.cfg, falls der neu hinzugefügte Host nicht dem bestehenden Benennungsschema entspricht. Detaillierte Informationen finden Sie im Abschnitt 5.5.1, „Die Datei policy.cfg.

  7. Führen Sie die Konfigurationsphase durch. In dieser Phase wird alles unter /srv/pillar/ceph gelesen und der Pillar wird entsprechend aktualisiert:

    root@master # salt-run state.orch ceph.stage.2

    Im Pillar sind Daten gespeichert, auf die Sie mit dem folgenden Kommando zugreifen:

    root@master # salt target pillar.items
    Tipp
    Tipp: Bearbeiten des OSD-Layouts

    Soll das standardmäßige OSD-Layout bearbeitet und die DriveGroups-Konfiguration geöffnet werden, befolgen Sie die Anweisungen in Abschnitt 5.5.2, „DriveGroups“.

  8. Die Konfigurations- und Bereitstellungsphasen umfassen neu hinzugefügte Nodes:

    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4

2.2 Hinzufügen neuer Rollen zu Nodes Edit source

Mit DeepSea stellen Sie alle Typen von unterstützten Rollen bereit. Weitere Informationen zu unterstützten Rollentypen und Beispiele zu deren Abgleich finden Sie im Abschnitt 5.5.1.2, „Rollenzuweisung“.

Führen Sie die folgenden Schritte aus, um einen neuen Service zu einem bestehenden Node hinzuzufügen:

  1. Passen Sie /srv/pillar/ceph/proposals/policy.cfg so an, dass der bestehende Host mit einer neuen Rolle abgeglichen wird. Weitere Informationen finden Sie im Abschnitt 5.5.1, „Die Datei policy.cfg. Wenn Sie beispielsweise ein Object Gateway in einem MON Node ausführen müssen, sieht die Zeile in etwas so aus:

    role-rgw/xx/x/example.mon-1.sls
  2. Führen Sie Phase 2 für das Update des Pillar aus:

    root@master # salt-run state.orch ceph.stage.2
  3. Führen Sie Phase 3 zum Bereitstellen von grundlegenden Services aus bzw. Phase 4 zum Bereitstellen optionaler Services. Es kann jedoch nicht schaden, beide Phasen auszuführen.

2.3 Entfernen und erneute Installation von Cluster Nodes Edit source

Tipp
Tipp: Vorübergehendes Entfernen eines Cluster Nodes

Der Salt Master erwartet, dass sich alle Minions im Cluster befinden und ansprechbar sind. Wenn ein Minion abstürzt und nicht mehr ansprechbar ist, verursacht dies Probleme in der Salt-Infrastruktur, vorwiegend für DeepSea und Ceph Dashboard.

Bevor Sie den Minion reparieren, löschen Sie seinen Schlüssel vorübergehend aus dem Salt Master:

root@master # salt-key -d MINION_HOST_NAME

Sobald der Minion repariert ist, fügen Sie seinen Schlüssel wieder in den Salt Master ein:

root@master # salt-key -a MINION_HOST_NAME

Bearbeiten Sie zum Entfernen einer Rolle aus dem Cluster die Datei /srv/pillar/ceph/proposals/policy.cfg und entfernen Sie die entsprechenden Zeilen. Führen Sie Phase 2 und 5 aus wie im Abschnitt 5.3, „Cluster-Bereitstellung“ erläutert.

Anmerkung
Anmerkung: Entfernen von OSDs aus dem Cluster

Falls Sie einen bestimmten OSD-Node aus Ihrem Cluster entfernen müssen, stellen Sie sicher, dass Ihr Cluster mehr freien Speicherplatz hat als die Festplatte, die Sie entfernen möchten. Bedenken Sie, dass durch Entfernen eines OSD ein Ausgleich des gesamten Clusters durchgeführt wird.

Bevor Sie die Phase 5 mit dem eigentlichen Entfernungsvorgang ausführen, prüfen Sie in jedem Fall, welche OSDs durch DeepSea entfernt werden:

root@master # salt-run rescinded.ids

Wenn eine Rolle von einem Minion entfernt wird, sollen damit alle Änderungen in Bezug auf diese Rolle rückgängig gemacht werden. Bei den meisten Rollen ist diese Aufgabe problemlos zu bewältigen, doch es gibt möglicherweise Probleme bei Paketabhängigkeiten. Wenn ein Paket deinstalliert wird, bleiben die Abhängigkeiten bestehen.

Entfernte OSDs werden als leere Laufwerke angezeigt. Die entsprechenden Aufgaben überschreiben den Anfang des Dateisystems, entfernen Sicherungspartitionen und löschen die Partitionstabellen endgültig.

Anmerkung
Anmerkung: Beibehalten von Partitionen, die anhand anderer Methoden erstellt wurden

Festplattenlaufwerke, die früher anhand anderer Methoden wie ceph-deploy konfiguriert wurden, enthalten möglicherweise immer noch Partitionen. Diese werden von DeepSea nicht automatisch zerstört. Der Administrator muss alle auf diesen Laufwerken noch enthaltenen Partitionen manuell entfernen.

Beispiel 2.1: Entfernen eines Salt Minion vom Cluster

Wenn Ihre Speicher-Minions benannt wurden, wie zum Beispiel "data1.ceph", "data2.ceph" ... "data6.ceph", und wenn die entsprechenden Zeilen in Ihrer Datei policy.cfg so ähnlich aussehen wie die folgende:

[...]
# Hardware Profile
role-storage/cluster/data*.sls
[...]

Dann müssen Sie zum Entfernen des Salt Minion "data2.ceph" die Zeile folgendermaßen ändern:

[...]
# Hardware Profile
role-storage/cluster/data[1,3-6]*.sls
[...]

Denken Sie auch daran, die Datei „drive_groups.yml“ gemäß den neuen Zielen anzupassen.

    [...]
    drive_group_name:
      target: 'data[1,3-6]*'
    [...]

Führen Sie dann die Phase 2 aus, prüfen Sie, welche OSDs entfernt werden, und führen Sie schließlich Phase 5 aus:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run rescinded.ids
root@master # salt-run state.orch ceph.stage.5
Beispiel 2.2: Migrieren von Nodes

Stellen Sie sich folgende Situation vor: Während der ersten Cluster-Installation haben Sie (als Administrator) einen der Speicher-Nodes als eigenständiges Object Gateway zugeordnet und warten noch auf die Lieferung der Gateway-Hardware. Die permanente Hardware für das Gateway wird schließlich geliefert und Sie können die vorgesehene Rolle zum Sicherungsspeicher-Node zuweisen und die Gateway-Rolle entfernen.

Nach Ausführung der Phasen 0 und 1 (Informationen hierzu finden Sie imProzedur 5.1, „Ausführen von Bereitstellungsphasen“) für die neue Hardware haben Sie das neue Gateway rgw1 genannt. Wenn für Node data8 die Object Gateway-Rolle entfernt und die Speicher-Rolle hinzugefügt werden muss und die aktuelle Datei policy.cfg folgendermaßen aussieht:

# Hardware Profile
role-storage/cluster/data[1-7]*.sls

# Roles
role-rgw/cluster/data8*.sls

Dann ändern Sie die Datei zu:

# Hardware Profile
role-storage/cluster/data[1-8]*.sls

# Roles
role-rgw/cluster/rgw1*.sls

Führen Sie die Phasen 2 bis 4 aus, prüfen Sie, welche OSDs entfernt werden, und führen Sie schließlich Phase 5 aus. Phase 3 fügt data8 als Speicher-Node hinzu. Einen Moment lang verfügt data8 über beide Rollen. In Phase 4 wird die Object Gateway-Rolle zu rgw1 hinzugefügt und in Phase 5 wird die Object Gateway-Rolle von data8 entfernt:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.3
root@master # salt-run state.orch ceph.stage.4
root@master # salt-run rescinded.ids
root@master # salt-run state.orch ceph.stage.5

2.4 Erneute Bereitstellung von Monitor Nodes Edit source

Wenn bei einem oder mehreren Monitor Nodes Fehler auftreten und sie nicht mehr antworten, müssen Sie die fehlerhaften Monitors aus dem Cluster entfernen und sie möglicherweise im Cluster wieder neu hinzufügen.

Wichtig
Wichtig: Das Minimum ist drei Monitor Nodes

Es müssen mindestens drei Monitor Nodes vorhanden sein. Wenn bei einem Monitor Node ein Fehler auftritt und Ihr Cluster deshalb nur noch zwei Monitor Nodes enthält, müssen Sie die Monitor-Rolle vorübergehend anderen Cluster Nodes hinzufügen, bevor Sie die fehlerhaften Monitor Nodes neu bereitstellen. Sie können die temporären Monitor-Rollen deinstallieren, nachdem Sie die fehlerhaften Monitor Nodes neu bereitgestellt haben.

Weitere Informationen zum Hinzufügen neuer Nodes/Rollen zum Ceph Cluster finden Sie in Abschnitt 2.1, „Hinzufügen neuer Cluster Nodes“ und Abschnitt 2.2, „Hinzufügen neuer Rollen zu Nodes“.

Weitere Informationen zum Entfernen von Cluster Nodes finden Sie in Abschnitt 2.3, „Entfernen und erneute Installation von Cluster Nodes“.

Es gibt zwei grundlegende Grade von Ceph Node-Fehlern:

  • Der Salt Minion ist entweder physisch defekt oder auf Betriebssystemebene beschädigt und antwortet nicht bei Aufruf von salt 'minion_name' test.ping. In diesem Fall müssen Sie den Server vollständig neu bereitstellen. Befolgen Sie dazu die entsprechenden Anweisungen im Abschnitt 5.3, „Cluster-Bereitstellung“.

  • Bei den auf den Monitor bezogenen Services sind Fehler aufgetreten und sie lassen sich nicht wiederherstellen, doch der Host antwortet bei Aufruf von salt 'minion_name' test.ping. Führen Sie in diesem Fall die folgenden Schritte aus:

  1. Bearbeiten Sie /srv/pillar/ceph/proposals/policy.cfg am Salt Master und entfernen oder aktualisieren Sie die Zeilen, die sich auf die fehlerhaften Monitor Nodes beziehen, sodass diese nun auf die funktionierenden Monitor Nodes zeigen. Beispiel:

    [...]
    # MON
    #role-mon/cluster/ses-example-failed1.sls
    #role-mon/cluster/ses-example-failed2.sls
    role-mon/cluster/ses-example-new1.sls
    role-mon/cluster/ses-example-new2.sls
    [...]
  2. Führen Sie die DeepSea-Phasen 2 bis 5 aus, um die Änderungen anzuwenden:

    root@master # deepsea stage run ceph.stage.2
    root@master # deepsea stage run ceph.stage.3
    root@master # deepsea stage run ceph.stage.4
    root@master # deepsea stage run ceph.stage.5

2.5 Hinzufügen eines OSD-Datenträgers zu einem Knoten Edit source

Verifizieren Sie zum Hinzufügen einer Festplatte zu einem bestehenden OSD-Node, dass alle Partitionen auf der Festplatte entfernt und diese vollständig gelöscht wurde. Weitere detaillierte Informationen finden Sie in Schritt 12 im Abschnitt 5.3, „Cluster-Bereitstellung“. Passen Sie /srv/salt/ceph/configuration/files/drive_groups.yml entsprechend an (siehe Abschnitt 5.5.2, „DriveGroups“). Sobald die Datei gespeichert wurde, führen Sie die DeepSea-Phase 3 aus:

root@master # deepsea stage run ceph.stage.3

2.6 Entfernen eines OSD Edit source

Durch Ausführen des folgenden Kommandos entfernen Sie einen Ceph OSD aus dem Cluster:

root@master # salt-run osd.remove OSD_ID

OSD_ID muss die Nummer des OSD ohne das Präfix osd. sein. Beispiel: Von osd.3 verwenden Sie nur die Zahl 3.

2.6.1 Entfernen mehrerer OSDs Edit source

Befolgen Sie die Anweisungen in Abschnitt 2.6, „Entfernen eines OSD“ und geben Sie lediglich mehrere OSD-IDs an:

root@master # salt-run osd.remove 2 6 11 15
Removing osd 2 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.2 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 6 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.6 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 11 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.11 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 15 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.15 is safe to destroy
Purging from the crushmap
Zapping the device


2:
True
6:
True
11:
True
15:
True

2.6.2 Entfernen aller OSDs auf einem Host Edit source

Mit folgendem Kommando entfernen Sie alle OSDs auf einem bestimmten Host:

root@master # salt-run osd.remove OSD_HOST_NAME

2.6.3 Entfernen fehlerhafter OSDs erzwingen Edit source

In manchen Fällen ist es nicht möglich, einen OSD ordnungsgemäß zu entfernen (weitere Informationen hierzu finden Sie in Abschnitt 2.6, „Entfernen eines OSD“). Dies ist beispielsweise der Fall, wenn der OSD oder dessen Journal, WAL oder DB beschädigt ist, wenn E/A-Operationen hängen geblieben sind oder wenn sich die OSD-Festplatte nicht aushängen lässt.

root@master # salt-run osd.remove OSD_ID force=True
Tipp
Tipp: Hängen gebliebene Einhängungen

Wenn noch eine Partition auf dem zu entfernenden Datenträger eingehängt ist, wird das Kommando mit der Meldung „Unmount failed – check for processes on DEVICE“ (Fehler beim Aushängen – Prozesse auf DEVICE prüfen) abgebrochen. Mit fuser -m DEVICE können Sie dann eine Liste aller Prozesse abrufen, die auf das Dateisystem zugreifen. Falls fuser nichts zurückgibt, versuchen Sie, unmount DEVICE manuell auszuführen, und beobachten Sie die Ausgabe der Kommandos dmesg oder journalctl.

2.6.4 Validieren von OSD-LVM-Metadaten Edit source

Wenn ein OSD mit salt-run osd.remove ID oder mit anderen Ceph-Kommandos entfernt wurde, wurden die LVM-Metadaten möglicherweise nicht vollständig entfernt. Dies bedeutet, dass bei der Implementierung eines neuen OSD die bisherigen LVM-Metadaten verwendet werden.

  1. Prüfen Sie zunächst, ob der OSD entfernt wurde:

    cephadm@osd > ceph-volume lvm list

    Ein OSD wird unter Umständen selbst dann noch aufgeführt, wenn es erfolgreich entfernt wurde. Wenn Sie beispielsweise osd.2 entfernt haben, wird Folgendes ausgegeben:

      ====== osd.2 =======
    
      [block] /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380
    
      block device /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380
      block uuid kH9aNy-vnCT-ExmQ-cAsI-H7Gw-LupE-cvSJO9
      cephx lockbox secret
      cluster fsid 6b6bbac4-eb11-45cc-b325-637e3ff9fa0c
      cluster name ceph
      crush device class None
      encrypted 0
      osd fsid aac51485-131c-442b-a243-47c9186067db
      osd id 2
      type block
      vdo 0
      devices /dev/sda

    In diesem Beispiel befindet sich osd.2 immer noch in /dev/sda.

  2. Validieren Sie die LVM-Metadaten auf dem OSD Node:

    cephadm@osd > ceph-volume inventory

    In der Ausgabe von ceph-volume inventory ist die Verfügbarkeit von /dev/sda als False gekennzeichnet. Beispiel:

      Device Path Size rotates available Model name
      /dev/sda 40.00 GB True False QEMU HARDDISK
      /dev/sdb 40.00 GB True False QEMU HARDDISK
      /dev/sdc 40.00 GB True False QEMU HARDDISK
      /dev/sdd 40.00 GB True False QEMU HARDDISK
      /dev/sde 40.00 GB True False QEMU HARDDISK
      /dev/sdf 40.00 GB True False QEMU HARDDISK
      /dev/vda 25.00 GB True False
  3. Mit folgendem Kommando auf dem OSD Node entfernen Sie die LVM-Metadaten vollständig:

    cephadm@osd > ceph-volume lvm zap --osd-id ID --destroy
  4. Führen Sie das Kommando inventory erneut aus und prüfen Sie, ob die Verfügbarkeit von /dev/sda wieder True lautet. Beispiel:

    cephadm@osd > ceph-volume inventory
    Device Path Size rotates available Model name
    /dev/sda 40.00 GB True True QEMU HARDDISK
    /dev/sdb 40.00 GB True False QEMU HARDDISK
    /dev/sdc 40.00 GB True False QEMU HARDDISK
    /dev/sdd 40.00 GB True False QEMU HARDDISK
    /dev/sde 40.00 GB True False QEMU HARDDISK
    /dev/sdf 40.00 GB True False QEMU HARDDISK
    /dev/vda 25.00 GB True False

    Die LVM-Metadaten sind nun entfernt. Das Kommando dd kann nunmehr gefahrlos auf dem Gerät ausgeführt werden.

  5. Der OSD kann nun erneut implementiert werden, ohne den OSD Node neu starten zu müssen:

    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3

2.7 Austauschen eines OSD-Datenträgers Edit source

Es gibt verschiedene Gründe, aus denen ein OSD-Datenträger ausgetauscht werden muss, beispielsweise:

  • Der OSD-Datenträger ist laut SMART-Informationen ausgefallen (oder wird bald ausfallen), weshalb keine Daten sicher mehr darauf gespeichert werden können.

  • Sie müssen den OSD-Datenträger aufrüsten, beispielsweise vergrößern.

Das Austauschverfahren ist in beiden Fällen gleich. Es gilt außerdem sowohl für standardmäßige als auch für angepasste CRUSH-Zuordnungen.

  1. Angenommen, der OSD, dessen Datenträger ausgetauscht werden muss, trägt die ID „5“. Mit dem folgenden Kommando wird er in der CRUSH-Zuordnung als destroyed (zerstört) gekennzeichnet, wobei er jedoch seine ursprüngliche ID beibehält:

    root@master # salt-run osd.replace 5
    Tipp
    Tipp: osd.replace und osd.remove

    Die Salt-Kommandos osd.replace und osd.remove (siehe Abschnitt 2.6, „Entfernen eines OSD“) sind nahezu identisch, mit der Ausnahme, dass der OSD mit osd.replace in der CRUSH-Zuordnung als „destroyed“ beibehalten wird, wogegen mit osd.remove alle Spuren aus der CRUSH-Zuordnung entfernt werden.

  2. Tauschen Sie den ausgefallenen/aufgerüsteten OSD-Datenträger manuell aus.

  3. Soll das standardmäßige OSD-Layout bearbeitet und die DriveGroups-Konfiguration geöffnet werden, befolgen Sie die Anweisungen in Abschnitt 5.5.2, „DriveGroups“.

  4. Implementieren Sie den ausgetauschten OSD-Datenträger mit der Implementierungsphase 3:

    root@master # salt-run state.orch ceph.stage.3

2.8 Wiederherstellen eines erneut installierten OSD-Nodes Edit source

Wenn das Betriebssystem in einem Ihrer OSD-Nodes abstürzt und sich nicht wiederherstellen lässt, führen Sie die folgenden Schritte aus, um es wiederherzustellen und seine OSD-Rolle mit den unveränderten Cluster-Daten neu bereitzustellen:

  1. Installieren Sie das SUSE Linux Enterprise-Basisbetriebssystem wieder auf dem Knoten, auf dem das Betriebssystem abgestürzt ist. Installieren Sie die salt-minion -Pakete auf dem OSD-Node, löschen Sie den alten Salt Minion-Schlüssel am Salt Master und registrieren Sie den neuen Schlüssel des Salt Minions beim Salt Master. Weitere Informationen zur ursprünglichen Implementierung finden Sie in Abschnitt 5.3, „Cluster-Bereitstellung“.

  2. Führen Sie statt der gesamten Phase 0 nur die folgenden Teile aus:

    root@master # salt 'osd_node' state.apply ceph.sync
    root@master # salt 'osd_node' state.apply ceph.packages.common
    root@master # salt 'osd_node' state.apply ceph.mines
    root@master # salt 'osd_node' state.apply ceph.updates
  3. Führen Sie die DeepSea-Phasen 1 bis 5 aus:

    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4
    root@master # salt-run state.orch ceph.stage.5
  4. Führen Sie die DeepSea-Phase 0 aus:

    root@master # salt-run state.orch ceph.stage.0
  5. Neustarten Sie den relevanten OSD-Node. Alle OSD-Festplatten werden neu ermittelt und wiederverwendet.

  6. Installieren und starten Sie das Prometheus-Knotenexportprogramm:

    root@master # salt 'RECOVERED_MINION' \
     state.apply ceph.monitoring.prometheus.exporters.node_exporter
  7. Aktualisieren Sie die Salt Grains:

    root@master # salt 'RECOVERED_MINION' osd.retain

2.9 Verschieben des Admin Node auf einen neuen Server Edit source

Wenn der Admin Node-Host durch einen neuen Host ersetzt werden muss, müssen Sie die Salt Master- und DeepSea-Dateien verschieben. Übertragen Sie die Dateien mit einem Synchronisierungswerkzeug Ihrer Wahl. In diesem Verfahren wird rsync herangezogen, da dieses Werkzeug standardmäßig in den Software-Repositorys von SUSE Linux Enterprise Server 15 SP1 zur Verfügung steht.

  1. Halten Sie die salt-master- und salt-minion-Services auf dem alten Admin Node an:

    root@master # systemctl stop salt-master.service
    root@master # systemctl stop salt-minion.service
  2. Konfigurieren Sie Salt auf dem neuen Admin Node, sodass der Salt Master und die Salt Minions miteinander kommunizieren. Weitere Informationen finden Sie in Abschnitt 5.3, „Cluster-Bereitstellung“.

    Tipp
    Tipp: Übergang der Salt Minions

    Damit der Übergang der Salt Minions auf den neuen Admin Node erleichtert wird, entfernen Sie den öffentlichen Schlüssel des ursprünglichen Salt Masters aus allen Minions:

    root@minion > rm /etc/salt/pki/minion/minion_master.pub
    root@minion > systemctl restart salt-minion.service
  3. Prüfen Sie, ob das Paket deepsea installiert ist. Falls nicht, installieren Sie es.

    root@master # zypper install deepsea
  4. Passen Sie die Datei policy.cfg an: Ändern Sie die Zeile role-master. Weitere Informationen finden Sie in Abschnitt 5.5.1, „Die Datei policy.cfg.

  5. Synchronisieren Sie die Verzeichnisse /srv/pillar und /srv/salt aus dem alten Admin Node mit dem neuen Admin Node.

    Tipp
    Tipp: Probelauf von rsync und symbolische Links

    Führen Sie die Synchronisation nach Möglichkeit zunächst in einem Probelauf durch und prüfen Sie, welche Dateien übertragen werden (rsync-Option -n). Geben Sie außerdem symbolische Links an (rsync-Option -a). Bei rsync sieht das Kommando zur Synchronisation wie folgt aus:

    root@master # rsync -avn /srv/pillar/ NEW-ADMIN-HOSTNAME:/srv/pillar
  6. Wenn Sie Dateien außerhalb der Verzeichnisse /srv/pillar und /srv/salt geändert haben, beispielsweise in /etc/salt/master oder /etc/salt/master.d, synchronisieren Sie diese Dateien ebenfalls.

  7. Nun können Sie die DeepSea-Phasen vom neuen Admin Node aus ausführen. Eine ausführliche Beschreibung finden Sie in Abschnitt 5.2, „Einführung zu DeepSea“.

2.10 Automatische Installation mit Salt Edit source

Die Installation kann mithilfe des Salt-Reaktors automatisiert werden. In virtuellen Umgebungen oder konsistenten Hardwareumgebungen ermöglicht diese Konfiguration die Erstellung eines Ceph Clusters mit dem angegebenen Verhalten.

Warnung
Warnung

Salt kann keine Abhängigkeitsprüfungen auf Basis von Reaktorereignissen durchführen. Das Risiko ist groß, dass Ihr Salt Master dadurch überlastet wird und nicht mehr antwortet.

Für die automatische Installation ist Folgendes erforderlich:

  • Eine ordnungsgemäß erstellte Datei /srv/pillar/ceph/proposals/policy.cfg.

  • Eine vorbereitete benutzerdefinierte Konfiguration, die in das Verzeichnis /srv/pillar/ceph/stack gestellt wurde.

Die standardmäßige Reaktorkonfiguration führt nur die Phasen 0 und 1 aus. Dadurch kann der Reaktor getestet werden, ohne auf die Ausführung der nachfolgenden Phasen warten zu müssen.

Wenn der erste „salt-minion“ startet, beginnt Phase 0. Eine Sperre verhindert mehrere Instanzen. Phase 1 beginnt, wenn alle Minions Phase 0 abgeschlossen haben.

Wenn der Vorgang ordnungsgemäß ausgeführt wurde, bearbeiten Sie die Datei

/etc/salt/master.d/reactor.conf

und ersetzen Sie die folgende Zeile

- /srv/salt/ceph/reactor/discovery.sls

durch

- /srv/salt/ceph/reactor/all_stages.sls

Die Zeile darf nicht auskommentiert sein.

2.11 Aktualisieren der Cluster Nodes Edit source

Wenden Sie regelmäßig Updates im laufenden Betrieb an, damit die Ceph Cluster Nodes auf dem neuesten Stand bleiben.

2.11.1 Software-Repositorys Edit source

Bevor Sie den Cluster mit den aktuellen Software-Paketen patchen, prüfen Sie, ob alle Cluster Nodes auf die relevanten Repositorys zugreifen können. Eine Liste aller erforderlichen Repositorys finden Sie in Abschnitt 6.8.1, „Manuelles Knoten-Upgrade mit der Installationsprogramms-DVD“.

2.11.2 Repository-Staging Edit source

Wenn Sie mit einem Repository-Staging-System arbeiten (z. B. SUSE Manager, Subscription Management Tool oder Repository Mirroring Tool), mit dem die Software-Repositorys für die Cluster Nodes bereitgestellt werden, müssen die Phasen für beide „Updates“-Repositorys für SUSE Linux Enterprise Server und SUSE Enterprise Storage zum gleichen Zeitpunkt erstellt werden.

Für Patches mit eingefrorenen/in Phasen unterteilten Patchstufen wird ein Staging-Werkzeug dringend empfohlen. Damit wird gewährleistet, dass die neu in den Cluster eintretenden Knoten dieselbe Patchstufe aufweisen wie die Knoten, die sich bereits im Cluster befinden. So müssen Sie nicht mehr die aktuellen Patches auf alle Cluster Nodes anwenden, bevor neue Knoten in den Cluster aufgenommen werden können.

2.11.3 zypper patch oder zypper dup Edit source

Cluster Nodes werden standardmäßig mit dem Kommando zypper dup aufgerüstet. Wenn Sie das System lieber mit zypper patch aktualisieren möchten, bearbeiten Sie /srv/pillar/ceph/stack/global.yml und fügen Sie folgende Zeile hinzu:

update_method_init: zypper-patch

2.11.4 Neustart der Cluster Nodes Edit source

Im Rahmen des Updates werden die Cluster Nodes optional neu gestartet, wenn ihr Kernel durch das Update aufgerüstet wurde. Soll die Möglichkeit eines erzwungenen Neustarts von potenziell allen Knoten ausgeschlossen werden, prüfen Sie entweder, ob der aktuelle Kernel auf den Ceph Nodes installiert und aktiv ist, oder deaktivieren Sie den automatischen Neustart von Knoten gemäß den Anweisungen in Abschnitt 7.1.5, „Updates und Neustarts in Phase 0“.

2.11.5 Ausfallzeit von Ceph Services Edit source

Je nach Konfiguration werden die Cluster Nodes während des Updates ggf. neu gestartet (siehe Abschnitt 2.11.4, „Neustart der Cluster Nodes“). Wenn ein Single-Point-of-Failure für Services wie Object Gateway, Samba Gateway, NFS Ganesha oder iSCSI vorliegt, werden die Client-Computer unter Umständen vorübergehend von Services getrennt, dessen Knoten neu gestartet werden.

2.11.6 Ausführen des Updates Edit source

So aktualisieren Sie die Software-Pakete auf allen Cluster Nodes auf die aktuelle Version:

  1. Aktualisieren Sie die Pakete deepsea, salt-master und salt-minion und starten Sie die relevanten Services auf dem Salt Master neu:

    root@master # salt -I 'roles:master' state.apply ceph.updates.master
  2. Aktualisieren Sie das Paket salt-minion auf allen Cluster Nodes und starten Sie es neu:

    root@master # salt -I 'cluster:ceph' state.apply ceph.updates.salt
  3. Aktualisieren Sie alle anderen Software-Pakete im Cluster:

    root@master # salt-run state.orch ceph.maintenance.upgrade

2.12 Anhalten oder Neustarten des Clusters Edit source

In einigen Fällen muss möglicherweise der gesamte Cluster angehalten oder neugestartet werden. Wir empfehlen, sorgfältig nach Abhängigkeiten von aktiven Services zu suchen. Die folgenden Schritte beschreiben den Vorgang zum Stoppen und Starten des Clusters:

  1. Weisen Sie den Ceph Cluster an, für OSDs die Flagge „noout“ zu setzen:

    cephadm@adm > ceph osd set noout
  2. Stoppen Sie die Daemons und Nodes in der folgenden Reihenfolge:

    1. Speicher-Clients

    2. Gateways wie NFS Ganesha oder Object Gateway

    3. Metadata Server

    4. Ceph OSD

    5. Ceph Manager

    6. Ceph Monitor

  3. Führen Sie Wartungsaufgaben aus, falls erforderlich.

  4. Starten Sie die Nodes und Server in umgekehrter Reihenfolge des Herunterfahrens:

    1. Ceph Monitor

    2. Ceph Manager

    3. Ceph OSD

    4. Metadata Server

    5. Gateways wie NFS Ganesha oder Object Gateway

    6. Speicher-Clients

  5. Entfernen Sie die Flagge „noout“:

    cephadm@adm > ceph osd unset noout

2.13 Anpassen von ceph.conf mit benutzerdefinierten Einstellungen Edit source

Wenn Sie benutzerdefinierte Einstellungen zu Datei ceph.conf hinzufügen müssen, können Sie dazu die Konfigurationsdateien im Verzeichnis /srv/salt/ceph/configuration/files/ceph.conf.d entsprechend ändern:

  • global.conf

  • mon.conf

  • mgr.conf

  • mds.conf

  • osd.conf

  • client.conf

  • rgw.conf

Anmerkung
Anmerkung: Eindeutige rgw.conf

Das Object Gateway bietet ein hohes Maß an Flexibilität und ist einzigartig verglichen mit anderen Abschnitten von ceph.conf. Alle anderen Ceph-Komponenten weisen statische Header auf wie [mon] oder [osd]. Das Object Gateway weist eindeutige Header auf wie [client.rgw.rgw1]. Dies bedeutet, dass für Datei rgw.conf ein Header-Eintrag erforderlich ist. Beispiele finden Sie in

/srv/salt/ceph/configuration/files/rgw.conf

oder

/srv/salt/ceph/configuration/files/rgw-ssl.conf
Wichtig
Wichtig: Phase 3 ausführen

Führen Sie die Phasen 3 und 4 aus, nachdem Sie benutzerdefinierte Änderungen an den oben genannten Konfigurationsdateien vorgenommen haben. Die Änderungen werden dadurch auf die Cluster Nodes angewendet:

root@master # salt-run state.orch ceph.stage.3
root@master # salt-run state.orch ceph.stage.4

Diese Dateien werden aus der Schablonendatei /srv/salt/ceph/configuration/files/ceph.conf.j2 übernommen. Sie entsprechen den verschiedenen Abschnitten, die von der Ceph-Konfigurationsdatei akzeptiert werden. Wenn Sie einen Konfigurationsausschnitt in die richtige Datei einfügen, kann DeepSea diesen Ausschnitt in den richtigen Abschnitt platzieren. Sie brauchen keine der Abschnitts-Header hinzuzufügen.

Tipp
Tipp

Fügen Sie einen Header wie [osd.1] hinzu, wenn Sie Konfigurationsoptionen nur auf bestimmte Instanzen eines Daemon anwenden möchten. Die folgenden Konfigurationsoptionen werden nur auf den OSD Daemon mit ID 1 angewendet.

2.13.1 Außerkraftsetzen der Standardeinstellungen Edit source

Ältere Anweisungen in einem Abschnitt werden durch neuere überschrieben. Somit ist es möglich, die in der Schablone /srv/salt/ceph/configuration/files/ceph.conf.j2 angegebene Standardkonfiguration außer Kraft zu setzen. Beispiel: Fügen Sie die folgenden drei Zeilen zu Datei /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf hinzu, um die cephx-Authentifizierung auszuschalten:

auth cluster required = none
auth service required = none
auth client required = none

Beim Neudefinieren der Standardwerte geben Ceph-spezifische Werkzeuge wie rados eventuell Warnungen aus, dass bestimmte Werte aus ceph.conf.j2 in global.conf neu definiert wurden. Diese Warnungen werden von einem Parameter verursacht, der in der resultierenden ceph.conf zweimal zugewiesen wird.

Als Behelfslösung für diesen bestimmten Fall führen Sie folgende Schritte aus:

  1. Wechseln Sie zum Verzeichnis /srv/salt/ceph/configuration/create:

    root@master # cd /srv/salt/ceph/configuration/create
  2. Kopieren Sie default.sls in custom.sls:

    root@master # cp default.sls custom.sls
  3. Bearbeiten Sie custom.sls und ersetzen Sie ceph.conf.j2 durch custom-ceph.conf.j2.

  4. Wechseln Sie zum Verzeichnis /srv/salt/ceph/configuration/files:

    root@master # cd /srv/salt/ceph/configuration/files
  5. Kopieren Sie ceph.conf.j2 in custom-ceph.conf.j2:

    root@master # cp ceph.conf.j2 custom-ceph.conf.j2
  6. Bearbeiten Sie custom-ceph.conf.j2 und löschen Sie folgende Zeile:

    {% include "ceph/configuration/files/rbd.conf" %}

    Bearbeiten Sie global.yml und fügen Sie folgende Zeile hinzu:

    configuration_create: custom
  7. Aktualisieren Sie den Pillar:

    root@master # salt target saltutil.pillar_refresh
  8. Führen Sie Phase 3 aus:

    root@master # salt-run state.orch ceph.stage.3

Nun sollte nur noch je ein Eintrag pro Wertdefinition vorliegen. Erstellen Sie die Konfiguration mit folgendem Kommando neu:

root@master # salt-run state.orch ceph.configuration.create

und prüfen Sie dann den Inhalt von /srv/salt/ceph/configuration/cache/ceph.conf.

2.13.2 Einbeziehen von Konfigurationsdateien Edit source

Wenn Sie viele benutzerdefinierte Konfigurationen anwenden müssen, erleichtern Sie die Dateiverwaltung anhand der folgenden „include“-Anweisungen in den benutzerdefinierten Konfigurationsdateien. Nachfolgend sehen Sie ein Beispiel der Datei osd.conf:

[osd.1]
{% include "ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing %}
[osd.2]
{% include "ceph/configuration/files/ceph.conf.d/osd2.conf" ignore missing %}
[osd.3]
{% include "ceph/configuration/files/ceph.conf.d/osd3.conf" ignore missing %}
[osd.4]
{% include "ceph/configuration/files/ceph.conf.d/osd4.conf" ignore missing %}

Im vorigen Beispiel enthalten die Dateien osd1.conf, osd2.conf, osd3.conf und osd4.conf die für den entsprechenden OSD spezifischen Konfigurationsoptionen.

Tipp
Tipp: Konfiguration zur Laufzeit

Änderungen an den Ceph-Konfigurationsdateien werden wirksam nach dem Neustart der entsprechenden Ceph Daemons. Weitere Informationen zum Ändern der Ceph-Konfiguration zur Laufzeit finden Sie im folgenden Abschnitt 16.1, „Konfiguration zur Laufzeit“.

2.14 Aktivieren von AppArmor-Profilen Edit source

Die Sicherheitslösung AppArmor beschränkt Programme mithilfe eines bestimmten Profils. Weitere Einzelheiten finden Sie unter https://www.suse.com/documentation/sles-15/book_security/data/part_apparmor.html.

DeepSea bietet drei Statusangaben für AppArmor-Profile: „enforce“, „complain“ und „disable“. Mit folgendem Kommando aktivieren Sie einen bestimmten AppArmor-Status:

salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-STATE

So versetzen Sie die AppArmor-Profile in den Status „enforce“:

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-enforce

So versetzen Sie die AppArmor-Profile in den Status „complain“:

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-complain

So deaktivieren Sie die AppArmor-Profile:

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-disable
Tipp
Tipp: Aktivieren des AppArmor-Services

Bei diesen drei Aufrufen wird jeweils überprüft, ob AppArmor installiert ist. Wenn dies nicht der Fall ist, wird AppArmor installiert und der zugehörige systemd-Service wird gestartet. DeepSea gibt eine Warnung aus, wenn AppArmor auf andere Weise installiert und gestartet/aktiviert wurde und damit ohne DeepSea-Profile ausgeführt wird.

2.15 Deaktivieren von abgestimmten Profilen Edit source

Standardmäßig stellt DeepSea die Ceph Cluster mit aktiven abgestimmten Profilen auf Ceph Monitor, Ceph Manager und Ceph OSD Nodes bereit. In einigen Fällen müssen abgestimmte Profile dauerhaft deaktiviert werden. Tragen Sie hierzu die folgenden Zeilen in /srv/pillar/ceph/stack/global.yml ein und führen Sie die Phase 3 erneut aus:

alternative_defaults:
 tuned_mgr_init: default-off
 tuned_mon_init: default-off
 tuned_osd_init: default-off
root@master # salt-run state.orch ceph.stage.3

2.16 Entfernen eines ganzen Ceph Clusters Edit source

Mit dem Ausführungsprogramm ceph.purge wird der gesamte Ceph Cluster entfernt. Auf diese Weise können Sie die kleinste menschliche Umgebung bereinigen, wenn Sie verschiedene Einrichtungen testen. Nach Abschluss von ceph.purge wird der Salt Cluster wieder in den Zustand versetzt, der am Ende der DeepSea-Phase 1 vorlag. Sie können dann entweder policy.cfg ändern (sieheAbschnitt 5.5.1, „Die Datei policy.cfg) oder die DeepSea-Phase 2 mit derselben Einrichtung fortsetzen.

Damit nicht versehentlich ein Löschvorgang durchgeführt wird, prüft die Orchestrierung, ob die Sicherheitsmaßnahmen deaktiviert sind. Mit folgendem Kommando können Sie die Sicherheitsmaßnahmen deaktivieren und den Ceph Cluster entfernen:

root@master # salt-run disengage.safety
root@master # salt-run state.orch ceph.purge
Tipp
Tipp: Deaktivieren der Entfernung des Ceph Clusters

Soll der Aufruf des Ausführungsprogramms ceph.purge durch andere Benutzer verhindert werden, erstellen Sie die Dateidisabled.sls im Verzeichnis /srv/salt/ceph/purge und fügen Sie folgende Zeile in die Datei /srv/pillar/ceph/stack/global.yml ein:

purge_init: disabled
Wichtig
Wichtig: Außerkraftsetzen von benutzerdefinierten Rollen

Wenn Sie benutzerdefinierte Rollen für das Ceph Dashboard erstellt hatten (siehe Abschnitt 22.2.6, „Hinzufügen benutzerdefinierter Rollen“ und Abschnitt 22.10.2, „Benutzerrollen und Berechtigungen“), müssen Sie sie manuell bereinigen, bevor Sie das Ausführungsprogramm ceph.purge aufrufen. Wenn die benutzerdefinierte Rolle für das Object Gateway beispielsweise die Bezeichnung „us-east-1“ trägt, führen Sie folgende Schritte aus:

root@master # cd /srv/salt/ceph/rescind
root@master # rsync -a rgw/ us-east-1
root@master # sed -i 's!rgw!us-east-1!' us-east-1/*.sls
Diese Seite drucken