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

10 Upgrade von SUSE Enterprise Storage 6 auf 7.1

In diesem Kapitel finden Sie die Schritte zum Upgrade von SUSE Enterprise Storage 6 auf Version 7.1.

Das Upgrade umfasst die folgenden Aufgaben:

  • Upgrade von Ceph Nautilus zu Pacific.

  • Umstellung von der Installation und Ausführung von Ceph über RPM-Pakete auf die Ausführung in Containern.

  • Vollständiges Entfernen von DeepSea und Ersetzen durch ceph-salt und cephadm.

Warnung
Warnung

Die Upgrade-Informationen in diesem Kapitel gelten nur für Upgrades von DeepSea auf cephadm. Versuchen Sie nicht, diese Anweisungen zu befolgen, wenn Sie SUSE Enterprise Storage auf der SUSE CaaS Platform implementieren möchten.

Wichtig
Wichtig

Das Upgrade von SUSE Enterprise Storage-Versionen vor 6 wird nicht unterstützt. Zunächst müssen Sie ein Upgrade auf die aktuelle Version von SUSE Enterprise Storage 6 durchführen und dann die Schritte in diesem Kapitel ausführen.

10.1 Vor dem Aufrüsten

Die folgenden Aufgaben müssen abgeschlossen sein, bevor Sie das Upgrade starten. Dies kann jederzeit während der Laufzeit von SUSE Enterprise Storage 6 erfolgen.

10.1.1 Zu berücksichtigende Aspekte

Lesen Sie vor dem Upgrade unbedingt die folgenden Abschnitte durch, um sicherzustellen, dass Sie alle auszuführenden Aufgaben verstehen.

  • Lesen Sie die Versionshinweise. Darin 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 Softwarepaketen 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.

    Die Versionshinweise zu SES 7.1 finden Sie online unter https://www.suse.com/releasenotes/.

    Nach der Installation des Pakets release-notes-ses aus dem SES 7.1-Repository finden Sie die Versionshinweise zudem lokal im Verzeichnis /usr/share/doc/release-notes oder online unter https://www.suse.com/releasenotes/.

  • Lesen Sie Teil II, „Bereitstellen des Ceph-Clusters“, um sich mit ceph-salt und dem Ceph-Orchestrator vertraut zu machen, insbesondere die Informationen zu Servicespezifikationen.

  • Das Cluster-Upgrade kann lange dauern, nämlich in etwa so lange, wie es dauert, ein Upgrade eines Computers multipliziert mit der Anzahl der Cluster-Knoten durchzuführen.

  • Sie müssen zuerst ein Upgrade des Salt Master durchführen und dann DeepSea durch ceph-salt und cephadm ersetzen. Sie können das cephadm-Orchestrator-Modul erst dann verwenden, wenn mindestens für alle Ceph-Manager-Knoten ein Upgrade durchgeführt wurde.

  • Das Upgrade von Nautilus-RPMs auf Pacific-Container muss in einem Schritt erfolgen. Das bedeutet, dass Sie für einen ganzen Knoten auf einmal ein Upgrade durchführen, nicht nur für einen Daemon auf einmal.

  • Das Upgrade der wichtigsten Services (MON, MGR, OSD) erfolgt nacheinander. Jeder Service ist während des Upgrades verfügbar. Die Gateway-Services (Metadata Server, Object Gateway, NFS Ganesha, iSCSI Gateway) müssen nach dem Upgrade der wichtigsten Services neu bereitgestellt werden. Für jeden der folgenden Services ist eine gewisse Ausfallzeit zu berücksichtigen:

    • Wichtig
      Wichtig

      Metadata Server und Object Gateways sind ab dem Zeitpunkt, an dem für die Knoten von SUSE Linux Enterprise Server 15 SP1 ein Upgrade auf SUSE Linux Enterprise Server 15 SP3 durchgeführt wurde, bis zur erneuten Bereitstellung der Services am Ende des Upgrade-Vorgangs außer Betrieb. Dies ist insbesondere dann zu beachten, wenn diese Services zusammen mit MONs, MGRs oder OSDs untergebracht sind, da sie für die gesamte Dauer des Cluster-Upgrades ausfallen können. Sollte dies ein Problem sein, ziehen Sie in Erwägung, diese Services vor dem Upgrade separat auf zusätzlichen Knoten bereitzustellen, damit sie so kurz wie möglich ausfallen. Hierbei handelt es sich um die Dauer des Upgrades der Gateway-Knoten, nicht die Dauer des Upgrades des gesamten Clusters.

    • NFS Ganesha und iSCSI Gateways sind nur für die Dauer des Neustarts der Knoten während des Upgrades von SUSE Linux Enterprise Server 15 SP1 auf SUSE Linux Enterprise Server 15 SP3 außer Betrieb und erneut für kurze Zeit, wenn die einzelnen Services im containerisierten Modus neu bereitgestellt werden.

10.1.2 Sichern der Cluster-Konfiguration und -Daten

Es wird dringend empfohlen, die gesamte Cluster-Konfiguration und alle Daten zu sichern, bevor Sie mit dem Upgrade auf SUSE Enterprise Storage 7.1 beginnen. Eine Anleitung zur Sicherung aller Daten finden Sie unter https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup.

10.1.3 Überprüfen der Schritte des vorherigen Upgrades

Falls Sie zuvor ein Upgrade von Version 5 durchgeführt haben, prüfen Sie, ob das Upgrade auf Version 6 erfolgreich abgeschlossen wurde:

Prüfen Sie, ob die Datei /srv/salt/ceph/configuration/files/ceph.conf.import vorhanden ist.

Diese Datei wird durch den Importvorgang während des Upgrades von SUSE Enterprise Storage 5 auf 6 erstellt. Die Option configuration_init: default-import wird in /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml festgelegt.

Wenn configuration_init noch auf default-import festgelegt ist, greift der Cluster auf ceph.conf.import als Konfigurationsdatei zurück, nicht auf die Standarddatei ceph.conf von DeepSea, die aus Dateien in /srv/salt/ceph/configuration/files/ceph.conf.d/ kompiliert wird.

Sie müssen daher ceph.conf.import auf benutzerdefinierte Konfigurationen prüfen und diese Konfigurationen ggf. in eine der Dateien in /srv/salt/ceph/configuration/files/ceph.conf.d/ verschieben.

Entfernen Sie dann die Zeile configuration_init: default-import aus /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml.

10.1.4 Aktualisieren von Cluster-Knoten und Überprüfen des Zustands des Clusters

Überprüfen Sie, ob alle aktuellen Aktualisierungen von SUSE Linux Enterprise Server 15 SP1 und SUSE Enterprise Storage 6 auf alle Cluster-Knoten angewendet werden:

# zypper refresh && zypper patch
Tipp
Tipp

Weitere Informationen zum Aktualisieren der Cluster-Knoten finden Sie unter https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updates.

Starten Sie nach Anwendung der Aktualisierungen den Salt Master neu, synchronisieren Sie neue Salt-Module und überprüfen Sie den Cluster-Zustand:

root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
cephuser@adm > ceph -s

10.1.4.1 Deaktivieren unsicherer Clients

Seit Nautilus v14.2.20 wurde eine neue Zustandswarnung eingeführt, die Sie darüber informiert, dass unsichere Clients im Cluster aufgenommen werden können. Diese Warnung ist standardmäßig aktiviert. Im Ceph Dashboard wird der Cluster mit dem Status HEALTH_WARN angezeigt. Sie können den Status des Clusters wie folgt über die Kommandozeile überprüfen:

 cephuser@adm > ceph status
 cluster:
   id:     3fe8b35a-689f-4970-819d-0e6b11f6707c
   health: HEALTH_WARN
   mons are allowing insecure global_id reclaim
 [...]

Diese Warnung bedeutet, dass Ceph Monitors immer noch alten, ungepatchten Clients erlauben, sich mit dem Cluster zu verbinden. Dadurch wird sichergestellt, dass bestehende Clients während eines Cluster-Upgrades weiterhin eine Verbindung herstellen können. Sie werden jedoch gewarnt, dass ein Problem vorhanden ist, das behoben werden muss.Dadurch wird sichergestellt, dass bestehende Clients während eines Cluster-Upgrades weiterhin eine Verbindung herstellen können Nach dem Upgrade des Clusters und aller Clients auf die neueste Version von Ceph verhindern Sie mit folgendem Kommando, dass sich ungepatchte Clients mit dem Cluster verbinden:

cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false

10.1.5 Überprüfen des Zugriffs auf Software-Repositorys und Container-Images

Stellen Sie sicher, dass alle Cluster-Knoten Zugriff auf die Software-Repositorys von SUSE Linux Enterprise Server 15 SP3 und SUSE Enterprise Storage 7.1 sowie auf die Registrierung von Container-Images haben.

10.1.5.1 Software-Repositorys

Wenn alle Knoten bei SCC registriert sind, können Sie das Kommando zypper migration für das Upgrade verwenden. Weitere Informationen finden Sie in https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-upgrade-online.html#sec-upgrade-online-zypper.

Wenn Knoten nicht bei SCC registriert sind, deaktivieren Sie alle vorhandenen Software-Repositorys und fügen Sie sowohl das Pool- als auch das Updates-Repository für jede der folgenden Erweiterungen hinzu:

  • SLE-Product-SLES/15-SP3

  • SLE-Module-Basesystem/15-SP3

  • SLE-Module-Server-Applications/15-SP3

  • SUSE-Enterprise-Storage-7.1

10.1.5.2 Container-Images

Alle Cluster-Knoten benötigen Zugriff auf die Container-Image-Registrierung. In den meisten Fällen verwenden Sie die öffentliche SUSE-Registrierung unter registry.suse.com. Dafür benötigen Sie die folgenden Images:

  • registry.suse.com/ses/7.1/ceph/ceph

  • registry.suse.com/ses/7.1/ceph/grafana

  • registry.suse.com/ses/7.1/ceph/prometheus-server

  • registry.suse.com/ses/7.1/ceph/prometheus-node-exporter

  • registry.suse.com/ses/7.1/ceph/prometheus-alertmanager

Alternativ (z. B. für Air-Gap-Bereitstellungen) können Sie eine lokale Registrierung konfigurieren und überprüfen, ob Sie den richtigen Satz von Container-Images zur Verfügung haben. Weitere Details zum Konfigurieren einer lokalen Container-Image-Registrierung finden Sie in Abschnitt 7.2.10, „Verwenden der Container-Registrierung“.

10.2 Upgrade des Salt Masters

Das folgende Verfahren beschreibt den Prozess des Upgrades des Salt Masters:

  1. Führen Sie ein Upgrade des zugrunde liegenden Betriebssystems auf SUSE Linux Enterprise Server 15 SP3 durch:

    • Führen Sie für Cluster, deren Knoten bei SCC registriert sind, zypper migration aus.

    • Führen Sie für Cluster, deren Knoten Software-Repositorys manuell zugewiesen wurden, zypper dup und dann reboot aus.

  2. Deaktivieren Sie die DeepSea-Phasen, um eine versehentliche Verwendung zu vermeiden. Fügen Sie folgenden Inhalt zu /srv/pillar/ceph/stack/global.yml hinzu:

    stage_prep: disabled
    stage_discovery: disabled
    stage_configure: disabled
    stage_deploy: disabled
    stage_services: disabled
    stage_remove: disabled

    Speichern Sie die Datei und übernehmen Sie die Änderungen:

    root@master # salt '*' saltutil.pillar_refresh
  3. Wenn Sie keine Container-Images von registry.suse.com verwenden, sondern die lokal konfigurierte Registrierung, bearbeiten Sie /srv/pillar/ceph/stack/global.yml, um DeepSea mitzuteilen, welches Ceph-Container-Image und welche Registrierung verwendet werden sollen. Beispiel: Fügen Sie die folgenden Zeilen ein, um 192.168.121.1:5000/my/ceph/image zu verwenden:

    ses7_container_image: 192.168.121.1:5000/my/ceph/image
    ses7_container_registries:
      - location: 192.168.121.1:5000

    Wenn Sie Authentifizierungsinformationen für die Registrierung angeben müssen, fügen Sie den Block ses7_container_registry_auth: hinzu, beispielsweise:

    ses7_container_image: 192.168.121.1:5000/my/ceph/image
    ses7_container_registries:
      - location: 192.168.121.1:5000
    ses7_container_registry_auth:
      registry: 192.168.121.1:5000
      username: USER_NAME
      password: PASSWORD

    Speichern Sie die Datei und übernehmen Sie die Änderungen:

    root@master # salt '*' saltutil.refresh_pillar
  4. Übernehmen Sie die bestehende Konfiguration:

    cephuser@adm > ceph config assimilate-conf -i /etc/ceph/ceph.conf
  5. Prüfen Sie den Upgrade-Status. Je nach Cluster-Konfiguration kann Ihre Ausgabe abweichen:

    root@master # salt-run upgrade.status
    The newest installed software versions are:
     ceph: ceph version 16.2.7-640-gceb23c7491b (ceb23c7491bd96ab7956111374219a4cdcf6f8f4) pacific (stable)
     os: SUSE Linux Enterprise Server 15 SP3
    
    Nodes running these software versions:
     admin.ceph (assigned roles: master, prometheus, grafana)
    
    Nodes running older software versions must be upgraded in the following order:
     1: mon1.ceph (assigned roles: admin, mon, mgr)
     2: mon2.ceph (assigned roles: admin, mon, mgr)
     3: mon3.ceph (assigned roles: admin, mon, mgr)
     4: data4.ceph (assigned roles: storage, mds)
     5: data1.ceph (assigned roles: storage)
     6: data2.ceph (assigned roles: storage)
     7: data3.ceph (assigned roles: storage)
     8: data5.ceph (assigned roles: storage, rgw)

10.3 Upgrade der MON-, MGR- und OSD-Knoten

Führen Sie die Upgrades für Ceph-Monitor-, Ceph-Manager- und OSD-Knoten nacheinander durch. Führen Sie für jeden Service die folgenden Schritte aus:

  1. Bevor Sie einen OSD-Knoten übernehmen, müssen Sie eine Formatkonvertierung der OSD-Knoten durchführen, um die Berücksichtigung von OMAP-Daten zu verbessern. Dazu führen Sie folgendes Kommando auf dem Admin-Knoten aus:

    cephuser@adm > ceph config set osd bluestore_fsck_quick_fix_on_mount true

    Die OSD-Knoten werden automatisch konvertiert, wenn ihre Übernahme abgeschlossen ist.

    Anmerkung
    Anmerkung

    Die Konvertierung kann von einigen Minuten bis zu mehreren Stunden dauern, je nachdem, wie viele OMAP-Daten die entsprechende Festplatte enthält. Weitere Einzelheiten finden Sie unter https://docs.ceph.com/en/latest/releases/pacific/#upgrading-non-cephadm-clusters.

  2. Wenn es sich bei dem Knoten, für den Sie ein Upgrade durchführen, um einen OSD-Knoten handelt, verhindern Sie, dass der OSD-Knoten während des Upgrade-Vorgangs als out markiert wird. Führen Sie hierzu folgendes Kommando aus:

    cephuser@adm > ceph osd add-noout SHORT_NODE_NAME

    Ersetzen Sie SHORT_NODE_NAME durch den Kurznamen des Knotens, wie er in der Ausgabe des Kommandos ceph osd tree erscheint. In der folgenden Eingabe lauten die Kurznamen des Hosts ses-min1 und ses-min2.

    root@master # ceph osd tree
    ID   CLASS  WEIGHT   TYPE NAME       STATUS  REWEIGHT  PRI-AFF
     -1         0.60405  root default
    -11         0.11691      host ses-min1
      4    hdd  0.01949          osd.4       up   1.00000  1.00000
      9    hdd  0.01949          osd.9       up   1.00000  1.00000
     13    hdd  0.01949          osd.13      up   1.00000  1.00000
    [...]
     -5         0.11691      host ses-min2
      2    hdd  0.01949          osd.2       up   1.00000  1.00000
      5    hdd  0.01949          osd.5       up   1.00000  1.00000
    [...]
  3. Führen Sie ein Upgrade des zugrunde liegenden Betriebssystems auf SUSE Linux Enterprise Server 15 SP3 durch:

    • Wenn alle Knoten des Clusters bei SCC registriert sind, führen Sie zypper migration aus.

    • Wenn den Knoten des Clusters Software-Repositorys manuell zugewiesen wurden, führen Sie zypper dup und dann reboot aus.

  4. Containerisieren Sie nach dem Neustart des Knotens alle vorhandenen MON-, MGR- und OSD-Daemons auf diesem Knoten. Führen Sie hierzu folgendes Kommando auf dem Salt Master aus:

    root@master # salt MINION_ID state.apply ceph.upgrade.ses7.adopt

    Ersetzen Sie MINION_ID durch die ID des Minion, den Sie aufrüsten möchten. Die Liste der Minion-IDs erhalten Sie durch Ausführen des Kommandos salt-key -L auf dem Salt Master.

    Tipp
    Tipp

    Den Status und den Fortschritt der Übernahme finden Sie im Ceph-Dashboard oder durch Ausführen eines der folgenden Kommandos auf dem Salt Master:

    root@master # ceph status
    root@master # ceph versions
    root@master # salt-run upgrade.status
  5. Entfernen Sie nach der erfolgreichen Übernahme das Flag noout, wenn der Knoten, den Sie aufrüsten, ein OSD-Knoten ist:

    cephuser@adm > ceph osd rm-noout SHORT_NODE_NAME

10.4 Upgrade von Gateway-Knoten

Führen Sie als Nächstes ein Upgrade der separaten Gateway-Knoten (Samba Gateway, Metadata Server, Object Gateway, NFS Ganesha oder iSCSI Gateway) durch. Führen Sie für jeden Knoten ein Upgrade des zugrunde liegenden Betriebssystems auf SUSE Linux Enterprise Server 15 SP3 auf:

  • Wenn alle Knoten des Clusters beim SUSE Customer Center registriert sind, führen Sie das Kommando zypper migration aus.

  • Wenn den Knoten des Clusters Software-Repositorys manuell zugewiesen wurden, führen Sie das Kommando zypper dup und dann das Kommando reboot aus.

Dieser Schritt gilt auch für alle Knoten, die Teil des Clusters sind, denen aber noch keine Rollen zugewiesen wurden (überprüfen Sie im Zweifelsfall die Liste der Hosts auf dem Salt Master, die durch das Kommando salt-key -L erstellt wird, und vergleichen Sie sie mit der Ausgabe des Kommandos salt-run upgrade.status).

Wenn das Betriebssystem auf allen Knoten im Cluster aktualisiert wurde, besteht der nächste Schritt darin, das Paket ceph-salt zu installieren und die Cluster-Konfiguration anzuwenden. Die eigentlichen Gateway-Services werden am Ende des Upgrade-Vorgangs in einem containerisierten Modus neu bereitgestellt.

Anmerkung
Anmerkung

Metadata-Server- und Object-Gateway-Services sind ab dem Zeitpunkt des Upgrades auf SUSE Linux Enterprise Server 15 SP3 nicht mehr verfügbar. Sie müssen am Ende des Upgrade-Vorgangs erneut bereitgestellt werden.

10.5 Installieren von ceph-salt und Anwenden der Cluster-Konfiguration

Bevor Sie damit beginnen, ceph-salt zu installieren und die Cluster-Konfiguration anzuwenden, müssen Sie den Cluster- und Upgrade-Status überprüfen. Führen Sie dazu folgende Kommandos aus:

root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status
  1. Entfernen Sie die von DeepSea erstellten Crons rbd_exporter und rgw_exporter. Führen Sie auf dem Salt Master als root das Kommando crontab -e aus, um crontab zu bearbeiten. Löschen Sie die folgenden Elemente, falls vorhanden:

    # SALT_CRON_IDENTIFIER:deepsea rbd_exporter cron job
    */5 * * * * /var/lib/prometheus/node-exporter/rbd.sh > \
     /var/lib/prometheus/node-exporter/rbd.prom 2> /dev/null
    # SALT_CRON_IDENTIFIER:Prometheus rgw_exporter cron job
    */5 * * * * /var/lib/prometheus/node-exporter/ceph_rgw.py > \
     /var/lib/prometheus/node-exporter/ceph_rgw.prom 2> /dev/null
  2. Führen Sie zum Exportieren der Cluster-Konfiguration aus DeepSea folgende Kommandos aus:

    root@master # salt-run upgrade.ceph_salt_config > ceph-salt-config.json
    root@master # salt-run upgrade.generate_service_specs > specs.yaml
  3. Deinstallieren Sie DeepSea und installieren Sie ceph-salt auf dem Salt Master:

    root@master # zypper remove 'deepsea*'
    root@master # zypper install ceph-salt
  4. Starten Sie den Salt Master neu und synchronisieren Sie die Salt-Module:

    root@master # systemctl restart salt-master.service
    root@master # salt \* saltutil.sync_all
  5. Importieren Sie die Cluster-Konfiguration von DeepSea in ceph-salt:

    root@master # ceph-salt import ceph-salt-config.json
  6. Generieren Sie SSH-Schlüssel für die Cluster-Knoten-Kommunikation:

    root@master # ceph-salt config /ssh generate
    Tipp
    Tipp

    Überprüfen Sie, ob die Cluster-Konfiguration aus DeepSea importiert wurde, und geben Sie eventuell fehlende Optionen an:

    root@master # ceph-salt config ls

    Eine vollständige Beschreibung der Cluster-Konfiguration finden Sie in Abschnitt 7.2, „Konfigurieren der Clustereigenschaften“.

  7. Wenden Sie die Konfiguration an und aktivieren Sie cephadm:

    root@master # ceph-salt apply
  8. Wenn Sie die URL und die Zugangsdaten für die lokale Container-Registrierung angeben müssen, führen Sie die in Abschnitt 7.2.10, „Verwenden der Container-Registrierung“ beschriebenen Schritte aus.

  9. Wenn Sie keine Container-Images von registry.suse.com verwenden, sondern die lokal konfigurierte Registrierung, teilen Sie Ceph mit, welches Container-Image verwendet werden soll. Führen Sie dazu folgendes Kommando aus:

    root@master # ceph config set global container_image IMAGE_NAME

    Beispiel:

    root@master # ceph config set global container_image 192.168.121.1:5000/my/ceph/image
  10. Stoppen und deaktivieren Sie die ceph-crash-Daemons von SUSE Enterprise Storage 6. Neue containerisierte Formen dieser Daemons werden später automatisch gestartet.

    root@master # salt '*' service.stop ceph-crash
    root@master # salt '*' service.disable ceph-crash

10.6 Upgrade und Übernahme des Überwachungs-Stacks

Durch folgendes Verfahren werden alle Komponenten des Überwachungs-Stacks übernommen (weitere Details finden Sie im Kapitel 16, Überwachung und Warnungen).

  1. Halten Sie den Orchestrator an:

    cephuser@adm > ceph orch pause
  2. Führen Sie auf dem Knoten, auf dem Prometheus, Grafana und Alertmanager ausgeführt werden (standardmäßig der Salt Master), die folgenden Kommandos aus:

    cephuser@adm > cephadm adopt --style=legacy --name prometheus.$(hostname)
    cephuser@adm > cephadm adopt --style=legacy --name alertmanager.$(hostname)
    cephuser@adm > cephadm adopt --style=legacy --name grafana.$(hostname)
    Tipp
    Tipp

    Wenn Sie nicht die standardmäßige Container-Image-Registrierung registry.suse.com ausführen, müssen Sie das zu verwendende Image für jedes Kommando angeben, beispielsweise:

    cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-server:2.32.1 \
      adopt --style=legacy --name prometheus.$(hostname)
    cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-alertmanager:0.21.0 \
      adopt --style=legacy --name alertmanager.$(hostname)
    cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/grafana:7.5.12 \
     adopt --style=legacy --name grafana.$(hostname)

    Die erforderlichen Container-Images und ihre jeweiligen Versionen sind in Abschnitt 16.1, „Konfigurieren von benutzerdefinierten oder lokalen Images“ aufgeführt.

  3. Entfernen Sie Node-Exporter von allen Knoten. Der Node-Exporter muss nicht migriert werden und wird als Container neu installiert, wenn die Datei specs.yaml angewendet wird.

    > sudo zypper rm golang-github-prometheus-node_exporter

    Alternativ können Sie Node-Exporter mit Salt über den Admin-Knoten von allen Knoten gleichzeitig entfernen:

    root@master # salt '*' pkg.remove golang-github-prometheus-node_exporter
  4. Wenden Sie die zuvor aus DeepSea exportierten Servicespezifikationen an:

    cephuser@adm > ceph orch apply -i specs.yaml
    Tipp
    Tipp

    Wenn Sie nicht die standardmäßige Container-Image-Registrierung registry.suse.com, sondern eine lokale Container-Registrierung verwenden, konfigurieren Sie cephadm so, dass das Container-Image aus der lokalen Registrierung für die Bereitstellung von Node-Exporter verwendet wird, bevor Sie den Node-Exporter bereitstellen. Andernfalls können Sie diesen Schritt ohne Bedenken überspringen und die folgende Warnung ignorieren.

    cephuser@adm > ceph config set mgr mgr/cephadm/container_image_node_exporter QUALIFIED_IMAGE_PATH

    Stellen Sie sicher, dass alle Container-Images für Überwachungsservices auf die lokale Registrierung verweisen, nicht nur das Image für Node-Exporter. Dieser Schritt ist nur für den Node-Exporter erforderlich, doch es ist ratsam, alle Container-Images für die Überwachung in cephadm so einzustellen, dass sie auf die lokale Registrierung verweisen.

    Andernfalls wird bei neuen und wiederholten Bereitstellungen von Überwachungsservices die Standardkonfiguration von cephadm verwendet und Sie können Services möglicherweise nur mit gemischten Versionen oder gar nicht (bei Air-Gapped-Bereitstellungen) bereitstellen.

    Wie cephadm für die Verwendung von Container-Images aus der lokalen Registrierung konfiguriert werden muss, ist in Abschnitt 16.1, „Konfigurieren von benutzerdefinierten oder lokalen Images“ beschrieben.

  5. Setzen Sie den Orchestrator fort:

    cephuser@adm > ceph orch resume

10.7 Erneute Bereitstellung des Gateway-Service

10.7.1 Upgrade des Object Gateways

In SUSE Enterprise Storage 7.1 werden die Object Gateways immer mit einem Bereich konfiguriert, was in Zukunft mehrere Standorte ermöglicht (weitere Details finden Sie im Abschnitt 21.13, „Object Gateways an mehreren Standorten“). Wenn Sie in SUSE Enterprise Storage 6 eine Object-Gateway-Konfiguration für einen einzigen Standort verwendet haben, gehen Sie folgendermaßen vor, um einen Bereich hinzuzufügen. Wenn Sie nicht vorhaben, die Funktionalität für mehrere Standorte zu nutzen, können Sie default für die Namen des Bereichs, der Zonengruppe und der Zone verwenden.

  1. Erstellen Sie einen neuen Bereich:

    cephuser@adm > radosgw-admin realm create --rgw-realm=REALM_NAME --default
  2. Optional können Sie die standardmäßige Zone und Zonengruppe umbenennen.

    cephuser@adm > radosgw-admin zonegroup rename \
     --rgw-zonegroup default \
     --zonegroup-new-name=ZONEGROUP_NAME
    cephuser@adm > radosgw-admin zone rename \
     --rgw-zone default \
     --zone-new-name ZONE_NAME \
     --rgw-zonegroup=ZONEGROUP_NAME
  3. Konfigurieren Sie die Master-Zonengruppe:

    cephuser@adm > radosgw-admin zonegroup modify \
     --rgw-realm=REALM_NAME \
     --rgw-zonegroup=ZONEGROUP_NAME \
     --endpoints http://RGW.EXAMPLE.COM:80 \
     --master --default
  4. Konfigurieren Sie die Master-Zone. Dazu benötigen Sie den ACCESS_KEY und SECRET_KEY eines Object-Gateway-Benutzers, bei dem das Flag system aktiviert ist. Hierbei handelt es sich normalerweise um den admin-Benutzer. Führen Sie zum Abrufen des ACCESS_KEY und SECRET_KEY das Kommando radosgw-admin user info --uid admin --rgw-zone=ZONE_NAME aus.

    cephuser@adm > radosgw-admin zone modify \
     --rgw-realm=REALM_NAME \
     --rgw-zonegroup=ZONEGROUP_NAME \
     --rgw-zone=ZONE_NAME \
     --endpoints http://RGW.EXAMPLE.COM:80 \
     --access-key=ACCESS_KEY \
     --secret=SECRET_KEY \
     --master --default
  5. Bestätigen Sie die aktualisierte Konfiguration:

    cephuser@adm > radosgw-admin period update --commit

Um den Object-Gateway-Service zu containerisieren, erstellen Sie dessen Spezifikationsdatei wie in Abschnitt 8.3.4, „Bereitstellen von Object Gateways“ beschrieben, und wenden Sie sie an.

cephuser@adm > ceph orch apply -i RGW.yml

10.7.2 Upgrade von NFS Ganesha

Wichtig
Wichtig

NFS Ganesha unterstützt NFS-Version 4.1 und neuer. NFS Ganesha unterstützt nicht NFS-Version 3.

Im Folgenden wird demonstriert, wie ein bestehender NFS-Ganesha-Service unter Ceph Nautilus in einen NFS-Ganesha-Container unter Ceph Octopus migriert wird.

Warnung
Warnung

Die folgende Dokumentation setzt voraus, dass Sie für die wichtigsten Ceph-Services bereits erfolgreich ein Upgrade durchgeführt haben.

NFS Ganesha speichert zusätzlich die Konfiguration pro Daemon und exportiert die Konfiguration in einen RADOS-Pool. Den konfigurierten RADOS-Pool finden Sie in der Datei ganesha.conf im Block RADOS_URLS in der Zeile watch_url. Standardmäßig wird dieser Pool ganesha_config genannt.

Es wird dringend empfohlen, vor einer Migration eine Kopie der Export- und Daemon-Konfigurationsobjekte im RADOS-Pool zu erstellen. Zum Auffinden des konfigurierten RADOS-Pools führen Sie folgendes Kommando aus:

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

So listen Sie den Inhalt des RADOS-Pools auf:

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

So kopieren Sie die RADOS-Objekte:

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

Pro Knoten muss jeder bestehende NFS-Ganesha-Service gestoppt und anschließend durch einen von cephadm verwalteten Container ersetzt werden.

  1. Stoppen und deaktivieren Sie den vorhandenen NFS-Ganesha-Service:

    cephuser@adm > systemctl stop nfs-ganesha
    cephuser@adm > systemctl disable nfs-ganesha
  2. Nachdem der bestehende NFS-Ganesha-Service gestoppt wurde, kann mit cephadm ein neuer Service in einem Container eingerichtet werden. Dazu müssen Sie eine Service-Spezifikation erstellen, die eine service_id enthält, die zur Identifizierung dieses neuen NFS-Clusters verwendet wird, den Hostnamen des Knotens, den wir migrieren und der in der Platzierungsspezifikation als Host aufgeführt ist, sowie den RADOS-Pool und -Namespace, der die konfigurierten NFS-Exportobjekte enthält. Beispiel:

    service_type: nfs
    service_id: SERVICE_ID
    placement:
      hosts:
      - node2
      pool: ganesha_config
      namespace: ganesha

    Weitere Informationen zum Erstellen einer Platzierungsspezifikation finden Sie in Abschnitt 8.2, „Service- und Platzierungsspezifikation“.

  3. Wenden Sie die Platzierungsspezifikation an:

    cephuser@adm > ceph orch apply -i FILENAME.yaml
  4. Bestätigen Sie, dass der NFS-Ganesha-Daemon auf dem Host ausgeführt wird:

    cephuser@adm > ceph orch ps --daemon_type nfs
    NAME           HOST   STATUS         REFRESHED  AGE  VERSION  IMAGE NAME                                IMAGE ID      CONTAINER ID
    nfs.foo.node2  node2  running (26m)  8m ago     27m  3.3      registry.suse.com/ses/7.1/ceph/ceph:latest  8b4be7c42abd  c8b75d7c8f0d
  5. Wiederholen Sie diese Schritte für jeden NFS-Ganesha-Knoten. Sie müssen nicht für jeden Knoten eine eigene Servicespezifikation erstellen. Es reicht aus, den Hostnamen jedes Knotens zur bestehenden NFS-Servicespezifikation hinzuzufügen und sie erneut anzuwenden.

Die vorhandenen Exporte können auf zwei verschiedene Arten migriert werden:

  • manuell neu erstellt oder neu zugewiesen über das Ceph Dashboard.

  • Kopieren Sie den Inhalt jedes RADOS-Objekts pro Daemon manuell in die neu erstellte gemeinsame NFS-Ganesha-Konfiguration.

Prozedur 10.1: Manuelles Kopieren von Exporten in die gemeinsame Konfigurationsdatei von NFS Ganesha
  1. Ermitteln Sie die Liste der RADOS-Objekte pro Daemon:

    cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
    cephuser@adm > DAEMON_OBJS=$(rados $RADOS_ARGS ls | grep 'conf-')
  2. Erstellen Sie eine Kopie der RADOS-Objekte pro Daemon:

    cephuser@adm > for obj in $DAEMON_OBJS; do rados $RADOS_ARGS get $obj $obj; done
    cephuser@adm > ls -lah
    total 20K
    drwxr-xr-x 2 root root 4.0K Sep 8 16:51 .
    drwxr-xr-x 3 root root 4.0K Sep 8 16:47 ..
    -rw-r--r-- 1 root root 90 Sep 8 16:51 conf-nfs.SERVICE_ID
    -rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node2
    -rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node3
  3. Sortieren Sie sie und führen Sie sie in einer einzigen Liste von Exporten zusammen:

    cephuser@adm > cat conf-* | sort -u > conf-nfs.SERVICE_ID
    cephuser@adm > cat conf-nfs.foo
    %url "rados://ganesha_config/ganesha/export-1"
    %url "rados://ganesha_config/ganesha/export-2"
    %url "rados://ganesha_config/ganesha/export-3"
    %url "rados://ganesha_config/ganesha/export-4"
  4. Schreiben Sie die neue gemeinsame Konfigurationsdatei für NFS Ganesha:

    cephuser@adm > rados $RADOS_ARGS put conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID
  5. Benachrichtigen Sie den NFS-Ganesha-Daemon:

    cephuser@adm > rados $RADOS_ARGS notify conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID
    Anmerkung
    Anmerkung

    Diese Aktion veranlasst den Daemon, die Konfiguration neu zu laden.

Nach der erfolgreichen Migration des Service kann der Nautilus-basierte NFS-Ganesha-Service entfernt werden.

  1. Entfernen Sie NFS Ganesha:

    cephuser@adm > zypper rm nfs-ganesha
    Reading installed packages...
    Resolving package dependencies...
    The following 5 packages are going to be REMOVED:
      nfs-ganesha nfs-ganesha-ceph nfs-ganesha-rados-grace nfs-ganesha-rados-urls nfs-ganesha-rgw
    5 packages to remove.
    After the operation, 308.9 KiB will be freed.
    Continue? [y/n/v/...? shows all options] (y): y
    (1/5) Removing nfs-ganesha-ceph-2.8.3+git0.d504d374e-3.3.1.x86_64 .................................................................................................................................................................................................................................................................................................[done]
    (2/5) Removing nfs-ganesha-rgw-2.8.3+git0.d504d374e-3.3.1.x86_64 ..................................................................................................................................................................................................................................................................................................[done]
    (3/5) Removing nfs-ganesha-rados-urls-2.8.3+git0.d504d374e-3.3.1.x86_64 ...........................................................................................................................................................................................................................................................................................[done]
    (4/5) Removing nfs-ganesha-rados-grace-2.8.3+git0.d504d374e-3.3.1.x86_64 ..........................................................................................................................................................................................................................................................................................[done]
    (5/5) Removing nfs-ganesha-2.8.3+git0.d504d374e-3.3.1.x86_64 ......................................................................................................................................................................................................................................................................................................[done]
    Additional rpm output:
    warning: /etc/ganesha/ganesha.conf saved as /etc/ganesha/ganesha.conf.rpmsave
  2. Entfernen Sie die veralteten Cluster-Einstellungen aus dem Ceph Dashboard:

    cephuser@adm > ceph dashboard reset-ganesha-clusters-rados-pool-namespace

10.7.3 Upgrade des Metadata Servers

Im Gegensatz zu MONs, MGRs und OSDs kann der Metadata Server nicht an Ort und Stelle übernommen werden. Stattdessen müssen Sie sie mit dem Ceph-Orchestrator neu in Containern bereitstellen.

  1. Führen Sie das Kommando ceph fs ls aus, um beispielsweise den Namen Ihres Dateisystems zu erhalten:

    cephuser@adm > ceph fs ls
    name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
  2. Erstellen Sie eine neue Servicespezifikationsdatei mds.yml wie in Abschnitt 8.3.3, „Bereitstellen von Metadatenservern“ beschrieben. Verwenden Sie dazu den Dateisystemnamen als service_id und geben Sie die Hosts an, auf denen die MDS-Daemons ausgeführt werden. Beispiel:

    service_type: mds
    service_id: cephfs
    placement:
      hosts:
      - ses-min1
      - ses-min2
      - ses-min3
  3. Führen Sie das Kommando ceph orch apply -i mds.yml aus, um die Servicespezifikation anzuwenden und die MDS-Daemons zu starten.

10.7.4 Upgrade des iSCSI Gateways

Für ein Upgrade des iSCSI Gateways müssen Sie es mithilfe des Ceph-Orchestrators neu in Containern bereitstellen. Wenn Sie über mehrere iSCSI Gateways verfügen, müssen Sie diese nacheinander neu bereitstellen, um die Ausfallzeit des Service zu reduzieren.

  1. Stoppen und deaktivieren Sie die vorhandenen iSCSI-Daemons auf jedem iSCSI Gateway-Knoten:

    > sudo systemctl stop rbd-target-gw
    > sudo systemctl disable rbd-target-gw
    > sudo systemctl stop rbd-target-api
    > sudo systemctl disable rbd-target-api
  2. Erstellen Sie eine Servicespezifikation für das iSCSI Gateway, wie in Abschnitt 8.3.5, „Bereitstellen von iSCSI-Gateways“ beschrieben. Dazu benötigen Sie die Einstellungen pool, trusted_ip_list und api_* aus der bestehenden Datei /etc/ceph/iscsi-gateway.cfg. Wenn Sie SSL-Unterstützung aktiviert haben (api_secure = true), benötigen Sie auch das SSL-Zertifikat (/etc/ceph/iscsi-gateway.crt) und den Schlüssel (/etc/ceph/iscsi-gateway.key).

    Beispiel: Wenn /etc/ceph/iscsi-gateway.cfg Folgendes enthält:

    [config]
    cluster_client_name = client.igw.ses-min5
    pool = iscsi-images
    trusted_ip_list = 10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202
    api_port = 5000
    api_user = admin
    api_password = admin
    api_secure = true

    Dann müssen Sie die folgende Servicespezifikationsdatei iscsi.yml erstellen:

    service_type: iscsi
    service_id: igw
    placement:
      hosts:
      - ses-min5
    spec:
      pool: iscsi-images
      trusted_ip_list: "10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202"
      api_port: 5000
      api_user: admin
      api_password: admin
      api_secure: true
      ssl_cert: |
        -----BEGIN CERTIFICATE-----
        MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
        DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
        [...]
        -----END CERTIFICATE-----
      ssl_key: |
        -----BEGIN PRIVATE KEY-----
        MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
        /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
        [...]
        -----END PRIVATE KEY-----
    Anmerkung
    Anmerkung

    Die Einstellungen pool, trusted_ip_list, api_port, api_user, api_password, api_secure sind identisch mit den Einstellungen aus Datei /etc/ceph/iscsi-gateway.cfg. Die Werte ssl_cert und ssl_key können aus dem bestehenden SSL-Zertifikat und den Schlüsseldateien kopiert und eingefügt werden. Vergewissern Sie sich, dass sie richtig eingerückt sind und das pipe Zeichen | am Ende der Zeilen ssl_cert: und ssl_key: erscheint (den Inhalt der Datei iscsi.yml finden Sie oben).

  3. Führen Sie das Kommando ceph orch apply -i iscsi.yml aus, um die Servicespezifikation anzuwenden und die iSCSI Gateway-Daemons zu starten.

  4. Entfernen Sie das alte ceph-iscsi-Paket von jedem der vorhandenen iSCSI-Gateway-Knoten:

    cephuser@adm > zypper rm -u ceph-iscsi

10.8 Bereinigung nach dem Upgrade

Führen Sie nach dem Upgrade die folgenden Schritte zur Bereinigung aus:

  1. Überprüfen Sie die aktuelle Ceph-Version, um sich zu vergewissern, dass für den Cluster erfolgreich ein Upgrade durchgeführt wurde:

    cephuser@adm > ceph versions
  2. Stellen Sie sicher, dass keine alten OSDs im Cluster aufgenommen werden:

    cephuser@adm > ceph osd require-osd-release pacific
  3. Legen Sie den pg_autoscale_mode von bestehenden Pools fest, falls erforderlich:

    Wichtig
    Wichtig

    Bei Pools in SUSE Enterprise Storage 6 war der Modus pg_autoscale_mode standardmäßig auf warn festgelegt. Dies führte zwar zu einer Warnmeldung bei einer suboptimalen Anzahl von PGs, doch eine automatische Skalierung fand nicht statt. In der Standardeinstellung von SUSE Enterprise Storage 7.1 ist die Option pg_autoscale_mode für neue Pools auf on festgelegt, und PGs werden tatsächlich automatisch skaliert. Bei dem Upgrade wird der pg_autoscale_mode von bestehenden Pools nicht automatisch geändert. Wenn Sie die Einstellung zu on ändern möchten, um die Vorteile des Autoscalers voll auszuschöpfen, lesen Sie die Anweisungen im Abschnitt 17.4.12, „Aktivieren der PG-Autoskalierung“.

    Weitere Informationen finden Sie in Abschnitt 17.4.12, „Aktivieren der PG-Autoskalierung“.

  4. Verhindern Sie Clients aus Versionen vor Luminous:

    cephuser@adm > ceph osd set-require-min-compat-client luminous
  5. Aktivieren Sie das Ausgleichsprogramm-Modul:

    cephuser@adm > ceph balancer mode upmap
    cephuser@adm > ceph balancer on

    Weitere Informationen finden Sie im Abschnitt 29.1, „Ausgleichsprogramm“.

  6. Aktivieren Sie optional das Telemetriemodul:

    cephuser@adm > ceph mgr module enable telemetry
    cephuser@adm > ceph telemetry on

    Weitere Informationen finden Sie im Abschnitt 29.2, „Aktivieren des Telemetriemoduls“.

Diese Seite drucken