© Gunter Nezhoda, 123RF

Seit 10. Juni schickt Red Hat eine neue Major-Release seiner hauseigenen Enterprise-Distribution auf die Piste: RHEL 7. Das Linux-Magazin schaut, welchen Kurs das Produkt einschlägt.

Wer sich derzeit das Treiben der Linux-Hersteller im Enterprise-Umfeld ansieht, dem kommt schnell das Bild vom Elefantenrennen auf der Autobahn in den Kopf: Zentimeter um Zentimeter schieben sich Ubuntu, Red Hat und Suse aneinander vorbei, jeder versucht seine Position am Markt durch neue Major-Versionen der jeweiligen Enterprise-Systeme zu zementieren. Große Fortschritte, ja gar Sprünge oder rasante Überholmanöver sind da nicht zu erwarten, will doch jeder der Marktteilnehmer Solidität und Leistungsfähigkeit durch Ausdauer und Konstanz beweisen.

Enterprise-Distributionen sind ohnehin ein Kuriosum in der sonst eher schnelllebigen FLOSS-Welt. Der Deal ist einfach: Canonical, Red Hat und Suse werfen ein Produkt auf den Markt und gehen zugleich die Verpflichtung ein, dieses Produkt über einen Zeitraum von mindestens x Jahren zu warten. Admins können also in langen Wartungszyklen von fünf Jahren und mehr denken und haben nicht alle zwei Jahre ein Major-Update vor sich, sogar Langzeitsupport gibt es gegen teures Geld [1].

Oberste Maxime: Stabilität!

Im Gegensatz zu den Desktop-Distributionen konzentrieren sich die Enterprise-Varianten vorrangig auf Stabilität. Red Hat und Suse haben in Form von Fedora und Open Suse ihr eigenes Versuchslabor, in dem sie Features testen, bevor diese ihren Weg in das Enterprise-Produkt der Firma finden.

Das legt auch die Latte für Bugs höher: Weil RHEL, SLES & Co. einer deutlich stärkeren Kontrolle unterliegen, bringt jedes Update mehr Arbeit als bei den Community-Distributionen. Und so weigert sich Red Hat beispielsweise, Kernelupdates oder auch nur aktuellere Versionen von den Paketen der Enterprise-Distribution zu verteilen. Neue Funktionen kommen in späteren Minor-Releases vielleicht als Tech-Preview hinzu, doch sicher ist das keineswegs.

Angesichts einer neuen Major-Release sind deshalb stets alle Augen auf das neue Produkt gerichtet. Was Red Hat in der Version 7.0 falsch macht, hängt dem Unternehmen schließlich eine lange Zeit nach. Das Red-Hat-Marketing sieht das freilich anders und meint in guter amerikanischer Tradition, “das Betriebssystem neu definiert” zu haben. Was RHEL 7 [2] wirklich kann, was sich im Vergleich zur Vorversion getan hat und ob sich das Update lohnt, zeigt dieser Artikel.

Die Installation

Eigentlich ist die Installation eines Linux-Systems nichts Besonderes mehr, gerade nicht in Zeiten bunter Installationsroutinen. Red Hat ist in RHEL 7 seinem Anaconda-Unterbau treu geblieben und garniert diesen mit einer simplen grafischen Oberfläche (Abbildung 1).

Abbildung 1: Der Red-Hat-Installer basiert noch immer auf Anaconda und bietet im besten Sinne Hausmannskost.

Trotzdem wartet so mancher Fallstrick auf den Admin. Denn wer sich für die Konfiguration nur an den Icons im Installer orientiert, die mit einem roten Ausrufezeichen versehen sind, hat am Ende zwar eine lauffähige RHEL-7-Installation, doch fehlt dieser praktisch alles, was für effektive Arbeit notwendig ist – ein Hostname, ordentliches Netz, Perl sowie eine grafische Oberfläche sind dafür nur einige Beispiele (Abbildung 2).

Abbildung 2: Vorsicht: Wer die minimale Paketauswahl nimmt, bekommt ein System ohne Perl oder GUI. Die Installation eines Paketsets empfiehlt sich also.

Erschwerend kommt hinzu, dass auf der Kommandozeile die Einstellungen für das Tastaturlayout nicht jene sind, die man zuvor im GUI-Installer gleich am Anfang festgelegt hatte. Im schlimmsten Falle sitzt der Admin vor einem TTY mit US-Layout, was bei einem Passwort mit Sonderzeichen zum Problem wird.

Deutlich besser kommt davon, wer während der RHEL-7-Installation gleich in der Paketauswahl eine grafische Oberfläche installiert. Dann landet er nach einem Reboot und dem Abnicken der Red-Hat-Eula (Abbildung 3) in einem deutschsprachigen Gnome-3-Desktop (Abbildung 4), der im speziellen “Klassik”-Modus läuft, und hat das angeforderte deutsche Tastaturlayout – auch wenn im Anschluss Gnome selbst nochmals nachfragt, ob dieses Layout wirklich das richtige ist.

Abbildung 3: Linux, ja, Open Source, ja – aber dennoch gilt es, nach dem Reboot erst mal eine EULA abzunicken: Nach dem ersten Start klickt sich der Admin durch Red Hats Lizenz, bevor es weitergeht.

Abbildung 4: RHEL 7 kommt mit einem Gnome-Classic-Desktop daher, der stark an Gnome 2 erinnert, aber auch Gnome-3-Elemente beinhaltet. Wer den auswählt, bekommt immerhin auch gleich die richtige Tastaturbelegung verordnet.

XFS statt Ext 3

Viele Änderungen passieren bei den Distributionen mit Langzeitsupport vom Admin eher unbemerkt: Der Wechsel des Standarddateisystems in RHEL 7 ist ein gutes Beispiel dafür. Denn nur der Aufruf von »mount« auf der Konsole legt offen, dass RHEL 7 auf XFS setzt. Damit löst XFS den vorherigen Standard Ext 4 ab, wobei letzteres selbstverständlich weiter zur Verfügung steht.

Red Hat gibt als Begründung für den Wechsel an, dass eine Default-Installation sich nun auf einem bis zu 500 Terabyte großen Device installieren lässt, doch scheint dieser Grund vorgeschoben. Über andere Motive schweigen sich die roten Hüte jedoch beharrlich aus. Denkbar scheint, dass Red Hat mit Ext 4 wegen dessen bekannter Performanceprobleme schon länger unzufrieden war und mit RHEL 7 eigentlich gleich zu Btr-FS wechseln wollte. Weil Btr-FS aber weder fertig ist noch abzusehen ist, wann es fertig wird, könnte der Schwenk auf XFS erfolgt sein – denn das gilt als so gut integriert und als so stabil, wie es auch bei Ext 4 der Fall ist.

Übrigens: Btr-FS steht in RHEL 7 als Option durchaus zur Verfügung und wird von den roten Hüten sogar mit einem eigenen Snapshot-Werkzeug namens Snapper [3] ausgestattet. Wer Btr-FS auf Red-Hat-Systemen ausprobieren möchte, kann das in RHEL 7 einfach aktivieren.

Rumms in Sachen Netzwerk

Offensichtlicher als die Festlegung eines neuen Standard-Dateisystems sind für RHEL-Admins die ausgebauten Netzwerkfähigkeiten des Systems. Hier präsentiert Red Hat einen ganzen Strauß voller Neuerungen: Support für 40-GBit-Karten, Inklusion des Team-Driver-Frameworks als Ersatz für klassisches Bonding, ein Haufen von Detailverbesserungen im TCP/IP-Stack und Low-Latency-Sockets, die auch der angepasste RHEL-Kernel ebenfalls unterstützt.

Besonders Team Driver [4] ist dabei symptomatisch für viele der Neuheiten in RHEL 7. Im Grunde tut das Framework nichts anderes, als die bis dato bekannten Bonding-Treiber im Kernel auch, aber als Daemon im Userland und eben nicht im Kernel. Davon versprechen sich die Entwickler einerseits bessere Performance und andererseits weniger Overload in hochverfügbaren Installationen – die klassischen Ziele für Bonding-Setups.

Dank RHEL 7 wissen Admins in Zukunft übrigens noch viel genauer, was die Stunde geschlagen hat. Den klassischen Ntpd ersetzt RHEL 7 durch das eigens gebaute Chrony [5] und PPTv2-Support kommt hinzu. PPT steht für Precision Time Protocol, ein Standard, der Uhren noch präziser synchronisiert, als es bei NTP der Fall ist. Red Hat spricht von wenigen Mikrosekunden Abweichung.

Cloud!

XFS, Netzwerk-Performance, neue Treiber – in den Augen des Marketings von Red Hat sind das offensichtlich eher nebensächliche Themen. Laut PR-Meldungen aus Raleigh anlässlich der Veröffentlichung der Nummer 7 soll RHEL 7 für Red Hat der ganz große Wurf sein und eine Überlegenheit gegenüber anderen Systemen etablieren, die über Jahre anhält. Red Hat setzt in der neuen RHEL-Version auf das Konzept der “Architektur für alles”, und dabei darf natürlich das unvermeidliche Buzzword “Cloud” nicht fehlen. Mehrere neue Funktionen machen deutlich, dass Red Hat Enterprise Linux 7 ein Big Player im Cloudgeschäft werden soll.

Eines der Argumente ist dabei der ab Werk vorhandene, ganz offizielle Support für Docker. Im Cloudumfeld ist der Containermanager gerade selbst ein Hype [6]: Im Grunde geht es um eine Erweiterung des Linux-Containerformats, die das Anlegen und das Verteilen von Applikations-Containern leichter macht.

Dass Docker sich in der neuen RHEL-Version offizieller Unterstützung erfreut, ist dabei durchaus bemerkenswert, denn Docker selbst existiert noch nicht besonders lange, und Red Hat ist in aller Regel sehr vorsichtig, was neue Funktionen angeht. Im Normalfall muss sich ein Projekt erst beweisen, bevor Red Hat sich festlegt, Support über viele Jahre für das Produkt zu bieten.

Vorrangig geht es bei Docker auf RHEL darum, virtuelle Systeme ohne den Overhead eines vollständig virtualisierten Computers zu betreiben. Anders formuliert: Docker-Container benötigen deutlich weniger Ressourcen als KVM-basierte virtuelle Maschinen.

Hypervisor-Verbesserungen

Auch für die Admins, die klassische Virtualisierung benötigen, hat sich Red Hat einiges einfallen lassen. Nach wie vor zeigt der Hersteller Xen die kalte Schulter und setzt ausschließlich auf KVM. Das ist angesichts der Tatsache, dass Red Hat sich einst den KVM-Erfinder Qumranet einverleibte, aber auch nicht weiter verwunderlich.

Wer Red Hat als Gastgeber einsetzen möchte, ist damit ein wenig festgelegt. Angenehmer sieht es aus, wenn RHEL 7 sich als Gast in einer Virtualisierungsumgebung ausbreiten soll: Es kommt bereits ausgestattet mit Kerneltreibern für diverse Hypervisor-Suites. Für den Einsatz auf VMware steht in Form von »open-vm-tools« nun sogar ein freies Pendant zu VMwares Tools zur Verfügung, das die Kooperation von Red-Hat-Gästen auf VMware-Hypervisoren geschmeidig machen soll.

Mehr Entropie

Auch ein lästiges Problem, das viele Virtualisierungs-Admins kennen, greift Red Hat an: Mangelnde Entropie in virtuellen Maschinen. KVM bietet in Zukunft die Option, eventuell vorhandene Random Number Generators (RNG, Zufallszahlen-Generatoren) vom Host an VMs durchzureichen. Damit steht diesen die gleiche Quelle für Entropie zur Verfügung wie dem Hostsystem.

Apropos Interoperabilität: Red Hat weist ausdrücklich darauf hin, dass der neue RHEL-Schützling ab Werk die Möglichkeit bietet, sich mit bestehender Active-Directory-Infrastruktur zu verkuppeln. Wer einen Account innerhalb von Active-Directory-Installationen hat, kann sich in solchen Setups dann je nach zugeteilten Berechtigungen auch auf Linux-Hosts einloggen.

Dadurch soll sich ein RHEL-7-System deutlich besser in bestehende Windows-Umgebungen integrieren und weniger Migrationsaufwand hervorrufen. Praktisch kann das insbesondere dort sein, wo durch Cloud Computing konsolidierte Setups einen hohen Grad an Heterogenität erreichen: Wer viele Windows- und Linux-Hosts gemischt betreibt, freut sich über ein Bindeglied zwischen den Betriebssystemwelten.

Storage

Ebenfalls für virtuelle Umgebungen dürften die Neuerungen relevant sein, die Red Hat in Sachen Storage für RHEL 7 umgesetzt hat. So kann ein Host mit der neuen Version des Betriebssystems über neue Targets für I-SCSI und FCoE-Devices für beide Protokolle exportieren; die Implementation in RHEL 6 war gegenüber der neuen Variante laut Red Hat deutlich langsamer. Ob sich der neue Treiber in RHEL selbst tatsächlich bezahlt macht, muss sich herausstellen. Vor dem Hintergrund, dass ein aktuelles RHEL aber stets auch Basis für viele andere Produkte aus Raleigh ist – darunter auch der Red Hat Storage Server –, darf man aber zumindest davon ausgehen, dass Red Hat viel Zeit in dieses Feature investiert hat.

Systemadministration und Performance

Gleich mehrere Schmankerl wollen Systemadministratoren die Arbeit erleichtern. Eine Komponente hierzu ist der Performance Co-Pilot (Abbildung 5). Dieses Framework zeichnet verschiedene Werte mit Relevanz für die Performance des Systems auf und überwacht sie. So soll es dem Admin schneller auffallen, wenn eine durchgeführte Änderung die Performance des Systems negativ beeinflusst. Über ein grafisches Werkzeug erhält er Zugriff auf alle relevanten Daten und kann dort gezielt nach Störenfrieden suchen. Wer schon mal stundenlang ein System untersucht hat, um die Quelle für schlechte Leistung zu finden, wird sich über diese Komponente freuen.

Abbildung 5: Der Performance Co-Pilot »pcp« hilft dem Administrator dabei, die Performance des Systems im Griff zu behalten, und gibt für die Fehlersuche hilfreiche Informationen aus.

Hinzu kommen mehrere Werkzeuge, die den Admin bei der Verbesserung seiner Systemperformance unterstützen, zum Beispiel Tuna. Mit dem Thunfisch lassen sich verschiedene Performance-bezogene Kernelparameter bearbeiten, auch Profiling verschiedener Dienste ist möglich. In Kombination mit »tuned« entsteht ein Gesamtbild: Tuned kann anhand fertiger Profile, die RHEL 7 beiliegen, bestimmte Systemparameter automatisch setzen.

Per Default sind die auf Grundlage der RHEL-Produktvariante, die der Kunde einsetzt, voreingestellt. Ein Storage-Server wird also ein anderes Profil nutzen als ein Knoten, der sich um virtuelle Maschinen kümmern. Ein gewisses Grund-Tuning ist bei RHEL 7 ab Werk bereits aktiviert, der Admin kann sich um die Details kümmern.

In-Place-Upgrades

Bei LTS-Systemen ist Kontinuität bei Upgrades ein Faktor, der auf den ersten Blick eher zweitrangig scheint. Viele Unternehmen haben den Lebenszyklus ihrer Hardware mit dem der Software in Einklang gebracht, sodass nach den üblichen fünf Jahren, wenn die alte Hardware aus der Garantie fällt, ein schleichender Übergang die Regel ist. Neben der Anschaffung neuer Hardware ziehen die Admins dann auch gleich das OS-Upgrade durch.

Im Grunde funktioniert der Zyklus gut, wenn er genau so eingespielt ist. Möchte ein Unternehmen aber vor Ablauf der Garantie bereits ein Update durchführen, taugt der Ansatz nur bedingt. Ubuntu unterstützt ein Update zwischen LTS-Versionen ab Werk, auch Red Hat hatte eine entsprechende Funktion. Die war jedoch stets mühsam, teils unrund und hinterließ oft genug mehr Schaden als Nutzen. In RHEL 7 soll damit Schluss sein; ein eigener “Assistent für In-Place Upgrades” erleichtert hier ein Ugprade von RHEL 6 auf 7.

Voraussetzung dafür ist aber, dass der Admin zuvor RHEL 6.5 einsetzte. Nur dann ist ein entsprechendes Paket verfügbar, das ihm schon vorab einen Überblick über den Ablauf liefert: Neben der Information, welche Änderungen automatisch durchführbar sind, enthält der Report auch solche Änderungen, die der Admin selbst erledigen muss.

Lokale Installationsmedien

Bei der Automatisierung von Deployments legt Red Hat ordentlich vor: Anaconda und Kickstart gelten als robuste und gut funktionierende Tools. In der neuen RHEL-Version lässt sich mit ihnen auch ein verändertes Bootmedium zur Systeminstallation zusammenstellen. Statt das Standardmedium zu nutzen, baut der Admin sich also eine eigene Installations-CD oder einen USB-Stick.

Mit den so veränderten Einstellungen fügen sich neue Systeme unmittelbar nach der Installation bereits in die Gegebenheiten des lokalen Setups ein. Im Grunde bildet die Funktion ein Mittelding zwischen Bare-Metal-Deployment-Tools wie Cobbler [7], Foreman [8] und Chef [9] und einer manuellen Konfiguration nach der Installation. Der Vorteil an so modifizierten Installationsmedien liegt auf der Hand: Admins können eigene Setups nutzen, ohne die Installation eines eigenen Dienstes hierfür vorzuschreiben.

Red Hat Enterprise Linux 7 ist die erste RHEL-Version, in der offiziell der Nachfolger des alten Sys-V-Init-Systems Einzug hält: Systemd. Nur sehr wenige Software-Komponenten der FLOSS-Community haben seit Anbegin ihrer Existenz so viel Wirbel verursacht. Einig sind sich im Grunde alle Distributionen darüber, dass das alte Sys-V-Init-System sehr veraltet wirkt und durch ein zeitgemäßeres Werkzeug ersetzt gehört.

Ubuntu und Red Hat preschten mit unterschiedlichen Ansätzen voran: Ubuntus Upstart war sehr schnell fertig und in Ubuntu 12.04 bereits vorhanden, also vor über zwei Jahren. Red Hat hatte eine größere Vision und wollte das Init-System durch eine Zentralstelle für Systemverwaltung ersetzen – also ein Kontrollzentrum, das die wichtigen Dienste und Parameter zentral steuert. Die Umsetzung, Systemd, fand über verschiedene Fedora-Versionen nun den Weg in RHEL.

Erste Enterprise-Distribution mit Systemd

Aber groteskerweise ist der so wichtige Systemd nicht vorrangig deshalb bekannt geworden, weil Admins über die Vor- und Nachteile der Lösung diskutieren. Freilich kann man unterschiedlicher Meinung hinsichtlich der Frage sein, wie tief ein Init-Tool seine Finger überhaupt im System haben sollte und wo sich andere Werkzeuge um die Verwaltung zu kümmern haben.

Doch Systemd kam vielmehr wegen seines Autorenteams zu unrühmlicher Bekanntheit: Entwickler Lennart Poettering gilt vielen als arrogant, abgehoben und herabwertend, wie manche seiner kontroversen Posts zeigen [10].

Dass RHEL 7 Systemd ab Werk liefert, ist insofern interessant, als dass es sich um den ersten Enterprise-Einsatz der Software handelt. Langfristig geht wohl an Systemd so oder so kein Weg vorbei; nach einer langen Diskussion hat vor einiger Zeit auch das Debian-Projekt beschlossen, auf Systemd zu setzen. Zwar relativierte man die Entscheidung kurze Zeit später, doch Ubuntu-Mäzen Shuttleworth hatte Upstart bereits für tot und Systemd zum neuen Standard in künftigen Ubuntu-Versionen erklärt.

Weil auch Suse in SLES 12 auf Systemd setzen wird, ist das Produkt bald in allen Major-Distributionen Standard. Ob sich der Ruf von Systemd erholt, wenn die Software sich in Produktion beweisen kann, muss die Zeit zeigen. Ein beruhigter, kontroverser aber weniger emotionaler Dialog ist dann auf jeden Fall möglich.

RHEL als Desktop

Eine grafische Oberfläche gilt bei Enterprise-Systemen als eher zweitrangig, auch weil diese Systeme vorrangig auf Servern landen. Zwar gibt es bei den Distributoren keine Enterprise-Desktops mehr, wie Suse sie zeitweilig im Angebot hatte. Dennoch installieren viele Firmen RHEL und Konkurrenten durchaus auch auf Desktops, um eine gewisse Kontinuität bei den Arbeitsplätzen der Mitarbeiter sicherzustellen.

RHEL 7 kommt auch deshalb mit drei verschiedenen Desktops daher: In der Standardkonfiguration kommt Gnome Classic zum Einsatz, das in Aussehen und Erscheinung stark an Gnome 2 erinnert. Alternativ stehen KDE 4 und Gnome 3 mit der Gnome-Shell bereit. Die meisten typischen Desktop-Werkzeuge wirken aber bereits jetzt prähistorisch: Firefox 24 reißt niemanden mehr vom Hocker, zum Redaktionsschluss war bereits Nummer 30 auf dem Desktop der Testrechner des Linux-Magazins.

Eine Bürosuite wie Libre oder Open Office fehlt gänzlich und ist manuell nachzuinstallieren. Hinzu kommt, dass der betagte Kernel 3.10, den RHEL verwendet, in relativ kurzer Zeit Unterstützung für aktuelle Desktop-Hardware vermissen lassen wird. Hier zeigt sich, dass Red Hat mit RHEL eben doch vorrangig auf Server abzielt. Für den alltäglichen Einsatz empfiehlt sich eine Fedora-Installation jedenfalls eher, auch wenn die Rothüte nicht müde werden zu beteuern, dass man via Backports auch neue Features in die alten Kernel bringe.

Drama Hochverfügbarkeit

Erst ganz am Ende des Changelog von RHEL 7 finden sich mehrere Bemerkungen zum Thema Hochverfügbarkeit. Fast hat es den Anschein, als wolle der Hersteller das nicht an die große Glocke hängen. Tatsächlich hat sich RHEL 7 in Sachen Hochverfügbarkeit so stark verändert wie seit etlichen RHEL-Major-Versionen nicht mehr. Denn ab RHEL 7 sitzt Red Hat im Pacemaker-Boot und adoptiert damit als letzter Hersteller den De-facto-Standard, was Clustermanagement auf Linux angeht.

Während in den letzten 15 Jahren Suse viel Geld investierte, um die Entwicklung von Heartbeat 1 und Heartbeat 2 voranzutreiben, tanzte Red Hat lieber auf einer eigens arrangierten Hochzeit. Aus der Backupsoftware namens Piranha schnitzte man kurzerhand eine HA-Lösung, die später unter der Bezeichnung Red Hat Cluster Suite (RHCS, [11]) firmierte. Als sich im Rahmen des Service Availability Forum (SAF) viele Unternehmen auf einen gemeinsamen Standard für Clusterkommunikation einigten, schlossen sich auch die roten Hüte der Gruppe an.

Red-Hat-Entwickler schrieben die erste FLOSS-Implementierung von AIS, der Application Interface Specification. Novell griff seinerzeit den Ball auf und wies den eigenen Entwickler Andrew Beekhof an, Heartbeat 2 so umzubauen, dass es mit der Open AIS genannten Suite funktionierte. Pacemaker war geboren [12].

Doch Red Hat wäre nicht Red Hat, hätte die Firma nicht einen ganz eigenen Weg für die Pacemaker-Integration gefunden. Corosync [13] als Nachfolger von Open AIS und Pacemaker funktionieren in dieser Kombination einwandfrei. Red Hat beschloss hingegen, »cman« aus der RHCS zu recyclen und ihn Pacemaker an die Seite zu stellen. Wer auf anderen Distributionen bereits erfolgreich ein Pacemaker-Setup gebaut hat, muss sich für Red Hat also umgewöhnen.

Das gilt in noch größerem Maße für die Modifikation der Clusterkonfiguration. Pacemaker setzt hier intern noch immer auf eine in XML abgebildete Datei, die alle Ressourcen enthält. Suse steuerte bereits vor Jahren ein Werkzeug bei, um diese XML-Datei über normale Text-Dateien zu editieren; »crmsh« [14] übernimmt dabei die Übersetzung zwischen Text und XML.

Red Hat wollte die CRM-Shell aber nicht und begann mit der Arbeit an PCS, das in RHEL 7 das Standardwerkzeug zur Clusterkonfiguration ist. Die meisten Anleitungen im Netz beziehen sich hingegen noch immer auf die CRM-Shell, die PCS auch im Hinblick auf verschiedene Features deutlich überlegen ist. Wer RHEL 7 nutzt, um Hochverfügbarkeit zu realisieren, kriegt also Pacemaker, aber eines, das deutlich nach Red Hat schmeckt (Abbildung 6).

Abbildung 6: RHEL 7 ist die erste Version von RHEL, die mit Pacemaker kommt – aber mit einem Red-Hat-Pacemaker.

Fazit

Red Hat Enterprise Linux 7 ist ein solides Upgrade, das die Erwartungen von passionierten Red-Hat-Admins nicht enttäuschen wird. Einige Neuerungen sind wirklich pfiffig; über die Performance-Profile lassen sich laut Versprechen der RH-Marketingabteilungen bis zu 40 Prozent Geschwindigkeitsvorteil über ältere RHEL-Versionen erzielen.

Der Kern des Betriebssystems, Linux 3.10, ist ein typischer Frankenstein-Kernel – wie üblich bei Enterprise-Systemen – und über einen riesigen Haufen Patches fast auf den aktuellen Stand von Linux 3.15 gebracht. Wer also mit RHEL 6 angefangen hätte, kann gleich zu RHEL 7 greifen. Ob sich für die Features ein dezidiertes Update lohnt, kann nur die Analyse im Einzelfall klären. Einen dringenden, pauschal gültigen Grund, von RHEL 6 auf die neue Version zu aktualisieren, gibt es nach Meinung des Linux-Magazins jedoch nicht.