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

7 Anpassen der Standardkonfiguration Edit source

Sie können die in Phase 2 generierte Cluster-Konfiguration ändern (weitere Informationen hierzu finden Sie im Abschnitt Beschreibung von DeepSea-Phasen). Beispielsweise müssen Sie die Netzwerkeinstellungen ändern oder eine standardmäßig auf dem Admin Node installierte Software. Ersteres erfolgt durch Ändern des Pillar, der nach Phase 2 aktualisiert wurde. Letzteres wird normalerweise durch Erstellen einer benutzerdefinierten sls-Datei ausgeführt, die dann zum Pillar hinzugefügt wird. Detaillierte Informationen erhalten Sie in den folgenden Abschnitten.

7.1 Verwenden benutzerdefinierter Konfigurationsdateien Edit source

In diesem Abschnitt sind einige Aufgaben aufgeführt, für die Sie zunächst Ihre eigenen sls-Dateien hinzufügen/ändern müssen. Dieses Verfahren wird normalerweise angewendet, wenn Sie den standardmäßigen Bereitstellungsprozess ändern müssen.

Tipp
Tipp: Präfix für benutzerdefinierte SLS-Dateien

Ihre benutzerdefinierten SLS-Dateien befinden sich im selben Unterverzeichnis wie die SLS-Dateien von DeepSea. Stellen Sie die Zeichenkette custom- als Präfix vor den Namen Ihrer SLS-Dateien, um zu verhindern, dass sie von den möglicherweise neu hinzugefügten Dateien aus dem DeepSea-Paket überschrieben werden.

7.1.1 Deaktivieren eines Bereitstellungschritts Edit source

Wenn Sie eine spezifische Aufgabe außerhalb des DeepSea-Bereitstellungsvorgangs ausführen und sie daher überspringen müssen, erstellen Sie eine "no-operation"-Datei anhand des folgenden Beispiels:

Prozedur 7.1: Deaktivieren der Zeitsynchronisierung
  1. Erstellen Sie die Datei /srv/salt/ceph/time/disabled.sls mit folgendem Inhalt und speichern Sie sie:

    disable time setting:
    test.nop
  2. Bearbeiten Sie die Datei /srv/pillar/ceph/stack/global.yml, fügen Sie die folgende Zeile hinzu und speichern Sie sie:

    time_init: disabled
  3. Verifizieren Sie das Ergebnis durch Aktualisieren des Pillar und Ausführen des folgenden Schritts:

    root@master # salt target saltutil.pillar_refresh
    root@master # salt 'admin.ceph' state.apply ceph.time
    admin.ceph:
      Name: disable time setting - Function: test.nop - Result: Clean
    
    Summary for admin.ceph
    ------------
    Succeeded: 1
    Failed:    0
    ------------
    Total states run:     1
    Anmerkung
    Anmerkung: Eindeutige Kennung

    Die Aufgabenkennung „disable time setting“ kann durch eine eindeutige Bezeichnung in einer sls-Datei ersetzt werden. Geben Sie eindeutige Beschreibungen an, um zu verhindern, dass Kennungen missverständlich sind.

7.1.2 Ersetzen eines Bereitstellungschritts Edit source

Wenn Sie das Standardverhalten eines bestimmten Schritts durch ein benutzerdefiniertes Verhalten ersetzen müssen, erstellen Sie eine benutzerdefinierte sls-Datei mit dem entsprechenden Inhalt.

Standardmäßig erstellt /srv/salt/ceph/pool/default.sls ein RBD-Image namens „demo“. In unserem Beispiel soll dieses Image nicht erstellt werden, sondern zwei Images namens „archive1“ und „archive2“.

Prozedur 7.2: Ersetzen des RBD-Image demo durch zwei benutzerdefinierte RBD-Images
  1. Erstellen Sie die Datei /srv/salt/ceph/pool/custom.sls mit folgendem Inhalt und speichern Sie sie:

    wait:
      module.run:
        - name: wait.out
        - kwargs:
            'status': "HEALTH_ERR"1
        - fire_event: True
    
    archive1:
      cmd.run:
        - name: "rbd -p rbd create archive1 --size=1024"2
        - unless: "rbd -p rbd ls | grep -q archive1$"
        - fire_event: True
    
    archive2:
      cmd.run:
        - name: "rbd -p rbd create archive2 --size=768"
        - unless: "rbd -p rbd ls | grep -q archive2$"
        - fire_event: True

    1

    Das wait-Modul pausiert bis der Status HEALTH_ERR des Ceph Clusters nicht mehr erscheint. Bei Neuinstallationen weist ein Ceph Cluster diesen Status möglicherweise so lange auf, bis eine ausreichende Anzahl von OSDs verfügbar und die Erstellung der Pools abgeschlossen ist.

    2

    Das Kommando rbd ist nicht idempotent. Wird dasselbe Erstellungskommando erneut ausgeführt, wenn das Image bereits vorhanden ist, ist der Salt-Zustand fehlerhaft. Durch die Anweisung unless wird dies verhindert.

  2. Sie müssen die Datei /srv/pillar/ceph/stack/ceph/cluster.yml bearbeiten, die folgende Zeile hinzufügen und sie speichern, um die neu erstellte benutzerdefinierte Datei statt der Standarddatei aufrufen zu können:

    pool_init: custom
  3. Verifizieren Sie das Ergebnis durch Aktualisieren des Pillar und Ausführen des folgenden Schritts:

    root@master # salt target saltutil.pillar_refresh
    root@master # salt 'admin.ceph' state.apply ceph.pool
Anmerkung
Anmerkung: Autorisierung

Für die Erstellung von Pools oder Images ist eine ausreichende Autorisierung erforderlich. Der admin.ceph-Minion verfügt über einen Admin-Schlüsselbund.

Tipp
Tipp: Alternative Methode

Alternativ können Sie die Variable in Datei /srv/pillar/ceph/stack/ceph/roles/master.yml ändern. Durch Verwendung dieser Datei wird die Fülle von Pillar-Daten für andere Minions reduziert.

7.1.3 Bearbeiten eines Bereitstellungschritts Edit source

Manchmal benötigen Sie zum Ausführen zusätzlicher Aufgaben möglicherweise einen bestimmten Schritt. Es ist nicht zu empfehlen, die entsprechende Zustandsdatei zu bearbeiten, weil ein zukünftiges Update dadurch kompliziert werden könnte. Erstellen Sie stattdessen zum Ausführen der zusätzlichen Aufgaben eine separate Datei, die mit dem übereinstimmt, was in Abschnitt 7.1.2, „Ersetzen eines Bereitstellungschritts“ beschrieben ist.

Geben Sie der neuen sls-Datei einen beschreibenden Namen. Beispiel: Wenn Sie zwei RBD-Images zusätzlich zum Demo-Image erstellen müssen, geben Sie der Datei den Namen archive.sls.

Prozedur 7.3: Erstellen von zwei zusätzlichen RBD-Images
  1. Erstellen Sie die Datei /srv/salt/ceph/pool/custom.sls mit folgendem Inhalt und speichern Sie sie:

    include:
     - .archive
     - .default
    Tipp
    Tipp: Reihenfolge angeben

    In diesem Beispiel erstellt Salt die archive-Images und dann das demo-Image. Die Reihenfolge spielt in diesem Beispiel keine Rolle. Vertauschen Sie die Zeilen nach der Anweisung include:, um die Reihenfolge zu ändern.

    Sie können die Zeile mit „include“ direkt zu archive.sls hinzufügen und alle Images werden ebenfalls erstellt. Allerdings verarbeitet Salt die Schritte in der enthaltenen Datei zuerst, unabhängig davon wo die Zeile mit „include“ platziert wird. Obwohl dieses Verhalten durch die Anweisungen requires und order außer Kraft gesetzt werden kann, garantiert eine separate Datei, die die anderen enthält, die Einhaltung der Reihenfolge und verringert die Gefahr von Verwechslungen.

  2. Bearbeiten Sie die Datei /srv/pillar/ceph/stack/ceph/cluster.yml, fügen Sie die folgende Zeile hinzu und speichern Sie sie:

    pool_init: custom
  3. Verifizieren Sie das Ergebnis durch Aktualisieren des Pillar und Ausführen des folgenden Schritts:

    root@master # salt target saltutil.pillar_refresh
    root@master # salt 'admin.ceph' state.apply ceph.pool

7.1.4 Bearbeiten einer Bereitstellungsphase Edit source

Wenn Sie einen völlig anderen Bereitstellungsschritt hinzufügen müssen, erstellen Sie drei neue Dateien: eine sls-Datei, die das Kommando ausführt, eine Orchestrierungsdatei sowie eine benutzerdefinierte Datei, die den neuen Schritt mit den ursprünglichen Bereitstellungsschritten abstimmt.

Beispiel: Wenn Sie logrotate auf allen Minions als Teil der Vorbereitungsphase ausführen müssen:

Erstellen Sie zunächst eine sls-Datei und fügen Sie das Kommando logrotate hinzu.

Prozedur 7.4: Ausführen von logrotate auf allen Salt-Minions
  1. Erstellen Sie ein Verzeichnis wie /srv/salt/ceph/logrotate.

  2. Erstellen Sie /srv/salt/ceph/logrotate/init.sls mit dem folgenden Inhalt und speichern Sie die Datei:

    rotate logs:
      cmd.run:
        - name: "/usr/sbin/logrotate /etc/logrotate.conf"
  3. Verifizieren Sie, dass das Kommando an einem Minion funktioniert:

    root@master # salt 'admin.ceph' state.apply ceph.logrotate

Fügen Sie die Orchestrierungsdatei der Phase 0 prep hinzu, da sie vor allen anderen Vorbereitungsschritten ausgeführt werden muss:

  1. Erstellen Sie /srv/salt/ceph/stage/prep/logrotate.sls mit dem folgenden Inhalt und speichern Sie die Datei:

    logrotate:
      salt.state:
        - tgt: '*'
        - sls: ceph.logrotate
  2. Verifizieren Sie, dass die Orchestrierungsdatei funktioniert:

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

Die letzte Datei ist die benutzerdefinierte Datei. Sie enthält den zusätzlichen Schritt sowie die ursprünglichen Schritte:

  1. Erstellen Sie /srv/salt/ceph/stage/prep/custom.sls mit dem folgenden Inhalt und speichern Sie die Datei:

    include:
      - .logrotate
      - .master
      - .minion
  2. Setzen Sie das Standardverhalten außer Kraft. Bearbeiten Sie die Datei /srv/pillar/ceph/stack/global.yml, fügen Sie die folgende Zeile hinzu und speichern Sie sie:

    stage_prep: custom
  3. Verifizieren Sie, dass Phase 0 funktioniert:

    root@master # salt-run state.orch ceph.stage.0
Anmerkung
Anmerkung: Wieso global.yml?

Die Datei global.yml wird anstelle der Datei cluster.yml gewählt, weil in der Phase prep noch kein Minion zum Ceph Cluster gehört und keinen Zugriff auf Einstellungen in cluster.yml hat.

7.1.5 Updates und Neustarts in Phase 0 Edit source

In Phase 0 (weitere Informationen zu DeepSea-Phasen siehe Beschreibung von DeepSea-Phasen) werden der Salt Master und die Salt Minions optional neu gestartet, da für neue Pakete, beispielsweise kernel, ein Neustart des Systems erforderlich ist.

Aus dem Standardverhalten werden verfügbare neue Updates installiert und die Knoten werden selbst bei einem Kernel-Update nicht neu gestartet.

Sie können das standardmäßige Update-/Neustartverhalten der DeepSea-Phase 0 ändern. Fügen Sie hierzu die Optionen stage_prep_master und stage_prep_minion in die /srv/pillar/ceph/stack/global.yml Datei ein oder ändern Sie diese Optionen. Mit _prep_master wird das Verhalten des Salt Masters in Phase festgelegt, mit stage_prep_minion das Verhalten aller Minions. Die folgenden Parameter sind verfügbar:

default

Installiert die Updates ohne Neustart.

default-update-reboot

Installiert die Updates und neustartet nach dem Update-Vorgang.

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.

Wenn beispielsweise keine Updates auf den Cluster Nodes installiert und die Cluster Nodes nicht neu gestartet werden sollen, bearbeiten Sie /srv/pillar/ceph/stack/global.yml und fügen Sie die folgenden Zeilen ein:

stage_prep_master: default-no-update-no-reboot
stage_prep_minion: default-no-update-no-reboot
Tipp
Tipp: Werte und zugehörige Dateien

Die Werte von stage_prep_master entsprechen den Dateinamen in /srv/salt/ceph/stage/0/master, die Werte von stage_prep_minion dagegen den Dateien in /srv/salt/ceph/stage/0/minion:

root@master # ls -l /srv/salt/ceph/stage/0/master
default-no-update-no-reboot.sls
default-no-update-reboot.sls
default-update-reboot.sls
[...]

root@master # ls -l /srv/salt/ceph/stage/0/minion
default-no-update-no-reboot.sls
default-no-update-reboot.sls
default-update-reboot.sls
[...]

7.2 Bearbeiten der ermittelten Konfiguration Edit source

Nach Abschluss von Phase 2 möchten Sie möglicherweise die ermittelte Konfiguration ändern. Führen Sie zur Anzeige der aktuellen Einstellungen Folgendes aus:

root@master # salt target pillar.items

Die Ausgabe der Standardkonfiguration für einen einzelnen Minion ähnelt normalerweise der folgenden Ausgabe:

----------
    available_roles:
        - admin
        - mon
        - storage
        - mds
        - igw
        - rgw
        - client-cephfs
        - client-radosgw
        - client-iscsi
        - mds-nfs
        - rgw-nfs
        - master
    cluster:
        ceph
    cluster_network:
        172.16.22.0/24
    fsid:
        e08ec63c-8268-3f04-bcdb-614921e94342
    master_minion:
        admin.ceph
    mon_host:
        - 172.16.21.13
        - 172.16.21.11
        - 172.16.21.12
    mon_initial_members:
        - mon3
        - mon1
        - mon2
    public_address:
        172.16.21.11
    public_network:
        172.16.21.0/24
    roles:
        - admin
        - mon
        - mds
    time_server:
        admin.ceph
    time_service:
        ntp

Die oben genannten Einstellungen werden auf verschiedene Konfigurationsdateien verteilt. Die Verzeichnisstruktur mit diesen Dateien ist im Verzeichnis/srv/pillar/ceph/stack/stack.cfg definiert. Die folgenden Dateien beschreiben normalerweise Ihren Cluster:

  • /srv/pillar/ceph/stack/global.yml - die Datei hat Auswirkungen auf alle Minions im Salt Cluster.

  • /srv/pillar/ceph/stack/ceph/cluster.yml - die Datei hat Auswirkungen auf alle Minions im Ceph Cluster namens ceph.

  • /srv/pillar/ceph/stack/ceph/roles/role.yml - die Datei hat Auswirkungen auf alle Minions, denen eine spezifische Rolle im ceph Cluster zugewiesen wurde.

  • /srv/pillar/ceph/stack/cephminions/MINION_ID/yml – die Datei hat Auswirkungen auf den einzelnen Minion.

Anmerkung
Anmerkung: Überschreiben von Verzeichnissen mit Standardwerten

In einem parallelen Verzeichnis ist die Standard-Konfigurationseinrichtung gespeichert unter /srv/pillar/ceph/stack/default. Ändern Sie hier keine Werte, weil diese überschrieben werden.

Das normale Verfahren zum Ändern der gesammelten Konfiguration ist wie folgt:

  1. Suchen Sie den Standort des Konfigurationselements, das Sie ändern müssen. Wenn Sie beispielsweise eine auf den Cluster bezogene Einstellung wie das Cluster-Netzwerk ändern müssen, bearbeiten Sie die Datei /srv/pillar/ceph/stack/ceph/cluster.yml.

  2. Speichern Sie die Datei.

  3. Führen Sie zum Verifizieren der Änderungen Folgendes aus:

    root@master # salt target saltutil.pillar_refresh

    und danach

    root@master # salt target pillar.items

7.2.1 Aktivieren von IPv6 für die Ceph Cluster-Implementierung Edit source

Die IPv4-Netzwerkadressierung ist derzeit gängig; IPv6 muss daher als benutzerdefinierte Anpassung aktiviert werden. DeepSea bietet keine automatische Erkennung von IPv6-Adressen.

Zum Konfigurieren von IPv6 legen Sie in den Variablen public_network und cluster_network in der Datei /srv/pillar/ceph/stack/global.yml gültige IPv6-Subnetze fest. Beispiel:

public_network: fd00:10::/64
cluster_network: fd00:11::/64

Führen Sie dann die DeepSea-Phase 2 aus und prüfen Sie, ob die Netzwerkinformationen mit den Einstellungen übereinstimmen. In Phase 3 wird ceph.conf mit den erforderlichen Flaggen erzeugt.

Wichtig
Wichtig: Keine Unterstützung für Dual Stack

Ceph bietet keine Unterstützung für Dual Stack – die gleichzeitige Ausführung von Ceph auf IPv4 und IPv6 ist nicht möglich. Die DeepSea-Validierung lehnt einen fehlerhaften Abgleich zwischen public_network und cluster_network bzw. innerhalb der einzelnen Variablen ab. Im folgenden Beispiel schlägt die Validierung fehl.

public_network: "192.168.10.0/24 fd00:10::/64"
Tipp
Tipp: Keine Verwendung von fe80::/10 link-local-Adressen

Verwenden Sie keine fe80::/10 link-local-Adressen. Allen Netzwerkschnittstellen ist eine fe80-Adresse zugewiesen und für das ordnungsgemäße Routing ist ein Schnittstellen-Qualifizierer erforderlich. Weisen Sie entweder IPv6-Adressen zu, die Ihrem Standort zugeordnet sind, oder verwenden Sie fd00::/8. Diese Adressen sind Teil der ULA und sind nicht global routingfähig.

Diese Seite drucken