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

6 Upgrade von vorigen Versionen Edit source

In diesem Kapitel finden Sie die Schritte zum Aufrüsten von SUSE Enterprise Storage 5.5 auf Version 6. Version 5.5 entspricht im Grunde der Version 5, auf die alle aktuellen Patches angewendet wurden.

Anmerkung
Anmerkung: Keine Unterstützung für das Upgrade älterer Versionen

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

6.1 Vor dem Upgrade zu beachtende Punkte Edit source

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

    • Sind bei der Hardware besondere Überlegungen zu beachten?

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

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

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

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

  • Falls Sie zuvor Version 4 aufgerüstet haben, prüfen Sie, ob das Upgrade auf Version 5 erfolgreich abgeschlossen wurde:

    • Prüfen Sie, ob folgende Datei vorhanden ist:

      /srv/salt/ceph/configuration/files/ceph.conf.import

      Die Datei wird beim Importprozess während des Upgrades von SES 4 auf 5 erstellt. Außerdem wird die Option configuration_init: default-import in folgender Datei festgelegt:

      /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml

      Wenn configuration_init noch auf default-import eingestellt ist, greift der Cluster auf ceph.conf.import als Konfigurationsdatei zurück, nicht auf die Standarddatei ceph.conf von DeepSea, die aus Dateien in folgendem Verzeichnis kompiliert wird:

      /srv/salt/ceph/configuration/files/ceph.conf.d/

      Sie müssen daher ceph.conf.import auf benutzerdefinierte Konfigurationen prüfen und diese Konfigurationen ggf. in eine der Dateien in folgendem Verzeichnis verschieben:

      /srv/salt/ceph/configuration/files/ceph.conf.d/

      Entfernen Sie anschließend die Zeile configuration_init: default-import aus

      /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
      Warnung
      Warnung: Standardmäßige DeepSea-Konfiguration

      Wenn Sie nicht die Konfiguration aus ceph.conf.import zusammenführen und die Option configuration_init: default-import entfernen, werden alle standardmäßigen Konfigurationseinstellungen von DeepSea (in /srv/salt/ceph/configuration/files/ceph.conf.j2 gespeichert) nicht auf den Cluster angewendet.

    • Prüfen Sie, ob der Cluster den neuen Bucket-Typ „straw2“ nutzt:

      cephadm@adm > ceph osd crush dump | grep straw
    • Prüfen Sie, ob das Ceph Profil „jewel“ verwendet wird:

      cephadm@adm > ceph osd crush dump | grep profile
  • Werden ältere RBD-Kernel-Clients (vor SUSE Linux Enterprise Server 12 SP3) verwendet, beachten Sie Abschnitt 12.9, „RBD-Zuordnung mit älteren Kernel-Clients“. Es wird empfohlen, ältere RBD-Kernel-Clients nach Möglichkeit aufzurüsten.

  • Wenn sich openATTIC auf dem Admin Node befindet, ist es nach dem Aufrüsten des Knotens nicht mehr verfügbar. Das neue Ceph Dashboard ist dann verfügbar, wenn Sie es mit DeepSea implementiert haben.

  • 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 Nodes durchzuführen.

  • Ein einzelner Knoten kann nicht aufgerüstet werden, wenn darauf noch die vorherige SUSE Linux Enterprise Server-Version ausgeführt wird, sondern muss mit dem Installationsprogramm der neuen Version neu gestartet werden. Die Services, die dieser Knoten anbietet, stehen daher eine gewisse Zeit lang nicht zur Verfügung. Die wesentlichen Cluster-Services sind weiterhin verfügbar – ist beispielsweise ein MON während des Upgrades inaktiv, gibt es dennoch mindestens zwei aktive MONs. Services, für die nur eine einzelne Instanz vorliegt, z. B. ein einzelnes iSCSI-Gateway, stehen leider nicht zur Verfügung.

  • Bestimmte Arten von Daemons hängen von anderen ab. Beispielsweise hängen Object Gateways von Ceph MON und Ceph OSD Daemons ab. Wir empfehlen für das Upgrade die folgende Reihenfolge:

    1. Admin Node

    2. Ceph Monitors/Ceph Managers

    3. Metadata Server

    4. Ceph OSDs

    5. Object Gateways

    6. iSCSI Gateways

    7. NFS Ganesha

    8. Samba Gateways

  • Wenn Sie AppArmor im Modus „complain“ oder „enforce“ ausgeführt hatten, müssen Sie vor dem Upgrade eine Salt-Pillar-Variable festlegen. SUSE Linux Enterprise Server 15 SP1 umfasst standardmäßig AppArmor, weshalb die AppArmor-Verwaltung in die DeepSea-Phase 0 integriert wurde. Laut dem Standardverhalten in SUSE Enterprise Storage 6 werden AppArmor und die zugehörigen Profile entfernt. Soll das in SUSE Enterprise Storage 5.5 konfigurierte Verhalten beibehalten werden, prüfen Sie, ob die Datei /srv/pillar/ceph/stack/global.yml eine der folgenden Zeilen enthält, bevor Sie das Upgrade starten:

    apparmor_init: default-enforce

    oder

    apparmor_init: default-complain
  • Ab SUSE Enterprise Storage 6 sind MDS-Namen, die mit einer Ziffer beginnen, nicht mehr zulässig und MDS-Daemons werden nicht gestartet. Sie können prüfen, ob Ihre Daemons solche Namen aufweisen. Führen Sie hierzu entweder das Kommando ceph fs status aus oder starten Sie einen MDS neu und prüfen Sie, ob dessen Protokolle die folgende Meldung enthalten:

    deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden in
    a future version.  MDS names may not start with a numeric digit.

    Wird die obige Meldung angezeigt, müssen die MDS-Namen migriert werden, bevor Sie auf SUSE Enterprise Storage 6 aufrüsten können. DeepSea umfasst eine Orchestrierung, mit der diese Migration automatisiert wird. Den MDS-Namen, die mit einer Ziffer beginnen, wird „mds“ vorangestellt.:

    root@master # salt-run state.orch ceph.mds.migrate-numerical-names
    Tipp
    Tipp: Benutzerdefinierte Konfiguration mit Bindung an MDS-Namen

    Wenn bestimmte Konfigurationseinstellungen an MDS-Namen gebunden sind und die Namen Ihrer MDS-Daemons mit einer Ziffer beginnen, prüfen Sie, ob Ihre Konfigurationseinstellungen auch für die neuen Namen angewendet werden (mit dem Präfix „mds“). Betrachten Sie den folgenden Beispielabschnitt in der Datei /etc/ceph/ceph.conf:

    [mds.123-my-mds] # config setting specific to MDS name with a name starting with a digit
    mds cache memory limit = 1073741824
    mds standby for name = 456-another-mds

    Der Orchestrator ceph.mds.migrate-numerical-names ersetzt den MDS-Daemon-Namen „123-my-mds“ durch „mds.123-my-mds“. Sie müssen die Konfiguration gemäß dem neuen Namen anpassen:

    [mds.mds,123-my-mds] # config setting specific to MDS name with the new name
    mds cache memory limit = 1073741824
    mds standby for name = mds.456-another-mds

    Damit werden MDS-Daemons mit den neuen Namen eingefügt, bevor die bisherigen MDS-Daemons entfernt werden. Die Anzahl der MDS-Daemons verdoppelt sich für kurze Zeit. Die Clients können erst nach einer kurzen Pause für das Failover auf CephFS zugreifen. Planen Sie die Migration daher für einen Zeitraum, in dem Sie nur eine geringe oder gar keine CephFS-Auslastung erwarten.

6.2 Sichern von Clusterdaten Edit source

Die Sicherung der Konfiguration und Daten eines Clusters ist nicht obligatorisch. Es wird jedoch dringend empfohlen, wichtige Konfigurationsdateien und Clusterdaten zu sichern. Weitere Informationen finden Sie in Kapitel 3, Sichern der Cluster-Konfiguration und -Daten.

6.3 Migration von ntpd zu chronyd Edit source

SUSE Linux Enterprise Server 15 SP1 synchronisiert die Uhrzeit des lokalen Hosts nicht mehr über ntpd. Stattdessen wird chronyd verwendet. Sie müssen den Zeitsynchronisierungs-Daemon auf jedem Cluster Node migrieren. Sie können wahlweise vor dem Cluster-Upgrade zu chronyd migrieren oder zunächst den Cluster aufrüsten und die Migration zu chronyd danach durchführen.

Prozedur 6.1: Migration zu chronyd vor dem Cluster-Upgrade
  1. Installieren Sie das Paket chrony :

    root@minion > zypper install chrony
  2. Bearbeiten Sie die chronyd-Konfigurationsdatei /etc/chrony.conf und fügen Sie NTP-Quellen aus der aktuellen ntpd-Konfiguration in /etc/ntp.conf ein.

    Tipp
    Tipp: Weitere Informationen zur chronyd-Konfiguration

    In https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html finden Sie weitere Anweisungen, wie Sie Zeitquellen in die chronyd-Konfiguration einfügen.

  3. Deaktivieren und stoppen Sie den ntpd-Service:

    root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service
  4. Starten und aktivieren Sie den chronyd-Service:

    root@minion > systemctl start chronyd.service && systemctl enable chronyd.service
  5. Überprüfen Sie den Status von „chrony“:

    root@minion > chronyc tracking
Prozedur 6.2: Migration zu chronyd nach dem Cluster-Upgrade
  1. Fügen Sie während des Cluster-Upgrades die folgenden Software-Repositorys ein:

    • SLE-Module-Legacy15-SP1-Pool

    • SLE-Module-Legacy15-SP1-Updates

  2. Rüsten Sie den Cluster auf Version 6 auf.

  3. Bearbeiten Sie die chronyd-Konfigurationsdatei /etc/chrony.conf und fügen Sie NTP-Quellen aus der aktuellen ntpd-Konfiguration in /etc/ntp.conf ein.

    Tipp
    Tipp: Weitere Informationen zur chronyd-Konfiguration

    In https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html finden Sie weitere Anweisungen, wie Sie Zeitquellen in die chronyd-Konfiguration einfügen.

  4. Deaktivieren und stoppen Sie den ntpd-Service:

    root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service
  5. Starten und aktivieren Sie den chronyd-Service:

    root@minion > systemctl start chronyd.service && systemctl enable chronyd.service
  6. Migrieren Sie von ntpd zu chronyd.

  7. Überprüfen Sie den Status von „chrony“:

    root@minion > chronyc tracking
  8. Entfernen Sie die eingefügten Legacy-Software-Repositorys, mit denen ntpd während des Upgrade-Prozesses im System beibehalten wurde.

6.4 Patchen des Clusters vor dem Upgrade Edit source

Wenden Sie die aktuellen Patches vor dem Upgrade auf alle Cluster Nodes an.

6.4.1 Erforderliche Software-Repositorys Edit source

Prüfen Sie, ob die erforderlichen Repositorys auf den einzelnen Knoten konfiguriert sind. Mit folgendem Kommando rufen Sie eine Liste aller verfügbaren Repositorys ab:

root@minion > zypper lr

Für SUSE Enterprise Storage 5.5 erforderlich:

  • SLES12-SP3-Installer-Updates

  • SLES12-SP3-Pool

  • SLES12-SP3-Updates

  • SUSE-Enterprise-Storage-5-Pool

  • SUSE-Enterprise-Storage-5-Updates

Für NFS/SMB Gateway auf SLE-HA unter SUSE Linux Enterprise Server 12 SP3 erforderlich:

  • SLE-HA12-SP3-Pool

  • SLE-HA12-SP3-Updates

6.4.2 Repository-Staging-Systeme Edit source

Wenn Sie mit einem Repository-Staging-System arbeiten (SMT, RMT oder SUSE Manager), erstellen Sie eine neue, eingefrorene Patchstufe für die aktuelle und die neue SUSE Enterprise Storage-Version.

Weitere Informationen finden Sie in:

6.4.3 Patchen des gesamten Clusters mit den aktuellen Patches Edit source

  1. Wenden Sie die aktuellen Patches für SUSE Enterprise Storage 5.5 und SUSE Linux Enterprise Server 12 SP3 auf jeden Ceph Cluster Node an. Prüfen Sie, ob die richtigen Software-Repositorys mit den einzelnen Cluster Nodes verbunden sind (siehe Abschnitt 6.4.1, „Erforderliche Software-Repositorys“) und führen Sie die DeepSea-Phase 0 aus:

    root@master # salt-run state.orch ceph.stage.0
  2. Prüfen Sie nach Abschluss der Phase 0, ob der Status der einzelnen Cluster „HEALTH_OK“ umfasst. Falls nicht, beheben Sie das Problem, bevor Sie etwaige Neustarts in nachfolgenden Schritten vornehmen.

  3. Prüfen Sie mit zypper ps, ob Prozesse vorliegen, die mit veralteten Bibliotheken oder Binärdateien ausgeführt werden, und starten Sie die betreffenden Prozesse neu.

  4. Prüfen Sie, ob der ausgeführte Kernel die aktuell verfügbare Version aufweist, und starten Sie ihn neu, wenn dies nicht der Fall ist. Prüfen Sie die Ausgabe der folgenden Kommandos:

    cephadm@adm > uname -a
    cephadm@adm > rpm -qa kernel-default
  5. Prüfen Sie, ob das Paket ceph in Version 12.2.12 (oder höher) vorliegt. Prüfen Sie, ob das Paket deepsea in Version 0.8.9 (oder höher) vorliegt.

  6. Wenn Sie bislang mit Einstellungen für bluestore_cache gearbeitet haben, sind diese Einstellungen ab ceph Version 12.2.10 nicht mehr in Kraft. Die neue Einstellung bluestore_cache_autotune, die standardmäßig auf „true“ eingestellt ist, deaktiviert die manuelle Festlegung der Cache-Größe. Soll das bisherige Verhalten wieder aktiviert werden, legen Sie bluestore_cache_autotune=false fest. Weitere Informationen finden Sie unter Abschnitt 16.2.1, „Automatische Festlegung der Cache-Größe“.

6.5 Überprüfen der aktuellen Umgebung Edit source

  • Wenn offensichtliche Probleme im System vorliegen, beheben Sie sie, bevor Sie das Upgrade starten. Allein durch das Upgrade werden bestehende Systemprobleme unter keinen Umständen behoben.

  • Prüfen Sie die Cluster-Leistung. Wählen Sie hierzu unter Kommandos wie rados bench, ceph tell osd.* bench oder iperf3.

  • Prüfen Sie den Zugriff auf Gateways (z. B. iSCSI-Gateway oder Object Gateway) und auf RADOS Block Device.

  • Dokumentspezifische Teile der Systemeinrichtung, z. B. Details zur Netzwerkeinrichtung, Partitionierung oder Installation.

  • Stellen Sie wichtige Systeminformationen mit supportconfig zusammen und speichern Sie sie außerhalb der Cluster Nodes. Weitere Informationen finden Sie in https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html.

  • Prüfen Sie, ob ausreichend freier Speicherplatz auf jedem Cluster Node bereitsteht. Prüfen Sie den freien Speicherplatz mit df -h. Bei Bedarf geben Sie Speicherplatz frei: Entfernen Sie nicht mehr benötigte Dateien/Verzeichnisse oder veraltete OS-Snapshots. Falls der Speicherplatz nicht ausreicht, setzen Sie das Upgrade erst dann fort, wenn Sie genügend Speicherplatz freigegeben haben.

6.6 Prüfen des Cluster-Status Edit source

  • Führen Sie das Kommando cluster health aus, bevor Sie den Upgrade-Vorgang starten. Starten Sie das Upgrade erst dann, wenn jeder Cluster Node „HEALTH_OK“ meldet.

  • Prüfen Sie, ob alle Services ausgeführt werden:

    • Salt Master und Salt Master Daemons.

    • Ceph Monitor und Ceph Manager Daemons.

    • Metadatenserver Daemons.

    • Ceph OSD Daemons.

    • Object Gateway-Daemons.

    • iSCSI-Gateway-Daemons.

Die folgenden Kommandos geben Details zum Cluster-Status und zur jeweiligen Konfiguration zurück:

ceph -s

Gibt eine kurze Zusammenfassung des Ceph Cluster-Zustands, der ausgeführten Services, der Datenauslastung und der E/A-Statistik zurück. Prüfen Sie, ob die Meldung „HEALTH_OK“ vorliegt, bevor Sie das Upgrade starten.

ceph health detail

Gibt Details zurück, wenn der Ceph Cluster-Zustand nicht in Ordnung ist.

ceph versions

Gibt die Versionen der ausgeführten Ceph Daemons zurück.

ceph df

Gibt den gesamten und den freien Speicherplatz auf dem Cluster zurück. Starten Sie das Upgrade nur dann, wenn der freie Speicherplatz im Cluster bei mindestens 25 % des gesamten Speicherplatzes liegt.

salt '*' cephprocesses.check results=true

Gibt die ausgeführten Ceph-Prozesse und ihre PIDs zurück, sortiert nach den Salt Minions.

ceph osd dump | grep ^flags

Prüfen Sie, ob die Flaggen „recovery_deletes“ und „purged_snapdirs“ vorhanden sind. Falls nicht, können Sie mit folgendem Kommando ein Scrubbing für alle Platzierungsgruppen erzwingen: Beachten Sie, dass dieses erzwungene Scrubbing die Leistung Ihrer Ceph Clients unter Umständen negativ beeinflusst.

cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub

6.7 Offline-Upgrade von CTDB-Clustern Edit source

CTDB umfasst eine geclusterte Datenbank, die von Samba Gateways herangezogen wird. Das CTDB-Protokoll ist sehr einfach und unterstützt keine Cluster mit Knoten, die mit anderen Protokollversionen kommunizieren. CTDB-Knoten müssen daher vor einem Upgrade offline geschaltet werden.

6.8 Upgrade Knoten für Knoten – Grundverfahren Edit source

Damit die wesentlichen Cluster-Services auch während des Upgrades verfügbar sind, müssen Sie die Cluster Nodes einzeln nacheinander aufrüsten. Für das Upgrade eines Knotens stehen zwei Möglichkeiten zur Auswahl: entweder mit der Installationsprogramm-DVD oder mit dem Distribution Migration System.

Nach dem Aufrüsten der einzelnen Knoten wird empfohlen, mit rpmconfigcheck nach aktualisierten Konfigurationsdateien zu suchen, die lokal bearbeitet wurden. Wenn das Kommando eine Liste von Dateinamen mit dem Suffix .rpmnew, .rpmorig oder .rpmsave zurückgibt, vergleichen Sie diese Dateien mit den aktuellen Konfigurationsdateien, damit gewährleistet ist, dass keine lokalen Änderungen verloren gehen. Aktualisieren Sie ggf. die betroffenen Dateien. Weitere Informationen zur Verwendung von .rpmnew-, .rpmorig- und .rpmsave-Dateien finden Sie in https://documentation.suse.com/sles/15-SP1/single-html/SLES-admin/#sec-rpm-packages-manage.

Tipp
Tipp: Bezuglose Pakete

Nach dem Aufrüsten eines Knotens sind einige Pakete „bezuglos“, besitzen also kein übergeordnetes Repository mehr. Dieser Fall tritt ein, da python2-Pakete nicht automatisch veraltet sind, wenn python3-spezifische Pakete vorliegen.

Weitere Informationen zum Abrufen bezugloser Pakete finden Sie in https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned.

6.8.1 Manuelles Knoten-Upgrade mit der Installationsprogramms-DVD Edit source

  1. Starten Sie den Knoten von der Installationsprogramm-DVD/dem Image mit Linux Enterprise Server 15 SP1 neu.

  2. Wählen Sie im Boot-Menü die Option Upgrade.

  3. Prüfen Sie im Bildschirm Select the Migration Target (Migrationsziel auswählen), ob „SUSE Linux Enterprise Server 15 SP1“ ausgewählt ist, und aktivieren Sie das Kontrollkästchen Manually Adjust the Repositories for Migration (Repositorys für Migration manuell anpassen).

    Auswahl des Migrationsziels
    Abbildung 6.1: Auswahl des Migrationsziels
  4. Wählen Sie die folgenden Module zur Installation aus:

    • SUSE Enterprise Storage 6 x86_64

    • Basesystem Module 15 SP1 x86_64

    • Desktop Applications Module 15 SP1 x86_64

    • Legacy Module 15 SP1 x86_64

    • Server Applications Module 15 SP1 x86_64

  5. Prüfen Sie im Bildschirm Previously Used Repositories (Bisher verwendete Repositorys), ob die richtigen Repositorys ausgewählt sind. Falls das System nicht bei SCC/SMT registriert ist, müssen Sie die Repositorys manuell einfügen.

    Für SUSE Enterprise Storage 6 erforderlich:

    • SLE-Module-Basesystem15-SP1-Pool

    •  SLE-Module-Basesystem15-SP1-Updates

    •  SLE-Module-Server-Applications15-SP1-Pool

    •  SLE-Module-Server-Applications15-SP1-Updates

    • SLE-Module-Desktop-Applications15-SP1-Pool

    • SLE-Module-Desktop-Applications15-SP1-Updates

    •  SLE-Product-SLES15-SP1-Pool

    •  SLE-Product-SLES15-SP1-Updates

    •  SLE15-SP1-Installer-Updates

    •  SUSE-Enterprise-Storage-6-Pool

    •  SUSE-Enterprise-Storage-6-Updates

    Wenn ntpd nach der SES-Migration zu chronyd migriert werden soll (siehe Abschnitt 6.3, „Migration von ntpd zu chronyd), fügen Sie die folgenden Repositorys ein:

    • SLE-Module-Legacy15-SP1-Pool

    • SLE-Module-Legacy15-SP1-Updates

    Für NFS/SMB Gateway auf SLE-HA unter SUSE Linux Enterprise Server 15 SP1 erforderlich:

    • SLE-Product-HA15-SP1-Pool

    • SLE-Product-HA15-SP1-Updates

  6. Prüfen Sie die Installation Settings (Installationseinstellungen) und starten Sie den Installationsvorgang mit Update (Aktualisieren).

6.8.2 Knoten-Upgrade mit dem SUSE Distribution Migration System Edit source

Das Distribution Migration System (DMS) bietet einen Pfad für das Upgrade eines installierten SUSE Linux Enterprise-Systems von einer Hauptversion auf eine andere Hauptversion. Im nachfolgenden Verfahren wird SUSE Enterprise Storage 5.5 mit DMS auf Version 6 aufgerüstet, wobei auch die zugrunde liegende Migration von SUSE Linux Enterprise Server 12 SP3 auf SUSE Linux Enterprise Server 15 SP1 durchgeführt wird.

Allgemeine und ausführliche Informationen zu DMS finden Sie in https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/.

  1. Installieren Sie die RPM-Pakete für die Migration. Damit wird der GRUB-Bootloader so angepasst, dass das Upgrade beim nächsten Neustart automatisch ausgelöst wird. Installieren Sie das Paket SLES15-SES-Migration und suse-migration-sle15-activation :

    root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation
    1. Ist der aufzurüstende Knoten bei einem Repository-Staging-System wie SCC, SMT, RMT oder SUSE Manager registriert, erstellen Sie /etc/sle-migration-service.yml mit folgendem Inhalt:

      use_zypper_migration: true
      preserve:
        rules:
          - /etc/udev/rules.d/70-persistent-net.rules
    2. Ist der aufzurüstende Knoten nicht bei einem Repository-Staging-System wie SCC, SMT, RMT oder SUSE Manager registriert, nehmen Sie die folgenden Änderungen vor:

      1. Erstellen Sie /etc/sle-migration-service.yml mit folgendem Inhalt:

        use_zypper_migration: false
        preserve:
          rules:
            - /etc/udev/rules.d/70-persistent-net.rules
      2. Deaktivieren oder entfernen Sie die Repositorys für SLE 12 SP3 und SES 5 und fügen Sie die Repositorys für SLE 15 SP1 und SES 6 ein. Eine Liste der zugehörigen Repositorys finden Sie in Abschnitt 6.4.1, „Erforderliche Software-Repositorys“.

  2. Führen Sie einen Neustart durch, sodass das Upgrade gestartet wird. Während des laufenden Upgrades können Sie sich vom Hostsystem aus über ssh mit dem vorhandenen SSH-Schlüssel als Migrationsbenutzer anmelden (siehe https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/). Wenn Sie bei SUSE Enterprise Storage den physischen Zugriff oder den direkten Konsolenzugriff auf den Computer besitzen, können Sie sich auch an der Systemkonsole als root mit dem Passwort sesupgrade anmelden. Der Knoten wird nach dem Upgrade automatisch neu gestartet.

    Tipp
    Tipp: Upgrade-Fehler

    Wenn das Upgrade fehlschlägt, prüfen Sie /var/log/distro_migration.log. Beheben Sie das Problem, installieren Sie die RPM-Pakete für die Migration erneut und starten Sie den Knoten neu.

6.9 Upgrade des Admin Node Edit source

Tipp
Tipp: Status der Cluster Nodes

Nach dem Upgrade des Admin Node können Sie mit dem Kommando salt-run upgrade.status nützliche Informationen zu den Cluster Nodes abrufen. Mit diesem Kommando werden die Ceph- und OS-Versionen aller Knoten aufgelistet und Sie erhalten eine Empfehlung für die Reihenfolge, in der die Knoten aufgerüstet werden sollten, auf denen noch ältere Versionen ausgeführt werden.

root@master # salt-run upgrade.status
The newest installed software versions are:
  ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable)
  os: SUSE Linux Enterprise Server 15 SP1

Nodes running these software versions:
  admin.ceph (assigned roles: master)
  mon2.ceph (assigned roles: admin, mon, mgr)

Nodes running older software versions must be upgraded in the following order:
   1: mon1.ceph (assigned roles: admin, mon, mgr)
   2: mon3.ceph (assigned roles: admin, mon, mgr)
   3: data1.ceph (assigned roles: storage)
[...]

6.10 Upgrade von Ceph Monitor/Ceph Manager Nodes Edit source

  • Wenn Ihr Cluster keine MDS-Rollen nutzt, rüsten Sie die MON/MGR Nodes einzeln nacheinander auf.

  • Wenn der Cluster MDS-Rollen nutzt und sich die MON/MGR- und MDS-Rollen auf demselben Rechner befinden, müssen Sie den MDS Cluster verkleinern und dann die auf demselben Rechner befindlichen Knoten aufrüsten. Weitere Informationen finden Sie in Abschnitt 6.11, „Upgrade von Metadatenservern“.

  • Wenn Ihr Cluster MDS-Rollen nutzt und diese Rollen auf dedizierten Servern ausgeführt werden, rüsten Sie alle MON/MGR Nodes einzeln nacheinander auf; verkleinern Sie dann den MDS Cluster und rüsten Sie ihn auf. Weitere Informationen finden Sie in Abschnitt 6.11, „Upgrade von Metadatenservern“.

Anmerkung
Anmerkung: Upgrade von Ceph Monitor

Aufgrund einer Einschränkung im Ceph Monitor-Design gilt Folgendes: Sobald zwei MONs auf SUSE Enterprise Storage 6 aufgerüstet wurden und ein Quorum gebildet haben, wird der dritte MON (auf dem weiterhin SUSE Enterprise Storage 5.5 ausgeführt wird) nicht wieder in den MON-Cluster aufgenommen, wenn er neu gestartet wurde (z. B. nach dem Neustart eines Knotens). Wenn zwei MONs aufgerüstet wurden, sollten die restlichen MONs daher so rasch wie möglich ebenfalls aufrüstet werden.

Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.

6.11 Upgrade von Metadatenservern Edit source

Sie müssen den Metadatenserver (MDS)-Cluster verkleinern. Aufgrund einer Inkompatibilität bestimmter Funktionen in den SUSE Enterprise Storage-Versionen 5.5 und 6 werden die älteren MDS-Daemons heruntergefahren, sobald ein einzelner MDS mit SES 6 in den Cluster eingefügt wird. Für die Dauer des Upgrades der MDS Nodes muss der MDS-Cluster daher auf einen einzelnen aktiven MDS (ohne Standbys) verkleinert werden. Sobald der zweite Knoten aufgerüstet wurde, können Sie den MDS-Cluster wieder erweitern.

Tipp
Tipp

Auf einem stark ausgelasteten MDS-Cluster müssen Sie die Auslastung ggf. vermindern (z. B. Clients anhalten), sodass ein einzelner MDS den gesamten Workload tragen kann.

  1. Beachten Sie den aktuellen Wert der Option max_mds:

    cephadm@adm > ceph fs get cephfs | grep max_mds
  2. Verkleinern Sie den MDS-Cluster, wenn mehrere aktive MDS-Daemons vorliegen, also wenn max_mds > 1 ist. Mit folgendem Kommando verkleinern Sie den MDS-Cluster:

    cephadm@adm > ceph fs set FS_NAME max_mds 1

    FS_NAME bezeichnet hierbei den Namen der CephFS-Instanz (standardmäßig „cephfs“).

  3. Ermitteln Sie den Knoten, auf dem einer der Standby-MDS-Daemons ausgeführt wird. Betrachten Sie die Ausgabe des Kommandos ceph fs status und starten Sie das Upgrade des MDS-Clusters auf diesem Knoten.

    cephadm@adm > ceph fs status
    cephfs - 2 clients
    ======
    +------+--------+--------+---------------+-------+-------+
    | Rank | State  |  MDS   |    Activity   |  dns  |  inos |
    +------+--------+--------+---------------+-------+-------+
    |  0   | active | mon1-6 | Reqs:    0 /s |   13  |   16  |
    +------+--------+--------+---------------+-------+-------+
    +-----------------+----------+-------+-------+
    |       Pool      |   type   |  used | avail |
    +-----------------+----------+-------+-------+
    | cephfs_metadata | metadata | 2688k | 96.8G |
    |   cephfs_data   |   data   |    0  | 96.8G |
    +-----------------+----------+-------+-------+
    +-------------+
    | Standby MDS |
    +-------------+
    |    mon3-6   |
    |    mon2-6   |
    +-------------+

    In diesem Beispiel müssen Sie den Upgrade-Vorgang entweder auf dem Knoten „mon3-6“ oder auf dem Knoten „mon2-6“ starten.

  4. Rüsten Sie den Knoten mit dem Standby-MDS-Daemon auf. Sobald der aufgerüstete MDS-Knoten startet, werden die veralteten MDS-Daemons automatisch heruntergefahren. Zu diesem Zeitpunkt kann der CephFS-Service für die Clients kurzzeitig ausfallen.

    Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.

  5. Rüsten Sie die verbleibenden MDS-Knoten auf.

  6. Setzen Sie max_mds auf die gewünschte Konfiguration zurück:

    cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT

6.12 Upgrade von Ceph OSDs Edit source

Führen Sie die folgenden Schritte auf jedem Speicher-Node aus:

  1. Ermitteln Sie die OSD-Daemons, die auf einem bestimmten Knoten ausgeführt werden:

    cephadm@osd > ceph osd tree
  2. Legen Sie die Flagge „noout“ für jeden OSD Daemon auf dem aufzurüstenden Knoten fest:

    cephadm@osd > ceph osd add-noout osd.OSD_ID

    Beispiel:

    cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done

    Prüfen Sie mit:

    cephadm@osd > ceph health detail | grep noout

    oder

    cephadm@osd > ceph –s
    cluster:
     id:     44442296-033b-3275-a803-345337dc53da
     health: HEALTH_WARN
          6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set
  3. Erstellen Sie /etc/ceph/osd/*.json-Dateien für alle vorhandenen OSDs. Führen Sie hierzu das folgende Kommando auf dem aufzurüstenden Knoten aus:

    cephadm@osd > ceph-volume simple scan --force
  4. Rüsten Sie den OSD Node auf. Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.

  5. Aktivieren Sie alle im System aufgefundenen OSDs:

    cephadm@osd > ;ceph-volume simple activate --all
    Tipp
    Tipp: Aktivieren einzelner Datenpartitionen

    Sollen die Datenpartitionen einzeln aktiviert werden, müssen Sie das entsprechende Kommando ceph-volume für die jeweilige Partitionen ermitteln. Ersetzen Sie X1 durch den richtigen Buchstaben/die richtige Zahl der Partition:

     cephadm@osd > ceph-volume simple scan /dev/sdX1

    Beispiel:

    cephadm@osd > ceph-volume simple scan /dev/vdb1
    [...]
    --> OSD 8 got scanned and metadata persisted to file:
    /etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json
    --> To take over management of this scanned OSD, and disable ceph-disk
    and udev, run:
    -->     ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290

    Die letzte Zeile der Ausgabe enthält das Kommando, mit dem Sie die Partition aktivieren:

    cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
    [...]
    --> All ceph-disk systemd units have been disabled to prevent OSDs
    getting triggered by UDEV events
    [...]
    Running command: /bin/systemctl start ceph-osd@8
    --> Successfully activated OSD 8 with FSID
    d7bd2685-5b92-4074-8161-30d146cd0290
  6. Prüfen Sie, ob der OSD Node nach dem Neustart ordnungsgemäß gestartet wird.

  7. Reagieren Sie auf die Meldung „Legacy BlueStore stats reporting detected on XX OSD(s)“ (Gemeldete Legacy-BlueStore-Statistik auf XX OSD(s) erkannt):

    cephadm@osd > ceph –s
    cluster:
     id:     44442296-033b-3275-a803-345337dc53da
     health: HEALTH_WARN
     Legacy BlueStore stats reporting detected on 6 OSD(s)

    Diese Warnmeldung ist beim Upgrade von Ceph auf Version 14.2.2 normal. Mit folgender Einstellung können Sie sie deaktivieren:

    bluestore_warn_on_legacy_statfs = false

    Zur Problembehebung führen Sie das folgende Kommando auf allen OSDs aus, während sie gestoppt sind:

    cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX

    Das folgende Helper-Skript führt ceph-bluestore-tool repair für alle OSDs auf dem Knoten NODE_NAME aus:

    OSDNODE=OSD_NODE_NAME;\
     for OSD in $(ceph osd ls-tree $OSDNODE);\
     do echo "osd=" $OSD;\
     salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\
     salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\
     salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\
     done
  8. Heben Sie die Flagge „noout“ für jeden OSD Daemon auf dem aufzurüstenden Knoten auf:

    cephadm@osd > ceph osd rm-noout osd.OSD_ID

    Beispiel:

    cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done

    Prüfen Sie mit:

    cephadm@osd > ceph health detail | grep noout

    Hinweis:

    cephadm@osd > ceph –s
    cluster:
     id:     44442296-033b-3275-a803-345337dc53da
     health: HEALTH_WARN
     Legacy BlueStore stats reporting detected on 6 OSD(s)
  9. Prüfen Sie den Cluster-Status. Die Ausgabe ähnelt der folgenden:

    cephadm@osd > ceph status
    cluster:
      id:     e0d53d64-6812-3dfe-8b72-fd454a6dcf12
      health: HEALTH_WARN
              3 monitors have not enabled msgr2
    
    services:
      mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
      mgr: mon2(active, since 22m), standbys: mon1, mon3
      osd: 30 osds: 30 up, 30 in
    
    data:
      pools:   1 pools, 1024 pgs
      objects: 0 objects, 0 B
      usage:   31 GiB used, 566 GiB / 597 GiB avail
      pgs:     1024 active+clean
  10. Prüfen Sie, ob alle OSD Nodes neu gestartet und ob die OSDs nach dem Neustart automatisch gestartet wurden.

6.13 OSD-Migration zu BlueStore Edit source

OSD BlueStore ist ein neues Back-End für die OSD Daemons. Ab SUSE Enterprise Storage 5 ist dies die Standardoption. Verglichen mit FileStore, das Objekte als Dateien in einem XFS-Dateisystem speichert, kann BlueStore eine höhere Leistung bereitstellen, weil es Objekte direkt auf dem zugrundeliegenden Blockgerät speichert. BlueStore ermöglicht außerdem weitere Funktionen, wie integrierte Komprimierung und EC-Überschreibungen, die bei FileStore nicht zur Verfügung stehen.

Für BlueStore spezifisch umfasst ein OSD ein „wal“ (Write Ahead-Protokoll)-Gerät und ein „db“ (RocksDB-Datenbank)-Gerät. Die RocksDB-Datenbank enthält die Metadaten für einen BlueStore OSD. Diese beiden Geräte befinden sich standardmäßig auf demselben Gerät wie ein OSD, doch jedes der beiden kann auf andere (z. B. schnellere) Medien platziert werden.

In SUSE Enterprise Storage 5 werden sowohl FileStore als auch BlueStore unterstützt und FileStore und BlueStore OSDs können gemeinsam in einem einzelnen Cluster vorhanden sein. Während des Upgrade-Vorgangs für SUSE Enterprise Storage werden FileStore OSDs nicht automatisch zu BlueStore konvertiert. Beachten Sie, dass die BlueStore-spezifischen Funktionen nicht auf OSDs verfügbar sind, die nicht zu BlueStore migriert wurden.

Vor der Konvertierung zu BlueStore müssen die OSDs SUSE Enterprise Storage 5 ausführen. Der Konvertierungsvorgang ist langsam, weil alle Daten zweimal umgeschrieben werden. Obwohl der Migrationsvorgang möglicherweise lange dauert, fällt der Cluster nicht aus und alle Clients können währenddessen weiterhin auf den Cluster zugreifen. Rechnen Sie für die Dauer der Migration jedoch mit einer geringeren Leistung. Der Grund dafür besteht in einem Ausgleich und Abgleich der Cluster-Daten.

Gehen Sie bei der Migration von FileStore OSDs zu BlueStore folgendermaßen vor:

Tipp
Tipp: Sicherheitsmaßnahmen ausschalten

Salt-Kommandos, die zur Ausführung der Migration erforderlich sind, werden durch Sicherheitsmaßnahmen blockiert. Führen Sie folgendes Kommando aus, um diese Vorsichtsmaßnahmen auszuschalten:

 root@master # salt-run disengage.safety

Bauen Sie die Knoten vor dem Fortsetzen des Vorgangs neu auf:

 root@master #  salt-run rebuild.node TARGET

Sie können die Knoten auch einzeln neu aufbauen. Beispiel:

root@master #  salt-run rebuild.node data1.ceph

Mit rebuild.node werden stets alle OSDs im Knoten entfernt und neu erstellt.

Wichtig
Wichtig

Wenn ein OSD nicht konvertiert werden kann, zerstört die erneute Ausführung des Aufbaus die bereits konvertierten BlueStore OSDs. Anstatt den Aufbau neu auszuführen, können Sie Folgendes ausführen:

root@master # salt-run disks.deploy TARGET

Nach der Migration zu BlueStore bleibt die Anzahl der Objekte gleich und die Datenträgerauslastung ist nahezu dieselbe.

6.14 Upgrade von Anwendungsknoten Edit source

Rüsten Sie die Anwendungsknoten in der folgenden Reihenfolge auf:

  1. Object Gateways

    • Wenn sich ein Lastausgleich vor Object Gateways befindet, sollte ein Upgrade der Object Gateways bei laufendem Betrieb ohne Ausfall möglich sein.

    • Prüfen Sie nach jedem Upgrade, ob die Object Gateway-Daemons ausgeführt werden, und testen Sie mit einem S3/Swift-Client.

    • Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.

  2. iSCSI Gateways

    • Wenn iSCSI Initiatoren mit Multipath konfiguriert sind, sollte ein Upgrade der iSCSI-Gateways bei laufendem Betrieb ohne Ausfall möglich sein.

    • Prüfen Sie nach jedem Upgrade, ob der lrbd-Daemon ausgeführt wird, und testen Sie mit einem Initiator.

    • Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.

  3. NFS Ganesha. Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.

  4. Samba Gateways. Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.

6.15 Aktualisieren von policy.cfg und Deploy Ceph Dashboard mit DeepSea Edit source

Bearbeiten Sie /srv/pillar/ceph/proposals/policy.cfg auf dem Admin Node und wenden Sie die folgenden Änderungen an:

Wichtig
Wichtig: Keine neuen Services

Nehmen Sie während des Cluster-Upgrades keine neuen Services in die Datei policy.cfg auf. Ändern Sie die Cluster-Architektur erst dann, wenn das Upgrade abgeschlossen ist.

  1. Entfernen Sie role-openattic.

  2. Fügen Sie role-prometheus und role-grafana in den Knoten ein, auf dem Prometheus und Grafana installiert waren (in der Regel der Admin Node).

  3. Die Rolle profile-PROFILE_NAME wird nunmehr ignoriert. Fügen Sie die neue Rolle in der Zeile role-storage ein. Für die vorhandene Rolle

    profile-default/cluster/*.sls

    fügen Sie beispielsweise Folgendes ein:

    role-storage/cluster/*.sls
  4. Synchronisieren Sie alle Salt-Module:

    root@master # salt '*' saltutil.sync_all
  5. Aktualisieren Sie den Salt-Pillar mit DeepSea-Phase 1 und Phase 2:

    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run state.orch ceph.stage.2
  6. Bereinigen Sie openATTIC:

    root@master # salt OA_MINION state.apply ceph.rescind.openattic
    root@master # salt OA_MINION state.apply ceph.remove.openattic
  7. Heben Sie das Grain „restart_igw“ auf, sodass Phase 0 nicht das iSCSI-Gateway neu startet, das bislang noch nicht installiert wurde:

    Salt mastersalt '*' grains.delkey restart_igw
  8. Führen Sie abschließend die DeepSea-Phasen 0–4 aus:

    root@master # salt-run state.orch ceph.stage.0
    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4
    Tipp
    Tipp: Fehler „subvolume missing“ (Subvolume fehlt) in Phase 3

    Unter Umständen schlägt die DeepSea-Phase 3 mit diesem Fehler fehl:

    subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \
    '/var/lib/ceph subvolume missing on 4510-1', \
    [...]
    'See /srv/salt/ceph/subvolume/README.md']

    In diesem Fall müssen Sie /srv/pillar/ceph/stack/global.yml bearbeiten und die folgende Zeile einfügen:

    subvolume_init: disabled

    Aktualisieren Sie dann den Salt-Pillar und führen Sie die DeepSea-Phase 3 erneut aus:

    root@master # salt '*' saltutil.refresh_pillar
     root@master # salt-run state.orch ceph.stage.3

    Sobald die DeepSea-Phase 3 erfolgreich beendet wurde, wird das Ceph Dashboard ausgeführt. Eine ausführliche Übersicht der Ceph Dashboard-Funktionen finden Sie in Kapitel 22, Ceph Dashboard.

    Mit folgendem Kommando rufen Sie eine Liste der Knoten ab, auf denen das Dashboard ausgeführt wird:

    cephadm@adm > ceph mgr services | grep dashboard

    Mit folgendem Kommando rufen Sie eine Liste der Admin-Berechtigungsnachweise ab:

    root@master # salt-call grains.get dashboard_creds
  9. Starten Sie die Object Gateway-Services einzeln nacheinander, sodass sie den „beast“-Webserver anstelle des veralteten „civetweb“ nutzen:

    root@master # salt-run state.orch ceph.restart.rgw.force
  10. Bevor Sie den Vorgang fortsetzen, wird dringend empfohlen, das Ceph-Telemetriemodul zu aktivieren. Weitere Informationen und Anweisungen finden Sie in Abschnitt 10.2, „Telemetriemodul“.

6.16 Migration von profilbasierten Implementierungen zu DriveGroups Edit source

In SUSE Enterprise Storage 5.5 wurde das Layout Ihrer OSDs mit sogenannten „Profilen“ in DeepSea beschrieben. Mit SUSE Enterprise Storage 6 wurde auf eine andere Vorgehensweise umgestellt, auf die sogenannten DriveGroups (weitere Informationen siehe Abschnitt 5.5.2, „DriveGroups“).

Anmerkung
Anmerkung

Die Migration auf die neue Vorgehensweise ist nicht sofort obligatorisch. Destruktive Operationen wie salt-run osd.remove, salt-run osd.replace oder salt-run osd.purge sind nach wie vor verfügbar. Sollen neue OSDs eingefügt werden, ist jedoch Ihre Mithilfe gefordert.

Angesichts der unterschiedlichen Vorgehensweise dieser Implementierungen bieten wir keinen automatisierten Migrationspfad an. Wir bieten jedoch verschiedene Werkzeuge (Salt-Ausführungsprogramme) an, die die Migration so weit wie möglich erleichtern sollen.

6.16.1 Analysieren des aktuellen Layouts Edit source

Mit folgendem Kommando rufen Sie Informationen zu den derzeit implementierten OSDs ab:

root@master # salt-run disks.discover

Alternativ können Sie den Inhalt der Dateien in den Verzeichnissen /srv/pillar/ceph/proposals/profile-*/ prüfen. Ihre Struktur sieht in etwa wie folgt aus:

ceph:
  storage:
    osds:
      /dev/disk/by-id/scsi-drive_name: format: bluestore
      /dev/disk/by-id/scsi-drive_name2: format: bluestore

6.16.2 Erstellen von passenden DriveGroups für das aktuelle Layout Edit source

Weitere detaillierte Informationen zur DriveGroups-Spezifikation finden Sie in Abschnitt 5.5.2.1, „Spezifikation“.

Der Unterschied zwischen einer frischen Implementierung und einem Upgrade-Szenario liegt darin, dass die zu migrierenden Laufwerke bereits „genutzt“ werden. Da

root@master # salt-run disks.list

nur nach nicht genutzten Datenträgern sucht, verwenden Sie

root@master # salt-run disks.list include_unavailable=True

Passen Sie die DriveGroups gemäß Ihrer aktuellen Einrichtung an. Mit folgendem Kommando erhalten Sie eine eher bildliche Darstellung der Abläufe. Beachten Sie, dass dieses Kommando nichts zurückgibt, wenn keine freien Datenträger vorliegen:

root@master # salt-run disks.report bypass_pillar=True

Wenn Sie die ordnungsgemäße Konfiguration Ihrer DriveGroups geprüft haben und nun die neue Vorgehensweise anwenden möchten, entfernen Sie die Dateien aus dem Verzeichnis /srv/pillar/ceph/proposals/profile-PROFILE_NAME/, entfernen Sie die entsprechenden Zeilen für profile-PROFILE_NAME/cluster/*.sls aus der Datei /srv/pillar/ceph/proposals/policy.cfg und führen Sie die DeepSea-Phase 2 aus, sodass der Salt-Pillar aktualisiert wird.

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

Prüfen Sie das Ergebnis mit folgenden Kommandos:

root@master # salt target_node pillar.get ceph:storage
root@master # salt-run disks.report
Warnung
Warnung: Fehlerhafte DriveGroups-Konfiguration

Wenn Ihre DriveGroups nicht ordnungsgemäß konfiguriert sind und Ihre Einrichtung Ersatz-Datenträger umfasst, werden diese Datenträger so implementiert, wie Sie dies angegeben haben. Wir empfehlen, Folgendes auszuführen:

root@master # salt-run disks.report

6.16.3 OSD-Implementierung Edit source

In einfachen Fällen wie Stand-Alone-OSDs erfolgt die Migration im Lauf der Zeit. Immer wenn Sie einen OSD im Cluster entfernen oder ersetzen, wird er durch einen neuen, LVM-basierten OSD ersetzt.

Tipp
Tipp: Migration zum LVM-Format

Immer wenn ein einzelner „Legacy“-OSD in einem Knoten ersetzt werden muss, müssen auch alle OSDs, die bestimmte Geräte gemeinsam mit diesem OSD nutzen, zum LVM-basierten Format migriert werden.

Aus Gründen der Vollständigkeit sollten Sie die OSDs im gesamten Knoten migrieren.

6.16.4 Komplexere Einrichtungen Edit source

Bei einer differenzierteren Einrichtung, die über Stand-Alone-OSDs hinausgeht (z. B. dedizierte WAL/DBs oder verschlüsselte OSDs), kann die Migration nur dann durchgeführt werden, wenn alle dem betreffenden WAL/DB-Gerät zugeordneten OSDs entfernt wurden. Dies ergibt sich aus dem Kommando ceph-volume, mit dem logische Volumes auf Datenträgern vor der Implementierung erstellt werden. So wird verhindert, dass der Benutzer partitionsbasierte Implementierungen mit LV-basierten Implementierungen vermischt. In diesen Fällen ist es am besten, alle einem WAL/DB-Gerät zugeordneten OSDs manuell zu entfernen und mit dem DriveGroups-Verfahren neu zu implementieren.

Diese Seite drucken