Frage Warum ist es so schwierig, zwischen den Hauptversionen von Red Hat und CentOS zu wechseln?


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

Eine einfach klingende Anfrage von zwei Kunden mit vollständig verschiedene Umgebungen führten zu meiner üblichen Best-Practice-Antwort "Ja, aber es wird ein koordiniertes erfordern Wiederaufbau aller Ihrer Systeme"...

Beide Kunden sind der Ansicht, dass eine vollständige Wiederherstellung ihrer Systeme aus Gründen der Ausfallzeit und der Ressourcen keine akzeptable Option darstellt ... Auf die Frage, warum die Systeme vollständig neu installiert werden sollten, hatte ich keine gute Antwort. "So ist es ... "

Ich versuche nicht, Antworten auf das Konfigurationsmanagement zu erhalten ("Puppe alles" gilt nicht immer) oder wie die Kunden besser geplant haben sollten. Dies ist ein realistisches Beispiel für Umgebungen, die in einer Produktionskapazität gewachsen und gediehen sind, aber keinen sauberen Pfad sehen, um zur nächsten Version ihres Betriebssystems zu wechseln.

Umgebung A:
Non-Profit-Organisation mit 40 x Red Hat Enterprise Linux 5.4 und 5.5 Web, Datenbankserver und Mailserver, die einen Java Web Application Stack, Software Load Balancer und Postgres Datenbanken betreiben. Alle Systeme werden auf zwei VMWare vSphere-Clustern an verschiedenen Standorten virtualisiert, wobei jeder über HA, DRS usw. verfügt.

Umwelt B:
Hochfrequenz-Finanzhandelsunternehmen mit 200 x CentOS 5.x Systeme in mehreren Co-Location-Anlagen, in denen der Produktionshandel betrieben wird, Unterstützung von Eigenentwicklungen und Backoffice-Funktionen. Die Trading-Server laufen auf Bare-Metal-Commodity-Server-Hardware. Sie haben zahlreiche sysctl.conf, rtctl, Interrupt-Bindung und Treiber-Tweaks, um die Messaging-Latenz zu senken. Einige haben benutzerdefinierte und / oder Echtzeit-Kernel. Die Entwickler-Workstations haben ebenfalls eine ähnliche Version von CentOS.


In beiden Fällen laufen die Umgebungen einwandfrei. Der Wunsch nach einem Upgrade besteht darin, dass eine neuere Anwendung oder Funktion in EL6 benötigt wird.

  • Für das Non-Profit-Unternehmen ist es mit Apache, dem Kernel und einigen Dingen verbunden, die die Entwickler glücklich machen.
  • In der Handelsfirma geht es um einige Verbesserungen im Kernel, Netzwerk-Stack und GLIBC, die die Entwickler glücklich machen werden.

Beides sind Dinge, die nicht ohne weiteres verpackt oder aktualisiert werden können drastisch das Betriebssystem ändern.

Als Systemingenieur weiß ich zu schätzen, dass Red Hat beim Wechsel zwischen den Hauptversionsversionen vollständige Neuerstellungen empfiehlt. Ein sauberer Start zwingt Sie zu Refactoring und achten Sie auf Configs auf dem Weg.

Da ich auf die geschäftlichen Bedürfnisse von Kunden sensibel bin, frage ich mich, warum das so sein muss belastende Aufgabe. Das RPM-Packaging-System ist mehr als nur in der Lage, In-Place-Upgrades zu verarbeiten, aber es sind die kleinen Details, die Ihnen helfen: /boot mehr Speicherplatz erforderlich, neue Standard-Dateisysteme, RPM, die möglicherweise während der Aktualisierung unterbrochen werden, veraltete und nicht mehr funktionierende Pakete ...

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

  • Was sollten diese Kunden tun, um dasselbe Problem zu vermeiden, wenn EL7 veröffentlicht wird und sich stabilisiert?
  • Oder ist dies ein Fall, in dem sich die Menschen alle paar Jahre den vollständigen Umbauten stellen müssen?
  • Dies scheint sich mit der Entwicklung von Enterprise Linux verschlechtert zu haben ... Oder stelle ich mir das nur vor?
  • Hat das irgendjemanden davon abgehalten, Red Hat und abgeleitete Betriebssysteme zu benutzen?

Ich nehme an, es gibt den Konfigurations-Management-Winkel, aber die meisten Puppet-Installationen, die ich sehe, lassen sich nicht gut in Umgebungen mit stark angepassten Anwendungsservern übersetzen (Umwelt B könnte einen einzigen Server haben, dessen ifconfig Ausgabe sieht aus wie das). Es wäre interessant, Vorschläge zu hören, wie das Konfigurationsmanagement genutzt werden kann, um Unternehmen dabei zu helfen, den RHEL-Hauptversions-Bump zu überwinden.


70
2017-11-15 15:14


Ursprung


Ich wollte dies als "nicht konstruktiv" bezeichnen, als ich den Namen des Autors sah, und ich werde es aus Respekt nicht tun. Ich denke immer noch, dass es eine dumme Frage ist, denn die Antwort ist, dass "Red Hat entschieden hat, dass es so sein sollte". 4-> 5 Upgrades waren per DVD-Boot perfekt möglich, und es gab Prozeduren, um es mit einem aktiven Betriebssystem zu machen yum, die für mich die meiste Zeit funktionierte. Meine einzige Hoffnung ist, dass RH eine aufgenommen hat enorm Hit des Schmerzes Stick von ihren zahlenden Kunden für ihre Entscheidung, keinen unterstützten Upgrade-Pfad 5-6 zu haben, und wird dies für 6-7 überdenken. - MadHatter
Das heißt, Sie wissen, dass ein funktionierender, nicht unterstützter Upgrade-Pfad über einen DVD-Boot von C5-> C6 mit Hilfe des upgradeany Boot-Zeit-Parameter, ja? Ich habe es zweimal getestet, einmal auf einer sauberen C5-Installation, wo es gut funktioniert hat; Einmal auf einer (Testkopie einer) kniffligen alten "früher C4 und wurde aktualisiert" installieren, wo es dramatisch gescheitert ist. - MadHatter
Ich bin mir der Upgrade-Möglichkeiten bewusst und habe definitiv die Installationen mit dem Live-RPM-Ansatz erzwungen (Änderung des Repo, *-release files und alles). Aber die Fragen der Kunden in dieser Woche haben mich dazu gebracht, mehr darüber nachzudenken, wie fest die Umwelt mit einer bestimmten Version verschmelzen kann und dass es keinen Weg nach draußen gibt. - ewwhite


Antworten:


(Anmerkung des Autors: Diese Antwort bezieht sich auf RHEL 6 und frühere Versionen. RHEL 7 verfügt jetzt über einen vollständig unterstützten Aktualisierungspfad von RHEL 6, dessen Details am Ende aufgeführt sind.)


Zu Beginn sollte ich beachten, dass es solche gibt zwei Wege um das In-Place-Upgrade durchzuführen:

  1. Legen Sie die Installations-DVD ein (oder verwenden Sie das DVD-Image über iLO / iDRAC), starten Sie von dieser und wählen Sie Upgrade, z. linux upgradeany.
  2. Aktualisieren Sie die redhat-release RPM manuell, ausführen yum distro-sync (Dies ist ein wenig vereinfacht) und neu starten.

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


Brauche ich Unterstützung?

Unterstützung hat zwei komplementäre Bedeutungen in unserer Welt. Die erste besteht darin, dass ein Produkt ein bestimmtes Merkmal aufweist (z. B. "Postfix unterstützt SMTP"). Der zweite ist, dass der Verkäufer mit Ihnen darüber reden wird. Welche Definition gemeint ist, ist nicht immer aus dem Kontext ersichtlich.

Um eine Aufgabe zu erfüllen, brauchen Sie natürlich Unterstützung im ersten Sinne. Lieferantensupport hilft Ihnen bei der Lösung von Problemen und gibt dem Anbieter Feedback, welche Funktionen vorhanden sein müssen oder verbessert werden müssen. Viele Websites zahlen ein Vermögen für die Unterstützung des Anbieters, wenn sie über das interne Know-how verfügen, um auftretende Probleme schneller und sogar billiger als der Anbieter zu lösen. Ob Sie eine Verkäuferunterstützung kaufen, ist letztlich eine Geschäftsentscheidung, die Sie treffen müssen (oder das Management beraten).


Warum nicht ein direktes Upgrade durchführen?

Das ist was sagt Red Hat dazu?:

Red Hat unterstützt keine direkten Upgrades zwischen den Hauptversionen von Red Hat Enterprise Linux. Eine Hauptversion wird durch eine Versionsänderung ganzer Nummern gekennzeichnet. Zum Beispiel sind Red Hat Enterprise Linux 5 und Red Hat Enterprise Linux 6 beide Hauptversionen von Red Hat Enterprise Linux.

In-Place-Upgrades in den Hauptversionen behalten nicht alle Systemeinstellungen, Dienste oder benutzerdefinierten Konfigurationen bei. Aus diesem Grund empfiehlt Red Hat nachdrücklich Neuinstallationen, wenn Sie von einer Hauptversion auf eine andere aktualisieren.

Sie warnen weiter:

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

  • Einzelne Paketkonfigurationsdateien funktionieren möglicherweise nach einem Upgrade aufgrund von Änderungen in verschiedenen Konfigurationsdateiformaten oder Layouts nicht.
  • Wenn eines der Layer-Produkte von Red Hat (z. B. die Cluster Suite) installiert ist, muss es möglicherweise manuell aktualisiert werden, nachdem das Red Hat Enterprise Linux-Upgrade abgeschlossen wurde.
  • Anwendungen von Drittanbietern oder ISV funktionieren möglicherweise nicht ordnungsgemäß nach dem Upgrade.

Natürlich beschreiben sie dann, wie man ein In-Place-Upgrade über Methode 1 durchführt, nur für den Fall, dass Sie es wirklich tun wollen. Das Feature ist vorhanden und Red Hat setzt Entwicklungszeit in das System ein. Es wird daher unterstützt, dass das Feature vorhanden ist. Aber wenn etwas schief geht, wird Red Hat dir sagen, dass du neu installieren sollst; Sie bieten keine Unterstützung für Produkte, die durch das Upgrade beschädigt werden.

Zur Erinnerung, ich hatte noch nie ein Problem mit einem direkten Upgrade eines RHEL / CentOS- oder Fedora-Systems, das ich selbst nicht lösen konnte. Die typischen Probleme ergeben sich aus umbenannten Paketen, Repositorys von Drittanbietern und gelegentlichem Versionsunterschied zwischen den Architekturen i386 und x86_64 eines Pakets. Der Installateur ist ein bisschen besser im Umgang mit diesen als yum, Meiner Ansicht nach.


Wie sollte ich upgraden?

Ich warne die Leute generell davor, dass sie es tun sollten planen in einem Wartungsfenster alle 3-4 Jahre, um RHEL-Systeme von einer Hauptversion zur nächsten zu aktualisieren. Während Upgrades im Allgemeinen reibungslos ablaufen, kann das Unerwartete immer passieren.

Für beide Umgebungen erwarte ich, dass ein direktes Upgrade funktioniert. Ich empfehle jedoch dringend, es zuerst gründlich zu testen. P2V ein repräsentatives Beispiel der Server und durchlaufen Sie das In-Place-Upgrade auf den virtuellen Systemen, um zu sehen, auf welche Probleme Sie stoßen werden. Sie können dann das tatsächliche Produktions-Upgrade basierend auf besserem Wissen darüber, was passieren wird, planen.

Für einen großen Einsatz, wie Sie ihn hier haben, sollten Sie Limoncellis "Eins-zu-Viele-Ansatz" in Betracht ziehen. Aktualisieren Sie eine Maschine, sehen Sie, welche Probleme auftreten, lösen Sie sie, und nutzen Sie die beim Hochrüsten einer kleinen Charge gelernten Lektionen, wiederholen Sie die gelernte Sache, und wenn Sie glauben, dass Sie alle Knicke haben, aktualisieren Sie große Chargen von ihnen.

In einer solchen Situation empfehle ich auch, einen langen Blick auf den Anwendungsbereitstellungsprozess zu werfen. Wenn es nicht ausreichend automatisiert ist, dass Sie es mit einem einzigen Befehl starten können und ziemlich sicher sein können, dass die App korrekt bereitgestellt wird, müssen die Entwickler möglicherweise daran arbeiten. Ein solcher Bereitstellungsprozess würde es sehr viel einfacher machen, die neuere Version von EL neu zu installieren und dann darauf zu implementieren.


Wird das Umschalten von Distributionen helfen?

Debian-basierte Distributionen haben eine unterstützte In-Place-Upgrade-Methode, und es funktioniert meistens, aber es ist nicht immun gegen Probleme. Viele Dinge brachen für Menschen Upgrade von Ubuntu 10.04 LTS auf 12.04 LTS über die unterstützte Methode, zum Beispiel. Es ist nicht klar, dass Debian oder Canonical genügend Entwicklungszeit investieren, um diese Funktion "zu unterstützen", d. H. Sicherzustellen, dass sie funktioniert. Und Sie müssen tatsächlich Verkäuferunterstützung für diese Verteilung kaufen, wenn Sie möchten, dass jemand Ihre Hand hält. Ich bezweifle also, dass Sie durch den Wechsel zu einer solchen Distribution viel gewinnen werden.

Sie können gewinnen, indem Sie auf eine Rolling-Release-Distribution wie Gentoo oder Arch wechseln. Dies macht Sie jedoch auch nicht immun gegen Probleme; Es bedeutet lediglich, dass Sie die Aktualisierungsprobleme während der gesamten Lebensdauer des Servers (z. B. wann immer Sie oder die Entwickler beschließen, etwas auf dem System zu aktualisieren) kontinuierlich und nicht sofort bei einer gut geplanten Zeit für die Aktualisierung der Distribution behandeln. Sie haben auch keinen Anbieter, der Unterstützung bietet.


Was hält die Zukunft bereit?

Das Fedora-Projekt arbeitet an einem Tool zur Verbesserung von direkten Upgrades. Sie hatten ein Werkzeug namens preupgrade welches aufgegeben wurde und ersetzt durch ein neues Tool namens Fedup beginnend mit Fedora 18. Dies wurde zu RHEL7 und jetzt hinzugefügt In-Place-Upgrades haben volle Unterstützung, wenigstens von RHEL 6 bis RHEL 7. Aus eigener Erfahrung kann ich das sagen fedup hat immer noch ein paar KnickeEs entwickelt sich zu einem sehr nützlichen Werkzeug.

CentOS experimentiert auch mit ein Rolling-Release-Repository, aber es gilt nur zwischen Nebenversionen (z. B. 6.3-6.4).


41
2017-11-15 17:09



Das neue Fedora-Upgrade-Tool wird aufgerufen satt. Drei bis vier Jahre klingen für mich auch bei größeren Upgrades aggressiv. Ich muss feststellen, dass ich viel mehr in Richtung des mehr als zehnjährigen Lebenszyklus von RHEL sehe. Daher würde ich regelmäßig kleinere Upgrades empfehlen. - Dominic Cleal
Für Menschen, die ständig neue Funktionen benötigen, sind 3-4 Jahre fast zu lang. - Michael Hampton♦
Einfache Dinge wie PHP, Apache, Kernel-Revisionen und GLIBC ... Leute neigen dazu, diese Änderungen häufiger zu wollen. - ewwhite
Der Upgrade-Prozess von Debian / Ubuntu ist nicht perfekt, aber die Tatsache, dass es der bevorzugte Upgrade-Mechanismus ist und Red Hat keinen offiziell unterstützten Upgrade-Mechanismus hat, spricht für mich Volumen. - Paul Gear
Es ist nicht so wichtig, ob es In-Situ-Upgrades gibt, wie sie es offensichtlich tun, sondern ob die jeweiligen Anbieter sie unterstützen. - Michael Hampton♦


Meine Meinung zu deinem 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). Es wäre interessant, Vorschläge zu hören, wie das Konfigurationsmanagement genutzt werden kann, um Unternehmen dabei zu helfen, den RHEL-Hauptversions-Bump zu überwinden.

Ich denke, der wahre Wert von Konfigurationsmanagementsystemen, insbesondere im Kontext von Umgebung B, besteht darin, dass sie die Werkzeuge bereitstellen, um einen Dienst unabhängig von den Servern, auf denen er ausgeführt wird, zu erstellen. Wenn ein CMS nicht zum Erstellen der vorhandenen Dienste verwendet wurde, wird es wahrscheinlich nicht sehr hilfreich sein, die Dienste neu zu erstellen.

Ich weiß, dass dies Ihr unmittelbares Problem nicht löst, aber für mich kommt es darauf an, dass die Organisation eher in Bezug auf Server als auf Dienste denkt. Beim serviceorientierten Denken muss die Persönlichkeit einzelner Server nicht aufrechterhalten werden, solange der Dienst weiterhin funktioniert. Wenn ein CMS in einer disziplinierten Weise verwendet wird, um den gesamten Dienst aufzubauen, sollte die Verlagerung dieses Dienstes auf ein anderes System relativ einfach sein, da die gesamte Persönlichkeit der Maschine vom CMS erstellt wird.

P.S. Ich bin mir nicht ganz sicher, was in diesem Zusammenhang für die ifconfig-Ausgabe von Bedeutung ist - sie wird von einer Konfigurationsdatei und einigen Skripts erzeugt (andernfalls wäre sie beim Booten nicht vorhanden), und diese können bei Bedarf von einem CMS verwaltet werden.


5
2017-11-20 22:28



Sie haben Recht mit Dienstleistungen im Vergleich zu Servern im allgemeinen Sinne. Umgebung B verfügt über spezialisierte Serverhardware (10-GbE-NICs, Offload-Bibliotheken), die mit Upstream-Providern verbunden sind. Es ist etwas, das nicht ohne Ausfallzeiten Lasten ausgeglichen oder leicht verschoben werden kann. Ein Nicht-Finanzbeispiel wäre etwa ein Server, der als Controller für einige beteiligte Produktionsmaschinen angeschlossen ist. Sonderfall, eventuell mit dedizierten PCIe-Schnittstellenkarten. Sehr ein einmaliges Setup, einzigartig für den Server. In Puppet, sagst du einfach "Hier ist die Konfiguration für diesen einen Host / Rolle" und lebst damit? - ewwhite
Vereinbart, einige Dinge sind nicht einfach in allgemeine Fälle zu passen, besonders wenn Sie eine Umgebung mit bestimmten Hardwareanforderungen haben. Mit der Puppe macht es so viel Sinn wie möglich in die Rolle zu drücken. Aber am Ende muss es funktionieren, wenn etwas nicht ganz Elegantes funktioniert, dann lebe ich damit, dass es unelegant ist. Meistens müssen wir mit uneleganten Dingen leben, nur weil wir nicht die Zeit haben, sie "richtig" zu machen. - Paul Gear