Vergangenes Wochenende hatten wir relativ kurzfristig eine Downtime von Planet 3DNow! angekündigt, ohne - wie sonst bei uns üblich - ausführlich zu erläutern, was gemacht werden soll und gemacht worden ist. Das möchten wir heute nachholen.
Nachdem Euer neuer Community-Server - aka Das Boot - seit Anfang 2006 online ist und zuverlässig seinen Dienst verrichtete, hatten wir aufgrund der massiv gestiegenen Besucherzahlen bereits Mitte Februar 2007 ankündigen müssen, dass die Maschine ein umfangreiches Hard- und Software Upgrade bekommen würde. Neue Prozessoren, einen Satz neuer Festplatten und vor allem ein neues Betriebssystem: Sun Solaris 10. Die Euphorie war riesig. Ein professionelles Server-Betriebssystem für den grünen Planeten, dazu eine Hardware, die Bäume ausreißen konnte. Gleich am ersten Tag ließ der Server seine Muskeln spielen. Ein neuer Besucher-Rekord, sowohl auf der Webseite, als auch im Forum und das mit einer Geschwindigkeit, die einen eher an statische HTML-Files im LAN, denn an dynamisch generierte PHP-Files auf einem Webserver schließen ließ, deuteten auf eine rosige Zukunft hin. Doch es sollte anders kommen...
Bereits 4 Tage nach der Inbetriebnahme des aufgerüsteten Servers ereilte uns aus heiterem Himmel und ohne Vorwarnung der Super-Gau für jeden Administrator: ein Totalabsturz des Systems und eine trotz Raid-1 regelrecht zerstückelte System-Partition. Der Schuldige war schnell ausgemacht. Ein fehlerhaft arbeitender SATA-Controller schien die System-Partition vernichtet zu haben. Zwar blieben von Anfang an Fragen offen - schließlich hatte uns dieser Controller bereits ein Jahr lang zuverlässig als Backup-Controller gedient - aber zunächst schien sich die alte Admin-Weisheit zu bewahrheiten, dass SCSI für einen stark frequentierten Webserver die einzig richtig Lösung ist. Allerdings hatten wir auch den Sil3114-Treiber unter Solaris (Status "known to work") auf der Rechnung. Aus verständlichen Gründen hatten wir allerdings nicht die Muse herauszufinden, ob nun der Controller oder der Treiber an der Misere schuld war. Gott Lob war den Daten - also den Inhalten der Webseite - nichts passiert. Die lagen auf einem SCSI-Raid. Nach fast 4 Tagen Downtime konnten wir den Server - nun in einer SCSI-only Konfiguration - wieder online bringen und glaubten uns über den Berg.
Allerdings hatten wir hier die Rechnung ohne den Wirt gemacht. Im Abstand von ein bis drei Tagen verabschiedete sich der Server mit einer kernel panic - vergleichbar einem Bluescreen unter Windows. Ein erster Blick in das dumpfile brachte zum Vorschein, dass der Absturz irgendetwas mit dem Netzwerk oder dem Netzwerk-Controller zu tun haben musste. Nur was? Nach dem fehlerhaften SATA-Treiber nun etwa auch noch ein fehlerhafter Broadcom-Treiber? Langsam machte sich Ernüchterung breit. Nach einem Jahr beinahe sorgenfreien Betriebs des Boot 1.0 nun Hiobsbotschaften im Tagesrhythmus. Haben wir beim Hardware-Upgrade irgendetwas falsch gemacht? Unsere Standard-Stabilitätstests unter Knoppix sagten "Nein". Alles ok. Hatten die neuen Hardware-Komponenten einen Patscher? Oder war es etwa ein Fehler auf Solaris 10 zu setzen? Noch tappten wir im Dunkeln.
Nach ein paar weiteren Abstürzen und etlichen Stunden Fehlersuche offenbarte sich ein erster Strohhalm an den wir uns klammern konnten. Die Bugbeschreibung "On Solaris 10 Kernel Memory Corruption May be Seen in TCP/IP Under High Stress Resulting in a System Panic" schien wie die Faust auf's Auge zu unserem Problem zu passen. Ein bisher nicht eingespielter Patch sollte alle Probleme lösen. Leider ein Trugschluss. Der Server zickte nach wie vor im 2-Tages Rhythmus herum und das ausgerechnet zur CeBIT. CeBIT? Genau! Sun ist doch auch auf der CeBIT, also schickten wir unsere "schnelle Eingreiftruppe" in Hannover rasch am Sun-Stand vorbei, um von unseren merkwürdigen Phänomenen zu berichten und hoffentlich einen guten Tipp zu erhalten. Allerdings war das Gespräch unerwartet schnell zu Ende. Wenn wir einen Supportvertrag für 240 US-Dollar im Jahr - oder am besten den Premium-Support für 1040 US-Dollar - abschließen würden, bekämen wir jede Hilfe die wir bräuchten. Außerdem könnten wir ja einen Sun Fire Server erwerben wenn wir wollen. Wir wollen nicht...
Hilfe bekamen wir weiterhin aus zwei Quellen. Einmal von unserem Community-Mitglied Mogul, zum anderen von Jörg Möllenkamp, der als Beschäftigter bei Sun einen Blog u.a. zum Thema Solaris betreibt und sich unsere crashdumps genauer angesehen hat. Über diese Quellen mussten wir zum Beispiel auch erfahren, dass es von Sun noch wesentlich mehr Patches gibt, als die ohnehin schon zahlreichen, die wir bereits eingespielt hatten. Allerdings bleiben die normalerweise den zahlenden Kunden vorbehalten. Erste Zweifel am Support-Modell von Sun machten sich breit. Kostenpflichtiger Support für individuelle Beratung oder für die Bereitstellung spezieller Features, ok. Aber zahlen für kritische Updates, damit das OS überhaupt stabil zu betreiben ist? Das war nicht mit unserer Auffassung von Support zu vereinbaren. Wie der Zufall es will gab es in diesem Pool einen weiteren Patch, der das Problem beheben sollte. Über inoffizielle Kanäle haben wir ihn auch zum Testen erhalten. Nach drei Tagen aber wieder das selbe Problem: Kernel Panic.
Das war der Punkt, an dem wir endgültig die Nase voll hatten. Seit Ende Februar hatten wir wegen der fortwährenden Probleme mit dem System mehr als 4.500 km zurückgelegt. Mehr als 600 Mann-Stunden hatte das Projekt seitdem verschlungen. Wohlgemerkt neben der normalen Arbeit, denn Planet 3DNow! ist für alle Beteiligten lediglich ein - wenn auch inzwischen sehr zeitaufwändiges - Hobby. Die 4-tägige Downtime Anfang März hat den grünen Planeten zudem bis heute fast ein Drittel an Besuchern gekostet und im Forum machte sich selbst bei den Stammbesuchern langsam Unmut breit über die zahlreichen Ausfälle durch sowohl die Abstürze, als auch die geplanten Downtimes beim Einspielen von Patches oder beim Reparieren von bei Abstürzen zerschossener Dateien. Dass unsere Frauen in den letzten Tagen auffällig häufig in den gelben Seiten unter "Scheidungsanwälte" blätterten, sei nur nebenbei erwähnt.
Nein, irgendwann einmal musste Schluss sein. Die zwei Hauptgründe für die Wahl von Solaris war das ZFS-Dateisystem sowie die unerschütterliche Stabilität, die dem Betriebssystem nachgesagt wird. Dieser Nimbus jedoch war bei uns auf alle Zeit zerstört, das Vertrauen dahin. Wir ertappten uns schon dabei im Dreischicht-Betrieb Serverwachen zu halten, damit wenigstens einer der Admins online ist, um zerfetzte Dateien wiederherstellen zu können, wenn der Server eine seiner Panik-Attacken hinter sich hatte. Mag sein, dass Solaris 10 auf Sun-Servern mit einer schmalen Bandbreite an eingesetzter Hardware und allen kostenpflichtigen Patches tatsächlich völlig problemlos arbeitet, auf unserer Maschine jedoch war das OS rückblickend ein teurer und zeitaufwändiger Mißgriff. Die einzige Möglichkeit das ZFS-Dateisystem als Feature nicht zu verlieren, wäre gewesen von Solaris 10 auf OpenSolaris zu wechseln. Aber ob das die Probleme auf unserer Maschine behoben hätte, konnte niemand mit Bestimmtheit vorher sagen. Nein, das Wichtigste, das wir nun brauchten, war Stabilität, um Vertrauen in den Server, bei den Besuchern und Besucher an sich zurück zu gewinnen, um im Reallife wieder ein Leben neben Planet 3DNow! führen zu können und vor allem um wieder ruhigen Gewissens ins Bett gehen zu können ohne fürchten zu müssen, dass am nächsten Tag ein weiterer Tiefflug nach Frankfurt bevorstehen könnte, um das System wiederzubeleben. Daher haben wir am zurückliegenden Wochenende in einem weiteren (und hoffentlich für lange Zeit letzten) Frankfurt-Aufenthalt Solaris 10 wieder vom Server geworfen und ein aktuelles Gentoo-Linux AMD64 installiert. Mit der Bekanntgabe dessen wollten wir allerdings warten bis sicher war, dass wir Solaris 10 nicht unrecht tun, dass die Probleme nicht etwa doch trotz aller bestandener Hardware-Stabilitätstests durch eine beim Upgrade beschädigte Komponente verursacht wurden. Wenig überraschend jedoch ist der Server seitdem wieder fromm wie ein Lamm.
Umso ärgerlicher ist unser Fehlschlag mit Solaris, da wir so gut vorbereitet wie noch nie in dieses Projekt gingen. Schon Wochen vor dem Upgrade lief Solaris auf einem Spiegelserver im Testbetrieb - völlig ohne Probleme wie es schien. Dort wurde auch die Konfiguration verfeinert, die Applikationen wurden installiert und angepasst - alles um eventuellen Problemen auf die Spur zu kommen, ehe das System auf der Produktiv-Maschine landet. Eines allerdings fehlte auf dem Testserver natürlich: fortwährende(r) und praxisbezogene(r) Last/Traffic über Tage hinweg.
So verlassen wir Solaris mit einem lachenden und einem weinenden Auge. Mit einem lachenden logischerweise, weil der Server nun mit Linux endlich wieder stabil arbeitet, weil wir nun wieder Anwendungen einsetzen können, die uns mit Solaris verwehrt waren (eaccelerator oder sämtliche Distributed Computing Anwendungen, bei denen P3D mit einem Team mitmischt), mit einem weinenden allerdings, da Solaris in den Tagen zwischen den Abstürzen sein Potenzial eindrucksvoll angedeutet hat. Eine traumhaft niedrige Systemlast verglichen mit Gentoo zum Beispiel, obwohl Gentoo in der Linux-Welt bereits als die mit am besten optimierte Distribution gilt. Oder die beispielhafte Performance des ZFS-Dateisystems, das lesend vom Raid-1 eine Readspeed von über 200 MB/s zu Stande brachte, während wir mit ext3 in der selben Konfiguration unter Linux nun wieder bei 90 MB/s dümpeln. Aber sei's drum.
Bedanken möchten wir uns an dieser Stelle noch bei Mogul, der uns alle Hilfe anbat, die er uns geben konnte, bei Jörg Möllenkamp der einerseits bei der crashdump-Analyse half, andererseits sich als Sun-Mann in seinem Blog aber auch leider zu der ein oder anderen unnötigen geringschätzigen Bemerkungen über unsere Admins hinreißen ließ, nachdem erste Kritik am OS bzw. am Supportmodell laut wurde; bei unseren beiden technischen Administratoren D'Espice und tomturbo, die in den letzten 6 Wochen scheinbar einen Weg gefunden haben die Raumzeit zu krümmen, um all die Zeit, die der Server für sich beanspruchte, irgendwo unterzubringen und natürlich bei unseren Besuchern, die nun wahrlich mehr als genug Geduld aufbringen mussten, wenn das Boot mal wieder im Trockendock stand und uns trotzdem (zumindest in der Mehrheit) nicht den Rücken kehrten. So kann auf dem grünen Planeten nun hoffentlich wieder Normalität einkehren.
Diesen Artikel bookmarken oder senden an ...
