CERN migriert über 2.200 Beschleunigersteuerungsrechner von RHEL auf Debian 13

CERN, die Europäische Organisation für Kernforschung, galt jahrzehntelang als eine der bekanntesten Red-Hat-Institutionen im wissenschaftlichen Rechnen. Nun stellt die Organisation einen zentralen Teil ihrer Infrastruktur um: Bis Ende 2026 sollen mehr als 2.200 industrielle Rechner und eingebettete Systeme der Beschleunigersteuerung von RHEL-basierten Systemen auf Debian 13 wechseln. Der Auslöser ist auffällig konkret und technisch, nicht etwa eine allgemeine Lizenzkostendebatte, sondern ein einzelner Compiler-Standard.

Was ist passiert?

Auf der MiniDebConf im schweizerischen Winterthur stellten die CERN-Ingenieure Federico Vaga und Nikos Tsipinakis die laufende Migration der Beschleunigersteuerung auf Debian 13 vor. Der Vortrag wurde unter anderem von Phoronix aufgegriffen und dokumentiert eine Zahl, die im wissenschaftlichen Linux-Umfeld aufhorchen lässt: CERN co-maintainte einst gemeinsam mit anderen Forschungseinrichtungen Scientific Linux, eine RHEL-Distribution, wechselte 2015 zu CentOS und lief danach über AlmaLinux weiter auf dem Red-Hat-Pfad. Diese über zehn Jahre gewachsene Kontinuität wird nun für einen wesentlichen Teilbereich beendet.

Wichtig ist die Abgrenzung: Es handelt sich nicht um eine vollständige Abkehr von Red Hat. CERN hat nach Presseberichten klargestellt, dass sich die Umstellung ausschließlich auf die industriellen Beschleunigersteuerungsrechner bezieht. Rechenzentren und das experimentelle Computing, also die Systeme rund um die Datenauswertung der Detektoren, bleiben auf RHEL und AlmaLinux.

Warum der Wechsel? Ein Compiler-Flag als Auslöser

Der nach Aussage der Referenten entscheidende Punkt war nicht Softwarepolitik im klassischen Sinn, sondern eine technische Grundsatzentscheidung von Red Hat: Ab RHEL 9 gilt für den Compiler-Baseline-Standard -march=x86-64-v2, RHEL 10 hebt die Anforderung weiter auf x86-64-v3 an. Diese Microarchitecture-Level definieren, welchen Befehlssatz ein Build minimal voraussetzen darf. Level v1 ist die ursprüngliche 64-Bit-Basis, v2 verlangt unter anderem SSE4.2 und POPCNT, was in der Praxis Prozessoren ab etwa Nehalem-Generation voraussetzt, v3 verlangt zusätzlich AVX2, BMI und FMA.

Für Desktop- oder Server-Flotten mit regelmäßigem Hardware-Refresh ist das ein überschaubares Problem. Für eine Beschleunigeranlage mit rund 43 Quadratkilometern Tunneln, Oberflächengebäuden und Anlagenhallen, in der Steuerungshardware nach Angaben der Referenten oft für 15 Jahre und länger im Betrieb bleibt, ist es das nicht. Systeme, die seit über einem Jahrzehnt zuverlässig laufen, verlieren durch die höhere Compiler-Baseline schlicht die Möglichkeit, künftige RHEL-Pakete auszuführen, unabhängig davon, ob die Hardware für ihre eigentliche Aufgabe weiterhin geeignet ist. Die CERN-Ingenieure bezeichneten das in ihrem Vortrag als erzwungene Obsoleszenz. Debian baut seinen amd64-Port dagegen weiterhin gegen die ursprüngliche x86-64-Baseline, ältere Hardware bleibt damit unterstützt.

Zahlen und Umfang der Migration

Der Umfang der Umstellung macht deutlich, dass es sich nicht um ein Pilotprojekt handelt. Folgende Eckdaten wurden im Vortrag beziehungsweise in der Berichterstattung genannt:

Kennzahl	Angabe
Zu migrierende Systeme	mehr als 2.200 industrielle Rechner und eingebettete Systeme
Angesteuerte Geräte insgesamt	rund 17.000
Zielplattform	Debian 13 (Trixie)
Geplanter Abschluss	Ende 2026
Vorherige Plattformen	Scientific Linux, CentOS (ab 2015), zuletzt RHEL/AlmaLinux
Ausgenommene Bereiche	Rechenzentren und experimentelles Computing, bleiben auf RHEL/AlmaLinux
Geografische Ausdehnung der Anlage	rund 43 Quadratkilometer Tunnel- und Anlagenfläche

Die Diskrepanz zwischen der über zehn Jahre gewachsenen Red-Hat-Historie von CERN und der jetzt binnen weniger Jahre geplanten Umstellung auf über 2.200 Systemen zeigt, wie stark ein einzelner Plattformentscheid in tief eingebetteter Infrastruktur nachwirken kann.

Herausforderungen bei der Debian-Einführung

Der Vortrag war ausdrücklich kein reiner Erfolgsbericht. Vaga und Tsipinakis benannten offen mehrere technische Lücken, auf die das Team bei der Umstellung gestoßen ist:

• Debian bietet keine ausreichenden Standardwerkzeuge für automatisiertes Bauen und Veröffentlichen eigener Pakete im benötigten Maßstab.
• Mehrere gängige Debian-Tools unterstützen es nicht sauber, wenn mehrere Versionen desselben Pakets parallel gepflegt werden müssen.
• CERN betreibt über Jahrzehnte hinweg mehrere Generationen an Steuerungssoftware gleichzeitig, was die fehlende Multi-Versions-Unterstützung besonders spürbar macht.
• Ein Wechsel auf CentOS Stream wurde als nähergelegener Weg erwogen, letztlich aber verworfen.
• Die Umstellung betrifft heterogene, teils sehr alte eingebettete Hardware, die individuell geprüft und qualifiziert werden muss.
• Für ein derart großes und sicherheitskritisches industrielles Umfeld mussten Build- und Release-Prozesse teilweise neu aufgebaut werden, statt vorhandene Werkzeuge einfach zu übernehmen.

Diese Punkte sind für Administratoren in Unternehmen mit eigener Paketverwaltung oder mit langlebiger Embedded-Hardware durchaus lehrreich: Auch außerhalb eines Forschungslabors kann eine Distributionsentscheidung durch fehlende Tooling-Reife in bestimmten Nischen komplizierter werden als durch die Betriebssystemwahl selbst.

Einordnung: Was bedeutet das für Admins und Unternehmen?

Für die meisten kleinen und mittleren Unternehmen ist der CERN-Fall kein akutes Handlungssignal, aber ein aufschlussreiches Beispiel für eine Entscheidung, die viele Betreiber langlebiger Infrastruktur in ähnlicher Form treffen müssen. Wer produktive Systeme mit sehr langen Lebenszyklen betreibt, etwa Steuerungsrechner, Embedded-Gateways oder ältere Server-Hardware, sollte die eigenen Distributionsanforderungen an Prozessor-Befehlssätze im Blick behalten. Steigt eine Distribution ihre Compiler-Baseline an, kann das faktisch zur erzwungenen Ausmusterung funktionsfähiger Hardware führen, selbst wenn keine Sicherheitslücke oder Supportende vorliegt.

Für Admins, die selbst Debian- oder Ubuntu-Systeme betreiben, ist der Fall zusätzlich ein Anlass, den eigenen Patch- und Update-Prozess robust zu halten, etwa über automatisierte Sicherheitsupdates, und die eigene Paketverwaltung sauber zu dokumentieren. Wer aktuell noch Debian 11 im Einsatz hat, sollte zudem das nahende Support-Ende im Blick behalten, da ältere Debian-Versionen ebenfalls in absehbarer Zeit ohne Sicherheitsupdates dastehen.

• Eigene Hardware-Inventarisierung prüfen: Welche Systeme sind älter als die neue Compiler-Baseline der eingesetzten Distribution voraussetzt?
• Vor größeren Distributions-Upgrades die Release Notes gezielt auf geänderte Build-Baselines und Mindestanforderungen prüfen.
• Bei eigenen Paket-Builds frühzeitig testen, ob benötigte Tools mehrere Paketversionen parallel sauber unterstützen.
• Langlebige Steuerungs- oder Embedded-Systeme getrennt von allgemeiner Server- und Client-Infrastruktur betrachten, da hier andere Update-Zyklen sinnvoll sein können.

Passende Anleitungen auf S-EDV

• Debian 11 Bullseye: Support endet am 31. August 2026, wichtiger Hintergrund für alle, die noch ältere Debian-Systeme im Einsatz haben und einen Umstiegsplan brauchen.
• Pakete verwalten mit apt und dpkg unter Debian und Ubuntu, Grundlagenwissen zur Paketverwaltung, relevant für alle, die eigene Debian-Umgebungen pflegen.
• Unattended Upgrades: Automatische Sicherheitsupdates unter Debian und Ubuntu, praktische Anleitung, um Debian-Systeme dauerhaft aktuell zu halten.

Quellen

• Phoronix: CERN Transitioning Industrial Computers To Debian After Being A Longtime RHEL Institution
• Hardware Busters: CERN's Debian Migration Moves 2,200 Accelerator Control Machines Off Red Hat
• MiniDebConf Winterthur, Vortrag von Federico Vaga und Nikos Tsipinakis (Primärmaterial, verlinkt über Phoronix)