Wie man SLES 15 SP5 auf SP6 migriert, ohne dass es zu Systemausfällen kommt

Sie können eine Anwendung während der Migration eines SLES 15 SP5-Clusters auf SP6 verfügbar halten, jedoch ist ein Upgrade und Neustart einer einzelnen Betriebssysteminstanz ohne jegliche Unterbrechung nicht möglich. SUSE unterstützt die Migration von Service Pack 5 auf SP6, der Online-Migrationsprozess erfordert jedoch weiterhin einen Systemneustart. Um Ausfallzeiten zu vermeiden, sollten Sie in einem unterstützten SUSE Linux Enterprise High Availability (SLE HA)-Cluster die Knoten nacheinander aktualisieren oder eine Ersatzumgebung mit SP6 einrichten und den Datenverkehr dorthin verlagern. Der Dienst muss während der Ausfallzeit der einzelnen Hosts auf einem fehlerfreien Server weiterlaufen können.

Diese Anleitung für Einsteiger konzentriert sich auf den rollierenden Upgrade-Pfad für einen SLE-HA-Cluster. Sie erklärt außerdem, was zu tun ist, wenn Sie nur einen Server haben, welche Punkte vor der Umstellung zu prüfen sind und wie Sie feststellen können, ob der Dienst weiterhin fehlerfrei funktioniert. Die genauen Befehle und die Reihenfolge zum Verschieben von Workloads hängen von Ihren Clusterressourcen, dem Speicher und der Anwendung ab.

Was „ohne Systemausfallzeiten“ bedeutet

Eine Service-Pack-Migration ersetzt Systempakete im laufenden Betrieb. SUSE nennt dies Online-Migration. Dadurch entfällt die Notwendigkeit, von Installationsmedien zu booten. Laut offizieller Anleitung muss das System jedoch nach erfolgreicher Migration neu gestartet werden. Eine Online-Migration ist nicht dasselbe wie ein Live-Upgrade, bei dem der Host weiterhin Anfragen bearbeitet.

Bei einem Clusterdienst bedeutet ein rollierendes Upgrade, dass ein Knoten außer Betrieb genommen, migriert und neu gestartet, wieder in den Cluster integriert und dieser Vorgang dann auf dem nächsten Knoten wiederholt wird. Die Anwendung kann von einem anderen Knoten aus weiterhin verfügbar sein, sofern das Failover funktioniert und die verbleibende Kapazität ausreicht. Ein Failover kann dennoch zu einer kurzen Unterbrechung aktiver Sitzungen führen. Messen Sie daher die Verfügbarkeit des benutzerseitigen Dienstes, anstatt anzunehmen, dass „Hochverfügbarkeit“ garantiert, dass jede Verbindung ununterbrochen bleibt.

SUSE führt SLES 15 SP5 als unterstützte Quelle für SP6 auf, sowohl online als auch offline. Der unterstützte Pfad ist im Upgrade-Leitfaden für SLES 15 SP6 dokumentiert . Die SUSE HA-Dokumentation unterstützt ein rollierendes Cluster-Upgrade zwischen Service Packs innerhalb derselben Hauptversion. Siehe den SLE HA-Cluster-Upgrade-Leitfaden .

Wählen Sie die richtige Vorgehensweise, bevor Sie irgendetwas ändern.

• Ein einzelner Server: Planen Sie ein Wartungsfenster für die Hostmigration und den Neustart ein. Ein Load Balancer kann Ausfallzeiten nicht beseitigen, wenn keine zweite fehlerfreie Anwendungsinstanz vorhanden ist.
• Bei zwei oder mehr SLE HA-Knoten sollte das dokumentierte Rolling-Upgrade-Verfahren angewendet werden, nachdem Quorum, Fencing, Ressourcenplatzierung, Speicherzugriff und Reservekapazität überprüft wurden.
• Anwendung mit Replikaten außerhalb von SLE HA: Aktualisieren Sie einen Ersatz-SP6-Host oder -Pool, validieren Sie ihn und verlagern Sie den Datenverkehr schrittweise. Dies ist eine Blue-Green- oder Rolling-Deployment-Migration auf Anwendungsebene und unterscheidet sich von einer direkten SLES-Migration.
• Für von SUSE Manager verwaltete Hosts: Befolgen Sie den Migrationsworkflow für SUSE Manager-Clients. SUSE rät davon ab, YaST für die Online-Migration oder zypper migrationdirekt auf einem SUSE Manager-Client zu verwenden.

Handelt es sich bei Ihrem Dienst um eine Datenbank oder eine andere zustandsbehaftete Anwendung, sollten Sie Anwendungskompatibilität und Datenreplikation als separate Arbeitsschritte behandeln. Ein Migrationspfad für das Betriebssystem aktualisiert die Datenbank nicht automatisch und beweist auch nicht, dass deren Replikations- und Failover-Design sicher ist.

Bereiten Sie den Cluster und den Änderungsplan vor.

1. Versionen, Registrierung und Upgrade-Berechtigung prüfen

Prüfen Sie, ob auf allen Knoten SLES 15 SP5 installiert ist und die SLE HA-Erweiterung sowie alle anderen Module und Produkte wie erwartet registriert sind. Die Liste der Migrationsziele hängt von den installierten Produkten und Erweiterungen ab. Ein fehlendes SP6-Ziel kann auf ein Problem mit der Registrierung, dem Repository oder der Verfügbarkeit von Erweiterungen hinweisen. Versuchen Sie nicht, einen anderen Repository-Pfad zu erzwingen, nur um das Ziel anzuzeigen.

Bei einem registrierten System können die folgenden schreibgeschützten Prüfungen helfen, seinen Status zu ermitteln:

cat /etc/os-release
sudo SUSEConnect --status
sudo zypper lr -u

Vergleichen Sie die installierten SLES- und SLE-HA-Produkte, Repositories und die Architektur auf allen Knoten. Wenn der Host von SUSE Manager verwaltet wird, verwenden Sie die entsprechende Client-Migrationsprozedur anstelle der unten beschriebenen Schritte.

2. Patchen, Backup erstellen und testen

SUSE verlangt, dass das Quellsystem vor dem Upgrade auf den aktuellsten Patchstand aktualisiert ist. Installieren Sie die aktuellen SP5-Wartungsupdates und lesen Sie die Versionshinweise zu SP6 hinsichtlich Paket-, Modul- und Anwendungsänderungen. Die Upgrade-Vorbereitungsanleitung von SUSE empfiehlt außerdem ein aktuelles Backup und die Durchsicht der Versionshinweise.

Sichern Sie die Systemkonfiguration und die Anwendungsdaten und überprüfen Sie, ob die Sicherung wiederhergestellt werden kann. Testen Sie den gesamten Vorgang auf einem Staging-Cluster, der der Produktionsumgebung entspricht, einschließlich Netzwerkschnittstellen, Speicher, Clusterressourcen, Drittanbieter-Repositories und Integritätsprüfungen der Anwendungen. Protokollieren Sie die Dauer der Migration und des Neustarts auf jedem Knoten, um das Änderungsfenster abschätzen zu können.

3. Beweisen Sie, dass die verbleibenden Knoten die Arbeitslast bewältigen können.

Bevor Sie einen Knoten entfernen, vergewissern Sie sich, dass der Cluster fehlerfrei funktioniert und keine ungelösten Ressourcenfehler aufweist. Prüfen Sie, ob ein anderer Knoten die Dienste ausführen, den benötigten Speicher einbinden oder darauf zugreifen und den erwarteten Datenverkehr bewältigen kann. Falls der Ausfall eines Knotens die CPU, den Arbeitsspeicher, das Netzwerk oder den Speicher überlasten würde, erweitern Sie die Kapazität, reduzieren Sie die Last oder planen Sie ein Wartungsfenster ein, anstatt Ausfallzeiten zu versprechen.

Stellen Sie sicher, dass Cluster-Fencing gemäß Ihrem etablierten HA-Design konfiguriert ist und funktioniert. Fencing schützt gemeinsam genutzte Ressourcen, indem es nicht vertrauenswürdige Knoten isoliert. Die Deaktivierung von Fencing, um ein Upgrade zu vereinfachen, kann ein Split-Brain-Risiko erzeugen. Halten Sie Konsolen- oder Out-of-Band-Zugriff bereit, falls ein Knoten nach einem Neustart nicht wieder verfügbar ist.

Führen Sie ein rollierendes Upgrade durch, einen Knoten nach dem anderen.

Nutzen Sie die folgenden Schritte als Planungsleitfaden. Befolgen Sie die Vorgehensweise entsprechend Ihrer spezifischen SLE HA-Version und Ressourcenkonfiguration; übernehmen Sie keine Ressourcenverwaltungssequenz blind in die Produktionsumgebung.

1. Überprüfen Sie den Clusterzustand. Erfassen Sie den aktuellen Status und stellen Sie sicher, dass alle Knoten und Ressourcen fehlerfrei funktionieren. In SLE HA crm statusist dies eine dokumentierte Methode zur Überprüfung des Clusterstatus.
2. Verschieben oder entfernen Sie Dienste vom Knoten. Verwenden Sie das für Ihren Cluster vorgesehene Verfahren, um die Anwendungsressourcen auf einem anderen fehlerfreien Knoten zu platzieren. Überprüfen Sie vor dem Fortfahren den Anwendungsendpunkt und den zugehörigen Speicher.
3. Stoppen Sie den Cluster-Stack auf dem zu aktualisierenden Knoten. Die Anweisungen von SUSE zum Rolling Upgrade warnen davor, dass das Aktivieren des Cluster-Ressourcenmanagers während eines Software-Upgrades zu Problemen wie der Abriegelung aktiver Knoten führen kann. Der dokumentierte Befehl auf Knotenebene lautet crm cluster stop:
4. Führen Sie die SLES-Service-Pack-Migration durch. Verwenden Sie dazu auf einem registrierten, nicht vom SUSE-Manager verwalteten Host den entsprechenden Befehl sudo zypper migration. Überprüfen Sie die angebotenen Änderungen an SP6-Ziel und -Repository. Lesen Sie die vorgeschlagenen Paketaktionen, insbesondere die zu entfernenden oder herabzustufenden Pakete, bevor Sie die Migration bestätigen. Die offizielle SLES-Online-Migrationsanleitung beschreibt diesen Befehlszeilenpfad.
5. Starten Sie den Knoten neu und überprüfen Sie ihn. Nach Abschluss der Migration starten Sie den Host gemäß den Anweisungen von SUSE neu. Stellen Sie sicher, dass er mit SLES 15 SP6 startet, die erforderlichen Produkte registriert sind, die Repositories mit dem Ziel-Service-Pack übereinstimmen und der Knoten keine kritischen Systemfehler aufweist.
6. Fügen Sie den Knoten wieder dem Cluster hinzu. Starten Sie den Cluster-Stack gemäß der genehmigten Vorgehensweise; die SLE HA-Anleitung zeigt dies crm cluster start. Überprüfen Sie crm statusHawk2 und stellen Sie sicher, dass der Knoten ohne Ressourcenfehler wieder dem Cluster beitritt.
7. Wiederholen Sie diesen Vorgang erst, wenn der Cluster stabil ist. Verlagern Sie die Arbeitslast des nächsten Knotens, entfernen Sie diesen Knoten aus dem Cluster, migrieren Sie ihn, starten Sie ihn neu, validieren Sie ihn und fügen Sie ihn wieder hinzu. Starten Sie den nächsten Knoten nicht, solange der verbleibende Cluster beeinträchtigt ist oder mehr Arbeit verrichtet, als er sicher bewältigen kann.

SUSE gibt an, dass Clusterknoten mit gemischten Versionen während des laufenden Upgrades nur vorübergehend unterstützt werden und das Upgrade innerhalb einer Woche abgeschlossen sein sollte. Planen Sie eine kurze, kontrollierte Vorgehensweise, anstatt einen Cluster mit gemischten Versionen dauerhaft zu betreiben. Stellen Sie abschließend sicher, dass auf allen Knoten SP6 ausgeführt wird, überprüfen Sie den Zustand des Clusters und der Anwendungen und prüfen Sie die Protokolle und die Repository-Registrierung.

Häufige Probleme und was man dagegen tun kann

• Es wird kein SP6-Migrationsziel angezeigt: Überprüfen Sie die Registrierung, die aktiven Repositories und ob jedes installierte Modul oder jede Erweiterung ein unterstütztes SP6-Ziel besitzt. Beheben Sie Repository- oder Berechtigungsprobleme, bevor Sie beginnen.
• Der Solver schlägt unerwartete Entfernungen vor: Untersuchen Sie die Paketquellen, Drittanbieter-Repositories und Abhängigkeiten. SUSE weist darauf hin, dass veraltete lokale oder DVD-Repositories für die Migration deaktiviert werden sollten. Akzeptieren Sie keinen Paketplan, den Sie nicht erklären können.
• Der aktualisierte Knoten wird nicht wieder beitreten: Halten Sie die Anwendung auf fehlerfreien Knoten, überprüfen Sie die Cluster- und Systemprotokolle und verifizieren Sie das Netzwerk, die Produktregistrierung, die Repository-Konfiguration und die SLE HA-Pakete des Knotens, bevor Sie es erneut versuchen.
• Der Dienst ist erreichbar, aber Benutzer melden Fehler: Testen Sie die Anwendungstransaktionen und nicht nur die Hostverfügbarkeit. Überprüfen Sie Datenbankverbindungen, gemeinsam genutzten Speicher, Authentifizierung, geplante Jobs und alle Load-Balancer-Integritätsprüfungen.
• Ein System mit einem einzelnen Server muss online bleiben: Es gibt kein SLES-Service-Pack-Migrationsverfahren, das einen Neustart auf demselben Host vermeidet. Fügen Sie eine zweite Anwendungsinstanz hinzu oder planen Sie eine Wartungsperiode ein.

Wie lässt sich beurteilen, ob Ausfallzeiten vermieden wurden?

Definieren Sie vor der Änderung eine messbare Erfolgsbedingung. Zum Beispiel: Der externe Integritätscheck des Dienstes bleibt während der gesamten Wartung jedes Knotens erfolgreich, die Fehlerraten bleiben innerhalb des vereinbarten Schwellenwerts und eine repräsentative Benutzertransaktion wird erfolgreich durchgeführt, während ein Knoten nicht verfügbar ist. Protokollieren Sie jegliche Ausfallzeiten, abgebrochene Sitzungen, in die Warteschlange gestellte Aufgaben oder Leistungseinbußen. Wenn der Endpunkt zwar erreichbar blieb, ein wichtiger Workflow jedoch fehlschlug, wurde das Service-Level-Ziel der Migration nicht erreicht.

Ein rollierendes Upgrade kann einen ordnungsgemäß konzipierten Dienst während des Neustarts einzelner Server verfügbar halten. Es kann jedoch keine unterbrechungsfreien Sitzungen garantieren, einen Cluster mit unzureichender Kapazität nicht kompensieren und den Neustart jedes migrierten Hosts nicht eliminieren. Bei Einzelknoten-Bereitstellungen, zustandsbehafteten Anwendungen ohne getestete Replikation oder Clustern mit nicht unterstützten Erweiterungen sollten Sie ein geplantes Wartungsfenster nutzen oder eine Ersatzumgebung aufbauen und validieren, bevor Sie den Produktionsdatenverkehr migrieren.

Offizielle Referenzen

• SUSE: Unterstützte Upgrade- und Migrationspfade zu SLES 15 SP6
• SUSE: Vorbereitung des Upgrades
• SUSE: Online-Upgrade mit YaST oder Zypper
• SUSE: Rolling Upgrade des SLE HA-Clusters
• SUSE: SLES 15 SP6 Versionshinweise