SLES 15 SP7 auf SLES 16.0: das Major-Upgrade für SAP-Systeme

Der Wechsel von SUSE Linux Enterprise Server (SLES) 15 SP7 auf SLES 16.0 ist kein Service-Pack-Wechsel, sondern ein Major-Upgrade. Ein zypper migration im laufenden System reicht dafür nicht mehr: Das Upgrade läuft offline in einer eigenen Live-Umgebung, YaST gibt es nicht mehr, wicked wird durch NetworkManager ersetzt, und eine ganze Reihe gewohnter Komponenten fällt weg. Für SAP-Systeme kommt dazu, dass Details wie Hostname, /etc/services oder der hdbuserstore nach dem Upgrade nicht mehr stimmen können.

Dieser Beitrag fasst zusammen, was sich ändert, wie wir SLES for SAP Applications 15 SP7 auf 16.0 migrieren und welche Fehlerbilder wir in der Praxis auf SAP-S/4HANA-Systemen mit SAP HANA angetroffen haben – mit den Befehlen, die sie verhindern.

Was sich mit SLES 16 grundlegend ändert

Weitere Änderungen mit Wirkung im Betrieb: /tmp ist jetzt ein tmpfs und überlebt keinen Neustart, der Name in /etc/hostname wird unverändert übernommen, Network Teaming (teamd) entfällt zugunsten von Bonding, und Dienste wie NIS oder nscd gibt es nicht mehr.

Rahmenbedingungen vor dem Start

• Upgrade-Pfad: Ausgangspunkt ist SLES for SAP 15 SP7. Laut den Release Notes von SLES for SAP 16.0 ist auch der direkte Weg von 15 SP6 möglich, sofern dort zuerst das Paket suse-migration-services aktualisiert wurde.
• SAP-Freigabe: In der SAP Product Availability Matrix (PAM) prüfen, dass die eingesetzten Releases von SAP S/4HANA bzw. SAP NetWeaver und SAP HANA für SLES 16.0 freigegeben sind.
• Partitionierung: Das Betriebssystem muss auf einer Partition liegen. Ein separates /home ist erlaubt, ein separates /var nicht.
• Registrierung: Das System muss beim SUSE Customer Center oder einem RMT-Server registriert sein, die Kanäle müssen dort aktuell gespiegelt sein.
• Rückfallebene: Ein einmal gestartetes Upgrade lässt sich nicht zurückdrehen. Rückfallebene sind ein Snapshot der virtuellen Maschine und eine aktuelle Datenbanksicherung – Snapper deckt die SAP- und HANA-Datenbereiche nicht ab.
• Konsole: Die SSH-Verbindung bricht beim Start der Live-Umgebung ab. Der Zugriff auf die Konsole (z. B. vSphere) muss während der ganzen Migration bestehen.
• Wartungsfenster: SAP und SAP HANA sind während des Upgrades offline. Reihenfolge wie bei jedem grösseren Eingriff: Sandbox, Entwicklung, Test, Produktion.

Vorbereitung: zwölf Punkte, bevor es losgeht

Die meisten Abbrüche, die wir gesehen haben, entstehen nicht in der Migration selbst, sondern durch Vorbedingungen, die erst in der Live-Umgebung auffallen. Deshalb arbeiten wir vor jedem Start eine feste Prüfliste ab.

1. Sicherungen

Neben VM-Snapshot und Datenbanksicherung sichern wir die Konfigurationsbäume direkt auf dem Server. Diese Kopie hat sich nach dem Upgrade mehrfach als unverzichtbar erwiesen:

cp -a /etc /etc_sp15
cp -a /var /var_sp15
cp -a /opt /opt_sp15

2. Vollständig patchen

zypper refresh
zypper patch          # wiederholen, bis keine Patches mehr anstehen
zypper patch-check
reboot

3. Registrierung bereinigen

Das DMS sucht für jedes installierte Produkt ein Gegenstück unter SLES 16. Meldet der Registrierungsserver HTTP 422, sind Module als Dienst eingebunden, aber nicht aktiviert – typischerweise Package Hub, Containers oder Legacy Module. Nicht benötigte Module abmelden (vorher mit zypper se -i -r <Repository> prüfen, ob ein Agent davon abhängt), benötigte aktivieren:

SUSEConnect --status-text
SUSEConnect -d -p PackageHub/15.7/x86_64
SUSEConnect -d -p sle-module-legacy/15.7/x86_64

4. Produktdateien prüfen

In /etc/products.d dürfen nur registrierte Produkte liegen, und baseproduct muss auf SLES_SAP.prod zeigen. Eine liegen gebliebene Produktdatei eines abgemeldeten Moduls führte bei uns in der Live-Umgebung zu «Base Product update failed»; die Migration brach ab und das System startete wieder SLES 15.

readlink /etc/products.d/baseproduct
for f in /etc/products.d/*.prod; do echo "$f: $(rpm -qf $f)"; done

5. Systems Management Module aktivieren

Die Migrationspakete stammen aus diesem Modul. Ist es nicht aktiv, findet zypper sie schlicht nicht:

SUSEConnect -p sle-module-systems-management/15.7/x86_64
zypper se *migration*

6. Snapper prüfen

Ist /.snapshots nicht eingehängt, kann Snapper keine Snapshots anlegen und snapper-cleanup schlägt später fehl. Vor dem Start einen Snapshot anlegen:

findmnt /.snapshots
snapper create -d "vor Migration SLES 16"

7. SSH-Zugang sicherstellen

Während des Upgrades funktioniert nur die Anmeldung per SSH-Schlüssel. Wer nach dem Neustart weiterhin mit Passwort als root arbeiten muss, legt vorübergehend eine Drop-in-Datei an und ersetzt sie nach der Migration durch das dafür vorgesehene Paket:

echo "PermitRootLogin yes" > /etc/ssh/sshd_config.d/50-permit-root-login.conf

8. kexec-tools installieren

Für den Start über run_migration wird kexec benötigt – fehlt es, bricht das Skript mit «kexec: command not found» ab. Das Paket heisst kexec-tools:

zypper in -y kexec-tools
which kexec

9. Migrations-Image installieren

Für SLES for SAP heisst das Live-Image SLES16-SAP_Migration, für das Standard-SLES SLES16-Migration. Die Pakete suse-migration-services und migration-tools muss man nicht separat installieren; sie sind Teil des Images. Fehlte bei uns die Datei network_pre.functions, half eine Neuinstallation mit zypper in -f:

zypper in SLES16-SAP_Migration
ls -la /usr/share/suse_migration_services/network_pre.functions

10. Vorabprüfung ausführen

/usr/bin/suse-migration-pre-checks

11. SAP und HANA stoppen

# Applikationsserver, als <sid>adm
stopsap
# Datenbankhost, als <hdbsid>adm
HDB stop

12. Konsole öffnen

Erst wenn alle Punkte erfüllt sind, die Konsole der virtuellen Maschine öffnen und das Upgrade starten.

Durchführung

Der von SUSE unterstützte Weg auf AMD64/Intel 64 (sowie AArch64 und ppc64le): Das Aktivierungspaket stellt den Bootloader um, beim nächsten Neustart bootet das System in die Migrations-Live-Umgebung.

zypper in suse-migration-sle16-activation
reboot

Auf s390x, wo der Bootloader nicht umgestellt werden kann, startet run_migration das Image per kexec. Auf virtuellen x86-Maschinen funktioniert dieser Weg ebenfalls, bewegt sich aber ausserhalb des dokumentierten Verfahrens; für Produktivsysteme empfehlen wir deshalb den Weg über das Aktivierungspaket.

In der Live-Umgebung werden die Dateisysteme eingebunden, die SLES-15-Pakete durch ihre SLES-16-Entsprechungen ersetzt, der Kernel aktualisiert und GRUB 2 neu konfiguriert. Danach startet das System in SLES for SAP 16.0. Das Protokoll liegt unter /var/log/distro_migration.log, die Startphase unter /var/log/migration_startup.log.

Bricht die Migration vor dem eigentlichen Upgrade ab, entfernt die Live-Umgebung die Migrationspakete und startet wieder SLES 15 SP7. Dann Protokolle lesen, Ursache beheben, Pakete neu installieren und erneut starten.

Besonderheit Hochverfügbarkeit

Pacemaker-Cluster werden nicht rollierend, sondern offline aktualisiert: Alle Knoten werden gestoppt, alle migriert und erst dann wieder gestartet. Vorher und nachher hilft die Clusterprüfung von SUSE:

crm cluster health sles16          # vorher: FAIL-Punkte beheben
crm cluster stop --all
# ... alle Knoten migrieren ...
crm cluster health sles16 --fix    # nachher

Wer noch SAPHanaSR oder SAPHanaSR-ScaleOut einsetzt, muss vor dem Wechsel auf SAPHanaSR-angi umstellen.

Nach der Migration: die Fehlerbilder aus der Praxis

/etc/services wurde ersetzt – der Message Server ist weg

Das häufigste Problem: Das Upgrade ersetzt /etc/services durch die Version des neuen Pakets. Alle manuell gepflegten SAP-Portdefinitionen wie sapms<SID> sind danach verschwunden, der alte Stand liegt als services.rpmsave daneben. Symptome: «Message server service sapms<SID> not defined», der Kurzdump START_CALL_SICK in ST22 oder in SM21 «NIECONN_REFUSED» beim Verbindungsaufbau der Workprozesse zum Message Server.

Die Lösung ist die Sicherung aus der Vorbereitung. Am saubersten übernimmt man nur die SAP-Zeilen, damit die neuen Einträge von SLES 16 erhalten bleiben:

cp -p /etc/services /etc/services.sles16_original
grep -E "^sap" /etc_sp15/services >> /etc/services
getent services sapms<SID>     # muss 36<Instanznr>/tcp liefern

Hostname als FQDN – der hdbuserstore-Schlüssel fehlt

Mit NetworkManager landete auf einem System der vollqualifizierte Name in /etc/hostname. Der Workprozess suchte den hdbuserstore-Schlüssel DEFAULT daraufhin unter ~/.hdb/<host>.<domain> statt unter ~/.hdb/<host>, die Datenbankverbindung scheiterte mit rc -10104 und die Instanz startete nicht. SAP erwartet hier den Kurznamen (SAP-Hinweis 611361).

hostnamectl set-hostname <kurzname>
printf '[main]\nhostname-mode=none\n' > /etc/NetworkManager/conf.d/90-hostname.conf
systemctl reload NetworkManager
hostname        # Kurzname
hostname -f     # FQDN

Das von SAP neu angelegte, leere FQDN-Verzeichnis unter ~/.hdb verschieben wir, statt es zu löschen, und prüfen danach als <sid>adm mit hdbuserstore list DEFAULT und R3trans -d (Rückgabe 0000).

YaST fehlt – und Cockpit lässt sich nicht installieren

Nach der Migration gibt es kein YaST mehr, auch nicht im Textmodus. Cockpit war bei uns zunächst nicht installierbar, weil nur das Basis-Repository aktiv war. zypper search-packages cockpit nennt das richtige Modul samt Aktivierungsbefehl. Danach:

zypper in -y cockpit cockpit-system cockpit-storaged cockpit-networkmanager cockpit-packagekit
systemctl enable --now cockpit.socket
zypper in -y pcp python3-pcp && systemctl enable --now pmcd pmlogger   # Metrik-Verlauf

Cockpit sperrt den direkten Login als root über /etc/cockpit/disallowed-users. Besser als die Sperre aufzuheben ist ein persönliches Konto in der Gruppe wheel, das im Dashboard administrative Rechte erhält. Port 9090 gehört auf administrative Netzsegmente beschränkt.

Firewall und SAP-Ports

Ist firewalld nach dem Upgrade aktiv, sind ohne Freigaben Dispatcher (32<nr>), Gateway (33<nr>), Message Server (36<nr>), ICM, SAP Host Agent (1128/1129), sapstartsrv (5<nr>13/14) und die HANA-Ports nicht mehr erreichbar. Den Zustand nach jeder Migration prüfen und die Ports bewusst freigeben, bevor SAP gestartet wird.

Snapper-Cleanup schlägt fehl

Auf älteren Installationen war /.snapshots nicht eingehängt. Snapper legt dann keine Snapshots an, und die Bereinigung läuft auf Fehler. Abhilfe ist ein fehlender fstab-Eintrag für das Subvolume @/.snapshots – idealerweise schon vor der Migration ergänzt.

Prüfliste vor dem SAP-Start

Danach SAP starten und SM21 sowie ST22 kontrollieren. Wer die Basis-Nacharbeiten im gleichen Wartungsfenster erledigt, kann direkt auch Kernel, SAP Host Agent und SAP HANA auf einen aktuellen Stand bringen – mehr zu Abbrüchen von Hintergrundjobs nach solchen Eingriffen lesen Sie im Beitrag zur SAPify Batch-Job Suite.

Checklisten zum Herunterladen (PDF)

Die Tabelle oben deckt nur die wichtigsten Prüfungen vor dem SAP-Start ab. Für die vollständige Durchführung haben wir unsere Erfahrungen aus den Migrationen in zwei Checklisten zusammengefasst: eine für die Vorbereitung und eine für die Nacharbeiten. Jeder Prüfpunkt ist nummeriert und enthält den passenden Befehl oder Nachweis sowie ein Feld zum Abhaken. Die Checklisten werden pro Host ausgefüllt, mit eigenen Punkten für Applikationsserver, Datenbankhosts und Pacemaker-Cluster, und schliessen mit einer Freigabe pro Host ab.

Häufige Fragen

Fazit

Das Upgrade auf SLES 16.0 ist gut beherrschbar, wenn man es als Major-Upgrade plant: saubere Registrierung, eine Sicherung von /etc, /var und /opt, eine feste Prüfliste vor dem Start und eine zweite vor dem SAP-Start. Die meisten Stolpersteine – fehlende Message-Server-Ports, ein Hostname als FQDN, fehlendes YaST – sind bekannt und in wenigen Minuten behoben, wenn man weiss, wo man suchen muss. Gerne übernehmen wir die Migration Ihrer SAP-Hosts im Rahmen unseres SAP Basis Supports.

Quellen

• SUSE: Upgrading to SUSE Linux Enterprise Server 16
• SUSE: Upgrading SUSE Linux Enterprise Server for SAP applications
• SUSE: Key Technical Differences Between SLE 15 and SUSE Linux 16
• SUSE: Release Notes SLES for SAP applications 16.0