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

4 Bereitstellen mit DeepSea/Salt

Anmerkung
Anmerkung: ceph-deploy in SUSE Enterprise Storage 5 entfernt

Das Cluster-Bereitstellungswerkzeug ceph-deploy wurde in SUSE Enterprise Storage 4 als veraltet gekennzeichnet und ab SUSE Enterprise Storage 5 zugunsten von DeepSea vollständig entfernt.

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-, Metadata Server- oder Ceph Monitor-Rolle nicht auf dem Salt Master 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 4.3, „Cluster-Bereitstellung“.

4.1 Lesen Sie die Versionshinweise

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

4.2 Einführung zu DeepSea

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: Phase 0 nach dem Neustart von Salt Master erneut ausführen

    Wenn in Phase 0 der Salt Master neustartet, um die neue Kernel-Version zu laden, müssen Sie Phase 0 erneut ausführen, ansonsten werden die Minions nicht adressiert.

  • Phase 1Ermittlung – hier ermitteln Sie die gesamte Hardware in Ihrem Cluster und erfassen die erforderlichen Informationen für die Ceph-Konfiguration. Ausführliche Informationen zur Konfiguration finden Sie in Abschnitt 4.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 1.3, „Entfernen und erneute Installation von Cluster Nodes“.

Eine detailliertere Einführung zu DeepSea finden Sie unter https://github.com/suse/deepsea/wiki.

4.2.1 Organisation und wichtige Standorte

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. Weitere Informationen dazu finden Sie in der Salt-Dokumentation.

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

4.2.2 Adressieren der Minions

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 dassalt-Kommando. In den folgenden Abschnitten werden mögliche Methoden zum Adressieren der Minions beschrieben.

4.2.2.1 Abgleichen des Minion-Namens

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

4.2.2.2 Adressieren mithilfe eines "deepsea" Grains

In einer heterogenen Salt-verwalteten Umgebung, in der SUSE Enterprise Storage in einer Teilmenge von Nodes zusammen mit anderen Cluster-Lösungen bereitgestellt wurde, ist es eine gute Idee, die relevanten Minions zu "markieren", indem Sie ein "deepsea" Grain darauf anwenden. Auf diese Weise werden DeepSea Minions leicht in Umgebungen adressiert, in denen der Abgleich anhand es 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

4.2.2.3 Festlegen der Option deepsea_minions

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

4.2.2.4 Weiterführende Informationen

Über die Salt-Infrastruktur können Sie anspruchsvollere Methoden zur Adressierung von Minions anwenden. Unter https://docs.saltstack.com/en/latest/topics/targeting/ finden Sie eine Beschreibung für alle Adressierungsmethoden.

Auf der Handbuchseite "deepsea-minions" finden Sie außerdem weitere Informationen zur DeepSea-Adressierung (man 7 deepsea_minions).

4.3 Cluster-Bereitstellung

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-Profile überspringen und die Monitor Nodes vorher bereitstellen müssen, können Sie dazu die Variable DEV_ENV festlegen. Sie ermöglicht die Bereitstellung von Monitors, auch wenn das Verzeichnisprofile/ nicht vorhanden ist, sowie die Bereitstellung eines Clusters mit mindestens einem Speicher-, Monitor- und Manager-Node.

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

Das folgende Verfahren beschreibt die Cluster-Vorbereitung im Detail.

  1. Installieren und registrieren Sie SUSE Linux Enterprise Server 12 SP3 zusammen mit der SUSE Enterprise Storage-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. Die Liste entspricht in etwa dieser Ausgabe:

     root@minion > zypper lr -E
    #  | Alias   | Name                              | Enabled | GPG Check | Refresh
    ---+---------+-----------------------------------+---------+-----------+--------
     4 | [...]   | SUSE-Enterprise-Storage-5-Pool    | Yes     | (r ) Yes  | No
     6 | [...]   | SUSE-Enterprise-Storage-5-Updates | Yes     | (r ) Yes  | Yes
     9 | [...]   | SLES12-SP3-Pool                   | Yes     | (r ) Yes  | No
    11 | [...]   | SLES12-SP3-Updates                | Yes     | (r ) Yes  | Yes
  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-12/book_sle_admin/data/sec_basicnet_yast.html. Weitere Informationen zum Konfigurieren eines DNS Servers finden Sie unter https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_dns.html.

  4. Konfigurieren, aktivieren und starten Sie den NTP-Zeitsynchronisierungsserver:

    root@master # systemctl enable ntpd.service
    root@master # systemctl start ntpd.service

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

  5. Prüfen Sie, ob der AppArmor Service ausgeführt wird und deaktivieren Sie ihn auf jedem Cluster Node. Starten Sie das YaST AppArmor-Modul, wählen Sie Einstellungen aus und deaktivieren Sie dann das Kontrollkästchen für AppArmor aktivieren. Bestätigen Sie den Vorgang mit Fertig.

    Beachten Sie, dass SUSE Enterprise Storage nicht funktioniert, wenn AppArmor aktiviert ist.

  6. 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
  7. 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@master # systemctl stop SuSEfirewall2.service

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

    FAIL_ON_WARNING: False
  8. 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.

  9. 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
  10. Überprüfen Sie, ob der salt-minion Service in allen Nodes aktiviert und gestartet wurde. Aktivieren und starten Sie ihn, falls erforderlich:

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

    Zeigen Sie den Fingerabdruck der einzelnen Minions an:

    root@minion > 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
  12. Verifizieren Sie, dass die Schlüssel akzeptiert wurden:

    root@master # salt-key --list-all
  13. Vergewissern Sie sich vor Bereitstellung von SUSE Enterprise Storage, dass alle Festplatten, die von früheren Clustern als OSD verwendet wurden, leer sind und keine Partitionen aufweisen. Um dies sicherzustellen, müssen Sie alle Festplatten manuell löschen. 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-12/stor_admin/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-12/stor_admin/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 neustarten Sie den Server.

      Löschen Sie den Anfang jeder Partition:

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

      sgdisk -Z --clear -g /dev/sdX
    7. Löschen Sie die gesicherten Partitionstabellen:

      size=`blockdev --getsz /dev/sdX`
      position=$((size/4096 - 33))
      dd if=/dev/zero of=/dev/sdX bs=4M count=33 seek=$position oflag=direct
  14. Installieren Sie DeepSea im Salt Master Node:

    root@master # zypper in deepsea
  15. Überprüfen Sie, ob die Datei /srv/pillar/ceph/master_minion.sls am Salt Master auf Ihren Salt Master verweist. Wenn Ihr Salt Master über mehrere Hostnamen erreichbar ist, verwenden Sie den Namen, der für den Speicher-Cluster am besten geeignet ist. 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. Die eine ist mit stage.<Phasennummer>, bei der anderen wird der Name der Phase verwendet. Beide Schreibweisen haben dieselbe Wirkung. Es liegt ganz bei Ihnen, welches Kommando Sie verwenden.

Prozedur 4.1: Ausführen von Bereitstellungsphasen
  1. Beziehen Sie die Salt Minions mit ein, die zum Ceph Cluster gehören, den Sie aktuell bereitstellen. In Abschnitt 4.2.2.1, „Abgleichen des Minion-Namens“ finden Sie weitere Informationen zum Adressieren der Minions.

  2. 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 4.4, „DeepSea CLI“.

  3. Optional: Erstellen Sie Btrfs Sub-Volumes für /var/lib/ceph/. Dieser Schritt sollte erst nach Ausführung der nächsten Phasen von DeepSea ausgeführt werden. Informationen zum Migrieren der bestehenden Verzeichnisse oder weitere Details finden Sie im Abschnitt 18.5, „Btrfs Sub-Volume für /var/lib/ceph“.

    root@master # salt-run state.orch ceph.migrate.subvolume
  4. 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.

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

    oder

    root@master # salt-run state.orch ceph.stage.discovery
  5. Erstellen Sie nach erfolgreicher Ausführung des vorigen Kommandos eine policy.cfg-Datei in /srv/pillar/ceph/proposals. Weitere Informationen finden Sie im Abschnitt 4.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.

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

  7. Nun führen Sie die Bereitstellungsphase aus. In dieser Phase wird der Pillar validiert und Monitors und ODS Daemons werden in den Speicher-Nodes gestartet. Führen Sie folgendes Kommando aus, um die Phase zu starten:

    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:

    root@master # ceph -s
  8. 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, openATTIC 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.

4.4 DeepSea CLI

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.

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 im Salt Master Node ausgeführt werden und es sind root-Berechtigungen dazu erforderlich.

4.4.1 DeepSea CLI: Überwachungsmodus

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.

Sie müssen die Überwachung 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

4.4.2 DeepSea CLI: Stand-Alone-Modus

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 4.1: Ausgabe des Fortschritts der Phasenausführung an der DeepSea CLI

4.4.2.1 DeepSea CLI-Alias für stage run

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

4.5 Konfiguration und Anpassung

4.5.1 Die Datei policy.cfg

Mit der Konfigurationsdatei /srv/pillar/ceph/proposals/policy.cfg werden Rollen einzelner Cluster Nodes ermittelt. Beispielsweise welcher Node als OSD fungiert oder welcher als Monitor Node. 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/.

4.5.1.1 Cluster-Zuweisung

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

4.5.1.2 Rollenzuweisung

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, wie zum Beispiel Ceph Monitor, Object Gateway, iSCSI Gateway oder openATTIC. 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", "mds", "igw", "rgw", "ganesha" oder "openattic".

  • 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
  • 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/stack/default/ceph/minions/xyz.domain.yml
    role-igw/cluster/*.sls
  • rgw - der Minion fungiert als Object Gateway.

    role-rgw/cluster/rgw*.sls
  • openattic - der Minion fungiert als openATTIC Server:

    role-openattic/cluster/openattic*.sls

    Weitere Informationen finden Sie unter Kapitel 15, openATTIC.

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

    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 14.3, „Benutzerdefinierte NFS Ganesha-Rollen“.

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

4.5.1.3 Allgemeine Konfiguration

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

4.5.1.4 Profilzuweisung

In Ceph würde eine einzelne Speicherrolle nicht ausreichen, um die vielen Festplattenkonfigurationen zu beschreiben, die auf ein und derselben Hardware verfügbar sind. DeepSea Phase 1 generiert einen Vorschlag eines Standardspeicherprofils. Standardmäßig ist dieser Vorschlag ein bluestore-Profil. Er versucht, die Konfiguration mit der optimalen Leistung für die vorliegende Hardware-Einrichtung vorzuschlagen. Beispielsweise werden externe Journale einer einzelnen Festplatte mit Objekten und Metadaten vorgezogen. Festkörperspeicher werden im Vergleich zu drehenden Festplatten priorisiert. Profile werden in der policy.cfg-Datei zugewiesen, ähnlich den Rollen.

Der Standardvorschlag ist im "profile-default"-Verzeichnisbaum zu finden. Fügen Sie die folgenden zwei Zeilen zu policy.cfg hinzu, um diesen Vorschlag zu übernehmen.

profile-default/cluster/*.sls
profile-default/stack/default/ceph/minions/*.yml

Sie können auch ein eigenes benutzerdefiniertes Speicherprofil über die Vorschlagsausführung erstellen. Dieses Ausführungsprogramm bietet drei Methoden: "help", "peek" und "populate".

salt-run proposal.help druckt den Hilfetext des Ausführungsprogramms zu den verschiedenen Argumenten, die akzeptiert werden.

salt-run proposal.peek zeigt den generierten Vorschlag gemäß der übergebenen Argumente.

salt-run proposal.populate schreibt den Vorschlag in das Unterverzeichnis /srv/pillar/ceph/proposals. Übergeben Sie name=myprofile, um das Speicherprofil zu benennen. Dadurch wird ein "profile-myprofile"-Unterverzeichnis erstellt.

Sehen Sie sich bei allen anderen Argumenten die Ausgabe von salt-run proposal.help an.

4.5.1.5 Bereitstellen verschlüsselter OSDs

Ab SUSE Enterprise Storage 5 werden OSDs standardmäßig mit BlueStore statt mit FileStore bereitgestellt. Obwohl BlueStore eine Verschlüsselung unterstützt, werden Ceph OSDs standardmäßig unverschlüsselt bereitgestellt. Nehmen wir an, dass sowohl die Daten-Festplatten als auch die WAL/DB-Festplatten, die für die OSD-Bereitstellung verwendet werden sollen, leer und nicht partitioniert sind. Falls die Festplatten vorher bereits verwendet wurden, löschen Sie sie vollständig anhand des in Schritt 13 beschriebenen Verfahrens.

Verwenden Sie das Ausführungsprogramm proposal.populate mit dem Argument encryption=dmcrypt, um verschlüsselte OSDs für Ihre neue Bereitstellung zu verwenden:

root@master # salt-run proposal.populate encryption=dmcrypt

4.5.1.6 Filtern von Elementen

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$

4.5.1.7 Beispiel einer policy.cfg-Datei

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

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

# IGW
role-igw/stack/default/ceph/minions/ses-example-4.yml 7
role-igw/cluster/ses-example-4.sls 8

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

# openATTIC
role-openattic/cluster/openattic*.sls 10

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

## Profiles
profile-default/cluster/*.sls 13
profile-default/stack/default/ceph/minions/*.yml 14

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

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

7

Stellt sicher, dass DeepSea die IP-Adresse des IGW Nodes kennt.

8

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

9

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

10

Gibt vor, dass die openATTIC-Bedienoberfläche zur Verwaltung des Ceph Clusters bereitgestellt wird. Weitere Einzelheiten finden Sie im Kapitel 15, openATTIC.

11

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

12

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

13

Wir weisen DeepSea an, das Standard-Hardwareprofil für jeden Minion zu verwenden. Die Wahl des Standard-Hardwareprofils bedeutet, dass wir alle anderen Festplatten (als die Root-Festplatte) als OSDs einrichten möchten.

14

Wir weisen DeepSea an, das Standard-Hardwareprofil für jeden Minion zu verwenden. Die Wahl des Standard-Hardwareprofils bedeutet, dass wir alle anderen Festplatten (als die Root-Festplatte) als OSDs einrichten möchten.

4.5.2 Benutzerdefinierte Datei ceph.conf

Wenn Sie benutzerdefinierte Einstellungen zur Datei ceph.conf hinzufügen müssen, finden Sie die entsprechenden Informationen dazu im Abschnitt 1.11, „Benutzerdefinierte Datei ceph.conf.

Diese Seite drucken