Enterprise-Linux: Red-Hat-Alternativen im Vergleich

Wenn es um Linux auf Enterprise-Servern geht, fallen in der Regel zwei Namen: Red Hat und Suse. Die beiden Distributionen erheben den Anspruch, für den Einsatz auf unternehmenskritischen Servern geeignet zu sein und bei entsprechender Konfiguration Hochverfügbarkeit zu gewährleisten.

Während in Deutschland oft auch Suse Linux Enterprise Server (SLES) zum Einsatz kommt, dominiert in anderen Ländern eindeutig Red Hat Enterprise Linux (RHEL). Letzteres entwickelt sich mehr und mehr zum Standard-Linux im Serverumfeld. Das zeigt sich zum Beispiel darin, dass zahlreiche Closed-Source-Anwendungen vor allem für Red Hat Linux verfügbar sind.

Bei Closed-Source-Anwendungen, die nur als Binaries vertrieben werden, ist es wichtig, ein Standard-Linux zu haben. Zwischen den einzelnen Distributionen gibt es zahlreiche Unterschiede in den Libraries, so dass etwa eine Binärdatei für Ubuntu 11.10 meist nicht auf Fedora 15 läuft.

Natürlich kann man auch das in den Griff kriegen, indem alle benötigten Bibliotheken in die ausführbare Datei mit hineingelinkt werden. Das ist aber wenig sinnvoll, da die Programme dadurch anwachsen und viel mehr Hauptspeicher benötigen. Standard-Routinen, etwa zur Anzeige von JPG-Bildern oder SSL-Verschlüsselung, wären dann im RAM mehrfach vorhanden.

Solche monolithischen Binärdateien, die alle Libraries enthalten, sind indes keine Seltenheit. Wer sich etwa Chrome beziehungsweise Chromium oder Firefox direkt von den Herstellern Google und Mozilla herunterlädt, bekommt solche monolithischen Versionen mit hohem Speicherverbrauch. Verwendet man die Anpassungen aus der Distribution, bekommt man, wenn der Distributionshersteller seine Sache gut gemacht hat, viel kleinere ausführbare Dateien, die Bibliotheken nutzen.

Bei Windows und Mac OS sind diese Probleme weitgehend unbekannt. Beide OS werden nur von einem Hersteller vertrieben und es gibt nicht Hunderte von Distributionen. Ferner ist das Treibermodell besser. Ein Treiber für Windows 2000 kann theoretisch durchaus auch in der Windows-8-Beta noch seinen Dienst verrichten. Bei Linux ist das jedoch wegen der absoluten Einsprungadressen technisch unmöglich. Das Höchste der Gefühle ist eine Objekt-Datei, die gegen die jeweiligen Kernel-Libraries gelinkt werden kann. Es gilt der Grundsatz: neuer Kernel, neue Treiber.

Allerdings ist Red Hat Enterprise Linux nicht kostenlos: Für ein 2P-System (Board mit zwei CPU-Sockeln) müssen Kunden in Red Hats Onlineshop 349 Dollar (etwa 270 Euro) pro Jahr ausgeben. Für ein 4P-System werden 1598 Dollar (etwa 1230 Euro) fällig. Darin enthalten sind nur Software-Updates, zum Beispiel Security Fixes, aber kein weiterer Support durch Red Hat. Das kostet extra.

Für Kunden bieten sich dennoch kostenlose Alternativen. Die bekannteste ist CentOS. Die Linux-Distribution erhebt den Anspruch, 100 Prozent kompatibel zu sein. Sogar binäre Treiber für RHEL lassen sich unter CentOS installieren. Support gibt es für CentOS dagegen nur durch die Community, beispielsweise in Foren.

Benutzer, die bisher wenig Erfahrung mit Enterprise-Server-Linux-Varianten haben, seien an dieser Stelle kurz darauf hingewiesen, dass diese vor allem auf Stabilität ausgerichtet sind – und zwar auf Kosten der Aktualität. Es werden in der Regel Pakete verwendet, die nicht auf dem neuesten Stand sind, aber dafür stetig verbessert werden, um Instabilitäten und Memory-Leaks zu vermeiden. Die Unterstützung neuester Hardware wird meist durch Backports erreicht.

Wer auf seinem Desktop-System ein "echtes Enterprise-Linux" installieren möchte und jetzt mit CentOS eine Alternative zu Ubuntu oder Fedora sieht, wird eventuell enttäuscht sein, weil er beispielsweise Firefox in der hoffnungslos veralteten Version 3.6 vorfindet. Viele Pakete sind sogar deutlich älter als in Debian Stable, das auch nicht die neuesten Versionen verwendet.

Einen Red-Hat-Clone erkennt man nur an Kleinigkeiten, zum Beispiel am dezenten Oracle-Schriftzug links oben im Tux-Symbol oder den voreingestellten Links in Firefox (Screenshot: ZDNet).

Einen anderen Ansatz als CentOS verfolgt Oracle: Auch Oracle gibt ein Red-Hat-kompatibles Linux kostenlos heraus. Das mag zunächst verwundern, da Oracle und sein Chef Larry Ellison nicht gerade dafür bekannt sind, Softwarelizenzen aus reiner Philantropie gratis zu verteilen. Beim genauen Hinsehen erkennt man aber, dass Oracle Enterprise Linux (OEL) lizenztechnisch eine Mogelpackung ist.

Nach einer Registrierung auf der Website sind Download und Nutzung zwar kostenlos, aber Benutzer erhalten keine Software-Updates, nicht einmal Security-Fixes. Der kostenlose Produktiveinsatz ist zwar theoretisch möglich, doch faktisch lässt sich er sich sicherheitstechnisch nicht vertreten.

So bietet Oracle einen "Public Yum Server" mit den Paketen aus OEL an. Er dient aber nur dazu, zusätzliche Pakete zu installieren, wenn man das Installationsmedium nicht zur Hand hat. Der Server wird nicht mit Updates gepflegt. Der Datenbankspezialist lässt zwar immer wieder verlautbaren, dass es sich um ein kostenloses Enterprise Linux handelt, erntet in Kommentaren dafür aber zu Recht nur Hohn und Spott.

Updates gibt es nur bei CentOS. Bei Oracle bleibt dieser Dialog leer (Screenshot: ZDNet).

Wer Updates beziehen möchte, muss Support kaufen. Das kostet mindestens 119 Dollar (etwa 90 Euro) pro Jahr. Damit ist das Basispaket, das nur Updates beinhaltet, deutlich günstiger als Red Hat. Die Kosten für weiteren Support durch Oracle lassen sich der Preisleiste (PDF) entnehmen. Sie liegen in etwa gleichauf mit denen von Red Hat.

Wie ein Red-Hat-Clone rechtlich möglich ist

Vollkompatible Red-Hat-Clones sind möglich, da die GNU Public License (GPL) vorschreibt, dass man ein unter der GPL stehendes Produkt im Source-Code veröffentlichen muss. Das gilt auch für abgeleitete Produkte, wenn man etwa Erweiterungen und Veränderungen vorgenommen hat.

Die Red-Hat-Clone-Hersteller, die neben Oracle und CentOS auch weniger bekannte Distributionen wie Scientific Linux, Fermi Linux und Yellow Dog Linux umfassen, holen sich die Source-Pakete (SRPMs) vom Red-Hat-Server, tauschen Texte, Bitmaps und Logos aus und kompilieren die Pakete neu. So entstehen vollkompatible Clones.

Das ist einfacher gesagt als getan: Insbesondere beim Kernel muss darauf geachtet werden, dass alle Einsprungadressen an der selben Stelle liegen. Es ist daher wichtig, dass alles mit exakt derselben Version des gcc-Compiler und denselben Compiler-Optionen kompiliert wird. Dabei ist Unterstützung durch Red Hat nicht zu erwarten.

Wenn ein neues Major-Release von Red Hat herauskommt, kann es durchaus eine Zeit dauern, bis die Clone-Hersteller mit ihren Versionen so weit sind. RHEL 6 wurde im November 2010 veröffentlicht. Oracle gab seinen Nachbau OEL 6 allerdings erst im Februar 2011 frei. Das von ehrenamtlichen Entwicklern hergestellte CentOS 6 erschien im Juli 2011, also acht Monate nach dem Original.

Anders ist das meist bei einem Minor-Release: RHEL 6.2 erschien am 7. Dezember 2011. Bereits am 15. Dezember konnten sowohl CentOS als auch Oracle mit der Version 6.2 nachziehen. Beide Clone-Hersteller benötigten nur eine gute Woche.

Besonderheiten von Oracle Linux: Kernel Patches ohne Reboot

Während CentOS sich damit zufriedengibt, einfach einen kostenlosen RHEL-Clone zu schaffen, hat Oracle einige Erweiterungen vorgenommen. Dies betrifft insbesondere den Kernel. OEL kommt mit zwei verschiedenen Kerneln: einem Red-Hat-kompatiblen Kernel und dem sogenannten "Unbreakable Enterprise Kernel" (UEK).

Wenn man den UEK einsetzt, verliert man die Binärkompatibilität bei Treibern. Die Binärkompatibilität von User-Mode-Prozessen bleibt jedoch erhalten. Das Attribut "unbreakable" zeigt, worauf Oracle aus ist. Die Stabilität soll gegenüber Red Hat noch einmal verbessert sein. Man sollte aber beachten, dass viele Programme intensiv gegen den Red-Hat-Kernel getestet sind. Im Zweifel geht man mit dem Red-Hat-kompatiblen Kernel auf Nummer Sicher.

Allerdings hat Oracle durchaus einige Features in den UEK eingebaut, die für Enterprise-Kunden interessant sind: Die Reliable Datagram Sockets (RDS) erreichen eine höhere Performance in schnellen Netzen mit geringer Latenz, was etwa in der Kommunikation mit Storage-Systemen Vorteile bringt. Die Netzwerk Performance soll insgesamt höher sein, da "Receive Steering" eingebaut wurde. So kann der Client einen Server bremsen, wenn er die Daten schneller anliefert, als der Client sie verarbeiten kann. Außerdem sei der asynchrone I/O verbessert und eine bessere Optimierung für SSDs vorhanden.

Das innovativste Element im UEK ist allerdings die Unterstützung von Ksplice. Dabei handelt es sich um eine Technologie, die es erlaubt, Updates in den Kernel und die Treiber einzuspielen, ohne dass dazu ein Reboot erforderlich ist.

Windows-User wissen, dass außer dem "Definition Update for Windows Defender" nahezu jedes Update ein Reboot erfordert. Für Desktop-User ist das nur ärgerlich, im Serverbereich bedeutet es jedoch immer eine Dienstunterbrechung. Viele Viren, etwa Conficker, konnten sich insbesondere in Unternehmen und Behörden ausbreiten, obwohl Microsoft schon ein halbes Jahr vor Ausbruch der Epidemie einen Patch bereitgestellt hatte. Admins verzichten oft auf Updates, weil dafür ein Reboot erforderlich ist. Es handelt sich um ein Design-Problem in Windows. In Benutzung befindliche Dateien, beispielsweise DLLs, lassen sich nicht austauschen.

Bei Unix-Systemen ist das grundsätzlich anders. Man kann jede Datei jederzeit "löschen" und durch eine neue Version austauschen. Dabei wird die alte Datei aber nicht wirklich gelöscht, sondern nur in Verzeichnis "geunlinkt" und verbleibt im System bis der letzte Prozess sie geschlossen hat. Bei einem Update müssen manche Serverdienste neu gestartet werden, was meist nur wenige Sekunden Dienstunterbrechung bedeutet.

Anders ist das bei Kernel-Dateien, sprich dem Kernel selbst und Modulen (.ko-Dateien): Auch sie können ausgetauscht werden. Allerdings werden sie immer komplett in den Hauptspeicher geladen. Ein Austausch der Datei bedeutet nicht, dass die neuen Dateien auch verwendet werden.

Ksplice sorgt dafür, dass die Kernel-Patches unmittelbar in den Hauptspeicher geladen werden. Damit lässt sich ein Linux-System schaffen, das theoretisch niemals neu gestartet werden muss.

Ursprünglich war Ksplice ein Open-Source-Projekt. Allerdings wurde Ksplice von Oracle übernommen und ist seitdem Closed Source. Oracle strich die Unterstützung für SLES und RHEL. Es ist jetzt nur noch kostenpflichtig für Oracle Linux sowie kostenlos für Fedora und Ubuntu verfügbar. Oracle-Linux-Kunden, die einen Premier-Vertrag haben, können Ksplice ebenfalls kostenlos nutzen.

Für die Bereitstellung von Enterprise-Diensten ist Ksplice durchaus ein Argument. Das gilt jedenfalls für Kunden, die der noch recht jungen Technologie ihr Vertrauen schenken.

Kompatibilität und Benchmarks

CentOS macht keinen Hehl daraus, dass der Red-Hat-Clone nicht absolut identisch mit dem Original ist. Auf der Homepage heißt es, man "strebe hundertprozentige Binärkompatibilität an". Für Enterprise-Kunden ist es jedoch nicht relevant, dass ein Dienst startet und etwa eine Woche oder einen Monat problemlos läuft. Er muss das auch nach mehreren Monaten ohne Reboot immer noch tun. Das kann aber niemand garantieren. Es bleibt immer ein kleines Restrisiko, wenn man einen Red-Hat-Clone einsetzt, egal ob CentOS oder OEL.

Unterschiede zeigen sich auch in der Performance: ZDNet führt dazu die offiziellen Benchmarks von Apache (ab) und MySQL (sql-bench) durch. Als Hardware kommt ein Desktop-System mit Core i7-920 zum Einsatz. Der Hauptspeicher beträgt 3 GByte. Als Festplatte dient die mechanische Western-Digital-Platte WD2500YS mit 250 GByte.

Den Apache-Benchmark führt ZDNet mit der offiziellen Testseite durch (Screenshot: ZDNet).

Beim Apache-Benchmark wird 100.000 Mal die offizielle Testseite des Apache-Servers über das lokale Interface 127.0.0.1 geladen. Dabei werden 100 Requests gleichzeitig gestellt. Bei einer Testreihe von 30 Benchmarks wird das beste Ergebnis verwendet. So kann man Zufalls-Effekte wie Garbage-Collection ausblenden. CentOS schafft dabei einen Durchsatz von 53.843 KByte/s. Oracle Linux kommt mit dem Red-Hat-Kernel nur auf 40.184 KByte/s und sogar nur auf 37.049 KByte/s mit dem UEK.

Auf den ersten Blick sieht es so aus, dass CentOS deutlich besser abschneidet und unter Oracle Linux der Unbreakable Enterprise Kernel zu einer Verlangsamung führt. Eine differenzierte Betrachtung kommt aber zu einem anderem Ergebnis: Beim Red-Hat-Kernel kommt es in beiden OS zu deutlichen Ausreißern nach unten in der Messreihe. Das schlechteste Ergebnis liegt mit Oracle Linux bei 5165 KByte/s, mit CentOS bei 9189 KBytes/s.

Solche Ausreißer gibt es beim UEK nicht. Kein Wert lag unterhalb von 30.000 KByte/s. Der UEK liefert geringere Spitzenwerte, zeigt aber keine Ausreißer. Die Varianz der Latenzzeiten für eine Apache-Transaktion ist viel geringer. Das Verhalten ist vorhersehbarer. Wenn Quality-of-Service gefragt ist, kann der UEK Vorteile bieten.

Der Standard MySQL-Benchmark führt verschiedene Transaktionen wie Create, Insert und Select durch. Es wurde das Standard-Skript run-all-tests verwendet, ohne die Default-Parameter zu verändern. Gemessen wurde nur die CPU-Zeit, da das Dateisystem-Layout trotz identischer Installationsprozedur unter CentOS und Oracle-Linux sehr unterschiedlich ist. Die dadurch resultierenden Unterschiede bei den Zugriffszeiten machen einen Vergleich der Gesamtzeit (CPU und Festplatten-I/O) unmöglich.

Bei diesem Test ist CentOS langsamer als Oracle Linux. CentOS benötigte 314,04 Sekunden. Oracle Linux schafft den Benchmark mit Red-Hat-Kernel in 244,37 Sekunden und mit UEK in 288,23 Sekunden.

Eine generelle Aussage, ob CentOS oder Oracle schneller ist, lässt sich nicht treffen. Zu ähnlichen Ergebnissen kommen auch andere Benchmarks, etwa von Phoronix. Die Messungen zeigen nur, dass es durchaus erhebliche Unterschiede gibt, je nachdem welchen Red-Hat-Clone man einsetzt. Welches OS im jeweiligen Anwendungsfall die höhere Performance liefert, muss einzeln getestet werden.

Fazit

Ob und welchen Red-Hat-Clone man einsetzen soll, hängt von vielen Faktoren ab. Wer glaubt, dass er keinen Support durch einen Hersteller brauche, ist sicherlich mit CentOS am besten bedient.

Der Vergleich von ZDNet zeigt, dass die Clones keineswegs zu 100 Prozent identisch sind, sonst dürften keine Unterschiede in der Performance auftreten. In Wahrheit sind die Clones aber nur binärkompatibel. Es ist zu bedenken, dass Anwendungen, die man betreiben möchte, meist gegen das Original-RHEL auf Stabilität getestet sind. Für Kunden, die ihre Server über Monate ohne Reboot betreiben möchten, kann ein Clone Probleme aufwerfen.

Im Einzelfall kann es aber auch sein, dass ein Softwarehersteller, der Binaries für Red Hat liefert, seine Software aus Kostengründen auf CentOS entwickelt und testet. Man kann beim Hersteller natürlich nachfragen, ob man aber eine ehrliche Antwort bekommt, steht in den Sternen.

Wer Oracle-Anwendungen, etwa die Oracle-Datenbank oder Oracle Financials betreiben möchte, für den kann es durchaus eine Überlegung sein, Oracle Linux einzusetzen und den Support aus einer Hand zu kaufen. So können sich Red Hat und Oracle bei Problemen nicht gegenseitig den Schwarzen Peter in die Schuhe schieben.

In jedem Fall ist eine Abwägung der Vor- und Nachteile sinnvoll. Einen Red-Hat-Clone vor vornherein abzulehnen, ist sicherlich die falsche Strategie.