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

5 Upgrade von vorigen Versionen

In diesem Kapitel werden die Schritte zum Upgrade älterer Versionen von SUSE Enterprise Storage zur aktuellen Version vorgestellt.

5.1 Lesen Sie die Versionshinweise

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

  • Sind bei der Hardware besondere Überlegungen zu beachten?

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

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

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

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

5.2 Allgemeiner Upgrade-Vorgang

Beachten Sie vor Beginn des Upgrade-Vorgangs die folgenden Punkte:

Upgrade-Reihenfolge

Vor dem Upgrade des Ceph Clusters müssen Sie den zugrundeliegenden SUSE Linux Enterprise Server und SUSE Enterprise Storage korrekt bei SCC oder SMT registrieren. Es ist möglich, ein Upgrade der Daemons im Cluster durchzuführen, wenn der Cluster online und in Betrieb ist. Bestimmte Arten von Daemons hängen von anderen ab. Beispielsweise hängen Ceph Object Gateways von Ceph Monitors und Ceph OSD Daemons ab. Wir empfehlen für das Upgrade die folgende Reihenfolge:

  1. Ceph Monitors

  2. Ceph Manager

  3. Ceph OSDs

  4. Metadata Server

  5. Object Gateways

  6. iSCSI Gateways

  7. NFS Ganesha

Unnötige Betriebssystem-Snapshots löschen

Entfernen Sie nicht benötigte Dateisystem-Snapshots auf den Betriebssystempartitionen der Nodes. Dadurch wird ausreichend Speicherplatz für das Upgrade sichergestellt.

Cluster-Zustand überprüfen

Wir empfehlen, vor Beginn des Upgrade-Vorgangs den Cluster-Zustand zu überprüfen.

Upgrade einzeln und nacheinander durchführen

Wir empfehlen, jeden Daemon eines bestimmten Typs, wie zum Beispiel alle Monitor Daemons oder alle OSD Daemons, einzeln und nacheinander upzugraden. So wird sichergestellt, dass alle dieselbe Version aufweisen. Wir empfehlen außerdem, zunächst ein Upgrade aller Daemons im Cluster durchzuführen, bevor Sie versuchen, eine neue Funktionalität in einer Version auszuprobieren.

Nach dem Upgrade aller Daemons eines bestimmten Typs müssen Sie deren Zustand überprüfen.

Vergewissern Sie sich, dass jeder Monitor nach dem Upgrade aller Monitors wieder im Quorum vorhanden ist:

root # ceph mon stat

Vergewissern Sie sich, dass jeder Ceph OSD Daemon nach dem Upgrade aller OSDs wieder im Cluster vorhanden ist:

root # ceph osd stat
Flagge require-osd-release luminous setzen

Wenn das Upgrade des letzten OSD auf SUSE Enterprise Storage 5 abgeschlossen ist, erkennen die Monitor Nodes, dass alle OSDs die "luminous"-Version von Ceph ausführen. Möglicherweise monieren sie daraufhin, dass die osdmap-Flagge require-osd-release luminous nicht gesetzt ist. In diesem Fall müssen Sie die betreffende Flagge manuell setzen, um zu bestätigen, dass – nachdem nun ein Upgrade auf "luminous" für den Cluster durchgeführt wurde – kein Downgrade auf Ceph "jewel" mehr möglich ist. Führen Sie zum Setzen der Flagge das folgende Kommando aus:

root@minion > sudo ceph osd require-osd-release luminous

Nach Ausführung des Kommandos wird die Warnung nicht mehr angezeigt.

Bei Neuinstallation von SUSE Enterprise Storage 5 wird diese Flagge automatisch gesetzt, wenn die Ceph Monitors die erste osdmap erstellen. Der Endbenutzer muss daher nicht eingreifen.

5.3 Verschlüsseln der OSDs beim Upgrade

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

Wichtig
Wichtig: Nur jeweils ein OSD

Verschlüsselte OSDs müssen nacheinander bereitgestellt werden, nicht gleichzeitig. Der Grund dafür besteht darin, dass die Daten der OSDs entfernt werden und der Cluster mehrere wiederholte Ausgleichsvorgänge durchläuft.

  1. Ermitteln Sie die Werte bluestore block db size und bluestore block wal size für Ihre Bereitstellung und fügen Sie sie auf dem Salt Master zur Datei /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf hinzu. Die Werte müssen in Byte angegeben werden.

    [global]
    bluestore block db size = 48318382080
    bluestore block wal size = 2147483648

    Weitere Informationen zur Anpassung der Datei ceph.conf finden Sie im Abschnitt 1.11, „Benutzerdefinierte Datei ceph.conf.

  2. Führen Sie DeepSea-Phase 3 aus, um die Änderungen zu verteilen:

    root@master # salt-run state.orch ceph.stage.3
  3. Verifizieren Sie, dass die Datei ceph.conf auf den entsprechenden OSD-Nodes aktualisiert ist:

    root@minion > cat /etc/ceph/ceph.conf
  4. Bearbeiten Sie die YML-Dateien im Verzeichnis /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions, die für die zu verschlüsselnden OSDs relevant sind. Prüfen Sie deren Pfad gegen den in Datei /srv/pillar/ceph/proposals/policy.cfg definierten Pfad, um sicherzustellen, dass Sie die richtigen YML-Dateien bearbeiten.

    Wichtig
    Wichtig: Lange Datenträgerkennungen

    Verwenden Sie lange Datenträgerkennungen, wenn Sie /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/*.yml-Dateien kennzeichnen.

    Nachfolgend sehen Sie ein Beispiel einer OSD-Konfiguration. Beachten Sie, dass wegen der erforderlichen Verschlüsselung die Optionen db_size und wal_size entfernt wurden:

    ceph:
     storage:
       osds:
         /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_007027b1065faa972100d34d7aa06d86:
           format: bluestore
           encryption: dmcrypt
           db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
           wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
         /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_00d146b1065faa972100d34d7aa06d86:
           format: bluestore
           encryption: dmcrypt
           db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
           wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
  5. Stellen Sie die neuen Blockspeicher-OSDs mit Verschlüsselung bereit, indem Sie die DeepSea-Phasen 2 und 3 ausführen:

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

    Sie können den Fortschritt mit ceph -s oder ceph osd tree beobachten. Es ist sehr wichtig, den Ausgleich des Clusters abzuwarten, bevor Sie den Vorgang am nächsten OSD-Node wiederholen.

5.4 Upgrade von SUSE Enterprise Storage 4 (DeepSea Bereitstellung) auf Version 5

Wichtig
Wichtig: Softwareanforderungen

Auf allen Ceph Nodes, auf denen das Upgrade durchgeführt werden soll, muss vor Beginn des Upgrade-Vorgangs die folgende Software installiert und auf die neueste Paketversion aktualisiert werden:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

Außerdem müssen Sie vor Beginn des Upgrade-Vorgangs ein Upgrade des Salt Master Node auf SUSE Linux Enterprise Server 12 SP3 und SUSE Enterprise Storage 5 durchführen. Führen Sie dazu zypper migration aus (oder Ihre bevorzugte Upgrade-Methode).

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

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

  • Obwohl der Cluster während des Upgrade-Vorgangs voll funktionsfähig ist, setzt DeepSea die "noout"-Flagge. Sie verhindert, dass Ceph während der Ausfallzeit Daten ausgleicht und somit unnötige Datenübertragungen.

  • Zur Optimierung des Upgrade-Vorgangs führt DeepSea die Upgrades Ihrer Nodes in der folgenden Reihenfolge aus, basierend auf der zugewiesenen Rolle wie vom Ceph Upstream empfohlen: MONs, MGRs, OSDs, MDS, RGW, IGW und NFS Ganesha.

    Beachten Sie, dass DeepSea nicht verhindern kann, dass die Reihenfolge nicht eingehalten wird, wenn auf einem Node mehrere Services ausgeführt werden.

  • Obwohl der Ceph Cluster während des Upgrade-Vorgangs aktiv ist, werden manche Nodes möglicherweise neugestartet, um beispielsweise neue Kernel-Versionen anzuwenden. Um die Anzahl der E/A-Operationen in der Warteschlange zu verringern, empfehlen wir, eingehende Anforderungen für die Dauer des Upgrade-Vorgangs abzulehnen.

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

  • Ab Ceph Luminous wird die Konfigurationsoption osd crush location nicht mehr unterstützt. Aktualisieren Sie vor dem Upgrade Ihre DeepSea-Konfigurationsdaten, damit crush location verwendet wird.

Führen Sie zum Upgrade des SUSE Enterprise Storage 4-Clusters auf Version 5 die folgenden Schritte aus:

  1. Legen Sie die neue interne Objekt-Sortierreihenfolge fest und führen Sie folgendes Kommando aus:

    root # ceph osd set sortbitwise
    Tipp
    Tipp

    Wir empfehlen, das folgende Kommando auszuführen, um zu verifizieren, dass das vorige Kommando erfolgreich war:

    root # ceph osd dump --format json-pretty | grep sortbitwise
     "flags": "sortbitwise,recovery_deletes,purged_snapdirs",
  2. Verifizieren Sie mit rpm -q deepsea, dass die Version des DeepSea-Pakets am Salt Master Node mit mindestens 0.7 beginnt. Beispiel:

    root # rpm -q deepsea
    deepsea-0.7.27+git.0.274c55d-5.1

    Wenn die Versionsnummer des DeepSea-Pakets mit 0.6 beginnt, prüfen Sie nach, ob Sie den Salt Master Node erfolgreich zu SUSE Linux Enterprise Server 12 SP3 und SUSE Enterprise Storage 5 migriert haben (lesen Sie dazu Wichtig: Softwareanforderungen am Anfang dieses Abschnitts). Diese Voraussetzung muss erfüllt sein, bevor Sie mit dem Upgrade-Vorgang beginnen.

    1. Wenn Sie Ihr System bei SUSEConnect registriert haben und SCC/SMT verwenden, müssen Sie nichts weiter tun. Fahren Sie mit Schritt 4 fort.

    2. Wenn Sie SCC/SMT nicht verwenden, sondern eine Media-ISO oder eine andere Paketquelle, fügen Sie die folgenden Repositorys manuell hinzu: SLE12-SP3 Basis, SLE12-SP3 Update, SES5 Basis und SES5 Update. Verwenden Sie dazu das zypper-Kommando. Entfernen Sie zunächst alle vorhandenen Software-Repositorys. Fügen Sie dann die erforderlichen neuen Repositorys hinzu und aktualisieren Sie schließlich die Quellen der Repositorys:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref

      Ändern Sie anschließend Ihre Pillar-Daten, um eine andere Strategie anzuwenden. Bearbeiten

      /srv/pillar/ceph/stack/name_of_cluster/cluster.yml

      und fügen Sie die folgende Zeile hinzu:

      upgrade_init: zypper-dup
      Tipp
      Tipp

      Für die zypper-dup-Strategie müssen Sie die neuesten Software-Repositorys hinzufügen. Die standardmäßige zypper-migration-Strategie dagegen verlässt sich auf die von SCC/SMT bereitgestellten Repositorys.

  3. Führen Sie ein Update für Ihre Pillar-Schnittstelle durch:

    root@master # salt target saltutil.sync_all

    In Abschnitt 4.2.2, „Adressieren der Minions“ finden Sie weitere Details zur Behandlung von Salt Minions.

  4. Verifizieren Sie, dass das Schreiben an Pillar erfolgreich war:

    root@master # salt target pillar.get upgrade_init

    Die Ausgabe des Kommandos sollte die hinzugefügte Eingabe spiegeln.

  5. Führen Sie ein Upgrade der Salt Minions durch:

    root@master # salt target state.apply ceph.updates.salt
  6. Verifizieren Sie, dass das Upgrade für alle Salt Minions durchgeführt wurde:

    root@master # salt target test.version
  7. Beziehen Sie die Salt Minions des Clusters mit ein. Weitere Informationen finden Sie in Abschnitt 4.2.2, „Adressieren der Minions“ zu Prozedur 4.1, „Ausführen von Bereitstellungsphasen“.

  8. Starten Sie das Upgrade von SUSE Linux Enterprise Server und Ceph:

    root@master # salt-run state.orch ceph.maintenance.upgrade
    Tipp
    Tipp: Kommando beim Neustart erneut ausführen

    Wenn durch den Vorgang ein Neustart des Salt Master ausgelöst wird, führen Sie das Kommando erneut aus, um den Upgrade-Vorgang für die Salt Minions erneut zu starten.

  9. Vergewissern Sie sich nach dem Upgrade, dass AppArmor deaktiviert und auf allen Nodes gestoppt ist:

    root # systemctl disable apparmor.service
    systemctl stop apparmor.service
  10. Nach dem Upgrade sind die Ceph Manager noch nicht installiert. Gehen Sie folgendermaßen vor, um einen fehlerfreien Cluster-Zustand zu erreichen:

    1. Führen Sie Phase 0 aus, um die Salt REST API zu aktivieren:

      root@master # salt-run state.orch ceph.stage.0
    2. Führen Sie Phase 1 aus, um das Unterverzeichnis role-mgr/ zu erstellen:

      root@master # salt-run state.orch ceph.stage.1
    3. Bearbeiten Sie policy.cfg wie in Abschnitt 4.5.1, „Die Datei policy.cfg beschrieben und fügen Sie eine Ceph Manager-Rolle zu den Nodes hinzu, auf denen Ceph Monitors bereitgestellt werden. Fügen Sie außerdem die openATTIC-Rolle zu einem der Cluster Nodes hinzu. Weitere Informationen finden Sie im Kapitel 15, openATTIC.

    4. Führen Sie Phase 2 für das Update des Pillar aus:

      root@master # salt-run state.orch ceph.stage.2
    5. DeepSea generiert die ceph.conf-Konfigurationsdateien nun anders. Weitere Informationen finden Sie im Abschnitt 1.11, „Benutzerdefinierte Datei ceph.conf.

    6. Führen Sie Phase 3 aus, um Ceph Manager bereitzustellen:

      root@master # salt-run state.orch ceph.stage.3
    7. Führen Sie Phase 4 aus, um openATTIC ordnungsgemäß zu konfigurieren:

      root@master # salt-run state.orch ceph.stage.4
    Anmerkung
    Anmerkung: Inkongruenz der Ceph Schlüsselfunktionen

    Wenn ceph.stage.3 mit der Fehlermeldung "Error EINVAL: entity client.bootstrap-osd exists but caps do not match" abbricht, bedeutet dies, dass die Schlüsselfunktionen (key capabilities; kurz: caps) für den client.bootstrap.osd-Schlüssel des bestehenden Clusters nicht mit den Funktionen übereinstimmt, die DeepSea festzulegen versucht. Oberhalb der Fehlermeldung sehen Sie in Rot einen Dump des Kommandos ceph auth, der nicht ausgeführt wurde. Sehen Sie sich dieses Kommando an und prüfen Sie die verwendete Schlüssel-ID und Datei. Im Fall von client.bootstrap-osd sieht das Kommando folgendermaßen aus:

    root # ceph auth add client.bootstrap-osd \
     -i /srv/salt/ceph/osd/cache/bootstrap.keyring

    Prüfen Sie zur Behebung von Fehlern bei Schlüsselfunktionen den Inhalt der Schlüsselbunddatei, die DeepSea bereitzustellen versucht. Beispiel:

    cephadm > cat /srv/salt/ceph/osd/cache/bootstrap.keyring
    [client.bootstrap-osd]
         key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
         caps mgr = "allow r"
         caps mon = "allow profile bootstrap-osd"

    Vergleichen Sie dies mit der Ausgabe von ceph auth get client.bootstrap-osd:

    root # ceph auth get client.bootstrap-osd
    exported keyring for client.bootstrap-osd
    [client.bootstrap-osd]
         key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
         caps mon = "allow profile bootstrap-osd"

    Beachten Sie, dass bei dem zweiten Schlüssel caps mgr = "allow r" fehlt. Führen Sie zur Fehlerbehebung folgendes Kommando aus:

    root # ceph auth caps client.bootstrap-osd mgr \
     "allow r" mon "allow profile bootstrap-osd"

    Die Ausführung von ceph.stage.3 sollte nun gelingen.

    Dasselbe Problem kann bei Ausführung von ceph.stage.4 bei Metadatenserver- und Object Gateway-Schlüsselbunden auftreten. Gehen Sie dann genauso vor wie oben beschrieben: Prüfen Sie das Kommando, das nicht ausgeführt wurde, die Schlüsselbunddatei, die bereitgestellt werden soll sowie die Funktionen des bestehenden Schlüssels. Führen Sie dann ceph auth caps aus, um die bestehenden Schlüsselfunktionen zu aktualisieren, damit diese mit den von DeepSea bereitgestellten Funktionen übereinstimmen.

Wichtig
Wichtig: Upgrade-Fehler

Wenn sich der Cluster länger als 300 Sekunden im Zustand "HEALTH_ERR" befindet oder einer der Services für jede zugewiesene Rolle länger als 900 Sekunden ausfällt, ist beim Upgrade ein Fehler aufgetreten. Versuchen Sie in diesem Fall das Problem zu finden, es zu beheben und den Upgrade-Vorgang erneut durchzuführen. Beachten Sie, dass die Zeitüberschreitungszeiträume bei virtualisierten Umgebungen kürzer sind.

Wichtig
Wichtig: Neustarten der OSDs

Nach dem Upgrade auf SUSE Enterprise Storage 5 brauchen FileStore OSDs ungefähr fünf Minuten länger für den Start, weil der OSD eine einmalige Konvertierung seiner Dateien auf der Festplatte vornimmt.

Tipp
Tipp: Version der Cluster-Komponenten/Nodes prüfen

Führen Sie das folgende Kommando aus, wenn Sie die Versionen der einzelnen Cluster-Komponenten und Nodes herausfinden müssen, beispielsweise um zu prüfen, ob nach dem Upgrade alle Nodes tatsächlich dieselbe Patch-Stufe aufweisen:

root@master # salt-run status.report

Das Kommando geht durch die verbundenen Salt Minions und fragt die Versionsnummern von Ceph, Salt und SUSE Linux Enterprise Server ab. Danach wird ein Bericht mit der Versionsnummer der meisten Nodes angezeigt sowie die Nodes, die eine andere Version als die Mehrheit aufweisen.

5.4.1 OSD-Migration zu BlueStore

OSD BlueStore ist ein neues Backend 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 dem selben Gerät wie ein OSD, doch jedes der beiden kann auf schnellere/andere Medien platziert werden.

In SES5 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
  1. Migrieren Sie die Hardwareprofile:

    root@master # salt-run state.orch ceph.migrate.policy

    Durch dieses Ausführungsprogramm werden Profile migriert, die aktuell von der policy.cfg-Datei verwendet werden. Es verarbeitet policy.cfg, findet jedes Hardwareprofil anhand der ursprünglichen Datenstruktur und konvertiert es zur neuen Datenstruktur. Das Ergebnis ist ein neues Hardwareprofil namens "migrated-ursprünglicher_Name". policy.cfg wird ebenfalls aktualisiert.

    Wenn die ursprüngliche Konfiguration verschiedene Journale umfasste, verwendet BlueStore dasselbe Gerät für das "wal" und "db" für diesen OSD.

  2. DeepSea migriert OSDs dadurch, dass es ihr Gewicht auf 0 festlegt. Dadurch werden die Daten so lange "abgesaugt" bis der OSD leer ist. Sie können OSDs entweder einzeln nacheinander oder alle auf einmal migrieren. In beiden Fällen wird der geleerte OSD von der Orchestrierung entfernt und anschließend mit der neuen Konfiguration neu erstellt.

    Tipp
    Tipp: Empfohlene Methode

    Verwenden Sie ceph.migrate.nodes, wenn Sie eine große Anzahl von physischen Speicher-Nodes oder fast keine Daten haben. Wenn ein Node weniger als 10 % Ihrer Kapazität belegt, dann ist ceph.migrate.nodes möglicherweise geringfügig schneller, weil alle Daten dieser OSDs gleichzeitig verschoben werden.

    Wenn Sie sich nicht sicher sind, welche Methode Sie anwenden sollen, oder wenn am Standort nur wenig Speicher-Nodes vorhanden sind (wenn beispielsweise jeder Node mehr als 10 % der Cluster-Daten enthält), dann wählen Sie ceph.migrate.osds aus.

    1. Führen Sie folgendes Kommando aus, um OSDs einzeln nacheinander zu migrieren:

      root@master # salt-run state.orch ceph.migrate.osds
    2. Führen Sie folgendes Kommando aus, um alle OSDs auf jedem Node gleichzeitig zu migrieren:

      root@master # salt-run state.orch ceph.migrate.nodes
    Tipp
    Tipp

    Da die Orchestrierung kein Feedback zum Migrationsvorgang gibt, verwenden Sie

    root # ceph osd tree

    um zu sehen, welche OSDs periodisch ein Gewicht von Null haben.

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

5.5 Upgrade von SUSE Enterprise Storage 4 (ceph-deploy Bereitstellung) auf Version 5

Wichtig
Wichtig: Softwareanforderungen

Auf allen Ceph Nodes, auf denen das Upgrade durchgeführt werden soll, muss vor Beginn des Upgrade-Vorgangs die folgende Software installiert und auf die neueste Paketversion aktualisiert werden:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

Wählen Sie den Salt Master für Ihren Cluster. Wenn in Ihrem Cluster Calamari bereitgestellt ist, dann ist der Calamari Node bereits der Salt Master. Alternativ wird der Admin Node, von dem aus Sie das Kommando ceph-deploy ausgeführt haben, zum Salt Master.

Sie müssen vor Beginn des folgenden Vorgangs ein Upgrade des Salt Master Node auf SUSE Linux Enterprise Server 12 SP3 und SUSE Enterprise Storage 5 durchführen. Führen Sie dazu zypper migration aus (oder Ihre bevorzugte Upgrade-Methode).

Führen Sie für ein Upgrade des SUSE Enterprise Storage 4-Clusters, der mit ceph-deploy bereitgestellt wurde, auf Version 5 die folgenden Schritte aus:

Prozedur 5.1: Schritte, die auf alle Cluster Nodes (einschließlich Calamari Node) angewendet werden sollen
  1. Installieren Sie das salt-Paket von SLE-12-SP2/SES4:

    root # zypper install salt
  2. Installieren Sie das salt-minion-Paket von SLE-12-SP2/SES4. Aktivieren und starten Sie dann den entsprechenden Service:

    root # zypper install salt-minion
    root # systemctl enable salt-minion
    root # systemctl start salt-minion
  3. Vergewissern Sie sich, dass der Hostname "salt" zur IP-Adresse des Salt Master Node aufgelöst wird. Wenn Ihr Salt Master mit dem Hostnamen salt nicht erreichbar ist, bearbeiten Sie die Datei /etc/salt/minion oder erstellen Sie eine neue Datei /etc/salt/minion.d/master.conf mit folgendem Inhalt:

    master: host_name_of_salt_master
    Tipp
    Tipp

    Für die bestehenden Salt Minions ist die master:-Option bereits in /etc/salt/minion.d/calamari.conf festgelegt. Der Name der Konfigurationsdatei spielt keine Rolle. Wichtig ist nur das Verzeichnis /etc/salt/minion.d/.

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

    root@minion > systemctl restart salt-minion.service
    1. Wenn Sie Ihr System bei SUSEConnect registriert haben und SCC/SMT verwenden, müssen Sie nichts weiter tun.

    2. Wenn Sie SCC/SMT nicht verwenden, sondern eine Media-ISO oder eine andere Paketquelle, fügen Sie die folgenden Repositorys manuell hinzu: SLE12-SP3 Basis, SLE12-SP3 Update, SES5 Basis und SES5 Update. Verwenden Sie dazu das zypper-Kommando. Entfernen Sie zunächst alle vorhandenen Software-Repositorys. Fügen Sie dann die erforderlichen neuen Repositorys hinzu und aktualisieren Sie schließlich die Quellen der Repositorys:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref
Prozedur 5.2: Schritte, die auf den Salt Master Node angewendet werden sollen
  1. Legen Sie die neue interne Objekt-Sortierreihenfolge fest und führen Sie folgendes Kommando aus:

    root@master # ceph osd set sortbitwise
    Tipp
    Tipp

    Wir empfehlen, das folgende Kommando auszuführen, um zu verifizieren, dass das vorige Kommando erfolgreich war:

    root@master # ceph osd dump --format json-pretty | grep sortbitwise
     "flags": "sortbitwise,recovery_deletes,purged_snapdirs",
  2. Führen Sie am Salt Master Node ein Upgrade auf SUSE Linux Enterprise Server 12 SP3 und SUSE Enterprise Storage 5 durch. Verwenden Sie zypper migration für SCC-registrierte Systeme. Verwenden Sie zypper dup, wenn Sie die erforderlichen Software-Repositorys manuell bereitstellen. Vergewissern Sie sich nach dem Upgrade, dass auf dem Salt Master Node nur Repositorys für SUSE Linux Enterprise Server 12 SP3 und SUSE Enterprise Storage 5 aktiv (und aktualisiert) sind, bevor Sie fortfahren.

  3. Falls nicht bereits vorhanden, installieren Sie das salt-master-Paket. Aktivieren und starten Sie dann den entsprechenden Service:

    root@master # zypper install salt-master
    root@master # systemctl enable salt-master
    root@master # systemctl start salt-master
  4. Verifizieren Sie, dass alle Salt Minions vorhanden sind, indem Sie Ihre Schlüssel auflisten:

    root@master # salt-key -L
  5. Fügen Sie alle Salt Minions-Schlüssel zum Salt Master hinzu, einschließlich des Minion Masters:

    root@master # salt-key -A -y
  6. Stellen Sie sicher, dass die Schlüssel aller Salt Minions akzeptiert wurden:

    root@master # salt-key -L
  7. Vergewissern Sie sich, dass die Software auf Ihrem Salt Master Node aktuell ist:

    root@master # zypper migration
  8. Installieren Sie das Paket deepsea:

    root@master # zypper install deepsea
  9. Beziehen Sie die Salt Minions des Clusters mit ein. Weitere Informationen finden Sie in Abschnitt 4.2.2, „Adressieren der Minions“ zu Prozedur 4.1, „Ausführen von Bereitstellungsphasen“.

  10. Importieren Sie den bestehenden installierten Cluster ceph-deploy:

    root@master # salt-run populate.engulf_existing_cluster

    Das Kommando bewirkt Folgendes:

    • Verteilen der erforderlichen Salt- und DeepSea-Module an alle Salt Minions.

    • Untersuchen des aktuell ausgeführten Ceph Clusters und Auffüllen von/srv/pillar/ceph/proposals mit einem Layout des Clusters.

      /srv/pillar/ceph/proposals/policy.cfg wird erstellt mit Rollen, die allen erkannten aktuell ausgeführten Ceph Services entsprechen. Sehen Sie sich diese Datei an, um zu verifizieren, dass jeder der bestehenden MON, OSD, RGW und MDS Nodes über die entsprechenden Rollen verfügt. OSD-Nodes werden im Unterverzeichnis profile-import/ importiert. Dadurch können Sie die Dateien in /srv/pillar/ceph/proposals/profile-import/cluster/ und /srv/pillar/ceph/proposals/profile-import/stack/default/ceph/minions/ untersuchen, um zu bestätigen, dass die OSDs korrekt übernommen wurden.

      Anmerkung
      Anmerkung

      Die generierte Datei policy.cfg wendet nur Rollen für die erkannten Ceph Services "role-mon", "role-mgr", "role-mds", "role-rgw", "role-admin" und "role-master" für den Salt Master Node an. Alle anderen gewünschten Rollen müssen manuell zur Datei hinzugefügt werden (weitere Informationen finden Sie in Abschnitt 4.5.1.2, „Rollenzuweisung“).

    • Die bestehende ceph.conf-Datei des Clusters wird im Pfad /srv/salt/ceph/configuration/files/ceph.conf.import gespeichert.

    • Die Datei /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml enthält die fsid des Clusters, das Cluster-Netzwerk und das öffentliche Netzwerk. Sie gibt auch die Option configuration_init: default-import an, durch die DeepSea die oben genannte Konfigurationsdatei ceph.conf.import verwendet statt der standardmäßigen Vorlagen /srv/salt/ceph/configuration/files/ceph.conf.j2 von DeepSea.

      Anmerkung
      Anmerkung: Benutzerdefinierte ceph.conf

      Wenn Sie benutzerdefinierte Änderungen in Datei ceph.conf vornehmen müssen, warten Sie bis der Import/Upgrade-Vorgang erfolgreich abgeschlossen ist. Bearbeiten Sie dann die Datei /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml und kommentieren Sie die folgende Zeile:

      configuration_init: default-import

      Speichern Sie die Datei und befolgen Sie die Anleitungen im Abschnitt 1.11, „Benutzerdefinierte Datei ceph.conf.

    • Die verschiedenen Schlüsselbunde des Clusters werden in den folgenden Verzeichnissen gespeichert:

      /srv/salt/ceph/admin/cache/
      /srv/salt/ceph/mon/cache/
      /srv/salt/ceph/osd/cache/
      /srv/salt/ceph/mds/cache/
      /srv/salt/ceph/rgw/cache/

      Verifizieren Sie, dass die Schlüsselbunddateien vorhanden sind und dass im folgenden Verzeichnis keine Schlüsselbunddatei enthalten ist (der Ceph Manager war vor SUSE Enterprise Storage 5 noch nicht vorhanden):

      /srv/salt/ceph/mgr/cache/
  11. Das Kommando salt-run populate.engulf_existing_cluster verarbeitet nicht den Import der openATTIC-Konfiguration. Sie müssen die Datei policy.cfg manuell bearbeiten und eine Zeile role-openattic hinzufügen. Weitere Informationen finden Sie in Abschnitt 4.5.1, „Die Datei policy.cfg.

  12. Das Kommando salt-run populate.engulf_existing_cluster verarbeitet nicht den Import der iSCSI Gateway-Konfigurationen. Wenn Ihr Cluster iSCSI Gateways enthält, importieren Sie deren Konfigurationen manuell:

    1. Exportieren Sie auf einem der iSCSI Gateway Nodes die aktuelle lrbd.conf-Datei und kopieren Sie sie in den Salt Master Node:

      root@minion > lrbd -o >/tmp/lrbd.conf
      root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
    2. Fügen Sie im Salt Master Node die standardmäßige iSCSI Gateway-Konfiguration zum DeepSea Setup hinzu:

      root@master # mkdir -p /srv/pillar/ceph/stack/ceph/
      root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
      root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
    3. Fügen Sie die iSCSI Gateway-Rollen zu policy.cfg hinzu und speichern Sie die Datei:

      role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml
      role-igw/cluster/ses-1.ses.suse.sls
      [...]
  13. Führen Sie Phase 1 aus, um alle möglichen Rollen zu erstellen:

    root@master # salt-run state.orch ceph.stage.1
  14. Generieren Sie die erforderlichen Unterverzeichnisse unter /srv/pillar/ceph/stack:

    root@master # salt-run push.proposal
  15. Verifizieren Sie, dass ein funktionierender von DeepSea verwalteter Cluster mit korrekt zugewiesenen Rollen vorhanden ist:

    root@master # salt target pillar.get roles

    Vergleichen Sie die Ausgabe mit dem tatsächlichen Layout des Clusters.

  16. Calamari führt einen geplanten Salt-Auftrag weiterhin aus, um den Cluster-Status zu prüfen. Löschen Sie den Auftrag:

    root@minion > salt target schedule.delete ceph.heartbeat
  17. Fahren Sie ab hier gemäß Abschnitt 5.4, „Upgrade von SUSE Enterprise Storage 4 (DeepSea Bereitstellung) auf Version 5“ fort.

5.6 Upgrade von SUSE Enterprise Storage 4 (Crowbar-Bereitstellung) auf Version 5

Wichtig
Wichtig: Softwareanforderungen

Auf allen Ceph Nodes, auf denen das Upgrade durchgeführt werden soll, muss vor Beginn des Upgrade-Vorgangs die folgende Software installiert und auf die neueste Paketversion aktualisiert werden:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

Führen Sie zum Upgrade von SUSE Enterprise Storage 4, das über Crowbar bereitgestellt wurde, auf Version 5 die folgenden Schritte aus:

  1. Stoppen und deaktivieren Sie alle auf Crowbar bezogenen Services für jeden Ceph Node (einschließlich Calamari Node):

    root@minion > sudo systemctl stop chef-client
    root@minion > sudo systemctl disable chef-client
    root@minion > sudo systemctl disable crowbar_join
    root@minion > sudo systemctl disable crowbar_notify_shutdown
  2. Verifizieren Sie für jeden Ceph Node (einschließlich Calamari Node), dass die Software-Repositorys auf die Produkte SUSE Enterprise Storage 5 und SUSE Linux Enterprise Server 12 SP3 verweisen. Wenn Repositorys, die auf ältere Produktversionen verweisen, noch vorhanden sind, müssen Sie sie deaktivieren.

  3. Verifizieren Sie, dass für jeden Ceph Node (einschließlich Calamari Node) der salt-minion installiert ist. Falls nicht, installieren Sie ihn:

    root@minion > sudo zypper in salt salt-minion
  4. Erstellen Sie für Ceph Nodes, auf denen das salt-minion -Paket nicht installiert war, die Datei /etc/salt/minion.d/master.conf, in der die Option master auf den vollständigen Calamari Node-Hostnamen verweist:

    master: full_calamari_hostname
    Tipp
    Tipp

    Für die bestehenden Salt Minions ist die master:-Option bereits in /etc/salt/minion.d/calamari.conf festgelegt. Der Name der Konfigurationsdatei spielt keine Rolle. Wichtig ist nur das Verzeichnis /etc/salt/minion.d/.

    Aktivieren und starten Sie den salt-minion Service:

    root@minion > sudo systemctl enable salt-minion
    root@minion > sudo systemctl start salt-minion
  5. Akzeptieren Sie am Calamari Node alle verbleibenden Salt Minion-Schlüssel:

    root@master # salt-key -L
    [...]
    Unaccepted Keys:
    d52-54-00-16-45-0a.example.com
    d52-54-00-70-ac-30.example.com
    [...]
    
    root@master # salt-key -A
    The following keys are going to be accepted:
    Unaccepted Keys:
    d52-54-00-16-45-0a.example.com
    d52-54-00-70-ac-30.example.com
    Proceed? [n/Y] y
    Key for minion d52-54-00-16-45-0a.example.com accepted.
    Key for minion d52-54-00-70-ac-30.example.com accepted.
  6. Wenn Ceph im öffentlichen Netzwerk bereitgestellt wurde und keine VLAN-Schnittstelle vorhanden ist, fügen Sie eine VLAN-Schnittstelle im öffentlichen Netzwerk von Crowbar zum Calamari Node hinzu.

  7. Führen Sie im Calamari Node ein Upgrade auf SUSE Linux Enterprise Server 12 SP3 und SUSE Enterprise Storage 5 durch, entweder mithilfe von zypper migration oder Ihrer bevorzugten Methode. Ab hier wird der Calamari Node zum Salt Master. Neustarten Sie den Salt Master nach dem Upgrade.

  8. Installieren Sie DeepSea am Salt Master:

    root@master # zypper in deepsea
  9. Geben Sie die Option deepsea_minions an, um die korrekte Gruppe von Salt Minions in den Bereitstellungsstufen einzufügen. Weitere Informationen finden Sie in Abschnitt 4.2.2.3, „Festlegen der Option deepsea_minions.

  10. DeepSea erwartet, dass die /etc/ceph/ceph.conf in allen Ceph Nodes identisch ist. Crowbar stellt in jedem Node eine leicht andere ceph.conf bereit, daher müssen Sie sie konsolidieren:

    • Entfernen Sie die Option osd crush location hook, da sie von Calamari hinzugefügt wurde.

    • Entfernen Sie die Option public addr im Abschnitt [mon].

    • Entfernen Sie die Portnummern in der Option mon host.

  11. Wenn Sie das Object Gateway ausgeführt haben, hat Crowbar eine andere Datei /etc/ceph/ceph.conf.radosgw bereitgestellt, damit die Keystone-Geheimnisse von der regulären ceph.conf-Datei getrennt sind. Crowbar hat außerdem eine benutzerdefinierte Datei /etc/systemd/system/ceph-radosgw@.service hinzugefügt. Sie müssen diese entfernen, weil DeepSea sie nicht unterstützt:

    • Fügen Sie alle [client.rgw....]-Abschnitte der Datei ceph.conf.radosgw in allen Nodes an die Datei /etc/ceph/ceph.conf an.

    • Führen Sie im Object Gateway Node Folgendes aus:

      root@minion > rm /etc/systemd/system/ceph-radosgw@.service
      systemctl reenable ceph-radosgw@rgw.public.$hostname
  12. Vergewissern Sie sich, dass ceph status bei Ausführung vom Salt Master aus funktioniert:

    root@master # ceph status
    cluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2
    health HEALTH_OK
    [...]
  13. Importieren Sie den bestehenden Cluster:

    root@master # salt-run populate.engulf_existing_cluster
    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run push.proposal
  14. Das Kommando salt-run populate.engulf_existing_cluster verarbeitet nicht den Import der iSCSI Gateway-Konfigurationen. Wenn Ihr Cluster iSCSI Gateways enthält, importieren Sie deren Konfigurationen manuell:

    1. Exportieren Sie auf einem der iSCSI Gateway Nodes die aktuelle lrbd.conf-Datei und kopieren Sie sie in den Salt Master Node:

      root@minion > lrbd -o > /tmp/lrbd.conf
      root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
    2. Fügen Sie im Salt Master Node die standardmäßige iSCSI Gateway-Konfiguration zum DeepSea Setup hinzu:

      root@master # mkdir -p /srv/pillar/ceph/stack/ceph/
      root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
      root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
    3. Fügen Sie die iSCSI Gateway-Rollen zu policy.cfg hinzu und speichern Sie die Datei:

      role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml
      role-igw/cluster/ses-1.ses.suse.sls
      [...]
    1. Wenn Sie Ihr System bei SUSEConnect registriert haben und SCC/SMT verwenden, müssen Sie nichts weiter tun.

    2. Wenn Sie SCC/SMT nicht verwenden, sondern eine Media-ISO oder eine andere Paketquelle, fügen Sie die folgenden Repositorys manuell hinzu: SLE12-SP3 Basis, SLE12-SP3 Update, SES5 Basis und SES5 Update. Verwenden Sie dazu das zypper-Kommando. Entfernen Sie zunächst alle vorhandenen Software-Repositorys. Fügen Sie dann die erforderlichen neuen Repositorys hinzu und aktualisieren Sie schließlich die Quellen der Repositorys:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref

      Ändern Sie anschließend Ihre Pillar-Daten, um eine andere Strategie anzuwenden. Bearbeiten

      /srv/pillar/ceph/stack/name_of_cluster/cluster.yml

      und fügen Sie die folgende Zeile hinzu:

      upgrade_init: zypper-dup
      Tipp
      Tipp

      Für die zypper-dup-Strategie müssen Sie die neuesten Software-Repositorys hinzufügen. Die standardmäßige zypper-migration-Strategie dagegen verlässt sich auf die von SCC/SMT bereitgestellten Repositorys.

  15. Reparieren Sie Host Grains, damit DeepSea für die Ceph Daemon Instanz-IDs kurze Hostnamen im öffentlichen Netzwerk verwenden kann. Für jeden Node müssen Sie grains.set mit dem neuen (kurzen) Hostnamen ausführen. Verifizieren Sie vor dem Ausführen von grains.set die aktuellen Monitor-Instanzen, indem Sie ceph status ausführen. Nachfolgend sehen Sie ein Vorher-Nachher-Beispiel:

    root@master # salt target grains.get host
    d52-54-00-16-45-0a.example.com:
        d52-54-00-16-45-0a
    d52-54-00-49-17-2a.example.com:
        d52-54-00-49-17-2a
    d52-54-00-76-21-bc.example.com:
        d52-54-00-76-21-bc
    d52-54-00-70-ac-30.example.com:
        d52-54-00-70-ac-30
    root@master # salt d52-54-00-16-45-0a.example.com grains.set \
     host public.d52-54-00-16-45-0a
    root@master # salt d52-54-00-49-17-2a.example.com grains.set \
     host public.d52-54-00-49-17-2a
    root@master # salt d52-54-00-76-21-bc.example.com grains.set \
     host public.d52-54-00-76-21-bc
    root@master # salt d52-54-00-70-ac-30.example.com grains.set \
     host public.d52-54-00-70-ac-30
    root@master # salt target grains.get host
    d52-54-00-76-21-bc.example.com:
        public.d52-54-00-76-21-bc
    d52-54-00-16-45-0a.example.com:
        public.d52-54-00-16-45-0a
    d52-54-00-49-17-2a.example.com:
        public.d52-54-00-49-17-2a
    d52-54-00-70-ac-30.example.com:
        public.d52-54-00-70-ac-30
  16. Führen Sie das Upgrade durch:

    root@master # salt target state.apply ceph.updates
    root@master # salt target test.version
    root@master # salt-run state.orch ceph.maintenance.upgrade

    Jeder Node startet neu. Der Cluster startet und moniert, dass keine aktive Ceph Manager-Instanz vorhanden ist. Das ist normal. Calamari sollte zu diesem Zeitpunkt nicht mehr installiert sein bzw. ausgeführt werden.

  17. Führen Sie die erforderlichen Bereitstellungsschritte aus, um den Cluster in einen ordnungsgemäßen Zustand zu versetzen:

    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
  18. Fügen Sie zum Bereitstellen von openATTIC (weitere Informationen hierzu finden Sie im Kapitel 15, openATTIC) eine entsprechende role-openattic-Zeile (weitere Informationen hierzu finden Sie in Abschnitt 4.5.1.2, „Rollenzuweisung“) zu/srv/pillar/ceph/proposals/policy.cfg hinzu und führen Sie dann Folgendes aus:

    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.4
  19. Während des Upgrades wird die Fehlermeldung "Error EINVAL: entity [...] exists but caps do not match" angezeigt. Informationen zur Fehlerbehebung finden Sie in Abschnitt 5.4, „Upgrade von SUSE Enterprise Storage 4 (DeepSea Bereitstellung) auf Version 5“.

  20. Führen Sie die noch verbleibende Bereinigung durch:

    • Crowbar erstellt für jeden OSD Einträge in /etc/fstab. Löschen Sie diese, da sie nicht notwendig sind.

    • Calamari führt einen geplanten Salt-Auftrag weiterhin aus, um den Cluster-Status zu prüfen. Löschen Sie den Auftrag:

      root@master # salt target schedule.delete ceph.heartbeat
    • Es sind immer noch einige unnötige Pakete installiert, meistens RubyGems und solche, die sich auf Chef beziehen. Sie müssen nicht unbedingt entfernt werden, doch Sie können sie löschen, indem Sie zypper rm pkg_name ausführen.

5.7 Upgrade von SUSE Enterprise Storage 3 auf 5

Wichtig
Wichtig: Softwareanforderungen

Auf allen Ceph Nodes, auf denen das Upgrade durchgeführt werden soll, muss vor Beginn des Upgrade-Vorgangs die folgende Software installiert und auf die neueste Paketversion aktualisiert werden:

  • SUSE Linux Enterprise Server 12 SP1

  • SUSE Enterprise Storage 3

Führen Sie für ein Upgrade des SUSE Enterprise Storage 3-Clusters auf Version 5 die in Prozedur 5.1, „Schritte, die auf alle Cluster Nodes (einschließlich Calamari Node) angewendet werden sollen“ und dann Prozedur 5.2, „Schritte, die auf den Salt Master Node angewendet werden sollen“ beschriebenen Schritte aus.

Diese Seite drucken