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

7 Upgrade von einer früheren Version Edit source

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

Das Upgrade umfasst die folgenden Aufgaben:

  • Upgrade von Ceph Nautilus zu Octopus.

  • 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-Plattform implementieren möchten.

Wichtig
Wichtig

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

7.1 Vor dem Aufrüsten Edit source

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.

7.1.1 Zu berücksichtigende Aspekte Edit source

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

  • 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 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 finden Sie online unter https://www.suse.com/releasenotes/.

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

  • Lesen Sie Kapitel 5, Bereitstellung mit cephadm, 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 danach DeepSea durch ceph-salt und cephadm ersetzen. Sie können das cephadm-Orchestrator-Modul erst dann verwenden, wenn mindestens für alle Ceph-Manager ein Upgrade durchgeführt wurde.

  • Das Upgrade von Nautilus-RPMs auf Octopus-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 SP2 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 in diesem Fall 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 SP2 außer Betrieb und erneut für kurze Zeit, wenn die einzelnen Services im containerisierten Modus neu bereitgestellt werden.

7.1.2 Sichern der Cluster-Konfiguration und -Daten Edit source

Wir empfehlen dringend, vor Beginn des Upgrades auf SUSE Enterprise Storage 7 alle Cluster-Konfigurationen und -Daten zu sichern. Eine Anleitung zur Sicherung aller Daten finden Sie unter https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup.

7.1.3 Überprüfen der Schritte des vorherigen Upgrades Edit source

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.

7.1.4 Aktualisieren von Cluster-Knoten und Überprüfen des Zustands des Clusters Edit source

Ü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:

root # zypper refresh && zypper patch

Überprüfen Sie nach der Anwendung der Aktualisierungen den Zustand des Clusters:

cephuser@adm > ceph -s

7.1.5 Überprüfen des Zugriffs auf Software-Repositorys und Container-Images Edit source

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

7.1.5.1 Software-Repositorys Edit source

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

  • SLE-Module-Basesystem/15-SP2

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

  • SUSE-Enterprise-Storage-7

7.1.5.2 Container-Images Edit source

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

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

  • registry.suse.com/caasp/v4.5/prometheus-server

  • registry.suse.com/caasp/v4.5/prometheus-node-exporter

  • registry.suse.com/caasp/v4.5/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 5.3.2.11, „Konfigurieren der Container-Registrierung“.

7.2 Upgrade des Salt Masters Edit source

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 SP2 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

    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 15.2.2-60-gf5864377ab (f5864377abb5549f843784c93577980aa264b9bc) octopus (stable)
     os: SUSE Linux Enterprise Server 15 SP2
    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)

7.3 Upgrade der MON-, MGR- und OSD-Knoten Edit source

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. 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
    [...]
  2. Führen Sie ein Upgrade des zugrunde liegenden Betriebssystems auf SUSE Linux Enterprise Server 15 SP2 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.

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

7.4 Upgrade von Gateway-Knoten Edit source

Führen Sie als Nächstes ein Upgrade der separaten Gateway-Knoten (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 SP2 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).

Sobald für das Betriebssystem auf allen Knoten im Cluster ein Upgrade durchgeführt wurde, wird im nächsten Schritt das Paket ceph-salt installiert und die Cluster-Konfiguration angewendet. 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 SP2 nicht mehr verfügbar. Sie müssen am Ende des Upgrade-Vorgangs erneut bereitgestellt werden.

7.5 Installieren von ceph-salt und Anwenden der Cluster-Konfiguration Edit source

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 5.3.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 5.3.2.11, „Konfigurieren 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

7.6 Upgrade und Übernahme des Überwachungs-Stacks Edit source

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 das Standard-Container-Image registry.suse.com ausführen, müssen Sie das zu verwendende Image angeben, zum Beispiel:

    cephuser@adm > cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-server:2.18.0 \
      adopt --style=legacy --name prometheus.$(hostname)
    cephuser@adm > cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-alertmanager:0.16.2 \
      adopt --style=legacy --name alertmanager.$(hostname)
    cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7/ceph/grafana:7.0.3 \
     adopt --style=legacy --name grafana.$(hostname)

    Weitere Details zur Verwendung benutzerdefinierter oder lokaler Container-Images finden Sie im Abschnitt 16.1, „Konfigurieren von benutzerdefinierten oder lokalen Images“.

  3. Entfernen Sie den Node Exporter. Er muss nicht migriert werden und wird als Container neu installiert, wenn die Datei specs.yaml angewendet wird.

    tux > sudo zypper rm golang-github-prometheus-node_exporter
  4. Wenden Sie die zuvor aus DeepSea exportierten Servicespezifikationen an:

    cephuser@adm > ceph orch apply -i specs.yaml
  5. Setzen Sie den Orchestrator fort:

    cephuser@adm > ceph orch resume

7.7 Erneute Bereitstellung des Gateway-Service Edit source

7.7.1 Upgrade des Object Gateways Edit source

In SUSE Enterprise Storage 7 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 tatsächlich zu nutzen, ist es in Ordnung, die Standardwerte für die Namen des Bereichs, der Zonengruppe und der Zone zu 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 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 5.4.3.4, „Bereitstellen von Object Gateways“ beschrieben, und wenden Sie sie an.

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

7.7.2 Upgrade von NFS Ganesha Edit source

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.

Bevor Sie eine Migration durchführen, empfehlen wir dringend, eine Kopie der Export- und der Daemon-Konfigurationsobjekte zu erstellen, die sich im RADOS-Pool befinden. Führen Sie das folgende Kommando aus, um den konfigurierten RADOS-Pool zu finden:

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 ein bestehender 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 5.4.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/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 7.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

7.7.3 Upgrade des Metadata Servers Edit source

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

7.7.4 Upgrade des iSCSI Gateways Edit source

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:

    tux > sudo systemctl stop rbd-target-gw
    tux > sudo systemctl disable rbd-target-gw
    tux > sudo systemctl stop rbd-target-api
    tux > sudo systemctl disable rbd-target-api
  2. Erstellen Sie eine Servicespezifikation für das iSCSI Gateway, wie in Abschnitt 5.4.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 bisherige ceph-iscsi -Paket aus allen bestehenden iSCSI Gateway-Knoten:

    cephuser@adm > zypper rm -u ceph-iscsi

7.8 Bereinigung nach dem Upgrade Edit source

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 octopus
  3. Aktivieren Sie das Autoscaler-Modul:

    cephuser@adm > ceph mgr module enable pg_autoscaler
    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 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“.