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:

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:

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:

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

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.

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:

Die folgenden Kommandos sind weiterhin funktionsfähig, auch wenn auf den Salt Minions veraltete Versionen von Ceph und Salt ausgeführt werden: salt '*' test.ping und ceph status

Nach dem Upgrade des Admin Node ist openATTIC nicht mehr installiert.

Wenn SMT auf dem Admin Node gehostet wurde, führen Sie dessen Migration zu RMT durch (siehe https://www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html).

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

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