Migration auf RHEL 6 — was uns überrascht hat

Red Hat Enterprise Linux 5 hat uns vier Jahre lang treu gedient. Doch mit dem nahenden Ende des erweiterten Supports und den stetig wachsenden Anforderungen unserer Java-Anwendungen an Systemressourcen haben wir uns zum Jahreswechsel für ein Upgrade auf RHEL 6 entschieden. Was wie eine Routineoperation aussah, entpuppte sich als interessante Herausforderung.

Warum wir migriert haben¶

RHEL 6 brachte einen neuen Kernel 2.6.32 mit deutlich verbesserter Speicherverwaltung, ext4 als Standard-Dateisystem und ein komplett überarbeitetes Init-System — Upstart anstelle des klassischen SysV init. Für unsere Produktionsumgebung mit Dutzenden von Diensten bedeutete das, die meisten Init-Skripte umzuschreiben. Die Hauptmotivation war der Support — RHEL 5 näherte sich dem Ende des vollen Supports und Sicherheitspatches kamen langsamer. Für unsere Kunden im Finanzsektor ist aktueller OS-Support eine Betriebsvoraussetzung.

SELinux — diesmal wirklich¶

Seien wir ehrlich — auf RHEL 5 haben wir SELinux auf den meisten Servern deaktiviert. Es war einfacher, als sich mit endlosen AVC-Denial-Meldungen herumzuschlagen. Auf RHEL 6 haben wir beschlossen, es richtig zu machen und SELinux im Enforcing-Modus zu belassen. Die erste Woche war schmerzhaft. Unsere benutzerdefinierten Java-Anwendungen auf Tomcat brauchten eigene SELinux-Policies. Der GlassFish-Server schrieb Logs in nicht-standardmäßige Verzeichnisse. Oracle Instant Client hatte Probleme beim Zugriff auf Shared Libraries. Jedes Problem bedeutete Stunden mit audit2allow und manuellem Policy-Tuning.

Aber das Ergebnis lohnt sich. Wir haben jetzt Server, auf denen eine kompromittierte Webanwendung nicht außerhalb ihres eigenen Verzeichnisses lesen kann. Für unsere Kunden im Bankensektor ist das eine grundlegende Sicherheitsverbesserung.

Dateisystem — ext4 und LVM¶

Der Übergang von ext3 zu ext4 verlief überraschend reibungslos. Besonders schätzten wir den schnelleren fsck — auf Servern mit Terabyte-Dateisystemen bedeutet das einen Unterschied von Stunden bei einem ungeplanten Neustart. Extents statt indirektem Block-Mapping beschleunigten sequentielle I/O-Operationen, was sich besonders bei Backups bemerkbar machte. LVM-Snapshots auf ext4 funktionieren zuverlässiger und schneller. Unser Backup-Skript, das einen konsistenten Snapshot der Oracle-Datenbank erstellt, wurde um 40 % schneller.

Anwendungskompatibilität¶

Das größte Problem? Bibliotheken. RHEL 6 wechselte auf glibc 2.12 und einige ältere Binärdateien funktionierten einfach nicht mehr. Konkret machte uns der Oracle Database Client 10g zu schaffen — er wird auf RHEL 6 offiziell nicht unterstützt. Wir mussten auf den 11g-Client upgraden, was Änderungen an tnsnames.ora und das Testen aller JDBC-Verbindungen bedeutete. Java 6 (OpenJDK) läuft auf RHEL 6 problemlos, aber Vorsicht bei Unterschieden in den Cryptographic Providers.

Upstart vs. SysV init¶

Upstart ist konzeptionell besser als SysV init — ereignisgesteuert, paralleler Dienststart, automatischer Respawn. Aber zwanzig benutzerdefinierte Init-Skripte auf Upstart-Konfiguration umzuschreiben kostete zwei Tage Arbeit. Glücklicherweise unterstützt RHEL 6 auch die alten SysV-Skripte über eine Kompatibilitätsschicht, sodass wir schrittweise migrieren konnten. Tipp: Migrieren Sie nicht alles auf einmal.

Netzwerk und Firewall¶

RHEL 6 verwendet weiterhin iptables, aber die Konfigurationswerkzeuge sind verbessert. Neu ist NetworkManager als Standard-Netzwerkmanager. Auf Servern deaktivieren wir ihn sofort — wir wollen statische Konfiguration in /etc/sysconfig/network-scripts, keinen dynamischen Manager.

Lehren aus der Migration¶

Eine Betriebssystem-Migration in der Produktion ist nie trivial. Planen Sie mindestens doppelt so viel Zeit ein, wie Sie schätzen. Testen Sie SELinux-Policies im Voraus in der Staging-Umgebung. Und vor allem — haben Sie einen Rollback-Plan.