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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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:

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.

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

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:

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.

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

update_method_init: zypper-patch

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:

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:

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

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.

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

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

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

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

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

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