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

5 Bereitstellen mit DeepSea/Salt Edit source

Salt bildet zusammen mit DeepSea ein Paket von Komponenten, die bei der Bereitstellung und Verwaltung von Serverinfrastruktur nützlich sind. Es ist hoch skalierbar, schnell und lässt sich relativ leicht in Betrieb nehmen. Lesen Sie die folgenden Überlegungen, bevor Sie mit der Bereitstellung des Clusters mit Salt beginnen:

  • Salt Minions sind die Nodes, die von einem dedizierten Node namens Salt Master gesteuert werden. Salt Minions verfügen über Rollen wie zum Beispiel Ceph OSD, Ceph Monitor, Ceph Manager, Object Gateway, iSCSI Gateway oder NFS Ganesha.

  • Ein Salt Master führt seinen eigenen Salt Minion aus. Er ist erforderlich zum Ausführen von privilegierten Aufgaben, beispielsweise Erstellen, Autorisieren und Kopieren von Schlüsseln für Minions, sodass Remote Minions niemals privilegierte Aufgaben ausführen müssen.

    Tipp
    Tipp: Freigeben mehrerer Rollen pro Server

    Sie erreichen die optimale Leistung Ihres Ceph Clusters, wenn jede Rolle in einem separaten Node bereitgestellt wird. Manchmal ist es jedoch bei Bereitstellungen erforderlich, einen Node für mehrere Rollen freizugeben. Stellen Sie die Ceph OSD-, Metadatenserver- oder Ceph Monitor-Rolle nicht auf dem Admin Node bereit, um Probleme mit der Leistung und dem Upgrade-Vorgang zu vermeiden.

  • Salt Minions müssen den Hostnamen des Salt Master im gesamten Netzwerk korrekt auflösen. Standardmäßig suchen sie nach dem Hostnamen salt, Sie können jedoch auch in Datei /etc/salt/minion jeden vom Netzwerk erreichbaren Hostnamen angeben. Weitere Informationen hierzu finden Sie in Abschnitt 5.3, „Cluster-Bereitstellung“.

5.1 Lesen Sie die Versionshinweise Edit source

In den Versionshinweisen finden Sie zusätzliche Informationen zu den Änderungen, die seit der vorigen Version von SUSE Enterprise Storage vorgenommen wurden. Informieren Sie sich in den Versionshinweisen über Folgendes:

  • Sind bei der Hardware besondere Überlegungen zu beachten?

  • Wurden erhebliche Änderungen an den verwendeten Software-Paketen vorgenommen?

  • Gelten besondere Vorsichtsmaßnahmen für die vorliegende Installation?

In den Versionshinweisen finden Sie auch Informationen, die erst nach der Fertigstellung des Handbuchs bekannt wurden. Auch bekannte Probleme werden beschrieben.

Nach Installation des Pakets release-notes-sesfinden Sie die Versionshinweise lokal im Verzeichnis /usr/share/doc/release-notes oder online unter https://www.suse.com/releasenotes/.

5.2 Einführung zu DeepSea Edit source

Das Ziel von DeepSea besteht darin, dem Administrator Zeit zu sparen und komplexe Operationen im Ceph Cluster zuverlässig durchzuführen.

Ceph ist eine umfassend konfigurierbare Softwarelösung. Systemadministratoren gewinnen dadurch mehr Freiheit, haben aber auch mehr Verantwortung.

Die minimale Einrichtung von Ceph eignet sich gut für Demonstrationszwecke, zeigt jedoch nicht die interessanten Funktionen von Ceph, die bei einer großen Anzahl von Nodes zum Tragen kommen.

DeepSea erfasst und speichert Daten über individuelle Server, wie Adressen und Gerätenamen. Bei einem dezentralen Speichersystem wie Ceph müssen gegebenenfalls Hunderte solcher Elemente erfasst und gespeichert werden. Manuelles Erfassen von Informationen und Eingeben der Daten in ein Konfigurationsmanagement-Tool ist ermüdend und fehleranfällig.

Die zum Vorbereiten des Servers, Erfassen der Konfiguration sowie zum Konfigurieren und Bereitstellen von Ceph erforderlichen Schritte sind weitgehend dieselben. Dies trifft jedoch nicht auf das Verwalten der unterschiedlichen Funktionen zu. Bei täglich anfallenden Vorgängen braucht man unbedingt die Möglichkeit, Hardware problemlos zu einer vorliegenden Funktion hinzuzufügen und sie wieder zu entfernen.

DeepSea setzt hierfür folgende Strategie ein: DeepSea konsolidiert die Entscheidungen des Administrators in einer einzelnen Datei. Zu den Entscheidungen zählen Cluster-Zuweisung, Rollenzuweisung und Profilzuweisung. Und DeepSea fasst jede Aufgabengruppe zu einem einfachen Ziel zusammen. Jedes Ziel ist eine Phase:

Beschreibung von DeepSea-Phasen
  • Phase 0Vorbereitung – in dieser Phase werden alle erforderlichen Updates angewendet und Ihr System wird möglicherweise neugestartet.

    Wichtig
    Wichtig: Erneute Ausführung der Phase 0 nach dem Neustart des Admin Nodes

    Wenn in Phase 0 der Admin Node neu startet, um die neue Kernel-Version zu laden, müssen Sie Phase 0 erneut ausführen, ansonsten werden die Minions nicht adressiert.

  • Phase 1 – die Ermittlung – hier wird die gesamte Hardware im Cluster erkannt und die erforderlichen Informationen für die Ceph-Konfiguration werden zusammengestellt. Ausführliche Informationen zur Konfiguration finden Sie in Abschnitt 5.5, „Konfiguration und Anpassung“.

  • Phase 2Konfiguration – Konfigurationsdaten müssen in einem bestimmten Format vorbereitet werden.

  • Phase 3Bereitstellung – erstellt einen einfachen Ceph Cluster mit obligatorischen Ceph Services. Eine Liste der Services finden Sie in Abschnitt 1.2.3, „Ceph Nodes und Daemons“.

  • Phase 4Services– zusätzliche Funktionen von Ceph wie iSCSI, Object Gateway und CephFS können in dieser Phase installiert werden. Jede der Funktionen ist optional.

  • Phase 5 – Entfernen. Diese Phase ist nicht obligatorisch und bei der ersten Einrichtung normalerweise nicht erforderlich. In dieser Phase werden die Rollen der Minions und auch die Cluster-Konfiguration entfernt. Sie müssen diese Phase ausführen, wenn Sie einen Speicher-Node von Ihrem Cluster entfernen müssen. Weitere Informationen finden Sie im Abschnitt 2.3, „Entfernen und erneute Installation von Cluster Nodes“.

5.2.1 Organisation und wichtige Standorte Edit source

Salt wendet für Ihren Master Node einige standardmäßige Standorte und Benennungskonventionen an:

/srv/pillar

In diesem Verzeichnis werden Konfigurationsdaten für Ihre Cluster Minions gespeichert. Pillar ist eine Schnittstelle zum Bereitstellen globaler Konfigurationswerte für alle Cluster Minions.

/srv/salt/

In diesem Verzeichnis speichert Salt die Zustandsdateien (auch sls-Dateien genannt). Zustandsdateien sind formatierte Beschreibungen zum Zustand, in dem sich der Cluster befinden sollte.

/srv/module/runners

In diesem Verzeichnis werden Python-Skripts gespeichert, die als Ausführungsprogramme (runner) bezeichnet werden. Die Ausführungsprogramme werden im Master Node ausgeführt.

/srv/salt/_modules

In diesem Verzeichnis werden Python-Skripts gespeichert, die als Module bezeichnet werden. Die Module werden auf alle Minions in Ihrem Cluster angewendet.

/srv/pillar/ceph

Dieses Verzeichnis wird von DeepSea verwendet. Erfasste Konfigurationsdaten werden hier gespeichert.

/srv/salt/ceph

Ein von DeepSea verwendetes Verzeichnis. In ihm werden sls-Dateien gespeichert, die unterschiedliche Formate aufweisen, doch jedes Unterverzeichnis enthält sls-Dateien. Jedes Unterverzeichnis enthält nur einen Typ von sls-Datei. Beispiel: /srv/salt/ceph/stage enthält Orchestrierungsdateien, die durch salt-run state.orchestrate ausgeführt werden.

5.2.2 Adressieren der Minions Edit source

DeepSea-Kommandos werden über die Salt-Infrastruktur ausgeführt. Für das salt-Kommando müssen Sie eine Gruppe von Salt Minions angeben, auf die das Kommando zutreffen soll. Wir beschreiben diese Gruppe von Minions als target für das salt-Kommando. In den folgenden Abschnitten werden mögliche Methoden zum Adressieren der Minions beschrieben.

5.2.2.1 Abgleichen des Minion-Namens Edit source

Sie können einen Minion oder eine Gruppe von Minions adressieren, indem Sie deren Namen abgleichen. Der Name eines Minions ist normalerweise der kurze Hostname des Nodes, in dem die Minions ausgeführt werden. Diese Adressierungsmethode ist für Salt spezifisch und trifft nicht auf DeepSea zu. Sie können den Bereich der Minion-Namen durch Verwenden von Platzhaltern, reguläre Ausdrücke oder Listen eingrenzen. Im Allgemeinen sieht die Syntax folgendermaßen aus:

root@master # salt target example.module
Tipp
Tipp: Nur im Ceph Cluster

Wenn alle Salt Minions in Ihrer Umgebung zu Ihrem Ceph Cluster gehören, können Sie target problemlos durch "*" ersetzen, um alle registrierten Minions einzubeziehen.

Gleichen Sie alle Minions in der Domäne "example.net" ab (unter der Annahme, dass alle Minion-Namen mit den "vollständigen" Hostnamen identisch sind):

root@master # salt '*.example.net' test.ping

Gleichen Sie die "web1"- bis "web5"-Minions ab:

root@master # salt 'web[1-5]' test.ping

Gleichen Sie sowohl die "web1-prod"- als auch die "web1-devel"-Minions mit einem regulären Ausdruck ab.

root@master # salt -E 'web1-(prod|devel)' test.ping

Gleichen Sie eine einfache Liste von Minions ab:

root@master # salt -L 'web1,web2,web3' test.ping

Gleichen Sie alle Minions im Cluster ab:

root@master # salt '*' test.ping

5.2.2.2 Adressieren mithilfe eines DeepSea Grains Edit source

In einer heterogenen, mit Salt verwalteten Umgebung, in der SUSE Enterprise Storage 6 auf einer Untergruppe von Knoten neben anderen Cluster-Lösungen installiert ist, müssen Sie die relevanten Minions mithilfe eines „deepsea“ Grains markieren, bevor Sie die DeepSea-Phase 0 ausführen. Auf diese Weise werden DeepSea Minions leicht in Umgebungen adressiert, in denen der Abgleich anhand des Minion-Namens problematisch ist.

Führen Sie zum Anwenden des „deepsea“ Grain auf eine Gruppe von Minions folgendes Kommando aus:

root@master # salt target grains.append deepsea default

Führen Sie zum Entfernen des „deepsea“ Grain von einer Gruppe von Minions folgendes Kommando aus:

root@master # salt target grains.delval deepsea destructive=True

Nach Anwenden des „deepsea“ Grain auf die relevanten Minions adressieren Sie diese wie folgt:

root@master # salt -G 'deepsea:*' test.ping

Das folgende Kommando funktioniert gleichermaßen:

root@master # salt -C 'G@deepsea:*' test.ping

5.2.2.3 Festlegen der Option deepsea_minions Edit source

Für die DeepSea-Bereitstellungen muss das Ziel der Option deepsea_minions festgelegt werden. DeepSea gibt den Minions während der Ausführung der Phasen darüber Anweisungen (weitere Informationen hierzu finden Sie in der Beschreibung von DeepSea-Phasen).

Bearbeiten Sie zum Festlegen oder Ändern der Option deepsea_minions die Datei /srv/pillar/ceph/deepsea_minions.sls auf dem Salt Master und fügen Sie die folgende Zeile hinzu oder ersetzen Sie sie:

deepsea_minions: target
Tipp
Tipp: deepsea_minions Target

Als target für die Option deepsea_minions können Sie eine der beiden Adressierungsmethoden anwenden: Abgleichen des Minion-Namens und Adressieren mithilfe eines DeepSea Grains.

Gleichen Sie alle Salt Minions im Cluster ab:

deepsea_minions: '*'

Gleichen Sie alle Minions mit „deepsea“ Grain ab:

deepsea_minions: 'G@deepsea:*'

5.2.2.4 Weiterführende Informationen Edit source

Über die Salt-Infrastruktur können Sie anspruchsvollere Methoden zur Adressierung von Minions anwenden. Auf der Handbuchseite „deepsea-minions“ finden Sie außerdem weitere Informationen zur DeepSea-Adressierung (man 7 deepsea_minions).

5.3 Cluster-Bereitstellung Edit source

Der Cluster-Bereitstellungsprozess besteht aus mehreren Phasen. Zunächst müssen Sie alle Nodes des Clusters durch Konfigurieren von Salt vorbereiten und dann Ceph bereitstellen und konfigurieren.

Tipp
Tipp: Bereitstellen von Monitor Nodes ohne OSD-Profile zu definieren

Wenn Sie die Definition der OSD-Speicherrollen gemäß Abschnitt 5.5.1.2, „Rollenzuweisung“ überspringen und die Monitor Nodes vorher bereitstellen müssen, können Sie dazu die Variable DEV_ENV festlegen.

Dies ermöglicht die Bereitstellung von Monitors, auch wenn das Verzeichnisrole-storage/ nicht vorhanden ist, sowie die Bereitstellung eines Ceph Clusters mit mindestens einer Speicher-, Monitor- und Manager-Rolle.

Zum Festlegen der Umgebungsvariable aktivieren Sie diese entweder global, indem Sie sie in Datei /srv/pillar/ceph/stack/global.yml festlegen, oder sie legen sie nur für die aktuelle Shell-Sitzung fest:

root@master # export DEV_ENV=true

Als Beispiel kann /srv/pillar/ceph/stack/global.yml mit dem folgenden Inhalt erstellt werden:

DEV_ENV: True

Das folgende Verfahren beschreibt die Cluster-Vorbereitung im Detail.

  1. Installieren und registrieren Sie SUSE Linux Enterprise Server 15 SP1 zusammen mit der SUSE Enterprise Storage 6-Erweiterung auf jedem Node des Clusters.

  2. Verifizieren Sie, dass die entsprechenden Produkte installiert und registriert sind. Listen Sie dazu die bestehenden Software-Repositorys auf. Führen Sie zypper lr -E aus und vergleichen Sie die Ausgabe mit folgender Liste:

     SLE-Product-SLES15-SP1-Pool
     SLE-Product-SLES15-SP1-Updates
     SLE-Module-Server-Applications15-SP1-Pool
     SLE-Module-Server-Applications15-SP1-Updates
     SLE-Module-Basesystem15-SP1-Pool
     SLE-Module-Basesystem15-SP1-Updates
     SUSE-Enterprise-Storage-6-Pool
     SUSE-Enterprise-Storage-6-Updates
  3. Konfigurieren Sie Netzwerkeinstellungen einschließlich der ordnungsgemäßen DNS-Namensauflösung auf jedem Node. Der Salt Master und alle Salt Minions müssen sich gegenseitig anhand ihrer Hostnamen auflösen. Weitere Informationen zum Konfigurieren eines Netzwerks finden Sie unter https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_network_yast.html. Weitere Informationen zum Konfigurieren eines DNS Servers finden Sie unter https://www.suse.com/documentation/sles-15/book_sle_admin/data/cha_dns.html.

  4. Wählen Sie mindestens einen Zeitserver/Pool aus und synchronisieren Sie die lokale Zeit damit. Prüfen Sie bei jedem Starten des Systems, ob der Zeitsynchronisierungsservice aktiviert ist. Mit dem Kommando yast ntp-client in einem Paket yast2-ntp-client können Sie die Zeitsynchronisierung konfigurieren.

    Tipp
    Tipp

    Virtuelle Maschinen sind keine zuverlässigen NTP-Quellen.

    Weitere Informationen zum Einrichten von NTP finden Sie unter https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html.

  5. Installieren Sie die Pakete salt-master und salt-minion im Salt Master Node:

    root@master # zypper in salt-master salt-minion

    Überprüfen Sie, ob der salt-master Service aktiviert und gestartet wurde und aktivieren und starten Sie ihn gegebenenfalls:

    root@master # systemctl enable salt-master.service
    root@master # systemctl start salt-master.service
  6. Falls Sie beabsichtigen, eine Firewall zu verwenden, verifizieren Sie, dass im Salt Master Node die Ports 4505 und 4506 für alle Salt Minion Nodes offen sind. Wenn die Ports geschlossen sind, können Sie diese mit dem Kommando yast2 firewall öffnen, indem Sie den SaltStack Service zulassen.

    Warnung
    Warnung: DeepSea-Phasen werden bei aktiver Firewall nicht durchgeführt

    Die DeepSea-Phasen zur Bereitstellung werden nicht ausgeführt, wenn die Firewall aktiv ist (und sogar konfiguriert). Um die Phasen korrekt abzuschließen, müssen Sie entweder die Firewall durch Ausführen von

        root # systemctl stop firewalld.service

    ausschalten oder die Option FAIL_ON_WARNING in /srv/pillar/ceph/stack/global.yml auf „False“ festlegen:

    FAIL_ON_WARNING: False
  7. Installieren Sie das Paket salt-minion in allen Minion Nodes.

    root@minion > zypper in salt-minion

    Vergewissern Sie sich, dass der vollqualifizierte Domänenname eines Nodes von allen anderen Nodes zur IP-Adresse des öffentlichen Netzwerks aufgelöst werden kann.

  8. Konfigurieren Sie alle Minions (einschließlich des Master Minion) zur Herstellung einer Verbindung zum Master. Wenn Ihr Salt Master mit dem Hostnamen salt nicht erreichbar ist, bearbeiten Sie die Datei /etc/salt/minion oder erstellen Sie eine neue Datei /etc/salt/minion.d/master.conf mit folgendem Inhalt:

    master: host_name_of_salt_master

    Wenn Sie an den oben genannten Konfigurationsdateien Änderungen vorgenommen haben, starten Sie den Salt Service auf allen Salt Minions neu:

    root@minion > systemctl restart salt-minion.service
  9. Überprüfen Sie, ob der salt-minion Service in allen Nodes aktiviert und gestartet wurde. Aktivieren und starten Sie ihn, falls erforderlich:

    root # systemctl enable salt-minion.service
    root # systemctl start salt-minion.service
  10. Verifizieren Sie den Fingerabdruck der einzelnen Salt Minions und akzeptieren Sie alle Salt-Schlüssel am Salt Master, wenn die Fingerabdrücke übereinstimmen.

    Anmerkung
    Anmerkung

    Wenn ein leerer Fingerabdruck des Salt Minions zurückgegeben wird, prüfen Sie, ob der Salt Minion eine Salt Master-Konfiguration umfasst und ob der Minion mit dem Salt Master kommunizieren kann.

    Zeigen Sie den Fingerabdruck der einzelnen Minions an:

    root@master # salt-call --local key.finger
    local:
    3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    Nachdem Sie die Fingerabdrücke aller Salt Minions gesammelt haben, listen Sie die Fingerabdrücke aller nicht akzeptierten Minion-Schlüssel am Salt Master auf:

    root@master # salt-key -F
    [...]
    Unaccepted Keys:
    minion1:
    3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    Wenn die Fingerabdrücke der Minions übereinstimmen, akzeptieren Sie sie:

    root@master # salt-key --accept-all
  11. Verifizieren Sie, dass die Schlüssel akzeptiert wurden:

    root@master # salt-key --list-all
  12. Löschen Sie alle Datenträger vor der Bereitstellung von SUSE Enterprise Storage 6 manuell. Denken Sie daran, „X“ durch den korrekten Festplattenbuchstaben zu ersetzen:

    1. Stoppen Sie alle Prozesse, die die spezifische Festplatte verwenden.

    2. Verifizieren Sie, ob eine Partition auf der Festplatte eingehängt ist, und hängen Sie sie gegebenenfalls aus.

    3. Wenn die Festplatte von LVM verwaltet wird, deaktivieren und löschen Sie die gesamte LVM-Infrastruktur. Weitere Informationen finden Sie in https://www.suse.com/documentation/sles-15/book_storage/data/cha_lvm.html.

    4. Wenn die Festplatte Teil von MD RAID ist, deaktivieren Sie RAID. Weitere Informationen finden Sie in https://www.suse.com/documentation/sles-15/book_storage/data/part_software_raid.html.

    5. Tipp
      Tipp: Server neustarten

      Wenn Sie in den folgenden Schritten Fehlermeldungen erhalten wie „Partition wird verwendet“ oder „Kernel kann nicht mit der neuen Partitionstabelle aktualisiert werden“, dann starten Sie den Server neu.

      Löschen Sie den Anfang der einzelnen Partitionen (als root):

      for partition in /dev/sdX[0-9]*
      do
        dd if=/dev/zero of=$partition bs=4096 count=1 oflag=direct
      done
    6. Löschen Sie den Anfang des Laufwerks:

      root # dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct
    7. Löschen Sie das Ende des Laufwerks:

      root # dd if=/dev/zero of=/dev/sdX bs=512 count=33 \
        seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct
    8. Prüfen Sie mit folgendem Kommando, ob das Laufwerk leer ist (keine GPT-Strukturen enthält):

      root # parted -s /dev/sdX print free

      oder

      root # dd if=/dev/sdX bs=512 count=34 | hexdump -C
      root # dd if=/dev/sdX bs=512 count=33 \
        skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C
  13. Optional: Wenn Sie die Einstellungen des Clusters vorkonfigurieren müssen, bevor das Paket deepsea installiert wurde, erstellen Sie /srv/pillar/ceph/stack/ceph/cluster.yml manuell und legen Sie die Optionen cluster_network: und public_network: fest. Die Datei wird nach der Installation von deepseanicht überschrieben.

    Tipp
    Tipp: Aktivieren von IPv6

    Wenn Sie die IPv6-Netzwerkadressierung aktivieren müssen, beachten Sie Abschnitt 7.2.1, „Aktivieren von IPv6 für die Ceph Cluster-Implementierung“

  14. Installieren Sie DeepSea im Salt Master Node:

    root@master # zypper in deepsea
  15. Der Wert für den Parameter master_minionwird aus der Datei /etc/salt/minion_id auf dem Salt Master abgeleitet. Wenn Sie den ermittelten Wert überschreiben müssen, bearbeiten Sie die Datei /srv/pillar/ceph/stack/global.yml und legen Sie einen relevanten Wert fest:

    master_minion: MASTER_MINION_NAME

    Wenn der Salt Master über mehrere Hostnamen erreichbar ist, verwenden Sie den Salt Minion-Namen für den Speicher-Cluster, der vom Kommando salt-key -L zurückgegeben wurde. Wenn Sie den Standard-Hostnamen für Ihren Salt Master (salt) in der ses-Domäne verwendet haben, dann sieht die Datei folgendermaßen aus:

    master_minion: salt.ses

Nun stellen Sie Ceph bereit und konfigurieren es. Alle Schritte sind obligatorisch, falls nicht anders angegeben.

Anmerkung
Anmerkung: Salt-Kommandokonventionen

Sie haben zwei Möglichkeiten zum Ausführen von salt-run state.orch: zum einen mit „stage.STAGE_NUMBER“, zum anderen mit dem Namen der Phase. Beide Schreibweisen haben dieselbe Wirkung. Es liegt ganz bei Ihnen, welches Kommando Sie verwenden.

Prozedur 5.1: Ausführen von Bereitstellungsphasen
  1. Prüfen Sie, ob die Salt Minions im Ceph Cluster ordnungsgemäß über die Option deepsea_minions in /srv/pillar/ceph/deepsea_minions.sls adressiert sind. Weitere Informationen finden Sie unter Abschnitt 5.2.2.3, „Festlegen der Option deepsea_minions.

  2. 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 muss die Bereitstellung ohne abgestimmte Profile durchgeführt werden. Tragen Sie hierzu die folgenden Zeilen in /srv/pillar/ceph/stack/global.yml ein, bevor Sie die DeepSea-Phasen ausführen:

    alternative_defaults:
     tuned_mgr_init: default-off
     tuned_mon_init: default-off
     tuned_osd_init: default-off
  3. Optional: Erstellen Sie Btrfs Sub-Volumes für /var/lib/ceph/. Dieser Schritt muss vor der DeepSea-Phase 0 ausgeführt werden. Weitere Informationen zum Migrieren vorhandener Verzeichnisse sowie allgemeine weitere Informationen finden Sie in Abschnitt 25.6, „Btrfs-Subvolume für /var/lib/ceph auf Ceph Monitor Nodes“.

    Führen Sie folgende Kommandos für jeden Salt Minion aus:

    root@master # salt 'MONITOR_NODES' saltutil.sync_all
    root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume
    Anmerkung
    Anmerkung

    Mit dem Kommando „Ceph.subvolume“ wird /var/lib/ceph als ein Btrfs-Subvolume für @/var/lib/ceph erstellt.

    Das neue Subvolume wird nun eingehängt und /etc/fstab wird aktualisiert.

  4. Bereiten Sie Ihren Cluster vor. Weitere Informationen finden Sie in Beschreibung von DeepSea-Phasen.

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

    oder

    root@master # salt-run state.orch ceph.stage.prep
    Anmerkung
    Anmerkung: Phasen mit DeepSea CLI ausführen oder überwachen

    Mit DeepSea CLI können Sie den Fortschritt der Phasenausführung in Echtzeit verfolgen. Führen Sie dazu DeepSea CLI im Überwachungsmodus aus oder führen Sie die Phase direkt über DeepSea CLI aus. Weitere Informationen finden Sie im Abschnitt 5.4, „DeepSea CLI“.

  5. In der Ermittlungsphase werden Daten von allen Minions erfasst und Konfigurationsfragmente erstellt, die im Verzeichnis /srv/pillar/ceph/proposals gespeichert sind. Die Daten werden im YAML-Format in SLS- oder YML-Dateien gespeichert.

    Mit folgendem Kommando lösen Sie die Ermittlungsphase aus:

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

    oder

    root@master # salt-run state.orch ceph.stage.discovery
  6. Erstellen Sie nach erfolgreicher Ausführung des vorigen Kommandos eine policy.cfg-Datei in /srv/pillar/ceph/proposals. Weitere Informationen finden Sie im Abschnitt 5.5.1, „Die Datei policy.cfg.

    Tipp
    Tipp

    Wenn Sie die Netzwerkeinstellungen des Clusters ändern müssen, bearbeiten Sie die Datei /srv/pillar/ceph/stack/ceph/cluster.yml und passen Sie die Zeilen an, die mit cluster_network: und public_network: beginnen.

  7. In der Konfigurationsphase wird die policy.cfg-Datei analysiert und die enthaltenen Dateien in der finalen Form zusammengeführt. Auf Cluster und Rolle bezogene Inhalte werden in /srv/pillar/ceph/cluster hinzugefügt, Ceph-spezifische Inhalte dagegen in /srv/pillar/ceph/stack/default.

    Führen Sie folgendes Kommando aus, um die Konfigurationsphase auszulösen:

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

    oder

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

    Der Konfigurationsschritt kann einige Sekunden dauern. Nach Ausführung des Kommandos sehen Sie die Pillar-Daten für die angegebenen Minions (beispielsweise mit Namen ceph_minion1, ceph_minion2 usw.), indem Sie folgendes Kommando ausführen:

    root@master # salt 'ceph_minion*' pillar.items
    Tipp
    Tipp: Bearbeiten des OSD-Layouts

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

    Anmerkung
    Anmerkung: Überschreiben von Standardwerten

    Sobald das Kommando ausgeführt ist, sehen Sie die Standardkonfiguration und können sie entsprechend Ihrer Anforderungen ändern. Weitere Informationen finden Sie im Kapitel 7, Anpassen der Standardkonfiguration.

  8. Nun führen Sie die Bereitstellungsphase aus. In dieser Phase wird der Pillar validiert und die Ceph Monitor und Ceph OSD Daemons werden gestartet:

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

    oder

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

    Die Ausführung des Kommandos kann einige Minuten dauern. Wenn es nicht ausgeführt wird, müssen Sie das Problem beheben und die vorigen Phasen erneut ausführen. Führen Sie nach erfolgreicher Ausführung des Kommandos das folgende Kommando aus, um den Status zu prüfen:

    cephadm@adm > ceph -s
  9. Die letzte Phase der Ceph Cluster-Bereitstellung ist die Services-Phase. Hier instanziieren Sie die gewünschten Services, die aktuell unterstützt werden: iSCSI Gateway, CephFS, Object Gateway, und NFS Ganesha. In dieser Phase werden die erforderlichen Pools, die autorisierenden Schlüsselbunde und Start-Services erstellt. Führen Sie folgendes Kommando aus, um die Phase zu starten:

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

    oder

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

    Je nach Einrichtung kann die Ausführung des Kommandos einige Minuten dauern.

  10. Bevor Sie den Vorgang fortsetzen, wird dringend empfohlen, das Ceph-Telemetriemodul zu aktivieren. Weitere Informationen und Anweisungen finden Sie in Abschnitt 10.2, „Telemetriemodul“.

5.4 DeepSea CLI Edit source

DeepSea stellt auch eine Kommandozeilenschnittstelle (Command Line Interface, CLI) zur Verfügung, mit dem Benutzer Phasen überwachen oder ausführen, während sie den Ausführungsfortschritt in Echtzeit visualisieren. Prüfen Sie, ob das Paket deepsea-cli installiert ist, bevor Sie die ausführbare Datei deepsea ausführen.

Zwei Modi werden zur Visualisierung des Ausführungsfortschritts einer Phase unterstützt:

DeepSea CLI-Modi
  • Überwachungsmodus: visualisiert den Ausführungsfortschritt einer DeepSea-Phase, die vom salt-run-Kommando ausgelöst wurde, das wiederum in einer anderen Terminalsitzung ausgestellt wurde.

  • Stand-Alone-Modus: führt eine DeepSea-Phase aus bei gleichzeitiger Echtzeit-Visualisierung der Komponentenschritte während ihrer Ausführung.

Wichtig
Wichtig: DeepSea CLI-Kommandos

Die DeepSea CLI-Kommandos können nur auf dem Salt Master Node ausgeführt werden und es sind root-Berechtigungen dazu erforderlich.

5.4.1 DeepSea CLI: Überwachungsmodus Edit source

Die Fortschrittsüberwachung bietet eine detaillierte Echtzeit-Visualisierung der Vorgänge bei der Ausführung von Phasen mit salt-run state.orch-Kommandos in anderen Terminalsitzungen.

Tipp
Tipp: Starten der Überwachung in einer neuen Terminalsitzung

Sie müssen die Überwachung in einem neuen Terminalfenster starten, bevor Sie ein salt-run state.orch-Kommando ausführen, damit die Überwachung den Start der Phasenausführung erkennt.

Wenn Sie die Überwachung nach Ausgabe des Kommandos salt-run state.orch starten, wird kein Ausführungsfortschritt angezeigt.

Sie können den Überwachungsmodus durch Ausführen des folgenden Kommandos starten:

root@master # deepsea monitor

Weitere Informationen zu den verfügbaren Kommandozeilenoptionen des deepsea monitor-Kommandos finden Sie auf der entsprechenden Handbuchseite:

root@master # man deepsea-monitor

5.4.2 DeepSea CLI: Stand-Alone-Modus Edit source

Im Stand-Alone-Modus wird über DeepSea CLI eine DeepSea-Phase ausgeführt und die Ausführung wird in Echtzeit angezeigt.

Das Kommando zur Ausführung einer DeepSea-Phase an der DeepSea CLI weist folgende Form auf:

root@master # deepsea stage run stage-name

stage-name stellt dabei die Methode dar, wie die Zustandsdateien der Salt-Orchestrierung referenziert werden. Beispiel: Phase Ermittlung, die dem Verzeichnis in Pfad /srv/salt/ceph/stage/deploy entspricht, wird als ceph.stage.deploy referenziert.

Dieses Kommando stellt eine Alternative zu den Salt-basierten Kommandos zur Ausführung von DeepSea-Phasen (oder von Zustandsdateien der DeepSea-Orchestrierung) dar.

Das Kommando deepsea stage run ceph.stage.0 entspricht salt-run state.orch ceph.stage.0.

Weitere Informationen zu den verfügbaren Kommandozeilenoptionen, die vom deepsea stage run-Kommando akzeptiert werden, finden Sie auf der entsprechenden Handbuchseite:

root@master # man deepsea-stage run

Die folgende Abbildung zeigt ein Beispiel der Ausgabe der DeepSea CLI bei Ausführung von Phase 2:

Ausgabe des Fortschritts der Phasenausführung an der DeepSea CLI
Abbildung 5.1: Ausgabe des Fortschritts der Phasenausführung an der DeepSea CLI

5.4.2.1 DeepSea CLI-Alias für stage run Edit source

Für fortgeschrittene Benutzer von Salt unterstützen wir einen Alias für die Ausführung einer DeepSea-Phase. Dieser betrachtet das Salt-Kommando, das zur Ausführung einer Phase verwendet wird (beispielsweise salt-run state.orch stage-name) als Kommando der DeepSea CLI.

Beispiel:

root@master # deepsea salt-run state.orch stage-name

5.5 Konfiguration und Anpassung Edit source

5.5.1 Die Datei policy.cfg Edit source

Mit der Konfigurationsdatei /srv/pillar/ceph/proposals/policy.cfg werden Rollen einzelner Cluster Nodes ermittelt. Beispiel: Welche Knoten fungieren als Ceph OSDs oder Ceph Monitors? Bearbeiten Sie policy.cfg, um die gewünschte Cluster-Einrichtung widerzuspiegeln. Die Reihenfolge der Abschnitte ist beliebig, doch der Inhalt der enthaltenen Zeilen überschreibt die passenden Schlüssel vom Inhalt der vorigen Zeilen.

Tipp
Tipp: Beispiele für policy.cfg

Sie finden verschiedene Beispiele von fertiggestellten Richtliniendateien im Verzeichnis /usr/share/doc/packages/deepsea/examples/.

5.5.1.1 Cluster-Zuweisung Edit source

Im Abschnitt cluster wählen Sie Minions für Ihren Cluster aus. Sie können alle Minions auswählen oder Minions auf eine Blacklist oder Whitelist setzen. Beispiele für einen Cluster namens ceph folgen.

Fügen Sie die folgenden Zeilen hinzu, um alle Minions einzubeziehen:

cluster-ceph/cluster/*.sls

So setzen Sie einen bestimmten Minion auf eine weiße Liste:

cluster-ceph/cluster/abc.domain.sls

oder eine Gruppe von Minions, mit Shell Glob-Abgleich:

cluster-ceph/cluster/mon*.sls

Um Minions auf eine schwarze Liste zu setzen, legen Sie sie als unassigned (nicht zugewiesen) fest:

cluster-unassigned/cluster/client*.sls

5.5.1.2 Rollenzuweisung Edit source

In diesem Abschnitt erhalten Sie detaillierte Informationen zur Zuweisung von „Rollen“ zu Ihren Cluster Nodes. Eine „Rolle“ bezeichnet in diesem Kontext einen Service, den Sie zur Ausführung im Node benötigen, z. B. Ceph Monitor, Object Gateway oder iSCSI-Gateway. Keine Rolle wird automatisch zugewiesen. Es werden nur Rollen bereitgestellt, die zu policy.cfg hinzugefügt wurden.

Die Zuweisung erfolgt nach dem folgenden Muster:

role-ROLE_NAME/PATH/FILES_TO_INCLUDE

Die einzelnen Elemente haben die folgende Bedeutung und Werte:

  • ROLE_NAME bezeichnet eines der folgenden Elemente: „master“, „admin“, „mon“, „mgr“, „storage“, „mds“, „igw“, „rgw“, „ganesha“, „grafana“ oder „prometheus“.

  • PATH ist ein relativer Verzeichnispfad zu SLS- oder YML-Dateien. Bei SLS-Dateien lautet er normalerweise cluster, YML-Dateien befinden sich unter stack/default/ceph/minions.

  • FILES_TO_INCLUDE bezeichnet die Salt-Zustandsdateien oder die YAML-Konfigurationsdateien. Sie bestehen normalerweise aus den Hostnamen der Salt Minions, beispielsweise ses5min2.yml. Ein weiterer spezifischen Abgleich kann über Shell Globbing erfolgen.

Nachfolgend sehen Sie ein Beispiel für jede Rolle:

  • master - der Node hat Admin-Schlüsselbunde zu allen Ceph Clustern. Aktuell wird nur ein einzelner Ceph Cluster unterstützt. Da die master-Rolle obligatorisch ist, fügen Sie immer eine ähnliche Zeile wie die folgende hinzu:

    role-master/cluster/master*.sls
  • admin - der Minion verfügt über einen Admin-Schlüsselbund. Sie definieren die Rolle wie folgt:

    role-admin/cluster/abc*.sls
  • mon – der Minion stellt den Überwachungs-Service für den Ceph Cluster zur Verfügung. Diese Rolle benötigt Adressen der zugewiesenen Minions. Ab SUSE Enterprise Storage 5 werden die öffentlichen Adressen dynamisch berechnet und sind im Salt Pillar nicht mehr erforderlich.

    role-mon/cluster/mon*.sls

    Im Beispiel wird die Überwachungsrolle einer Gruppe von Minions zugewiesen.

  • mgr - der Ceph Manager Daemon, der alle Zustandsinformationen des gesamten Clusters erfasst. Stellen Sie ihn auf allen Minions bereit, auf denen Sie die Ceph Monitor-Rolle bereitstellen möchten.

    role-mgr/cluster/mgr*.sls
  • storage – mit dieser Rolle geben Sie bestimmte Speicher-Nodes an.

    role-storage/cluster/data*.sls
  • mds - der Minion stellt den Metadaten-Service zur Unterstützung von CephFS bereit.

    role-mds/cluster/mds*.sls
  • igw - der Minion fungiert als iSCSI Gateway. Diese Rolle benötigt Adressen der zugewiesenen Minions. Daher müssen Sie auch die Dateien aus dem stack-Verzeichnis hinzufügen:

    role-igw/cluster/*.sls
  • rgw - der Minion fungiert als Object Gateway.

    role-rgw/cluster/rgw*.sls
  • ganesha - der Minion fungiert als NFS Ganesha Server. Für die „ganesha“-Rolle ist eine „rgw“- oder „mds“-Rolle im Cluster erforderlich. Andernfalls wird die Validierung in Phase 3 nicht durchgeführt.

    role-ganesha/cluster/ganesha*.sls

    Für die erfolgreiche Installation von NFS Ganesha ist eine weitere Konfiguration erforderlich. Wenn Sie NFS Ganesha verwenden möchten, lesen Sie Kapitel 12, Installation von NFS Ganesha, bevor Sie Phase 2 und 4 ausführen. Es ist jedoch möglich, NFS Ganesha später zu installieren.

    In einigen Fällen kann es nützlich sein, benutzerdefinierte Rollen für NFS Ganesha Nodes zu definieren. Weitere Informationen finden Sie in Abschnitt 21.3, „Benutzerdefinierte NFS Ganesha-Rollen“.

  • grafana, prometheus – dieser Knoten fügt Grafana-Diagramme auf der Grundlage der Prometheus-Warnmeldungen in das Ceph Dashboard ein. Eine ausführliche Beschreibung finden Sie in Kapitel 22, Ceph Dashboard.

    role-grafana/cluster/grafana*.sls
    role-prometheus/cluster/prometheus*.sls
Anmerkung
Anmerkung: Mehrere Rollen von Cluster Nodes

Sie können einem einzelnen Node verschiedene Rollen zuweisen. Beispielsweise können Sie die „mds“-Rollen zu Monitor Nodes zuweisen:

role-mds/cluster/mon[1,2]*.sls

5.5.1.3 Allgemeine Konfiguration Edit source

Im Abschnitt zur allgemeinen Konfiguration sind Konfigurationsdateien enthalten, die in der Phase der Ermittlung (Phase 1) generiert wurden. In diesen Konfigurationsdateien werden Parameter wie fsid oder public_network gespeichert. Fügen Sie die folgenden Zeilen hinzu, um die erforderliche allgemeine Ceph-Konfiguration einzubeziehen:

config/stack/default/global.yml
config/stack/default/ceph/cluster.yml

5.5.1.4 Filtern von Elementen Edit source

Manchmal ist es nicht praktisch, alle Dateien eines vorliegenden Verzeichnisses zum *.sls Globbing hinzuzufügen. Das Dateianalyseprogramm policy.cfg versteht die folgenden Filter:

Warnung
Warnung: Erweiterte Methoden

In diesem Abschnitt werden Filtermethoden für fortgeschrittene Benutzer beschrieben. Wenn die Filter nicht korrekt verwendet werden, können sie Probleme verursachen, beispielsweise wenn sich die Node-Nummerierung ändert.

slice=[start:end]

Mit dem Slice-Filter beziehen Sie nur die Elemente start bis end-1 ein. Beachten Sie, dass die im vorliegenden Verzeichnis vorhandenen Elemente alphanumerisch sortiert sind. Die folgende Zeile enthält die dritte bis fünfzigste Datei des Unterverzeichnisses role-mon/cluster/:

role-mon/cluster/*.sls slice[3:6]
re=regexp

Mit dem regex Filter werden nur Elemente einbezogen, die den vorliegenden regulären Ausdrücken entsprechen. Beispiel:

role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$

5.5.1.5 Beispiel einer policy.cfg-Datei Edit source

Nachfolgend sehen Sie ein Beispiel einer einfachen policy.cfg-Datei:

## Cluster Assignment
cluster-ceph/cluster/*.sls 1

## Roles
# ADMIN
role-master/cluster/examplesesadmin.sls 2
role-admin/cluster/sesclient*.sls 3

# MON
role-mon/cluster/ses-example-[123].sls 4

# MGR
role-mgr/cluster/ses-example-[123].sls 5

# STORAGE
role-storage/cluster/ses-example-[5,6,7,8].sls 6

# MDS
role-mds/cluster/ses-example-4.sls 7

# IGW
role-igw/cluster/ses-example-4.sls 8

# RGW
role-rgw/cluster/ses-example-4.sls 9

# COMMON
config/stack/default/global.yml 10
config/stack/default/ceph/cluster.yml 11

1

Gibt an, dass alle Minions im Ceph Cluster enthalten sind. Wenn Sie über Minions verfügen, die nicht im Ceph Cluster enthalten sein sollen, verwenden Sie:

cluster-unassigned/cluster/*.sls
cluster-ceph/cluster/ses-example-*.sls

Die erste Zeile kennzeichnet alle Minions als nicht zugewiesen. Die zweite Zeile überschreibt Minions, die "ses-example-*.sls" entsprechen, und weist sie dem Ceph Cluster zu.

2

Der Minion namens „examplesesadmin“ verfügt über die „master“-Rolle. Dies bedeutet übrigens, dass er Admin-Schlüssel für den Cluster erhält.

3

Alle Minions, die "sesclient*" entsprechen, erhalten ebenfalls Admin-Schlüssel.

4

Alle Minions, die "ses-example-[123]" entsprechen (vermutlich drei Minions: ses-example-1, ses-example-2 und ses-example-3), werden als MON Nodes eingerichtet.

5

Alle Minions, die "ses-example-[123]" entsprechen (alle MON Nodes in diesem Beispiel), werden als MGR-Nodes eingerichtet.

6

Alle Minions, die „ses-example-[5,6,7,8]“ entsprechen, werden als Speicher-Nodes eingerichtet.

7

Minion "ses-example-4" erhält die MDS-Rolle.

8

Minion "ses-example-4" erhält die IGW-Rolle.

9

Minion "ses-example-4" erhält die RGW-Rolle.

10

Bedeutet, dass wir die Standardwerte für allgemeine Konfigurationsparameter wie fsid und public_network akzeptieren.

11

Bedeutet, dass wir die Standardwerte für allgemeine Konfigurationsparameter wie fsid und public_network akzeptieren.

5.5.2 DriveGroups Edit source

DriveGroups bestimmen das Layout der OSDs im Ceph Cluster. Sie sind in einer einzelnen Datei definiert (/srv/salt/ceph/configuration/files/drive_groups.yml).

Ein Administrator muss manuell eine Gruppe von OSDs erstellen, die zusammenhängen (Hybrid-OSDs, die auf Solid-State-Laufwerken und rotierenden Datenträgern implementiert sind) oder dieselben Implementierungsoptionen aufweisen (identisch, z. B. gleicher Objektspeicher, gleiche Verschlüsselungsoption, Stand-Alone-OSDs). Damit die Geräte nicht explizit aufgelistet werden müssen, werden sie in den DriveGroups anhand einer Liste von Filterelementen gefiltert, die einigen wenigen ausgewählten Feldern in den ceph-volume-Bestandsberichten entsprechen. Im einfachsten Fall ist dies die „rotierende“ Flagge (alle Solid-State-Laufwerke müssen db_devices sein, alle rotierenden Laufwerke dagegen Datengeräte), alternativ und etwas aufwendiger sind z. B. „Modell“-Zeichenketten oder Größen. Der Code in DeepSea wandelt diese DriveGroups in Gerätelisten um, die dann vom Benutzer geprüft werden können.

Dieses einfache Verfahren veranschaulicht den grundlegenden Workflow beim Konfigurieren der DriveGroups:

  1. Prüfen Sie die Eigenschaften Ihrer Datenträger, die vom Kommando ceph-volume zurückgegeben wurden. DriveGroups akzeptieren ausschließlich folgende Eigenschaften:

    root@master # salt-run disks.details
  2. Öffnen Sie die YAML-Datei /srv/salt/ceph/configuration/files/drive_groups.yml und passen Sie sie an Ihre Anforderungen an. Weitere Informationen finden Sie unter Abschnitt 5.5.2.1, „Spezifikation“. Denken Sie daran, Leerzeichen anstelle von Tabulatoren anzugeben. Ausführliche Beispiele finden Sie in Abschnitt 5.5.2.4, „Beispiele“ Das folgende Beispiel umfasst alle Datenträger, die in Ceph als OSDs verfügbar sind:

    default_drive_group_name:
      target: '*'
      data_devices:
        all: true
  3. Prüfen Sie die neuen Layouts:

    root@master # salt-run disks.list

    Dieses Ausführungsprogramm gibt eine Struktur der passenden Datenträger auf der Grundlage Ihrer DriveGroups zurück. Wenn Sie mit dem Ergebnis nicht zufrieden sind, wiederholen Sie den vorherigen Schritt.

    Tipp
    Tipp: Ausführlicher Bericht

    Neben dem Ausführungsprogramm disks.list steht das Ausführungsprogramm disks.report bereit, das einen detaillierten Bericht über die Abläufe beim nächsten Aufrufen der DeepSea-Phase 3 zurückgibt.

    root@master # salt-run disks.report
  4. Imitieren Sie die OSDs. Beim nächsten Aufrufen der DeepSea-Phase 3 werden die OSD-Datenträger gemäß Ihrer DriveGroups-Spezifikation implementiert.

5.5.2.1 Spezifikation Edit source

/srv/salt/ceph/configuration/files/drive_groups.yml akzeptiert folgende Optionen:

drive_group_default_name:
  target: *
  data_devices:
    drive_spec: DEVICE_SPECIFICATION
  db_devices:
    drive_spec: DEVICE_SPECIFICATION
  wal_devices:
    drive_spec: DEVICE_SPECIFICATION
  block_wal_size: '5G'  # (optional, unit suffixes permitted)
  block_db_size: '5G'   # (optional, unit suffixes permitted)
  osds_per_device: 1   # number of osd daemons per device
  format:              # 'bluestore' or 'filestore' (defaults to 'bluestore')
  encryption:           # 'True' or 'False' (defaults to 'False')

Für FileStore-Einrichtungen kann drive_groups.yml wie folgt aussehen:

drive_group_default_name:
  target: *
  data_devices:
    drive_spec: DEVICE_SPECIFICATION
  journal_devices:
    drive_spec: DEVICE_SPECIFICATION
  format: filestore
  encryption: True

5.5.2.2 Abstimmung von Datenträgergeräten Edit source

Sie können die Spezifikation mit folgenden Filtern beschreiben:

  • Nach Datenträgermodell:

    model: DISK_MODEL_STRING
  • Nach Datenträgerhersteller:

    vendor: DISK_VENDOR_STRING
    Tipp
    Tipp: Hersteller-Zeichenkette

    Geben Sie DISK_VENDOR_STRING stets in Kleinbuchstaben an.

  • Angabe, ob ein rotierender oder ein nicht rotierender Datenträger vorliegt. SSDs und NVME-Laufwerke sind keine rotierenden Datenträger.

    rotational: 0
  • Implementieren Sie einen Knoten mit allen verfügbaren Laufwerken für OSDs:

    data_devices:
      all: true
  • Zusätzlich mit Einschränkung der Anzahl passender Datenträger

    limit: 10

5.5.2.3 Filtern von Geräten nach Größe Edit source

Sie können die Datenträgergeräte nach ihrer Größe filtern – wahlweise nach einer genauen Größenangabe oder einem Größenbereich. Der Parameter size: akzeptiert Argumente wie folgt:

  • „10G“ – Datenträger mit einer bestimmten Größe.

  • „10G:40G“ – Datenträger mit einer Größe im angegebenen Bereich.

  • „:10G“ – Datenträger mit einer Größe von maximal 10 GB.

  • „40G:“ – Datenträger mit einer Größe von mindestens 40 GB.

Beispiel 5.1: Abstimmung nach Datenträgergröße
drive_group_default:
  target: '*'
  data_devices:
    size: '40TB:'
  db_devices:
    size: ':2TB'
Anmerkung
Anmerkung: Anführungszeichen erforderlich

Beim Begrenzer „:“ müssen Sie die Größe in Anführungszeichen setzen, da das Zeichen „:“ ansonsten als neuer Konfiguration-Hash interpretiert wird.

Tipp
Tipp: Abkürzungen für Einheiten

Anstelle von (G)igabyte können Sie die Größen auch in (M)egabyte oder (T)erabyte angeben.

5.5.2.4 Beispiele Edit source

Dieser Abschnitt enthält Beispiele verschiedener OSD-Einrichtungen.

Beispiel 5.2: Einfache Einrichtung

Dieses Beispiel zeigt zwei Knoten mit derselben Einrichtung:

  • 20 HDDs

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 2 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

Die entsprechende Datei drive_groups.yml sieht wie folgt aus:

drive_group_default:
  target: '*'
  data_devices:
    model: SSD-123-foo
  db_devices:
    model: MC-55-44-XZ

Eine solche Konfiguration ist unkompliziert und zulässig. Es stellt sich allerdings das Problem, dass ein Administrator in Zukunft eventuell Datenträger von anderen Herstellern einfügt, die dann nicht berücksichtigt werden. Zur Verbesserung geben Sie weniger Filter für die wesentlichen Eigenschaften der Laufwerke an:

drive_group_default:
  target: '*'
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

Im vorherigen Beispiel wird die Deklaration aller rotierenden Geräte als „Datengeräte“ erzwungen und alle nicht rotierenden Geräte werden als „freigegebene Geräte“ (wal, db) genutzt.

Wenn Laufwerke mit mehr als 2 TB stets als langsamere Datengeräte eingesetzt werden sollen, können Sie nach Größe filtern:

drive_group_default:
  target: '*'
  data_devices:
    size: '2TB:'
  db_devices:
    size: ':2TB'
Beispiel 5.3: Erweiterte Konfiguration

Dieses Beispiel umfasst zwei getrennte Einrichtungen: 20 HDDs sollen gemeinsam 2 SSDs nutzen und 10 SSDs nutzen gemeinsam 2 NVMes.

  • 20 HDDs

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 12 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

  • 2 NVMes

    • Hersteller: Samsung

    • Modell: NVME-QQQQ-987

    • Größe: 256 GB

Eine solche Einrichtung kann wie folgt mit zwei Layouts definiert werden:

drive_group:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: MC-55-44-XZ
drive_group_default:
  target: '*'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    vendor: samsung
    size: 256GB
Beispiel 5.4: Erweiterte Einrichtung mit nicht einheitlichen Knoten

In den vorherigen Beispielen wurde angenommen, dass alle Knoten dieselben Laufwerke umfassen. Dies ist jedoch nicht immer der Fall:

Knoten 1–5:

  • 20 HDDs

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 2 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

Knoten 6–10:

  • 5 NVMes

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 20 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

Mit dem „target“-Schlüssel im Layout können Sie bestimmte Knoten adressieren. Die Salt-Zielnotation trägt zur Vereinfachung bei:

drive_group_node_one_to_five:
  target: 'node[1-5]'
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

gefolgt von:

drive_group_the_rest:
  target: 'node[6-10]'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    model: SSD-123-foo
Beispiel 5.5: Experteneinrichtung

In allen vorherigen Fällen wird angenommen, dass die WALs und DBs dasselbe Gerät nutzen. Es ist jedoch auch möglich, WAL auf einem dedizierten Gerät zu implementieren:

  • 20 HDDs

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 2 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

  • 2 NVMes

    • Hersteller: Samsung

    • Modell: NVME-QQQQ-987

    • Größe: 256 GB

drive_group_default:
  target: '*'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    model: SSD-123-foo
  wal_devices:
    model: NVME-QQQQ-987
Beispiel 5.6: Komplexe (und unwahrscheinliche) Einrichtung

In der folgenden Einrichtung soll Folgendes definiert werden:

  • 20 HDDs mit 1 NVMe

  • 2 HDDs mit 1 SSD(db) und 1 NVMe(wal)

  • 8 SSDs mit 1 NVMe

  • 2 Stand-Alone-SSDs (verschlüsselt)

  • 1 HDD fungiert als Ersatz und soll nicht bereitgestellt werden

Zusammenfassung der verwendeten Datenträger:

  • 23 HDDs

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 10 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

  • 1 NVMe

    • Hersteller: Samsung

    • Modell: NVME-QQQQ-987

    • Größe: 256 GB

Die DriveGroups-Definition lautet:

drive_group_hdd_nvme:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: NVME-QQQQ-987
drive_group_hdd_ssd_nvme:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: MC-55-44-XZ
  wal_devices:
    model: NVME-QQQQ-987
drive_group_ssd_nvme:
  target: '*'
  data_devices:
    model: SSD-123-foo
  db_devices:
    model: NVME-QQQQ-987
drive_group_ssd_standalone_encrypted:
  target: '*'
  data_devices:
    model: SSD-123-foo
  encryption: True

Eine HDD verbleibt, da die Datei von oben nach unten analysiert wird.

5.5.3 Anpassen von ceph.conf mit benutzerdefinierten Einstellungen Edit source

Wenn Sie benutzerdefinierte Einstellungen zur Datei ceph.conf hinzufügen müssen, finden Sie die entsprechenden Informationen dazu im Abschnitt 2.13, „Anpassen von ceph.conf mit benutzerdefinierten Einstellungen“.

Diese Seite drucken