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

1 Cluster-Verwaltung mit Salt

Nach der Bereitstellung des 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.

1.1 Hinzufügen neuer Cluster Nodes

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

  1. Installieren Sie SUSE Linux Enterprise Server 12 SP3 im neuen Node, konfigurieren Sie dessen Netzwerkeinstellung, sodass der Hostname des Salt Masters korrekt aufgelöst wird, und installieren Sie 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 alle Salt-Schlüssel am Salt Master:

    root@master # salt-key --accept-all
  3. Verifizieren Sie, dass /srv/pillar/ceph/deepsea_minions.sls auch den neuen Salt Minion adressiert. Weitere Informationen finden Sie im Abschnitt 4.2.2.1, „Abgleichen des Minion-Namens“ und im Prozedur 4.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
  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 4.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
  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

1.2 Hinzufügen neuer Rollen zu Nodes

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 4.5.1.2, „Rollenzuweisung“.

Tipp
Tipp: Erforderliche und optionale Rollen und Phasen

Grundsätzlich empfehlen wir, alle Bereitstellungsphasen 0 bis 5 auszuführen, wenn Sie eine neue Rolle zu einem Cluster Node hinzufügen. Um Zeit zu sparen, können Sie die Phase 3 oder 4 überspringen, je nach dem Typ der Rolle, die Sie bereitstellen möchten. Die OSD- und MON-Rollen enthalten grundlegende Services und sind für Ceph erforderlich. Andere Rollen wie das Object Gateway sind optional. DeepSea-Bereitstellungsphasen sind hierarchisch: Phase 3 stellt grundlegende Services bereit, Phase 4 optionale.

Daher müssen Sie Phase 3 ausführen, wenn Sie grundlegende Rollen wie MON in einem bestehenden OSD-Node ausführen und können Phase 4 überspringen.

Entsprechend können Sie Phase 3 überspringen, wenn Sie optionale Services wie Object Gateway bereitstellen, müssen in diesem Fall jedoch Phase 4 ausführen.

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

Tipp
Tipp

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

1.3 Entfernen und erneute Installation von Cluster Nodes

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 4.3, „Cluster-Bereitstellung“ erläutert.

Anmerkung
Anmerkung: Entfernen von OSDs aus Ihrem 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.

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

Beispiel 1.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
profile-default/cluster/data*.sls
profile-default/stack/default/ceph/minions/data*.yml
[...]

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

[...]
# Hardware Profile
profile-default/cluster/data[1,3-6]*.sls
profile-default/stack/default/ceph/minions/data[1,3-6]*.yml
[...]

Führen Sie dann die Phasen 2 und 5 aus:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.5
Beispiel 1.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 4.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
profile-default/cluster/data[1-7]*.sls
profile-default/stack/default/ceph/minions/data[1-7]*.sls

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

Dann ändern Sie die Datei zu:

# Hardware Profile
profile-default/cluster/data[1-8]*.sls
profile-default/stack/default/ceph/minions/data[1-8]*.sls

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

Führen Sie die Phasen 2 und 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.

1.4 Erneute Bereitstellung von Monitor Nodes

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 einen oder 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 1.1, „Hinzufügen neuer Cluster Nodes“ und Abschnitt 1.2, „Hinzufügen neuer Rollen zu Nodes“.

Weitere Informationen zum Entfernen von Cluster Nodes finden Sie in Abschnitt 1.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 4.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.

  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

1.5 Hinzufügen eines OSD zu einem Node

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 13 im Abschnitt 4.3, „Cluster-Bereitstellung“. Wenn die Festplatte leer ist, fügen Sie diese zur YAML-Datei des Nodes hinzu. Der Pfad zur Datei lautet /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/node_name.yml. Führen Sie nach dem Speichern der Datei die DeepSea-Phasen 2 und 3 aus:

root@master # deepsea stage run ceph.stage.2
root@master # deepsea stage run ceph.stage.3
Tipp
Tipp: Profile automatisch aktualisiert

Statt die YAML-Datei manuell zu bearbeiten, können Sie DeepSea neue Profile erstellen lassen. Die bestehenden Profile müssen entfernt werden, damit DeepSea neue Profile erstellen kann:

root@master # old /srv/pillar/ceph/proposals/profile-default/
root@master # deepsea stage run ceph.stage.1
root@master # deepsea stage run ceph.stage.2
root@master # deepsea stage run ceph.stage.3

1.6 Entfernen eines OSD

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

root@master # salt-run disengage.safety
root@master # salt-run remove.osd OSD_ID

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

Tipp
Tipp: Entfernen mehrerer OSDs

Es ist nicht möglich, mit dem Kommando salt-run remove.osd mehrere OSDs gleichzeitig zu entfernen. Um den Vorgang zum Entfernen mehrerer OSDs zu automatisieren, verwenden Sie folgende Schleife (5, 21, 33, 19 sind ID-Nummern der zu entfernenden OSDs):

for i in 5 21 33 19
do
 echo $i
 salt-run disengage.safety
 salt-run remove.osd $i
done

1.6.1 Entfernen fehlerhafter OSDs erzwingen

In manchen Fällen ist es nicht möglich, einen OSD ordnungsgemäß zu entfernen (weitere Informationen hierzu finden Sie in Abschnitt 1.6, „Entfernen eines OSD“). Dies ist beispielsweise der Fall, wenn der OSD oder dessen Cache beschädigt ist, wenn E/A-Operationen hängen geblieben sind oder wenn sich die OSD-Festplatte nicht aushängen lässt. In einem derartigen Fall müssen Sie den Vorgang zum Entfernen des OSD erzwingen:

root@master # target osd.remove OSD_ID force=True

Durch dieses Kommando wird sowohl die Datenpartition entfernt als auch das Journal oder die WAL/DB-Partitionen.

Führen Sie die folgenden Schritte aus, um mögliche bezuglose Journal/WAL/DB-Geräte zu erkennen:

  1. Wählen Sie das Gerät, auf dem sich möglicherweise bezuglose Partitionen befinden, und speichern Sie die Liste dieser Partitionen in eine Datei:

    root@minion > ls /dev/sdd?* > /tmp/partitions
  2. Führen Sie readlink gegen alle "block.wal"-, "block.db"- und "journal"-Geräte aus und vergleichen Sie die Ausgabe mit der vorher gespeicherten Liste der Partitionen:

    root@minion > readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \
     | sort | comm -23 /tmp/partitions -

    Die Ausgabe stellt die Liste der Partitionen dar, die nicht von Ceph genutzt werden.

  3. Entfernen Sie die bezuglosen Partitionen, die nicht zu Ceph gehören, mit Ihrem bevorzugten Kommando (beispielsweise fdisk, parted oder sgdisk).

1.7 Wiederherstellen eines erneut installierten OSD-Nodes

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. Führen Sie eine erneute Installation des Betriebssystems im Node durch.

  2. Installieren Sie die salt-minion-Pakete im 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 Salt Minion-Bereitstellung finden Sie im Abschnitt 4.3, „Cluster-Bereitstellung“.

  3. 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
  4. 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
  5. Führen Sie DeepSea-Phase 0 aus:

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

1.8 Automatische Installation mit Salt

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 gestestet 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äß durchgeführt wird, ändern Sie die letzte Zeile in Datei /etc/salt/master.d/reactor.conf:

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

zu

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

1.9 Aktualisieren der Cluster Nodes

Es empfiehlt sich, regelmäßig die verfügbaren Rolling Releases auf die Nodes Ihres Clusters anzuwenden. Führen Sie Phase 0 aus, um die Updates anzuwenden:

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

Wenn DeepSea einen aktiven Ceph Cluster erkennt, wendet es Updates an und startet die Nodes der Reihe nach neu. DeepSea hält sich an die offizielle Empfehlung von Ceph, zunächst die Monitors zu aktualisieren, dann die OSDs und zuletzt zusätzliche Services wie MDS, Object Gateway, iSCSI Gateway oder NFS Ganesha. DeepSea stoppt den Update-Vorgang, wenn es ein Problem im Cluster erkennt. Dies wird möglicherweise ausgelöst durch Folgendes:

  • Ceph zeigt die Meldung "HEALTH_ERR" länger als 300 Sekunden an.

  • Auf den Salt Minions wird abgefragt, ob ihre zugewiesenen Services nach dem Update noch aktiv sind und ausgeführt werden. Das Update wird nicht ausgeführt, wenn die Services länger als 900 Sekunden inaktiv sind.

Durch diese Maßnahmen wird sichergestellt, dass der Ceph Cluster funktionsfähig bleibt, auch wenn Updates beschädigt sind oder nicht durchgeführt werden können.

DeepSea Phase 0 aktualisiert das System mittels zypper update und neustartet das System, wenn der Kernel aktualisiert ist. Stellen Sie sicher, dass der neueste Kernel installiert ist und ausgeführt wird, bevor Sie DeepSea Phase 0 initiieren, wenn Sie die Möglichkeit eines erzwungenen Neustarts potenziell aller Nodes ausschließen möchten.

Tipp
Tipp: zypper patch

Wenn Sie das System lieber mit dem Kommando 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

Das standardmäßige Neustartverhalten von DeepSea Phase 0 lässt sich durch Hinzufügen der folgenden Zeilen zu Datei /srv/pillar/ceph/stack/global.yml ändern:

stage_prep_master: default-update-no-reboot
stage_prep_minion: default-update-no-reboot

Mit stage_prep_master wird das Verhalten des Salt Masters in Phase 0 festgelegt, mit stage_prep_minion das Verhalten aller Minions. Die folgenden Parameter sind verfügbar:

default

Installiert die Updates und neustartet nach dem Update-Vorgang.

default-update-no-reboot

Installiert die Updates ohne Neustart.

default-no-update-reboot

Neustart ohne Installation der Updates.

default-no-update-no-reboot

Updates werden nicht installiert und es wird kein Neustart durchgeführt.

1.10 Anhalten oder Neustarten des Clusters

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:

    root # 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":

    root # ceph osd unset noout

1.11 Benutzerdefinierte Datei ceph.conf

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. Ein Beispiel hierzu finden Sie in Datei /srv/salt/ceph/configuration/files/rgw.conf.

Wichtig
Wichtig: Phase 3 ausführen

Führen Sie Phase 3 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

Diese Dateien werden aus der Vorlagendatei /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.

1.11.1 Außerkraftsetzen der Standardeinstellungen

Ältere Anweisungen in einem Abschnitt werden durch neuere überschrieben. Somit ist es möglich, die in der Vorlage /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

1.11.2 Einbeziehen von Konfigurationsdateien

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 1.12, „Ceph-Konfiguration zur Laufzeit“.

1.12 Ceph-Konfiguration zur Laufzeit

In Abschnitt 1.11, „Benutzerdefinierte Datei ceph.conf wird erläutert, wie Änderungen an der Ceph-Konfigurationsdatei ceph.conf vorgenommen werden. Das tatsächliche Cluster-Verhalten wird jedoch nicht durch den aktuellen Zustand der Datei ceph.conf bestimmt, sondern durch die Konfiguration der aktiven Ceph Daemons, die im Arbeitsspeicher gespeichert ist.

Mit dem admin socket im Node, in dem der Daemon ausgeführt wird, fragen Sie einen einzelnen Ceph Daemon nach einer bestimmten Konfigurationseinstellung ab. Beispiel: Mit dem folgenden Kommando wird der Wert des Konfigurationsparameters osd_max_write_size vom Daemon namens osd.0 abgerufen:

root # ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok \
config get osd_max_write_size
{
  "osd_max_write_size": "90"
}

Die Einstellungen des Daemons können auch zur Laufzeit geändert werden. Berücksichtigen Sie, dass diese Änderung vorübergehend ist und beim nächsten Neustart des Daemons verloren geht. Beispiel: Mit dem folgenden Kommando wird der Parameter osd_max_write_size für alle OSDs im Cluster auf "50" geändert:

root # ceph tell osd.* injectargs --osd_max_write_size 50
Warnung
Warnung: injectargs ist nicht zuverlässig

Leider können Sie sich nicht hundertprozentig darauf verlassen, dass mit injectargs die Cluster-Einstellungen geändert werden. Wenn Sie sicherstellen müssen, dass der geänderte Parameter aktiv ist, ändern Sie ihn in der Konfigurationsdatei und starten Sie alle Daemons im Cluster neu.

Diese Seite drucken