Warum ist ein Upgrade zwischen den Hauptversionen von Red Hat und CentOS so schwierig?


72

"Können wir unsere vorhandenen Produktions-EL5-Server auf EL6 aufrüsten?"

Eine einfach klingende Anfrage von zwei Kunden mit völlig unterschiedlichen Umgebungen veranlasste mich zu meiner üblichen Best-Practice-Antwort: "Ja, aber es wird ein koordinierter Neuaufbau aller Ihrer Systeme erforderlich sein " ...

Beide Kunden sind der Meinung, dass ein vollständiger Neuaufbau ihrer Systeme aus Gründen der Ausfallzeit und der Ressourcen nicht akzeptabel ist ... Als ich gefragt wurde, warum die Systeme vollständig neu installiert werden mussten, hatte ich darüber hinaus keine gute Antwort: "So ist das nun mal ... "

Ich versuche nicht, Antworten zum Konfigurationsmanagement ("Puppetize everything " trifft nicht immer zu ) oder zur besseren Planung der Clients zu erhalten. Dies ist ein Beispiel aus der Praxis für Umgebungen, deren Produktionskapazität gewachsen und gediehen ist, die jedoch keinen sauberen Weg für die Umstellung auf die nächste Version ihres Betriebssystems finden.

Umgebung A:
Non-Profit-Organisation mit 40 Web-, Datenbank- und Mailservern von Red Hat Enterprise Linux 5.4 und 5.5 , einem Java-Webanwendungsstapel, Software-Load-Balancern und Postgres-Datenbanken. Alle Systeme werden auf zwei VMWare vSphere-Clustern an verschiedenen Standorten mit jeweils HA, DRS usw. virtualisiert.

Umfeld B:
Hochfrequenz-Finanzhandelsunternehmen mit 200 CentOS 5.x- Systemen in mehreren Co-Location-Einrichtungen, die den Produktionshandel betreiben und die interne Entwicklung und Back-Office-Funktionen unterstützen. Die Handelsserver laufen auf Bare-Metal-Commodity-Server-Hardware. Sie haben zahlreiche sysctl.conf, rtctl, Interrupt - Bindung und Treiber zwickt anstelle Messaging - Latenz zu senken. Einige haben benutzerdefinierte und / oder Echtzeit-Kernel. Auf den Entwicklerarbeitsplätzen werden ähnliche Versionen von CentOS ausgeführt.


In beiden Fällen laufen die Umgebungen so, wie sie sind. Der Wunsch nach einem Upgrade ergibt sich aus der Notwendigkeit einer neueren Anwendung oder Funktion, die in EL6 verfügbar ist.

  • Für die gemeinnützige Firma ist es an Apache, den Kernel und einige Dinge gebunden, die die Entwickler glücklich machen werden.
  • In der Handelsfirma geht es um einige Verbesserungen im Kernel, Networking Stack und GLIBC, die die Entwickler glücklich machen werden.

Beides ist nicht einfach zu packen oder zu aktualisieren, ohne das Betriebssystem drastisch zu verändern .

Als Systemingenieur weiß ich zu schätzen, dass Red Hat beim Wechsel zwischen Hauptversionen vollständige Neuerungen empfiehlt. Ein sauberer Start zwingt Sie dazu, die Konfiguration zu überarbeiten und auf diese zu achten.

Ich bin sensibel für die geschäftlichen Bedürfnisse der Kunden und frage mich, warum dies eine so beschwerliche Aufgabe sein muss . Das RPM-Paketierungssystem ist mehr als in der Lage, direkte Upgrades durchzuführen, aber es sind die kleinen Details, die Sie /bootbenötigen : mehr Speicherplatz, neue Standarddateisysteme, RPM, das möglicherweise während des Upgrades unterbrochen wird, veraltete und nicht mehr funktionierende Pakete ...

Was ist die Antwort hier? Andere Distributionen (.deb-basiert, Arch und Gentoo) scheinen diese Fähigkeit oder einen besseren Pfad zu haben. Nehmen wir an, wir finden die Ausfallzeit, um diese Aufgabe richtig auszuführen:

  • Was sollten diese Clients tun, um das gleiche Problem zu vermeiden, wenn EL7 freigegeben und stabilisiert wird?
  • Oder ist dies ein Fall, in dem sich die Menschen alle paar Jahre mit einem vollständigen Umbau abfinden müssen?
  • Dies scheint schlimmer geworden zu sein, als sich Enterprise Linux weiterentwickelt hat ... Oder bilde ich mir das nur ein?
  • Hat dies jemanden davon abgehalten, Red Hat und abgeleitete Betriebssysteme zu verwenden?

Ich nehme an, es gibt den Konfigurationsverwaltungsaspekt, aber die meisten Puppet-Installationen, die ich sehe, lassen sich nicht gut in Umgebungen mit stark angepassten Anwendungsservern übersetzen ( Umgebung B könnte einen einzelnen Server haben, dessen ifconfigAusgabe so aussieht ). Ich wäre jedoch an Vorschlägen interessiert, wie das Konfigurationsmanagement Unternehmen dabei helfen kann, die Probleme der RHEL-Hauptversion zu überwinden.


16
Ich wollte dies zum Abschluss als "nicht konstruktiv" markieren, als ich den Namen des Autors und des Vertreters sah, und aus Respekt werde ich dies nicht tun. Ich denke immer noch, dass es eine dumme Frage ist, denn die Antwort lautet: "Red Hat hat entschieden, dass es so sein sollte". 4-> 5 Upgrades waren per DVD-Boot problemlos möglich, und es gab Verfahren, um ein Live-Betriebssystem zu verwenden yum, was die meiste Zeit bei mir funktionierte. Meine einzige Hoffnung ist, dass RH seinen zahlenden Kunden einen Riesenerfolg abverlangt hat, weil sie entschieden haben, keinen unterstützten Upgrade-Pfad 5-> 6 zu haben, und dies für 6-> 7 überdenken wird.
MadHatter

1
Das heißt, Sie wissen, dass ein nicht unterstützter Upgrade-Pfad per DVD-Boot von C5-> C6 unter Verwendung des upgradeanyBoot-Time-Parameters funktioniert , ja? Ich habe es zweimal getestet, einmal auf einer sauberen C5-Installation, wo es gut funktioniert hat. einmal auf einer (Testkopie einer) crufty alten "C4 und wurde aktualisiert" -Installation, wo es dramatisch fehlschlug.
MadHatter

2
Ich bin mir der Upgrade-Optionen sehr wohl bewusst und habe die Installationen definitiv unter Verwendung des Live-RPM-Ansatzes (Ändern des Repos *-release filesund aller) erzwungen . Aber die Fragen von Kunden in dieser Woche haben mich mehr darüber nachdenken lassen, wie tief eine Umgebung mit einer bestimmten Version verwurzelt werden kann und wie weit ich gehen kann.
Ewwhite

Antworten:


42

(Anmerkung des Autors: Diese Antwort bezieht sich auf RHEL 6 und frühere Versionen. RHEL 7 verfügt nun über einen vollständig unterstützten Upgrade-Pfad von RHEL 6, dessen Details am Ende stehen.)


Zunächst sollte ich beachten, dass es zwei Möglichkeiten gibt , das direkte Upgrade durchzuführen:

  1. Legen Sie die Installations-DVD ein (oder verwenden Sie das DVD-Image über iLO / iDRAC), booten Sie von dieser und wählen Sie Upgrade, z linux upgradeany.
  2. Aktualisieren Sie das redhat-releaseRPM manuell, führen Sie es aus yum distro-sync(dies ist etwas vereinfacht) und starten Sie es neu.

Methode 1 wird lediglich nicht unterstützt. Methode 2 ist für echte Cowboys. Zusätzlich zu den empfohlenen Neuinstallationen habe ich beide ...


Benötige ich Unterstützung?

Unterstützung hat in unserer Welt zwei sich ergänzende Bedeutungen. Das erste ist, dass ein Produkt eine bestimmte Funktion hat (zB "Postfix unterstützt SMTP"). Das zweite ist, dass der Verkäufer mit Ihnen darüber spricht. Welche Definition gemeint ist, ergibt sich nicht immer aus dem Kontext.

Um eine Aufgabe zu erfüllen, braucht man natürlich Unterstützung im ersten Sinne. Die Unterstützung von Anbietern soll Sie bei der Lösung von Problemen unterstützen und dem Anbieter Feedback geben, welche Funktionen vorhanden sein oder verbessert werden müssen. Viele Standorte zahlen ein Vermögen für die Unterstützung von Anbietern, wenn sie über das interne Know-how verfügen, um auftretende Probleme schneller und sogar billiger zu lösen, als dies der Anbieter könnte. Ob Sie Lieferantenunterstützung kaufen, ist letztendlich eine Geschäftsentscheidung, die Sie treffen müssen (oder die Sie an das Management weiterleiten müssen).


Warum nicht ein direktes Upgrade durchführen?

Das sagt Red Hat dazu :

Red Hat unterstützt keine direkten Upgrades zwischen Hauptversionen von Red Hat Enterprise Linux. Eine Hauptversion wird durch eine Versionsänderung mit einer ganzen Zahl gekennzeichnet. Beispielsweise sind Red Hat Enterprise Linux 5 und Red Hat Enterprise Linux 6 beide Hauptversionen von Red Hat Enterprise Linux.

Durch direkte Upgrades über größere Releases hinweg werden nicht alle Systemeinstellungen, Dienste oder benutzerdefinierten Konfigurationen beibehalten. Red Hat empfiehlt daher dringend, beim Upgrade von einer Hauptversion auf eine andere eine Neuinstallation durchzuführen.

Sie warnen weiter:

Beachten Sie jedoch die folgenden Einschränkungen, bevor Sie Ihr System aktualisieren:

  • Einzelne Paketkonfigurationsdateien können nach dem Durchführen eines Upgrades aufgrund von Änderungen in verschiedenen Konfigurationsdateiformaten oder -layouts möglicherweise nicht funktionieren.
  • Wenn Sie eines der mehrschichtigen Produkte von Red Hat (z. B. die Cluster Suite) installiert haben, muss dieses möglicherweise nach Abschluss des Red Hat Enterprise Linux-Upgrades manuell aktualisiert werden.
  • Drittanbieter- oder ISV-Anwendungen funktionieren nach dem Upgrade möglicherweise nicht richtig.

Anschließend wird natürlich beschrieben, wie ein direktes Upgrade über Methode 1 durchgeführt wird, nur für den Fall, dass Sie es wirklich möchten. Das Feature ist vorhanden und Red Hat verwendet Entwicklungszeit, sodass es unterstützt wird, dass das Feature vorhanden ist. Wenn jedoch etwas schief geht, werden Sie von Red Hat aufgefordert, die Installation neu durchzuführen. Sie bieten keinen Anbietersupport für Dinge, die durch das Upgrade beschädigt werden.

Eigentlich hatte ich nie ein Problem mit einem direkten Upgrade eines RHEL / CentOS- oder Fedora-Systems, das ich nicht selbst lösen konnte. Die typischen Probleme werden durch umbenannte Pakete, Repositorys von Drittanbietern und gelegentliche Versionskonflikte zwischen den Architekturen i386 und x86_64 eines Pakets verursacht. Der Installer kann damit ein bisschen besser umgehen als yum, denke ich.


Wie soll ich upgraden?

Ich warne die Menschen im Allgemeinen , dass sie sollten planen , auf einem Wartungsfenster alle 3-4 Jahre zu aktualisieren RHEL - Systeme von einer Hauptversion auf den nächsten. Während Upgrades im Allgemeinen reibungslos verlaufen, kann es immer zu unerwarteten Ereignissen kommen.

Ich gehe davon aus, dass ein direktes Upgrade in beiden Umgebungen funktioniert, empfehle jedoch dringend, es zuerst gründlich zu testen. Stellen Sie eine repräsentative Stichprobe der Server zur Verfügung und führen Sie das direkte Upgrade auf den virtuellen Systemen durch, um festzustellen, auf welche Probleme Sie stoßen werden. Sie können dann das eigentliche Produktions-Upgrade planen, indem Sie besser wissen, was passieren wird.

Bei einer umfangreichen Bereitstellung wie der hier beschriebenen sollten Sie den Limoncelli-Ansatz "one-some-many" in Betracht ziehen. Aktualisieren Sie eine Maschine, sehen Sie, welche Probleme auftreten, lösen Sie sie, und verwenden Sie dann die Lektionen, die Sie beim Aktualisieren einer kleinen Menge von Maschinen gelernt haben. Wiederholen Sie die Lektionen, und aktualisieren Sie große Mengen von ihnen, wenn Sie glauben, dass alle Probleme behoben sind.

In einer Zeit wie dieser empfehle ich außerdem, sich eingehend mit Ihrem Anwendungsbereitstellungsprozess zu befassen. Wenn es nicht ausreichend automatisiert ist, dass Sie es mit einem einzigen Befehl starten können, und Sie einigermaßen sicher sind, dass die App ordnungsgemäß bereitgestellt wird, müssen die Entwickler möglicherweise damit beginnen, daran zu arbeiten. Ein solcher Bereitstellungsprozess würde es viel einfacher machen, eine Neuinstallation der neueren Version von EL durchzuführen und dann darauf bereitzustellen.


Wird das Umschalten von Distributionen helfen?

Auf Debian basierende Distributionen haben eine unterstützte direkte Upgrade-Methode, die meistens funktioniert, aber nicht vor Problemen gefeit ist. Es gab viele Probleme bei einem Upgrade von Ubuntu 10.04 LTS auf 12.04 LTS über die unterstützte Methode. Es ist nicht klar, ob Debian oder Canonical genügend Entwicklungszeit darauf verwenden, diese Funktion zu "unterstützen", dh sicherzustellen, dass sie funktioniert. Und Sie müssen für diese Distribution immer noch Herstellerunterstützung kaufen, wenn Sie möchten, dass jemand Ihre Hand hält. Ich bezweifle, dass Sie durch den Wechsel zu einer solchen Distribution viel gewinnen werden.

Sie können davon profitieren, wenn Sie zu einer rollenden Release-Distribution wie Gentoo oder Arch wechseln. Dies macht Sie jedoch auch nicht immun gegen Probleme. Dies bedeutet lediglich, dass Sie sich über die gesamte Lebensdauer des Servers hinweg mit den Upgrade-Problemen auseinandersetzen müssen (z. B. wenn Sie oder die Entwickler entscheiden, das System zu aktualisieren), und nicht alle gleichzeitig zu einer gut geplanten Upgrade-Zeit für die Verteilung. Sie haben auch keinen Anbieter, der Support leistet.


Was hält die Zukunft bereit?

Das Fedora-Projekt arbeitet an einem Tool zur Verbesserung der direkten Upgrades. Sie hatten ein Tool namens " Fedup", das mit Fedora 18 preupgradeaufgegeben und durch ein neues Tool namens " Fedup" ersetzt wurde . Dies wurde zu RHEL7 hinzugefügt, und jetzt bieten vorhandene Upgrades vollständige Unterstützung , zumindest von RHEL 6 auf RHEL 7 . Aus eigener Erfahrung kann ich sagen, dass es zwar fedupeinige Knicke aufweist , sich jedoch als sehr nützliches Werkzeug herausstellt.

CentOS experimentiert auch mit einem rollierenden Release-Repository , das jedoch nur für Nebenversionen (z. B. 6.3-6.4) gilt.


1
Das neue Fedora-Upgrade-Tool heißt fedup . Drei bis vier Jahre klingen für mich auch für größere Upgrades aggressiv. Muss installiert werden, sehe ich für den mehr als 10-jährigen Lebenszyklus von RHEL eine längere Lebensdauer. Daher würde ich regelmäßigere kleinere Upgrades empfehlen.
Dominic Cleal

3
Für Leute, die ständig neue Funktionen benötigen, sind 3-4 Jahre fast zu lang.
Michael Hampton

3
Einfache Dinge wie PHP, Apache, Kernel-Revisionen und GLIBC ... Die Leute tendieren dazu, diese Änderungen häufiger zu wollen.
Ewwhite

2
Der Upgrade-Prozess von Debian / Ubuntu ist nicht perfekt, aber die Tatsache, dass es sich um den bevorzugten Upgrade-Mechanismus handelt und Red Hat keinen offiziell unterstützten Upgrade-Mechanismus hat, spricht Bände für mich.
Paul Gear

1
Es ist nicht so wichtig, ob direkte Upgrades vorhanden sind, wie dies offensichtlich der Fall ist, sondern ob die jeweiligen Anbieter Unterstützung für sie bereitstellen.
Michael Hampton

6

Meine Einstellung zu Ihrem letzten Absatz:

Ich nehme an, es gibt den Konfigurationsverwaltungswinkel, aber die meisten Puppet-Installationen, die ich sehe, lassen sich nicht gut in Umgebungen mit stark angepassten Anwendungsservern übersetzen (Umgebung B könnte einen einzelnen Server haben, dessen ifconfig-Ausgabe so aussieht). Ich wäre jedoch an Vorschlägen interessiert, wie das Konfigurationsmanagement Unternehmen dabei unterstützen kann, die Hauptversion von RHEL zu überwinden.

Ich denke, der wahre Wert von Konfigurationsmanagementsystemen, insbesondere im Kontext von Umgebung B, besteht darin, dass sie die Tools zum Erstellen eines Dienstes unabhängig von den Servern bereitstellen, auf denen sie ausgeführt werden. Wenn ein CMS nicht zum Erstellen der vorhandenen Dienste verwendet wurde, hilft es wahrscheinlich nicht sehr, die Dienste neu zu erstellen.

Ich weiß, dass dies Ihr unmittelbares Problem nicht löst, aber für mich resultiert es aus dem Denken der Organisation in Bezug auf Server und nicht in Bezug auf Dienste. Beim serviceorientierten Denken muss die Persönlichkeit einzelner Server nicht beibehalten werden, solange der Service weiterhin funktioniert. Wenn ein CMS auf disziplinierte Weise zum Erstellen des gesamten Dienstes verwendet wird, sollte das Verschieben dieses Dienstes auf ein anderes System relativ einfach sein, da die gesamte Persönlichkeit des Computers vom CMS erstellt wird.

PS Ich bin mir nicht ganz sicher, was in diesem Zusammenhang an der Ausgabe von ifconfig wichtig ist. Sie wird von einer Konfigurationsdatei und einigen Skripten erstellt (andernfalls wäre sie beim Booten nicht vorhanden). Diese können bei Bedarf von einem CMS verwaltet werden.


1
Sie haben Recht mit Services im Vergleich zu Servern im Allgemeinen. Die Umgebung B verfügt über eine spezielle Serverhardware (10-GbE-NICs, Offload-Bibliotheken), die mit Upstream-Anbietern zusammenarbeitet. Es ist etwas, das sich ohne Ausfallzeiten nicht leicht ausgleichen oder bewegen lässt. Ein nicht finanzielles Beispiel wäre so etwas wie ein Server, der als Controller für einige beteiligte Produktionsmaschinen angeschlossen ist. Sonderfall, möglicherweise mit dedizierten PCIe-Schnittstellenkarten. Sehr einmalig für den Server. Würden Sie in Puppet einfach sagen: "Hier ist die Konfiguration für diesen einen Host / diese Rolle" und damit leben?
ewwhite

1
Einverstanden ist, dass einige Dinge nicht einfach in allgemeine Fälle zu integrieren sind, insbesondere wenn Sie eine Umgebung mit bestimmten Hardwareanforderungen haben. Mit Puppet macht es Sinn, so viel wie möglich in die Rolle zu schieben. Aber am Ende muss es funktionieren. Wenn also etwas nicht ganz Elegantes funktioniert, dann lebe ich einfach damit, dass es unelegant ist. Die meiste Zeit müssen wir mit uneleganten Dingen leben, nur weil wir nicht die Zeit haben, sie "richtig" zu machen.
Paul Gear
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.