Sicherstellung der Verfügbarkeit der Dienste während eines Upgrades von SLES 15 SP5 auf SP6

Ein kurzes Wartungsfenster lässt sich schwer einplanen, wenn auf einem SLES-Server ein kundenorientierter Dienst läuft. SUSE unterstützt zwar die Online-Migration von Service Packs von SLES 15 SP5 auf SP6, der aktualisierte Server muss jedoch neu gestartet werden; „online“ bedeutet nicht „ohne Neustart“. Um die Erreichbarkeit einer Anwendung zu gewährleisten, sollten redundante Knoten nacheinander aktualisiert oder ein Ersatzsystem mit SP6 eingerichtet und der Datenverkehr dorthin verlagert werden. Ein einzelner Server kann sein eigenes Betriebssystem während eines Neustarts nicht verfügbar halten.

Beispielszenario: Ein fiktives Team betreibt eine Webanwendung auf drei SLES 15 SP5-Knoten hinter einem Load Balancer. Die Anwendung kann Anfragen von den beiden anderen Knoten bearbeiten, während ein Knoten gewartet wird. Die folgende Sequenz zeigt, wie das Team den Cluster migrieren könnte; es handelt sich um ein Beispiel, nicht um eine Aussage darüber, dass ein Test durchgeführt wurde oder dass jeder Cluster einen Knotenausfall tolerieren kann.

1. Wählen Sie einen Pfad, der zum Dienst passt.

Für die Migration von SLES 15 SP5 auf SP6 dokumentiert SUSE sowohl Online- als auch Offline-Upgrade-Methoden. Die Online-Methode nutzt die YaST-Migration zypper migrationwährend des laufenden Betriebs und erfordert anschließend einen Neustart des Systems. Paketänderungen können zudem einen Neustart von Diensten erforderlich machen, sodass die Online-Migration allein keine Anwendungskontinuität gewährleisten kann.

Verwenden Sie das SLE-Hochverfügbarkeits-Rolling-Upgrade-Verfahren nur, wenn Ihre Workload bereits durch einen unterstützten, fehlerfreien Cluster geschützt ist. Der Cluster muss Quorum und ausreichende Kapazität für den Betrieb des Dienstes auch bei einem ausgefallenen Knoten gewährleisten. Ein herkömmlicher Load Balancer ohne Anwendungsredundanz oder ein Zwei-Knoten-Cluster, der bei Ausfall eines Knotens das Quorum verliert, ist nicht ausreichend. Bei einem Standalone-Server verwenden Sie einen parallelen SP6-Host und eine getestete Workload-/Datenumschaltung, um die Erreichbarkeit aufrechtzuerhalten. Planen Sie andernfalls eine Ausfallzeit für den Neustart ein.

2. Überprüfen Sie das Ziel und erstellen Sie einen Wiederherstellungsplan.

Bevor Sie Änderungen am Cluster vornehmen, überprüfen Sie die Ausgangsversion, die Registrierung, die Repositories und die unterstützten Erweiterungen. SUSE empfiehlt die Migration von SLES 15 SP5 auf SP6. Für die Online-Migration muss der Rechner beim SUSE Customer Center oder einem lokalen RMT-Server registriert sein. SUSE Manager-Clients müssen die Manager-Client-Migrationsprozedur verwenden und dürfen die Migration nicht zypper migrationdirekt ausführen. Die verfügbaren Zielsysteme hängen von den registrierten Produkten und Erweiterungen ab.

Laut den SUSE-Veröffentlichungsinformationen wird SLES 15 SP6 ab dem 1. Januar 2026 auf LTSS umgestellt. Prüfen Sie vor der Planung dieser Migration, ob Ihr Abonnement und Ihre Registrierungsquelle SP6 als Zielversion anbieten. Falls dies nicht der Fall ist, erzwingen Sie keine Repository-Änderung, um eine unterstützte Migration zu simulieren.

Sichern Sie Anwendungsdaten und -konfigurationen mit der von der Anwendung unterstützten Methode und vergewissern Sie sich, dass Sie diese wiederherstellen können. Lesen Sie den SLE HA-Upgrade-Leitfaden und die SP6-Versionshinweise für Ihre Erweiterungen, Datenbanken, Speicher und Hardware. Im fiktiven Cluster prüft der Operator außerdem Quorum, Fencing, Replikationsstatus, freie Kapazität, Load-Balancer-Status und eine getestete Methode zur Umleitung des Datenverkehrs von jedem Knoten. Ein Snapshot kann bei unterstützten Btrfs-Root-Setups das Rollback erleichtern, ersetzt aber keine Anwendungs- oder Datenbanksicherungen.

3. Aktualisieren Sie jeweils einen erschöpften Knoten.

Führen Sie für jeden Knoten die SLE HA-Rolling-Upgrade-Prozedur und das Runbook Ihres Clusters durch. Aktualisieren Sie niemals mehrere Knoten gleichzeitig, es sei denn, die produktspezifische Vorgehensweise erlaubt dies ausdrücklich.

1. Stellen Sie sicher, dass die verbleibenden Knoten die Arbeitslast bewältigen können. Überprüfen Sie den Zustand der Anwendung und des Clusters. Leiten Sie den Datenverkehr von dem betroffenen Knoten um oder entfernen Sie ihn mithilfe der dokumentierten Steuerelemente für Ihren Load Balancer und Ihre Clusterressourcen. Fahren Sie nicht fort, wenn die verbleibenden Knoten das Quorum nicht aufrechterhalten oder die Mindestkapazität des Dienstes nicht erreichen können.
2. Stoppen Sie den Cluster-Stack auf diesem Knoten. SUSE warnt davor, dass das Aktivieren des Cluster-Ressourcenmanagers während des Software-Updates zu einer Abriegelung aktiver Knoten führen kann. Führen Sie auf dem für die Wartung ausgewählten Knoten Folgendes aus:

sudo crm cluster stop

3. Starten Sie die Service-Pack-Migration und prüfen Sie den Vorschlag. Führen Sie den dokumentierten Zypper-Migrationsbefehl aus:

sudo zypper migration

Wählen Sie SLES 15 SP6 nur dann aus, wenn es als verfügbares Ziel angezeigt wird. Lesen Sie den Repository- und Paketplan, insbesondere die zur Entfernung oder zum Downgrade vorgeschlagenen Pakete, und brechen Sie den Vorgang ab, wenn die Änderungen unerwartet sind. Akzeptieren Sie keinen Plan, den Sie nicht geprüft haben. Die genaue Paketliste variiert je nach installierter Software und registrierten Erweiterungen.

4. Starten Sie den aktualisierten Knoten neu. Nachdem Zypper eine erfolgreiche Migration gemeldet hat, starten Sie den Rechner neu, damit er den SP6-Kernel und die zugehörigen Dienste startet.

sudo reboot

5. Wiederverbinden und verifizieren, bevor zum nächsten Knoten gewechselt wird: Nach der Rückkehr des Knotens wird dessen Cluster-Stack gestartet:

sudo crm cluster start
sudo crm status

Warten Sie, bis der Cluster meldet, dass der Knoten beigetreten ist und die Ressourcen fehlerfrei sind. Stellen Sie ihn dann gemäß Ihrem Runbook wieder her. Überprüfen Sie die Anwendung von außerhalb des Clusters. Wiederholen Sie den Vorgang erst dann für den nächsten Knoten. SUSE erlaubt gemischte Versionen nur kurzzeitig während eines rollierenden Upgrades und weist Administratoren an, das Cluster-Upgrade innerhalb einer Woche abzuschließen.

4. Überprüfen Sie den Dienst, nicht nur die Betriebssystembezeichnung.

Nachdem alle Knoten aktualisiert wurden, bestätigen Sie deren Freigabe mit `git update` cat /etc/os-release, überprüfen Sie den Clusterzustand mit `git status` crm statusund prüfen Sie fehlerhafte systemd-Units mit `git status` systemctl --failed. Testen Sie anschließend die Anwendung über ihre normale Client-Adresse, einschließlich der Zustandsprüfungen, des Datenbank- oder Speicherzugriffs und aller für Benutzer relevanten geplanten Jobs. Überprüfen Sie die Migrationsprotokolle und stellen Sie sicher, dass die erwarteten Repositories und Erweiterungen auf jedem Knoten aktiv sind.

Eine erfolgreiche Betriebssystemmigration beweist nicht, dass alle Anwendungsabhängigkeiten kompatibel sind oder dass keine Anfragen unterbrochen wurden. Wenn die Anwendung einen Knotenausfall nicht toleriert, verwenden Sie eine Blue-Green-Bereitstellung mit validierter Datenreplikation und kontrolliertem Endpunktwechsel oder planen Sie ein Wartungsfenster ein. Genaue Befehlsoptionen und Supportbedingungen finden Sie im Online-Upgrade-Leitfaden von SUSE SLES 15 SP6 , in den unterstützten Upgrade-Pfaden , im SLE HA Rolling-Upgrade-Verfahren und in den Versionshinweisen zu SUSE Multi-Linux Manager 5.1 für den Abschnitt zum Lebenszyklusübergang von SP6.