Was sind RHEL In-Place-Upgrades?

Wenn Kunden von Red Hat Enterprise Linux (RHEL) ihren Anwendungs-Stack aktualisieren, die neuesten Sicherheitsupdates erhalten wollen oder sich dem Ende eines RHEL Lifecycles nähern (wie etwa RHEL 7, das am 30. Juni 2024 sein End of Maintenance erreicht), dann möchten sie in der Regel auf den neuesten Release zugreifen. Dieser Beitrag ist der erste in einer Reihe von Artikeln über RHEL Upgrades, von denen wir hoffen, dass sie Ihnen bei der Planung zukünftiger Upgrades helfen. Zunächst werfen wir einen Blick auf RHEL In-Place-Upgrades.

Welche Probleme lösen In-Place-Upgrades?

In der Vergangenheit erforderten Upgrades eine Neuinstallation des Betriebssystems sowie die erneute Bereitstellung aller Anwendungs-Stacks, Datenbanken und Konfigurationen. In-Place-Upgrades lösen dieses Problem und erhalten gleichzeitig bestehende Kunden-Workflows. Sehen wir uns zunächst an, wo In-Place-Upgrades im Vergleich zu einer Neuinstallation die richtige Wahl für Unternehmen sind.

In-Place-Upgrades im Vergleich zu Neuinstallationen

In-Place-Upgrades können in vielen Fällen von weniger erfahrenen Systemadministratoren durchgeführt werden. Wenn Ihre Systeme keine komplexen oder ungewöhnlichen Konfigurationen aufweisen, brauchen Sie nur wenige Befehle auf den zu aktualisierenden Rechnern auszuführen, den Analysebericht vor dem Upgrade überprüfen und bei Bedarf die vorgeschlagenen Korrekturen ausführen.

Konfigurationen beibehalten

Die Beibehaltung der Kontrolle über die installierte Anwendung ist eine der wichtigsten Funktionen von In-Place-Upgrades. Sie können den Upgrade-Prozess erweitern, indem Sie angeben, welche benutzerdefinierten Repositorys während des Upgrades verwendet werden sollen. Das Schreiben von benutzerdefinierten Leapp-Actors kann auch bei der Migration von Drittanbieteranwendungen mit bestimmten Konfigurationen helfen. Organisationen, die ihre Umgebung modernisieren möchten, profitieren von dieser Kontrolle, da sie sich um benutzerdefinierte Anwendungsanforderungen kümmern können. Weiterhin können die während des Upgrade-Vorgangs angezeigten Korrekturschritte mithilfe von Ansible-Playbooks automatisiert werden.

Weniger Bedarf an fortgeschrittenen Kenntnissen 

In-Place-Upgrades erfordern keine Vorkenntnisse über vorhandene Systemkonfigurationen oder installierte Anwendungen, sodass auch relativ unerfahrene Administratoren das Upgrade durchführen können. Das Risiko eines versehentlichen Löschens von Anwendungen oder Konfigurationen wird durch die Analyse vor dem Upgrade und vorgeschlagene Korrekturen verringert. Der Administrator muss nur in der Lage sein, die Informationen in dem Bericht zu verstehen.

Subskriptionen behalten

Da während eines In-Place-Upgrades keine Informationen zu vorhandenen RHEL Subskriptionen gelöscht werden, funktionieren die Subskriptionen weiterhin.

Sparen von Zeit und Ressourcen

In-Place-Upgrades sparen Zeit und wertvolle Ressourcen. Sie bieten eine bequeme Möglichkeit, die Lebensdauer aktueller Hardware zu verlängern und gleichzeitig die gesamte Umgebung zu modernisieren.

Weniger Unsicherheit

Die Analyse vor dem Upgrade ist ein nützliches eigenständiges Tool. Wenn ein Kunde sich nicht sicher ist, kann er die Analyse vor dem Upgrade ausführen, um eine Bestandsaufnahme der auf dem System installierten Pakete mit möglichen Upgrade-Pfaden und Korrekturvorschlägen zu erstellen. Dies kann bei der Entscheidung für den richtigen Upgrade-Ansatz hilfreich sein.

Neue Installationen 

Bei einer Neuinstallation von RHEL werden die Systemdaten gelöscht, einschließlich Anwendungen und Konfigurationen. Dies führt zu enormen Betriebskosten und erfordert zusätzliches Fachwissen während der Bereitstellung.

Löschen vorhandener Konfigurationen

Konfigurationen werden während der Installation gelöscht. Das erneute Anwenden der Konfigurationen kann zeitaufwändig sein, insbesondere wenn Sie keine Automatisierungsfunktionen verwenden, die in Produkten wie Red Hat Ansible Automation Platform enthalten sind.

Erhöhter Zeit- und Kostenaufwand

Sie müssen das Betriebssystem (OS) auf möglicherweise Hunderten oder sogar Tausenden von Rechnern neu installieren, einschließlich der erneuten Bereitstellung des gesamten Anwendungs-Stack. Diese zusätzliche Arbeit kostet Ressourcen und Zeit.

Rechner müssen neu subskribiert werden

Auf den gelöschten Rechnern können vorhandene RHEL Subskriptionen während der Installation nicht beibehalten werden. Die Rechner müssen erneut subskribiert werden, damit sie ordnungsgemäß funktionieren.

Wann sind Neuinstallationen empfehlenswert?

Neue Installationen können von Vorteil sein, wenn Sie auf neue Hardware umsteigen, einen neuen Anwendungs-Stack haben oder neue Management- und Automatisierungsfunktionen benötigen. Greenfield-Projekte (Projekte, die nicht auf vorheriger Arbeit basieren) können beispielsweise gute Use Cases für neue Installationen sein. 

Verfügbarkeit und unterstützte Versionen

Beim Upgrade über die Befehlszeilenschnittstelle können die erforderlichen Pakete über dnf oder yum installiert werden – durch die Installation von Leapp-upgrade– einem virtuellen Paket, das auf RHEL Systemen bereitgestellt wird, auf denen Leapp verfügbar ist. Der Befehl Leapp verwendet dann seine Unterbefehle, um den Pre-Upgrade-Bericht zu erstellen. Danach ist das Upgrade verfügbar.

Kunden können die Pre-Upgrade-Analyse auch in Red Hat Satellite ausführen, wo sie ihre Rechner verwalten. Nach der Durchführung der Bewertung vor dem Upgrade und der Behebung der analysierten Risiken können die Rechner auch in der Benutzeroberfläche gleichzeitig aktualisiert werden. Weitere Informationen finden Sie unter Leapp in Satellite.

Mehrere Versionen von RHEL sind für ein Upgrade berechtigt. Eine vollständige und aktuelle Liste der unterstützten Upgrade-Pfade finden Sie unter: Supported in-place upgrade paths for Red Hat Enterprise Linux.  Die Liste wird bei neuen RHEL Releases aktualisiert.

Was den Support für Public Clouds betrifft, so bieten wir In-Place-Upgrades für On-Demand-Pay-as-you-go-Instanzen (PAYG) auf Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform mit Red Hat Update Infrastructure (RHUI) an. Wir unterstützen auch Upgrades für Bring Your Own Subscription (BYOS)-Instanzen in allen Public Clouds, die Red Hat Subscription Manager für eine RHEL Subskription verwenden.

Beachten Sie, dass direkte Upgrades über mehrere Major-Releases (wie etwa RHEL 6 auf RHEL 8) nicht möglich sind. Beim Upgrade von Version 6 auf 8 führen Sie zunächst ein Upgrade auf RHEL 7 und dann ein Upgrade auf RHEL 8 durch.

Genaue Details zu unterstützten Architekturen und Produkten sowie ausführlichere Informationen zum Upgrade finden Sie in der folgenden Dokumentation:

• Upgraden von RHEL 6 auf RHEL 7
• Upgraden von RHEL 7 zu RHEL 8
• Upgraden von RHEL 8 auf RHEL 9

Zusammenfassung

In-Place-Upgrades können verschiedene Probleme bei dem erneuten Deployment lösen und gleichzeitig Kosten und Zeit sparen. Während Neuinstallationen weiterhin für Greenfield-Projekte verwendet werden können, sind In-Place-Upgrades der klare Gewinner bei der Modernisierung vorhandener Umgebungen. In-Place-Upgrades sind ebenfalls ein wesentlicher Bestandteil des RHEL Ökosystems. Daher ist ihre kontinuierliche Unterstützung sowie geplante Innovationen weiterhin zu erwarten.