Laufzeiten und Produktionsbetrieb von Linux-Distributionen
Mein Kommentar zur Episode Newsupdate 07/23 vom Focus on: Linux-Podcast ist etwas länger geworden, aus diesem Grund habe ich das in einen Blogartikel verpackt.
Prima Episode. Leider muss ich ein wenig Erbsen zählen.
Eine Distribution wird nicht über die komplette Laufzeit (im Podcast war die Sprache von zehn Jahren) produktiv eingesetzt.
Wenn wir uns mal einen mittelprächtig konservativen Ansatz anschauen, dann beginnt man mit dem Testen einer Linuxdistribution ein halbes Jahr nach dem Erscheinen.
Man bringt erste Workloads (Development- und Test-Systeme) darauf, wenn das gut läuft, folgt irgendwann die Abnahmeumgebung und zum Schluss die Produktion. Wenn es gut läuft, sind wir ein Jahr nach dem Erscheinen der Distribution produktiv. Ich habe deutlich progressivere Vorgehensweisen in meiner Berufslaufbahn erlebt, aber deutlich konservativere.
Das oben genannte ist im übrigen der Grund, weshalb es Distributionen mit kurzer Supportzeit gar nicht erst in viele Unternehmen schaffen.
Weil wir Warmduscher sind, wollen wir wenigstens ein Jahr Support übrig haben, wenn wir auf ein neues Release gehen, das bedeutet insbesondere, dass wir 18 Monate vor Supportende mit dem Testen beginnen und das Nachfolgrelease muss dann wenigstens ein halbes Jahr alt sein. Wir können so immer noch zurück, wenn in der Produktion etwas schieflaufen sollte.
In Summe bedeutet das, dass nur acht von zehn Jahren produktiv genutzt werden.
Daten von endoflife.date:
Beispiel Red Hat Enterprise Linux (RHEL):
- RHEL 7 erscheint Dezember 2013, Laufzeit bis Juni 2024
- Wir testen ab Juni 2014
- Produktion ab Dezember 2014
- Testen Nachfolgerelease ab Dezember 2022
- Produktion auf dem Nachfolgerelease ab Juni 2023
Wenn wir den Sprung auf RHEL 9 wagen, dann sind wir wieder rund 7,5 Jahre dabei. Glücklicherweise ist RHEL 9 genau passend erschienen. Zufall?
Das gleiche Verfahren mit RHEL 6:
- RHEL 6 erscheint November 2010, Laufzeit bis November 2020
- Produktion ab November 2011
- Testen Nachfolgerelease ab Mai 2019
- Produktion auf dem Nachfolgerelease ab November 2019
Mai 2019 ist zu früh für RHEL 8, das heisst, wir müssen im November 2019 auf RHEL 7 migrieren und hätten dann nur 4,5 Jahre Laufzeit (bis Juni 2024).
Wenn man sich das einmal so anschaut, ist es nicht mehr "Zehn Jahre Laufzeit müssen für alle reichen ...".
Trackbacks
Keine Trackbacks
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
MattG am :
Ja 10 Jahre...auf dem "Papier" aber in reality, siehts anders aus und man kommt eigentlich recht zügig wieder unter Druck.
Dirk Deimeke am :
Christoph am :
Dirk Deimeke am :
Christian Stankowic am :
Vielen Dank für euren wertvollen Input - so haben wir es in unserem Gespräch tatsächlich nicht betrachtet. Man muss auch dazu sagen, dass wir meist nur am Anfang solcher Umstellungen dabei sind. Die letzte Migration als interner Administrator hatte ich damals von EL5 nach EL6 betreut.
Nur so interessehalber: wie steht ihr zu den erweiterten Laufzeiten? SLES und RHEL bieten ja beide gegen Extramünze bis zu 13 Jahre Support an. Habt ihr das jemals gebraucht? Ist mir in meiner bisherigen Laufzeit noch nie untergekommen.
Beste Grüße,
Christian.
Jörg am :
Dass 10 Jahre Support für viele Unternehmen für einen Releasewechsel immer noch zu kurz sind, sieht man aktuell gut bei RHEL 7. Auf Wunsch (Druck) vieler Kunden wird es 4 Jahre ELS-Support für RHEL 7 inkl. High-Availability- und Resillient-Storage-Add-on geben.
Viele Grüße
Jörg
Dirk Deimeke am :
Dirk Deimeke am :
Wenn man sich den Lifecycle eines RHEL-Systems anguckt, dann gibt es ja auch "nur" fünf Jahre Full Support, danach "nur noch" Maintenance. Das ist bei anderen Distributionen ähnlich.
Letzten Endes ist das mit ein Grund dafür, dass Container so einen Siegeszug angetreten haben. (Was einen nachdenklich stimmen sollte, wenn man sich die Sicherheit von Containern überlegt).
MattG am :
Blöd ist nur wenn noch CentOS7, dann müsste man sie erst zu "echten" RHEL's machen und dann noch teuer den Extended einkaufen
Jörg am :
Ich würde jedoch empfehlen, die Anwendungen direkt auf RHEL 8 oder 9 neu zu deployen. In meinen Augen ist das sauberer und mit weniger Aufwand verbunden, als erst zu konvertieren und dann ein In-Place Upgrade zu machen.
Ohne es getestet zu haben, bekomme ich Gänsehaut bei dem Gedanken.
okraits am :
Es soll ja auch Firmen geben, welche Debian einsetzen. Dort erscheint in der Regel alle 2 Jahre ein neues Release. Wir versuchen schon, innerhalb des ersten halben Jahres nach dem Release auf diese Version zu migrieren. Sehr viel länger sollte man sich auch nicht Zeit lassen, sonst hat man nicht viel von dem Release, es sei denn, man nutzt den Zeitraum als oldstable voll aus.
Dirk Deimeke am :
Vielleicht spielte auch eine Rolle, dass Ubuntu mit LTS Support für fünf Jahre geboten hat.
Am Ende ist es eine wirtschaftliche Entscheidung. Wenn Du viele Server und kurze Supportzeiträume hast, ist ein Team fast ausschliesslich mit Migrationen beschäftigt.
Die grösste Anzahl von Systemen, für die ich (mit)verantwortlich war, waren 1800, mit einigen hundert Applikationen, die alle einzeln getestet werden müssen bei einer Migration.
Aber, ich gebe Dir recht, lange Supportzeiträume haben einen Preis. Ich verweise dazu einmal auf einen älteren Artikel bei mir.
okraits am :
Auf der anderen Seite möchte man als Applikationsentwickler natürlich aktuelle Technologien (sprich Pakete, z.B. eine aktuelle Python-Version) zur Verfügung haben, um vorne dabei zu sein in punkto Features, Performance und auch Security Fixes.
Da sieht es dann bei Distris mit langem Supportzeitraum nicht so gut aus. Deshalb behelfen sich die Leute dann z.B. auch mit Technologien wie virtuellen Environments, Containern und dem nix-Paketmanager.
Dirk Deimeke am :
Heute brauchst Du eine stabile Basis, auf der sich die Entwickler "austoben" können.
Die Frage und die Philosophie sind, wie weit man damit gehen will. Wenn ich alles aus den Paketquellen bereitstellen muss, muss ich zwangsweise sehr aktuelle Distributionen nehmen, aber sie sollten auch nicht zu weit von der späteren Produktion entfernt sein.
Aus diesem Grund bin ich ein grosser Fan davon, dass die Developmentsysteme die gleiche Laufzeitumgebung bieten wie die spätere Produktion.
okraits am :