cephx
ceph.conf
mit benutzerdefinierten EinstellungenNach 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.
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:
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:
Fügen Sie osd crush initial weight = 0
in /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf
ein.
Erstellen Sie die neue Konfiguration auf dem Salt Master Node:
root@master #
salt 'SALT_MASTER_NODE' state.apply ceph.configuration.create
Wenden Sie die neue Konfiguration auf die adressierten OSD-Minions an:
root@master #
salt 'OSD_MINIONS' state.apply ceph.configuration
Sobald die neuen OSDs hinzugefügt wurden, passen Sie deren Gewicht je nach Bedarf mit dem Kommando ceph osd crush reweight
an.
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
Akzeptieren Sie auf dem Salt Master den Salt-Schlüssel des neuen Knotens:
root@master #
salt-key --accept NEW_NODE_KEY
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“.
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
Wenn der Salt Master nach dem Kernel-Update neu gestartet wurde, müssen Sie die DeepSea-Phase 0 neu starten.
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
Ä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
“.
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
Soll das standardmäßige OSD-Layout bearbeitet und die DriveGroups-Konfiguration geöffnet werden, befolgen Sie die Anweisungen in Abschnitt 5.5.2, „DriveGroups“.
Die Konfigurations- und Bereitstellungsphasen umfassen neu hinzugefügte Nodes:
root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4
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:
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
Führen Sie Phase 2 für das Update des Pillar aus:
root@master #
salt-run state.orch ceph.stage.2
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.
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.
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.
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.
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.2root@master #
salt-run rescinded.idsroot@master #
salt-run state.orch ceph.stage.5
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.2root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4root@master #
salt-run rescinded.idsroot@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.
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:
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 [...]
Führen Sie die DeepSea-Phasen 2 bis 5 aus, um die Änderungen anzuwenden:
root@master #
deepsea
stage run ceph.stage.2root@master #
deepsea
stage run ceph.stage.3root@master #
deepsea
stage run ceph.stage.4root@master #
deepsea
stage run ceph.stage.5
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
.
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
Mit folgendem Kommando entfernen Sie alle OSDs auf einem bestimmten Host:
root@master #
salt-run osd.remove OSD_HOST_NAME
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
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
.
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.
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
.
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
Mit folgendem Kommando auf dem OSD Node entfernen Sie die LVM-Metadaten vollständig:
cephadm@osd >
ceph-volume lvm zap --osd-id ID --destroy
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.
Der OSD kann nun erneut implementiert werden, ohne den OSD Node neu starten zu müssen:
root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3
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.
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
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.
Tauschen Sie den ausgefallenen/aufgerüsteten OSD-Datenträger manuell aus.
Soll das standardmäßige OSD-Layout bearbeitet und die DriveGroups-Konfiguration geöffnet werden, befolgen Sie die Anweisungen in Abschnitt 5.5.2, „DriveGroups“.
Implementieren Sie den ausgetauschten OSD-Datenträger mit der Implementierungsphase 3:
root@master #
salt-run state.orch ceph.stage.3
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:
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“.
Führen Sie statt der gesamten Phase 0 nur die folgenden Teile aus:
root@master #
salt 'osd_node' state.apply ceph.syncroot@master #
salt 'osd_node' state.apply ceph.packages.commonroot@master #
salt 'osd_node' state.apply ceph.minesroot@master #
salt 'osd_node' state.apply ceph.updates
Führen Sie die DeepSea-Phasen 1 bis 5 aus:
root@master #
salt-run state.orch ceph.stage.1root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4root@master #
salt-run state.orch ceph.stage.5
Führen Sie die DeepSea-Phase 0 aus:
root@master #
salt-run state.orch ceph.stage.0
Neustarten Sie den relevanten OSD-Node. Alle OSD-Festplatten werden neu ermittelt und wiederverwendet.
Installieren und starten Sie das Prometheus-Knotenexportprogramm:
root@master #
salt 'RECOVERED_MINION' \
state.apply ceph.monitoring.prometheus.exporters.node_exporter
Aktualisieren Sie die Salt Grains:
root@master #
salt 'RECOVERED_MINION' osd.retain
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.
Halten Sie die salt-master
- und salt-minion
-Services auf dem alten Admin Node an:
root@master #
systemctl stop salt-master.serviceroot@master #
systemctl stop salt-minion.service
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“.
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.pubroot@minion >
systemctl restart salt-minion.service
Prüfen Sie, ob das Paket deepsea installiert ist. Falls nicht, installieren Sie es.
root@master #
zypper install deepsea
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
“.
Synchronisieren Sie die Verzeichnisse /srv/pillar
und /srv/salt
aus dem alten Admin Node mit dem neuen Admin Node.
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
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.
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“.
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.
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.
Wenden Sie regelmäßig Updates im laufenden Betrieb an, damit die Ceph Cluster Nodes auf dem neuesten Stand bleiben.
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“.
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.
zypper patch
oder zypper dup
#
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
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“.
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.
So aktualisieren Sie die Software-Pakete auf allen Cluster Nodes auf die aktuelle Version:
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
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
Aktualisieren Sie alle anderen Software-Pakete im Cluster:
root@master #
salt-run state.orch ceph.maintenance.upgrade
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:
Weisen Sie den Ceph Cluster an, für OSDs die Flagge „noout“ zu setzen:
cephadm@adm >
ceph
osd set noout
Stoppen Sie die Daemons und Nodes in der folgenden Reihenfolge:
Speicher-Clients
Gateways wie NFS Ganesha oder Object Gateway
Metadata Server
Ceph OSD
Ceph Manager
Ceph Monitor
Führen Sie Wartungsaufgaben aus, falls erforderlich.
Starten Sie die Nodes und Server in umgekehrter Reihenfolge des Herunterfahrens:
Ceph Monitor
Ceph Manager
Ceph OSD
Metadata Server
Gateways wie NFS Ganesha oder Object Gateway
Speicher-Clients
Entfernen Sie die Flagge „noout“:
cephadm@adm >
ceph
osd unset noout
ceph.conf
mit benutzerdefinierten Einstellungen #
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
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
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.3root@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.
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.
Ä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:
Wechseln Sie zum Verzeichnis /srv/salt/ceph/configuration/create
:
root@master #
cd /srv/salt/ceph/configuration/create
Kopieren Sie default.sls
in custom.sls
:
root@master #
cp default.sls custom.sls
Bearbeiten Sie custom.sls
und ersetzen Sie ceph.conf.j2
durch custom-ceph.conf.j2
.
Wechseln Sie zum Verzeichnis /srv/salt/ceph/configuration/files
:
root@master #
cd /srv/salt/ceph/configuration/files
Kopieren Sie ceph.conf.j2
in custom-ceph.conf.j2
:
root@master #
cp ceph.conf.j2 custom-ceph.conf.j2
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
Aktualisieren Sie den Pillar:
root@master #
salt target saltutil.pillar_refresh
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
.
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.
Ä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
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.safetyroot@master #
salt-run state.orch ceph.purge
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
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/rescindroot@master #
rsync -a rgw/ us-east-1root@master #
sed -i 's!rgw!us-east-1!' us-east-1/*.sls